Kubernetes 使用時によくある 10 の間違い

ノート。 翻訳。: この記事の著者は、チェコの小さな会社、pipetail のエンジニアです。 彼らは、Kubernetes クラスターの運用に関連する [時にはありふれたものですが、それでも] 非常に差し迫った問題と誤解の素晴らしいリストをまとめることに成功しました。

長年にわたって Kubernetes を使用してきたため、私たちは多数のクラスター (GCP、AWS、Azure 上のマネージドクラスターとアンマネージドクラスターの両方) を操作してきました。 時間が経つにつれて、いくつかの間違いが常に繰り返されていることに気づき始めました。 しかし、これは恥ずべきことではありません。ほとんどのことは私たち自身で行ったのです。

この記事には、最も一般的なエラーが含まれており、それらを修正する方法についても説明されています。

1. リソース: リクエストと制限

このアイテムは間違いなく最も注目を集め、リストの最初の場所に値します。

通常、CPU リクエスト まったく指定されていないか、値が非常に低いかのどちらかです (各ノードにできるだけ多くのポッドを配置するため)。 したがって、ノードは過負荷になります。 高負荷時には、ノードの処理能力が最大限に活用され、特定のワークロードは「要求」したものだけを受け取ります。 CPU スロットル。 これにより、アプリケーションの遅延、タイムアウト、その他の不快な結果が増加します。 (これについて詳しくは、最近の翻訳をご覧ください:Kubernetes の CPU 制限と積極的なスロットル" - 約。 翻訳）

最大限の努力 （非常に ノー 推奨）：

resources: {}

非常に低い CPU リクエスト (非常に低い) ノー 推奨）：

   resources:
      Requests:
        cpu: "1m"

一方、CPU 制限が存在すると、ノード プロセッサが完全にロードされていない場合でも、ポッドによるクロック サイクルの不当なスキップが発生する可能性があります。 繰り返しますが、これにより遅延が増加する可能性があります。 パラメータを巡る論争は続く CPU CFS クォータ Linux カーネルでは、設定された制限に応じて CPU スロットリングが行われ、さらに CFS クォータが無効になります...悲しいことに、CPU 制限は、解決できる以上の問題を引き起こす可能性があります。 詳細については、以下のリンクを参照してください。

過剰な選択 (オーバーコミット) メモリの問題は、より大きな問題につながる可能性があります。 CPU の制限に達するとクロック サイクルがスキップされ、メモリの制限に達するとポッドが強制終了されます。 観察したことがありますか OOMkill? はい、まさにそれが私たちが話していることです。

このようなことが起こる可能性を最小限に抑えたいですか? (以下の例のように) メモリ要求を制限値に設定することで、メモリを過剰に割り当てず、保証された QoS (サービス品質) を使用します。 これについて詳しくは、 ヘニング・ジェイコブスのプレゼンテーション (Zalando のリードエンジニア)。

破裂性 (OOMkillされる可能性が高くなります):

   resources:
      requests:
        memory: "128Mi"
        cpu: "500m"
      limits:
        memory: "256Mi"
        cpu: 2

保証された:

   resources:
      requests:
        memory: "128Mi"
        cpu: 2
      limits:
        memory: "128Mi"
        cpu: 2

リソースを設定するときに何が役立つ可能性がありますか?

ととも​​に メトリクスサーバー ポッド (およびポッド内のコンテナー) による現在の CPU リソース消費量とメモリ使用量を確認できます。 おそらく、すでに使用していることでしょう。 次のコマンドを実行するだけです。

kubectl top pods
kubectl top pods --containers
kubectl top nodes

ただし、現在の使用状況のみが表示されます。 これにより、おおよその規模を把握できますが、最終的には次のことが必要になります。 時間の経過に伴うメトリクスの変化の履歴 (「CPU のピーク負荷はどれくらいでしたか?」、「昨日の朝の負荷はどれくらいでしたか?」などの質問に答えるため)。 このために使用できます プロメテウス, データドッグ およびその他のツール。 メトリクスサーバーからメトリクスを取得して保存するだけで、ユーザーはメトリクスをクエリして、それに応じてプロットすることができます。

垂直ポッドオートスケーラー 許可する 自動化 このプロセス。 CPU とメモリの使用履歴を追跡し、この情報に基づいて新しいリクエストと制限を設定します。

コンピューティング能力を効率的に使用することは簡単な作業ではありません。 テトリスをずっとプレイしているようなものです。 平均消費量が低い (たとえば、約 10%) コンピューティング能力に多額の費用を支払っている場合は、AWS Fargate または Virtual Kubelet をベースにした製品を検討することをお勧めします。 これらはサーバーレス/従量制課金モデルに基づいて構築されており、そのような状況ではコストが安くなる可能性があります。

2. Liveness プローブと Readiness プローブ

デフォルトでは、Kubernetes では liveness チェックと readiness チェックが有効になっていません。 そして時々電源を入れ忘れることもあります...

しかし、致命的なエラーが発生した場合にサービスの再起動を開始するには、他にどのようにすればよいでしょうか? また、ロード バランサーは、ポッドがトラフィックを受け入れる準備ができていることをどのようにして知るのでしょうか? それともより多くのトラフィックを処理できるのでしょうか?

これらのテストは互いに混同されることがよくあります。

• 活気 — 「生存性」チェック。失敗した場合にポッドを再起動します。
• 準備 — 準備状況チェック。失敗した場合、ポッドを Kubernetes サービスから切断します (これは次のコマンドを使用して確認できます) kubectl get endpoints) となり、次のチェックが正常に完了するまでトラフィックは到着しません。

