K8Sエコシステムの選択と落とし穴をすべて網羅

[[320104]]

収益の増加とコストの削減は、企業が利益を増やすための 2 つの主要な方向性です。多くの場合、コスト削減の責任はミドルプラットフォーム戦略またはインフラストラクチャシステムに負わされます。企業の規模に関係なく、コンテナ化により効率が大幅に向上し、運用と保守の標準化が進み、リソースの利用率が向上すると考えられています。しかし、そういったことがきちんと行われないと、多額の費用をかけたのに成果が認められないという恥ずかしい結果に陥りがちです。この共有はチームの実際の経験から始まり、コンテナ化されたエコシステムの実装に関するいくつかのことについて話します。

モニター

コンテナ環境は通常、完全なソリューション セットを提供します。監視は、インジケーター監視、ビジネス監視、コール チェーン監視の 3 つのタイプに分けられます。

ビジネス監視とコール チェーン監視は、スカイウォーキングなどのビジネス開発部門の選択に大きく依存します。

コンテナ環境では、Prometheus がインジケーターの監視に最適です。スクレイプ パスは、サービス ディスカバリ メカニズムの Kubernetes プラグインを通じて取得され、後続のリンクはよりスムーズになります。

Prometheus を使用する際に避けられない問題の 1 つは、永続ストレージです。 WAL に保存されるデータは多すぎてはなりません。多すぎると、メモリと読み込み速度に大きな問題が発生します。公式にサポートされているリモート読み取り/書き込みリストでは、InfluxDB と TiDB を調べました。実際には、どちらも大量のメモリを占有します。クラスター外の物理マシンにデプロイすることをお勧めします。 InfluxDB を使用する場合、クラスター内で Pod が頻繁に作成されると (たとえば、cronjob を使用)、キー数量制限がトリガーされる可能性があります。

ログ

ログには、std シリーズ ログとファイル ログの 2 種類があります。それらの主な違いは、収集方法の違いです。一般的に、収集されたログは ELK システムに入力され、その後の処理はほぼ同じです。

std シリーズのログは Linux モデルに属しているため、Docker データ ディレクトリから均一に収集できます。 1 つのデプロイメント方法は、DaemonSet を使用して Fluentd をデプロイし、hostPath をマウントすることです。

ファイル形式のログは少し複雑です。 NFS/CephFS などの分散ストレージは、ログの保存には絶対に適していません。 emptyDir の形式でディレクトリ共有を実装し、共有ディレクトリ内のログ ファイルを収集して ELK システムに追加するために、Filebeat サイドカーを追加します。

継続的デリバリーとの接続方法

ここでは、継続的デリバリー展開のソリューションに焦点を当てます。 Kubernetes のデプロイメントは、基本的に、さまざまな種類のリソース オブジェクトを YAML 形式で適用することです。自社開発ソリューションとオープンソース ソリューションの間で、デプロイメント フェーズでの継続的デリバリーと Kubernetes 間の通信ブリッジとして Helm を選択しました。 Helm を使用すると、デプロイメント構成を JSON オブジェクトに変換し、標準化されたデプロイメント テンプレートを追加して、デプロイメントの標準化を実現できます。同時に、リソース状態の監視やアプリケーション管理などの機能も搭載されています。

toBサービスとしては、サービス自体の可用性やパフォーマンスに注力するだけでなく、エンドユーザーエクスペリエンスの次元から自己点検・改善を行う必要があります。たとえば、公式の Kubernetes ベンチマーク ツールでは平均 Pod 起動時間について言及されていますが、プロジェクトでは平均 Pod 準備時間の方が重視されており、プローブの結果はプロジェクトの依存関係、データベース、その他の要因によって影響を受けます。特定のプロジェクトでは、多くの値が安定しており、アラーム システムでいくつかの統計処理を実行できます。

サイドカーを正しく追加する方法

前のログの章では、Filebeat Sidecar を使用してログを収集することについて説明しました。また、継続的デリバリーのドッキング プロセスでは、テンプレートを使用してプロジェクトの YAML ファイルを生成することについて説明しました。つまり、ログ サイドカー コンテナーはプロジェクトのデプロイメント構成に反映され、プロジェクトと結合される必要があります。これにより、非常に複雑になり、ログ システムの構成変更プロセスが非常に複雑になります。結局のところ、安定したプロジェクトでは通常、デプロイメント構成は更新されず、ログ記録システムは常に古いバージョンのルール ファイルと互換性がある必要があります。したがって、ログ構成をプロジェクト構成から分離する方法が必要です。

