Kubernetesのプログラミング

第7章. シッピングコントローラーと演算子

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

カスタムコントローラの開発について理解したところで、次にカスタムコントローラと演算子を本番環境に対応させる方法について説明する。この章では、コントローラと演算子の運用面について説明し、それらをパッケージ化する方法を紹介し、本番環境でコントローラを実行するためのベストプラクティスを説明し、拡張点がKubernetesクラスタを壊さないように、セキュリティやパフォーマンスの面で確認する。

ライフサイクル管理とパッケージング

このセクションでは、演算子のライフサイクル管理について考える。つまり、コントローラまたは演算子をパッケージングして出荷する方法と、 アップグレードを処理する方法について説明します。演算子をユーザに出荷する準備ができたら、ユーザがそれをインストールする方法が必要になる。そのためには、コントローラバイナリを定義するデプロイ成果物（通常はKubernetesデプロイとして）、CRD、セキュリティ関連リソース（サービスアカウントや必要なRBACパーミッションなど）をパッケージ化する必要がある。ターゲットとするユーザがあるバージョンの演算子を動作させたら、バージョニングと潜在的なゼロダウンタイムアップグレードを考慮して、コントローラをアップグレードするためのメカニズムも用意したい。

ユーザが簡単にインストールできるように、コントローラをパッケージングして提供する。

パッケージング課題

Kubernetes 、リソースの状態を宣言するための低レベルインタフェースであるYAMLで記述されたマニフェストでリソースを定義するが、これらのマニフェストファイルには欠点がある。つまり、YAMLマニフェスト内のすべての値は固定である。つまり、YAMLマニフェスト内のすべての値は固定である。これは、例えばデプロイマニフェスト内のコンテナイメージを変更したい場合、新しいマニフェストを作成しなければならないことを意味する。

具体例を見てみよう。以下のKubernetesデプロイをmycontroller.yamlというYAMLマニフェストにエンコーディングし、ユーザにインストールさせたいカスタムコントローラを表現しているとする：

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: mycustomcontroller
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: customcontroller
    spec:
      containers:
      - name: thecontroller
        image: example/controller:0.1.0
        ports:
        - containerPort: 9999
        env:
        - name: REGION
          value: eu-west-1

環境変数REGION は、コントローラの特定の実行時プロパティ(マネージドサービス メッシュのような他のサービスの可用性など)を定義しているとする。言い換えると、eu-west-1 のデフォルト値は賢明な値かもしれないが、ユーザは自分の好みやポリシーに基づいて上書きすることができる。

さて、YAML マニフェストmycontroller.yaml自体が静的ファイルで、すべての変数が記述時に定義され、