これらのチェックは両方とも ポッドのライフサイクル全体にわたって実行されます。 それは非常に重要です。

よくある誤解は、readiness プローブは起動時にのみ実行され、ポッドの準備ができていることをバランサーが認識できるというものです (Ready) になり、トラフィックの処理を開始できるようになります。 ただし、これは使用上のオプションの XNUMX つにすぎません。

もう XNUMX つは、ポッド上のトラフィックが過剰であることが判明する可能性です。 過負荷になる (またはポッドがリソースを大量に消費する計算を実行します)。 この場合、準備状況チェックが役に立ちます。 ポッドの負荷を軽減し、ポッドを「冷却」します。。 今後、準備状況チェックが正常に完了すると、 ポッドの負荷を再び増加させます。 この場合 (準備テストが失敗した場合)、活性テストの失敗は非常に逆効果になります。 健全で一生懸命に動作しているポッドを再起動する必要はありません。

したがって、場合によっては、誤って設定されたパラメーターを使用してチェックを有効にするよりも、まったくチェックを行わない方が良い場合があります。 上で述べたように、もし 活性チェックは準備チェックをコピーします、それでは大変なことになります。 可能なオプションは次のとおりです 準備テストのみと 危険な生命力 脇に置いておいてください。

共通の依存関係が失敗した場合、どちらのタイプのチェックも失敗すべきではありません。失敗しないと、すべてのポッドの連鎖的 (雪崩のような) 失敗が発生します。 言い換えると、 自分を傷つけないでください.

3. 各HTTPサービスのロードバランサー

おそらく、クラスター内に外部に転送したい HTTP サービスがあると思います。

次のようにサービスを開くと、 type: LoadBalancer、そのコントローラー (サービス プロバイダーによって異なります) は、外部ロードバランサー (必ずしも L7 で実行されるわけではなく、むしろ L4 で実行される場合もあります) を提供およびネゴシエートします。これは、コスト (外部静的 IPv4 アドレス、コンピューティング能力、秒単位の請求) に影響を与える可能性があります。 ）そのようなリソースを多数作成する必要があるためです。

