Masaya Aoyama CyberAgent ʮVM ࣌୅ͷ։ൃʯͱ ʮKubernetes ʹΑΔ Cloud Native ͳ։ൃʯͷ ͜Ε͔Β Infra Study Meetup #2 amsy810 @amsy810

- Co-chair ੨ࢁ ਅ໵ + CREATIONLINE / DENSO - 技術アドバイザ + SAKURA Internet Research Center – 客員研究員 - Organizer - KaaS Product Owner - Publications Twitter: @amsy810

サイバーエージェントには、特定の分野に抜きん出た知識とスキルを持ち、その領域の第一人者とし て実績を上げているエンジニアに、新たな活躍の場を提供するとともに、各専門領域において、その 分野の発展のための貢献および、サイバーエージェントグループに還元することを目的とした 「Developer Experts制度」があります。 「Developer Experts」の選出は、これまでの実績に基づいて、サイバーエージェントが注力する技術 領域から5名を選出しました。任命されたメンバーは、担当領域における、その技術や使われ方などに ついて中立的な立場で発信することで、各担当領域の活性化に貢献することを目指します。 「Developer Experts」の5名には、大きく以下の３つの役割が任されています。 • 各専門領域において高い専門性を身につけ、その発展に貢献すること。 • 対外活動（登壇・コミュニティ活動・執筆・情報発信）を通して、各専門領域の発展に貢献するこ と。 • 各専門領域におけるサイバーエージェント全体の旗振り役として、管轄や事業部の垣根を超えて、 担当領域の相談を受けたりサポートすること。 これらの活動を支援するため、会社からは国内外を含む活動費のサポートを行い、全面的にバック アップしていきます。 技術支援制度 Developer Experts制度 - https://www.cyberagent.co.jp/techinfo/info/detail/id=23823

Cloud Native Meetup Tokyo と Forkwell さん Cloud Native Meetup Tokyo #2 （ 2018/6/1 ）から 実は何度かスポンサーをしていただいてます。

Masaya Aoyama CyberAgent ʮVM ࣌୅ͷ։ൃʯͱ ʮKubernetes ʹΑΔ Cloud Native ͳ։ൃʯͷ ͜Ε͔Β Infra Study Meetup #2 amsy810 @amsy810

͜͜Ͱ͍͏ VM ࣌୅ͱ͸ʁ

物理マシン時代 -2000年 （※ 年代は立場や会社によって異なります） • 数台のサーバ上でアプリケーションを動作 • 台数もそこまで多くはなく、1台1台をペット（Pet）として扱う 物理マシン 時代 仮想マシン 時代 (1) 仮想マシン 時代 (2) CloudNative 時代

仮想マシン時代（1） 2001-2009年 • 物理マシンの代替 としてVMを使う • このときもVMはまだペットとして扱われている • 集約率をあげて高効率化をすることが目的 • サーバのメニーコア化と仮想化技術の普及 • VMの代替としてのコンテナ技術自体は存在（いわゆる System Container） 物理マシン 時代 仮想マシン 時代 (1) 仮想マシン 時代 (2) CloudNative 時代 2003 2007 2001 (ESX) 2006 (EC2/S3)

仮想マシン時代（2）≒ Cloud 時代 2010-2015年 • Webサービスの普及によりスケーラブルなシステム設計 • クラウドが普及し、無尽蔵なリソースを利用可能に • データベースなどのマネージドサービスも拡充 • 安定的に大規模インフラを管理するための技術も普及 • Immutable Infrastructure • Infrastructure as Code • 合わせて DevOps の考え方も普及 物理マシン 時代 仮想マシン 時代 (1) 仮想マシン 時代 (2) CloudNative 時代

Cloud Native 時代 2016年-現在 • 仮想マシン時代(2) はインフラ側から寄っていった方法 • アプリ側とも歩幅をあわせた方法論 ＝ Cloud Nativeのはじまり • IaC, Immutable Infrastructure, Cattle 化なども継承 • アプリケーションを実行するために最適なインフラ • 開発したものを「即座に」「安定的に」提供する（ビジネス優位性のためにも） 物理マシン 時代 仮想マシン 時代 (1) 仮想マシン 時代 (2) CloudNative 時代

