6月 2019年

今回は「ベアメタル Kubernetes 環境に ingress-nginx (L7ロードバランサ) を構築する方法」についてまとめます。

概要

ベアメタル Kubernetes 環境に NGINX ingress Controller を導入して「Ingress」を利用できるようにします。

本記事では「NGINX ingress Controller の導入から動作確認まで」を行っていきます。

前提

Ingress は その後ろで Service の ロードバランサ を利用しているので、前提として Service の ロードバランサ (MetalLB など) が利用できる状態になっていること。

• Kubernetes v1.14
• MetalLB 0.7.3
• NGINX ingress Controller v0.24.1

インストール

1. mandatory.yaml をダウンロード

   wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.24.1/deploy/mandatory.yaml
   

2. mandatory.yaml を編集

   ingress-nginx の controller は master Node に配置したいので、affinity と tolerations を追加します。

   
   …（省略）…
   
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: nginx-ingress-controller
     namespace: ingress-nginx
     labels:
       app.kubernetes.io/name: ingress-nginx
       app.kubernetes.io/part-of: ingress-nginx
   spec:
     replicas: 1
     selector:
       matchLabels:
         app.kubernetes.io/name: ingress-nginx
         app.kubernetes.io/part-of: ingress-nginx
     template:
       metadata:
         labels:
           app.kubernetes.io/name: ingress-nginx
           app.kubernetes.io/part-of: ingress-nginx
         annotations:
           prometheus.io/port: "10254"
           prometheus.io/scrape: "true"
       spec:
         serviceAccountName: nginx-ingress-serviceaccount
         containers:
           - name: nginx-ingress-controller
             image: quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.24.1
             args:
               - /nginx-ingress-controller
               - --configmap=$(POD_NAMESPACE)/nginx-configuration
               - --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services
               - --udp-services-configmap=$(POD_NAMESPACE)/udp-services
               - --publish-service=$(POD_NAMESPACE)/ingress-nginx
               - --annotations-prefix=nginx.ingress.kubernetes.io
             securityContext:
               allowPrivilegeEscalation: true
               capabilities:
                 drop:
                   - ALL
                 add:
                   - NET_BIND_SERVICE
               # www-data -> 33
               runAsUser: 33
             env:
               - name: POD_NAME
                 valueFrom:
                   fieldRef:
                     fieldPath: metadata.name
               - name: POD_NAMESPACE
                 valueFrom:
                   fieldRef:
                     fieldPath: metadata.namespace
             ports:
               - name: http
                 containerPort: 80
               - name: https
                 containerPort: 443
             livenessProbe:
               failureThreshold: 3
               httpGet:
                 path: /healthz
                 port: 10254
                 scheme: HTTP
               initialDelaySeconds: 10
               periodSeconds: 10
               successThreshold: 1
               timeoutSeconds: 10
             readinessProbe:
               failureThreshold: 3
               httpGet:
                 path: /healthz
                 port: 10254
                 scheme: HTTP
               periodSeconds: 10
               successThreshold: 1
               timeoutSeconds: 10
   # - ADD - START - ------------
         affinity:
           nodeAffinity:
             requiredDuringSchedulingIgnoredDuringExecution:
               nodeSelectorTerms:
               - matchExpressions:
                 - key: node-role.kubernetes.io/master
                   operator: Exists
         tolerations:
         - key: node-role.kubernetes.io/master
           operator: Exists
           effect: NoSchedule
   # - ADD -  END  - ------------
   

3. mandatory.yaml を適用

   kubectl apply -f mandatory.yaml
   

4. service-nodeport.yaml を適用

   kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/baremetal/service-nodeport.yaml
   

必要なPodが立ち上がっているかどうか、以下のコマンドで確認します。

kubectl get pods --all-namespaces -l app.kubernetes.io/name=ingress-nginx --watch

上記コマンドは状態を監視し続けるので、終了する際は Ctrl + C で抜けます。

設定

1. ConfigMap用のマニュフェスト（configmap.yaml）を作成

   kind: ConfigMap
   apiVersion: v1
   metadata:
     name: nginx-config
     namespace: nginx-ingress
   data:
     proxy-connect-timeout: "10s"
     proxy-read-timeout: "10s"
     client-max-body-size: "2m"
   

   適用できる ConfigMap の namespace および name は 前述のインストールで引数 --configmap に渡している値を指定します。

   nginx-ingress の 設定はすべて文字列になるので必ず "(ダブルクォート) でくくります。

   その他設定は以下を参照してください。

   NGINX Ingress Controller - ConfigMaps

2. 作成した ConfigMap を適用します。

   kubeadm apply -f configmap.yaml
   

動作確認

1. 以下のようなサンプルマニュフェスト（sample.yaml）を作成

   Deployment にある イメージ や ポートは適宜書き換えてください。

   apiVersion: networking.k8s.io/v1beta1
   kind: Ingress
   metadata:
     name: sample-ingress
     annotations:
       nginx.ingress.kubernetes.io/rewrite-target: /
   spec:
     backend:
       serviceName: sample-service
       servicePort: 8080
   
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: sample-service
   spec:
     selector:
       app: echo
     ports:
     - name: http
       protocol: TCP
       port: 8080
       targetPort: 3000
   
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: sample-deployment
     labels:
       app: echo
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: echo
     template:
       metadata:
         labels:
           app: echo
       spec:
         containers:
         - name: echo
           image: garafu/test.echo:latest
           ports:
           - containerPort: 3000
   
   ---
   

2. マニュフェストを適用して展開

   kubectl apply -f sample.yaml
   

3. Ingress に External IP がふられるのを待つ

   kubectl get ing --watch
   

   IPが振られるまで数分かかります。 上記コマンドでは状態変化を追っているのでIPが振られると自動で更新されれます。 抜ける際は Ctrl + C で抜けます。

   実行した際のイメージは以下のようになります。

   [root@k8s-master k8s-ingress]# kubectl get ing --watch
   NAME             HOSTS   ADDRESS   PORTS   AGE
   sample-ingress   *                 80      8s
   sample-ingress   *       10.51.2.10   80      16s
   

4. 接続確認

   curl http://10.51.2.10
   