この場合、XNUMX つの外部ロード バランサーを使用してサービスを開く方がはるかに論理的です。 type: NodePort。 あるいは、さらに良いのは、次のようなものを展開することです nginx-ingress-controller （または トレフィク）、誰が唯一の人になりますか？ ノードポート 外部ロード バランサーに関連付けられたエンドポイント。次を使用してクラスター内のトラフィックをルーティングします。 進入-Kubernetes リソース。

相互に対話する他のクラスター内 (マイクロ) サービスは、次のようなサービスを使用して「通信」できます。 クラスターIP DNS を介した組み込みのサービス検出メカニズム。 パブリック DNS/IP は使用しないでください。これは遅延に影響を与え、クラウド サービスのコストを増加させる可能性があります。

4. クラスターの機能を考慮せずにクラスターを自動スケールする

クラスターにノードを追加したり、クラスターからノードを削除したりする場合、それらのノードの CPU 使用率などの基本的なメトリクスに依存すべきではありません。 ポッドの計画では、多くのことを考慮する必要があります 制限ポッド/ノードのアフィニティ、テイントと許容、リソース リクエスト、QoS など。 これらの微妙な違いを考慮せずに外部オートスケーラーを使用すると、問題が発生する可能性があります。

特定のポッドをスケジュールする必要があるが、利用可能なすべての CPU パワーが要求または逆アセンブルされ、ポッドが 状態に陥ってしまう Pending。 外部オートスケーラーは現在の平均 CPU 負荷 (要求されたものではない) を確認し、拡張を開始しません。 （規格外） - 別のノードを追加しません。 その結果、このポッドはスケジュールされません。

この場合、逆スケーリング (スケールイン) — クラスターからノードを削除することは常に実装が困難です。 ステートフル ポッド (永続ストレージが接続されている) があると想像してください。 永続ボリューム 通常は所属する 特定のアベイラビリティーゾーン リージョン内では複製されません。 したがって、外部オートスケーラーがこのポッドを含むノードを削除すると、スケジューラーは別のノードでこのポッドをスケジュールできなくなります。これは、永続ストレージが配置されている可用性ゾーンでのみ実行できるためです。 ポッドがスタック状態になる Pending.

Kubernetes コミュニティで非常に人気のある クラスターオートスケーラー。 クラスター上で実行され、主要なクラウド プロバイダーの API をサポートし、すべての制限を考慮し、上記の場合に拡張できます。 また、設定されたすべての制限を維持しながらスケールインすることもできるため、コスト (未使用の容量に費やされることになるコスト) を節約できます。

5. IAM/RBAC 機能の無視

永続的なシークレットを持つ IAM ユーザーの使用には注意してください。 マシンとアプリケーション。 ロールとサービス アカウントを使用して一時的なアクセスを整理する (サービスアカウント).

Cloud IAM にアクセスできるにもかかわらず、アクセス キー (およびシークレット) がアプリケーション構成にハードコーディングされているだけでなく、シークレットのローテーションが無視されているという事実によく遭遇します。 必要に応じて、ユーザーの代わりに IAM ロールとサービス アカウントを使用します。

kube2iam のことは忘れて、サービス アカウントの IAM ロールに直接進みます (「 同じ名前のメモ シュテパン・ヴラニー):

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/my-app-role
  name: my-serviceaccount
  namespace: default

注釈が XNUMX つあります。 そんなに難しくないですよね？

また、サービス アカウントとインスタンス プロファイルの権限を付与しないでください。 admin и cluster-admin彼らがそれを必要としないなら。 これは、特に RBAC K8 では実装が少し難しくなりますが、努力する価値は間違いなくあります。

6. ポッドの自動アンチアフィニティに依存しない

ノード上にあるデプロイメントの XNUMX つのレプリカがあると想像してください。 ノードが落ち、それに伴ってすべてのレプリカも落ちます。 不快な状況ですよね？ しかし、なぜすべてのレプリカが同じノード上にあったのでしょうか? Kubernetes は高可用性 (HA) を提供するものではないでしょうか?!

