Day3

最終日！
自分用参加・聴講メモ
※Keynoteは省略

Handling Risky Business: Cluster Upgrades

Lyftのクラスタ自動アップグレードの話
2017年からK8sを調査・構築して、2018年にはレガシーシステムを移行開始、2019年に(K8sが)急成長

OSセキュリティパッチ, バグフィックス, 機能追加などでK8sのバージョンアップは避けられない

目指すのはp95,99 latencyやCluster Healthなどを守ったアップグレード
(ということは、zero-downtimeは前提のようだ)

次のような流れでコード化して、クラスタ更新を自動化する

do
while
  !is_cluster_updated() and
  cluster_is_healthy() {
    NODE = get_old_node()
    kubectl cordon NODE
    kubectl drain NODE
    kubectl delete NODE
    terminate(NODE)
  }

それで作ったのがk8srotator(最初はv0)
GO言語で実装したOperator

FleezeとRotateの状態をもつ

Fleezeはクラスタアップグレードを停止する

RotateはCluster Cycleをローテートする

ローテーションの順番は資料に細かく書いてあるので、それを読んだ方がいい
簡単にいうと、Kubelet(Node)単位で、Old KubeletからNew KubeletへPodを移して、Drainしていく

K8srotator v1も登場
Cluster Healthを拡張, 特定ノードのフィルタリング, Cluster設定のカスタムなどを追加

取り込むべき障害シナリオは下記
・etcdがquorumを失う
・api-server, ingressの疲弊
・AWSのQuotaに当たる
・In-placeでのバージョン不整合

・ダメージコントロール
- Fleezeモードに切り替える
- User/ 管理者 / チームにアラート
・応急措置
- ログ・ステータス確認
- ローテートモードに戻す

今後やっていくとして、ML用のWorkloadの対応, Triggerの廃止, Multi Cluster, PDB, Custom Cluster Health, Node Terminateの順序化などがある

感想

Lyftでのクラスタアップグレードのお話で、クラスタ更新を自動で達成するためにOperatorを書くというアプローチが非常に面白かった
(TriggerベースでReconcile Modelではないので、たぶん厳密にはOperatorではない(似てるけど))
こうしたクラスタ自動更新のモチベーションは今のチームでもあって、非常に参考になった

今の日本だとクラスタ更新自動化を達成できている企業は限られていると思っているが、近いうちに同じモチベーションで様々な企業がこうしたクラスタ更新自動化に取り組んでいくのではないかな、という予感がしている

惜しむらくはKubeConでの世界のテックカンパニー各社が各社で別々の仕組みを構築していること。つまりデファクトスタンダードはない
ビジネスの特性によってWorkloadの特性も違うので、当然といえば当然かもしれないが...
公式からはkubeadm以上のものは出ない気がするので、もしやるならその選択になるのかもしれない

Am I Using It Right? Checking Best Practices on Live Kubernetes Clusters

DigitalOceanのClusterlintの話
Clusterlintというクラスタチェックツールを開発したようだ

best practices checker for Kubernetes clusters
https://github.com/digitalocean/clusterlint

DOKSというのがDigitalOceanのマネージドK8sサービス

Clusterlintで、K8sのベストプラクティスをチェックする

Clusterlint queries live Kubernetes clusters for resources, executes
common and platform specific checks against these resources and
provides actionable feedback to cluster operators.

とのこと

あとはClusterlintの使い方がメイン

Clusterlintの目指していることは
・マニフェストではなく、クラスタそのもののチェック
・プラットフォームごとの分析
・他のコードとの統合

ClusterlintはK8sからResourceを取得して、チェックし、結果をレポートする

次のように使う

clusterlint run -G aws

チェックするルールはコードで書く

実際にベストプラクティスに則っていないPodをデプロイし、チェックするデモもありました。

DigitalOceanの商用にはこのClusterlintを組み込んでいるらしい

最後には、他のLintツールにも触れていました

感想

YAML LinterはOSSで見かけることがあったものの、Clusterそのものをチェックする、というアプローチは初めてだったので興味深かった。
ベンダロック感も少し感じたが、利用者がコードを書いて、それでチェックできるのであれば良い選択肢かもしれない

The Gotchas of Zero-Downtime Traffic /w Kubernetes

Graceful Trafficでzero-downtimeを実現する話

前半はNginx + NodeJSのアプリを元に、説明

Podのシャットダウンは、kube-apiserverがDeleteを受信
PodはTerminatingステータスになる
全てのコンテナのPID 1がSIGTERMを受信する → (Termination Grace Period Seconds) → 全てのコンテナのPID 1がSIGKILLを受信する

Gotcha #1 CMD vs ENTRYPOINT

ENTRYPOINTでsh -c nginxを使うと、shにSIGTERMが送られる

Gotcha #2 STOPSIGNAL

Docker RuntimeだとSTOPSIGNALでSIGTERMを書き換えできる

Gotcha #3 Readiness / Liveness Probe

LivenessはプロセスがOKかどうかを確認
Readinessはプロセスが応答を受けられるかを確認

Gotcha #4 PreStop

preStopが動いている or SIGTERMが送られた時、Applicationは通信を受け続けている
(ServiceのEndpointが非同期で更新されるため)

