July 29, 2021

包括的なKubernetes用語集

包括的なKubernetes用語集

Kubernetesを使用していて、出くわした新しい用語を検索するという考えが疲れ果てているように思われる場合は、適切な場所に来ています。 この用語集は、Kubernetesの用語をアルファベット順に包括的にリストしたものです。  

にジャンプする:

A | C | D | E | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W

アドミッションコントローラー –ユーザーがクラスターで許可されるオブジェクトを構成できるようにするKubernetes固有のセキュリティ機能。 アドミッションコントローラーは、各クラスターの使用方法を規制します。 アドミッションコントローラーは、オブジェクトを実行する前に、Kubernetesサーバーで各リクエストをすばやくチェックします。

親和力 –ポッドの配置を示唆する一連のルール。 XNUMXつのタイプがあります:

  • ノード
  • ポッドツーポッド

スケジューラーが実行する必要のある厳密さに応じて、これらのルールは優先または必須のいずれかになります。

集約層 –アグリゲーションレイヤーを使用すると、基本的なKubernetes APIで利用できるものに加えて、他のAPIでKubernetesを拡張できます。 サービスカタログなど、カスタマイズされた既製のAPIを使用することも、自分で開発したAPIを使用することもできます。 

AKS – Azure Kubernetes Service(AKS)は、2018年にデビューしたオープンソースのフルマネージドコンテナープランニングサービスです。AKSはパブリックMicrosoft Azureクラウドで提供され、Dockerコンテナーやその他のコンテナー化されたアプリのデプロイ、スケーリング、管理に使用できます。クラスターでの作業。 すべてのリソースについて、AKSは必要に応じてまたはオンデマンドで以下を提供します。

  • プロビジョニング
  • スケーリング
  • アップグレード

クラスターのダウンタイムは発生せず、AKSを使用するためにコンテナー構成を深く理解する必要はありません。

アマゾンEKS(EKS) –AmazonのElasticKubernetes Service(EKS)を使用すると、独自のコントロールプレーン/ノードをインストール、操作、またはメンテナンスすることなく、Amazon Web Service(AWS)でKubernetesを実行できます。

アノテーション –オブジェクトのメタデータに割り当てられた値。

APIグループ – KubernetesAPI内の関連するパスのグループ。

APIサーバー – KubernetesAPIを表示するコントロールプレーンの一部。 コントロールプレーンのフロントエンド。 この軽量アプリケーションを使用すると、カスタマイズされた開発手順を必要とせずに、他のデータからAPIデータを作成および抽出できます。

アプリケーション –コンテナー化されたアプリが実行されるレイヤー。 アプリケーションはコンテナ化されたソリューションです。

cgroup –コンテナグループ –リソース、アカウンティング、および/または制限のオプションの分離があるLinuxネイティブのプロセスのグループ。 特定のプロセスセットのリソース使用を制限、説明、または分離するカーネル機能。 cgroupsを使用すると、次のようなさまざまなリソースを割り当てることができます。

  • システムメモリ
  • 帯域幅
  • CPU時間
  • 上記の組み合わせ

cgroupsを使用すると、ユーザー定義されたシステム内で実行されているタスクグループまたはプロセス間でこれらのリソースを割り当てることもできます。 あなたもすることができます:

  • 構成したcgroupを監視します。
  • 特定のcgroupへの特定のリソースアクセスを拒否します。
  • 特定のcgroupを動的に再構成します。

CIDR –クラスレスドメイン間ルーティング(CIDR)は、IPアドレスのマスクです。 スーパーネットとも呼ばれるCIDRは、IPアドレスを割り当ててアドレス配布の効率を向上させ、クラスA、B、およびCネットワークに基づいていた以前のシステムを置き換えます。

クラウドコントローラーマネージャー –クラウドコントローラーは、データを物理的なオンプレミスのストレージの場所からクラウドの場所に移動するストレージツールです。 クラウドコントローラーは、オンプレミスストレージにハードドライブ、SSD、またはそれらの組み合わせのいずれかを使用します。 クラウドコントローラーマネージャーは、特定の制御ロジックをクラウドに埋め込むことができるコントロールプレーン要素です。 このツールは、さまざまなクラウドサービスプロバイダーがKubernetesと統合またはリンクできるようにするプラグインで構成されています。 

クラスタ – Kubernetesクラスターは、コンテナー化されたアプリを実行するノードマシンのセットです。 つまり、Kubernetesを使用している場合は、クラスターを使用しています。 最低限、クラスターには、コントロールプレーンと、少なくともXNUMX台のコンピューティングマシンまたはノードが含まれます。 ノードは、アプリとワークロードの実行を担当します。

