KubeCon + CloudNativeCon 2017 社内報告会資料〜Keystone day 1,2 + CI/CD Sessions〜

by Masaya Aoyama (@amsy810)

Slide 1

Slide 1 text

KubeCon + CloudNativeCon 2017 社内報告会〜Keystone day 1,2 + CI/CD Sessions〜青山真也, CyberAgent adtech studio

Slide 2

Slide 2 text

青山真也 (Masaya Aoyama) @amsy810 普段の主な仕事↓ 世界で 138 番目 https://adtech.cyberagent.io/techblog/ archives/3086

Slide 3

Slide 3 text

行ってきました

Slide 4

Slide 4 text

KubeCon + CloudNativeCon 2017 @Austin 概要

Slide 5

Slide 5 text

Austin はこんなところ

Slide 6

Slide 6 text

KubeCon + CNCon コンテンツの一覧 Keynote：基調講演 Session：セッション Lightning Talk：LT セッション Salon：特定分野の相談所＋ディスカッションをする場 SIG：特定分野の詳しい話＋ディスカッションをする場 BoF：特定分野の情報交換

Slide 7

Slide 7 text

Keynote は満員。別会場で Live streaming も。

Slide 8

Slide 8 text

Sponsor Booth はいろんな SaaS 等もあり興味深い

Slide 9

Slide 9 text

All Atendees Party 参加者全員による懇親会 Rainy Street の飲み屋を貸し切り！

Slide 10

Slide 10 text

KubeCon Austin 2017 日本人会　主催コペンハーゲンでまたお会いしましょう！

Slide 11

Slide 11 text

Keynote（1 日目 + α）

Slide 12

Slide 12 text

CNCF Executive Director の Dan Kohn さん　基本的にコミュニティ周りの話まず、Kubernetes はデファクトとなり、 CloudNative は全体として 1.0 になった今回は事実上 CNCF の勝利宣言セッションに近い感じ 1: A Community of Builders: CloudNativeCon Opening Keynote

Slide 13

Slide 13 text

No content

Slide 14

Slide 14 text

CNCF がホストするプロジェクトが増加　寄贈もより活発となり、CNCF の全プロジェクトを使うことで　Cloud Native なアプリケーションが構築可能に 1: A Community of Builders: CloudNativeCon Opening Keynote

Slide 15

Slide 15 text

KubeCon の参加者数は一気に激増　今回は KubeCon のチケットが完売となりました 1: A Community of Builders: CloudNativeCon Opening Keynote

Slide 16

Slide 16 text

Kubernetes は現状かなり活発な OSS としてデファクトとなりました 1: A Community of Builders: CloudNativeCon Opening Keynote

Slide 17

Slide 17 text

1: A Community of Builders: CloudNativeCon Opening Keynote Kubernetes の爆発的広がりにつき、Certified Program が開始　Kubernetes Certified Service Provider：コンサル等の認定企業　Certified Kubernetes Administrator：K8s 管理者としての技術認定　Certified Kubernetes Distribution/Platform：K8s としての機能確認

Slide 18

Slide 18 text

1: A Community of Builders: CloudNativeCon Opening Keynote 2018 年の KubeCon ● KubeCon + CloudNativeCon Europe 2018 ○ コペンハーゲン　デンマーク ○ 2018/5/2-4 ● KubeCon + CloudNativeCon China 2018 ○ 上海　中国 ○ 2018/11/14-15 ● KubeCon + CloudNativeCon North America 2018 ○ シアトル　アメリカワシントン州 ○ 2018/12/11-13

Slide 19

Slide 19 text

2: CNCF Project Updates 各プロジェクトの Update トピックスを紹介　多くのプロジェクトがこのタイミングで 1.0 化 CNCF からの ● CloudNative は既に Ready かつ ● デファクトスタンダードを確立したとのメッセージに近い印象を受けました

Slide 20

Slide 20 text

2: CNCF Project Updates Kubernetes 1.9 リリース　　Workload API が app/v1 リリース　　kube-dns の実装が SkyDNS > CoreDNS に（alpha） CoreDNS 1.0 リリース containerd 1.0 が OCI 準拠な実装としてリリース rktlet が CRI / OCI 準拠な実装としてリリース CNI の IPv6 フルサポート

Slide 21

Slide 21 text

2: CNCF Project Updates Prometheus 2.0 リリース　　K8s に最適化されたストレージエンジンを導入し、　　劇的なパフォーマンス改善 ● 　　CPU 使用率 1/3 以下 ● 　　ディスク使用量半分 ● 　　I/O 数 1/100

