Kubernetes (K8s) の入門

1. Kubernetesとは何ですか

Kubernetesとは何ですか?

        まず第一に、これはコンテナーテクノロジーに基づいた分散アーキテクチャのためのまったく新しい主要なソリューションです。このソリューションはまだ非常に新しいものですが、10 年以上にわたる Google のコンテナ テクノロジーの大規模アプリケーションの経験の重要な成果です。正確に言うと、Kubernetes は、10 年以上秘密にされてきた Google の秘密兵器である Borg のオープンソース バージョンです。Borg は、Google 社内で使用されているよく知られた大規模クラスタ管理システムで、コンテナ テクノロジーに基づいており、リソース管理を自動化し、複数のデータ センターにわたるリソース使用率を最大化することを目的としています。Google は 10 年以上にわたり、Borg システムを通じて多数のアプリケーション クラスタを管理してきました。Googleの従業員は機密保持契約に署名しているため、退職してもBorgの内部設計を公開することはできず、外部の世界はそれについて詳しく知ることができなかった。2015 年 4 月、長い間噂されていた Borg 論文が、Kubernetes の注目度の高まりとともに Google によって初めて公開され、誰もがそれについて詳しく知ることができました。Kubermetes は、前任者である Borg の肩の上に立ち、Borg の過去 10 年間の経験と教訓を吸収したからこそ、オープンソース化されるや否や大ヒットとなり、瞬く間にコンテナ技術の分野を席巻しました。

        第二に、システム設計が Kubermetes の設計思想に従っている場合、ビジネスにほとんど関係のない従来のシステム アーキテクチャの基盤となるコードや機能モジュールはすぐに視界から消えるため、負荷を心配する必要がなくなります。複雑なサービス ガバナンス フレームワークの導入や開発を検討する必要はなくなり、サービス監視モジュールや障害処理モジュールの開発について心配する必要もなくなりました。つまり、Kubernetes が提供するソリューションを使用することで、開発コストを 30% 以上節約できるだけでなく、ビジネス自体にさらに集中できるようになります。また、Kubernetes は強力な自動化メカニズムを提供するため、後段階の運用の難しさを軽減できます。システムの保守・運用コストが大幅に削減されます。

        次に、Kubernetes はオープン開発プラットフォームです。J2EE とは異なり、言語に限定されず、プログラミング インターフェイスも定義されていないため、Java、Go、C++、または Python で記述されたサービスは、問題なく Kubernetes Services にマッピングでき、標準の TCP 通信プロトコルを通過して対話できます。さらに、Kubernetes プラットフォームは既存のプログラミング言語、プログラミング フレームワーク、ミドルウェアに影響を与えないため、既存のシステムを簡単にアップグレードして Kubernetes プラットフォームに移行できます。

        最後に、Kubernetes は完全な分散システム サポート プラットフォームです。Kubermetes には、マルチレベルのセキュリティ保護とアクセス メカニズム、マルチテナント アプリケーション サポート機能、透過的なサービス登録とサービス検出メカニズム、組み込みのインテリジェント ロード バランサー、強力な障害検出と自己修復機能、サービス ローリングなどの完全なクラスター管理機能があります。アップグレードおよびオンライン拡張機能、スケーラブルなリソース自動スケジューリング メカニズム、および複数粒度のリソース クォータ管理機能。同時に、Kubernetes は、開発、展開テスト、運用および保守の監視を含むあらゆる側面をカバーする包括的な管理ツールを提供します。したがって、Kubernetes はコンテナ技術をベースにしたまったく新しい分散アーキテクチャ ソリューションであり、ワンストップで完全な分散システム開発およびサポート プラットフォームです。

        Kubernetes が提供するソリューションを理解するには、まず Kubernetes の基本的な知識を学ぶ必要があります。

        Kubernetes では、Service (サービス) が分散クラスター アーキテクチャの中核であり、Service オブジェクトには次の主要な特性があります。

