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 上で開発したくなっているでしょう。

Transcript

1. Masaya Aoyama CyberAgent Cloud Native࣌୅ʹ͓͚Δ GKE / Kubernetes Ͱ͸͡ΊΔ։ൃ
   GDG DevFest Tokyo 2019 MasayaAoyama @amsy810
2. 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 – 客員研究員
3. サイバーエージェントには、特定の分野に抜きん出た知識とスキルを持ち、その領域の第一人者として実 績を上げているエンジニアに、新たな活躍の場を提供するとともに、各専門領域において、その分野の発 展のための貢献および、サイバーエージェントグループに還元することを目的とした「Developer Experts 制度」があります。 「Developer Experts」の選出は、これまでの実績に基づいて、サイバーエージェントが注力する技術領域 から5名を選出しました。任命されたメンバーは、担当領域における、その技術や使われ方などについて 中立的な立場で発信することで、各担当領域の活性化に貢献することを目指します。 「Developer Experts」の5名には、大きく以下の３つの役割が任されています。 •  各専門領域において高い専門性を身につけ、その発展に貢献すること。 •  対外活動（登壇・コミュニティ活動・執筆・情報発信）を通して、各専門領域の発展に貢献すること。 •  各専門領域におけるサイバーエージェント全体の旗振り役として、管轄や事業部の垣根を超えて、担 当領域の相談を受けたりサポートすること。 これらの活動を支援するため、会社からは国内外を含む活動費のサポートを行い、全面的にバックアップ していきます。
4. Developer Experts ͷྖҬ 技術支援制度 Developer Experts制度 - https://www.cyberagent.co.jp/techinfo/info/detail/id=23823
5. みなさん、 Kubernetes は使ってますか？
6. Instagramable Kubernetes 時代はKubernetes。 ⼀般のご家庭には、インスタ映えのする⼿のひらクラスタを みなさん当然持ってますよね？
7. Agenda •  Kubernetes and Cloud Native •  疎結合性 •  管理容易性 •  回復性 •  可観測性 •  堅牢な自動化と更新 •  スケーラビリティ •  Google Kubernetes Engine
8. Kubernetes and Cloud Native What is Kubernetes? What is Cloud Naitve?
9. 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 ίϯςφ ͷىಈ
10. Kubernetes ͱ͸ʁ Kubernetes は複数のノードをマシンとして束ねて、 その上でコンテナをいい感じに起動させるオーケストレータ Google 社内で利用されていた クラスタマネージャ Borg が元になっている その他にも様々な機能 •  障害時のセルフヒーリング •  サービスディスカバリ •  ロードバランシング •  データや機密情報の管理 •  複数のDockerホストの管理 •  コンテナのスケジューリング •  スケーリング / オートスケーリング •  ローリングアップデート •  コンテナの死活監視
11. CNCF and The Linux Foundation •  Kubernetes はThe Linux Foundationの サブプロジェクトであるCNCFによってホスト •  その他にも多くのプロジェクトを ホストしている
12. 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)
13. 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なシステムを実現
14. Cloud Native ͸ Kubernetesʁ 誤解されることがあるので改めて伝えますが、「違います」 Kubernetes != Cloud Native •  Kubernetes を使うだけで Cloud Native になるわけではない •  もちろんレール（お作法）に乗ることで近づきはします •  VM でも Cloud Native な開発をすることも可能です •  その他のマネージド・サービスを利用して Cloud Native な開発にすることも可能です •  CloudRun、Cloud Functions
15. ૄ݁߹ੑ Loosely coupled
16. Microservice Architecture システム全体を機能ごとに分離 ProductPage Reviews Details Ratings HTTP/gRPC HTTP/gRPC
17. マイクロサービス毎に技術選定可能 gRPC, REST 等でマイクロサービス間を繋ぐことで、 各サービスの技術選定の自由度が高い デプロイが容易 小さい機能単位でデプロイが可能なため、 高速かつ影響範囲が少ない 大規模な開発を加速させる 各部門が特定のマイクロサービスを開発することで全体が成立 機能追加も比較的しやすい スケーリングが容易 特定の機能だけスケーリングさせるため効率が良い 障害が全体に波及しづらい 特定の機能に障害が起きた場合でも、 縮退した状態でサービス継続を行いやすい Benefit of Microservice Golang Java Scala gRPC REST
18. マイクロサービス毎に技術選定可能 gRPC, REST 等でマイクロサービス間を繋ぐことで、 各サービスの技術選定の自由度が高い デプロイが容易 小さい機能単位でデプロイが可能なため、 高速かつ影響範囲が少ない 大規模な開発を加速させる 各部門が特定のマイクロサービスを開発することで全体が成立 機能追加も比較的しやすい スケーリングが容易 特定の機能だけスケーリングさせるため効率が良い 障害が全体に波及しづらい 特定の機能に障害が起きた場合でも、 縮退した状態でサービス継続を行いやすい Developer Benefit of Microservice
19. マイクロサービス毎に技術選定可能 gRPC, REST 等でマイクロサービス間を繋ぐことで、 各サービスの技術選定の自由度が高い デプロイが容易 小さい機能単位でデプロイが可能なため、 高速かつ影響範囲が少ない 大規模な開発を加速させる 各部門が特定のマイクロサービスを開発することで全体が成立 機能追加も比較的しやすい スケーリングが容易 特定の機能だけスケーリングさせるため効率が良い 障害が全体に波及しづらい 特定の機能に障害が起きた場合でも、 縮退した状態でサービス継続を行いやすい Benefit of Microservice
20. マイクロサービス毎に技術選定可能 gRPC, REST 等でマイクロサービス間を繋ぐことで、 各サービスの技術選定の自由度が高い デプロイが容易 小さい機能単位でデプロイが可能なため、 高速かつ影響範囲が少ない 大規模な開発を加速させる 各部門が特定のマイクロサービスを開発することで全体が成立 機能追加も比較的しやすい スケーリングが容易 特定の機能だけスケーリングさせるため効率が良い 障害が全体に波及しづらい 特定の機能に障害が起きた場合でも、 縮退した状態でサービス継続を行いやすい Benefit of Microservice
21. マイクロサービス毎に技術選定可能 gRPC, REST 等でマイクロサービス間を繋ぐことで、 各サービスの技術選定の自由度が高い デプロイが容易 小さい機能単位でデプロイが可能なため、 高速かつ影響範囲が少ない 大規模な開発を加速させる 各部門が特定のマイクロサービスを開発することで全体が成立 機能追加も比較的しやすい スケーリングが容易 特定の機能だけスケーリングさせるため効率が良い 障害が全体に波及しづらい 特定の機能に障害が起きた場合でも、 縮退した状態でサービス継続を行いやすい Benefit of Microservice
22. Kubernetes / GKE Λར༻͢Δ͜ͱͰ ɾେྔͷ௿Φʔόʔϔουɾߴ଎ͳىಈͳίϯςφΛ ɹޮ཰తʹ؅ཧ͢Δ͜ͱ͕Ͱ͖ɺૄ݁߹ͳγεςϜΛ࡞Γ΍͍͢
23. ؅ཧ༰қੑ Manageable
24. Declarative Code and APIs Developer Register YAML Manifest Kubernetes Cluster 構成情報はManifestsで宣言的に記述してAPIに登録 Infrastructure as Code $ kubectl apply –f manifest.yaml
25. Podʢίϯςφʣͷىಈ コンテナのレプリカを作成し 指定した数のコンテナを維持 apiVersion: apps/v1 kind: Deployment metadata: name: sample-deployment spec: replicas: 5 template: metadata: labels: {app: a} spec: containers: - name: app-container image: app:A
26. 起動したコンテナには ラベル が付与されている 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 ͱͷ࿈ܞ
27. 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
28. 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
29. 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
30. 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
31. IP Address ͷ؅ཧ͔Βͷղ์ Kubernetes 外部の通信も external-dns を利⽤して グローバル IP と外部 DNS に⾃動登録させることが可能 1.  ロードバランサにグローバル IP が⾃動的に払い出される 2.  外部の DNS に⾃動的にグローバル IP と登録 LB xxx.xxx.xxx.xxx 外部 DNS
32. IP Address ͷ؅ཧ͔Βͷղ์ Kubernetes 外部の通信も external-dns を利⽤して グローバル IP と外部 DNS に⾃動登録させることが可能 1.  ロードバランサにグローバル IP が⾃動的に払い出される 2.  外部の DNS に⾃動的にグローバル IP と登録 LB xxx.xxx.xxx.xxx 外部 DNS amsy.dev => xxx.xxx.xxx.xxx
33. 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
34. Kubernetes / GKE Λར༻͢Δ͜ͱͰ ɾωοτϫʔΫ΍ετϨʔδͳͲ΋ந৅Խͯ͠ѻ͏͜ͱ͕Ͱ͖ɺ ɹ΄΅શͯΛ
    YAML
    ϑΝΠϧͰ؅ཧ͢Δ͜ͱ͕Մೳ ɾΞϓϦέʔγϣϯ։ൃऀʢDevʣଆ͔Β΋ ɹΠϯϑϥ૚ͷ੍ޚ͕༰қʹ
