Kube con + cloudnativecon 2017 社内報告会（外部公開用）

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

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

KubeCon + CloudNativeCon 2017 @Austin
概要

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

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

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

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

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

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

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

KubeCon の参加者数は一気に激増
　今回は KubeCon のチケットが完売となりました

Kubernetes は現状かなり活発な OSS としてデファクトとなりました

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

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

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

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

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

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

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

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

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 の設定化）
○ デプロイ方法の詳細を抽象化して提供

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 の紹介もちらっとしてました）

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

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

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

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

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

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

まさかの音声クラスタ構築と deployment の scaling
「OK, Google. Create Kubernetes Cluster...」

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

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

余談ですが、サイン本を頂きつつ写真を撮ってもらいました

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

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

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

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

２．Shift Left
テストは出来るだけ前倒ししましょう
Bottleneck

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

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

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

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

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

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 内でのパフォーマンスチェック

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()
})

あとこのセッションでちょっと納得したのは
● PR で Canary リリース
● Merge で正式リリース
というのは良さそうだなと思いました

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)

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

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

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

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

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

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

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

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

Kube con + cloudnativecon 2017 社内報告会（外部公開用）

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Kube con + cloudnativecon 2017 社内報告会（外部公開用）

Similaire à Kube con + cloudnativecon 2017 社内報告会（外部公開用） (20)

Kube con + cloudnativecon 2017 社内報告会（外部公開用）