Service Mesh - Istio实战篇（下）

上篇：

Service Mesh - Istio实战篇（上）

收集指标并监控应用

在可观察性里，指标是最能够从多方面去反映系统运行状况的。因为指标有各种各样，我们可以通过多维数据分析的方式来对系统的各个维度进行一个测量和监控。

Istio 默认是通过自带的 Promethuse 和 Grafana 组件来完成指标的收集和展示，但是监控系统这样的基础工具，通常在每个公司的生产环境上都是必备的，所以如果使用 Istio 自带的组件就重复了。

因此把现有的监控系统和 Istio 整合在一起是最好的解决方案。所以本小节就演示下用现有的监控系统和 Istio 进行一个指标收集方面的整合。

Istio 的指标接口

首先，我们需要了解 Istio 是怎么把它的指标暴露出来的。它主要提供了以下两个指标接口：

/metrics：提供 Istio 自身运行状况的指标信息
/stats/prometheus：Envoy 提供的接口，可获取网络流量相关的指标

我们可以请求 /stats/prometheus 接口查看它提供的指标数据：

$ kubectl exec -it -n demo ${sleep_pod_name} -c sleep -- curl http://httpbin.demo:15090/stats/prometheus

istiod 服务的 /metrics 接口暴露了控制平面的一些指标，我们可以通过如下方式获取到：

$ kubectl exec -it -n demo ${sleep_pod_name} -c sleep -- curl http://istiod.istio-system:15014/metrics

Prometheus 配置方式

サービスメッシュ-Istio実用章（パート2）

静态配置局限性比较大，不能很好的适应变化，所以一般都是使用动态配置的方式

支撑动态配置的基础是 Prometheus 的服务发现机制：

服务发现机制可以保证 Prometheus 能够通过服务暴露出来的接口来找到这些对应指标提供的接口
kubernetes_sd_config.role 配置项定义了对哪些目标进行指标收集
- node：集群节点
- service：服务，常用于黑盒监控
- pod：以pod中容器为目标
- endpoints：端点
- ingress：入口网关
relabel_configs 配置项定义了过滤机制，用于对暴露出来的接口进行过滤

实战

我们先来搭建一个监控系统，然后与 Istio 进行整合。首先部署 Prometheus ，具体的配置清单内容如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: prometheus
  namespace: monitoring
  labels:
    app: prometheus
spec:
  selector:
    matchLabels:
      app: prometheus
  template:
    metadata:
      labels:
        app: prometheus
    spec:
      serviceAccount: appmesh-prometheus
      serviceAccountName: appmesh-prometheus
      containers:
      - image: prom/prometheus:latest
        name: prometheus
        command:
        - "/bin/prometheus"
        args:
        - "--config.file=/etc/prometheus/prometheus.yml"
        - "--storage.tsdb.path=/prometheus"
        - "--storage.tsdb.retention=24h"
        - "--web.enable-admin-api"  
        - "--web.enable-lifecycle"  
        ports:
        - containerPort: 9090
          protocol: TCP
          name: http
        volumeMounts:
        - mountPath: /etc/prometheus
          name: config-volume
        - mountPath: /prometheus/data
          name: data-volume
        resources:
          requests:
            cpu: 100m
            memory: 512Mi
          limits:
            cpu: 100m
            memory: 512Mi
      securityContext:
        runAsUser: 0
      volumes:
      - configMap:
          name: prometheus-config
        name: config-volume
      - emptyDir: {}
        name: data-volume
---
apiVersion: v1
kind: Service
metadata:
  name: prometheus
  namespace: monitoring
  labels:
    app: prometheus
spec:
  selector:
    app: prometheus
  type: NodePort
  ports:
    - name: web
      port: 9090
      targetPort: http
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: appmesh-prometheus
  namespace: monitoring
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  namespace: monitoring
  name: appmesh-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:
      - "/metrics"
    verbs:
      - get
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: appmesh-prometheus
subjects:
  - kind: ServiceAccount
    name: appmesh-prometheus
    namespace: monitoring
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: appmesh-prometheus

PrometheusConfigMapを作成します。

apiVersion: v1
kind: ConfigMap
metadata:
  name: prometheus-config
  namespace: monitoring
