Kubernetes を簡単に学ぶにはどうすればいいですか?

[[324142]]

この記事では、Kubernetes に関する Alibaba の技術専門家の見解や意見を共有し、Kubernetes の学習方法に関する提案を行い、最後に Kubernetes クラスターの問題のトラブルシューティングの経験を共有します。

Kubernetes とは何ですか?

Kubernetes とは何かを見てみましょう。このパートでは、4つの視点から私の見解を皆さんと共有したいと思います。

1 将来はどうなるのでしょうか?

これは、将来のほとんどの企業のバックエンド IT インフラストラクチャのアーキテクチャを示す図です。簡単に言えば、将来的にはすべての企業の IT インフラストラクチャがクラウド上に展開されることになります。ユーザーは、基盤となるクラウド リソースを Kubernetes に基づく特定のクラスター ユニットに分割し、さまざまなビジネスで使用できるようになります。ビジネス マイクロサービスがより洗練されるにつれて、サービス メッシュなどのサービス ガバナンス ロジックは、下の 2 つのレイヤーと同じになり、インフラストラクチャの一部になります。

現在、アリババの事業のほぼすべてがクラウド上で運営されています。ビジネスの約半分が、独自にカスタマイズされた Kubernetes クラスターに移行されました。さらに、私の知る限り、Alibaba は今年、Kubernetes クラスターをベースとしたビジネス展開を 100% 完了する予定です。

サービスグリッドに関しては、アント・ファイナンシャルなどアリババの一部部門がすでにオンラインビジネスで利用している。 Ant の生徒の共有を通じて、彼らの練習プロセスについて学ぶことができます。

この写真の見解は少し絶対的かもしれませんが、現在の傾向は非常に明白です。したがって、今後数年のうちに、Kubernetes は間違いなく Linux のようなユビキタスなクラスター オペレーティング システムになるでしょう。

2 Kubernetesとオペレーティングシステム

これは、従来のオペレーティング システムと Kubernetes の比較表です。ご存知のとおり、Linux や Windows などの従来のオペレーティング システムの役割は、基盤となるハードウェアの抽象化レイヤーです。メモリや CPU などのコンピューターのハードウェアを下位レベルで管理し、基盤となるハードウェアをいくつかの使いやすいインターフェイスに抽象化し、これらのインターフェイスを使用して上位のアプリケーション層にサポートを提供します。

Kubernetes に関しては、オペレーティング システムとして理解することもできます。簡単に言えば、このオペレーティング システムも抽象化レイヤーです。管理対象となるハードウェアは、メモリや CPU などのハードウェアではなく、複数のコンピューターのクラスターです。これらのコンピュータ自体は、独自のオペレーティング システムとハードウェアを備えた通常のスタンドアロン システムです。 Kubernetes はこれらのコンピューターをリソース プールとして管理し、アプリケーションのサポートを提供します。

ここで紹介するアプリケーションは、すべてコンテナ化されたアプリケーションであるという点で非常に特殊です。コンテナに慣れていない場合は、これらのアプリケーションを単純にアプリケーション インストール ファイルと考えることができます。インストール ファイルには、libc などのすべての依存ライブラリがパッケージ化されています。これらのアプリケーションは、実行するために基盤となるオペレーティング システムのライブラリに依存しません。

3 KubernetesとGoogleのオペレーションの解読

上の写真では、左側に Kubernetes クラスターがあり、右側には非常に有名な本「Google Operations Decoded」があります。この本は多くの方が読んだと思いますし、現在多くの企業がこの本の手法を実践しています。障害管理、運用保守スケジュールなどを含みます。

Kubernetes とこの本の関係は、剣術と気功の関係に例えることができます。ここで『微笑む誇り高き放浪者』を見た人は何人いるだろうか。 『微笑む誇り高き放浪者』の華山宗は、気宗と剣宗の 2 つの派閥に分かれています。気派は気功の修行に重点を置き、剣派は剣術の精巧さを重視します。実際、斉宗と堅宗の分裂は、華山宗の二人の弟子がひそかに『ひまわり教本』を学んだことによって引き起こされた。それぞれがその一部を暗記し、やがて意見の相違から二つの宗派に分裂した。

Kubernetes は実は、本書で解説する運用・保守方法の対象である、Google のクラスタ自動化管理・スケジューリング システムである Borg から生まれたものです。ボーグシステムと、この本で説明されているさまざまな運用および保守方法は、同じものの 2 つの側面として考えることができます。企業が SRE 職を開設するなど、運用および保守の方法のみを学習し、この方法で管理されるシステムを理解していない場合、実際には Sunflower マニュアルを学習しているものの、その一部しか学習していないことになります。

