これまでの流れをぶった切って、いきなりKubernetesネタです。
Kubernetes1.12でFlannelがデプロイできないと悩んでる人は読んでください。
Kubernetes+Flannelで問題発生
最近のITインフラのトレンドを理解する上でKubernetesは避けられなくなってきました。なので、自宅ラボを使用して、時間があるときに色々試してます。
個人的にはKubernetesで最もややこしいのは「ネットワーク」だと思います。なので、近い内にKubernetesのネットワークについて色々紹介できればと考えています。
今回はKubernetesの基礎はいきなりすっ飛ばして、ネットワークソリューションの一つである「Flannelを使う」についてです。
Centos7+Kubernets+Flannelの組み合わせの手順については、色んなブログで紹介されているのですが・・・
なぜかFlannelのPodが起動しない。
Masterノードも、いつまでたっても「Not Ready」のままです。
[root@k-master ~]# kubectl get node NAME STATUS ROLES AGE VERSION 2180f21b NotReady <none> 2m32s v1.12.3 c34d0a6a NotReady <none> 2m32s v1.12.3 k-master NotReady master 3m16s v1.12.3
ちなみに、Weave-netのデプロイなら上手くいく。普通にServiceも作成できるし、Worker-Nodeの追加もできる。
原因はTolerationsでした
数時間ハマったのですが、以下のリンクを参考にしてようやく解決できました。
Kubernetes 1.12 and flannel does not work out of the box
要約するとこんな感じです。
- Kubernetesには「Taints&Tolerations」というvCenterの「Anti-Affinity Rule」みたいな仕組みがある。
- NodeにTaintsを付けることができ、同じTolerationsを持つPod(Deployment yamlで設定できる）しかデプロイできない仕組み（本当はもう少しだけややこしいが、本質的にはこんな感じ）
- Kubernetes 1.12では仕様が変わったっぽくて、NotReady状態のNodeは「node.kubernetes.io/not-ready:NoSchedule」Taintsが自動的に付与される。
- kube-flannel.ymlのtoraletionsには「node-role.kubernetes.io/master」しか設定されていない。つまり、「node.kubernetes.io/not-ready」が設定されていない。
- 従って、FlannelのPodがデプロイできない。
本当かよ！と疑って、実際に実機を見てみました。
init直後のTaintsの確認
v1.11とv1.12のVMを新規に準備して、kubeadm init直後のkubectl describe node MasterNodeのtaintsを見てみました。
[v1.11]CreationTimestamp: Fri, 30 Nov 2018 04:13:42 +0000 Taints: node-role.kubernetes.io/master:NoSchedule Unschedulable: false
[v1.12]
CreationTimestamp: Fri, 30 Nov 2018 04:42:29 +0000
Taints: node-role.kubernetes.io/master:NoSchedule
node.kubernetes.io/not-ready:NoSchedule
Unschedulable: false確かに、v1.12の方は、init直後に「node.kubernetes.io/not-ready:NoSchedule」が付与されていました。
この状態だと、「node.kubernetes.io/not-ready:NoSchedule」のTolerationが設定されているPodしか起動できません。
（厳密には「node-role.kubernetes.io/master:NoSchedule」も。これは通常のPodがマスターノードにデプロイされるのを防ぐため。）
Deployment YAMLのTolerationsの確認
一方、flannelのDLした直後のyamlを見てみます。
tolerations:
- key: node-role.kubernetes.io/master
operator: Exists
effect: NoSchedule確かにこれだけです。
ここを、以下に変更します。
tolerations:
- key: node-role.kubernetes.io/master
operator: Exists
effect: NoSchedule
- key: node.kubernetes.io/not-ready
operator: Exists
effect: NoScheduleこれでデプロイしてみたところ、普通にNodeがReadyになりました。
[root@k-master ~]# kubectl apply -f /root/kube-flannel.yml clusterrole.rbac.authorization.k8s.io/flannel created clusterrolebinding.rbac.authorization.k8s.io/flannel created serviceaccount/flannel created configmap/kube-flannel-cfg created daemonset.extensions/kube-flannel-ds created [root@k-master ~]# kubectl get node NAME STATUS ROLES AGE VERSION 2180f21b Ready <none> 15m v1.12.3 c34d0a6a Ready <none> 15m v1.12.3 k-master Ready master 15m v1.12.3
なぜ、Weave-netは問題ないのか？
Weave-netのDeployment YAMLを見てみます。
tolerations:
- effect: NoSchedule
operator: Existsこんな感じでKeyを指定していないから、とりあえずTaintsのKey名を気にしないで動作してるんですね。
つまり、FlannelもKey指定なしでTolerationsを書いてくれてたらなんの問題もないということです。（上記リンクのおじさんも、ポストにコメントしている人たちの意見もおおよそ同意見です）
少し解せないのが、この仕様の追加はv1.6からスタートしたとの記載もあります。
Kubernetes Taints and Tolerations
In addition, Kubernetes 1.6 introduced alpha support for representing node problems. In other words, the node controller automatically taints a node when certain condition is true. The following taints are built in:
node.kubernetes.io/not-ready: Node is not ready. This corresponds to the NodeCondition Ready being “False”.
うーん、謎です。
コメント