アプリ・デプロイメントの計画

IBM Cloud Kubernetes Service ではどのようなアプリを実行できますか?

ステートレス・アプリ

ステートレス・アプリは、Kubernetes のようなクラウド・ネイティブ環境に適しています。 これらのアプリはマイグレーションとスケーリングが簡単です。これは、これらのアプリでは、依存関係が宣言され、構成がコードとは別に保管され、データベースなどのバッキング・サービスが、アプリに結合されたものではなく接続されたリソースとして扱われるためです。 アプリ・ポッドは永続データ・ストレージや安定したネットワーク IP アドレスを必要としないため、ワークロードの需要に応じてポッドを終了、スケジュール変更、およびスケーリングできます。 このアプリでは、永続データに対して Database-as-a-Service が使用されるとともに、NodePort サービス、ロード・バランサー・サービス、または Ingress サービスを使用して安定した IP アドレス上でワークロードが公開されます。

ステートフル・アプリ

ステートフル・アプリは、ステートレス・アプリよりも、セットアップ、管理、およびスケーリングが複雑になります。これは、ポッドが永続データと安定したネットワーク ID を必要とするためです。 ステートフル・アプリは、多くの場合、データベース、またはその他の分散型でデータ集中型のワークロードであり、データ自体に近ければ近いほど、処理効率が高くなります。 ステートフル・アプリをデプロイする場合は、永続ストレージをセットアップして、StatefulSet オブジェクトによって制御されるポッドに永続ボリュームをマウントする必要があります。 ステートフル・セット用の永続ストレージとして、ファイル・ストレージ、ブロック・ストレージ、またはオブジェクト・ストレージを追加することを選択できます。 また、ベアメタルのワーカーノードに Portworx インストールし、高可用性ソフトウェア定義ストレージソリューションとして Portworx 使用して、ステートフルアプリケーションの永続ストレージを管理することもできます。 ステートフルセットの動作に関する詳細については、 ドキュメント Kubernetes を参照してください。

ステートレスなクラウド・ネイティブ・アプリを開発するためのガイドラインはどのようなものですか?

1 2要素アプリ（Twelve-Factor App）をご覧ください。これは言語に依存しない方法論であり、アプリ開発を12の要素から検討するものです。その概要は以下の通りです。

1. コード・ベース: デプロイメントのバージョン管理システムで単一のコード・ベースを使用します。 コンテナー・デプロイメントのイメージをプルする際は、latest を使用する代わりにテスト済みのイメージ・タグを指定します。
2. 依存関係: 外部的な依存関係を明示的に宣言して分離します。
3. 構成: デプロイメント固有の構成をコード内ではなく環境変数に保管します。
4. バッキング・サービス: データ・ストアやメッセージ・キューなどのバッキング・サービスを、接続されたリソースまたは交換可能なリソースとして扱います。
5. アプリのステージ: build、release、run などの独立したステージを取り入れて、これらのステージを厳格に分離します。
6. プロセス: 何も共有しない 1 つ以上のステートレス・プロセスとして実行します。また、データ保存用に永続ストレージを使用します。
7. ポート・バインディング: ポート・バインディングは自己完結型であり、明確に定義されたホストとポート上でサービス・エンドポイントを提供します。
8. 並行性: レプリカや水平スケーリングなどのプロセス・インスタンスを通じてアプリを管理およびスケーリングします。 デプロイメントに対するリソースの要求と制限を設定します。 Calico ネットワーク・ポリシーによって帯域幅を制限することはできません。 代わりに、Istio を検討してください。
9. 廃棄容易性: 最小の起動時間、安全なシャットダウン、突然のプロセス終了への容認を備えた、廃棄可能なアプリを設計します。 コンテナー、ポッド、さらにはワーカー・ノードも廃棄可能であることを意図しているため、アプリもこれらに従って計画してください。
10. 開発環境と本番環境の整合性: 開発中のアプリと本番環境のアプリに最小限の差異しか生じないよう、アプリの継続的インテグレーションおよび継続的デリバリーパイプラインを設定する。
11. ログ: ログをイベント・ストリームとして扱います。外部環境またはホスティング環境によってログ・ファイルが処理されてルーティングされます。 重要: IBM Cloud Kubernetes Service では、ログはデフォルトで有効になっていません。 ログを有効にするには、ログ転送の構成を参照してください。
12. 管理プロセス: アプリに一時的な管理スクリプトを同梱し、それらを Kubernetes ジョブオブジェクトとして実行してください。これにより、管理スクリプトがアプリ本体と同じ環境で確実に実行されます。 クラスタ Kubernetes で実行したい大規模なパッケージのオーケストレーションには、パッケージマネージャー（例： Helm ）の使用を検討してください。