35. ճ෮ੑ Resilient
36. Kubernetes では あるべき理想の状態（Desired State）へと収束させる 何か問題が発⽣した場合でも、Reconcile loop により セルフヒーリングされる ※ 厳密には Controller も API を⽤いて変更します。 reconcile() { … } 登録 (via API Request) Watch クラスタの状態 コンテナの作成・削除 Controller 登録された時に、ただ起動させるだけではない ࣗಈճ෮ɾηϧϑώʔϦϯά
37. Kubernetes の内部には様々な Controller と呼ばれるプログラムが動作している Reconcile loop（調整ループ）とは、Controller 内で実⾏されている あるべき状態へと収束させるループ処理 のこと Observe Diff Act Observe: 現状を確認 Diff: 理想と現実の差分を計算 Act: 差分に対する処理を実施 reconcile() { … } Controller ࣗಈճ෮ɾηϧϑώʔϦϯά
38. ࣗಈճ෮ɾηϧϑώʔϦϯά 例えば、コンテナ（Pod）を 3 つ起動させる ReplicaSet リソースの場合 Observe Diff Act Observe: 現状を確認 Diff: 理想と現実の差分を計算 Act: 差分に対する処理を実施 クラスタの状態 理想の状態 reconcile() { … } Controller
39. ࣗಈճ෮ɾηϧϑώʔϦϯά たとえば 2 つしかコンテナ（Pod）が起動していない場合… Observe: 理想=3、現状=2 Observe Diff Act Observe: 現状を確認 Diff: 理想と現実の差分を計算 Act: 差分に対する処理を実施 クラスタの状態 理想の状態 reconcile() { … } Controller
40. ࣗಈճ෮ɾηϧϑώʔϦϯά たとえば 2 つしかコンテナ（Pod）が起動していない場合… Diff: 1 つコンテナ（Pod）が⾜りない Observe Diff Act Observe: 現状を確認 Diff: 理想と現実の差分を計算 Act: 差分に対する処理を実施 クラスタの状態 理想の状態 reconcile() { … } Controller
41. ࣗಈճ෮ɾηϧϑώʔϦϯά たとえば 2 つしかコンテナ（Pod）が起動していない場合… Act: 1つ nginx:1.12 のコンテナ（Pod）を作成する Observe Diff Act Observe: 現状を確認 Diff: 理想と現実の差分を計算 Act: 差分に対する処理を実施 クラスタの状態 理想の状態 reconcile() { … } Controller
42. ʰ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 『障害時のクラスタ復旧』 『バックアップなどの運用』 を自動化（マネージド）
43. ʰX as a Service ج൫ʱͱͯ͠ͷ Kubernetes Kubernetes は ⼩さなクラウド に近い oracle/mysql-operator 『障害時のクラスタ復旧』 『バックアップなどの運用』 を自動化（マネージド） Relational DB Key Value Store Document DB Queue Developer
44. ʰ෼ࢄγεςϜϑϨʔϜϫʔΫʱͱͯ͠ͷ Kubernetes Kubernetes のコアは『Decralative API 』と『分散システムフレームワーク』 ※ 厳密には Controller も API を⽤いて変更します。 reconcile() { … } 登録 (via API Request) 監視 MySQL Cluster の管理 reconcile() { … } Controller 独⾃のリソースに対してどのような処理をするか Controller を書くことで運⽤が容易に （運⽤ナレッジのプログラム化）
45. Kubernetes / GKE Λར༻͢Δ͜ͱͰ ɾো֐࣌΍ঢ়ଶมߋ࣌ʹࣗಈతʹ͋Δ΂͖ঢ়ଶʢDesired Stateʣʹ ɹऩଋͤ͞Δ Platform ্ͰΞϓϦέʔγϣϯΛ࣮ߦՄೳ ɾυϝΠϯಛԽͳΞϓϦέʔγϣϯΛ Kubernetes ͷ֦ுੑΛ ɹੜ͔ͯ͠ಉ౳ͷखஈͰ؅ཧ͢Δ͜ͱ͕Ͱ͖Δ
46. Մ؍ଌੑ Observable
47. Մ؍ଌੑͱ͸ʁ トレーシング サービスメッシュ メトリクス ロギング
48. Kubernetes / GKE Λར༻͢Δ͜ͱͰ ɾKubernetes ͷ؅ཧੑΛੜ͔͢͜ͱͰɺ ɹपลͷΤίγεςϜΛར༻ͯ͠Մ؍ଌੑΛߴΊΔखஈΛར༻Մೳ
49. ݎ࿚ͳࣗಈԽͱߋ৽ Robust automation and frequently changes
50. 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 ϩʔϦϯάΞοϓσʔτ
51. ϩʔϦϯάΞοϓσʔτ 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 が⾃動的にアップデート処理を⾏う
52. ϩʔϦϯάΞοϓσʔτ Kubernetes LB •  デファクトとなった⼿段でアップデートが可能 •  更新間隔、タイムアウト、ロールバックなど細かい制御 CloudFormation や OpenStack Heat などでも作り込めば同等のことは可能 appA:1 appA:1 appA:2
53. ैདྷͷ CI / CD Code Repository S3 / etc CI - test, build VM CD - Deploy v1 v2 v3
54. ίϯςφͷ৔߹ͷ CI / CD Code Repository Docker Registry CI - test, build Kubernetes CI - update manifests Manifest Repository CD - depoy v1 v2 v3 v1 v2 v3 GItOps の場合:
55. GitOps Overview ϚχϑΣετ リポジトリ ΞϓϦέʔγϣϯ リポジトリ CI CD コンテナ レジストリ Kubernetes クラスタ マニフェストの 書き換え（PR） アプリケーションのテスト Dockerイメージのビルド イメージの保存 マニフェストの適⽤（デプロイ） Developer
56. GitOps – PRʹΑΔࠩ෼ͷνΣοΫ ϚχϑΣετ リポジトリ CD Kubernetes クラスタ
57. GitOps - Staging ϚχϑΣετ リポジトリ (staging) ΞϓϦέʔγϣϯ リポジトリ CI CD コンテナ レジストリ Staging クラスタ マニフェストの 書き換え（PR） アプリケーションのテスト Dockerイメージのビルド イメージの保存 マニフェストの適⽤ Developer staging branch master branch ϚχϑΣετ リポジトリ (production) Production クラスタ
58. GitOps - Production ϚχϑΣετ リポジトリ (staging) ΞϓϦέʔγϣϯ リポジトリ CI CD コンテナ レジストリ マニフェストの 書き換え（PR） アプリケーションのテスト Dockerイメージのビルド イメージの保存 Developer staging branch master branch ϚχϑΣετ リポジトリ (production) Staging クラスタ マニフェストの適⽤ Production クラスタ
59. GitOps ϚχϑΣετ リポジトリ (staging) ΞϓϦέʔγϣϯ リポジトリ CI CD コンテナ レジストリ Developer staging branch master branch ϚχϑΣετ リポジトリ (production) Staging クラスタ マニフェストの適⽤ Production クラスタ アプリケーションエンジニアから⾒ると  ブランチの状態 ＝ デプロイされているアプリケーション  （アプリのコミットハッシュでイメージのタグが付与） インフラエンジニア・SREから⾒ると  リポジトリの状態 ＝ Kubernetesクラスタの状態  （Single Source of Truth）
60. Kubernetes / GKE Λར༻͢Δ͜ͱͰ ɾϚχϑΣετͷߋ৽Λ΋ͱʹ༷ʑͳࣗಈԽΛ ɹKuberntes ʹ೚ͤΔ͜ͱ͕Մೳ ɾCI / CD ͕ैདྷΑΓ΋໌֬ʹͳΓɺ ɹΞϓϦέʔγϣϯͷߋ৽ͱΠϯϑϥʢ࣮ߦج൫ʣଆͷ੍ޚΛ ɹγʔϜϨεʹͭͳ͙͜ͱ͕Մೳ
61. εέʔϥϏϦςΟ Scalability
62. ⾼速起動な⼩さいコンテナをスケール可能 同様にスケーリングは マニフェストを書き換えて適⽤するだけ 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 ߴ଎ͳεέʔϦϯά
63. ߴ଎ͳεέʔϦϯά 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 ⾼速起動な⼩さいコンテナをスケール可能 同様にスケーリングは マニフェストを書き換えて適⽤するだけ
64. ਫฏεέʔϦϯάͱਨ௚εέʔϦϯά HorizontalPodAutoscaling VerticalPodAutoscaling
65. ΫϥελͷΦʔτεέʔϧ Kubernetes ではクラスタのオートスケールはスコープ外
66. Kubernetes
    ্Ͱ Cloud Native ͳ ΞϓϦέʔγϣϯ։ൃ͸Ͱ͖ͦ͏ Kubernetes ͷ؅ཧ͸Ͳ͏͢Δͷ͔ʁ