• 一意に割り当てられた名前 (mysql-server など) を持ちます。
• 仮想 IP (クラスター IP、サービス IP、または VIP) とポート番号を持っています。
• 何らかのリモート サービス機能を提供できます。
• これは、このサービス機能を提供する一連のコンテナ アプリケーションにマップされます。

        現在、Service のサービス プロセスは、Redis、Memcache、MySQL、Web サーバー、または特定のビジネスを実装する特定の TCP サーバー プロセスなど、ソケット通信に基づいた外部サービスを提供しています。通常、サービスは複数の関連するサービス プロセスによって提供され、各サービス プロセスには独立したエンドポイント (IP + ポート) アクセス ポイントがありますが、Kubernetes では、指定されたサービス上のサービス (仮想クラスター IP + サービス ポート) を介してサービスに接続できます。Kubernetes の組み込みの透過的なロード バランシングと障害回復メカニズムを使用すると、バックエンドにサービス プロセスがいくつあるか、障害によりサービス プロセスが他のマシンに再デプロイされるかどうかに関係なく、システムには影響しません。通常サービスの転送です。さらに重要なのは、サービス自体は一度作成されると変更されないということです。つまり、Kubernetes クラスターでは、サービスの IP アドレスの変更の問題を心配する必要がなくなりました。

        コンテナは強力な分離機能を提供するため、Serviceのサービスを提供するプロセス群をコンテナに入れて分離する必要があります。この目的を達成するために、Kubernetes は Pod オブジェクトを設計し、各サービス プロセスを対応する Pod にパッケージ化し、Pod 内で実行されるコンテナ (Container) にします。Service と Pod の間の関係を確立するために、Kubernetes はまず各 Pod にラベル (Label) をアタッチし、MySQL を実行している Pod には name=mysql のラベルを付け、PHP を実行している Pod にはラベル name=php を付けます。対応する Service はラベル セレクター (Label Selector) を定義します。たとえば、MySQLService のラベル セレクターの選択条件は name--mysql であり、これは Service が name=mysqlLabel を含むすべての Pod に対して動作することを意味します。このようにして、Service と Pod 間の関連付けの問題は巧みに解決されます。

        Pod について、ここでその概念を簡単に紹介しましょう。まず第一に、ポッドはノード (ノード) と呼ばれる環境で実行されます。このノードは物理マシン、またはプライベート クラウドまたはパブリック クラウドの仮想マシンにすることができます。通常、1 つのノード上で数百のポッドが実行されます。;第二に、各 Pod は Pause と呼ばれる特別なコンテナを実行し、その他のコンテナはビジネス コンテナです。これらのビジネス コンテナは、Pause コンテナのネットワーク スタックとボリューム マウント ボリュームを共有するため、それらの間の通信とデータの交換がより効率的になり、最大限に活用できます設計時にこの機能を使用して、密接に関連するサービス プロセスのグループを同じポッドに配置します: 最後に、すべてのポッドとその中で実行されているコンテナがサービスに「マッピング」できるわけではないことに注意してください。提供するサービス (内部または外部) はサービスに「マッピング」されます。

        クラスター管理の観点から、Kubernetes はクラスター内のマシンをマスター ノードと作業ノード (ノード) のグループに分割します。このうちクラスタ管理に関連するプロセス群であるkube-apiserver、kube-controller-manager、kubeスケジューラはMasterノード上で動作しており、リソース管理、Podスケジューリング、エラスティックスケーリング、セキュリティ制御、システム監視、エラー修正およびその他の管理機能は完全に自動化されています。クラスター内の作業ノードとして、Node は実際のアプリケーションを実行し、Node 上で Kubernetes によって管理される最小の操作単位は Pod です。Kubernetes の kubelet および kube-proxy サービス プロセスは Node 上で実行されており、これらのサービス プロセスは、Pod の作成、起動、監視、再起動、破棄、およびソフトウェア モードでのロード バランサの実装を担当します。

        最後に、従来の IT システムにおけるサービス拡張とサービスアップグレードという 2 つの問題と、Kubernetes が提供する新しいソリューションを見てみましょう。サービスの拡張には、リソースの割り当て（拡張するノードを選択する）、インスタンスのデプロイと起動などが含まれます。複雑なビジネス システムでは、これら 2 つの問題は基本的に手動で段階的に実行することで完了しますが、これは時間がかかり、実行が困難です。保証の品質です。

        Kubernetes クラスターでは、拡張する必要がある Service に関連付けられた Pod の ReplicationController (略して RC) を作成するだけで、Service の拡張やその後の Service アップグレードなどの問題が簡単に解決されます。RC 定義ファイルには、次の 3 つの重要な情報を含めます。

• ターゲットポッドの定義。
• ターゲット ポッドが実行する必要があるレプリカ (レプリカ) の数。
• 監視対象のPodのラベル(Label)。

        RC が作成されると (システムが自動的にポッドを作成します)、Kubernetes は RC で定義されたラベルを通じて対応するポッド インスタンスをフィルターし、そのステータスと数をリアルタイムで監視します。レプリカ (Replica) の数を指定すると、RC で定義された Pod テンプレートに従って新しい Pod が作成され、Pod インスタンスの数が所定の目標に達するまで、適切な Node で実行を開始するようにスケジュールされます。このプロセスは完全に自動化されており、人間の介入は必要ありません。RC を使用すると、RC 内のレプリカの数が変更される限り、サービスの拡張は純粋に単純な数字ゲームになります。後続のサービスのアップグレードも、RC を変更することによって自動的に行われます。

