Kubernetesと サービスメッシュの 素敵な関係

• これからクラウドネイティブに取り組みたい企業と、クラウドネイティブの先進企業 の交流によって、中⽴に、企業情報システムが新たな段階に踏み出すことを⽀ 援するコミュニティです。 • コンテナとKubernetes導入で成果を上げている先進企業と、検討中の情報 システム部門の方々が出会うミートアップイベントを開催します。 • 情報システム部門の⽴場でコンテナの導入を検討する中で、課題を感じている 方を対象に、既に成果を収めている先進企業の方々から話を聞いて、対話し て、参考にできるイベントを目指します。さまざまな方の活動経験や知見を共有 いただけるように進めますので、是非、奮ってご参加ください。 CNBF（Cloud Native Bright Future） https://cnbfmeetup.connpass.com/

お話する人 IBM Cloud / © 2020 IBM Corporation 3 所属 日本アイ・ビー・エム株式会社 クラウド＆コグニティブソフトウェア事業部 ハイブリッドクラウド CTO 高良 真穂 著書 コンテナとKubernetesの利用価値を 理解し活用してもらうため、 エンジニア育成、お客様へのご進講、 執筆活動を推進しています。 韓国語に 翻訳され ました

要旨 Kubernetesを利用するにあたって、外すことができない必須ア イテムの一つがサービスメッシュです。 サービスメッシュの３大機能は、トラフィック制御、セキュリ ティとアクセス制御、そして、状態の可視化（可観測性）があり ます。 従来のイングレスコントローラーから、サービスメッシュ(Istio) に置き換えることで、システム監視の質を向上させることができ ます。 システム監視のゴールデンシグナルの対応、OAuth2との連携と アクセスコントロール、そして、カナリアリリースついて解説し ます。

サービスメッシュを 理解するための 基礎知識

クライアントのリクエストをポッドへ伝えるには？ • NodePort • LoadBalancer • Ingress • ServiceMesh アプリのユーザーは ポッドの中のコンテナ内の アプリへアクセスしている。 ポッド 豆がコンテナに相当 ネットワーク K8sのサービスを外部へ公開する方法3種

Kubernetesの基本（リクエストがコンテナに届くまでの過程） Pod Service (Cluster IP) controller nodeport Load balancer container Pod Service (Cluster IP) controller container マイクロサービス A マイクロサービス B Load balancer xxxx container K8sクラスタ外の機器／ソフト K8sのAPIオブジェクト コンテナ化アプリケーション 凡例 アプリのユーザー

Kubernetesの基本（リクエストがコンテナに届くまでの過程） Pod Service (Cluster IP) controller nodeport Load balancer container Pod Service (Cluster IP) controller container マイクロサービス A マイクロサービス B アプリのユーザー KubernetesクラスタのプライベートIP範囲 外部 パブリックIP範囲

Kubernetesのネットワーク・モデルは Node1 Node2 EXTERNAL-IPの ネットワーク INTERNAL-IPの ネットワーク Pod Pod Pod ポッドが接続される ネットワーク ポッドのIPアドレスをリスト ノードのIPアドレスをリスト Kubernetesのネットワークモデル

Kubernetesのネットワーク・モデルは Node1 Node2 EXTERNAL-IPの ネットワーク INTERNAL-IPの ネットワーク Pod Pod Pod ポッドが接続される ネットワーク LoadBalancer LoadBalancer NodePort LoadBalancer Ingress ServiceMesh 繋がりが解らん！ LBはK8sの外側

NodePortとは Pod Pod Pod kube-proxy kube-proxy ノードのIPアドレス+ポート番号 ポッドのIPアドレス + コンテナのポート番号 コンテナ TCP/UDPポート番号 コンテナ Node1 Node2 service K8s-APIオブジェクト リクエストトラフィック クライアント NodePortは、ノードのIPに ポートを開くの解ったけど Nodeが止まったらアクセス できないよね。不便だな コンテナ TCP/UDPポート番号 コンテナ EXTERNAL-IPの ネットワーク Node1-IP:30318 80 80 Node2-IP:30318 Pod-X-IP:80 Pod-X-IP:80

