C# & JavaScript

今回は「Redis を CentOS に インストール する 方法」についてまとめます。

動作環境

今回は以下の環境で確認しています。

[root@localhost ~]# cat /etc/redhat-release
CentOS Linux release 7.6.1810 (Core)

インストール

1. 以下のコマンドを実行してインストール

   wget http://download.redis.io/releases/redis-5.0.5.tar.gz
   tar xzf redis-5.0.5.tar.gz
   cd redis-5.0.5
   make
   make install
   

インストール先は /usr/local/bin 配下になります。 とりあえず起動したい場合 redis-server で起動できます。

初期設定

ポート開放

デフォルト「6379」ポートを利用するので該当ポートを開放します。

firewall-cmd --zone=public --add-port=6379/tcp --permanent
firewall-cmd --reload

設定ファイル作成

設定ファイル（ redis.conf ） はダウンロードした tar.gz の中にサンプルが含まれているのでそれをコピーして利用してもよいです。 今回は最低限必要そうな設定だけしたものを用意します。

/etc/redis.conf

########### NETWORK ##########
bind 0.0.0.0
port 6379

########### GENERAL ##########
daemonize no
supervised systemd
logfile /var/log/redis/redis.log

######## SNAPSHOTTING ########
save 900 1
save 300 10
save 60 10000
dir /var/lib/redis
dbfilename dump.rdb

########## SECURITY ##########
requirepass master-password

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

設定

各種設定に関する補足を以下にまとめておきます。

• ネットワーク

  bind <IP1> [[<IP2> [<IP3> ...]]]

  受け付けるIPアドレスを指定します。複数指定する場合は " "(空白) で連結して指定します。

  port <PORT>

  受け付けるポート番号を指定します。

• 一般

  daemonize [yes|no]

  デーモン起動するかどうかを指定します。デフォルト no 。

  supervised [no|upstart|systemd|auto]

  upstart か systemd を指定するとスーパーバイザと通信します。

  loglevel [debug|verbose|notice|warning]

  ログレベルを指定します。debug が一番多く、 warning が一番少ない。プロダクション推奨は notice 。

  logfile <PATH>

  ログファイルの出力先を指定します。 ""(空白) は標準出力を意味しますが、daemonize している場合は出力先が /dev/null となり破棄されます。 意図的に標準出力を指定したい場合は stdout を指定します。

• スナップショット

  save <SECONDS> <CHANGES>

  SECONDS 秒以上経過したとき少なくとも CHANGES 回数変更があった場合ディスク保存します。

  dir <PATH>

  DBファイル保存先ディレクトリを指定します。

  dbfilename <FILENAME>

  DBファイル名を指定します。

• セキュリティ

  requirepass <PASSWORD>

  Redisを利用するためのパスワードを指定します。 Redisは性能が良いので秒間150,000回以上の試行ができてしまいます。 パスワードは十分長い文字列を指定してください。

• メモリ管理

  maxmemory <BYTES>

  Redisが使用できるメモリ上限を指定します。 メモリ上限に到達した場合、 maxmemory-policy に従って削除を行います。

  maxmemory-policy [volatile-lru|allkeys-lru|volatile-lfu|allkeys-lfu|volatile-random|allkeys-random|volatile-ttl|noeviction]

  メモリ上限に到達した際どのようなルールでメモリ上のデータを削除するかを指定します。

自動起動設定

make しただけだとサービス設定がなされないので手動でサービスを追加します。

1. ユーザー/グループの作成

   # useradd redis
   # mkdir -p /var/lib/redis
   # mkdir -p /var/log/redis
   # chown -R redis:redis /var/lib/redis /var/log/redis
   

2. サービスファイルの作成

   /etc/systemd/system/redis-server.service

   [Unit]
   Description=Redis
   
   [Service]
   Type=notify
   ExecStart=/usr/local/bin/redis-server /etc/redis.conf
   ExecStop=/usr/local/bin/redis-cli shutdown
   User=redis
   Group=redis
   
   [Install]
   WantedBy=multi-user.target
   

3. systemctl の再読み込み

   # systemctl daemon-reload
   

4. サービス有効化/起動

   # systemctl enable redis-server
   # systemctl start redis-server
   

動作確認

1. サーバー起動

   手動起動する場合は以下のコマンドを実行します。 サービス実行しているようであればこの手順をスキップします

   # redis-server
   

2. サーバー接続

   # redis-cli
   

3. 認証

   127.0.0.1:6379> AUTH master-password
   OK
   

4. データ挿入/確認/削除/キー一覧

   127.0.0.1:6379> set mykey1 "Hello World"
   OK
   127.0.0.1:6379> get mykey1
   "Hello World"
   127.0.0.1:6379> del mykey1
   (integer) 1
   127.0.0.1:6379> keys *
   (empty list or set)
   

5. サーバー停止

   127.0.0.1:6379> shutdown
   not connected>
   

6. サーバー切断

   not connected> exit
   