2. Kubernetes を使用する理由

        Kubernetes を使用する理由はたくさんありますが、最も根本的な理由は次のとおりです。IT は常に新しいテクノロジーによって推進されてきた業界です。新興のコンテナ化テクノロジーである Docker が多くの企業に採用され、単一マシンからクラスターへの移行が避けられなくなり、クラウド コンピューティングの活発な発展によりこのプロセスが加速しています。Kubernetes は現在、業界で広く認識され、楽観視されている唯一の Docker 分散システム ソリューションです。今後数年間で、システムがローカル サーバーで実行されているかどうかに関係なく、多数の新しいシステムで Kubernetes が選択されることが予想されます企業のサーバーやパブリックサーバー、クラウド上でホストされています。

        Kubernetes を使用するメリットは何ですか?

        まず最も直接的に感じられるのは、複雑なシステムを「軽く」開発できるということです。以前は、分散システムの設計、実装、運用には常に十数人以上の人材が必要で、チーム内の多くの技術専門家が協力して作業する必要がありましたが、Kubernetes ソリューションの採用後は、小規模で有能なチームのみがそれを実現できます。簡単に処理できます。このチームでは、アーキテクトがシステム内の「サービス コンポーネント」の改良に重点を置き、数名の開発エンジニアがビジネス コードの開発に重点を置き、システム エンジニアと運用保守エンジニアが Kubermnetes の導入と運用保守を担当します。 「996」、これは私たちがあまり行っていないからではなく、Kubernetes がすでに私たちのために多くのことをしてくれているからです。

        2 番目に、Kubernetes を使用すると、マイクロサービス アーキテクチャが全面的に採用されます。マイクロサービス アーキテクチャの核心は、巨大なモノリシック アプリケーションを相互接続された多数の小さなマイクロサービスに分解することです。マイクロサービスは複数のインスタンス コピーによってサポートされる場合があり、システム負荷の変化に応じてコピーの数が変わる場合があります。チューニング、組み込みロード バランサーは、ロード バランサーの役割を果たします。ここで重要な役割。マイクロサービス アーキテクチャにより、各サービスは専任の開発チームによって開発され、開発者は開発テクノロジを自由に選択できるため、大規模なチームにとって貴重です。また、各マイクロサービスは独立して開発、アップグレード、拡張されるため、システムは高い安定性と迅速な反復進化機能を備えています。Google、Amazon、eBay、NetFlix などの多くの大手インターネット企業がマイクロサービス アーキテクチャを採用していますが、今回、Google はマイクロサービス アーキテクチャのインフラストラクチャを Kubernetes ソリューションに直接パッケージ化し、マイクロサービス アーキテクチャを直接適用して問題を解決する機会を与えてくれました。複雑な問題 ビジネス システムのアーキテクチャ上の問題

        そうすれば、いつでもどこでもシステム全体をパブリック クラウドに「再配置」できます。Kubernetes の当初の目標は、Google 独自のパブリック クラウド GCE 上で実行することであり、将来的にはさらに多くのパブリック クラウドと OpenStack ベースのプライベート クラウドをサポートする予定です。同時に、Kubernetes アーキテクチャ ソリューションでは、基盤となるネットワークの詳細が完全にシールドされ、サービスベースのクラスター IP により、ランタイムを変更することなくシステムを物理マシン環境からパブリック クラウドにシームレスに移行できます。または、サービスのピーク時に一部のサービスに対応するポッドのコピーをパブリック クラウドに配置してシステムのスループットを向上させ、企業のハードウェア投資を節約するだけでなく、顧客エクスペリエンスも大幅に向上します。私たちがよく知っている鉄道省の 12306 発券システムは、春節のピーク期間中に配布するために Alibaba Cloud をレンタルしました。

        最後に、Kubernetes システム アーキテクチャには超水平拡張機能があります。インターネット企業にとって、ユーザーの規模は資産に相当し、より多くのユーザーを抱えた企業が競争に勝つことになるため、超水平展開力がインターネットビジネスシステムの重要な指標の一つとなっています。コードを変更することなく、Kubernetes クラスターは、少数のノードのみを含む小規模クラスターから数百のノードを含む大規模クラスターまでスムーズに拡張でき、Kubernetes が提供するツールを使用してオンラインでクラスターの拡張を完了することもできます。マイクロサービスが適切に設計されている限り、ハードウェアまたはパブリック クラウド リソースの直線的な増加と組み合わせることで、システムは多数のユーザーによる同時アクセスによってもたらされる多大な圧力に耐えることができます。

