Kubernetes の使用 3 年間で何を学んだか?

2017 年に、私たちは最初の Kubernetes クラスター バージョン 1.9.4 を構築しました。クラスターは 2 つあり、1 つはベアメタル RHEL VM で実行され、もう 1 つは AWS EC2 を使用しています。現在、当社の Kubernetes インフラストラクチャ チームは、複数のデータ センターにまたがる 400 台を超える仮想マシンを保有しています。このプラットフォームは、可用性が高くミッションクリティカルなソフトウェア アプリケーションとシステムをホストし、約 400 万台のアクティブ マシンを実行する大規模なリアルタイム ネットワークを管理します。

[[346038]]

Kubernetes は私たちの生活を楽にしますが、プロセスは難しく、パラダイムシフトが必要です。スキルやツールだけでなく、デザインやアイデアも全面的に見直す必要があります。私たちは多くの新しいテクノロジーを習得し、チームとインフラストラクチャを大幅に拡張する必要がありました。

Kubernetes の使用に関する過去 3 年間を振り返って、次のような重要な教訓が得られました。

1. アプリの奇妙なケース

マイクロサービスとコンテナ化に関しては、主にメモリ管理が不十分なため、エンジニアは Java を使用しない傾向があります。しかし、Java はもはや昔のようなものではなく、コンテナの適応性は長年にわたって向上してきました。結局のところ、Apache Kafka や Elasticsearch など、ほとんどのシステムは Java で実行されます。

2017 年から 2018 年にかけて、Java 8 で実行されたアプリケーションはごくわずかでした。これらのアプリケーションは Docker メモリ システムに適合するのが難しいことが多く、ヒープ メモリの問題や異常なガベージ コレクションの傾向により簡単にクラッシュする可能性があります。これは、コンテナ化テクノロジーの中核である Linux cgroup および名前空間に Java 仮想マシンが準拠できないことが原因です。

しかし、Oracle はそれ以来、Java コンテナ化の適応性を改善し続けています。 Java 8 のその後のパッチでは、これらの問題に対処するために実験的な Java 仮想マシン フラグも導入されました。

• XX:+実験的VMオプションのロック解除
• XX:+ヒープのCグループメモリ制限を使用する

しかし、Java の評判は依然として悪いです。同等の Python や Go と比較すると、Java はメモリを消費し、起動速度が遅くなります。これは主に、Java 仮想マシンのメモリ管理とクラス ローダーによって発生します。

ここで、Java を選択する必要がある場合は、バージョン 11 以上であることを確認し、余裕を持たせるために Kubernetes メモリを Java VM 最大ヒープ メモリ ( -Xmx ) より 1 GB 多く設定します。つまり、JVM が 8 GB のヒープ メモリを使用する場合、アプリケーションの Kubernetes リソース制限は 9 GB になります。そうすれば人生はもっと良くなるでしょう。

[[346039]]

画像ソース: unsplash

2. Kubernetesライフサイクルのアップグレード

Kubernetes のライフサイクル管理は、特にベアメタルまたは VM で構築されたクラスターでは、アップグレードや機能拡張など、非常に複雑です。アップグレード時に、新しいクラスターを構築する最も簡単な方法は、最新バージョンを使用し、古いバージョンから新しいバージョンにワークロードを移行することであることがわかりました。モデル内でアップグレードするための努力と計画は、まったく価値がありません。

Kubernetes には、アップグレードと同期する必要がある複数のランタイム プラグインがあります。 Docker、Calico、Flannel などの CNI プラグインは、適切に動作させるためには慎重に組み合わせる必要があります。 Kubespray、Kubeone、Kops、Kubeaws など、実行を容易にするプロジェクトもありますが、いずれも欠点があります。

