Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥

KubeCon + CloudNativeCon 2017 社内報告会資料 〜Keystone...

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

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

Masaya Aoyama (@amsy810)

January 09, 2018
Tweet

More Decks by Masaya Aoyama (@amsy810)

Other Decks in Technology

Transcript

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

    Sessions〜 青山 真也, CyberAgent adtech studio
  2. CNCF Executive Director の Dan Kohn さん  基本的にコミュニティ周りの話 まず、Kubernetes はデファクトとなり、

    CloudNative は全体として 1.0 になった 今回は事実上 CNCF の勝利宣言セッションに近い感じ 1: A Community of Builders: CloudNativeCon Opening Keynote
  3. 1: A Community of Builders: CloudNativeCon Opening Keynote Kubernetes の爆発的広がりにつき、Certified

    Program が開始  Kubernetes Certified Service Provider:コンサル等の認定企業  Certified Kubernetes Administrator:K8s 管理者としての技術認定  Certified Kubernetes Distribution/Platform:K8s としての機能確認
  4. 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
  5. 2: CNCF Project Updates 各プロジェクトの Update トピックスを紹介  多くのプロジェクトがこのタイミングで 1.0 化

    CNCF からの • CloudNative は既に Ready かつ • デファクトスタンダードを確立した とのメッセージに近い印象を受けました
  6. 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 フルサポート
  7. 2: CNCF Project Updates fluentd 1.0 リリース   マルチプロセス worker が導入され並列実行可能に

      sub-second をサポート   buffer 最適化により高速化   fluentd forwarder protocol v1 リリースにより高速化   native tls/ssl サポート   
  8. 2: CNCF Project Updates fluentbit リリース   C 言語 で書かれた CloudNative

    な軽量 fluentd   少ないメモリ使用量と CPU 使用率   Event driven / async network IO   Build-in TLS/SSL   プラグインは使いまわせず現状は 35 個のみ   基本的にコンテナからの forward や簡単な filtering 等を想定
  9. 3: Accelerating the Digital Transformation OpenStack Foundation が発表した Kata Container

    の紹介   OCI / CRI に準拠し、Intel Clear Containers と Hyper runV をベースとした実装  コンテナ間でカーネルを共有しないため、よりセキュア  スポンサーブースで見てきた感じだと即時起動  
  10. 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 の設定化) ◦ デプロイ方法の詳細を抽象化して提供
  11. 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 の紹介もちらっとしてました)
  12. 6: Service Meshes and Observability OpenTracing を導入することで、複雑な ServiceMesh のデバッグを容易にする ServiceMesh

    の規模が大きくなると分散トレーシングは必須に API Response が遅いのはどこが影響しているか? MicroService 化した際に計測するべきところは?
  13. 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
  14. 7: Kubernetes: This Job is Too Hard デプロイフローを工夫すれば一箇所にまとめることも可能 その他の選択肢として Metaparticle

    の提案  言語上に Annotation を付与して Docker Image 生成と K8s へのデプロイを行なう
  15. 8: Can 100 Million Developers Use Kubernetes? OpenStack、Hadoop のように熟練者でなくても Kubernetes

    を使えるように 簡単に誰でも使える OpenFaaS を使った Function as a Service プラットフォーム
  16. 8: Can 100 Million Developers Use Kubernetes? 開発者はコードを書いて OpenFaaS に登録するだけ

     Docker Image 登録は OpenFaaS にお任せ  HTTP Path > Function の登録を行なう  スケーリングも自動で行われる
  17. 9: KubeCon Opening Keynote - Project Update ちなみに 2 日目からは

    KubeCon + CNCon K8s クラスタ構築のデモ + CI/CD 周りのデモ
  18. 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
  19. 9: KubeCon Opening Keynote - Project Update アプリケーション開発者は CI/CD Pipeline

    を確立し、kubectl を使う必要はない  = kubectl は ssh と同等(kubectl exec -it SOMETHING /bin/sh) Replica 数は Kubernetes Manifest YAML には書かない  = Manifest の apply 時に変更されないように
  20. Using Containers for Continuous Integration and Continuous Delivery Jenkins のスケーリング手法

    • 1 Master に Agent を沢山ぶら下げる ◦ Master が SPOF ◦ Agent の管理が必要 ◦ エージェント数に限界がある • 複数 Master を用意する ◦ SSO ◦ 共通設定や管理の集中化を考える必要がある 結構しんどい。
  21. 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
  22. Deploying to Kubernetes Thousands of Times Per/Day Kubernetes を使って High

    Velocity を実現しましょう!  ※ 変更から反映までの間隔を出来るだけ短くすること
  23. Deploying to Kubernetes Thousands of Times Per/Day 1.Image First •

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

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

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

    Spinnaker + CircleCI + DockerHub のようなもの? • Github のコード変更 • Docker Image の作成 • Deployment の Config や Helm Charts を生成 • (Performance Test) • Kubernetes クラスタにデプロイ
  27. Continuous Delivery with Kubernetes at Box Kubernetes Cluster の状態 =

    Github のリポジトリになるように構築 Docker Build 時に YAML を自動生成して manifest Github に PR をする方式 Kubernetes Cluster GitHub k8s YAML manifest =
  28. Continuous Delivery with Kubernetes at Box Kubernetes クラスタに Agent を仕込んでおく

     クラスタの状態となる Github を Agent に登録 Agent が Github を監視して変更があれば反映 障害時にも Agent を入れるだけで復旧可能 Kubernetes Cluster GitHub k8s YAML manifest =
  29. 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 内でのパフォーマンスチェック
  30. 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() })
  31. Microservices, Service Mesh, and CI/CD Pipelines: Making It All Work

    Together あとこのセッションでちょっと納得したのは • PR で Canary リリース • Merge で正式リリース というのは良さそうだなと思いました
  32. 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)
  33. GitOps - Operations by Pull Request GitOps の 3 つの法則

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

    • Pipeline • Observility • Controll この3つをベースに話して行きます
  35. GitOps - Operations by Pull Request Pipeline • 1 Repository

    は 1 app / service で構成 • ブランチは prd / stg / dev などで切る • ブランチは Namespace か Cluster にマップさせる • stg に展開するときは stg ブランチにマージしたら自動で行われる • ブランチはプロテクトしてレビューを必須にする
  36. GitOps - Operations by Pull Request Observility メトリクス等を駆使して PR をマージしていいかを判断する

    レスポンスタイムが 100ms 以下かどうか等 Controll すべては Git を介して行い Kuberentes を直接操作しない
  37. Developer Tooling for Kubernetes Configuration Validation(kubeval) • Manifest YAML のフォーマットが正しいかどうか

    Unit Test(kubetest) • podSpec のチェック • label 設定のチェック • 特権コンテナを使っていないかのチェック • etc… jsonnet や helm charts などでもテスト可能
  38. Webhooks for Automated Updates DockerHub の Webhook を使った自動デプロイ  CircleCI /

    ConcourceCI などから K8s を操作するのではなく直でやる方法
  39. 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