私たちが見つけた解決策は、Kubernetes の動的アドミッション制御 (Mutating Admission Webhook) を使用してサイドカー インジェクションを実装することです。このメカニズムにより、操作 (追加、削除、変更) が etcd に同期される前に、すべてのリソースが Webhook を要求します。 Webhook は、通過または拒否 (allow/reject) したり、JSON パッチで応答してオブジェクトの一部のリソースを変更したりできます。

実際、デフォルトで定義した Pod にデフォルトのサービス アカウントが挿入されることがよくあります。これは、Kubernetes に組み込まれた Admission の結果です。非常に人気のある Istio は、各 Pod のネットワーク ルールを変更してトラフィックをハイジャックします。また、このメカニズムを通じて init-container が挿入され、これによって Pod 内の iptables が変更され、これを実現します。

この仕組みにより、hostPort、hostPath、probe の仕様に対してもセキュリティ監査を実行できるようになり、想像の余地が大きく広がると言えます。リスクの点は、Webhook が安定していて信頼性が高くなければならず、長い遅延が問題にならないことです。 1.14 以降では timeoutSeconds が提供されますが、適用できないパッチが返された場合、リソースの作成は失敗します。

ログ適用シナリオでは、Pod オブジェクトの Create アクションを登録しました。このプロジェクトでは、アノテーションを通じていくつかの簡単な構成を渡すだけで、カスタマイズされた Filebeat Sidecar が自動的に生成されるため、非常にわかりやすく便利です。

カスタム PodIP を実装する方法

Kubernetes で Pod が作成されるたびに、新しい IP アドレスが割り当てられます。コミュニティは、ユーザーがサービス + DNS メカニズムを使用して通信を実現できることを期待しています。しかし、実際には、いくつかの基本コンポーネントのコンテナ化プロセス中に、ソフトウェアの互換性のため、一部のビジネス コンテナの IP アドレスが固定され、再起動によって変更されないことを期待しています。

ここでは、安定した IP の使用を説明するために Redis を例に挙げます。

Redis クラスター モードでは、「cluster meet」コマンドは IP 形式のみをサポートし、ドメイン名解決の構成はサポートしません。コミュニティ内の誰かがこの問題を提起しましたが、却下されました。 Redis クラスター内の任意のノードの IP 変更は Redis クラスター内で自動的に認識されます (インスタンス ID は変更されないため) が、予期しない状況によりすべての Redis クラスター ノードが同時に再起動すると、クラスター内のノードは互いを見つけることができません。この場合、ノードが再び互いを見つけるには、運用および保守スタッフによる手動介入が必要になります。さらに、IP の変更により、キャッシュを持つ Redis クライアントでもエラーが発生します。

Kubernetes では、サービス関連のリソースは kube-proxy によって管理され、主に iptables または IPVS ルールに反映されますが、PodIP は CNI によって割り当てられ、具体的には eth-pair とルーティング テーブルに反映されます。 CNI プラグインとして Calico を選択し、cni.projectcalico.org/ipAddrs アノテーションを通じて予想される IP を Calico に渡しました。

CNI の二次開発を行って独自に IPAM を実装する場合と比較すると、この方法の開発コストは低くなります。

具体的な実装としては、親オブジェクトリソースのテンプレートを介して Pod が作成されるため、テンプレート内の各 Pod のアノテーションをカスタマイズすることはできません。そのため、sts リソース内のアノテーションをカスタマイズして IP のグループを渡し、その後 Pod の作成をハイジャックして、シーケンス番号に従って順番に Pod にアノテーションを追加し、Calico の指定された PodIP 機能をアクティブにするなど、動的アクセス メカニズムを介して実装します。

ここで注目すべき点は、IP 固定化機能を実装した後、一部のマイクロサービス チームもこの機能を使用したいと考えていることです。彼らが解決したい問題点は、コンテナがリリースされた後も登録センターが古い PodIP を保持し続けるという問題です。これは IP の固定化には適していません。

• 理由 1: ほとんどの Web プロジェクトはデプロイメントを使用してリリースされます。 RS ステージと Pod ステージでは、識別およびソートできないランダムな文字列が podName に追加されます。実際、STS リソースに対しては固定 IP のソリューションのみを公開しています。
• 理由 2: マイクロサービス アプリケーションは、SIGINT や SIGTERM などのシグナルを監視し、ポッド終了時のGracePeriodSeconds で登録センターへの登録解除を実装する必要があります。

タスクのスケジュール

当社の従来の営業担当者の中には、プロセス管理が比較的不足している PHP をまだ使用している人もいます。物理マシン環境では、多くのスケジュールタスクを cronjob を利用して完了する必要があります。一部の PHP プロジェクトが初めてコンテナにデプロイされたとき、Kubernetes が提供する cronjob メカニズムを使用しました。しかし、このメカニズムにはいくつかの問題がありました。

