kubectlを使用したアプリケーションのサービス・メッシュの設定

アプリケーションにサービス・メッシュを設定するには、一連のサービス・メッシュ・リソースを構成する必要があります。

この項では、kubectlを使用したサービス・メッシュの管理の例を示します(詳細は、Kubernetesを使用したサービス・メッシュの管理を参照)。Kubernetesネームスペース<app-namespace>が作成され、そのネームスペースにアプリケーションがデプロイされると仮定します。サービス・メッシュ・カスタム・リソースは、アプリケーションと同じネームスペースまたは別のネームスペースに作成できます。この例では、サービス・メッシュ・カスタム・リソースに<app-namespace>を使用します。

アプリケーション設計

この例では、次で構成されるアプリケーションを想定しています。

uiという名前のフロントエンド・マイクロサービス。
2つのバックエンド・マイクロサービスms1およびms2。
バックエンド・マイクロサービスms2には、2つのバージョンms2-v1とms2-v2があります。

Kubernetesクラスタの想定を次に示します。

各マイクロサービスui、ms1およびms2には、クラスタ内でDNSベースのホスト名検索を有効にするために、同じ名前で定義されたKubernetesサービスがあります。
ui Kubernetesサービス定義には、uiポッドと一致するセレクタがあります。
ms1 Kubernetesサービス定義には、ms1ポッドと一致するセレクタがあります。
ms2 Kubernetesサービス定義には、ms2-v1およびms2-v2ポッドと一致するセレクタがあります。
クラスタには、クラスタへのイングレス・トラフィックを許可するタイプ・ロード・バランサのイングレスKubernetesサービスがあり、uiポッドと一致するセレクタがあります。

サンプル・アプリケーション: name.yaml

apiVersion: v1
kind: Service
metadata:
  name: ui
  namespace: app-namespace
spec:
  ports:
    - port: 9080
      name: http
  selector:
    app: ui
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ui
  namespace: app-namespace
  labels:
    app: ui
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ui
  template:
    metadata:
      namespace: app-namespace
      labels:
        app: ui
      annotations:
        servicemesh.oci.oracle.com/proxy-log-level: error
    spec:
      containers:
        - name: ui
        ...
---
apiVersion: v1
kind: Service
metadata:
  name: ms1
  namespace: app-namespace
spec:
  ports:
    - port: 9080
      name: http
  selector:
    app: ms1
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ms1
  namespace: app-namespace
  labels:
    app: ms1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ms1
  template:
    metadata:
      namespace: app-namespace
      labels:
        app: ms1
      annotations:
        servicemesh.oci.oracle.com/proxy-log-level: error
    spec:
      containers:
        - name: ms1
        ...
---
apiVersion: v1
kind: Service
metadata:
  name: ms2
  namespace: app-namespace
spec:
  ports:
    - port: 9080
      name: http
  selector:
    app: ms2
---
apiVersion: v1
kind: Service
metadata:
  name: ms2-v1
  namespace: app-namespace
spec:
  ports:
    - port: 9080
      name: http
  selector:
    app: ms2
    version: v1
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ms2-v1
  namespace: app-namespace
  labels:
    app: ms2
    version: v1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ms2
      version: v1
  template:
    metadata:
      namespace: app-namespace
      labels:
        app: ms2
        version: v1
      annotations:
        servicemesh.oci.oracle.com/proxy-log-level: error
    spec:
      containers:
        - name: ms2
        ...
---
apiVersion: v1
kind: Service
metadata:
  name: ms2-v2
  namespace: app-namespace
spec:
  ports:
    - port: 9080
      name: http
  selector:
    app: ms2
    version: v2
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ms2-v2
  namespace: app-namespace
  labels:
    app: ms2
    version: v2
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ms2
      version: v2
  template:
    metadata:
      namespace: app-namespace
      labels:
        app: ms2
        version: v2
      annotations:
        servicemesh.oci.oracle.com/proxy-log-level: error
    spec:
      containers:
        - name: ms2
        ...
