これは何？
Kubernetes ドキュメントの Standardized Glossaryの翻訳案として作成しました。違和感の有無や、より分かりやすい説明のご提案がありましたらコメント等でご指摘いただければと思います。
なお、対象ドキュメントのバージョンは v1.11 です（https://kubernetes.io/docs/reference/glossary/?all=true）
基本用語集（Standardized Glossary）
この用語集が目指すのは、広範囲にわたる Kubernetes 技術から、共通する項目の一覧化です。内容は Kubernetes 特定の技術用語だけでなく、有益な内容をもたらす一般用語も含みます。
Annotation（注釈）
オブジェクトに対して識別する用途以外のメタデータ属性を付与するために使う１対の鍵と値（キー・バリュー）です。
annocation（注釈）内のメタデータは、小さくても大きくても構いませんし、構造化あるいは非構造化でも構いません。また、ラベルでは許可されない文字も含められます。ツールやライブラリのようなクライアントがメタデータを読み出せます。
Application Architect（アプリケーション設計者）
アプリケーションのハイレベルな設計に責任を持つ人です。
設計者（アーキテクト）が請け負うのは、アプリケーションの実装にあたり、拡大縮小でき（スケーラブル）で保守性（メンテナンス性）が高い手法で周辺のコンポーネント（構成要素）とやりとりできるようにすることです。コンポーネントの周辺にはデータベース、ログ記録、インフラストラクチャ、マイクロサービスを含みます。
Application Developer（アプリケーション開発者）
Kubernetes クラスタ内で実行するアプリケーションを書く人です。
アプリケーション開発者はアプリケーションの一部に対して集中します。この集中する範囲は、規模によって著しく異なります。
Approver（承認者）
Kubernetes コードへの貢献をレビューおよび承認する人です。
コードレビューとはコード品質と正確さに集中し、承認（approval）は貢献を全体的な視点で受け入れるかどうかに集中します。全体的な視点には前方・後方互換、API とフラグの慣例遵守、わずかな性能と正確さの問題、他のパーツやシステムとの相互作用などを含みます。承認者の立場は、コードベースの一部であると範囲が定められています。
CLA (Contributor License Agreement：貢献者許諾合意)
オープンソース・プロジェクトに貢献する 貢献者（コントリビュータ） に与えらられる許諾（ライセンス）です。
CLA は貢献された素材や知的財産（IP：intellectual property）に関連する法的な論争を回避するために使います。
Certificate（証明書）
暗号化された安全なファイルであり、Kubernetes クラスタへの接続確認に使います。
証明書によって Kubernetes クラスタ内にあるアプリケーションが Kubernetes API へ安全に接続できるようにします。証明書の認証があるクライアントが API へアクセスできるようになります。
Cloud Controller Manager（クラウド・コントローラ・マネージャ）
クラウド・コントローラ・マネージャは 1.8 ではアルファ機能（訳者注：実験的な導入）です。今後のリリースでは、あらゆるクラウドで Kubernetes と統合するのに望ましい手法となります。
Kubernetes v1.6 から cloud-controller-manager という名前の新しいバイナリが入っています。cloud-controller-manager はクラウド特有の制御ループを組み込むためのデーモンです。クラウド固有のコントロール・ループとは、元々は kube-controller-manager に入っていたものでした。クラウド事業者の開発やリリースは Kubernetes プロジェクトとは異なるため、クラウド固有のコードを cloud-controller-manager バイナリに抽象化することで、クラウド事業者はコアの Kubernetes コードとは独立して進化できるようになります。
Cloud Provider（クラウド・プロバイダ）
クラウド・プロバイダ（提供事業者）とは Kubernetes クラスタを実行可能なクラウドコンピューティング基盤（プラットフォーム）を提供する会社です。
クラウド・プロバイダもしくはかつてのクラウド・サービス・プロバイダ（CSP）とはクラウドコンピューティング基盤（プラットフォーム）を提供します。インフラストラクチャ（システム基盤）としてのサービス（IaaS）、プラットフォームとしてのサービス（PaaS）といったサービスを提供できます。クラウド・プロバイダは Kubernetes クラスタをホストする（提供する）だけではなく、クラスタとやりとりするサービスも提供します。
Cluster Architect（クラスタ・アーキテクト）
１つまたは複数の Kubernetes クラスタに関与する基盤を設計する人です。
クラスタ・アーキテクト（設計者）は分散システムにおけるベスト・プラクティスを考慮します。例えば、高可用性や安全性です。
Cluster Operator（クラスタ・オペレータ）
クラスタの設定、管理、監視をする人です。
主にクラスタの正常稼働を維持する責任があり、定期的な保守活動やアップデートが必要になる場合があります。
メモ：クラスタ・オペレータは Kubernetes API を拡張する Operator パターン とは異なります。
Cluster（クラスタ）
マシンの集まりであり、ノードと呼ばれ、Kubernetes によって管理されるコンテナ化したアプリケーションを実行します。
クラスタには少なくとも１つのマスタ・ノードを含む、複数のワーカ・ノードがあります。
Code Contributor（コード貢献者）
Kubernetes オープンソース・コードベースに対する開発やコードを貢献する人です。
また、１つまたは複数の分科会 (SIG) に参加するアクティブな コミュニティ・メンバ も含みます。
ConfigMap（コンフィグマップ）
機密ではないデータをキーバリューの組で保管するための API オブジェクトです。用途は環境変数、コマンドラインの引数、ボリューム における設定ファイルなどです。
コンテナ・イメージ と環境固有の設定を分離できるので、アプリケーションを簡単に移動可能（ポータブル）にします。機密データを保管する場合は Secret（シークレット） を使います。
Container Environment Variables（コンテナ環境変数）
コンテナ環境変数は名前と値の組であり、ポッドの中で実行するコンテナ内で使う情報を提供します。
コンテナ化したアプリケーションの実行に必要な情報と共に、[コンテナ] コンテナ に対する重要な情報をコンテナ環境変数を通して提供します。たとえば、ファイルシステムや、コンテナ自身の情報や、サービスのendポイントなど他のクラスタ・リソースなどです。
Container（コンテナ）
軽量で可搬性があり、ソフトウェアとソフトウェアに依存するすべてを含む実行可能なイメージです。
コンテナはアプリケーションと根底にあるホスト基盤（インフラ）を切り離すため、異なるクラウドや OS 環境においても展開（デプロイ）を速くし、簡単にスケール（規模の拡大縮小）します。
Contributor（貢献者：コントリビュータ）
Kubernetes プロジェクトやコミュニティに役立つコードやドキュメントや時間で貢献をする人です。
貢献（コントリビューション）にはプル・リクエスト（PR）、issue、フィードバック、 分科会 (SIG) への参加や、コミュニティ・イベントの取りまとめも含みます。
Controller（コントローラ）
クラスタ共有状態の監視を通しながら、 apiserver とクラスタの現在状態を、期待状態へと移行を試みる制御ループ（control loop）です。
現在 Kubernetes が提供しているコントローラには、replication controller（レプリケーション・コントローラ）、endpoints controller（エンドポイント・コントローラ）、namespace controller（名前空間コントローラ）、serviceaccounts controler（サービスアカウント・コントローラ）があります。
CronJob（クロン・ジョブ）
定期的にスケジュールして実行する Job（ジョブ） を管理します。
Cronjob オブジェクトは crontab ファイルの行と似ており、 Cron 形式でスケジュールを指定します。
CustomResourceDefinition（カスタム・リソース定義）
リソースを定義するカスタム・コードであり、Kubernetes API サーバに完全なカスタム・サーバを構築しなくても追加できます。
カスタム・リソース定義によって、公開済みの API リソースが自分の必要性に一致していなければ、Kubernetes API を環境に応じて拡張できるようになります。
DaemonSet（デーモンセット）
クラスタ 内のノード群を横断して ポッド の複製が動くようにします。
ログ収集や監視アラート・エージェントのように展開用（デプロイ）システム・デーモンが使うもので、通常はすべてのノード 上で動作します。
Deployment（デプロイメント）
複製されたアプリケーションを管理する API オブジェクトです。
ポッド の複製（レプリカ）とポッドは、クラスタのノード全体にわたって配布されます。
Developer （開発者）（あいまいさ回避）
アプリケーション開発者 、 コード貢献者 、 プラットフォーム開発者 を指す場合があります。
頻繁に使われる用語であり、文脈によって異なる意味を持ちます。
Downstream （ダウンストリーム）(あいまいさ回避)
Kubernetes エコシステムにおいては、コアの Kubernetes コードベースかフォーク（分岐）したリポジトリに対するコードに言及する場合があります。
- Kubernetes コミュニティ の場合：エコシステム全般、他のコード、依存するサードパーティ製ツールの場合、会話における downstram（ダウンストリーム） とは、たいていコアの Kubernetes コードベースに対してを意味します。例えば、Kubernetes の新機能を採用するにあたり、機能性を改善するためにはアプリケーションの ダウンストリーム（downstream） が適用されているかもしれません。
- GitHub や git の場合：通常はフォーク（分岐）したリポジトリを downstream （ダウンストリーム：下流）として参照します。一方でソース・リポジトリは upsteam（アップストリーム：上流）とみなします。
Dynamic Volume Provisioning（動的なボリュームの自動準備）
ユーザは記憶領域の自動作成を要求できます。
動的な自動準備（プロビジョニング）によって、クラスタの管理者は記憶領域（ストレージ）の事前準備を不要にします。そのかわりに、ユーザの要求によって記憶量期を自動的に準備します。動的なボリュームの事前準備は API オブジェクト StorageClass をベースとし、ボリューム・プラグイン が ボリューム の自動展開とボリューム・プラグインによって与えられたパラメータを指定する時に参照するために使います。
Helm Chart（ヘルム・チャート）
Helm（ヘルム）ツールによって管理される、Kubernetes リソースを事前に設定済みのパッケージです。
チャートは Kubernetes アプリケーションを作成と共有を再現可能にします。１つのチャートによって、たとえば memcached ポッドのような簡単なものの展開（デプロイ）だけでなく、HTTP サーバ、データベース、キャッシュなどがあるウェブ・アプリケーション・スタックすべてのような複雑なものの展開にも使えます。
Horizontal Pod Autoscaler（水平ポッド自動スケール機能：HPA）
CPU 使用率の目標や任意のメトリック（計測指標）目標に基づき、ポッドの複製数を自動的にスケール（拡大）する API リソースです。
HPA は Replication Controller（レプリケーション・コントローラ） 、 Deployments（デプロイメント） やr Replica Set（レプリカ・セット）と通常は使います。ただし、 DaemonSets（デーモンセット） . のようなオブジェクトはスケールできないので割り当てできません。
Image（イメージ）
コンテナの実体を保管するもので、アプリケーションを実行するために必要なソフトウェアの集まりを保有します。
ソフトウェアをパッケージ化する手法であり、これによってコンテナ・レジストリへの保管や、ローカル・システムへのダウンロード、アプリケーションとしての実行が可能になります。イメージにはメタデータ（meta data）を含めることが可能です。メタデータは何を実行するか、何を構築したか、あるいはその他の情報を示すのに利用できます。
Ingress（イングレス）
クラスタ内のサービスに外部からの接続、通常は HTTP を管理する API オブジェクトです。
Ingress は負荷分散、SSL ターミネーション（認証機能） 、名前をベースとした仮想ホストも提供できます。
Init Container（初期化コンテナ）
１つまたは複数の初期化コンテナは、あらゆるアプリケーション・コンテナを実行する前に終了する必要があります。
初期化（init）コンテナとは通常のアプリケーション・コンテナのようなものですが、１点が異なります。それは初期化コンテナはあらゆるアプリケーション・コンテナを開始するまでに実行を完了しなくてはいけません。初期化コンテナは連続して実行します。つまり、各初期化コンテナは次の初期化コンテナを実行する前に終了する必要があります。
Istio（イスティオ）
マイクロサービスを統合し、トラフィックの流れを管理し、ポイシーを適用し、遠隔測定したデータを統合するために、統一した手法を提供する オープンなプラットフォーム（Kubernetes 固有ではありません）です。 [-]
Istio の追加にはアプリケーション・コードの変更を必要としません。サービスとネットワークの間にある基盤（インフラ）のレイヤとは、サービスを展開（デプロイ）する時に組み合わせるものであり、通常はサービス・メッシュと呼ばれます。Istio はコントロール・プレーンで根底にあるクラスタを管理するプラットフォームを抽象化します。
Job（ジョブ）
有限もしくはバッチのタスク完了するまで実行します。
１つまたは複数の ポッド オブジェクトを作成し、指定した数のオブジェクトを完全に終了できるようにします。ポッドが無事に完了すると、ジョブの処理進行も完了します。
Kops
本番段間での高可用性 Kubernetes クラスタを作成、破棄、更新、運用に役立つコマンドライン・ツールです。メモ：公式にサポートしているのは AWS のみであり、GCE と VMware vSphere はアルファ版です。
kops はクラスタに次のものを自動構築（プロビジョン）します：
- 完全にインストールを自動化
- DNS をベースとしたクラスタ認識
- 自己修復（self-healing）：オートスケーリング・グループ内のすべてに対応
- 限定的な OS のサポート（Debian が推奨、Ubuntu 16.04 はサポートされており、CentOS & RHEL は初期段階のサポート）
- 高可用性（HA）のサポート
- 直に自動構築（プロビジョン）するか Terrafrom マニフェストを作成する機能がある
Kubeadm を使って構築ブロック（building block）として自分でクラスタを構築できます。 kops は kubeadm の動作の上に成り立っています。
Kubeadm
Kubernetes を迅速にインストールし、安全なクラスタをセットアップします。
kubeadm を使ってコントロール・プレーンとワーカ・ノード構成要素の両方をインストールできます。
Kubectl
Kubernetes API サーバと通信するコマンドライン・ツールです。
kubelet を使って Kubernetes オブジェクトの作成・調査・更新ができます。
Kubelet
クラスタ内の各ノードで実行するエージェント。ポッドの中でコンテナを確実に実行します。
kubelet は PodSpec のセットを取得し、PodSpec に記述されたコンテナが確実に正常に稼働し続けるようにするための、様々な仕組みを提供します。kubelet は Kubernetes によって作成されていないコンテナを管理しません。
Kubernetes API
Kubernetes の機能性を提供する RESTful インターフェースの提供と、クラスタの状態を保管するアプリケーションです。
Kubernetes リソースと “records of intent”（意図の記録）がすべて API オブジェクトに保管され、さらに RESTful な API コールを経由して変更可能です。API は宣言型の手法によって設定を管理できます。ユーザは Kubernetes API と直接やりとりをするか、 kubectl のようなツールを経由してやりとりできます。コアの Kubernetes API は柔軟性があり、また、カスタム・リソースをサポートするために拡張可能です。
Label（ラベル）
オブジェクトを識別するための、ユーザにとって意味があるか関係のある属性です。
ラベルはキーとバリューの組み合わせで、ポッド などのオブジェクトに割り当てます。これらはオブジェクトの体系化やサブセット（小集団）の選択に使います。
Maintainer（メンテナ）
Kubernetes の複数の領域で活動的である経験豊富な貢献者 です。プロジェクトの GitHub リポジトリを横断して所有権と書き込み権限を持つ人です。
メンテナはプロジェクトの全体的にわたり、プロジェクトが健全に維持され成功するように働きます。また、コード開発と組織全体の幅広く影響の両方において、多大な貢献を行います。
Managed Service（マネージド・サービス）
サードパーティ・プロバイダが保守を提供するソフトウェアです。
マネージド・サービスの例は AWS EC2、Azure SQL Database、GCP Pub/Sub ですが、アプリケーションによって使われうるあらゆるソフトウェア提供が該当します。 Service Catalog（サービス・カタログ） プロバイダは Service Brokers（サービス・ブローカー） によって提供されるマネージド・サービスの一覧表示、自動環境構築（プロビジョン）、サービス稼働を提供します。
Member（メンバ）
K8s コミュニティにおいて継続的に活動している貢献者 です。
メンバーは issue や Pull Request を割り当てられることがあり、GitHub チームをを押して SIG（分科会） に参加します。メンバーの Pull Request によって事前送信テストが自動的に走ります。メンバはコミュニティに対する活動的な貢献者であることが期待されます。
Minikube
Kubernetes をローカルで実行するためのツールです。
Minikube はコンピュータ上の仮想マシン内に単一ノードのクラスタを実行します。
Namespace（名前空間：ネームスペース）
Kubernetes が使う抽象概念であり、同じ物理クラスタ 上に複数の仮想クラスタをサポートするためです。
名前空間の用途はクラスタ内にあるオブジェクトの体系化と、クラスタのリソースを分割する手法の提供です。名前空間内でのリソースの名前はユニーク（一意）である必要がありますが、名前空間は越えての影響は及ぼしません。
Name（名前）
クライアントに提供する文字列で、 /api/v1/pods/some-name のようなリソース URL でオブジェクトを参照します。
同時に名前で指定できるオブジェクトは１つのみです。しかしながら、オブジェクトの削除時は、同じ名前でオブジェクトを作成できます。
Network Policy（ネットワーク・ポリシー）
ポッドのグループがどのようにしてお互いに通信するか、あるいは、他のネットワーク・エンドポイントと通信するかの指定です。
どのポッドがお互いに通信できるかどうか、どの名前空間との通信が許可されているか、どのポート番号に対して各ポリシーを適用するかといった設定をするために、ネットワーク・ポリシーの宣言型の設定が役立ちます。 NetworkPolicy リソースは対象ポッドを選択するのにラベルを使い、選択したポッドに対しては、何の通信を許可するかを指定するルールを定義します。ネットワーク・ポリシーの実装はネットワーク・プロバイダが提供するネットワーク・プラグインがサポートしているものです。ネットワーク・リソースの作成にあたり、コントローラの実装をしていしなければ、何の影響も及ぼさないのでご注意ください。
Node（ノード）
ノードは Kubernetes におけるワーカ・マシン（作業用マシン）です。
ワーカ・マシン（作業用マシン）は仮想マシンもしくは物理マシンであり、クラスタに依存します。ポッド を実行するために必要な サービス を保持し、マスタ構成要素（コンポーネント）によって管理されます。ノード上の サービス には Docker 、kubelet、kube-proxy を含みます。
Persistent Volume Claim（持続型領域の要求）
記憶領域（ストレージ）リソースを PersistentVolume（持続型領域）として要求すると、コンテナではボリューム（領域）としてマウントできます。
記憶領域（ストレージ）の容量を指定するには、記憶領域（ストレージ）にどのように接続するか（読み込み専用、読み書き可能、あるいは両方いずれでもない）と、どのように要求するか（保持し続ける、再利用する、削除するか）によります。記憶領域（ストレージ）自身の詳細については PersistentVolume の仕様にあります。
Persistent Volume（持続型領域：パーシステント・ボリューム）
クラスタ内で記憶領域（ストレージ）の構成要素を表す API オブジェクトです。個々の Pod のライフサイクルとは切り離して一般的に利用できるプラガブル（着脱可能）なリソースです
持続型領域（PersistentVolue：PV）は API を提供しており、どのように記憶領域を提供するか、どのように消費するかの詳細を抽象化します。記憶領域を事前に作成しておく場合（静的な環境自動構築）には、持続型領域が直接使われます。あるいはオンデマンドに（必要に応じて）記憶領域が必要な場合には、持続型領域の要求（PersistentVolumeClaims）が代わりに使われます。
Platform Developer（プラットフォーム開発者）
Kubernetes プラットフォームを各プロジェクトの必要性に一致するようカスタマイズする人です。
プラットフォーム開発者とは、たとえば Custom Resources（カスタム・リソース） や 統合レイヤによる拡張 Kubernetes API を使い、Kubernetes のインスタンスにプラットフォームのアプリケーションに特化した機能性を追加します。また、プラットフォーム開発者のいくつかは 貢献者 でもあり、Kubernetes コミュニティに対する貢献は、開発を拡大しています。その他の開発は、ソースが非公開な商用もしくはサイト固有の拡張です。
Pod Security Policy（ポッド・セキュリティ・ポリシー）
ポッドの作成と更新時に、粒度の高い認証を有効化します。
クラスタ・レベルのリソースで、セキュリティ管理に細心の注意を払うべき対象がポッドの設計です。 PodSecurityPolicy オブジェクトで、システムに受け入れられるようにするためにポッドの実行を必須にしたり、関連するフィールドをデフォルトにしたり、一連の状況を定義します。ポッド・セキュリティ・ポリシーの管理はオプションのコントローラと並んで実装されています。
PodPreset（ポッド・プリセット）
シークレットやボリューム・マウントや環境変数といった情報を、ポッドの作成時に投入するための API オブジェクトです。
このオブジェクトでは標準セレクタを使って情報を導入するためのポッドを選択します。これにより podspec 定義は環境に依存せず、環境固有の設定とは切り離せるようにします。
Pod（ポッド）
最小かつ最も単純な Kubernetes オブジェクトです。ポッドはクラスタ上で実行する コンテナ の集まりを意味します。
ポッドは主として単一のプライマリ・コンテナが実行するセットアップします。また、オプションでサイドカー・コンテナも実行します。サイドカー・コンテナとは、ログ記録などの補助的な機能をポッドに追加します。ポッドは Deployment（デプロイメント） によって共通管理されます。
RBAC (Role-Based Access Control：役割に応じたアクセス制御)
認証の可否を管理するにあたり、管理者が Kubernetes API を通してアクセス・ポリシーを動的に設定変更できるようにします。
RBAC は権限のルールを含む role（ロール：役割） と、ユーザのセットに対して役割の定義に応じて権限を与える role bindings（役割の割り当て） を使います。
ReplicaSet（レプリカ・セット）
ReplicaSet（レプリカ・セット）は次世代のレプリケーション・コントローラ（複製制御）です。
ReplicaSet はReplicationController（レプリケーション・コントローラ）のように、指定したポッドの複製（レプリカ）を同時に実行中にします。Replication Contrller（レプリケーション・コントローラ）がサポートしているのは equality-based selector 要求であるのに対し、ReplicaSet はラベル・ユーザ・ガイドに説明がある新しい set-based selector 要求をサポートしています。
Replication Controller（レプリケーション・コントローラ）
ポッドで指定したインスタンス数を常に実行中にするための Kubernetes サービスです。
ポッドに対して設定されている値に基づいて、実行しているポッドのインスタンスを自動的に追加または削除します。これにより、ポッドを削除するか多くのポッドを間違って作ったとしても、指定した数のインスタンスを常に返します。
Resource Quotas（リソース制限）
名前空間 ごとに、リソース使用量の合計に上限を設けます。
オブジェクトの量の上限とは、名前空間内で作成されるものだけでなく、プロジェクト内のリソースによって消費される可能性がある合計リソース量も含みます。
Reviewer（レビュアー）
プロジェクトの一部として品質と正確さのためにコードをレビューする人です。
レビュアーはコードベースとソフトウェア工学原則のどちらにも熟知しています。レビューアの割り当てられている範囲はコードベースの一部です。
SIG (special interest group：分科会)
進行中の一部や大きな Kubernetes オープンソース・プロジェクトの側面を適切に管理する コミュニティ・メンバ です。
SIG 内のメンバは推進している特定領域における興味を共有します。たとえばアーキテクチャや、API 機構、ドキュメントです。SIG は SIG 統制 ガイドラインに従う必要がありますが、同時の貢献ポリシーとコミュニケーション手段を持てます。
詳しい情報は kubernetes/community リポジトリと、現在の SIG とワーキンググループ 一覧 をご覧ください。
Secret（機密情報：シークレット）
パスワード、OAuth トークン、ssh 鍵のような機密事項を扱う情報を保管します。
機密情報をどのように制御して使うかどうかや、偶発的な漏洩リスクを減らすための情報は 暗号化 にあります。ポッド は機密情報をボリュームでマウントしたファイルとして参照するか、kubelet で pod.Secrets にあるイメージを取得して、秘密のデータと秘密ではないデータ用の ConfigMaps に使うと役立つでしょう。
Security Context（セキュリティ・コンテキスト）
securityContext フィールドはポッドやコンテナに対する権限やアクセス制御設定を定義します。これには実行時の UID と GID も含みます。
ポッド (すべてのコンテナに適用) やコンテナの securityContext は、のコンテナ・プロセスが使うユーザ（runAsUser）、グループ（fsGroup）、ケーパビリティ、特権設定、セキュリティ・ポリシー（SELinux/AppArmors/Seccomp）の指定に使います。
Selector（セレクタ）
ユーザはラベルに基づくリソースの一覧をフィルタできます。
Selector（セレクタ）は ラベル でリソース一覧からフィルタを使って問い合わせできます。
Service Account（サービス・アカウント）
ポッド 内で実行するプロセスの同一性を提供します。
ポッド内のプロセスがクラスタへ接続する時は、API サーバによって個々のサービス・アカウントとして認証されます。例えば default です。ポッドの作成時にサービス・アカウントを指定しなければ、自動的に 名前空間 と同じサービス・アカウントがデフォルトで割り当てられます。
Service Broker（サービス・ブローカー）
サードパーティによって提供および保守されているマネージド・サービス 一式のエンドポイントです。
サービス・ブローカー は Open Service Broker API spec を実装し、マネージド・サービスで使うためのアプリケーションのために共通するインターフェースを提供します。サービス・カタログ はサービス・ブローカーによって提供されているマネージド・サービスを一覧表示、環境の自動構築（プロビジョン）利用可能にするための手段を提供します。
Service Catalog（サービス・カタログ）
Kubernetes クラスタ内で実行するアプリケーションが、クラウド事業者が提供するデータストア・サービスのように、外部で管理されているソフトウェア提供を簡単に利用可能にするための拡張 API です。
Service Brokers（サービス・ブローカー） が提供する 外部の Managed Services（マネージド・サービス） を一覧、環境の自動構築（プロビジョン）、利用可能にするために、各サービスの作成や管理の仕方に関する詳細な知識を必要としない手段を提供します。
Service（サービス）
ポッドのセットなどがアプリケーションに接続できる方法を記述する API オブジェクトです。ここではポート番号や負荷分散も記述できます。
アクセスポイントはクラスタの内部または外部です。
StatefulSet（ステートフルセット）
ポッド（Pod） の集まりの展開（デプロイ）と拡大縮小（スケーリング）を管理し、 かつ、順序づけ（ordering）と一意性（uniqueness）の保証 をポッドに対して行います。
Deployment（デプロイメント） のように、StatefulSet は同一のコンテナ spec をベースにしているポッドを管理します。Deployment と違うのは、StatefulSet は各ポッドの厄介な自己同一性を管理します。ポッドは同じ spec から作成されていますが、お互いを交換できません。つまり、それぞれのポッドは再スケジューリングの間でも一貫した識別子を持ちます。
StetefulSet は他のあらゆる Controller（コントローラ）と同じパターンの元で稼働します。StatefulSet オブジェクト で期待状態（desired state）を定義し、 現在の状態からそこ（期待状態）に到達するよう必要な更新を StatefulSet コントローラ が行います。
Storage Class（ストレージ・クラス）
ストレージ・クラスは管理者のために異なる利用可能なストレージ型（タイプ）を記述する手段を提供します。
クラスタ管理者がサービス品質レベル、バックアップ方針、あるいは任意のポリシーを決めるときに、ストレージ・クラスを割り当てられます。各ストレージ・クラスに provisioner（プロビジョナ）、 parameters（パラメータ）、 reclaimPolicy（再要求ポリシー） のフィールド（項目）を含みます。これらは Persistent Volume（持続型領域） と一緒に使われるもので、動的にプロビジョン（自動構築）する時にクラスが必要となります。ユーザは StorageClass オブジェウトの名前を使い、個々に使うクラスを要求できます。
UID
オブジェクトを一意に識別するために、Kubernetes システムが生成した文字列です。
Kubernetes クラスタで作られたすべてのオブジェクトは、存在し続ける間中、常に明確に識別する UID を持ちます。これは過去に存在した似たようなオブジェクトとを明確に区別する意図があります。
Upstream （アップストリーム）(あいまいさの回避)
コアの Kubernetes あるいはリポジトリがフォークしたソース・リポジトリを言及している可能性があります。
- Kubernetes コミュニティ の場合：エコシステム全般、他のコード、依存するサードパーティ製ツールの場合、会話における upstream（アップストリーム） とは、たいていコアの Kubernetes コードベースを意味します。例えば コミュニティ・メンバ が upstream への移行を提案する場合があるでしょう。これはプラグインやサードパーティ製のツールではなく、コアのコードベースの移行を意味します。 * GitHub や git の場合：通常はソース・リポジトリを upstream （アップストリーム：上流）として参照します。一方でフォーク（分岐）したリポジトリは downsteam（ダウンストリーム：下流）とみなします。
Volume Plugin（ボリューム・プラグイン）
ボリューム・プラグインは ポッド 内でのストレージ統合を有効化します。
ボリューム・プラグインは ポッド が使うためのストレージ・ボリューム（記憶領域）をアタッチ（訳者注：領域をポッドから認識できるようにする）およびマウント（訳者注：ファイルシステムとして読み書き可能にする）します。
Volume（ボリューム）
データを収容するディレクトリであり、ポッド 内のコンテナが利用できます。
Kubernetes ボリュームは ポッド に取り込まれている限り存続します。従って、ボリュームはどの コンテナ よりも長く存在します。そのため、 ポッド 内にあるボリュームは、コンテナ を再起動する間もデータを維持します。
WG（ワーキング・グループ）
議論や実装における短期間で限定的な調整のためであり、プロジェクトの委員会、分科会（SIG） 、複数の分科会にわたって重複する場合があります。
ワーキング・グループは組織における人々が個別の課題を達成するためであり、比較的簡単に作成でき、活動ではない時に廃止できます。
詳細については kubernetes/community リポジトリと分科会とワーキング・グループ一覧をご覧ください。
docker（ドッカー）
Docker とは、コンテナとして知られているオペレーティングシステム・レベルでの仮想化を提供するソフトウェア技術です。
Docker はリソースを独立（分離：isolation）する機能のために Linux カーネルの cgorup と kernel 名前空間（namespace）と、OverlayFS のような統合可能なファイルシステムと、その他により、１つの Linux インスタンス（実体）の中に独立した コンテナ（container） として実行できるようにするものであり、仮想マシン（VM）を起動・運用するオーバーヘッドを防ぎます。
etcd（イーティーシーディー）
一貫性かつ可用性の高いキーバリューストアであり、Kubernetes の全クラスタ・データ保管を支援するのに使います。
常に Kubernetes クラスタ用 etcd データに対するバックアップ計画を持ってください。etcd の詳細な情報については etcd ドキュメント をご覧ください。
kube-apiserver
マスタ上で Kubernetes API を公開するコンポーネント（構成要素）です。Kubernetes コントロール・プレーンのフロントエンドです。
水平スケールできるように設計されていますが、スケールのためにはインスタンスを追加で展開（デプロイ）します。高可用性クラスタの構築 をご覧ください。
kube-controller-manager
マスタ上で コントローラ を実行する構成要素（コンポーネント）です。
論理的には各 コントローラ は分離されたプロセスですが、複雑さを減らすために、すべてが１つのバイナリにコンパイルされ、１つのプロセスとして実行します。
kube-proxy
kube-proxy はクラスタ内の各ノード上で動作するネットワーク・プロキシです。
kube-proxy はリクエストの転送に責任を負います。 kube-proxy は TCP と UDP ストリームを転送するか、ラウンド・ロビン TCP および UDP 転送をバックエンドの機能セットを横断して利用可能にします。
kube-scheduler
マスタの構成要素（コンポーネント）です。直近で作成されたポッドを監視し、ノードが割り当てられていなければ、ポッドを実行するノードを選んで実行します。
スケジューリングを決めるために考慮するには、個別の要素と全体的なリソース要求が含まれます。これには、ハードウェアやソフトウエアとポリシーの制約、または親和性の指定、データのローカル保存、お互いのワークフローが干渉しない、そして、期限があげられます。