JAPAN CONTAINER DAYS V18.12 https://containerdays.jp/ での登壇資料です

1. Rancher2.0で実現する
Managed Kubernetes Service
LINE Corporation, Verda2 Yuki Nishiwaki

2. Our KaaS?

3. Rancherの採用に到るまで

4. 理想と現実 (2018年6月)
Web Application Engineer: ちょっと
Kubernetes Engineer: いっぱい
Etcd Engineer : ちょっと
OpenStack Engineer: 0.6 人
Web Application Engineer: 0.6 人
Frontend Engineer: 0.5人

5. Deployment? Configuration? HA? Monitoring?...
● Kubernetes/Etcdの仕組みの深い理解
● KubernetesにおけるHA設定
● Kubernetesのデプロイの自動化
● EtcdにおけるHA設定
● Etcdのデプロイの自動化
● 設定のチューニング
● 障害時の対処の仕方
● 監視すべき項目の整理
● バックアップすべきデータ /設定の整理
● 管理に必要な情報の整理
● 管理するためのソフトウェアの開発
● 新しいバージョンの機能検証
・
・
リリースまで何年かかるの？

6. OSS利用の検討
● OpenStack L3サービス利用の前提
● 強いVMイメージの制約
● 積極的なOpenStackサービスの利用
● 開発コミュニティが活発でない
● 社内実績なし
● VMが作れてSSHできればOK
● ゆるいイメージ制約
● OpenStackサービスに依存しない
● 今は活発にみえる
● 社内のプロダクション運用実績

7. OSS利用の検討
● OpenStack L3サービス利用の前提
● 強いVMイメージの制約
● 積極的なOpenStackサービスの利用
● 開発コミュニティが活発でない
● 社内実績なし
● VMが作れてSSHできればOK
● ゆるいイメージ制約
● OpenStackサービスに依存しない
● 今は活発にみえる
● 社内のプロダクション運用実績

8. ● OSSを利用する
● OSSはきちんと動くと思い込む
● 開発業務はない

9. OSSは利用するが、OSSは信用しすぎない
信用する？
OSS
Blackbox
Clusterはきっと冗
長構成だよ
Clusterはきっと
Rancherが面倒みて
るよ
Clusterはきっと簡
単にUpgradeでき
るよ

10. OSSは利用するが、OSSは信用しすぎない
信用しない？
OSS
Whitebox
どういう仕組みで
Clusterは作成され
るのか
Rancherはどこま
でClusterの面倒を
みるのか

11. Community Contribution from Our Team
● Pull Requests
○ Rancher (8件)
■ https://github.com/rancher/norman/pull/201
■ https://github.com/rancher/norman/pull/202
■ https://github.com/rancher/norman/pull/203
■ https://github.com/rancher/machine/pull/12
■ https://github.com/rancher/types/pull/525
■ https://github.com/rancher/rancher/pull/16044
■ https://github.com/rancher/rancher/pull/15991
■ https://github.com/rancher/rancher/pull/15909
○ Ingress-Nginx (1件)
■ https://github.com/kubernetes/ingress-nginx/pull/3270
● Issue
○ Rancher (8件)
● Presentation/Material
○ https://github.com/ukinau/rancher-analyse
○ Rancher 2.0 の実装とNormanの紹介
○ Rancher 2.0 の実装の概要
バグ修正、バグレポート等 解析資料の公開等

12. Rancherをどのように利用しているのか？
本題

13. Rancher 2.X
● 複数のKubernetesクラスタを作成、管理するためのソフトウェア
● Kubernetes Operator Patternを用いてCluster/Nodeの管理を実現
○ 全てのリソースがKubernetesのリソースとして表現される
API Controller
ClusterA
Watch
Reconcile
Get latest
information from
kube-apiserver
Check if any difference
Between desired and
actual states
Do something to make actual state desired
Reconcile
Loop
Kubernetes Cluster
Cluster Agent
Node AgentCreate

14. Rancher +αでManaged Kubernetes Serviceを実現
API Server
● Private Cloudとの連携
● Rancherの機能を制限
● 複数Rancherサーバに対応
User Kubernetes Cluster
● Rancherによってデプロイされる
● OpenStackのVMにデプロイされる
● Worker数以外のClusterの構成を固定

15. Rancher +αでManaged Kubernetes Serviceを実現
Rancher
● ここの深堀りが今日のメイントピック