---
apiVersion: v1
kind: Service
metadata:
  name: application-ingress
  namespace: app-namespace
spec:
  ports:
  - port: 80
    targetPort: 9080
    name: http
  selector:
    app: ui
  type: LoadBalancer
---

ノート

Kubernetes Service Meshリソース作成YAML構成データは、特定の順序である必要があります。

メッシュ
仮想サービス
仮想デプロイメント
仮想サービスのルート表
Ingress Gateway
Ingress Gatewayのルート表
ポリシーへのアクセス
仮想デプロイメント・バインディング
Ingress Gatewayデプロイメント

Kubernetes構成リソースが1つのYAMLファイルにあるか、複数のYAMLファイル内にあるかに関係なく、リソースの順序は変わりません。

サービス・メッシュ・リソースの作成

アプリケーションに対してサービス・メッシュを有効にするには、次の2つのリソース・セットを作成する必要があります。

サービスメッシュコントロールプレーンリソース
サービス・メッシュ・バインディング・リソース。

この例では、サービス・メッシュをkubectlで管理し、Kubernetesクラスタにカスタム・リソースを作成してコントロール・プレーン・リソースを作成します。サービス・メッシュ・バインディング・リソースは、常にKubernetesクラスタでカスタム・リソースとして作成されます。

アプリケーション設計に基づいて、サービス・メッシュ・コントロール・プレーン・リソースを作成します。次の提案は、前述のアプリケーション設計に基づいてサービス・メッシュ・リソースをモデル化する方法を示しています。

メッシュ: app- nameという名前のサービス・メッシュを作成します。
仮想サービス: 3つのマイクロサービスに対応する3つの仮想サービス(ui、ms1、ms2)を作成します。
仮想デプロイメント: マイクロサービスのバージョンごとに1つずつ、4つの仮想デプロイメントを作成します(ui、ms1、ms2-v1、ms2-v2)。
仮想サービス・ルート表: 仮想サービスの各バージョンに1つずつ、3つの仮想サービス・ルート表を作成し、仮想サービスのバージョンに分割されるトラフィックを定義します。
Ingress Gateway: 1つのイングレス・ゲートウェイを作成してメッシュへのイングレスを有効にします
イングレス・ゲートウェイのルート表: 1つのイングレス・ゲートウェイのルート表を作成し、イングレス・ゲートウェイでの受信トラフィックのトラフィック・ルーティングを定義します
アクセス・ポリシー: メッシュ内のマイクロサービス間のトラフィックへのアクセスを可能にするルールを使用して、1つのアクセス・ポリシーを作成します。

システム上のローカルのService Mesh構成ファイルを使用して、Service Meshコントロール・プレーン・リソースを作成します。

kubectl apply -f meshify.yaml

サンプルmeshify.yamlファイル

サービスメッシュリソースを構成するYAMLファイルの例を次に示します。

---
kind: Mesh
apiVersion: servicemesh.oci.oracle.com/v1beta1
metadata:
  name: app-name
  namespace: app-namespace
spec:
  compartmentId: ocid1.compartment.oc1..aaaa...
  certificateAuthorities:
    - id: ocid1.certificateauthority.oc1.iad.aaa...
  mtls:
    minimum: PERMISSIVE
---
kind: VirtualService
apiVersion: servicemesh.oci.oracle.com/v1beta1
metadata:
  name: ms1
  namespace: app-namespace
spec:
  mesh:
    ref:
      name: app-name
 
  defaultRoutingPolicy:
    type: UNIFORM
  compartmentId: ocid1.compartment.oc1..aaaa...
 
  hosts:
    - ms1
    - ms1:9080
---
kind: VirtualDeployment
apiVersion: servicemesh.oci.oracle.com/v1beta1
metadata:
  name: ms1
  namespace: app-namespace