Slide 22

Slide 22 text

2: CNCF Project Updates fluentd 1.0 リリース　　マルチプロセス worker が導入され並列実行可能に　　sub-second をサポート　　buffer 最適化により高速化　　fluentd forwarder protocol v1 リリースにより高速化　　native tls/ssl サポート　　

Slide 23

Slide 23 text

2: CNCF Project Updates fluentbit リリース　　C 言語で書かれた CloudNative な軽量 fluentd 　　少ないメモリ使用量と CPU 使用率　　Event driven / async network IO 　　Build-in TLS/SSL 　　プラグインは使いまわせず現状は 35 個のみ　　基本的にコンテナからの forward や簡単な filtering 等を想定

Slide 24

Slide 24 text

3: Accelerating the Digital Transformation OpenStack Foundation が発表した Kata Container の紹介　　OCI / CRI に準拠し、Intel Clear Containers と Hyper runV をベースとした実装　コンテナ間でカーネルを共有しないため、よりセキュア　スポンサーブースで見てきた感じだと即時起動　

Slide 25

Slide 25 text

4: Cloud Native CD: Spinnaker and the Culture Behind the Tech Netflix の Spinnaker が出来るまでのテクノロジーの歴史 ● 時間区切りで Deploy タイミングを指定する Time Window ● トラフィックガード機能 ● Canary / Blue-Green デプロイ ● Manual Judgement によるデプロイ判断のフロー ● 今後の展望 ○ CI ○ Declartive CD （恐らく宣言的コードによる CD の設定化） ○ デプロイ方法の詳細を抽象化して提供

Slide 26

Slide 26 text

5: Cloud Native at AWS Elastic Kubernetes Service ● コミュニティへの Contribute を元に EKS を改良（Open & Management K8s） ○ kube2iam ■ IAM role を pod に割り当てる（ServiceAccount / RBAC） ○ AWS CNI plugin ■ VM に NIC をアタッチし Pod NW と VPC NW をマッピング ● 各種 AWS Service との Integration ● 3 AZ にまたがって etcd / k8s master が展開 ○ GKE はシングルマスタらしい（一応コンテナ課金の Fargate の紹介もちらっとしてました）

Slide 27

Slide 27 text

6: Service Meshes and Observability OpenTracing を導入することで、複雑な ServiceMesh のデバッグを容易にする ServiceMesh の規模が大きくなると分散トレーシングは必須に API Response が遅いのはどこが影響しているか？ MicroService 化した際に計測するべきところは？

Slide 28

Slide 28 text

7: Kubernetes: This Job is Too Hard 例えば Application の bind port を 8080 から 7070 に変える 1. アプリケーションのコードを変えてビルド 2. Dockerfile の EXPOSE を変えてビルド 3. K8s の Service 定義や Pod Template を変えてデプロイ Files Language Tools Application .java, etc Java, etc Editor Docker Dockerfile Dockerfile docker Kubernetes k8s config YAML kubectl

Slide 29

Slide 29 text

7: Kubernetes: This Job is Too Hard デプロイフローを工夫すれば一箇所にまとめることも可能その他の選択肢として Metaparticle の提案　言語上に Annotation を付与して Docker Image 生成と K8s へのデプロイを行なう

Slide 30

Slide 30 text

8: Can 100 Million Developers Use Kubernetes? OpenStack、Hadoop のように熟練者でなくても Kubernetes を使えるように簡単に誰でも使える OpenFaaS を使った Function as a Service プラットフォーム

Slide 31

Slide 31 text

8: Can 100 Million Developers Use Kubernetes? 開発者はコードを書いて OpenFaaS に登録するだけ　Docker Image 登録は OpenFaaS にお任せ　HTTP Path > Function の登録を行なう　スケーリングも自動で行われる

Slide 32

Slide 32 text

9: KubeCon Opening Keynote - Project Update ちなみに 2 日目からは KubeCon + CNCon K8s クラスタ構築のデモ + CI/CD 周りのデモ

Slide 33

Slide 33 text

9: KubeCon Opening Keynote - Project Update まさかの音声クラスタ構築と deployment の scaling 「OK, Google. Create Kubernetes Cluster...」

Slide 34

Slide 34 text