ConfigMap –構成設定の辞書。 ConfigMapには、キーと値のペアの文字列があります。 キーと値のペアは、Kubernetesがコンテナに提供する命令として機能します。 他のKubernetes辞書と同様に、構成の値を表示および設定できます。 ConfigMapを使用して、アプリケーションコードを構成から分離しておくことができます。 これは、Software-as-a-Serviceアプリケーションの作成に使用される12要素アプリの重要な側面です。

コンテナ –ソフトウェアとその依存関係を含む軽量で実行可能なイメージ。 コンテナは、すぐに使用できるソフトウェアパッケージです。 アプリの実行に必要なものはすべて、次のようにコンテナにあります。

  • コー​​ド
  • ランタイム
  • アプリライブラリ
  • システムライブラリ
  • 重要な設定のデフォルト値

コンテナ入り –比較的高レベルのインターフェースを提供するカーネル機能の概念。 他のソフトウェアは、コンテナとイメージを実行および管理するためにコンテナを使用できます。

コンテナ環境変数 –ポッド内で実行されるコンテナーへの洞察を提供する「名前は値に等しい」ペア。 コンテナ環境変数は、次のようなリソースに関するアプリケーション固有の必要な情報を各コンテナに提供します。

  • システムの詳細
  • コンテナ情報
  • サービスエンドポイント

コンテナネットワークインターフェイス(CNI) – Cloud Native Computing FoundationによるプロジェクトであるCNIは、Linuxコンテナ内のネットワークインターフェイスを構成するプラグインの作成に関するライブラリと仕様で構成されています。 Kubernetesでは、CNIはネットワークプロバイダーとネットワークポッド間のインターフェイスとして機能します。 

コンテナランタイム –コンテナーの実行を担当するソフトウェア。 このソフトウェアは、各コンテナを実行し、ノード上で管理します。 コンテナランタイムインターフェイス(CRI)を使用すると、Kubernetesは再コンパイルせずにいくつかのタイプのコンテナランタイムを使用できます。 理論的には、Kubernetesは、CRIを使用してポッド、コンテナ、イメージを管理する任意のコンテナランタイムを使用できます。

コンテナランタイムインターフェイス(CRI) –ノード上のkubeletと結合するコンテナーランタイムAPI。

コンテナストレージインターフェイス(CSI) –コンテナとストレージシステム間の標準化されたインターフェースを提供し、カスタマイズされたストレージプラグインが各ストレージシステムをKubernetesリポジトリに追加することなくKubernetesと連携できるようにします。

コントロールプレーン –コンテナーのデプロイメント、定義、および管理が行われるレイヤー。 コントロールプレーンのコンポーネントには、etcd、Scheduler、およびControllerManagerが含まれます。

コントローラー –クラスターの状態を監視し、必要に応じて変更を加えて要求し、クラスターの現在の状態をクラスターの最も望ましい状態に近づけるループ。 一部のコントローラーのループは、操作に必要な場合、コントロールプレーン内で実行される場合があります。 たとえば、名前空間コントローラーはkube-controller-manager内で実行されます。

それを作成する – CRI-Oは、Kubernetesのコンテナランタイムインターフェイス(CRI)の操作であり、Open Container Initiative(OCI)を使用する互換性のあるランタイムを有効にすることができます。 Docker、Moby、およびrktが必要なほど軽量でない場合は、CRI-Oが適切な代替手段です。 ポッドを実行するためのKubernetesランタイムとして任意のランタイムを使用できます。 また、OCIに準拠したruncおよびその他のコンテナランタイムもサポートします。 CRIOは任意のOCIイメージを維持し、指示に従ってすべてのコンテナーレジストリから描画できます。 

カスタムコントローラー –場合によっては、Kubernetesのコアコントローラーが必要な制御を提供しないことがあります。 カスタムコントローラーを使用すると、ユーザーはコアコードを変更せずにKubernetesのコア機能を拡張できます。

CustomResourceDefinition(CRD) –カスタムコントローラー用にカスタマイズされたコード。Kubernetesコアコントローラーが必要な機能を提供しない場合に使用されます。

デーモンセット –システムのデーモン(ログコレクター、監視エージェントなど)は通常、各ノードで実行する必要があります。 DaemonSetは、ポッドコピーがクラスター内のノードのグループ全体で機能することを確認します。

データプレーン –コンテナーを実行するためのCPU、メモリー、ストレージなどの作業面を保持するレイヤー。 データプレーンは、コンテナが特定のネットワークに接続するのに役立ちます。