spec:
  virtualService:
    ref:
      name: ms1
  compartmentId: ocid1.compartment.oc1..aaaa...
  listener:
    - port: 9080
      protocol: HTTP
  accessLogging:
    isEnabled: true
  serviceDiscovery:
    type: DNS
    hostname: ms1
---
apiVersion: servicemesh.oci.oracle.com/v1beta1
kind: VirtualServiceRouteTable
metadata:
  name: ms1-route-table
  namespace: app-namespace
spec:
  compartmentId: ocid1.compartment.oc1..aaaa...
  virtualService:
    ref:
      name: ms1
  routeRules:
    - httpRoute:
        destinations:
          - virtualDeployment:
              ref:
                name: ms1
            weight: 100
---
kind: VirtualService
apiVersion: servicemesh.oci.oracle.com/v1beta1
metadata:
  name: ms2
  namespace: app-namespace
spec:
  mesh:
    ref:
      name: app-name
 
  defaultRoutingPolicy:
    type: UNIFORM
  compartmentId: ocid1.compartment.oc1..aaaa...
 
  hosts:
    - ms2
    - ms2:9080
---
kind: VirtualDeployment
apiVersion: servicemesh.oci.oracle.com/v1beta1
metadata:
  name: ms2-v1
  namespace: app-namespace
spec:
  virtualService:
    ref:
      name: ms2
  compartmentId: ocid1.compartment.oc1..aaaa...
  listener:
    - port: 9080
      protocol: HTTP
  accessLogging:
    isEnabled: true
  serviceDiscovery:
    type: DNS
    hostname: ms2-v1
---
kind: VirtualDeployment
apiVersion: servicemesh.oci.oracle.com/v1beta1
metadata:
  name: ms2-v2
  namespace: app-namespace
spec:
  virtualService:
    ref:
      name: ms2
  compartmentId: ocid1.compartment.oc1..aaaa...
  listener:
    - port: 9080
      protocol: HTTP
  accessLogging:
    isEnabled: true
  serviceDiscovery:
    type: DNS
    hostname: ms2-v2
---
apiVersion: servicemesh.oci.oracle.com/v1beta1
kind: VirtualServiceRouteTable
metadata:
  name: ms2-route-table
  namespace: app-namespace
spec:
  compartmentId: ocid1.compartment.oc1..aaaa...
  virtualService:
    ref:
      name: ms2
  routeRules:
    - httpRoute:
        destinations:
          - virtualDeployment:
              ref:
                name: ms2-v1
            weight: 50
          - virtualDeployment:
              ref:
                name: ms2-v2
            weight: 50
---
kind: VirtualService
apiVersion: servicemesh.oci.oracle.com/v1beta1
metadata:
  name: ui
  namespace: app-namespace
spec:
  mesh:
    ref:
      name: app-name
 
  defaultRoutingPolicy:
    type: UNIFORM
  compartmentId: ocid1.compartment.oc1..aaaa...
 
  hosts:
    - ui
    - ui:9080
---
kind: VirtualDeployment
apiVersion: servicemesh.oci.oracle.com/v1beta1
metadata:
  name: ui
  namespace: app-namespace
spec:
  virtualService:
    ref:
      name: ui
  compartmentId: ocid1.compartment.oc1..aaaa...
  listener:
    - port: 9080
      protocol: HTTP
  accessLogging:
    isEnabled: true
  serviceDiscovery:
    type: DNS
    hostname: ui
---
apiVersion: servicemesh.oci.oracle.com/v1beta1
kind: VirtualServiceRouteTable
metadata:
  name: ui-route-table
  namespace: app-namespace
spec:
  compartmentId: ocid1.compartment.oc1..aaaa...
  virtualService:
    ref:
      name: ui
  routeRules:
    - httpRoute:
        destinations:
          - virtualDeployment:
              ref:
                name: ui
            weight: 100
---
kind: IngressGateway
apiVersion: servicemesh.oci.oracle.com/v1beta1
metadata:
  name: app-name-ingress-gateway
  namespace: app-namespace