重要なのは、ほとんどの場合のグレースフルシャットダウンの定義で、プログラムはKubernetesの期待に沿っていない。

新しい通信を受け付けないように、/bin/sleepも必要になる
(おそらく、新しい「sleep」LifeCycleHookを入れた方が良いのでは、と)

Gotcha #5 Deployment

replicasが1の時はRollingUpdateのmaxUnavailableを0にしておく
DefaultではmaxUnavaliableが1になっている(apps/v1betaで修正)
apps/v1を使っていることを確認しよう

Gotcha #6 Deployment

.spec.strategy.minReadySecondsと.spec.strategy.progressDeadlineSecondsの時間の間に、アプリケーションのウォームアップが完了するようにする

そして.spec.strategy.rollingUpdate.maxSurgeがキャパシティを超えないようにする

Gotcha #7 SideCar

AppがDBに接続するためのプロキシをSideCarとしている場合、preStop hookの間に競合しないように、同期またはスケジューリングするべき

まとめ

entrypointはシグナルをハンドルすべき
STOPSIGNALが必要になるかもしれない
Liveness / Readiness Probeは異なる間隔を設定する
接続を受け付けないように、preStopではSleepを入れる
apps/v1 Deploymentを使う
RollingUpdateの間にウォームアップを行う
SideCarのシャットダウンを同期させる

感想

アプリケーションで502,503を発生させずにいかに(ローリング)アップデートさせるか、という点に焦点をあてたセッションで非常にためになりました。

結局、リクエスト停止はsleepが最善なのか……
すでに取り組めていること、考えたことすらなかったことのどちらもあるので、もうGracefulについて考え直そうかな…

Evolving the Kubernetes Ingress APIs to GA and Beyond

Ingressの現状はNginx Ingress ControllerやHAProxy Ingress Controllerのようなプロダクトが出ている

v1ではIngressClassというモデルにクリーンアップする

backendをdefaultBackendにリネーム

パスが正規表現だが、Nginx/HAProxyでは合わないことも
v1ではPathTypeが追加される(詳しくは資料内の表を参考に)
PathTypeでPrefixも許容される

HostnameのWildcard
*.foo.comで「bar.foo.com」はOK。「baz.bar.foo.com」「foo.com」はNG

IngressClassはControllerとParameterをフィールドに持つ

v1betaではIngressBackendにserviceNameを持っているが、v1ではServiceBackendやServiceBackendPortなどの構造体が増える

v1 API Timelineとして、v1.18でIngress v1をRelease予定
v1.19でextension/v1beta1から取り除かれる。networking.k8s.io/v1beta1もv1.2xで取り除かれる

早期設定デザインは“self-service” oriented
現在は実装がたくさん...

より良いResource管理モデルの構築や、携帯性を保ちながら現在のLoadBalancing機能をサポートするのがゴール

※あくまで以下のAPIは提案ステージ。これからも変わっていく予定

Ingressはセルフサービスモデル
IngressClassがインフラプロバイダによって開発される

GatewayClassもインフラプロバイダが開発する
GatewayはLBのインスタンスのこと

RouteとServiceをApplicationエンジニアなどが定義する

RBACモデルでUSERがどういったROLEで、どのRESOURCEをどうVERBするのか、という記述ができるようにした

API Resourceのデザインや実装はこれから(Help Wanted!)

感想

IngressをGAに持って行こうという話で、まずはv1の拡張。
そしてv2でモデルを綺麗にするという話でした。
モデルを綺麗にすることでResourceが増えて、より複雑性は増しますが、ようやくそれでプロバイダー関係なく綺麗にまとまるのならアリかなと個人的には思いました。
Resourceが分割されることで、インフラプロバイダ•クラスタ管理者•アプリ開発者の役割が分割されて適正化されることに期待です。
(でもv2の実装はまだまだ先のよう)

Tutorial: Mastering Multi-version CRDs: From YAML to a Serious Development Project

CRDの応用機能は多数ある(Defaulting, Pruning, Conversion, etc...)
今回はConversionが主役

KubernetesのオブジェクトにはVersion XXのオブジェクトという考え方はない(裏側でバージョンの違いをConversionして互換性を保っている)

今回は機能の説明をしながら、実際のConversion, Admissionのソースに手を入れていくチュートリアル形式

こちらにソースがあるので、気になる人は読むと良いかも
(Programming Kubernetesを読んでいれば理解できると思う)

ClusterはMinikubeやKindなどでv1.16のクラスタを用意して、リポジトリに用意してあるYAMLをApplyすれば良い

チュートリアルリポジトリ:
https://github.com/jpbetz/Ko

感想

Programmin Kubernetesの著者の一人によるMulti Version CRDのチュートリアルという、すごく豪華なセッションでした。
CRDはv1.16でGAになりましたが、「今後CRDに他の応用機能が追加される予定がありますか？」と聞いたところ、Deep Dive Into API MachineryのKEP2つとUnionTypeのKEPが予定に入っているとのこと
CRDにはBreaking Changeがなさそうで安心した

KubeCon NA 2019(Day3) 参加メモ