Confidential & Proprietary

『Kubernetes / Container による開発』

導入難易度 と メリット

株式会社サイバーエージェント

adtech studioInfrastructure Engineer

青山 真也（@amsy810）

出版・登壇（一部抜粋）

　Kubernetes 完全ガイド、みんな Docker / Kubernetes　著者

　Japan Container Days v18.04　基調講演

　情報処理学会 コンピュータシステムシンポジウム　招待講演

　Developers Summit　招待講演

　CKAD #2、CKA #138

Masaya Aoyama (@amsy810)

Infrastructure Engineer

コミュニティ

　Cloud Native Days Tokyo Co-chair （旧 Japan Container Days）

　Cloud Native Meetup Tokyo Organizer

　Kubernetes Meetup Tokyo Organizer

　KubeCon 日本交流会 Organizer

　Contribute to OpenStack and Kubernetes

主業務 KaaS 実装 / 運用K8s 関連 アーキテクト

and

● 早いところで 2016 年頃から Kubernetes を採用

● 採用が早かった もあり、GKE とオンプレミス 採用が多い

● オンプレミスで 独自 Kubernetes as a Service 基盤を構築

● 新規事業 多くが Kubernetes / Container を利用した開発

● レガシーシステム マイグレーションなども一部で 実施

https://speakerdeck.com/chokkoyamada/midoruuea-webapurimadequan-tewohelmhua-sitasabisufalseyun-yong-shi-li

https://speakerdeck.com/wappy100/legacy-to-container

https://speakerdeck.com/masayaaoyama/saibaezientoniokerupuraibetokontenaji-pan-akewozhi-eruji-shu

CyberAgent 事例　@Japan Container Days v18.12 / v18.04

What is ?

Container Orchestration System 1 つ

Google クラスタマネージャ Borg を元にした OSS

長年 Google 経験が Kubernetes に引き継がれている

現在 Cloud Native Computing Foundation が中立的にホスト

コミュニティによって改良

This is era.

時代 Kubernetes。

一般 ご家庭に 、インスタ映え する手 ひらクラスタ。

みなさん当然持ってますよ ？

is

Container Orchestration System

What is Orchestration?

And that’s history?

Bootstrapping

Configration

Orchestration

Classification of “Provisioning”サーバ 準備

OS インストール

サーバ セットアップ

ミドルウェア インストール・セットアップ

アプリケーション 配置

Provisioning Toolchain, Lee Thompson, 2010-03-17(https://conferences.oreilly.com/velocity/velocity-mar2010/public/schedule/detail/14180)

Bootstrapping

Configration

Orchestration

Baremetal Era - Part 1

温かみ ある 手順書 と 手動構築

温かみ ある 手順書 と 手動設定

温かみ ある 手順書 と 手動配置

Bootstrapping

Configration

Orchestration

Baremetal Era - Part 2

Kickstart

Shell Script

社内ツール、Jenkins

自動化 始まり

But各社秘伝 コードにな

りがち

Bootstrapping

Configration

Orchestration

Cloud Era - Part 1

Terraform

Chef、Ansible、

Puppet、Salt

Fabric、Capistrano

構 化 / 共通化された

自動化 始まり

But再現性が高く ない

構築に時間がかかる

Bootstrapping

Configration

Orchestration

Cloud Era - Part 2

( Terraform )

Packer、Cloud Image

OpenStack HeatAWS Cloud Formation

イメージ化による

高い再現性

Orchestration がBootstrapping を一部兼 る状態に

Butあまり簡単で ない

Bootstrapping

Configration

Orchestration

Cloud Native Era - (Now)

( Terraform )

Docker

Kubernetes

容易なイメージ化

軽量なイメージ

高 な起動と停止

高い抽象度とクラウド非依存

宣言的な API と Code洗練された自動化

But新しい考え方や体制が必要

What is 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)

What is 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 なシステムを実現

Towards

Cloud -> Cloud Native

Cloud Native Trail Map