今回は「ベアメタル Kubernetes 環境に ingress-nginx (L7ロードバランサ) を構築する方法」についてまとめました。 参考になったでしょうか？ 本記事がお役に立っていると嬉しいです！！

参考記事

• NGINX Ingress Controller - Installation Guide
• GitHub nginxinc/kubernetes-ingress - ConfigMap and Annotations
• GitHub kubernetes/ingress-nginx - ConfigMaps

今回は「kubeadm を利用して構築した Kubernetes 環境に MetalLB (L4 ロードバランサー)の インストール方法」についてまとめます。

概要

L4ロードバランサーの1つである「MetalLB」を ベアメタル Kubernetes クラスタにインストールします。 「MetalLB」を導入することで「Service」の「LoadBalancer」が利用できるようになります。

この記事では「MetalLBの導入から動作確認まで」をまとめます。

前提

ベアメタル Kubernetes クラスタが構築されている前提での作業を想定しています。本記事の内容は以下の環境で動作確認しています。

• Kubernetes v1.14
• MetalLB v0.7.3

インストール

GitHub から metallb.yaml をダウンロードして環境にあわせて修正。 今回は Controller を master Node に配置し、 Speaker を 各 worker Node に配置します。 そのため、 Controller の Deployment だけ修正します。

1. metallb.yaml をダウンロード

   curl -O https://raw.githubusercontent.com/google/metallb/v0.7.3/manifests/metallb.yaml
   

2. Controller が master Node に配置されるよう修正

   今回は Controller の Deployment に対して nodeAffinity と toleratioins を設定しました。

   
   … (省略) …
   
   ---
   apiVersion: apps/v1beta2
   kind: Deployment
   metadata:
     namespace: metallb-system
     name: controller
     labels:
       app: metallb
       component: controller
   spec:
     revisionHistoryLimit: 3
     selector:
       matchLabels:
         app: metallb
         component: controller
     template:
       metadata:
         labels:
           app: metallb
           component: controller
         annotations:
           prometheus.io/scrape: "true"
           prometheus.io/port: "7472"
       spec:
         serviceAccountName: controller
         terminationGracePeriodSeconds: 0
         securityContext:
           runAsNonRoot: true
           runAsUser: 65534 # nobody
         containers:
         - name: controller
           image: metallb/controller:v0.7.3
           imagePullPolicy: IfNotPresent
           args:
           - --port=7472
           - --config=config
           ports:
           - name: monitoring
             containerPort: 7472
           resources:
             limits:
               cpu: 100m
               memory: 100Mi
             
           securityContext:
             allowPrivilegeEscalation: false
             capabilities:
               drop:
               - all
             readOnlyRootFilesystem: true
   # Add -START-
         affinity:
           nodeAffinity:
             requiredDuringSchedulingIgnoredDuringExecution:
               nodeSelectorTerms:
               - matchExpressions:
                 - key: node-role.kubernetes.io/master
                   operator: Exists
         tolerations:
         - key: node-role.kubernetes.io/master
           operator: Exists
           effect: NoSchedule
   # Add -END-
   ---
   

3. Kubernetes 上に展開

   kubectl apply -f metallb.yaml
   

設定

1. L2ロードバランサ用の設定を作成

   以下のような layer2-config.yaml ファイルを作成します。 IPアドレスのレンジは環境に合わせて修正します。 ここで指定された範囲で Service の EXTERNAL-IP が設定されます。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     namespace: metallb-system
     name: config
   data:
     config: |
       address-pools:
       - name: my-ip-space
         protocol: layer2
         addresses:
         - 10.51.2.10-10.51.2.20
   

2. Kubernetes 上に適用

   kubectl apply -f layer2-config.yaml
   

1. Firewallの穴あけ

   sudo firewall-cmd --zone public --add-port 7472/tcp --permanent
   firewall-cmd --add-service=http --zone=public --permanent
   firewall-cmd --add-service=https --zone=public --permanent
   sudo firewall-cmd --reload
   

Firewallに関してはうまく動かなければ切ってしまったほうが早いかも… Firewallを停止したい場合は systemctl stop firewalld で停止させます。

動作確認

1. Load Balancer を含むサービスを展開

   kubectl apply -f https://raw.githubusercontent.com/google/metallb/v0.7.3/manifests/tutorial-2.yaml
   

2. Pod 、 Service が起動していることを確認

   kubectl get pods,services
   

   NAME                         READY   STATUS    RESTARTS   AGE
   pod/nginx-58df4bbfdd-vk6x9   1/1     Running   0          7m42s
   
   NAME                 TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
   service/kubernetes   ClusterIP      10.96.0.1        <none>        443/TCP        13d
   service/nginx        LoadBalancer   10.104.173.121   10.51.2.10    80:30291/TCP   7m42s
   

   Pod、Service が起動していればOK。起動しているサービスの EXTERNAL-IP でアクセスできる。

3. ブラウザから http://10.51.2.10 (Service の EXTERNAL-IP)へアクセス

   

• 必要に応じてテストに使った Deployment と Service を削除

  kubectl delete -f https://raw.githubusercontent.com/google/metallb/v0.7.3/manifests/tutorial-2.yaml
  

今回は「MetalLBの導入から動作確認まで」についてまとめました。 参考になったでしょうか？ 本記事がお役に立っていると嬉しいです！！

参考記事

• MetalLB - LAYER 2 MODE TUTORIAL
• Qiita - Kubesprayで準備したk8sにMetalLBをデプロイしてみる

今回は「Podを配置するNodeの選択/制限方法」のうち「Taints & Tolerations」についてまとめます。 「NodeSelector」「Node Affinity」「Pod Affinity / Anti-Affinity」について以前まとめていますので過去記事を参照してください。

Selector または Affinity 、 Taints & Tolerations など似たようなものがいくつかあり、分かりづらいのでまとめてみました。

概要

「Podを意図したNodeに配置したい」とは逆で、「Nodeに配置したくないPodの条件」を指定します。 Node に対して決められた Pod 以外は配置できないようにするための仕組みです。