spec:
  compartmentId: ocid1.compartment.oc1..aaaa...
  mesh:
    ref:
      name: app-name
  hosts:
    - name: exampleHost
      hostnames:
        - hostname.example.com
        - hostname.example.com:80
        - hostname.example.com:443
      listeners:
        - port: 9080
          protocol: HTTP
          tls:
            serverCertificate:
              ociTlsCertificate:
                certificateId: ocid1.certificate.oc1.iad.aaa...
            mode: TLS
  accessLogging:
    isEnabled: true
---
apiVersion: servicemesh.oci.oracle.com/v1beta1
kind: IngressGatewayRouteTable
metadata:
  name: app-name-ingress-gateway-route-table
  namespace: app-namespace
spec:
  compartmentId: ocid1.compartment.oc1..aaaa...
  ingressGateway:
    ref:
      name: app-name-ingress-gateway
  routeRules:
    - httpRoute:
        ingressGatewayHost:
          name: exampleHost
        destinations:
          - virtualService:
              ref:
                name: ui
---
kind: AccessPolicy
apiVersion: servicemesh.oci.oracle.com/v1beta1
metadata:
  name: app-name-policy
  namespace: app-namespace
spec:
  mesh:
    ref:
      name: app-name
  compartmentId: ocid1.compartment.oc1..aaaa...
  rules:
    - action: ALLOW
      source:
        virtualService:
          ref:
            name: ui
      destination:
        virtualService:
          ref:
            name: ms1
    - action: ALLOW
      source:
        virtualService:
          ref:
            name: ms2
      destination:
        allVirtualServices: {}
    - action: ALLOW
      source:
        ingressGateway:
          ref:
            name: app-name-ingress-gateway
      destination:
        virtualService:
          ref:
            name: ui
---

kubectlコマンドを使用してサービス・メッシュ・リソースを適用した後、すべてのリソースがアクティブな状態になるまで待機する必要があります。

すべてのカスタム・リソースをリストします。

kubectl get crd

NAME                                                   CREATED AT
accesspolicies.servicemesh.oci.oracle.com              2022-05-10T21:50:24Z
autonomousdatabases.oci.oracle.com                     2022-05-10T21:50:24Z
catalogsources.operators.coreos.com                    2022-05-10T21:48:21Z
clusterserviceversions.operators.coreos.com            2022-05-10T21:48:23Z
ingressgatewaydeployments.servicemesh.oci.oracle.com   2022-05-10T21:50:24Z
ingressgatewayroutetables.servicemesh.oci.oracle.com   2022-05-10T21:50:24Z
ingressgateways.servicemesh.oci.oracle.com             2022-05-10T21:50:24Z
installplans.operators.coreos.com                      2022-05-10T21:48:24Z
meshes.servicemesh.oci.oracle.com                      2022-05-10T21:50:24Z
mysqldbsystems.oci.oracle.com                          2022-05-10T21:50:24Z
olmconfigs.operators.coreos.com                        2022-05-10T21:48:24Z
operatorconditions.operators.coreos.com                2022-05-10T21:48:25Z
operatorgroups.operators.coreos.com                    2022-05-10T21:48:26Z
operators.operators.coreos.com                         2022-05-10T21:48:26Z
streams.oci.oracle.com                                 2022-05-10T21:50:24Z
subscriptions.operators.coreos.com                     2022-05-10T21:48:27Z
virtualdeploymentbindings.servicemesh.oci.oracle.com   2022-05-10T21:50:24Z
virtualdeployments.servicemesh.oci.oracle.com          2022-05-10T21:50:25Z
virtualserviceroutetables.servicemesh.oci.oracle.com   2022-05-10T21:50:24Z
virtualservices.servicemesh.oci.oracle.com             2022-05-10T21:50:24Z

