オンプレミスK8s基盤をまるごと VMで仮想化した検証環境とその活用

2023/02/27に行われた"CI/CD Conference 2023 前夜祭"での発表資料です

Transcript

1. オンプレミスK8s基盤をまるごと VMで仮想化した検証環境とその活⽤ 2023/02/27 サイボウズ株式会社 ⼭下 壮樹 1
2. アジェンダ - ⾃⼰紹介 - Necoの概要 - dctest(仮想データセンタ環境)の概要 - dctestの活⽤ - まとめ 2
3. 3 Necoで実践している，オンプレK8s基盤の テスト環境についてお伝えします！
4. ⾃⼰紹介 - ⼭下 壮樹 (Soju Yamashita) - 22卒⼊社 - チームでは主にモニタリング関連とCI/CDのコンポーネントを担当 - VictoriaMetricsとかLokiとか - Self hosted runner のコントローラとか 4
5. Necoの概要 5
6. Necoについて - サイボウズではkintoneやGaroon, サイボウズOfficeなどのサービスを提供 - K8sやCephを使った新しい基盤でインフラ基盤を刷新するプロジェクト - 現⾏基盤はVMベースのアーキテクチャ - 本番運⽤も開始 - ⼀部のサービスはNeco基盤で稼働中 - Necoチームでは引き続きNeco基盤を開発/運⽤している - 成果の多くをOSSとして公開 6
7. Necoのインフラについて - インフラ基盤を⼀から設計 - ⾃社データセンタでK8s基盤を構築 - サーバ管理システム， K8sエンジン，CNIを⾃作 - K8sクラスタと各種ミドルウェアを管理し，PaaS相当の機能をテナントに提供 - 1つのクラスタに複数のテナントが同居している構成 - 本番クラスタではデータを複数リージョンにレプリケーション 7
8. Necoのインフラ構成 ⼈間 GitHub CKE sabakan 管理サーバ (Ubuntu) Argo CD Neco CD Kubernetes Contour Grafana Loki Victoria Metrics Teleport MOCO Node (Flatcar) Coil Cilium Node (Flatcar) Coil Cilium Node (Flatcar) Coil Cilium 構築/管理 8 Push
9. Necoのインフラについて - necoリポジトリで管理 - K8s基盤を構築するところまで - sabakan(サーバ管理システム), CKE(Cybozu K8s Engine)などを管理 - Neco CDのGitOpsでデプロイされる - neco-appsリポジトリで管理 - K8s上に載せるアプリケーションを管理 - Kustomize, Jsonnetを使ってマニフェストを管理 - Argo CDのGitOpsでデプロイされる 9
10. Necoのインフラ構成(再掲) neco neco 10 neco-apps ⼈間 GitHub CKE sabakan 管理サーバ (Ubuntu) Kubernetes Contour Grafana Loki Victoria Metrics Teleport MOCO Node (Flatcar) Coil Cilium Node (Flatcar) Coil Cilium Node (Flatcar) Coil Cilium
11. dctestの概要 11
12. Test Everything - Necoでは“データセンタの機能すべてをテストすること”を設計⽅針としている - テストしていないものは動かさない - 各コンポーネントについてもe2eテストを実施 - カスタムコントローラをkindで試験するなど - インフラ構成についても統合的にテストしたい - サーバ管理システムからK8s上のアプリケーション まで全てひっくるめたテスト 12 各コンポーネントの e2eテスト 機能単位のテスト ☜この部分 インフラ構成のテスト
13. インフラ構成のテスト - Necoのシステムを含めたインフラ構成をテストしたい - Necoのシステム: サーバ管理システム，K8sエンジン，⾃作CNI等 - 全ての要素が協調的に動作しているかを確認する，統合的なテストをしたい - パブリッククラウドのマネージドサービスではNecoのシステムを試験できない - sabakan，CKE等の試験が必要 - 検証⽤のアドホックなクラスタを気軽に⽴てられない 仮想マシンでデータセンタを再現した環境を 作って，そこでインフラ構成の試験をしよう 13
14. dctestの概要 - dctestではVMを使ってデータセンタ構成を丸ごと仮想化 - サーバをVMを使って表現 - ルータ，スイッチはnetwork namespaceを使って表現 - ネットワークスイッチの各機能を複数のソフトウェアを組み合わせて実現 - いくつかのテスト観点に基づいて試験を実施 - 0から基盤を構築できるか，前のバージョンからアップグレードできるか，など - dctest上でneco, neco-appsを構築するテストシナリオを⽤意 14
15. ToR Switch ToR Switch Boot Server Compute Server Compute Server ToR Switch ToR Switch Boot Server Compute Server Compute Server ToR Switch ToR Switch Boot Server Compute Server Compute Server Core Switch Spine Switch Spine Switch Operation External dctest環境の構成 - 本番DCを模擬した構成 - 5ラック構成 - サーバ15台 - CLOSトポロジ - neco,neco-appsが動作 - 必要なリソース - CPU30コア - メモリ100Gi namespace VM 15
16. dctest環境を⽀える技術 - Placemat - YAMLファイルの設定をもとにVMを使って仮想データセンタ環境を構築できる - NodeリソースによってVMへの多彩な設定が可能 - プロビジョニングの⾃動化等 - pmctlコマンドによってVMへのアクセス等もサポート 16 kind: Node name: worker-1 interfaces: - net0 volumes: - kind: raw name: data size: 10G cpu: 1 memory: 2G smbios: serial: 1234abcd uefi: false Node Node Node Node IP:172.16.0.1 IP:172.16.0.11 IP:172.16.0.101 IP:172.16.0.102 net0 IP:172.16.0.0/24
17. dctest環境のテストシナリオ(1) - dctest環境で実⾏する幾つかのテストシナリオを⽤意 - Bootstrap試験: 0からのBootstrapを試験 - Upgrade試験: リリースブランチからフィーチャーブランチへのUpgradeを試験 - Reboot試験: ノードの再起動を試験 - Placematで仮想データセンタを構築して，Bootstrapシナリオを実⾏するだけ でneco, neco-appsをデプロイしたdctest環境が完成する - 所要時間は1時間くらい - できた環境が正しく動作しているかどうかのチェックもされる 17
18. dctest環境のテストシナリオ(2) 18 - Bootstrap試験 - 管理サーバのセットアップ • BIOSやネットワークの設定，システムソフトウェア, etcd, Vaultなどのセットアップ - K8sノードのセットアップ • Compute Serverのネットブート，CKEによるK8sクラスタ構築，CNI等のセットアップ - K8s上で実⾏するアプリケーションのデプロイ - Upgrade試験 - Neco CD, Argo CDでリリースブランチから更新し，正しく動作するかを確認する - Reboot試験 - すべてのノードを再起動し，正しく完了するかを確認する
19. 詳しくはWEBで - データセンター仮想化ツール Placemat v2の紹介 - Test Everything: データセンター仮想化と⾃動テストの取り組み - Necoのネットワーク - アーキテクチャと設計編 - アーキテクチャ刷新プロジェクト「Neco」の紹介 - https://github.com/cybozu-neco 19
20. dctestの利⽤ 20
21. dctestのユースケース 21 - CIで利⽤する - 継続的にテストすることでシステムの整合性を担保 - dctestによるテストが成功しない変更は原則取り込まれない - リポジトリのワークフローにdctestを実⾏する⼿順を記述することで実現 - 検証⽤にアドホックなdctestを利⽤する - 障害が起こった際の再現などや，更新作業に利⽤ - Placematを起動し，dctest環境を構築すれば良い
22. dctest on K8s - ステージング環境でdctestを動かすためにカスタムコントローラを開発 - 元々はGCEで動かしていたが，Nested VMのため不安定だった - Meows - dctestを使ったCIを実現するために開発 - K8s上でGitHub Actions self-hosted runnerを動作させる - Nyamber - dctestを使った検証を実現するために開発 - K8s上でdctest環境を構築する 22
23. dctest on K8s 23 GitHub 開発者 Meows Nyamber Kubernetes Runner Pod Placemat VM VM VM Kubernetes ステージング環境 利⽤者 Workflow kick Runner登録 仮想データセンタ上で テストを実⾏ 仮想データセンタに ログインして利⽤ 作成 Dctest Pod Placemat VM VM VM Kubernetes
24. dctest on K8s 24 GitHub 開発者 Meows Nyamber Kubernetes Runner Pod Placemat VM VM VM Kubernetes ステージング環境 利⽤者 Workflow kick Runner登録 仮想データセンタに ログインして利⽤ 作成 Dctest Pod Placemat VM VM VM Kubernetes 仮想データセンタ上で テストを実⾏
25. dctest on K8s 25 GitHub 開発者 Meows Nyamber Kubernetes Runner Pod Placemat VM VM VM Kubernetes ステージング環境 利⽤者 Workflow kick Runner登録 仮想データセンタ上で テストを実⾏ 仮想データセンタに ログインして利⽤ 作成 Dctest Pod Placemat VM VM VM Kubernetes
26. Meowsの概要 - K8s上でGitHub Actions self-hosted runnerを動作させる - RunnerPoolリソースを作ることでself hosted runnerを利⽤できる - 実⾏終了時にSlackで結果を通知 - 失敗時は環境の削除を延期する - 何が原因で失敗したかdctest環境に ログインして確認できる - Slackから延命することも可能 ⼈間 RunnerPool リソース GitHub Meows Slack通知 Workflow kick ランナー登録 Workflow Run ⽣成 作成 Runner Pod K8sクラスタ 26
27. Nyamberの概要 - K8sクラスタ上にdctestを起動するためのカスタムコントローラ - 専⽤のカスタムリソースを作成することでdctestが⽴ち上がる ⼈間 VirtualDC リソース dctest (Pod) Nyamber read create create access 27
28. dctestの使いどころ - 障害発⽣時に起きた障害をdctestで再現 - 新しいミドルウェアを⼊れた際に正しくデプロイされるかの確認 - 管理ソフトウェアに実装した機能がクラスタで正しく動作するかの確認 - 設定変更チェック - K8s, Ubuntu, ワーカノードのOSアップグレード - 取り込みたい修正をCIで試験する 28
29. これまでにdctestで検証した項⽬ - ラック故障時にストレージの可⽤性を確認する検証 - 全台再起動によるPod Disruption Budget違反をチェックする検証 - ネットワーク関連の移⾏の検証 - 既存のCNIからCiliumへ置き換えるシナリオの検証 - LoadBalancer移⾏シナリオの検証 29
30. まとめ 30
31. まとめ - NecoではオンプレでK8s環境を構築しており，サーバ管理システムやK8s管理 システム，CNIなどを⾃作している - これらのシステムを統合的に試験するためにデータセンタの環境を丸ごと仮想 化したdctest環境を利⽤ - dctestは新機能追加や障害の再現，CIなど，さまざまなところで使われている - dctestをステージング環境で実⾏するためのカスタムコントローラを開発した 31
32. 今後の展望 - CIの実⾏時間を早くしたい - dctestの起動に1h近くかかってしまう - 特にArgo CDによるアプリケーションデプロイが遅い - Flaky Testを改善していきたい - 内部ネットワークのテストでタイムアウトするとか - 外部に依存しているテストは壊れがち 32
33. ご清聴ありがとうございました！ 33
34. Appendix 34
35. 新規アプリケーションをデプロイする場合 - neco-appsに新たなミドルウェアをデプロイする場合を想定 - ⼿順は以下の通り 1. neco-appsでブランチを切って，⼊れたいミドルウェアの設定をする 2. necoのブランチをリリースに，neco-appsのブランチを新たなブラ ンチに指定して，テストシナリオを流す 3. dctestが⽴ち上がるので，あとは中で動作確認する - あとはCIで試験するだけ - テストシナリオにそのミドルウェアで動作確認⽤のシナリオを追加する 新ブランチでミドルウェア追加 ブランチ指定してdctest起動 CI通るか確認 想定通りに動作するか確認 Ready for Review 35
36. クラスタで起きた障害を再現したい場合 - 本番/ステージングでなんらかの障害が発⽣した場合 - 暫定対応を終えたら，原因究明をしたい - リリースブランチでdctestを起動 - ⼿順を流して問題が再現するかを確認する - kindを使う場合よりも再現度の⾼い試験ができる - ネットワーク関連の問題は特に本番と同じ構成で試験したい 場合が多い 障害発⽣ dctest起動 再現⼿順を流して再現するか確認 原因究明 本番クラスタに適⽤ 36