あらかじめ Node に対しては Taint （汚れ）を指定しておきます。 Pod を Node に配置する際、Toleration（許容(= 許せる汚れ)） がなければ Taints(汚れ) のある Node へ Toloration（許容(= 許せる汚れ)）のない Pod は配置できません。 逆に Taint（汚れ） のある Node でも Toloration（許容(= 許せる汚れ)）がある Pod であれば 配置できます。

Node Taints

Taintsの確認

Node Label の確認と同じで kubectl describe node NAME で確認できます。

[root@k8s-master ~]# kubectl describe node k8s-node02
Name:               k8s-node02
Roles:              worker
Labels:             beta.kubernetes.io/arch=amd64
                    beta.kubernetes.io/os=linux
                    kubernetes.io/arch=amd64
                    kubernetes.io/hostname=k8s-node02
                    kubernetes.io/os=linux
                    node-role.kubernetes.io/worker=
Annotations:        flannel.alpha.coreos.com/backend-data: {"VtepMAC":"aa:ff:b4:fa:6c:05"}
                    flannel.alpha.coreos.com/backend-type: vxlan
                    flannel.alpha.coreos.com/kube-subnet-manager: true
                    flannel.alpha.coreos.com/public-ip: 10.51.1.102
                    kubeadm.alpha.kubernetes.io/cri-socket: /var/run/dockershim.sock
                    node.alpha.kubernetes.io/ttl: 0
                    volumes.kubernetes.io/controller-managed-attach-detach: true
CreationTimestamp:  Sun, 02 Jun 2019 17:48:59 +0900
Taints:             key1=value1:NoSchedule
Unschedulable:      false
Conditions:
  Type             Status  LastHeartbeatTime                 LastTransitionTime                Reason                       Message
  ----             ------  -----------------                 ------------------                ------                       -------
  MemoryPressure   False   Sat, 15 Jun 2019 16:03:38 +0900   Sun, 02 Jun 2019 17:48:59 +0900   KubeletHasSufficientMemory   kubelet has sufficient memory available
  DiskPressure     False   Sat, 15 Jun 2019 16:03:38 +0900   Sun, 02 Jun 2019 17:48:59 +0900   KubeletHasNoDiskPressure     kubelet has no disk pressure
  PIDPressure      False   Sat, 15 Jun 2019 16:03:38 +0900   Sun, 02 Jun 2019 17:48:59 +0900   KubeletHasSufficientPID      kubelet has sufficient PID available
  Ready            True    Sat, 15 Jun 2019 16:03:38 +0900   Sun, 02 Jun 2019 17:49:29 +0900   KubeletReady                 kubelet is posting ready status

… (以下省略) …

Taintsの付与/削除

Node に対して Taint を付与/削除するには kubectl taint nodes NAME KEY=VALUE:EFFECT を利用します。

[root@k8s-master ~]# kubectl taint nodes k8s-node02 key1=value1:NoSchedule
node/k8s-node02 tainted

EFFECTに指定できるのは以下のいずれかになります。 指定によってNode中で動作しているPodに対する影響が変わります。

• NoSchedule 今後は配置しないで。実行中のPodは無視するよ。
• PreferNoSchedule 今後できれば配置しないで。実行中のPodは無視するよ。
• NoExecute 実行中のPodは出ていけ！

付与されている Taint を削除する場合 kubectl taint nodes NAME KEY:EFFECT- で削除できます。

[root@k8s-master ~]# kubectl taint nodes k8s-node02 key1:NoSchedule-
node/k8s-node02 untainted

組み込み Taints

自動付与される組み込み Taint は以下の通りです。

• node.kubernetes.io/not-ready
• node.kubernetes.io/unreachable
• node.kubernetes.io/out-of-disk
• node.kubernetes.io/memory-pressure
• node.kubernetes.io/disk-pressure
• node.kubernetes.io/network-unavailable
• node.kubernetes.io/unschedulable
• node.cloudprovider.kubernetes.io/uninitialized

Pod Tolerations

Pod に対して Tolerations を指定すると Taints が指定された Node に対して配置が可能になります。

apiVersion: v1
kind: Pod
metadata:
  name: sample
spec:
  containers:
  - name: sample
    image: k8s.gcr.io/pause:2.0
  tolerations:
  - key: "key"
    operator: "Equal"
    value: "value"
    effect: "NoSchedule"
    tolerationSeconds: 3600

tolorations に指定できるのは key 、 operator 、 value 、 effect 、 tolerationSeconds です。

key 、 value 、 effect が operator で指定された条件で一致している Node であれば配置されますが、それ以外は配置されません。 operator に指定できる演算子は以下の通りです。

• Exists (デフォルト)
• Equal

tolerationSeconds は effect が NoExecute のときに立ち退くまでの時間(秒)を指定します。

今回は「Taints & Tolerations」についてまとめました。 参考になったでしょうか？ 本記事がお役に立っていると嬉しいです！！

参考記事

• kubernetes - Assigning Pods to Nodes
• kubernetes - Taints and Tolerations

今回は「Podを配置するNodeの選択/制限方法」のうち「NodeSelector」「Node Affinity」「Pod Affinity / Anti-Affinity」についてまとめます。 「Taints & Tolerations」は次回まとめます。

Selector または Affinity 、 Taints & Tolerations など似たようなものがいくつかあり、分かりづらいのでまとめてみました。

概要

NodeにはあらかじめLabelが指定されています。 Podに対して「NodeのどのLabelと一致させるか」を指定し、Labelが一致するNodeに対してPodを配置していくものです。

Podを意図したNodeに配置したい場合、以下のような定義を利用して指定します。

• nodeSelector
• nodeAffinity
• podAffinity または podAntiAffinity

上記の定義はいずれも Node Label との一致状況を確認するので、まずは Node Label から確認していきましょう。

Node Label

Podの配置にはNodeのラベルが使われます。 なので、何はともあれNodeのラベルとしてどんなものが定義されているのか、どう定義するのかなどを確認しておきます。

Labelの確認

現在 Node に付与されている ラベル を確認するには kubectl describe node NAME で確認できます。

[root@k8s-master ~]# kubectl describe node k8s-node01
Name:               k8s-node01
Roles:              worker
Labels:             beta.kubernetes.io/arch=amd64
                    beta.kubernetes.io/os=linux
                    kubernetes.io/arch=amd64
                    kubernetes.io/hostname=k8s-node01
                    kubernetes.io/os=linux
                    node-role.kubernetes.io/worker=