Cloud Native 時代 2016年-現在 • アプリケーションを実行するために最適なインフラの最適解のひとつ • Docker • Kubernetes • Serverless • PaaS • （VM） • etc 物理マシン 時代 仮想マシン 時代 (1) 仮想マシン 時代 (2) CloudNative 時代 その他の選択肢も十分にありえる

Cloud Native 時代 2016年-現在 • アプリケーションを実行するために最適なインフラ • 開発したものを「即座に」「安定的に」提供する（ビジネス優位性のためにも） 物理マシン 時代 仮想マシン 時代 (1) 仮想マシン 時代 (2) CloudNative 時代 今でこそ CloudNative と名前がついているが パブリッククラウドもこうした思想で取り組んでいると思う こういった思想から生まれたもののひとつが Docker / Kubernetes

Cloud Native 時代 2016年-現在 • アプリケーションを実行するために最適なインフラの最適解のひとつ • Docker（ Application Container ） • 正しく動かすためにアプリケーションと動作環境のパッケージング • 開発者にとってのイメージのビルドの容易性 • アプリケーション起動と同等の低オーバーヘッド • Kubernetes（ Container Orchestrator ） • アプリケーションの実行を第一に考えたときに どういうインフラを作るかを主軸に設計されたインフラ基盤 物理マシン 時代 仮想マシン 時代 (1) 仮想マシン 時代 (2) CloudNative 時代 Develper Experience の良さ Reconcilliation modelの洗練さ

CNCF͕ݴ͏Cloud Nativeͱ͸ʁ