サーバーレス・アプリは使用できますか?

サーバーレス・アプリおよびジョブは、 IBM Cloud Code Engine サービスを使用して実行できます。 Code Engine は、イメージを作成することもできます。 Code Engine は、基盤となるテクノロジーを使用する必要がないように設計されています。 ただし、Kubernetes または Knative に基づく既存のツールがある場合は、それを Code Engine と一緒に使用することができます。 詳しくは、 Kubernetes を使用したアプリケーションとの対話を参照してください。

既にアプリがあります。 どうすれば IBM Cloud Kubernetes Service にマイグレーションできますか?

以下の一般的な手順を実行することで、アプリをコンテナー化できます。

1. 依存関係を分離し、プロセスを個別のサービスに分割し、アプリケーションの状態依存性を可能な限り低減するための指針として、 1 2要素アプリケーションを採用してください。
2. 使用する適切な基本イメージを見つけます。 Hub Docker の公開画像、 パブリック IBM 画像 を利用するか、プライベート環境で独自に構築 IBM Cloud Container Registry ・管理できます。
3. アプリを実行するために必要なもののみを Docker イメージに追加します。
4. ローカル・ストレージを利用する代わりに、永続ストレージまたはクラウド Database as a Service のソリューションを使用してアプリのデータをバックアップすることを計画してください。
5. 時間をかけて、アプリのプロセスをリファクタリングしてマイクロサービスに変換します。

アプリをコンテナーに配置する必要があると思っていました。 ポッドとは何ですか?

ポッドは管理 Kubernetes 可能な最小の展開単位である。 コンテナー (またはコンテナーのグループ) をポッドに格納して、そのポッドの構成ファイルを使用して、そのコンテナーを実行する方法および他のポッドとリソースを共有する方法をそのポッドに通知します。 ポッドに配置したすべてのコンテナは共有コンテキストで実行されます。つまり、仮想マシンまたは物理マシンを共有します。

コンテナーに格納するもの

使用するアプリケーションのコンポーネントについて検討するときには、CPU やメモリーなどのリソース要件がそれらのコンポーネントの間で大きく異なるかどうかを考慮してください。 例えば、コンポーネントによっては、リソースを他の領域に転用するために一時的に稼働停止することが許容され、ベスト・エフォート方式で実行できる場合があります。 別のコンポーネントは、顧客に対応するものであるため、常時稼働させることが非常に重要である可能性があります。 これらは、別々のコンテナーに分けてください。 いつでも、これらを同じポッドにデプロイすることで、同期的に一緒に実行されるようにすることができます。

ポッドに格納するもの

同じアプリの複数のコンテナーが常に同じポッドに格納される必要はありません。 ステートフルでありスケーリングが困難なコンポーネント (データベース・サービスなど) がある場合は、そのコンポーネントを異なるポッドに格納して、そのワークロードを処理するための十分なリソースを備えたワーカー・ノード上でそのポッドをスケジュールしてください。 コンテナーが正常に動作し、別々のワーカー・ノード上で実行される場合は、複数のポッドを使用してください。 同じマシンに配置して一緒にスケーリングする必要があるコンテナーは、まとめて同じポッドに格納します。

では、ポッドを使えるのなら、なぜこれら様々な種類のオブジェクトが必要なのでしょうか？

ポッドの YAML ファイルは簡単に作成できます。 次のように数行で記述できます。

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80