3. Kubernetes アーキテクチャ図

        Kubernetes システムは、分散ノード クラスター内のマイクロサービスまたはコンテナー化されたアプリケーションを管理するために使用され、ダウンタイムなしのデプロイ、自動ロールバック、スケーリング、コンテナーの自己修復 (自動構成、自動再起動、自動レプリケーションを含む) を提供します。 、コンテナの自動スケーリングなど）およびその他の機能。

        Kubernetes システムの最も重要な設計要素の 1 つは、スケールアウト機能、つまり、アプリケーションのレプリカの数を調整して可用性を向上させる機能です。大規模なシステムを設計し、そのランタイムが堅牢でスケーラブルで移植性があり、非常に困難であることを確認することは、特にシステムの複雑さが増すと、システムのアーキテクチャがその動作モード、環境への依存性、結合度に直接影響します。関連コンポーネントの説明。

        マイクロサービスは、クラスター上でスケーラブルに展開するためのソフトウェア設計パターンです。このパターンを使用すると、開発者は、明確に定義された HTTP REST API インターフェイスを通じて通信する、小さな構成可能なアプリケーションを作成できます。Kubernetes もマイクロサービス アーキテクチャ モデルに準拠したプログラムであり、弾力性、可観測性、管理機能を備え、クラウド プラットフォームのニーズに適応できます。

        Kubernetes のシステム アーキテクチャ設計は、Scheduler スケジューラ、Pod リソース オブジェクト管理など、Borg のシステム アーキテクチャ設計概念と非常によく似ています。図 1-1 は、Kubernetes の一般的なアーキテクチャを示しています。

        Kubernetes のシステム アーキテクチャはクライアント/サーバー (C/S) アーキテクチャに従っており、システム アーキテクチャはマスターとノードの 2 つの部分に分かれており、マスターがサーバー、ノードがクライアントとなります。Kubernetes システムには複数のマスター サーバーがあり、高可用性を実現できます。デフォルトでは、マスター サーバーがすべての作業を実行できます。

        マスター サーバーはマスター コントロール ノードとも呼ばれ、主にクラスター内の次のタスクを担当します。

• (1) クラスターの「頭脳」は、すべてのノード (Node) の管理を担当します。
• (2) ポッドを実行するノードのスケジュールを担当します。
• (3) クラスタ動作中のすべての状態の制御を担当します。

        ノード クライアントは作業ノードとも呼ばれ、主にクラスター内の次のタスクを担当します。

• (1) すべてのコンテナ(Container)の管理を担当します。
• (2) すべての Pod の実行ステータスを監視/報告する責任があります。

        マスター サーバー (マスター コントロール ノード) は主に Kubernetes クラスター全体の管理と制御を担当し、クラスターに関するグローバルな意思決定を行い、クラスター全体の「頭脳」に相当します。クラスターによって実行されるすべての制御コマンドは、マスター サーバーによって受信され、処理されます。マスター サーバーには主に次のコンポーネントが含まれています。

• kube-apiserver コンポーネント: クラスターの HTTP REST API インターフェイス。クラスター制御のエントリ ポイントです。
• kube-controller-manager コンポーネント: クラスター内のすべてのリソース オブジェクトの自動化されたコントロール センター。
• kube-scheduler コンポーネント: クラスター内の Pod リソース オブジェクトのスケジューリング サービス。

        ノード クライアント (作業ノード) は、Kubernetes クラスター内の作業ノードです。ノード ノード上の作業はマスター サーバーによって分散されます。たとえば、ノード ノードがダウンすると、マスター ノードはその作業を他のノードに転送します。ノードノード。

        Node ノードには主に次のコンポーネントが含まれます。

• Kubelet コンポーネント: ノード上のコンテナの作成、削除、開始と停止などのタスクの管理、およびマスター ノードとの通信を担当します。
• kube-proxy コンポーネント: Kubernetes サービスの通信および負荷分散サービスを担当します。
• コンテナコンポーネント: コンテナの基本的な管理サービスを担当し、kubelet コンポーネントから指示を受け取ります。

4. まとめと展開

4.1. Kubernetes の優れた機能

Kubermetes には以下のような優れた機能があります。