今回は「Redis を CentOS に インストール する 方法」についてまとめました。 RedisはオンメモリDBと思ってましたが、実はデータ保存する仕組みがあったんですね。 参考になったでしょうか？ 本記事がお役に立っていると嬉しいです！！

参考記事

• redis - Download
• YOMON8.NET - CentOS7にRedisのインストールとsystemdサービス化まで
• 設定ファイル

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

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

ユーザー

ユーザー追加

# 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 の レプリカセット を 構築する 方法」についてまとめます。

概要

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

前提

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

• Kubernetes v1.14.2
• Docker v18.09.6

PersistentVolume

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

1. マニュフェスト作成

   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
   

2. 適用

   kubectl apply -f mongo-pv.yml
   

3. 確認

   kubectl get pv
   

Service

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

1. マニュフェスト作成

   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 を指定することで実現できます。

2. 適用

   kubectl apply -f mongo-svc.yml
   

3. 確認

   kubectl get svc
   

Secret

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

1. キーファイル作成

   openssl rand -base64 768 > keyfile
   

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

2. Secretリソース作成

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

3. 確認

   kubectl get secrets
   

StatefulSet

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

1. マニュフェスト作成

   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です。

2. 適用

   kubectl apply -f mongo-sts.yml.yml
   

3. 確認

   kubectl get sts,po
   

初期設定

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

1. いずれかのPodに入る

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

2. MongoDBに接続

   # mongo mongo-sts-0.mongo-svc
   

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

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

4. レプリカセットを初期化

   > 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

PersistentVolume

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

1. マニュフェスト作成

   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サーバーへの接続情報を設定します。

2. リソース作成

   kubectl apply -f pv0001.yml
   

3. 作成確認

   kubectl get pv
   

PersistentVolumeClaim

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

1. マニュフェスト作成

   nfs-pvc1.yml

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

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

2. リソース作成

   kubectl apply -f nfs-pvc1.yml
   

3. 作成確認

   kubectl get pvc
   

Secret

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

1. リソース作成

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

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

2. 作成確認

   kubectl get secrets
   

Pod

1. マニュフェスト作成

   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

2. リソース作成

   kubectl apply -f mongodb.yml
   

3. 作成確認

   kubectl get po
   

動作確認

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

1. 起動した 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              
   

2. デバッグ用の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.
   
   #
   

3. 起動している 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
   >
   

4. adminデータベースにスイッチ

   use admin
   

5. 設定したID/PASSWORDでログイン

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

6. データベース一覧が表示できることを確認

   show dbs
   

7. 動作確認が終わったら exit で終了

   exit
   

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

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

概要

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

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

前提

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

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

• Kubernetes 1.14.0

NFSサーバー

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

1. index.htmlを準備

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

   /var/share/pv0001/index.html

   Hello World !
   

2. NFSフォルダ共有設定

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

   /etc/exports

   /share/data1    10.51.0.0/24   (rw,async,no_root_squash)
   

3. NFSサーバー再起動

   systemctl enable nfs
   systemctl restart nfs
   

PersistentVolume

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

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

   今回は 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 (非推奨)　： ファイル削除して再利用できるようにする。

2. 作成したマニュフェストを適用、反映

   kubectl apply -f pv0001.yml
   

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

  kubectl get pv
  

PersistentVolumeClaim

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

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

   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 とマッチします。

2. 作成したマニュフェストを適用、反映

   kubectl apply -f nfs-pvc1.yml
   

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

  kubectl get pvc
  

Pod

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

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

2. 作成したマニュフェストを適用、反映

   kubectl apply -f nginx-with-pvc.yml
   

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

  kubectl get po
  

動作確認

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

1. 作成したPodのIPアドレス(Podネットワーク上のIPアドレス)を確認

   kubectl get po -o wide
   

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

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

3. 動作確認用のCentOSコンテナにcurlインストール

   yum install -y curl
   

4. 動作確認用のCentOSコンテナから作成したPodにアクセス

   yum install -y curl
   

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

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

概要

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

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

前提

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

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

インストール

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

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

2. mandatory.yaml を編集

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

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

3. mandatory.yaml を適用

   kubectl apply -f mandatory.yaml
   

4. service-nodeport.yaml を適用

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

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

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

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

設定

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

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

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

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

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

   NGINX Ingress Controller - ConfigMaps

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

   kubeadm apply -f configmap.yaml
   

動作確認

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

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

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

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

   kubectl apply -f sample.yaml
   

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

   kubectl get ing --watch
   

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

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

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

4. 接続確認

   curl http://10.51.2.10
   

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

参考記事

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

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

概要

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

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

前提

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

• Kubernetes v1.14
• MetalLB v0.7.3

インストール

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

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

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

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

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

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

3. Kubernetes 上に展開

   kubectl apply -f metallb.yaml
   

設定

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

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

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

2. Kubernetes 上に適用

   kubectl apply -f layer2-config.yaml
   

1. Firewallの穴あけ

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

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

動作確認

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

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

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

   kubectl get pods,services
   

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

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

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

   

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

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

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

参考記事

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