Kubernetes アプリケーション構成管理を 1 つの記事で理解する

アプリケーションに関係なく、基本的に設定ファイルが存在します。企業では、ほとんどが apollo、nacos などの構成センターを使用します。一部の企業では、主に Kubernetes に付属する構成管理を直接使用しています。

秘密
構成マップ

秘密

設定情報が Secret に保存されている場合は、暗号化されて Etcd に保存されます。 Pod は次の 2 つの方法で使用できます。

環境変数を通じて
マウントすることで
イメージを取得するためのシークレットを指定します

一般的に、Secret に保存される構成情報は、データベースアカウントのパスワード、認証サービスアカウントのパスワードなどの機密情報であり、大きな Secret を使用すると API サーバーと kubelet のメモリを大量に占有するため、Secret は大きすぎないようにしてください。

シークレットを作成する

シークレットを作成するには、主に 2 つの方法があります。

YAMLファイルを使用して作成する
kubectlコマンドを使用して作成する

YAMLファイルを使用して作成する

YAML ファイルを使用して Secret を作成するには、kubectl explain secret で表示できる Secret 構成の詳細を理解している必要があります。主なフィールドは、apiVersion、data、kind、metadata、type です。

たとえば、次のように単純な Secret を作成します。

 APIバージョン: v1
 種類: 秘密
メタデータ:
 名前: 私の秘密の巻
タイプ: 不透明
データ：
 ユーザー: cm9vdA ==
 パスワード: UEBzc1cwcmQ =

このうち、apiVersion、kind、metadata はよく使用されるフィールドですが、ここでは説明しません。タイプはシークレットのタイプを示し、主に次のものが含まれます。

Qpaque: 任意のデータを定義できます。
kubernetes.io/service-account-token: ServiceAccount トークンを設定します。
kubernetes.io/dockercfg: docker 認証ファイルを設定します。
kubernetes.io/dockerconfigjson: docker 認証ファイルを設定します。
kubernetes.io/basic-auth: 基本認証を設定します。
kubernetes.io/ssh-auth: SSH 認証を設定します。
kubernetes.io/tls: TLS 証明書を構成します。
bootstrap.kubernetes.io/token: ブートストラップトークンを設定します。

Secret の作成時にタイプが指定されていない場合は、デフォルトで Qpaque タイプが使用されます。さらに、データの値は base64 でエンコードされている必要があります。

kubectlコマンドを使用して作成する

kubectl を使用して作成するときに、サブコマンドの情報がわからない場合は、kubectl explain secret を使用して表示できます。

次のコマンドを使用して Secret を作成します。

 $ kubectl シークレットを作成します。 汎用シークレット- auth - test --from - literal = ユーザー名= joker --from - literal = パスワード= 123

作成が完了すると、次のようにユーザー名とパスワードの値が自動的に暗号化されていることがわかります。

 $ kubectl シークレットを取得しますsecret - auth - test - oyaml
 APIバージョン: v1
 データ：
 パスワード: MTIz
 ユーザー名: am9rZXI =
 種類: 秘密
メタデータ:
 作成タイムスタンプ: "2022-07-25T07:44:18Z"
 名前: シークレット- 認証- テスト
名前空間: デフォルト
リソースバージョン: "652834"
 uid : ff1b756a - 6 b38 - 4 b68 - a47c - c51988729b68
 タイプ: 不透明

コマンドラインでデータを直接入力するだけでなく、次のようにファイルからデータを作成することもできます。

 $ echo -n ' admin ' > ./ユーザー名.txt
 $ echo -n ' 1f2d1e2e67df ' > ./ パスワード .txt

次に、次のように --from-file を使用してファイルをインポートします。

 $ kubectl シークレットジェネリックDB を作成- ユーザー- パス\
 -- ファイルから= . / ユーザー名。 TXT \
 -- from - ファイル= ./password .txt

作成されたシークレット値はすべて暗号化されます。プレーンテキスト情報を取得する場合は、次のコマンドを使用します。

 $ kubectl get secret db - user - pass - o jsonpath = '{.data.password}' | base64 -- デコード

デフォルトでは、シークレットは base64 を使用して暗号化されるため、base64 復号化を使用して直接復号化を行うことができます。

シークレットの使用

Secret は単なる静的リソースです。最終的にはそれを使いたいのです。実際には、主に次の方法で使用されます。

環境変数を通じて。
マウントすることで。
イメージをプルするためのシークレットを指定します。

上記で secret-auth-test の Secret を作成し、それぞれ以下の 3 つの方法で使用します。

