“Kubernetes クラスター切り替えて ください” のオモテウラ @capsmalt Kazufumi Saito 1 Cloud Native Days Tokyo 2020 #CNDT2020

2 2020年， 気がつけば Kubernetes の世界に

3

“Kubernetes クラスター 切り替えてください” 4

5 2020年元旦 わずか1⽇ https://twitter .com/capsmalt/status/1213103609677672453?s=21 “切り替えて” ! ! ! ! ! Twitter⺠ ! @capsmalt

6 オモテ ウラ K8s めちゃ良い︕便利︕カッコいい︕︕︕ デファクトでしょ︕ え︖無理。 やれるもんならやってみ︖

7 何が無理︖根本的な課題は︖ いま Kubernetes 頑張ろうとしている⽅々に向けて Kubernetes の普及にチカラを注ぐ中での実体験をベースに Kubernetes 実践のリアルをお伝えします。

Kazufumi Saito (斎藤 和史) Who am I Red Hat K.K. OpenShift / Kubernetes Architect Kubernetes を国内に広げる 商⽤K8sで実戦/本番投⼊を加速 K8s Lover を増やす @capsmalt 8

Cloud Native Meetup Tokyo Cloud Native Developer JP OSSコミュニティのかかわり Japan Rook 9 - Japan Container Days (JKD v18.04, v18.12) - CNDF / CNDT / CNDK 2019 - CNDT 2020 <== Now on air !! Speaker Staff Sponsor Community As

アジェンダ 1 2 K8s 実践のリアル in 2020 K8s クラスター維持管理の対応策 10

11 K8s 実践のリアル in 2020

12 オモテ ウラ K8s めちゃ良い︕便利︕カッコいい︕︕︕ デファクトでしょ︕ え︖無理。 やれるもんならやってみ︖

13 良さげ︕ 使い始める 良い︕ スキ︕ これに賭ける︕ えっ・・・ 無理。。。 GAP︖

INSTALL HARDEN DEPLOY OPERATE ● Templating ● Validation ● OS Setup ● Identity & Security Access ● App Monitoring & Alerts ● Storage & Persistence ● Egress, Ingress & Integration ● Host Container Images ● Build/Deploy Methodology ● Platform Monitoring & Alerts ● Metering & Chargeback ● Platform Security Hardening ● Image Hardening ● Security Certifications ● Network Policy ● Disaster Recovery ● Resource Segmentation ● OS Upgrade & Patch ● Platform Upgrade & Patch ● Image Upgrade & Patch ● App Upgrade & Patch ● Security Patches ● Continuous Security Scanning ● Multi-environment Rollout ● Enterprise Container Registry ● Cluster & App Elasticity ● Monitor, Alert, Remediate ● Log Aggregation 業務ユーザーが，構築，運⽤の複雑さの為に 導⼊が難しいと考えている Source: The New Stack, The State of the Kubernetes Ecosystem, August 2017 75% Kubernetes を 正しく運⽤するのは 難しい 14

Kubernetes の保守は難しい Kubernetesは偉⼤な基礎技術ですが，ストレージ，ネットワーキング，セキ ュリティ，アプリケーションフレームワークなどを統合し，それを四半期ご とに更新し続けることは⼤きな負担です - Ashesh Badani, Red Hat https://www.techrepublic.com/article/why-running-your-own-kubernetes-deployment-could-be-a-terrible-idea/ 15

16 Kubernetes は 基本的には “４半期ごとにバージョンアップ” します。 なお，“サポートされるのは直近３バージョン” です。 kubernetes.io Kubernetes Support Policy

17 ⼀度システム作ったら ５年は変更しません。 つまりバージョンアップは ５年毎です。 うちは １０年 塩漬けでっせ。 In Japan… Kubernetes は 基本的には “４半期ごとにバージョンアップ” します。 なお，“サポートされるのは直近３バージョン” です。 kubernetes.io Kubernetes Support Policy

Kubernetes サポート期間の延⻑ 18 2020年どうなったか︖ ※対象: v1.19以降 https://kubernetes.io/blog/2020/08/31/kubernetes-1-19-feature-one-year-support/