展開 –さまざまなアプリケーションに更新を提供するAPIリソースオブジェクト。 デプロイメントは、ポッドのスケジューリング、管理、更新、ロールバック、水平スケーリング、およびライフサイクルを管理します。

デバイスプラグイン –ポッドがさまざまなリソースにアクセスできるようにするノードで実行します。 ベンダー固有のアプリケーションの特定のセットアップまたは初期化では、デバイスプラグインを使用して動作します。 デバイスプラグインは、DaemonSetとしてデプロイすることも、必要な各ノードに直接インストールすることもできます。

混乱 –ポッド(または複数のポッド)がサービスを停止する原因となるイベント。 これは、必要なポッドに影響を与えるため、ワークロードに必要な展開やその他のリソースに悪影響を与える可能性があります。

デッカー –ソフトウェアテクノロジーであるDocker、またはDocker Engineは、コンテナーの形式でオペレーティングシステムレベルで仮想化を提供します。

動的ボリュームプロビジョニング – StorageClass APIオブジェクトを使用すると、ユーザーは事前にプロビジョニングされたボリュームを必要とせずに、ストレージボリュームを自動的にプロビジョニングできます。 動的ボリュームプロビジョニングを使用して、オンデマンドでストレージボリュームを作成できます。 このツールがない場合、クラスター管理者は手動でクラウドを呼び出して新しいストレージボリュームを作成し、その後、Kubernetesでそれらの呼び出しを表すPersistentVolumeオブジェクトを作成する必要があります。 動的プロビジョニングにより、事前プロビジョニングの要件がなくなります。 要求に応じてストレージを自動的にプロビジョニングするだけです。

エンドポイント –エンドポイントは、個々のポッドIPアドレスが割り当てられるオブジェクトです。 次に、エンドポイントのオブジェクトがKubernetesによって参照されるため、通信を実行できるように、すべてのポッドのすべての内部IPアドレスのレコードがあります。

エンドポイントスライス –Kubernetesバージョン1.16でリリースされました。 エンドポイントスライシングを使用すると、Kubernetesリソースを使用してグループ内のエンドポイントをグループ化できます。 エンドポイントには、特定のサービスに一致するすべてのポッドが格納されます。 サービス内に数百のポッドがあり、変更を加えると、エンドポイントオブジェクトが大きくなる可能性があります。 エンドポイントスライシングがリリースされる前は、行われたすべての変更によってすべてのオブジェクトが変更され、その変更がクラスター内のすべてのノードに渡されたため、パフォーマンスと安定性に重大な問題が発生していました。 エンドポイントスライシングを使用すると、同様のエンドポイントをグループ化できるため、複数のエンドポイントを変更するときに中断が発生することはありません。

エフェメラルコンテナ –ポッド内で一時的に実行できるコンテナーのタイプ。 ポッドに問題の兆候が見られる場合、エフェメラルコンテナを実行すると、ユーザーはワークロード全体に影響を与えることなく問題を診断できます。 重要な注意点は、このタイプのコンテナーにはリソースまたはスケジュールの保証がなく、実際のワークロードを実行するために使用すべきではないということです。

その他 –ストレージ構成管理ツールなどはKubernetesの実行に不可欠です。 サービスがスケジュールされ、適切に動作するように、常に一貫性があり、利用可能である必要があります。 Etcdデータは重要であるため、クラスターバックアップを作成することを強くお勧めします。

拡張機能 –「拡張」するソフトウェア要素。新しいハードウェアタイプをサポートするためにKubernetesプラットフォームと緊密に統合されます。 クラスター管理者は、新しいインスタンスを作成するのではなく、XNUMXつ以上の拡張機能をインストールできます。

Google Kubernetes Engine(GKE) – GKEは、Googleのインフラストラクチャを使用してコンテナ化されたアプリをデプロイ、管理、スケーリングするための管理された環境を提供します。 この環境には、Compute Engineなど、グループ化されてクラスターを形成する複数のマシンがあります。

ヘルムチャート –ヘルムチャートは、Kubernetesクラスターに提示できるXNUMXつのパッケージに結合されたYAMLマニフェストです。 パッケージ化後、クラスター内にヘルムチャートを配置するのは、ヘルムインストールを実行するのと同じくらい簡単です。 Helm Chartの目的は、コンテナ化されたアプリのデプロイを簡素化することです。 