Cloud Nativeとは？ クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの 近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築および実行するための能 力を組織にもたらします。 このアプローチの代表例に、コンテナ、サービスメッシュ、マイクロサービ ス、イミュータブルインフラストラクチャ、および宣言型APIがあります。 これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。 これらを堅 牢な自動化と組み合わせることで、エンジニアはインパクトのある変更を最小限の労力で頻繁かつ予測ど おりに行うことができます。 Cloud Native Computing Foundationは、オープンソースでベンダー中立プロジェクトのエコシステムを育 成・維持して、このパラダイムの採用を促進したいと考えてます。 私たちは最先端のパターンを民主化 し、これらのイノベーションを誰もが利用できるようにします。 CNCF Cloud Native Defenition v1.0, CNCF, 2018-11-28 (https://github.com/cncf/toc/blob/master/DEFINITION.md)

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なシステムを実現 テクニカルに

Cloud Nativeとは？ クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの 近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築および実行するための能 力を組織にもたらします。 このアプローチの代表例に、コンテナ、サービスメッシュ、マイクロサービ ス、イミュータブルインフラストラクチャ、および宣言型APIがあります。 これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。 これらを堅 牢な自動化と組み合わせることで、エンジニアはインパクトのある変更を最小限の労力で頻繁かつ予測ど おりに行うことができます。 Cloud Native Computing Foundationは、オープンソースでベンダー中立プロジェクトのエコシステムを育 成・維持して、このパラダイムの採用を促進したいと考えてます。 私たちは最先端のパターンを民主化 し、これらのイノベーションを誰もが利用できるようにします。 CNCF Cloud Native Defenition v1.0, CNCF, 2018-11-28 (https://github.com/cncf/toc/blob/master/DEFINITION.md) これにより、開発したものを「即座に」「安定的に」実行できます。 前とは異なり、 DevとOpsが一緒に考えた、アプリケーションの実行環境を、最適な形で利用します。 CNCFはオープンソースを推奨します。 ≒ 必須ではない（ 個人の見解 ） 個人的な意訳的に

Kubernetes Concept 101

Kubernetes と「リソース」 Google Borg をベースとした洗練された基盤 • ローリングアップデート • オートスケール • ロードバランサとの⾃動連携（抽象化） 様々なものを「リソース」として扱う リソースを記述したマニフェストを K8s に登録 ReplicaSet リソースを登録

『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 presslabs/mysql-operator 『障害時のクラスタ復旧』 『バックアップなどの運用』 を自動化（マネージド）

『X as a Service 基盤』としての Kubernetes Kubernetes は ⼩さなクラウド に近い Message Queue Key Value Store Document DB Relational DB Developer ステートフルなもの以外にも ML、Serverless、バッチJobなど 様々なものを Kubernetes 上で提供する エコシステムが発達

Ϋϥ΢υ؀ڥ ͱ Cloud Native

クラウド環境 と Cloud Native • Kubernetesもクラウド環境相当の機能を持っている • コンテナなどを使わなければ Cloud Native ではないか？ • 前述の Cloud Native を目指しさえすれば、それは Cloud Native（だと私は考える） • 逆に Kubernetes を従来的な使い方しかできない場合は、Cloud Native ではない RDS MySQLCluster CloudSQL EC2 Auto Scaling HPA Auto Scaling Group EC2 Auto Scaling Deployment Instance Template AMI Container Image Custom Image

Managed Kubernetes on Public Cloud 最近の環境は K8s on クラウド環境 • Nested VM ならぬ Nested Cloud

Kubernetes 導入の進め方 • 純粋な Computing Workload のみを Kubernetes 上で実行 • Deployment リソース（アプリケーションの実行） • Service リソース（ロードバランサとの連携） • クラウド環境と Kubernetes は適切に共存していくべき • 共存レベルは利用するクラウド環境により異なる • AWS, GCP, OpenStack, etc. Computing Computing

VM࣌୅ͱͷൺֱ ΞϓϦέʔγϣϯͷ࣮ߦΛୈҰʹߟ͑ͨΠϯϑϥ ʢ̍ʣଈ࠲ʹ҆ఆͨ͠ϏϧυʙσϓϩΠΛ࣮ݱ͢ΔΠϝʔδԽ ʢ̎ʣΞϓϦέʔγϣϯ࣮ߦͷϕετϓϥΫςΟεͷίʔυԽ ʢ̏ʣΠϯϑϥͷந৅Խ

Bootstrap & Orchestrate Terraform CloudFormation / Heat Configuration Chef / Ansible / Puppet / Salt Packer Deploy Jenkins / Capistrano パターン 1 • Terraform で VM を起動 • CAPS でセットアップ • Jenkins でアプリのデプロイ ・イメージビルド時間︓0 min ・デプロイ時間︓10 min〜60 min ・同⼀環境になることが保証されない ・複数のツールの習得が必要 [VM] インフラのビルド〜デプロイまでの道のり

[VM] インフラのビルド〜デプロイまでの道のり Bootstrap & Orchestrate Terraform CloudFormation / Heat Configuration Chef / Ansible / Puppet / Salt Packer Deploy Jenkins / Capistrano パターン 2 • Packer で VM イメージのビルド • Terraform で VM を起動 • Jenkins でアプリのデプロイ ・イメージビルド時間︓10 min - 30 min ・デプロイ時間︓5 min ・同⼀環境になることが保証される ・複数のツールの習得が必要

[CloudNative] インフラのビルド〜デプロイまでの道のり Bootstrap & Orchestrate Kubernetes Manifests Configuration Dockerfile Kubernetes Manifests Deploy Kubernetes Manifests パターン 3 • Dockerfile でイメージのビルド • K8s Manifest でコンテナを起動 • ミドルウェア • アプリケーション • サービス間の接続性も管理 ・イメージビルド時間︓1 min - 10 min ・デプロイ時間︓5 sec – 1 min ・同⼀環境になることが保証される ・少ない数のツールの習得で⼗分 イメージ化がとても容易 Dev 側が関わることができる

[VM] アプリのビルド〜デプロイまでの道のり Code Repository S3 / etc CI - test, build VM CD - Deploy v1 v2 v3

[CloudNative] アプリのビルド〜デプロイまでの道のり Code Repository Docker Registry CI - test, build Kubernetes CI - update manifests Manifest Repository CD - depoy v1 v2 v3 v1 v2 v3 GItOps の場合: アプリケーションの状態がコード化 環境込みのアプリケーション

[CloudNative] 開発用環境の準備のしやすさ Docker Registry Kubernetes Manifest Repository v1 v2 v3 v1 v2 v3 アーティファクトはコンテナとマニフェスト 外部に依存する部分さえ用意すれば、手元でも再現可能 DBなどもコンテナとして起動することが容易

VM࣌୅ͱͷൺֱ ΞϓϦέʔγϣϯͷ࣮ߦΛୈҰʹߟ͑ͨΠϯϑϥ ʢ̍ʣଈ࠲ʹ҆ఆͨ͠ϏϧυʙσϓϩΠΛ࣮ݱ͢ΔΠϝʔδԽ ʢ̎ʣΞϓϦέʔγϣϯ࣮ߦͷϕετϓϥΫςΟεͷίʔυԽ ʢ̏ʣΠϯϑϥͷந৅Խ

CAPS のコード化と Kubernetes のコード化の違い • CAPS や Terraform のコード化 • あくまでも構築スクリプト的（宣言的記述のサポートと冪等性による再実行） • Cloud Formation や Instance Group などと組み合わせることで… • Kubernetesのコード化 • アプリケーションをどう動かすかに主眼 • 安定的に動かすためのベストプラクティス的設定郡 • インフラ運用に関するベストプラクティスのコード化 a

[Kubernetes] アプリ実行のベストプラクティスのコード化 spec: containers: - name: cart-app-container image: cart-app:v1.2.3 env: - name: DB_HOST value: db.product readinessProbe: httpGet: path: /healthz resources: requests: cpu: 100m memory: 128Mi lifecycle: preStop: {...} postStart: {...} terminationGracePeriodSeconds: 30 コンテナの停止処理に関する設定 SIGTERM/SIGKILL による停止容易性の確保 アプリケーションが前提となる実行宣言 ヘルスチェック設定 アプリケーションが動作するための リソースの割り当て アプリケーション実行時の ライフサイクルに関する設定 環境変数による環境の切り分け

VM࣌୅ͱͷൺֱ ΞϓϦέʔγϣϯͷ࣮ߦΛୈҰʹߟ͑ͨΠϯϑϥ ʢ̍ʣଈ࠲ʹ҆ఆͨ͠ϏϧυʙσϓϩΠΛ࣮ݱ͢ΔΠϝʔδԽ ʢ̎ʣΞϓϦέʔγϣϯ࣮ߦͷϕετϓϥΫςΟεͷίʔυԽ ʢ̏ʣΠϯϑϥͷந৅Խ

[VM] ロードバランサの連携／IPアドレスの管理 ロードバランサ連携 • ⾃前スクリプト • 別ツール • ⼿動管理だったり IPアドレス管理 • VM ごとに把握・管理し、Ansible / Chef などで構成管理を実⾏

起動したPod（コンテナ）には ラベル が付与されている 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 app: a app: a app: a [Kubernetes] ロードバランサとの連携

⾃動的に 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 app: a app: a app: a LB app: a [Kubernetes] ロードバランサとの連携

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 [Kubernetes] IP アドレスの管理

クラスタ外部からの通信も external-dns を利⽤して グローバル IP を外部 DNS に⾃動登録させることが可能 1. ロードバランサにグローバル IP が⾃動的に払い出される 2. 外部の DNS に⾃動的にグローバル IP を登録 さらに cert-manager を利⽤することで ACME を利⽤して証明書の⾃動発⾏/更新も可能 LB xxx.xxx.xxx.xxx 外部 DNS amsy.dev => xxx.xxx.xxx.xxx [Kubernetes] IP アドレスの管理

Kubernetes ͷίΞίϯηϓτ Reconciliation Loop

あるべき理想の状態（Desired State）≒ Declarative へと収束する 何か問題が発⽣した場合でも、Controller により セルフヒーリングされる ※ 厳密には Controller も API を⽤いて変更します。 reconcile() { … } 登録 (via API Request) Watch クラスタの状態 コンテナの作成・削除 Controller 登録された時に、ただ起動させるだけではない Kubernetes と Reconciliation Loop

Controller 内では Reconciliation loop（調整ループ）と呼ばれる あるべき状態へと収束させるループ処理 が実⾏されている Kubernetes の内部には様々な Controller と呼ばれるプログラムが動作している Observe Diff Act Observe: 現状を確認 Diff: 理想と現実の差分を計算 Act: 差分に対する処理を実施 reconcile() { … } Controller Kubernetes と Reconciliation Loop

ReplicaSet Controller の責務は 「指定されたレプリカ数で Pod を維持し続けること」 Observe Diff Act Observe: 現状を確認 Diff: 理想と現実の差分を計算 Act: 差分に対する処理を実施 クラスタの状態 理想の状態 reconcile() { … } Controller 例： ReplicaSet Controller の例

例えば、コンテナ（Pod）を 3 つ起動させる ReplicaSet リソースの場合 Observe Diff Act Observe: 現状を確認 Diff: 理想と現実の差分を計算 Act: 差分に対する処理を実施 クラスタの状態 理想の状態 reconcile() { … } Controller 例： ReplicaSet Controller の例

たとえば 2 つしかコンテナ（Pod）が起動していない場合… Observe: 理想=3、現状=2 Observe Diff Act Observe: 現状を確認 Diff: 理想と現実の差分を計算 Act: 差分に対する処理を実施 クラスタの状態 理想の状態 reconcile() { … } Controller 例： ReplicaSet Controller の例

たとえば 2 つしかコンテナ（Pod）が起動していない場合… Diff: 1 つコンテナ（Pod）が⾜りない Observe Diff Act Observe: 現状を確認 Diff: 理想と現実の差分を計算 Act: 差分に対する処理を実施 クラスタの状態 理想の状態 reconcile() { … } Controller 例： ReplicaSet Controller の例

たとえば 2 つしかコンテナ（Pod）が起動していない場合… Act: 1つ nginx:1.12 のコンテナ（Pod）を作成する Observe Diff Act Observe: 現状を確認 Diff: 理想と現実の差分を計算 Act: 差分に対する処理を実施 クラスタの状態 理想の状態 reconcile() { … } Controller 例： ReplicaSet Controller の例

実際にはすべてが Kubernetes API 上のリソースとして表現されている Controllerの中⾝ = API の操作 ＋ ロジック 例： ReplicaSet Controller の例 reconcile() { … } Controller ReplicaSet の監視 Pod の制御 via API 運⽤のコード化

Kubernetes の構成要素 リソースのスキーマ + Controller + およびその仕組み Kubernetes では⾮常に沢⼭の Controller が動いている • ReplicaSet Controller • Deployment Controller • Ingress Controller • Node Controller • Scheduler • etc. これらの Controller が⾮同期に動作することで ⼀つの分散システムとして成り⽴っている reconcile() { … } Controller reconcile() { … } Controller reconcile() { … } Controller reconcile() { … } Controller reconcile() { … } Controller 実際の状態 理想の状態 watch

実際にはすべてが Kubernetes API 上のリソースとして表現されている Controllerの中⾝ = API の操作 ＋ ロジック └─ kubebuilder, Operator Framework などによりフレームワーク化 MySQL Controller の例 (mysql-operator) reconcile() { … } Controller 独⾃リソースの監視 Pod などの制御 via API 運⽤のコード化

ͦͯ͢͠΂͕ͯ Kubernetes YAML ʹͳΔ ≒ Θ͕ͨ͠ Container Orchestrator ͱͯ͠ Kuebrnetes ʹະདྷΛײ͍ͯ͡Δ෦෼

Controller による運用の自動化パターン（1/3） １．⼀般的な運⽤⾃動化ロジック • 社内に伝わる秘伝の闇の運⽤スクリプトを駆逐 • Kubernetes-way な統⼀化された⽅法 • Reconciliation モデルにより「運⽤」のロジック化に適している • 汎化した形で実装し、オープンソースのエコシステムとして共有 例） リポジトリのマニフェストを Kubernetes に apply する︓ArgoCD 払い出されたロードバランサの IP アドレスを DNS に登録する︓ExternalDNS Issuer から証明書を発⾏して Secret として登録する︓Cert Manager コンテナのリソースの使⽤率から⾃動的にリソース割当を変える︓VerticalPodAutoscaler

Controller による運用の自動化パターン（2/3） ２．ステートフルなミドルウェアを運⽤する Controller がつくられる Databaseなどの運⽤を任せられる時代に。 Message Queue／KVS に関しては近いうちに現実的に （個⼈的にステートを持つ Computing リソースの延⻑に感じている） ステートフルなミドルウェアが進まない理由 • Podのライフサイクルに適応できるものが少ない • 現状はクラスタ間のボリューム移⾏が得意ではない

Controller による運用の自動化パターン（3/3） Computing Computing 定期的な運⽤が必要 ３．外部システムを制御・運⽤するための仕組み • Reconcile を踏襲した管理 • e.g. Config Connector︓ GCP リソースの制御 既存の問題点 １．クラウドリソースが適切な状態か判別できない Terraformなどは構築ツール的 ２．管理系が複数に分かれている 認証情報等はどうするか

Controller による運用の自動化パターン（3/3） KVS DB Computing Computing KVS (meta) DB (meta) ３．外部システムを制御・運⽤するための仕組み • Reconcile を踏襲した管理 • e.g. Config Connector︓ GCP リソースの制御 既存の問題点 １．クラウドリソースが適切な状態か判別できない Terraformなどは構築ツール的 => Controller 内ロジックにより担保 ２．管理系が複数に分かれている 認証情報等はどうするか => Secret リソースとして⾃動展開し アプリから利⽤可能に（CCに機能的にあるか不明） 定期的な運⽤

今回のスコープだと残るコード Dockerfile • アプリケーションのパッケージングに関するコードのみ • Cloud Native Build Pack（各⾔語のツール含む）により Dockerfile が不要になる世界も Terraform • IP アドレスの確保 や クラスタの初期構築 • ExternalDNS や Cert Manager の活⽤により IP アドレスフリーに • クラスタ運⽤は⾃動化へ

クラスタ運用の自動化 Node Auto Healing（like Self-healing of ReplicaSet） Kubernetes Node に問題が⽣じた場合にノードの復旧を⾏う Cluster Auto Upgrade（like Rolling Update of Deployment） Kubernetes の Master 及び Node のコンポーネント郡の Rolling Upgrade Cluster Autoscaling（like HorizontalPodAutoscaler） Kubernetes Node を追加/削除してクラスタのスケーリングを⾏う Node Auto Provisioning（like VerticalPodAutoscaler） 適切なサイズ・種別のノードを⾃動判別してクラスタに追加

·ͱΊ

まとめ Cloud Native とは、アプリケーションの実⾏を第⼀に考えたときに どういうインフラを作るかということを主軸にした考え⽅とも⾔える Controller による⾃動化のパターン ⼀般的な運⽤⾃動化 ステートフルなミドルウェアの運⽤ 外部システムを制御・運⽤する仕組み VM時代との⽐較 即座に安定したビルド〜デプロイを実現するイメージ化 運⽤のベストプラクティス インフラの抽象化 Kubernetes は宣⾔的API + Controller による Reconciliation Loop により 運⽤⾃動化を⾏うエコシステムを⽀えている

͍͞͝ʹ

5 年後の一般的なインフラ環境の未来 オンプレ環境 「データベース以外はKubernetes上で稼働している状態」 パブリッククラウド環境 「Kubernetes 上ですべてが管理されている状態」

Kubernetes-native testbed for the future (still alpha release) https://employment.en-japan.com/engineerhub/entry/2020/04/16/103000

ͦͯ͢͠΂͕ͯ Kubernetes YAML ʹͳΔ ͦͯ͢͠΂͕ͯ Kubernetes-native ʹͳΔ

ຊ౰ͷ࠷ޙʹ

ຊ౰ͷ࠷ޙʹ ಥવͷએ఻

CloudNative Days Tokyo 2020 (9/8 - 9/9) 今年はオンライン開催になりました！ CFP・スポンサー募集中です！ http://bit.ly/cndt2020cfp About CloudNative Days CloudNative Days はコミュニティ、企業、技術者が一堂に 会し、クラウドネイティブムーブメントを牽引することを 目的としたテックカンファレンスです。 最新の活用事例や先進的なアーキテクチャを学べるのはも ちろん、ナレッジの共有やディスカッションの場を通じて 登壇者と参加者、参加者同士の繋がりを深め、初心者から 熟練者までが共に成長できる機会を提供します。 皆様がクラウドネイティブ技術を適切に選択し、活用し、 次のステップに進む手助けになることを願っています。 クラウドネイティブで、未来を共に創造しましょう。

CloudNative Days Tokyo 2020 (9/8 - 9/9) 今年はオンライン開催になりました！ CFP・スポンサー募集中です！ http://bit.ly/cndt2020cfp About CloudNative Days CloudNative Days はコミュニティ、企業、技術者が一堂に 会し、クラウドネイティブムーブメントを牽引することを 目的としたテックカンファレンスです。 最新の活用事例や先進的なアーキテクチャを学べるのはも ちろん、ナレッジの共有やディスカッションの場を通じて 登壇者と参加者、参加者同士の繋がりを深め、初心者から 熟練者までが共に成長できる機会を提供します。 皆様がクラウドネイティブ技術を適切に選択し、活用し、 次のステップに進む手助けになることを願っています。 クラウドネイティブで、未来を共に創造しましょう。 ొஃऀٻΉ

Thank you for your attention Twitter: @amsy810