Annotations:        flannel.alpha.coreos.com/backend-data: {"VtepMAC":"9e:14:d6:92:02:02"}
                    flannel.alpha.coreos.com/backend-type: vxlan
                    flannel.alpha.coreos.com/kube-subnet-manager: true
                    flannel.alpha.coreos.com/public-ip: 10.51.1.101
                    kubeadm.alpha.kubernetes.io/cri-socket: /var/run/dockershim.sock
                    node.alpha.kubernetes.io/ttl: 0
                    volumes.kubernetes.io/controller-managed-attach-detach: true
CreationTimestamp:  Sun, 02 Jun 2019 17:49:09 +0900
Taints:             
Unschedulable:      false
Conditions:
  Type             Status  LastHeartbeatTime                 LastTransitionTime                Reason                       Message
  ----             ------  -----------------                 ------------------                ------                       -------
  MemoryPressure   False   Mon, 10 Jun 2019 23:39:18 +0900   Sun, 02 Jun 2019 17:49:09 +0900   KubeletHasSufficientMemory   kubelet has sufficient memory available
  DiskPressure     False   Mon, 10 Jun 2019 23:39:18 +0900   Sun, 02 Jun 2019 17:49:09 +0900   KubeletHasNoDiskPressure     kubelet has no disk pressure
  PIDPressure      False   Mon, 10 Jun 2019 23:39:18 +0900   Sun, 02 Jun 2019 17:49:09 +0900   KubeletHasSufficientPID      kubelet has sufficient PID available
  Ready            True    Mon, 10 Jun 2019 23:39:18 +0900   Sun, 02 Jun 2019 17:49:19 +0900   KubeletReady                 kubelet is posting ready status

… (以下省略) …

Labelの付与/削除

新たなラベルを Node に付与したい場合は kubectl label nodes NAME KEY=VALUE で付与します。

以下のコマンドでは「k8s-node01」に対して「disktype = ssd」を指定しています。

[root@k8s-master ~]# kubectl label nodes k8s-node01 disktype=ssd
node/k8s-node01 labeled

付与したラベルを削除したい場合は kubectl label nodes NAME KEY- を指定します。

以下のコマンドでは「k8s-node01」に定義された「disktype」を削除しています。

[root@k8s-master ~]# kubectl label nodes k8s-node01 disktype-
node/k8s-node01 labeled

デフォルトLabel

Node作成時にデフォルトで付与されるラベルは以下の通りです。

• kubernetes.io/hostname
• failure-domain.beta.kubernetes.io/zone
• failure-domain.beta.kubernetes.io/region
• beta.kubernetes.io/instance-type
• kubernetes.io/os
• kubernetes.io/arch

kubernetes.io/hostname は基本的に Node 名 と一致します。

Node Selector

nodeSelector はその名の通り「Podを配置したいNodeラベル」をキーバリュー形式で指定します。

例えば disktype: ssd というラベルのある Node へ配置したい場合、以下のような指定をします。

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  nodeSelector:
    disktype: ssd

この nodeSelector はいずれなくなるようです。 理由は、この後に説明する nodeAffinity で代替できるからとのことです。

Node Affinity

nodeAffinity は nodeSelector よりも柔軟な Node 指定ができます。 Anti Affinity や、この後に紹介する Taints & Tolerations と維持する動作も表現可能です。

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/e2e-az-name
            operator: In
            values:
            - e2e-az1
            - e2e-az2
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: another-node-label-key
            operator: In
            values:
            - another-node-label-value

Node選択する際、「配置する時（DuringScheduling）の必須度合（required または preferred）」と「既に配置されて実行されているPod（DuringExecution）の対応（Ignore または Required）」の組み合わせで4パターンの動作が考えられます。 どのような動作をさせたいかで選択します。

• requiredDuringSchedulingIgnoredDuringExecution

  Pod配置時は必須条件とするが、すでに配置されているPodに対しては無視する。

• preferredDuringSchedulingIgnoredDuringExecution

  Pod配置時にできるだけ配慮して配置する。すでに配置されているPodに対しては無視する。

• requiredDuringSchedulingRequiredDuringExecution

  Pod配置時に必須条件とし、すでに配置されているPodがある場合は退去させる。 Kubernetes v1.14 時点では利用不可。 今後実装予定の機能。

• preferredDuringSchedulingRequiredDuringExecution

  組み合わせ上は存在するが機能としては存在しない。

matchExpressions は key 、 operator 、 values で構成されます。 key には条件にしたいNodeのラベル名、values には値を指定します。 operator に使える演算子は以下の通りです。

• In
• NotIn
• Exists
• DoesNotExist
• Gt
• Lt

preferredDuringScheduling には上記の条件に加えて weight が 1 ～ 100 の範囲で指定できます。 この weight は Node 選択時の演算で利用します。 各 Node においてラベルマッチした個数分 weight を加算し、最終的に点数の高い Node に Pod を配置します。

Pod Affinity / Anti-Affinity

podAffinity および podAffinity はすでに動いているPodをもとにどこへPodを配置するかを定義するものになります。

podAffinity は「指定されたラベルに一致する Pod が動作している Node がもつ topologyKey が同一の Node に Pod を配置させる」動作になります。 podAffinity は「topologyKey の範囲内に 指定されたラベルに一致するPodが動作していなければ、Pod を topologyKey 範囲内のNodeのいずれかに Pod を配置する」動作になります。

apiVersion: v1
kind: Pod
metadata:
  name: with-pod-affinity
spec:
  containers:
  - name: with-pod-affinity
    image: k8s.gcr.io/pause:2.0
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: security
            operator: In
            values:
            - S1
        topologyKey: failure-domain.beta.kubernetes.io/zone
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: security
              operator: In
              values:
              - S2
          topologyKey: failure-domain.beta.kubernetes.io/zone

podAffinityやpodAntiAffinityはその性質（Nodeに配置されたPodのラベルマッチを行う）ので処理が重くなります。 そのため、数百Nodeもあるようなサービスでは使わないほうが良いようです。

labelSelector は key 、 operator 、 values で構成されます。 key には条件にしたいPodのラベル名、values には値を指定します。 operator に使える演算子は以下の通りです。

