# Fedora 33でkubernetesクラスタ組む

2020/11/21

kubernetes

GKEの料金を支払うのがつらくなってきたので、自宅にFedora 33でkubernetesクラスタを組んだときのメモ。

# 環境

3ノード、シングルコントロールプレーンクラスター。コントロールプレーンはワーカーノードと共有。CNIはflannel。

基本的には以下のkubernetes公式ドキュメントに従って進めます。

$ cat /etc/redhat-release
Fedora release 33 (Thirty Three)
$ docker --version
Docker version 19.03.13, build 4484c46d9d
$ kubeadm version
kubeadm version: &version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.3", GitCommit:"1e11e4a2108024935ecfcb2912226cedeafd99df", GitTreeState:"clean", BuildDate:"2020-10-14T12:47:53Z", GoVersion:"go1.15.2", Compiler:"gc", Platform:"linux/amd64"}
$ kubectl get pod -n kube-system kube-flannel-ds-5dbpv -o jsonpath='{.status.containerStatuses[0].image}'
quay.io/coreos/flannel:v0.13.0

1
2
3
4
5
6
7
8

参考までに、雑構築Playbook (opens new window)を置いておきます。

# ハマったところ

# Fedora 33用のdocker rpmがない

VMをFeroda 33で構築してさぁkubeadmインストールしようとしたときに気付きました。

以下のissueで要望も上がっていますが、Fedora 33自体がかなり新しい(2020年10月29日リリース)なので、まだないようです。

Please Provide a Repo for Fedora 33 (opens new window)

こういう場合、たいてい一つ前のディストリビューション用のrpm入れれば動きます。以下のrpmをインストールしました。

- name: install docker
  dnf:
    name:
      - https://download.docker.com/linux/fedora/32/x86_64/stable/Packages/containerd.io-1.3.7-3.1.fc32.x86_64.rpm
      - https://download.docker.com/linux/fedora/32/x86_64/stable/Packages/docker-ce-19.03.13-3.fc32.x86_64.rpm
      - https://download.docker.com/linux/fedora/32/x86_64/stable/Packages/docker-ce-cli-19.03.13-3.fc32.x86_64.rpm

1
2
3
4
5
6

趣味用なのでいいかなと。

# `zram-generator`サービスが勝手にSwapを作成する

kubeadmのインストール#始める前に (opens new window)にも記載がある通り、各ノードでSwapは無効化しないといけないです。

kubeadm initでコケるので必ず無効化しないといけないですが、/etc/fstabやswapoffコマンドでSwapを無効化しても、OSを再起動するとなぜかswapが勝手に作られてしまいます。

Swap領域が/dev/zram0に作られていて、なんだコレと思って調べた結果、zram-generator (opens new window)というsystemdサービスがあって、こいつが勝手にswapをzram上に作っていました。

なのでサービスを無効化します。私はrpmパッケージごとアンインストールしました。

- name: remove zram-generator to disable swap
  dnf:
    name: zram-generator
    state: absent

1
2
3
4

# CNIプラグインのインストールディレクトリが変わったのか

ドキュメントに従ってクラスタを構築して、flannelのマニフェストをapplyしても、CoreDNSのPodがRunningにならず困りました。

Podをdescribeしてもあまり要領のいいエラーメッセージが出ていなかったのですが、nodeをdescribeしたところ、kubeletでエラーが発生していることがわかりました。

journalctl -e -u kubelet.serviceでkubeletサービスのエラーログを見てみると、以下のようなエラーメッセージが出ていました。

[failed to find plugin "flannel" in path [/opt/cni/bin] failed to find plugin "portmap" in path [/opt/cni/bin]

flannelやportmapのプラグインが/opt/cni/binにないよと怒られています。

findで探したところ、portmapやflannelコマンドは、/opt/cni/binではなく/usr/libexec/cniに配置されていました。このファイルは、containernetworking-pluginsというrpmパッケージによってダウンロードされていました。

$ dnf provides /usr/libexec/cni/portmap
メタデータの期限切れの最終確認: 0:08:56 時間前の 2020年11月21日 17時56分31秒 に実施しました。
containernetworking-plugins-0.8.7-1.fc33.x86_64 : Libraries for writing CNI plugin
Repo        : @System
一致:
ファイル名    : /usr/libexec/cni/portmap

1
2
3
4
5
6

このrpmパッケージは、kubeletによってインストールされるようです。

Kubernetesバイナリとパッケージの内容 (opens new window)

kubeletがcontainernetworking-pluginをインストールするパスが変わったけど、それを読み込むパスの方が変わっていないのでしょうか。よくわかりません。

kubelet起動時のオプション--cni-bin-dirで変更してもいいようですが、私は以下のようにSymlinkを張って解決しました。

- name: mkdir for cni plugin
  file:
    path: /opt/cni
    state: directory

- name: create symlink for cni plugin
  file:
    path: /opt/cni/bin
    src: /usr/libexec/cni
    state: link
    force: yes

1
2
3
4
5
6
7
8
9
10
11

おわり。

コメントする

name

content