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