カスタム・リソース定義のすべてのオブジェクトをリストするには、<service-mesh-crd-name>のカスタム・リソースの名前と、カスタム・リソースが存在するネームスペース(<crd-namespace>)を置き換えます。
```
kubectl get <service-mesh-crd-name> -n <crd-namespace>
```
```
NAME                                            ACTIVE   AGE
app-namespace/app-name                          True     1h
```

これらのステップが完了すると、サービス・メッシュ・リソースをコンソールで使用できます。

サービス・メッシュ・バインディング・リソース

次のステップでは、サービス・メッシュ・コントロール・プレーン・リソースをインフラストラクチャにバインドします(この場合、Kubernetesクラスタのポッド)。このバインディング・リソースにより、プロキシ・ソフトウェアの自動サイドカー・インジェクションおよびポッド検出が可能になります。リソースのバインディングの詳細は、アーキテクチャおよび概念を参照してください。

バインディング・リソースは次のとおりです。

仮想デプロイメント・バインディング: 4つの仮想デプロイメント・バインディング・リソースを作成して、コントロール・プレーン内の4つの仮想デプロイメントのそれぞれを、それらの仮想デプロイメントを表す対応するポッドに関連付けます。
Ingress Gateway Deployment: 1つのイングレス・ゲートウェイ・デプロイメントを作成して、コントロール・プレーンに定義されているイングレス・ゲートウェイをデプロイします。

次のコマンドを実行して、Kubernetesネームスペースでサイドカー・インジェクションが有効になっていることを確認します。サイドカー・インジェクションを有効にしない場合、プロキシはアプリケーション・ポッドに注入されません。

kubectl label namespace app-namespace servicemesh.oci.oracle.com/sidecar-injection=enabled

次に、次のコマンドを使用して、Kubernetesサービスおよびデプロイメントをサービス・メッシュにバインドします:

kubectl apply -f bind.yaml

サンプルbind.yamlファイル

リソースのバインディング構成を持つサンプルのYAMLファイルを次に示します。

---
kind: VirtualDeploymentBinding
apiVersion: servicemesh.oci.oracle.com/v1beta1
metadata:
  name: ms1-binding
  namespace: app-namespace
spec:
  virtualDeployment:
    ref:
      name: ms1
      namespace: app-namespace
 
  target:
    service:
      ref:
        name: ms1
        namespace: app-namespace
---
kind: VirtualDeploymentBinding
apiVersion: servicemesh.oci.oracle.com/v1beta1
metadata:
  name: ms2-v1-binding
  namespace: app-namespace
spec:
  virtualDeployment:
    ref:
      name: ms2-v1
      namespace: app-namespace
 
  target:
    service:
      ref:
        name: ms2
        namespace: app-namespace
      matchLabels:
        version: v1
---
kind: VirtualDeploymentBinding
apiVersion: servicemesh.oci.oracle.com/v1beta1
metadata:
  name: ms2-v2-binding
  namespace: app-namespace
spec:
  virtualDeployment:
    ref:
      name: ms2-v2
      namespace: app-namespace
 
  target:
    service:
      ref:
        name: ms2
        namespace: app-namespace
      matchLabels:
        version: v2
---
kind: VirtualDeploymentBinding
apiVersion: servicemesh.oci.oracle.com/v1beta1
metadata:
  name: ui-binding
  namespace: app-namespace
spec:
  virtualDeployment:
    ref:
      name: ui
      namespace: app-namespace
 
  target:
    service:
      ref:
        name: ui
        namespace: app-namespace
---
apiVersion: servicemesh.oci.oracle.com/v1beta1
kind: IngressGatewayDeployment
metadata:
  name: app-name-ingress-gateway-deployment
  namespace: app-namespace
spec:
  ingressGateway:
    ref:
      name: app-name-ingress-gateway
      namespace: app-namespace
  deployment:
    autoscaling:
      minPods: 1
      maxPods: 1
  ports:
    - protocol: TCP
      port: 9080
      serviceport: 443
  service:
    type: ClusterIP
---

mTLSおよびルーティングポリシーの詳細については、次を参照してください。