Kubernetes サポート期間の延⻑ 19 2020年どうなったか︖ ※対象: v1.19以降 https://kubernetes.io/blog/2020/08/31/kubernetes-1-19-feature-one-year-support/ サポート期間が “９ヶ⽉から１年に延⻑” ありがたや︕︕ でも・・。１年じゃ短すぎるよ・・・。 うちは１０ねｎ（ｒｙ

20 それでも僕らは Kubernetes を使うんだ︕︕(2020) これぞカオス なんて無謀な。。

21 ・各種マネージドサービス ・各種 K8s 製品 ・各種プロフェッショナルサービス 救済の⼿⽴てはある ※製品の⻑期サポートや，技術的な⽀援やトラブルシュートの⽀援など

22 ・各種マネージドサービス ・各種 K8s 製品 ・各種プロフェッショナルサービス 救済の⼿⽴てはある ※製品の⻑期サポートや，技術的な⽀援やトラブルシュートの⽀援など もちろん必要に応じて 使って頂くのが良い 外部からメスを ⼊れていく

23 いまいちど⾒直して欲しいコト

24 CNCF TRAIL MAP

25 なぜ CI / CD が TRAIL MAP の２番⽬なのか • アプリケーションの更新 • ビルド，テスト，デプロイ • クラスターのバージョンアップ，流れ の早いテクノロジーへの追随 • アプリケーションのCI • インフラのCI • 各環境への安全・確実なデプロイ

26 Git Repo Build App(WAR) Code Analysis Unit Test Archive App Build Image Deploy Dev Integration Test Promote Staging Deploy Staging Dev Project Staging Project Container Registry push image git push シンプルな例 コード開発 〜 K8sクラスターへのデプロイ (Pipeline)

27 コード開発 〜 K8sクラスターへのデプロイ (Pipeline) 実態はいかに︖ Git Repo Build App(WAR) Code Analysis Unit Test Archive App Build Image Deploy Dev Integration Test Promote Staging Deploy Staging Dev Project Staging Project Container Registry push image git push シンプルな例 ・バージョン管理がされていない ・仕組みが整っていない （開発者PCのファイルシステム依存）

28 Git Repo Build App(WAR) Code Analysis Unit Test Archive App Build Image Deploy Dev Integration Test Promote Staging Deploy Staging Dev Project Staging Project Container Registry push image git push シンプルな例 ・ビルドに必要なクラスファイル/ライブラリが管理されていない ・ビルド端末/⼿順に属⼈性がある（AさんのPCじゃないと無理） ・不要なライブラリが多数含まれている コード開発 〜 K8sクラスターへのデプロイ (Pipeline) 実態はいかに︖

29 Git Repo Build App(WAR) Code Analysis Unit Test Archive App Build Image Deploy Dev Integration Test Promote Staging Deploy Staging Dev Project Staging Project Container Registry push image git push シンプルな例 ・テストコードが存在しない（テストは⽬検ベース） ・テストの単位が⼤きすぎる/⼩さすぎる ・テストコードが管理されていない コード開発 〜 K8sクラスターへのデプロイ (Pipeline) 実態はいかに︖

K8s に苦労している原因の代表例 30 • 継続的な開発スタイル，テストの流れが整備されていない ==> 実は K8s 云々以前 の課題が根本原因 ==> このケースが圧倒的に多い

なぜ K8s のバージョンアップに追随できないか︖ 31 • Kubernetes の難しさ • 技術カバレッジの広さ • リリースサイクルの短さ • 蓄積された負債 • 技術的 • 組織的

なぜ K8s のバージョンアップに追随できないか︖ 32 • Kubernetes の難しさ • 技術カバレッジの広さ • リリースサイクルの短さ • 蓄積された負債 • 技術的 • 組織的 “幅広く”，”短いサイクル” でテストが必要 （K8s の機能のdeprecated対応，他）

なぜ K8s のバージョンアップに追随できないか︖ 33 • Kubernetes の難しさ • 技術カバレッジの広さ • リリースサイクルの短さ • 蓄積された負債 • 技術的 • 組織的 プロプライエタリ 新規開発者の関わりにくさ 個別のセキュリティパッチ対応 属⼈性，ドキュメント不⾜ 陳腐化しやすいコード “幅広く”，”短いサイクル” でテストが必要 （K8s の機能のdeprecated対応，他）