LoadBalancer の役割 Pod Pod Pod kube-proxy kube-proxy ノードのIPアドレス+ポート番号 ポッドのIPアドレス + コンテナのポート番号 コンテナ TCP/UDPポート番号 コンテナ Node1 Node2 service K8s-APIオブジェクト リクエストトラフィック クライアント リクエストトラフィックを ロードバランサのVIPで受けて、 NodePortに転送 なんでノードでロードバランス しないの？ コンテナ TCP/UDPポート番号 コンテナ EXTERNAL-IPの ネットワーク Node1-IP:30318 80 80 Node2-IP:30318 Pod-X-IP:80 Pod-X-IP:80 LoadBalancer LoadBalancer NodePortヘリクエストを 振り分ける

K8sクラスタの内部は専用プライベートN/Wであり、パブリックN/Wと経路情報は共有さ れない。つまり、NodePortとLoadBalancerは、外部からのリクエストトラフィックを導 くうえで必須の機能となる。 Pod Pod Pod kube-proxy kube-proxy ノードのIPアドレス+ポート番号 ポッドのIPアドレス + コンテナのポート番号 コンテナ TCP/UDPポート番号 コンテナ Node1 Node2 service K8s-APIオブジェクト リクエストトラフィック クライアント コンテナ TCP/UDPポート番号 コンテナ EXTERNAL-IPの ネットワーク Node1-IP:30318 80 80 Node2-IP:30318 Pod-X-IP:80 Pod-X-IP:80 LoadBalancer LoadBalancer K8sクラスタの内部ネットワーク 外部パブリック ネットワーク （プライベートネットワーク）

kube-proxyはL4レベルのLBでランダムに振り分け YAML kube- apiserver Service IPVS iptables proxy Linux Kernel 設定実施 kube-proxy 択一 kubectl L３レベルの 負荷分散設定

イングレスとの関係は？

IngressはL7のLB（OpenShiftではRouter） • Ingress Controllerは、NodePortの後ろ側でリバースプロキシーとしてL7のロードバランシングを担当する （L7はHTTPヘッダーのリライトなどの機能を有する） • IngressコントローラーはServiceの情報から対象のポッドのIPを調べて、リクエストをダイレクトに分配する ことで、セッション固定やHTTPヘッダーのリライトが可能となる。 Ingress Controller service pod kube-proxy kube-proxy kube-proxy kube-proxy pod NodePortに負荷分散 etcd

サービスメッシュ

クライアントのリクエストをポッドへ伝えるには？ • NodePort • LoadBalancer • Ingress • ServiceMesh アプリのユーザーは ポッドの中のコンテナ内の アプリへアクセスしている。 ポッド 豆がコンテナに相当 ネットワーク K8sのサービスを外部へ公開する方法3種

サービスメッシュは注目の機能 Red Hat OpenShift Service Mesh は、 IstioをベースにRed Hatが保守

サービスメッシュの３大機能 •トラフィック管理 •認証・認可とアクセス制御 •状態の可視化（可観測性）

トラフィック管理(Istio) • Ingress Gateway 外部からのリクエストを内部へ • Egress Gateway 内部から外部サービスへ • Virtual Service他 内部のトラフィック管理 Ingress Gateway 内部 トラフィック 管理 Egress Gateway 外部 サービス コンテナ化 アプリ コンテナ化 アプリ クライアント

Istio Ingress GWによる アプリの公開 apiVersion: networking.istio.io/v1beta1 kind: Gateway metadata: name: httpbin-gateway spec: selector: istio: ingressgateway servers: - port: number: 80 name: http protocol: HTTP hosts: - "*" --- apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: httpbin spec: hosts: - "*" gateways: - httpbin-gateway http: - route: - destination: host: httpbin port: number: 8000 Ingress Gateway Virtual Service Service コンテナ化 アプリ Pod Deployment Controller apiVersion: networking.istio.io/v1beta1 kind: Gateway metadata: name: httpbin-gateway spec: selector: istio: ingressgateway servers: - port: number: 80 name: http protocol: HTTP hosts: - "*" --- サービスの名前 Isito Ingress コントローラ と対応づけ 任意のDNS名を受け取る 参照