Borg は Google の社内システムなので、私たち一般の人には見えませんが、Kubernetes は基本的に、クラスター自動化管理における Borg のコア概念の一部を継承しています。したがって、この本を読んで役に立ったと感じたり、この本の方法を実践したりしている場合は、Kubernetes について深く理解しているはずです。

4 技術進化の歴史

初期の頃、Web サイトのバックエンドを作成していたときは、すべてのモジュールを 1 つの実行可能ファイルに配置するだけで済む場合もありました。上の図に示すように、UI、データ、ビジネスの 3 つのモジュールがあります。これら 3 つのモジュールは 1 つの実行可能ファイルにコンパイルされ、サーバー上で実行されます。

しかし、業務量が大幅に増加したため、サーバー構成をアップグレードして容量を拡張する手段がありませんでした。現時点ではマイクロサービスを実行する必要があります。

マイクロサービスは、モノリシック アプリケーションを結合度の低い小さなアプリケーションに分割します。これらのアプリケーションはそれぞれ特定の業務を担当し、各アプリケーション インスタンスはサーバーを排他的に占有し、ネットワークを介して相互に呼び出します。

ここで重要な点は、インスタンスの数を増やすことで、小さなアプリケーションを水平方向に拡張できることです。これにより、単一のサーバーを拡張できないという問題が解決されます。

マイクロサービス化後に発生する問題は、1 つのインスタンスが 1 つのサーバーを占有することです。この展開方法は、実際にはリソースの重大な浪費を引き起こします。この時点で、当然、これらのインスタンスを基盤となるサーバーにデプロイすることを考えます。

ただし、コロケーションによって 2 つの新しい問題が発生します。 1 つは依存ライブラリの互換性です。これらのアプリケーションが依存するライブラリ ファイルのバージョンは完全に異なる場合があり、同じオペレーティング システムにインストールされていると問題が発生する可能性があります。もう 1 つの問題は、アプリケーションのスケジューリングとクラスター リソースの管理です。

たとえば、新しいアプリケーションを作成する場合、アプリケーションがどのサーバーにスケジュールされるか、スケジュール後に十分なリソースがあるかどうかを考慮する必要があります。

ここでの依存ライブラリの互換性の問題は、コンテナ化によって解決されます。つまり、各アプリケーションには独自の依存ライブラリが付属し、他のアプリケーションとカーネルのみを共有します。スケジューリングとリソース管理は、Kubernetes が解決する問題です。

ちなみに、クラスターにデプロイされているアプリケーションの数が多すぎて、アプリケーション間の関係が複雑なため、リクエストの応答が遅いなどの問題をトラブルシューティングできない場合があります。したがって、サービス メッシュなどのサービス ガバナンス テクノロジーは間違いなく次のトレンドになるでしょう。

2. Kubernetes を学ぶにはどうすればいいですか?

1 Kubernetesの学習の難しさ

一般的に、Kubernetes の敷居が高く、習得が難しい理由は、カーネル、仮想化、コンテナ、ソフトウェア定義ネットワーク (SDN)、ストレージ、セキュリティ、さらには信頼できるコンピューティングなど、そのテクノロジー スタックが非常に深いためです。まさにフルスタック技術と言えます。

同時に、クラウド環境での Kubernetes の実装には、間違いなく多くのクラウド製品が関与することになります。たとえば、Alibaba Cloud では、Kubernetes クラスターは ECS クラウド サーバー、VPC 仮想ネットワーク、負荷分散、セキュリティ グループ、ログ サービス、クラウド モニタリング、Ahas や Arms などのミドルウェア製品、サービス メッシュ、エラスティック スケーリング、その他多くのクラウド製品を使用します。

最後に、Kubernetes は汎用コンピューティング プラットフォームであるため、データベースなどのさまざまなビジネス シナリオで使用できます。私の知る限り、当社の PolarDB Box オールインワンマシンは Kubernetes をベースに構築される予定です。エッジ コンピューティング、機械学習、ストリーム コンピューティングなどもあります。

2. 理解し、実行し、考える

私の個人的な経験から言うと、Kubernetes を学ぶには、理解、実践、思考という 3 つの側面を把握する必要があります。

特にテクノロジーの進化の歴史やテクノロジーの全体像を理解することは、実はとても重要です。

