Kubernetes v1.18とflannelとmetallbを構成してみた

この記事は約11分で読めます。
スポンサーリンク

タイトルのとおりですが、久しぶりにKubernetesをオンプレに導入してみました。

とりあえず現時点で最新のv1.18.3です。

過去記事「Kubernetesのラボ、初期構築」からのアップデートです。

はじめに

1年ほど前に執筆した以下の記事(当時はv1.12)からのアップデートです。

今回は全てのコマンドとかの紹介はしていないので、適宜上記と照らし合わせながら確認してください。

今回の構成

  • Master:Centos7 CPU1/Memory 2GB/Storage 6GB
  • Node(2つ):Centos7 CPU1/Memory 1GB/Storage 5GB
  • LB Node:Centos7 CPU1/Memory 1GB/Storage 5GB

とりあえずの検証目的なら、意外とスペック低くても動くのね!

[root@master-prod ~]# cat /etc/redhat-release
CentOS Linux release 7.8.2003 (Core)

ちなみに、Masterノードは構成時(kubeadm init)時に「CPUが2つ以上必要だよ!」と怒られますが、オプションで回避できました。v1.12の時にできたのか、謎です。

最終的な構成バージョンはこちら。

[root@master-prod ~]# kubectl get node
NAME          STATUS   ROLES    AGE   VERSION
master-prod   Ready    master   57m   v1.18.3
node1-prod    Ready    <none>   43m   v1.18.3
node2-prod    Ready    <none>   39m   v1.18.3
nodelb-prod   Ready    <none>   34m   v1.18.3

一応、導入直後のPod情報とかも貼っておきます。

こーゆーのが、どこかの誰かの助けになってることもあるしな

[root@master-prod ~]# kubectl get namespace
NAME              STATUS   AGE
default           Active   80m
kube-node-lease   Active   80m
kube-public       Active   80m
kube-system       Active   80m
metallb-system    Active   53m
[root@master-prod ~]# kubectl get pod -n kube-system
NAME                                  READY   STATUS    RESTARTS   AGE
coredns-66bff467f8-cbnvb              1/1     Running   2          78m
coredns-66bff467f8-gh2zn              1/1     Running   2          78m
etcd-master-prod                      1/1     Running   3          80m
kube-apiserver-master-prod            1/1     Running   3          80m
kube-controller-manager-master-prod   1/1     Running   3          80m
kube-flannel-ds-amd64-8cbjk           1/1     Running   1          57m
kube-flannel-ds-amd64-flx99           1/1     Running   3          78m
kube-flannel-ds-amd64-jxjdp           1/1     Running   2          66m
kube-flannel-ds-amd64-r84nw           1/1     Running   1          62m
kube-proxy-4vmw6                      1/1     Running   1          62m
kube-proxy-6hv2w                      1/1     Running   2          78m
kube-proxy-nbgsb                      1/1     Running   0          57m
kube-proxy-xzn2s                      1/1     Running   1          66m
kube-scheduler-master-prod            1/1     Running   3          80m
[root@master-prod ~]# kubectl get pod -n metallb-system
NAME                         READY   STATUS    RESTARTS   AGE
controller-b6fff6579-7s9nj   1/1     Running   0          45m
speaker-9bv9p                1/1     Running   0          45m
speaker-lzgmj                1/1     Running   0          45m
speaker-z4pt8                1/1     Running   0          45m
speaker-zhv4s                1/1     Running   0          45m
[root@master-prod ~]# kubectl get ds -n metallb-system
NAME      DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR                 AGE
speaker   4         4         4       4            4           beta.kubernetes.io/os=linux   46m
[root@master-prod ~]# kubectl get deployment -n metallb-system
NAME         READY   UP-TO-DATE   AVAILABLE   AGE
controller   1/1     1            1           46m
[root@master-prod ~]# kubectl get secret
NAME                  TYPE                                  DATA   AGE
default-token-j8tx4   kubernetes.io/service-account-token   3      80m