ここからさらに設定を進めます。 ポッドが実行されているノードがダウンした場合は、そのポッドも一緒にダウンするため、そのポッドがスケジュール変更されることはありません。 代わりに、 デプロイメントを使用してポッドの再スケジューリング、レプリカセット、ローリング更新をサポートします。 基本的なデプロイメントは、ポッドと同じくらい簡単に作成できます。 ただし、spec 内で単独でコンテナーを定義する代わりに、デプロイメントの replicas 内で template と spec を指定します。 テンプレートには、次の例のようにコンテナー用の独自の spec が含まれています。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

ポッドのアンチアフィニティーやリソース制限などの機能を、同じ YAML ファイルにさらに追加できます。

デプロイに追加できるさまざまな機能の詳細な説明については、 「アプリデプロイのYAMLファイルの作成」 を参照してください。

どのようなタイプの Kubernetes オブジェクトをアプリ用に作成できますか?

アプリ YAML ファイルを準備するとき、アプリの可用性、パフォーマンス、セキュリティーを高めるための多くの選択肢があります。 例えば、1 つのポッドを用意する代わりに、Kubernetes コントローラー・オブジェクトを使用してレプリカ・セット、ジョブ、デーモン・セットなどのワークロードを管理できます。 ポッドとコントローラーの詳細については、 ドキュメント Kubernetes を参照してください。 ポッドのレプリカ・セットを管理するデプロイメントは、アプリの一般的なユース・ケースです。

例えば、kind: Deployment オブジェクトは、アプリ・ポッドをデプロイするための良い選択です。このオブジェクトを使用すると、ポッドの可用性を高めたい場合にレプリカ・セットを指定できるからです。

次の表は、Kubernetes ワークロード・オブジェクトを作成する場合にそのタイプはさまざまである理由を示しています。

アプリ構成で変数を使用するにはどうすればよいですか? これらの変数をYAMLに追加するにはどうすればよいですか？

デプロイに可変情報を追加するには、データを YAML ファイルにハードコーディングする代わりに、 または Secret KubernetesConfigMap オブジェクトを使用できます。

構成マップまたはシークレットを取り込むには、それをポッドにマウントする必要があります。 構成マップまたはシークレットは、ポッドが実行される直前にポッドと結合されます。 デプロイメントの仕様とイメージを多くのアプリで再利用できますが、その後、カスタマイズした構成マップとシークレットをスワップアウトすることもできます。 特にシークレットはローカル・ノード上のストレージを大量に専有する場合があるため、適宜計画してください。

どちらのリソースでもキーと値のペアが定義されますが、状況に応じて使い分けてください。

Configmap

デプロイメントで指定されたワークロードに機密性の高くない構成情報を提供します。 主に 3 つの方法で構成マップを使用できます。

• ファイル・システム: ファイル全体または変数セットをポッドにマウントできます。 値に設定されたファイルのキー名の内容に基づいて、エントリーごとにファイルが作成されます。
• 環境変数: コンテナー仕様の環境変数を動的に設定します。
• コマンドラインオプション: コンテナ仕様で使用されるコマンドラインオプションを設定します。

シークレット

以下のような機密情報をワークロードに提供します。 クラスターの他のユーザーがシークレットに対するアクセス権限を持っている場合があるため、シークレット情報はそれらのユーザーと共有される可能性があることを知っておいてください。

• 個人情報 (PII): E メール・アドレスなどの機密情報や、企業コンプライアンスや政府規制に必要な他のタイプの情報をシークレットに保管します。
• 資格情報: 意図しない情報漏洩のリスクを軽減するために、パスワード、鍵、トークンなどの資格情報をシークレットに入れます。 例えば、クラスターにサービスをバインドすると、シークレットに資格情報が保管されます。

シークレットをさらに保護したいですか? クラスター管理者に連絡してクラスター内の鍵管理サービス・プロバイダーを有効にしてもらい、新しいシークレットと既存のシークレットを暗号化します。

アプリが正しいリソースを持っていることを確認するにはどうすればよいですか？

アプリの設定 YAML ファイルを指定する 際、アプリが正しいリソースを取得するのに役立つ機能性をアプリ構成に Kubernetes 追加できます。 特に、YAMLファイルで定義された各コンテナに対して、 リソース制限と要求を設定してください。

さらに、アプリ・デプロイメントに影響を与える可能性がある以下のようなリソース制御をクラスター管理者がセットアップすることもできます。

• リソースの割り当て量
• ポッドの優先度

