Service基本概念
ユーザーはKubernetes内で各種コンテナをデプロイできます。そのうちの一部はHTTP、HTTPSプロトコルによって外部にレイヤー7ネットワークサービスを提供し、もう一部はTCP、UDPプロトコルによってレイヤー4ネットワークサービスを提供します。Kubernetesによって定義されたServiceリソースはクラスター内のレイヤー4ネットワークを管理するためのサービスアクセスです。
KubernetesのServiceTypesはServiceタイプを指定でき、デフォルトはClusterIPタイプです。ServiceTypesの値および行動は次のとおりです。
|
ClusterIP | クラスターの内部IPによってサービスを公開します。サービスがクラスター内部でのみアクセスされる必要がある場合は、このタイプを使用してください。このタイプはデフォルトのServiceTypeです。 |
NodePort | 各クラスターノード上のIPおよび静的ポート(NodePort)によってサービスを公開します。NodePortサービスはClusterIPサービスにルーティングされ、このClusterIPサービスは自動的に作成されます。<NodeIP>:<NodePort>をリクエストすることによって、クラスターの外部からこのNodePortサービスにアクセスすることができます。テストおよび非本番環境を除き、本番環境内で直接クラスターノードによって外部またはパブリックネットワークにサービスを提供することは推奨していません。安全面から考慮すると、このタイプを使用して直接クラスターノードを公開すると、攻撃を受けやすくなります。通常クラスターノードは動的で、スケーラブルであると考えられ、このタイプを使用して外部にサービスを提供するアドレスおよびクラスターノードには結合が発生します。 |
LoadBalancer | Tencent CloudのCLBを使用し、パブリックネットワークまたはプライベートネットワークにサービスを公開することができます。CLBはNodePortサービスにルーティングするか、VPC-CNIネットワーク条件のコンテナ内に転送することができます。 |
ClusterIPおよびNodePortタイプの Serviceは、異なるクラウドサービスプロバイダまたは自作のクラスター内での行動が通常の状況で同じです。LoadBalancerタイプのServiceは、クラウドサービスプロバイダのCLBを使用してサービスの公開を行うため、クラウドサービスプロバイダはCLBを制御するネットワークタイプ、バックエンドバインディングの重み調整など、そのCLBの機能に関わるさまざまな追加機能を提供します。詳細はService機能ドキュメントをご参照ください。 サービスのアクセス方法
上記のServiceTypesに基づいて定義されます。TKEが提供する以下の4種類のサービスアクセス方式を使用することができます。
|
パブリックネットワーク | LoadBalancer | ServiceのLoadbalanceモードを使用し、パブリックネットワークIPはバックエンドのPodにアクセスし、Webフロントエンド類のサービスに適用されます。 作成が完了したサービスはクラスター外ではCLBドメイン名またはIP+サービスポートによってサービスにアクセスでき、クラスター内ではサービス名+サービスポートによってサービスにアクセスできます。 注意:Tencent Cloud Load Balancerインスタンスは2023年3月6日にアーキテクチャがアップグレードされました。アップグレード後、パブリックネットワークCLBはドメイン名の形式でサービスを提供します。VIPは業務リクエストに応じて動的に変化し、コンソールにはVIPアドレスが表示されなくなります。ドメイン名型パブリックネットワークCLBリリースのお知らせをご参照ください。 新規登録したTencent Cloudユーザーはデフォルトでアップグレード後のドメイン名型CLBを使用します。 既存のユーザーは元のCLBを継続して使用することを選択でき、アップグレードの影響を受けません。CLBサービスをアップグレードする必要がある場合は、同時にTencent Cloud製品のCLBおよびTKEをアップグレードする必要があります。アップグレードしない場合、TKE内のすべてのパブリックネットワークタイプの Service/Ingressの同期は影響を受ける可能性があります。CLBのアップグレード操作の詳細については、ドメイン名型CLBアップグレードガイドをご参照ください。TKEがService/Ingressコンポーネントのバージョンをアップグレードするには、チケットを提出してお問い合わせください。
|
VPCプライベートネットワーク | LoadBalancer | ServiceのLoadbalanceモードを使用し、service.kubernetes.io/qcloud-loadbalancer-internal-subnetid: subnet-xxxxxxxxというアノテーションを指定します。すなわちプライベートIPによってバックエンドのPodに直接アクセスすることができます。 作成が完了したサービスはクラスター外ではCLBドメイン名またはIP+サービスポートによってサービスにアクセスでき、クラスター内ではサービス名+サービスポートによってサービスにアクセスできます。 |
ホストポートアクセス | NodePort | 1つのホストポートをコンテナにマッピングするアクセス方式を提供し、TCP、UDP、Ingressをサポートしています。業務のカスタム上位階層LBをNodeに転送することができます。 作成が完了したサービスはCVM IP+ホストポートによってサービスにアクセスできます。 |
クラスター内のみアクセス | ClusterIP | ServiceのClusterIP モードを使用し、Serviceネットワークセグメント内のIPを自動的に割り当て、クラスター内のアクセスに使用します。MySQLのようなデータベース類などのサービスはクラスター内アクセスを選択でき、それによってサービスネットワークの隔離を保証します。 作成が完了したサービスはサービス名+サービスポートによってサービスにアクセスできます。 |
CLBの関連概念
Serviceの動作原理
Tencent Cloudコンテナクラスター内のService ControllerコンポーネントはユーザーのServiceリソースの同期を行う役割を担います。ユーザーがServiceリソースを作成、変更または削除した場合、クラスターノードまたはService Endpointsに変化が発生した場合、コンポーネントコンテナにドリフト再起動が発生した場合、コンポーネントはいずれもユーザーのServiceリソースに同期を行います。
Service ControllerはユーザーのServiceリソースの記述によって対応するCLBリソースを作成し、リスナーおよびそのバックエンドを設定します。ユーザーがクラスターのServiceリソースを削除した場合、対応するCLBリソースを変更します。
Serviceのライフサイクル管理
Serviceが外部にサービスする機能はCLBが提供するリソースに依存します。サービスリソース管理もServiceの重要な作業のひとつです。Serviceはリソースのライフサイクル管理において以下のタグを使用します。
tke-createdBy-flag = yes:このリソースがコンテナサービスによって作成されたことを示します。
このタグがあれば、Serviceは破棄される時に対応するリソースを削除します。
このタグがなければ、Serviceは破棄される時に、CLB内のリスナーリソースのみを削除します。CLB自体は削除されません。
tke-clusterId = <ClusterId>:このリソースがどのClusterによって使用されているかを示します。
ClusterIdが正確であれば、Serviceが破棄された時に、対応するタグを削除します。
説明
ユーザーが既存のCLBを使用した場合、ServiceはこのCLBのみを使用し、このCLBを削除することはありません。
ユーザーがCLB上で削除保護を有効にしたか、プライベート接続を使用した場合、Serviceを削除する時に、このCLBは削除されません。
LoadBalancerタイプのServiceクラスターリソースが作成された時に、CLBに対応するライフサイクルが開始されます。Serviceリソースが削除されるかCLBが再構成された時に、CLBのライフサイクルが終了します。この期間、CLBはServiceリソースの記述に基づいて継続的に同期を行います。ユーザーがServiceのネットワークアクセスに切り替えた場合、例えばパブリックネットワーク > VPCプライベートネットワーク、VPCプライベートネットワーク > パブリックネットワーク、VPCサブネットに切り替え、使用する既存のCLBを切り替えた場合、この操作はいずれもCLBの再構成または破棄に影響します。LoadBalancerタイプのServiceの動作原理は下図に示すとおりです。 Serviceの注意事項
Serviceには.spec.externalTrafficPolicyというフィールドがあります。kube-proxyは、spec.internalTrafficPolicyの設定に基づいてルーティングされたターゲットサービスのエンドポイントをフィルタリングします。その値がLocalに設定されている場合、ノードローカルのサービスのエンドポイントのみが選択されます。その値がClusterに設定されているか省略されている場合、Kubernetesはすべてのサービスのエンドポイントを選択します。詳細については、Kubernetesドキュメントをご参照ください。 ServiceがLocal方式を使用している場合、PodがTKEノードからスーパーノードにスケジューリングされるか、またはスーパーノードからTKEノードにスケジューリングされる時に切断が発生するため、Serviceはローカルのサービスエンドポイントのみ選択できます。
Serviceの高リスク操作
従来型CLBを使用する(非推奨)。
コンテナサービスによって追加されたCLBタグを変更または削除し、新しいCLBを再購入してそのタグを復元します。
CLBコンソールによって、コンテナサービスがCLBを管理するリスナー名を変更します。
Service機能
Serviceの関連操作および機能は次のとおりです。以下のドキュメントをご参照ください。
参考資料