data:
  prometheus.yml: |
    global:
      scrape_interval: 15s
      scrape_timeout: 15s
    scrape_configs:
    - job_name: 'prometheus'
      static_configs:
      - targets: ['localhost:9090']

次に、Grafanaをデプロイします。構成リストは次のとおりです。

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: grafana
  name: grafana
  namespace: monitoring
spec:
  replicas: 1
  selector:
    matchLabels:
      app: grafana
  template:
    metadata:
      labels:
        app: grafana
    spec:
      containers:
      - name: grafana
        image: grafana/grafana:latest
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 3000
          name: grafana
        env:
        - name: GRAFANA_PORT
          value: "3000"
        - name: GF_AUTH_BASIC_ENABLED
          value: "false"
        - name: GF_AUTH_ANONYMOUS_ENABLED
          value: "true"
        - name: GF_AUTH_ANONYMOUS_ORG_ROLE
          value: Admin
        resources:
          limits:
            cpu: 100m
            memory: 256Mi
          requests:
            cpu: 100m
            memory: 256Mi
        volumeMounts:
          - mountPath: /var/lib/grafana
            name: grafana-storage
      volumes:
        - name: grafana-storage
          emptyDir: {}
---
apiVersion: v1
kind: Service
metadata:
  name: grafana
  namespace: monitoring
  labels:
    app: grafana
spec:
  selector:
    app: grafana
  type: NodePort
  ports:
    - name: http
      port: 3000
      targetPort: 3000
      nodePort: 32000
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: grafana
  namespace: monitoring

すべてが正常に開始されたことを確認します。

[root@m1 ~]# kubectl get all -n monitoring 
NAME                             READY   STATUS    RESTARTS   AGE
pod/grafana-86f5dc96d-6hsmz      1/1     Running   0          20m
pod/prometheus-9dd6bd8bb-wcdrw   1/1     Running   0          2m30s

NAME                 TYPE       CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
service/grafana      NodePort   10.101.215.111   <none>        3000:32000/TCP   20m
service/prometheus   NodePort   10.101.113.122   <none>        9090:31053/TCP   13m

NAME                         READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/grafana      1/1     1            1           20m
deployment.apps/prometheus   1/1     1            1           13m

NAME                                   DESIRED   CURRENT   READY   AGE
replicaset.apps/grafana-86f5dc96d      1         1         1       20m
replicaset.apps/prometheus-9dd6bd8bb   1         1         1       13m
[root@m1 ~]#

どの作業ノードのプロメテウスとグラファナがスケジュールされているかを確認します。

[root@m1 ~]# kubectl get po -l app=grafana -n monitoring -o jsonpath='{.items[0].status.hostIP}'
192.168.243.139
[root@m1 ~]# kubectl get po -l app=prometheus -n monitoring -o jsonpath='{.items[0].status.hostIP}'
192.168.243.139

ブラウザを使用してプロメテウスにアクセスし、その構成コンテンツが期待を満たしているかどうか、つまり、ConfigMapのコンテンツに対応できるかどうかを確認します。
サービスメッシュ-Istio実用章（パート2）

上の図から、現在プロメテウスが静的に構成されていることがわかります。次に、プロメテウスを動的構成に変更し、次のようにConfigMapコンテンツを変更する必要があります。

apiVersion: v1
kind: ConfigMap
metadata:
  name: prometheus-config
  namespace: monitoring
data:
  prometheus.yml: |-
    global:
      scrape_interval: 15s
      scrape_timeout: 15s
    scrape_configs:
    - job_name: 'prometheus'
      static_configs:
      - targets: ['localhost:9090']

    # 以下是整合Istio的配置
    - job_name: envoy-stats
      honor_timestamps: true
      metrics_path: /stats/prometheus
      scheme: http
      kubernetes_sd_configs:
      - role: pod
      relabel_configs:
      - source_labels: [__meta_kubernetes_pod_container_port_name]
        separator: ;
        regex: .*-envoy-prom
        replacement: $1
        action: keep
      - source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
        separator: ;
        regex: ([^:]+)(?::\d+)?;(\d+)
        target_label: __address__
        replacement: $1:15090
        action: replace
      - separator: ;
        regex: __meta_kubernetes_pod_label_(.+)
        replacement: $1
        action: labeldrop
      - source_labels: [__meta_kubernetes_namespace]
        separator: ;
        regex: (.*)
        target_label: namespace
        replacement: $1
        action: replace
      - source_labels: [__meta_kubernetes_pod_name]
        separator: ;
        regex: (.*)
        target_label: pod_name
        replacement: $1
        action: replace

