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

KubeCon + CloudNativeCon 2017 NorthAmerica @Austin に参加してきた共有資料になります。
社内向けに Keynote 1 + 2 日目と CI/CD 周りの話をまとめてあります。

Transcript

1. KubeCon + CloudNativeCon 2017 社内報告会 〜Keystone day 1,2 + CI/CD Sessions〜 青山 真也, CyberAgent adtech studio
2. 青山 真也 (Masaya Aoyama) @amsy810 普段の主な仕事↓ 世界で 138 番目 https://adtech.cyberagent.io/techblog/ archives/3086
3. 行ってきました
4. KubeCon + CloudNativeCon 2017 @Austin 概要
5. Austin はこんなところ
6. KubeCon + CNCon コンテンツの一覧 Keynote：基調講演 Session：セッション Lightning Talk：LT セッション Salon：特定分野の相談所＋ディスカッションをする場 SIG：特定分野の詳しい話＋ディスカッションをする場 BoF：特定分野の情報交換
7. Keynote は満員。別会場で Live streaming も。
8. Sponsor Booth はいろんな SaaS 等もあり興味深い
9. All Atendees Party 参加者全員による懇親会 Rainy Street の飲み屋を貸し切り！
10. KubeCon Austin 2017 日本人会　主催 コペンハーゲンでまたお会いしましょう！
11. Keynote（1 日目 + α）
12. CNCF Executive Director の Dan Kohn さん 　基本的にコミュニティ周りの話 まず、Kubernetes はデファクトとなり、 CloudNative は全体として 1.0 になった 今回は事実上 CNCF の勝利宣言セッションに近い感じ 1: A Community of Builders: CloudNativeCon Opening Keynote
14. CNCF がホストするプロジェクトが増加 　寄贈もより活発となり、CNCF の全プロジェクトを使うことで 　Cloud Native なアプリケーションが構築可能に 1: A Community of Builders: CloudNativeCon Opening Keynote
15. KubeCon の参加者数は一気に激増 　今回は KubeCon のチケットが完売となりました 1: A Community of Builders: CloudNativeCon Opening Keynote
16. Kubernetes は現状かなり活発な OSS としてデファクトとなりました 1: A Community of Builders: CloudNativeCon Opening Keynote
17. 1: A Community of Builders: CloudNativeCon Opening Keynote Kubernetes の爆発的広がりにつき、Certified Program が開始 　Kubernetes Certified Service Provider：コンサル等の認定企業 　Certified Kubernetes Administrator：K8s 管理者としての技術認定 　Certified Kubernetes Distribution/Platform：K8s としての機能確認
18. 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
19. 2: CNCF Project Updates 各プロジェクトの Update トピックスを紹介 　多くのプロジェクトがこのタイミングで 1.0 化 CNCF からの • CloudNative は既に Ready かつ • デファクトスタンダードを確立した とのメッセージに近い印象を受けました
20. 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 フルサポート
21. 2: CNCF Project Updates Prometheus 2.0 リリース 　　K8s に最適化されたストレージエンジンを導入し、 　　劇的なパフォーマンス改善 • 　　CPU 使用率 1/3 以下 • 　　ディスク使用量半分 • 　　I/O 数 1/100
22. 2: CNCF Project Updates fluentd 1.0 リリース 　　マルチプロセス worker が導入され並列実行可能に 　　sub-second をサポート 　　buffer 最適化により高速化 　　fluentd forwarder protocol v1 リリースにより高速化 　　native tls/ssl サポート 　　
23. 2: CNCF Project Updates fluentbit リリース 　　C 言語 で書かれた CloudNative な軽量 fluentd 　　少ないメモリ使用量と CPU 使用率 　　Event driven / async network IO 　　Build-in TLS/SSL 　　プラグインは使いまわせず現状は 35 個のみ 　　基本的にコンテナからの forward や簡単な filtering 等を想定
24. 3: Accelerating the Digital Transformation OpenStack Foundation が発表した Kata Container の紹介　 　OCI / CRI に準拠し、Intel Clear Containers と Hyper runV をベースとした実装 　コンテナ間でカーネルを共有しないため、よりセキュア 　スポンサーブースで見てきた感じだと即時起動 　
25. 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 の設定化） ◦ デプロイ方法の詳細を抽象化して提供
26. 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 の紹介もちらっとしてました）
27. 6: Service Meshes and Observability OpenTracing を導入することで、複雑な ServiceMesh のデバッグを容易にする ServiceMesh の規模が大きくなると分散トレーシングは必須に API Response が遅いのはどこが影響しているか？ MicroService 化した際に計測するべきところは？
28. 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
29. 7: Kubernetes: This Job is Too Hard デプロイフローを工夫すれば一箇所にまとめることも可能 その他の選択肢として Metaparticle の提案 　言語上に Annotation を付与して Docker Image 生成と K8s へのデプロイを行なう
30. 8: Can 100 Million Developers Use Kubernetes? OpenStack、Hadoop のように熟練者でなくても Kubernetes を使えるように 簡単に誰でも使える OpenFaaS を使った Function as a Service プラットフォーム
31. 8: Can 100 Million Developers Use Kubernetes? 開発者はコードを書いて OpenFaaS に登録するだけ 　Docker Image 登録は OpenFaaS にお任せ 　HTTP Path > Function の登録を行なう 　スケーリングも自動で行われる
32. 9: KubeCon Opening Keynote - Project Update ちなみに 2 日目からは KubeCon + CNCon K8s クラスタ構築のデモ + CI/CD 周りのデモ
33. 9: KubeCon Opening Keynote - Project Update まさかの音声クラスタ構築と deployment の scaling 「OK, Google. Create Kubernetes Cluster...」
34. 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
35. 9: KubeCon Opening Keynote - Project Update アプリケーション開発者は CI/CD Pipeline を確立し、kubectl を使う必要はない 　＝ kubectl は ssh と同等（kubectl exec -it SOMETHING /bin/sh） Replica 数は Kubernetes Manifest YAML には書かない 　＝ Manifest の apply 時に変更されないように
36. 9: KubeCon Opening Keynote - Project Update 余談ですが、サイン本を頂きつつ写真を撮ってもらいました
37. CI / CD
38. Using Containers for Continuous Integration and Continuous Delivery Jenkins のスケーリング手法 • 1 Master に Agent を沢山ぶら下げる ◦ Master が SPOF ◦ Agent の管理が必要 ◦ エージェント数に限界がある • 複数 Master を用意する ◦ SSO ◦ 共通設定や管理の集中化を考える必要がある 結構しんどい。
39. Using Containers for Continuous Integration and Continuous Delivery
40. 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
41. Deploying to Kubernetes Thousands of Times Per/Day Kubernetes を使って High Velocity を実現しましょう！ 　※ 変更から反映までの間隔を出来るだけ短くすること
42. Deploying to Kubernetes Thousands of Times Per/Day １．Image First • Immutable なコンテナにする • Entrypoint を設定してそのまま起動できるようにする • local / dev / prd で同じイメージを利用する • latest タグは使わない • GitHub の特定のコミットと Image Tag を紐付けておく • local でビルドして push はしない（自動化必須）
43. Deploying to Kubernetes Thousands of Times Per/Day ２．Shift Left テストは出来るだけ前倒ししましょう Bottleneck
44. Deploying to Kubernetes Thousands of Times Per/Day ３．Maintain Application Portability クラスタが消し飛んだときに復旧できますか？　（会場では x hour ~ x day の声） ちゃんと移行出来るようにメンテナンスをし続ける • 設定ファイルはコンテナイメージに内包せず ConfigMap / Secret を使う ◦ Docker Build は出来るだけ避ける ◦ 環境変化に強い設計にする • Helm Charts 化も検討する • ディザスタリカバリのテストもする
45. Deploying to Kubernetes Thousands of Times Per/Day ４．Outsource Cluster Management • クラスタの管理は専門チームに任せる • スケーラビリティや冗長化の計画を持っておく • Certified Kubernetes Conformance Program に準拠した構成にしましょう ◦ 一部の Kubernetes 環境にしかない機能に依存すると移行が難しい
46. Deploying to Kubernetes Thousands of Times Per/Day CodeFresh 　Kubernetes に特化した Spinnaker + CircleCI + DockerHub のようなもの？ • Github のコード変更 • Docker Image の作成 • Deployment の Config や Helm Charts を生成 • （Performance Test） • Kubernetes クラスタにデプロイ
47. Deploying to Kubernetes Thousands of Times Per/Day
48. Continuous Delivery with Kubernetes at Box Kubernetes Cluster の状態 ＝ Github のリポジトリになるように構築 Docker Build 時に YAML を自動生成して manifest Github に PR をする方式 Kubernetes Cluster GitHub k8s YAML manifest ＝
49. Continuous Delivery with Kubernetes at Box Kubernetes クラスタに Agent を仕込んでおく 　クラスタの状態となる Github を Agent に登録 Agent が Github を監視して変更があれば反映 障害時にも Agent を入れるだけで復旧可能 Kubernetes Cluster GitHub k8s YAML manifest ＝
50. 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 内でのパフォーマンスチェック
51. 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() })
52. Microservices, Service Mesh, and CI/CD Pipelines: Making It All Work Together あとこのセッションでちょっと納得したのは • PR で Canary リリース • Merge で正式リリース というのは良さそうだなと思いました
53. 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)
54. GitOps - Operations by Pull Request GitOps の 3 つの法則 • システム全体が正常に稼働する状態を Git で管理する • 実際の状態と Git の状態（想定する状態）の差分を比較 • 全ての変更操作は PR 経由で実行する
55. GitOps - Operations by Pull Request GitOps の 3 つの柱 • Pipeline • Observility • Controll この３つをベースに話して行きます
56. GitOps - Operations by Pull Request Pipeline • 1 Repository は 1 app / service で構成 • ブランチは prd / stg / dev などで切る • ブランチは Namespace か Cluster にマップさせる • stg に展開するときは stg ブランチにマージしたら自動で行われる • ブランチはプロテクトしてレビューを必須にする
57. GitOps - Operations by Pull Request
58. GitOps - Operations by Pull Request Observility メトリクス等を駆使して PR をマージしていいかを判断する レスポンスタイムが 100ms 以下かどうか等 Controll すべては Git を介して行い Kuberentes を直接操作しない
59. Developer Tooling for Kubernetes Configuration Validation（kubeval） • Manifest YAML のフォーマットが正しいかどうか Unit Test（kubetest） • podSpec のチェック • label 設定のチェック • 特権コンテナを使っていないかのチェック • etc… jsonnet や helm charts などでもテスト可能
60. Webhooks for Automated Updates DockerHub の Webhook を使った自動デプロイ 　CircleCI / ConcourceCI などから K8s を操作するのではなく直でやる方法
61. Webhooks for Automated Updates Rancher の Webhook Framework を使うとココらへんが自動化出来るらしい 　早い話が Webhook 用の管理サーバを Rancher が請け負うよって形
62. そして…
63. 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