気をつけたいKubernetes との付き合い方 go_vargo OpenShift.Run Winter 2020

Kubernetes...分散システム

Kubernetes...分散コンポーネント

今日の発表 ● Kubernetesは分散システムかつ分散コンポーネントで複雑 ○ Event Driven, Asynchronous ● そんなKubernetesと触れ合う上で、気をつけたいことを徒然 なるままに書きました ● KubernetesをWebアプリケーション基盤として使っているパ ターンで考えています ● Production Ready観点ではないので、ご注意ください ● すべて個人の見解です

Agenda ● 気をつけよう！ スケジューリング ● 気をつけよう！ オートスケール ● 気をつけよう！ DNS ● 気をつけよう！ モニタリング ● 知っておこう！ トラブルシューティング ● まとめ

気をつけよう！ スケジューリング Kubernetesのスケジューリング = Kubernetesがいい感じにやってくれる いい感じにやってくれる = 人間が特に何も考えなくてもよい？ そんなわけはなく... 分散システム上でスケジューリングを何も考えないと 時には痛い目に......

スケジューリングの要素分解 ● 複数のNode (+NodePool, NodeGroup) ● Resources/Limits ● Qos Class ● NodeSelector ● Taints/Tolerations ● Affinity ● Auto Scaler ● PriorityClassによるPreemption

スケジューリングの要素分解 ● 複数のNode (+NodePool, NodeGroup) ● Resources/Limits ● Qos Class ● NodeSelector ● Taints/Tolerations ● Affinity ● Auto Scaler ● PriorityClassによるPreemption

PriorityClassによるPreemption apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: system-cluster-critical value: 2000000000 description: Used for system critical pods system-cluster-critical priority: 2000000000 priority: 0 Preemption = Pod Delete 容量一杯のNode Autoscalerによる スケジューリング

スケジューリングの注意点 ※一部のみ ● K8sシステム系のPodが乗るNodeに、重要なPodを相乗りさせない ○ PreemptionによるPodの即死を防ぐ ● (Preemption関係なく) 落ちるとシステムに影響が出るようなPodは固ま らないように、あるいは固まってもまとめて死なないように注意する わりとある気がするケース(特定NodeにPodが偏る)

気をつけよう！ オートスケール Kubernetesのオートスケールはとても素晴らしい機能です。 これを上手く使いこなせれば、人手を経ずにシステムの負荷に対処できます。 しかし、万能というわけではなく苦手なケースもあるので、それらについて考 えてみます。

オートスケールと負荷パターン ゆっくり負荷が増えるケース 急にスパイクするケース なかなか上がり切らないケース

オートスケールと負荷パターン ゆっくり負荷が増えるケース 急にスパイクするケース なかなか上がり切らないケース 理想のケース (特に問題なし)

オートスケールと負荷パターン ゆっくり負荷が増えるケース 急にスパイクするケース なかなか上がり切らないケース Targetに行ったり来たりするので、 負荷に対するリソースが安定しない これはこれで迷惑なパターン Target

オートスケールと負荷パターン ゆっくり負荷が増えるケース 急にスパイクするケース なかなか上がり切らないケース 急なスパイクに対して、 プロビジョニングが間に合わない

オートスケールの注意点 ※一部のみ ● オートスケールのTargetに対して、行ったり来たりが頻繁に来ると Replicasが増えたり減ったりを繰り返すと、アプリケーションの種類に よっては迷惑に... ● 急なスパイクが来ると、NodeやPodのプロビジョニングが間に合わない こともある ○ 過負荷で502が多発することも ○ だいたい事前にPod数を増やしておくしかない ● オートスケールの閾値は定期的に見直しましょう ○ 実際の負荷と要相談

気をつけよう！ DNS KubernetesのDNSは、Control Planeではありませんがシステム系の重要なコ ンポーネントです。 通常名前解決はこのDNSを経由するので、DNSにアクセスできないとその時点 でエラーや障害になります。 KubernetesのDNSについて知っておきたいことに触れます。

resolv.conf - ClusterFirst 複数のsearch domains と ndots: 5が設定される 問い合わせ名が「ドット数 < ndots:5 」だとsearch domainと組み合わせて 問い合わせする nameserver 10.96.0.10 search .svc.cluster.local svc.cluster.local cluster.local options ndots:5 /etc/resolv.conf ※Kubernetesの種類によって微妙に違う。これはMinikube 例: Service「nginx-service」 nginx-service nginx-service.cluster.local nginx-service.svc.cluster.local nginx-service..svc.cluster.local ※ 実際はsearchの先頭から試行する