• ELK システムによって収集されたポッド実行ログは直感的ではありません。
• コードを更新した後、プル コードが原因でノード上の Pod の最初の起動が遅延されます。
• 起動は手動では実行できません。
• 間隔が短い Cron では、クラスター Pod の合計数が大幅に増加し、管理ノードへの負荷が増加します。

最後に、オープンソースの goCron ソリューションを使用して、プロジェクトにタスク固有のデプロイメントを展開し、タスクを開始および停止し、gRPC 経由でログを送信することを選択しました。

オープンソースの goCron ソリューションでは、Server ロールが Node ロールへのリクエストを開始しますが、各 Node コンテナに Ingress または NodePort の公開を装備することは不可能であることに注意してください。

二次開発では、gRPC プロトパラメータにターゲットフィールドを追加しました。つまり、サーバー ロールは集中的にデプロイされ、各コンテナー オーケストレーション クラスターはトランジットとしてエージェント ロールをデプロイし、最終的に SVC を介してノード ロールに到達します。

クラスターイベント監視

問題をトラブルシューティングする場合、通常、最初に行うことは、関連するリソースを記述し、イベントを確認することです。ただし、実際には、イベントはデフォルトで 1 時間しか存在できません。 kube-apiserver には、etcd のイベントの保持期間を定義するパラメーターがあります: event-ttl イベントを保持する時間。 (デフォルトは1時間0分0秒)。

1 時間かかる主な理由は、大規模クラスターにおける etcd のパフォーマンスボトルネックです。ただし、小規模なクラスターの場合でも、この値を 24 時間以上に調整することはお勧めしません。つまり、夜中にクラスター内でイベントが発生した場合、日中に出勤すると、再起動カウンターが +1 になったり、オブジェクトの生存時間がゼロにリセットされたりすることしか確認できず、関連する情報が見つからないことになります。

そのため、二次開発の後、すべてのクラスターにイベント収集ミドルウェアを展開しました。このミドルウェアは、ns 内のすべての ev を監視し、それらを ES に送信し、いくつかの簡単な集計を実行し、メトリックの形式で prom に公開します。このツールは運用チームに好評で、徐々にクラスターの健全性の重要なバロメーターになってきました。

コンテナ内の時間シミュレーションとシステムパラメータシミュレーション

コンテナ化と仮想化の最大の違いは、コンテナと物理マシンがカーネルを共有し、プロセスのスケジューリング、ネットワーク、IO などの機能を実装し、名前空間と CGroup を通じて分離を実現することです。しかし、これらの分離では、時間、CPU、メモリなどの情報が分離内に存在しないため、問題が発生します。

まず、CPUとメモリを見てみましょう。コンテナ内で /proc/cpuinfo または /proc/meminfo を印刷すると、物理マシンのコア数とメモリ サイズが取得されます。しかし、実際には、コンテナにはリソース制限があり、コンテナ環境内のプロセスが誤解され、期待される最適化がマイナスの最適化に変わってしまうことがあります。スレッド数や GC のデフォルト設定など。

この問題には 3 つの解決策があります。

• Java/Golang/Node を起動するときに最大リソース制限を手動で渡します。
• Java 8u131+ および Java 9+ では -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap が追加されます。 Java 8u191+ および Java 10+ では、UseContainerSupport がデフォルトで有効になっているため、操作は必要ありません。ただし、これらの方法では、/proc から直接読み取られたコンテンツや、プロセス内の top、free -m、uptime などのコマンドから呼び出されたコンテンツを修正することはできません。
• 関連するカーネルパラメータを書き換えます。これはすべてのプログラムに影響します。

最初の 2 つのソリューションは非常に侵襲的であるため、3 番目のソリューションを選択し、関連するカーネル パラメータを書き換え、LXCFS を使用して実装し、hostPath を使用して yaml にマウントしました。

LXCFS に関しては、ここではキーワードが 1 つだけ提供されており、関連する情報を検索できます。

CPU/メモリと同様に、稼働時間、ディスク統計、スワップなどの情報もあります。書き換え後はコンテナ内のtop、free -m、uptimeなどのコマンドが正しく表示されるようになります。

コンテナ内のいわゆる CPU 制限は、排他的なコアをバインドするのではなく、使用時間を制限することに注意してください。たとえば、4 つのコアを持つ物理マシンでは、4 つのスレッドを並列に実行できます。 32 個のコアを持つホスト マシンでは、4 個のコアに制限されたコンテナーでも 32 個のスレッドを並列に実行できますが、各コアが占有できるのはタイム スライスの 1/8 だけです。