環境変数経由でシークレットを使用する

Pod オブジェクトには spec.containers.env.valueFrom.secretKeyRef フィールドがあり、次のように Secret フィールドを参照するために使用できます。

 APIバージョン: v1
 種類: ポッド
メタデータ:
 名前: secret - env - pod
 仕様:
 コンテナ:
 - 名前: mycontainer
 画像: redis
 環境:
 - 名前: SECRET_USERNAME
 値の開始値:
 シークレットキーリファレンス:
 名前: シークレット- 認証- テスト
キー: ユーザー名
- 名前: SECRET_PASSWORD
 値の開始値:
 シークレットキーリファレンス:
 名前: シークレット- 認証- テスト
キー: パスワード

これにより、Secret 内の情報がコンテナの環境変数に挿入され、アプリケーションは環境変数を読み取ってそれを直接使用できるようになります。

マウントによるシークレットの使用

次のように、マウントメソッドを使用して、Secret をファイルとしてコンテナーにマウントできます。

 APIバージョン: v1
 種類: ポッド
メタデータ:
 名前: マイポッド
仕様:
 コンテナ:
 - 名前: mypod
 画像: redis
 ボリュームマウント:
 - 名前: foo
 マウントパス: "/etc/foo"
 読み取り専用: true
 巻数:
 - 名前: foo
 秘密：
 secretName : シークレット- 認証- テスト

これにより、次のようにデータが /etc/foo ディレクトリにマウントされます。

 $ kubectl exec -it mypod -- / bin / sh
 # ls -l / etc / foo
 合計0
 lrwxrwxrwx 1 root root 15 Jul 25 08 : 30 パスワード-> .. データ/ パスワード
lrwxrwxrwx 1 root root 15 Jul 25 08 : 30 ユーザー名-> .. data / ユーザー名

Secret に複数のキー値がある場合は、次のように 1 つのデータのみをマウントすることもできます。

 APIバージョン: v1
 種類: ポッド
メタデータ:
 名前: マイポッド
仕様:
 コンテナ:
 - 名前: mypod
 画像: redis
 ボリュームマウント:
 - 名前: foo
 マウントパス: "/etc/foo"
 読み取り専用: true
 巻数:
 - 名前: foo
 秘密：
 secretName : シークレット- 認証- テスト
アイテム:
 - キー: ユーザー名
パス: my - グループ/ my - ユーザー名

上記で指定した volumes.secret.items.path は、次のようにユーザー名のサブディレクトリを指定するために使用されます。

 $ kubectl exec -it mypod -password -- / bin / bash
 root @mypod - パスワード: / data # cat / etc / foo / my - グループ/ my - ユーザー名
ジョーカー

さらに、次のように権限を指定することもできます。

 APIバージョン: v1
 種類: ポッド
メタデータ:
 名前: マイポッド
仕様:
 コンテナ:
 - 名前: mypod
 画像: redis
 ボリュームマウント:
 - 名前: foo
 マウントパス: "/etc/foo"
 巻数:
 - 名前: foo
 秘密：
 secretName : シークレット- 認証- テスト
デフォルトモード: 0400

すると、マウントされた Secret の権限が次のように表示されます。

 $ kubectl exec -it mypod -permision -- / bin / bash
 root @mypod - 権限: / etc / foo # ls - l
 合計0
 lrwxrwxrwx 1 root root 15 Jul 25 08 : 38 パスワード-> .. データ/ パスワード
lrwxrwxrwx 1 root root 15 Jul 25 08 : 38 ユーザー名-> .. data / ユーザー名
root @mypod - 権限: / etc / foo # ls .. data / password - l
 - r -------- 1 root root 3 7月25日08:38 .. データ/ パスワード

注: /etc/foo ディレクトリに入り、ls -l を使用して権限を確認すると、権限が 777 であることがわかります。ただし、注意深い人であれば、それが実際にはリンクファイルであることに気付くでしょう。本当に確認したい権限は、リンクされたファイル、つまり上記の ..data/password の権限です。

イメージを取得するときにSecretを使用する

上記では多くの YAML ファイルをリストしましたが、そのいずれも imagePullSecret を設定していません。これは主に、これらのイメージが公式の Dockerhub イメージであり、一般に公開されているためです。

しかし、実際の制作においては、会社のイメージが公開されることはなく、非常に不安です。イメージリポジトリが暗号化されている場合は、イメージをダウンロードするときに docker login が必要です。この操作はKubernetesでも避けられません。