なぜ K8s のバージョンアップに追随できないか︖ 34 • Kubernetes の難しさ • 技術カバレッジの広さ • リリースサイクルの短さ • 蓄積された負債 • 技術的 • 組織的 プロプライエタリ 新規開発者の関わりにくさ 個別のセキュリティパッチ対応 属⼈性，ドキュメント不⾜ 陳腐化しやすいコード “幅広く”，”短いサイクル” でテストが必要 （K8s の機能のdeprecated対応，他） ・影響調査に膨⼤な時間がかかる ・テスト負荷が⽇々増していく ・属⼈性が⽇々増していく ・CI/CD頑張っても，スピード感，安定性が出せない 関連するテクノロジーのアップデートに追随できない

コード開発 〜 K8sクラスターへのデプロイ (Pipeline) 実態はいかに︖ 35 Git Repo Build App(WAR) Code Analysis Unit Test Archive App Build Image Deploy Dev Integration Test Promote Staging Deploy Staging Dev Project Staging Project Container Registry push image git push シンプルな例 ・いつでも同じ，かつ正常なK8sクラスターを構築できる状態が整っていない ・K8sのConfigの管理ができていない ・K8sのライフサイクル管理ができていない ・K8s⽤のノード群のライフサイクル管理ができていない ・K8s⽤のストレージ群のライフサイクル管理ができていない

36 もしいまからサービス作るなら， 誰もがCI/CDなど当たり前に組み込んだものを作るでしょう。 ・テスト⾄上主義 ・疎結合 ・ALL Declarative なシステム（K8sと相性抜群）

37 ・数⼗から数百のサービス ・巨⼤かつ複雑なシステム間連携 ・プロプライエタリな作り込み ・⻑年の継ぎ接ぎアップデート，etc. しかし，現実は・・・。 クラウドネイティブ化するタスクがあったらやれますか︖ （※クラウドネイティブがマッチしているか否かの議論もある） やりますか︖

38 Kubernetes を始めとする クラウドネイティブ技術 ポジティブな企業・ヒトがいる︕︕ DevOps の効果を⾼めやすい これを機に， チーム・組織での CI / CD や DevOps実現 に踏み出す⼈達がいる

39 https://speakerdeck.com/superbrothers/cloud-native-devops-with-kubernetes-devops-cloudnative-and-gitops Kubernetes で実践する クラウドネイティブ DevOps 参考）

Kubernetes とうまくつきあっている先駆者の傾向 40 • アップストリームに追従している • アップストリームにコントリビュートしている • コード開発 • 社内啓蒙 • コミュニティ参画

Kubernetes とうまくつきあっている先駆者の傾向 41 • アップストリームに追従している • アップストリームにコントリビュートしている • コード開発 • 社内啓蒙 • コミュニティ参画 • そのために必要なスタックを整えている • 技術選定のスキーム • テストコードの徹底，テストの継続的実施 • 社内展開を推進する⽂化・評価 • 積極的なエンジニア育成，採⽤

Let’s Try – コミュニティの参画・形成 42 1) 社外コミュニティへの参画 • たくさんいるスーパーなエンジニアとつながる • 情報収集，共有して貢献。本当に活⽤できるものを知る 2) 社内コミュニティの作成 • ⼀緒にやれる仲間をつくる • 組織として取組むべき対象，独⾃開発の範囲を検討する 創る︓ ⾃作ソフトウェアとして開発し，メンテする 活⽤する︓ 便利な仕組み（公開されているOperator）を使う 創る or 活⽤ の⾒極め

Let’s Try – アップストリームと共存 43 • “根幹となるテクノロジー” はアップストリームに追従 • 機能追加はアップストリームに対してPR投げる • コミュニティの主要メンバーになる • 得られるメリット • 影響範囲のあたりがつきやすく，テストしやすい • OSSの品質向上の貢献を受けられる，貢献できる • 取り組まない場合のデメリット • 独⾃開発だと未来永劫メンテがつきまとう • アップストリームのバージョンアップ毎に対応が必要 （負荷が増していく）

44 Enjoy Opensource Era !!!

45 K8s クラスター維持管理の対応策

46 https://speakerdeck.com/masayaaoyama/kubefest2020-lt-k8s-native-testbed?slide=12 Operator フル活⽤な Kubernetes-native テストベッド

Operator 47

48 What’s Operator An Operator is a method of packaging, deploying and managing a Kubernetes application Kubernetes Applications 運⽤の知⾒をコード化し，ステートフルアプリケーションの運⽤を⾃動化する アプリ運⽤における運⽤の知⾒をコード化し， パッケージ化したもの。 アプリケーション運⽤に必要な以下のような 作業を⾃動的に⾏う。 ・インストール ・リソーススケーリング ・バックアップ ・アップデート 運⽤の知⾒をコード化 Operator - Installation - Backup - Monitoring

49 Reconciliation Loop Custom Resource Definition & Custom Controller Custom Controller Custom Resource Definition Deploy CRD Watch StatefulSet ConfigMap Pod Pod Service Actions (Operational Knowledge) Custom Controller Custom Resource Definition Operator = + (Resources) Kubernetes Operator

50 これ，クラスターの維持管理に活かせないか︖ ! (Operator)

51 Kubernetesクラスターの維持管理 o クラスター作成，削除，変更 o バージョンアップ o ノードの拡張・縮退 o ホストOSアップデート o 証明書管理 o 認証認可ユーザー管理 o 障害時のノード復旧 o … o … o etc. 1.16 1.17 1.18

52 V1.16 V1.17 V1.18 V1.19 V1.16 V1.19 クラスタA （既存） クラスタB （新規） アプリケーション，yaml群を 新クラスターに適⽤ $ kubectl apply -f xxx.yaml $ kubectl apply -f yyy.yaml $ kubectl apply -f zzz.yaml 単⼀クラスタ ※Velero (Heptio Ark)やResticで，PVやK8sリソースの抽出・バックアップ クラスターアップデート（マイグレーション）

53 V1.16 V1.17 V1.18 V1.19 V1.16 V1.19 クラスタA （既存） クラスタB （新規） アプリケーション，yaml群を 新クラスターに適⽤ $ kubectl apply -f xxx.yaml $ kubectl apply -f yyy.yaml $ kubectl apply -f zzz.yaml 単⼀クラスタ ※Velero (Heptio Ark)やResticで，PVやK8sリソースの抽出・バックアップ クラスターアップデート まずは， “Kubernetes + あなたが必要な標準環境” が正常に動作する必要がある

54 Kubernetesクラスターの維持管理 o クラスター作成，削除，変更 o バージョンアップ o ノードの拡張・縮退 o ホストOSアップデート o 証明書管理 o 認証認可ユーザー管理 o 障害時のノード復旧 o … o … o etc. 1.16 1.17 1.18 ・各コンポーネントの正常性をどう担保するか 今回考えるケース）クラスターのバージョンを上げるとき ※もちろんサービスの正常性維持の観点では， アプリケーションの正常性確認，永続データもあるが今回は対象としない

55 あなたの Kubernetes クラスターに必要なものは︖ サービス，プロジェクトごとに 必要なコンポーネント （各DB，各CI/CD，etc.） • kube-apiserver, kube-controller-manager, kube-scheduler, etc. • ネットワーク • ストレージ • DNS • etcd • ingress • 内部イメージレジストリ • ノードのチューニング • コンソール • クラスタモニタリング • VM（OS）の管理 • 独⾃のapiserver, controller manager, etc.

56 あなたの Kubernetes クラスターに必要なものは︖ サービス，プロジェクトごとに 必要なコンポーネント （各DB，各CI/CD，etc.） • kube-apiserver, kube-controller-manager, kube-scheduler, etc. • ネットワーク • ストレージ • DNS • etcd • ingress • 内部イメージレジストリ • ノードのチューニング • コンソール • クラスタモニタリング • VM（OS）の管理 • 独⾃のapiserver, controller manager, etc. xxx Operator (Custom Controller + CRD) ターゲットクラスターに対して ・各コンポーネントを展開 ・設定を変更 ・削除 ・アップデート

