IBM Cloud Internet Services による耐障害性のあるセキュアなマルチ・リージョン Kubernetes クラスター
このチュートリアルでは、費用が発生する場合があります。 コスト見積もりツールを使用して、予測使用量に基づいてコスト見積もりを生成します。
耐障害性を考慮してアプリケーションを設計すると、ユーザーがダウン時間を経験する可能性が低くなります。 Kubernetes Service を使用してソリューションを実装する場合、ロード・バランシングや負荷の分離などの組み込み機能により、ホスト、ネットワーク、アプリで想定される障害に対する耐障害性を強化できるという利点が得られます。 多くのクラスタを作成し、1つのクラスタで障害が発生しても、ユーザーは別のクラスタにもデプロイされているアプリにアクセスできる。 さまざまな場所に多くのクラスタがあるため、ユーザーは最も近いクラスタにアクセスし、ネットワークの待ち時間を短縮することもできる。 さらに弾力性を高めるために、マルチゾーン・クラスターを選択するオプションもあります。これは、ノードを1つのロケーション内の複数のゾーンに分散配置することを意味します。
このチュートリアルでは、ドメイン・ネーム・システム(DNS)、グローバル・ロード・バランシング(GLB)、ウェブ・アプリケーション・ファイアウォール(WAF)、インターネット・アプリケーションの分散型サービス拒否( DDoS )に対する保護を設定および管理するための統一プラットフォームである Cloud Internet Services (CIS) を Kubernetes クラスタと統合して、このシナリオをサポートし、安全で回復力のあるソリューションを多くの場所に提供する方法を紹介します。
目標
- 異なる場所にある多数の Kubernetes クラスターにアプリケーションをデプロイする。
- グローバルロードバランサーで多くのクラスタにトラフィックを分散する。
- ユーザーを一番近いクラスターに転送する。
- アプリケーションをセキュリティー上の脅威から保護する。
- キャッシュを使用してアプリケーションのパフォーマンスを向上させる。
{: caption="図
- 開発者はアプリケーション用に Docker イメージを構築する。
- 画像は Container Registry にプッシュされる。
- アプリケーションは、ダラスとロンドンの Kubernetes クラスターにデプロイされます。
- エンド・ユーザーがアプリケーションにアクセスします。
- IBM Cloud Internet Services は、アプリケーションへの要求を代行受信して、負荷を複数のクラスター間に分散させるように構成します。 さらに、アプリケーションを一般的な脅威から保護するために、DDoS 対策および Web アプリケーション・ファイアウォールを有効にします。 オプションで、画像や CSS ファイルなどの資産をキャッシュに入れます。
開始前に
このチュートリアルでは、以下が必要です。
- IBM Cloud CLI
- IBM Cloud Kubernetes Service プラグイン (
kubernetes-service
)
- IBM Cloud Kubernetes Service プラグイン (
kubectl
: Kubernetes クラスターと対話します。
ソリューション・チュートリアルを始める ためのガイドに、お使いのオペレーティング環境にこれらのツールをダウンロードしてインストールする手順が記載されています。
さらに、以下を実行します。
- カスタム・ドメインを所有し、このドメインが IBM Cloud Internet Services のネーム・サーバーを指すように DNS を構成する。
- Kubernetesの基本を理解します。
1 つのロケーションにアプリケーションをデプロイする
このチュートリアルでは、 Kubernetes アプリケーションを多くの場所にあるクラスタにデプロイする。 1 つのロケーション、ダラスから開始して、次の手順をロンドンについても繰り返します。
Kubernetes クラスターを作成する
このチュートリアルでは、ゾーン1つ、ワーカーノード1つの最小クラスタで十分です。
以下の Kubernetes クラスターを作成する場合:
-
「クラスター名」 を my-us-cluster に設定します。
-
場所は 「北アメリカ」 の 「ダラス」 に設定します。
-
Kubernetes クラスターを 開き、 クラスターの作成をクリックします。
-
選択した 「インフラストラクチャー」 にクラスターを作成します。
-
VPC インフラストラクチャー上の Kubernetes に VPC を選択する場合は、以下の手順を実行します。 Kubernetes クラスターを作成する前に、VPC とサブネットを作成する必要があります。 詳しくは、 VPC クラスターの作成 の資料を参照してください。
- 「VPC の作成」 をクリックします。
- 「ロケーション」 セクションで、 「地域」 と 「地域」 を選択します (例えば、
North America
とDallas
)。 - VPCの名前を入力し、 リソースグループを選択し、オプションでタグを追加してリソースを整理します。
- デフォルトのセキュリティー・グループ の 「SSH を許可」 と 「ping を許可」 のチェック・マークを外します。
- すべてのゾーンにサブネットを作成する 」のチェックを外す。
- 「作成」 をクリックします。
- 「ワーカー・ゾーンとサブネット (Worker zones and subnets)」 の下で、サブネットが作成されなかった 2 つのゾーンのチェック・マークを外します。
- Worker nodes per zone を
1
に設定し、Change flavor をクリックして、お好みのワーカーノードフレーバーに変更します。 - 「Ingress」 で、 「Ingress シークレット管理 (Ingress secrets management)」 を有効にし、既存の Secrets Manager インスタンスを選択します。
- クラスター名 を入力し、VPC に使用したのと同じ リソース・グループ を選択します。
- このチュートリアルでは、ロギングまたはモニタリングは必要ありません。これらのオプションを無効にして、 「作成」 をクリックします。
- クラスターがアクティブになるのを待っている間に、VPC にパブリック・ゲートウェイを接続します。 仮想プライベート・クラウド にナビゲートします。
- クラスターで使用されている VPC の名前をクリックし、「サブネット」セクションまでスクロールダウンします。
- 前に作成したサブネットの名前をクリックし、 Public Gateway セクションで 「切り離し済み」 をクリックして、状態を 「接続済み」 に変更します。
-
以下のステップは、クラシック・インフラストラクチャー上の Kubernetes に対して 「クラシック」 を選択した場合です。 詳しくは、 標準クラシック・クラスターの作成 の資料を参照してください。
- 「ロケーション」 セクションで、 「地域」、複数ゾーンの 「可用性」、および メトロ (
North America
やDallas
など) を選択します。 - 「ワーカー・ゾーンと VLAN」 の下で、1 つを除くすべてのゾーンのチェック・マークを外します。
- Worker nodes per zone を
1
に設定し、Change flavor をクリックして、お好みのワーカーノードフレーバーに変更します。 - 「マスター・サービス・エンドポイント」 の下で、 「両方ともプライベート & パブリック・エンドポイント」 を選択します。
- 「Ingress」 で、 「Ingress シークレット管理 (Ingress secrets management)」 を有効にし、既存の Secrets Manager インスタンスを選択します。
- クラスター名 を入力し、これらのリソースを作成する リソース・グループ を選択します。
- このチュートリアルでは、ロギングまたはモニタリングは必要ありません。これらのオプションを無効にして、 「作成」 をクリックします。
- 「ロケーション」 セクションで、 「地域」、複数ゾーンの 「可用性」、および メトロ (
-
クラスターが準備中の間に、アプリケーションを準備します。
Kubernetes クラスターにアプリケーションをデプロイする
クラスターの準備が完了していなければなりません。 Kubernetes Service コンソールでその状況を確認できます。
-
クラスターの「アクセス」タブの説明に従って、クラスターにアクセスできるようにします。 例えば、次のようなものです。
MYCLUSTER=my-us-cluster ibmcloud ks cluster config --cluster $MYCLUSTER
-
アプリケーションの事前作成イメージを使用してデプロイメントを作成します。 アプリケーション・ソース・コードは、この GitHub リポジトリーにあります。
kubectl create deploy hello-world-deployment --image=icr.io/solution-tutorials/tutorial-scalable-webapp-kubernetes
出力例:
deployment "hello-world-deployment" created
。 -
サービスを作成して、クラスター内でアプリケーションをアクセス可能にします。
kubectl expose deployment/hello-world-deployment --type=ClusterIP --port=80 --name=hello-world-service --target-port=3000
service "hello-world-service" exposed
のようなメッセージが返されます。 サービスを表示するには、次のようにします。kubectl get services
-
2 つのレプリカを使用してクラスターでアプリケーションを実行します。
kubectl scale deployment hello-world-deployment --replicas=2
-
次のコマンドを使用して、デプロイメントの状況を確認できます。
kubectl get pods
クラスターに割り当てられた Ingress サブドメインを取得する
Kubernetes クラスタが作成されると、Ingress サブドメイン (例えば、 my-us-cluster.us-south.containers.appdomain.cloud )とアプリケーションロードバランサのパブリックIPアドレスが割り当てられます。
- クラスターの Ingress サブドメインを取得します。
ibmcloud ks cluster get --cluster $MYCLUSTER
Ingress Subdomain
の値を見つけます。 - 後の手順で使用するために、この情報をメモします。
このチュートリアルでは、Ingress サブドメインを使用してグローバル・ロード・バランサーを構成します。 Ingress サブドメインを、クラスターのパブリック・アプリケーション・ロード・バランサー (ALB) に置き換えることもできます。 <IngressSubdomain>
は次のようになる。 my-us-cluster-e7f2ca73139645ddf61a8702003a483a-0000.us-south.containers.appdomain.cloud
独自の DNS サブドメイン用の Ingress を構成する
独自のDNSドメイン名を持つことが必要になり、グローバルロードバランサーのサブドメインが次のタスクで作成されます: <glb_name>.<your_domain_name>
。 hello-world-service.example.com <glb_name> = hello-world-service
および <your_domain_name> = example.com
など
- ファイル glb-ingress.yaml を作成し、プレースホルダーをそれぞれの値に置き換えます。
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: <glb-name> annotations: spec.ingressClassName: "public-iks-k8s-nginx" spec: rules: - host: <glb-name>.<your_domain_name> http: paths: - path: / pathType: Prefix backend: service: name: hello-world-service port: number: 80
- Ingress インスタンスを追加します。
Ingress が使用可能になったことがコマンドの ADDRESS 列の値に示されるまでに数分かかることがあります。kubectl apply -f glb-ingress.yaml
kubectl get ingress
- 次に、DNS サブドメイン名を使用して curl の ホスト HTTP ヘッダーを構成してテストし、デフォルトの
<IngressSubdomain>
をオーバーライドします。
curlコマンドは次のようになる:curl --header 'Host: <glb_name>.<your_domain_name>' <IngressSubdomain>/hostname
curl --header 'Host: hello-world-service.ibmom.com' my-us-cluster-e7f2ca73139645ddf61a8702003a483a-0000.us-south.containers.appdomain.cloud/hostname
次は別のロケーションで
以下の置き換えを使用して、ロンドン・ロケーションに対して上記のステップを繰り返します。
- Kubernetes クラスターの作成で、以下の置き換えを行います。
- クラスター名 my-us-cluster を my-uk-cluster に置き換える。
- 北アメリカ および ダラス からのロケーション ( ヨーロッパ および ロンドンを含む)。
- Kubernetes クラスターにアプリケーションをデプロイするで、以下の置き換えを行います。
- MYCLUSTER= my-us-cluster を my-uk-cluster に置き換えます。
- DNS サブドメイン用の Ingress を構成します
複数のロケーションのロード・バランシングを構成する
これでアプリケーションが 2 つのクラスターで実行されるようになりましたが、ユーザーが単一のエントリー・ポイントからいずれかのクラスターに透過的にアクセスできるようにする、あるコンポーネントが欠落しています。
このセクションでは、 IBM Cloud Internet Services ( CIS ) を設定して、2つのクラスタ間で負荷を分散させます。 CIS は、 グローバル・ロード・バランサー (GLB)、 キャッシング、 ウェブ・アプリケーション・ファイアウォール (WAF)、 ページ・ルールを提供するワンストップ・ショッピング・サービスで、クラウド・アプリケーションの信頼性とパフォーマンスを確保しながら、アプリケーションを保護します。
グローバル・ロード・バランサーを構成するには、以下を行う必要があります。
- カスタム・ドメインに CIS ネーム・サーバーを参照させる
- Kubernetes クラスターの Ingress サブドメインを取得する
- アプリケーションの使用可否を検証するヘルス・チェックを構成する
- クラスターを指定したオリジン・プールを定義する
IBM Cloud Internet Services にカスタム・ドメインを登録する
最初の手順は、CIS のインスタンスを作成し、カスタム・ドメインに CIS ネーム・サーバーを参照させることです。
-
ドメインを所有していない場合は、レジストラから購入することができます。
-
IBM Cloud カタログ内の IBM Cloud Internet Services にナビゲートします。
-
プランを選択し、サービス名とリソース・グループを設定し、 「作成」 をクリックしてサービスのインスタンスを作成します。
-
サービス・インスタンスがプロビジョンされたら、「ドメインの追加」 をクリックします。
-
ドメイン名を入力し、「次へ」 をクリックします。
-
DNS レコードのセットアップはオプションのステップであり、このチュートリアルではスキップできます。「次へ」 をクリックします。
-
ネーム・サーバーが割り当てられたら、そのリストされたネーム・サーバーを使用するようにレジストラーまたはドメイン・ネーム・プロバイダーを構成します。
-
この時点で、「取り消し」 をクリックしてメインページに戻ることができます。レジストラーまたは DNS プロバイダーを構成してから、その変更が反映されるまでに最大で 24 時間かかる場合があります。
「概要」ページのドメインの状況が*「保留中」から「アクティブ」*に変わったら、
dig <your_domain_name> ns
コマンドを使用して、新しいネーム・サーバーが有効になったことを確認できます。
グローバル・ロード・バランサーのヘルス・チェックを構成する
ヘルス・チェックでは、設定した間隔で HTTP/HTTPS 要求に対するオリジン・プールからの応答をモニターします。 これらをオリジン・プールで使用することで、プールが正常に実行されているかどうかを判別できます。
-
IBM Cloud Internet Services ダッシュボードで、ナビゲーションメニューを使用して [信頼性 ]>[ グローバルロードバランサー]を選択します。
-
「ヘルス・チェック」 タブを選択し、「作成」 をクリックします。
- 「名前」 を 「hello-world-service」 に設定します。
- 「モニター・タイプ」 を 「HTTP」 に設定します。
- 「ポート」 を 「80」 に設定します。
- 「パス」 を 「/」 に設定します。
- 「要求ヘッダーの構成 (オプション)」 で、ヘッダー名
Host
と値<glb_name>.<your_domain_name>
を追加します。 - 「作成」 をクリックします。
独自のアプリケーションを構築するときに、アプリケーション状態を報告する /heathz などの専用ヘルス・エンドポイントを定義できます。
オリジン・プールを定義する
プールとは、GLB に接続するとトラフィックがインテリジェントに転送されるオリジン・サーバーのグループのことです。 英国と米国にクラスターがあるので、ロケーション・ベースのプールを定義し、ユーザー要求の地理的位置に基づいて一番近いクラスターにユーザーをリダイレクトするように CIS を構成できます。
ダラスのクラスター用のプール
- 「オリジン・プール (Origin pools)」 タブを選択し、「作成」 をクリックします。
- 名前を
US
に設定する。 - 「起点名」 を
us-cluster
に設定します。 - 「起点アドレス (Origin Address)」 を、米国クラスターの
ibmcloud ks cluster get --cluster $MYCLUSTER
によって印刷された kubernetes サービス<IngressSubdomain>
に設定します。 - ヘルスチェックを前のセクションで作成したものに設定する。
- ヘルスチェックの地域を
Western North America
に設定する。 - 保存 をクリックします。
ロンドンのクラスター用のプール
- 「オリジン・プール (Origin pools)」 タブを選択し、「作成」 をクリックします。
- 名前を
UK
に設定する。 - 「起点名」 を
uk-cluster
に設定します。 - 「起点アドレス (Origin Address)」 を、英国クラスターの
ibmcloud ks cluster get --cluster $MYCLUSTER
によって印刷された kubernetes サービス<IngressSubdomain>
に設定します。 - ヘルスチェックを前のセクションで作成したものに設定する。
- ヘルスチェックの地域を
Western Europe
に設定する。 - 保存 をクリックします。
グローバル・ロード・バランサーを作成する
オリジン・プールを定義したら、ロード・バランサーの構成を実行できます。
-
「ロード・バランサー」 タブを選択し、「作成」 をクリックします。
-
「名前」 の下に、グローバル・ロード・バランサーの名前
<glb_name>
を入力します。 この名前は、ロケーションに関係なく、ユニバーサル・アプリケーション URL (http://<glb_name>.<your_domain_name>
) の一部にもなります。 -
Geo routes の下にある Add route をクリックします。
- Regionのドロップダウンから Defaultを選択する。
- プール USを選択する。
- 追加 をクリックします。
この処理を繰り返して、以下を作成します。
作成する地理的経路のリスト リージョン 起点プール デフォルト 米国 西ヨーロッパ 英国 東ヨーロッパ 英国 北東アジア 英国 東南アジア 英国 北アメリカ西部 米国 北アメリカ東部 米国 この構成により、ヨーロッパとアジアのユーザーはロンドンのクラスターにリダイレクトされ、米国のユーザーはダラスのクラスターにリダイレクトされます。 リクエストが定義されたどのルートにもマッチしないとき、それは Default リージョンのプールにリダイレクトされる。
-
作成 をクリックします。
この段階で、あなたは多くの場所にまたがる Kubernetes クラスタを持つ Global Load Balancer の設定に成功しました。 GLB の URL http://<glb_name>.<your_domain_name>/hostname
にアクセスして、アプリケーションを表示できます。 ユーザーの場所に応じて一番近いクラスターにリダイレクトされます。CIS がユーザーの IP アドレスを特定の場所にマップできない場合には、デフォルト・プールにリダイレクトされます。
アプリケーションを保護する
Web アプリケーション・ファイアウォールをオンにする
Web アプリケーション・ファイアウォール (WAF) は、Web アプリケーションを ISO レイヤー 7 攻撃から保護します。 これは通常、グループ化されたルール・セットと組み合わされます。これらのルール・セットは、不正なトラフィックを除外してアプリケーションの脆弱性を保護するためのものです。
- IBM Cloud Internet Services ダッシュボードで、「セキュリティー」 、「WAF」 の順に移動します。
- WAF が 「オン」 であることを確認します。
- 「OWASP ルール・セット」 をクリックします。 このページで、「OWASP コア・ルール・セット」 を確認し、ルールを個別に有効/無効にすることができます。 ルールを有効にすると、着信要求でルールがトリガーされた場合に、グローバルな脅威のスコアが高くなります。 要求に対して 「アクション」 がトリガーされるかどうかは、「機密度」 設定によって決まります。
- デフォルトの OWASP ルール・セットはそのままにしておきます。
- 「機密度」 を
Low
に設定します。 - 「アクション」 を
Simulate
に設定して、すべてのイベントをログに記録します。
- 「CIS ルール・セット」 をクリックします。 このページには、Web サイトをホストするための一般的な技術スタックに基づいて構築された追加のルールが表示されます。
HTTPS、 Let's Encryptから証明書を取得するか、または以下の方法でセキュアな接続を行うことができます。 IBM Cloud Secrets Manager.
パフォーマンスの向上およびサービス拒否攻撃への防御を強化する
分散型サービス妨害 (DDoS) 攻撃とは、ターゲットやその周辺のインフラストラクチャーに大量のインターネット・トラフィックを送り付けて圧倒し、サーバー、サービス、またはネットワークの通常のトラフィックを中断させようとする悪意のある行為です。CIS は、ドメインを DDoS から保護する機能を備えています。
-
CIS ダッシュボードで、「信頼性」 > 「グローバル・ロード・バランサー」 を選択します。
-
作成した GLB を 「ロード・バランサー」 テーブルで見つけます。
-
「プロキシー」 列でセキュリティーとパフォーマンスの機能を有効にします。
CIS プロキシー・トグルがオン
これで GLB が保護されるようになりました。 。 すぐに享受できるメリットとして、クラスターのオリジン IP アドレスがクライアントに表示されなくなります。 着信要求に脅威があることを CIS が検出すると、一般には、アプリケーションにリダイレクトされる前に、ユーザーに次のような画面が表示されます。

さらに、CIS でキャッシュに入れるコンテンツと、キャッシュに入れておく期間も制御できるようになりました。 「パフォーマンス」 > 「キャッシュ」 に移動して、グローバル・キャッシュ・レベルおよびブラウザー有効期限を定義してください。 「ページ・ルール」 によって、グローバルなセキュリティーおよびキャッシュのルールをカスタマイズできます。 ページ・ルールにより、特定のドメイン・パスを使用した、きめの細かい構成が可能になります。 ページ・ルールを使用する例として、/assets の下のすべてのコンテンツをキャッシュに 3 日間 入れるように指定できます。

リソースを削除する
Kubernetes クラスター・リソースの削除
- Ingress を削除します。これを行うには、以下のコマンドを実行します。
kubectl delete -f glb-ingress.yaml
- サービスを削除します。これを行うには、以下のコマンドを実行します。
kubectl delete service hello-world-service
- デプロイメントを削除します。削除するには、以下のコマンドを実行します。
kubectl delete deployment hello-world-deployment
- このチュートリアル用に特別にクラスターを作成した場合は、そのクラスターを削除します。
CIS リソースの削除
- GLB を削除します。
- 起点プールを削除します。
- ヘルス・チェックを削除します。
- カスタム・ドメインの DNS を更新します。
- このチュートリアル専用に作成した場合は、 CIS インスタンスを削除します。