galife

Kubernetes 上に単独 MongoDB サーバーを構築する方法

今回は「Kubernetes 上に単独 MongoDB サーバーを構築する方法」についてまとめます。

概要
PersistentVolume
PersistentVolumeClaim
Secret
Pod
動作確認

概要

Kubernetes上に単一の MongoDB サーバーを構築します。あまり凝ったことはせずシンプルな構成にしました。作成するリースは以下の通りです。

PersistentVolume
PersistentVolumeClaim
Secret
Pod

PersistentVolume

永続データの保存先を作成します。今回は NFS サーバーに保存するように設定しています。

マニュフェスト作成

pv0001.yml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0001
  labels:
    type: nfs
spec:
  storageClassName: slow
  accessModes:
    - ReadWriteMany
  capacity:
    storage: 3Gi
  persistentVolumeReclaimPolicy: Retain
  nfs:
    server: 10.51.1.103
    path: /var/share/pv0001

spec.nfs にNFSサーバーへの接続情報を設定します。

リソース作成
```
kubectl apply -f pv0001.yml
```
作成確認
```
kubectl get pv
```

PersistentVolumeClaim

1段抽象化された永続データ保存先情報を作成します。今回は上で作成したNFSサーバーを要求するリソースを作成しています。

マニュフェスト作成

nfs-pvc1.yml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-pvc1
spec:
  storageClassName: slow
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 3Gi

storageClassName、 accessModes は完全一致、 storage は PersistentVolume 以下になっていることに注意して設定します。

リソース作成
```
kubectl apply -f nfs-pvc1.yml
```
作成確認
```
kubectl get pvc
```

Secret

マニュフェストファイルはGitHubなどリポジトリにコミットするものですが、機微情報はだれでも閲覧できる場所に保存することはできません。そんな状況で利用できるのがこの「Secret」リソースです。機微情報は外だししてPodで参照利用するようにします。

リソース作成

以下のコマンドを実行して「Secret」リソースを作成します。

kubectl create secret generic mongo-secret \
  --from-literal=root_username=admin \
  --from-literal=root_password=Passw0rd

作成確認
```
kubectl get secrets
```

Pod

マニュフェスト作成

mongodb.yml

apiVersion: v1
kind: Pod
metadata:
  name: mongodb
  namespace: default
  labels:
    app: mongodb
    ver: "0.0.1"
    env: staging
spec:
  containers:
    - name: mongodb
      image: mongo:4.1.13-bionic
      ports:
        - containerPort: 27017
      args:
        - "mongod"
        - "--auth"
        - "--bind_ip_all"
      env:
        - name: "MONGO_INITDB_ROOT_USERNAME"
          valueFrom:
            secretKeyRef:
              name: mongo-secret
              key: root_username
        - name: "MONGO_INITDB_ROOT_PASSWORD"
          valueFrom:
            secretKeyRef:
              name: mongo-secret
              key: root_password
        - name: "MONGO_INITDB_DATABASE"
          value: "admin"
      volumeMounts:
        - mountPath: /data/db
          name: nfs-storage
  volumes:
    - name: nfs-storage
      persistentVolumeClaim:
        claimName: nfs-pvc1

command で Docker イメージの CMD を上書きしたくなりますが、実際はマッピングが異なるので args で CMD を上書きすることになります。 MongoDBの Dockerfile を見ると初期化シェルスクリプト (docker-entrypoint.sh) が ENTRYPOINT に定義されているので、 args だけ上書きします。

	Docker	Kubernetes
コンテナの初期化処理	ENTRYPOINT	command
コンテナ実行時に渡されるコマンド	CMD	args

MongoDBの初期化処理時にユーザーアカウント作成したい場合、以下の環境変数を定義しておくことでデフォルトユーザーを作成できます。

MONGO_INITDB_ROOT_USERNAME
MONGO_INITDB_ROOT_PASSWORD
MONGO_INITDB_DATABASE

リソース作成
```
kubectl apply -f mongodb.yml
```
作成確認
```
kubectl get po
```

動作確認

前述までの作業が終わっていればMongoDBサーバーが起動しているはずなので、動作確認をしてみます。

起動した MongoDB の Pod ネットワークアドレスを確認

[root@k8s-master ~]# kubectl get po -o wide
NAME      READY   STATUS    RESTARTS   AGE    IP            NODE         NOMINATED NODE   READINESS GATES
mongodb   1/1     Running   0          55s    10.244.1.48   k8s-node02

デバッグ用のPodを作成

