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 上の複数のアカウントを一元管理

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

推薦する

ウェブサイトのデザイン: どのようなホームページのデザインが見栄えが良いでしょうか?

インターネット ユーザーはサメのようなもので、前進し続けなければ生き残ることができません。常にブラウ...

ハイブリッドクラウドのリスクが心配ですか?霧を払いのける5つのヒント

クラウド プラットフォームは運用の回復力と、非常に必要な在宅勤務ツールを提供するため、組織がこの危機...

ドメイン名の選び方を教えてくれる11の視点

個人のブログから大規模なポータルまで、どのような種類の Web サイトであっても、ドメイン名にリンク...

インターネットにはたくさんの人がいますが、SEO初心者は何をすべきでしょうか?

百度は以前2回大規模なアップデートを実施し、一部のウェブマスターのウェブサイトがブロックされたり、格...

ハイブリッドクラウド戦略でデータセンターのコストを管理する方法

中小企業は、コストを抑えながら IT インフラストラクチャを管理するという課題に直面することがよくあ...

trentahost-1.56 USD/KVM/256 MB RAM/8 GB SSD/Windows/1000 MB/無制限/7 データセンター

trentahost.com は 年に設立されたようですが、それについての情報はあまりありません。 ...

郡レベルのポータル: インターネットで採掘される次の金鉱

ポータル Web サイトとは何ですか? 郡レベルのポータルを構築する理由は何ですか?ポータルサイトと...

中国のトップ 10 検索エンジンについての簡単な説明 (パート 1)

現在、中国の検索エンジンは混乱状態にあります。百度、捜索、捜狗、有道、ヤフー、ビング、グーグル、そし...

SAP製品ライフサイクル管理ソリューションは進化と拡大を続けています

2020 年 10 月は、SAP 製品ライフサイクル管理にとって重要な節目となります。 SAP はシ...

個人ウェブマスターは「問題を抱えて生まれ、安楽に死ぬ」ことに注意を払っている

このタイトルを見てすぐに意味が分かる人も多いと思いますが、今日は検索エンジン最適化の観点からこの文章...

ウェブサイトの最適化はゼロから始める必要があります

過去 1 か月間の経験を少しまとめました。現在の会社に入社してから、ウェブサイトの最適化やプロモーシ...

Baiduの最近の改善点をいくつか見てみましょう

長い間、捜索や捜狗などの検索エンジンは百度の優位な地位を揺るがすことができず、ブラウザの入り口をコン...

ミスフレッシュ上場後の状況

MissFreshとDingdong Maicaiが同日にIPO目論見書を提出したことで、この前線倉...

Seata 分散トランザクション XA および AT の総合分析

[[395191]] Seata は、19,200 を超えるスターと非常に活発なコミュニティを持つオ...