• In
• NotIn
• Exists
• DoseNotExist

topologyKey は基本的に Node に設定されたラベルになります。 なので、意図的にすべての Node に対して付与しているラベルがないのであれば標準的に付与される以下のようなラベルを利用します。

• kubernetes.io/hostname
• failure-domain.beta.kubernetes.io/zone
• failure-domain.beta.kubernetes.io/region
• beta.kubernetes.io/instance-type
• kubernetes.io/os
• kubernetes.io/arch

今回は「NodeSelector」「Node Affinity」「Pod Affinity / Anti-Affinity」についてまとめました。 参考になったでしょうか？ 本記事がお役に立っていると嬉しいです！！

参考記事

• kubernetes - Assigning Pods to Nodes
• kubernetes - Taints and Tolerations

今回は「CentOS上にシングルマスター構成のKubernetesクラスターを構築する方法」についてまとめます。

いくつかブログやホームページを確認しながらやってみたのですが、うまくいかないものですね… 今回の記事では「目指せ冪等！」としてバージョン指定で構築方法をまとめました。

概要

マスターノード1台、ワーカーノード2台の3台構成で構築してみます。 同一筐体の上に仮想マシン3台を作成して、その3台でクラスタ環境を構築していきます。

利用するモジュール類は以下のようなものです。

• docker （コンテナエンジン）
• flannel （ネットワーク）
• kubeadm （Kubernetes 構築ツール）

Dockerはきちんとバージョン指定するのに、手作業の環境構築でバージョン指定しない違和感が激しかったので、今回はきちんとバージョン指定で環境構築していきます。 利用しているパッケージやイメージのバージョンは以下の通りです。

OS
CentOS Linux release 7.3.1611 (Core)

パッケージ	アーキテクチャー	バージョン
systemd	x86_64	219-62.el7_6.6
docker-ce	x86_64	18.09.6
docker-ce-cli	x86_64	18.09.6
containerd.io	x86_64	1.2.5
kubeadm	x86_64	1.14.2
kubectl	x86_64	1.14.2
kubelet	x86_64	1.14.2

イメージ	バージョン
flannel	0.11.0

OSが少し古いものを使いまわしていたので systemd の更新をしないと cgroup-driver を systemd に変更して動作させることができませんでした。 上の表はあらかじめアップデート済みの状態で記述しています。 もし、バージョンが異なるようであれば事前にアップデートが必要になります。

仮想マシン準備

必要となる仮想マシン3台分（マスター1台、ワーカー2台）を準備します。 基本的に root ユーザーで実施していきます（ sudo が手間なので…）。

仮想マシン作成

仮想マシンを作成する際、以下のような内容で作成しました。 基本的にはデフォルトのままで、CPUだけ修正しています。 Kubernetes は CPU コア 2コア 以上 で作成しないと動作しないので、作成時に間違えないよう注意してください。

CPU	2コア
メモリ	2048MB
ハードディスク	16GB
SCSI コントローラ	VMware Paravirtual
ネットワーク アダプタ	VM Network
CD/DVD ドライブ	データストア ISO ファイル (CentOS 7 のインストーラー イメージ)

systemdの更新

この手順は OS のバージョンによっては不要です。 バージョン確認して新しければいったんスキップしてもよいでしょう。 もし、「kubelet が systemd で起動できない」といった症状が出た場合はこの手順に戻って更新が必要になります。

バージョン確認

yum list | grep systemd

systemdの入れ直し

yum remove systemd
yum install systemd-219-62.el7_6.6.x86_64

マスターノード、ワーカーノード共通の構築

ホスト名、IPアドレス

あとで出てくるコマンド kubeadm init においてIPは決められている前提になるので、最初に固定しておきます。

1. ホスト名の設定

   hostnamectl set-hostname <hostname>
   

2. ネットワークの設定

   vi /etc/sysconfig/network-scripts/ifcfg-ens192
   

   TYPE="Ethernet"
   BOOTPROTO=none
   DEFROUTE="yes"
   IPV4_FAILURE_FATAL="no"
   IPV6INIT="yes"
   IPV6_AUTOCONF="yes"
   IPV6_DEFROUTE="yes"
   IPV6_FAILURE_FATAL="no"
   IPV6_ADDR_GEN_MODE="stable-privacy"
   NAME="ens192"
   DEVICE="ens192"
   ONBOOT="yes"
   IPADDR=10.51.1.100
   PREFIX=16
   GATEWAY=10.51.0.254
   DNS1=8.8.8.8
   DNS2=8.8.4.4
   IPV6_PEERDNS=yes
   IPV6_PEERROUTES=yes
   

   systemctl restart network
   

swap 無効化

swap が有効だと kubelet が起動しないので、 swap をあらかじめ無効化しておきます。

1. swapを一時的に無効化

   swapoff -a
   

2. swapを恒久的に無効化

   リブート時に再有効化されないためには /etc/fstab の内容を一部コメントアウトします。 コメントアウトするのは swap の記載がある行（L.10）です。

   vi /etc/fstab
   

   #
   # /etc/fstab
   # Created by anaconda on Thu May 23 20:34:05 2019
   #
   # Accessible filesystems, by reference, are maintained under '/dev/disk'
   # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
   #
   /dev/mapper/cl-root     /                       xfs     defaults        0 0
   UUID=868f654f-e5e7-4369-9b43-99c462ac384d /boot                   xfs     defaults        0 0
   # /dev/mapper/cl-swap     swap                    swap    defaults        0 0
   

Docker インストール

今回はコンテナエンジンとして「Docker」を利用します。 Dockerは cgroup-driver にデフォルトだと cgroupfs を利用しているので、 Kubernetes 推奨の systemd で起動するように変更して設定していきます。

1. 実行に必要なパッケージをインストール

   yum install -y yum-utils device-mapper-persistent-data lvm2
   

2. 安定板リポジトリを設定

   yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
   

3. DockerCEをインストール

   sudo yum install \
    docker-ce-18.09.6 \
    docker-ce-cli-18.09.6 \
    containerd.io-1.2.5
   

