Red Hat SummitOpenShift Service Mesh 3.0 is a Technology Preview feature only
Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. This documentation is a work in progress and might not be complete or fully tested.第1章 ゲートウェイについて
ゲートウェイは、スタンドアロンの Envoy プロキシーデプロイメントと、サービスメッシュのエッジで動作する関連する Kubernetes サービスです。ゲートウェイを設定すると、メッシュに出入りするトラフィックをきめ細かく制御できます。Red Hat OpenShift Service Mesh では、ゲートウェイインジェクションを使用してゲートウェイをインストールします。
1.1. ゲートウェイインジェクションについて
ゲートウェイインジェクションは、サイドカーインジェクションと同じメカニズムを利用して、Envoy プロキシーをゲートウェイ Pod に注入します。ゲートウェイインジェクションを使用してゲートウェイをインストールするには、Istio コントロールプレーンに表示される namespace に Kubernetes Deployment オブジェクトと関連する Kubernetes Service オブジェクトを作成します。Deployment オブジェクトを作成するときに、Istio コントロールプレーンがプロキシーを注入し、プロキシーがゲートウェイとして設定されるように、オブジェクトにラベルおよびアノテーションを付けます。ゲートウェイをインストールしたら、Istio Gateway と VirtualService リソースを使用して、Ingress と Egress トラフィックを制御するようにゲートウェイを設定します。
1.1.1. ゲートウェイインジェクションを使用したゲートウェイのインストール
この手順では、ゲートウェイインジェクションを使用してゲートウェイをインストールする方法を説明します。
この手順を使用して、Ingress または Egress ゲートウェイを作成できます。
前提条件
- OpenShift Service Mesh Operator バージョン 3.0 以降がインストールされている。
- Istio コントロールプレーンを作成している。
-
IstioCNIリソースを作成している。
手順
ゲートウェイのインストールに使用する namespace を作成します。
$ oc create namespace <gateway_namespace>
注記ゲートウェイと Istio コントロールプレーンを異なる namespace にインストールします。
ゲートウェイを専用のゲートウェイ namespace にインストールできます。このアプローチにより、異なる namespace で動作する多くのアプリケーションでゲートウェイを共有できるようになります。または、ゲートウェイをアプリケーション namespace にインストールすることもできます。このアプローチでは、ゲートウェイはその namespace 内のアプリケーション専用のゲートウェイとして機能します。
ゲートウェイデプロイメントのサービスアカウント、ロール、およびロールバインディングを定義する
secret-reader.ymlという名前の YAML ファイルを作成します。これらの設定により、ゲートウェイは TLS 認証情報を取得するために必要なシークレットを読み取ることができます。apiVersion: v1 kind: ServiceAccount metadata: name: secret-reader namespace: <gateway_namespace> --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: secret-reader namespace: <gateway_namespace> rules: - apiGroups: [""] resources: ["secrets"] verbs: ["get", "watch", "list"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: secret-reader namespace: <gateway_namespace> roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: secret-reader subjects: - kind: ServiceAccount name: secret-reader以下のコマンドを実行して、YAML ファイルを適用します。
$ oc apply -f secret-reader.yml
ゲートウェイの Kubernetes
Deploymentオブジェクトを定義する、gateway-deployment.ymlという名前の YAML ファイルを作成します。apiVersion: apps/v1 kind: Deployment metadata: name: <gateway_name> namespace: <gateway_namespace> spec: selector: matchLabels: istio: <gateway_name> template: metadata: annotations: inject.istio.io/templates: gateway 1 labels: istio: <gateway_name> 2 sidecar.istio.io/inject: "true" 3 spec: containers: - name: istio-proxy image: auto 4 securityContext: capabilities: drop: - ALL allowPrivilegeEscalation: false privileged: false readOnlyRootFilesystem: true runAsNonRoot: true ports: - containerPort: 15090 protocol: TCP name: http-envoy-prom resources: limits: cpu: 2000m memory: 1024Mi requests: cpu: 100m memory: 128Mi securityContext: sysctls: - name: net.ipv4.ip_unprivileged_port_start value: "0" serviceAccountName: secret-reader 5- 1
- Istio コントロールプレーンがデフォルトのサイドカーテンプレートではなく、ゲートウェイインジェクションテンプレートを使用することを示します。
- 2
- ゲートウェイのデプロイメントに一意のラベルが設定されていることを確認します。Istio
Gatewayリソースがゲートウェイワークロードを選択できるようにするには、一意のラベルが必要です。 - 3
sidecar.istio.io/injectラベルをtrueに設定して、ゲートウェイインジェクションを有効にします。Istio リソースの名前がdefaultでない場合は、代わりにistio.io/rev: <istio_revision>ラベルを使用する必要があります。ここで、リビジョンは Istio リソースのアクティブなリビジョンを表します。- 4
- Pod が起動するたびにイメージが自動的に更新されるように、イメージフィールドを
autoに設定します。 - 5
serviceAccountNameを、以前作成したServiceAccountの名前に設定します。
以下のコマンドを実行して、YAML ファイルを適用します。
$ oc apply -f gateway-deployment.yml
次のコマンドを実行して、ゲートウェイ
Deploymentロールアウトが正常に行れたことを確認します。$ oc rollout status deployment/<gateway_name> -n <gateway_namespace>
以下のような出力が表示されるはずです。
出力例
Waiting for deployment "<gateway_name>" rollout to finish: 0 of 1 updated replicas are available... deployment "<gateway_name>" successfully rolled out
ゲートウェイの Kubernetes
Serviceオブジェクトを含む、gateway-service.ymlという名前の YAML ファイルを作成します。apiVersion: v1 kind: Service metadata: name: <gateway_name> namespace: <gateway_namespace> spec: type: ClusterIP 1 selector: istio: <gateway_name> 2 ports: - name: status-port port: 15021 protocol: TCP targetPort: 15021 - name: http2 port: 80 protocol: TCP targetPort: 80 - name: https port: 443 protocol: TCP targetPort: 443
以下のコマンドを実行して、YAML ファイルを適用します。
$ oc apply -f gateway-service.yml
次のコマンドを実行して、ゲートウェイサービスがゲートウェイ Pod のエンドポイントをターゲットにしていることを確認します。
$ oc get endpoints <gateway_name> -n <gateway_namespace>
次の例のような出力が表示されるはずです。
出力例
NAME ENDPOINTS AGE <gateway_name> 10.131.0.181:8080,10.131.0.181:8443 1m
オプション: ゲートウェイの Horizontal Pod Autoscaler を定義する、
gateway-hpa.ymlという名前の YAML ファイルを作成します。次の例では、最小レプリカを2に、最大レプリカを5に設定し、平均 CPU 使用率が CPU リソース制限の 80% を超えたときにレプリカをスケールアップします。この制限は、ゲートウェイのデプロイメントの Pod テンプレートで指定されます。apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: <gateway_name> namespace: <gateway_namespace> spec: minReplicas: 2 maxReplicas: 5 metrics: - resource: name: cpu target: averageUtilization: 80 type: Utilization type: Resource scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: <gateway_name> 1- 1
spec.scaleTargetRef.nameを、以前作成したゲートウェイデプロイメントの名前に設定します。
オプション: 次のコマンドを実行して YAML ファイルを適用します。
$ oc apply -f gateway-hpa.yml
オプション: ゲートウェイの Pod Disruption Budget を定義する、
gateway-pdb.ymlという名前の YAML ファイルを作成します。次の例では、ゲートウェイ Pod のエビクション後も、クラスター上に少なくとも 1 つの正常なゲートウェイ Pod が残る場合にのみ、ゲートウェイ Pod のエビクションが許可されます。apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: <gateway_name> namespace: <gateway_namespace> spec: minAvailable: 1 selector: matchLabels: istio: <gateway_name> 1- 1
spec.selector.matchLabelsを、以前作成したゲートウェイデプロイメントの Pod テンプレートで指定された一意のラベルまたはラベルセットに設定します。
オプション: 次のコマンドを実行して YAML ファイルを適用します。
$ oc apply -f gateway-pdb.yml
