cha_pppo blog

i have an unbeknown dictionary. everything is up to me.

de:code2019 CD12 Kubernetes関連のまとめ

f:id:hrt0kmt:20190529090621j:plain

  • Session: CD12 / マネージド Kubernetes ガチ本番運用 in ZOZOTOWN
  • Date: 2019/05/29
  • Place: 港区芝公園ザ・プリンス パークタワー東京
  • Official URL

Presentation

  • Kubernetes運用の目的
    • システムの安定稼働を目指す
      • サービスの成長、突発的なアクセス負荷に耐えられるインフラ
    • コンテナ化、オートスケール、オートヒーリングによる運用負荷の低減
    • マイクロサービス、マルチクラウド化を視野に入れた設計
  • Kubernetesを運用にしてみて
    • 運用が楽になる反面、通常運用まで持っていくのに相当な知識が必要
    • Kubernetesのversion upサイクルが早く、常に追いついていく必要がある
  • Microsoft unified supportが手厚い
    • 問い合わせ制限無し
    • MSの技術者と問題解決に向き合える
    • オンプレの問題もMSに相談可能
  • コスト面
    • Azureのmaster nodeリソース分の料金が減る
    • 運用負荷も軽減
    • カスタマイズ幅が小さくなるが、必要性はあまり無いと感じる

f:id:hrt0kmt:20190529170220j:plain
Kubernetesの構成 (CD12)

AKSの特性

  • Azure Active Directory
    • 各種リソース操作権限はAzure ADにより管理、AKSの操作も同様
  • type: LoadBalancer (Azure Load Balancer)

Kubernetesでの障害例

  • HTTP status 400,500,502エラー発生も、原因追求が困難
    • どのレイヤーで発生している障害なのか?
      • HTTP connection, TCP/IP connection, DB connection
  • 突然podがapply出来なくなる事象
    • Service Principalの期限切れでクラウドリソースの操作不可となったことが原因
  • nodeやpodが落ちる場合がある
    • Azure VMのバグによるnode停止

Summary

Kubernetesを運用する上でのテクニック

  • サービス継続可能なpod数を維持
    • maxSurge, maxUnavailable
      • deploymentを用いたrolling update時
    • PodDisruptionBudget
      • nodeからのdrain時
  • アクセスの強制切断を防ぐ為、Graceful Shutdownを設定
    • lifecycle.preStop
      • podのtermination時に実行される処理
      • podのrestart時に必要となる
      • serviceの更新とpodのterminationは非同期であり適切な設定が必要
  • health check
    • Liveness Prove, Readiness Probeの設定
      • pod起動時間を考慮してProbeを開始
      • DBのtimeoutを考慮
  • podのpending時はnodeのauto scalingが有効
    • cpu, memoryリソースに余裕が無い場合、podがpending状態で起動しない場合がある

Digression

AWS ECSの場合、コンテナが確保するリソースに対しホストのリソースが足りない場合は、Taskの実行→コンテナが起動するもリソースが足りずに落ちるというのを無限に繰り返すが、Kubernetesの場合はpodがpending statusになるとのことでその方が遥かに分かりやすい。Azure Monitorによってコンテナ毎にリソース状況、各コンテナのログを確認出来るようで、pendingになっている要因もそこから読み取れそう。

※ 尚、AWS ECSのTask Rolling updateの流れは以下の通りである。

Task Definition(A) deploy → Task Definition(A) start → Task Definition(B) deploy → Task Definition(A,B)が混在 → Task Definition(A)停止 → Task Definition(B)のみ起動

検証から半年で、少人数のチーム(5人?)で運用に乗せるまでは、相当な検証と失敗を相当反復したに違い無い。お疲れ様でした。

以上。