このため、Kubernetes は、イメージをプルするための Secret を指定するために使用される imagePullSecret フィールドを提供します。このシークレットは、イメージリポジトリの認証情報を保存します。

（１）まず、画像認証情報のSecretを作成します。

 kubectl シークレットを作成\
 docker - レジストリプル- レジストリ- シークレット\
 --docker - server = レジストリ。 テスト。 \ ...
 --docker - ユーザー名= ops \
 --docker - パスワード= ops123123 \

（２）ポッドで使用される。

 APIバージョン: v1
 種類: ポッド
メタデータ:
 名前: マイポッド
仕様:
 イメージプルシークレット:
 - 名前: プル- レジストリ- シークレット
コンテナ:
 - 名前: mypod
 画像: redis
 ボリュームマウント:
 - 名前: foo
 マウントパス: "/etc/foo"
 巻数:
 - 名前: foo
 秘密：
 secretName : シークレット- 認証- テスト
デフォルトモード: 0400

この方法で、プライベートウェアハウス内のイメージをプルできます。

要約する

要約すると、Secret を使用して他のシステムの機密情報 (データベースのユーザー名やパスワードなど) を保存し、Secret をマウントモードでコンテナーにマウントし、ディレクトリ内のファイルにアクセスして機密情報を取得することができます。 API サーバーによってポッドが作成されると、API サーバーはポッドによって参照されるシークレットが存在するかどうかを確認しません。 Pod がスケジュールされると、kubelet は Secret の値を取得しようとします。 Secret が存在しないか、一時的に API サーバーに接続できない場合、kubelet は定期的に Secret の取得を再試行し、Pod が起動しなかった理由を説明するイベントを送信します。 Pod が Secret を取得すると、kubelet は Secret を含むボリュームを作成してマウントします。すべてのボリュームが正常にマウントされた場合にのみ、ポッド内のコンテナが起動します。 kubelet がポッド内のコンテナを起動した後、Secret 自体が変更されても、コンテナ内の Secret に関連付けられたボリュームは変更されません。更新された Secret を使用するには、古い Pod を削除して新しい Pod を作成する必要があります。

構成マップ

ConfigMap は Secret と似ていますが、一部のアプリケーションの構成情報など、ConfigMap に保存されるデータ情報は暗号化する必要がない点が異なります。その他の使用方法は Secret と同じです。

ConfigMapを作成する

同様に、ConfigMap を作成するには 2 つの方法を使用できます。

コマンドラインから、つまり kubectl create configmap を使用します。
YAML ファイル方式を通じて;

コマンドでConfigMapを作成する

ConfigMap オブジェクトのフィールドについて詳しくない場合は、kubectl explain configmap を使用して表示できます。 configmap の作成例を確認したい場合は、次のように kubectl create configmap -h で表示できます。

 例:
 # フォルダbar に基づいて、 my - config という名前の新しい設定マップを作成します。
 kubectl create configmap my - config --from - file = パス/ to / bar 
 # ディスク上のファイルベース名の代わりに指定されたキーを持つ、 my - config という名前の新しい設定マップを作成します
kubectl create configmap my - config --from - file = key1 = / path / to / bar / file1 。 txt -- from - file = key2 = / path / to / bar / file2 。 TXT
 # key1 = config1 、 key2 = config2 で、 my - config という名前の新しい設定マップを作成します。
 kubectl configmap を作成します。my - config --from - literal = key1 = config1 --from - literal = key2 = config2
 # ファイル内のキー= 値のペアから、 my - config という名前の新しい設定マップを作成します。
 kubectl create configmap my - config --from - file = パス/ to / bar 
 # env ファイルからmy - config という名前の新しい設定マップを作成します
kubectl create configmap my - config --from - env -file = path / to / foo 。  env --from - env -file = パス/ to / bar 。  環境

上記のように、ConfigMap は指定されたディレクトリから作成できます。たとえば、次の構成ファイルを定義します。

 $ mkdir configmap -demo
 $ cd configmap - デモ
$ ll
 合計8
 -rw -r -- r -- 1 root root 25 9 月6 17:07 mysqld .  会議
-rw -r -- r -- 1 root root 25 9 月6 17:07 redis .  会議
mysqld をcat します。 会議
ホスト= 127.0.0.1
 ポート= 3306
 $ cat redis 。 会議
ホスト= 127.0.0.1
 ポート= 6379

次に、次のコマンドを使用して作成します。

 $ kubectl create configmap my - configmap --from - file = ../configmap-demo/ を実行します。

