Kubernetes と オープンソース

KubeFest Tokyo 2020のサイボウズのスポンサーセッションで発表した内容です。

Transcript

1. Kubernetes と オープンソース サイボウズ株式会社 井上 万実 1
2. About Me ▌井上 万実(@binoue4) ▌⼤⼿SIerから転職して、現在サイボウズ勤務 ▌次期クラウドサービスインフラ基盤のNecoプロジェクト所属 l オンプレミスのKubernetes環境を構築中 2
3. KubernetesとOSS ▌Kubernetes のエコシステムには多くのOSSがあり、活⽤できると便利 3
4. サイボウズのKubernetesで使っているOSS ▌(⾃社製も含め)たくさんのOSSを活⽤ (30以上) 4 … H/W インフラ ミドルウェア サーバ
5. 課題 ▌選定⽅法 ▌メンテナンス ▌機能追加・修正 ▌ライセンス ➡ サイボウズでの上記の課題の取り組みをご紹介します 5
6. OSSの選定⽅法 6
7. 考慮するべきポイント ▌利⽤者・利⽤実績 ▌メンテナンス体制 ▌ライセンス ▌改修容易性 7
8. Proof of Concept ▌実際⾃分たちの環境⽤途にフィットするか ▌必要な改修があるか ▌必要なら複数の候補を⽐較する ➡ なければOSSとして⾃作 8
9. OSSとして⾃作するメリット ▌成果物をOSSとして公開することはメリットがある l 品質管理や ドキュメントの充実 l 過度な⾃社環境への適応(モノリス)を避ける l 将来⾃社の技術⼒アピールや採⽤に役⽴てる 9
10. 具体例: TopoLVM ▌Kubernetes上で LVM を活⽤するストレージドライバ l 元々、需要があった l 徐々に社外ユーザが増加 l Bug報告・修正に伴うさらなる品質強化 l 外部からのパッチで機能強化も l 外部からのノウハウの蓄積 10
11. OSSのメンテナンス 11
12. OSSのメンテナンス ▌毎⽇OSSの状況をチェック l GitHubのrelease page などリリース情報が配信されるものをsubscribe l TwitterでSecurity関係のアカウントをフォローしておき、随時対応 ▌アップデート契機 l セキュリティ的に必要であれば、即時対応 l 3ヶ⽉に1回の定期更新でOSSを最新に保つ ▌改修を容易に l イメージの⾃前ビルド（パッチをすぐに利⽤できる様に） 12
13. メンテナンス⼿順 1. Release noteの確認 2. ⾃前でcontainerイメージをビルド・更新 3. manifestの更新 4. CIによる結合試験 5. 実機適⽤ 13
14. テストの重要性 ▌OSSアップデートの⼿順の中で最も重要なのは結合試験の⾃動化 l OSSでは動きが早く、 互換性の破壊やアップグレードでの障害が⼊りやすい l 多数のOSSを使⽤している場合は特に、⼿動での確認は現実的ではない l 実機上での障害対応は緊急性が⾼く、開発・運⽤メンバの負荷が⾼い ➡ 結合試験の⾃動化が充実していないと、OSSのメンテナンスは困難 14
15. テストシナリオ ▌結合試験の⾃動化をするにあたってはテストのシナリオが重要 ▌オンプレミスで運⽤する場合、下記の両⽅が必要になる。 l インフラ部分の試験 l KubernetesやKubernetes⾃体の運⽤ツールを対象 l アプリケーション部分の試験 l Kubernetes上のミドルウェア, アプリケーションを対象 15
16. インフラ部分の試験 ▌インフラ部分の試験は、⾃作ツールを使って、仮想データセンタを構築 ▌仮想データセンタ上で、下記試験を実施 l 標準試験 l 機能試験 l 再起動試験 l 障害試験 l (前のバージョンからの)アップグレード試験 ▌GitHubでmerge前にCIで上の試験を全て実⾏ ▌毎⽇で夜間にCI試験 16
17. アプリケーション部分の試験 ▌前のスライドのテスト済みのインフラの上で、アプリが動くかも確認 l 機能試験 l アップグレード試験 l Kubernetesのアップデート試験 ▌GitHubでmerge前にCIで機能試験・アップグレード試験を全て実⾏ l Kubernetesのアップデート試験はKubernetes更新時のみ ▌毎⽇で夜間にCI試験 17
18. テストポリシー ▌開発速度に影響するので、結合試験のテスト時間は抑えたい ▌テストピラミッドを作成し、 できるだけ下位のレイヤーでテストを実⾏している 18 複数台のホスト上で複数のコンポーネントを組み合わせて試験 1台のホスト上で1つのコンポーネントの機能を試験 データセンターを丸ごと仮想化し、本番と同じ構成で試験
19. テスト時間 ▌テストポリシーに従うことと、上位のレイヤでの試験を分割し並列実⾏することで⼤体 1時間ぐらいでCIが完了するようになっている ➡開発が進むにつれて、テスト時間が伸びる傾向にあるので、時々、テストの分割・内 容の⾒直し・テスト環境のチューニングを⾏っている 19
20. 検出した不具合の例 20 ▌検出した不具合の例 l etcdの先頭のメンバーがクラッシュしたときに、etcdに接続できなくなる問題 l サーバー再起動後にCNIプラグインのアップグレードをすると、アドレスプールが解放 されてしまう問題 l Argo CDのアップグレードによりアプリケーションの適⽤順序が変わり、デプロイに失 敗する問題 ➡ これにより多数のOSSのアップデートを安⼼して⾏える
21. OSSの機能追加・修正 21
22. OSSの機能追加・修正⽅針 ▌サイボウズでは開発体制の規模・開発⼒を考慮し、OSSの機能追加・修正⽅針は 下記のようにしている。 l 原則アップストリームへの修正をする l 独⾃版の運⽤は将来的にはコストが⾼くなるのでできるだけ避ける l コミュニティとの関係強化で上記を実現する 22
23. 原則アップストリームへの修正 ▌業務上問題になる様な場合は、アップストリームへの修正Issue/PRを⽴ててチーム のタスクとして管理する l アップストリームとのGitHub/Slack上での議論も積極的に⾏う ▌業務上問題にならないものでも、気づいたバグに関しては、積極的にIssue/PRを作 成し、アップストリームに貢献する l Necoチームの実績値 (⾃社リポジトリを除く) l 2019年 Issue: 22件, PR:38件 l 2020年 Issue: 38件, PR:57件 23
24. 独⾃版の運⽤コストが⾼い理由 ▌独⾃版なので、コミュニティサポートが受けられない ▌アップストリームの更新ごとに独⾃版の追従が発⽣する l アップストリームのバージョンアップに追従 l アップストリームのバージョンアップをバックポート 24
25. アップストリームのバージョンアップに追従 ▌アップストリームのバージョンアップに追従する場合、下記のようにバージョンアップを重 ねることで、独⾃パッチが肥⼤化し、コストが増加する 1. アップストリーム vNに対して独⾃パッチを作成 2. アップストリーム vN+1に対応して、vNとvN+1の差分に対応するように独⾃パッチを修正 3. アップストリーム vN+2に対応して、vN+1とvN+2の差分に対応するように独⾃パッチを修正 25 アップストリーム vN アップストリーム vN+1 アップストリーム vN+2 独⾃パッチ 独⾃パッチ 独⾃パッチ
26. アップストリームのバージョンアップをバックポート ▌アップストリームのバージョンアップをバックポートする場合も、下記のようにバージョン アップを重ねることで、独⾃パッチが肥⼤化する 1. アップストリーム vNに対して独⾃パッチを作成 2. アップストリーム vN+1に対して、vNとvN+1の差分に対応するように独⾃パッチを修正してバックポート 3. アップストリーム vN+2に対応して、vNとvN+2の差分に対応するように独⾃パッチを修正してバックポート 26 アップストリーム vN アップストリーム vN+1 アップストリーム vN+2 独⾃パッチ vN+1 独⾃パッチ アップストリーム vN 独⾃パッチ vN+1 独⾃パッチ vN+2
27. 独⾃版の⼀時運⽤ ▌アップストリームでの取り込みに時間がかかる場合は次善策として、独⾃版を⼀時運⽤ l Rookの例︓ l KubernetesのPodの分散配置機能であるTopologySpreadConstraintを使⽤したかった l アップストリームRookでは Kubernetes v1.18が出るまで対応しない⽅針 l PRを準備しつつ、 Kubernetes v1.17では独⾃パッチを使⽤ l Kubernetes v1.18リリース後に無事マージされ、独⾃パッチ不要に https://github.com/rook/rook/issues/4387 27
28. 独⾃版の継続運⽤ ▌どうしても取り⼊れてもらえない場合は、独⾃版運⽤ l OSSのVaultのバリデーションに問題があり、アップストリームにPR/Issueを投げる も対応されず l ⼩さな修正だったため、patchファイルを作成し毎回リリースごとに適⽤ https://github.com/hashicorp/vault/issues/5129 28
29. 重要なOSSに関して ▌お客様のデータを扱うストレージソフトウェア Rook&Ceph が特に重要 ▌ほぼ専任のOSS活動エンジニアがいる ▌事例:Rook l サイボウズの最新開発版への貢献数は世界⼆位 l 貢献が認められてサイボウズのメンバがレビューアに l レビューア: 変更が適切だと承認できる権利を持つ l メンテナ: 変更を取り込む権限を持つ 29
30. コミュニティとの関係強化 ▌Slackでの相談, Zoomミーティング参加, Issue/PRのコメントを通してコミュニティと の関係強化 l パッチをRVしてもらいやすくする l コミュニティを盛り上げることで、ユーザを増やしてOSSの品質を上げてもらう 30
31. サイボウズのOSS⽅針でうれしいこと ▌OSSで⾃前パッチがほとんどない l アップデートに伴う作業が軽減されている ▌サイボウズのコントリビューションによって、コミュニティ全体にプラスになるケースがある ▌対外発表をコントリビューション先と共同でできることがある ➡いくつかの具体例をご紹介します 31
32. コミュニティ全体にプラスになるケースの例 ▌Argo CD の windows binary提供 l Argo CDとは︓ l CNCF管理下のCIツール l Git repositoryを監視して、変更があった場合は、変更をデプロイ l リッチなWeb UI l 問題︓ l Argo CDをCLIから操作するbinaryがwindowsには提供されていない l サイボウズでは Windowsの Argo CD CLIが必要だったためPRを作成 l サイボウズがサポートすることで、 Windowsの Argo CD CLIがアップストリームから 提供される様になった。 https://github.com/argoproj/argo-cd/pull/3015 32
33. 対外発表をコントリビューション先と共同で⾏うことの例 ▌AWSの⽅と⼀緒に現在、KubeCon NA 2020にProposal提出中 ▌経緯︓ l RookというOSSではLVを扱えなかった l サイボウズではLVを使⽤してRookを使⽤したい l LV対応⽤のPR/Issue作成を⾏なっていた l 同じ様なことをやっている⼈から 共同セッションの勧誘 33
34. サイボウズのOSS⽅針でつらいこと ▌Issue/PR のために英語で対応する必要がある ▌PR⽤に再現⼿順の作成などをで、⼯数が嵩むことがある ▌Issue/PR対応の内容によっては、業務内で使⽤していないツールを使う必要があ る。 ➡いくつかの具体例をご紹介します 34
35. 再現⼿順の作成などを⾏うことで、⼯数が嵩む ▌kube-proxyによるipvs更新バグ l kube-proxyとは︓ l Kubernetesを構成するコンポーネントの⼀部 l ipvsモードの場合、nodeのipvsの操作も⾏う l 問題︓ l コンテナがUnhealthyになったとき、kube-proxyがipvsを変更し、Gracefulにルー ティングを停⽌ l Gracefulにルーティング停⽌中に kube-proxyが停⽌し、 コンテナがHealthyに復 帰した場合、 kube-proxyが起動後、コンテナにルーティングがされないままになる l 再現状況がかなり特殊なため、再現⼿順の作成に時間がかかった 35 https://github.com/kubernetes/kubernetes/issues/92019
36. 業務内で使⽤していないツールを使う ▌Rook の multi-cluster⽤ manifest⽣成 l Rookとは︓ l Storage ソフトウェアのCeph⽤のOperator l Ceph クラスターを複数⾃動管理してくれる l 問題︓ l Rookはmulti-cluster⽤のmanifestを⽤意しておらず、複数クラスタを運⽤する際には バージョンアップごとにmanifestの⼤幅な修正が必要 l アップストリームはmanifest管理ツールのHelmを使⽤して対応したい l サイボウズではHelmを使⽤していないが、multi-cluster⽤のmanifestを簡単に⽣成でき る様にHelmの仕様を把握しながらPR作成 36 https://github.com/rook/rook/pull/5573
37. OSSのライセンス 37
38. OSSのライセンス ▌OSS推進室 l OSSライセンスの審査を⼀元管理 l GitHub Orgの審査を担当 l OSSへの寄付対象も決定 l CNCFの silver member に加盟費⽤なども拠出 38
39. まとめ 39
40. まとめ ▌CybozuのKubernetesでは多くのOSSを活⽤しています ▌OSSを活⽤する上で、選定・活⽤⽅法を⼯夫してきました ▌既存のOSSで適切なものがない場合は、⾃作しOSSとして公開してい ます ▌OSSを活⽤する際に、参考になれば幸いです 40