apiVersion: networking.istio.io/v1beta1 kind: Gateway metadata: name: httpbin-gateway spec: selector: istio: ingressgateway servers: - port: number: 80 name: http protocol: HTTP hosts: - "*" --- apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: httpbin spec: hosts: - "*" gateways: - httpbin-gateway http: - route: - destination: host: httpbin port: number: 8000 apiVersion: networking.istio.io/v1beta1 kind: Gateway metadata: name: httpbin-gateway spec: selector: istio: ingressgateway servers: - port: number: 80 name: http protocol: HTTP hosts: - "*" --- サービスの名前 任意のDNS名を受け取る 参照 デプロイの流れ $ istioctl kube-inject -f httpbin.yaml | kubectl apply -f - serviceaccount/httpbin created service/httpbin created deployment.apps/httpbin created $ kubectl apply -f httpbin-gateway.yaml gateway.networking.istio.io/httpbin-gateway created virtualservice.networking.istio.io/httpbin created $ kubectl get gw NAME AGE httpbin-gateway 9s $ kubectl get vs NAME GATEWAYS HOSTS AGE httpbin ["httpbin-gateway"] ["*"] 14s $ kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE httpbin ClusterIP 10.32.0.186 8000/TCP 49s kubernetes ClusterIP 10.32.0.1 443/TCP 11h $ kubectl get pod -n istio-system -l istio=ingressgateway NAME READY STATUS RESTARTS AGE istio-ingressgateway-69c597589-bpz9q 1/1 Running 0 10h (1)アプリのデプロイでは明示的にサイドカーを注入する (2)Istio Ingress GWとVirtualServiceのデプロイ (3)Istio Ingress GWの稼働を確認 (4)仮想サービスの稼働を確認 (5)サービスの稼働を確認 (6)IstioのIngress Gateway本体の稼働を確認

Ingress と Istio の違い • Kubernetes API オブジェクトのIngress（左側）は、リバースプロキシとして動作して、PodへのL7 ロードバランスを実施する。サービス(オブジェクト)を読取って、ラベルの一致するポッドへ転送する。 • Istio Ingress gateway (右側)も動作は基本的に同じ、Virtual Serviceが Istio Ingress Gatewayとサービ スを仲介する役割を果たす。要求トラフィックはProxyを介してポッド内コンテナへ届く Isito Ingress-Gateway (pod) service kube-proxy kube-proxy Isito virtual service Nginx Ingress Controller (pod) service kube-proxy kube-proxy pod pod Ingressを使用する場合 Istioを使用する場合 Ingress Isito Ingress Gateway コンテナ proxy Pod コンテナ proxy Pod

なんのため プロキシをする？

Isito ServiceMeshのアーキテクチャ

要求トラフィックの可視化を提供 •Proxyによってアプリを変更せずに可視化を実現

要求トラフィックの可視化を提供 • アプリがエラー応答を返していないことを一目で解る。 リクエストの 成功率 Virtual Serviceのアイコン GWを通過した 後から計測 Serviceのアイコン Podのアイコン アプリ本体は この中

アプリ運用品質に 重要なGolden Signalのうち 重要な3点が視覚化される SRE監視4大シグナル 1. レイテンシ 2. トラフィック 3. エラー 4. サチュレーション 応答時間 成功率 リクエストレート

Istio Ingress-gatewayの機能 •セッション・アフィニティ •バーチャルホスト •TLSターミネション