9: KubeCon Opening Keynote - Project Update 1. アプリケーションコードの変更 a. git clone HOGE; b. git checkout -b funcA; c. vi test.java; d. git push origin funcA e. PR を出す f. Merge する（Dev 環境へ反映） g. Docker Image の build h. Registry への upload i. リリース Tag を打つ 2. Kubernetes クラスタへの反映 a. 上記で Tag を打ったことで、Kubernetes Manifest YAML が生成されて PR が自動で出される b. マージすると apply される（本番適用） GitHub k8s YAML manifest GitHub Application Code

Slide 35

Slide 35 text

9: KubeCon Opening Keynote - Project Update アプリケーション開発者は CI/CD Pipeline を確立し、kubectl を使う必要はない　＝ kubectl は ssh と同等（kubectl exec -it SOMETHING /bin/sh） Replica 数は Kubernetes Manifest YAML には書かない　＝ Manifest の apply 時に変更されないように

Slide 36

Slide 36 text

9: KubeCon Opening Keynote - Project Update 余談ですが、サイン本を頂きつつ写真を撮ってもらいました

Slide 37

Slide 37 text

CI / CD

Slide 38

Slide 38 text

Using Containers for Continuous Integration and Continuous Delivery Jenkins のスケーリング手法 ● 1 Master に Agent を沢山ぶら下げる ○ Master が SPOF ○ Agent の管理が必要 ○ エージェント数に限界がある ● 複数 Master を用意する ○ SSO ○ 共通設定や管理の集中化を考える必要がある結構しんどい。

Slide 39

Slide 39 text

Using Containers for Continuous Integration and Continuous Delivery

Slide 40

Slide 40 text

Using Containers for Continuous Integration and Continuous Delivery podTemplate(label: 'mypod') { node('mypod') { sh 'Hello world!' } } build task をコンテナとして起動 Groovy で記述可能 PodTemplate と同等の表現力 https://github.com/jenkinsci/kubernetes-plugin

Slide 41

Slide 41 text

Deploying to Kubernetes Thousands of Times Per/Day Kubernetes を使って High Velocity を実現しましょう！　※ 変更から反映までの間隔を出来るだけ短くすること

Slide 42

Slide 42 text

Deploying to Kubernetes Thousands of Times Per/Day １．Image First ● Immutable なコンテナにする ● Entrypoint を設定してそのまま起動できるようにする ● local / dev / prd で同じイメージを利用する ● latest タグは使わない ● GitHub の特定のコミットと Image Tag を紐付けておく ● local でビルドして push はしない（自動化必須）

Slide 43

Slide 43 text

Deploying to Kubernetes Thousands of Times Per/Day ２．Shift Left テストは出来るだけ前倒ししましょう Bottleneck

Slide 44

Slide 44 text

Deploying to Kubernetes Thousands of Times Per/Day ３．Maintain Application Portability クラスタが消し飛んだときに復旧できますか？　（会場では x hour ~ x day の声）ちゃんと移行出来るようにメンテナンスをし続ける ● 設定ファイルはコンテナイメージに内包せず ConfigMap / Secret を使う ○ Docker Build は出来るだけ避ける ○ 環境変化に強い設計にする ● Helm Charts 化も検討する ● ディザスタリカバリのテストもする

Slide 45

Slide 45 text

Deploying to Kubernetes Thousands of Times Per/Day ４．Outsource Cluster Management ● クラスタの管理は専門チームに任せる ● スケーラビリティや冗長化の計画を持っておく ● Certified Kubernetes Conformance Program に準拠した構成にしましょう ○ 一部の Kubernetes 環境にしかない機能に依存すると移行が難しい

Slide 46

Slide 46 text

Deploying to Kubernetes Thousands of Times Per/Day CodeFresh 　Kubernetes に特化した Spinnaker + CircleCI + DockerHub のようなもの？ ● Github のコード変更 ● Docker Image の作成 ● Deployment の Config や Helm Charts を生成 ● （Performance Test） ● Kubernetes クラスタにデプロイ

Slide 47

Slide 47 text

Deploying to Kubernetes Thousands of Times Per/Day

Slide 48

Slide 48 text

Continuous Delivery with Kubernetes at Box Kubernetes Cluster の状態＝ Github のリポジトリになるように構築 Docker Build 時に YAML を自動生成して manifest Github に PR をする方式 Kubernetes Cluster GitHub k8s YAML manifest ＝

Slide 49

Slide 49 text

Continuous Delivery with Kubernetes at Box Kubernetes クラスタに Agent を仕込んでおく　クラスタの状態となる Github を Agent に登録 Agent が Github を監視して変更があれば反映障害時にも Agent を入れるだけで復旧可能 Kubernetes Cluster GitHub k8s YAML manifest ＝

