Rancher2.0で実現する Managed Kubernetes Service
2 likes2,712 views
JAPAN CONTAINER DAYS V18.12 https://containerdays.jp/ での登壇資料です
Rancher2.0で実現する Managed Kubernetes Service
- 1. Rancher2.0で実現する Managed Kubernetes Service LINE Corporation, Verda2 Yuki Nishiwaki
- 2. Our KaaS?
- 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はきちんと動くと思い込む ● 開発業務はない
- 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 の実装の概要 バグ修正、バグレポート等 解析資料の公開等
- 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が分かるので、ログと合わせてトラブ ルシューティングの効率が上がる
- 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に従い、利用しています。