残念ながら、Kubernetes スケジューラは、独自の判断で、分離存在のルールに準拠していません。 (アンチアフィニティ) ポッド用。 それらは明示的に指定する必要があります。

// опущено для краткости
      labels:
        app: zk
// опущено для краткости
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: "app"
                    operator: In
                    values:
                    - zk
              topologyKey: "kubernetes.io/hostname"

それだけです。 これで、ポッドは別のノードでスケジュールされます (この条件はスケジュール中にのみチェックされ、操作中にはチェックされません)。 requiredDuringSchedulingIgnoredDuringExecution).

ここで私たちが話しているのは、 podAntiAffinity 異なるノード上: topologyKey: "kubernetes.io/hostname", - 異なるアベイラビリティーゾーンについてではありません。 本格的な HA を実装するには、このトピックをさらに深く掘り下げる必要があります。

7. PodDisruptionBudget の無視

Kubernetes クラスター上に実稼働負荷があると想像してください。 定期的に、ノードとクラスター自体を更新 (または廃止) する必要があります。 PodDisruptionBudget (PDB) は、クラスター管理者とユーザー間のサービス保証契約のようなものです。

PDB を使用すると、ノード不足によるサービスの中断を回避できます。

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: zk-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: zookeeper

この例では、クラスターのユーザーとして、管理者に次のように述べます。「私は Zookeeper サービスを持っています。何をするにしても、このサービスの少なくとも 2 つのレプリカを常に使用できるようにしたいのです。」

これについて詳しく読むことができます ここで.

8. 共通クラスター内の複数のユーザーまたは環境

Kubernetes 名前空間 (名前空間) 強力な絶縁を提供しない.

よくある誤解は、非本番ロードを XNUMX つの名前空間にデプロイし、本番ロードを別の名前空間にデプロイすると、 お互いにいかなる影響も与えません...ただし、リソースの要求/制限、クォータの設定、および priorityClasses の設定を使用して、一定レベルの分離を達成できます。 データ プレーン内の一部の「物理的」分離は、アフィニティ、許容範囲、テイント (またはノードセレクター) によって提供されますが、そのような分離は完全に分離されます。 難しい 埋め込む。

同じクラスター内で両方のタイプのワークロードを組み合わせる必要がある場合は、複雑さに対処する必要があります。 そのような必要がなく、余裕がある場合は、 もう一つのクラスター (たとえば、パブリック クラウド内で) であれば、そうする方が良いでしょう。 これにより、より高いレベルの断熱性が実現されます。

9. externalTrafficPolicy: クラスター

クラスター内のすべてのトラフィックが、デフォルトのポリシーが設定されている NodePort などのサービスを経由していることがよく見られます。 externalTrafficPolicy: Cluster。 つまり、 ノードポート はクラスター内のすべてのノードで開いており、それらのいずれかを使用して目的のサービス (ポッドのセット) と対話できます。

同時に、上記の NodePort サービスに関連付けられた実際のポッドは、通常、特定のサーバーでのみ利用可能です。 これらのノードのサブセット。 つまり、必要なポッドがないノードに接続すると、トラフィックが別のノードに転送されます。 ホップを追加する レイテンシの増加 (ノードが異なるアベイラビリティ ゾーン/データ センターに配置されている場合、レイテンシは非常に高くなる可能性があります。さらに、下りトラフィックのコストも増加します)。

一方、特定の Kubernetes サービスにポリシーが設定されている場合、 externalTrafficPolicy: Localそうすると、必要なポッドが実際に実行されているノードでのみ NodePort が開きます。 状態を確認する外部ロードバランサを使用する場合 (健康診断) エンドポイント (どのように機能するか) AWS ELB）、 彼 必要なノードにのみトラフィックを送信します、これは遅延、コンピューティングのニーズ、下り料金に有益な効果をもたらします（そして常識的には同様です）。