どうすればアプリ構成に機能を追加できますか?

デプロイメントに何を含めることができるかについては、YAML ファイルでのアプリ要件の指定を参照してください。 この例には以下のオプションが含まれています。

• レプリカ・セット
• ラベル
• アフィニティー
• イメージ・ポリシー
• ポート
• リソースの要求と制限
• Liveness Probe と Readiness Probe
• アプリサービスをポートで公開する サービス。
• Configmaps を使用して、コンテナー環境変数を設定します。
• シークレット: コンテナー環境変数を設定します。
• コンテナにストレージとしてマウントされる 永続ボリューム。

どうすれば Watson などの IBM サービスをアプリに追加できますか?

アプリへのサービスの追加を参照してください。

アプリの可用性を向上させるにはどうすればよいですか?

アプリの可用性を向上させるには、以下の選択肢を検討してください。

デプロイメントとレプリカ・セットを使用してアプリとその依存項目をデプロイする

デプロイメントとは、アプリのすべてのコンポーネントとその依存項目を宣言するために使用できる Kubernetes リソースのことです。 デプロイメントでは、すべてのステップを書き留める必要はなく、代わりにアプリに集中できます。 複数のポッドをデプロイすると、ポッドをモニターするデプロイメント用にレプリカ・セットが自動的に作成され、指定された数のポッドが稼働中であることが保証されます。 ポッドがダウンすると、応答しなくなったポッドがレプリカ・セットによって新しいポッドに置き換えられます。 デプロイメントを使用して、ローリング更新中に追加するポッドの数や、一度に使用不可にできるポッドの数など、アプリの更新戦略を定義できます。 ローリング更新の実行時には、デプロイメントによって、リビジョンが動作しているかどうかが確認され、障害が検出されるとロールアウトが停止されます。 デプロイでは、異なるオプションを持つ複数のリビジョンを同時にデプロイできます。 例えば、実稼働環境にプッシュする前に、デプロイメントをテストすることができます。 デプロイメントを使用することによって、デプロイしたリビジョンを追跡できます。 更新が期待どおりに機能しない場合に、この履歴を使用して以前のバージョンにロールバックすることができます。

アプリのワークロードに十分なレプリカ数、プラス 2 を組み込む

アプリの可用性と耐障害性を高めるために、予想されるワークロードを処理する最低限の数のレプリカに加えて予備のレプリカを組み込むことを検討してください。 ポッドがクラッシュし、そのポッドがレプリカ・セットによってリカバリーされなかった場合に、予備のレプリカでワークロードを処理できます。 2 つが同時に障害を発生した場合に対応できるようにするには、2 つ余分にレプリカを組み込みます。 この構成は N+2 パターンです。N は着信ワークロードを処理するレプリカの数、+2 は追加の 2 つのインスタンスです。 クラスターに十分なスペースがある限り、必要な数のポッドを作成できます。

複数のノードにポッドを分散させる (アンチアフィニティー)

デプロイメントを作成するときに、各ポッドを同じワーカー・ノードにデプロイすることもできます。 これは親和性、またはコロケーションとして知られています。 ワーカー・ノードの障害からアプリを保護するには、標準クラスターで podAntiAffinity オプションを使用して、複数のワーカー・ノードにポッドを分散させるようにデプロイメントを構成します。 「優先」と「必須」という 2 つのタイプのポッド・アンチアフィニティーを定義できます。 詳細については、 ノードへのポッドの割り当てに関するドキュメント Kubernetes を参照してください。

アプリ・デプロイメント内のアフィニティーの例については、アプリ・デプロイメント YAML ファイルの作成を参照してください。

複数のゾーンまたはリージョンにポッドを分散させる

ゾーン障害からアプリを保護するには、別々のゾーンに複数のクラスターを作成するか、または複数ゾーン・クラスター内のワーカー・プールにゾーンを追加することができます。 マルチゾーン・クラスターは、ダラスなどの特定のクラシック・マルチゾーンまたは VPC マルチゾーンでのみ使用可能です。 複数のクラスターを別々のゾーンに作成する場合は、グローバル・ロード・バランサーをセットアップする必要があります。 レプリカ・セットを使用し、ポッドのアンチアフィニティーを指定すると、Kubernetes はアプリ・ポッドをノード間で分散させます。 複数のゾーンにノードがある場合、ポッドはゾーン間で分散され、アプリの可用性が向上します。 アプリを 1 つのゾーンのみで実行するように制限する場合は、ポッドのアフィニティーを構成するか、または 1 つのゾーン内にワーカー・プールを作成してラベル付けすることができます。

