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

ステートレス・アプリ

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

ステートフル・アプリ

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

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

「 12ファクター・アプリ 」をご覧ください。これは、12の要素に基づいてアプリの開発方法を検討するための、言語に依存しない方法論であり、その概要は以下の通りです。

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

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

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

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

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

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

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

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

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

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

ポッドに格納するもの

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

じゃあ、podを使えるなら、なんでこんなにたくさんの種類のオブジェクトが必要なんですか？

ポッドの 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 ファイルにデータをハードコーディングする代わりに、デプロイに可変情報を追加するには、 Kubernetes を使用できます ConfigMap または Secret オブジェクトを使用できます。

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

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

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 つのポッドがスケジュールされるとは限りません。 スケジューリングをより細かく制御するには、 Podのアフィニティを設定することができます。

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

それはデプロイメントに使用されているスケジューリング・ポリシーによって異なります。 ノード固有のポッドアフィニティを指定した場合、ポッドは再スケジューリングされません。 そうしていない場合、ポッドは他のゾーンの使用可能なワーカー・ノード上に作成されますが、バランスが取れていない可能性があります。 例えば、2 つのポッドが使用可能な 2 つのノードに分散される場合もあれば、使用可能な容量がある 1 つのノードに両方のポッドがスケジュールされる場合もあります。 同様に、使用不可になっていたゾーンが回復した場合も、ポッドが自動的に削除されて、ノード間でリバランスされるわけではありません。 ゾーンが復旧した後、ゾーン間でポッドの再バランス調整を行いたい場合は、 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 コマンドを使用して、単一ファイルだけでなくディレクトリー全体に適用できます。

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

ラベル

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

• 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 を設定した上で、 このブログ記事で説明されているように、A/Bテストに Istio サービスメッシュを使用するとよいでしょう。

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

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

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

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

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

この HelmKubernetes パッケージマネージャーを使用すると、アプリに必要なすべての Kubernetes リソースを Helm チャートで指定できます。 次に、Helm を使用して YAML 構成ファイルを作成して、これらのファイルをクラスターにデプロイできます。 また、 IBM Cloud が提供する Helm のチャートを取り入れることで、ブロックストレージプラグインなどを活用し、クラスタの機能を拡張することも可能です。

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 ロギングおよびモニタリングをセットアップできます。 サード・パーティーのロギング・サービスまたはモニタリング・サービスと統合することを選択することもできます。