コンテナ Istio Proxy Pod Istio Ingress-gateway セッション維持機能 • 12-Factor-Appに準拠できないレガシーなウェブアプリはセッション維持機能が必須となる。 • K8sのServiceのCluster-IPではランダムな振り分けに限られ、対策としてIngressが利用される。 • Istioでも同様に、Istio Ingress-gateway によりセッション維持の機能実施する。 Service (Cluster IP) node port Load balancer Pod Pod ランダムな負荷分散 Service (LoadBalancer) Ingress -gateway (pod) HTTPヘッダーによる負荷分散 Istio Ingress -gateway (pod) Service Type = LoadBalancerのケース(L4ロードバランス） コンテナ Istio Proxy Pod イングレスのケース(L7ロードバランス） Istioのケース(L7ロードバランス） Service (Cluster IP) Pod node port Service (Cluster IP) Service (LoadBalancer) node port Pod Load balancer Load balancer HTTPヘッダーによる負荷分散

apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: session-gateway spec: selector: istio: ingressgateway servers: - port: number: 80 name: http protocol: HTTP hosts: - "*" コンテナ Istio Proxy Pod Istio Ingress-gateway セッション維持機能 Istio Ingress -gateway (pod) VirtualService Gateway コンテナ Istio Proxy Pod Service (Cluster IP) Service (LoadBalancer) apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: session spec: hosts: - "*" gateways: - session-gateway http: - match: - uri: prefix: "/user" rewrite: uri: "/" route: - destination: host: session-svc port: number: 9080 apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: session spec: host: session-svc trafficPolicy: loadBalancer: consistentHash: httpCookie: name: PHPSESSID ttl: 0s apiVersion: v1 kind: Service metadata: name: session-svc spec: selector: app: session ports: - name: http port: 9080 targetPort: 80 DestinationRule Application Istiod コントロールプレーン apiVersion: apps/v1 kind: Deployment metadata: name: session-deployment spec: replicas: 1 selector: matchLabels: app: session template: metadata: labels: app: session spec: containers: - image: 'maho/session-test:1.1' name: session ports: - containerPort: 80 セッション維持の Cookie名を設定する

Virtual HostはDNS名で転送先をアプリ変更する • 一つのアプリをデータやお化粧だけ変えて、複数の事業者へ提供したい。 コンテナ Istio Proxy Pod Istio Ingress -gateway (pod) コンテナ Istio Proxy Pod Service (Cluster IP) Service (LoadBalancer) node port Load balancer コンテナ Istio Proxy Pod コンテナ Istio Proxy Pod Service (Cluster IP) http://svc1.labo.com/ http://svc2.labo.com/ アプリ1 アプリ2

DNS名で転送先のアプリを結びつける • GWとVSにDNS名を設定、VSに宛先サービスの名前とポートを設定 apiVersion: networking.istio.io/v1beta1 kind: Gateway metadata: name: svc1-gateway spec: selector: istio: ingressgateway servers: - port: number: 80 name: http protocol: HTTP hosts: - "svc1.labo.local" apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: svc1 spec: hosts: - "svc1.labo.local" gateways: - svc1-gateway http: - route: - destination: host: webapl1 port: number: 8000 apiVersion: v1 kind: Service metadata: name: webapl1 labels: app: webapl1 service: webapl1 spec: ports: - name: http port: 8000 targetPort: 3000 selector: app: webapl1

外向けTLS暗号化を一括で終端したい • シークレットにTLS証明書を設定して、Istio Gatwayをデプロイすることで、TLS暗号を利用できる。 コンテナ Istio Proxy Pod Istio Ingress -gateway (pod) コンテナ Istio Proxy Pod Service (Cluster IP) Service (LoadBalancer) node port Load balancer アプリ パブリックネットワーク の通信を暗号化で保護 内部でも 暗号化で保護 （デフォルト） apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: mygateway spec: selector: istio: ingressgateway servers: - port: number: 443 name: https protocol: HTTPS tls: mode: SIMPLE credentialName: httpbin-credential hosts: - "*" プライベート認証局証明書作成 openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -subj '/O=labo. /CN=labo.local' -keyout labo.local.key -out labo.local.crt サーバー証明要求 openssl req -out httpbin.labo.local.csr -newkey rsa:2048 -nodes -keyout httpbin.labo.local.key -subj "/CN=istio- ingressgateway.istio-system.k8s1.labo.local/O=httpbin organization" 認証局署名 openssl x509 -req -days 365 -CA labo.local.crt -CAkey labo.local.key -set_serial 0 -in httpbin.labo.local.csr -out httpbin.labo.local.crt シークレット作成 kubectl create -n istio-system secret tls httpbin-credential --key=httpbin.labo.local.key --cert=httpbin.labo.local.crt 自己署名証明書の作成 TLSを終端するゲートウェイ

トラフィック管理(Istio) • Ingress Gateway 外部からのリクエストを内部へ • Egress Gateway 内部から外部サービスへ • Virtual Service他 内部のトラフィック管理 Ingress Gateway 内部 トラフィック 管理 Egress Gateway 外部 サービス コンテナ化 アプリ コンテナ化 アプリ クライアント

サービスメッシュから外部アクセスを制限 • Istioを管理するオペレーターから現状のYAMLを取り出し、外部向けトラ フィックのポリシーを変更することで、コンテナ内からの無許可のアクセ スを禁止できる。 • Service Entry にアクセス可能なサイトを記述できる • Egress-Gateway を通過するように設定すればKialiで厳格な管理も可能 Egress Gateway 外部 サービス K8sクラスタ kubectl -n istio-system get IstioOperator installed-state -o yaml > installed-state.yaml istioctl install -f installed-state.yaml --set meshConfig.outboundTrafficPolicy.mode=REGISTRY_ONLY service Entry

サービスメッシュから外部アクセスを制限 • Egress Gatewayを起動しなくても外部へのアクセス制限を設定できる • Service Entry に自K8sクラスタからアクセス可能なDNS名を設定する apiVersion: networking.istio.io/v1alpha3 kind: ServiceEntry metadata: name: webapl5 spec: hosts: - webapl5.default.k8s2.labo.local ports: - number: 8080 name: http protocol: HTTP resolution: DNS location: MESH_EXTERNAL コンテナ Istio Proxy Pod コンテナ Istio Proxy Pod Service (Cluster IP) アプリ コンテナ Istio Proxy Pod コンテナ Istio Proxy Pod Service (LoadBalancer) アプリ service Entry K8sクラスタ-k8s2 K8sクラスタ-k8s3

アウトバウンドトラフィックの可視化状況 トポロジー 応答時間やエラー率の時系列グラフ

トラフィック管理(Istio) • Ingress Gateway 外部からのリクエストを内部へ • Egress Gateway 内部から外部サービスへ • Virtual Service他 内部のトラフィック管理 Ingress Gateway 内部 トラフィック 管理 コンテナ化 アプリ コンテナ化 アプリ クライアント

内部トラフィック管理 • リクエストルーティング • リクエストをマイクロサービスの複数のバージョンに動的にルーティングする • トラフィックシフト • マイクロサービスのあるバージョンから別のバージョンにトラフィックを段階的に移行する • TCPトラフィックシフト • TCPトラフィックをあるバージョンから別のバージョンに段階的に移行する • フォールトインジェクション • 障害を注入してアプリケーションの復元力をテストする • リクエストのタイムアウト • Istioを使用してEnvoyでリクエストのタイムアウトを設定 • サーキットブレーカー • トラフィック遮断により、障害の影響、遅延スパイク、およびネットワークの特性によるその 他の望ましくない影響を制限する • ミラーリング • ミラーリングは、ライブトラフィックのコピーをミラーリングされたサービスに送信

Ver1へ80％そしてVer2に20％へトラフィックを流したい apiVersion: v1 kind: Namespace metadata: name: istio-apl # Istio管理対象の名前空間 labels: istio-injection: enabled # Istio-proxyサイドカーの自動注入 名前空間に対して、Isito-proxyの自動注入を設定できる。 Ingress Gateway 内部 トラフィック 管理 コンテナ化 アプリ ver1 コンテナ化 アプリ ver2 クライアント 80% 20%

内部トラフィック管理 ## サービス apiVersion: v1 kind: Service metadata: name: rest-apl namespace: istio-apl labels: app: rest-apl service: rest-apl spec: ports: - name: http port: 8080 targetPort: 4009 type: ClusterIP selector: app: rest-apl ## デプロイメント apiVersion: apps/v1 kind: Deployment metadata: name: rest-apl-v1 namespace: istio-apl labels: app: rest-apl version: v1 spec: replicas: 1 selector: matchLabels: app: rest-apl version: v1 template: metadata: labels: app: rest-apl version: v1 spec: containers: - name: rest-apl-v1 image: maho/simple:1.0 imagePullPolicy: Always env: - name: PORT value: "4009" ## デプロイメント apiVersion: apps/v1 kind: Deployment metadata: name: rest-apl-v2 namespace: istio-apl # Isito管理下の名前空間へ配置する labels: # コントローラーに対するラベルを設定 app: rest-apl version: v2 spec: replicas: 1 # ポッドのレプリカ数は１としておく selector: # コントローラーとポッドのラベルの一致条件 matchLabels: app: rest-apl version: v2 template: # これ以降はコントローラーが起動するポッドの雛形 metadata: # コントローラーとポッドの対応付のラベル labels: app: rest-apl version: v2 spec: containers: # アプリケーションのコンテナの仕様 - name: rest-apl-v2 image: maho/simple:2.0 # Docker Hubに登録した模擬アプリ imagePullPolicy: Always # キャッシュを使わず毎回ダウンロードする env: # 環境変数 ポッドのサーバーポート番号を指定する - name: PORT value: "4009" アプリ1 アプリ2 共通のサービス 赤文字部分で Isitoが参照するためのバージョンを識別するためのラベルを設定する。

内部トラフィック管理 apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: rest-apl-gateway namespace: istio-apl spec: selector: istio: ingressgateway # Istio イングレスゲートウェイのラベル servers: # サーバー仕様のリストを記述 - port: name: rest-apl # ポート番号ユニークな名前（オプション） number: 80 # イングレスゲートウェイの公開ポート番号 protocol: HTTP # プロトコル hosts: - "*" # ゲートウェイが受けるホスト名 apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: rest-apl-vs namespace: istio-apl spec: hosts: # 対象とするFQDNを指定する - "*" # ここでは任意のFQDNを受け入れる gateways: - rest-apl-gateway # 連携するゲートウェイObjectを設定 http: # URIのマッチングと、サービスへ転送のため書換え実施 - match: # ここでは /version -> / へ変更 - uri: prefix: "/version" rewrite: uri: "/" route: # ルート設定として、サービスrest-apl:8080 へ転送する - destination: host: rest-apl # 宛先サービス port: number: 8080 subset: v1 # 宛先ルールのサブセットを参照 weight: 80 # トラフィック分割の割合 - destination: host: rest-apl # 宛先サービス port: number: 8080 subset: v2 # 宛先ルールのサブセットを参照 weight: 20 # トラフィック分割の割合 # 宛先ルール apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: rest-apl namespace: istio-apl spec: host: rest-apl # 対象とするサービスの名前 trafficPolicy: # トラフィック管理の一つで、本文中で解説 loadBalancer: # 負荷分散のアルゴリズムを指定 simple: LEAST_CONN # リクエスト・トラフィックの分割先を指定する subsets: # 分割割合などをバーチャルサービスに記述する - name: v1 # rest-virtual-service-weighted.yamlを参照 labels: version: v1 # ポッドのラベルでありrest-deployment-v1.yamlを参照 - name: v2 labels: version: v2 # 同様に、rest-deployment-v2.yamlを参照 VirtualService Gateway DestinationRule

トラフィック分割状態 $ while true; do curl http://istio-ingressgateway.istio-system.k8s3.labo.local/version; sleep 1;done version: 2.0 version: 1.0 version: 1.0 version: 1.0 version: 1.0 version: 2.0 version: 1.0 version: 2.0 version: 2.0 version: 1.0

認証・認可とアクセス制御 • 証明書管理 • Istio認証局（CA）、証明書管理 • 認証 (Authentication) • ピア認証（相互TLS) • リクエスト認証 • 許可 (Authorization) • K8s名前空間に対するHTTP/HTTPS,TCPアクセス制御 • JWTによる認証とアクセス制御 • Ingress-GatewayでのIPベースのアクセス制御

47 Envoy プロキシ OAuth2 サーバー ①ログイン ②JWTトークン 準備段階で バリデーション用JWKS(鍵)を配布 ③アプリケーションへのアクセス ＋JWTトークン ④JWTトークンを JWKSで評価して認証 ⑤認証されたリクエスト トラフィックだけが到達 ポッド この方法のOauthサーバーの利点 • 外部のSaaSで良い • 性能ボトルネックになり難い • 単一障害点になり難い 認証と役割データ SaaS or 内製 ワークフローと連携した 社内システム OAuth2サーバーとの連携イメージ

JWTによる認証 apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: httpbin-gateway spec: selector: istio: ingressgateway servers: - port: number: 80 name: http protocol: HTTP hosts: - "*" --- apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: httpbin spec: hosts: - "*" gateways: - httpbin-gateway http: - route: - destination: host: httpbin port: number: 8000 apiVersion: "security.istio.io/v1beta1" kind: "RequestAuthentication" metadata: name: "jwt-example" namespace: istio-system spec: selector: matchLabels: istio: ingressgateway jwtRules: - issuer: "ISSUER" jwksUri: "http://auth-server.default.svc.labs.local:8000/jwks" apiVersion: "security.istio.io/v1beta1" kind: "AuthorizationPolicy" metadata: name: "frontend-ingress" namespace: istio-system spec: selector: matchLabels: istio: ingressgateway action: DENY rules: - from: - source: notRequestPrincipals: ["*"]

JWTによる認証 $ curl --header "Authorization: Bearer $TOKEN" -X GET http://istio-ingressgateway.istio-system.k8s1.labs.local/headers $ export TOKEN=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdWQiOiJ0YWthcmEiLCJleHAiOjE2MDgwMjA4MzYsImlhdCI6MTYwODAxMzYzNiwiaXNzIjoiSVNTV UVSIiwianRpIjoicHN1NHMtNDA4c3EtbjFQXzVGa29hdyIsIm5iZiI6MTYwODAxMzYzNiwicGVybWlzc2lvbiI6ImFsbCIsInJvbGUiOiJ1c2VyIiwic3ViIjoidGFrYXJhIn 0.bbFdubMw-tQCRbym2QK-1M14vTuYR0zmT0Y6HqxjZz-B0nmoI_m_LL34tRsV68teOrdQuT183hLLtkicwBtf0Fsx_kahW2QmiVJblWxIq_2CqZr3kwCxST7AqoVlywBg9Uv 40qVqfsIzQbDJsIgrT4qhrYyvAEykUKNdmnZOjfKXuQ_bJuOXEQV1SYuc4aYz7SlH5cR7ttQvOci53cTFKYld_zcr6k-nIjDSAeS0739ygjsyagGboTOuInzVTM9p1-6t1Y5Q rXKq7ZO4o00y0EMEoe5Pz4X6IYsuyojkWN3-zuR8dpffoNv9tAT3CYbSgVnzfUpeCQAlbTv692YMGA ①②ログインによりOAuth2サーバーから、JWTトークンを取得 ③トークンをHTTPヘッダーに付与してアクセスする。 Istio側でバリデーション用キーで認証

状態の可視化（可観測性） • メトリックス • TCPサービスのテレメトリを自動的に収集するようにIstioを構成 • Istioが生成するメトリックをカスタマイズ Grafana, Kiali, Prometheus • メッシュ内のサービスによって処理される要求と応答のタイプに基づいてテレメトリを視覚化 • Prometheusを使用してIstioメトリックをクエリ • Istioダッシュボードをセットアップしてメッシュトラフィックを監視 • ログ • Envoyプロキシは、アクセス情報を標準出力に出力 • Envoyのコンテナの標準出力をkubectl logsコマンドで出力 • 分散トレーシング • 分散トレースを使用すると、ユーザーは複数のサービスに分散されたメッシュを介してリクエストを追跡 できます。これにより、視覚化により、リクエストのレイテンシ、シリアル化、並列処理についてより深 く理解できます。 • Istioは、Envoyの分散トレース機能を活用して、すぐにトレース統合を提供 • Zipkin, Jeager, Lightstep • レポートされたスパンへのカスタムタグの追加など、高度なトレースオプションを構成する機能を提供 • メッシュの視覚化 • Kialiアドオンをインストールし、Webベースのグラフィカルユーザーインターフェイス

まとめ

まとめ • サービスメッシュの3大機能 • トラフィック管理 • 認証・認可とアクセス制御 • 状態の可視化（可観測性） • サービスメッシュで最も人気はIstio • アプリをマイクロサービス化してなくても利用可能 • K8s API Ingressコントローラーの代替として利用可能 • Isitoに変えた方が運用品質が向上するので変えるべき • 要求と応答状況をKialiを利用して視覚化 • ゴールデンシグナルの3つを監視 ✓ レイテンシ ✓ トラフィック ✓ エラー ✓ サチュレーション • OAuth2サーバーと連携した認証が可能 Isitoという小人たち はK8sの弱点を補いア プリの運用品質向上 に貢献する