16. 僕らが、Rancherでできるに期待していること
● Cluster/Nodeの作成、削除
● Clusterがきちんと作成できたのかの検証
● Clusterの継続的な監視、状態の反映
● 特定の故障パターンの自動復旧
● Clusterの安全なアップグレード
● Cluster上で動かすAdd-onの管理
・
・
・
Kubernetesを簡単に利用できるようにする
ある程度決められた条件で、
Kubernetesを簡単に運用できるようにする

17. 僕らが、Rancherでできるに期待していること
● Cluster/Nodeの作成、削除
● Clusterがきちんと作成できたのかの検証
● Clusterの継続的な監視、状態の反映
● 特定の故障パターンの自動復旧
● Clusterの安全なアップグレード
● Cluster上で動かすAdd-onの管理
・
・
・
ある程度決められた条件で、
Kubernetesを簡単に運用できるようにする
Kubernetesを簡単に利用できるようにする
自信を持っておすすめできる機能
実装済みだが、追加でさらに検証が必要そうな機能
実装されていな機能

18. カスタマイズを前提にRancherの利用を決断
● 全てがすでに実装されていることは最初から想定していない
● 必要最低限の機能実装と今後の方向性があっているのであれば良い
● 足りない部分、バグの修正など、自分たちも実装に参加
公式Dockerイメージは、使わず
自分たちでPatchを当てたイメージを作成し、運用している

19. Rancher Image Pipeline
rancher/rancher
LINE/rancher
base commit id
patches
Create Patch
patch
patch
Pull Requests
Run Job
Check out base commit
● Apply patch
● Run Test
● Build image
● Push to registry
Github Enterprise
Github
Jenkins
Docker Registry
● Update manifest
● Run Integration Test
Pull new image
old new