水平ポッドオートスケーラー – HPAとも呼ばれる水平ポッドオートスケーラーは、レプリカポッドの数を自動的にスケーリングします。 複製されるポッドの量を制御するためにCPUパワーまたはメモリのしきい値を使用するのではなく、オートスケーラーはそれを行います。 HPAは、カスタムしきい値に設定することもできます。

ホストエイリアス –ポッドホストファイルが指定されている場合、このオプションのマッピングをホストファイルに入力できます。 これは、IPアドレスとホスト名の間のオプションのマップです。 ホストエイリアスは、非ホストネットワークポッドでのみ機能します。

画像 –アプリケーションの実行に必要なソフトウェアセットを保持する格納されたコンテナインスタンス。 イメージは、ソフトウェアのパッケージ化方法であり、コンテナのレジストリに保存し、ローカルシステムから提供され、アプリケーションとして実行されます。 メタデータは、何を実行するか、誰がアプリケーションを作成したか、およびその他の情報に関する情報を提供します。

進入 –このAPIオブジェクトは、クラスターの外部で開始するセキュアルートと非セキュアルート(それぞれHTTPSとHTTP)の両方を、クラスター内で実行されているサービスに公開します。 入力は、内部サービスへの外部アクセスを提供します。 入力のタイプには、とりわけ、単一サービスと負荷分散が含まれます。

初期化コンテナ –初期化またはinitコンテナーは通常のコンテナーに相当しますが、initコンテナーは、別のコンテナーが開始できるようになる前に、完了するまで実行する必要があります。 initコンテナは、次のコンテナが開始する前に、他のすべてのinitコンテナと順番に実行する必要があります。 

イスティオ –サービスメッシュであるIstioは、ネットワーク機能用の透過的で言語に依存しない自動化アプリケーション用の最新のネットワーキングレイヤーです。 このサービスメッシュはマイクロサービス通信を維持し、データ共有を可能にします。

ジョブ – Kubernetes Jobオブジェクトは、ポッドの作成と終了のための基本的な機能または命令です。 ジョブが作成されると、ジョブコントローラーは必要なポッドを作成し、ポッドが正常に終了することを確認します。 各ポッドが終了すると、ジョブコントローラーは正常に完了したポッドタスクの数を追跡します。 

クベアドム –このツールは、kubeadminitとkubeadmjoinがKubernetesクラスターを作成するための最良の経路であることをKubernetesに指示するのに役立ちます。 Kubeadmは、実行可能なクラスターを機能させるために必要なアクションを処理します。 Kubeadmは、マシンのプロビジョニングではなく、ブートストラップのみを考慮するように設計されています。 

久部コントローラーマネージャー –コントローラープロセスを実行しているコントロールプレーンのコンポーネント。 複雑さを緩和するために、各プロセスはXNUMXつのバイナリにロールされ、XNUMXつとして実行されます。

kube-apiserver - 見る APIサーバー。

キューブクル – Kubernetes APIサーバーと通信することにより、オブジェクトを作成、検査、更新、および削除するコマンドラインツール。

久部スケジューラー –クラスター管理を担当するコントロールプレーンのコンポーネントのXNUMXつ。 Kube-schedulerは、まだスケジュールされていないポッドを探し、リソースの可用性などの特定の仕様によってノードに割り当てます。 ポッドがノードに割り当てられると、各ノードのkubeletがトリガーされ、ポッドとそのコンテナーが作成されます。

クベレット –クラスター内のすべてのノードで実行されるミニアプリケーション。 一連の命令またはPodSpecsが必要であり、これらの仕様を使用して、各コンテナーが正しく機能していることを確認します。 Kubeletsは、マスターノードから各コンテナーに送信されたアクションを実行します。

kube-proxy –これはKubernetesのネットワークプロキシです。 このサービスは各ノードで実行され、リクエストの転送を処理します。 kube-proxyの主な役割は、iptablesのルールを作成することです。 ポッドのIPアドレスは同じではありませんが、kube-proxyを使用すると、ユーザーはKubernetesの特定のポッドに接続できます。 これは、ローンバランシングの有効化などのアクションにとって特に重要です。

Kubernetes API –Kubernetes機能を提供するアプリ。 これはRESTfulインターフェースで動作し、クラスターの状態を保存します。 つまり、すべてのKubernetesリソースとインテントレコードがオブジェクトとして保存され、APIへのRESTfulオーダーに従って変更されます。 Kubernetes APIを使用すると、ユーザーは管理構成を宣言できます。 ユーザーは、APIを直接操作することも、kubectlなどのツールを使用して操作することもできます。 Kubernetes APIのコアは柔軟性があり、カスタムリソースへの拡張が可能です。

