galife: Kubernetes

ラベル Kubernetes の投稿を表示しています。すべての投稿を表示

minikube が起動する Kubernetes VM に SSH でログインする方法

今回は「minikube が起動する Kubernetes 仮想マシンに SSH 接続する方法」についてまとめます。

SSH接続方法①（簡易方式）
SSH接続方法②（通常方式）

そもそもなんでこんな記事を書こうかと思ったかというと、imagePullPolicy: Never がなぜかうまく動かない（ErrImageNeverPull になる）という事象が発生したのでその原因を調査していたため。

minikubeでKubernetesクラスタを起動する際、 --vm-driver=none を指定しない場合、minikubeはホスト上に存在する何かしらのハイパーバイザーに対してKubernetesのワーカーノードとなる仮想マシンを動させます。つまり、いくらホストOS上でDockerイメージを生成してもKubernetesワーカーノードとなるゲストOS上にDockerイメージは生成されていないので、 imagePullPolicy: Never は必ず ErrImageNeverPull になるわけです。

というわけで、その対策として直接DockerイメージをKubernetesワーカーノード上に生成したいのでワーカーノードにSSH接続したい、ということで本記事のSSH接続です。

SSH接続方法①（簡易方式）

minikubeのコマンドを利用した簡易的に接続する方法です。

ターミナルを起動して以下のコマンドを実行
```
minikube ssh
```

SSH接続方法②（通常方式）

一般的なSSH接続方法で接続していく方法です。

ターミナルを起動して仮想マシンのIPアドレスを確認

$ kubectl config view

apiVersion: v1
clusters:
- cluster:
    certificate-authority: /Users/owner/.minikube/ca.crt
    server: https://192.168.99.100:8443
  name: minikube
contexts:
- context:
    cluster: minikube
    user: minikube
  name: minikube
current-context: minikube
kind: Config
preferences: {}
users:
- name: minikube
  user:
    client-certificate: /Users/owner/.minikube/client.crt
    client-key: /Users/owner/.minikube/client.key

SSHコマンドを実行して接続

ユーザー名
docker

パスワード
tcuser
```
ssh docker@192.168.99.100
```

今回は「minikube が起動する Kubernetes 仮想マシンに SSH 接続する方法」についてまとめました。参考になったでしょうか？本記事がお役に立っていると嬉しいです！！

参考記事

Kubernetes 上に Redis Sentinel 構成を構築する方法

今回は「Kubernetes上にRedisのSentinel構成を構築する方法」についてまとめます。

今回はRedisの冗長化構成３種（Replication、Sentinel、Cluster）のうち「Sentinel」構成について、構築する方法をまとめました。ただ…残念ながら現状のRedis（v5.0.5）では標準付属の Sentinel のみを利用した Kubernetes上での"完全な" 冗長構成は作れなさそうです。もし完全な冗長構成を作りたい場合は少し自作が必要そうです。

概要
構築（共通）
- Secret
構築（Replication）
- Service
- StatefulSet
構築（Sentinel）
- Service
- StatefulSet
確認

概要

今回は以下のような構成で Redis Sentinel 構成を組み上げていきます。

構成としては「マスター１台、スレーブ１台、センチネル３台」で、「パスワードを共有」するような構成にしています。

「Redis Seerver の StatefulSet に Sentinel を同梱」するような実装だと Pod 内に Redis Server と Sentinel が一緒になってしまってPodの再起動がしづらくなってしまいます。まぁ、そもそも役割違うのでPod分けてあげるのが妥当かと思って上のような構成にしています。

なお、Sentinel側もStatefulSetで構築していますが、こちらはDeploymentでもいいかもしれません（Sentinel は順序性の意味がないので）。

構築（共通）

まずは共有するパスワードをSecretリソースに準備します。作成方法は単独サーバーのときと同じなのでほぼ再掲になります。一応、今回は作成リソースが多くなるのであとから検索しやすくするようラベルを追加しておきます。

パスワードファイルを作成

OpenSSL を利用してランダムなパスワード文字列を作成します。デフォルト指定する base64 オプションだと約3割り増しの文字列生成されるので、改行削除して先頭512文字をパスワードとして利用します。
```
openssl rand -base64 512 | tr -d '\r\n' | cut -c 1-512 > redis-password
```
この後で動作確認をする際に毎回このパスワードを入力します。パスワードが長いとテスト向けに動作確認するのはつらくなるので、本番まで間はいったん適当にしておくのもあり。

