※ 本記事は、Ajay Chhabriaによる”Announcing load balancer node label selector for Kubernetes on OCI“を翻訳したものです。
2022年6月23日
企業は通常、ロード・バランサまたはネットワーク・ロード・バランサの背後に多くのバックエンド・サービスを実行します。これらのサービスは、顧客向けのアプリケーション、ダッシュボード、API、ビジネス・ロジックなどを強化します。これらのアプリケーションが拡張したり、クラウド・ネイティブのマイクロサービス・ベースのアーキテクチャを適用したり、パブリック・クラウドに移行したりすると、管理者は、任意のトラフィックを様々なサービスにルーティングする効果的な方法を探します。アプリケーションの性質に基づいて、異なるノード・プールを使用する複数のチームまたは異なるチームが、1つの環境で単一のクラスタを使用する場合があります。そのため、Kubernetes管理者は、ロード・バランサの更新に影響する関連のないワーカー・ノードを回避するために、ロード・バランサを特定のバックエンドに配線する必要があります。この構成では、1つのクラスタ内のトラフィックが分離され、ノード・レベルのワークロード管理がきめ細かく行われます。
Oracle Cloud Infrastructure(OCI)Kubernetesにより、ロード・バランサ・サービス・タイプや、それらのロード・バランサ・サービスに対するバックエンド・セットの追加方法をきめ細かく制御できます。本日、Oracle Container Engine for Kubernetes(OKE)で特定のワーカー・ノードを選択して、クラスタに先行するロード・バランサまたはネットワーク・ロード・バランサのバックエンド・セットとして機能できるようにする新しい構成オプションであるnode-label-selectorを発表しています。
ノード・ラベル・セレクタとは?
ノード・ラベル・セレクタは、サービスオン・タイプのロード・バランサがトラフィックを転送するワーカー・ノードを指定するキーまたは値のペアです。作成時にオブジェクトにアタッチするか、後で追加していつでも変更できます。各オブジェクトには、一連のキーまたは値ラベルを定義できます。各キーは、特定のオブジェクトに対して一意である必要があります。
ノード・ラベル・セレクタの利点
Kubernetes管理者と開発者は、トラフィックをフィルタするようにノード・ラベル・セレクタを構成することを希望しています。トラフィックのフィルタリングの一般的なユース・ケースとしては、トラフィックがスケール・アップまたはスケール・ダウンしているときにワーカー・ノードをフィルタリングする簡単な方法の提供や、ネットワークのタイムアウトなどの問題のトリアージなどが挙げられます。ノード・ラベル・セレクタは、トラフィックを新しいワーカー・ノード・セットにリダイレクトする場合や、ライブ・トラフィックを中断せずにそのサブセットを停止する場合にも役立ちます。
スケーリングされた環境では、ロード・バランサがワーカー・ノード(externalTrafficPolicy: Local)にローカルなポッドを検索するように構成されている場合、ロード・バランサのヘルスは重要です。これは、すべてのノードがデフォルトで追加され、すべてのノードに必要なアプリケーション・ポッドがあるわけではないためです。ノード・セレクタでは、関連するサブセットのみを追加できるため、ロード・バランサのヘルスがより適切です。バックエンド登録用のワーカー・ノードをフィルタすると、モニタリングやアラームの設定と管理も簡単になります。
OKEのロード・バランサ・ノード・ラベル・セレクタは、イングレス内の各サービスのバックエンドのマッピングにも役立ちます。イングレスを使用している顧客は、単一のOKEクラスタで複数のサービス(論理クラスタ)を作成します。各論理クラスタまたはサービスは、パブリック・ロード・バランサを通じてお客様に公開されます。各サービスに複数のロード・バランサがある場合、各ロード・バランサには、それぞれのイングレス・エンドポイントをバックエンドとしてホストしているすべてのワーカー・ノードがあります。お客様は、各イングレス・ロード・バランサのバックエンドに1対1または1対多のマッピングを指定することを希望しています。たとえば、サービスのパブリック・ロード・バランサには1つまたは複数のバックエンドのみがありますが、そのサービスのイングレスをホストしているすべてのノードはありません。
ノード・ラベル・セレクタの使用
次の図およびステップは、OKEクラスタに先立つOCIロード・バランサまたはネットワーク・ロード・バランサにノード・ラベル・セレクタを使用する方法を示しています。

作成中の新規または既存のロード・バランサ・タイプ・サービスについて、次の注釈を追加して、バックエンド・セット登録に含めるノードを指定できます。
最初のステップは、ワーカー・ノードにラベルを付けることです。
kubectl label nodes <node-name> <node-label>。たとえば、kubectl label nodes 10.0.1.2 lbset=ServiceAを使用できます。
initialNodeLabelsのセットを持つようにノード・プールを構成することもできます。
ロード・バランサのバックエンド・セットに含めるノードを選択するには、マニフェストに注釈を含めます。次の例は、node-labelセレクタ注釈を使用したサービス・マニフェストを示しています。
apiVersion: v1
kind: Service
metadata:
name: my-nginx-svc
labels:
app: nginx
annotations:
oci.oraclecloud.com/node-label-selector: lbset=ServiceA
spec:
type: LoadBalancer
ports:
- port: 80
selector:
app: nginx
ネットワーク・ロード・バランサの場合は、次のコマンドを使用します。
oci-network-load-balancer.oraclecloud.com/node-label-selector: lbset=ServiceC
この注釈は、このリストに定義されているすべてのk8sラベル・セレクタをサポートします。次の例を参照してください。
lbset in (ServiceA, ServiceC)
lbset #checks existence
lbset=ServiceA
lbset=ServiceA,Prod=ServiceC #comma is logical AND
lbset != ServiceA
バックエンド・セット内のすべてのバックエンドがある場合、この注釈を既存のサービスまたはロード・バランサに追加すると、ロード・バランサの作業リクエストがトリガーされ、不要なノードが削除されます。注釈でラベル付けされたノードのみがロード・バランサにバックエンドとして追加されます。
ポッドがロード・バランサが接続されているノードのセットに常に配置されるようにするには、ノード・アフィニティを使用します。たとえば、次のマニフェストでは、requiredDuringSchedulingIgnoredDuringExecution node affinity, lbset: ServiceAを持つポッドについて説明します。ポッドは、lbset= ServiceAラベルを持つノードでのみスケジュールされます。
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: lbset
operator: In
values:
- ServiceA
containers:
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
次のステップ
ロード・バランサ・ノード・ラベル・セレクタにより、Kubernetes管理者は選択したワーカー・ノードにトラフィックを転送する柔軟性が提供されます。OCIロード・バランサまたはネットワーク・ロード・バランサのすべてのバックエンド・サーバーにトラフィックを送信することに制限されなくなりました。
詳細は、ドキュメントのロード・バランサ・ノード・ラベル・セレクタを参照してください。この新機能や、Oracle Cloud Infrastructureが提供するエンタープライズ・グレードのすべての機能を体験するには、Always Freeのアカウントを今すぐ作成し、300ドルの無料クレジットでOKEネットワーキング・オプションを試してください。
