5分でわかるKubernetes: すべてのコンポーネントを簡単に理解

5分でわかるKubernetes: すべてのコンポーネントを簡単に理解

以前、サービスメッシュに関する一連のコンテンツについて触れました。しかし、アプリケーション サービス メッシュの概念はおろか、Kubernetes についての知識が比較的少ない学生もいることに気づきました。そのため、今日は、Kubernetes のいくつかの用語をすぐに理解できるようにして、短期間で開始して学習時間を短縮できるようにすることにしました。これから 5 分間でこれらの用語を紹介し、皆さんがそこから何かを得られることを願っています。役に立ったと思ったら、ぜひ高評価を押して励ましてください!皆さんの応援が私の前進の原動力です〜

クベネフィット

まず最初に強調したいのは、あらゆる知識を学ぶときに最も重要なリソースは公式ドキュメントだということです: https://kubernetes.io/zh-cn/docs/home/

公式ドキュメントには詳細かつ正確な情報が記載されており、このテクノロジーをより深く理解し、習得するのに役立ちます。したがって、Kubernetes に本当に興味がある場合は、時間をかけて公式ドキュメントを注意深く読むことを強くお勧めします。

Kubernetes について言えば、これはコンテナ化されたアプリケーションの展開、スケーリング、管理を自動化するように設計されたオープンソースのコンテナ オーケストレーション エンジンです。つまり、各コンテナを個別に操作するのではなく、複数の Docker コンテナを集中的に制御できるようになります。 Kubernetes が登場する前は、複数の Docker コンテナを同時に操作したい場合、シェル スクリプトを学習して実行する必要があり、時間がかかっていました。したがって、Docker コンテナをバッチで管理したい場合は、Kubernetes が適しています。もちろん、他の類似製品もご検討いただけます。

Kubernetes コンポーネント

Kubernetes が正常にインストールされていることを前提としています。 Kubernetes をデプロイすると、完全なクラスターが完成します。以下は参考用の公式アーキテクチャ図です。この図には、Node、Pod、kubelet、kube-proxy、kube-apiserver、etcd、kube-scheduler、kube-controller-manager、cloud-controller-manager などの特殊な用語を含む、多くのコンポーネントの名前がリストされています。次に、これらの名詞の意味を一つずつ説明していきます。

写真

ノード

アーキテクチャ図に基づいて、Node は実際にはコンテナ化されたアプリケーションの実行を担当するマシンであると推測できるでしょう。ただし、ノード上で複数のポッドを実行できます。 Pod は Kubernetes の最小のスケジューリング単位です。通常、Pod はマイクロサービスを表します。以下は Pod の YAML の例です。

 apiVersion: v1 kind: Pod metadata: name: my-pod spec: containers: - name: my-container image: nginx:latest

ただし、これは Pod が 1 つの Docker イメージのみをサポートできることを意味するものではありません。たとえば、サービス メッシュには、同じ Pod 内で複数のマイクロサービスを定義できるサイドカー パターンがあります。しかし、同じ Pod 内に複数のマイクロサービスを定義しないのはなぜでしょうか?これは、ポッドが最小のスケジュール単位であり、一緒に起動および再起動する必要があるためです。このバインディングは非常に厳密なので、すでにクラスターがある場合は、個別に定義してみてはいかがでしょうか。したがって、複数のイメージを定義する場合でも、ログ収集などのいくつかの補助機能のみを定義する必要があります。

クベレット

kubelet コンポーネントは、Kubernetes システム全体において重要な役割を果たします。具体的には、コントロール プレーンは Pod 定義を kubelet に送信し、kubelet はこれらの定義に基づいて Pod 内のコンテナを作成および管理します。 kubelet は、Pod とコンテナのステータスを監視し、このステータス情報をコントロール プレーンに報告する役割を担います。コントロール プレーンは、このステータス情報に基づいてスケジュールと管理の決定を行い、システム全体の効率的な運用を確保します。

Pod は、プロジェクトの採用マネージャーと同様に、各プロジェクト チームの採用担当 HR と考えることができます。コントロールプレーンは、採用要件と採用人数を設定する企業上層部のリーダーであり、具体的な採用業務は人事部門が担当します。 HR の責任は、プロジェクトに十分な人員が確保され、会社のリーダーシップの要件を満たしていることを確認することです。彼らはプロジェクトの人員状況を継続的に監視し、誰かが退職した場合は、上位レベルの制御プレーンの要件を満たすために上司に報告します。一方で、会社の上層部とプロジェクト担当者の間で直接のコミュニケーションはなく、すべてのコミュニケーションは人事部を通じて行われています。このプロセスでは、人事部門はプロジェクト担当者と上級管理職の間の連絡役として、情報の伝達、問題の解決、作業の調整を担当します。

kubeプロキシ

最適化ステートメントを長くします。アーキテクチャ図では、kube-proxy も上位層に接続されていることがわかります。サービス プロキシと負荷分散機能を通じてクラスター内でネットワーク通信とトラフィック転送を実装し、サービスの可用性と信頼性を確保します。