KubernetesにSecreetリソースを作成

kubectl create secret generic redis-secret --from-file=redis-password

Secreetリソースをラベルを追加

kubectl label secrets/redis-secret app=redis

構築（Replication）

Redis Server 用の Service を作成していきます。

マニュフェストの作成

redis-server-service.yml

apiVersion: v1
kind: Service
metadata:
  name: cache-service
  labels:
    app: redis
spec:
  ports:
  - port: 6379
    targetPort: 6379
  clusterIP: None               # Headless Service
  selector:
    app: redis                  # match "StatefulSet spec.template.metadata.labels"
    type: server

selector には app 以外にも type を指定しています。今回は Redis Server と Sentinel の２つがあるので、その違いを type で区別するようにしています。

リソースの作成

kubectl apply -f redis-server-service.yml

Redisサーバーの実態を作成します。

マニュフェストの作成

redis-server-statefulset.yml

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: redis
  namespace: default
  labels:
    app: redis
    ver: "0.0.1"
    env: staging
spec:
  selector:
    matchLabels:
      app: redis
      type: server
  serviceName: cache-service    # match "Service metadata.name"
  replicas: 2
  template:
    metadata:
      name: redis
      namespace: default
      labels:
        app: redis
        type: server
        ver: "0.0.1"
        env: staging
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: redis
        image: redis:5.0.5-alpine3.10
        ports:
        - containerPort: 6379
        command:
        - "/bin/sh"
        - "-c"
        args:
        - |
          CONFIG_FILE_PATH=/data/redis.conf
          
          create_config() {
          if [ $HOSTNAME = ${REDIS_STATEFULSETNAME}-0 ]; then
          
          # 
          # Master server config file
          # 
          cat <<-EOF > "${CONFIG_FILE_PATH}"
          ########### NETWORK ##########
          bind 0.0.0.0
          port 6379
          protected-mode no

          ########### GENERAL ##########
          daemonize no
          logfile ""

          ######## SNAPSHOTTING ########
          save 900 1
          save 300 10
          save 60 10000
          dir "/data"
          dbfilename "dump.rdb"

          ######### REPLICATION ########
          masterauth ${REDIS_PASSWORD}
          replica-announce-ip "${HOSTNAME}.${REDIS_SERVICENAME}"
          replica-announce-port 6379

          ########## SECURITY ##########
          requirepass ${REDIS_PASSWORD}

          ##### MEMORY MANAGEMENT ######
          maxmemory 100mb
          maxmemory-policy allkeys-lru
          EOF
          
          else
          
          # 
          # Slave server config file
          # 
          cat <<-EOF > "${CONFIG_FILE_PATH}"
          ########### NETWORK ##########
          bind 0.0.0.0
          port 6379
          protected-mode no

          ########### GENERAL ##########
          daemonize no
          logfile ""

          ######## SNAPSHOTTING ########
          save 900 1
          save 300 10
          save 60 10000
          dir "/data"
          dbfilename "dump.rdb"

          ######### REPLICATION ########
          replicaof ${REDIS_STATEFULSETNAME}-0.${REDIS_SERVICENAME} 6379
          masterauth ${REDIS_PASSWORD}
          replica-announce-ip "${HOSTNAME}.${REDIS_SERVICENAME}"
          replica-announce-port 6379

          ########## SECURITY ##########
          requirepass ${REDIS_PASSWORD}

          ##### MEMORY MANAGEMENT ######
          maxmemory 100mb
          maxmemory-policy allkeys-lru
          EOF
          
          fi
          }

          if [ ! -e ${CONFIG_FILE_PATH} ]; then
            create_config
          fi

          redis-server "${CONFIG_FILE_PATH}"
        env:
        - name: "REDIS_STATEFULSETNAME"
          value: "redis"
        - name: "REDIS_SERVICENAME"
          value: "cache-service"
        - name: "REDIS_PASSWORD"
          valueFrom:
            secretKeyRef:
              name: redis-secret
              key: redis-password

あまり特筆事項はありませんが…もし設定ファイルを ConfigMap から与えたいのであれば、initContainerやShellで別途コピーして書き込みできるようにする必要があります。

リソースの作成

kubectl apply -f redis-server-statefulset.yml

構築（Sentinel）

Redisレプリケーションを監視するセンチネルを構築します。センチネルはステートフルである必要ありませんが・・・サーバー本体と同じ作りのほうがわかりやすいかと思うので、今回は StatefulSet で準備します。

サーバーを個別に特定できるようHeadlessサービスを作っておきます。

マニュフェストの作成

redis-sentinel-service.yml

apiVersion: v1
kind: Service
metadata:
  name: cache-monitoring
  labels:
    app: redis
spec:
  ports:
  - port: 26379
    targetPort: 26379
  clusterIP: None               # Headless Service
  selector:
    app: redis                  # match "StatefulSet spec.template.metadata.labels"
    type: sentinel

リソースの作成

kubectl apply -f redis-sentinel-service.yml

センチネルを構築します。

マニュフェストの作成

redis-sentinel-statefulset.yml

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: sentinel
  namespace: default
  labels:
    app: redis
    ver: "0.0.1"
    env: staging
spec:
  selector:
    matchLabels:
      app: redis
      type: sentinel
  serviceName: cache-monitoring # match "Service metadata.name"
  replicas: 3
  template:
    metadata:
      name: redis
      namespace: default
      labels:
        app: redis
        type: sentinel
        ver: "0.0.1"
        env: staging
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: sentinel
        image: redis:5.0.5-alpine3.10
        ports:
        - containerPort: 26379
        command:
        - "/bin/sh"
        - "-c"
        args:
        - |
          CONFIG_FILE_PATH=/etc/redis.conf

          while ! ping -c 1 ${REDIS_MASTER_HOST} &> /dev/null
          do
            echo "Waiting for redis master server boot ..."
            sleep 1
          done

          cat <<-EOF > "${CONFIG_FILE_PATH}"
          ########### NETWORK ##########
          bind 0.0.0.0
          port 26379
          protected-mode no
          
          ########### GENERAL ##########
          daemonize no
          logfile ""
          sentinel announce-ip "${HOSTNAME}.${REDIS_SENTINEL_SERVICENAME}"
          sentinel announce-port 26379
          
          ########## SECURITY ##########
          requirepass ${REDIS_PASSWORD}
          
          ########## SENTINEL ##########
          sentinel monitor mymaster ${REDIS_MASTER_HOST} 6379 2
          sentinel auth-pass mymaster ${REDIS_PASSWORD}
          sentinel down-after-milliseconds mymaster 5000
          sentinel failover-timeout mymaster 180000
          sentinel parallel-syncs mymaster 1
          EOF

          redis-server "${CONFIG_FILE_PATH}" --sentinel
        env:
        - name: "REDIS_MASTER_HOST"
          value: "redis-0.cache-service"
        - name: "REDIS_SENTINEL_SERVICENAME"
          value: "cache-monitoring"
        - name: "REDIS_PASSWORD"
          valueFrom:
            secretKeyRef:
              name: redis-secret
              key: redis-password

センチネルは３台以上が推奨なので、 replication は 3以上を指定します。

リソースの作成

kubectl apply -f redis-sentinel-statefulset.yml

確認

ここまでに作成したクラスタの動作確認をしていきます。

ラベル指定で作成リソースを確認

[root@k8s-master ~]# kubectl get sts,svc,po,secrets -l app=redis
NAME                        READY   AGE
statefulset.apps/redis      2/2     13h
statefulset.apps/sentinel   3/3     12h

NAME                       TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)     AGE
service/cache-monitoring   ClusterIP   None         <none>        26379/TCP   12h
service/cache-service      ClusterIP   None         <none>        6379/TCP    13h

NAME             READY   STATUS    RESTARTS   AGE
pod/redis-0      1/1     Running   0          146m
pod/redis-1      1/1     Running   0          13h
pod/sentinel-0   1/1     Running   0          12h
pod/sentinel-1   1/1     Running   0          12h
pod/sentinel-2   1/1     Running   0          12h

NAME                  TYPE     DATA   AGE
secret/redis-secret   Opaque   1      13h

動作確認用Pod作成

kubectl run -it redis-debug --image=redis:5.0.5-alpine3.10 --restart=Never --rm -- sh

マスターへログイン

redis-cli -h redis-0.cache-service -a password

マスターにデータ投入
```
set key1 "Hello World"
```
マスターからログアウト

exit でログアウトします。

スレーブにログイン

redis-cli -h redis-1.cache-service -a password

スレーブでデータ確認
```
get key1
"Hello World"
```

動作確認用Pod作成

kubectl run -it redis-debug --image=redis:5.0.5-alpine3.10 --restart=Never --rm -- sh

現在の状態を確認

redis-cli -h redis-0.cache-service -a password info | grep role
redis-cli -h redis-1.cache-service -a password info | grep role

マスターを停止

redis-cli -h redis-0.cache-service -a password debug sleep 30

スレーブが昇格していることを確認

redis-cli -h redis-0.cache-service -a password info | grep role
redis-cli -h redis-1.cache-service -a password info | grep role

…と、まぁ、"1回" だけは自動でフェールオーバーしてくれるのですが…２回目を続けて実施すると動かないんですよね。。おそらく Redis Sentinel が内部的に管理しているものが「IPアドレス」で「ホスト名」ではないことに起因しているように見えます。また、 sleep ではなく kubectl delete pod/redis-0 のようなことをすると、そもそもIPアドレスが変わってしまって動きがおかしくなります。

これに対する対策は…「ホスト名解決できる実装を待つ」か「IPアドレスがおかしな場合に補正を行うスクリプトを書く」かどちらかになりそうです。後者（補正するスクリプト）については実際に作っている人がいる（hortonworks/k8s-redis-ha ）ので参考にしてみるとよいかも。

今回は「Kubernetes 上に Redis Sentinel 構成を構築する方法」についてまとめました。ポイントは以下の通りです。

レプリケーションは StatefulSet で構築、 Headless サービスで特定できるようにする
センチネルは StatefulSet ないし Deployment で構築
標準機能だけだと１回しかフェールオーバーできない

参考になったでしょうか？本記事がお役に立っていると嬉しいです！！

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

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

概要
構築
- Secret
- Pod
確認

概要

単独サーバーとして Redis を動作させる構成を作っていきます。冗長構成はとっていないので落ちたら止まります…が、基本構成の学習にはシンプルなほうが良いのでまずは単独サーバーで構築を行っていきます

構築

Redis のパスワードは最大512文字まで指定できるので512文字でランダム文字列を作成します。

パスワードファイルを作成

OpenSSL を利用してランダムなパスワード文字列を作成します。デフォルト指定する base64 オプションだと約3割り増しの文字列生成されるので、改行削除して先頭512文字をパスワードとして利用します。
```
openssl rand -base64 512 | tr -d '\r\n' | cut -c 1-512 > redis-password
```

KubernetesにSecreetリソースを作成

kubectl create secret generic redis-secret --from-file=redis-password

もし作成されていることを確認したいのであれば以下のコマンドで確認します。

kubectl get secrets

構築の方法はいろいろ考えられます。 ConfigMap を使う方法が真っ先に思い浮かぶのですが…単純に組み込むと ReadOnly になってしまってうまく動作しません。 initContainer と PersistentVolume ないし emptyDir 使えば回避できますが…複雑なので今回はやめておきます。今回は簡単な方法として、Redis設定ファイル（redis.conf）をシェル内で作成する方法をとりました。

マニュフェストファイル作成

redis-pod.yml

apiVersion: v1
kind: Pod
metadata:
  name: redis
  namespace: default
  labels:
    app: redis
    ver: "0.0.1"
    env: staging
spec:
  containers:
  - name: redis
    image: redis:5.0.5-alpine3.10
    command:
    - "/bin/sh"
    - "-c"
    args:
    - |
      cat <<-EOF > /etc/redis.conf
      ########### NETWORK ##########
      bind 0.0.0.0
      port 6379

      ########### GENERAL ##########
      daemonize no
      logfile ""

      ########## SECURITY ##########
      requirepass ${REDIS_PASSWORD}

      ##### MEMORY MANAGEMENT ######
      maxmemory 100mb
      maxmemory-policy allkeys-lru
      EOF

      redis-server /etc/redis.conf
    env:
    - name: "REDIS_PASSWORD"
      valueFrom:
        secretKeyRef:
          name: redis-secret
          key: redis-password

リソース作成
```
kubectl apply -f redis-pod.yml
```

動作確認は以下のコマンドで行います。

kubectl get pods

確認

RedisサーバーのIPアドレス確認

[root@k8s-master ~]# kubectl get po -o wide
NAME    READY   STATUS    RESTARTS   AGE   IP             NODE         NOMINATED NODE   READINESS GATES
redis   1/1     Running   0          11m   10.244.1.119   k8s-node02   <none>           <none>

デバッグ用のPod起動

ポッド名は「redis-debug」、イメージは「Redisサーバーと同じもの（= redis:5.0.5-alpine3.10）」、再起動はさせず終了時に削除を指定（--restart=Never --rm）して起動します。
```
[root@k8s-master ~]# kubectl run -it redis-debug --image=redis:5.0.5-alpine3.10 --restart=Never --rm -- sh
If you don't see a command prompt, try pressing enter.
/data #
```
Redisサーバーに接続して動作確認

接続先（-h オプションへ渡すIP）は 1 で確認した IP を指定します。パスワードはSecret作成時に作った redis-password の値を指定します。
```
/data # redis-cli -h 10.244.1.119
10.244.1.121:6379> auth xxxxxxxxx
OK
10.244.1.121:6379> set key1 Hello
OK
10.244.1.121:6379> get key1
"Hello"
10.244.1.121:6379> keys
1) "key1"
```

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

Alpine Linux でユーザー/グループを追加/削除/一覧する方法

今回は Docker や Kubernetes を触っているとよく出てくる Alpine Linux について、「ユーザー/グループを追加/削除/一覧する方法」をまとめます。

今回はどちらかというと備忘のためのまとめです。

ユーザー
グループ
(参考)　コマンド
- adduser
- deluser
- addgroup
- delgroup

ユーザー

ユーザー追加

# adduser [-u UID] USER

ユーザー削除

# deluser [--remove-home] USER

ユーザー一覧表示

# cat /etc/passwd

passwdファイルに保存されているデータは以下のデータを ":"(コロン) でつないだデータ形式になっている。

ユーザー名
パスワード
ユーザーID
グループID
コメント
ホームディレクトリ
ログインシェル

グループ

グループ追加

# addgroup [-g GID] GROUP

グループ削除

# delgroup GROUP

グループ一覧

# cat /etc/group

グループにユーザー追加

# addgroup USER GROUP

グループからユーザー削除

# delgroup USER GROUP

(参考) コマンドリファレンス

adduser

Usage: adduser [OPTIONS] USER [GROUP]

Create new user, or add USER to GROUP

        -h DIR          Home directory
        -g GECOS        GECOS field
        -s SHELL        Login shell
        -G GRP          Group
        -S              Create a system user
        -D              Don't assign a password
        -H              Don't create home directory
        -u UID          User id
        -k SKEL         Skeleton directory (/etc/skel)

deluser

Usage: deluser [--remove-home] USER

Delete USER from the system

addgroup

Usage: addgroup [-g GID] [-S] [USER] GROUP

Add a group or add a user to a group

        -g GID  Group id
        -S      Create a system group

delgroup

Usage: delgroup [USER] GROUP

Delete group GROUP from the system or user USER from group GROUP

今回は「Alpine Linux 上でユーザー/グループを追加/削除/一覧する方法」についてまとめました。参考になったでしょうか？本記事がお役に立っていると嬉しいです！！

Kubernetes 上に MongoDB レプリカセットを構築する方法

今回は「Kubernetes 上に MongoDB のレプリカセットを構築する方法」についてまとめます。

概要
前提
PersistentVolume
Service
Secret
StatefulSet
初期設定
動作確認

概要

MongoDB 3台構成のレプリカセットを構築します。また、レプリカセット構築にあたっては「キーファイル（--keyFile）」「認証（--auth）」「実行ユーザー変更（runAsUser）」も含めた内容になっています。最後の StatefulSet がいろいろな情報を含んでしまって濁ってしまっていますが…３種類を含んでいることを踏まえて読んでいただければ理解しやすいと思います。

前提

今回の検証は以下のような環境で実施しています。

Kubernetes v1.14.2
Docker v18.09.6

PersistentVolume

今回は3台構成なのでデータ保存先も3か所用意します。環境の都合で保存先は同じ NFS になっています。

マニュフェスト作成

mongo-pv.yml

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

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

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

適用
```
kubectl apply -f mongo-pv.yml
```
確認
```
kubectl get pv
```

Service

Podネットワーク中でサービス名を使った検索をするわけではないので、ClusterIP は不要になります。必要なのはPodの名前からIPアドレスを引けるようにするため、ヘッドレスサービスを作成します。