[root@k8s-master ~]# kubectl run mongo-debug -it --rm=true --restart=Never --image=mongo:4.1 -- sh
If you don't see a command prompt, try pressing enter.

#

起動している MongoDB へ接続

# mongo 10.244.1.48
MongoDB shell version v4.1.13
connecting to: mongodb://10.244.1.48:27017/test?compressors=disabled&gssapiServiceName=mongodb
Implicit session: session { "id" : UUID("02b3159d-a585-417a-8f55-5811a40861e4") }
MongoDB server version: 4.1.13
Welcome to the MongoDB shell.
For interactive help, type "help".
For more comprehensive documentation, see
        http://docs.mongodb.org/
Questions? Try the support group
        http://groups.google.com/group/mongodb-user
>

adminデータベースにスイッチ
```
use admin
```
設定したID/PASSWORDでログイン
```
db.auth("admin", "Passw0rd")
```
データベース一覧が表示できることを確認
```
show dbs
```
動作確認が終わったら exit で終了
```
exit
```

今回は「Kubernetes 上に単独 MongoDB サーバーを構築する方法」についてまとめました。参考になったでしょうか？本記事がお役に立っていると嬉しいです！！

Kubernetes で永続データを取り扱う方法

今回は「永続データの取り扱い」として「Pod に永続データボリュームを接続、利用する方法」についてまとめます。 Kubernetes 上の永続データとして切り離せない「PersistentVolumes および PersistentVolumeClaims」についても見ていきます。

概要
前提
NFSサーバー
PersistentVolume
PersistentVolumeClaim
Pod
動作確認

概要

PersistentVolume (PV) と PersistentVolumeClaim (PVC) について学習するため、nginx の Pod に PersistentVolumeClaim を接続し、 nfs に保存されたファイルを開く方法を見ていきます。

NFSサーバーを Kubernetes クラスターとは別に用意し、Kubernetes クラスターから参照するようなサンプルを実装してみます。

前提

今回はベアメタル Kubernetes 環境で動作確認をしています。 AWS や GCP の話はやや事情が異なるのでご注意ください。

関係しそうなモジュールバージョンは以下の通りです。

Kubernetes 1.14.0

NFSサーバー

NFSサーバーには nginx へアクセスした際に返却する index.html を配置します。

index.htmlを準備

NFSサーバーには nginx で配信したい index.html を配置しておきます。配置するファイルは以下のようなものを用意します。

/var/share/pv0001/index.html
```
Hello World !
```
NFSフォルダ共有設定

/var/share を共有するように設定します。

/etc/exports
```
/share/data1    10.51.0.0/24   (rw,async,no_root_squash)
```

NFSサーバー再起動

systemctl enable nfs
systemctl restart nfs

PersistentVolume

PersistentVolume は永続データ保存先の実態です。データ保存先の実態（HDD、USB、NFS…など）に対するアクセス方法を定義します。今回は NFSサーバー向けの設定を行います。

永続データの実態となるマニュフェストを作成

今回は NFS サーバーへ接続する場合を例としたマニュフェストを記載します。

pv0001.yml
```
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0001
  labels:
    type: hdd
spec:
  capacity:
    storage: 3Gi
  storageClassName: slow
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  nfs:
    server: 10.51.1.103
    path: /var/share/pv0001
```
storageClassName

ストレージクラス名を指定します。あらかじめ定義した StorageClass の名前でもいいですし、いきなり任意の文字列を指定してもOKです。上記サンプルでは「slow」という任意文字列をいきなり指定しています。

accessMode

以下のいずれかを指定します。「どのNodeから」と「読み書き」を定義します。
- ReadWriteOnce　：単一Nodeからの読み書きアクセス
- ReadOnlyMany　：複数Nodeからの読み取り専用アクセス
- ReadWriteMany　：複数Nodeからの読み書きアクセス
persistentVolumeReclaimPolicy

PersistentVolumeClaim からの接続が解除された時の動作を定義します。選択肢は以下のどれかになります。
- Retain　：ファイル削除せずVolumeを残す。再利用は不可。
- Delete (デフォルト)　： Volumeをまるごと削除。再利用は不可。
- Recycle (非推奨)　：ファイル削除して再利用できるようにする。
作成したマニュフェストを適用、反映
```
kubectl apply -f pv0001.yml
```

以下のコマンドで作成できたことの確認ができます。
```
kubectl get pv
```

PersistentVolumeClaim

PersistentVolumeClaim では必要な PersistentVolume がどんなものであるかを定義します。データ保存先の実態は PersistentVolume で隠蔽しておき、PersistntVolumeClaim では 1段抽象化されたデータ保存先条件にマッチする PersistentVolume を探す仕組みになります。

永続データの実態への接続マニュフェストを作成

nfs-pvc1.yml
```
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-pvc1
spec:
  selector: 
    matchLabels:
      type: hdd
  storageClassName: slow
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Gi
```
PersistentVolumeClaim から PersistentVolume を検索する際に利用できる検索条件は以下のようなものになります。
- ラベル　(metadata.labels)
- 容量　(spec.capacity.storage)
- アクセスモード　(spec.accessModes)
- ストレージクラス名　(spec.storageClassName)
spec.selector.matchLabels

「PersistentVolumeClaim の spec.selector.matchLabels に指定された条件」と「PersistentVolume の metadata.labels の値」が一致する PersistentVolume を探します。指定がなければ任意のPersistentVolumeにマッチします。

spec.accessModes

accessMode が完全一致する PersistentVolume を探します。

spec.resources.requests.storage

指定された容量より大きなPersistentVolumeとマッチします。

spec.storageClassName

完全一致するPersistentVolumeとマッチします。指定がなければ storageClassName がない PersistentVolume とマッチします。
作成したマニュフェストを適用、反映
```
kubectl apply -f nfs-pvc1.yml
```

以下のコマンドで作成できたことの確認ができます。
```
kubectl get pvc
```

Pod

ここまでに作成した PersistentVolume および PersistentVolumeClaim を実際に Pod へ接続していきます。

PVCを接続する nginx コンテナ Pod のマニュフェストを作成

nginx-with-pvc.yml

apiVersion: v1
kind: Pod
metadata:
  name: nginx-with-pvc
spec:
  containers:
    - name: nginx-with-pvc
      image: nginx
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: nginx-pvc
  volumes:
    - name: nginx-pvc
      persistentVolumeClaim:
       claimName: nfs-pvc1

作成したマニュフェストを適用、反映
```
kubectl apply -f nginx-with-pvc.yml
```

以下のコマンドで作成できたことの確認ができます。
```
kubectl get po
```

動作確認

Podは意図的な配置をしない限り基本的にはPodネットワーク内で通信することになります。そのため、デバッグ用にPodを作成し、デバッグ用Podから作成したPodにアクセスすることで動作確認します。

作成したPodのIPアドレス(Podネットワーク上のIPアドレス)を確認
```
kubectl get po -o wide
```

動作確認用のCentOSコンテナ作成

kubectl run debug --image=centos:7 -it --rm --restart=Never -- sh

動作確認用のCentOSコンテナにcurlインストール
```
yum install -y curl
```
動作確認用のCentOSコンテナから作成したPodにアクセス
```
yum install -y curl
```

今回は「Pod に永続データボリュームを接続、利用する方法」についてまとめました。参考になったでしょうか？本記事がお役に立っていると嬉しいです！！

Kubernetes に NGINX Ingress Controller をデプロイする方法

今回は「ベアメタル 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

インストール

mandatory.yaml をダウンロード

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

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  - ------------

mandatory.yaml を適用
```
kubectl apply -f mandatory.yaml
```

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 で抜けます。

設定

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
作成した ConfigMap を適用します。
```
kubeadm apply -f configmap.yaml
```

動作確認

以下のようなサンプルマニュフェスト（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

---

マニュフェストを適用して展開
```
kubectl apply -f sample.yaml
```
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
```
接続確認
```
curl http://10.51.2.10
```

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

参考記事

Kubernetes に MetalLB をデプロイする方法

今回は「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 だけ修正します。

metallb.yaml をダウンロード

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

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-
---

Kubernetes 上に展開
```
kubectl apply -f metallb.yaml
```

設定

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
```
Kubernetes 上に適用
```
kubectl apply -f layer2-config.yaml
```

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 で停止させます。

動作確認

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

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

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 でアクセスできる。

ブラウザから 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の導入から動作確認まで」についてまとめました。参考になったでしょうか？本記事がお役に立っていると嬉しいです！！

参考記事

Nodeに決められたPod以外配置させない方法

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

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

関連記事

Podを指定したNodeに配置する方法
Nodeに決められたPod以外配置させない方法（この記事）

概要
Node Taints
Pod Tolerations

概要

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

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

Node 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

… (以下省略) …

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