chrootコマンドからコンテナ技術がどのように発展してきたのか、技術進化の背後にはどのような課題があるのか​​など、さまざまな技術の進化の歴史を知る必要があります。テクノロジーの進化の歴史と発展の原動力を知ることによってのみ、テクノロジーの将来の方向性について自ら判断を下すことができます。

同時に、技術的な全体像を理解する必要があります。 Kubernetes の場合、コンテナ、CICD、マイクロサービス、サービス メッシュなどを含むクラウド ネイティブ テクノロジー スタック全体を理解し、テクノロジー スタック全体における Kubernetes の位置づけを知る必要があります。

Kubernetes テクノロジーを学習する際には、これらの基本的な背景知識に加えて、実践的な練習が非常に重要です。

多くのエンジニアと協力して問題を解決してきた経験から言うと、多くの人は実際には技術的な詳細を深く掘り下げません。私たちはよく、エンジニアには 2 つのタイプがある、と冗談を言います。1 つは検索エンジニア、もう 1 つは研究エンジニアです。多くのエンジニアは問題に遭遇し、Google で検索します。答えが見つからない場合は、直接作業指示書を開きます。これでは、技術を深く理解することが難しくなります。

最後に、どのように考えるか、どのように要約するかについてです。私の個人的な経験では、技術的な詳細を理解した後、その詳細の背後にもっと本質的な何かがあるかどうかを常に自問する必要があると思います。つまり、複雑な詳細を単純化して、共通のパターンを見つける必要があります。

以下では、2つの例を使って上記の方法を詳しく説明します。

3 冷蔵庫を使ってクラスターコントローラーを理解する

最初の例は、クラスター コントローラーに関するものです。 Kubernetes を学ぶときには、宣言型 API、Operator、エンドステート指向設計など、いくつかの概念について耳にすることになります。これらの概念は、本質的にはコントローラー モードという 1 つの事柄について説明しています。

Kubernetes コントローラーをどのように理解すればよいでしょうか?上の図は、典型的な Kubernetes アーキテクチャ図です。この図は、クラスター制御ノードと作業ノードを示しています。制御ノードには、中央データベース、API サーバー、スケジューラ、およびいくつかのコントローラーがあります。

中央データベースはクラスターのコア ストレージ システムであり、API サーバーはクラスターの制御ポータルであり、スケジューラはリソースが豊富なノードにアプリケーションをスケジュールする役割を担います。ここで焦点となるのはコントローラーです。コントローラーの役割は、「夢を実現する」という一言で要約できます。そういう意味では、私はコントローラーの役割を果たすことが多いです。もし娘が「パパ、アイスクリームが食べたい」と言ったら、娘はクラスターのユーザーであり、私は娘の願いを叶える責任者、つまりコントローラーです。

制御ノードに加えて、Kubernetes クラスターには多くの作業ノードがあり、これらのノードは Kubelet と Proxy という 2 つのエージェントとともにデプロイされます。 Kubelet は、ノード上のアプリケーションの起動と停止を含むワーカーノードの管理を担当します。プロキシは、サービス定義を特定の iptables または ipvs ルールに実装する役割を担います。ここでのサービスの概念は、簡単に言えば、iptables または ipvs を使用して負荷分散を実現することです。

最初の画像をコントローラーの視点から見ると、2 番目の画像になります。つまり、クラスターには実際にはデータベース、クラスター エントリ、および多数のコントローラーが含まれます。スケジューラ、Kubelet、Proxy などのこれらのコンポーネントは、実際にはクラスター内のさまざまなリソースの定義を常に監視し、これらの定義をコンテナの起動や iptables 構成などの特定の構成に実装します。

コントローラーの観点から Kubernetes を観察すると、Kubernetes の最も基本的な原則が実際にわかります。コントローラーモードです。

実際、コントローラー モードは私たちの生活のいたるところに存在します。ここでは冷蔵庫を例に挙げます。冷蔵庫を制御する場合、冷蔵庫内の冷却システムや照明システムを直接制御するわけではありません。冷蔵庫を開けると内部のライトが点灯し、希望の温度を設定したら、家にいないときでも冷蔵システムが常にその温度を維持します。これはコントローラーモードが動作しているためです。

4 名前空間を削除できないのはなぜですか?

2 番目の例として、実際の問題のトラブルシューティング プロセスを見てみましょう。問題は、名前空間を削除できないことです。問題は少し複雑なので、順を追って見ていきましょう。