マルチゾーンクラスター環境において、アプリケーションのポッドはノード全体に均等に分散されますか？

ポッドはゾーン間で均等に分散されますが、ノード間では必ずしも均等になるとは限りません。 例えば、3 つの各ゾーンにノードが 1 つずつあるクラスターがある場合、6 つのポッドからなるレプリカ・セットをデプロイすると、ポッドは各ノードに 2 つずつ配分されます。 しかし、3 つの各ゾーンにノードが 2 つずつあるクラスターの場合は、6 つのポッドからなるレプリカ・セットをデプロイすると、各ゾーンに 2 つのポッドがスケジュールされますが、必ずしもノードごとに 1 つのポッドがスケジュールされるとは限りません。 スケジューリングをより細かく制御するには、 ポッドアフィニティを設定できます。

ゾーンがダウンした場合、ポッドは他のゾーンの残存ノードにどのように再スケジューリングされるのか？

それはデプロイメントに使用されているスケジューリング・ポリシーによって異なります。 ノード固有のポッドアフィニティを設定した場合、ポッドは再スケジューリングされません。 そうしていない場合、ポッドは他のゾーンの使用可能なワーカー・ノード上に作成されますが、バランスが取れていない可能性があります。 例えば、2 つのポッドが使用可能な 2 つのノードに分散される場合もあれば、使用可能な容量がある 1 つのノードに両方のポッドがスケジュールされる場合もあります。 同様に、使用不可になっていたゾーンが回復した場合も、ポッドが自動的に削除されて、ノード間でリバランスされるわけではありません。 ゾーンが復旧した後、ポッドをゾーン間で再バランスさせたい場合は、 descheduler Kubernetes を設定してください{: shortdesc}。 マルチゾーンクラスタでは、ワーカーノードの容量をゾーンごとに50%に保つようにしてください。これにより、ゾーン障害からクラスタを保護するのに十分な容量を確保できます。

アプリを複数の地域に展開したい場合はどうすればよいですか？

リージョン障害からアプリを保護するには、別のリージョンに2つ目のクラスターを作成し、 グローバルロードバランサーを設定して クラスターを接続します。さらに、アプリの複製セットを複製し、 ポッドの反親和性設定を適用したデプロイメントYAMLを使用してデプロイします。

アプリが永続的なストレージを必要とする場合はどうすればよいですか？

IBM Cloudant や IBM Cloud Object Storageなどのクラウド・サービスを使用します。

どうすればアプリをスケーリングできますか?

ワークロードの使用状況に応じてアプリを動的に追加/除去するには、アプリのスケーリングを参照して、水平ポッド自動スケーリングを有効にするための手順を確認してください。

どうすれば更新と管理がしやすいようにデプロイメントを編成できますか?

デプロイメントに含めるものを把握したところで、これらすべての異なる YAML ファイルを管理する方法についての疑問が生じるかもしれません。 当然ながら、Kubernetes 環境内でデプロイメントによって作成されるオブジェクトについても同様でしょう。

以下のヒントは、デプロイメント YAML ファイルの編成に役立ちます。

• Git などのバージョン管理システムを使用します。
• 相互に密接に関連する Kubernetes オブジェクトを同じ YAML ファイルにまとめます。 例えば、deployment を作成する場合は、service ファイルもその YAML ファイルに追加するとよいでしょう。 以下の例のように、--- でオブジェクトを区切ってください。

  apiVersion: apps/v1
  kind: Deployment
  metadata:
  ...
  ---
  apiVersion: v1
  kind: Service
  metadata:
  ...
  

• kubectl apply -f コマンドを使用して、単一ファイルだけでなくディレクトリー全体に適用できます。
• Kubernetes リソースの YAML 構成の記述、カスタマイズ、および再利用に役立つよう使用可能な kustomize プロジェクトを試してみます。