Kubernetesオペレーション(Kops) – Kopsは、クラスターをセットアップするための高速で簡単なオープンソースの方法です。 技術的には、これは「kubectl」クラスターのセットアップ方法です。 Kopsを使用すると、利用可能なクラスターをアマゾンウェブサービス(AWS)とGoogleクラウド(GCP)にデプロイできます。

ラベル –意味のある関連性のある識別属性をオブジェクトに割り当てます。 ラベルはオブジェクトを整理し、サブセットを選択します。

限界範囲 –名前空間内で割り当てられる制限範囲により、コンテナーとポッドのリソース消費を制限または制限できます。 特定の数のオブジェクトタイプのみが必要な場合、制限範囲は、名前空間内のコンテナまたはポッドが要求または消費できるリソースの数を制限します。

ロギング –クラスターまたはアプリケーション内のイベントの記録。 システムログとアプリログは、ユーザーがクラスター内で何が起こっているかを理解するのに役立ちます。 ログは、クラスター内のアクティビティの監視や問題のデバッグに特に役立ちます。

マニフェスト –特定のオブジェクトの望ましい状態の計画。 ユーザーがマニフェストを適用すると、Kubernetesはその目的のオブジェクトの状態を維持します。 すべての構成ファイルは、いくつかのマニフェストを保持できます。 Kubernetesのマニフェストは、作成するすべてのリソースを示しています。たとえば、次のようなものです。

  • デプロイメント
  • サービス/製品
  • ポッド

マニフェストを使用すると、これらのリソースをクラスター内でどのように実行するかを指定することもできます。

マスターノード –名前が示すように、このノードは、クラスター、クラスター状態に関するデータ、および構成を制御するKubernetesオブジェクトを保持します。 マスターノードのKubernetesオブジェクトには、etcd、kube-controller-manager、kube-apiserver、kube-scheduler、cloud-controllermanagerが含まれます。

ミニキューブ –ユーザーがKubernetesをローカルで実行できるようにします。 ユーザーのコンピューター上の仮想メモリファイル内の単一ノードクラスター。 minikubeを使用すると、Windows、macOS、Linuxのいずれを実行していても、自分のPC上でノードをXNUMXつだけ使用してクラスターを実行できます。 minikubeは、Kubernetesを試してみたり、日常の開発作業を実行したりするだけのユーザーや開発者に最適です。

ミラーポッド –静的ポッドを表すkubeletによって使用されるオブジェクト。 kubeletが構成内で静的ポッドを検出すると、KubernetesAPIサーバーでそのポッドオブジェクトを作成しようとします。 ユーザーはAPIサーバーでポッドを表示できますが、そこで制御することはできません。

お名前 –URL内の特定のオブジェクトを参照するユーザー提供の文字列。 同じタイプのXNUMXつのオブジェクトが同時に同じ名前を持つことはできません。 ただし、ユーザーがオブジェクトを削除すると、その名前を使用して新しいオブジェクトを作成できます。 

名前空間 – Kubernetesが、同じ物理クラスター上にある複数の仮想クラスターをサポートするために使用する抽象的なプレースホルダー名。 これにより、クラスターオブジェクトを整理し、ユーザーがそのクラスターのリソースを分割できるようになります。 リソース名は、クラスター内の特定の名前名内で一意である必要がありますが、他の名前名で使用できます。

ネットワークポリシー – Kubernetesポッドには、デフォルトで他のポッドと通信し、他のソースからトラフィックと情報を取得する機能があります。 このKubernetesリソースは、ポッドのグループが他のポッドやネットワークエンドポイントと通信する方法を示しています。 ラベルを使用して、ポッドが選択され、許容されるトラフィックが構成されます。

ノード –ワーカーマシン。 ノードは、個々のクラスターに応じて、仮想または物理のいずれかになります。 ノードには、ポッドを実行するために必要なローカルデーモンがあります。 ノードはコントロールプレーンで管理されます。 ノード上のデーモンには次のものがあります。

  • キューブレット
  • kube-proxy
  • コンテナランタイム

ノード圧力エビクション –ノードに障害が発生しているように見える場合、ノードプレッシャーエビクションにより、必要なノードリソースを再利用するために、事前にkubeletがポッドを終了します。 StatefulSet、Deploymentなどのワークロードリソースがポッドを管理し、交換が必要なポッドをチェックする場合、コントロールプレーン(またはkubeコントローラーマネージャー)は、削除されたポッドごとに新しいポッドを作成します。 