• 強力なコンテナオーケストレーション機能

        Kubernetes は Docker とともに開発され、Docker と深く統合され、コンテナの特性に自然に適応し、コンテナの組み合わせ、ラベルの選択、サービスの検出などの強力なコンテナ オーケストレーション機能を設計したと言えます。エンタープライズレベルのニーズ。

• 軽量

        Kubermetes はマイクロサービス アーキテクチャの理論に従っており、システム全体が機能的に独立したコンポーネントに分割されており、コンポーネント間の境界が明確で、導入が簡単で、さまざまなシステムや環境で簡単に実行できます。同時に、Kubermetes の多くの機能はプラグ可能であり、簡単に拡張したり置き換えたりできます。

• オープンソース

        Kubermetes はオープンソースのトレンドに準拠しており、多くの開発者や企業が参加し、協力してエコシステムを構築しています。同時に、Kubernetes は OpenStack や Docker などのオープンソース コミュニティと積極的に協力および開発しており、企業と個人の両方が参加して恩恵を受けることができます。

同時に、Kubernetes システムには次のような特徴もあります。
●ポータブル: パブリック クラウド、プライベート クラウド、ハイブリッド クラウド、マルチクラウド (マルチクラウド) をサポートします。
● 拡張性: モジュール式、プラグイン式、取り付け可能、組み合わせ可能。
● 自動化: 自動展開、自動再起動、自動レプリケーション、自動スケーリング/拡張。

4.2. Kubernetes と Docker

        Kubernetes と Docker は、補完的な 2 つのテクノロジーです。たとえば、通常、アプリケーション開発には Docker を使用し、その後、運用環境でアプリケーションを調整するために Kubernetes を使用します。

        このようなモデルでは、開発者は好みの言語でコードを記述し、Docker を使用してパッケージ化、テスト、配信します。ただし、最終的にテスト環境や本番環境で実行するプロセスは Kubernetes によって行われます。動作アーキテクチャの観点から、実稼働環境の Kubernetes クラスターが 10 ノードで構成されていると仮定します。次に、各ノードは Docker をコンテナー ランタイム (コンテナー ランタイム) として使用します。言い換えれば、Docker はコンテナの起動や停止などの操作を担当する、より低レベルのテクノロジであり、一方 Kubernetes は、どのノードを実行するかの決定など、クラスタ全体の管理に焦点を当てたより上位のテクノロジです。コンテナーのスケーリングまたはアップグレードに何が適しているかを決定します。

        図 1.2 は、コンテナー ランタイムとして Docker を使用する複数のノードで構成される Kubernetes クラスターを示しています。

        図 1.2 に示すように、Kubernetes でサポートされるコンテナ ランタイムは Docker だけではありません。実際、Kubernetes は一連の機能に基づいてコンテナー ランタイムの抽象化を実装します (そのため、基になるさまざまなコンテナー ランタイムと互換性を持たせることができます)。

        (1) Container Runtime Interface (CRI) は、サードパーティのコンテナ ランタイムとのインターフェイスとして Kubernetes によって使用される標準化された抽象化レイヤーです。このようにして、コンテナー ランタイムは Kubernetes から分離され、同時に標準化された方法でサポートできます。

        (2) ランタイム クラス (Runtime Class) は、Kubernetes 1.12 で導入された新機能で、バージョン 1.14 でベータ版にアップグレードされました。さまざまなランタイムを分類します。たとえば、gVisor または Kata コンテナー ランタイムは、Docker や Containerd よりも優れた分離を提供する可能性があります。

        この記事の執筆時点では、Containerd が Docker を追い越し、Kubernetes で最も一般的に使用されているコンテナ ランタイムとなっています。これは実際には、Kubernetes に必要な部分だけを残した、Docker の必要最低限​​のバージョンです。

        言及されていますが、これらの基盤となるテクノロジーは Kubernetes の学習エクスペリエンスには影響しません。Kubernetes レベルでの操作 (コマンドなど) は、どのコンテナー ランタイムが使用されても同じです。

4.3 Kubernetes が K8s と呼ばれる理由

        K8Sは、GoogleのBorgシステム（Borgシステム、Google社内で使用されている大規模コンテナオーケストレーションツール）をプロトタイプとしてベースにし、Borgのアイデアを用いてGo言語で書き直してオープンソースとしてCNCF財団に寄贈したものである。

        kubernetes の名前は「操舵手」または「航海士」を意味するギリシャ語に由来しており、K8s は「ubernete」の 8 文字を「8」に置き換えた略語です。