Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

Cloud Native 時代における GKE / Kubernetes ではじめる開発 @G...

Cloud Native 時代における GKE / Kubernetes ではじめる開発 @GDG DevFest Tokyo 2019 / dev-fest-tokyo-2019-k8s

https://tokyo.gdgjapan.org/devfest2019/session/masaya-aoyama

講演概要
CloudNative 時代における GKE/Kubernetes ではじめる開発
Dockerなどのコンテナ技術は広く普及し、コンテナオーケストレーションエンジンとしてはKubernetesがデファクトスタンダードとなりました。Kubernetes は Google が社内で 10 年以上利用していたクラスタマネージャ Borg が元となっています。GCP のマネージド Kubernetes サービス GKE(Google Kubernetes Engine) では利便性が高く、運用が楽になる機能も多いため、Kubernetesの 利用を始めやすくなっています。本セッションでは、CloudNative な開発には何が求められているのかから始まり、Kubernetes の基本的なコンセプト・基本機能・拡張性・将来性、また GKE 特有の機能について紹介します。セッション後には、Kubernetes 上で開発したくなっているでしょう。

Masaya Aoyama (@amsy810)

December 14, 2019
Tweet

More Decks by Masaya Aoyama (@amsy810)

Other Decks in Technology

Transcript

  1. Publicity (一部抜粋)   書籍 『Kubernetes 完全ガイド』 『みんなの Docker/K8s』  基調講演 『Japan

    Container Days v18.04』 『Google Cloud K8s Day』   招待講演 『情報処理学会 コンピュータシステムシンポジウム』         『AWS Dev Day Tokyo』 『IBM Think Japan』 『JEITA 委員会』   登壇 『KubeCon + CNCon China 2019』 『Open Source Summit 2019』 等  資格 『CKAD #2』 『CKA #138』 Masaya Aoyama (@amsy810) Infrastructure Engineer Community   Co-chair 『Cloud Native Days Tokyo (旧 Japan Container Days)』  Organizer 『Cloud Native Meetup Tokyo』   『Kubernetes Meetup Tokyo』   『KubeCon Japanese exchange meeting』   Contribute to OpenStack and Kubernetes 主業務: K8s as a Service の実装 K8s / CloudNative 関連のアーキテクト + CREATIONLINE / DENSO - 技術アドバイザ + SAKURA Internet Research Center – 客員研究員
  2. サイバーエージェントには、特定の分野に抜きん出た知識とスキルを持ち、その領域の第一人者として実 績を上げているエンジニアに、新たな活躍の場を提供するとともに、各専門領域において、その分野の発 展のための貢献および、サイバーエージェントグループに還元することを目的とした「Developer Experts 制度」があります。 「Developer Experts」の選出は、これまでの実績に基づいて、サイバーエージェントが注力する技術領域 から5名を選出しました。任命されたメンバーは、担当領域における、その技術や使われ方などについて 中立的な立場で発信することで、各担当領域の活性化に貢献することを目指します。 「Developer

    Experts」の5名には、大きく以下の3つの役割が任されています。 •  各専門領域において高い専門性を身につけ、その発展に貢献すること。 •  対外活動(登壇・コミュニティ活動・執筆・情報発信)を通して、各専門領域の発展に貢献すること。 •  各専門領域におけるサイバーエージェント全体の旗振り役として、管轄や事業部の垣根を超えて、担 当領域の相談を受けたりサポートすること。 これらの活動を支援するため、会社からは国内外を含む活動費のサポートを行い、全面的にバックアップ していきます。
  3. Agenda •  Kubernetes and Cloud Native •  疎結合性 •  管理容易性

    •  回復性 •  可観測性 •  堅牢な自動化と更新 •  スケーラビリティ •  Google Kubernetes Engine
  4. Docker ͱ͸ʁ Docker コンテナとは、アプリケーションバイナリ + 周辺の実行環境 作成したコンテナイメージを元に起動するため、基本的にどこでも同じように実行される  例) Ubuntu 18.04

    + Nginx サーバ  例) CentOS 8.0 + Go アプリケーション 軽量 ・ 高速な起動 ・ 低オーバーヘッド FROM golang:1.12.6 COPY main.go ./ RUN go build ./main.go –o main ENTRYPOINT ["main", "--args", "$ARG;"] 1. ΠϝʔδͷϏϧυ Dockerイメージ 2. Docker ίϯςφ ͷىಈ
  5. Kubernetes ͱ͸ʁ Kubernetes は複数のノードをマシンとして束ねて、 その上でコンテナをいい感じに起動させるオーケストレータ Google 社内で利用されていた クラスタマネージャ Borg が元になっている

    その他にも様々な機能 •  障害時のセルフヒーリング •  サービスディスカバリ •  ロードバランシング •  データや機密情報の管理 •  複数のDockerホストの管理 •  コンテナのスケジューリング •  スケーリング / オートスケーリング •  ローリングアップデート •  コンテナの死活監視
  6. CNCF and The Linux Foundation •  Kubernetes はThe Linux Foundationの

    サブプロジェクトであるCNCFによってホスト •  その他にも多くのプロジェクトを ホストしている
  7. Cloud Nativeͱ͸ʁ Cloud native technologies empower organizations to build and

    run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach. These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil. The Cloud Native Computing Foundation seeks to drive adoption of this paradigm by fostering and sustaining an ecosystem of open source, vendor-neutral projects. We democratize state-of-the-art patterns to make these innovations accessible for everyone. CNCF Cloud Native Defenition v1.0, CNCF, 2018-11-28 (https://github.com/cncf/toc/blob/master/DEFINITION.md)
  8. Cloud Nativeͱ͸ʁ Cloud native technologies empower organizations to build and

    run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach. These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil. The Cloud Native Computing Foundation seeks to drive adoption of this paradigm by fostering and sustaining an ecosystem of open source, vendor-neutral projects. We democratize state-of-the-art patterns to make these innovations accessible for everyone. CNCF Cloud Native Defenition v1.0, CNCF, 2018-11-28 (https://github.com/cncf/toc/blob/master/DEFINITION.md) •  疎結合なシステム •  回復性がある •  管理しやすい •  可観測である •  堅牢な自動化により、頻繁かつ期待通りに最 小限の労力で大きな変更が可能 OpenかつScalableなシステムを実現
  9. Cloud Native ͸ Kubernetesʁ 誤解されることがあるので改めて伝えますが、「違います」 Kubernetes != Cloud Native • 

    Kubernetes を使うだけで Cloud Native になるわけではない •  もちろんレール(お作法)に乗ることで近づきはします •  VM でも Cloud Native な開発をすることも可能です •  その他のマネージド・サービスを利用して Cloud Native な開発にすることも可能です •  CloudRun、Cloud Functions
  10. マイクロサービス毎に技術選定可能 gRPC, REST 等でマイクロサービス間を繋ぐことで、 各サービスの技術選定の自由度が高い デプロイが容易 小さい機能単位でデプロイが可能なため、 高速かつ影響範囲が少ない 大規模な開発を加速させる 各部門が特定のマイクロサービスを開発することで全体が成立

    機能追加も比較的しやすい スケーリングが容易 特定の機能だけスケーリングさせるため効率が良い 障害が全体に波及しづらい 特定の機能に障害が起きた場合でも、 縮退した状態でサービス継続を行いやすい Benefit of Microservice Golang Java Scala gRPC REST
  11. マイクロサービス毎に技術選定可能 gRPC, REST 等でマイクロサービス間を繋ぐことで、 各サービスの技術選定の自由度が高い デプロイが容易 小さい機能単位でデプロイが可能なため、 高速かつ影響範囲が少ない 大規模な開発を加速させる 各部門が特定のマイクロサービスを開発することで全体が成立

    機能追加も比較的しやすい スケーリングが容易 特定の機能だけスケーリングさせるため効率が良い 障害が全体に波及しづらい 特定の機能に障害が起きた場合でも、 縮退した状態でサービス継続を行いやすい Developer Benefit of Microservice
  12. マイクロサービス毎に技術選定可能 gRPC, REST 等でマイクロサービス間を繋ぐことで、 各サービスの技術選定の自由度が高い デプロイが容易 小さい機能単位でデプロイが可能なため、 高速かつ影響範囲が少ない 大規模な開発を加速させる 各部門が特定のマイクロサービスを開発することで全体が成立

    機能追加も比較的しやすい スケーリングが容易 特定の機能だけスケーリングさせるため効率が良い 障害が全体に波及しづらい 特定の機能に障害が起きた場合でも、 縮退した状態でサービス継続を行いやすい Benefit of Microservice
  13. マイクロサービス毎に技術選定可能 gRPC, REST 等でマイクロサービス間を繋ぐことで、 各サービスの技術選定の自由度が高い デプロイが容易 小さい機能単位でデプロイが可能なため、 高速かつ影響範囲が少ない 大規模な開発を加速させる 各部門が特定のマイクロサービスを開発することで全体が成立

    機能追加も比較的しやすい スケーリングが容易 特定の機能だけスケーリングさせるため効率が良い 障害が全体に波及しづらい 特定の機能に障害が起きた場合でも、 縮退した状態でサービス継続を行いやすい Benefit of Microservice
  14. マイクロサービス毎に技術選定可能 gRPC, REST 等でマイクロサービス間を繋ぐことで、 各サービスの技術選定の自由度が高い デプロイが容易 小さい機能単位でデプロイが可能なため、 高速かつ影響範囲が少ない 大規模な開発を加速させる 各部門が特定のマイクロサービスを開発することで全体が成立

    機能追加も比較的しやすい スケーリングが容易 特定の機能だけスケーリングさせるため効率が良い 障害が全体に波及しづらい 特定の機能に障害が起きた場合でも、 縮退した状態でサービス継続を行いやすい Benefit of Microservice
  15. Declarative Code and APIs Developer Register YAML Manifest Kubernetes Cluster

    構成情報はManifestsで宣言的に記述してAPIに登録 Infrastructure as Code $ kubectl apply –f manifest.yaml
  16. 起動したコンテナには ラベル が付与されている Kubernetes や周辺エコシステムでは ラベルを元に様々な処理を⾏う apiVersion: apps/v1 kind: Deployment

    metadata: name: sample-deployment spec: replicas: 3 template: metadata: labels: {app: a} spec: containers: - name: app-container image: app:A LoadBalancer ͱͷ࿈ܞ
  17. LoadBalancer ͱͷ࿈ܞ ⾃動的に LoadBalancer を作成し、⾃動的に連携を⾏う •  コンテナやノードの追加時にも⾃動的にメンバ更新 •  ローリングアップデート時のメンバ管理 開発者も管理が可能

    apiVersion: v1 kind: Service metadata: name: sample-svc spec: type: LoadBalancer ports: - name: "http-port" protocol: "TCP" port: 8080 targetPort: 80 selector: app: a LB app: a
  18. L7 LoadBalancer ࿈ܞ L7 LoadBalancer も Manifest で管理 •  ホスト名

    •  パス •  証明書 apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: name: sample-ingress spec: rules: - host: sample.example.com http: paths: - path: /path1/* backend: serviceName: sample-ingress-svc-1 servicePort: 8888 - path: /path2/* backend: serviceName: sample-ingress-svc-2 servicePort: 8888 tls: - hosts: - sample.example.com secretName: tls-sample Kubernetes L7 LB appA appB appC appA appA appC appB appC appC
  19. L7 LoadBalancer ࿈ܞ 証明書はすべて Secret リソースで管理 更新はファイルを変更して 「kubectl apply」で登録するだけ apiVersion:

    v1 kind: Secret metadata: name: tls-sample type: kubernetes.io/tls data: tls.crt: LS0tLS1CRUd...= tls.key: LS0tLS1CRUd...= apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: name: sample-ingress spec: rules: - host: sample.example.com http: paths: - path: /path1/* backend: serviceName: sample-ingress-svc-1 servicePort: 8888 - path: /path2/* backend: serviceName: sample-ingress-svc-2 servicePort: 8888 tls: - hosts: - sample.example.com secretName: tls-sample
  20. IP Address ͷ؅ཧ͔Βͷղ์ Kubernetes では IP Address を⼀切管理しない Kubernetes 内部の通信は

    サービスディスカバリによって成⽴ apiVersion: v1 kind: Service metadata: name: sample-svc spec: type: LoadBalancer ports: - name: "http-port" protocol: "TCP" port: 8080 targetPort: 80 selector: app: a LB (name: sample-svc) http://sample-svc.default.svc.cluster.local
  21. IP Address ͷ؅ཧ͔Βͷղ์ Kubernetes 外部の通信も external-dns を利⽤して グローバル IP と外部

    DNS に⾃動登録させることが可能 1.  ロードバランサにグローバル IP が⾃動的に払い出される 2.  外部の DNS に⾃動的にグローバル IP と登録 LB xxx.xxx.xxx.xxx 外部 DNS
  22. IP Address ͷ؅ཧ͔Βͷղ์ Kubernetes 外部の通信も external-dns を利⽤して グローバル IP と外部

    DNS に⾃動登録させることが可能 1.  ロードバランサにグローバル IP が⾃動的に払い出される 2.  外部の DNS に⾃動的にグローバル IP と登録 LB xxx.xxx.xxx.xxx 外部 DNS amsy.dev => xxx.xxx.xxx.xxx
  23. IP Address ͷ؅ཧ͔Βͷղ์ Kubernetes 外部の通信も external-dns を利⽤して グローバル IP と外部

    DNS に⾃動登録させることが可能 1.  ロードバランサにグローバル IP が⾃動的に払い出される 2.  外部の DNS に⾃動的にグローバル IP と登録 さらに cert-manager を利⽤することで ACME を利⽤して証明書の⾃動発⾏/更新も可能 LB xxx.xxx.xxx.xxx 外部 DNS amsy.dev => xxx.xxx.xxx.xxx
  24. Kubernetes では あるべき理想の状態(Desired State)へと収束させる 何か問題が発⽣した場合でも、Reconcile loop により セルフヒーリングされる ※ 厳密には

    Controller も API を⽤いて変更します。 reconcile() { … } 登録 (via API Request) Watch クラスタの状態 コンテナの作成・削除 Controller 登録された時に、ただ起動させるだけではない ࣗಈճ෮ɾηϧϑώʔϦϯά
  25. Kubernetes の内部には様々な Controller と呼ばれるプログラムが動作している Reconcile loop(調整ループ)とは、Controller 内で実⾏されている あるべき状態へと収束させるループ処理 のこと Observe

    Diff Act Observe: 現状を確認 Diff: 理想と現実の差分を計算 Act: 差分に対する処理を実施 reconcile() { … } Controller ࣗಈճ෮ɾηϧϑώʔϦϯά
  26. ࣗಈճ෮ɾηϧϑώʔϦϯά 例えば、コンテナ(Pod)を 3 つ起動させる ReplicaSet リソースの場合 Observe Diff Act Observe:

    現状を確認 Diff: 理想と現実の差分を計算 Act: 差分に対する処理を実施 クラスタの状態 理想の状態 reconcile() { … } Controller
  27. ࣗಈճ෮ɾηϧϑώʔϦϯά たとえば 2 つしかコンテナ(Pod)が起動していない場合… Observe: 理想=3、現状=2 Observe Diff Act Observe:

    現状を確認 Diff: 理想と現実の差分を計算 Act: 差分に対する処理を実施 クラスタの状態 理想の状態 reconcile() { … } Controller
  28. ࣗಈճ෮ɾηϧϑώʔϦϯά たとえば 2 つしかコンテナ(Pod)が起動していない場合… Diff: 1 つコンテナ(Pod)が⾜りない Observe Diff Act

    Observe: 現状を確認 Diff: 理想と現実の差分を計算 Act: 差分に対する処理を実施 クラスタの状態 理想の状態 reconcile() { … } Controller
  29. ࣗಈճ෮ɾηϧϑώʔϦϯά たとえば 2 つしかコンテナ(Pod)が起動していない場合… Act: 1つ nginx:1.12 のコンテナ(Pod)を作成する Observe Diff

    Act Observe: 現状を確認 Diff: 理想と現実の差分を計算 Act: 差分に対する処理を実施 クラスタの状態 理想の状態 reconcile() { … } Controller
  30. ʰX as a Service ج൫ʱͱͯ͠ͷ Kubernetes Platform for Platform • 

    Database as a Service on Kubernetes •  Queue as a Service on Kubernetes •  Serverless as a Service on Kubernetes •  ML as a Service on Kubernetes oracle/mysql-operator 『障害時のクラスタ復旧』 『バックアップなどの運用』 を自動化(マネージド)
  31. ʰX as a Service ج൫ʱͱͯ͠ͷ Kubernetes Kubernetes は ⼩さなクラウド に近い

    oracle/mysql-operator 『障害時のクラスタ復旧』 『バックアップなどの運用』 を自動化(マネージド) Relational DB Key Value Store Document DB Queue Developer
  32. ʰ෼ࢄγεςϜϑϨʔϜϫʔΫʱͱͯ͠ͷ Kubernetes Kubernetes のコアは『Decralative API 』と『分散システムフレームワーク』 ※ 厳密には Controller も

    API を⽤いて変更します。 reconcile() { … } 登録 (via API Request) 監視 MySQL Cluster の管理 reconcile() { … } Controller 独⾃のリソースに対してどのような処理をするか Controller を書くことで運⽤が容易に (運⽤ナレッジのプログラム化)
  33. Kubernetes の場合にはマニフェストを書き換えて 「kubectl apply」コマンドで再適⽤するだけ あとは Kubernetes が⾃動的にアップデート処理を⾏う Kubernetes appA:1 appA:1

    LB appA:1 apiVersion: apps/v1 kind: Deployment metadata: name: sample-deployment spec: replicas: 3 strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 0 maxSurge: 1 template: spec: containers: - name: app-container image: app:A1 ϩʔϦϯάΞοϓσʔτ
  34. ϩʔϦϯάΞοϓσʔτ Kubernetes appA:1 appA:1 apiVersion: apps/v1 kind: Deployment metadata: name:

    sample-deployment spec: replicas: 3 strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 0 maxSurge: 1 template: spec: containers: - name: app-container image: appA:2 LB appA:2 Kubernetes の場合にはマニフェストを書き換えて 「kubectl apply」コマンドで再適⽤するだけ あとは Kubernetes が⾃動的にアップデート処理を⾏う
  35. ैདྷͷ CI / CD Code Repository S3 / etc CI

    - test, build VM CD - Deploy v1 v2 v3
  36. ίϯςφͷ৔߹ͷ CI / CD Code Repository Docker Registry CI -

    test, build Kubernetes CI - update manifests Manifest Repository CD - depoy v1 v2 v3 v1 v2 v3 GItOps の場合:
  37. GitOps Overview ϚχϑΣετ リポジトリ ΞϓϦέʔγϣϯ リポジトリ CI CD コンテナ レジストリ

    Kubernetes クラスタ マニフェストの 書き換え(PR) アプリケーションのテスト Dockerイメージのビルド イメージの保存 マニフェストの適⽤(デプロイ) Developer
  38. GitOps - Staging ϚχϑΣετ リポジトリ (staging) ΞϓϦέʔγϣϯ リポジトリ CI CD

    コンテナ レジストリ Staging クラスタ マニフェストの 書き換え(PR) アプリケーションのテスト Dockerイメージのビルド イメージの保存 マニフェストの適⽤ Developer staging branch master branch ϚχϑΣετ リポジトリ (production) Production クラスタ
  39. GitOps - Production ϚχϑΣετ リポジトリ (staging) ΞϓϦέʔγϣϯ リポジトリ CI CD

    コンテナ レジストリ マニフェストの 書き換え(PR) アプリケーションのテスト Dockerイメージのビルド イメージの保存 Developer staging branch master branch ϚχϑΣετ リポジトリ (production) Staging クラスタ マニフェストの適⽤ Production クラスタ
  40. GitOps ϚχϑΣετ リポジトリ (staging) ΞϓϦέʔγϣϯ リポジトリ CI CD コンテナ レジストリ

    Developer staging branch master branch ϚχϑΣετ リポジトリ (production) Staging クラスタ マニフェストの適⽤ Production クラスタ アプリケーションエンジニアから⾒ると  ブランチの状態 = デプロイされているアプリケーション  (アプリのコミットハッシュでイメージのタグが付与) インフラエンジニア・SREから⾒ると  リポジトリの状態 = Kubernetesクラスタの状態  (Single Source of Truth)
  41. Kubernetes / GKE Λར༻͢Δ͜ͱͰ ɾϚχϑΣετͷߋ৽Λ΋ͱʹ༷ʑͳࣗಈԽΛ ɹKuberntes ʹ೚ͤΔ͜ͱ͕Մೳ ɾCI / CD

    ͕ैདྷΑΓ΋໌֬ʹͳΓɺ ɹΞϓϦέʔγϣϯͷߋ৽ͱΠϯϑϥʢ࣮ߦج൫ʣଆͷ੍ޚΛ ɹγʔϜϨεʹͭͳ͙͜ͱ͕Մೳ
  42. ߴ଎ͳεέʔϦϯά apiVersion: apps/v1 kind: Deployment metadata: name: sample-deployment spec: replicas:

    6 template: metadata: labels: {app: a} spec: containers: - name: app-container image: app:A ⾼速起動な⼩さいコンテナをスケール可能 同様にスケーリングは マニフェストを書き換えて適⽤するだけ
  43. Kubernetes Ϋϥελͷߏ੒ Kubernetes Cluster  = Kubernetes Master + Kubernetes Node

    Master/Node ⾃体も複数のコンポーネントで構成 Master Node Master Master Node Node Node Node Node
  44. Certified Kubernetes Distribution / Platform CNCF が提供する Conformance Test(適合テスト)に 通過したものだけが

    Certified Kubernetes として認定 Kubernetes 環境は現状 123 個  https://docs.google.com/spreadsheets/d/1LxSqBzjOxfGx3cmtZ4EbB_BGCxT_wlxW_xgHVVa23es/edit#gid=0 Installer:インストールツール(kubeadm、kubeaws、kubespray、etc) Distribution:Kubernetes 準拠の環境(OpenShift、Docker EE、k3s、Rancher、etc) Hosted:マネージドサービス(GKE、EKS、AKS、etc)
  45. Kubernetes Ϋϥελͷ҆ఆԽ ノードオートヒーリング(like Self-healing)  Kubernetes Node に問題があった場合にノードの復旧を⾏う クラスタのバージョンアップ(like Rolling Update

    of Deployment)  Kubernetes の Master 及び Node のコンポーネント郡の Rolling Upgrade クラスタオートスケール(like HorizontalPodAutoscaler)  Kubernetes Node を追加/削除してクラスタのスケーリングを⾏う
  46. ΫϥελͷόʔδϣϯΞοϓ Kubernetes Master や Node を構成するコンポーネント郡の Rolling Update Kubernetes Node

    の Upgrade 時には事前にコンテナの退避処理を⾏う Master コンポーネント⾃体もコンテナ化されているケースも多い
  47. Google Kubernetes Engine ಛ༗ͷػೳ ⾃動ノードプロビジョニング Container-native Load Balancing Stackdriver Monitoring/Logging

    との連携 TPU on Kubernetes Workload Identity Google Groups for RBAC BackendConfig ...more and more
  48. ࠓ೥ͷ Google Kubernetes Engine GKE は他社のクラウドと⽐較して約 3 年ほど早く マネージド Kubernetes

    サービスをリリース 2019/11 で満5年 今年に⼊ってさらに多くのマネージド特有の機能が GA  今後もさらに利便性・安定性の⾼い機能が⼊ってくるため期待
  49. Kubernetesの各リソースについて体系的かつ網羅的に説明 Cloud Nativeな開発を促進させる周辺エコシステムについても紹介 ▪⽬次案 第1章 Dockerの復習とHello, Kubernetes 第2章 なぜKubernetesが必要なのか? 第3章

    Kubernetes環境の選択肢 第4章 APIリソースとkubectl 第5章 Workloadsリソース 第6章 Discovery & LBリソース 第7章 Config & Storageリソース 第8章 ClusterリソースとMetadataリソース 第9章 リソース管理とオートスケーリング 第10章 ヘルスチェックとコンテナのライフサイクル 第11章 メンテナンスとノードの停⽌ 第12章 ⾼度で柔軟なスケジューリング 第13章 セキュリティ 第14章 マニフェストの汎⽤化を⾏うオープンソースソフトウェア 第15章 モニタリング 第16章 コンテナログの集約 第17章 CI/CD環境 第18章 マイクロサービスとServiceMesh 第19章 Kubernetesのアーキテクチャ 第20章 Kubernetesとこれから 付録