次に、次のコマンドを使用して、作成された configmap を表示します。

 $ kubectl 取得cm
 名前データ年齢
kube - ルート- ca.crt121d
 私の- configmap 2 9 秒
$ kubectl はcm my - configmap を記述します
名前: my - configmap
 名前空間: デフォルト
ラベル: < なし>
 注釈: < なし>
 データ
====
 : :mysqld.conf :
 ----
 ホスト= 127.0.0.1
 ポート= 3306
 conf : ...
 ----
 ホスト= 127.0.0.1
 ポート= 6379
 バイナリデータ
====
 イベント: < なし>

2 つのキーはファイルの名前に対応し、値はファイルの内容に対応していることがわかります。キー値を表示する場合は、次のコマンドを使用して表示できます。

 $ kubectl get configmap my - configmap - o yaml
 APIバージョン: v1
 データ：
 mysqld.conf : |
 ホスト= 127.0.0.1
 ポート= 3306
 レディス。 conf : |
 ホスト= 127.0.0.1
 ポート= 6379
 種類: ConfigMap
 メタデータ:
 作成タイムスタンプ: "2022-07-25T09:20:43Z"
 名前: my - configmap
 名前空間: デフォルト
リソースバージョン: "667706"
 uid : 46cb52e9-0936-4934-9628 - ac20efcfd893

もちろん、ファイルを通じて configmap を作成することもできます。たとえば、次のように構成ファイルを定義します。

 $ cat nginx.conf
 ユーザーnobody ;
 ワーカープロセス1 ;
 error_log ログ/ エラー。 ログ;
 error_log ログ/ エラー。 ログ通知;
 error_log ログ/ エラー。 ログ情報;
 pid ログ/ nginx 。 ピッド;
 イベント{
 ワーカー接続1024 ;
 }
 http {
 mime を含めます。 種類;
 default_type アプリケーション/ オクテットストリーム;
 log_format main '$remote_addr - $remote_user [$time_local] "$request" '
 '$status $body_bytes_sent "$http_referer" '
 '"$http_user_agent" "$http_x_forwarded_for"' ;
 access_log ログ/ アクセス。 ログメイン;
 ファイル送信オン;
 tcp_nopush オン;
 キープアライブタイムアウト65 ;
 gzip オン;
 サーバー{
 聞く80 ;
 サーバー名ローカルホスト;
 位置/ {
 ルートhtml ;
 インデックスインデックス。 html インデックス。 .html ;
 }
 エラーページ500 502 503 504 / 50 x . html ;
 場所= / 50 x . html {
 ルートhtml ;
 }
 }
 }

次に、次のコマンドで nginx の configmap を作成します。

 $ kubectl create configmap nginx - configmap --from - file = nginx 。 会議

作成された情報を表示します。

 $ kubectl get configmap nginx - configmap - o yaml
 APIバージョン: v1
 データ：
 nginx.conf : |
 ユーザーnobody ;
 ワーカープロセス1 ;
 error_log ログ/ エラー。 ログ;
 error_log ログ/ エラー。 ログ通知;
 error_log ログ/ エラー。 ログ情報;
 pid ログ/ nginx 。 ピッド;
 イベント{
 ワーカー接続1024 ;
 }
 http {
 mime を含めます。 種類;
 default_type アプリケーション/ オクテットストリーム;
 log_format main '$remote_addr - $remote_user [$time_local] "$request" '
 '$status $body_bytes_sent "$http_referer" '
 '"$http_user_agent" "$http_x_forwarded_for"' ;
 access_log ログ/ アクセス。 ログメイン;
 ファイル送信オン;
 tcp_nopush オン;
 キープアライブタイムアウト65 ;
 gzip オン;
 サーバー{
 聞く80 ;
 サーバー名ローカルホスト;
 位置/ {
 ルートhtml ;
 インデックスインデックス。 html インデックス。 .html ;
 }
 エラーページ500 502 503 504 / 50 x . html ;
 場所= / 50 x . html {
 ルートhtml ;
 }
 }
 }
 種類: ConfigMap
 メタデータ:
 作成タイムスタンプ: "2022-07-25T09:24:29Z"
 名前: nginx - configmap
 名前空間: デフォルト
リソースバージョン: "668283"
 uid : a025da28-6817-4605-8daf - 375 b676282c1

注: --from-file は 1 つのコマンドで複数回指定できます。

さらに、ヘルプドキュメントを見ると、--from-literal パラメータを介して構成情報を渡し、文字列を使用して直接作成することもできることがわかります。同様に、このパラメータは複数回使用できます。形式は次のとおりです。

 $ kubectl create configmap my - cm - daemo --from - literal = db 。 ホスト= localhost -- from - リテラル= db 。 ポート= 3306

YAML による ConfigMap の作成

YAML ファイルを使用して作成するのは比較的簡単です。上記の yaml 情報出力を参照して、次のように YAML ファイルを定義することができます。

 APIバージョン: v1
 種類: ConfigMap
 メタデータ:
 名前: my - cm - daemon2
 ラベル:
 アプリ: cm - デーモン
データ：
 レディス。 conf : |
 ホスト= 127.0.0.1
 ポート= 6379

それでは作成しましょう。

ConfigMapの使用

ConfigMap の構成データは、次の方法で使用できます。

環境変数の値を設定します。
データボリュームに設定ファイルを作成します。

環境変数経由でConfigMapを使用する

次のように、pod.spec.containers.env.valueFrom.configMapKeyRef で ConfigMap を参照するだけです。

 APIバージョン: v1
 種類: ポッド
メタデータ:
 名前: env - configmap
 ラベル:
 アプリ: env - configmap - mysql
 仕様:
 コンテナ:
 - 名前: テスト- 構成マップ
画像: ビジーボックス
指示：
 - "/bin/sh"
 - 「-c」
 - 「env」
 環境:
 - 名前: DB_HOST
 値の開始値:
 configMapKeyRef :
 名前: my - cm - daemo
 キー: db 。 ホスト
- 名前: DB_PORT
 値の開始値:
 configMapKeyRef :
 名前: my - cm - daemo
 キー: db 。 ポート
envFrom : から
- configMapRef :
 名前: my - cm - daemo

作成後、次のようにログを通じて環境変数の出力を表示できます。

 $ kubectl logs env - configmap | grep DB
 DB_ポート= 3306
 DB_HOST = ローカルホスト

データボリュームでのConfigMapの使用

基本的な原理は Secret と同じです。

ここでは、pod.spec.volumes.configMap.name を指定して ConfigMap を指定し、次のようにコンテナにマウントします。

 APIバージョン: v1
 種類: ポッド
メタデータ:
 名前: ボリューム- configmap - テスト
仕様:
 コンテナ:
 - 名前: ボリューム- configmap - テスト
画像: ビジーボックス
コマンド: [ "/bin/sh" 、 "-c" 、 "cat /etc/config/redis.conf" ]
 ボリュームマウント:
 - 名前: 設定- ボリューム
マウントパス: / etc / config
 巻数:
 - 名前: 設定- ボリューム
構成マップ:
 名前: my - configmap

ログを通じて ConfigMap がマウントされているかどうかを確認できます。

 $ kubectl ログボリューム- configmap - テスト
ホスト= 127.0.0.1
 ポート= 6379

次のように、ConfigMap 値がマップされるデータボリューム内のパスを制御することもできます。

 APIバージョン: v1
 種類: ポッド
メタデータ:
 名前: ボリューム- パス- configmap
 仕様:
 コンテナ:
 - 名前: ボリューム- パス- configmap - テスト
画像: ビジーボックス
コマンド: [ "/bin/sh" 、 "-c" 、 "cat /etc/config/path/to/msyqld.conf" ]
 ボリュームマウント:
 - 名前: 設定- ボリューム
マウントパス: / etc / config
 巻数:
 - 名前: 設定- ボリューム
構成マップ:
 名前: my - configmap
 アイテム:
 - キー: mysqld 。 会議
パス: msyqld.conf へのパス

また、ConfigMap がデータボリュームとして Pod にマウントされている場合、ConfigMap が更新されると (または ConfigMap が削除されて再構築されると)、Pod にマウントされている構成情報がホットに更新されます。構成情報が更新されても、アプリケーションが使用できるかどうかは、主にアプリケーションがホットアップデートできるかどうかによって決まります。

要約する

ConfigMap は実際にはまだ広く使用されており、主に Nginx 構成ファイルや MySQL 構成ファイルなど、一部のアプリケーションの構成ファイルに使用されています。このような構成ファイルをプライベート構成センターに配置する場合は、追加の労力を費やす必要があります。 ConfigMap に配置する方がはるかに便利で、そのほとんどはマウントされた形式でコンテナに配置されます。

<<: エッジコンピューティングが業務に与える影響

>>: ダボでのプロキシレスメッシュの実践