Kubernetes を 2 年間使用して学んだ教訓

Ridecell でインフラストラクチャ チームを数年間運営した後、少し休憩して、自分の考えや学んだ教訓を記録しておきたいと思いました。

[[331782]]

Kubernetesは単なる誇大宣伝ではない

私は長い間 Kubernetes の分野で活動してきたので、これは私にとって予想外のことではありませんでしたが、何かが話題になっているときは必ず二重チェックをするのが良いでしょう。 2 年かけて、私のチームは Ansible+Terraform から純粋な Kubernetes への完全な移行を完了し、その過程でデプロイメント率が 3 倍以上に増加し、デプロイメント エラーが「最後に発生したのはいつだったか思い出せない」レベルにまで減少しました。また、運用の可視性を向上させ、地味だが重要なタスクの多くを自動化し、インフラストラクチャの停止が発生したときの平均復旧時間を改善しました。

Kubernetes は魔法ではありませんが、それを理解しているチームが使用すれば非常に強力なツールになります。

Traefik + Cert-Manager + Ext-DNSの組み合わせは素晴らしい

Traefik は Ingress コントローラーとして機能し、Cert-Manager は LetsEncrypt を通じて証明書を生成し、External-DNS はエッジ DNS レコードを管理します。これら 3 つの組み合わせにより、HTTP ルーティングと管理が非常にスムーズになります。私は、Traefik 2.0 で 1.x の注釈機能の多くを削除するという選択にかなり批判的でしたが、異なる形式ではありますが、最終的に 2.2 でそれらの注釈機能が復活しました。エッジ プロキシとして、Traefik は、優れたメトリック統合、すべての Ingress コントローラーの中で管理する部分が最も少ない、対応力の高い開発チームを備えた確実な選択肢です。 Cert-Manager は、あらゆる Ingress ソリューションと組み合わせて使用​​すると非常に便利なツールです。 Kubernetes クラスターに TLS があるが、まだ使用していない場合は、今すぐ確認してください。外部 DNS は他の 2 つほど人気はありませんが、DNS レコードと実際のマッチングの手順を自動化する上で同様に重要です。

むしろ、これらのツールを使用すると、新しい HTTPS エンドポイントの設定が簡単になりすぎる可能性があります。長年にわたり、私たちは数十の固有の証明書を使用することになり、Cert Transparency 検索や LetsEncrypt 独自の証明書有効期限の警告などで多くのノイズが発生していました。今後は、使用される証明書の総数を減らすために、どのホスト名をグローバルに構成されたワイルドカード証明書の一部にできるかを慎重に検討します。

プロメテウスは素晴らしい、サノスは才能の無駄ではない

Prometheus を主要なメトリクス システムとして使用したのは今回が初めてですが、この分野で最高のツールとなるにふさわしいものです。私たちはそれを管理するために Prometheus-Operator を選択しました。これは良い選択であり、スクレイピングとルール構成を、それらを必要とするアプリケーションに簡単に配布できるようになりました。 （もう一度やり直すなら）最初からサノスを使っていただろう。当初はこれを使うのはやり過ぎだと思っていましたが、設定が非常に簡単で、マスター-マスターの高可用性設定を直接使用しなかったにもかかわらず、クロスリージョンクエリや Prometheus リソース使用量の削減に大いに役立ちました。

このスタックで私が最も苦労したのは、Grafana のデータ管理、つまりダッシュボードの保存方法と組み立て方でした。 YAML ファイル、JSON ファイル、Kubernetes カスタム オブジェクトなど、ダッシュボードの管理に使用できるツールは大幅に増加しています。しかし、根本的な問題は、Grafana には数百万もの異なる構成オプションやパネル モードなどがあるため、どのツールを使ってもダッシュボードをゼロから作成するのが難しいことです。最終的には、すべてのダッシュボードをグループで管理するステートフル システムとして処理することになりましたが、このソリューションは気に入りませんでした。もっと良いワークフローはあるでしょうか?

GitOpsは正しい方法

Kubernetes を使用する場合は、GitOps を使用する必要があります。ツールの選択肢は多数あり、既存の CI システムに kubectl apply を実行するジョブを追加するだけから、ArgoCD や Flux などの専用システムを使用するまで多岐にわたります。しかし、私は断固として ArgoCD 派です。これは始めるには確実な選択であり、年々良くなってきています。今週、GitOps エンジンの最初のバージョンが公開され、ArgoCD と Flux が共通の基盤システム上に配置されたため、より高速で優れたものになりました。これらのツールのワークフローが気に入らない場合は、新しいツールをより簡単に構築することもできます。数か月前、誰かが誤ってテスト クラスター内のほとんどの名前空間を削除したため、予期せぬ DR ゲーム デーが発生しましたが、GitOps のおかげで、ブートストラップ リポジトリで make apply を実行し、システムが再構築されるのを待つことで復旧できました。そうは言っても、Velero バックアップは、git では保存できない一部のステートフル データ (cert-manager 証明書など。再発行は可能ですが、LetsEncrypt のレート制限に遭遇する可能性があります) にとっても重要です。

私たちが直面した最大の問題は、すべてのコア インフラストラクチャを 1 つのリポジトリに保存するという選択でした。単一のリポジトリを使用するのが適切な設計だと今でも思っていますが、現在のようにすべてを 1 つの「インフラ」インスタンスに格納するのではなく、さまざまなものを異なる ArgoCD インスタンスに分離します。単一のインスタンスを使用すると、収束時間が長くなり、UI が乱雑になり、Kustomize 定義を適切にセグメント化する習慣が身に付いても、あまりメリットがありません。

オペレーターを増やすために応募します