すでに次のようなものを使用している可能性が高いです トレフィク または nginx-ingress-controller NodePort エンドポイント (または NodePort を使用する LoadBalancer) として HTTP 受信トラフィックをルーティングし、このオプションを設定すると、そのようなリクエストの待ち時間を大幅に短縮できます。

В この出版物 externalTrafficPolicy とその利点と欠点について詳しく学ぶことができます。

10. クラスターに縛られず、コントロール プレーンを乱用しないでください。

以前は、サーバーを適切な名前で呼び出すのが慣例でした。 アントン、HAL9000、Colossus...現在、それらはランダムに生成された識別子に置き換えられています。 しかし、その習慣は残り、現在では固有名詞がクラスターに属します。

典型的なストーリー (実際の出来事に基づく): すべては概念実証から始まったので、クラスターには誇らしい名前が付けられました テスト…何年も経ちましたが、まだ本番環境で使用されており、誰もがそれに触れるのを恐れています。

クラスターがペットに変わっても何も楽しいことはないので、練習中は定期的にクラスターを削除することをお勧めします。 災害からの回復 (これは役に立ちます カオスエンジニアリング — 約翻訳）。 さらに、コントロール層で作業しても問題ありません (コントロールプレーン)。 彼に触れることを恐れるのは良い兆候ではありません。 その他 死んだ？ 皆さん、本当に困っています！

一方で、それを操作することに夢中になるべきではありません。 時間とともに 制御層が遅くなる可能性があります。 最も可能性が高いのは、多数のオブジェクトが回転せずに作成されていることが原因です (Helm をデフォルト設定で使用する場合によくある状況です。これが、configmaps/secret 内の状態が更新されない理由です。その結果、数千のオブジェクトがコントロール層)、または kube-api オブジェクトの継続的な編集 (自動スケーリング、CI/CD、モニタリング、イベント ログ、コントローラーなど) を使用します。

さらに、マネージド Kubernetes プロバイダーとの SLA/SLO 契約を確認し、保証に注意することをお勧めします。 ベンダーが保証してくれる 制御層の可用性 (またはそのサブコンポーネント) ただし、送信するリクエストの p99 遅延は含まれません。 つまり、次のように入力できます。 kubectl get nodes、10分後にのみ回答が得られますが、これはサービス契約の条件に違反するものではありません。

11. おまけ: 最新タグの使用

しかし、これはすでに古典です。 最近では、多くの人が苦い経験から学んでこのタグの使用をやめたため、この手法に遭遇することは少なくなりました。 :latest そしてバージョンの固定を開始しました。 万歳！

ECR イメージタグの不変性を維持します; この注目すべき機能についてよく理解しておくことをお勧めします。

サマリー

すべてが一夜にして機能することを期待しないでください。Kubernetes は万能薬ではありません。 悪いアプリ Kubernetes でも​​このままになります （そしておそらく悪化するでしょう）。 不注意な場合、制御層の過度の複雑化、遅延とストレスの多い作業が発生します。 さらに、災害復旧戦略が講じられないままになる危険性があります。 Kubernetes がすぐに分離性と高可用性を提供することを期待しないでください。 時間をかけてアプリケーションを真のクラウド ネイティブにしてください。

さまざまなチームの失敗体験を知ることができます。 この物語集 ヘニング・ジェイコブス著。

この記事に記載されているエラーのリストに追加したい場合は、Twitter (@MarekBartik, @mstrsObserver).

翻訳者からの追伸

私たちのブログもお読みください:

• «Kubernetes クラスターの設計: クラスターはいくつ必要ですか?";
• «Kubernetes のセキュリティの ABC: 認証、認可、監査";
• «Kubernetes の自動スケーリングとリソース管理」（レビューとビデオレポート）;
• «Kubernetes の ConfigMap: 知っておく価値のあるニュアンス'。

出所： habr.com