20. どのようなパッチを当てているのか
● Rancherの内部ステートをモニタリングするための機能追加
○ 全ての変更はまだ、提案できていない
○ 一部UpstreamでMergeされている (https://github.com/rancher/norman/pull/202)
● 複数のバグ修正
○ Upstreamに提案済みのもの
○ すでにマージされているが、利用バージョンではまだマージされていないもの

21. /metrics エンドポイントの追加
Upstream Rancher
LINEで運用している Rancher

22. 内部ステート監視のモチベーション
● Rancherサーバの障害の影響範囲は小さくない
○ Cluster、Nodeの作成ができなくなる
○ Cluster、Nodeの正常性の管理ができなくなる
○ Clusterに対してKubernetes APIが叩けなくなる
● 障害についてきちんと内部で何が起きているか把握したい
○ スケールが原因の障害には予兆があることが多い
○ ログのみから内部の情報を把握するのは難しい
○ 内部情報は、バグ修正の役に立つことが多い

23. Rancher API部分の重要な内部ステート
Kubernetes API Latency (from client-go)
● Rancherが扱うデータは全て、 Kubernetesのリソースとして保存される
● Rancher APIは、Kubernetes API Proxyのように振舞っており、全ての Rancher APIリクエストの裏側では、
複数のKubernets APIが呼び出されている
● 遅延の多い APIリクエストを特定、改善に役立つ
WebSocket Session Informations for Agents
● 全てのRancher Agentは、Rancher Serverに対してWebSocket Sessionを確立すると期待されている
● Rancher Serverがデプロイ済みのClusterの管理のために、Clusterや特定のNodeのDockerにAPIリクエスト
を実施したいとき、WebSocket Session越しで提供されるTCP Proxyを利用する
● Rancherからデプロイされたクラスタに対する APIリクエストも実は、上記の TCP Proxy機能を使って実現さ
れている
=> WebSocket Sessionが不安定だと、クラスタ管理、クラスタの利用に多大な支障がでる

24. Rancher Controller部分の重要な内部ステート
Handler Total Execution/Total Failure
● Rancherでは、ほとんどのビジネスロジックが Norman Frameworkを用いて実装されている
● Norman Frameworkは、Custom ControllerのFrameworkで、Kubernetes Clientと複数の
Function(Handlerと呼ばれる) を１つのCustom Controllerに登録できる
● 登録されたKubernetes Clientがリソース変化を検知すると、登録された全ての Handlerが実行され、１つで
もHandlerの実行に失敗すると、時間を置いてからリトライされる
● どのHandlerがどれくらいの頻度で呼ばれているのか、失敗しているのか把握することでバグの発見やトラ
ブルシューティングに非常に有効
Each Controller’s Queue Metrics (from client-go)
● Norman Frameworkは、client-goのラッパーなので、client-goより提供されるQueue滞在時間や１つのkey
処理時間などの把握も有効

25. どんな感じ？
Websocket Sessionが確立できていないノード、クラ
スタが表示される。
=> 長期的に接続が切れているものが検出可能
直近5分間で接続と切断が行われた
クラスタ、ノードが表示される。
=> 頻繁に接続が切れているものが検出可能

26. どんな感じ？
2分間の間で実行された Handlerの回数が表示される。
どのような処理がRancherの中でよく実施されているかが
分かる
2分間の間で実行された Handlerで失敗したものとその時評価し
ていたリソースのkeyが表示される。
=> 失敗したHandlerとKeyが分かるので、ログと合わせてトラブ
ルシューティングの効率が上がる

27. Rancherを採用してみて
実際どうだったか

28. よかったこと
● リードタイムをかなり短縮できた
○ 2018年6月に２人でプロジェクトを開始し、 11月にβ版として社内提供まで
● 少数クラスタ管理を前提にすれば、今のままでも十分活用できると思う
○ KaaSのバックエンド以外にも、弊社でプロダクションで運用されている事例はいくつかある
● 数少ないOperator Patternを使ったManaged KubernetesのOSS実装
● Kubernetesの使い方、デプロイのされ方など、立ち上がりには十分なほどの知見が
Rancherを解析した結果得ることができた

29. 少し苦労した（している）こと
● ドキュメントがとにかく少ない = コードを読むしかない
○ 社内でのナレッジ共有コストがとにかく高い（属人化のリスク）
● 大丈夫と思ったオペレーションに危険が潜んでいる
○ イメージアップデートをすると、 1-5分の間クラスタに対する APIが叩けなくなる(デザイン)
● 様々な機能が実装されているため、障害が起きた時の原因の特定が難しい
○ この点は、モニタリングカスタマイズでかなり改善された
● クラスタステートの扱いがあまり重要視されていない
○ https://github.com/rancher/rancher/issues/15907
● クラスタ数増加に伴って判明した、タイミング起因のバグ
○ 750ノード作成した際に、一部 Pod間通信ができなくなる
(https://github.com/rancher/rancher/issues/13644)
○ 特定の条件でNodeの作成に失敗した際に、リトライされない
(https://github.com/rancher/rancher/issues/14933)

30. 少し苦労した（している）こと
● ドキュメントがとにかく少ない = コードを読むしかない
○ 社内でのナレッジ共有コストがとにかく高い（属人化のリスク）
● 大丈夫と思ったオペレーションに危険が潜んでいる
○ イメージアップデートをすると、 1-5分の間クラスタに対する APIが叩けなくなる(デザイン)
● 様々な機能が実装されているため、障害が起きた時の原因の特定が難しい
○ この点は、モニタリングカスタマイズでかなり改善された
● クラスタステートの扱いがあまり重要視されていない
○ https://github.com/rancher/rancher/issues/15907
● クラスタ数増加に伴って判明した、タイミング起因のバグ
○ 750ノード作成した際に、一部 Pod間通信ができなくなる
(https://github.com/rancher/rancher/issues/13644)
○ 特定の条件でNodeの作成に失敗した際に、リトライされない
(https://github.com/rancher/rancher/issues/14933)
とはいうものの、
KaaSのベースソフトウェアとして
十分な価値が発揮できていると思っている

31. これから期待していること
● ~100, ~1000クラスタの管理を見据えたさらなるオペレーションの自動化
○ クラスタ向けテストとテスト情報の管理
○ クラスタ向けの監視、監視情報の Cluster Stateへの反映
○ 特定の故障からのセルフヒーリング
○ 自動バックアップと1 API Callリカバリ
=> クラスタを直接意識して、何かを設定、オペレーションする機会をもっと減らしたい
● スケーラビリティに関する改善
○ Rancher 2.1 でようやく2つ以上のRancher Serverのデプロイが可能になった
○ Rancher 2.X でRancher Serverのメモリ使用量の大幅な改善
=> この調子で1つRancherクラスタでなるべく多くの k8sを管理したい

32. ライセンス
Jenkins ならびに Jenkins CIは、Jenkins (http://jenkins-ci.org/)に帰属します。また、 Creative
Commons Attribution 3.0 Unported licenseに従い、利用しています。