オブジェクト –システムエンティティ。 エンティティはクラスターの状態を表します。 オブジェクトは意図の記録です。 ユーザーがオブジェクトを作成すると、コントロールプレーンは、オブジェクトが表す実際のアイテムの存在を確認します。 オブジェクトは、クラスターのワークロードがどのように見えるか、またはクラスターの望ましい状態をシステムに表します。

永続ボリューム(PV) –クラスターストレージリソース。 Kubernetesは、アプリを実行するコンテナーを管理するだけではありません。 また、クラスターアプリケーションデータも管理します。 永続ボリューム(PV)は、既存のストレージインフラストラクチャからデータストレージを抽象化し、実際にはポッド自体よりも長持ちします。 この機能により、PVはステートフルなポッドを作成できます。

永続ボリュームクレーム(PVC) –ストレージアクセスの要求。 PVCはコンテナ内にマウントされ、必要なストレージ量、アクセス方法、およびリソースの再利用方法を指定します。

ポッド –クラスター上で実行されているコンテナーのセットを表すKubernetesの最小オブジェクト。 通常、ポッドはXNUMXつのプライマリコンテナを実行しますが、ロギングなどの追加機能のためにサイドカーコンテナを追加することもできます。 これらのオブジェクトは通常、デプロイメントによって管理されます。

ポッドの中断 –ポッドの中断は、次のXNUMXつの方法のいずれかで発生します。

  • ユーザーまたはコントローラーがポッドを破壊する
  • 避けられないハードウェア、ソフトウェア、またはシステムエラーが発生しました

避けられない、または避けられないタイプのポッドの中断は、非自発的中断と呼ばれます。 不本意な混乱のいくつかの例は次のとおりです。

  • ノードをバックアップする実際の物理マシン内のハードウェア障害。
  • クラスタ管理者が誤ってインスタンスを削除してしまいました。
  • クラウドプロバイダーで障害が発生します。
  • パニックに陥ったカーネル。
  • クラスタネットワークパーティションにより、ノードが消えます。
  • ノードがリソースを使い果たし、ポッドを削除します。

最後の例を除いて、ほとんどのユーザーはおそらく他の例に精通しています。 それらはKubernetesだけで発生するわけではありません。

その他の中断は自発的と呼ばれ、アプリの所有者が開始できるアクションとクラスター管理者が開始できるアクションが含まれます。 いくつかの典型的な自発的な混乱は次のとおりです。

  • ポッドを管理しているデプロイメントまたは別のコントローラーを削除します。
  • デプロイメントポッドのテンプレートを更新します。これにより、再起動が発生します。
  • ポッドを削除するだけです。

ポッド中断予算(PDB) –ポッドのクラスが許容できる中断の数をユーザーが構成できるため、中断イベントが発生した場合でも、常に正しい数を使用できます。 ポッドの中断によりクラスターが予算を下回ると、予算が維持されるまで操作が一時停止されます。

ポッドのライフサイクル –ポッドにはXNUMXつの異なるフェーズがあります。

  • 掲載予定の求人
  • ランニング
  • 成功した
  • 失敗しました
  • 未知の

ポッドのライフサイクルは、ポッドの存在全体にわたるこれらの状態の順序です。

ポッドフェーズ –ポッドがそのライフサイクルにあるポイントの高レベルの合計。 定義されているXNUMXつの潜在的なポッドフェーズは次のとおりです。

  • 保留中:受け入れられましたが、必要な量のコンテナイメージを待機しています。
  • 実行中:すべてのコンテナーが作成され、ポッドがノードに接続されます。 少なくともXNUMXつのコンテナーが実行中、開始に向けて作業中、または再起動中です。
  • 成功:ポッド内の各コンテナーは正常に終了し、再起動しません。
  • 失敗:ポッド内の各コンテナは終了しましたが、XNUMXつ以上が失敗しました。 ゼロ以外のステータスまたはシステム終了で終了します。
  • 不明:ポッドの状態を判別できません。 通常、ホストポッドとの通信に失敗します。 

ポッドの優先順位 –実稼働負荷では、一部のポッドの重要度が高くなります。 ポッドの優先度により、ユーザーは特定のポッドを他のポッドよりも重要度の低いものよりも優先することができます。

ポッドプリセット –ユーザーが作成時にポッドに情報を配置できるようにするAPIオブジェクト。 その後、プリセットはアドミッションコントローラーによって管理されます。 アドミッションコントローラーは、作成リクエスト時にプリセットを適用します。 最も一般的なプリセットには、次のものがあります。

  • シークレット
  • ボリューム
  • マウント
  • 環境変数

