kubectlを使用した仮想サービスの管理

kubectlコマンドを使用すると、仮想サービスを作成、更新、移動、リスト、表示および削除できます。次のトピックでは、kubectlを使用してこれらの操作を管理する方法について説明します。

仮想サービスに必要なIAMポリシー

仮想サービスを使用するには、管理者がポリシー(IAM)で必要なアクセス・タイプを付与する必要があります。コンソール、REST API、SDK、CLI、Kubernetes kubectlまたはその他のツールのいずれを使用している場合でも、適切な権限が必要です。

アクションによって権限が拒否または認可されていないメッセージが生成される場合は、管理者にいくつかの設定を確認してください。管理者は、適切なタイプのアクセス権が付与され、正しいコンパートメントが指定されていることを確認する必要があります。

たとえば、グループMeshAdminsのユーザーがコンパートメントsales-app内のすべての仮想サービスを作成、更新および削除できるようにするには:

Allow group MeshAdmins to manage mesh-virtual-services in compartment sales-app

各リソースのサービス・メッシュIAMポリシー・リファレンスの詳細は、サービス・メッシュIAMポリシーを参照してください。

サービス・メッシュに必要なすべてのIAMポリシーを設定するステップバイステップ・ガイドは、サービス・メッシュに必要なポリシーの設定を参照してください

仮想サービスの作成

仮想サービスを作成するには、kubectl applyコマンドを使用します。次に例を示します。

kubectl apply -f virtual-service.yaml

YAML構成ファイルでmetadata:namespaceフィールドを指定して、異なるネームスペースにリソースを作成します。デフォルトでは、ネームスペースが指定されていない場合、コマンドは現在のネームスペースを使用します。YAML構成ファイルのspecセクションにメッシュを指定するときは、メッシュIDまたはメッシュ参照を使用します。

サンプル: virtual-service.yaml (参照)

apiVersion: servicemesh.oci.oracle.com/v1beta1
kind: VirtualService
metadata:
name: <virtualServiceName>  # Name of virtual service
  namespace: <k8sAppNamespace>
  labels:
    version: v1
spec:
  compartmentId: ocid1.compartment.oc1..aaa...
  name: <virtualServiceName>  # Virtual service name inside the mesh
  description: <description>
  mesh:
    ref:
      name: <meshName>  # Name of the containing mesh resource.
      namespace: <sample-mesh-namespace>  # Namespace of the referenced custom resource.
  defaultRoutingPolicy:
    type: UNIFORM
  hosts:
    - <vsHostName>.example.com  # Host name matching vs-name. 
  mtls:
    maximumValidity: 45  # Default is 45. 
    mode: STRICT

サンプル: virtual-service.yaml (ID)

apiVersion: servicemesh.oci.oracle.com/v1beta1
kind: VirtualService
metadata:
  name: <virtualServiceName>  # Name of virtual service
  namespace: <k8sAppNamespace>
  labels:
    version: v1
spec:
  compartmentId: ocid1.compartment.oc1..aaa...
  name: <virtualServiceName>  # Virtual service name inside the mesh
  description: <description>
  mesh:
    id: ocid1.mesh.oc1..aa...
  defaultRoutingPolicy:
    type: UNIFORM
  hosts:
    - <vsHostName>.example.com  # Host name matching vs-name.
  mtls:
    maximumValidity: 45  # Default is 45.
    mode: STRICT

ヒント

サービス・メッシュKubernetesカスタム・リソース・ステータスの詳細は、「サービス・メッシュKubernetesリソース条件」を参照してください。

場所:

<name>: 仮想サービスの名前。名前は同じサービス・メッシュ内で一意である必要があり、作成後に変更できません(変更不可)。名前は、文字またはアンダースコアで始まり、文字、数字、ハイフンまたはアンダースコアが続く必要があります。長さは1から255文字です。機密情報を入力しないでください。
<compartmentId>: 仮想サービスが属するコンパートメントのOCID。
<meshId>: この仮想サービスが作成されるサービス・メッシュのOCID。
<description>: (オプション)仮想サービスの説明。機密情報を入力しないでください。
<defaultRoutingPolicy>: 仮想サービス内の仮想デプロイメント全体のデフォルトのルーティング・ポリシー。仮想サービスのルート表が存在しない場合、仮想サービスはデフォルトのルーティング・ポリシーを適用します。オプションは、DENYまたはUNIFORMです。デフォルトのルーティング・ポリシーはDENYです。
ルーティング・オプションは次のとおりです。
- 均一: 仮想デプロイメント間でトラフィックを均一に分散します。
- 拒否: デフォルト・オプションです。ルーティングを無効にします。仮想デプロイメントにトラフィックを送信しません。
詳細は、仮想サービスでのトラフィックのルーティングを参照してください。
<hosts>コール元が使用する仮想サービスのDNSホスト名。接頭辞形式のワイルドカード・ホスト名をサポートします。最大10個の DNSホスト名を指定します。有効なホスト名の例を次に示します: www.example.com, *.example.com, *.com, www.example.com:9080, *.example.com:9080。仮想サービスにTCP仮想デプロイメントのみがある場合、省略できます。

