アリババのテクニカルエキスパートであるWang Bingshenが、Kubernetesとクラウドネイティブなシナリオを用いたサービスディスカバリーとロードバランシングの目的と実装について説明します。
著者：アリババのテクニカルエキスパート、Wang Bingshen（Xiheng）氏
1. 必要条件のソース
サービスディスカバリーの目的
Kubernetesクラスタ内のアプリケーションは、Podを使用してデプロイされますが、これは特定のマシンにアプリケーションをデプロイする従来のアプローチとは異なります。我々は、他のマシンのIPアドレスを呼び出す方法を知っていますが、Podのライフサイクルは短いです。PodのIPアドレスは、Podが作成されたり破棄されたりするなど、そのライフサイクルの中で変化します。このため、従来の方法では、指定したIPアドレスを介したアプリケーションのアクセスができず、Kubernetesクラスターにアプリケーションを展開することができません。
Kubernetesクラスターにアプリケーションをデプロイするには、デプロイメントに加えてPodのグループを作成し、Podのセントラルエンドポイントを提供し、Pod間のトラフィックロードバランシングを実装する必要があります。また、アプリケーションをデプロイする際には、テスト環境、ステージング環境、本番環境で同じデプロイメントテンプレートとアクセスモードを維持する必要があります。こうすることで、同じテンプレートを使って異なる環境にアプリケーションを直接公開することができます。
Kubernetesのサービス:サービスディスカバリーとロードバランシング
アプリケーションは、外部のユーザーが呼び出せるように公開する必要があります。Podは、マシンとは異なるネットワークセグメントにあります。Podのネットワークを外部からアクセスできるように公開するには、サービスディスカバリーを設定する必要があります。
Kubernetesでは、サービスディスカバリーとロードバランシングがサービスとして提供されています。前述の図は、Kubernetes Serviceのアーキテクチャを示しており、アップリンク方向に外部ネットワークとPodネットワークへのアクセスを提供します。
Kubernetes Serviceは、ダウンリンク方向でPodのグループと相互に連携し、Pod間のロードバランシングを実施します。これにより、サービスディスカバリーのための中央エンドポイントが提供され、外部ネットワークへのアクセスと、同一アドレスを介した異なるPod間のアクセスが可能になります。
2. ケーススタディ
実際のユースケースとして、KubernetesにおけるPod用のServiceの宣言と使用方法を紹介します。
サービス構文
まず、Kubernetes Serviceの構文を見てみましょう。前述の図は、Kubernetesの宣言構造を示しています。この構造には多くの構文が含まれており、それらは先に説明したいくつかの標準的なKubernetesオブジェクトと似ています。例えば、labelsとselectorフィールドを使用して選択を行い、labelsフィールドを使用して宣言を行うことができます。
このテンプレートでは、サービス発見に使用するKubernetes Serviceのプロトコルとポートを定義します。テンプレートでは、app:my-serviceラベルを持つ、my-serviceという名前のKubernetes Serviceを宣言しています。このサービスは、app:MyAppラベルを持つPodをバックエンドとして選択します。
サービスの検出には、TCPとポート80が定義されています。ターゲットポートは9376です。ポート80へのアクセス要求は、バックエンドにapp:MyAppラベルを持つPodのポート9376にルーティングされます。これにより、ロードバランシングが実装されます。
サービスの作成と表示
ここでは、先ほど宣言したServiceの作成と、作成したServiceの表示について説明します。以下のコマンドを実行します。
-
kubectl apply -f service.yaml
あるいは -
kubectl created -f service.yaml
以上のコマンドでServiceを作成します。Serviceが作成されたら、以下のコマンドを実行します。 -
kubectl describe service
これにより、作成されたServiceを確認することができます。
作成されたServiceの名前はmy-serviceです。「Namespace」、「Labels」、「Selector」の各フィールドは、先の宣言のフィールドと同じです。サービス用にIPアドレスが作成され、クラスター内のPodからアクセスできるようになります。このIPアドレスは、すべてのPodのセントラルエンドポイントであり、サービスディスカバリーで使用されます。
「Endpoints」フィールドには、「selector」フィールドで指定されたPodが表示されます。Podのステータスを表示することができます。たとえば、選択したPodのIPアドレスとターゲットポートを表示できます。
前述の図は、そのアーキテクチャを示しています。クラスタ内のサービスとともに、仮想IPアドレスとポートが作成されます。クラスタ内のすべてのPodとノードは、このIPアドレスとポートを介してサービスにアクセスできます。サービスは、選択したPodとそのIPアドレスをバックエンドにマウントします。このようにして、ServiceのIPアドレスを介したアクセス要求がこれらのPodに分散され、負荷分散が行われます。
Podのライフサイクルが変化したとき、たとえばPodが破壊されたとき、サービスは自動的にPodをバックエンドから削除します。これにより、Podのライフサイクルが変更されても、エンドポイントは変更されません。
クラスタ内のサービスアクセス
クラスター内でサービスを作成した後、クラスター内のPodは以下のいずれかの方法でサービスにアクセスできます。
-
Podは、その仮想IPアドレスを介してサービスにアクセスできます。先に作成した
my-serviceという名前のServiceの場合、kubectl get svcまたはkubectl describe serviceコマンドを実行すると、Serviceの仮想IPアドレス172.29.3.27とポート80が表示され、PodがServiceにアクセスするために直接使用することができます。 -
サービスと同じ名前空間にあるPodは、DNSで名前が解決された後、その名前を通してサービスにアクセスできます。本サービスと異なる名前空間にあるPodは、
service_name.service_namespaceの形式で本サービスにアクセスできます。例えば、curlを使って、my-service:80という形式でServiceにアクセスすることができます。 -
サービスと同じ名前空間にあるPodは、起動時にサービスのIPアドレス、ポート、簡単な設定をPodに転送するための環境変数を介して、サービスにアクセスすることができます。Podのコンテナが起動すると、環境変数を読み込んで、同じ名前空間にあるサービスのIPアドレスとポートを取得します。例えば、クラスタ内のPodは、curl
$を使って環境変数の値を取得することができます。MY_SERVICE_HOSTはサービスのIPアドレス、MY_SERVICEは宣言されたサービス名、SERVICE_PORTはサービスのポートを示しています。これにより、Podはクラスタ内のMY_SERVICEで示されるServiceにリクエストを送信することができます。
ヘッドレスサービス
ヘッドレスサービスは、特別なタイプのサービスです。サービスを作成する際にclusterIP:Noneを指定することで、KubernetesにクラスタIPアドレス、つまり前述の仮想IPアドレスが不要であることを伝えることができます。そうすると、KubernetesはこのServiceに仮想IPアドレスを割り当てません。仮想IPアドレスがなくても、Serviceは以下のようにロードバランシングを実装し、中央のエンドポイントを提供することができる。
Podは、DNSのAレコードを介してService名をバックエンドの全PodのIPアドレスに直接解決することができる。クライアントは、解決されたバックエンドのIPアドレスのいずれかを選択できる。AレコードはPodのライフサイクルの変更に伴い変更され、返されるAレコードのリストも変更されます。クライアントは、Podにアクセスするために、DNSで返されたAレコードのリストから適切なIPアドレスを選択する必要があります。
先に宣言したテンプレートと比較して、前図のテンプレートではclusterIP:Noneが追加されており、仮想IPアドレスが不要であることを示しています。クラスタ内のPodがmy-serviceにアクセスすると、サービス名を直接解決して、ServiceにマッチするすべてのPodのIPアドレスを取得します。その後、Podは返されたリストからIPアドレスを選択し、サービスに直接アクセスします。
サービスをクラスタ外に公開
前節では、クラスター内のノードやPodからサービスにアクセスする方法を紹介しました。本節では、クラスター外でサービスを公開し、インターネットからのアクセスのためにアプリケーションを公開する方法を説明します。NodePortやLoadBalancerを使ってサービスを外部に公開することができます。
-
NodePortモードでは、クラスタ内のノードのポートがノードホスト上で公開されます。ノードポートモードでは、クラスタ内のノードのポートがノードホスト上で公開され、アクセスリクエストを受信すると、公開されたポートはホスト上に設定されたサービスの仮想IPアドレスにリクエストを転送します。 -
LoadBalancerモードでは、フォワーディングレイヤーが追加されます。NodePortはクラスタ内のすべてのノードのポートに実装されますが、LoadBalancerはすべてのノードにロードバランサーをマウントします。たとえば、Alibaba Cloud Server Load Balancer（SLB）インスタンスをマウントして中央のエンドポイントを提供し、着信トラフィックをクラスター内のすべてのノードのPodに均等に分配することができます。その後、PodはクラスターのIPアドレスに基づいてトラフィックをターゲットPodに転送します。
3. 実践編
次の例では、Alibaba Cloud Container ServiceでKubernetes Serviceを使用する方法を示します。
サービスの作成
前提条件：Alibaba Cloudコンテナクラスターを作成し、ローカル端末からAlibaba Cloudコンテナクラスターへの接続を設定しています。
kubectl get csコマンドを実行して、Alibaba Cloudコンテナクラスターが接続されていることを確認します。
Alibaba CloudにKubernetes Serviceを実装するには、以下のテンプレートを使用します。3つのテンプレートがあります。クライアントテンプレートは、サービスで宣言されたPodにトラフィックを均等に分配するKubernetes Serviceにアクセスするために使用します。
Kubernetes Serviceテンプレートを作成し、フロントエンドのポート80からバックエンドのポート80までトラフィックが均等に分散するようにPodを宣言します。そして、run:nginxラベルを持つバックエンドPodを選択するようにselectorフィールドを設定します。
次に、Kubernetes Deploymentsを使ってrun:nginxラベルを持つPodのグループを作成します。Deploymentには2つのレプリカがあり、2つのPodにマッチします。
kubectl create -f service.yaml コマンドを実行して Deployment を作成します。Deploymentが作成されたら、podも作成されているか確認します。次の図のように、Deploymentと一緒に作成された2つのpodはRunning状態になっています。kubectl get pod -o wideコマンドを実行すると、PodのIPアドレスが表示されます。run=nginxに基づくフィルタリングを実装するには、-lを使用します。次の図のように、2つのPodのIPアドレスは「10.0.0.135」と「10.0.0.12」で、どちらも「run=nginx」というラベルが付いています。
以下のコマンドを実行して、2つのPodを選択するKubernetes Serviceを作成します。
kubectl describe svcコマンドを実行して、Serviceの状態を確認します。次の図に示すように、nginxという名前で作成されたKubernetes Serviceは、run=nginxというセレクタを使用して、バックエンドのPodとして10.0.0.12と10.0.0.135を選択しています。バックエンドの2つのPodにトラフィックを均等に分配するために、Kubernetes Service用にクラスタ内の仮想IPアドレスを作成します。
client.yamlコマンドを実行して、Kubernetes ServiceにアクセスするためのクライアントPodを作成します。kubectl get podコマンドを実行して、クライアントPodが作成され、Running状態になっていることを確認します。
kubectl execコマンドを実行してクライアントPodにアクセスし、3つのアクセスモードを体験します。curlを使用して、Kubernetes ServiceのクラスタIPアドレス（または仮想IPアドレス）に直接アクセスします。クライアントPodにはcurlがインストールされていません。wgetコマンドを実行して、仮想IPアドレスを入力します。バックエンドのnginxというKubernetes Serviceに、中央のエンドポイントでもある仮想IPアドレスを介してアクセスできます。
サービス名からKubernetes Serviceにアクセスすることもできます。wgetコマンドを実行してKubernetes Serviceのnginxにアクセスすると、先ほどと同じ結果が得られます。
クライアントPodがKubernetes Serviceと異なる名前空間にある場合、Serviceが置かれている名前空間の名前を追加することで、Serviceにアクセスすることができます。ここでは、defaultという名前の名前空間を例にしています。
環境変数を使ってKubernetes Serviceにアクセスすることもできます。クライアントPodでenvコマンドを実行すると、注入された環境変数が表示されます。nginx Serviceのすべての設定が登録されています。
wgetコマンドを実行して、環境変数にアクセスします。すると、Kubernetes Serviceにアクセスできるようになります。
外部ネットワークからKubernetes Serviceにアクセスする方法を説明します。VimでKubernetes Serviceの一部の設定を変更します。
typeフィールドを追加し、LoadBalancerに設定して外部からのアクセスを可能にします。
kubectl applyコマンドを実行して、変更した内容をServiceに適用します。
では、Serviceにどのような変化が起こるか見てみましょう。kubectl get svc -o wideコマンドを実行すると、Service nginxに外部アクセス用のIPアドレスであるEXTERNAL-IPが追加されていることがわかります。前述の通り、本サービスはクラスタ内ではCLUSTER-IPで定義された仮想IPアドレスを介してアクセスされます。
外部IPアドレス39.98.21.187にアクセスして、本サービスでどのようにアプリケーションが公開されているかを確認します。端末のWebブラウザに外部IPアドレスを入力して、本サービスにアクセスしてください。
以下は、Service を使用して Kubernetes でサービスディスカバリーを実装する方法です。Serviceのアクセスアドレスは、Podのライフサイクルとは関係ありません。まず、Serviceに選ばれた2つのPodのIPアドレスを見てみましょう。
kubectl deleteコマンドを実行して、1つ目のPodを削除します。
すると、Deployment は、末尾が137のIPアドレスを持つ別のPodを自動的に作成します。
describeコマンドを実行すると、次の図のようにService情報が表示されます。エンドポイントはクラスターのIPアドレスのままです。LoadBalancerモードでは、外部アクセス用のIPアドレスは変更されません。バックエンドPodのIPアドレスは、ServiceのバックエンドIPアドレスリストに自動的に含まれます。これは、クライアントのアクセスには影響しません。
このようにして、Podのライフサイクルの変更が、アプリケーション・コンポーネントへの呼び出しに影響を与えることはありません。
4. アーキテクチャ設計
本章では、Kubernetesの設計と実装について分析します。
Kubernetesのサービスディスカバリーアーキテクチャ
前述の図は、サービスディスカバリーのためのKubernetes Serviceのアーキテクチャを示しています。
このアーキテクチャには、マスターノードと複数のワーカーノードが含まれています。
- マスターノードは、Kubernetesの制御機能を実装しています。
- ワーカーノードは、ユーザーアプリケーションを実行します。
マスターノードには、すべてのKubernetesオブジェクトを集中管理するためのKubernetes APIサーバーが配備されています。すべてのコンポーネントはAPIサーバーに登録され、Podのライフサイクルの変更など、オブジェクトの変更をリッスンします。
マスターノードには3つの主要なコンポーネントがあります。
- クラウドコントローラーマネージャーは、外部からのアクセスのためにロードバランサーを構成します。
-
CoreDNSは、API サーバー上の Service のバックエンド Podの変更をリッスンします。サービス名を介してサービスの仮想 IP アドレスに直接アクセスするように DNS 解決を構成できます。また、ヘッドレスサービスが保持するIPアドレスリストのIPアドレスを解決するようにDNS解決を設定することもできます。 - 各ノードの
kube-proxyがServiceやPodの変更をリッスンするため、実際の状況に応じてクラスタ内のノードやPodを設定したり、仮想IPアドレスを介したアクセスを設定したりすることができます。
実際のアクセスリンクを見てみましょう。例えば、クラスタ内のクライアントPod3がサービスにアクセスしたいとします。クライアントPod3は、CoreDNSを介してサービスのIPアドレスを解決し、サービス名と一致するIPアドレスを返します。クライアントPod3は、サービスIPアドレスを通じてリクエストを開始します。リクエストはホストネットワークに送信された後、iptablesやkube-proxyで設定されたIP virtual server (IPVS)に基づいてインターセプトされます。その後、リクエストはロードバランサーによってバックエンドの各Podに分配されます。これにより、サービスディスカバリーとロードバランシングのプロセスが実装されます。
インターネットからリクエストが送られてきた場合など、外部からのトラフィックがどのように処理されるかを見てみましょう。ロードバランサーでもある外部のクラウドコントローラーマネージャーが、本サービスの変更を聞き取った後にロードバランサーが設定されます。設定されたロードバランサーは、外部からのアクセスリクエストをノードのポートに転送し、ノードは、kube-proxyで設定されたiptablesに基づいて、リクエストをクラスタIPアドレスに転送します。その後、クラスターIPアドレスがバックエンドPodのIPアドレスにマッピングされ、最終的にこのリクエストが送信されます。これにより、サービスディスカバリーとロードバランシングのプロセスが実装されます。これがサービスディスカバリーのためのKubernetes Serviceのアーキテクチャです。
高度なスキル
Kubernetes Serviceの実装方法と、Serviceのネットワークエラーの診断・修正方法について説明します。
まとめ
この記事で学んだことをまとめてみましょう。
1、クラウドネイティブなシナリオにおけるサービスディスカバリーとロードバランシングの目的
2、サービスディスカバリーとロードバランシングのためにKubernetes Serviceを実装する方法
3、サービスが使用するKubernetesクラスタ内のコンポーネントと、それらのコンポーネントがどのように動作するか。
この記事を読んだ後、Kubernetes Servicesを使用することで、複雑なエンタープライズレベルのアプリケーションを標準的かつ高速にオーケストレーションできるようになることを願っています。
本ブログは英語版からの翻訳です。オリジナルはこちらからご確認いただけます。一部機械翻訳を使用しております。翻訳の間違いがありましたら、ご指摘いただけると幸いです。
アリババクラウドは日本に２つのデータセンターを有し、世界で60を超えるアベラビリティーゾーンを有するアジア太平洋地域No.1(2019ガートナー)のクラウドインフラ事業者です。
アリババクラウドの詳細は、こちらからご覧ください。
アリババクラウドジャパン公式ページ