4. daemonの設定

   systemd 経由で起動されるよう /etc/docker/daemon.json ファイルを以下の内容で作成します。

   vi /etc/docker/daemon.json
   

   {
     "exec-opts": ["native.cgroupdriver=systemd"],
     "log-driver": "json-file",
     "log-opts": {
       "max-size": "100m"
     },
     "storage-driver": "overlay2"
   }
   

   以下のコマンドを実行してサービス用のフォルダを作成します。

   mkdir -p /etc/systemd/system/docker.service.d
   

5. daemonの再読み込み

   systemctl daemon-reload
   

6. Dockerの自動起動を有効化

   systemctl enable docker
   

7. Dockerを起動

   systemctl start docker
   

Dockerが正常にインストールできたかどうかは、docker run hello-world コマンドを実行して確認できます。 以下には実行結果のサンプルも含めて掲載します。

[root@k8s-master ~]# docker run hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
1b930d010525: Pull complete
Digest: sha256:0e11c388b664df8a27a901dce21eb89f11d8292f7fca1b3e3c4321bf7897bffe
Status: Downloaded newer image for hello-world:latest

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
    (amd64)
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
 https://hub.docker.com/

For more examples and ideas, visit:
 https://docs.docker.com/get-started/

Kubernetes インストール

Kubernetes といってもインストールする実態は kubeadm 、 kubelet 、 kubectl の3つです。

1. ネットワーク設定(iptables)

   以下のような内容の /etc/sysctl.d/k8s.conf ファイルを作成します。

   vi /etc/sysctl.d/k8s.conf
   

   net.bridge.bridge-nf-call-ip6tables = 1
   net.bridge.bridge-nf-call-iptables = 1
   

   以下のコマンドで設定ファイルの読み込みを行います。

   sysctl --system
   

2. ネットワーク設定(hosts)

   ホスト名でアクセスできるよう、/etc/hosts に以下のネットワーク情報を追記します。

   vi /etc/hosts
   

   10.51.1.100 k8s-master
   10.51.1.101 k8s-node01
   10.51.1.102 k8s-node02
   

3. リポジトリの設定

   以下のような内容の /etc/yum.repos.d/kubernetes.repo ファイルを作成

   [kubernetes]
   name=Kubernetes
   baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
   enabled=1
   gpgcheck=1
   repo_gpgcheck=1
   gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
   exclude=kube*
   

4. SELinux の 無効化

   setenforce 0
   sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config
   

5. Kubernetes の インストール

   yum install -y \
    kubelet-1.14.2-0.x86_64 \
    kubeadm-1.14.2-0.x86_64 \
    kubectl-1.14.2-0.x86_64 \
    --disableexcludes=kubernetes
   

6. daemonの設定変更

   Cgroup Driver に systemd を指定します。 /var/lib/kubelet/kubeadm-flags.env ファイルの内容に以下を追記します。

   vi /var/lib/kubelet/kubeadm-flags.env
   

   KUBELET_EXTRA_ARGS=--cgroup-driver=systemd
   

7. daemonの再読み込み

   systemctl daemon-reload
   

8. kubelet の 有効化

   systemctl enable kubelet
   

9. kubelet の 起動

   systemctl start kubelet
   

このタイミングまでの動作確認をしたい場合、 systemctl status kubelet で kubelet が起動しているかどうかを確認すると良いです。 以下に実行サンプルを掲載します。

[root@k8s-master ~]# systemctl status kubelet
● kubelet.service - kubelet: The Kubernetes Node Agent
   Loaded: loaded (/usr/lib/systemd/system/kubelet.service; enabled; vendor preset: disabled)
  Drop-In: /usr/lib/systemd/system/kubelet.service.d
           mq10-kubeadm.conf
   Active: active (running) since 日 2019-06-02 18:26:32 JST; 6h ago
     Docs: https://kubernetes.io/docs/
 Main PID: 18332 (kubelet)
    Tasks: 16
   Memory: 96.8M
   CGroup: /system.slice/kubelet.service
           mq18332 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kube...

マスタノード構築

以下の手順はマスターノードだけで行う作業です。 マスターノードにアクセスして実行していきます。

ファイアウォール設定

1. ポートの開放

   ポートレンジ	プロトコル	用途
   6443	TCP	Kubernetes API Server
   2379-2380	TCP	etcd
   10250	TCP	kubelet
   10251	TCP	kube-scheduler
   10252	TCP	kube-controller-manager

   sudo firewall-cmd --zone public --add-port 6443/tcp --permanent
   sudo firewall-cmd --zone public --add-port 2379-2380/tcp --permanent
   sudo firewall-cmd --zone public --add-port 10250/tcp --permanent
   sudo firewall-cmd --zone public --add-port 10251/tcp --permanent
   sudo firewall-cmd --zone public --add-port 10252/tcp --permanent
   sudo firewall-cmd --reload
   

マスターノードの初期化