67. Google Kubernetes Engine Kubernetes is inspired by Google borg
68. Kubernetes Ϋϥελͷߏ੒ Kubernetes Cluster  = Kubernetes Master + Kubernetes Node Master/Node ⾃体も複数のコンポーネントで構成 Master Node Master Master Node Node Node Node Node
69. 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）
70. Kubernetes Ϋϥελͷ҆ఆԽ ノードオートヒーリング（like Self-healing）  Kubernetes Node に問題があった場合にノードの復旧を⾏う クラスタのバージョンアップ（like Rolling Update of Deployment）  Kubernetes の Master 及び Node のコンポーネント郡の Rolling Upgrade クラスタオートスケール（like HorizontalPodAutoscaler）  Kubernetes Node を追加/削除してクラスタのスケーリングを⾏う
71. Kubernetes ͷ؅ཧ΋ Cloud Native way Ͱ
72. ϊʔυΦʔτώʔϦϯά ノードの Disk/Memory/PID の状態やコンテナランタイムの状態が異常な場合に コンテナを退避後、ノードを⾃動復旧させる機能 Kubernetes Nodes Kubernetes Nodes コンテナ コンテナ
73. ΫϥελͷόʔδϣϯΞοϓ Kubernetes Master や Node を構成するコンポーネント郡の Rolling Update Kubernetes Node の Upgrade 時には事前にコンテナの退避処理を⾏う Master コンポーネント⾃体もコンテナ化されているケースも多い
74. ΫϥελΦʔτεέʔϧ Kubernetes Node ⾃体のオートスケーリング  コンテナのオートスケールだけでは限界があるため、  通常はクラスタ側のオートスケール機能と合わせて利⽤ 複数のインスタンスタイプのノードが⼊り乱れている場合は 特定のアルゴリズムによって計算される
75. ࣗಈϊʔυϓϩϏδϣχϯά Kubernetes のマニフェストの設定やスケジューリングポリシーに従って ⾃動的にクラスタノードを追加する ・インスタンスタイプ ・GPU / TPU ・ノードラベル ・etc. 通常のクラスタKubernetes のマニフェストの設定やスケジューリングポリ シーに従って
76. Google Kubernetes Engine ಛ༗ͷػೳ ⾃動ノードプロビジョニング Container-native Load Balancing Stackdriver Monitoring/Logging との連携 TPU on Kubernetes Workload Identity Google Groups for RBAC BackendConfig ...more and more
77. ࠓ೥ͷ Google Kubernetes Engine GKE は他社のクラウドと⽐較して約 3 年ほど早く マネージド Kubernetes サービスをリリース 2019/11 で満５年 今年に⼊ってさらに多くのマネージド特有の機能が GA  今後もさらに利便性・安定性の⾼い機能が⼊ってくるため期待
78. GKE Λར༻͢Δ͜ͱͰ Kubernetes ͷ؅ཧͷ େ෦෼͸͓೚ͤ
79. ࠓ೥ͷςʔϚ͸ʮࠓ೥ͷٕज़૯ܾࢉʯ
80. CNCF Community Presentation, CNCF, 2018 (https://github.com/cncf/presentations)
81. Kubernetes ʹڵຯ͸༙͖·͔ͨ͠ʁ
82. 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とこれから 付録
83. Thank you for your attention follow me: @amsy810