名前空間は、ここの最初の図のように、Kubernetes クラスターのコンテナ メカニズムです。このボックスは、消しゴムと鉛筆が含まれる名前空間です。

名前空間を作成または削除できます。名前空間を削除できないという問題が頻繁に発生します。この問題が発生した場合、どのようにトラブルシューティングすればよいかわかりません。考えられる最初のステップは、API サーバーがこの削除操作をどのように処理するかを調べることです。これは、API サーバーがクラスターの管理の入り口であるためです。

API サーバー自体はアプリケーションです。このアプリケーションのログ レベルを向上させることで、その操作プロセスをより深く理解することができます。この問題では、API サーバーが削除コマンドを受信しますが、その他の情報がないことがわかります。

ここでは、名前空間の削除プロセスを理解する必要があります。ユーザーが名前空間を削除すると、名前空間は直接削除されるのではなく、「削除中」状態に変更されます。この時点で、名前空間コントローラーはこのステータスを確認します。

名前空間コントローラーの動作を理解するために、コントローラーのログ記録レベルを上げて詳細なログを表示することもできます。この時点で、コントローラーがすべての API グループを取得しようとしていることがわかります。

ここでは2つのことを理解する必要があります。 1 つは、名前空間が削除されると、コントローラーが API グループを取得する理由です。 2 番目は、API グループ化とは正確には何なのかということです。

まず、2 番目の質問「API グループ化とは一体何でしょうか?」について考えてみましょう。簡単に言えば、API グループ化はクラスター API の分類メカニズムです。たとえば、ネットワーク関連の API はネットワーク グループにあります。ネットワーク API グループ化を通じて作成されたリソースは、このグループに属します。

では、なぜ名前空間コントローラーが API グループを取得するのでしょうか?名前空間を削除する場合、コントローラーは名前空間内のすべてのリソースを削除する必要があるためです。この操作は、フォルダーを削除する操作とは異なります。フォルダーを削除すると、フォルダー内のすべてのファイルが削除されます。

名前空間にはリソースが含まれます。実際、これらのリソースは、インデックスのようなメカニズムを使用してこの名前空間を指します。クラスターは、すべての API グループを走査し、この名前空間を指すすべてのリソースを見つけて、それらを 1 つずつ削除することしかできません。

API グループをトラバースする操作により、クラスターの API サーバーはその拡張機能と通信できるようになります。これは、API サーバーの拡張機能によっていくつかの API グループ化も実装できるためです。したがって、削除された名前空間にこの拡張機能によって定義されたリソースが含まれているかどうかを確認するには、API サーバーが拡張機能と通信する必要があります。

この時点で、問題は実際には API サーバーとその拡張機能間の通信になります。つまり、リソースの削除の問題はネットワークの問題になります。

Alibaba Cloud の Kubernetes クラスターは、VPC ネットワーク (仮想ローカル エリア ネットワーク) 上に作成されます。デフォルトでは、VPC は VPC ネットワーク セグメント内のアドレスのみを認識し、クラスター内のコンテナは通常、VPC とは異なるネットワーク セグメントを使用します。たとえば、VPC がネットワーク セグメント 172 を使用する場合、コンテナはネットワーク セグメント 192 を使用する可能性があります。

VPC ルーティング テーブルにコンテナ ネットワーク セグメントのルーティング項目を追加することで、コンテナが VPC ネットワークを使用して通信できるようになります。

右下の図には 2 つのクラスター ノードがあり、それらのアドレスはネットワーク セグメント 172 にあります。ルーティング テーブルにネットワーク セグメント 192 のルーティング エントリを追加すると、VPC はコンテナーに送信されたデータを正しいノードに転送し、そのノードはデータを特定のコンテナーに送信します。

ここでのルーティング項目は、ノードがクラスターに参加したときにルーティング コントローラーによって追加されます。ルーティング コントローラは、新しいノードがクラスターに参加したことを検出すると、すぐに応答し、ルーティング テーブルにルーティング エントリを追加します。

ルーティング エントリを追加する操作は、実際には VPC 上の操作です。この操作は、確実に認証が必要となるオフライン マシンがクラウド リソースにアクセスするのと似ているため、特定の認証が必要です。

ここでルーティング コントローラによって使用される認証は、ルーティング コントローラが RAM ロールの形式で配置されているクラスター ノードにバインドされます。この RAM ロールには通常、一連の承認ルールがあります。

最後に確認したところ、ユーザーが承認ルールを変更したことがこの問題の原因であることがわかりました。