1. 初期化

   sudo kubeadm init \
     --apiserver-advertise-address 10.51.1.100 \
     --kubernetes-version 1.14.2 \
     --pod-network-cidr 10.244.0.0/16
   

   フラグ	必須	説明
   --apiserver-advertise-address string		APIサーバーとして受け付けるIPアドレス。指定しなければデフォルトネットワークインターフェースが利用される
   --apiserver-bind-port int32		APIサーバーとして受け付けるポート。デフォルト 6443 。
   --cert-dir string		証明書の保存先を指定。デフォルトは /etc/kubernetes/pki 。
   --config string		kubeadm 用設定ファイル へのパスを指定。
   --image-repository string		イメージを取得するリポジトリを指定。デフォルトは k8s.gcr.io 。
   --kubernetes-version string		Kubernetes の バージョン を指定。デフォルトは stable-1 。
   --node-name string		ノード名を指定。
   --pod-network-cidr string	○	Podネットワークで利用するIPアドレス範囲を指定。CNIにFlannelを利用する場合、10.244.0.0/16 を指定。
   --service-cidr string		サービスに割り当てるVIP範囲を指定。デフォルトは 10.96.0.0/12 。
   --service-dns-domain string		サービスに割り当てるドメイン名を指定。デフォルトは cluster.local

   実行結果

   [root@k8s-master ~]# kubeadm init --apiserver-advertise-address 10.51.1.100 \
   > --kubernetes-version 1.14.2 \
   > --pod-network-cidr 10.244.0.0/16
   [init] Using Kubernetes version: v1.14.2
   [preflight] Running pre-flight checks
           [WARNING Firewalld]: firewalld is active, please ensure ports [6443 10250] are open or your cluster may not function correctly
   [preflight] Pulling images required for setting up a Kubernetes cluster
   [preflight] This might take a minute or two, depending on the speed of your internet connection
   [preflight] You can also perform this action in beforehand using 'kubeadm config images pull'
   [kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
   [kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
   [kubelet-start] Activating the kubelet service
   [certs] Using certificateDir folder "/etc/kubernetes/pki"
   [certs] Generating "etcd/ca" certificate and key
   [certs] Generating "etcd/healthcheck-client" certificate and key
   [certs] Generating "etcd/peer" certificate and key
   [certs] etcd/peer serving cert is signed for DNS names [k8s-node00 localhost] and IPs [10.51.2.191 127.0.0.1 ::1]
   [certs] Generating "apiserver-etcd-client" certificate and key
   [certs] Generating "etcd/server" certificate and key
   [certs] etcd/server serving cert is signed for DNS names [k8s-node00 localhost] and IPs [10.51.2.191 127.0.0.1 ::1]
   [certs] Generating "ca" certificate and key
   [certs] Generating "apiserver" certificate and key
   [certs] apiserver serving cert is signed for DNS names [k8s-node00 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 10.51.2.191]
   [certs] Generating "apiserver-kubelet-client" certificate and key
   [certs] Generating "front-proxy-ca" certificate and key
   [certs] Generating "front-proxy-client" certificate and key
   [certs] Generating "sa" key and public key
   [kubeconfig] Using kubeconfig folder "/etc/kubernetes"
   [kubeconfig] Writing "admin.conf" kubeconfig file
   [kubeconfig] Writing "kubelet.conf" kubeconfig file
   [kubeconfig] Writing "controller-manager.conf" kubeconfig file
   [kubeconfig] Writing "scheduler.conf" kubeconfig file
   [control-plane] Using manifest folder "/etc/kubernetes/manifests"
   [control-plane] Creating static Pod manifest for "kube-apiserver"
   [control-plane] Creating static Pod manifest for "kube-controller-manager"
   [control-plane] Creating static Pod manifest for "kube-scheduler"
   [etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests"
   [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
   [apiclient] All control plane components are healthy after 17.002251 seconds
   [upload-config] storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
   [kubelet] Creating a ConfigMap "kubelet-config-1.14" in namespace kube-system with the configuration for the kubelets in the cluster
   [upload-certs] Skipping phase. Please see --experimental-upload-certs
   [mark-control-plane] Marking the node k8s-node00 as control-plane by adding the label "node-role.kubernetes.io/master=''"
   [mark-control-plane] Marking the node k8s-node00 as control-plane by adding the taints [node-role.kubernetes.io/master:NoSchedule]
   [bootstrap-token] Using token: q8793g.yx6nn1ca0ckvkqcz
   [bootstrap-token] Configuring bootstrap tokens, cluster-info ConfigMap, RBAC Roles
   [bootstrap-token] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
   [bootstrap-token] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
   [bootstrap-token] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
   [bootstrap-token] creating the "cluster-info" ConfigMap in the "kube-public" namespace
   [addons] Applied essential addon: CoreDNS
   [addons] Applied essential addon: kube-proxy
   
   Your Kubernetes control-plane has initialized successfully!
   
   To start using your cluster, you need to run the following as a regular user:
   
     mkdir -p $HOME/.kube
     sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
     sudo chown $(id -u):$(id -g) $HOME/.kube/config
   
   You should now deploy a pod network to the cluster.
   Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
     https://kubernetes.io/docs/concepts/cluster-administration/addons/
   
   Then you can join any number of worker nodes by running the following on each as root:
   
   kubeadm join 10.51.2.191:6443 --token q8793g.yx6nn1ca0ckvkqcz \
       --discovery-token-ca-cert-hash sha256:86d84fead96089fd28631f4f172348b823abb85f80c99fefa851ec136075df40
   

   実行結果の最後に表示される kubeadm join ~ （L.68-69）はメモしておきます。 このあと、ワーカーノード上で子のコマンドを実行してマスターノードに参加させていきます。

2. config ファイル の コピー

   kubectl を通常ユーザーで利用する場合、通常ユーザーにおいて以下のコマンドを実行します。

   mkdir -p $HOME/.kube
   sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
   sudo chown $(id -u):$(id -g) $HOME/.kube/config
   

   もし、引き続き root ユーザーで kubectl を利用する場合、rootユーザーで以下のコマンドを実行します。

   export KUBECONFIG=/etc/kubernetes/admin.conf
   

ここまでの作業がうまくできているか、 kubectl を実行して動作確認してみます。 このタイミングではまだネットワーク（CNI）が設定されていないので、 ステータスは NotReady になっています。

[root@k8s-master ~]# kubectl get nodes
NAME         STATUS     ROLES    AGE     VERSION
k8s-master   NotReady   master   3m41s   v1.14.2

Flannel インストール

1. kube-flannel.yml のダウノード

   curl -O https://raw.githubusercontent.com/coreos/flannel/62e44c867a2846fefb68bd5f178daf4da3095ccb/Documentation/kube-flannel.yml
   

2. kube-flannel.yml の編集

   5箇所修正。OSプラットフォームの違いで5種類の設定があるため。

     …
         - name: kube-flannel
           image: quay.io/coreos/flannel:v0.11.0-amd64
           command:
           - /opt/bin/flanneld
           args:
           - --ip-masq
           - --kube-subnet-mgr
           - --iface=ens192        # <- 環境に合わせてNIC名を指定
     …
   

3. Kubernetes上に展開

   kubectl apply -f kube-flannel.yml
   

無事、Flannelの展開が完了して、Kubernetesのマスターノードが利用可能になっているか、kubectl get pods コマンドで Pod起動状況 を確認します。 起動までは少し時間がかかるので、何度かコマンドをたたいて様子を見てみます。 最終的にすべてのPodが Running になっていればOKです。

[root@k8s-master ~]# kubectl get pods --all-namespaces
NAMESPACE     NAME                                 READY   STATUS    RESTARTS   AGE
kube-system   coredns-fb8b8dccf-dc59z              1/1     Running   0          11m
kube-system   coredns-fb8b8dccf-mghv4              1/1     Running   0          11m
kube-system   etcd-k8s-node00                      1/1     Running   0          10m
kube-system   kube-apiserver-k8s-node00            1/1     Running   0          10m
kube-system   kube-controller-manager-k8s-node00   1/1     Running   0          10m
kube-system   kube-flannel-ds-amd64-7rswc          1/1     Running   0          47s
kube-system   kube-proxy-j8xmv                     1/1     Running   0          11m
kube-system   kube-scheduler-k8s-node00            1/1     Running   0          10m

ワーカーノード構築

マスターノード構築後24時間以内であれば、kubeadm init 実行結果で取得されたコマンドを実行すればワーカーノードをマスターノードに登録できます。 以下の手順は マスターノード初期化後24時間以内 にワーカーノードをマスターノードに登録する手順です。

ファイアウォール設定

1. ポートの開放

   ポートレンジ	プロトコル	用途
   10250	TCP	Control plane
   30000-32767	TCP	All

   sudo firewall-cmd --zone public --add-port 10250/tcp --permanent
   sudo firewall-cmd --zone public --add-port 30000-32767/tcp --permanent
   sudo firewall-cmd --reload
   

マスターノードに登録

1. マスタノードへ参加

   sudo kubeadm join 10.51.1.100:6443 --token q8793g.yx6nn1ca0ckvkqcz \
       --discovery-token-ca-cert-hash sha256:86d84fead96089fd28631f4f172348b823abb85f80c99fefa851ec136075df40
   

もし、ワーカーノードの追加がマスターノード構築から24時間以上経っている場合、以下の手順でトークンとハッシュを作成してからワーカーノードをマスターノードに追加します。

マスターノード上で操作

1. トークンの生成

   kubeadm token create
   

2. ハッシュの取得

   openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | \
      openssl dgst -sha256 -hex | sed 's/^.* //'
   

ワーカーノード上で操作

1. マスターノードへ参加

   sudo kubeadm join 10.51.1.100:6443 --token <トークン> \
       --discovery-token-ca-cert-hash sha256:<ハッシュ>
   

動作確認

環境構築がすべて終わっているかどうか、Node と Pod を確認してみます。 Node を確認するには kubectl get nodes 、 Pod を確認するには kubectl get pods を利用します。 以下に実行結果のサンプルを掲載します。

[root@k8s-master ~]# kubectl get nodes
NAME         STATUS   ROLES    AGE     VERSION
k8s-master   Ready    master   6h41m   v1.14.2
k8s-node01   Ready       6h28m   v1.14.2
k8s-node02   Ready       6h28m   v1.14.2

[root@k8s-master ~]# kubectl get pods --all-namespaces
NAMESPACE     NAME                                 READY   STATUS    RESTARTS   AGE
kube-system   coredns-fb8b8dccf-tjrv9              1/1     Running   0          6h41m
kube-system   coredns-fb8b8dccf-w8qmr              1/1     Running   0          6h41m
kube-system   etcd-k8s-master                      1/1     Running   0          6h41m
kube-system   kube-apiserver-k8s-master            1/1     Running   0          6h41m
kube-system   kube-controller-manager-k8s-master   1/1     Running   0          6h40m
kube-system   kube-flannel-ds-amd64-fqmdp          1/1     Running   0          6h28m
kube-system   kube-flannel-ds-amd64-ql2g2          1/1     Running   0          6h28m
kube-system   kube-flannel-ds-amd64-xhrmx          1/1     Running   0          6h36m
kube-system   kube-proxy-7wglt                     1/1     Running   0          6h41m
kube-system   kube-proxy-ckfwd                     1/1     Running   0          6h28m
kube-system   kube-proxy-hz4k9                     1/1     Running   0          6h28m
kube-system   kube-scheduler-k8s-master            1/1     Running   0          6h41m

「Node が 仮想マシン分あること」、「flannel の Pod が仮想マシン分あること」が確認できれば環境構築ができていることの確認になります。 そもそも Flannnel 自体が Kubernetes の仕組み上で動作している DaemonSet という種類のリソースで、各ノードに1台ずつ配置されるものなので、

[参考] うまくいかず再設定したい場合

Docker

• Daemonの停止、無効化

  systemctl stop docker && systemctl disable docker
  

• ファイル/フォルダ削除

  rm -f /etc/docker/daemon.json
  rm -rf /etc/systemd/system/docker.service.d
  

• Dockerアンインストール

  yum remove docker-ce docker-ce-cli containerd.io
  

Kubernetes

• Daemonの停止、無効化

  systemctl stop kubelet && systemctl disable kubelet
  

• kubernetesクラスタの初期化

  kubeadm reset
  

• ファイル/フォルダ削除

  rm -f /var/lib/kubelet/kubeadm-flags.env
  

• kubelet, kubeadm, kubectl の削除

  yum remove \
   kubelet \
   kubeadm \
   kubectl
  

[参考] 各種確認

エラーが発生して困ったときに利用した各種確認用のコマンドの覚書。

Kubernetes

# node, pod の一覧
kubectl get nodes
kubectl get pods --all-namespaces

# 詳細確認(Kubernetes視点)
kubectl describe nodes <node name>
kubectl describe pods <pod name> -A

# kubelet のエラー確認(詳細確認はできない・・・)
systemctl status kubelet

# kubelet のエラー確認（詳細も確認）
journalctl -xe -u kubelet

今回は「CentOS上にシングルマスター構成のKubernetesクラスターを構築する方法」についてまとめました。 参考になったでしょうか？ 本記事がお役に立っていると嬉しいです！！

参考記事

• kubernetes - Installing kubeadm
• kubernetes - Creating a single master cluster with kubeadm
• kubernetes - CRI installation
• Qiita - Kubernetes on CentOS7
• GitHub - coreos/flannel
• 寝て起きて寝る - kubeadmでKubernetes1.9.3のClusterを構築したメモ
• Qiita - Kubernetes on CentOS7