変更点

Docker/Kubernetesのバージョンについて

以下のバージョンで構成してみました。現時点で最新のはず。

[root@master-prod ~]# yum list installed | grep docker
docker.x86_64                         2:1.13.1-161.git64e9980.el7_8  @extras
docker-client.x86_64                  2:1.13.1-161.git64e9980.el7_8  @extras
docker-common.x86_64                  2:1.13.1-161.git64e9980.el7_8  @extras
[root@master-prod ~]# yum list installed | grep kube
cri-tools.x86_64                      1.13.0-0                       @kubernetes
kubeadm.x86_64                        1.18.3-0                       @kubernetes
kubectl.x86_64                        1.18.3-0                       @kubernetes
kubelet.x86_64                        1.18.3-0                       @kubernetes
kubernetes-cni.x86_64                 0.7.5-0                        @kubernetes

v1.12時代と違い、現時点ではバージョン指定せずにLatestで動きました(dockerも)。

MasterのCPUが1つでもkubeadm initできた

MasterのCPUが1つの場合、何も考えずにkubeadm initすると以下のメッセージが表示されます。

[ERROR NumCPU]: the number of available CPUs 1 is less than the required 2

これは「–ignore-preflight-errors=NumCPU」で回避できました。実際に使用したコマンドは以下の通り(Masterノードが192.168.1.50の場合)。

kubeadm init --apiserver-advertise-address=192.168.1.50 --pod-network-cidr=10.244.0.0/16 --ignore-preflight-errors=NumCPU

MasterノードのDiskは最低6GBくらいは必要ぽい

初期構築でも6GBくらいは必要なようです。2GBだとFlannelインストール時点でDiskが枯渇しました。

参考までに、全てを設定後のdfはこんな感じ。

Master:

[root@master-prod ~]# df -m .
ファイルシス            1M-ブロック  使用 使用可 使用% マウント位置
/dev/mapper/centos-root        4490  2660   1831   60% /

Worker Node:

[root@node1-prod ~]# df -m .
ファイルシス            1M-ブロック  使用 使用可 使用% マウント位置
/dev/mapper/centos-root        3570  1937   1634   55% /

LB Node

[root@nodelb-prod ~]# df -m .
ファイルシス            1M-ブロック  使用 使用可 使用% マウント位置
/dev/mapper/centos-root        3570  1971   1600   56% /

Flannelの導入は何も考えずにできた

上記のkubeadm initで「–pod-network-cidr」さえしっかり設定していれば、後は何も考えずに公式のkube-flannel.ymlの適用で動きました。

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

人生が少し楽になった

ちなみに、公式サイトの導入手順に従っただけです。

metallbも簡単だった

これも基本的に公式サイトの導入手順に従えば良い。

ただ、私の過去の記事と同じくcontrollerをlbnodeに固定したい場合は、前回の記事と同じくaffinity設定をすれば良い。その為にローカルにymlはwgetしなければいけない。

wget https://raw.githubusercontent.com/google/metallb/master/manifests/metallb.yaml

あとは、ひたすらkubectl apply -fする。

kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.9.3/manifests/namespace.yaml
kubectl apply -f metallb.yaml
kubectl create secret generic -n metallb-system memberlist --from-literal=secretkey="$(openssl rand -base64 128)"
kubectl apply -f metallb-config.yml

最後のmetallb-config.ymlも、公式サイトに書いてる通り。

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: |
    address-pools:
    - name: default
      protocol: layer2
      addresses:
      - 192.168.1.240-192.168.1.250

addressesをsvcとして使いたいIPレンジにするだけ。

なんや!普通に動くやん!

まとめ

軽くnginxを動かしてsvc付けて動作は確認しました。変なログも出ていないし、今のところ大丈夫っぽい。

過去の記事を書いてて良かったとつくづく感じた1日でした。

コメント

タイトルとURLをコピーしました