私は当初からカスタムオペレーターの開発を積極的に行っており、この点では大きな成功を収めています。私たちは、メインの Web アプリをデプロイするための単一のカスタム リソースとコントローラーから始めて、そのアプリや他のアプリに必要な他のすべての自動化に徐々に拡張していきました。単純なインフラストラクチャ サービスに単純な Kustomize と ArgoCD を使用すると問題なく動作しますが、外部のもの (Kubernetes から kiam 経由で使用するために AWS IAM ロールを作成するなど) を制御したい場合や、これらのものを制御するためにあるレベルのステート マシンが必要な場合 (SQL 移行による Django アプリのデプロイメントなど) は、Operators を使用する必要があります。この一環として、すべてのカスタム オブジェクトとコントローラーに対して非常に徹底したテスト スイートも構築しました。これにより、操作の安定性が大幅に向上し、システムが正しく動作しているという確信も高まりました。

Operator を構築する方法は増えていますが、私は今でも kubebuilder にかなり満足しています (ただし、公平を期すために言うと、時間の経過とともにプロジェクト構造が大幅に変更されたため、kubebuilder 自体ではなく、controller-runtime と controller-tools を使用していると言った方が公平です)。どのような言語やフレームワークを使用したい場合でも、おそらく Operator ツールキットが利用可能であり、それを必ず使用する必要があります。

秘密管理は依然として問題

Kubernetes には、コンテナーやその他のオブジェクトで使用するために実行時に秘密データを管理するための独自の Secret オブジェクトがあり、このシステムは非常にうまく機能します。しかし、Secret の長期的なワークフローはまだ少し乱雑です。生の Secret を Git にコミットするのは、列挙する必要がないほど多くの理由から好ましくありません。では、これらのオブジェクトをどのように管理すればよいのでしょうか。私の解決策は、AWS KMS を使用して各値を暗号化するカスタム EncryptedSecret タイプを開発し、Kubernetes で実行されているコントローラーが通常どおりそれを通常の Secret に復号化し、復号化、編集、再暗号化サイクル用のコマンドライン ツールを開発することでした。 KMS を使用すると、アクセス制御のための IAM ルールを通じて KMS キーの使用を制限し、ファイルを合理的に区別できるように値のみを暗号化できます。現在では、Mozilla Sops をベースにしたコミュニティ オペレーターがいて、ほぼ同じワークフローを提供していますが、Sops はローカル編集ワークフローには少々不便です。全体として、この分野ではまだやるべきことがたくさんあり、GitOps の世界のすべてと同様に、監査可能、バージョン管理可能、コードレビュー可能なワークフローが期待されます。

関連する問題として、Kubernetes の RBAC モデルの弱点は Secrets で最も顕著になります。ほとんどの場合、1 つの目的で使用される Secret は、それを使用するものと同じ名前空間に存在する必要があります。つまり、多くの場合、さまざまな目的の Secret が同じ名前空間 (データベース パスワード、ベンダー API トークン、TLS 証明書) に存在することになり、誰か (または何か、同じ問題はオペレーターにも当てはまります) にそれらのうちの 1 つへのアクセスを許可すると、そのユーザーはそれらすべてにアクセスできるようになります。名前空間はできるだけ小さく保ちます。独自の名前空間に配置できるものはすべて、それを実行します。これを実行すると、RBAC ポリシーによって感謝されることになります。

ネイティブCIとログ分析は未解決の問題

私が遭遇したエコシステムの最大の落とし穴は、CI とログ分析の 2 つでした。 Jenkins、Concourse、Buildkite など、Kubernetes 上にデプロイされている CI システムは多数ありますが、完全にネイティブなソリューションはほとんどないように感じます。 JenkinsX はおそらくネイティブ エクスペリエンスに最も近いものですが、非常に複雑な構造になっているため、残念だと思います。 Prow 自体も非常にネイティブですが、カスタマイズ性が高いため、使いやすいツールではありません。 Tekton Pipelines と Argo Workflows はどちらもネイティブ CI システム用の低レベルの配管機能を備えていますが、それを開発チームに公開する方法を見つけることは、理論上の運用スタッフを超えることはありませんでした。 Argo-CI は放棄されたようですが、Tekton チームはこのユースケースを積極的に追求しているようなので、何らかの改善が期待できます。

ログ収集はほぼ解決された問題であり、コミュニティは Fluent Bit に注力し、それを DaemonSet としていくつかの Fluentd ポッドに送信し、その後、保存と分析に使用する任意のシステムに送信します。ストレージ側では、ElasticSearch と Loki が主なオープン競合製品であり、それぞれ独自の分析フロントエンド (Kibana と Grafana) を備えています。私のフラストレーションの原因は主に最後の部分のようです。 Kibana は以前から存在しており、分析機能も充実していますが、ユーザー認証やユーザー権限などの基本的な操作を行うには商用バージョンを使用する必要がありますが、まだ非常に曖昧です。 Loki ははるかに新しいため、分析ツール (サブ文字列検索と行ごとのタグ検索) がさらに少なく、権限の設計はまだありません。すべてのログ出力が安全であり、すべてのエンジニアに見えるように注意していれば問題ありませんが、SOC/PCI などの監査で厳しい質問に直面する準備をしてください。

結論

Kubernetes は多くの人が主張するようなターンキー ソリューションではありませんが、慎重なエンジニアリングと驚異的なコミュニティ エコシステムがあれば、比類のないプラットフォームになる可能性があります。時間をかけて基礎となる各コンポーネントを学習すれば、コンテナの至福への道を順調に歩むことができ、その過程で私のような間違いも避けられるでしょう。