YAML ファイル内では、デプロイメントを管理するためのメタデータとしてラベルやアノテーションを使用できます。

ラベル

ラベルは、ポッドやデプロイメントなどのオブジェクト Kubernetes に付与できるペア key:value です。 ラベルには任意の値を使用でき、ラベル情報に基づいてオブジェクトを簡単に選択できます。 ラベルは、オブジェクトをグループ分けするための基盤となります。 以下の例をラベルの参考にしてください。

• app: nginx
• version: v1
• env: dev

アノテーション

注釈はラベルと同様に、ペアである key:value という点で似ています。 アノテーションは、各種のツールやライブラリーで活用できる、非識別情報に適しています。例えば、オブジェクトの取得元に関する追加情報、そのオブジェクトの使用方法、関連する追跡リポジトリーへのポインター、そのオブジェクトに関するポリシーなどを保持します。 アノテーションに基づいてオブジェクトを選択することはありません。

アプリの更新戦略としては、どのようなものを使用できますか?

アプリを更新するには、以下のようなさまざまな戦略から選択できます。 最初はローリング・デプロイメントや即時切り替えから始めて、その後で複雑なカナリア・デプロイメントに進むことができます。

ローリング・デプロイメント

Kubernetes 固有の機能を使用して、v2 デプロイメントを作成したり、以前の v1 デプロイメントを段階的に置き換えたりできます。 このアプローチでは、アプリが以前のバージョンと互換性を持つことが求められます。これにより、提供されたアプリバージョ v2 ンを利用するユーザーが、互換性を損なう変更を経験することがなくなります。 詳しくは、アプリを更新するためのローリング・デプロイメントの管理を参照してください。

即時切り替え

即時切り替え (ブルー/グリーン・デプロイメントとも呼ばれます) では、同じアプリの 2 つのバージョンを同時に実行するために通常の 2 倍のコンピュート・リソースが必要になります。 この手法を使用すると、ほぼリアルタイムでユーザーを新しいバージョンに切り替えることができます。 サービスラベルセレクター（例: version: green および version: blue）を使用し、リクエストが正しいアプリバージョンに送信されることを確認してください。 新しい version: green デプロイメントを作成して、このデプロイメントの準備が完了するまで待ってから、version: blue デプロイメントを削除できます。 あるいは、 ローリング更新を実行できますが、その場合は maxUnavailable パラメーターを 0% に設定して、maxSurge パラメーターを 100% に設定します。

カナリア・デプロイメントまたは A/B デプロイメント

さらに複雑な更新戦略であるカナリア・デプロイメントでは、指定した比率 (5% など) のユーザーのみが新しいアプリ・バージョンを利用できるようにします。 新しいアプリ・バージョンのパフォーマンスに関するメトリックをロギング・ツールとモニタリング・ツールで収集し、A/B テストを実行してから、より多くのユーザーに更新をロールアウトします。 他のデプロイメント方式と同様に、アプリにラベル (version: stable や version: canary など) を割り当てることが非常に重要です。 カナリアデプロイメント を 管理するには、マネージドIstioアドオンサービスメッシュをインストールし、 クラスター用に Monitoring 設定 した後、 このブログ記事で説明されているようにIstioサービスメッシュをA/Bテストに使用できます。

どうすればアプリのデプロイメントを自動化できますか?

複数のクラスター、パブリック環境とプライベート環境、または複数のクラウド・プロバイダーでアプリを実行する場合は、これらの環境を横断してデプロイメント戦略をどのように成功させるかが課題となります。 IBM Cloud および他のオープン・ソース・ツールを使用すると、アプリケーションをパッケージ化してデプロイメントの自動化に役立てることができます。

継続的な統合とデリバリー (CI/CD) パイプラインのセットアップ

アプリの構成ファイルが Git などのソース制御管理システムで編成されている場合は、パイプラインを構築することで、コードをテストして、test や prod などの別々の環境にデプロイできます。 クラスター管理者と協力して継続的統合/継続的デリバリーをセットアップします。

アプリ構成ファイルのパッケージ化

Kustomize や Helm などのツールを使用してアプリをパッケージ化します。

• kustomize プロジェクトを使用して、Kubernetes リソースの YAML 構成の記述、カスタマイズ、再利用を行うことができます。
• パッケージ HelmKubernetes マネージャーを使用すると、アプリに必要なすべての Kubernetes リソースをチャート Helm で指定できます。 次に、Helm を使用して YAML 構成ファイルを作成して、これらのファイルをクラスターにデプロイできます。 また、ブロックストレージプラグインなど、 提供されている Helm チャートを IBM Cloud 統合することでクラスターの機能を拡張できます。

YAML ファイル・テンプレートを作成しようとしていますか? 一部の人々はまさにその Helm ためにを使用したり、あるいはなどの他のコミュニティツールを試 yttしてみることもできます。

自分のサービスが正しいデプロイメントに接続され、すぐに利用可能な状態であることを確認するにはどうすればよいですか？

ほとんどのサービスについては、そのサービスの .yaml ファイルにセレクターを追加することで、そのラベルによってアプリを実行するポッドにそのセレクターが適用されるようにします。 アプリが最初に起動したとき、多くの場合、すぐにリクエストを処理したくないでしょう。 デプロイメントに Readiness Probe を追加することで、準備ができていると見なされるポッドのみにトラフィックが送信されるようにします。 ラベルを使用し、レディネスプローブを設定するサービスのデプロイ例については、 こちらのNGINX YAMLを参照してください。

場合によっては、サービスでラベルを使用することが望ましくないことがあります。 例えば、外部データベースを使用している場合や、そのサービスでクラスター内の異なる名前空間内の別のサービスを参照することを希望する場合があります。 このような場合は、エンドポイント・オブジェクトを手動で追加して、このオブジェクトをそのサービスにリンクする必要があります。

どうすればサービスをインターネットで公開できますか?

NodePort、LoadBalancer、および Ingress という 3 タイプのサービスを外部ネットワーキング用に作成できます。

クラスター・タイプに依存するいくつかのオプションがあります。 詳しくは、ネットワーク・サービスの計画を参照してください。

• 標準クラスター: NodePort サービス、ロード・バランサー・サービス、または Ingress サービスを使用することによって、アプリを公開できます。
• Calico を使用してプライベートになったクラスター: NodePort サービス、ロード・バランサー・サービス、または Ingressサービスを使用することによって、アプリを公開できます。 同時に、パブリック・ノード・ポートをブロックするために、Calico preDNAT ネットワーク・ポリシーを使用する必要もあります。
• プライベート VLAN 専用標準クラスター: NodePort サービス、ロード・バランサー・サービス、または Ingress サービス を使用することによって、アプリを公開できます。 同時に、ファイアウォールで、サービスのプライベート IP アドレス用のポートを開く必要もあります。

クラスター内で必要な Service オブジェクトの数を計画する際は、Kubernetes では iptables を使用してネットワーキングとポート転送の規則が処理されることに留意してください。 いくつもの (例えば 5000) サービスをクラスターで実行すると、パフォーマンスに影響する可能性があります。

どうすればアプリ・デプロイメントにアクセスできるユーザーを制御できますか?

アカウント管理者とクラスター管理者は、さまざまなレベル (クラスター、Kubernetes 名前空間、ポッド、コンテナー) でアクセス権限を制御できます。

IBM Cloud IAM を使用すれば、個々のユーザー、グループ、またはサービス・アカウントに、クラスター・インスタンス・レベルで許可を割り当てることができます。 クラスター内の特定の名前空間にユーザーを制限することによって、クラスター・アクセス権限の適用範囲をさらに絞り込むことができます。 詳しくは、クラスター・アクセス権限の割り当てを参照してください。

ポッドレベルでのアクセス制御を行うには、ポッドセキュリティポリシー（PSP）を設定できます。

アプリ・デプロイメント YAML 内に、ポッドまたはコンテナーのセキュリティー・コンテキストを設定できます。 詳細については、 ドキュメント Kubernetes を参照してください。

アプリをデプロイした後、どうすればその正常性をモニターできますか?

クラスターの IBM Cloud ロギングおよびモニタリングをセットアップできます。 サード・パーティーのロギング・サービスまたはモニタリング・サービスと統合することを選択することもできます。