vs kubeadm@Kubernetes1.20
RyuSAAWS上にkubeadmでHA構成クラスターを組むぞ～(忘備録用)
※ etcdを分けるの忘れてたので今回は積層で
RyuSA目標：Kubernetes1.20をcontainerd&runcのランタイムで構築
NLBでAPIを立ててその下にEC2インスタンスでmasterを作成する
環境：
- OS: Ubuntu20.04
- CRI: containerd1.4.3
- runc: バージョンわからん(あとで調べる)
- k8s: 1.20
RyuSAまずはkubeadmをインストール
その途中でcontainerdのインストール
今回はdockershimがDepricatedになったので初のCRIを利用することにする. またcgroupの設定を入れておく。
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
...
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
SystemdCgroup = true
APIエンドポイントとcgroupの設定を入れた設定ファイルを作成
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
cgroupDriver: systemd
---
apiVersion: kubeadm.k8s.io/v1beta2
kind: ClusterConfiguration
controlPlaneEndpoint: "NLB_ENDPOINT:6443"
networking:
podSubnet: "192.168.0.0/16"
これでkubeadm initすれば動くはず？
kubeadm init --config ./config.yaml --upload-certs
...
[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s
[kubelet-check] Initial timeout of 40s passed.
Unfortunately, an error has occurred:
timed out waiting for the condition
This error is likely caused by:
- The kubelet is not running
- The kubelet is unhealthy due to a misconfiguration of the node in some way (required cgroups disabled)
If you are on a systemd-powered system, you can try to troubleshoot the error with the following commands:
- 'systemctl status kubelet'
- 'journalctl -xeu kubelet'
Additionally, a control plane component may have crashed or exited when started by the container runtime.
To troubleshoot, list all containers using your preferred container runtimes CLI.
Here is one example how you may list all Kubernetes containers running in cri-o/containerd using crictl:
- 'crictl --runtime-endpoint /run/containerd/containerd.sock ps -a | grep kube | grep -v pause'
Once you have found the failing container, you can inspect its logs with:
- 'crictl --runtime-endpoint /run/containerd/containerd.sock logs CONTAINERID'
error execution phase wait-control-plane: couldn't initialize a Kubernetes cluster
To see the stack trace of this error execute with --v=5 or higher
なんか怒られた、ログを確認する
Dec 15 13:08:19 node1 kubelet[36498]: E1215 13:08:19.300755 36498 reflector.go:138] k8s.io/kubernetes/pkg/kubelet/kubelet.go:438: Failed to watch *v1.Node: failed to list *v1.Node: Get "https://NLB_ENDPOINT>
Dec 15 13:08:19 node1 kubelet[36498]: E1215 13:08:19.382323 36498 kubelet.go:2240] node "node1" not found
Dec 15 13:08:19 node1 kubelet[36498]: E1215 13:08:19.482463 36498 kubelet.go:2240] node "node1" not found
どうもNLBからアクセスできないっぽい。
telnet NLB_ENDPOINT 6443
Trying 10.XX.XX.XXX...
^C
と思いきや別のノードからはtelnetで接続できた。なんだろう？
RyuSA正解はこれでした
NLBはターゲットを「インスタンス」に設定していると自分自身へのリクエストがイケないらしい。マジかお前
ということでターゲットをIPアドレスに変更して動作確認。
kubeadm reset
kubeadm init --config ./config.yaml --upload-certs
...
[addons] Applied essential addon: CoreDNS
[addons] Applied essential addon: kube-proxy
Your Kubernetes control-plane has initialized successfully!
起動確認完了。無駄に時間かかった……
そしてうっかり忘れてetcdを外出しし損ねたのでetcdの分割はまた後日
RyuSACNIは今回もCalicoを使用。そろそろ別のCNIも使ってみようかしら……
kubectl apply -f https://docs.projectcalico.org/v3.11/manifests/calico.yaml
と思ったらcalico-nodeが上手く上がらない。ログを確認
2020-12-15 14:03:48.304 [FATAL][659] int_dataplane.go 1035: Kernel's RPF check is set to 'loose'. This would allow endpoints to spoof their IP address. Calico requires net.ipv4.conf.all.rp_filter to be set to 0 or 1. If you require loose RPF and you are not concerned about spoofing, this check can be disabled by setting the IgnoreLooseRPF configuration parameter to 'true'.
net.ipv4.conf.all.rp_filterの値を0か1にせよとのこと。Calico側を無効にしてもいいのだけど、一旦試しにホストマシン側に設定を入れてみる。
sysctl -w net.ipv4.conf.all.rp_filter=2
calico-nodeが動いた！……が、なぜかNode側がそれを検知しない。。。
RyuSAなぜかNode側がそれを検知しない。。。
はい解決しました、swapをオフにしていなかったためkubeletがまともに動いておりませんでした。(草)
swapをオフにして再起動かけたらすんなり動いてくれた。。。orz
RyuSAということでこのスクラップはClose
次回(というかこれから)分離型etcdのクラスタを構築します