ポッドセキュリティポリシー –ポッドセキュリティポリシーは、ポッドの仕様の機密性の高い側面を制御するクラスターレベルのリソースです。 PodSecurityPolicyオブジェクトは、他の関連フィールドのデフォルトに加えて、システムがそれを受け入れるために特定のポッドを実行する必要がある特定の条件のセットを定義します。 

先取り –ポッドは作成後にキューに入れられます。 ポッドの優先度とプリエンプションがオンになっています。 スケジューラーはこのキューからポッドを取得すると、クラスター内のノードにポッドをスケジュールしようとします。 ポッドをスケジュールできない場合、スケジューラーはプリエンプションロジックを使用して、優先度の低いポッドを一時的に停止し、保留中のポッドをスケジュールできるようにします。

プロキシ – kube-proxyは、Kubernetesサービスモデルの一部を実装するクラスター内のすべてのノードで実行されるネットワークプロキシです。 Kube-proxyは、各ノード内のネットワークルールをサポートします。 ネットワークルールにより、ネットワークセッションがクラスター内にあるかどうかに関係なく、ネットワークはポッドと通信できます。 

サービス品質(QoS)クラス –Kubernetesがスケジューリングまたはエビクションの観点からポッドの優先度を決定するのに役立つ概念。 これらのクラスは、ポッドの作成時に割り当てられ、リソースの要求と制限によって決定されます。 割り当てることができるXNUMXつのサービス品質クラスは次のとおりです。

  • 保証された
  • 破裂性
  • 最大限の努力

RBAC – Kubernetes APIを介して、RBACは承認の決定を管理します。 これにより、管理者レベルのユーザーは、役割ごとに動的アクセスポリシーを構成できます。 ロールには権限ルールが含まれています。 ロールバインディングは、定義された各権限を特定のユーザーセットに付与します。

レプリカセット –適切な量のレプリカが実行されていることを確認するために使用されるコアKubernetesコントローラー。

ReplicationController –クラスターでの実行を許可する必要がある正確なポッドコピーの数を制御します。 管理者が許可されるレプリカの数を定義した後、ポッドに障害が発生したり、削除されたり、展開時に開始されたレプリカが多すぎたりしても、コントロールプレーンはクラスターコンプライアンスを維持します。

リソースクォータ –名前空間内にタイプごとに作成できるオブジェクトの数に制限を設けます。 また、プロジェクト内で許可されるコンピューティングリソースの量を超えないようにします。

シークレット –セキュリティアカウントの資格情報。 シークレットは、機密データの小さなパケットを含むオブジェクトです。 名前が示すように、KubernetesのSecretsは、次のような機密性の高い情報を保存および管理できるツールです。

  • ログイン情報
  • OAuthトークン
  • SSHキー

シークレットがない場合、この機密データはポッドの仕様または画像に配置される可能性があります。

セキュリティコンテキスト –ポッドまたはコンテナのセキュリティコンテキストは、特権とアクセス制御の概要を示します。 随意アクセス制御は、ファイルなどの特定のオブジェクトへのアクセス許可を制限し、ユーザーのIDやグループIDに基づいています。 セキュリティコンテキストは、特権の有無にかかわらず実行するように設定できます。 

セレクタ –ユーザーがリソースのリストをラベルでフィルタリングできるようにします。 Kubernetesのセレクターを使用すると、ラベル値と割り当てられたリソースフィールドに基づいてリソースを選択できます。 Excelスプレッドシートを使用するときに適用するフィルターのように考えてください。 Selectorを使用すると、類似したラベルを持つオブジェクトの詳細だけをフィルタリングできます。 

サービス –ポッドセットで実行されているアプリケーションをネットワークサービスとして公開する概念的な方法。 サービスの対象となるポッドセットは、(通常)セレクターによって選択されます。 ユーザーがポッドを追加または削除すると、セレクターに一致するポッドセットが変更されます。 このサービスは、ネットワークトラフィックが適切なポッドセットに転送されるようにします。

サービスアカウント –ポッド内で実行されているプロセスにIDを付与します。 クラスタにアクセスするポッドプロセスは、「デフォルト」などの特定のサービスアカウントとしてサーバーによって検証されます。 ユーザーがポッドを作成するときに、特定のサービスアカウントが指定されていない場合、その名前空間内で「デフォルト」として自動的に割り当てられます。