警告

このリソースでは、サービス・メッシュ予約ポート15000、15003、15006および9901を使用しないでください。

HTTPベースの仮想デプロイメントを使用するサービスの場合、ホスト名は、サービスとの通信に使用されるHTTPホスト・ヘッダーと一致する必要があります。不一致が発生した場合、このサービスに接続しているアプリケーションは404エラーを受け取ります。HTTPホストヘッダーの形式は、標準ポート80および443の場合は example.comです。9080などの非標準ポートの場合、ホスト・ヘッダーの形式はexample.com:9080です。

TLS_PASSTHROUGHに基づく仮想デプロイメントを持つサービスの場合、ホスト名は、サービスとの通信に使用されるサーバー名指示(SNI)と一致する必要があります。不一致が発生した場合、このサービスに接続しているアプリケーションはTLSハンドシェイク・エラーを受信します。このサービスでは、プリフィクス・フォームでワイルドカードを使用できますが、包括ワイルドカード(*)は許可されません。

SNIはHTTPホスト・ヘッダーに似ていますが、TLS用です。ただし、SNIにはポート情報は必要ありません。たとえば、SNI example.comおよび非標準ポート9080でKubernetesサービスを実行している場合は、仮想サービスのホストとしてexample.comを定義する必要があります。

重要

ホスト・エントリは、エグレス専用サービスには必要ありません。エグレス専用サービスは、他のサービスからのコールを受信しないマイクロサービスです。
<mtls>メッシュ内の他の仮想サービスまたはイングレス・ゲートウェイからのリクエストを受信するときに使用するmTLS認証モード。次のリストの説明に従って、mTLS <mode>をDISABLED、PERMISSIVEまたはSTRICTに設定します。また、<maximumValidity>を指定して、mTLS証明書の有効日数を決定します。45から90の間の値を指定しますデフォルト値は45日です。
- <mode>:
  - DISABLED: raw TCPトラフィックを受け入れます。このメッシュ内の最小仮想サービスまたはイングレス・ゲートウェイでは、mTLS認証モードを使用できません。
  - PERMISSIVE: mTLSトラフィックとRAW TCPトラフィックの両方を受け入れます。このメッシュ内の仮想サービスおよびイングレス・ゲートウェイは、PERMISSIVEまたはSTRICTモードのいずれかです。
  - STRICT: mTLSトラフィックを受け入れます。このメッシュ内のすべての仮想サービスおよびイングレスでは、STRICTモードを使用する必要があります。
  サービス・メッシュでのmTLSの使用の詳細は、サービス・メッシュでのmTLSの使用を参照してください。

仮想サービスの更新

kubectlを使用して仮想サービスを更新するには:

必要に応じて、仮想サービスの既存のYAML構成ファイルを変更します。
ファイルを保存します。
applyコマンドを再度実行します:
```
kubectl apply -f virtual-service.yaml
```

仮想サービスの移動

仮想サービスを別のコンパートメントに移動するには:

コンパートメントOCIDを、仮想サービスの既存のYAML構成ファイル内のターゲット・コンパートメントの値に更新します。
ファイルを保存します。
applyコマンドを再度実行します:
```
kubectl apply -f virtual-service.yaml
```

仮想サービスのリストの取得

ネームスペース内の仮想サービスのリストを取得するには、次のコマンドを使用します。

kubectl get virtualservices -n <namespace>

仮想サービス詳細の取得

ネームスペース内の特定の仮想サービスの詳細を表示するには、次のコマンドを使用します:

kubectl describe virtualservice <name> -n <namespace>

仮想サービスの削除

ネームスペース内の特定の仮想サービスを削除するには、次のコマンドを使用します:

kubectl delete virtualservice <name> -n <namespace>

ノート

仮想デプロイメントや仮想サービス・ルート表など、仮想サービス内に子リソースが存在する場合、削除操作は失敗します。

Oracle Cloud Infrastructureドキュメント