彼は私たちのプロジェクトチームの中で誰ですか?彼は実際にポッドにどのようなタスクを実行するかを指示する人物です。プロジェクトチームにおける開発リーダーの役割、あるいはプロジェクトマネージャーに近い役割を担っていると言えます。彼は、私たちが行うべきタスクを指導する責任があり、必要に応じて作業を転送して割り当てる責任があります。

ただし、ネットワーク経由で Pod と直接通信するのではなく、Service オブジェクトと通信することに注意してください。

サービス

上記のケースでは、Service オブジェクトを導入しました。実際、Service オブジェクトは Pod リソースのグループを表します。実稼働環境では、通常、リクエストを処理するために 1 つのサービスだけをデプロイするのではなく、複数の Pod コピーが同時にリクエストを処理します。したがって、kube-proxy が負荷分散や転送などの操作を実行できるように、それらをグループ化する Service オブジェクトが必要です。 Pod 内のラベルに続くキー:値が一致している限り、リクエストは対応する Pod レプリカに転送できます。メタデータの下のラベル フィールドには、キー:値の形式に準拠している限り、任意のキーと値のペアを含めることができます。

 apiVersion: v1 kind: Pod metadata: name: nginx labels: app.kubernetes.io/name: proxy spec: containers: - name: nginx image: nginx:stable ports: - containerPort: 80 name: http-web-svc --- apiVersion: v1 kind: Service metadata: name: nginx-service spec: selector: app.kubernetes.io/name: proxy ports: - name: name-of-service-port protocol: TCP port: 80 targetPort: http-web-svc

コントロールプレーンコンポーネント

コントロール プレーン コンポーネントはクラスター内で重要な役割を果たします。これらは、リソースのスケジュール設定などのグローバルな決定や、デプロイメントのレプリカ フィールドが満たされていない場合に新しいポッドを開始するなどのクラスター イベントの監視と応答を担当します。コントロール プレーン コンポーネントは、クラスター内の任意のノードで実行できます。ただし、セットアップと管理を簡素化するために、通常はすべてのコントロール プレーン コンポーネントが同じマシン上で起動され、そのマシン上でユーザー コンテナーは実行されません。これは、意思決定と管理に責任を持ち、実際に作業を実行するポッドと間接的な関係を持つ、会社の取締役会に例えることができます。

kube-apiサーバー

名前から、すべての API リクエストを完了するために他のコンポーネントを処理して呼び出す役割を担っていることが推測できます。たとえば、以前は YAML 形式のファイルで Pod を定義しました。バックグラウンドで kubectl apply -f your-pod.yaml を実行すると、kube-apiserver はリクエストを受信して​​誰に転送しますか?前述したように、リクエストは kubelet に転送されます。kubelet は Docker と対話し、作成などの操作を実行します。したがって、kube-apiserver はコントローラーのように動作し、リクエストを直接受信しますが、処理はしません。

など

etcd は、すべての Kubernetes クラスター データのリポジトリとして使用されるバックエンド データベースです。考えられるすべてのデータを保存できるだけでなく、分散ストレージを使用し、Raft アルゴリズムに基づいてデータの一貫性を保証します。これにより、etcd はクラスターの構成データ、状態情報、メタデータを保存するため、すべてのノードでデータの一貫性を維持できます。 etcd はクラスターの「頭脳」として、コンテナ、ノード、ポッド、サービス、その他のリソースに関する情報を保存します。 etcd のデータの変更を監視することにより、サービス検出メカニズムは自動的なサービス登録と検出を実現できます。新しいポッドまたはサービスが作成されると、関連情報が etcd に登録されます。他のコンポーネントまたはアプリケーションは、etcd を照会することでこの情報を取得できるため、サービス間の通信と調整が可能になります。

kube スケジューラ

当時、kubelet はノード上のコンテナと Pod の管理を担当していると述べましたが、スケジュールの責任は誰が負うのでしょうか?それは kube-scheduler の責任です。 kube-scheduler の主な役割は、利用可能なノードから Pod を実行するための最適なノードを選択し、リソースのバランスの取れた配分を確保し、マシン リソースの無駄を避けることです。コントロール プレーンのコンポーネントは多数あるため、それぞれの機能をよりよく理解できるように、わかりやすく示す追加の図も用意しました。

写真

kube コントローラー マネージャー

kube-controller-manager は、Kubernetes クラスターに欠かせないコア コンポーネントの 1 つです。その主な役割は、一連のコントローラーを実行して、クラスターの状態が常に期待どおりに維持されるようにすることです。機能の理解を深めるために、デプロイメント コントローラー マネージャーを例に挙げます。他のコントローラーの詳細情報は、自分でクエリを実行することで取得できます。

デプロイメント コントローラーは、アプリケーションのデプロイメントを管理するコンポーネントです。その主な機能は、ユーザー定義の希望状態に応じて ReplicaSet の作成、更新、削除を制御し、アプリケーションのローリング アップグレードとロールバックを実現することです。例えば。 Pod がダウンすると、kubelet はまず Pod のステータスの変化を検出し、この情報を kube-controller-manager のレプリケーション コントローラーに渡します (Pod がレプリケーション コントローラーによって作成された場合)。レプリケーション コントローラーは、Pod レプリカの数を管理するコントローラーの 1 つです。

