Recap: [Code fresh] Deploying to kubernetes thousands of times per day @kuber...Masaya Aoyama
Kubernetes Meetup #9 @CyberAgent は KubeCon + CNCon 2017 North America Austin の Recap スペシャルということで、「Deploying to Kubernetes Thousands of Times Per Day」 についてお話させていただきました。
High Velocity の重要性と、CI/CD Pipeline を作るときに注意するべきポイントを話した上で、CodeFresh について紹介しました。
[Japan Container Days v18.04 Keynote (Production User Stories)]
CyberAgentではプライベートクラウド上にGKEライクなコンテナ基盤を展開するサービスを提供しています。最近では様々な利便性からコンテナでの開発が増えており、オンプレ環境でも Kubernetes as a Serviceの需要があります。サーバ上にKubernetesを展開するだけでは利用できないLoadBalancerやIngressを実現する方法やOpenStackとの連携方法について説明しながら、アドテク領域での利用に耐えうるコンテナ基盤の事例を紹介します。
by Masaya Aoyama (@amsy810)
OpenStack上に展開するContainer as a Service を本番で利用するために必要だったことMasaya Aoyama
OpenStack上に展開するContainer as a Service を本番で利用するために必要だったこと
at OpenStack Days / Cloud Native Days 2018
CyberAgent, Inc
adtech studio
Strategic Infrastructure Agency
@amsy810
@makocchi
Recap: [Code fresh] Deploying to kubernetes thousands of times per day @kuber...Masaya Aoyama
Kubernetes Meetup #9 @CyberAgent は KubeCon + CNCon 2017 North America Austin の Recap スペシャルということで、「Deploying to Kubernetes Thousands of Times Per Day」 についてお話させていただきました。
High Velocity の重要性と、CI/CD Pipeline を作るときに注意するべきポイントを話した上で、CodeFresh について紹介しました。
[Japan Container Days v18.04 Keynote (Production User Stories)]
CyberAgentではプライベートクラウド上にGKEライクなコンテナ基盤を展開するサービスを提供しています。最近では様々な利便性からコンテナでの開発が増えており、オンプレ環境でも Kubernetes as a Serviceの需要があります。サーバ上にKubernetesを展開するだけでは利用できないLoadBalancerやIngressを実現する方法やOpenStackとの連携方法について説明しながら、アドテク領域での利用に耐えうるコンテナ基盤の事例を紹介します。
by Masaya Aoyama (@amsy810)
OpenStack上に展開するContainer as a Service を本番で利用するために必要だったことMasaya Aoyama
OpenStack上に展開するContainer as a Service を本番で利用するために必要だったこと
at OpenStack Days / Cloud Native Days 2018
CyberAgent, Inc
adtech studio
Strategic Infrastructure Agency
@amsy810
@makocchi
KueCon 2020 NA Recap - Building a Global Supercomputer with Virtual Kubelet /...Preferred Networks
KubeCon + CloudNativeCon North America 2020 における Building a Global Supercomputer with Virtual Kubelet という講演を振り返りながら、Kubernetes における multi-cluster scheduling の最新情報と現時点での課題を紹介します。
KueCon 2020 NA Recap - Building a Global Supercomputer with Virtual Kubelet /...Preferred Networks
KubeCon + CloudNativeCon North America 2020 における Building a Global Supercomputer with Virtual Kubelet という講演を振り返りながら、Kubernetes における multi-cluster scheduling の最新情報と現時点での課題を紹介します。
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
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 の登録を行なう
スケーリングも自動で行われる
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
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
1.Image First
● Immutable なコンテナにする
● Entrypoint を設定してそのまま起動できるようにする
● local / dev / prd で同じイメージを利用する
● latest タグは使わない
● GitHub の特定のコミットと Image Tag を紐付けておく
● local でビルドして push はしない(自動化必須)
43. Deploying to Kubernetes Thousands of Times Per/Day
2.Shift Left
テストは出来るだけ前倒ししましょう
Bottleneck
44. Deploying to Kubernetes Thousands of Times Per/Day
3.Maintain Application Portability
クラスタが消し飛んだときに復旧できますか? (会場では x hour ~ x day の声)
ちゃんと移行出来るようにメンテナンスをし続ける
● 設定ファイルはコンテナイメージに内包せず ConfigMap / Secret を使う
○ Docker Build は出来るだけ避ける
○ 環境変化に強い設計にする
● Helm Charts 化も検討する
● ディザスタリカバリのテストもする
45. Deploying to Kubernetes Thousands of Times Per/Day
4.Outsource Cluster Management
● クラスタの管理は専門チームに任せる
● スケーラビリティや冗長化の計画を持っておく
● Certified Kubernetes Conformance Program に準拠した構成にしましょう
○ 一部の Kubernetes 環境にしかない機能に依存すると移行が難しい
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)