57 Operator もソフトウェア Operator v1.1.2 Operator v1.1.3 Operator v1.2.0 Operator v1.2.2 Time Version Custom Controller, CRD(CR) Operator アプリケーションと同様に アップデートやテストが必要 （放置していると負債になる）

58 Operator Lifecycle Manager CRD (Custom Resource Definition) Custom Controllers Custom Resource Instances Operator Catalog 1. Register 2. Monitor Registration 3. Install/Update 4. Manage Resource Instances Operator Lifecycle Manager(OLM)は，Kubernetes上のOperatorとそのリソースのライフサイクル全体を容易 にするツール。管理者はどのNamespaceでどのOperatorが利⽤できるのか，また，どのOperatorが実⾏可能な Operatorと対話できるのかを制御可能。Operator Framework (OSS) に含まれる。

Automated Dependency Resolution My Operator v1.1.2 requires requires Jaeger Operator jaeger .jaegertracing.io/v1 CockroachDB Operator cockroachdb.charts.helm.k8s.io/v1alpha1 resolves to resolves to Operator Framework 依存性グラフ installed by installed by Operator Lifecycle Manager 59

https://github.com/operator-framework Build Run Operate Operator Framework 60

創る 活⽤する。 or Operator 61 そして，管理する https://speakerdeck.com/capsmalt/operator-101 https://speakerdeck.com/shkitayama/operatorlifecyclemanager-101

創る 活⽤する or Kubernetes Platform 動向を知った上で， リーズナブルな選択を。 62

まとめ 63

64 まとめ Kubernetes に苦労している主な理由は２つ ・K8s の難しさ ・技術，組織的な負債 ==> オープンな世界にどっぷりハマることをオススメ （技術，組織，コミュニティ，全部楽しいはず） Operator (Custom Controller + CRD)活⽤ ==> あなたに必要なコンポーネントを含んだクラスターの⾃律運⽤

65 OperatorによってK8s周辺をフルカバー 運⽤プロセスを含めたポータビリティの実現。コンテナ/Kubernetesシステムを，K8sの技術を活⽤した付加価値機能によって⾃律運⽤を⽀援。 AUTOMATED OPERATIONS CLUSTER SERVICES APPLICATION SERVICES DEVELOPER SERVICES Middleware, Service Mesh Functions, ISV Monitoring, Chargeback Registry, Logging Automated Builds, CI/CD, IDE Any Infrastructure どの環境でも，迅速か つ信頼性の⾼いOS どの環境でも，同様の ⼿順でアプリケーショ ンを稼働 どの環境でも，⾃動化 された運⽤プロセスを 実現 Virtual Private cloud Bare metal Public cloud Edge

OpenShift.Run Summer 2020 #openshiftjp ・⽇時: 2020年9⽉24⽇(⽊) 14:00-19:00 予定 ・会場: Zoom / Meet などリモート開催 ・主催: Japan OpenShift User Group ・参加者: Kubernetes, OpenShift, 他クラウドネイティブテクノロジー, などに関わるすべての⽅ ・OpenShift Meetupとは: KubernetesやOpenShift，CNCF Projectなどをはじめとするクラウドネイティブ テクノロジーの最新情報や活⽤ノウハウを共有し合うコミュニティです。 https://openshift.connpass.com/event/184350/ ※有事の際など状況によって変更になる場合がございます OpenShift Meetup 拡⼤版として開催します︕

67 Speaker Contents ⻘⼭真也 @amsy810 Kubernetesと連携するアプリケーション開発⼿法 川沼⼤輝 @Santea3173 エンプラに Kubernetes を導⼊してみて分かった5つのTips 須⽥⼀輝 @superbrothers Kubernetes で実践するクラウドネイティブ DevOps （オブザーバビリティ編） 惣道哲也 @tetsuyasd Kubernetes クラスタのログ分析と可視化で知っておくべき こと 〜Elastic Stackの特性と注意点〜 脇⽥祥穂 @sachiho0402 OpenShift cluster-monitoringで困ったこと学んだこと @hodagi コンテナレジストリサーバーにコンテナ以外を格納する @_inductor_ CRI-O shallow dive @tetsuyaIsogai Upgrade 4.4 to 4.5 with OTA その裏側 OpenShift.Run Summer 2020

Happy Kubernetes Life 68 @capsmalt