Slide 50

Slide 50 text

Microservices, Service Mesh, and CI/CD Pipelines: Making It All Work Together Istio + BRIGADE + kashti (WebUI) を使った ServiceMesh + CI/CD 環境 Istio を使うことで ● トラフィックコントロール ○ Canary リリース ● Chaos テストのために Fault injection（遅延やドロップ） ○ 障害試験 ● メトリクスのスコアリング ○ パフォーマンス低下の検知 ○ 複雑な ServiceMesh 内でのパフォーマンスチェック

Slide 51

Slide 51 text

Microservices, Service Mesh, and CI/CD Pipelines: Making It All Work Together Istio + BRIGADE + kashti (WebUI) を使った ServiceMesh + CI/CD 環境 BRIGADE を使うことで ● Event driven な CI/CD Pipeline ○ DockerHub の変更を検知 ○ Github の変更を検知 ● JavaScript による Pipeline 定義 ○ コード化が可能 ● 全てを網羅 ○ Go binary の作成、Docker Image の作成、Helm Charts の作成、Slack 通知 events.on("exec", () => { var job = new Job("test", "alpine:3.4") job.tasks = [ "echo Hello", "echo World" ] job.run() })

Slide 52

Slide 52 text

Microservices, Service Mesh, and CI/CD Pipelines: Making It All Work Together あとこのセッションでちょっと納得したのは ● PR で Canary リリース ● Merge で正式リリースというのは良さそうだなと思いました

Slide 53

Slide 53 text

Building Better Containers: A Survey of Container Build Tools 現状の Dockerfile の問題 ● イメージの再現性が乏しい ● Bash での Programmability ● イメージフォーマット間での連携が弱い Dockerfile 使ってコンテナイメージ作る時代はきっと終わるよ！ [ソースからイメージビルド] source-to-image (s2i) buildkit habitat 詳しくは凄い量になるので、付録の SpreadSheet で。 [従来方式] buildah nixos-container ansible-container smith (distroless)

Slide 54

Slide 54 text

GitOps - Operations by Pull Request GitOps の 3 つの法則 ● システム全体が正常に稼働する状態を Git で管理する ● 実際の状態と Git の状態（想定する状態）の差分を比較 ● 全ての変更操作は PR 経由で実行する

Slide 55

Slide 55 text

GitOps - Operations by Pull Request GitOps の 3 つの柱 ● Pipeline ● Observility ● Controll この３つをベースに話して行きます

Slide 56

Slide 56 text

GitOps - Operations by Pull Request Pipeline ● 1 Repository は 1 app / service で構成 ● ブランチは prd / stg / dev などで切る ● ブランチは Namespace か Cluster にマップさせる ● stg に展開するときは stg ブランチにマージしたら自動で行われる ● ブランチはプロテクトしてレビューを必須にする

Slide 57

Slide 57 text

GitOps - Operations by Pull Request

Slide 58

Slide 58 text

GitOps - Operations by Pull Request Observility メトリクス等を駆使して PR をマージしていいかを判断するレスポンスタイムが 100ms 以下かどうか等 Controll すべては Git を介して行い Kuberentes を直接操作しない

Slide 59

Slide 59 text

Developer Tooling for Kubernetes Configuration Validation（kubeval） ● Manifest YAML のフォーマットが正しいかどうか Unit Test（kubetest） ● podSpec のチェック ● label 設定のチェック ● 特権コンテナを使っていないかのチェック ● etc… jsonnet や helm charts などでもテスト可能

Slide 60

Slide 60 text

Webhooks for Automated Updates DockerHub の Webhook を使った自動デプロイ　CircleCI / ConcourceCI などから K8s を操作するのではなく直でやる方法

Slide 61

Slide 61 text

Webhooks for Automated Updates Rancher の Webhook Framework を使うとココらへんが自動化出来るらしい　早い話が Webhook 用の管理サーバを Rancher が請け負うよって形

Slide 62

Slide 62 text

そして…

Slide 63

Slide 63 text

is coming soon... 来年はココらへんの話で発表したい！「GKE 互換のオンプレコンテナ基盤 AKE (Adtech Container Engine)」 https://developers.cyberagent.co.jp/blog/archives/12058/ 「Kubernetes をいじって Hardware LoadBalancer で “type LoadBalancer” を実装」 https://adtech.cyberagent.io/techblog/archives/3127 「オンプレでも GKE Like な Ingress を使うために自作 Ingress Controller を実装」 https://adtech.cyberagent.io/techblog/archives/3758