コンテナ内の時間のシミュレーションに関しては、libfaketime を使用し、プロセスの開始時に LD_PRELOAD および FAKETIME 環境変数を追加しました。

最後に、Kubernetes の基礎である etcd について説明します。 api-server が利用できない場合は、etcd からデータを直接読み取ることが最後の手段になります。しかし、etcdに保存されているデータは、あるバージョン以降、Protobufでコンパイルされたバイナリデータになってしまいました。取り出した後は肉眼では確認できません。

私は通常、オープンソース プロジェクト Auger を使用して、パイプラインを通じて etcd のコンテンツを YAML テキストに復元します。

私の理解では、Kubernetes はコンテナ オーケストレーション システムであり、クラウド ネイティブのマイクロサービス アーキテクチャです。

>>>>

質疑応答

Q1 : 実装プロセスでは、必然的に、これまでの開発、テスト、運用、保守のプロセスに変更が伴います。組織や関係者は調整に直面することになる。御社ではこの部分の作業をどのように進めましたか?どのような落とし穴に遭遇しましたか? また、それをどのように解決しましたか?

A: これを一言で説明するのは難しいです。人間の問題は解決するのが最も難しい。テクノロジーで解決できるものは問題ではありません。答えを言わなければならないとすれば、早い段階で社内のあらゆるリンクを公開し、上司にこの件を承認してもらい、行政命令で押し通すことが非常に重要です。そうしないと、誰も製品を使用しなくなり、時間の無駄になってしまいます。完璧だと思うものをリリースするのではなく、ユーザーの中からモルモットを見つけて繰り返し試す必要があります。

Q2 : Java コンテナを瞬時に起動すると、クラスター全体の CPU が枯渇します。 Java CPU の起動時に CPU リソース競合の問題を解決するにはどうすればよいでしょうか?

A: 以前にもこの問題に遭遇しましたが、カーネルを 4.19 にアップグレードした後は発生しなくなりました。カーネルのアップグレードを通じて、多くのメモリ枯渇や CPU 爆発の問題を解決しました。

Q3 : ログ プラットフォームは、grep -C のようにコンテキストを検索できないという問題をどのように解決できますか?ログ プラットフォームはどのようにしてログ形式を標準化できるのでしょうか?

A: ログ プラットフォームの開発方法によって異なります。一般的に言えば、これは問題ではありません。

ログ形式の標準化にはビジネスとの協力が必要です。実際、ログプラットフォームは一般的にミドルオフィス部門の別システムであり、別途開発する必要があります。

Q4 : コンテナ化は開発ニーズをどのように調整しますか?たとえば、開発の学習コスト、ローカルデバッグと再現可能な問題のオンサイト保持、開発者に優しいトラブルシューティング方法などです。

A: これはやはり人間の問題です。多くのビジネス開発者は学ぶことを嫌がり、新しいことを受け入れず、一つのことに目がくらんでコンテナを否定します。本当に私たちには何もできないのです。人々から妥協点を探しましょう。誰のエネルギーにも限りがあり、一度このような状況に陥ると抜け出すのは困難です。公開研修、講演、現地サポート、事業部門で状況を理解する人材の育成など。

Q5 : オンライン Kubernetes クラスターはバイナリ、kubeadm など、どのようにデプロイされますか?展開アーキテクチャとは何ですか?

A: 証明書の生成とさまざまな Kubernetes コンポーネントの機能を理解している場合は、バイナリ ファイルから始めることをお勧めします。エンタープライズ環境では、Ansible などのスクリプトを自分で作成できます。 kubeadm メンテナンスは通常、オンライン環境には適していません。

Q6 : 私は7年の経験を持つJavaエンジニアです。コンテナ関連の分野に切り替えたい。コンテナ開発エンジニアになるための要件は何ですか?

A: Linux について十分に理解し、JVM に依存しないシステム知識を習得する必要があります。また、コンテナの言語は基本的にGoで、マイクロサービスセットもJavaと大差なく、Protobufにも精通しています。

Q7 : ログサイドカーの存続がビジネスコンテナに影響を与えないようにするにはどうすればよいですか?

A: サイドカー コンテナとビジネス コンテナは、もともと互いに分離されています。現在、Kubernetes 1.10 以降では、Pod 内のネットワークのみが共有され、デフォルトでは pid は共有されません。影響はないはずです。

Q8 : サイドカー方式でログを収集する場合、遅延が発生し、特にログが失われます。これをどう解決すればいいでしょうか?

A: Filebeat の収集時間を短縮する解決策はないと思います。または、gracefultime に記事を書いて、Filebeat をもう少し長く存続させてください。