自動付与される組み込み 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」についてまとめました。参考になったでしょうか？本記事がお役に立っていると嬉しいです！！

参考記事

Podを指定したNodeに配置する方法

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

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

関連記事

Podを指定したNodeに配置する方法（この記事）
Nodeに決められたPod以外配置させない方法

概要
Node Label
Node Selector
Node Affinity
Pod Affinity と Pod Anti-Affinity

概要

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

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

nodeSelector
nodeAffinity
podAffinity または podAntiAffinity

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

Node Label

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

現在 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

… (以下省略) …

新たなラベルを 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

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」についてまとめました。参考になったでしょうか？本記事がお役に立っていると嬉しいです！！

参考記事

CentOS 上に Kubernetes クラスターを構築する方法

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

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

概要
仮想マシン準備
- 仮想マシン作成
- systemd更新
マスターノード、ワーカーノード共通の構築
マスターノード構築
ワーカーノード構築
- ファイアウォール設定
- マスターノードに登録
動作確認
[参考] うまくいかず再設定したい場合
[参考] 各種確認

概要

マスターノード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 のインストーラーイメージ)

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

バージョン確認

yum list | grep systemd

systemdの入れ直し

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

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

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

ホスト名の設定
```
hostnamectl set-hostname <hostname>
```

ネットワークの設定

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 が有効だと kubelet が起動しないので、 swap をあらかじめ無効化しておきます。

swapを一時的に無効化
```
swapoff -a
```

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は cgroup-driver にデフォルトだと cgroupfs を利用しているので、 Kubernetes 推奨の systemd で起動するように変更して設定していきます。

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

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

安定板リポジトリを設定

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

DockerCEをインストール

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

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

daemonの再読み込み
```
systemctl daemon-reload
```
Dockerの自動起動を有効化
```
systemctl enable docker
```
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 といってもインストールする実態は kubeadm 、 kubelet 、 kubectl の3つです。

ネットワーク設定(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
```
ネットワーク設定(hosts)

ホスト名でアクセスできるよう、/etc/hosts に以下のネットワーク情報を追記します。
```
vi /etc/hosts
```
```
10.51.1.100 k8s-master
10.51.1.101 k8s-node01
10.51.1.102 k8s-node02
```

リポジトリの設定

以下のような内容の /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*

SELinux の無効化

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

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

daemonの設定変更

Cgroup Driver に systemd を指定します。 /var/lib/kubelet/kubeadm-flags.env ファイルの内容に以下を追記します。
```
vi /var/lib/kubelet/kubeadm-flags.env
```
```
KUBELET_EXTRA_ARGS=--cgroup-driver=systemd
```
daemonの再読み込み
```
systemctl daemon-reload
```
kubelet の有効化
```
systemctl enable kubelet
```
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...

マスタノード構築

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

ポートの開放

ポートレンジ	プロトコル	用途
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

初期化

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）はメモしておきます。このあと、ワーカーノード上で子のコマンドを実行してマスターノードに参加させていきます。

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

kube-flannel.yml のダウノード

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

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名を指定
  …

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時間以内にワーカーノードをマスターノードに登録する手順です。

ポートの開放

ポートレンジ	プロトコル	用途
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

マスタノードへ参加

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

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

マスターノード上で操作

トークンの生成
```
kubeadm token create
```

ハッシュの取得

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

ワーカーノード上で操作

マスターノードへ参加

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クラスターを構築する方法」についてまとめました。参考になったでしょうか？本記事がお役に立っていると嬉しいです！！

参考記事

C# & JavaScript

概要

PersistentVolume

PersistentVolumeClaim

Secret

Pod

動作確認

概要

前提

NFSサーバー

PersistentVolume

PersistentVolumeClaim

Pod

動作確認

概要

前提

インストール

設定

動作確認

概要

前提

インストール

設定

動作確認

概要

Node Taints

Taintsの確認

Taintsの付与/削除

組み込み Taints

Pod Tolerations

概要

Node Label

Labelの確認

Labelの付与/削除

デフォルトLabel

Node Selector

Node Affinity

Pod Affinity / Anti-Affinity

概要

仮想マシン準備

仮想マシン作成

systemdの更新

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

ホスト名、IPアドレス

swap 無効化

Docker インストール

Kubernetes インストール

マスタノード構築

ファイアウォール設定

マスターノードの初期化

Flannel インストール

ワーカーノード構築

ファイアウォール設定

マスターノードに登録

動作確認

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

Docker

Kubernetes

[参考] 各種確認

Kubernetes