気をつけたいKubernetesとの付き合い方 / Happy Kubernetes Life

Transcript

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

   View Slide

2. Kubernetes...分散システム
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

9. 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による
   スケジューリング
   

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

18. 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の先頭から試行する
    

    View Slide

19. 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
    末尾にドット(.)あり
    

    View Slide

20. 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 ~
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide