過去 3 年間に Kubernetes クラスターを管理する際に遭遇した 10 の落とし穴

著者: Herve Khg

編集者 |ルヤン

制作 | 51CTO テクノロジースタック (WeChat ID: blog)

クラウド コンピューティングの分野における絶対的な主役として、Kubernetes は間違いなくコンテナ テクノロジーの分野で「トップの座」を獲得しました。本質は、アプリケーションを YAML で記述するだけで、残りは自動的に実行されることです。

しかし、これらすべての前提は、K8s クラスターの効率的な管理です。

Kubernetes クラスターを管理してきた 3 年間について言えば、紆余曲折のジェットコースターのような日々でした。この困難な経験を通して、私はこのテクノロジーに対する理解を深め、基盤となるインフラストラクチャの管理、展開プロセスの最適化、クラスターのスケーラビリティとセキュリティの確保に関するベストプラクティスを網羅した、最も価値があると思われる 10 の教訓をまとめました。

Kubernetes を初めて使用する方でも、経験豊富な専門家でも、これらの経験は Kubernetes クラスターの管理についてより豊かな視点を提供します。

1. 基盤となる Kubernetes インフラストラクチャを自分で管理しますか?それは本当に必要ありません

基盤となるインフラストラクチャの管理に多くの時間を費やすと、kube-api、kube-apiserver、kubelet、etcd、kube-proxy などの分野の専門家になれるかもしれませんが、これはビジネスにとっては時間と労力の無駄になる可能性があります。

Kubernetes クラスターをより効率的に管理したい場合は、このタスクを適切なクラウド サービス プロバイダーに引き渡すだけです。

2. コードを使用してKubernetesインフラストラクチャをデプロイする

コンソール上でクラスター操作を実行しないでください。特に、「コンソールで問題が修正されたらすぐにコードを更新します」という行き当たりばったりの考え方は持たないでください。

3. 完全に制御できないHelm Chartsを過度に使用しない

Helm Chart は Kubernetes アプリケーションをパッケージ化して配布するより簡単な方法を提供しますが、YAML を書くために頭を悩ませる必要はありません。ただし、values.yaml ファイル内の各変数を理解し、デフォルト値の使用を避ける必要があることにも注意してください。

4. Kubernetesは直接移行には適していない

Kubernetes をアプリケーションに適応させるのではなく、アプリケーションを Kubernetes に適応させます。したがって、古いアプリケーションをクラウドと互換性のあるものに再適応させる必要があります。アプリケーションの再コーディングが不可能な場合は、古い仮想マシンを引き続き使用できます。

5. サービス メッシュをインストールしますか?

必要がない限り、サービス メッシュをインストールしないでください。では、サービス メッシュをインストールする必要があるかどうかをどのように判断すればよいのでしょうか?次の 2 つの質問を自分に問いかけてみましょう。

1 つは、クラスター内のアプリケーションが相互に通信できるかどうかです。

次に、クラスター内のアプリケーション間のやり取りを保護する必要がありますか?

これらの質問の両方の答えが「はい」の場合は、サービス メッシュをインストールする必要があります。

6. 複数のツールを使わない

Kubernetes には、argocd、lens、k9s、keda、krew、kubectx、kubens、kail など、クラスターをより適切に管理するのに役立つ多数の補助ツールが用意されています。ただし、あまり多くのツールに頼らないでください。適切な kubectl を使用すれば、ニーズの 90% を満たすことができます。

私の経験では、通常は kubectx、kubens、k9s などのツールのみを選択します。これにより、クラスターの管理がより効率的になります。

7. ポッドに割り当てられるリソース制限を必ず定義してください

そうすることで、一部のポッドが貪欲になりすぎて、コーディングや構成が不十分なアプリケーションがすべてのクラスター リソースを消費し、最終的にアプリケーションが 1 つずつシャットダウンしてしまうリスクを防ぐことができます。これは、Helm Charts に注意し、完璧なパッケージ化の背後にあるマニフェスト ソース コードを常に確認する必要がある理由の 1 つです。

8. ポッドにデータを保存するのは避ける

これを実現するのが本当に難しい場合は、ディスクではなく NAS にインストールする方がよいでしょう。そうしないと、デプロイメント内の一部のポッドが永続リソースにアクセスできない可能性があります。

ハードディスクは 1 つのノードにしかマウントできないため、ポッドが複数のノードに分散されている場合、同じノード上のポッドには同じデータが表示されますが、他のノード上のポッドにはデータは表示されません。 EFS のような NAS タイプのインストールを使用すると、この問題を回避できます。

9. HPAを構成する

これまでの作業をやめて、需要に基づいてリソース使用率を自動的に管理する Kubernetes の機能を活用したい場合は、すべてのアプリケーション プロジェクトで HPA (Horizo​​ntal Pod Autoscaler) を構成する必要があります。

10. 変化を恐れない

クラスターのバージョンは 4 か月ごとに、1 年に約 3 回アップグレードする必要があります。一部のアップグレードは透過的ですが、通常は何らかの影響を伴います。

アップデートにさらに万全の準備をするには、リリース ノートを確認し、他の専門家の経験を参考にする必要があると思います。

11. 最後に

この記事では、主に、基盤となるインフラストラクチャの展開と管理、Helm Chart の使用、サービス グリッドのインストール、Kubernetes ツールの選択、ポッド リソース制限の定義など、K8s クラスター管理で考慮する必要がある 10 の重要なポイントを分析します。しかし、実際の業務では複数のクラスターを同時に管理する必要があることが多く、状況はより複雑になります。したがって、実際の操作プロセスではいくつかの重要なポイントは無視できますが、特別な注意を必要とするいくつかの「落とし穴」があります。