マニュフェスト作成

mongo-svc.yml

apiVersion: v1
kind: Service
metadata:
  name: mongo-svc
  labels:
    app: mongodb
spec:
  ports:
    - port: 27017
      targetPort: 27017
  clusterIP: None               # Headless Service
  selector:
    app: mongodb                # match "StatefulSet spec.template.metadata.labels"

HeadlessService は clusterIP に None を指定することで実現できます。

適用
```
kubectl apply -f mongo-svc.yml
```
確認
```
kubectl get svc
```

Secret

「ユーザー名、パスワード、キーファイル」を準備します。

キーファイル作成
```
openssl rand -base64 768 > keyfile
```
MongoDBのキーファイルは「6～1024文字」なのですが…1024文字で生成すると少しデータが膨らむようでうまく動きませんでした。そのため文字数は少な目で生成します。

Secretリソース作成

kubectl create secret generic mongo-secret \
  --from-literal=root_username=admin \
  --from-literal=root_password=Passw0rd \
  --from-file=./keyfile

確認
```
kubectl get secrets
```

StatefulSet

とても残念なことに MongoDB の公式イメージを素のまま使おうとすると認証回りの初期化処理がうまく動きませんでした。。仕方ないので、公式イメージのコマンドに対してシェルスクリプトを挟むことで回避するようにしています。ただ…結果としてマニュフェストが大きくなってしまってます。。実運用する場合はきちんとDockerイメージ作って運用したほうがよさそうです。

マニュフェスト作成

mongo-sts.yml

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mongo-sts
  namespace: default
  labels:
    app: mongodb
spec:
  selector:
    matchLabels:
      app: mongodb
  serviceName: mongo-svc        # match "Service metadata.name"
  replicas: 3
  template:
    metadata:
      name: mongodb
      namespace: default
      labels:
        app: mongodb
        ver: "0.0.1"
        env: staging
    spec:
      terminationGracePeriodSeconds: 10
      containers:
        - name: mongodb
          image: mongo:4.0
          ports:
            - containerPort: 27017
          command:
            - "/bin/sh"
            - "-c"
          args:
            - |
              INIT_FLAG_FILE=/data/db/init-completed
              INIT_LOG_FILE=/data/db/init-mongodb.log

              start_mongod_as_daemon() {
              echo 
              echo "> start mongod ..."
              echo 
              mongod \
                --fork \
                --logpath ${INIT_LOG_FILE} \
                --quiet \
                --bind_ip 127.0.0.1 \
                --smallfiles;
              }

              create_user() {
              echo 
              echo "> create user ..."
              echo 
              mongo "${MONGO_INITDB_DATABASE}" <<-EOS
                db.createUser({
                  user: "${MONGO_INITDB_ROOT_USERNAME}",
                  pwd: "${MONGO_INITDB_ROOT_PASSWORD}",
                  roles: [{ role: "root", db: "${MONGO_INITDB_DATABASE}" }]
                })
              EOS
              }

              create_initialized_flag() {
              echo 
              echo "> create initialized flag file ..."
              echo 
              cat <<-EOF > "${INIT_FLAG_FILE}"
              [$(date +%Y-%m-%dT%H:%M:%S.%3N)] Initialize scripts is finished.
              EOF
              }

              stop_mongod() {
              echo 
              echo "> stop mongod ..."
              echo 
              mongod --shutdown;
              }

              
              start_mongod() {
              mongod \
                --auth \
                --clusterAuthMode "keyFile" \
                --keyFile "/home/mongodb/keyfile" \
                --replSet "rs0" \
                --bind_ip_all \
                --smallfiles;
              }
              
              
              if [ ! -e ${INIT_FLAG_FILE} ]; then
              echo 
              echo "--- Initialize MongoDB --------------"
              echo 
              start_mongod_as_daemon
              create_user
              create_initialized_flag
              fi

              echo
              echo "--- Start MongoDB -------------------"
              echo
              start_mongod

          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:
            - name: mongo-secret-keyfile
              mountPath: /etc/mongo/secrets
              readOnly: true
            - name: volatile-volume
              mountPath: /home/mongodb
            - name: nfs-storage
              mountPath: /data/db
          securityContext:
            runAsUser: 999
            runAsGroup: 999
      initContainers:
        - image: centos:7
          name: mongo-init
          volumeMounts:
            - name: mongo-secret-keyfile
              mountPath: /etc/mongo/secret
            - name: volatile-volume
              mountPath: /home/mongodb
          command:
            - "/bin/sh"
            - "-c"
          args:
            - |
              cp /etc/mongo/secret/keyfile /home/mongodb/keyfile
              chown 999:999 /home/mongodb/keyfile
              chmod 700 /home/mongodb/keyfile
              exit
      securityContext:
        fsGroup: 999
      volumes:
        - name: mongo-secret-keyfile
          secret:
            secretName: mongo-secret
            items:
              - key: keyfile
                path: keyfile
                mode: 384
        - name: volatile-volume
          emptyDir: {}
  volumeClaimTemplates:
    - metadata:
        name: nfs-storage
      spec:
        storageClassName: slow
        accessModes:
          - ReadWriteMany
        resources:
          requests:
            storage: 3Gi

L.12
serviceName は作成済みの HeadlessService 名と同じ名前を指定してあげます。ここでサービス名が異なっているとサービス利用してPod名を解決できません（=DNSにレコードが登録されない）。

L.34-102
DBの初期化で利用するユーザー名、パスワードは作成済の Secretリソースから取得します。こうすることで、機微な情報をリポジトリにコミットせずにすみます。 MongoDB公式の初期化処理がいまいちなので…結局このあたりの処理は自前実装しています。

L.128, L.146, L.154
keyfile のパーミッションは実行ユーザーのみに限定しないと MongoDB が起動しません。これを実現するためには、 mode に 10進数か 8進数でパーミッションを指定し、fsGroup に mongodb (UID=999) を指定します。本来であればこの設定（mode と fsGroup）のみでうまく動いてほしいのですが… Secrets と ConfigMap はマウントする際、強制的に「root 所有の読み取り専用、フルアクセス」になってしまいます。そのため、 initContainers と emptyDir の組み合わせ技で中間処理を挟んで適切な所有者とアクセス権になるよう修正します。

L.161, 162, 163, 166
volumeClaimTemplates は作成した PersistentVolume にあわせて指定します。一致しなければいけないのは storageClassName 、 accessModes 。 storage は PersistentVolume より小さい値であればOKです。

適用
```
kubectl apply -f mongo-sts.yml.yml
```
確認
```
kubectl get sts,po
```

初期設定

前述までの実装ができていれば MongoDB サーバーが 3台立ち上がっているはずです。まだ単独で動作しているだけの状態なので、レプリカセットとしての初期化を行っていきます。

いずれかのPodに入る

[root@k8s-master ~]# kubectl exec -it mongo-sts-0 -- sh

MongoDBに接続
```
# mongo mongo-sts-0.mongo-svc
```

adminデータベースにログイン

> use admin
> db.auth("admin", "Passw0rd")

レプリカセットを初期化

> config = {
   _id : "rs0",
   members: [
      { _id: 0, host: "mongo-sts-0.mongo-svc:27017" },
      { _id: 1, host: "mongo-sts-1.mongo-svc:27017" },
      { _id: 2, host: "mongo-sts-2.mongo-svc:27017" },
   ]
}
> rs.initiate(config)

動作確認

動作確認は MongoDB クラスタに接続して以下のようなコマンドを実行することで状態確認してみます。

> rs.status()

今回は「Kubernetes 上に MongoDB のレプリカセットを構築する方法」についてまとめました。参考になったでしょうか？本記事がお役に立っていると嬉しいです！！

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

参考記事

SSH接続方法①（簡易方式）

SSH接続方法②（通常方式）

概要

構築（共通）

Secret

構築（Replication）

Service

StatefulSet

構築（Sentinel）

Service

StatefulSet

確認

作成したリソースの確認

マスター→スレーブへデータがコピーされる動作確認

マスター停止時にスレーブがマスターに昇格する動作確認

概要

構築

Secret

Pod

確認

ユーザー

ユーザー追加

ユーザー削除

ユーザー一覧表示

グループ

グループ追加

グループ削除

グループ一覧

グループにユーザー追加

グループからユーザー削除

(参考) コマンドリファレンス

adduser

deluser

addgroup

delgroup

概要

前提

PersistentVolume

Service

Secret

StatefulSet

初期設定

動作確認

概要

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