ヒント：ここでのConfigMap構成コンテンツは、Istioによって公式に提供されているPrometheus構成ファイルからコピーされたものであり、構成はバージョンごとに異なる場合があります。パスは次のとおりです。$ISTIO_HOME/samples/addons/prometheus.yaml

次に、patchコマンドを使用してプロメテウスを再構築します。

[root@m1 ~]# kubectl patch deployment prometheus -n monitoring -p "{\"spec\":{\"template\":{\"metadata\":{\"labels\":{\"date\":\"`date +'%s'`\"}}}}}"
deployment.apps/prometheus patched
[root@m1 ~]#

構成が有効になっているかどうかを確認します。
サービスメッシュ-Istio実用章（パート2）

この時点で、Istioのメトリックをプロメテウスで照会できます。
サービスメッシュ-Istio実用章（パート2）

Grafanaの場合、Istioの組み込みダッシュボードをエクスポートしてから、別のGrafanaにインポートするだけで済みます。これは比較的単純で、デモンストレーションは行いません。

統合されたELKスタックログスイート

分散システムでは、アプリケーションによって生成されたログが各ノードに分散されるため、表示と管理に非常に不利です。したがって、一般に集中ログアーキテクチャを使用して、ログデータをログプラットフォームに集約して統合管理を行います。最も広く知られているログプラットフォームはELKスタックです。

一元化されたログアーキテクチャ

サービスメッシュ-Istio実用章（パート2）

主な機能：

収集する
扱う
見せびらかす

ELKスタックログアーキテクチャ

サービスメッシュ-Istio実用章（パート2）

ElasticSearch：データの保存と検索を担当します
Logstash：データ収集パイプラインを担当し、フィルタリングおよび前処理機能を提供します
Kibana：データのグラフ化に使用
LibBeats：軽量データコレクター

ELK展開フォーム

サービスメッシュ-Istio実用章（パート2）

実際の戦闘

次に、ELKスイートをインストールして、IstioEnvoyログデータを収集します。まず、クラスターに名前名を作成します。

[root@m1 ~]# kubectl create ns elk
namespace/elk created
[root@m1 ~]#

次に、次の構成チェックリストを使用して、ElasticSearchとKibanaを展開します。

kind: List
apiVersion: v1
items:
- apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: kibana
  spec:
    selector:
      matchLabels:
        app: kibana
    replicas: 1
    template:
      metadata:
        name: kibana
        labels:
          app: kibana
      spec:
        containers:
        - image: docker.elastic.co/kibana/kibana:6.4.0
          name: kibana
          env:
          - name: ELASTICSEARCH_URL
            value: "http://elasticsearch:9200"
          ports:
          - name: http
            containerPort: 5601
- apiVersion: v1
  kind: Service
  metadata:
    name: kibana
  spec:
    type: NodePort
    ports:
    - name: http
      port: 5601
      targetPort: 5601 
      nodePort: 32001
    selector:
      app: kibana            
- apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: elasticsearch
  spec:
    selector:
      matchLabels:
        app: elasticsearch
    replicas: 1
    template:
      metadata:
        name: elasticsearch
        labels:
          app: elasticsearch
      spec:
        initContainers:
        - name: init-sysctl
          image: busybox
          command:
          - sysctl
          - -w
          - vm.max_map_count=262144
          securityContext:
            privileged: true
        containers:
        - image: docker.elastic.co/elasticsearch/elasticsearch:6.4.0
          name: elasticsearch
          env:
          - name: network.host
            value: "_site_"
          - name: node.name
            value: "${HOSTNAME}"
          - name: discovery.zen.ping.unicast.hosts
            value: "${ELASTICSEARCH_NODEPORT_SERVICE_HOST}"
          - name: cluster.name
            value: "test-single"
          - name: ES_JAVA_OPTS
            value: "-Xms128m -Xmx128m"
          volumeMounts:
          - name: es-data
            mountPath: /usr/share/elasticsearch/data
        volumes:
          - name: es-data
            emptyDir: {}
- apiVersion: v1
  kind: Service
  metadata: 
    name: elasticsearch-nodeport
  spec:
    type: NodePort
    ports:
    - name: http
      port: 9200
      targetPort: 9200
      nodePort: 32002
    - name: tcp
      port: 9300
      targetPort: 9300
      nodePort: 32003
    selector:
      app: elasticsearch
- apiVersion: v1
  kind: Service
  metadata:
    name: elasticsearch
  spec:
    clusterIP: None
    ports:
    - name: http
      port: 9200
    - name: tcp
      port: 9300
    selector:
      app: elasticsearch

展開する名前を指定します。

[root@m1 ~]# kubectl apply -f elk/deploy.yaml -n elk 
deployment.apps/kibana created
service/kibana created
deployment.apps/elasticsearch created
service/elasticsearch-nodeport created
service/elasticsearch created
[root@m1 ~]#

上記はelasticsearchとkibanaのみをデプロイしますが、Envoyログを収集する場合は、LogstashまたはFileBeatsもデプロイする必要があります。ここでは、FileBeatsを例として使用します。構成リストは次のとおりです。

kind: List
apiVersion: v1
items:
- apiVersion: v1
  kind: ConfigMap
  metadata:
    name: filebeat-config
    labels:
      k8s-app: filebeat
      kubernetes.io/cluster-service: "true"
      app: filebeat-config
  data:
    filebeat.yml: |
      processors:
        - add_cloud_metadata:
      filebeat.modules:
      - module: system
      filebeat.inputs:
      - type: log
        paths:
          - /var/log/containers/*.log
        symlinks: true
      output.elasticsearch:
        hosts: ['elasticsearch:9200']
      logging.level: info        
- apiVersion: apps/v1
  kind: Deployment 
  metadata:
    name: filebeat
    labels:
      k8s-app: filebeat
      kubernetes.io/cluster-service: "true"
  spec:
    selector:
      matchLabels:
        app: filebeat
    replicas: 1
    template:
      metadata:
        name: filebeat
        labels:
          app: filebeat
          k8s-app: filebeat
          kubernetes.io/cluster-service: "true"
      spec:
        containers:
        - image: docker.elastic.co/beats/filebeat:6.4.0
          name: filebeat
          args: [
            "-c", "/home/filebeat-config/filebeat.yml",
            "-e",
          ]
          securityContext:
            runAsUser: 0
          volumeMounts:
          - name: filebeat-storage
            mountPath: /var/log/containers
          - name: varlogpods
            mountPath: /var/log/pods
          - name: varlibdockercontainers
            mountPath: /var/lib/docker/containers
          - name: "filebeat-volume"
            mountPath: "/home/filebeat-config"
        volumes:
          - name: filebeat-storage
            hostPath:
              path: /var/log/containers
          - name: varlogpods
            hostPath:
              path: /var/log/pods
          - name: varlibdockercontainers
            hostPath:
              path: /var/lib/docker/containers
          - name: filebeat-volume
            configMap:
              name: filebeat-config
- apiVersion: rbac.authorization.k8s.io/v1
  kind: ClusterRoleBinding
  metadata:
    name: filebeat
  subjects:
  - kind: ServiceAccount
    name: filebeat
    namespace: elk
  roleRef:
    kind: ClusterRole
    name: filebeat
    apiGroup: rbac.authorization.k8s.io
- apiVersion: rbac.authorization.k8s.io/v1
  kind: ClusterRole
  metadata:
    name: filebeat
    labels:
      k8s-app: filebeat
  rules:
  - apiGroups: [""] # "" indicates the core API group
    resources:
    - namespaces
    - pods
    verbs:
    - get
    - watch
    - list
- apiVersion: v1
  kind: ServiceAccount
  metadata:
    name: filebeat
    namespace: elk
    labels:
      k8s-app: filebeat

すべてのコンポーネントが正常にデプロイされたことを確認します。

[root@m1 ~]# kubectl get all -n elk 
NAME                                 READY   STATUS    RESTARTS   AGE
pod/elasticsearch-697c88cd76-xvn4j   1/1     Running   0          4m53s
pod/filebeat-8646b847b7-f58zg        1/1     Running   0          32s
pod/kibana-fc98677d7-9z5dl           1/1     Running   0          8m14s

NAME                             TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                         AGE
service/elasticsearch            ClusterIP   None            <none>        9200/TCP,9300/TCP               8m14s
service/elasticsearch-nodeport   NodePort    10.96.106.229   <none>        9200:32002/TCP,9300:32003/TCP   8m14s
service/kibana                   NodePort    10.105.91.140   <none>        5601:32001/TCP                  8m14s

NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/elasticsearch   1/1     1            1           8m14s
deployment.apps/filebeat        1/1     1            1           32s
deployment.apps/kibana          1/1     1            1           8m14s

NAME                                       DESIRED   CURRENT   READY   AGE
replicaset.apps/elasticsearch-697c88cd76   1         1         1       4m53s
replicaset.apps/filebeat-8646b847b7        1         1         1       32s
replicaset.apps/kibana-fc98677d7           1         1         1       8m14s
[root@m1 ~]#

Kibanaに移動して、単純なインデックスパターンを作成します。
サービスメッシュ-Istio実用章（パート2）

作成した：
サービスメッシュ-Istio実用章（パート2）

次に、FileBeatによって収集され、ElasticSearchに保存されたログデータを[検出]ページで表示できます。
サービスメッシュ-Istio実用章（パート2）

統合された分散追跡ツール

Istioの分散追跡

Istioの分散トレースはEnvoyに基づいて実装されています
アプリケーションはトレースヘッダー情報（b3トレースヘッダー）の送信を担当するため、アプリケーションに対して完全に透過的ではなく、アプリケーションはヘッダーを単独で渡す必要があります。
b3この情報ヘッダーはopenzipkinによって最初に提案されました：https：//github.com/openzipkin/b3-propagation
サンプリングレートをサポート

Envoyに基づく分散トレースのプロセスは次のとおりです。
サービスメッシュ-Istio実用章（パート2）

まず、Envoyプロキシを通過するリクエストのRequestIdと、情報ヘッダーであるTraceHeaderを生成します。
リクエストとレスポンスのメタデータに基づいて対応するTraceSpanを生成し、スパンをトレースバックエンドに送信します
最後に、Traceヘッダーがエージェントのアプリケーションノードに転送されます

イエーガーを配備する

次に、Operatorを使用してJaegerをインストールし、Istioが既存の分散追跡システムとどのように統合されるかを示します。オペレーターを簡単に見てみましょう。

Kubernetesアプリケーションを展開および管理するためのツールキット
クラスタにデプロイし、KubernetesAPIを使用してアプリケーションを管理します
オペレーターフレームワーク
- オペレーターSDK
- オペレーターライフサイクルマネージャー

まず、jaeger-operatorリポジトリのクローンを作成します。

[root@m1 ~]# cd /usr/local/src
[root@m1 /usr/local/src]# git clone https://github.com/jaegertracing/jaeger-operator.git

設定ファイルを変更し、WATCH_NAMESPACEされてvalue、それはすべての名前空間内の要求を追跡することができるように、nullに設定します。

[root@m1 /usr/local/src]# vim jaeger-operator/deploy/operator.yaml
...
        env:
        - name: WATCH_NAMESPACE
          value:
...

イェーガーのcrdを作成します。

[root@m1 /usr/local/src]# kubectl apply -f jaeger-operator/deploy/crds/jaegertracing.io_jaegers_crd.yaml 
customresourcedefinition.apiextensions.k8s.io/jaegers.jaegertracing.io created
[root@m1 /usr/local/src]#

次に、名前を作成し、この名前の下に他のイエーガーリソースを作成します。

$ kubectl create ns observability
$ kubectl apply -f jaeger-operator/deploy/role.yaml -n observability 
$ kubectl apply -f jaeger-operator/deploy/role_binding.yaml -n observability 
$ kubectl apply -f jaeger-operator/deploy/service_account.yaml -n observability 
$ kubectl apply -f jaeger-operator/deploy/cluster_role.yaml -n observability
$ kubectl apply -f jaeger-operator/deploy/cluster_role_binding.yaml -n observability
$ kubectl apply -f jaeger-operator/deploy/operator.yaml -n observability

オペレーターが正常に起動したことを確認します。

[root@m1 /usr/local/src]# kubectl get all -n observability 
NAME                                   READY   STATUS    RESTARTS   AGE
pod/jaeger-operator-7f76698d98-x9wkh   1/1     Running   0          105s

NAME                              TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)             AGE
service/jaeger-operator-metrics   ClusterIP   10.100.189.227   <none>        8383/TCP,8686/TCP   11s

NAME                              READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/jaeger-operator   1/1     1            1           105s

NAME                                         DESIRED   CURRENT   READY   AGE
replicaset.apps/jaeger-operator-7f76698d98   1         1         1       105s
[root@m1 /usr/local/src]#

カスタムリソースであるイェーガーをインストールすると、オペレーターはカスタムリソースを介してイェーガーを自動的に展開します。

[root@m1 /usr/local/src]# kubectl apply -f jaeger-operator/examples/simplest.yaml -n observability 
jaeger.jaegertracing.io/simplest created
[root@m1 /usr/local/src]# kubectl get jaegers -n observability 
NAME       STATUS    VERSION   STRATEGY   STORAGE   AGE
simplest   Running   1.21.0    allinone   memory    3m8s
[root@m1 /usr/local/src]#

イエーガーはIstioを統合します

Jaegerが展開されたら、次のステップはそれをIstioと統合することです。統合は非常に簡単で、istioctlいくつかの構成変数ツールを設定するだけで済みます。コマンドは次のとおりです。

[root@m1 ~]# istioctl install --set profile=demo -y \
--set values.global.tracer.zipkin.address=simplest-collector.observability:9411 \
--set values.pilot.traceSampling=100

ヒント：profile値は、Istioのインストール時に設定された値に設定する必要があります。そうしないと、Istioはデフォルト値に従って再インストールされます。

JaegerがIstioを統合した後、最後のステップが残っています。Jaegerのエージェントをアプリケーションに注入する必要があります。JaegerOperatorは自動インジェクションをサポートしています。Annotationにインジェクションフラグを追加するだけで済みます。

また、Istioのトレースはアプリケーションに対して完全に透過的ではないことにも言及しました。アプリケーションで、トレースヘッダーを自分で処理する必要があります。したがって、テストの便宜のために、公式のBookinfoアプリケーションをデモンストレーションとして使用します。Bookinfoのデプロイ：

[root@m1 ~]# kubectl apply -f /usr/local/istio-1.8.1/samples/bookinfo/platform/kube/bookinfo.yaml
[root@m1 ~]# kubectl apply -f /usr/local/istio-1.8.1/samples/bookinfo/networking/bookinfo-gateway.yaml

Jaegerは、インジェクションまたはDeployment、Deployment to productこの例の名前付けをサポートしています。彼の注釈sidecar.jaegertracing.io/inject: "true"に、次の行を追加するだけで済みます。

[root@m1 ~]# kubectl edit deployments.apps/productpage-v1
apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    sidecar.jaegertracing.io/inject: "true"

    ...

次に、patchコマンドを使用して製品ページを再構築します。

[root@m1 ~]# kubectl patch deployment productpage-v1 -p "{\"spec\":{\"template\":{\"metadata\":{\"labels\":{\"date\":\"`date +'%s'`\"}}}}}"
deployment.apps/productpage-v1 patched
[root@m1 ~]#

この時点で、製品ページポッド内のコンテナの数が3つに増えたことを確認できます。これは、イエーガーがエージェントをポッドに注入したことを示しています。

[root@m1 ~]# kubectl get pods
NAME                              READY   STATUS    RESTARTS   AGE
productpage-v1-5c75dcd69f-g9sjh   3/3     Running   0          96s
...

次のコマンドを使用して、JaegerのWebUIアクセスポートを開きます。

[root@m1 ~]# kubectl port-forward svc/simplest-query -n observability 16686:16686 --address 192.168.243.138
Forwarding from 192.168.243.138:16686 -> 16686

Jaegerがproductpageサービスを検出できたことをページで確認できます。
サービスメッシュ-Istio実用章（パート2）

デバッグツールと方法：グリッドをデバッグするためのツールと方法は何ですか？

Istioの一般的なデバッグ方法には、主に次のものがあります。

istioctlコマンドライン
controlZコントロールプレーンのセルフチェックツール
エンボイ管理インターフェース
パイロットデバッグインターフェイス

istioctlコマンドライン

--helpパラメータを使用して、istioctlコマンドのヘルプ情報を確認できます。

$ istioctl --help

インストールと展開に関連

istioctl verify-install：現在のk8sクラスター環境がIstioをデプロイできるかどうかを確認するために使用できます
istioctl install [flags]：現在のクラスターにIstio環境をインストールするために使用されます
istioctl profile [list / diff / dump]：Istioのプロファイルの操作
istioctl kube-inject：Envoyサイドカーをポッドに注入するために使用されます
istioctl dashboard [command]：指定されたIstioダッシュボードWebUIを起動します
- controlz / envoy / Grafana / jaeger / kiali / Prometheus / zipkin

グリッド構成ステータスチェック

istioctl ps <pod-name>：グリッド構成の同期ステータスを表示します。いくつかの状態があります：
- 同期済み：構成が同期されています
- 送信されません：構成は発行されません
- STALE：構成は配信されましたが、ポッドは動作に応答しませんでした
istioctl pc [cluster/route/…] <pod-name.namespace>：指定したリソースのグリッド構成の詳細を取得します

ポッド関連のグリッド構成情報を表示する

istioctl x（ experimental ）describe pod <pod-name>：

グリッド内にあることを確認します
VirtualServiceを確認します
DestinationRuleを確認します
ルーティングを確認する
…

例：

[root@m1 ~]# istioctl x describe pod productpage-v1-65576bb7bf-4bwwr
Pod: productpage-v1-65576bb7bf-4bwwr
   Pod Ports: 9080 (productpage), 15090 (istio-proxy)
--------------------
Service: productpage
   Port: http 9080/HTTP targets pod port 9080

Exposed on Ingress Gateway http://192.168.243.140
VirtualService: bookinfo
   /productpage, /static*, /login, /logout, /api/v1/products*
[root@m1 ~]#

グリッド構成診断

istioctl analyze [–n <namespace> / --all-namespaces]：指定された名前名の下のグリッド構成を確認してください。問題がある場合は、対応する警告またはエラーメッセージが表示されます。
istioctl analyze a.yaml b.yaml my-app-config/：ディレクトリ内の単一の構成ファイルまたはすべての構成ファイルを確認します
istioctl analyze --use-kube=false a.yaml：デプロイメントプラットフォームを無視して、指定された構成ファイルを確認してください

controlZビジュアルセルフチェックツール

controlZは、コントロールプレーンの視覚的なセルフチェックツールです。主な機能は次のとおりです。

ログ出力レベルを調整します
メモリ使用量を表示する
環境変数を表示する
プロセス情報を表示する

使用法は次のとおりです。

istioctl d controlz <istiod-podname> -n istio-system

サービスメッシュ-Istio実用章（パート2）

Envoy管理APIインターフェイス

Envoy admin APIは、データプレーンを表示および操作できます。主な機能は、次のとおりです。

ログレベルの調整
パフォーマンスデータ分析
構成およびその他の情報
インジケータービュー

次のコマンドを使用して、指定したポッドのEnvoy adminAPIを開きます。

istioctl d envoy <pod-name>.[namespace] --address ${ip}

または、次の方法でポートを開きます。

kubectl port-forward <pod-name> 15000:15000 ${ip}

そのページは次のとおりです。
サービスメッシュ-Istio実用章（パート2）

パイロットデバッグインターフェイス

パイロットデバッグインターフェイスの主な機能は次のとおりです。

xDSおよび構成情報
パフォーマンス問題の分析
同期を構成する

次のコマンドを使用して、ポートを開きます。

kubectl port-forward service/istiod -n istio-system 15014:15014 --address ${ip}

そのページは次のとおりです。
サービスメッシュ-Istio実用章（パート2）