Trail Map, CNCF, 2019-03-18, (https://github.com/cncf/trailmap)

本日 CI / CD パート 飛 しますが、非常に重要な要素 1 つです。

Merit at first step

Containerization with Docker

1. 容易なイメージ化と再現性 by Docker

アプリケーション と 実行環境 イメージ化

　＝再現性 高い環境

アプリケーション ビルドもコンテナイメージ ビルド時に実施

OCI v1.0 によるポータビリティ

ローカル環境でも同等 動作が保証される

2. 軽量なイメージ by Docker

VM イメージと比べて軽量

単一プロセス みを稼働させるため、軽量 OS 選定もしやすい

3. 高 な起動と停止 by Docker

仮想マシン 起動と停止より高

　コンテナ 起動と停止 プロセス 起動と停止相当

高 な スケールアウト や 障害時 復旧 が可能

Containerization まとめ

1. 容易なイメージ化と再現性

2. 軽量なイメージ

3. 高 な起動と停止

レガシーシステム マイグレーションもスタート地点 ここから

実行環境込み アプリケーションをSystemd に置き換えるイメージ

Merit at next step

Orchestration with Kubernetes

1. 高い抽象度とクラウド非依存 by Kubernetes

Load Balancer や Storage なども抽象化

利用者から見るとクラウド固有 知識がほぼ不要

　vs Terraform、OpenStach Heat、AWS Cloud Formation

ベンダーニュートラルな実行基盤

基本的に ポータビリティがある

2. 宣言的な API と Code by Kubernetes

開発者

Register

YAML Manifest

Kubernetes Cluster

構成情報 Manifests で宣言的に記述して API に登録

（Infrastructure as Code）

$ kubectl apply –f

manifest.yaml

例）複数コンテナ 管理

コンテナ レプリカを作成し

指定した数 コンテナを維持

　（厳密に Pod）

例）複数コンテナ 管理

コンテナ レプリカを作成し

指定した数 コンテナを維持

例）Load Balancer と 連携転送先 ポート番号と

対象とするコンテナを指定

Load Balancer

例）Load Balancer と 連携転送先 ポート番号と

対象とするコンテナを指定

Load Balancer

Control Loop と Reconciliation開発者

マニフェスト 登録Pod 個数を確認し、

必要に応じて Pod 作成や削除

1. 現在 状態を観測

2. 現在 状態と理想状態を比較

3. 差分に対処する処理を実施（Reconcilation）

→ Control Loop

3. 洗練された自動化 by Kubernetes

例）障害時 セルフヒーリング

ReplicaSet で コンテナ Replica 数を維持し続ける

　＝ 障害などでコンテナが不足した場合 、別 Node 上で高 に起動

3. 洗練された自動化 by Kubernetes

例）アプリケーション アップグレード　（厳密に Deployment リソースが必要）

Load Balancer

開発者 マニフェストを変更するだけ

3. 洗練された自動化 by Kubernetes

例）アプリケーション アップグレード　（厳密に Deployment リソースが必要）

Load Balancer• ロードバランサから 除外

• コンテナイメージ アップデート

• Immutable Infrastructure

• ロードバランサへ 追加

3. 洗練された自動化 by Kubernetes

例）アプリケーション アップグレード　（厳密に Deployment リソースが必要）

Load Balancer• ロードバランサから 除外

• コンテナイメージ アップデート

• Immutable Infrastructure

• ロードバランサへ 追加

3. 洗練された自動化 by Kubernetes

例）アプリケーション アップグレード　（厳密に Deployment リソースが必要）

Load Balancer• ロードバランサから 除外

• コンテナイメージ アップデート

• Immutable Infrastructure

• ロードバランサへ 追加

3. 洗練された自動化 by Kubernetes

例）コンテナ（プロセス）単位 ヘルスチェック

例）コンテナ（プロセス）起動前 初期化処理

例）コンテナ（プロセス）停止時 SIGNAL

例）コンテナ（プロセス）開始直後、停止直前 フック

そ 他にも 様々な自動化 や 豊富な機能 が実装されており、

様々なワークロードに対応可能

4. 豊富なエコシステムと拡張性 by Kubernetes

CNCF Cloud Native Interactive Landscape, CNCF, 2019-03-18, (https://landscape.cncf.io/)

他 Container Orchestration System に ない

豊富なエコシステムが様々な要件に対応

例）MySQL Cluster on Kubernetes

開発者 マニフェスト 登録複数個 コンテナを起動し

MySQL Cluster を構成

1. 現在 状態を観測

2. 現在 状態と理想状態を比較

3. 差分に対処する処理を実施（Reconcilation）

→ Control Loop

例）CI/CD on Kubernetes

開発者 マニフェスト 登録Kubernetes 上で

CI/CD Workflow を展開

1. 現在 状態を観測

2. 現在 状態と理想状態を比較

3. 差分に対処する処理を実施（Reconcilation）

→ Control Loop

例）Serverless on Kubernetes

開発者 マニフェスト 登録Kubernetes 上に

Serverless 環境を構築

1. 現在 状態を観測

2. 現在 状態と理想状態を比較

3. 差分に対処する処理を実施（Reconcilation）

→ Control Loop

例）Service Mesh on Kubernetes

開発者 マニフェスト 登録Kubernetes 上で

Service Mesh を構築

1. 現在 状態を観測

2. 現在 状態と理想状態を比較

3. 差分に対処する処理を実施（Reconcilation）

→ Control Loop

例）Managed Service via Kubernetes

開発者 マニフェスト 登録Kubernetes から

マネージドサービスを管理

1. 現在 状態を観測

2. 現在 状態と理想状態を比較

3. 差分に対処する処理を実施（Reconcilation）

→ Control Loop

Cloud SQL

例）YOUR FEATURES with Kubernetes

開発者 マニフェスト 登録独自 処理を記述可能

kubebuilder / Operator SDK

1. 現在 状態を観測

2. 現在 状態と理想状態を比較

3. 差分に対処する処理を実施（Reconcilation）

→ Control Loop

Orchestration まとめ

1. 高い抽象度とクラウド非依存

2. 宣言的な API と Code3. 洗練された自動化

4. 豊富なエコシステムと拡張性

コンテナ 導入 比較的容易

Kubernetes 導入 多少 覚悟 必要

difficulty

Cloud -> Cloud Native

導入難易度

● アプリケーション アーキテクチャ

● セキュリティと分離性

● Kubernetes 学習コスト

● Kubernetes クラスタ 運用

1. アプリケーション アーキテクチャ

基本的に マイクロ/ミニ サービスに適した技術

いつでも停止できるように SIGTERM ハンドリング 必須

　ノード アップグレード、コンテナイメージ アップデート

Service Discovery 経由で通信

ネットワークに一部制約がある（Source IP が消失する等）

2. セキュリティと分離性

仮想化 分離性

　runC（標準 Docker）で Kernel 共有

　gVisor など分離性 高い Conteiner Runtime が登場

ネットワーク 分離性

　Network Policy を利用できない環境で 、

　コンテナ間 通信 筒抜け

3. Kubernetes 学習コスト

学習コスト 小さく ないも 、懸念するほどで ない（CyberAgent 全社横断アンケートより）

コンテナで 開発をスタートした時 学習コスト 辛かったか？

今後もコンテナを用いて開発したいか？

みんな Docker / Kubernetes, 技術評論社, 2019-04-18 (https://www.amazon.co.jp/dp/429710461X)

（再掲）私 メインミッション 1 つオンプレミス上 Kubernetes as a Service

構築・運用

一番辛い

Kubernetes クラスタ 管理

4. Kubernetes クラスタ 運用 つらみ

etcd バックアップ

Kubernetes Master スケールアップ

Kubernetes バージョン アップグレード

Kubernetes クラスタ オートスケール

障害時 ノード復旧

コンテナランタイム（Docker / runC） 管理

OS（Kernel） 管理

etc...

（オンプレ KaaS 提供者から見た）

Google Kubernetes Engine 強みKubernetes Master 管理

Container-Optimized OS

ノード 自動復旧

クラスタ 自動アップグレード

クラスタ オートスケーリング

ノード自動プロビジョニング

マルチクラスタマネジメント、etcGKE On-prem, Google Cloud Platform, 2019-03-25, https://cloud.google.com/gke-on-prem/

マネージド Kubernetes サービス 選定基準

● マネージド 範囲

● クラスタマネジメント 自動化機能

● Kubernetes バージョン 追従スピード

● 他 マネージドサービスと インテグレーション

● Network 周り 要件

● そ 他（virtual-kubelet 対応 etc）

and

で GKE 活用

利用開始が早かったこともあり、

Kubernetes 環境として GKE が多い

GKE クラスタ運用 自動化機能などをフル活用

　（一部プロダクトで 技術選定時に 未実装）

で GKE 活用

レイテンシ要件 にシビアなアドテク領域で利用

新規開発 ほとんどが GKE を利用

ステートフルな部分 GCP 豊富なマネージドサービスを利用

BigQuery Cloud Pub/Sub

Cloud Storage

Cloud Bigtable

Cloud Datastore Cloud SQL Cloud

SpannerCloud

Memorystore

で GKE 活用

まとめ

ネットワーク要件とセキュリティ要件が必須条件

導入難易度 クラスタ 運用が大半

　Kubernetes 利用時 学習コスト自体 そこまで高くない ず

　＝ 自社独自 ツールを利用する に比べたら…

Cloud Native な開発（Kubernetes / Container）を導入することで

組織力を強化し、開発効率を向上させることが可能

Release: 2019/04/19

発売前ですが、本日お話ししたアンケート結果 掲載許可を頂きました。[技術評論社]Docker、そしてKubernetes 活用 広まりつつありますが、それに関する書籍 多く 入門にとどまるも も多く、実際 利用に裏打ちされたノウハウについて 未だまとまった情報がない が現状です。そんななか本書で 、現場でDocker/Kubernetesを活用している読者に向けて、実践 ため 知識や事例 紹介を行います。第1部および第2部 Docker/Kubernetes活用で知られるZ Lab エンジニアによる手厚い解説、第3部 freee、Wantedly、CyberAgent、サイボウズといった幅広い企業で活躍するエンジニアによる事例紹介など、盛り沢山な内容をお届けします!

[インプレス]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とこれから付録

全て GKE ベースで解説（基本的にど 環境でも可）

I love . and

I love GKE

Thank youFollow me :)

@amsy810