RHEL VM 上で Kubespray を使用してクラスターをセットアップしました。 Kubespray には、新しいノードの設定、追加、削除、およびバージョン アップグレードに関するガイドがあり、基本的に Kubernetes を使用して作成するために必要なすべての内容が網羅されています。ただし、アップグレード マニュアルには、変更が小さい場合でもどのバージョンも無視しないように、つまり、ターゲット バージョンを使用する前にすべての中間バージョンを更新するように注意を促す免責事項が含まれています。

重要なのは、Kubernetes の使用を計画している場合、またはすでに使用している場合は、ライフサイクル アクティビティと、ソリューションがこれらの問題にどのように対処するかについて考えることです。これを使用してクラスターを構築および実行するのは比較的簡単ですが、ライフサイクルのメンテナンスは依然として多くの可動部分がある新しい領域です。

3. ビルドとデプロイ

[[346040]]

画像ソース: unsplash

ビルドおよびデプロイメント パイプライン全体を再設計する準備をしてください。私たちのビルド プロセスとデプロイメントは、Jenkins パイプラインの大規模な再編成だけでなく、Helm などの新しいツール、新しい git プロセスとビルドのオーケストレーション、Docker イメージのタグ付け、Helm デプロイメント チャートのバージョン管理など、Kubernetes への完全な変革を経る必要がありました。

コードを保守する必要があるだけでなく、Kubernetes デプロイメント ファイル、Docker ファイル、Docker イメージ、Helm チャートを保守し、それらをリンクする方法を考案するための戦略も必要です。

数回の反復を経て、アプリケーション コードとその Helm チャートを別々の Git リポジトリに配置し、個別にバージョン管理できるようにするという設計にたどり着きました。 (セマンティックバージョン番号)

次に、アプリケーション バージョンとともにグラフ バージョンのマップを保存し、それを使用してリリースを追跡します。たとえば、app-1.2.0 を charts-1.1.0 と一緒にデプロイします。 Helm 値ファイルのみを変更する場合は、チャートのパッチ バージョンのみを変更します (たとえば、1.1.0 から 1.1.1 へ)。これらのリリースはすべて、各リポジトリの RELEASE.txt 内のリリース ノートに記載されています。

Apache Kafka や Redis のコードなどのシステム アプリケーションのコードは動作が異なり、それらのコードはビルドも変更もしていません。つまり、Docker タグは Helm チャート バージョン管理の一部にすぎないため、2 つの Git リポジトリは存在しません。 docker タグをアップグレードに変更する場合は、chart タグのメジャー バージョンを増分します。

4. 生存性と準備性プローブ（諸刃の剣）

Kubernetes のライブネス プローブと準備プローブは、システムの問題を自動的にトラブルシューティングするための優れた機能です。障害が発生した場合にコンテナを再起動し、異常なインシデントからトラフィックを迂回させることができます。しかし、特定の障害シナリオでは、プローブは諸刃の剣となり、アプリケーションの起動と回復、特にメッセージング プラットフォームやデータベースなどのステートフル アプリケーションに影響を及ぼす可能性があります。

Kafka システムが被害者です。 replicationFactor が 3、minInSyncReplica が 2 の 3 Broker 3 Zookeeper ステートフル セットを実行していましたが、予期しないシステム障害またはクラッシュによって Kafka が起動したときにこの問題が発生しました。これにより、起動時に破損したインデックスを修復するための追加のスクリプトが実行され、そのプロセスは重大度に応じて 10 ～ 30 分かかることがあります。

完了にかかる時間が長くなると、活性プローブは失敗し続け、Kafka に終了と再起動の信号を送り、その結果、Kafka システムがインデックスを変更して完全に起動できなくなります。

唯一の解決策は、ライブネス プローブ設定で initialDelaySeconds を設定し、コンテナーの起動後にプローブの評価を遅らせることです。しかし、問題は、もちろん具体的な時間を示すのが難しく、回復には 1 時間かかる場合もあるため、時間を計算するための十分な余裕を残す必要があることです。ただし、initialDelaySeconds を増やすほど、Kubernetes が起動に失敗した場合にコンテナを再起動するのに時間がかかるようになるため、速度は遅くなります。