resolv.conf - ClusterFirst 例: Service「nginx-service」 nginx-service nginx-service.cluster.local nginx-service.svc.cluster.local nginx-service..svc.cluster.local A(IPv4)/AAAA(IPv6) A(IPv4)/AAAA(IPv6) A(IPv4)/AAAA(IPv6) A(IPv4)/AAAA(IPv6) ここにIPv4/IPv6のクエリが加わるので、FQDNでなかったりAbsolute Domain Name でないと、DNSに対して余分なクエリを発行してしまう nginx-service.default.svc.cluster.local nginx-service.default.svc.cluster.local. Absolute Domain Name FQDN but not Absolute 末尾にドット(.)あり

DNSの注意点 ※一部のみ ● Kubernetes上で、名前解決をするときは余分なクエリが発行されないよ うに、Absolute Domain Nameで書くようにする ● 大規模だったり高負荷なシステムの場合は、Node Local DNS Cacheの有 効化も考える ○ https://kubernetes.io/ja/docs/tasks/administer-cluster/nodel ocaldns/ It’s not DNS. There’s no way it’s DNS. It was DNS. ~ It’s always DNS ~

気をつけよう！ モニタリング モニタリングと言いつつ、ほとんどPrometheusの話です。 というのもクラウドネイティブなOSSでモニタリングしようとすると、 だいたいPrometheus + Grafanaの構成を取ると思っているからです。 先に言っておくと、Prometheusは好きです。

Prometheusよ、永遠なれ Prometheusはよく死にます。 気を抜くと、CrashLoopBackOffで数千回死んだままということもありえます (早く気づけよ、という話ですが私はありました)。 Prometheusのプロセスが落ちるよくある理由はOOMKillでしょう(偏見かも)。 当然ですが、PrometheusがScrapeする対象・頻度・保存期間が増えれば増え るほどPrometheusのメモリ使用量は逼迫され、上限に達するとOOMKillされま す。 あくまで経験則なので絶対ではないですが、メモリ上限を増やしてもいつかは 死にます。

Prometheusと私の5の約束 1. なるべくたくさんのメモリを用意してあげてください 2. Prometheusは長期保存に向いていません。Retentionは短めに 3. 不要なScrapeターゲット(とexporter)は追加しないでください 4. 不要なMetricsは(可能なら)Dropしてください 5. どうしても長期保存したい場合は、長期保存用のストレージと組み合わせ て使ってください

モニタリング(Prometheus)の注意点 ※一部のみ ● Prometheusは長期保存には向いていません ● Prometheusのメトリクスデータを長期保存したい場合は、長期保存用の プロダクトと組み合わせてください ○ Cortex ○ Thanos ○ Victoria Metrics ○ M3DB ● PrometheusはMetricsのScrapeにだけ集中させてあげると、安定する印 象です

知っておこう！ トラブルシューティング Kubernetesであろうがなかろうが、トラブルシューティングはエンジニアとは 切ってもきれない関係です。 あらゆるパターンの網羅はできませんが、Kubernetesの管理者観点でこういう ことができるといいな、ということを書いておきます (kubectl logs や kubectl describeは使える前提で)

Kubernetesコンポーネントログに慣れ親しむ CKA(※)の試験では、Kubernetesクラスタの管理者としての知識・技能が問わ れます。その問題の中には、Master NodeやWorker Nodeに実際にSSHをし て、サーバー上のログや設定ファイルからエラーを探し出して修正する問題が 出ます。 実際にSSHをする必要がないケースも当然ありますが、 この場合は「知っていること」と「いざという時にできること」が重要です。 ※ Certified Kubernetes Administrator

SSH & journalctl $ ssh worker-XX $ systemctl status kubelet # kubeletのログチェック $ journalctl -u kubelet 引用: https://kubernetes.io/ja/docs/concepts/overview/components/

まとめ Kubernetesは分散システム・分散コンポーネントのため、気をつけるべきポイ ントがいくつもあります。 今回はその中からいくつか抜粋してお話しました。 時に不可解な動きをすることもありますが、その時はKubernetesの気持ちに なって、時系列・各コンポーネントの動作(非同期)を考慮しながら向き合って みてください。 Happy Kubernetes Life!!!