mTLS設定については、Using mTLS with Service Meshを参照してください。
ルーティング・ポリシーの詳細は、仮想サービスでのトラフィックのルーティングを参照してください。

サービス・メッシュ・イングレス・ゲートウェイの使用

これまで、イングレス・ゲートウェイを設定してデプロイしましたが、受信トラフィックをリダイレクトする必要があります。KubernetesクラスタにタイプLoadBalancerのイングレス・サービスがある場合、イングレス・ゲートウェイを指すように更新する必要があります。

kubectl apply -f ingress.yaml

サンプルingress.yamlファイル

次に、サンプルのYAMLファイル・イングレス・ゲートウェイ構成情報を示します。

apiVersion: v1
kind: Service
metadata:
  name: application-ingress
  namespace: app-namespace
spec:
  ports:
  - port: 80
    targetPort: 9080
    name: http
  selector:
    servicemesh.oci.oracle.com/ingress-gateway-deployment: app-name-ingress-gateway-deployment
  type: LoadBalancer
---

サービス・メッシュのエグレス・トラフィックの有効化

サービス・メッシュからの送信エグレス・トラフィックを許可するには、アクセス・ポリシーを構成する必要があります。エグレス・アクセス・ポリシーを作成するには、kubectl applyコマンドを使用します。次に例を示します。

kubectl apply -f egress-access-policy.yaml

次のサンプルのyaml構成ファイルでは、エグレス・アクセス・ポリシーを作成します。ポリシーでは、2つのエグレス・ルール(1つはHTTP用、もう1つはHTTPS用)を定義します。外部サービスの場合、HTTP、HTTPSおよびTCPの3つのプロトコルがサポートされています。プロトコルは、KubernetesのhttpExternalService、httpsExternalServiceおよびtcpExternalServiceキーと相関しています。エントリごとにホスト名とポートを指定できます。

サンプルのegress- access- policy.yamlファイル

アクセス・ポリシーを使用してエグレスを構成するサンプルのYAMLファイルを次に示します。

apiVersion: servicemesh.oci.oracle.com/v1beta1
kind: AccessPolicy
metadata:
  name: <sample-access-policy>      # Access Policy name
  namespace: <sample-namespace>
spec:
  compartmentId: ocid1.compartment.oc1..aaa...
  name: sample-ap     # Access Policy name inside the mesh
  description: This Access Policy
  mesh:
    ref:
      name: <sample-mesh>
  rules:
     - action: ALLOW
      source:
        virtualService:
          ref:
            name: <vs-sample-page>
      destination:
        externalService:
          httpExternalService:
            hostnames: ["example.com"]
            ports: [80]
    - action: ALLOW
      source:
        virtualService:
          ref:
            name: <vs-sample-page>
      destination:
        externalService:
          httpsExternalService:
            hostnames: ["example.com"]
            ports: [443]

コンソールを使用したアクセス・ポリシーの作成の詳細は、アクセス・ポリシーの作成を参照してください。

kubectlを使用してアクセス・ポリシーを作成する方法の詳細は、kubectlを使用したアクセス・ポリシーの管理を参照してください。

メッシュへのロギング・サポートの追加

アプリケーションでサービス・メッシュがサポートされるようになったため、ロギング機能を追加できます。ロギング機能を追加すると、OCIロギング・サービスにログが表示されます。

ノート

インスタンスがロギングをサポートできるようにするポリシーを作成するには、サービス・メッシュに必要なポリシーの設定の手順に従います。

次に、アクセス・ログを格納するOCIロギング・サービスを設定します。ログ・グループおよびカスタム・ログを作成して、ログ・スクレイピングを設定します。

ログ・グループを作成します。

oci logging log-group create --compartment-id <your-compartment-ocid> --display-name <your-app-name>

新しいログ・グループのOCIDを取得します。
- コンソールから、「ロギング」の下の「監視および管理」に移動し、「ログ・グループ」を選択します。
- 前のステップで作成したログ・グループの名前をクリックします。
- 「OCID」フィールドを見つけて、「コピー」をクリックします。OCIDをテキスト・ファイルに保存します。