最新バージョンでは、Kubernetes はこの問題を解決するために、3 番目のタイプのプローブである「スタートアップ プローブ」を導入しました。アルファ版は 1.16 から、ベータ版は 1.18 から利用可能。プローブを開始すると、コンテナが起動する前に活性プローブと準備プローブが停止され、アプリケーションが中断されることなく起動することが保証されます。

5. パブリック外部IP

[[346041]]

画像ソース: unsplash

静的な外部 IP を使用してサービスを公開すると、カーネルの接続追跡メカニズムが大幅に損なわれることがわかりました。詳細に計画されなければ、大規模な崩壊が起こるだけです。

クラスターは、Kubernetes 内部ルーティング プロトコルとして CNI および BGP を使用する Calico 上で実行され、エッジ ルーターとペアになっています。 Kubeproxy では、IP テーブル モードを使用します。 Kubernetes には、外部 IP 経由で公開され、1 日に数百万件の接続を処理する大規模なサービスがあります。

すべてのソース ネットワーク アドレス変換 (NAT) とマスカレードはソフトウェア定義ネットワークから発生するため、Kubernetes にはすべての論理フローを追跡するメカニズムが必要です。これを行うには、カーネルの Conntrack および netfilter ツールを使用して静的 IP への外部接続を管理し、それを内部サービス IP に変換してから、ポッド IP に変換します。これはすべて、conntrack テーブルと IP テーブルを通じて実行されます。

しかし、この conntrack テーブルには制限があります。制限に達すると、Kubernetes クラスター (その下の OS カーネルを含む) は新しい接続を受け入れることができなくなります。 RHEL では、次の方法で確認できます。

 $ sysctlnet.netfilter.nf_conntrack_countnet.netfilter.nf_conntrack_maxnet.netfilter.nf_conntrack_count = 167012  
ネット.netfilter.nf_conntrack_max = 262144  

この問題の解決策は、複数のノードをエッジ ルーターに一致させて、静的 IP への着信接続がクラスター全体に広がるようにすることです。したがって、クラスター内に多数の VM がある場合は、累積的に大きな conntrack テーブルを作成して、多数の着信接続を処理できます。

2017 年に初めて使用し始めたとき、この問題は私たちを完全に困惑させました。しかし、2019年にCalicoは「なぜconntrackはもはや友好的でなくなったのか」と題した詳細な調査を発表しました。

Kubernetes は本当に必要ですか?

画像ソース: debian

3年経った今も、私たちは日々新しいことを探求し、学び続けています。この複雑なプラットフォームには、環境の構築と維持にかかる高いオーバーヘッドをはじめ、独自の課題が伴います。これにより、設計、思考、構築の方法が変わり、変化に対応するためにチームは継続的に改善し、拡張する必要があります。

ただし、クラウドで Kubernetes を「サービス」として使用している場合は、「内部ネットワークの CIDR を拡張するにはどうすればよいか」といった、プラットフォームのメンテナンスのオーバーヘッドの多くを削減できます。または「Kubernetes のバージョンをアップグレードするにはどうすればよいですか?」

最初に尋ねるべき質問は、「Kubernetes は本当に必要ですか?」です。これにより、問題を評価し、その解決に Kubernetes が必要かどうかを判断するのに役立ちます。 Kubernetes のアップグレードと変換は安価ではありません。使用事例は、費用を本当に正当化し、プラットフォームを使用する価値があるものでなければなりません。価値があるなら、Kubernetes は生産性を大幅に向上させることができます。

覚えておいてください。テクノロジーをただ使うためだけに使うのは意味がありません。

この記事はWeChatの公開アカウント「Reading the Core」から転載したもので、以下のQRコードからフォローできます。この記事を転載する場合は、Duxinshu の公開アカウントにご連絡ください。