レプリケーション コントローラーは、ポッドの状態変更に関する通知を受信すると、クラスター内の現在のポッド レプリカの数を確認し、定義されているレプリカの数に基づいて調整します。現在のポッド数が必要なレプリカ数より少ないことが判明した場合、レプリケーション コントローラーは、必要なレプリカ数を満たすために、対応するノード上で不足しているポッドを再作成するように kubelet に指示を発行します。 kubelet は HR と比較されるといつも言っていませんでしたか?上級管理職がデプロイメント コントローラーを見つけました。

コントローラーの管理レベルに関係なく、kube-apiserver レイヤーを通過する必要があることに注意してください。他のコンポーネント kube-apiserver を呼び出す資格があるのは彼だけです。

クラウド コントローラー マネージャー

cloud-controller-manager は、クラウド プラットフォーム関連のコントローラーを提供するオプション コンポーネントです。私たちにとっては、それは私たちの仕事とは無関係に思えるかもしれません。 cloud-controller-manager は、クラウド プラットフォームの API と対話するときに、ロード バランサー、ノード グループ、ストレージ ボリュームなどのクラウド リソースを管理できます。これにより、より豊富なクラウド リソース管理機能を実現できます。 cloud-controller-manager の特定の機能と動作は、使用するクラウド プラットフォームによって異なることに注意することが重要です。そのため、使用するクラウド プラットフォームに応じて適切なソリューションを提供できます。

要約する

この記事では、Kubernetes の用語をいくつか紹介しました。 Kubernetes は、コンテナ化されたアプリケーションの展開、拡張、管理を自動化するのに役立つ非常に強力なコンテナ オーケストレーション エンジンです。これらの用語を理解することで、Kubernetes の動作原理とアーキテクチャをより深く理解できるようになります。


<<:  Alibaba Cloud 上の複数のアカウントを一元管理

>>:  いくつかの一般的なコンテナオーケストレーションツールの比較

推薦する

セール中の共有ホスティングブランドのリスト

2017年のブラックフライデーには、海外のウェブホスティングブランドも当然プロモーションを実施します...

SEOは検索エンジンのアルゴリズムの変化に合わせて変化するべきである

私は長い間プラットフォーム サイトの最適化に携わっており、検索エンジン アルゴリズムの変化について多...

クラウド ストレージにまだ高額な料金を支払っていませんか?ワークロードを最適化してコストを節約する10の方法をお見逃しなく

[51CTO.com クイック翻訳] クラウドは、多くの企業がプロジェクトを追跡、アクセス、共同作業...

Baiduのホームページ再設計後にボタンを追加した例

2012 年 5 月 16 日、Baidu はホームページを刷新しました (下の図 1 を参照)。 ...

[翻訳] リクエストとlxmlを使用したWebスクレイピング

ウェブスクレイピングWeb サイトは HTML で記述されており、各 Web ページは構造化されたド...

共同購入は疲労期に突入:価格が上昇し、期間当たりの取引量は減少

7月30日午後、共同購入業界は昨年末から沈黙の時期に入った。「2012年上半期共同購入統計報告」によ...

semoweb 第2世代 VZ/高速VPS/ロサンゼルス/QuadraNetデータセンター

Semoweb は、仮想ホスティング、再販業者、VPS、サーバーなど、多くのビジネスを展開する 20...

医療業界の現状とSEOの実態の解釈

私はSEOに携わるようになってからずっと医療業界で働いています。医療業界に長く携わってきて、一番感じ...

インターネットの「戦争」は非常にエキサイティングです。CEOの「ユーザーエクスペリエンス」を見てみましょう

最近、インターネットがとても活発になっています。少し前には劉強東と張金東の北京・蘇州の戦いがあり、最...

websound - $20/年/KVM/512m メモリ/25g ハードディスク/2T トラフィック/ラスベガス

セール中の格安 VPS をご紹介します: websound.co.uk のラスベガス KVM 仮想 ...

ウェブサイトはスタートラインで勝利する: 良いウェブサイトの秘訣

清明節の休暇から戻ってきました。友達と楽しい時間を過ごしましたか?ふふ、私はとても幸せです。少なくと...

第4世代検索エンジンの外部リンクを最も効果的にする方法

Baidu Green Radish Algorithm(第4世代の検索と呼んでいます)のリリース後...

SD-WANはマルチクラウドの課題解決に役立ちます

SD-WAN がリモート ユーザーがクラウドベースのアプリケーションにアクセスするための主な方法にな...

成功するWeiboを構築するための8つの要素

Weiboはますます人気が高まり、今日のインターネット上で欠かせないコミュニケーションツールとなって...

テンセントVS今日頭条、戦いの末にユーザーは何を得たのか?

実際、テンセントと今日頭条の間で起こったユーザーのアバターとニックネームに関する事件は、より明確に整...