ログ・グループにカスタム・ログを作成します。

oci logging log create --log-group-id <your-log-group-ocid> --display-name <your-app-name>-logs --log-type custom

新しいログ・グループのOCIDを取得します。
- コンソールから、「ロギング」の下の「監視および管理」に移動し、「ログ」を選択します。
- 前の手順で作成したログの名前をクリックします。
- 「OCID」フィールドを見つけて、「コピー」をクリックします。OCIDをテキスト・ファイルに保存します。

システムで、次のサンプル・ファイルを使用してlogconfig.json構成ファイルを作成します。カスタム・ログのOCIDをlogObjectIdフィールドに入力します。

{
  "configurationType": "LOGGING",
    "destination": {
      "logObjectId": "<your-custom-log-ocid>"
    },
    "sources": [
      {
        "name": "proxylogs",
        "parser": {
          "fieldTimeKey": null,
          "isEstimateCurrentEvent": null,
          "isKeepTimeKey": null,
          "isNullEmptyString": null,
          "messageKey": null,
          "nullValuePattern": null,
          "parserType": "NONE",
          "timeoutInMilliseconds": null,
          "types": null
        },
        "paths": [
          "/var/log/containers/*<app-namespace>*oci-sm-proxy*.log"
        ],
        "source-type": "LOG_TAIL"
      }
    ]
}

プロキシ・コンテナのログ・ファイルをスクレイプするカスタム・エージェント構成を作成します。

oci logging agent-configuration create --compartment-id <your-compartment-ocid> --is-enabled true --service-configuration file://your-log-config.json --display-name <your-app-name>LoggingAgent --description "Custom agent config for mesh" --group-association '{"groupList": ["<your-dynamic-group-ocid>"]}'

ノート

ログの構成方法の詳細は、エージェント管理: エージェント構成の管理を参照してください

アプリケーション・モニタリングおよびグラフ・サポートの追加

アプリケーションのKubernetes監視およびグラフ・サポートを追加するには、前提条件に指定されているPrometheusおよびGrafanaがインストールされている必要があります。また、Service Meshプロキシからスクレイピング・メトリックを有効にするようにPrometheusを構成する必要があります。

サービス・メッシュ・プロキシは、/stats/prometheusエンドポイントのメトリックを公開します。プロメテウス・サービスのClusterRoleを作成する場合は、「nonResourceURLs」に/stats/prometheusを含めます。次のClusterRole構成例を参照してください。

サンプルClusterRole

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: prometheus
rules:
  - apiGroups:
      - ""
    resources:
      - nodes
      - nodes/proxy
      - nodes/metrics
      - services
      - endpoints
      - pods
      - ingresses
      - configmaps
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - "extensions"
      - "networking.k8s.io"
    resources:
      - ingresses/status
      - ingresses
    verbs:
      - get
      - list
      - watch
  - nonResourceURLs:
      - "/stats/prometheus"
    verbs:
      - get
---

スクレイプ・ジョブの追加

プロメテウス・スクレイプ構成の一部として、サービス・メッシュ・プロキシ・エンドポイントからメトリックをスクレイプするジョブを追加する必要があります。次のscrape_configの例を参照してください。

サンプルscrape_config

scrape_configs:
  - job_name: 'kubernetes-pods'
 
    metrics_path: /stats/prometheus
    kubernetes_sd_configs:
    - role: pod
 
    relabel_configs:
    - source_labels: [__meta_kubernetes_namespace]
      action: replace
      target_label: kubernetes_namespace
    - source_labels: [__meta_kubernetes_pod_name]
      action: replace
      target_label: kubernetes_pod_name

詳細情報

メッシュリソースの管理の詳細については、次を参照してください。

次: Kubernetesサービス・メッシュのOCIサービス・オペレータの構成

Oracle Cloud Infrastructureドキュメント