サービスカタログ –このAPI拡張機能を使用すると、Kubernetesクラスターで実行されるアプリで、クラウドプロバイダーが提供するデータストアサービスなどの外部管理ソフトウェアを使用できます。 サービスカタログは、特定の各サービスがどのように管理または作成されたかを理解しなくても、ユーザーが外部管理サービスの一覧表示、プロビジョニング、およびバインドを行うのに役立ちます。 

シャッフルシャーディング –キュー要求を割り当てる手法。 シャッフルシャーディングは、キューの数をハッシュするよりも、低強度のフローを高強度のフローから分離するのに適した軽快な手法です。

サイドカーコンテナ –メインコンテナのサポート拡張。 サイドカーコンテナは、必要な数のメインコンテナと組み合わせることができ、メインコンテナの機能を強化します。 たとえば、サイドカーコンテナは、システムログの処理または監視を支援するために、メインコンテナに追加するのに適しています。

ステートフルセット –ポッドセットのデプロイとスケーリングを管理するKubernetesコントローラー。 このコントローラーによって管理されるポッドには、一意のIDが提供されます。 このIDは、ポッドのスケジュールを変更する必要がある場合に使用されます。 

静的ポッド –通常のポッドと同様に、静的ポッドはサーバーではなく、kubeletによってノード上で直接管理されます。 kube-schedulerは静的ポッドを無視します。つまり、ノードに障害が発生しても、ポッドは終了または削除されません。

ストレージクラス –管理者がストレージに使用できるさまざまなオプションを説明する方法。 StorageClass仕様の重要なフィールドは次のとおりです。

  • プロビジョニング担当者
  • パラメーター
  • ReclaimPolicy
  • VolumeBindingMode

永続ボリュームに動的プロビジョニングが必要な場合は、これらのStorageClass用語を使用できます。

Systcl –管理者がカーネルの属性または設定を変更または変更する方法。 'system control'の略であるsysctlは、次のようなシステムカーネル属性を読み取ったり変更したりできる一部のオペレーティングシステムのユーティリティです。

  • バージョン番号
  • 最大制限
  • セキュリティ設定

コンパイルされたプログラムでは、システム呼び出しと管理者コマンドの両方として使用できます。 Sysctlは、インタラクティブに使用することも、スクリプトを作成するために使用することもできます。

汚染 –コアKubernetesオブジェクト。 XNUMXつの必要なプロパティで構成されます。

  • キー
  • 効果

汚染は、ポッドがノードまたはノードグループでスケジュールされるのを防ぎます。 特別なハードウェアを備えたノードが予約されている場合、クラスター内で既に実行されているソフトウェアのライセンスが付与されていない場合、およびその他の理由で特に役立ちます。 汚染は、これらのノードがスケジューリングに使用できないことをスケジューラーに警告します。 汚染と許容範囲は連携して、ポッドからノードへのスケジューリングをより適切に制御します。

寛容 –コアKubernetesオブジェクト。 XNUMXつの必要なプロパティで構成されます。

  • キー
  • 効果

汚染の反対に、許容値はノードまたはノードグループでのポッドスケジューリングを可能にします。 許容値により、ポッドは汚染を無視でき、PodSpec内に収容されます。

UID –オブジェクト識別のためにKubernetesシステムによって生成された文字列。 一意の識別子。

垂直ポッドオートスケーラー –このツールは、各アプリケーションが正確に適切なサイズになるように、ポッドのCPUとメモリの予約を調整します。 これらの調整は、クラスターがリソースをより適切に使用するのに役立ち、他のポッドのCPU処理とメモリを解放します。 

音量 –データディレクトリ。 ボリュームには、ポッド内のコンテナからアクセスできます。 ボリュームには、ポッドと同じ長さの寿命があります。 その結果、ボリュームはポッドで実行されているコンテナーよりも長生きし、データはコンテナーの再起動中も保持されます。

ワーカーノード– Kubernetesノード。 見る ノード。 Kubernetesクラスターは、ノードとも呼ばれるワーカーマシンセットで構成されます。 これらのノードは、コンテナ化されたアプリを実行します。 すべてのクラスターに少なくともXNUMXつのワーカーノードがあります。 ワーカーノードには、アプリケーションのワークロードポッドが含まれています。 各クラスターのmodとワーカーノードは、コントロールプレーンによって管理されます。

ワークロード –Kubernetesで実行されるアプリはワークロードです。 ワークロードがXNUMXつだけのコンポーネントであるか、複数のコンポーネントが連携して動作するかは関係ありません。 Kubernetesはポッドセット内でワークロードを実行します。 ポッドは、クラスター内で実行されているコンテナーのセットです。 すべてのクラスターがワークロードを表します。