commit first work from 1.19 milestone
This commit is contained in:
inductor
@@ -20,7 +20,7 @@ cloud-controller-managerは、プラグイン機構を用い、異なるクラ
|
||||
|
||||
## 設計
|
||||
|
||||
|
||||
|
||||
|
||||
クラウドコントローラーマネージャーは、複製されたプロセスの集合としてコントロールプレーンで実行されます。（通常、Pod内のコンテナとなります）各cloud-controller-managerは、シングルプロセスで複数の{{< glossary_tooltip text="controllers" term_id="controller" >}}を実装します。
|
||||
|
||||
|
||||
@@ -50,7 +50,11 @@ Jobとは対照的に、クラスターの外部に変更を加える必要が
|
||||
|
||||
外部の状態とやりとりをするコントローラーは、目的の状態をAPIサーバーから取得した後、外部のシステムと直接通信し、現在の状態を目的の状態に近づけます。
|
||||
|
||||
(クラスター内のノードを水平にスケールさせるコントローラーが実際に存在します。詳しくは、[クラスターのオートスケーリング](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling)を読んでください。)
|
||||
(クラスター内のノードを水平にスケールさせる[コントローラー](https://github.com/kubernetes/autoscaler/)が実際に存在します。)
|
||||
|
||||
ここで重要な点は、コントローラーが目的の状態を実現するために変更を加えてから、現在の状態をクラスターのAPIサーバーに報告することです。他の制御ループは、その報告されたデータを監視し、独自のアクションを実行できます。
|
||||
|
||||
サーモスタットの例では、部屋が非常に寒い場合、別のコントローラーが霜防止ヒーターをオンにすることもあります。Kubernetesクラスターを使用すると、コントロールプレーンは、[Kubernetesを拡張して](/ja/docs/concepts/extend-kubernetes/)実装することにより、IPアドレス管理ツールやストレージサービス、クラウドプロバイダーAPI、およびその他のサービスと間接的に連携します。
|
||||
|
||||
## 目的の状態 vs 現在の状態 {#desired-vs-current}
|
||||
|
||||
@@ -86,4 +90,3 @@ Kubernetesを拡張するためにコントロールプレーンの外で動作
|
||||
* 基本的な[Kubernetesオブジェクト](/ja/docs/concepts/#kubernetes-objects)について学ぶ
|
||||
* [Kubernetes API](/ja/docs/concepts/overview/kubernetes-api/)について学ぶ
|
||||
* 自分でコントローラーを書きたい場合は、「Kubernetesを拡張する」の[エクステンションパターン](/ja/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns)を読んでください。
|
||||
|
||||
|
||||
@@ -6,11 +6,12 @@ weight: 10
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
Kubernetesはコンテナを_Node_上で実行されるPodに配置することで、ワークロードを実行します。
|
||||
Kubernetesはコンテナを _Node_ 上で実行されるPodに配置することで、ワークロードを実行します。
|
||||
ノードはクラスターによりますが、1つのVMまたは物理的なマシンです。
|
||||
各ノードは{{< glossary_tooltip text="Pod" term_id="pod" >}}やそれを制御する{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}を実行するのに必要なサービスを含んでいます。
|
||||
|
||||
通常、1つのクラスターで複数のノードを持ちます。学習用途やリソースの制限がある環境では、1ノードかもしれません。
|
||||
|
||||
1つのノード上の[コンポーネント](/ja/docs/concepts/overview/components/#node-components)には、{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}、{{< glossary_tooltip text="コンテナランタイム" term_id="container-runtime" >}}、{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}が含まれます。
|
||||
|
||||
<!-- body -->
|
||||
@@ -22,7 +23,7 @@ Kubernetesはコンテナを_Node_上で実行されるPodに配置すること
|
||||
1. ノード上のkubeletが、コントロールプレーンに自己登録する。
|
||||
2. あなた、もしくは他のユーザーが手動でNodeオブジェクトを追加する。
|
||||
|
||||
Nodeオブジェクトの作成、もしくはノード上のkubeketによる自己登録の後、コントロールプレーンはNodeオブジェクトが有効かチェックします。例えば、下記のjsonマニフェストでノードを作成してみましょう。
|
||||
Nodeオブジェクトの作成、もしくはノード上のkubeketによる自己登録の後、コントロールプレーンはNodeオブジェクトが有効かチェックします。例えば、下記のjsonマニフェストでノードを作成してみましょう:
|
||||
|
||||
```json
|
||||
{
|
||||
@@ -72,9 +73,9 @@ kubeletのフラグ `--register-node`がtrue（デフォルト）のとき、kub
|
||||
管理者が手動でNodeオブジェクトを作成したい場合は、kubeletフラグ `--register-node = false`を設定してください。
|
||||
|
||||
管理者は`--register-node`の設定に関係なくNodeオブジェクトを変更することができます。
|
||||
変更には、ノードにラベルを設定し、それをunschedulableとしてマークすることが含まれます。
|
||||
例えば、ノードにラベルを設定し、それをunschedulableとしてマークすることが含まれます。
|
||||
|
||||
ノード上のラベルは、スケジューリングを制御するためにPod上のノードセレクタと組み合わせて使用できます。
|
||||
ノード上のラベルは、スケジューリングを制御するためにPod上のノードセレクターと組み合わせて使用できます。
|
||||
例えば、Podをノードのサブセットでのみ実行する資格があるように制限します。
|
||||
|
||||
ノードをunschedulableとしてマークすると、新しいPodがそのノードにスケジュールされるのを防ぎますが、ノード上の既存のPodには影響しません。
|
||||
@@ -124,7 +125,7 @@ kubectl describe node <ノード名をここに挿入>
|
||||
{{< table caption = "ノードのConditionと、各condition適用時の概要" >}}
|
||||
| ノードのCondition | 概要 |
|
||||
|----------------------|-------------|
|
||||
| `Ready` | ノードの状態がHealthyでPodを配置可能な場合に`True`になります。ノードの状態に問題があり、Podが配置できない場合に`False`になります。ノードコントローラーが、`node-monitor-grace-period`で設定された時間内(デフォルトでは40秒)に該当ノードと疎通できない場合、`Unknown`になります。 |
|
||||
| `Ready` | ノードの状態が有効でPodを配置可能な場合に`True`になります。ノードの状態に問題があり、Podが配置できない場合に`False`になります。ノードコントローラーが、`node-monitor-grace-period`で設定された時間内(デフォルトでは40秒)に該当ノードと疎通できない場合、`Unknown`になります。 |
|
||||
| `DiskPressure` | ノードのディスク容量が圧迫されているときに`True`になります。圧迫とは、ディスクの空き容量が少ないことを指します。それ以外のときは`False`です。 |
|
||||
| `MemoryPressure` | ノードのメモリが圧迫されているときに`True`になります。圧迫とは、メモリの空き容量が少ないことを指します。それ以外のときは`False`です。 |
|
||||
| `PIDPressure` | プロセスが圧迫されているときに`True`になります。圧迫とは、プロセス数が多すぎることを指します。それ以外のときは`False`です。 |
|
||||
@@ -217,7 +218,7 @@ Kubernetesは無効なノードのためにオブジェクトを保存し、そ
|
||||
|
||||
#### ハートビート
|
||||
ハートビートは、Kubernetesノードから送信され、ノードが利用可能か判断するのに役立ちます。
|
||||
２つのハートビートがあります：`NodeStatus`の更新と[Lease object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}#lease-v1-coordination-k8s-io)です。
|
||||
２つのハートビートがあります：`NodeStatus`の更新と[Lease object](/docs/reference/generated/kubernetes-api/{{< latest-version >}}#lease-v1-coordination-k8s-io)です。
|
||||
各ノードは`kube-node-lease`という{{< glossary_tooltip term_id="namespace" text="namespace">}}に関連したLeaseオブジェクトを持ちます。
|
||||
Leaseは軽量なリソースで、クラスターのスケールに応じてノードのハートビートにおけるパフォーマンスを改善します。
|
||||
|
||||
@@ -241,7 +242,7 @@ kubeletが`NodeStatus`とLeaseオブジェクトの作成および更新を担
|
||||
このような場合、ノードコントローラーはマスター接続に問題があると見なし、接続が回復するまですべての退役を停止します。
|
||||
|
||||
ノードコントローラーは、Podがtaintを許容しない場合、 `NoExecute`のtaintを持つノード上で実行されているPodを排除する責務もあります。
|
||||
さらに、デフォルトで無効になっているアルファ機能として、ノードコントローラーはノードに到達できない、または準備ができていないなどのノードの問題に対応する{{< glossary_tooltip text="taint" term_id="taint" >}}を追加する責務があります。これはスケジューラーが、問題のあるノードにPodを配置しない事を意味しています。
|
||||
さらに、ノードコントローラーはノードに到達できない、または準備ができていないなどのノードの問題に対応する{{< glossary_tooltip text="taint" term_id="taint" >}}を追加する責務があります。これはスケジューラーが、問題のあるノードにPodを配置しない事を意味しています。
|
||||
|
||||
{{< caution >}}
|
||||
`kubectl cordon`はノードに'unschedulable'としてマークします。それはロードバランサーのターゲットリストからノードを削除するという
|
||||
@@ -254,8 +255,7 @@ Nodeオブジェクトはノードのリソースキャパシティ（CPUの数
|
||||
[自己登録](#self-registration-of-nodes)したノードは、Nodeオブジェクトを作成するときにキャパシティを報告します。
|
||||
[手動によるノード管理](#manual-node-administration)を実行している場合は、ノードを追加するときにキャパシティを設定する必要があります。
|
||||
|
||||
Kubernetes{{< glossary_tooltip text="スケジューラー" term_id="kube-scheduler" >}}は、ノード上のすべてのPodに十分なリソースがあることを確認します。
|
||||
ノード上のコンテナが要求するリソースの合計がノードキャパシティ以下であることを確認します。
|
||||
Kubernetes{{< glossary_tooltip text="スケジューラー" term_id="kube-scheduler" >}}は、ノード上のすべてのPodに十分なリソースがあることを確認します。スケジューラーは、ノード上のコンテナが要求するリソースの合計がノードキャパシティ以下であることを確認します。
|
||||
これは、kubeletによって管理されたすべてのコンテナを含みますが、コンテナランタイムによって直接開始されたコンテナやkubeletの制御外で実行されているプロセスは含みません。
|
||||
|
||||
{{< note >}}
|
||||
@@ -275,4 +275,3 @@ kubeletはリソースの割当を決定する際にトポロジーのヒント
|
||||
* [Node APIオブジェクト](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core)について読む。
|
||||
* アーキテクチャ設計文書の[Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)という章を読む。
|
||||
* [TaintとToleration](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/)について読む。
|
||||
* [クラスターのオートスケール](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling)について読む。
|
||||
|
||||
@@ -119,11 +119,11 @@ weight: 20
|
||||
1. 以下のように、ダウンロードして解凍し、コマンドラインツールを用意します。
|
||||
使用しているハードウェアアーキテクチャやcfsslのバージョンに応じて、サンプルコマンドの調整が必要な場合があります。
|
||||
|
||||
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.4.1/cfssl_1.4.1_linux_amd64 -o cfssl
|
||||
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl_1.5.0_linux_amd64 -o cfssl
|
||||
chmod +x cfssl
|
||||
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.4.1/cfssljson_1.4.1_linux_amd64 -o cfssljson
|
||||
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssljson_1.5.0_linux_amd64 -o cfssljson
|
||||
chmod +x cfssljson
|
||||
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.4.1/cfssl-certinfo_1.4.1_linux_amd64 -o cfssl-certinfo
|
||||
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl-certinfo_1.5.0_linux_amd64 -o cfssl-certinfo
|
||||
chmod +x cfssl-certinfo
|
||||
1. アーティファクトを保持するディレクトリーを生成し、cfsslを初期化します。
|
||||
|
||||
|
||||
@@ -1,327 +0,0 @@
|
||||
---
|
||||
title: クラウドプロバイダー
|
||||
content_type: concept
|
||||
weight: 30
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
このページでは、特定のクラウドプロバイダーで実行されているKubernetesを管理する方法について説明します。
|
||||
|
||||
<!-- body -->
|
||||
### kubeadm
|
||||
[kubeadm](/ja/docs/reference/setup-tools/kubeadm/kubeadm/)は、Kubernetesクラスターを作成する選択肢として人気があります。
|
||||
kubeadmには、クラウドプロバイダーの設定情報を指定する設定オプションがあります。
|
||||
例えば、典型的なインツリークラウドプロバイダーは、以下のようにkubeadmを使用して設定することができます。
|
||||
|
||||
```yaml
|
||||
apiVersion: kubeadm.k8s.io/v1beta2
|
||||
kind: InitConfiguration
|
||||
nodeRegistration:
|
||||
kubeletExtraArgs:
|
||||
cloud-provider: "openstack"
|
||||
cloud-config: "/etc/kubernetes/cloud.conf"
|
||||
---
|
||||
apiVersion: kubeadm.k8s.io/v1beta2
|
||||
kind: ClusterConfiguration
|
||||
kubernetesVersion: v1.13.0
|
||||
apiServer:
|
||||
extraArgs:
|
||||
cloud-provider: "openstack"
|
||||
cloud-config: "/etc/kubernetes/cloud.conf"
|
||||
extraVolumes:
|
||||
- name: cloud
|
||||
hostPath: "/etc/kubernetes/cloud.conf"
|
||||
mountPath: "/etc/kubernetes/cloud.conf"
|
||||
controllerManager:
|
||||
extraArgs:
|
||||
cloud-provider: "openstack"
|
||||
cloud-config: "/etc/kubernetes/cloud.conf"
|
||||
extraVolumes:
|
||||
- name: cloud
|
||||
hostPath: "/etc/kubernetes/cloud.conf"
|
||||
mountPath: "/etc/kubernetes/cloud.conf"
|
||||
```
|
||||
|
||||
典型的なインツリークラウドプロバイダーは、通常、[kube-apiserver](/ja/docs/reference/command-line-tools-reference/kube-apiserver/)および[kube-controller-manager](ja//docs/reference/command-line-tools-reference/kube-controller-manager/)、[kubelet](/ja/docs/reference/command-line-tools-reference/kubelet/)のコマンドラインで指定される`--cloud-provider`と`--cloud-config`の両方が必要です。
|
||||
プロバイダーごとに`--cloud-config`で指定されるファイルの内容についても、以下に記載します。
|
||||
|
||||
すべての外部クラウドプロバイダーについては、以下の見出しに列挙されている個々のリポジトリーの案内に従ってください。または[すべてのリポジトリーのリスト](https://github.com/kubernetes?q=cloud-provider-&type=&language=)もご覧ください。
|
||||
|
||||
## AWS
|
||||
ここでは、Amazon Web ServicesでKubernetesを実行する際に使用できるすべての設定について説明します。
|
||||
|
||||
この外部クラウドプロバイダーを利用したい場合、[kubernetes/cloud-provider-aws](https://github.com/kubernetes/cloud-provider-aws#readme)リポジトリーを参照してください。
|
||||
|
||||
### ノード名
|
||||
|
||||
AWSクラウドプロバイダーは、AWSインスタンスのプライベートDNS名をKubernetesのNodeオブジェクトの名前として使用します。
|
||||
|
||||
### ロードバランサー
|
||||
以下のようにアノテーションを設定することで、[外部ロードバランサー](/ja/docs/tasks/access-application-cluster/create-external-load-balancer/)をAWS上で特定の機能を利用するように構成できます。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: example
|
||||
namespace: kube-system
|
||||
labels:
|
||||
run: example
|
||||
annotations:
|
||||
service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:xx-xxxx-x:xxxxxxxxx:xxxxxxx/xxxxx-xxxx-xxxx-xxxx-xxxxxxxxx #replace this value
|
||||
service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http
|
||||
spec:
|
||||
type: LoadBalancer
|
||||
ports:
|
||||
- port: 443
|
||||
targetPort: 5556
|
||||
protocol: TCP
|
||||
selector:
|
||||
app: example
|
||||
```
|
||||
AWSのロードバランサーサービスには、_アノテーション_ を使ってさまざまな設定を適用することができます。以下では、AWS ELBでサポートされているアノテーションについて説明します。
|
||||
|
||||
* `service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval`: アクセスログの送信間隔を指定するために使用します。
|
||||
* `service.beta.kubernetes.io/aws-load-balancer-access-log-enabled`: アクセスログを有効または無効にするためにサービスで使用します。
|
||||
* `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name`: アクセスログ用のs3バケット名を指定するために使用します。
|
||||
* `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix`: アクセスログ用のs3バケットのプレフィックスを指定するために使用します。
|
||||
* `service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags`: ELBに追加タグとして記録されるキーとバリューのペアのコンマ区切りリストとして指定するためにサービスで使用します。例えば、`"Key1=Val1,Key2=Val2,KeyNoVal1=,KeyNoVal2"`のように指定できます。
|
||||
* `service.beta.kubernetes.io/aws-load-balancer-backend-protocol`: リスナーの背後にあるバックエンド(Pod)が使用するプロトコルを指定するためにサービスで使用します。`http`(デフォルト)または`https`を指定すると、接続を終端してヘッダーを解析するHTTPSリスナーが生成されます。`ssl`または`tcp`を指定すると、「生の」SSLリスナーが使われます。`http`を指定して`aws-load-balancer-ssl-cert`を使わない場合は、HTTPリスナーが使われます。
|
||||
* `service.beta.kubernetes.io/aws-load-balancer-ssl-cert`: セキュアなリスナーを要求するためにサービスで使用します。値は有効な証明書のARNです。詳細は、[ELBリスナーの設定](https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-listener-config.html)を参照してください。CertARNは、IAMまたはCM証明書のARNで、例えば`arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012`のようになります。
|
||||
* `service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled`: 接続ドレインを有効または無効にするためにサービスで使用します。
|
||||
* `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout`: 接続ドレインのタイムアウトを指定するためにサービスで使用します。
|
||||
* `service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout`: アイドル接続タイムアウトを指定するためにサービスで使用します。
|
||||
* `service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled`: クロスゾーン負荷分散を有効または無効にするためにサービスで使用されます。
|
||||
* `service.beta.kubernetes.io/aws-load-balancer-security-groups`: 作成されたELBに追加するセキュリティーグループを指定するために使用します。これは、以前にELBに割り当てられた他のすべてのセキュリティーグループを置き換えます。ここで定義されたセキュリティーグループは、サービス間で共有してはいけません。
|
||||
* `service.beta.kubernetes.io/aws-load-balancer-extra-security-groups`: 作成されたELBに加える追加のセキュリティーグループを指定するためにサービスで使用します。
|
||||
* `service.beta.kubernetes.io/aws-load-balancer-internal`: 内部ELBが必要であることを示すためにサービスで使用します。
|
||||
* `service.beta.kubernetes.io/aws-load-balancer-proxy-protocol`: ELB上でプロキシープロトコルを有効にするためにサービスで使用します。現在は、すべてのELBバックエンドでプロキシープロトコルを有効にすることを意味する`*`という値しか受け付けません。将来的には、特定のバックエンドでのみプロキシープロトコルを設定できるように調整できます。
|
||||
* `service.beta.kubernetes.io/aws-load-balancer-ssl-ports`: SSL/HTTPSリスナーを使用するポートのコンマ区切りリストを指定するためにサービスで使用します。デフォルトは`*`(すべて)です。
|
||||
|
||||
AWSのアノテーションの情報は、[aws.go](https://github.com/kubernetes/legacy-cloud-providers/blob/master/aws/aws.go)のコメントから引用しています。
|
||||
|
||||
## Azure
|
||||
|
||||
この外部クラウドプロバイダーを利用したい場合、[kubernetes/cloud-provider-azure](https://github.com/kubernetes/cloud-provider-azure#readme)リポジトリーを参照してください。
|
||||
|
||||
### ノード名
|
||||
|
||||
Azureクラウドプロバイダーは、ノードのホスト名(kubeletで決定されたもの、または`--hostname-override`で上書きされたもの)を、Kubernetes Nodeオブジェクトの名前として使用します。
|
||||
Kubernetesノード名は、Azure VM名と一致しなければならないことに注意してください。
|
||||
|
||||
## CloudStack
|
||||
|
||||
この外部クラウドプロバイダーを利用したい場合、[apache/cloudstack-kubernetes-provider](https://github.com/apache/cloudstack-kubernetes-provider)リポジトリーを参照してください。
|
||||
|
||||
### ノード名
|
||||
|
||||
CloudStackクラウドプロバイダーは、ノードのホスト名(kubeletで決定されたもの、または`--hostname-override`で上書きされたもの)を、Kubernetes Nodeオブジェクトの名前として使用します。
|
||||
Kubernetesノード名は、CloudStack VM名と一致しなければならないことに注意してください。
|
||||
|
||||
## GCE
|
||||
|
||||
この外部クラウドプロバイダーを利用したい場合、[kubernetes/cloud-provider-gcp](https://github.com/kubernetes/cloud-provider-gcp#readme)リポジトリーを参照してください。
|
||||
|
||||
### ノード名
|
||||
|
||||
GCEクラウドプロバイダーは、ノードのホスト名(kubeletで決定されたもの、または`--hostname-override`で上書きされたもの)を、Kubernetes Nodeオブジェクトの名前として使用します。
|
||||
Kubernetesノード名の最初のセグメントは、GCEインスタンス名と一致しなければならないことに注意してください。例えば、`kubernetes-node-2.c.my-proj.internal`という名前のノードは、`kubernetes-node-2`という名前のインスタンスに対応していなければなりません。
|
||||
|
||||
## HUAWEI CLOUD
|
||||
|
||||
この外部クラウドプロバイダーを利用したい場合、[kubernetes-sigs/cloud-provider-huaweicloud](https://github.com/kubernetes-sigs/cloud-provider-huaweicloud)リポジトリーを参照してください。
|
||||
|
||||
### ノード名
|
||||
|
||||
HUAWEI CLOUDプロバイダーは、ノードのプライベートIPアドレスをKubernetesノード名として使用します。
|
||||
ノードでkubeletを開始するときは、必ず`--hostname-override=<node private IP>`を指定してください。
|
||||
|
||||
## OpenStack
|
||||
ここでは、OpenStackでKubernetesを実行する際に使用できるすべての設定について説明します。
|
||||
|
||||
この外部クラウドプロバイダーを利用したい場合、[kubernetes/cloud-provider-openstack](https://github.com/kubernetes/cloud-provider-openstack#readme)リポジトリーを参照してください。
|
||||
|
||||
### ノード名
|
||||
|
||||
OpenStackクラウドプロバイダーは、インスタンス名(OpenStackのメタデータで決定されたもの)を、Kubernetes Nodeオブジェクトの名前として使用します。
|
||||
インスタンス名は必ず、Kubernetesノード名は、CloudStack VM名と一致しなければならないことに注意してください。
|
||||
kubeletがNodeオブジェクトを正常に登録できるように、インスタンス名は有効なKubernetesノード名である必要があります。
|
||||
|
||||
### サービス
|
||||
|
||||
KubernetesのOpenStackクラウドプロバイダーの実装では、利用可能な場合、基盤となるクラウドからこれらのOpenStackのサービスの使用をサポートします。
|
||||
|
||||
| サービス名 | APIバージョン | 必須か |
|
||||
|--------------------------|----------------|----------|
|
||||
| Block Storage (Cinder) | V1†, V2, V3 | No |
|
||||
| Compute (Nova) | V2 | No |
|
||||
| Identity (Keystone) | V2‡, V3 | Yes |
|
||||
| Load Balancing (Neutron) | V1§, V2 | No |
|
||||
| Load Balancing (Octavia) | V2 | No |
|
||||
|
||||
† Block Storage V1 APIのサポートは非推奨ですが、Kubernetes 1.9ではBlock Storage V3 APIのサポートが追加されました。
|
||||
|
||||
‡ Identity V2 APIのサポートは非推奨となり、将来のリリースでプロバイダーから削除される予定です。「Queens」のリリース時点で、OpenStackはIdentity V2 APIを公開しません。
|
||||
|
||||
§ Load Balancing V1 APIのサポートは、Kubernetes 1.9で削除されました。
|
||||
|
||||
サービスディスカバリーは、プロバイダー設定で提供される`auth-url`を使用して、OpenStack Identity(Keystone)が管理するサービスカタログを一覧表示することで実現されます。
|
||||
プロバイダーは、Keystone以外のOpenStackサービスが利用できなくなった場合には、機能を緩やかに低下させ、影響を受ける機能のサポートを放棄します。
|
||||
特定の機能は、基盤となるクラウドでNeutronが公開している拡張機能のリストに基づいて有効または無効にされます。
|
||||
|
||||
### cloud.conf
|
||||
Kubernetesはcloud.confというファイルを介して、OpenStackとのやりとり方法を知っています。
|
||||
これは、KubernetesにOpenStack認証エンドポイントの認証情報と場所を提供するファイルです。
|
||||
ファイル内に以下の詳細を指定することで、cloud.confファイルを作成できます。
|
||||
|
||||
#### 典型的な設定
|
||||
以下の設定例は、最も頻繁に設定が必要な値に関するものです。
|
||||
プロバイダーをOpenStackクラウドのKeystoneエンドポイントに指定し、そのエンドポイントでの認証方法の詳細を提供し、さらにロードバランサーを設定します。
|
||||
|
||||
```yaml
|
||||
[Global]
|
||||
username=user
|
||||
password=pass
|
||||
auth-url=https://<keystone_ip>/identity/v3
|
||||
tenant-id=c869168a828847f39f7f06edd7305637
|
||||
domain-id=2a73b8f597c04551a0fdc8e95544be8a
|
||||
|
||||
[LoadBalancer]
|
||||
subnet-id=6937f8fa-858d-4bc9-a3a5-18d2c957166a
|
||||
```
|
||||
|
||||
##### グローバル
|
||||
これらのOpenStackプロバイダーの設定オプションは、グローバル設定に関連しており、`cloud.conf`ファイルの`[Global]`セクションに記述する必要があります。
|
||||
|
||||
* `auth-url`(必死): 認証に使用するKeystone APIのURLです。OpenStackのコントロールパネルでは、Access and Security > API Access > Credentialsで確認できます。
|
||||
* `username`(必須): Keystoneに設定されている有効なユーザーのユーザー名を参照します。
|
||||
* `password`(必須): Keystoneで設定された有効なユーザーのパスワードを参照します。
|
||||
* `tenant-id`(必須): リソースを作成するプロジェクトのIDを指定するために使用します。
|
||||
* `tenant-name`(任意): リソースを作成するプロジェクトの名前を指定します。
|
||||
* `trust-id`(任意): 認証に使用するtrustの識別子を指定するために使用します。trustは、ユーザー(委託者)が他のユーザー(受託者)に役割を委譲したり、受託者が委託者になりすますことを許可したりする権限を表します。利用可能なtrustは、Keystone APIの`/v3/OS-TRUST/trusts`エンドポイントの下にあります。
|
||||
* `domain-id`(任意): ユーザーが所属するドメインのIDを指定するために使用します。
|
||||
* `domain-name`(任意): ユーザーが所属するドメイン名を指定するために使用します。
|
||||
* `region`(任意): マルチリージョンのOpenStackクラウド上で実行する際に使うリージョンの識別子を指定するために使用します。リージョンはOpenStackデプロイメントの一般的な区分です。リージョンには厳密な地理的な意味合いはありませんが、デプロイメントでは`us-east`のような地理的な名前をリージョンの識別子に使うことができます。利用可能なリージョンはKeystone APIの`/v3/regions`エンドポイントの下にあります。
|
||||
* `ca-file`(任意): カスタムCAファイルのパスを指定するために使用します。
|
||||
|
||||
|
||||
テナントをプロジェクトに変更するKeystone V3を使用している場合、`tenant-id`の値は自動的にAPIのプロジェクト構造体にマッピングされます。
|
||||
|
||||
##### ロードバランサー
|
||||
これらのOpenStackプロバイダーの設定オプションは、ロードバランサー設定に関連しており、`cloud.conf`ファイルの`[LoadBalancer]`セクションに記述する必要があります。
|
||||
|
||||
* `lb-version`(任意): 自動バージョン検出を上書きするために使用します。有効な値は`v1`または`v2`です。値が指定されていない場合、自動検出は基盤となるOpenStackクラウドが公開するサポートバージョンのうち、最も高いものを選択します。
|
||||
* `use-octavia`(任意): Octavia LBaaS V2サービスカタログエンドポイントを探して、利用するかどうかを決定するために使用します。有効な値は`true`または`false`です。`true`が指定され、Octaiva LBaaS V2エントリーが見つからなかった場合、プロバイダーはフォールバックして代わりにNeutron LBaaS V2エンドポイントを見つけようとします。デフォルト値は`false` です。
|
||||
* `subnet-id`(任意): ロードバランサーを作成したいサブネットのIDを指定します。Network > Networksにあります。サブネットを取得するには、それぞれのネットワークをクリックします。
|
||||
* `floating-network-id`(任意): 指定した場合、ロードバランサーのフローティングIPを作成します。
|
||||
* `lb-method`(任意): ロードバランサープールのメンバー間で負荷分散させるアルゴリズムを指定するために使用します。値には`ROUND_ROBIN`、`LEAST_CONNECTIONS`、`SOURCE_IP`を指定できます。何も指定しない場合のデフォルトの動作は`ROUND_ROBIN` です。
|
||||
* `lb-provider`(任意): ロードバランサーのプロバイダーを指定するために使用します。指定しない場合は、Neutronで設定されたデフォルトのプロバイダサービスが使用されます。
|
||||
* `create-monitor`(任意): Neutronロードバランサーのヘルスモニターを作成するかどうかを表します。有効な値は`true`と`false`で、デフォルト値は`false`です。`true`を指定した場合は、`monitor-delay`、`monitor-timeout`、`monitor-max-retries`も設定しなければなりません。
|
||||
* `monitor-delay`(任意): ロードバランサーのメンバーにプローブを送信するまでの時間です。有効な時間単位を指定してください。有効な時間単位は"ns"、"us"(または"μs")、"ms"、"s"、"m"、"h"です。
|
||||
* `monitor-timeout`(任意): モニタリングがタイムアウトする前にpingの応答を待つための最大の時間です。この値はdelay値よりも小さくする必要があります。有効な時間単位を指定してください。有効な時間単位は"ns"、"us"(または"μs")、"ms"、"s"、"m"、"h"です。
|
||||
* `monitor-max-retries`(任意): ロードバランサーメンバーのステータスをINACTIVEに変更する前に許容されるpingの失敗の数です。1から10の間の数値でなければなりません。
|
||||
* `manage-security-groups`(任意): ロードバランサーがセキュリティーグループのルールを自動的に管理するかどうかを決定します。有効な値は`true`と`false`で、デフォルト値は`false`です。`true`を指定した場合は、`node-security-group`も指定しなければなりません。
|
||||
* `node-security-group`(任意): 管理するセキュリティーグループのIDです。
|
||||
|
||||
##### ブロックストレージ
|
||||
これらのOpenStackプロバイダーの設定オプションは、ブロックストレージ設定に関連しており、`cloud.conf`ファイルの`[BlockStorage]`セクションに記述する必要があります。
|
||||
|
||||
* `bs-version`(任意): 自動バージョン検出を上書きするために使用します。有効な値は`v1`、`v2`、`v3`、`auto`です。`auto`が指定された場合、自動検出は基盤となるOpenStackクラウドが公開するサポートバージョンのうち、最も高いものを選択します。何も指定しない場合のデフォルト値は`auto`です。
|
||||
* `trust-device-path`(任意): ほとんどのシナリオでは、Cinderが提供するブロックデバイス名(例: `/dev/vda`)は信頼できません。このブール値はこの動作をトグルします。`true`に設定すると、Cinderが提供するブロックデバイス名を信頼することになります。デフォルト値の`false`は、シリアル番号と`/dev/disk/by-id`のマッピングに基づいてデバイスのパスを検出します。
|
||||
* `ignore-volume-az`(任意): Cinderボリュームをアタッチする際のアベイラビリティーゾーンの使用に影響を与えます。NovaとCinderのアベイラビリティーゾーンが異なる場合は、`true`に設定する必要があります。これは、Novaのアベイラビリティーゾーンが多くあるにも関わらず、Cinderのアベイラビリティーゾーンが1つしかない場合によく見られます。デフォルト値は以前のリリースで使用されていた動作を維持するために`false`になっていますが、将来的には変更される可能性があります。
|
||||
* `node-volume-attach-limit`(任意): ノードにアタッチできるボリュームの最大数で、デフォルトはCinderの256です。
|
||||
|
||||
エンドポイントを区別するためにポートではなくパスを使用しているOpenStackデプロイメントにおいて、Kubernetesのバージョン1.8以下をデプロイする際、明示的に`bs-version`パラメーターの設定が必要な場合があります。パスベースのエンドポイントは`http://foo.bar/volume`の形式であり、ポートベースのエンドポイントは`http://foo.bar:xxx`の形式です。
|
||||
|
||||
パスベースのエンドポイントを使う環境で、Kubernetesが古い自動検出ロジックを使用している場合、ボリュームの切り離しを試みると`BS API version autodetection failed.`というエラーが返されます。この問題を回避するには、クラウドプロバイダー設定に以下のように追記することで、Cinder APIバージョン2を強制的に使用することができます。
|
||||
|
||||
```yaml
|
||||
[BlockStorage]
|
||||
bs-version=v2
|
||||
```
|
||||
|
||||
##### メタデータ
|
||||
これらのOpenStackプロバイダーの設定オプションは、メタデータ設定に関連しており、`cloud.conf`ファイルの`[Metadata]`セクションに記述する必要があります。
|
||||
|
||||
* `search-order`(任意): この設定のキーは、プロバイダーが実行するインスタンスに関連するメタデータの取得方法に影響します。デフォルト値の`configDrive,metadataService`について、プロバイダーは、コンフィグドライブが利用可能な場合は最初にインスタンスに関連するメタデータをそこから取得し、次にメタデータサービスから取得します。代替値は以下の通りです。
|
||||
* `configDrive` - コンフィグドライブからのみ、インスタンスのメタデータを取得します。
|
||||
* `metadataService` - メタデータサービスからのみ、インスタンスのメタデータを取得します。
|
||||
* `metadataService,configDrive` - 最初にメタデータサービスからインスタンスのメタデータを取得し、次にコンフィグドライブから取得します。
|
||||
|
||||
コンフィグドライブ上のメタデータは時間の経過とともに陳腐化する可能性がありますが、メタデータサービスは常に最新の情報を提供するため、この動作を調整するのが望ましいです。しかし、すべてのOpenStackクラウドがコンフィグドライブとメタデータサービスの両方を提供しているわけではなく、どちらか一方しか利用できない場合もあるため、デフォルトでは両方をチェックするようになっています。
|
||||
|
||||
##### ルート
|
||||
これらのOpenStackプロバイダーの設定オプションは、[kubenet](/ja/docs/concepts/cluster-administration/network-plugins/#kubenet)のKubernetesネットワークプラグインに関連しており、`cloud.conf`ファイルの`[Route]`セクションに記述する必要があります。
|
||||
|
||||
|
||||
* `router-id`(任意): 基盤となるクラウドのNeutronデプロイメントが`extraroutes`拡張機能をサポートしている場合は、`router-id`を使用してルートを追加するルーターを指定します。選択したルーターは、クラスターノードを含むプライベートネットワークにまたがっていなければなりません(通常、ノードネットワークは1つしかないので、この値はノードネットワークのデフォルトルーターになります)。この値は、OpenStackで[kubenet](/docs/concepts/cluster-administration/network-plugins/#kubenet)を使用するために必要です。
|
||||
|
||||
## OVirt
|
||||
|
||||
### ノード名
|
||||
|
||||
OVirtクラウドプロバイダーは、ノードのホスト名(kubeletで決定されたもの、または`--hostname-override`で上書きされたもの)を、Kubernetes Nodeオブジェクトの名前として使用します。
|
||||
Kubernetesノード名は、VMのFQDN(`<vm><guest_info><fqdn>...</fqdn></guest_info></vm>`の下でOVirtによって報告されたもの)と一致しなければならないことに注意してください。
|
||||
|
||||
## Photon
|
||||
|
||||
### ノード名
|
||||
|
||||
Photonクラウドプロバイダーは、ノードのホスト名(kubeletで決定されたもの、または`--hostname-override`で上書きされたもの)を、Kubernetes Nodeオブジェクトの名前として使用します。
|
||||
Kubernetesノード名はPhoton VM名と一致しなければならないことに注意してください(もしくは、`--cloud-config`で`overrideIP`がtrueに設定されている場合は、Kubernetesノード名はPhoton VMのIPアドレスと一致しなければなりません)。
|
||||
|
||||
## vSphere
|
||||
|
||||
{{< tabs name="vSphere cloud provider" >}}
|
||||
{{% tab name="vSphere 6.7U3以上" %}}
|
||||
vSphere 6.7U3以上のすべてのvSphereデプロイメントでは、[external vSphere cloud provider](https://github.com/kubernetes/cloud-provider-vsphere)と[vSphere CSI driver](https://github.com/kubernetes-sigs/vsphere-csi-driver)の使用を推奨します。クイックスタートガイドについては、[Deploying a Kubernetes Cluster on vSphere with CSI and CPI](https://cloud-provider-vsphere.sigs.k8s.io/tutorials/kubernetes-on-vsphere-with-kubeadm.html)を参照してください。
|
||||
{{% /tab %}}
|
||||
{{% tab name="vSphere 6.7U3未満" %}}
|
||||
vSphere 6.7U3未満を実行している場合は、インツリーのvSphereクラウドプロバイダーを推奨します。クイックスタートガイドについては、[Running a Kubernetes Cluster on vSphere with kubeadm](https://cloud-provider-vsphere.sigs.k8s.io/tutorials/k8s-vcp-on-vsphere-with-kubeadm.html)を参照してください。
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
vSphereクラウドプロバイダーの詳細なドキュメントについては、[vSphereクラウドプロバイダーのドキュメントサイト](https://cloud-provider-vsphere.sigs.k8s.io)を参照してください。
|
||||
|
||||
## IBM Cloud Kubernetes Service
|
||||
|
||||
### コンピュートノード
|
||||
IBM Cloud Kubernetes Serviceプロバイダーを使用することで、仮想ノードと物理ノード(ベアメタル)を混在させたクラスターを単一のゾーン、またはリージョン内の複数のゾーンにまたがって作成することができます。詳細については、[Planning your cluster and worker node setup](https://cloud.ibm.com/docs/containers?topic=containers-planning_worker_nodes)を参照してください。
|
||||
|
||||
Kubernetes Nodeオブジェクトの名前は、IBM Cloud Kubernetes ServiceワーカーノードインスタンスのプライベートIPアドレスです。
|
||||
|
||||
### ネットワーク
|
||||
IBM Cloud Kubernetes Serviceプロバイダーは、高品質なネットワークパフォーマンスとノードのネットワーク分離のためにVLANを提供します。カスタムファイアウォールやCalicoネットワークポリシーを設定して、クラスターにセキュリティーの追加レイヤーを加えたり、VPNを使用してクラスターをオンプレミスデータセンターに接続したりすることができます。詳細については、[Planning your cluster network setup](https://cloud.ibm.com/docs/containers?topic=containers-plan_clusters)を参照してください。
|
||||
|
||||
アプリケーションをパブリックまたはクラスター内で公開するには、NodePort、LoadBalancer、Ingressサービスを利用できます。また、Ingressアプリケーションのロードバランサーをアノテーションでカスタマイズすることもできます。詳細については、[Choosing an app exposure service](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planning#cs_network_planning)を参照してください。
|
||||
|
||||
### ストレージ
|
||||
IBM Cloud Kubernetes Serviceプロバイダーは、Kubernetesネイティブの永続ボリュームを活用して、ユーザーがファイル、ブロック、およびクラウドオブジェクトストレージをアプリケーションにマウントできるようにします。また、データの永続ストレージにDatabase as a Serviceやサードパーティーのアドオンを使用することもできます。詳しくは、[Planning highly available persistent storage](https://cloud.ibm.com/docs/containers?topic=containers-storage_planning#storage_planning)を参照してください。
|
||||
|
||||
## Baidu Cloud Container Engine
|
||||
|
||||
### ノード名
|
||||
|
||||
Baiduクラウドプロバイダーは、ノードのプライベートIPアドレス(kubeletで決定されたもの、または`--hostname-override`で上書きされたもの)を、Kubernetes Nodeオブジェクトの名前として使用します。
|
||||
Kubernetesノード名はBaidu VMのプライベートIPと一致しなければならないことに注意してください。
|
||||
|
||||
## Tencent Kubernetes Engine
|
||||
|
||||
この外部クラウドプロバイダーを利用したい場合、[TencentCloud/tencentcloud-cloud-controller-manager](https://github.com/TencentCloud/tencentcloud-cloud-controller-manager)リポジトリーを参照してください。
|
||||
|
||||
### ノード名
|
||||
|
||||
Baiduクラウドプロバイダーは、ノードのホスト名(kubeletで決定されたもの、または`--hostname-override`で上書きされたもの)を、Kubernetes Nodeオブジェクトの名前として使用します。
|
||||
Kubernetesノード名はTencent VMのプライベートIPと一致しなければならないことに注意してください。
|
||||
|
||||
## Alibaba Cloud Kubernetes
|
||||
|
||||
この外部クラウドプロバイダーを利用したい場合、[kubernetes/cloud-provider-alibaba-cloud](https://github.com/kubernetes/cloud-provider-alibaba-cloud)リポジトリーを参照してください。
|
||||
|
||||
### ノード名
|
||||
|
||||
Alibaba Cloudではノード名の書式は必要ありませんが、kubeletでは`--provider-id=${REGION_ID}.${INSTANCE_ID}`を追加する必要があります。パラメーター`${REGION_ID}`はKubernetesのリージョンのIDを、`${INSTANCE_ID}`はAlibaba ECS(Elastic Compute Service)のIDを表します。
|
||||
|
||||
### ロードバランサー
|
||||
|
||||
[アノテーション](https://www.alibabacloud.com/help/en/doc-detail/86531.htm)を設定することで、Alibaba Cloudの特定の機能を使用するように外部のロードバランサーを設定できます。
|
||||
@@ -29,8 +29,6 @@ Kubernetesクラスターの計画、セットアップ、設定の例を知る
|
||||
|
||||
## クラスターの管理
|
||||
|
||||
* [クラスターの管理](/docs/tasks/administer-cluster/cluster-management/)では、クラスターのライフサイクルに関するいくつかのトピックを紹介しています。例えば、新規クラスターの作成、クラスターのマスターやワーカーノードのアップグレード、ノードのメンテナンスの実施(例: カーネルのアップグレード)、稼働中のクラスターのKubernetes APIバージョンのアップグレードについてです。
|
||||
|
||||
* [ノードの管理](/ja/docs/concepts/architecture/nodes/)方法について学んでください。
|
||||
|
||||
* 共有クラスターにおける[リソースクォータ](/docs/concepts/policy/resource-quotas/)のセットアップと管理方法について学んでください。
|
||||
@@ -41,7 +39,7 @@ Kubernetesクラスターの計画、セットアップ、設定の例を知る
|
||||
|
||||
* [Kubernetes コンテナの環境](/ja/docs/concepts/containers/container-environment/)では、Kubernetesノード上でのKubeletが管理するコンテナの環境について説明します。
|
||||
|
||||
* [Kubernetes APIへのアクセス制御](/docs/reference/access-authn-authz/controlling-access/)では、ユーザーとサービスアカウントの権限の設定方法について説明します。
|
||||
* [Kubernetes APIへのアクセス制御](/docs/concepts/security/controlling-access)では、Kubernetesで自身のAPIに対するアクセスコントロールがどのように実装されているかを説明します。
|
||||
|
||||
* [認証](/docs/reference/access-authn-authz/authentication/)では、様々な認証オプションを含むKubernetesでの認証について説明します。
|
||||
|
||||
|
||||
@@ -237,7 +237,7 @@ guestbook-redis-slave-qgazl 1/1 Running 0 3m
|
||||
image: gb-frontend:v3
|
||||
```
|
||||
|
||||
そして2つの異なるPodのセットを上書きしないようにするため、`track`ラベルに異なる値を持つ(例: `canary`)ようなguestbookフロントエンドの新しいリリースを作成できます。
|
||||
そして2つの異なるPodのセットを上書きしないようにするため、`track`ラベルに異なる値を持つ(例: `canary`)ようなguestbookフロントエンドの新しいリリースを作成できます。
|
||||
|
||||
```yaml
|
||||
name: frontend-canary
|
||||
|
||||
@@ -39,18 +39,20 @@ Kubernetesは、ネットワークの実装に次の基本的な要件を課し
|
||||
|
||||
このモデルは全体としてそれほど複雑ではないことに加え、KubernetesがVMからコンテナへのアプリへの移植を簡単にするという要望と基本的に互換性があります。ジョブがVMで実行されていた頃も、VMにはIPがあってプロジェクト内の他のVMと通信できました。これは同じ基本モデルです。
|
||||
|
||||
KubernetesのIPアドレスは`Pod`スコープに存在します。`Pod`内のコンテナは、IPアドレスを含むネットワーク名前空間を共有します。これは、`Pod`内のコンテナがすべて`localhost`上の互いのポートに到達できることを意味します。また、`Pod`内のコンテナがポートの使用を調整する必要があることも意味しますが、これもVM内のプロセスと同じです。これのことを「IP-per-pod(Pod毎のIP)」モデルと呼びます。
|
||||
KubernetesのIPアドレスは`Pod`スコープに存在します。`Pod`内のコンテナは、IPアドレスとMACアドレスを含むネットワーク名前空間を共有します。これは、`Pod`内のコンテナがすべて`localhost`上の互いのポートに到達できることを意味します。また、`Pod`内のコンテナがポートの使用を調整する必要があることも意味しますが、これもVM内のプロセスと同じです。これのことを「IP-per-pod(Pod毎のIP)」モデルと呼びます。
|
||||
|
||||
この実装方法は実際に使われているコンテナランタイムの詳細部分です。
|
||||
|
||||
`Pod`に転送する`ノード`自体のポート(ホストポートと呼ばれる)を要求することは可能ですが、これは非常にニッチな操作です。このポート転送の実装方法も、コンテナランタイムの詳細部分です。`Pod`自体は、ホストポートの有無を認識しません。
|
||||
|
||||
## Kubernetesネットワークモデルの実装方法
|
||||
## Kubernetesネットワークモデルの実装方法 {#how-to-implement-the-kubernetes-networking-model}
|
||||
|
||||
このネットワークモデルを実装する方法はいくつかあります。このドキュメントは、こうした方法を網羅的にはカバーしませんが、いくつかの技術の紹介として、また出発点として役立つことを願っています。
|
||||
|
||||
この一覧はアルファベット順にソートされており、順序は優先ステータスを意味するものではありません。
|
||||
|
||||
{{% thirdparty-content %}}
|
||||
|
||||
### ACI
|
||||
|
||||
[Cisco Application Centric Infrastructure](https://www.cisco.com/c/en/us/solutions/data-center-virtualization/application-centric-infrastructure/index.html) offers an integrated overlay and underlay SDN solution that supports containers, virtual machines, and bare metal servers.
|
||||
@@ -99,6 +101,10 @@ With the help of the Big Cloud Fabric's virtual pod multi-tenant architecture, c
|
||||
|
||||
BCF was recognized by Gartner as a visionary in the latest [Magic Quadrant](https://go.bigswitch.com/17GatedDocuments-MagicQuadrantforDataCenterNetworking_Reg.html). One of the BCF Kubernetes on-premises deployments (which includes Kubernetes, DC/OS & VMware running on multiple DCs across different geographic regions) is also referenced [here](https://portworx.com/architects-corner-kubernetes-satya-komala-nio/).
|
||||
|
||||
### Calico
|
||||
|
||||
[Calico](https://docs.projectcalico.org/)は、コンテナ、仮想マシン、ホストベースのワークロードのためのオープンソースのネットワーク及びネットワークセキュリティのソリューションです。Calicoは、純粋なLinuxのeBPFデータプレーンや、Linuxの標準的なネットワークデータプレーン、WindowsのHNSデータプレーンを含む、複数のデータプレーンをサポートしています。Calicoは完全なネットワークスタックを提供していますが、[クラウドプロバイダーのCNI](https://docs.projectcalico.org/networking/determine-best-networking#calico-compatible-cni-plugins-and-cloud-provider-integrations)と組み合わせてネットワークポリシーを提供することもできます。
|
||||
|
||||
### Cilium
|
||||
|
||||
[Cilium](https://github.com/cilium/cilium) is open source software for
|
||||
@@ -129,6 +135,11 @@ tables to provide per-instance subnets to each host (which is limited to 50-100
|
||||
entries per VPC). In short, cni-ipvlan-vpc-k8s significantly reduces the
|
||||
network complexity required to deploy Kubernetes at scale within AWS.
|
||||
|
||||
### Coil
|
||||
|
||||
[Coil](https://github.com/cybozu-go/coil)は、容易に連携できるよう設計されていて、フレキシブルなEgressネットワークを提供することができるCNIプラグインです。
|
||||
Coilはベアメタルと比較して低いオーバーヘッドで操作することができ、また外部のネットワークへの任意のEgress NATゲートウェイを定義することができます。
|
||||
|
||||
### Contiv
|
||||
|
||||
[Contiv](https://github.com/contiv/netplugin) provides configurable networking (native l3 using BGP, overlay using vxlan, classic l2, or Cisco-SDN/ACI) for various use cases. [Contiv](https://contiv.io) is all open sourced.
|
||||
@@ -266,14 +277,6 @@ stateful ACLs, load-balancers etc to build different virtual networking
|
||||
topologies. The project has a specific Kubernetes plugin and documentation
|
||||
at [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes).
|
||||
|
||||
### Project Calico
|
||||
|
||||
[Project Calico](https://docs.projectcalico.org/) is an open source container networking provider and network policy engine.
|
||||
|
||||
Calico provides a highly scalable networking and network policy solution for connecting Kubernetes pods based on the same IP networking principles as the internet, for both Linux (open source) and Windows (proprietary - available from [Tigera](https://www.tigera.io/essentials/)). Calico can be deployed without encapsulation or overlays to provide high-performance, high-scale data center networking. Calico also provides fine-grained, intent based network security policy for Kubernetes pods via its distributed firewall.
|
||||
|
||||
Calico can also be run in policy enforcement mode in conjunction with other networking solutions such as Flannel, aka [canal](https://github.com/tigera/canal), or native GCE, AWS or Azure networking.
|
||||
|
||||
### Romana
|
||||
|
||||
[Romana](https://romana.io) is an open source network and security automation solution that lets you deploy Kubernetes without an overlay network. Romana supports Kubernetes [Network Policy](/docs/concepts/services-networking/network-policies/) to provide isolation across network namespaces.
|
||||
@@ -287,9 +290,7 @@ or stand-alone. In either version, it doesn't require any configuration or extr
|
||||
to run, and in both cases, the network provides one IP address per pod - as is standard for Kubernetes.
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
ネットワークモデルの初期設計とその根拠、および将来の計画については、[ネットワーク設計ドキュメント](https://git.k8s.io/community/contributors/design-proposals/network/networking.md)で詳細に説明されています。
|
||||
|
||||
|
||||
@@ -22,12 +22,18 @@ ConfigMapは機密性や暗号化を提供しません。保存したいデー
|
||||
|
||||
こうすることで、必要であればクラウド上で実行しているコンテナイメージを取得することで、ローカルでも完全に同じコードを使ってデバッグができるようになります。
|
||||
|
||||
ConfigMapは、大量のデータを保持するようには設計されていません。ConfigMapに保存されるデータは1MiBを超えることはできません。この制限を超える設定を保存する必要がある場合は、ボリュームのマウントを検討するか、別のデータベースまたはファイルサービスを使用することを検討してください。
|
||||
|
||||
## ConfigMapオブジェクト
|
||||
|
||||
ConfigMapは、他のオブジェクトが使うための設定を保存できるAPI[オブジェクト](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/)です。ほとんどのKubernetesオブジェクトに`spec`セクションがあるのとは違い、ConfigMapにはアイテム(キー)と値を保存するための`data`セクションがあります。
|
||||
ConfigMapは、他のオブジェクトが使うための設定を保存できるAPI[オブジェクト](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/)です。ほとんどのKubernetesオブジェクトに`spec`セクションがあるのとは違い、ConfigMapには`data`および`binaryData`フィールドがあります。これらのフィールドは、キーとバリューのペアを値として受け入れます。`data`フィールドと`binaryData`フィールドはどちらもオプションです。`data`フィールドはUTF-8バイトシーケンスを含むように設計されていますが、`binaryData`フィールドはバイナリデータを含むように設計されています。
|
||||
|
||||
ConfigMapの名前は、有効な[DNSのサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)でなければなりません。
|
||||
|
||||
`data`または`binaryData`フィールドの各キーは、英数字、`-`、`_`、または`.`で構成されている必要があります。`data`に格納されているキーは、`binaryData`フィールドのキーと重複することはできません。
|
||||
|
||||
v1.19以降、ConfigMapの定義に`immutable`フィールドを追加して、[イミュータブルなConfigMap](#configmap-immutable)を作成できます。
|
||||
|
||||
## ConfigMapとPod
|
||||
|
||||
ConfigMapを参照して、ConfigMap内のデータを元にしてPod内のコンテナの設定をするPodの`spec`を書くことができます。このとき、PodとConfigMapは同じ{{< glossary_tooltip text="名前空間" term_id="namespace" >}}内に存在する必要があります。
|
||||
@@ -43,7 +49,7 @@ data:
|
||||
# プロパティーに似たキー。各キーは単純な値にマッピングされている
|
||||
player_initial_lives: "3"
|
||||
ui_properties_file_name: "user-interface.properties"
|
||||
#
|
||||
|
||||
# ファイルに似たキー
|
||||
game.properties: |
|
||||
enemy.types=aliens,monsters
|
||||
@@ -56,7 +62,7 @@ data:
|
||||
|
||||
ConfigMapを利用してPod内のコンテナを設定する方法には、次の4種類があります。
|
||||
|
||||
1. コマンドライン引数をコンテナのエントリーポイントに渡す
|
||||
1. コンテナ内のコマンドと引数
|
||||
1. 環境変数をコンテナに渡す
|
||||
1. 読み取り専用のボリューム内にファイルを追加し、アプリケーションがそのファイルを読み取る
|
||||
1. Kubernetes APIを使用してConfigMapを読み込むコードを書き、そのコードをPod内で実行する
|
||||
@@ -75,7 +81,8 @@ metadata:
|
||||
spec:
|
||||
containers:
|
||||
- name: demo
|
||||
image: game.example/demo-game
|
||||
image: alpine
|
||||
command: ["sleep", "3600"]
|
||||
env:
|
||||
# 環境変数を定義します。
|
||||
- name: PLAYER_INITIAL_LIVES # ここではConfigMap内のキーの名前とは違い
|
||||
@@ -117,11 +124,9 @@ ConfigMapは1行のプロパティの値と複数行のファイルに似た形
|
||||
|
||||
ConfigMapは、データボリュームとしてマウントできます。ConfigMapは、Podへ直接公開せずにシステムの他の部品として使うこともできます。たとえば、ConfigMapには、システムの他の一部が設定のために使用するデータを保存できます。
|
||||
|
||||
{{< note >}}
|
||||
ConfigMapの最も一般的な使い方では、同じ名前空間にあるPod内で実行されているコンテナに設定を構成します。ConfigMapを独立して使用することもできます。
|
||||
|
||||
たとえば、ConfigMapに基づいて動作を調整する{{< glossary_tooltip text="アドオン" term_id="addons" >}}や{{< glossary_tooltip text="オペレーター" term_id="operator-pattern" >}}を見かけることがあるかもしれません。
|
||||
{{< /note >}}
|
||||
|
||||
### ConfigMapをPodからファイルとして使う
|
||||
|
||||
@@ -161,14 +166,17 @@ Pod内に複数のコンテナが存在する場合、各コンテナにそれ
|
||||
|
||||
ボリューム内で現在使用中のConfigMapが更新されると、射影されたキーも最終的に(eventually)更新されます。kubeletは定期的な同期のたびにマウントされたConfigMapが新しいかどうか確認します。しかし、kubeletが現在のConfigMapの値を取得するときにはローカルキャッシュを使用します。キャッシュの種類は、[KubeletConfiguration構造体](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go)の中の`ConfigMapAndSecretChangeDetectionStrategy`フィールドで設定可能です。ConfigMapは、監視(デフォルト)、ttlベース、またはすべてのリクエストを直接APIサーバーへ単純にリダイレクトする方法のいずれかによって伝搬されます。その結果、ConfigMapが更新された瞬間から、新しいキーがPodに射影されるまでの遅延の合計は、最長でkubeletの同期期間+キャッシュの伝搬遅延になります。ここで、キャッシュの伝搬遅延は選択したキャッシュの種類に依存します(監視の伝搬遅延、キャッシュのttl、または0に等しくなります)。
|
||||
|
||||
{{< feature-state for_k8s_version="v1.18" state="alpha" >}}
|
||||
環境変数として使用されるConfigMapは自動的に更新されないため、ポッドを再起動する必要があります。
|
||||
## イミュータブルなConfigMap {#configmap-immutable}
|
||||
|
||||
Kubernetesのアルファ版の機能である _イミュータブルなSecretおよびConfigMap_ は、個別のSecretやConfigMapをイミュータブルに設定するオプションを提供します。ConfigMapを広範に使用している(少なくとも数万のConfigMapがPodにマウントされている)クラスターでは、データの変更を防ぐことにより、以下のような利点が得られます。
|
||||
{{< feature-state for_k8s_version="v1.19" state="beta" >}}
|
||||
|
||||
Kubernetesのベータ版の機能である _イミュータブルなSecretおよびConfigMap_ は、個別のSecretやConfigMapをイミュータブルに設定するオプションを提供します。ConfigMapを広範に使用している(少なくとも数万のConfigMapがPodにマウントされている)クラスターでは、データの変更を防ぐことにより、以下のような利点が得られます。
|
||||
|
||||
- アプリケーションの停止を引き起こす可能性のある予想外の(または望まない)変更を防ぐことができる
|
||||
- ConfigMapをイミュータブルにマークして監視を停止することにより、kube-apiserverへの負荷を大幅に削減し、クラスターの性能が向上する
|
||||
|
||||
この機能を使用するには、`ImmutableEmphemeralVolumes`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にして、SecretやConfigMapの`immutable`フィールドを`true`に設定してください。次に例を示します。
|
||||
この機能は、`ImmutableEmphemeralVolumes`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)によって管理されます。`immutable`フィールドを`true`に設定することで、イミュータブルなConfigMapを作成できます。次に例を示します。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
@@ -180,9 +188,7 @@ data:
|
||||
immutable: true
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
一度ConfigMapやSecretがイミュータブルに設定すると、この変更を元に戻したり、`data`フィールドのコンテンツを変更することは*できません*。既存のPodは削除されたConfigMapのマウントポイントを保持するため、こうしたPodは再作成することをおすすめします。
|
||||
{{< /note >}}
|
||||
一度ConfigMapがイミュータブルに設定されると、この変更を元に戻したり、`data`または`binaryData`フィールドのコンテンツを変更することは*できません*。ConfigMapの削除と再作成のみ可能です。既存のPodは削除されたConfigMapのマウントポイントを保持するため、こうしたPodは再作成することをおすすめします。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
@@ -29,6 +29,10 @@ Podが動作しているNodeに利用可能なリソースが十分にある場
|
||||
制限は、違反が検出されるとシステムが介入するように事後的に、またはコンテナーが制限を超えないようにシステムが防ぐように強制的に、実装できます。
|
||||
異なるランタイムは、同じ制限を実装するために異なる方法をとることができます。
|
||||
|
||||
{{< note >}}
|
||||
コンテナが自身のメモリー制限を指定しているが、メモリー要求を指定していない場合、Kubernetesは制限に一致するメモリー要求を自動的に割り当てます。同様に、コンテナが自身のCPU制限を指定しているが、CPU要求を指定していない場合、Kubernetesは制限に一致するCPU要求を自動的に割り当てます。
|
||||
{{< /note >}}
|
||||
|
||||
## リソースタイプ
|
||||
|
||||
*CPU*と*メモリー*はいずれも*リソースタイプ*です。リソースタイプには基本単位があります。
|
||||
@@ -84,7 +88,7 @@ CPUは常に相対量としてではなく、絶対量として要求されま
|
||||
### メモリーの意味
|
||||
|
||||
`メモリー`の制限と要求はバイト単位で測定されます。
|
||||
E、P、T、G、M、Kのいずれかのサフィックスを使用して、メモリーを整数または固定小数点整数として表すことができます。
|
||||
E、P、T、G、M、Kのいずれかのサフィックスを使用して、メモリーを整数または固定小数点数として表すことができます。
|
||||
また、Ei、Pi、Ti、Gi、Mi、Kiのような2の累乗の値を使用することもできます。
|
||||
たとえば、以下はほぼ同じ値を表しています。
|
||||
|
||||
@@ -104,11 +108,8 @@ metadata:
|
||||
name: frontend
|
||||
spec:
|
||||
containers:
|
||||
- name: db
|
||||
image: mysql
|
||||
env:
|
||||
- name: MYSQL_ROOT_PASSWORD
|
||||
value: "password"
|
||||
- name: app
|
||||
image: images.my-company.example/app:v4
|
||||
resources:
|
||||
requests:
|
||||
memory: "64Mi"
|
||||
@@ -116,8 +117,8 @@ spec:
|
||||
limits:
|
||||
memory: "128Mi"
|
||||
cpu: "500m"
|
||||
- name: wp
|
||||
image: wordpress
|
||||
- name: log-aggregator
|
||||
image: images.my-company.example/log-aggregator:v6
|
||||
resources:
|
||||
requests:
|
||||
memory: "64Mi"
|
||||
@@ -185,7 +186,7 @@ kubeletは、ローカルのエフェメラルストレージを使用して、P
|
||||
また、kubeletはこの種類のストレージを使用して、[Nodeレベルのコンテナログ](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)、コンテナイメージ、実行中のコンテナの書き込み可能なレイヤーを保持します。
|
||||
|
||||
{{< caution >}}
|
||||
Nodeに障害が発生すると、そのエフェメラルストレージ内のデータが失われる可能性があります。
|
||||
Nodeに障害が発生すると、そのエフェメラルストレージ内のデータが失われる可能性があります。
|
||||
アプリケーションは、ローカルのエフェメラルストレージにパフォーマンスのサービス品質保証(ディスクのIOPSなど)を期待することはできません。
|
||||
{{< /caution >}}
|
||||
|
||||
@@ -242,7 +243,7 @@ Podの各コンテナは、次の1つ以上を指定できます。
|
||||
* `spec.containers[].resources.requests.ephemeral-storage`
|
||||
|
||||
`ephemeral-storage`の制限と要求はバイト単位で記します。
|
||||
ストレージは、次のいずれかの接尾辞を使用して、通常の整数または固定小数点整数として表すことができます。
|
||||
ストレージは、次のいずれかの接尾辞を使用して、通常の整数または固定小数点数として表すことができます。
|
||||
E、P、T、G、M、K。Ei、Pi、Ti、Gi、Mi、Kiの2のべき乗を使用することもできます。
|
||||
たとえば、以下はほぼ同じ値を表しています。
|
||||
|
||||
@@ -262,18 +263,15 @@ metadata:
|
||||
name: frontend
|
||||
spec:
|
||||
containers:
|
||||
- name: db
|
||||
image: mysql
|
||||
env:
|
||||
- name: MYSQL_ROOT_PASSWORD
|
||||
value: "password"
|
||||
- name: app
|
||||
image: images.my-company.example/app:v4
|
||||
resources:
|
||||
requests:
|
||||
ephemeral-storage: "2Gi"
|
||||
limits:
|
||||
ephemeral-storage: "4Gi"
|
||||
- name: wp
|
||||
image: wordpress
|
||||
- name: log-aggregator
|
||||
image: images.my-company.example/log-aggregator:v6
|
||||
resources:
|
||||
requests:
|
||||
ephemeral-storage: "2Gi"
|
||||
@@ -300,6 +298,7 @@ kubeletがローカルのエフェメラルストレージをリソースとし
|
||||
Podが許可するよりも多くのエフェメラルストレージを使用している場合、kubeletはPodの排出をトリガーするシグナルを設定します。
|
||||
|
||||
コンテナレベルの分離の場合、コンテナの書き込み可能なレイヤーとログ使用量がストレージの制限を超えると、kubeletはPodに排出のマークを付けます。
|
||||
|
||||
Podレベルの分離の場合、kubeletはPod内のコンテナの制限を合計し、Podの全体的なストレージ制限を計算します。
|
||||
このケースでは、すべてのコンテナからのローカルのエフェメラルストレージの使用量とPodの`emptyDir`ボリュームの合計がPod全体のストレージ制限を超過する場合、
|
||||
kubeletはPodをまた排出対象としてマークします。
|
||||
@@ -345,7 +344,7 @@ Kubernetesでは、`1048576`から始まるプロジェクトIDを使用しま
|
||||
Kubernetesが使用しないようにする必要があります。
|
||||
|
||||
クォータはディレクトリスキャンよりも高速で正確です。
|
||||
ディレクトリがプロジェクトに割り当てられると、ディレクトリ配下に作成されたファイルはすべてそのプロジェクト内に作成され、カーネルはそのプロジェクト内のファイルによって使用されているブロックの数を追跡するだけです。
|
||||
ディレクトリがプロジェクトに割り当てられると、ディレクトリ配下に作成されたファイルはすべてそのプロジェクト内に作成され、カーネルはそのプロジェクト内のファイルによって使用されているブロックの数を追跡するだけです。
|
||||
ファイルが作成されて削除されても、開いているファイルディスクリプタがあれば、スペースを消費し続けます。
|
||||
クォータトラッキングはそのスペースを正確に記録しますが、ディレクトリスキャンは削除されたファイルが使用するストレージを見落としてしまいます。
|
||||
|
||||
@@ -354,7 +353,7 @@ Kubernetesが使用しないようにする必要があります。
|
||||
* kubelet設定で、`LocalocalStorpactionCapactionIsolationFSQuotaMonitoring=true`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gate/)を有効にします。
|
||||
|
||||
* ルートファイルシステム(またはオプションのランタイムファイルシステム))がプロジェクトクォータを有効にしていることを確認してください。
|
||||
すべてのXFSファイルシステムはプロジェクトクォータをサポートしています。
|
||||
すべてのXFSファイルシステムはプロジェクトクォータをサポートしています。
|
||||
ext4ファイルシステムでは、ファイルシステムがマウントされていない間は、プロジェクトクォータ追跡機能を有効にする必要があります。
|
||||
```bash
|
||||
# ext4の場合、/dev/block-deviceがマウントされていません
|
||||
|
||||
@@ -0,0 +1,240 @@
|
||||
---
|
||||
title: Podの優先度とプリエンプション
|
||||
content_type: concept
|
||||
weight: 70
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state for_k8s_version="v1.14" state="stable" >}}
|
||||
|
||||
[Pod](/ja/docs/concepts/workloads/pods/)は _priority_（優先度）を持つことができます。
|
||||
優先度は他のPodに対する相対的なPodの重要度を示します。
|
||||
もしPodをスケジューリングできないときには、スケジューラーはそのPodをスケジューリングできるようにするため、優先度の低いPodをプリエンプトする（追い出す）ことを試みます。
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
|
||||
{{< warning >}}
|
||||
クラスターの全てのユーザーが信用されていない場合、悪意のあるユーザーが可能な範囲で最も高い優先度のPodを作成することが可能です。これは他のPodが追い出されたりスケジューリングできない状態を招きます。
|
||||
管理者はResourceQuotaを使用して、ユーザーがPodを高い優先度で作成することを防ぐことができます。
|
||||
|
||||
詳細は[デフォルトで優先度クラスの消費を制限する](/ja/docs/concepts/policy/resource-quotas/#limit-priority-class-consumption-by-default)
|
||||
を参照してください。
|
||||
{{< /warning >}}
|
||||
|
||||
## 優先度とプリエンプションを使う方法
|
||||
|
||||
優先度とプリエンプションを使うには、
|
||||
|
||||
1. 1つまたは複数の[PriorityClass](#priorityclass)を追加します
|
||||
|
||||
1. 追加したPriorityClassを[`priorityClassName`](#pod-priority)に設定したPodを作成します。
|
||||
もちろんPodを直接作る必要はありません。
|
||||
一般的には`priorityClassName`をDeploymentのようなコレクションオブジェクトのPodテンプレートに追加します。
|
||||
|
||||
これらの手順のより詳しい情報については、この先を読み進めてください。
|
||||
|
||||
{{< note >}}
|
||||
Kubernetesには最初から既に2つのPriorityClassが設定された状態になっています。
|
||||
`system-cluster-critical`と`system-node-critical`です。
|
||||
これらは汎用のクラスであり、[重要なコンポーネントが常に最初にスケジュールされることを保証する](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/)ために使われます。
|
||||
{{< /note >}}
|
||||
|
||||
## PriorityClass
|
||||
|
||||
PriorityClassはnamespaceによらないオブジェクトで、優先度クラスの名称から優先度を表す整数値への対応を定義します。
|
||||
PriorityClassオブジェクトのメタデータの`name`フィールドにて名称を指定します。
|
||||
値は`value`フィールドで指定し、必須です。
|
||||
値が大きいほど、高い優先度を示します。
|
||||
PriorityClassオブジェクトの名称は[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)として適切であり、かつ`system-`から始まってはいけません。
|
||||
|
||||
PriorityClassオブジェクトは10億以下の任意の32ビットの整数値を持つことができます。
|
||||
それよりも大きな値は通常はプリエンプトや追い出すべきではない重要なシステム用のPodのために予約されています。
|
||||
クラスターの管理者は割り当てたい優先度に対して、PriorityClassオブジェクトを1つずつ作成すべきです。
|
||||
|
||||
PriorityClassは任意でフィールド`globalDefault`と`description`を設定可能です。
|
||||
`globalDefault`フィールドは`priorityClassName`が指定されないPodはこのPriorityClassを使うべきであることを示します。`globalDefault`がtrueに設定されたPriorityClassはシステムで一つのみ存在可能です。`globalDefault`が設定されたPriorityClassが存在しない場合は、`priorityClassName`が設定されていないPodの優先度は0に設定されます。
|
||||
|
||||
`description`フィールドは任意の文字列です。クラスターの利用者に対して、PriorityClassをどのような時に使うべきか示すことを意図しています。
|
||||
|
||||
### PodPriorityと既存のクラスターに関する注意
|
||||
|
||||
- もし既存のクラスターをこの機能がない状態でアップグレードすると、既存のPodの優先度は実質的に0になります。
|
||||
|
||||
- `globalDefault`が`true`に設定されたPriorityClassを追加しても、既存のPodの優先度は変わりません。PriorityClassのそのような値は、PriorityClassが追加された以後に作成されたPodのみに適用されます。
|
||||
|
||||
- PriorityClassを削除した場合、削除されたPriorityClassの名前を使用する既存のPodは変更されませんが、削除されたPriorityClassの名前を使うPodをそれ以上作成することはできなくなります。
|
||||
|
||||
### PriorityClassの例
|
||||
|
||||
```yaml
|
||||
apiVersion: scheduling.k8s.io/v1
|
||||
kind: PriorityClass
|
||||
metadata:
|
||||
name: high-priority
|
||||
value: 1000000
|
||||
globalDefault: false
|
||||
description: "この優先度クラスはXYZサービスのPodに対してのみ使用すべきです。"
|
||||
```
|
||||
|
||||
## 非プリエンプトのPriorityClass {#non-preempting-priority-class}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.19" state="beta" >}}
|
||||
|
||||
`PreemptionPolicy: Never`と設定されたPodは、スケジューリングのキューにおいて他の優先度の低いPodよりも優先されますが、他のPodをプリエンプトすることはありません。
|
||||
スケジューリングされるのを待つ非プリエンプトのPodは、リソースが十分に利用可能になるまでスケジューリングキューに残ります。
|
||||
非プリエンプトのPodは、他のPodと同様に、スケジューラーのバックオフの対象になります。これは、スケジューラーがPodをスケジューリングしようと試みたものの失敗した場合、低い頻度で再試行するようにして、より優先度の低いPodが先にスケジューリングされることを許します。
|
||||
|
||||
非プリエンプトのPodは、他の優先度の高いPodにプリエンプトされる可能性はあります。
|
||||
|
||||
`PreemptionPolicy`はデフォルトでは`PreemptLowerPriority`に設定されており、これが設定されているPodは優先度の低いPodをプリエンプトすることを許容します。これは既存のデフォルトの挙動です。
|
||||
`PreemptionPolicy`を`Never`に設定すると、これが設定されたPodはプリエンプトを行わないようになります。
|
||||
|
||||
ユースケースの例として、データサイエンスの処理を挙げます。
|
||||
ユーザーは他の処理よりも優先度を高くしたいジョブを追加できますが、そのとき既存の実行中のPodの処理結果をプリエンプトによって破棄させたくはありません。
|
||||
`PreemptionPolicy: Never`が設定された優先度の高いジョブは、他の既にキューイングされたPodよりも先に、クラスターのリソースが「自然に」開放されたときにスケジューリングされます。
|
||||
|
||||
### 非プリエンプトのPriorityClassの例
|
||||
|
||||
```yaml
|
||||
apiVersion: scheduling.k8s.io/v1
|
||||
kind: PriorityClass
|
||||
metadata:
|
||||
name: high-priority-nonpreempting
|
||||
value: 1000000
|
||||
preemptionPolicy: Never
|
||||
globalDefault: false
|
||||
description: "この優先度クラスは他のPodをプリエンプトさせません。"
|
||||
```
|
||||
|
||||
## Podの優先度 {#pod-priority}
|
||||
|
||||
一つ以上のPriorityClassがあれば、仕様にPriorityClassを指定したPodを作成することができるようになります。優先度のアドミッションコントローラーは`priorityClassName`フィールドを使用し、優先度の整数値を設定します。PriorityClassが見つからない場合、そのPodの作成は拒否されます。
|
||||
|
||||
下記のYAMLは上記の例で作成したPriorityClassを使用するPodの設定の例を示します。優先度のアドミッションコントローラーは仕様を確認し、このPodの優先度は1000000であると設定します。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: nginx
|
||||
labels:
|
||||
env: test
|
||||
spec:
|
||||
containers:
|
||||
- name: nginx
|
||||
image: nginx
|
||||
imagePullPolicy: IfNotPresent
|
||||
priorityClassName: high-priority
|
||||
```
|
||||
|
||||
### スケジューリング順序におけるPodの優先度の効果
|
||||
|
||||
Podの優先度が有効な場合、スケジューラーは待機状態のPodをそれらの優先度順に並べ、スケジューリングキューにおいてより優先度の低いPodよりも前に来るようにします。その結果、その条件を満たしたときには優先度の高いPodは優先度の低いPodより早くスケジューリングされます。優先度の高いPodがスケジューリングできない場合は、スケジューラーは他の優先度の低いPodのスケジューリングも試みます。
|
||||
|
||||
## プリエンプション
|
||||
|
||||
Podが作成されると、スケジューリング待ちのキューに入り待機状態になります。スケジューラーはキューからPodを取り出し、ノードへのスケジューリングを試みます。Podに指定された条件を全て満たすノードが見つからない場合は、待機状態のPodのためにプリエンプションロジックが発動します。待機状態のPodをPと呼ぶことにしましょう。プリエンプションロジックはPよりも優先度の低いPodを一つ以上追い出せばPをスケジューリングできるようになるノードを探します。そのようなノードがあれば、優先度の低いPodはノードから追い出されます。Podが追い出された後に、Pはノードへスケジューリング可能になります。
|
||||
|
||||
### ユーザーへ開示される情報
|
||||
|
||||
Pod PがノードNのPodをプリエンプトした場合、ノードNの名称がPのステータスの`nominatedNodeName`フィールドに設定されます。このフィールドはスケジューラーがPod Pのために予約しているリソースの追跡を助け、ユーザーにクラスターにおけるプリエンプトに関する情報を与えます。
|
||||
|
||||
Pod Pは必ずしも「指名したノード」へスケジューリングされないことに注意してください。Podがプリエンプトされると、そのPodは終了までの猶予期間を得ます。スケジューラーがPodの終了を待つ間に他のノードが利用可能になると、スケジューラーは他のノードをPod Pのスケジューリング先にします。この結果、Podの`nominatedNodeName`と`nodeName`は必ずしも一致しません。また、スケジューラーがノードNのPodをプリエンプトさせた後に、Pod Pよりも優先度の高いPodが来た場合、スケジューラーはノードNをその新しい優先度の高いPodへ与えます。このような場合は、スケジューラーはPod Pの`nominatedNodeName`を消去します。これによって、スケジューラーはPod Pが他のノードのPodをプリエンプトさせられるようにします。
|
||||
|
||||
### プリエンプトの制限
|
||||
|
||||
#### プリエンプトされるPodの正常終了
|
||||
|
||||
Podがプリエンプトされると、[猶予期間](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)が与えられます。
|
||||
|
||||
Podは作業を完了し、終了するために十分な時間が与えられます。仮にそうでない場合、強制終了されます。この猶予期間によって、スケジューラーがPodをプリエンプトした時刻と、待機状態のPod Pがノード Nにスケジュール可能になるまでの時刻の間に間が開きます。この間、スケジューラーは他の待機状態のPodをスケジュールしようと試みます。プリエンプトされたPodが終了したら、スケジューラーは待ち行列にあるPodをスケジューリングしようと試みます。そのため、Podがプリエンプトされる時刻と、Pがスケジュールされた時刻には間が開くことが一般的です。この間を最小にするには、優先度の低いPodの猶予期間を0または小さい値にする方法があります。
|
||||
|
||||
#### PodDisruptionBudgetは対応するが、保証されない
|
||||
|
||||
[PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) (PDB)は、アプリケーションのオーナーが冗長化されたアプリケーションのPodが意図的に中断される数の上限を設定できるようにするものです。KubernetesはPodをプリエンプトする際にPDBに対応しますが、PDBはベストエフォートで考慮します。スケジューラーはプリエンプトさせたとしてもPDBに違反しないPodを探します。そのようなPodが見つからない場合でもプリエンプションは実行され、PDBに反しますが優先度の低いPodが追い出されます。
|
||||
|
||||
#### 優先度の低いPodにおけるPod間のアフィニティ
|
||||
|
||||
次の条件が真の場合のみ、ノードはプリエンプションの候補に入ります。
|
||||
「待機状態のPodよりも優先度の低いPodをノードから全て追い出したら、待機状態のPodをノードへスケジュールできるか」
|
||||
|
||||
{{< note >}}
|
||||
プリエンプションは必ずしも優先度の低いPodを全て追い出しません。
|
||||
優先度の低いPodを全て追い出さなくても待機状態のPodがスケジューリングできる場合、一部のPodのみ追い出されます。
|
||||
このような場合であったとしても、上記の条件は真である必要があります。偽であれば、そのノードはプリエンプションの対象とはされません。
|
||||
{{< /note >}}
|
||||
|
||||
待機状態のPodが、優先度の低いPodとの間でPod間のアフィニティを持つ場合、Pod間のアフィニティはそれらの優先度の低いPodがなければ満たされません。この場合、スケジューラーはノードのどのPodもプリエンプトしようとはせず、代わりに他のノードを探します。スケジューラーは適切なノードを探せる場合と探せない場合があります。この場合、待機状態のPodがスケジューリングされる保証はありません。
|
||||
|
||||
この問題に対して推奨される解決策は、優先度が同一または高いPodに対してのみPod間のアフィニティを作成することです。
|
||||
|
||||
#### 複数ノードに対するプリエンプション
|
||||
|
||||
Pod PがノードNにスケジューリングできるよう、ノードNがプリエンプションの対象となったとします。
|
||||
他のノードのPodがプリエンプトされた場合のみPが実行可能になることもあります。下記に例を示します。
|
||||
|
||||
* Pod PをノードNに配置することを検討します。
|
||||
* Pod QはノードNと同じゾーンにある別のノードで実行中です。
|
||||
* Pod Pはゾーンに対するQへのアンチアフィニティを持ちます (`topologyKey: topology.kubernetes.io/zone`)。
|
||||
* Pod Pと、ゾーン内の他のPodに対しては他のアンチアフィニティはない状態です。
|
||||
* Pod PをノードNへスケジューリングするには、Pod Qをプリエンプトすることが考えられますが、スケジューラーは複数ノードにわたるプリエンプションは行いません。そのため、Pod PはノードNへはスケジューリングできないとみなされます。
|
||||
|
||||
Pod Qがそのノードから追い出されると、Podアンチアフィニティに違反しなくなるので、Pod PはノードNへスケジューリング可能になります。
|
||||
|
||||
複数ノードに対するプリエンプションに関しては、十分な需要があり、合理的な性能を持つアルゴリズムを見つけられた場合に、追加することを検討する可能性があります。
|
||||
|
||||
## トラブルシューティング
|
||||
|
||||
Podの優先度とプリエンプションは望まない副作用をもたらす可能性があります。
|
||||
いくつかの起こりうる問題と、その対策について示します。
|
||||
|
||||
### Podが不必要にプリエンプトされる
|
||||
|
||||
プリエンプションは、リソースが不足している場合に優先度の高い待機状態のPodのためにクラスターの既存のPodを追い出します。
|
||||
誤って高い優先度をPodに割り当てると、意図しない高い優先度のPodはクラスター内でプリエンプションを引き起こす可能性があります。Podの優先度はPodの仕様の`priorityClassName`フィールドにて指定されます。優先度を示す整数値へと変換された後、`podSpec`の`priority`へ設定されます。
|
||||
|
||||
この問題に対処するには、Podの`priorityClassName`をより低い優先度に変更するか、このフィールドを未設定にすることができます。`priorityClassName`が未設定の場合、デフォルトでは優先度は0とされます。
|
||||
|
||||
Podがプリエンプトされたとき、プリエンプトされたPodのイベントが記録されます。
|
||||
プリエンプションはPodに必要なリソースがクラスターにない場合のみ起こるべきです。
|
||||
このような場合、プリエンプションはプリエンプトされるPodよりも待機状態のPodの優先度が高い場合のみ発生します。
|
||||
プリエンプションは待機状態のPodがない場合や待機状態のPodがプリエンプト対象のPod以下の優先度を持つ場合には決して発生しません。そのような状況でプリエンプションが発生した場合、問題を報告してください。
|
||||
|
||||
### Podはプリエンプトされたが、プリエンプトさせたPodがスケジューリングされない
|
||||
|
||||
Podがプリエンプトされると、それらのPodが要求した猶予期間が与えられます。そのデフォルトは30秒です。
|
||||
Podがその期間内に終了しない場合、強制終了されます。プリエンプトされたPodがなくなれば、プリエンプトさせたPodはスケジューリング可能です。
|
||||
|
||||
プリエンプトさせたPodがプリエンプトされたPodの終了を待っている間に、より優先度の高いPodが同じノードに対して作成されることもあります。この場合、スケジューラーはプリエンプトさせたPodの代わりに優先度の高いPodをスケジューリングします。
|
||||
|
||||
これは予期された挙動です。優先度の高いPodは優先度の低いPodに取って代わります。
|
||||
|
||||
### 優先度の高いPodが優先度の低いPodより先にプリエンプトされる
|
||||
|
||||
スケジューラーは待機状態のPodが実行可能なノードを探します。ノードが見つからない場合、スケジューラーは任意のノードから優先度の低いPodを追い出し、待機状態のPodのためのリソースを確保しようとします。
|
||||
仮に優先度の低いPodが動いているノードが待機状態のPodを動かすために適切ではない場合、スケジューラーは他のノードで動いているPodと比べると、優先度の高いPodが動いているノードをプリエンプションの対象に選ぶことがあります。この場合もプリエンプトされるPodはプリエンプトを起こしたPodよりも優先度が低い必要があります。
|
||||
|
||||
複数のノードがプリエンプションの対象にできる場合、スケジューラーは優先度が最も低いPodのあるノードを選ぼうとします。しかし、そのようなPodがPodDisruptionBudgetを持っており、プリエンプトするとPDBに反する場合はスケジューラーは優先度の高いPodのあるノードを選ぶこともあります。
|
||||
|
||||
複数のノードがプリエンプションの対象として利用可能で、上記の状況に当てはまらない場合、スケジューラーは優先度の最も低いノードを選択します。
|
||||
|
||||
## Podの優先度とQoSの相互作用 {#interactions-of-pod-priority-and-qos}
|
||||
|
||||
Podの優先度と{{< glossary_tooltip text="QoSクラス" term_id="qos-class" >}}は直交する機能で、わずかに相互作用がありますが、デフォルトではQoSクラスによる優先度の設定の制約はありません。スケジューラーのプリエンプションのロジックはプリエンプションの対象を決めるときにQoSクラスは考慮しません。
|
||||
プリエンプションはPodの優先度を考慮し、優先度が最も低いものを候補とします。より優先度の高いPodは優先度の低いPodを追い出すだけではプリエンプトを起こしたPodのスケジューリングに不十分な場合と、`PodDisruptionBudget`により優先度の低いPodが保護されている場合のみ対象になります。
|
||||
|
||||
QoSとPodの優先度の両方を考慮するコンポーネントは[リソース不足によりkubeletがPodを追い出す](/docs/tasks/administer-cluster/out-of-resource/)のみです。
|
||||
kubeletは追い出すPodの順位付けを次の順で行います。枯渇したリソースを要求以上に使用しているか、優先度、枯渇したリソースの消費量の複数のPodの要求に対する相対値。
|
||||
詳細は[エンドユーザーのPodの追い出し](/docs/tasks/administer-cluster/out-of-resource/#evicting-end-user-pods)を参照してください。
|
||||
|
||||
|
||||
kubeletによるリソース不足時のPodの追い出しでは、リソースの消費が要求を超えないPodは追い出されません。優先度の低いPodのリソースの利用量がその要求を超えていなければ、追い出されることはありません。より優先度が高く、要求を超えてリソースを使用しているPodが追い出されます。
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* PriorityClassと関連付けてResourceQuotaを使用することに関して [デフォルトで優先度クラスの消費を制限する](/ja/docs/concepts/policy/resource-quotas/#limit-priority-class-consumption-by-default)
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Secrets
|
||||
title: Secret
|
||||
content_type: concept
|
||||
feature:
|
||||
title: Secretと構成管理
|
||||
@@ -11,18 +11,18 @@ weight: 30
|
||||
<!-- overview -->
|
||||
|
||||
KubernetesのSecretはパスワード、OAuthトークン、SSHキーのような機密情報を保存し、管理できるようにします。
|
||||
Secretに機密情報を保存することは、それらを{{< glossary_tooltip text="Pod" term_id="pod" >}}の定義や{{< glossary_tooltip text="コンテナイメージ" term_id="image" >}}に直接記載するより、安全で柔軟です。詳しくは[Secretの設計文書](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md)を参照してください。
|
||||
Secretに機密情報を保存することは、それらを{{< glossary_tooltip text="Pod" term_id="pod" >}}の定義や{{< glossary_tooltip text="コンテナイメージ" term_id="image" >}}に直接記載するより、安全で柔軟です。
|
||||
詳しくは[Secretの設計文書](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md)を参照してください。
|
||||
|
||||
Secretはパスワード、トークン、キーのような小容量の機密データを含むオブジェクトです。
|
||||
他の方法としては、そのような情報はPodの定義やイメージに含めることができます。
|
||||
ユーザーはSecretを作ることができ、またシステムが作るSecretもあります。
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Secretの概要
|
||||
|
||||
Secretはパスワード、トークン、キーのような小容量の機密データを含むオブジェクトです。
|
||||
他の方法としては、そのような情報はPodの定義やイメージに含めることができます。
|
||||
ユーザーはSecretを作ることができ、またシステムが作るSecretもあります。
|
||||
|
||||
Secretを使うには、PodはSecretを参照することが必要です。
|
||||
PodがSecretを使う方法は3種類あります。
|
||||
|
||||
@@ -30,392 +30,292 @@ PodがSecretを使う方法は3種類あります。
|
||||
- [コンテナの環境変数](#using-secrets-as-environment-variables)として利用する
|
||||
- Podを生成するために[kubeletがイメージをpullする](#using-imagepullsecrets)ときに使用する
|
||||
|
||||
### 内蔵のSecret
|
||||
|
||||
#### 自動的にサービスアカウントがAPIの認証情報のSecretを生成し、アタッチする
|
||||
|
||||
KubernetesはAPIにアクセスするための認証情報を含むSecretを自動的に生成し、この種のSecretを使うように自動的にPodを改変します。
|
||||
|
||||
必要であれば、APIの認証情報が自動生成され利用される機能は無効化したり、上書きしたりすることができます。しかし、安全にAPIサーバーでアクセスすることのみが必要なのであれば、これは推奨されるワークフローです。
|
||||
|
||||
サービスアカウントがどのように機能するのかについては、[サービスアカウント](/docs/tasks/configure-pod-container/configure-service-account/)
|
||||
のドキュメントを参照してください。
|
||||
|
||||
### Secretを作成する
|
||||
|
||||
#### `kubectl`を利用してSecretを作成する
|
||||
|
||||
SecretにはPodがデータベースにアクセスするために必要な認証情報を含むことができます。
|
||||
例えば、ユーザー名とパスワードからなる接続文字列です。
|
||||
ローカルマシンのファイル`./username.txt`にユーザー名を、ファイル`./password.txt`にパスワードを保存することができます。
|
||||
|
||||
```shell
|
||||
# この後の例で使用するファイルを作成します
|
||||
echo -n 'admin' > ./username.txt
|
||||
echo -n '1f2d1e2e67df' > ./password.txt
|
||||
```
|
||||
|
||||
`kubectl create secret`コマンドはそれらのファイルをSecretに格納して、APIサーバー上でオブジェクトを作成します。
|
||||
Secretオブジェクトの名称は正当な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names)である必要があります。
|
||||
シークレットの構成ファイルを作成するときに、`data`および/または`stringData`フィールドを指定できます。`data`フィールドと`stringData`フィールドはオプションです。
|
||||
`data`フィールドのすべてのキーの値は、base64でエンコードされた文字列である必要があります。
|
||||
base64文字列への変換が望ましくない場合は、代わりに`stringData`フィールドを指定することを選択できます。これは任意の文字列を値として受け入れます。
|
||||
|
||||
|
||||
`data`と`stringData`のキーは、英数字、`-`、`_`、または`.`で構成されている必要があります。
|
||||
`stringData`フィールドのすべてのキーと値のペアは、内部で`data`フィールドにマージされます。
|
||||
キーが`data`フィールドと`stringData`フィールドの両方に表示される場合、`stringData`フィールドで指定された値が優先されます。
|
||||
|
||||
## Secretの種類 {#secret-types}
|
||||
|
||||
Secretを作成するときは、[`Secret`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)の`type`フィールド、または特定の同等の`kubectl`コマンドラインフラグ（使用可能な場合）を使用して、その型を指定できます。
|
||||
Secret型は、Secret dataのプログラムによる処理を容易にするために使用されます。
|
||||
|
||||
Kubernetesは、いくつかの一般的な使用シナリオに対応するいくつかの組み込み型を提供します。
|
||||
これらの型は、実行される検証とKubernetesが課す制約の点で異なります。
|
||||
|
||||
| Builtin Type | Usage |
|
||||
|--------------|-------|
|
||||
| `Opaque` | arbitrary user-defined data |
|
||||
| `kubernetes.io/service-account-token` | service account token |
|
||||
| `kubernetes.io/dockercfg` | serialized `~/.dockercfg` file |
|
||||
| `kubernetes.io/dockerconfigjson` | serialized `~/.docker/config.json` file |
|
||||
| `kubernetes.io/basic-auth` | credentials for basic authentication |
|
||||
| `kubernetes.io/ssh-auth` | credentials for SSH authentication |
|
||||
| `kubernetes.io/tls` | data for a TLS client or server |
|
||||
| `bootstrap.kubernetes.io/token` | bootstrap token data |
|
||||
|
||||
Secretオブジェクトの`type`値として空でない文字列を割り当てることにより、独自のSecret型を定義して使用できます。空の文字列は`Opaque`型として扱われます。Kubernetesは型名に制約を課しません。ただし、組み込み型の1つを使用している場合は、その型に定義されているすべての要件を満たす必要があります。
|
||||
|
||||
### Opaque secrets
|
||||
|
||||
`Opaque`は、Secret構成ファイルから省略された場合のデフォルトのSecret型です。
|
||||
`kubectl`を使用してSecretを作成する場合、`generic`サブコマンドを使用して`Opaque`Secret型を示します。 たとえば、次のコマンドは、`Opaque`型の空のSecretを作成します。
|
||||
|
||||
```shell
|
||||
kubectl create secret generic db-user-pass --from-file=./username.txt --from-file=./password.txt
|
||||
```
|
||||
|
||||
次のように出力されます:
|
||||
|
||||
```
|
||||
secret "db-user-pass" created
|
||||
```
|
||||
|
||||
デフォルトのキー名はファイル名です。`[--from-file=[key=]source]`を使って任意でキーを指定することができます。
|
||||
|
||||
```shell
|
||||
kubectl create secret generic db-user-pass --from-file=username=./username.txt --from-file=password=./password.txt
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
`$`、`\`、`*`、`=`、`!`のような特殊文字は[シェル](https://ja.wikipedia.org/wiki/%E3%82%B7%E3%82%A7%E3%83%AB)に解釈されるので、エスケープする必要があります。
|
||||
ほとんどのシェルではパスワードをエスケープする最も簡単な方法はシングルクォート(`'`)で囲むことです。
|
||||
例えば、実際のパスワードが`S!B\*d$zDsb=`だとすると、実行すべきコマンドは下記のようになります。
|
||||
|
||||
```shell
|
||||
kubectl create secret generic dev-db-secret --from-literal=username=devuser --from-literal=password='S!B\*d$zDsb='
|
||||
```
|
||||
|
||||
`--from-file`を使ってファイルからパスワードを読み込む場合、ファイルに含まれるパスワードの特殊文字をエスケープする必要はありません。
|
||||
{{< /note >}}
|
||||
|
||||
Secretが作成されたことを確認できます。
|
||||
|
||||
```shell
|
||||
kubectl get secrets
|
||||
kubectl create secret generic empty-secret
|
||||
kubectl get secret empty-secret
|
||||
```
|
||||
|
||||
出力は次のようになります。
|
||||
|
||||
```
|
||||
NAME TYPE DATA AGE
|
||||
db-user-pass Opaque 2 51s
|
||||
NAME TYPE DATA AGE
|
||||
empty-secret Opaque 0 2m6s
|
||||
```
|
||||
|
||||
Secretの説明を参照することができます。
|
||||
`DATA`列には、Secretに保存されているデータ項目の数が表示されます。
|
||||
この場合、`0`は空のSecretを作成したことを意味します。
|
||||
|
||||
```shell
|
||||
kubectl describe secrets/db-user-pass
|
||||
```
|
||||
### Service account token Secrets
|
||||
|
||||
出力は次のようになります。
|
||||
|
||||
```
|
||||
Name: db-user-pass
|
||||
Namespace: default
|
||||
Labels: <none>
|
||||
Annotations: <none>
|
||||
|
||||
Type: Opaque
|
||||
|
||||
Data
|
||||
====
|
||||
password.txt: 12 bytes
|
||||
username.txt: 5 bytes
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
`kubectl get`や`kubectl describe`コマンドはデフォルトではSecretの内容の表示を避けます。
|
||||
これはSecretを誤って盗み見られたり、ターミナルのログへ記録されてしまったりすることがないよう保護するためです。
|
||||
{{< /note >}}
|
||||
|
||||
Secretの内容を参照する方法は[Secretのデコード](#decoding-a-secret)を参照してください。
|
||||
|
||||
#### 手動でSecretを作成する
|
||||
|
||||
SecretをJSONまたはYAMLフォーマットのファイルで作成し、その後オブジェクトを作成することができます。
|
||||
Secretオブジェクトの名称は正当な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names)である必要があります。
|
||||
[Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)は、`data`と`stringData`の2つの連想配列を持ちます。
|
||||
`data`フィールドは任意のデータの保存に使われ、Base64でエンコードされています。
|
||||
`stringData`は利便性のために存在するもので、機密データをエンコードされない文字列で扱えます。
|
||||
|
||||
例えば、`data`フィールドを使って1つのSecretに2つの文字列を保存するには、次のように文字列をBase64エンコードします。
|
||||
|
||||
```shell
|
||||
echo -n 'admin' | base64
|
||||
```
|
||||
|
||||
出力は次のようになります。
|
||||
|
||||
```
|
||||
YWRtaW4=
|
||||
```
|
||||
|
||||
```shell
|
||||
echo -n '1f2d1e2e67df' | base64
|
||||
```
|
||||
|
||||
出力は次のようになります。
|
||||
|
||||
```
|
||||
MWYyZDFlMmU2N2Rm
|
||||
```
|
||||
|
||||
このようなSecretを書きます。
|
||||
`kubernetes.io/service-account-token`型のSecretは、サービスアカウントを識別するトークンを格納するために使用されます。 このSecret型を使用する場合は、`kubernetes.io/service-account.name`アノテーションが既存のサービスアカウント名に設定されていることを確認する必要があります。Kubernetesコントローラーは、`kubernetes.io/service-account.uid`アノテーションや実際のトークンコンテンツに設定された`data`フィールドの`token`キーなど、他のいくつかのフィールドに入力します。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: mysecret
|
||||
type: Opaque
|
||||
name: secret-sa-sample
|
||||
annotations:
|
||||
kubernetes.io/service-account.name: "sa-name"
|
||||
type: kubernetes.io/service-account-token
|
||||
data:
|
||||
username: YWRtaW4=
|
||||
password: MWYyZDFlMmU2N2Rm
|
||||
# You can include additional key value pairs as you do with Opaque Secrets
|
||||
extra: YmFyCg==
|
||||
```
|
||||
|
||||
これでSecretを[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply)コマンドで作成できるようになりました。
|
||||
`Pod`を作成すると、Kubernetesはservice account Secretを自動的に作成し、このSecretを使用するようにPodを自動的に変更します。service account token Secretには、APIにアクセスするための資格情報が含まれています。
|
||||
|
||||
```shell
|
||||
kubectl apply -f ./secret.yaml
|
||||
```
|
||||
API証明の自動作成と使用は、必要に応じて無効にするか、上書きすることができます。 ただし、API Serverに安全にアクセスするだけの場合は、これが推奨されるワークフローです。
|
||||
|
||||
出力は次のようになります。
|
||||
ServiceAccountの動作の詳細については、[ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/)のドキュメントを参照してください。
|
||||
PodからServiceAccountを参照する方法については、[`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)の`automountServiceAccountToken`フィールドと`serviceAccountName`フィールドを確認することもできます。
|
||||
|
||||
```
|
||||
secret "mysecret" created
|
||||
```
|
||||
### Docker config Secrets
|
||||
|
||||
状況によっては、代わりに`stringData`フィールドを使いたいときもあるでしょう。
|
||||
このフィールドを使えばBase64でエンコードされていない文字列を直接Secretに書くことができて、その文字列はSecretが作られたり更新されたりするときにエンコードされます。
|
||||
次の`type`値のいずれかを使用して、イメージのDockerレジストリにアクセスするための資格情報を格納するSecretを作成できます。
|
||||
|
||||
実用的な例として、設定ファイルの格納にSecretを使うアプリケーションをデプロイすることを考えます。
|
||||
デプロイプロセスの途中で、この設定ファイルの一部のデータを投入したいとしましょう。
|
||||
- `kubernetes.io/dockercfg`
|
||||
- `kubernetes.io/dockerconfigjson`
|
||||
|
||||
例えば、アプリケーションは次のような設定ファイルを使用するとします。
|
||||
|
||||
`kubernetes.io/dockercfg`型は、Dockerコマンドラインを構成するためのレガシー形式であるシリアル化された`~/.dockercfg`を保存するために予約されています。
|
||||
このSecret型を使用する場合は、Secretの`data`フィールドに`.dockercfg`キーが含まれていることを確認する必要があります。このキーの値は、base64形式でエンコードされた`~/.dockercfg`ファイルの内容です。
|
||||
|
||||
`kubernetes.io/dockerconfigjson`型は、`~/.dockercfg`の新しいフォーマットである`~/.docker/config.json`ファイルと同じフォーマットルールに従うシリアル化されたJSONを保存するために設計されています。
|
||||
このSecret型を使用する場合、Secretオブジェクトの`data`フィールドには`.dockerconfigjson`キーが含まれている必要があります。このキーでは、`~/.docker/config.json`ファイルのコンテンツがbase64でエンコードされた文字列として提供されます。
|
||||
|
||||
以下は、`kubernetes.io/dockercfg`型のSecretの例です。
|
||||
|
||||
```yaml
|
||||
apiUrl: "https://my.api.com/api/v1"
|
||||
username: "user"
|
||||
password: "password"
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
name: secret-dockercfg
|
||||
type: kubernetes.io/dockercfg
|
||||
data:
|
||||
.dockercfg: |
|
||||
"<base64 encoded ~/.dockercfg file>"
|
||||
```
|
||||
|
||||
次のような定義を使用して、この設定ファイルをSecretに保存することができます。
|
||||
{{< note >}}
|
||||
base64エンコーディングを実行したくない場合は、代わりに`stringData`フィールドを使用することを選択できます。
|
||||
{{< /note >}}
|
||||
|
||||
マニフェストを使用してこれらの型のSecretを作成すると、APIserverは期待されるキーが`data`フィールドに存在するかどうかを確認し、提供された値を有効なJSONとして解析できるかどうかを確認します。APIサーバーは、JSONが実際にDocker configファイルであるかどうかを検証しません。
|
||||
|
||||
|
||||
Docker configファイルがない場合、または`kubectl`を使用してDockerレジストリSecretを作成する場合は、次の操作を実行できます。
|
||||
|
||||
```shell
|
||||
kubectl create secret docker-registry secret-tiger-docker \
|
||||
--docker-username=tiger \
|
||||
--docker-password=pass113 \
|
||||
--docker-email=tiger@acme.com
|
||||
```
|
||||
|
||||
このコマンドは、`kubernetes.io/dockerconfigjson`型のSecretを作成します。
|
||||
`data`フィールドから`.dockerconfigjson`コンテンツをダンプすると、その場で作成された有効なDocker configである次のJSONコンテンツを取得します。
|
||||
|
||||
```json
|
||||
{
|
||||
"auths": {
|
||||
"https://index.docker.io/v1/": {
|
||||
"username": "tiger",
|
||||
"password": "pass113",
|
||||
"email": "tiger@acme.com",
|
||||
"auth": "dGlnZXI6cGFzczExMw=="
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Basic authentication Secret
|
||||
|
||||
`kubernetes.io/basic-auth`型は、Basic認証に必要な認証を保存するために提供されています。このSecret型を使用する場合、Secretの`data`フィールドには次の2つのキーが含まれている必要があります。
|
||||
|
||||
- `username`: 認証のためのユーザー名
|
||||
- `password`: 認証のためのパスワードかトークン
|
||||
|
||||
上記の2つのキーの両方の値は、base64でエンコードされた文字列です。もちろん、Secretの作成に`stringData`を使用してクリアテキストコンテンツを提供することもできます。
|
||||
|
||||
次のYAMLは、Basic authentication Secretの設定例です。
|
||||
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: mysecret
|
||||
type: Opaque
|
||||
name: secret-basic-auth
|
||||
type: kubernetes.io/basic-auth
|
||||
stringData:
|
||||
config.yaml: |-
|
||||
apiUrl: "https://my.api.com/api/v1"
|
||||
username: {{username}}
|
||||
password: {{password}}
|
||||
username: admin
|
||||
password: t0p-Secret
|
||||
```
|
||||
|
||||
デプロイツールは`kubectl apply`を実行する前に`{{username}}`と`{{password}}`のテンプレート変数を置換することができます。
|
||||
|
||||
`stringData`フィールドは利便性のための書き込み専用フィールドです。
|
||||
Secretを取得するときに出力されることは決してありません。
|
||||
例えば、次のコマンドを実行すると、
|
||||
Basic認証Secret型は、ユーザーの便宜のためにのみ提供されています。Basic認証に使用される資格情報の`Opaque`を作成できます。
|
||||
ただし、組み込みのSecret型を使用すると、認証の形式を統一するのに役立ち、APIserverは必要なキーがSecret configurationで提供されているかどうかを確認します。
|
||||
|
||||
|
||||
### SSH authentication secrets
|
||||
|
||||
組み込みのタイプ`kubernetes.io/ssh-auth`は、SSH認証で使用されるデータを保存するために提供されています。このSecret型を使用する場合、使用するSSH認証として`data`（または`stringData`）フィールドに`ssh-privatekey`キーと値のペアを指定する必要があります。
|
||||
|
||||
次のYAMLはSSH authentication Secretの設定例です：
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: secret-ssh-auth
|
||||
type: kubernetes.io/ssh-auth
|
||||
data:
|
||||
# the data is abbreviated in this example
|
||||
ssh-privatekey: |
|
||||
MIIEpQIBAAKCAQEAulqb/Y ...
|
||||
```
|
||||
|
||||
SSH authentication Secret型は、ユーザーの便宜のためにのみ提供されています。
|
||||
SSH認証に使用される資格情報の`Opaque`を作成できます。
|
||||
ただし、組み込みのSecret型を使用すると、認証の形式を統一するのに役立ち、APIserverは必要なキーがSecret configurationで提供されているかどうかを確認します。
|
||||
|
||||
### TLS secrets
|
||||
|
||||
Kubernetesは、TLSに通常使用される証明書とそれに関連付けられたキーを保存するための組み込みのSecret型`kubernetes.io/tls`を提供します。このデータは、主にIngressリソースのTLS terminationで使用されますが、他のリソースで使用されることも、ワークロードによって直接使用されることもあります。
|
||||
このSecret型を使用する場合、APIサーバーは各キーの値を実際には検証しませんが、`tls.key`および`tls.crt`キーをSecret configurationの`data`（または`stringData`）フィールドに指定する必要があります。
|
||||
|
||||
|
||||
次のYAMLはTLS Secretの設定例です：
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: secret-tls
|
||||
type: kubernetes.io/tls
|
||||
data:
|
||||
# the data is abbreviated in this example
|
||||
tls.crt: |
|
||||
MIIC2DCCAcCgAwIBAgIBATANBgkqh ...
|
||||
tls.key: |
|
||||
MIIEpgIBAAKCAQEA7yn3bRHQ5FHMQ ...
|
||||
```
|
||||
|
||||
TLS Secret型は、ユーザーの便宜のために提供されています。 TLSサーバーやクライアントに使用される資格情報の`Opaque`を作成できます。ただし、組み込みのSecret型を使用すると、プロジェクトでSecret形式の一貫性を確保できます。APIserverは、必要なキーがSecret configurationで提供されているかどうかを確認します。
|
||||
|
||||
`kubectl`を使用してTLS Secretを作成する場合、次の例に示すように`tls`サブコマンドを使用できます。
|
||||
|
||||
```shell
|
||||
kubectl get secret mysecret -o yaml
|
||||
kubectl create secret tls my-tls-secret \
|
||||
--cert=path/to/cert/file \
|
||||
--key=path/to/key/file
|
||||
```
|
||||
|
||||
出力は次のようになります。
|
||||
|
||||
公開鍵と秘密鍵のペアは、事前に存在している必要があります。`--cert`の公開鍵証明書は.PEMエンコード（Base64エンコードDER形式）であり、`--key`の指定された秘密鍵と一致する必要があります。
|
||||
秘密鍵は、一般にPEM秘密鍵形式と呼ばれる暗号化されていない形式である必要があります。どちらの場合も、PEMの最初と最後の行（たとえば、`-------- BEGIN CERTIFICATE -----`と`------- END CERTIFICATE ----`）は含まれて*いません*。
|
||||
|
||||
### Bootstrap token Secrets
|
||||
|
||||
Bootstrap token Secretは、Secretの`type`を`bootstrap.kubernetes.io/token`に明示的に指定することで作成できます。このタイプのSecretは、ノードのブートストラッププロセス中に使用されるトークン用に設計されています。よく知られているConfigMapに署名するために使用されるトークンを格納します。
|
||||
|
||||
Bootstrap toke Secretは通常、`kube-system`namespaceで作成され`bootstrap-token-<token-id>`の形式で名前が付けられます。ここで`<token-id>`はトークンIDの6文字の文字列です。
|
||||
|
||||
Kubernetesマニフェストとして、Bootstrap token Secretは次のようになります。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
creationTimestamp: 2018-11-15T20:40:59Z
|
||||
name: mysecret
|
||||
namespace: default
|
||||
resourceVersion: "7225"
|
||||
uid: c280ad2e-e916-11e8-98f2-025000000001
|
||||
type: Opaque
|
||||
name: bootstrap-token-5emitj
|
||||
namespace: kube-system
|
||||
type: bootstrap.kubernetes.io/token
|
||||
data:
|
||||
config.yaml: YXBpVXJsOiAiaHR0cHM6Ly9teS5hcGkuY29tL2FwaS92MSIKdXNlcm5hbWU6IHt7dXNlcm5hbWV9fQpwYXNzd29yZDoge3twYXNzd29yZH19
|
||||
auth-extra-groups: c3lzdGVtOmJvb3RzdHJhcHBlcnM6a3ViZWFkbTpkZWZhdWx0LW5vZGUtdG9rZW4=
|
||||
expiration: MjAyMC0wOS0xM1QwNDozOToxMFo=
|
||||
token-id: NWVtaXRq
|
||||
token-secret: a3E0Z2lodnN6emduMXAwcg==
|
||||
usage-bootstrap-authentication: dHJ1ZQ==
|
||||
usage-bootstrap-signing: dHJ1ZQ==
|
||||
```
|
||||
|
||||
`username`のようなフィールドを`data`と`stringData`の両方で指定すると、`stringData`の値が使用されます。
|
||||
例えば、次のSecret定義からは
|
||||
|
||||
Bootstrap type Secretには、`data`で指定された次のキーがあります。
|
||||
|
||||
- `token_id`：トークン識別子としてのランダムな6文字の文字列。必須。
|
||||
- `token-secret`：実際のtoken secretとしてのランダムな16文字の文字列。必須。
|
||||
- `description`：トークンの使用目的を説明する人間が読める文字列。オプション。
|
||||
- `expiration`：トークンの有効期限を指定するRFC3339を使用した絶対UTC時間。オプション。
|
||||
- `usage-bootstrap-<usage>`：Bootstrap tokenの追加の使用法を示すブールフラグ。
|
||||
- `auth-extra-groups`：`system：bootstrappers`グループに加えて認証されるグループ名のコンマ区切りのリスト。
|
||||
|
||||
上記のYAMLは、値がすべてbase64でエンコードされた文字列であるため、混乱しているように見える場合があります。実際、次のYAMLを使用して同一のSecretを作成できます。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: mysecret
|
||||
type: Opaque
|
||||
data:
|
||||
username: YWRtaW4=
|
||||
# Note how the Secret is named
|
||||
name: bootstrap-token-5emitj
|
||||
# A bootstrap token Secret usually resides in the kube-system namespace
|
||||
namespace: kube-system
|
||||
type: bootstrap.kubernetes.io/token
|
||||
stringData:
|
||||
username: administrator
|
||||
auth-extra-groups: "system:bootstrappers:kubeadm:default-node-token"
|
||||
expiration: "2020-09-13T04:39:10Z"
|
||||
# This token ID is used in the name
|
||||
token-id: "5emitj"
|
||||
token-secret: "kq4gihvszzgn1p0r"
|
||||
# This token can be used for authentication
|
||||
usage-bootstrap-authentication: "true"
|
||||
# and it can be used for signing
|
||||
usage-bootstrap-signing: "true"
|
||||
```
|
||||
|
||||
次のようなSecretが生成されます。
|
||||
## Secretの作成
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
creationTimestamp: 2018-11-15T20:46:46Z
|
||||
name: mysecret
|
||||
namespace: default
|
||||
resourceVersion: "7579"
|
||||
uid: 91460ecb-e917-11e8-98f2-025000000001
|
||||
type: Opaque
|
||||
data:
|
||||
username: YWRtaW5pc3RyYXRvcg==
|
||||
```
|
||||
Secretを作成するには、いくつかのオプションがあります。
|
||||
|
||||
`YWRtaW5pc3RyYXRvcg==`をデコードすると`administrator`になります。
|
||||
- [create Secret using `kubectl` command](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
|
||||
- [create Secret from config file](/docs/tasks/configmap-secret/managing-secret-using-config-file/)
|
||||
- [create Secret using kustomize](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
|
||||
|
||||
`data`や`stringData`のキーは英数字または'-'、'_'、'.'からなる必要があります。
|
||||
|
||||
{{< note >}}
|
||||
シリアライズされたJSONやYAMLの機密データはBase64エンコードされています。
|
||||
文字列の中の改行は不正で、含まれていてはなりません。
|
||||
Darwin/macOSの`base64`ユーティリティーを使うときは、長い行を分割する`-b`オプションを指定するのは避けるべきです。
|
||||
反対に、Linuxユーザーは`base64`コマンドに`-w 0`オプションを指定するか、`-w`オプションが使えない場合は`base64 | tr -d '\n'`のようにパイプ*すべき*です。
|
||||
{{< /note >}}
|
||||
|
||||
#### ジェネレーターからSecretを作成する
|
||||
|
||||
Kubernetes v1.14から、`kubectl`は[Kustomizeを使ったオブジェクトの管理](/docs/tasks/manage-kubernetes-objects/kustomization/)に対応しています。
|
||||
KustomizeはSecretやConfigMapを生成するリソースジェネレーターを提供します。
|
||||
Kustomizeのジェネレーターはディレクトリの中の`kustomization.yaml`ファイルにて指定されるべきです。
|
||||
Secretが生成された後には、`kubectl apply`コマンドを使用してAPIサーバー上にSecretを作成することができます。
|
||||
|
||||
#### ファイルからのSecretの生成
|
||||
|
||||
./username.txtと./password.txtのファイルから生成するように`secretGenerator`を定義することで、Secretを生成することができます。
|
||||
|
||||
```shell
|
||||
cat <<EOF >./kustomization.yaml
|
||||
secretGenerator:
|
||||
- name: db-user-pass
|
||||
files:
|
||||
- username.txt
|
||||
- password.txt
|
||||
EOF
|
||||
```
|
||||
|
||||
Secretを生成するには、`kustomization.yaml`を含むディレクトリをapplyします。
|
||||
|
||||
```shell
|
||||
kubectl apply -k .
|
||||
```
|
||||
|
||||
出力は次のようになります。
|
||||
|
||||
```
|
||||
secret/db-user-pass-96mffmfh4k created
|
||||
```
|
||||
|
||||
Secretが生成されたことを確認できます。
|
||||
|
||||
```shell
|
||||
kubectl get secrets
|
||||
```
|
||||
|
||||
出力は次のようになります。
|
||||
|
||||
```
|
||||
NAME TYPE DATA AGE
|
||||
db-user-pass-96mffmfh4k Opaque 2 51s
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl describe secrets/db-user-pass-96mffmfh4k
|
||||
```
|
||||
|
||||
出力は次のようになります。
|
||||
|
||||
```
|
||||
Name: db-user-pass
|
||||
Namespace: default
|
||||
Labels: <none>
|
||||
Annotations: <none>
|
||||
|
||||
Type: Opaque
|
||||
|
||||
Data
|
||||
====
|
||||
password.txt: 12 bytes
|
||||
username.txt: 5 bytes
|
||||
```
|
||||
|
||||
#### 文字列リテラルからのSecretの生成
|
||||
|
||||
リテラル`username=admin`と`password=secret`から生成するように`secretGenerator`を定義して、Secretを生成することができます。
|
||||
|
||||
```shell
|
||||
cat <<EOF >./kustomization.yaml
|
||||
secretGenerator:
|
||||
- name: db-user-pass
|
||||
literals:
|
||||
- username=admin
|
||||
- password=secret
|
||||
EOF
|
||||
```
|
||||
|
||||
Secretを生成するには、`kustomization.yaml`を含むディレクトリをapplyします。
|
||||
|
||||
```shell
|
||||
kubectl apply -k .
|
||||
```
|
||||
|
||||
出力は次のようになります。
|
||||
|
||||
```
|
||||
secret/db-user-pass-dddghtt9b5 created
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
Secretが生成されるとき、Secretのデータからハッシュ値が算出され、Secretの名称にハッシュ値が加えられます。
|
||||
これはデータが更新されたときに毎回新しいSecretが生成されることを保証します。
|
||||
{{< /note >}}
|
||||
|
||||
#### Secretのデコード
|
||||
|
||||
Secretは`kubectl get secret`を実行することで取得可能です。
|
||||
例えば、前のセクションで作成したSecretは次のコマンドを実行することで参照できます。
|
||||
|
||||
```shell
|
||||
kubectl get secret mysecret -o yaml
|
||||
```
|
||||
|
||||
出力は次のようになります。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
creationTimestamp: 2016-01-22T18:41:56Z
|
||||
name: mysecret
|
||||
namespace: default
|
||||
resourceVersion: "164619"
|
||||
uid: cfee02d6-c137-11e5-8d73-42010af00002
|
||||
type: Opaque
|
||||
data:
|
||||
username: YWRtaW4=
|
||||
password: MWYyZDFlMmU2N2Rm
|
||||
```
|
||||
|
||||
`password`フィールドをデコードします。
|
||||
|
||||
```shell
|
||||
echo 'MWYyZDFlMmU2N2Rm' | base64 --decode
|
||||
```
|
||||
|
||||
出力は次のようになります。
|
||||
|
||||
```
|
||||
1f2d1e2e67df
|
||||
```
|
||||
|
||||
#### Secretの編集
|
||||
## Secretの編集
|
||||
|
||||
既存のSecretは次のコマンドで編集することができます。
|
||||
|
||||
@@ -457,7 +357,7 @@ Secretは直接Podが参照できるようにはされず、システムの別
|
||||
PodのボリュームとしてSecretを使うには、
|
||||
|
||||
1. Secretを作成するか既存のものを使用します。複数のPodが同一のSecretを参照することができます。
|
||||
1. ボリュームを追加するため、Podの定義の`.spec.volumes[]`以下をを書き換えます。ボリュームに命名し、`.spec.volumes[].secret.secretName`フィールドはSecretオブジェクトの名称と同一にします。
|
||||
1. ボリュームを追加するため、Podの定義の`.spec.volumes[]`以下を書き換えます。ボリュームに命名し、`.spec.volumes[].secret.secretName`フィールドはSecretオブジェクトの名称と同一にします。
|
||||
1. Secretを必要とするそれぞれのコンテナに`.spec.containers[].volumeMounts[]`を追加します。`.spec.containers[].volumeMounts[].readOnly = true`を指定して`.spec.containers[].volumeMounts[].mountPath`をSecretをマウントする未使用のディレクトリ名にします。
|
||||
1. イメージやコマンドラインを変更し、プログラムがそのディレクトリを参照するようにします。連想配列`data`のキーは`mountPath`以下のファイル名になります。
|
||||
|
||||
@@ -491,7 +391,7 @@ Podに複数のコンテナがある場合、それぞれのコンテナが`volu
|
||||
#### Secretのキーの特定のパスへの割り当て
|
||||
|
||||
Secretのキーが割り当てられるパスを制御することができます。
|
||||
それぞれのキーがターゲットとするパスは`.spec.volumes[].secret.items`フィールドによって指定てきます。
|
||||
それぞれのキーがターゲットとするパスは`.spec.volumes[].secret.items`フィールドによって指定できます。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
@@ -668,32 +568,6 @@ Secretはwatch（デフォルト）、TTLベース、単に全てのリクエス
|
||||
Secretを[subPath](/docs/concepts/storage/volumes#using-subpath)を指定してボリュームにマウントしているコンテナには、Secretの更新が反映されません。
|
||||
{{< /note >}}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.18" state="alpha" >}}
|
||||
|
||||
Kubernetesのアルファ機能である _Immutable Secrets and ConfigMaps_ は各SecretやConfigMapが不変であると設定できるようにします。
|
||||
Secretを広範に利用しているクラスター（PodにマウントされているSecretが1万以上）においては、データが変更されないようにすることで次のような利点が得られます。
|
||||
|
||||
- 意図しない（または望まない）変更によってアプリケーションの停止を引き起こすことを防ぎます
|
||||
- 不変であると設定されたSecretの監視を停止することにより、kube-apiserverの負荷が著しく軽減され、クラスターのパフォーマンスが改善されます
|
||||
|
||||
この機能を利用するには、`ImmutableEphemeralVolumes`[feature gate](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にして、SecretまたはConfigMapの`immutable`フィールドに`true`を指定します。例えば、次のようにします。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
...
|
||||
data:
|
||||
...
|
||||
immutable: true
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
一度SecretやConfigMapを不変であると設定すると、この変更を戻すことや`data`フィールドの内容を書き換えることは _できません_ 。
|
||||
Secretを削除して、再生成することだけができます。
|
||||
既存のPodは削除されたSecretへのマウントポイントを持ち続けるため、Podを再生成することが推奨されます。
|
||||
{{< /note >}}
|
||||
|
||||
### Secretを環境変数として使用する {#using-secrets-as-environment-variables}
|
||||
|
||||
SecretをPodの{{< glossary_tooltip text="環境変数" term_id="container-env-variables" >}}として使用するには、
|
||||
@@ -753,12 +627,38 @@ echo $SECRET_PASSWORD
|
||||
1f2d1e2e67df
|
||||
```
|
||||
|
||||
## Immutable Secrets {#secret-immutable}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.19" state="beta" >}}
|
||||
|
||||
Kubernetesベータ機能*ImmutableSecrets and ConfigMaps*は、個々のSecretsとConfigMapsをimutableとして設定するオプションを提供します。Secret（少なくとも数万の、SecretからPodへの一意のマウント）を広範囲に使用するクラスターの場合、データの変更を防ぐことには次の利点があります。
|
||||
|
||||
- アプリケーションの停止を引き起こす可能性のある偶発的な（または不要な）更新からユーザーを保護します
|
||||
- imutableとしてマークされたSecretのウォッチを閉じることで、kube-apiserverの負荷を大幅に削減することができ、クラスターのパフォーマンスを向上させます。
|
||||
|
||||
この機能は、`ImmutableEphemeralVolumes`[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)によって制御されます。これは、v1.19以降デフォルトで有効になっています。`immutable`フィールドを`true`に設定することで、imutableのSecretを作成できます。例えば、
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
...
|
||||
data:
|
||||
...
|
||||
immutable: true
|
||||
```
|
||||
{{< note >}}
|
||||
SecretまたはConfigMapがimutableとしてマークされると、この変更を元に戻したり、`data`フィールドの内容を変更したりすることは*できません*。Secretを削除して再作成することしかできません。
|
||||
既存のPodは、削除されたSecretへのマウントポイントを維持します。これらのPodを再作成することをお勧めします。
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
|
||||
### imagePullSecretsを使用する {#using-imagepullsecrets}
|
||||
|
||||
`imagePullSecrets`フィールドは同一のネームスペース内のSecretの参照のリストです。
|
||||
kubeletにDockerやその他のイメージレジストリのパスワードを渡すために、`imagePullSecrets`にそれを含むSecretを指定することができます。
|
||||
kubeletはこの情報をPodのためにプライベートイメージをpullするために使います。
|
||||
`imagePullSecrets`の詳細は[PodSpec API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)を参照してください。
|
||||
`imagePullSecrets`の詳細は[PodSpec API](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#podspec-v1-core)を参照してください。
|
||||
|
||||
#### imagePullSecretを手動で指定する
|
||||
|
||||
@@ -1028,8 +928,8 @@ kubectl apply -k .
|
||||
|
||||
2つのサービスアカウントを使用すると、ベースのPod仕様をさらに単純にすることができます。
|
||||
|
||||
1. `prod-user` と `prod-db-secret`
|
||||
1. `test-user` と `test-db-secret`
|
||||
1. `prod-user`と`prod-db-secret`
|
||||
1. `test-user`と`test-db-secret`
|
||||
|
||||
簡略化されたPod仕様は次のようになります。
|
||||
|
||||
@@ -1155,3 +1055,10 @@ Podに複数のコンテナが含まれることもあります。しかし、Po
|
||||
- Secretを利用するPodを作成できるユーザーはSecretの値を見ることができます。たとえAPIサーバーのポリシーがユーザーにSecretの読み取りを許可していなくても、ユーザーはSecretを晒すPodを実行することができます。
|
||||
- 現在、任意のノードでルート権限を持つ人は誰でも、kubeletに偽装することで _任意の_ SecretをAPIサーバーから読み取ることができます。
|
||||
単一のノードのルート権限を不正に取得された場合の影響を抑えるため、実際に必要としているノードに対してのみSecretを送る機能が計画されています。
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
- [`kubectl`を使用してSecretを管理する](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)方法を学ぶ
|
||||
- [config fileを使用してSecretを管理する](/docs/tasks/configmap-secret/managing-secret-using-config-file/)方法を学ぶ
|
||||
- [kustomizeを使用してSecretを管理する](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)方法を学ぶ
|
||||
|
||||
@@ -21,7 +21,7 @@ no_list: true
|
||||
## コンテナイメージ
|
||||
[コンテナイメージ](/docs/concepts/containers/images/)はすぐに実行可能なソフトウェアパッケージで、アプリケーションの実行に必要なものをすべて含んています。コードと必要なランタイム、アプリケーションとシステムのライブラリ、そして必須な設定項目のデフォルト値を含みます。
|
||||
|
||||
設計上、コンテナは不変で、既に実行中のコンテナのコードを変更することはできません。コンテナ化されたアプリケーションがあり変更したい場合は、変更を含んだ新しいコンテナをビルドし、コンテナを再作成して、更新されたイメージから起動する必要があります。
|
||||
設計上、コンテナは不変で、既に実行中のコンテナのコードを変更することはできません。コンテナ化されたアプリケーションがあり変更したい場合は、変更を含んだ新しいイメージをビルドし、コンテナを再作成して、更新されたイメージから起動する必要があります。
|
||||
|
||||
## コンテナランタイム
|
||||
|
||||
|
||||
@@ -30,11 +30,11 @@ Angularなどのコンポーネントライフサイクルフックを持つ多
|
||||
|
||||
`PreStop`
|
||||
|
||||
このフックは、liveness probeの失敗、プリエンプション、リソース競合などのAPI要求または管理イベントが原因でコンテナが終了する直前に呼び出されます。コンテナがすでに終了状態または完了状態にある場合、preStopフックの呼び出しは失敗します。
|
||||
これはブロッキング、つまり同期的であるため、コンテナを削除するための呼び出しを送信する前に完了する必要があります。
|
||||
このフックは、APIからの要求、またはliveness probeの失敗、プリエンプション、リソース競合などの管理イベントが原因でコンテナが終了する直前に呼び出されます。コンテナがすでに終了状態または完了状態にある場合、preStopフックの呼び出しは失敗します。
|
||||
これはブロッキング、つまり同期的であるため、コンテナを停止する信号が送信される前に完了する必要があります。
|
||||
ハンドラーにパラメーターは渡されません。
|
||||
|
||||
終了動作の詳細な説明は、[Termination of Pods](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)にあります。
|
||||
終了動作の詳細な説明は、[Termination of Pods](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)にあります。
|
||||
|
||||
### フックハンドラーの実装
|
||||
|
||||
@@ -47,27 +47,32 @@ Angularなどのコンポーネントライフサイクルフックを持つ多
|
||||
|
||||
### フックハンドラーの実行
|
||||
|
||||
コンテナライフサイクル管理フックが呼び出されると、Kubernetes管理システムはそのフック用に登録されたコンテナ内のハンドラーを実行します。
|
||||
コンテナライフサイクル管理フックが呼び出されると、Kubernetes管理システムはフックアクションにしたがってハンドラーを実行します。
|
||||
`exec`と`tcpSocket`はコンテナの中で実行され、`httpGet`はkubeletプロセスによって実行されます。
|
||||
|
||||
フックハンドラーの呼び出しは、コンテナを含むPodのコンテキスト内で同期しています。
|
||||
これは、`PostStart`フックの場合、コンテナのENTRYPOINTとフックは非同期に起動することを意味します。
|
||||
しかし、フックの実行に時間がかかりすぎたりハングしたりすると、コンテナは`running`状態になることができません。
|
||||
|
||||
その振る舞いは `PreStop`フックに似ています。
|
||||
実行中にフックがハングした場合、Podフェーズは`Terminating`状態に留まり、Podの`terminationGracePeriodSeconds`が終了した後に終了します。
|
||||
`PostStart`または`PreStop`フックが失敗した場合、コンテナを強制終了します。
|
||||
`PreStop`フックはコンテナを停止する信号から非同期で実行されるのではなく、信号が送られる前に実行を完了する必要があります。
|
||||
もし`PreStop`フックが実行中にハングした場合、Podは`Terminating`状態になり、
|
||||
`terminationGracePeriodSeconds`の時間切れで強制終了されるまで続きます。
|
||||
この猶予時間は、`PreStop`フックが実行され正常にコンテナを停止できるまでの合計時間に適用されます。
|
||||
例えば`terminationGracePeriodSeconds`が60で、フックの終了に55秒かかり、シグナルを受信した後にコンテナを正常に停止させるのに10秒かかる場合、コンテナは正常に停止する前に終了されてしまいます。`terminationGracePeriodSeconds`が、これら２つの実行にかかる合計時間(55+10)よりも短いからです。
|
||||
|
||||
`PostStart`または`PreStop`フックが失敗した場合、コンテナは強制終了します。
|
||||
|
||||
ユーザーはフックハンドラーをできるだけ軽量にするべきです。
|
||||
ただし、コンテナを停止する前に状態を保存する場合など、長時間実行されるコマンドが意味をなす場合があります。
|
||||
ただし、コンテナを停止する前に状態を保存するなどの場合は、長時間のコマンド実行が必要なケースもあります。
|
||||
|
||||
### フック配送保証
|
||||
### フック配信保証
|
||||
|
||||
フックの配送は *少なくとも1回* を意図しています。これはフックが`PostStart`や`PreStop`のような任意のイベントに対して複数回呼ばれることがあることを意味します。
|
||||
フックの配信は *少なくとも1回* を意図しています。これはフックが`PostStart`や`PreStop`のような任意のイベントに対して複数回呼ばれることがあることを意味します。
|
||||
これを正しく処理するのはフックの実装次第です。
|
||||
|
||||
通常、単一の配送のみが行われます。
|
||||
通常、1回の配信のみが行われます。
|
||||
たとえば、HTTPフックレシーバーがダウンしていてトラフィックを受け取れない場合、再送信は試みられません。
|
||||
ただし、まれに二重配送が発生することがあります。
|
||||
ただし、まれに二重配信が発生することがあります。
|
||||
たとえば、フックの送信中にkubeletが再起動した場合、kubeletが起動した後にフックが再送信される可能性があります。
|
||||
|
||||
### フックハンドラーのデバッグ
|
||||
@@ -101,4 +106,3 @@ Events:
|
||||
* [コンテナ環境](/ja/docs/concepts/containers/container-environment/)の詳細
|
||||
* [コンテナライフサイクルイベントへのハンドラー紐付け](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)のハンズオン
|
||||
|
||||
|
||||
|
||||
@@ -48,10 +48,9 @@ weight: 10
|
||||
|
||||
`imagePullPolicy`が値なしで定義された場合、この場合も`Always`が設定されます。
|
||||
|
||||
## マニフェストを使ったマルチアーキテクチャイメージ
|
||||
## イメージインデックスを使ったマルチアーキテクチャイメージ
|
||||
|
||||
コンテナレジストリはバイナリイメージの提供だけでなく、[コンテナイメージマニフェスト](https://github.com/opencontainers/image-spec/blob/master/manifest.md)も提供する事ができます。
|
||||
マニフェストはコンテナのアーキテクチャ固有バージョンに関するイメージマニフェストを参照できます。マニフェストの目的はイメージの名前(例:`pause`、`example/mycontainer`、`kube-apiserver`)をもたせ、様々なシステムが使用しているマシンアーキテクチャにあう適切なバイナリイメージを取得できることです。
|
||||
コンテナレジストリはバイナリイメージの提供だけでなく、[コンテナイメージインデックス](https://github.com/opencontainers/image-spec/blob/master/image-index.md)も提供する事ができます。イメージインデックスはコンテナのアーキテクチャ固有バージョンに関する複数の[イメージマニフェスト](https://github.com/opencontainers/image-spec/blob/master/manifest.md)を指すことができます。イメージインデックスの目的はイメージの名前(例:`pause`、`example/mycontainer`、`kube-apiserver`)をもたせ、様々なシステムが使用しているマシンアーキテクチャにあう適切なバイナリイメージを取得できることです。
|
||||
|
||||
Kubernetes自身は、通常コンテナイメージに`-$(ARCH)`のサフィックスを持つ名前をつけます。下位互換の為にサフィックス付きの古い仕様のイメージを生成してください。その目的は、`pause`のようなすべてのアーキテクチャのマニフェストを持つイメージと、サフィックスのあるイメージをハードコードしていた可能性のある古い仕様の設定やYAMLファイルと下位互換がある`pause-amd64`のようなイメージを生成することです。
|
||||
|
||||
@@ -179,7 +178,7 @@ Node構成を制御できる場合、この方法が適しています。
|
||||
|
||||
すべてのPodは事前にPullしたイメージへの読み取りアクセス権をもちます。
|
||||
|
||||
### PodでImagePullSecretsを指定する
|
||||
### PodでimagePullSecretsを指定する
|
||||
|
||||
{{< note >}}
|
||||
この方法がプライベートレジストリのイメージに基づいてコンテナを実行するための推奨の方法です。
|
||||
@@ -187,7 +186,7 @@ Node構成を制御できる場合、この方法が適しています。
|
||||
|
||||
KubernetesはPodでのコンテナイメージレジストリキーの指定をサポートしています。
|
||||
|
||||
#### Docker Configを利用してSecretを作成する。
|
||||
#### Dockerの設定を利用してSecretを作成する。
|
||||
|
||||
適切な大文字の値を置き換えて、次のコマンドを実行します。
|
||||
|
||||
|
||||
@@ -149,7 +149,7 @@ PodのオーバーヘッドはRuntimeClass内の`overhead`フィールドによ
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
- [RuntimeClassデザイン](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md)
|
||||
- [RuntimeClassスケジューリングデザイン](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md)
|
||||
- [Podオーバーヘッド](/docs/concepts/configuration/pod-overhead/)のコンセプトを読む
|
||||
- [RuntimeClassデザイン](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md)
|
||||
- [RuntimeClassスケジューリングデザイン](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md#runtimeclass-scheduling)
|
||||
- [Podオーバーヘッド](/docs/concepts/scheduling-eviction/pod-overhead/)のコンセプトを読む
|
||||
- [PodOverhead機能デザイン](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)
|
||||
|
||||
@@ -105,7 +105,7 @@ Webhookのモデルでは、Kubernetesは外部のサービスを呼び出しま
|
||||
|
||||
### APIアクセス拡張 {#api-access-extensions}
|
||||
|
||||
リクエストがKubernetes APIサーバーに到達すると、まず最初に認証が行われ、次に認可、その後、様々なAdmission Controlの対象になります。このフローの詳細は[Kubernetes APIへのアクセスをコントロールする](/docs/reference/access-authn-authz/controlling-access/)を参照して下さい。
|
||||
リクエストがKubernetes APIサーバーに到達すると、まず最初に認証が行われ、次に認可、その後、様々なAdmission Controlの対象になります。このフローの詳細は[Kubernetes APIへのアクセスをコントロールする](/docs/concepts/security/controlling-access/)を参照して下さい。
|
||||
|
||||
これらの各ステップごとに拡張ポイントが用意されています。
|
||||
|
||||
|
||||
@@ -14,7 +14,7 @@ weight: 10
|
||||
|
||||
## カスタムリソース
|
||||
|
||||
*リソース* は、[Kubernetes API](/docs/reference/using-api/api-overview/)のエンドポイントで、特定の[APIオブジェクト](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/)のコレクションを保持します。例えば、ビルトインの *Pods* リソースは、Podオブジェクトのコレクションを包含しています。
|
||||
*リソース* は、[Kubernetes API](/ja/docs/concepts/overview/kubernetes-api/)のエンドポイントで、特定の[APIオブジェクト](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/)のコレクションを保持します。例えば、ビルトインの *Pods* リソースは、Podオブジェクトのコレクションを包含しています。
|
||||
|
||||
*カスタムリソース* は、Kubernetes APIの拡張で、デフォルトのKubernetesインストールでは、必ずしも利用できるとは限りません。つまりそれは、特定のKubernetesインストールのカスタマイズを表します。しかし、今現在、多数のKubernetesのコア機能は、カスタムリソースを用いて作られており、Kubernetesをモジュール化しています。
|
||||
|
||||
|
||||
@@ -58,7 +58,7 @@ Kubernetes上でうまく動くクライアントプログラムを書くため
|
||||
|
||||
Webhookのモデルでは、Kubernetesは外部のサービスを呼び出します。
|
||||
*バイナリプラグイン* モデルでは、Kubernetesはバイナリ(プログラム)を実行します。
|
||||
バイナリプラグインはkubelet(例、[FlexVolumeプラグイン](/docs/concepts/storage/volumes/#flexVolume)、[ネットワークプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/))、またkubectlで利用されています。
|
||||
バイナリプラグインはkubelet(例、[FlexVolumeプラグイン](/docs/concepts/storage/volumes/#flexvolume)、[ネットワークプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/))、またkubectlで利用されています。
|
||||
|
||||
下図は、それぞれの拡張ポイントが、Kubernetesのコントロールプレーンとどのように関わっているかを示しています。
|
||||
|
||||
@@ -107,7 +107,7 @@ Webhookのモデルでは、Kubernetesは外部のサービスを呼び出しま
|
||||
|
||||
### APIアクセスエクステンション
|
||||
|
||||
リクエストがKubernetes APIサーバーに到達すると、まず最初に認証が行われ、次に認可、その後、様々なAdmission Controlの対象になります。このフローの詳細は[Kubernetes APIへのアクセスをコントロールする](/docs/reference/access-authn-authz/controlling-access/)を参照して下さい。
|
||||
リクエストがKubernetes APIサーバーに到達すると、まず最初に認証が行われ、次に認可、その後、様々なAdmission Controlの対象になります。このフローの詳細は[Kubernetes APIへのアクセスをコントロールする](/docs/concepts/security/controlling-access/)を参照して下さい。
|
||||
|
||||
これらの各ステップごとに拡張ポイントが用意されています。
|
||||
|
||||
@@ -134,7 +134,7 @@ Kubernetesはいくつかのビルトイン認証方式と、それらが要件
|
||||
|
||||
### ストレージプラグイン
|
||||
|
||||
[Flex Volumes](/docs/concepts/storage/volumes/#flexVolume)は、Kubeletがバイナリプラグインを呼び出してボリュームをマウントすることにより、ユーザーはビルトインのサポートなしでボリュームタイプをマウントすることを可能にします。
|
||||
[Flex Volumes](/docs/concepts/storage/volumes/#flexvolume)は、Kubeletがバイナリプラグインを呼び出してボリュームをマウントすることにより、ユーザーはビルトインのサポートなしでボリュームタイプをマウントすることを可能にします。
|
||||
|
||||
### デバイスプラグイン
|
||||
|
||||
|
||||
@@ -27,7 +27,7 @@ Kubernetesは自動化のために設計されています。追加の作業、
|
||||
ワークロードのデプロイおよび稼働を自動化するためにKubernetesを使うことができます。 *さらに* Kubernetesがそれをどのように行うかの自動化も可能です。
|
||||
|
||||
Kubernetesの{{< glossary_tooltip text="コントローラー" term_id="controller" >}}コンセプトは、Kubernetesのソースコードを修正すること無く、クラスターの振る舞いを拡張することを可能にします。
|
||||
オペレーターはKubernetes APIのクライアントで、[Custom Resource](/docs/concepts/api-extension/custom-resources/)にとっての、コントローラーのように振る舞います。
|
||||
オペレーターはKubernetes APIのクライアントで、[Custom Resource](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)にとっての、コントローラーのように振る舞います。
|
||||
|
||||
## オペレーターの例 {#example}
|
||||
|
||||
@@ -90,7 +90,7 @@ kubectl edit SampleDB/example-database # 手動でいくつかの設定を変更
|
||||
* [KUDO](https://kudo.dev/)（Kubernetes Universal Declarative Operator）を使います
|
||||
* [kubebuilder](https://book.kubebuilder.io/)を使います
|
||||
* [Metacontroller](https://metacontroller.app/)を自分で実装したWebHooksと一緒に使います
|
||||
* [Operator Framework](https://github.com/operator-framework/getting-started)を使います
|
||||
* [Operator Framework](https://operatorframework.io)を使います
|
||||
* 自前のオペレーターを他のユーザーのために[公開](https://operatorhub.io/)します
|
||||
* オペレーターパターンを紹介している[CoreOSオリジナル記事](https://coreos.com/blog/introducing-operators.html)を読みます
|
||||
* Google Cloudが出したオペレーター作成のベストプラクティス[記事](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps)を読みます
|
||||
|
||||
@@ -17,7 +17,7 @@ Kubernetesをデプロイすると、クラスターが展開されます。
|
||||
|
||||
すべてのコンポーネントが結び付けられたKubernetesクラスターの図を次に示します。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -18,22 +18,13 @@ APIサーバーは、エンドユーザー、クラスターのさまざまな
|
||||
|
||||
Kubernetes APIを使用すると、Kubernetes API内のオブジェクトの状態をクエリで操作できます（例：Pod、Namespace、ConfigMap、Events）。
|
||||
|
||||
APIエンドポイント、リソースタイプ、サンプルについては[APIリファレンス](/docs/reference/kubernetes-api/)で説明しています。
|
||||
ほとんどの操作は、APIを使用している[kubectl](/docs/reference/kubectl/overview/)コマンドラインインターフェースもしくは[kubeadm](/docs/reference/setup-tools/kubeadm/)のような別のコマンドラインツールを通して実行できます。
|
||||
RESTコールを利用して直接APIにアクセスすることも可能です。
|
||||
|
||||
Kubernetes APIを利用してアプリケーションを書いているのであれば、[client libraries](/docs/reference/using-api/client-libraries/)の利用を考えてみてください。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## APIの変更
|
||||
|
||||
成功を収めているシステムはすべて、新しいユースケースの出現や既存の変化に応じて成長し、変化する必要があります。
|
||||
したがって、Kubernetesには、Kubernetes APIを継続的に変更および拡張できる設計機能があります。
|
||||
Kubernetesプロジェクトは、既存のクライアントとの互換性を破壊しないこと、およびその互換性を一定期間維持して、他のプロジェクトが適応する機会を提供することを目的としています。
|
||||
|
||||
基本的に、新しいAPIリソースと新しいリソースフィールドは追加することができます。
|
||||
リソースまたはフィールドを削除するには、[API非推奨ポリシー](/docs/reference/using-api/deprecation-policy/)に従ってください。
|
||||
|
||||
互換性のある変更の構成要素とAPIの変更方法については、[APIの変更](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)で詳しく説明しています。
|
||||
|
||||
|
||||
## OpenAPI 仕様 {#api-specification}
|
||||
|
||||
完全なAPIの詳細は、[OpenAPI](https://www.openapis.org/)を使用して文書化されています。
|
||||
@@ -43,6 +34,7 @@ Kubernetes APIサーバーは、`/openapi/v2`エンドポイントを介してOp
|
||||
|
||||
|
||||
<table>
|
||||
<caption style="display:none">OpenAPI v2クエリの有効なリクエストヘッダー値</caption>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Header</th>
|
||||
@@ -70,74 +62,55 @@ Kubernetes APIサーバーは、`/openapi/v2`エンドポイントを介してOp
|
||||
<td><code>application/json</code>を提供</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
<caption>OpenAPI v2クエリの有効なリクエストヘッダー値</caption>
|
||||
</table>
|
||||
|
||||
|
||||
Kubernetesは、他の手段として主にクラスター間の連携用途向けのAPIに、Protocol buffersをベースにしたシリアライズフォーマットを実装しており、そのフォーマットの概要は[デザイン提案](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md)に記載されています。また各スキーマのIDFファイルは、APIオブジェクトを定義しているGoパッケージ内に配置されています。
|
||||
|
||||
## APIバージョニング
|
||||
|
||||
フィールドの削除やリソース表現の再構成を簡単に行えるようにするため、Kubernetesは複数のAPIバージョンをサポートしており、`/api/v1`や`/apis/rbac.authorization.k8s.io/v1alpha1`のように、それぞれ異なるAPIのパスが割り当てられています。
|
||||
|
||||
APIが、システムリソースと動作について明確かつ一貫したビューを提供し、サポート終了、実験的なAPIへのアクセス制御を有効にするために、リソースまたはフィールドレベルではなく、APIレベルでバージョンが行われます。
|
||||
|
||||
JSONとProtocol Buffersのシリアライズスキーマも、スキーマ変更に関して同じガイドラインに従います。ここから以下の説明は、双方のフォーマットをカバーしています。
|
||||
|
||||
APIとソフトウエアのバージョニングは、間接的にしか関連していないことに注意してください。[APIとリリースバージョニング提案](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)で、APIとソフトウェアのバージョニングの関連について記載しています。
|
||||
|
||||
異なるバージョンのAPIでは、安定性やサポートのレベルも変わります。各レベルの詳細な条件は、[APIの変更](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)に記載されています。下記に簡潔にまとめます:
|
||||
|
||||
- アルファレベル(版):
|
||||
- バージョン名に`alpha`を含みます(例、`v1alpha1`)。
|
||||
- バグが多いかもしれません。アルファ機能の有効化がバグを顕在化させるかもしれません。デフォルトでは無効となっています。
|
||||
- アルファ機能のサポートは、いつでも通知無しに取りやめられる可能性があります。
|
||||
- ソフトウェアリリース後、APIが通知無しに互換性が無い形で変更される可能性があります。
|
||||
- バグが増えるリスク、また長期サポートが無いことから、短期間のテスト用クラスターでの利用を推奨します。
|
||||
- ベータレベル(版):
|
||||
- バージョン名に`beta`を含みます(例、`v2beta3`)。
|
||||
- コードは十分にテストされています。ベータ機能の有効化は安全だと考えられます。デフォルトで有効化されています。
|
||||
- 全体的な機能のサポートは取りやめられませんが、詳細は変更される可能性があります。
|
||||
- オブジェクトのスキーマ、意味はその後のベータ、安定版リリースで互換性が無い形で変更される可能性があります。その場合、次のバージョンへアップデートするための手順を提供します。その手順ではAPIオブジェクトの削除、修正、再作成が必要になるかもしれません。修正のプロセスは多少の検討が必要になるかもしれません。これは、この機能を利用しているアプリケーションでダウンタイムが必要になる可能性があるためです。
|
||||
- 今後のリリースで、互換性の無い変更が行われる可能性があるため、ビジネスクリティカルな場面以外での利用を推奨します。もし複数のクラスターを持っており、それぞれ個別にアップグレードが可能な場合、この制限の影響を緩和できるかもしれません。
|
||||
- **是非ベータ機能を試して、フィードバックをください！ベータから安定版になってしまうと、より多くの変更を加えることが難しくなってしまいます。**
|
||||
- 安定版:
|
||||
- バージョン名は`vX`のようになっており、`X`は整数です。
|
||||
- 安定版の機能は、今後のリリースバージョンにも適用されます。
|
||||
|
||||
## APIグループ {#api-groups}
|
||||
|
||||
APIの拡張を簡易に行えるようにするため、Kubernetesは[*APIグループ*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)を実装しました。
|
||||
APIグループは、RESTのパスとシリアライズされたオブジェクトの`apiVersion`フィールドで指定されます。
|
||||
|
||||
クラスターにはいくつかのAPIグループがあります:
|
||||
|
||||
1. *core* グループ(*legacy group* とも呼ばれます)は、`/api/v1`というRESTのパスで、`apiVersion: v1`を使います。
|
||||
|
||||
1. 名前付きのグループは、`/apis/$GROUP_NAME/$VERSION`というRESTのパスで、`apiVersion: $GROUP_NAME/$VERSION`(例、`apiVersion: batch/v1`)を使います。Kubernetesの[APIリファレンス](/docs/reference/kubernetes-api/)にすべての使用可能なAPIグループのリストがあります。
|
||||
|
||||
[カスタムリソース](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)でAPIを拡張するために、2つの方法があります:
|
||||
|
||||
1. [カスタムリソース定義](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)は、APIサーバーが選択したリソースAPIを提供する方法を宣言的に定義できます。
|
||||
1. [独自の拡張APIサーバーを実装](/docs/tasks/extend-kubernetes/setup-extension-api-server/)し、[アグリゲーター](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)を使用してクライアントに対してシームレスにすることもできます。
|
||||
|
||||
## APIグループの有効化、無効化
|
||||
|
||||
いくつかのリソースとAPIグループはデフォルトで有効になっています。それらは、kube-apiserverのコマンドラインオプションとしてAPIサーバーの`--runtime-config`設定で、有効化、無効化できます。
|
||||
|
||||
`--runtime-config`は、カンマ区切りの複数の値を設定可能です。例えば、batch/v1を無効化する場合、`--runtime-config=batch/v1=false`をセットし、batch/v2alpha1を有効化する場合、`--runtime-config=batch/v2alpha1`をセットします。このフラグは、APIサーバーのランタイム設定を表すkey=valueのペアを、カンマ区切りで指定したセットを指定可能です。
|
||||
|
||||
{{< note >}}APIグループ、リソースの有効化、無効化は、`--runtime-config`の変更を反映するため、kube-apiserverとkube-controller-managerの再起動が必要です。{{< /note >}}
|
||||
Kubernetesは、他の手段として主にクラスター間の連携用途向けのAPIに、Protocol buffersをベースにしたシリアライズフォーマットを実装しています。このフォーマットに関しては、[Kubernetes Protobuf serialization](https://github.com/kubernetes/community/blob/master/contributors/des ign-proposals/api-machinery/protobuf.md)デザイン提案を参照してください。また、各スキーマのInterface Definition Language（IDL）ファイルは、APIオブジェクトを定義しているGoパッケージ内に配置されています。
|
||||
|
||||
## 永続性
|
||||
|
||||
KubernetesはAPIリソースの観点からシリアル化された状態を{{< glossary_tooltip term_id="etcd" >}}に書き込むことで保存します。
|
||||
|
||||
## APIグループとバージョニング
|
||||
|
||||
フィールドの削除やリソース表現の再構成を簡単に行えるようにするため、Kubernetesは複数のAPIバージョンをサポートしており、`/api/v1`や`/apis/rbac.authorization.k8s.io/v1alpha1`のように、それぞれ異なるAPIのパスが割り当てられています。
|
||||
|
||||
APIが、システムリソースと動作について明確かつ一貫したビューを提供し、サポート終了、実験的なAPIへのアクセス制御を有効にするために、リソースまたはフィールドレベルではなく、APIレベルでバージョンが行われます。
|
||||
|
||||
APIの発展や拡張を簡易に行えるようにするため、Kubernetesは[有効もしくは無効](/docs/reference/using-api/#enabling-or-disabling)を行える[APIグループ](/docs/reference/using-api/#api-groups)を実装しました。
|
||||
|
||||
APIリソースは、APIグループ、リソースタイプ、ネームスペース（namespacedリソースのための）、名前によって区別されます。APIサーバーは、APIバージョン間の変換を透過的に処理します。すべてのバージョンの違いは、実際のところ同じ永続データとして表現されます。APIサーバーは、同じ基本的なデータを複数のAPIバージョンで提供することができます。
|
||||
|
||||
例えば、同じリソースで`v1`と`v1beta1`の2つのバージョンが有ることを考えてみます。`v1beta1`バージョンのAPIを利用しオブジェクトを最初に作成したとして、`v1beta1`もしくは`v1`どちらのAPIバージョンを利用してもオブジェクトのread、update、deleteができます。
|
||||
|
||||
## APIの変更
|
||||
|
||||
成功を収めているシステムはすべて、新しいユースケースの出現や既存の変化に応じて成長し、変化する必要があります。
|
||||
したがって、Kubernetesには、Kubernetes APIを継続的に変更および拡張できる設計機能があります。
|
||||
Kubernetesプロジェクトは、既存のクライアントとの互換性を破壊 _しないこと_ 、およびその互換性を一定期間維持して、他のプロジェクトが適応する機会を提供することを目的としています。
|
||||
|
||||
基本的に、新しいAPIリソースと新しいリソースフィールドは追加することができます。
|
||||
リソースまたはフィールドを削除するには、[API非推奨ポリシー](/docs/reference/using-api/deprecation-policy/)に従ってください。
|
||||
|
||||
Kubernetesは、公式のKubernetes APIが一度一般提供（GA）に達した場合、通常は`v1`APIバージョンです、互換性を維持することを強い責任があります。さらに、Kubernetesは _beta_ についても可能な限り互換性を維持し続けます。ベータAPIを採用した場合、その機能が安定版になったあとでも、APIを利用してクラスタを操作し続けることができます。
|
||||
|
||||
{{< note >}}
|
||||
Kubernetesは、 _alpha_ APIバージョンについても互換性の維持に注力しますが、いくつかの事情により不可である場合もあります。アルファAPIバージョンを使っている場合、クラスタのアップグレードやAPIが変更された場合に備えて、Kubernetesのリリースノートを確認してください。
|
||||
{{< /note >}}
|
||||
|
||||
APIバージョンレベルの定義に関する詳細は[APIバージョンのリファレンス](/docs/reference/using-api/#api-versioning)を参照してください。
|
||||
|
||||
## APIの拡張
|
||||
|
||||
Kubernetes APIは2つの方法で拡張できます。
|
||||
|
||||
1. [カスタムリソース](/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources/)は、APIサーバーが選択したリソースAPIをどのように提供するかを宣言的に定義します。
|
||||
1. [アグリゲーションレイヤー](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)を実装することでKubernetes APIを拡張することもできます。
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
[APIアクセスの制御](/docs/reference/access-authn-authz/controlling-access/)は、クラスターがAPIアクセスの認証と承認を管理する方法を説明しています。
|
||||
|
||||
全体的なAPI規則は、[API規則](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#api-conventions)の資料で説明されています。
|
||||
|
||||
APIエンドポイント、リソースタイプ、サンプルについては、[APIリファレンス](/docs/reference/kubernetes-api/)をご覧ください。
|
||||
- 自分自身で[カスタムリソース定義](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)を追加してKubernetes APIを拡張する方法について学んでください。
|
||||
- [Kubernetes APIのアクセス制御](/docs/concepts/security/controlling-access/)では、クラスターがAPIアクセスの認証と承認を管理する方法を説明しています。
|
||||
- [APIリファレンス](/ja/docs/reference/kubernetes-api/)を読んで、APIエンドポイント、リソースタイプやサンプルについて学んでください。
|
||||
- [APIの変更](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)から、互換性のある変更とは何か, どのようにAPIを変更するかについて学んでください。
|
||||
|
||||
@@ -8,6 +8,8 @@ weight: 10
|
||||
card:
|
||||
name: concepts
|
||||
weight: 10
|
||||
sitemap:
|
||||
priority: 0.9
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
@@ -17,7 +19,7 @@ card:
|
||||
<!-- body -->
|
||||
Kubernetesは、宣言的な構成管理と自動化を促進し、コンテナ化されたワークロードやサービスを管理するための、ポータブルで拡張性のあるオープンソースのプラットフォームです。Kubernetesは巨大で急速に成長しているエコシステムを備えており、それらのサービス、サポート、ツールは幅広い形で利用可能です。
|
||||
|
||||
Kubernetesの名称は、ギリシャ語に由来し、操舵手やパイロットを意味しています。Googleは2014年にKubernetesプロジェクトをオープンソース化しました。Kubernetesは、本番環境で大規模なワークロードを稼働させた[Googleの15年以上の経験](/blog/2015/04/borg-predecessor-to-kubernetes/)と、コミュニティからの最高のアイディアや実践を組み合わせています。
|
||||
Kubernetesの名称は、ギリシャ語に由来し、操舵手やパイロットを意味しています。Googleは2014年にKubernetesプロジェクトをオープンソース化しました。Kubernetesは、本番環境で大規模なワークロードを稼働させた[Googleの15年以上の経験](/blog/2015/04/borg-predecessor-to-kubernetes/)と、コミュニティからの最高のアイディアや実践を組み合わせています。
|
||||
|
||||
## 過去を振り返ってみると
|
||||
|
||||
@@ -33,7 +35,7 @@ Kubernetesの名称は、ギリシャ語に由来し、操舵手やパイロッ
|
||||
|
||||
各VMは、仮想ハードウェア上で各自のOSを含んだ全コンポーネントを実行する完全なマシンです。
|
||||
|
||||
**コンテナを使ったデプロイ (Container deployment):** コンテナはVMと似ていますが、アプリケーション間でオペレーティング・システム(OS)を共有できる緩和された分離特性を持っています。そのため、コンテナは軽量だといわれます。VMと同じように、コンテナは各自のファイルシステム、CPU、メモリー、プロセス空間等を持っています。基盤のインフラストラクチャから分離されているため、クラウドやOSディストリビューションを越えて移動することが可能です。
|
||||
**コンテナを使ったデプロイ (Container deployment):** コンテナはVMと似ていますが、アプリケーション間でオペレーティング・システム(OS)を共有できる緩和された分離特性を持っています。そのため、コンテナは軽量だといわれます。VMと同じように、コンテナは各自のファイルシステム、CPUの共有、メモリー、プロセス空間等を持っています。基盤のインフラストラクチャから分離されているため、クラウドやOSディストリビューションを越えて移動することが可能です。
|
||||
|
||||
コンテナは、その他にも次のようなメリットを提供するため、人気が高まっています。
|
||||
|
||||
@@ -56,17 +58,17 @@ Kubernetesの名称は、ギリシャ語に由来し、操舵手やパイロッ
|
||||
|
||||
Kubernetesは以下を提供します。
|
||||
|
||||
* **サービスディスカバリーと負荷分散**
|
||||
Kubernetesは、DNS名または独自のIPアドレスを使ってコンテナを公開することができます。コンテナへのトラフィックが多い場合は、Kubernetesは負荷分散し、ネットワークトラフィックを振り分けることができるたため、デプロイが安定します。
|
||||
* **ストレージ オーケストレーション**
|
||||
* **サービスディスカバリーと負荷分散**
|
||||
Kubernetesは、DNS名または独自のIPアドレスを使ってコンテナを公開することができます。コンテナへのトラフィックが多い場合は、Kubernetesは負荷分散し、ネットワークトラフィックを振り分けることができるため、デプロイが安定します。
|
||||
* **ストレージ オーケストレーション**
|
||||
Kubernetesは、ローカルストレージやパブリッククラウドプロバイダーなど、選択したストレージシステムを自動でマウントすることができます。
|
||||
* **自動化されたロールアウトとロールバック**
|
||||
* **自動化されたロールアウトとロールバック**
|
||||
Kubernetesを使うとデプロイしたコンテナのあるべき状態を記述することができ、制御されたスピードで実際の状態をあるべき状態に変更することができます。例えば、アプリケーションのデプロイのために、新しいコンテナの作成や既存コンテナの削除、新しいコンテナにあらゆるリソースを適用する作業を、Kubernetesで自動化できます。
|
||||
* **自動ビンパッキング**
|
||||
* **自動ビンパッキング**
|
||||
コンテナ化されたタスクを実行するノードのクラスターをKubernetesへ提供します。各コンテナがどれくらいCPUやメモリー(RAM)を必要とするのかをKubernetesに宣言することができます。Kubernetesはコンテナをノードにあわせて調整することができ、リソースを最大限に活用してくれます。
|
||||
* **自己修復**
|
||||
* **自己修復**
|
||||
Kubernetesは、処理が失敗したコンテナを再起動し、コンテナを入れ替え、定義したヘルスチェックに応答しないコンテナを強制終了します。処理の準備ができるまでは、クライアントに通知しません。
|
||||
* **機密情報と構成管理**
|
||||
* **機密情報と構成管理**
|
||||
Kubernetesは、パスワードやOAuthトークン、SSHキーのよう機密の情報を保持し、管理することができます。機密情報をデプロイし、コンテナイメージを再作成することなくアプリケーションの構成情報を更新することができます。スタック構成の中で機密情報を晒してしまうこともありません。
|
||||
|
||||
## Kubernetesにないもの
|
||||
|
||||
@@ -72,8 +72,7 @@ Kubernetesオブジェクトを`.yaml`ファイルに記載して作成する場
|
||||
|
||||
|
||||
|
||||
* [Kubernetes API overview](/docs/reference/using-api/api-overview/)はこのページでは取り上げていない他のAPIについて説明します。
|
||||
* 最も重要、かつ基本的なKubernetesオブジェクト群を学びましょう、例えば、[Pod](/ja/docs/concepts/workloads/pods/)です。
|
||||
* Kubernetesの[コントローラー](/docs/concepts/architecture/controller/)を学びましょう。
|
||||
|
||||
* Kubernetesの[コントローラー](/ja/docs/concepts/architecture/controller/)を学びましょう。
|
||||
* [Using the Kubernetes API](/docs/reference/using-api/)はこのページでは取り上げていない他のAPIについて説明します。
|
||||
|
||||
|
||||
@@ -151,10 +151,11 @@ partition
|
||||
!partition
|
||||
```
|
||||
|
||||
最初の例では、キーが`environment`で、値が`production`か`qa`に等しいリソースを全て選択します。
|
||||
第2の例では、キーが`tier`で、値が`frontend`と`backend`以外のもの、そして`tier`キーを持たないリソースを全て選択します。
|
||||
第3の例では、`partition`というキーをもつラベルを全て選択し、値はチェックしません。
|
||||
第4の例では、`partition`というキーを持たないラベルを全て選択し、値はチェックしません。
|
||||
* 最初の例では、キーが`environment`で、値が`production`か`qa`に等しいリソースを全て選択します。
|
||||
* 第2の例では、キーが`tier`で、値が`frontend`と`backend`以外のもの、そして`tier`キーを持たないリソースを全て選択します。
|
||||
* 第3の例では、`partition`というキーをもつラベルを全て選択し、値はチェックしません。
|
||||
* 第4の例では、`partition`というキーを持たないラベルを全て選択し、値はチェックしません。
|
||||
|
||||
同様に、コンマセパレーターは、_AND_ オペレーターと同様にふるまいます。そのため、`partition`と`environment`キーの値がともに`qa`でないラベルを選択するには、`partition,environment notin (qa)`と記述することで可能です。
|
||||
*集合ベース* のラベルセレクターは、`environment=production`という記述が`environment in (production)`と等しいため、一般的な等価形式となります。 `!=`と`notin`も同様に等価となります。
|
||||
|
||||
@@ -198,7 +199,7 @@ kubectl get pods -l 'environment,environment notin (frontend)'
|
||||
```
|
||||
|
||||
### APIオブジェクトに参照を設定する
|
||||
[`Service`](/ja/docs/concepts/services-networking/service/) と [`ReplicationController`](/docs/concepts/workloads/controllers/replicationcontroller/)のような、いくつかのKubernetesオブジェクトでは、ラベルセレクターを[Pod](/ja/docs/concepts/workloads/pods/pod/)のような他のリソースのセットを指定するのにも使われます。
|
||||
[`Service`](/ja/docs/concepts/services-networking/service/) と [`ReplicationController`](/docs/concepts/workloads/controllers/replicationcontroller/)のような、いくつかのKubernetesオブジェクトでは、ラベルセレクターを[Pod](/ja/docs/concepts/workloads/pods/)のような他のリソースのセットを指定するのにも使われます。
|
||||
|
||||
#### ServiceとReplicationController
|
||||
`Service`が対象とするPodの集合は、ラベルセレクターによって定義されます。
|
||||
|
||||
@@ -24,8 +24,6 @@ Namespaceは名前空間のスコープを提供します。リソース名は
|
||||
|
||||
Namespaceは、複数のユーザーの間でクラスターリソースを分割する方法です。(これは[リソースクォータ](/docs/concepts/policy/resource-quotas/)を介して分割します。)
|
||||
|
||||
Kubernetesの将来的なバージョンにおいて、同一のNamespace内のオブジェクトは、デフォルトで同一のアクセスコントロールポリシーが適用されます。
|
||||
|
||||
同じアプリケーションの異なるバージョンなど、少し違うリソースをただ分割するだけに、複数のNamespaceを使う必要はありません。
|
||||
同一のNamespace内でリソースを区別するためには[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)を使用してください。
|
||||
|
||||
|
||||
@@ -15,17 +15,17 @@ weight: 10
|
||||
|
||||
<!-- body -->
|
||||
|
||||
`ResourceQuota`オブジェクトによって定義されるリソースクォータは、名前空間ごとの総リソース消費を制限するための制約を提供します。リソースクォータは同じ名前空間のクラスター内でタイプごとに作成できるオブジェクト数や、プロジェクト内のリソースによって消費されるコンピュートリソースの総量を制限できます。
|
||||
`ResourceQuota`オブジェクトによって定義されるリソースクォータは、名前空間ごとの総リソース消費を制限するための制約を提供します。リソースクォータは同じ名前空間のクラスター内でタイプごとに作成できるオブジェクト数や、名前空間内のリソースによって消費されるコンピュートリソースの総量を制限できます。
|
||||
|
||||
リソースクォータは下記のように働きます。
|
||||
|
||||
- 異なる名前空間で異なるチームが存在するとき。現時点ではこれは自主的なものですが、将来的にはACLsを介してリソースクォータの設定を強制するように計画されています。
|
||||
- 管理者は各名前空間で1つの`ResourceQuota`を作成します。
|
||||
- ユーザーが名前空間内でリソース(Pod、Serviceなど)を作成し、クォータシステムが`ResourceQuota`によって定義されたハードリソースリミットを超えないことを保証するために、リソースの使用量をトラッキングします。
|
||||
- リソースの作成や更新がクォータの制約に違反しているとき、そのリクエストはHTTPステータスコード`403 FORBIDDEN`で失敗し、違反した制約を説明するメッセージが表示されます。
|
||||
- リソースの作成や更新がクォータの制約に違反しているとき、そのリクエストはHTTPステータスコード`403 FORBIDDEN`で失敗し、違反した制約を説明するメッセージが表示されます。
|
||||
- `cpu`や`memory`といったコンピューターリソースに対するクォータが名前空間内で有効になっているとき、ユーザーはそれらの値に対する`requests`や`limits`を設定する必要があります。設定しないとクォータシステムがPodの作成を拒否します。 ヒント: コンピュートリソースの要求を設定しないPodに対してデフォルト値を強制するために、`LimitRanger`アドミッションコントローラーを使用してください。この問題を解決する例は[walkthrough](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)で参照できます。
|
||||
|
||||
`ResourceQuota`のオブジェクト名は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります.
|
||||
ResourceQuotaのオブジェクト名は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります.
|
||||
|
||||
名前空間とクォータを使用して作成できるポリシーの例は以下の通りです。
|
||||
|
||||
@@ -40,7 +40,7 @@ weight: 10
|
||||
|
||||
多くのKubernetesディストリビューションにおいてリソースクォータはデフォルトで有効になっています。APIサーバーで`--enable-admission-plugins=`の値に`ResourceQuota`が含まれるときに有効になります。
|
||||
|
||||
特定の名前空間に`ResourceQuota`があるとき、そのリソースクォータはその名前空間に適用されます。
|
||||
特定の名前空間にResourceQuotaがあるとき、そのリソースクォータはその名前空間に適用されます。
|
||||
|
||||
## リソースクォータの計算
|
||||
|
||||
@@ -55,6 +55,9 @@ weight: 10
|
||||
| `limits.memory` | 停止していない状態の全てのPodで、メモリーの合計がこの値を超えることができません。 |
|
||||
| `requests.cpu` | 停止していない状態の全てのPodで、CPUリクエストの合計がこの値を超えることができません。 |
|
||||
| `requests.memory` | 停止していない状態の全てのPodで、メモリーリクエストの合計がこの値を超えることができません。 |
|
||||
| `hugepages-<size>` | 停止していない状態の全てのPodで, 指定されたサイズのHuge Pageリクエスト数がこの値を超えることができません。 |
|
||||
| `cpu` | `requests.cpu`と同じ。 |
|
||||
| `memory` | `requests.memory`と同じ。 |
|
||||
|
||||
### 拡張リソースのためのリソースクォータ
|
||||
|
||||
@@ -79,8 +82,8 @@ GPUリソースを例にすると、もしリソース名が`nvidia.com/gpu`で
|
||||
| --------------------- | ----------------------------------------------------------- |
|
||||
| `requests.storage` | 全てのPersistentVolumeClaimにおいて、ストレージのリクエストの合計がこの値を超えないようにします。 |
|
||||
| `persistentvolumeclaims` | 特定の名前空間内で作成可能な[PersistentVolumeClaim](/ja/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)の総数。 |
|
||||
| `<storage-class-name>.storageclass.storage.k8s.io/requests.storage` | ストレージクラス名に関連する全てのPersistentVolumeClaimにおいて、ストレージリクエストの合計がこの値を超えないようにします。 |
|
||||
| `<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims` | ストレージクラス名に関連する全てのPersistentVolumeClaimにおいて、特定の名前空間内で作成可能な[PersistentVolumeClaim](/ja/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)の総数。 |
|
||||
| `<storage-class-name>.storageclass.storage.k8s.io/requests.storage` | ストレージクラス名`<storage-class-name>`に関連する全てのPersistentVolumeClaimにおいて、ストレージリクエストの合計がこの値を超えないようにします。 |
|
||||
| `<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims` | ストレージクラス名`<storage-class-name>`に関連する全てのPersistentVolumeClaimにおいて、特定の名前空間内で作成可能な[PersistentVolumeClaim](/ja/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)の総数。 |
|
||||
|
||||
例えば、もし管理者が`gold`ストレージクラスを`bronze`ストレージクラスと分けてリソースクォータを設定するとき、管理者はリソースクォータを下記のように指定できます。
|
||||
|
||||
@@ -93,12 +96,14 @@ Kubernetes v1.8において、ローカルのエフェメラルストレージ
|
||||
| ------------------------------- |----------------------------------------------------------- |
|
||||
| `requests.ephemeral-storage` | 名前空間内の全てのPodで、ローカルのエフェメラルストレージのリクエストの合計がこの値を超えないようにします。 |
|
||||
| `limits.ephemeral-storage` | 名前空間内の全てのPodで、ローカルのエフェメラルストレージのリミットの合計がこの値を超えないようにします。 |
|
||||
| `ephemeral-storage` | `requests.ephemeral-storage`と同じ。 |
|
||||
|
||||
## オブジェクト数に対するクォータ
|
||||
|
||||
Kubernetes v1.9では下記のシンタックスを使用して、名前空間に紐づいた全ての標準リソースタイプに対するリソースクォータのサポートが追加されました。
|
||||
下記のシンタックスを使用して、名前空間に紐づいた全ての標準であるリソースタイプの中の特定のリソースの総数に対するリソースクォータを設定できます。
|
||||
|
||||
* `count/<resource>.<group>`
|
||||
* `count/<resource>.<group>` コアでないグループのリソース用
|
||||
* `count/<resource>` コアグループのリソース用
|
||||
|
||||
オブジェクト数に対するクォータでユーザーが設定するリソースの例は下記の通りです。
|
||||
|
||||
@@ -112,13 +117,12 @@ Kubernetes v1.9では下記のシンタックスを使用して、名前空間
|
||||
* `count/statefulsets.apps`
|
||||
* `count/jobs.batch`
|
||||
* `count/cronjobs.batch`
|
||||
* `count/deployments.extensions`
|
||||
|
||||
Kubernetes v1.15において、同一のシンタックスを使用して、カスタムリソースに対するサポートが追加されました。例えば、`example.com`というAPIグループ内の`widgets`というカスタムリソースのリソースクォータを設定するには`count/widgets.example.com`と記述します。
|
||||
カスタムリソースに対して同じシンタックスを使用できます。例えば、`example.com`というAPIグループ内の`widgets`というカスタムリソースのリソースクォータを設定するには`count/widgets.example.com`と記述します。
|
||||
|
||||
`count/*`リソースクォータの使用において、オブジェクトがサーバーストレージに存在するときオブジェクトはクォータの計算対象となります。このようなタイプのリソースクォータはストレージリソース浪費の防止に有効です。例えば、もしSecretが大量に存在するとき、そのSecretリソースの総数に対してリソースクォータの制限をかけたい場合です。クラスター内でSecretが大量にあると、サーバーとコントローラーの起動を妨げることになります！また、適切に設定されていないCronJobが名前空間内で大量のJobを作成し、サービスが利用不可能になることを防ぐためにリソースクォータを設定できます。
|
||||
`count/*`リソースクォータの使用において、オブジェクトがサーバーストレージに存在するときオブジェクトはクォータの計算対象となります。このようなタイプのリソースクォータはストレージリソース浪費の防止に有効です。例えば、もしSecretが大量に存在するとき、そのSecretリソースの総数に対してリソースクォータの制限をかけたい場合です。クラスター内でSecretが大量にあると、サーバーとコントローラーの起動を妨げることになります。適切に設定されていないCronJobから保護するためにジョブのクォータを設定できます。名前空間内で大量のJobを作成するCronJobは、サービスを利用不可能にする可能性があります。
|
||||
|
||||
Kubernetes v1.9より前のバージョンでは、限定されたリソースのセットにおいて汎用オブジェクトカウントのリソースクォータを実行可能でした。さらに、特定のリソースに対するリソースクォータを種類ごとに制限することができます。
|
||||
また、限定されたリソースのセットにおいて汎用オブジェクトカウントのリソースクォータを実行可能です。
|
||||
|
||||
下記のタイプのリソースがサポートされています。
|
||||
|
||||
@@ -128,7 +132,7 @@ Kubernetes v1.9より前のバージョンでは、限定されたリソース
|
||||
| `persistentvolumeclaims` | 名前空間内で存在可能な[PersistentVolumeClaim](/ja/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)の総数。 |
|
||||
| `pods` | 名前空間内で存在可能な停止していないPodの総数。`.status.phase in (Failed, Succeeded)`がtrueのとき、Podは停止状態にあります。 |
|
||||
| `replicationcontrollers` | 名前空間内で存在可能なReplicationControlerの総数。 |
|
||||
| `resourcequotas` | 名前空間内で存在可能な[リソースクォータ](/docs/reference/access-authn-authz/admission-controllers/#resourcequota)の総数。 |
|
||||
| `resourcequotas` | 名前空間内で存在可能なResourceQuotaの総数。 |
|
||||
| `services` | 名前空間内で存在可能なServiceの総数。 |
|
||||
| `services.loadbalancers` | 名前空間内で存在可能なtype:LoadBalancerであるServiceの総数。 |
|
||||
| `services.nodeports` | 名前空間内で存在可能なtype:NodePortであるServiceの総数。 |
|
||||
@@ -138,7 +142,7 @@ Kubernetes v1.9より前のバージョンでは、限定されたリソース
|
||||
|
||||
## クォータのスコープについて
|
||||
|
||||
各リソースクォータには関連するスコープのセットを関連づけることができます。クォータは、列挙されたスコープの共通部分と一致する場合にのみリソースの使用量を計測します。
|
||||
各リソースクォータには関連する`scope`のセットを関連づけることができます。クォータは、列挙されたscopeの共通部分と一致する場合にのみリソースの使用量を計測します。
|
||||
|
||||
スコープがクォータに追加されると、サポートするリソースの数がスコープに関連するリソースに制限されます。許可されたセット以外のクォータ上でリソースを指定するとバリデーションエラーになります。
|
||||
|
||||
@@ -148,27 +152,72 @@ Kubernetes v1.9より前のバージョンでは、限定されたリソース
|
||||
| `NotTerminating` | `.spec.activeDeadlineSecondsがnil`であるPodに一致します。 |
|
||||
| `BestEffort` | ベストエフォート型のサービス品質のPodに一致します。 |
|
||||
| `NotBestEffort` | ベストエフォート型のサービス品質でないPodに一致します。 |
|
||||
| `PriorityClass` | 指定された[優先度クラス](/docs/concepts/configuration/pod-priority-preemption)と関連付いているPodに一致します。 |
|
||||
|
||||
`BestEffort`スコープはリソースクォータを次のリソースに対するトラッキングのみに制限します: `pods`
|
||||
`BestEffort`スコープはリソースクォータを次のリソースに対するトラッキングのみに制限します:
|
||||
|
||||
`Terminating`、`NotTerminating`、`NotBestEffort`スコープは、リソースクォータを次のリソースに対するトラッキングのみに制限します:
|
||||
|
||||
* `cpu`
|
||||
* `limits.cpu`
|
||||
* `limits.memory`
|
||||
* `memory`
|
||||
* `pods`
|
||||
|
||||
`Terminating`、`NotTerminating`、`NotBestEffort`、`PriorityClass`スコープは、リソースクォータを次のリソースに対するトラッキングのみに制限します:
|
||||
|
||||
* `pods`
|
||||
* `cpu`
|
||||
* `memory`
|
||||
* `requests.cpu`
|
||||
* `requests.memory`
|
||||
* `limits.cpu`
|
||||
* `limits.memory`
|
||||
|
||||
同じクォータで`Terminating`と`NotTerminating`の両方のスコープを指定することはできず、また同じクォータで`BestEffort`と`NotBestEffort`の両方のスコープを指定することもできないことに注意してください。
|
||||
|
||||
`scopeSelector`は`operator` フィールドにおいて下記の値をサポートしています。:
|
||||
|
||||
* `In`
|
||||
* `NotIn`
|
||||
* `Exists`
|
||||
* `DoesNotExist`
|
||||
|
||||
`scopeSelector`の定義において`scopeName`に下記のいずれかの値を使用する場合、`operator`に`Exists`を指定してください。
|
||||
|
||||
* `Terminating`
|
||||
* `NotTerminating`
|
||||
* `BestEffort`
|
||||
* `NotBestEffort`
|
||||
|
||||
`operator`が`In`または`NotIn`の場合、`values`フィールドには少なくとも1つの値が必要です。例えば以下のように記述します：
|
||||
|
||||
```yaml
|
||||
scopeSelector:
|
||||
matchExpressions:
|
||||
- scopeName: PriorityClass
|
||||
operator: In
|
||||
values:
|
||||
- middle
|
||||
```
|
||||
|
||||
`operator`が`Exists`または`DoesNotExist`の場合、`values`フィールドは指定*しないでください*。
|
||||
|
||||
### PriorityClass毎のリソースクォータ
|
||||
|
||||
{{< feature-state for_k8s_version="v1.12" state="beta" >}}
|
||||
{{< feature-state for_k8s_version="v1.17" state="stable" >}}
|
||||
|
||||
Podは特定の[優先度](/docs/concepts/configuration/pod-priority-preemption/#pod-priority)で作成されます。リソースクォータのSpec内にある`scopeSelector`フィールドを使用して、Podの優先度に基づいてPodのシステムリソースの消費をコントロールできます。
|
||||
|
||||
リソースクォータのSpec内の`scopeSelector`によってPodが選択されたときのみ、そのリソースクォータが一致し、消費されます。
|
||||
|
||||
リソースクォータが`scopeSelector`フィールドを使用して優先度クラスに対してスコープされる場合、リソースクォータのオプジェクトは、次のリソースのみトラッキングするように制限されます:
|
||||
|
||||
* `pods`
|
||||
* `cpu`
|
||||
* `memory`
|
||||
* `ephemeral-storage`
|
||||
* `limits.cpu`
|
||||
* `limits.memory`
|
||||
* `limits.ephemeral-storage`
|
||||
* `requests.cpu`
|
||||
* `requests.memory`
|
||||
* `requests.ephemeral-storage`
|
||||
|
||||
この例ではリソースクォータのオブジェクトを作成し、特定の優先度を持つPodに一致させます。この例は下記のように動作します。
|
||||
|
||||
- クラスター内のPodは"low"、"medium"、"high"の3つの優先度クラスのうち1つをもちます。
|
||||
@@ -230,7 +279,7 @@ items:
|
||||
kubectl create -f ./quota.yml
|
||||
```
|
||||
|
||||
```shell
|
||||
```
|
||||
resourcequota/pods-high created
|
||||
resourcequota/pods-medium created
|
||||
resourcequota/pods-low created
|
||||
@@ -242,7 +291,7 @@ resourcequota/pods-low created
|
||||
kubectl describe quota
|
||||
```
|
||||
|
||||
```shell
|
||||
```
|
||||
Name: pods-high
|
||||
Namespace: default
|
||||
Resource Used Hard
|
||||
@@ -305,7 +354,7 @@ kubectl create -f ./high-priority-pod.yml
|
||||
kubectl describe quota
|
||||
```
|
||||
|
||||
```shell
|
||||
```
|
||||
Name: pods-high
|
||||
Namespace: default
|
||||
Resource Used Hard
|
||||
@@ -333,13 +382,6 @@ memory 0 20Gi
|
||||
pods 0 10
|
||||
```
|
||||
|
||||
`scopeSelector`は`operator`フィールドにおいて下記の値をサポートしています。
|
||||
|
||||
* `In`
|
||||
* `NotIn`
|
||||
* `Exist`
|
||||
* `DoesNotExist`
|
||||
|
||||
## リクエスト vs リミット
|
||||
|
||||
コンピュートリソースを分配する際に、各コンテナはCPUとメモリーそれぞれのリクエストとリミット値を指定します。クォータはそれぞれの値を設定できます。
|
||||
@@ -400,7 +442,7 @@ kubectl create -f ./object-counts.yaml --namespace=myspace
|
||||
kubectl get quota --namespace=myspace
|
||||
```
|
||||
|
||||
```shell
|
||||
```
|
||||
NAME AGE
|
||||
compute-resources 30s
|
||||
object-counts 32s
|
||||
@@ -410,7 +452,7 @@ object-counts 32s
|
||||
kubectl describe quota compute-resources --namespace=myspace
|
||||
```
|
||||
|
||||
```shell
|
||||
```
|
||||
Name: compute-resources
|
||||
Namespace: myspace
|
||||
Resource Used Hard
|
||||
@@ -426,7 +468,7 @@ requests.nvidia.com/gpu 0 4
|
||||
kubectl describe quota object-counts --namespace=myspace
|
||||
```
|
||||
|
||||
```shell
|
||||
```
|
||||
Name: object-counts
|
||||
Namespace: myspace
|
||||
Resource Used Hard
|
||||
@@ -447,53 +489,50 @@ kubectl create namespace myspace
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl create quota test --hard=count/deployments.extensions=2,count/replicasets.extensions=4,count/pods=3,count/secrets=4 --namespace=myspace
|
||||
kubectl create quota test --hard=count/deployments.apps=2,count/replicasets.apps=4,count/pods=3,count/secrets=4 --namespace=myspace
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl create deployment nginx --image=nginx --namespace=myspace
|
||||
kubectl scale deployment nginx --replicas=2 --namespace=myspace
|
||||
kubectl create deployment nginx --image=nginx --namespace=myspace --replicas=2
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl describe quota --namespace=myspace
|
||||
```
|
||||
|
||||
```shell
|
||||
```
|
||||
Name: test
|
||||
Namespace: myspace
|
||||
Resource Used Hard
|
||||
-------- ---- ----
|
||||
count/deployments.extensions 1 2
|
||||
count/deployments.apps 1 2
|
||||
count/pods 2 3
|
||||
count/replicasets.extensions 1 4
|
||||
count/replicasets.apps 1 4
|
||||
count/secrets 1 4
|
||||
```
|
||||
|
||||
## クォータとクラスター容量
|
||||
|
||||
`ResourceQuotas`はクラスター容量に依存しません。またユニット数の絶対値で表されます。そのためクラスターにノードを追加したことにより、各名前空間が自動的により多くのリソースを消費するような機能が提供されるわけでは*ありません*。
|
||||
ResourceQuotaはクラスター容量に依存しません。またユニット数の絶対値で表されます。そのためクラスターにノードを追加したことにより、各名前空間が自動的により多くのリソースを消費するような機能が提供されるわけでは*ありません*。
|
||||
|
||||
下記のようなより複雑なポリシーが必要な状況があります。
|
||||
|
||||
- 複数チーム間でクラスターリソースの総量を分けあう。
|
||||
- 各テナントが必要な時にリソース使用量を増やせるようにするが、偶発的なリソースの枯渇を防ぐために上限を設定する。
|
||||
- 1つの名前空間に対してリソース消費の需要を検出し、ノードを追加し、クォータを増加させる。
|
||||
- 複数チーム間でクラスターリソースの総量を分けあう。
|
||||
- 各テナントが必要な時にリソース使用量を増やせるようにするが、偶発的なリソースの枯渇を防ぐために上限を設定する。
|
||||
- 1つの名前空間に対してリソース消費の需要を検出し、ノードを追加し、クォータを増加させる。
|
||||
|
||||
このようなポリシーは、クォータの使用量の監視と、他のシグナルにしたがってクォータのハードの制限を調整する"コントローラー"を記述することにより、`ResourceQuotas`をビルディングブロックのように使用して実装できます。
|
||||
このようなポリシーは、クォータの使用量の監視と、他のシグナルにしたがってクォータのハードの制限を調整する"コントローラー"を記述することにより、ResourceQuotaをビルディングブロックのように使用して実装できます。
|
||||
|
||||
リソースクォータは集約されたクラスターリソースを分割しますが、ノードに対しては何の制限も行わないことに注意して下さい。例: 複数の名前空間のPodは同一のノード上で稼働する可能性があります。
|
||||
|
||||
## デフォルトで優先度クラスの消費を制限する
|
||||
## デフォルトで優先度クラスの消費を制限する {#limit-priority-class-consumption-by-default}
|
||||
|
||||
例えば"cluster-services"のように、条件に一致するクォータオブジェクトが存在する場合に限り、特定の優先度のPodを名前空間で許可することが望ましい場合があります。
|
||||
|
||||
このメカニズムにより、オペレーターは特定の高優先度クラスの使用を限られた数の名前空間に制限することができ、全ての名前空間でこれらの優先度クラスをデフォルトで使用することはできなくなります。
|
||||
|
||||
これを実施するには、kube-apiserverの`--admission-control-config-file`というフラグを使い、下記の設定ファイルに対してパスを渡す必要がります。
|
||||
これを実施するには、`kube-apiserver`の`--admission-control-config-file`というフラグを使い、下記の設定ファイルに対してパスを渡す必要がります。
|
||||
|
||||
{{< tabs name="example1" >}}
|
||||
{{% tab name="apiserver.config.k8s.io/v1" %}}
|
||||
```yaml
|
||||
apiVersion: apiserver.config.k8s.io/v1
|
||||
kind: AdmissionConfiguration
|
||||
@@ -509,27 +548,6 @@ plugins:
|
||||
operator: In
|
||||
values: ["cluster-services"]
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="apiserver.k8s.io/v1alpha1" %}}
|
||||
```yaml
|
||||
# v1.17では非推奨になり、apiserver.config.k8s.io/v1の使用を推奨します。
|
||||
apiVersion: apiserver.k8s.io/v1alpha1
|
||||
kind: AdmissionConfiguration
|
||||
plugins:
|
||||
- name: "ResourceQuota"
|
||||
configuration:
|
||||
# v1.17では非推奨になり、apiserver.config.k8s.io/v1、ResourceQuotaConfigurationの使用を推奨します。
|
||||
apiVersion: resourcequota.admission.k8s.io/v1beta1
|
||||
kind: Configuration
|
||||
limitedResources:
|
||||
- resource: pods
|
||||
matchScopes:
|
||||
- scopeName: PriorityClass
|
||||
operator: In
|
||||
values: ["cluster-services"]
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
なお、"cluster-services"Podは、条件に一致する`scopeSelector`を持つクォータオブジェクトが存在する名前空間でのみ許可されます。
|
||||
|
||||
@@ -541,14 +559,9 @@ plugins:
|
||||
values: ["cluster-services"]
|
||||
```
|
||||
|
||||
さらなる情報は、[LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765)と[優先度クラスに対するクォータサポートの design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-resourcequota.md)を参照してください。
|
||||
|
||||
## 例
|
||||
|
||||
[リソースクォータの使用方法の例](/docs/tasks/administer-cluster/quota-api-object/)を参照してください。
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
- さらなる情報は[クォータの design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)を参照してください。
|
||||
|
||||
- [リソースクォータの使用方法の例](/docs/tasks/administer-cluster/quota-api-object/)を参照してください。
|
||||
- [優先度クラスに対するクォータサポートの design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-resourcequota.md)を参照してください。
|
||||
- [LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765)を参照してください。
|
||||
|
||||
@@ -66,17 +66,7 @@ nodeSelectorを以下のように追加します:
|
||||
## 補足: ビルトインNodeラベル {#built-in-node-labels}
|
||||
|
||||
明示的に[付与](#step-one-attach-label-to-the-node)するラベルの他に、事前にNodeへ付与されているものもあります。
|
||||
以下のようなラベルが該当します。
|
||||
|
||||
* [`kubernetes.io/hostname`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-hostname)
|
||||
* [`failure-domain.beta.kubernetes.io/zone`](/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domainbetakubernetesiozone)
|
||||
* [`failure-domain.beta.kubernetes.io/region`](/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domainbetakubernetesioregion)
|
||||
* [`topology.kubernetes.io/zone`](/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone)
|
||||
* [`topology.kubernetes.io/region`](/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone)
|
||||
* [`beta.kubernetes.io/instance-type`](/docs/reference/kubernetes-api/labels-annotations-taints/#beta-kubernetes-io-instance-type)
|
||||
* [`node.kubernetes.io/instance-type`](/docs/reference/kubernetes-api/labels-annotations-taints/#nodekubernetesioinstance-type)
|
||||
* [`kubernetes.io/os`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-os)
|
||||
* [`kubernetes.io/arch`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-arch)
|
||||
これらのラベルのリストは、[Well-Known Labels, Annotations and Taints](/docs/reference/kubernetes-api/labels-annotations-taints/)を参照してください。
|
||||
|
||||
{{< note >}}
|
||||
これらのラベルは、クラウドプロバイダー固有であり、確実なものではありません。
|
||||
@@ -140,9 +130,9 @@ Nodeアフィニティでは、`In`、`NotIn`、`Exists`、`DoesNotExist`、`Gt`
|
||||
|
||||
`nodeSelector`と`nodeAffinity`の両方を指定した場合、Podは**両方の**条件を満たすNodeにスケジュールされます。
|
||||
|
||||
`nodeAffinity`内で複数の`nodeSelectorTerms`を指定した場合、Podは**全ての**`nodeSelectorTerms`を満たしたNodeへスケジュールされます。
|
||||
`nodeAffinity`内で複数の`nodeSelectorTerms`を指定した場合、Podは**いずれかの**`nodeSelectorTerms`を満たしたNodeへスケジュールされます。
|
||||
|
||||
`nodeSelectorTerms`内で複数の`matchExpressions`を指定した場合にはPodは**いずれかの**`matchExpressions`を満たしたNodeへスケジュールされます。
|
||||
`nodeSelectorTerms`内で複数の`matchExpressions`を指定した場合にはPodは**全ての**`matchExpressions`を満たしたNodeへスケジュールされます。
|
||||
|
||||
PodがスケジュールされたNodeのラベルを削除したり変更しても、Podは削除されません。
|
||||
言い換えると、アフィニティはPodをスケジュールする際にのみ考慮されます。
|
||||
|
||||
@@ -50,65 +50,10 @@ _スコアリング_ ステップでは、Podを割り当てるのに最も適
|
||||
|
||||
最後に、kube-schedulerは最も高いランクのNodeに対してPodを割り当てます。もし同一のスコアのNodeが複数ある場合は、kube-schedulerがランダムに1つ選択します。
|
||||
|
||||
### デフォルトのポリシーについて
|
||||
スケジューラーのフィルタリングとスコアリングの動作に関する設定には2つのサポートされた手法があります。
|
||||
|
||||
kube-schedulerは、デフォルトで用意されているスケジューリングポリシーのセットを持っています。
|
||||
|
||||
### フィルタリング
|
||||
|
||||
- `PodFitsHostPorts`: Nodeに、Podが要求するポートが利用可能かどうかをチェックします。
|
||||
|
||||
- `PodFitsHost`: Podがそのホスト名において特定のNodeを指定しているかをチェックします。
|
||||
|
||||
- `PodFitsResources`: Nodeに、Podが要求するリソース(例: CPUとメモリー)が利用可能かどうかをチェックします。
|
||||
|
||||
- `PodMatchNodeSelector`: PodのNodeSelectorが、Nodeのラベルにマッチするかどうかをチェックします。
|
||||
|
||||
- `NoVolumeZoneConflict`: Podが要求するVolumeがNode上で利用可能かを、障害が発生しているゾーンを考慮して評価します。
|
||||
|
||||
- `NoDiskConflict`: NodeのVolumeがPodの要求を満たし、すでにマウントされているかどうかを評価します。
|
||||
|
||||
- `MaxCSIVolumeCount`: CSI Volumeをいくつ割り当てるべきか決定し、それが設定された上限を超えるかどうかを評価します。
|
||||
|
||||
- `CheckNodeMemoryPressure`: もしNodeがメモリーの容量が逼迫している場合、また設定された例外がない場合はそのPodはそのNodeにスケジュールされません。
|
||||
|
||||
- `CheckNodePIDPressure`: もしNodeのプロセスIDが枯渇しそうになっていた場合や、設定された例外がない場合はそのPodはそのNodeにスケジュールされません。
|
||||
|
||||
- `CheckNodeDiskPressure`: もしNodeのストレージが逼迫している場合(ファイルシステムの残り容量がほぼない場合)や、設定された例外がない場合はそのPodはそのNodeにスケジュールされません。
|
||||
|
||||
- `CheckNodeCondition`: Nodeは、ファイルシステムの空き容量が完全になくなった場合、ネットワークが利用不可な場合、kubeletがPodを稼働させる準備をできていない場合などに、その状況を通知できます。Nodeがこの状況下かつ設定された例外がない場合、Podは該当のNodeにスケジュールされません。
|
||||
|
||||
- `PodToleratesNodeTaints`: PodのTolerationがNodeのTaintを許容できるかチェックします。
|
||||
|
||||
- `CheckVolumeBinding`: Podが要求するVolumeの要求を満たすか評価します。これはPersistentVolumeClaimがバインドされているかに関わらず適用されます。
|
||||
|
||||
### スコアリング
|
||||
|
||||
- `SelectorSpreadPriority`: 同一のService、StatefulSetや、ReplicaSetに属するPodを複数のホストをまたいで稼働させます。
|
||||
|
||||
- `InterPodAffinityPriority`: weightedPodAffinityTermの要素をイテレートして合計を計算したり、もし一致するPodAffinityTermがNodeに適合している場合は、"重み"を合計値に足したりします。:最も高い合計値を持つNode(複数もあり)が候補となります。
|
||||
|
||||
- `LeastRequestedPriority`: 要求されたリソースがより低いNodeを優先するものです。言い換えると、Nodeに多くのPodが稼働しているほど、Podが使用するリソースが多くなり、その要求量が低いNodeが選択されます。
|
||||
|
||||
- `MostRequestedPriority`: 要求されたリソースがより多いNodeを優先するものです。このポリシーは、ワークロードの全体セットを実行するために必要な最小数のNodeに対して、スケジュールされたPodを適合させます。
|
||||
|
||||
- `RequestedToCapacityRatioPriority`: デフォルトのリソーススコアリング関数を使用して、requestedToCapacityベースのResourceAllocationPriorityを作成します。
|
||||
|
||||
- `BalancedResourceAllocation`: バランスのとれたリソース使用量になるようにNodeを選択します。
|
||||
|
||||
- `NodePreferAvoidPodsPriority`: Nodeの`scheduler.alpha.kubernetes.io/preferAvoidPods`というアノテーションに基づいてNodeの優先順位づけをします。この設定により、2つの異なるPodが同じNode上で実行しないことを示唆できます。
|
||||
|
||||
- `NodeAffinityPriority`: "PreferredDuringSchedulingIgnoredDuringExecution"の値によって示されたNode Affinityのスケジューリング性向に基づいてNodeの優先順位づけを行います。詳細は[NodeへのPodの割り当て](https://kubernetes.io/ja/docs/concepts/scheduling-eviction/assign-pod-node/)にて確認できます。
|
||||
|
||||
- `TaintTolerationPriority`: Node上における許容できないTaintsの数に基づいて、全てのNodeの優先順位リストを準備します。このポリシーでは優先順位リストを考慮してNodeのランクを調整します。
|
||||
|
||||
- `ImageLocalityPriority`: すでにPodに対するコンテナイメージをローカルにキャッシュしているNodeを優先します。
|
||||
|
||||
- `ServiceSpreadingPriority`: このポリシーの目的は、特定のServiceに対するバックエンドのPodが、それぞれ異なるNodeで実行されるようにすることです。このポリシーではServiceのバックエンドのPodがすでに実行されていないNode上にスケジュールするように優先します。これによる結果として、Serviceは単体のNode障害に対してより耐障害性が高まります。
|
||||
|
||||
- `CalculateAntiAffinityPriorityMap`: このポリシーは[PodのAnti-Affinity](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)の実装に役立ちます。
|
||||
|
||||
- `EqualPriorityMap`: 全てのNodeに対して等しい重みを与えます。
|
||||
1. [スケジューリングポリシー](/docs/reference/scheduling/policies) は、フィルタリングのための_Predicates_とスコアリングのための_Priorities_の設定することができます。
|
||||
1. [スケジューリングプロファイル](/docs/reference/scheduling/config/#profiles)は、`QueueSort`、 `Filter`、 `Score`、 `Bind`、 `Reserve`、 `Permit`やその他を含む異なるスケジューリングの段階を実装するプラグインを設定することができます。kube-schedulerを異なるプロファイルを実行するように設定することもできます。
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
@@ -118,4 +63,8 @@ kube-schedulerは、デフォルトで用意されているスケジューリン
|
||||
* kube-schedulerの[リファレンスドキュメント](/docs/reference/command-line-tools-reference/kube-scheduler/)を参照してください。
|
||||
* [複数のスケジューラーの設定](/docs/tasks/administer-cluster/configure-multiple-schedulers/)について学んでください。
|
||||
* [トポロジーの管理ポリシー](/docs/tasks/administer-cluster/topology-manager/)について学んでください。
|
||||
* [Podのオーバーヘッド](/docs/concepts/configuration/pod-overhead/)について学んでください。
|
||||
* [Podのオーバーヘッド](/docs/concepts/scheduling-eviction/pod-overhead/)について学んでください。
|
||||
* ボリュームを使用するPodのスケジューリングについて以下で学んでください。
|
||||
* [Volume Topology Support](/docs/concepts/storage/storage-classes/#volume-binding-mode)
|
||||
* [ストレージ容量の追跡](/ja//docs/concepts/storage/storage-capacity/)
|
||||
* [Node-specific Volume Limits](/docs/concepts/storage/storage-limits/)
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: スケジューラーのパフォーマンスチューニング
|
||||
content_type: concept
|
||||
weight: 70
|
||||
weight: 80
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
@@ -15,12 +15,44 @@ weight: 70
|
||||
このページでは、大規模のKubernetesクラスターにおけるパフォーマンス最適化のためのチューニングについて説明します。
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## スコア付けするノードの割合
|
||||
大規模クラスターでは、レイテンシー(新規Podをすばやく配置)と精度(スケジューラーが不適切な配置を行うことはめったにありません)の間でスケジューリング結果を調整するスケジューラーの動作をチューニングできます。
|
||||
|
||||
Kubernetes 1.12以前では、Kube-schedulerがクラスター内の全てのノードに対して割り当て可能かをチェックし、実際に割り当て可能なノードのスコア付けをしていました。Kubernetes 1.12では新機能を追加し、ある数の割り当て可能なノードが見つかった時点で、割り当て可能なノードの探索を止めれるようになりました。これにより大規模なクラスターにおけるスケジューラーのパフォーマンスが向上しました。その数はクラスターのサイズの割合(%)として指定されます。この割合は`percentageOfNodesToScore`というオプションの設定項目によって指定可能です。この値の範囲は1から100までです。100より大きい値は100%として扱われます。0を指定したときは、この設定オプションを指定しないものとして扱われます。Kubernetes 1.14では、この値が指定されていないときは、スコア付けするノードの割合をクラスターのサイズに基づいて決定するためのメカニズムがあります。このメカニズムでは100ノードのクラスターに対しては50%の割合とするような線形な式を使用します。5000ノードのクラスターに対しては10%となります。自動で算出される割合の最低値は5%となります。言い換えると、クラスターの規模がどれだけ大きくても、ユーザーがこの値を5未満に設定しない限りスケジューラーは少なくても5%のクラスター内のノードをスコア付けすることになります。
|
||||
このチューニング設定は、kube-scheduler設定の`percentageOfNodesToScore`で設定できます。KubeSchedulerConfiguration設定は、クラスター内のノードにスケジュールするための閾値を決定します。
|
||||
|
||||
### 閾値の設定
|
||||
|
||||
`percentageOfNodesToScore`オプションは、0から100までの数値を受け入れます。0は、kube-schedulerがコンパイル済みのデフォルトを使用することを示す特別な値です。
|
||||
`percentageOfNodesToScore`に100より大きな値を設定した場合、kube-schedulerの挙動は100を設定した場合と同様となります。
|
||||
|
||||
この値を変更するためには、kube-schedulerの設定ファイル(これは`/etc/kubernetes/config/kube-scheduler.yaml`の可能性が高い)を編集し、スケジューラーを再起動します。
|
||||
|
||||
この変更をした後、
|
||||
|
||||
```bash
|
||||
kubectl get pods -n kube-system | grep kube-scheduler
|
||||
```
|
||||
|
||||
を実行して、kube-schedulerコンポーネントが正常であることを確認できます。
|
||||
|
||||
## ノードへのスコア付けの閾値 {#percentage-of-nodes-to-score}
|
||||
|
||||
スケジューリング性能を改善するため、kube-schedulerは割り当て可能なノードが十分に見つかるとノードの検索を停止できます。大規模クラスターでは、すべてのノードを考慮する単純なアプローチと比較して時間を節約できます。
|
||||
|
||||
クラスター内のすべてのノードに対する十分なノード数を整数パーセンテージで指定します。kube-schedulerは、これをノード数に変換します。スケジューリング中に、kube-schedulerが設定されたパーセンテージを超える十分な割り当て可能なノードを見つけた場合、kube-schedulerはこれ以上割り当て可能なノードを探すのを止め、[スコアリングフェーズ](/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler-implementation)に進みます。
|
||||
|
||||
[スケジューラーはどのようにノードを探索するか](#how-the-scheduler-iterates-over-nodes)で処理を詳しく説明しています。
|
||||
|
||||
### デフォルトの閾値
|
||||
|
||||
閾値を指定しない場合、Kubernetesは100ノードのクラスタでは50%、5000ノードのクラスタでは10%になる線形方程式を使用して数値を計算します。自動計算の下限は5%です。
|
||||
|
||||
つまり、明示的に`percentageOfNodesToScore`を5未満の値を設定しない限り、クラスターの規模に関係なく、kube-schedulerは常に少なくともクラスターの5%のノードに対してスコア付けをします。
|
||||
|
||||
スケジューラーにクラスター内のすべてのノードに対してスコア付けをさせる場合は、`percentageOfNodesToScore`の値に100を設定します。
|
||||
|
||||
## 例
|
||||
|
||||
`percentageOfNodesToScore`の値を50%に設定する例は下記のとおりです。
|
||||
|
||||
@@ -35,22 +67,23 @@ algorithmSource:
|
||||
percentageOfNodesToScore: 50
|
||||
```
|
||||
|
||||
## percentageOfNodesToScoreのチューニング
|
||||
|
||||
`percentageOfNodesToScore`は1から100の間の範囲である必要があり、デフォルト値はクラスターのサイズに基づいて計算されます。また、クラスターのサイズの最小値は50ノードとハードコードされています。
|
||||
|
||||
{{< note >}}
|
||||
割り当て可能なノードが50未満のクラスターにおいては、割り当て可能なノードの探索を止めるほどノードが多くないため、スケジューラーは全てのノードをチェックします。
|
||||
割り当て可能なノードが50以下のクラスタでは、スケジューラの検索を早期に停止するのに十分な割り当て可能なノードがないため、スケジューラはすべてのノードをチェックします。
|
||||
|
||||
小規模クラスタでは、`percentageOfNodesToScore`に低い値を設定したとしても、同様の理由で変更による影響は全くないか、ほとんどありません。
|
||||
|
||||
クラスターのノード数が数百以下の場合は、この設定オプションをデフォルト値のままにします。変更してもスケジューラの性能を大幅に改善する可能性はほとんどありません。
|
||||
{{< /note >}}
|
||||
|
||||
**この機能を無効にするためには**、`percentageOfNodesToScore`を100に設定してください。
|
||||
この値を設定する際に考慮するべき重要な注意事項として、割り当て可能ノードのチェック対象のノードが少ないと、一部のノードはPodの割り当てのためにスコアリングされなくなります。結果として、高いスコアをつけられる可能性のあるノードがスコアリングフェーズに渡されることがありません。これにより、Podの配置が理想的なものでなくなります。
|
||||
|
||||
kube-schedulerが頻繁に不適切なPodの配置を行わないよう、`percentageOfNodesToScore`をかなり低い値を設定することは避けるべきです。スケジューラのスループットがアプリケーションにとって致命的で、ノードのスコアリングが重要でない場合を除いて、10%未満に設定することは避けてください。言いかえると、割り当て可能な限り、Podは任意のノード上で稼働させるのが好ましいです。
|
||||
|
||||
### percentageOfNodesToScoreのチューニング
|
||||
|
||||
`percentageOfNodesToScore`は1から100の間の範囲である必要があり、デフォルト値はクラスターのサイズに基づいて計算されます。また、クラスターのサイズの最小値は50ノードとハードコードされています。これは数百のノードを持つようなクラスターにおいてこの値を50より低い値に変更しても、スケジューラーが検出する割り当て可能なノードの数に大きな影響を与えないことを意味します。このオプションは意図的なものです。その理由としては、小規模のクラスターにおいてパフォーマンスを著しく改善する可能性が低いためです。1000ノードを超える大規模なクラスターでこの値を低く設定すると、パフォーマンスが著しく改善される可能性があります。
|
||||
|
||||
この値を設定する際に考慮するべき重要な注意事項として、割り当て可能ノードのチェック対象のノードが少ないと、一部のノードはPodの割り当てのためにスコアリングされなくなります。結果として、高いスコアをつけられる可能性のあるノードがスコアリングフェーズに渡されることがありません。これにより、Podの配置が理想的なものでなくなります。したがって、この値をかなり低い割合に設定すべきではありません。一般的な経験則として、この値を10未満に設定しないことです。スケジューラーのスループットがアプリケーションにとって致命的で、ノードのスコアリングが重要でないときのみ、この値を低く設定するべきです。言いかえると、割り当て可能な限り、Podは任意のノード上で稼働させるのが好ましいです。
|
||||
|
||||
クラスターが数百のノードを持つ場合やそれに満たない場合でも、この設定オプションのデフォルト値を低くするのを推奨しません。デフォルト値を低くしてもスケジューラーのパフォーマンスを大幅に改善することはありません。
|
||||
|
||||
### スケジューラーはどのようにノードを探索するか
|
||||
## スケジューラーはどのようにノードを探索するか {#how-the-scheduler-iterates-over-nodes}
|
||||
|
||||
このセクションでは、この機能の内部の詳細を理解したい人向けになります。
|
||||
|
||||
|
||||
@@ -22,30 +22,30 @@ Nodeにtaintを付与するには[kubectl taint](/docs/reference/generated/kubec
|
||||
例えば、次のコマンドは
|
||||
|
||||
```shell
|
||||
kubectl taint nodes node1 key=value:NoSchedule
|
||||
kubectl taint nodes node1 key1=value1:NoSchedule
|
||||
```
|
||||
|
||||
`node1`にtaintを設定します。このtaintのキーは`key`、値は`value`、taintの効果は`NoSchedule`です。
|
||||
`node1`にtaintを設定します。このtaintのキーは`key1`、値は`value1`、taintの効果は`NoSchedule`です。
|
||||
これは`node1`にはPodに合致するtolerationがなければスケジューリングされないことを意味します。
|
||||
|
||||
上記のコマンドで付与したtaintを外すには、下記のコマンドを使います。
|
||||
```shell
|
||||
kubectl taint nodes node1 key:NoSchedule-
|
||||
kubectl taint nodes node1 key1=value1:NoSchedule-
|
||||
```
|
||||
|
||||
PodのtolerationはPodSpecの中に指定します。下記のtolerationはどちらも、上記の`kubectl taint`コマンドで追加したtaintと合致するため、どちらのtolerationが設定されたPodも`node1`へスケジューリングされることができます。
|
||||
|
||||
```yaml
|
||||
tolerations:
|
||||
- key: "key"
|
||||
- key: "key1"
|
||||
operator: "Equal"
|
||||
value: "value"
|
||||
value: "value1"
|
||||
effect: "NoSchedule"
|
||||
```
|
||||
|
||||
```yaml
|
||||
tolerations:
|
||||
- key: "key"
|
||||
- key: "key1"
|
||||
operator: "Exists"
|
||||
effect: "NoSchedule"
|
||||
```
|
||||
@@ -67,7 +67,7 @@ tolerationがtaintと合致するのは、`key`と`effect`が同一であり、
|
||||
|
||||
空の`key`と演算子`Exists`は全ての`key`、`value`、`effect`と一致するため、すべてのtaintと合致します。
|
||||
|
||||
空の`effect`は`key`が一致する全てのeffectと合致します。
|
||||
空の`effect`は`key1`が一致する全てのeffectと合致します。
|
||||
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
@@ -77,17 +77,17 @@ Kubernetesを保護する為には２つの懸念事項があります。
|
||||
|
||||
### クラスター内のコンポーネント(アプリケーション) {#cluster-applications}
|
||||
|
||||
アプリケーションを対象にした攻撃に応じて、セキュリティの特定側面に焦点をあてたい場合があります。例:他のリソースとの連携で重要なサービス(サービスA)と、リソース枯渇攻撃に対して脆弱な別のワークロード(サービスB)が実行されている場合、サービスBのリソースを制限していないとサービスAが危険にさらされるリスクが高くなります。次の表はセキュリティの懸念事項とKubernetesで実行されるワークロードを保護するための推奨事項を示しています。
|
||||
アプリケーションを対象にした攻撃に応じて、セキュリティの特定側面に焦点をあてたい場合があります。例:他のリソースとの連携で重要なサービス(サービスA)と、リソース枯渇攻撃に対して脆弱な別のワークロード(サービスB)が実行されている場合、サービスBのリソースを制限していないとサービスAが危険にさらされるリスクが高くなります。次の表はセキュリティの懸念事項とKubernetesで実行されるワークロードを保護するための推奨事項を示しています。
|
||||
|
||||
|
||||
ワークロードセキュリティに関する懸念事項 | 推奨事項 |
|
||||
------------------------------ | --------------------- |
|
||||
RBAC認可(Kubernetes APIへのアクセス) | https://kubernetes.io/docs/reference/access-authn-authz/rbac/
|
||||
認証 | https://kubernetes.io/docs/reference/access-authn-authz/controlling-access/ |
|
||||
RBAC認可(Kubernetes APIへのアクセス) | https://kubernetes.io/ja/docs/reference/access-authn-authz/rbac/
|
||||
認証 | https://kubernetes.io/docs/concepts/security/controlling-access/ |
|
||||
アプリケーションのSecret管理(およびetcdへの保存時に暗号化) | https://kubernetes.io/ja/docs/concepts/configuration/secret/ <br> https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/ |
|
||||
PodSecurityPolicy | https://kubernetes.io/docs/concepts/policy/pod-security-policy/ |
|
||||
Quality of Service (およびクラスターリソース管理) | https://kubernetes.io/ja/docs/tasks/configure-pod-container/quality-service-pod/ |
|
||||
NetworkPolicy | https://kubernetes.io/docs/concepts/services-networking/network-policies/ |
|
||||
NetworkPolicy | https://kubernetes.io/ja/docs/concepts/services-networking/network-policies/ |
|
||||
Kubernetes IngressのTLS | https://kubernetes.io/ja/docs/concepts/services-networking/ingress/#tls |
|
||||
|
||||
|
||||
@@ -123,10 +123,10 @@ TLS経由のアクセスのみ | コードがTCP通信を必要とする場合
|
||||
|
||||
関連するKubernetesセキュリティについて学びます。
|
||||
|
||||
* [Podのセキュリティ基準](/docs/concepts/security/pod-security-standards/)
|
||||
* [PodのNetworkPolicy](/docs/concepts/services-networking/network-policies/)
|
||||
* [Podセキュリティの標準](/ja/docs/concepts/security/pod-security-standards/)
|
||||
* [Podのネットワークポリシー]](/ja/docs/concepts/services-networking/network-policies/)
|
||||
* [Kubernetes APIへのアクセスを制御する](/docs/concepts/security/controlling-access)
|
||||
* [クラスターの保護](/docs/tasks/administer-cluster/securing-a-cluster/)
|
||||
* [APIアクセスコントロール](/docs/reference/access-authn-authz/controlling-access/)
|
||||
* コントロールプレーンとの[通信時のデータ暗号化](/docs/tasks/tls/managing-tls-in-a-cluster/)
|
||||
* [保存時のデータ暗号化](/docs/tasks/administer-cluster/encrypt-data/)
|
||||
* [Kubernetes Secret](/ja/docs/concepts/configuration/secret/)
|
||||
|
||||
@@ -122,6 +122,29 @@ spec:
|
||||
A(AAAA)レコードはPodの名前に対して作成されないため、`hostname`はPodのA(AAAA)レコードが作成されるために必須となります。`hostname`を持たないが`subdomain`を持つようなPodは、そのPodのIPアドレスを指し示すHeadless Service(`default-subdomain.my-namespace.svc.cluster.local`)に対するA(AAAA)レコードのみ作成します。
|
||||
{{< /note >}}
|
||||
|
||||
### PodのsetHostnameAsFQDNフィールド
|
||||
|
||||
{{< feature-state for_k8s_version="v1.19" state="alpha" >}}
|
||||
|
||||
**前提条件**: {{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}に対して`SetHostnameAsFQDN`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にする必要があります。
|
||||
|
||||
Podが完全修飾ドメイン名(FQDN)を持つように構成されている場合、そのホスト名は短いホスト名です。
|
||||
例えば、FQDNが`busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example`のPodがある場合、
|
||||
デフォルトではそのPod内の`hostname`コマンドは`busybox-1`を返し、`hostname --fqdn`コマンドはFQDNを返します。
|
||||
|
||||
Podのspecで`setHostnameAsFQDN: true`を設定した場合、そのPodの名前空間に対してkubeletはPodのFQDNをホスト名に書き込みます。
|
||||
この場合、`hostname`と`hostname --fqdn`の両方がPodのFQDNを返します。
|
||||
|
||||
{{< note >}}
|
||||
Linuxでは、カーネルのホスト名のフィールド(`struct utsname`の`nodename`フィールド)は64文字に制限されています。
|
||||
|
||||
Podがこの機能を有効にしていて、そのFQDNが64文字より長い場合、Podは起動に失敗します。
|
||||
Podは`Pending`ステータス(`kubectl`でみられる`ContainerCreating`)のままになり、「Podのホスト名とクラスタードメインからFQDNを作成できなかった」や、「FQDN`long-FQDN`が長すぎる(64文字が最大, 70文字が要求された)」などのエラーイベントが生成されます。
|
||||
|
||||
このシナリオのユーザー体験を向上させる1つの方法は、[admission webhook controller](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)を作成して、ユーザーがDeploymentなどのトップレベルのオブジェクトを作成するときにFQDNのサイズを制御することです。
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
### PodのDNSポリシー
|
||||
|
||||
DNSポリシーはPod毎に設定できます。現在のKubernetesでは次のようなPod固有のDNSポリシーをサポートしています。これらのポリシーはPod Specの`dnsPolicy`フィールドで指定されます。
|
||||
|
||||
@@ -40,6 +40,7 @@ IPv4/IPv6デュアルスタックを有効にするには、クラスターの
|
||||
|
||||
* kube-apiserver:
|
||||
* `--feature-gates="IPv6DualStack=true"`
|
||||
* `--service-cluster-ip-range=<IPv4 CIDR>,<IPv6 CIDR>
|
||||
* kube-controller-manager:
|
||||
* `--feature-gates="IPv6DualStack=true"`
|
||||
* `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>`
|
||||
@@ -89,7 +90,7 @@ IPv6が有効になった外部ロードバランサーをサポートしてい
|
||||
|
||||
## 外向きのトラフィック {#egress-traffic}
|
||||
|
||||
パブリックおよび非パブリックでのルーティングが可能なIPv6アドレスのブロックを利用するためには、クラスターがベースにしている{{< glossary_tooltip text="CNI" term_id="cni" >}}プロバイダーがIPv6の転送を実装している必要があります。もし非パブリックでのルーティングが可能なIPv6アドレスを使用するPodがあり、そのPodをクラスター外の送信先(例:パブリックインターネット)に到達させたい場合、外向きのトラフィックと応答の受信のためにIPマスカレードを設定する必要があります。[ip-masq-agent](https://github.com/kubernetes-incubator/ip-masq-agent)はデュアルスタックに対応しているため、デュアルスタックのクラスター上でのIPマスカレードにはip-masq-agentが利用できます。
|
||||
パブリックおよび非パブリックでのルーティングが可能なIPv6アドレスのブロックを利用するためには、クラスターがベースにしている{{< glossary_tooltip text="CNI" term_id="cni" >}}プロバイダーがIPv6の転送を実装している必要があります。もし非パブリックでのルーティングが可能なIPv6アドレスを使用するPodがあり、そのPodをクラスター外の送信先(例:パブリックインターネット)に到達させたい場合、外向きのトラフィックと応答の受信のためにIPマスカレードを設定する必要があります。[ip-masq-agent](https://github.com/kubernetes-sigs/ip-masq-agent)はデュアルスタックに対応しているため、デュアルスタックのクラスター上でのIPマスカレードにはip-masq-agentが利用できます。
|
||||
|
||||
## 既知の問題
|
||||
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: EndpointSlice
|
||||
content_type: concept
|
||||
weight: 15
|
||||
weight: 35
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
@@ -14,13 +14,19 @@ weight: 15
|
||||
|
||||
## 動機
|
||||
|
||||
Endpoints APIはKubernetes内のネットワークエンドポイントを追跡する単純で直観的な手段を提供してきました。残念ながら、KubernetesクラスターやServiceが大規模になるにつれて、Endpoints APIの限界が明らかになってきました。最も顕著な問題の1つに、ネットワークエンドポイントの数が大きくなったときのスケーリングの問題があります。
|
||||
Endpoint APIはKubernetes内のネットワークエンドポイントを追跡する単純で直観的な手段を提供してきました。
|
||||
残念ながら、Kubernetesクラスターや{{< glossary_tooltip text="Service" term_id="service" >}}が大規模になり、より多くのトラフィックを処理し、より多くのバックエンドPodに送信するようになるにしたがって、Endpoint APIの限界が明らかになってきました。
|
||||
最も顕著な問題の1つに、ネットワークエンドポイントの数が大きくなったときのスケーリングの問題があります。
|
||||
|
||||
Serviceのすべてのネットワークエンドポイントが単一のEndpointsリソースに格納されていたため、リソースのサイズが非常に大きくなる場合がありました。これがKubernetesのコンポーネント(特に、マスターコントロールプレーン)の性能に悪影響を与え、結果として、Endpointsに変更があるたびに、大量のネットワークトラフィックと処理が発生するようになってしまいました。EndpointSliceは、この問題を緩和するとともに、トポロジカルルーティングなどの追加機能のための拡張可能なプラットフォームを提供します。
|
||||
Serviceのすべてのネットワークエンドポイントが単一のEndpointリソースに格納されていたため、リソースのサイズが非常に大きくなる場合がありました。これがKubernetesのコンポーネント(特に、マスターコントロールプレーン)の性能に悪影響を与え、結果として、Endpointに変更があるたびに、大量のネットワークトラフィックと処理が発生するようになってしまいました。EndpointSliceは、この問題を緩和するとともに、トポロジカルルーティングなどの追加機能のための拡張可能なプラットフォームを提供します。
|
||||
|
||||
## EndpointSliceリソース {#endpointslice-resource}
|
||||
|
||||
Kubernetes内ではEndpointSliceにはネットワークエンドポイントの集合へのリファレンスが含まれます。EndpointSliceコントローラーは、{{< glossary_tooltip text="セレクター" term_id="selector" >}}が指定されると、Kubernetes Serviceに対するEndpointSliceを自動的に作成します。これらのEndpointSliceにはServiceセレクターに一致する任意のPodへのリファレクンスが含まれます。EndpointSliceはネットワークエンドポイントをユニークなServiceとPortの組み合わせでグループ化します。EndpointSliceオブジェクトの名前は有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。
|
||||
Kubernetes内ではEndpointSliceにはネットワークエンドポイントの集合へのリファレンスが含まれます。
|
||||
コントロールプレーンは、{{< glossary_tooltip text = "セレクター" term_id = "selector" >}}が指定されているKubernetes ServiceのEndpointSliceを自動的に作成します。
|
||||
これらのEndpointSliceには、Serviceセレクターに一致するすべてのPodへのリファレンスが含まれています。
|
||||
EndpointSliceは、プロトコル、ポート番号、およびサービス名の一意の組み合わせによってネットワークエンドポイントをグループ化します。
|
||||
EndpointSliceオブジェクトの名前は有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。
|
||||
|
||||
一例として、以下に`example`というKubernetes Serviceに対するサンプルのEndpointSliceリソースを示します。
|
||||
|
||||
@@ -47,9 +53,9 @@ endpoints:
|
||||
topology.kubernetes.io/zone: us-west2-a
|
||||
```
|
||||
|
||||
デフォルトではEndpointSliceコントローラーが管理するEndpointSliceには、1つにつき最大で100個のエンドポイントしか所属しません。この規模以下であれば、EndpointSliceはEndpointとServiceが1対1対応になり、性能は変わらないはずです。
|
||||
デフォルトでは、コントロールプレーンはEndpointSliceを作成・管理し、それぞれのエンドポイント数が100以下になるようにします。`--max-endpoints-per-slice`{{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}フラグを設定することで、最大1000個まで設定可能です。
|
||||
|
||||
EndpointSliceは内部トラフィックのルーティング方法に関して、kube-proxyに対する唯一のソース(source of truth)として振る舞うことができます。EndpointSliceを有効にすれば、非常に多数のエンドポイントを持つServiceに対して性能向上が得られるはずです。
|
||||
EndpointSliceは内部トラフィックのルーティング方法に関して、{{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}に対する唯一のソース(source of truth)として振る舞うことができます。EndpointSliceを有効にすれば、非常に多数のエンドポイントを持つServiceに対して性能向上が得られるはずです。
|
||||
|
||||
### アドレスの種類
|
||||
|
||||
@@ -59,9 +65,10 @@ EndpointSliceは次の3種類のアドレスをサポートします。
|
||||
* IPv6
|
||||
* FQDN (Fully Qualified Domain Name、完全修飾ドメイン名)
|
||||
|
||||
### トポロジー
|
||||
### トポロジー {#topology}
|
||||
|
||||
EndpointSliceに属する各エンドポイントは、関連するトポロジーの情報を持つことができます。この情報は、エンドポイントの場所を示すために使われ、対応するNode、ゾーン、リージョンに関する情報が含まれます。値が利用できる場合にはEndpointSliceコントローラーによって次のようなTopologyラベルが設定されます。
|
||||
EndpointSliceに属する各エンドポイントは、関連するトポロジーの情報を持つことができます。この情報は、エンドポイントの場所を示すために使われ、対応するNode、ゾーン、リージョンに関する情報が含まれます。
|
||||
値が利用できる場合には、コントロールプレーンはEndpointSliceコントローラーに次のようなTopologyラベルを設定します。
|
||||
|
||||
* `kubernetes.io/hostname` - このエンドポイントが存在するNodeの名前。
|
||||
* `topology.kubernetes.io/zone` - このエンドポイントが存在するゾーン。
|
||||
@@ -71,25 +78,34 @@ EndpointSliceに属する各エンドポイントは、関連するトポロジ
|
||||
|
||||
### 管理
|
||||
|
||||
EndpointSliceはデフォルトではEndpointSliceコントローラーによって作成・管理されます。EndpointSliceには他にもサービスメッシュの実装などのさまざまなユースケースがあるため、他のエンティティやコントローラーがEndpointSliceの追加の集合を管理する場合もあります。複数のエンティティが互いに干渉せずにEndpointSliceを管理できるようにするために、EndpointSliceを管理しているエンティティを表す`endpointslice.kubernetes.io/managed-by`ラベルが使用されます。EndpointSliceコントローラーの場合、管理対象のすべてのEndpointSliceに対して、このラベルの値として`endpointslice-controller.k8s.io`を設定します。EndpointSliceを管理するその他のエンティティも同様に、このラベルにユニークな値を設定する必要があります。
|
||||
ほとんどの場合、コントロールプレーン（具体的には、EndpointSlice {{< glossary_tooltip text = "コントローラー" term_id = "controller" >}}）は、EndpointSliceオブジェクトを作成および管理します。EndpointSliceには、サービスメッシュの実装など、他のさまざまなユースケースがあり、他のエンティティまたはコントローラーがEndpointSliceの追加セットを管理する可能性があります。
|
||||
|
||||
複数のエンティティが互いに干渉することなくEndpointSliceを管理できるようにするために、KubernetesはEndpointSliceを管理するエンティティを示す`endpointslice.kubernetes.io/managed-by`という{{< glossary_tooltip term_id="label" text="ラベル" >}}を定義します。
|
||||
EndpointSliceを管理するその他のエンティティも同様に、このラベルにユニークな値を設定する必要があります。
|
||||
|
||||
### 所有権
|
||||
|
||||
ほとんどのユースケースでは、EndpointSliceは対象のエンドポイントが追跡しているServiceによって所有されます。これは、各EndpointSlice上のownerリファレンスと`kubernetes.io/service-name`ラベルによって示されます。これにより、Serviceに属するすべてのEndpointSliceを簡単に検索できるようになっています。
|
||||
ほとんどのユースケースでは、EndpointSliceはエンドポイントスライスオブジェクトがエンドポイントを追跡するServiceによって所有されます。
|
||||
これは、各EndpointSlice上のownerリファレンスと`kubernetes.io/service-name`ラベルによって示されます。これにより、Serviceに属するすべてのEndpointSliceを簡単に検索できるようになっています。
|
||||
|
||||
## EndpointSliceコントローラー
|
||||
### EndpointSliceのミラーリング
|
||||
|
||||
EndpointSliceコントローラーは対応するEndpointSliceが最新の状態であることを保証するために、ServiceとPodを監視します。このコントローラーはセレクターが指定した各Serviceに対応するEndpointSliceを管理します。EndpointSliceはServiceセレクターに一致するPodのIPを表します。
|
||||
場合によっては、アプリケーションはカスタムEndpointリソースを作成します。これらのアプリケーションがEndpointリソースとEndpointSliceリソースの両方に同時に書き込む必要がないようにするために、クラスターのコントロールプレーンは、ほとんどのEndpointリソースを対応するEndpointSliceにミラーリングします。
|
||||
|
||||
### EndpointSliceのサイズ
|
||||
コントロールプレーンは、次の場合を除いて、Endpointリソースをミラーリングします。
|
||||
|
||||
デフォルトでは、それぞれのEndpointSliceのサイズの上限は100個のEndpointsに制限されています。この制限は{{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}に`--max-endpoints-per-slice`フラグを使用することで、最大で1000まで設定できます。
|
||||
* Endpointリソースの`endpointslice.kubernetes.io/skip-mirror`ラベルが`true`に設定されています。
|
||||
* Endpointリソースが`control-plane.alpha.kubernetes.io/leader`アノテーションを持っています。
|
||||
* 対応するServiceリソースが存在しません。
|
||||
* 対応するServiceリソースには、nil以外のセレクターがあります。
|
||||
|
||||
個々のEndpointリソースは、複数のEndpointSliceに変換される場合があります。これは、Endpointリソースに複数のサブセットがある場合、または複数のIPファミリ（IPv4およびIPv6）を持つエンドポイントが含まれている場合に発生します。サブセットごとに最大1000個のアドレスがEndpointSliceにミラーリングされます。
|
||||
|
||||
### EndpointSliceの分散
|
||||
|
||||
それぞれのEndpointSliceにはポートの集合があり、リソース内のすべてのエンドポイントに適用されます。サービスが名前付きポートを使用した場合、Podが同じ名前のポートに対して、結果的に異なるターゲットポート番号が使用されて、異なるEndpointSliceが必要になる場合があります。これはサービスの部分集合がEndpointsにグループ化される場合と同様です。
|
||||
それぞれのEndpointSliceにはポートの集合があり、リソース内のすべてのエンドポイントに適用されます。サービスが名前付きポートを使用した場合、Podが同じ名前のポートに対して、結果的に異なるターゲットポート番号が使用されて、異なるEndpointSliceが必要になる場合があります。これはサービスの部分集合がEndpointにグループ化される場合と同様です。
|
||||
|
||||
コントローラーはEndpointSliceをできる限り充填しようとしますが、積極的にリバランスを行うことはありません。コントローラーのロジックは極めて単純で、以下のようになっています。
|
||||
コントロールプレーンはEndpointSliceをできる限り充填しようとしますが、積極的にリバランスを行うことはありません。コントローラーのロジックは極めて単純で、以下のようになっています。
|
||||
|
||||
1. 既存のEndpointSliceをイテレートし、もう必要のないエンドポイントを削除し、変更があったエンドポイントを更新する。
|
||||
2. 前のステップで変更されたEndpointSliceをイテレートし、追加する必要がある新しいエンドポイントで充填する。
|
||||
@@ -101,8 +117,16 @@ EndpointSliceコントローラーは対応するEndpointSliceが最新の状態
|
||||
|
||||
現実的には、こうしたあまり理想的ではない分散が発生することは稀です。EndpointSliceコントローラーによって処理されるほとんどの変更は、既存のEndpointSliceに収まるほど十分小さくなるためです。そうでなかったとしても、すぐに新しいEndpointSliceが必要になる可能性が高いです。また、Deploymentのローリングアップデートが行われれば、自然な再充填が行われます。Podとそれに対応するエンドポイントがすべて置換されるためです。
|
||||
|
||||
### エンドポイントの重複
|
||||
|
||||
EndpointSliceの変更の性質上、エンドポイントは同時に複数のEndpointSliceで表される場合があります。
|
||||
これは、さまざまなEndpointSliceオブジェクトへの変更が、さまざまな時間にKubernetesクライアントのウォッチ/キャッシュに到達する可能性があるために自然に発生します。
|
||||
EndpointSliceを使用する実装では、エンドポイントを複数のスライスに表示できる必要があります。
|
||||
エンドポイント重複排除を実行する方法のリファレンス実装は、`kube-proxy`の`EndpointSliceCache`実装にあります。
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [EndpointSliceを有効にする](/docs/tasks/administer-cluster/enabling-endpointslices)
|
||||
* [EndpointSliceの有効化](/docs/tasks/administer-cluster/enabling-endpointslices)について学ぶ
|
||||
* [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)を読む
|
||||
|
||||
|
||||
@@ -11,47 +11,42 @@ Ingressリソースが動作するためには、クラスターでIngressコン
|
||||
|
||||
`kube-controller-manager`バイナリの一部として実行される他のタイプのコントローラーとは異なり、Ingressコントローラーはクラスターで自動的に起動されません。このページを使用して、クラスターに最適なIngressコントローラーの実装を選択してください。
|
||||
|
||||
プロジェクトとしてのKubernetesは現在、[GCE](https://git.k8s.io/ingress-gce/README.md)と[nginx](https://git.k8s.io/ingress-nginx/README.md)のコントローラーをサポートし、保守しています。
|
||||
|
||||
|
||||
プロジェクトとしてのKubernetesは現在、[AWS](https://github.com/kubernetes-sigs/aws-load-balancer-controller#readme)、[GCE](https://git.k8s.io/ingress-gce/README.md#readme)、および[nginx](https://git.k8s.io/ingress-nginx/README.md#readme)のIngressコントローラーをサポート・保守しています。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 追加のコントローラー {#additional-controllers}
|
||||
|
||||
* [AKS Application Gateway Ingress Controller](https://github.com/Azure/application-gateway-kubernetes-ingress)は[Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview)を利用して[AKSクラスター](https://docs.microsoft.com/azure/aks/kubernetes-walkthrough-portal)でIngressを実行可能にするIngressコントローラーです。
|
||||
* [Ambassador](https://www.getambassador.io/) API Gatewayは[Envoy](https://www.envoyproxy.io)ベースのIngressコントローラーで、[Datawire](https://www.datawire.io/)による[コミュニティ版](https://www.getambassador.io/docs)または[商用版](https://www.getambassador.io/pro/)のサポートがあります。
|
||||
* [AppsCode Inc.](https://appscode.com)では、最も広く使用されている[HAProxy](https://www.haproxy.org/)ベースのIngressコントローラーである[Voyager](https://appscode.com/products/voyager)のサポートと保守を提供しています。
|
||||
* [AWS ALB Ingress Controller](https://github.com/kubernetes-sigs/aws-alb-ingress-controller)は[AWS Application Load Balancer](https://aws.amazon.com/elasticloadbalancing/)を使用したIngressを有効にします。
|
||||
* [Contour](https://projectcontour.io/)は、VMwareが提供し、サポートしている[Envoy](https://www.envoyproxy.io/)ベースのIngressコントローラーです。
|
||||
* Citrixは、[ベアメタル](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal)と[クラウド](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment)のデプロイ用に、ハードウェア(MPX）、仮想化(VPX)、[フリーコンテナ化(CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html)用の[Ingressコントローラー](https://github.com/citrix/citrix-k8s-ingress-controller)を提供しています。
|
||||
* F5 Networksは[F5 BIG-IP Container Ingress Services for Kubernetes](https://clouddocs.f5.com/containers/latest/userguide/kubernetes/)の[サポートと保守](https://support.f5.com/csp/article/K86859508)を提供しています。
|
||||
* [Gloo](https://gloo.solo.io)は[Envoy](https://www.envoyproxy.io)をベースにしたオープンソースのIngressコントローラーで、[solo.io](https://www.solo.io)からのエンタープライズサポートでAPI Gateway機能を提供しています。
|
||||
* [HAProxy Ingress](https://haproxy-ingress.github.io)は、HAProxy用の高度にカスタマイズ可能なコミュニティ主導のIngressコントローラーです。
|
||||
* [HAProxy Technologies](https://www.haproxy.com/)は[HAProxy Ingress Controller for Kubernetes](https://github.com/haproxytech/kubernetes-ingress)のサポートと保守を提供しています。[公式ドキュメント](https://www.haproxy.com/documentation/hapee/1-9r1/traffic-management/kubernetes-ingress-controller/)を参照してください。
|
||||
* [Istio](https://istio.io/)ベースのIngressコントローラー[Control Ingress Traffic](https://istio.io/docs/tasks/traffic-management/ingress/)。
|
||||
* [Kong](https://konghq.com/)は、[Kong Ingress Controller for Kubernetes](https://github.com/Kong/kubernetes-ingress-controller)の[コミュニティ版](https://discuss.konghq.com/c/kubernetes)と[商用版]](https://konghq.com/kong-enterprise/)のサポートと保守を提供しています。
|
||||
* [NGINX, Inc.](https://www.nginx.com/)は[NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)のサポートと保守を提供しています。
|
||||
{{% thirdparty-content %}}
|
||||
|
||||
* [AKS Application Gateway Ingress Controller](https://github.com/Azure/application-gateway-kubernetes-ingress)は、[Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview)を設定するIngressコントローラーです。
|
||||
* [Ambassador](https://www.getambassador.io/) API Gatewayは[Envoy](https://www.envoyproxy.io)ベースのIngressコントローラーです。
|
||||
* [Citrix ingress controller](https://github.com/citrix/citrix-k8s-ingress-controller#readme)は、Citrix Application Delivery Controllerで動作します。
|
||||
* [Contour](https://projectcontour.io/)は、[Envoy](https://www.envoyproxy.io/)ベースのIngressコントローラーです。
|
||||
* F5 BIG-IPの[Container Ingress Services for Kubernetes](https://clouddocs.f5.com/containers/latest/userguide/kubernetes/)はF5 BIG-IPの仮想サーバー上でIngressの設定を可能にします。
|
||||
* [Gloo](https://gloo.solo.io)は[Envoy](https://www.envoyproxy.io)をベースにしたオープンソースのIngressコントローラーで、API Gateway機能を提供しています。
|
||||
* [HAProxy Ingress](https://haproxy-ingress.github.io)は、[HAProxy](http://www.haproxy.org/#desc)用のIngressコントローラーです。
|
||||
* [HAProxy Ingress Controller for Kubernetes](https://github.com/haproxytech/kubernetes-ingress)も、[HAProxy](http://www.haproxy.org/#desc)用のIngressコントローラーです。
|
||||
* [Istio Ingress](https://istio.io/latest/docs/tasks/traffic-management/ingress/kubernetes-ingress/)は、[Istio](https://istio.io/)ベースのIngressコントローラーです。
|
||||
* [Kong Ingress Controller for Kubernetes](https://github.com/Kong/kubernetes-ingress-controller#readme)は、[Kong Gateway](https://konghq.com/kong/)向けのIngressコントローラーです。
|
||||
* [NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)は、[NGINX](https://www.nginx.com/resources/glossary/nginx/)ウェブサーバーで(プロキシとして)動作します。
|
||||
* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/)は、カスタムプロキシーを構築するためのライブラリーとして設計された、Kubernetes Ingressなどのユースケースを含む、サービス構成用のHTTPルーターとリバースプロキシーです。
|
||||
* [Traefik](https://github.com/containous/traefik)はフル機能([Let's Encrypt](https://letsencrypt.org), secrets, http2, websocket)のIngressコントローラーで、[Containous](https://containo.us/services)による商用サポートもあります。
|
||||
* [Traefik Kubernetes Ingress provider](https://doc.traefik.io/traefik/providers/kubernetes-ingress/)は、[Traefik](https://github.com/containous/traefik) proxy向けのIngressコントローラーです。
|
||||
* [Voyager](https://appscode.com/products/voyager)は、[HAProxy](http://www.haproxy.org/#desc)向けのIngressコントローラーです。
|
||||
|
||||
## 複数のIngressコントローラーの使用 {#using-multiple-ingress-controllers}
|
||||
|
||||
[Ingressコントローラーは、好きな数だけ](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers))クラスターにデプロイすることができます。Ingressを作成する際には、クラスター内に複数のIngressコントローラーが存在する場合にどのIngressコントローラーを使用するかを示すために適切な[`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster)のアノテーションを指定します。
|
||||
[Ingressコントローラーは、好きな数だけ](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers)クラスターにデプロイすることができます。Ingressを作成する際には、クラスター内に複数のIngressコントローラーが存在する場合にどのIngressコントローラーを使用するかを示すために適切な[`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster)のアノテーションを指定する必要があります。
|
||||
|
||||
クラスを定義しない場合、クラウドプロバイダーはデフォルトのIngressコントローラーを使用する場合があります。
|
||||
|
||||
理想的には、すべてのIngressコントローラーはこの仕様を満たすべきですが、いくつかのIngressコントローラーはわずかに異なる動作をします。
|
||||
|
||||
|
||||
{{< note >}}
|
||||
Ingressコントローラーのドキュメントを確認して、選択する際の注意点を理解してください。
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* [Ingress](/ja/docs/concepts/services-networking/ingress/)の詳細
|
||||
* [Set up Ingress on Minikube with the NGINX Controller](/docs/tasks/access-application-cluster/ingress-minikube)
|
||||
* [Ingress](/ja/docs/concepts/services-networking/ingress/)についてさらに学ぶ。
|
||||
* [Minikube上でNGINX Ingressコントローラーを使用してIngressをセットアップする](/ja/docs/tasks/access-application-cluster/ingress-minikube)。
|
||||
|
||||
@@ -5,7 +5,7 @@ weight: 40
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
{{< feature-state for_k8s_version="v1.1" state="beta" >}}
|
||||
{{< feature-state for_k8s_version="v1.19" state="stable" >}}
|
||||
{{< glossary_definition term_id="ingress" length="all" >}}
|
||||
|
||||
|
||||
@@ -23,17 +23,28 @@ weight: 40
|
||||
|
||||
## Ingressとは何か
|
||||
|
||||
[Ingress](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)はクラスター外からクラスター内{{< link text="Service" url="/ja/docs/concepts/services-networking/service/" >}}へのHTTPとHTTPSのルートを公開します。トラフィックのルーティングはIngressリソース上で定義されるルールによって制御されます。
|
||||
[Ingress](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1-networking-k8s-io)はクラスター外からクラスター内{{< link text="Service" url="/ja/docs/concepts/services-networking/service/" >}}へのHTTPとHTTPSのルートを公開します。トラフィックのルーティングはIngressリソース上で定義されるルールによって制御されます。
|
||||
|
||||
```none
|
||||
internet
|
||||
|
|
||||
[ Ingress ]
|
||||
--|-----|--
|
||||
[ Services ]
|
||||
```
|
||||
全てのトラフィックを単一のServiceに送る単純なIngressの例を示します。
|
||||
|
||||
IngressはServiceに対して、外部疎通できるURL、負荷分散トラフィック、SSL/TLS終端の機能や、名前ベースの仮想ホスティングを提供するように設定できます。[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)は通常はロードバランサーを使用してIngressの機能を実現しますが、エッジルーターや、追加のフロントエンドを構成してトラフィックの処理を支援することもできます。
|
||||
{{< mermaid >}}
|
||||
graph LR;
|
||||
client([クライアント])-. Ingress管理下の <br> ロードバランサー .->ingress[Ingress];
|
||||
ingress-->|ルーティングルール|service[Service];
|
||||
subgraph cluster[クラスター]
|
||||
ingress;
|
||||
service-->pod1[Pod];
|
||||
service-->pod2[Pod];
|
||||
end
|
||||
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
|
||||
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
|
||||
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
|
||||
class ingress,service,pod1,pod2 k8s;
|
||||
class client plain;
|
||||
class cluster cluster;
|
||||
{{</ mermaid >}}
|
||||
|
||||
IngressはServiceに対して、外部疎通できるURL、負荷分散トラフィック、SSL/TLS終端の機能や、名前ベースの仮想ホスティングを提供するように設定できます。[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers/)は通常はロードバランサーを使用してIngressの機能を実現しますが、エッジルーターや、追加のフロントエンドを構成してトラフィックの処理を支援することもできます。
|
||||
|
||||
Ingressは任意のポートやプロトコルを公開しません。HTTPやHTTPS以外のServiceをインターネットに公開する場合、[Service.Type=NodePort](/ja/docs/concepts/services-networking/service/#nodeport)や[Service.Type=LoadBalancer](/ja/docs/concepts/services-networking/service/#loadbalancer)のServiceタイプを一般的には使用します。
|
||||
|
||||
@@ -53,23 +64,7 @@ Ingressコントローラーのドキュメントを確認して、選択する
|
||||
|
||||
Ingressリソースの最小構成の例は以下のとおりです。
|
||||
|
||||
```yaml
|
||||
apiVersion: networking.k8s.io/v1beta1
|
||||
kind: Ingress
|
||||
metadata:
|
||||
name: test-ingress
|
||||
annotations:
|
||||
nginx.ingress.kubernetes.io/rewrite-target: /
|
||||
spec:
|
||||
rules:
|
||||
- http:
|
||||
paths:
|
||||
- path: /testpath
|
||||
pathType: Prefix
|
||||
backend:
|
||||
serviceName: test
|
||||
servicePort: 80
|
||||
```
|
||||
{{< codenew file="service/networking/minimal-ingress.yaml" >}}
|
||||
|
||||
他の全てのKubernetesリソースと同様に、Ingressには`apiVersion`、`kind`や`metadata`フィールドが必要です。Ingressオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。設定ファイルに関する一般的な情報は、[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナの設定](/docs/tasks/configure-pod-container/configure-pod-configmap/)、[リソースの管理](/docs/concepts/cluster-administration/manage-deployment/)を参照してください。Ingressでは、Ingressコントローラーに依存しているいくつかのオプションの設定をするためにアノテーションを一般的に使用します。例としては、[rewrite-targetアノテーション](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)などがあります。[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)の種類が異なれば、サポートするアノテーションも異なります。サポートされているアノテーションについて学ぶためには、使用するIngressコントローラーのドキュメントを確認してください。
|
||||
|
||||
@@ -80,52 +75,106 @@ Ingress [Spec](https://git.k8s.io/community/contributors/devel/sig-architecture/
|
||||
各HTTPルールは以下の情報を含みます。
|
||||
|
||||
* オプションで設定可能なホスト名。上記のリソースの例では、ホスト名が指定されていないと、そのルールは指定されたIPアドレスを経由する全てのインバウンドHTTPトラフィックに適用されます。ホスト名が指定されていると(例: foo.bar.com)、そのルールはホストに対して適用されます。
|
||||
* パスのリスト(例: `/testpath`)。各パスには`serviceName`と`servicePort`で定義されるバックエンドが関連づけられます。ロードバランサーがトラフィックを関連づけられたServiceに転送するために、外部からくるリクエストのホスト名とパスが条件と一致させる必要があります。
|
||||
* [Serviceドキュメント](/ja/docs/concepts/services-networking/service/)に書かれているように、バックエンドはServiceとポート名の組み合わせとなります。Ingressで設定されたホスト名とパスのルールに一致するHTTP(とHTTPS)のリクエストは、リスト内のバックエンドに対して送信されます。
|
||||
* パスのリスト(例: `/testpath`)。各パスには`service.name`と`service.port.name`または`service.port.number`で定義されるバックエンドが関連づけられます。ロードバランサーがトラフィックを関連づけられたServiceに転送するために、外部からくるリクエストのホスト名とパスが条件と一致させる必要があります。
|
||||
* バックエンドは[Serviceドキュメント](/ja/docs/concepts/services-networking/service/)に書かれているようなService名とポート名の組み合わせ、または{{< glossary_tooltip term_id="CustomResourceDefinition" text="CRD" >}}による[カスタムリソースバックエンド](#resource-backend)です。Ingressで設定されたホスト名とパスのルールに一致するHTTP(とHTTPS)のリクエストは、リスト内のバックエンドに対して送信されます。
|
||||
|
||||
Ingressコントローラーでは、デフォルトのバックエンドが設定されていることがあります。これはSpec内で指定されているパスに一致しないようなリクエストのためのバックエンドです。
|
||||
Ingressコントローラーでは、`defaultBackend`が設定されていることがあります。これはSpec内で指定されているパスに一致しないようなリクエストのためのバックエンドです。
|
||||
|
||||
### デフォルトのバックエンド
|
||||
### デフォルトのバックエンド {#default-backend}
|
||||
|
||||
ルールが設定されていないIngressは、全てのトラフィックをデフォルトのバックエンドに転送します。このデフォルトのバックエンドは、[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)のオプション設定であり、Ingressリソースでは指定されていません。
|
||||
ルールが設定されていないIngressは、全てのトラフィックをデフォルトのバックエンドに転送します。`defaultBackend`は、[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)のオプション設定であり、Ingressリソースでは指定されていません。
|
||||
|
||||
IngressオブジェクトでHTTPリクエストが1つもホスト名とパスの条件に一致しない時、そのトラフィックはデフォルトのバックエンドに転送されます。
|
||||
HTTPリクエストがIngressオブジェクトのホスト名とパスの条件に1つも一致しない時、そのトラフィックはデフォルトのバックエンドに転送されます。
|
||||
|
||||
### リソースバックエンド {#resource-backend}
|
||||
|
||||
`Resource`バックエンドはIngressオブジェクトと同じnamespaceにある他のKubernetesリソースを指すObjectRefです。
|
||||
`Resource`はServiceの設定とは排他であるため、両方を指定するとバリデーションに失敗します。
|
||||
`Resource`バックエンドのよくある用途は、静的なアセットが入ったオブジェクトストレージを設定することです。
|
||||
|
||||
{{< codenew file="service/networking/ingress-resource-backend.yaml" >}}
|
||||
|
||||
上記のIngressを作成した後に、次のコマンドで参照することができます。
|
||||
|
||||
```bash
|
||||
kubectl describe ingress ingress-resource-backend
|
||||
```
|
||||
|
||||
```
|
||||
Name: ingress-resource-backend
|
||||
Namespace: default
|
||||
Address:
|
||||
Default backend: APIGroup: k8s.example.com, Kind: StorageBucket, Name: static-assets
|
||||
Rules:
|
||||
Host Path Backends
|
||||
---- ---- --------
|
||||
*
|
||||
/icons APIGroup: k8s.example.com, Kind: StorageBucket, Name: icon-assets
|
||||
Annotations: <none>
|
||||
Events: <none>
|
||||
```
|
||||
|
||||
### パスのタイプ
|
||||
|
||||
Ingressのそれぞれのパスは対応するパスのタイプを持ちます。サポートされているパスのタイプは3種類あります。
|
||||
Ingressのそれぞれのパスは対応するパスのタイプを持ちます。`pathType`が明示的に指定されていないパスはバリデーションに通らないでしょう。サポートされているパスのタイプは3種類あります。
|
||||
|
||||
* _`ImplementationSpecific`_ (デフォルト): このパスタイプでは、パスとの一致はIngressClassに依存します。Ingressの実装はこれを独立した`pathType`と扱うことも、`Prefix`や`Exact`と同一のパスタイプと扱うこともできます。
|
||||
* `ImplementationSpecific`（実装に特有）: このパスタイプでは、パスとの一致はIngressClassに依存します。Ingressの実装はこれを独立した`pathType`と扱うことも、`Prefix`や`Exact`と同一のパスタイプと扱うこともできます。
|
||||
|
||||
* _`Exact`_: 大文字小文字を区別して完全に一致するURLパスと一致します。
|
||||
* `Exact`: 大文字小文字を区別して完全に一致するURLパスと一致します。
|
||||
|
||||
* _`Prefix`_: `/`で分割されたURLと前方一致で一致します。大文字小文字は区別され、パスの要素対要素で比較されます。パス要素は`/`で分割されたパスの中のラベルのリストを参照します。リクエストがパス _p_ に一致するのは、Ingressのパス _p_ がリクエストパス _p_ と要素単位で前方一致する場合です。
|
||||
* `Prefix`: `/`で分割されたURLと前方一致で一致します。大文字小文字は区別され、パスの要素対要素で比較されます。パス要素は`/`で分割されたパスの中のラベルのリストを参照します。リクエストがパス _p_ に一致するのは、Ingressのパス _p_ がリクエストパス _p_ と要素単位で前方一致する場合です。
|
||||
|
||||
{{< note >}}
|
||||
パスの最後の要素がリクエストパスの最後の要素の部分文字列である場合、これは一致しません（例えば、`/foo/bar`は`/foo/bar/baz`と一致しますが、`/foo/barbaz`とは一致しません）。
|
||||
{{< /note >}}
|
||||
|
||||
### 例
|
||||
|
||||
| タイプ | パス | リクエストパス | 一致するか |
|
||||
|--------|---------------------------------|-------------------------------|--------------------------------------|
|
||||
| Prefix | `/` | （全てのパス） | はい |
|
||||
| Exact | `/foo` | `/foo` | はい |
|
||||
| Exact | `/foo` | `/bar` | いいえ |
|
||||
| Exact | `/foo` | `/foo/` | いいえ |
|
||||
| Exact | `/foo/` | `/foo` | いいえ |
|
||||
| Prefix | `/foo` | `/foo`, `/foo/` | はい |
|
||||
| Prefix | `/foo/` | `/foo`, `/foo/` | はい |
|
||||
| Prefix | `/aaa/bb` | `/aaa/bbb` | いいえ |
|
||||
| Prefix | `/aaa/bbb` | `/aaa/bbb` | はい |
|
||||
| Prefix | `/aaa/bbb/` | `/aaa/bbb` | はい、末尾のスラッシュは無視 |
|
||||
| Prefix | `/aaa/bbb` | `/aaa/bbb/` | はい、末尾のスラッシュと一致 |
|
||||
| Prefix | `/aaa/bbb` | `/aaa/bbb/ccc` | はい、パスの一部と一致 |
|
||||
| Prefix | `/aaa/bbb` | `/aaa/bbbxyz` | いいえ、接頭辞と一致しない |
|
||||
| Prefix | `/`, `/aaa` | `/aaa/ccc` | はい、接頭辞`/aaa`と一致 |
|
||||
| Prefix | `/`, `/aaa`, `/aaa/bbb` | `/aaa/bbb` | はい、接頭辞`/aaa/bbb`と一致 |
|
||||
| Prefix | `/`, `/aaa`, `/aaa/bbb` | `/ccc` | はい、接頭辞`/`と一致 |
|
||||
| Prefix | `/aaa` | `/ccc` | いいえ、デフォルトバックエンドを使用 |
|
||||
| Mixed | `/foo` (Prefix), `/foo` (Exact) | `/foo` | はい、Exactが優先 |
|
||||
|
||||
#### 複数のパスとの一致
|
||||
|
||||
リクエストがIngressの複数のパスと一致することがあります。そのような場合は、最も長くパスが一致したものが優先されます。2つのパスが同等に一致した場合は、完全一致が前方一致よりも優先されます。
|
||||
|
||||
## ホスト名のワイルドカード
|
||||
|
||||
ホストは正確に一致する（例えば`foo.bar.com`）かワイルドカード（例えば`*.foo.com`）とすることができます。
|
||||
正確な一致ではHTTPヘッダーの`host`が`host`フィールドと一致することが必要です。
|
||||
ワイルドカードによる一致では、HTTPヘッダーの`host`がワイルドカードルールに沿って後方一致することが必要です。
|
||||
|
||||
| Host | Hostヘッダー | 一致するか |
|
||||
| ----------- |-------------------| ------------------------------------------------------------|
|
||||
| `*.foo.com` | `bar.foo.com` | 共通の接尾辞により一致 |
|
||||
| `*.foo.com` | `baz.bar.foo.com` | 一致しない。ワイルドカードは単一のDNSラベルのみを対象とする |
|
||||
| `*.foo.com` | `foo.com` | 一致しない。ワイルドカードは単一のDNSラベルのみを対象とする |
|
||||
|
||||
{{< codenew file="service/networking/ingress-wildcard-host.yaml" >}}
|
||||
|
||||
## Ingress Class
|
||||
|
||||
Ingressは異なったコントローラーで実装されうるため、しばしば異なった設定を必要とします。
|
||||
IngressClassリソースは、この種別のIngressを実装すべきコントローラーの名称を含む追加の設定情報を含みます。各IngressはIngressClassリソースへの参照によって種別を指定すべきです。
|
||||
|
||||
```yaml
|
||||
apiVersion: networking.k8s.io/v1beta1
|
||||
kind: IngressClass
|
||||
metadata:
|
||||
name: external-lb
|
||||
spec:
|
||||
controller: example.com/ingress-controller
|
||||
parameters:
|
||||
apiGroup: k8s.example.com/v1alpha
|
||||
kind: IngressParameters
|
||||
name: external-lb
|
||||
```
|
||||
{{< codenew file="service/networking/external-lb.yaml" >}}
|
||||
|
||||
IngressClassリソースは任意のパラメータフィールドを含むことができます。これは追加の設定情報を参照するために利用することができます。
|
||||
|
||||
@@ -137,7 +186,7 @@ Kubernetes 1.18でIngressClassリソースと`ingressClassName`フィールド
|
||||
Ingressの新しい`ingressClassName`フィールドはこのアノテーションを置き換えるものですが、完全に等価ではありません。
|
||||
アノテーションは一般にIngressを実装すべきIngressのコントローラーの名称を示していましたが、フィールドはIngressClassリソースを示しており、これはIngressのコントローラーの名称を含む追加のIngressの設定情報を持ちます。
|
||||
|
||||
### デフォルトのIngress Class
|
||||
### デフォルトのIngressClass {#default-ingress-class}
|
||||
|
||||
特定のIngressClassをクラスターでのデフォルトとすることができます。
|
||||
IngressClassリソースの`ingressclass.kubernetes.io/is-default-class`アノテーションを`true`に設定すると、`ingressClassName`フィールドが指定されないIngressにはこのデフォルトIngressClassが割り当てられるようになります。
|
||||
@@ -148,20 +197,21 @@ IngressClassリソースの`ingressclass.kubernetes.io/is-default-class`アノ
|
||||
|
||||
## Ingressのタイプ
|
||||
|
||||
### 単一ServiceのIngress
|
||||
### 単一ServiceのIngress {#single-service-ingress}
|
||||
|
||||
Kubernetesには、単一のServiceを公開できるようにする既存の概念があります（[Ingressの代替案](#alternatives)を参照してください）。ルールなしで*デフォルトのバックエンド* を指定することにより、Ingressでこれを実現することもできます。
|
||||
|
||||
{{< codenew file="service/networking/ingress.yaml" >}}
|
||||
{{< codenew file="service/networking/test-ingress.yaml" >}}
|
||||
|
||||
`kubectl apply -f`を実行してIngressを作成すると、その作成したIngressの状態を確認することができます。
|
||||
|
||||
```shell
|
||||
```bash
|
||||
kubectl get ingress test-ingress
|
||||
```
|
||||
|
||||
```
|
||||
NAME HOSTS ADDRESS PORTS AGE
|
||||
test-ingress * 203.0.113.123 80 59s
|
||||
NAME CLASS HOSTS ADDRESS PORTS AGE
|
||||
test-ingress external-lb * 203.0.113.123 80 59s
|
||||
```
|
||||
|
||||
`203.0.113.123`はIngressコントローラーによって割り当てられたIPで、作成したIngressを利用するためのものです。
|
||||
@@ -174,34 +224,29 @@ IngressコントローラーとロードバランサーがIPアドレス割り
|
||||
|
||||
ファンアウト設定では単一のIPアドレスのトラフィックを、リクエストされたHTTP URIに基づいて1つ以上のServiceに転送します。Ingressによってロードバランサーの数を少なくすることができます。例えば、以下のように設定します。
|
||||
|
||||
```none
|
||||
foo.bar.com -> 178.91.123.132 -> / foo service1:4200
|
||||
/ bar service2:8080
|
||||
```
|
||||
{{< mermaid >}}
|
||||
graph LR;
|
||||
client([クライアント])-. Ingress管理下の <br> ロードバランサー .->ingress[Ingress, 178.91.123.132];
|
||||
ingress-->|/foo|service1[Service service1:4200];
|
||||
ingress-->|/bar|service2[Service service2:8080];
|
||||
subgraph cluster[クラスター]
|
||||
ingress;
|
||||
service1-->pod1[Pod];
|
||||
service1-->pod2[Pod];
|
||||
service2-->pod3[Pod];
|
||||
service2-->pod4[Pod];
|
||||
end
|
||||
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
|
||||
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
|
||||
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
|
||||
class ingress,service1,service2,pod1,pod2,pod3,pod4 k8s;
|
||||
class client plain;
|
||||
class cluster cluster;
|
||||
{{</ mermaid >}}
|
||||
|
||||
Ingressを以下のように設定します。
|
||||
|
||||
```yaml
|
||||
apiVersion: networking.k8s.io/v1beta1
|
||||
kind: Ingress
|
||||
metadata:
|
||||
name: simple-fanout-example
|
||||
annotations:
|
||||
nginx.ingress.kubernetes.io/rewrite-target: /
|
||||
spec:
|
||||
rules:
|
||||
- host: foo.bar.com
|
||||
http:
|
||||
paths:
|
||||
- path: /foo
|
||||
backend:
|
||||
serviceName: service1
|
||||
servicePort: 4200
|
||||
- path: /bar
|
||||
backend:
|
||||
serviceName: service2
|
||||
servicePort: 8080
|
||||
```
|
||||
{{< codenew file="service/networking/simple-fanout-example.yaml" >}}
|
||||
|
||||
Ingressを`kubectl apply -f`によって作成したとき:
|
||||
|
||||
@@ -220,8 +265,6 @@ Rules:
|
||||
foo.bar.com
|
||||
/foo service1:4200 (10.8.0.90:4200)
|
||||
/bar service2:8080 (10.8.0.91:8080)
|
||||
Annotations:
|
||||
nginx.ingress.kubernetes.io/rewrite-target: /
|
||||
Events:
|
||||
Type Reason Age From Message
|
||||
---- ------ ---- ---- -------
|
||||
@@ -232,75 +275,46 @@ IngressコントローラーはService(`service1`、`service2`)が存在する
|
||||
構築が完了すると、ADDRESSフィールドでロードバランサーのアドレスを確認できます。
|
||||
|
||||
{{< note >}}
|
||||
使用する[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)に依存しますが、default-http-backend[Service](/ja/docs/concepts/services-networking/service/)の作成が必要な場合があります。
|
||||
使用する[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers/)に依存しますが、default-http-backend[Service](/ja/docs/concepts/services-networking/service/)の作成が必要な場合があります。
|
||||
{{< /note >}}
|
||||
|
||||
### 名前ベースのバーチャルホスティング
|
||||
|
||||
名前ベースのバーチャルホストは、HTTPトラフィックを同一のIPアドレスの複数のホスト名に転送することをサポートしています。
|
||||
|
||||
```none
|
||||
foo.bar.com --| |-> foo.bar.com service1:80
|
||||
| 178.91.123.132 |
|
||||
bar.foo.com --| |-> bar.foo.com service2:80
|
||||
```
|
||||
{{< mermaid >}}
|
||||
graph LR;
|
||||
client([クライアント])-. Ingress管理下の <br> ロードバランサー .->ingress[Ingress, 178.91.123.132];
|
||||
ingress-->|Host: foo.bar.com|service1[Service service1:80];
|
||||
ingress-->|Host: bar.foo.com|service2[Service service2:80];
|
||||
subgraph cluster[クラスター]
|
||||
ingress;
|
||||
service1-->pod1[Pod];
|
||||
service1-->pod2[Pod];
|
||||
service2-->pod3[Pod];
|
||||
service2-->pod4[Pod];
|
||||
end
|
||||
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
|
||||
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
|
||||
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
|
||||
class ingress,service1,service2,pod1,pod2,pod3,pod4 k8s;
|
||||
class client plain;
|
||||
class cluster cluster;
|
||||
{{</ mermaid >}}
|
||||
|
||||
以下のIngress設定は、ロードバランサーに対して、[Hostヘッダー](https://tools.ietf.org/html/rfc7230#section-5.4)に基づいてリクエストを転送するように指示するものです。
|
||||
|
||||
```yaml
|
||||
apiVersion: networking.k8s.io/v1beta1
|
||||
kind: Ingress
|
||||
metadata:
|
||||
name: name-virtual-host-ingress
|
||||
spec:
|
||||
rules:
|
||||
- host: foo.bar.com
|
||||
http:
|
||||
paths:
|
||||
- backend:
|
||||
serviceName: service1
|
||||
servicePort: 80
|
||||
- host: bar.foo.com
|
||||
http:
|
||||
paths:
|
||||
- backend:
|
||||
serviceName: service2
|
||||
servicePort: 80
|
||||
```
|
||||
{{< codenew file="service/networking/name-virtual-host-ingress.yaml" >}}
|
||||
|
||||
rules項目でのホストの設定がないIngressを作成すると、IngressコントローラーのIPアドレスに対するwebトラフィックは、要求されている名前ベースのバーチャルホストなしにマッチさせることができます。
|
||||
|
||||
例えば、以下のIngressリソースは`first.bar.com`に対するトラフィックを`service1`へ、`second.foo.com`に対するトラフィックを`service2`へ、リクエストにおいてホスト名が指定されていない(リクエストヘッダーがないことを意味します)トラフィックは`service3`へ転送します。
|
||||
例えば、以下のIngressは`first.bar.com`に対するトラフィックを`service1`へ、`second.foo.com`に対するトラフィックを`service2`へ、リクエストにおいてホスト名が指定されていない(リクエストヘッダーがないことを意味します)トラフィックは`service3`へ転送します。
|
||||
|
||||
```yaml
|
||||
apiVersion: networking.k8s.io/v1beta1
|
||||
kind: Ingress
|
||||
metadata:
|
||||
name: name-virtual-host-ingress
|
||||
spec:
|
||||
rules:
|
||||
- host: first.bar.com
|
||||
http:
|
||||
paths:
|
||||
- backend:
|
||||
serviceName: service1
|
||||
servicePort: 80
|
||||
- host: second.foo.com
|
||||
http:
|
||||
paths:
|
||||
- backend:
|
||||
serviceName: service2
|
||||
servicePort: 80
|
||||
- http:
|
||||
paths:
|
||||
- backend:
|
||||
serviceName: service3
|
||||
servicePort: 80
|
||||
```
|
||||
{{< codenew file="service/networking/name-virtual-host-ingress-no-third-host.yaml" >}}
|
||||
|
||||
### TLS
|
||||
|
||||
TLSの秘密鍵と証明書を含んだ{{< glossary_tooltip term_id="secret" >}}を指定することにより、Ingressをセキュアにできます。現在Ingressは単一のTLSポートである443番ポートのみサポートし、TLS終端を行うことを想定しています。IngressのTLS設定のセクションで異なるホストを指定すると、それらのホストはSNI TLSエクステンション(IngressコントローラーがSNIをサポートしている場合)を介して指定されたホスト名に対し、同じポート上で多重化されます。TLSのSecretは`tls.crt`と`tls.key`というキーを含む必要があり、TLSを使用するための証明書と秘密鍵を含む値となります。以下がその例です。
|
||||
TLSの秘密鍵と証明書を含んだ{{< glossary_tooltip term_id="secret" >}}を指定することにより、Ingressをセキュアにできます。Ingressは単一のTLSポートである443番ポートのみサポートし、IngressでTLS終端を行うことを想定しています。IngressからServiceやPodへのトラフィックは平文です。IngressのTLS設定のセクションで異なるホストを指定すると、それらのホストはSNI TLSエクステンション(IngressコントローラーがSNIをサポートしている場合)を介して指定されたホスト名に対し、同じポート上で多重化されます。TLSのSecretは`tls.crt`と`tls.key`というキーを含む必要があり、TLSを使用するための証明書と秘密鍵を含む値となります。以下がその例です。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
@@ -314,37 +328,25 @@ data:
|
||||
type: kubernetes.io/tls
|
||||
```
|
||||
|
||||
IngressでこのSecretを参照すると、クライアントとロードバランサー間の通信にTLSを使用するようIngressコントローラーに指示することになります。作成したTLS Secretは、`sslexample.foo.com`の完全修飾ドメイン名(FQDN)とも呼ばれる共通名(CN)を含む証明書から作成したものであることを確認する必要があります。
|
||||
IngressでこのSecretを参照すると、クライアントとロードバランサー間の通信にTLSを使用するようIngressコントローラーに指示することになります。作成したTLS Secretは、`https-example.foo.com`の完全修飾ドメイン名(FQDN)とも呼ばれる共通名(CN)を含む証明書から作成したものであることを確認する必要があります。
|
||||
|
||||
```yaml
|
||||
apiVersion: networking.k8s.io/v1beta1
|
||||
kind: Ingress
|
||||
metadata:
|
||||
name: tls-example-ingress
|
||||
spec:
|
||||
tls:
|
||||
- hosts:
|
||||
- sslexample.foo.com
|
||||
secretName: testsecret-tls
|
||||
rules:
|
||||
- host: sslexample.foo.com
|
||||
http:
|
||||
paths:
|
||||
- path: /
|
||||
backend:
|
||||
serviceName: service1
|
||||
servicePort: 80
|
||||
```
|
||||
{{< note >}}
|
||||
デフォルトルールではTLSが機能しない可能性があることに注意してください。
|
||||
これは取り得る全てのサブドメインに対する証明書を発行する必要があるからです。
|
||||
そのため、`tls`セクションの`hosts`は`rules`セクションの`host`と明示的に一致する必要があります。
|
||||
{{< /note >}}
|
||||
|
||||
{{< codenew file="service/networking/tls-example-ingress.yaml" >}}
|
||||
|
||||
{{< note >}}
|
||||
サポートされるTLSの機能はIngressコントローラーによって違いがあります。利用する環境でTLSがどのように動作するかを理解するためには、[nginx](https://kubernetes.github.io/ingress-nginx/user-guide/tls/)や、[GCE](https://git.k8s.io/ingress-gce/README.md#frontend-https)、他のプラットフォーム固有のIngressコントローラーのドキュメントを確認してください。
|
||||
{{< /note >}}
|
||||
|
||||
### 負荷分散
|
||||
### 負荷分散 {#load-balancing}
|
||||
|
||||
Ingressコントローラーは、負荷分散アルゴリズムやバックエンドの重みスキームなど、すべてのIngressに適用されるいくつかの負荷分散ポリシーの設定とともにブートストラップされます。発展した負荷分散のコンセプト(例: セッションの永続化、動的重み付けなど)はIngressによってサポートされていません。代わりに、それらの機能はService用のロードバランサーを介して利用できます。
|
||||
|
||||
Ingressによってヘルスチェックの機能が直接に公開されていない場合でも、Kubernetesにおいて、同等の機能を提供する[Readiness Probe](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)のようなコンセプトが存在することは注目に値します。コントローラーがどのようにヘルスチェックを行うかについては、コントローラーのドキュメントを参照してください([nginx](https://git.k8s.io/ingress-nginx/README.md)、[GCE](https://git.k8s.io/ingress-gce/README.md#health-checks))。
|
||||
Ingressによってヘルスチェックの機能が直接に公開されていない場合でも、Kubernetesにおいて、同等の機能を提供する[Readiness Probe](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)のようなコンセプトが存在することは注目に値します。コントローラーがどのようにヘルスチェックを行うかについては、コントローラーのドキュメントを参照してください(例えば[nginx](https://git.k8s.io/ingress-nginx/README.md)、または[GCE](https://git.k8s.io/ingress-gce/README.md#health-checks))。
|
||||
|
||||
## Ingressの更新
|
||||
|
||||
@@ -385,16 +387,22 @@ spec:
|
||||
http:
|
||||
paths:
|
||||
- backend:
|
||||
serviceName: service1
|
||||
servicePort: 80
|
||||
service:
|
||||
name: service1
|
||||
port:
|
||||
number: 80
|
||||
path: /foo
|
||||
pathType: Prefix
|
||||
- host: bar.baz.com
|
||||
http:
|
||||
paths:
|
||||
- backend:
|
||||
serviceName: service2
|
||||
servicePort: 80
|
||||
service:
|
||||
name: service2
|
||||
port:
|
||||
number: 80
|
||||
path: /foo
|
||||
pathType: Prefix
|
||||
..
|
||||
```
|
||||
|
||||
@@ -430,11 +438,7 @@ Events:
|
||||
|
||||
## アベイラビリティーゾーンをまたいだ障害について
|
||||
|
||||
障害のあるドメインをまたいでトラフィックを分散する手法は、クラウドプロバイダーによって異なります。詳細に関して、[Ingress コントローラー](/ja/docs/concepts/services-networking/ingress-controllers)のドキュメントを参照してください。複数のクラスターにおいてIngressをデプロイする方法の詳細に関しては[Kubernetes Cluster Federationのドキュメント](https://github.com/kubernetes-sigs/federation-v2)を参照してください。
|
||||
|
||||
## 将来追加予定の内容
|
||||
|
||||
Ingressと関連するリソースの今後の開発については[SIG Network](https://github.com/kubernetes/community/tree/master/sig-network)で行われている議論を確認してください。様々なIngressコントローラーの開発については[Ingress リポジトリー](https://github.com/kubernetes/ingress/tree/master)を確認してください。
|
||||
障害のあるドメインをまたいでトラフィックを分散する手法は、クラウドプロバイダーによって異なります。詳細に関して、[Ingress コントローラー](/ja/docs/concepts/services-networking/ingress-controllers)のドキュメントを参照してください。
|
||||
|
||||
## Ingressの代替案 {#alternatives}
|
||||
|
||||
@@ -447,4 +451,4 @@ Ingressリソースを直接含まない複数の方法でサービスを公開
|
||||
## {{% heading "whatsnext" %}}
|
||||
* [Ingress API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)について学ぶ
|
||||
* [Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers/)について学ぶ
|
||||
* [MinikubeとNGINXコントローラーでIngressのセットアップを行う](/docs/tasks/access-application-cluster/ingress-minikube)
|
||||
* [MinikubeとNGINXコントローラーでIngressのセットアップを行う](/docs/tasks/access-application-cluster/ingress-minikube/)
|
||||
|
||||
@@ -6,9 +6,17 @@ weight: 50
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
ネットワークポリシーは、{{< glossary_tooltip text="Pod" term_id="pod">}}のグループが、Pod相互や他のネットワークエンドポイントと通信する場合に許可を与える方法を指定するための仕様です。
|
||||
IPアドレスまたはポートのレベル(OSI参照モデルのレイヤ3または4)でトラフィックフローを制御したい場合、クラスター内の特定のアプリケーションにKubernetesのネットワークポリシーを使用することを検討してください。ネットワークポリシーはアプリケーション中心の構造であり、{{<glossary_tooltip text="Pod" term_id="pod">}}がネットワークを介して多様な「エンティティ」(「Endpoint」や「Service」のようなKubernetesに含まれる特定の意味を持つ共通の用語との重複を避けるため、ここではエンティティという単語を使用します。)と通信する方法を指定できます。
|
||||
|
||||
NetworkPolicyリソースは、{{< glossary_tooltip text="ラベル" term_id="label">}}を使用してPodを選択し、選択したPodに対してどんなトラフィックを許可するかを指定するルールを定義します。
|
||||
Podが通信できるエンティティは以下の3つの識別子の組み合わせによって識別されます。
|
||||
|
||||
1. 許可されている他のPod(例外: Podはそれ自体へのアクセスをブロックできません)
|
||||
2. 許可されている名前空間
|
||||
3. IPブロック(例外: PodまたはノードのIPアドレスに関係なく、Podが実行されているノードとの間のトラフィックは常に許可されます。)
|
||||
|
||||
Podベースもしくは名前空間ベースのネットワークポリシーを定義する場合、{{<glossary_tooltip text="セレクター" term_id="selector">}}を使用してセレクターに一致するPodとの間で許可されるトラフィックを指定します。
|
||||
|
||||
一方でIPベースのネットワークポリシーが作成されると、IPブロック(CIDRの範囲)に基づいてポリシーが定義されます。
|
||||
|
||||
<!-- body -->
|
||||
## 前提条件
|
||||
@@ -186,14 +194,33 @@ __ipBlock__: 特定のIPのCIDRの範囲を選択して、ingressの送信元ま
|
||||
|
||||
## SCTPのサポート
|
||||
|
||||
{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
|
||||
{{< feature-state for_k8s_version="v1.19" state="beta" >}}
|
||||
|
||||
この機能を利用するには、クラスター管理者がAPIサーバーで`--feature-gates=SCTPSupport=true,…`と指定して、`SCTPSupport`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にする必要があります。フィーチャーゲートが有効になれば、NetworkPolicyの`protocol`フィールドに`SCTP`が指定できるようになります。
|
||||
ベータ版の機能として、これはデフォルトで有効化されます。
|
||||
クラスターレベルでSCTPを無効化するために、クラスター管理者はAPIサーバーで`--feature-gates=SCTPSupport=false,…`と指定して、`SCTPSupport`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を無効にする必要があります。
|
||||
|
||||
{{< note >}}
|
||||
SCTPプロトコルのネットワークポリシーをサポートする{{< glossary_tooltip text="CNI" term_id="cni" >}}プラグインを使用している必要があります。
|
||||
{{< /note >}}
|
||||
|
||||
## ネットワークポリシーでできないこと(少なくともまだ)
|
||||
|
||||
Kubernetes1.20現在、ネットワークポリシーAPIに以下の機能は存在しません。
|
||||
しかし、オペレーティングシステムのコンポーネント(SELinux、OpenVSwitch、IPTablesなど)、レイヤ7の技術(Ingressコントローラー、サービスメッシュ実装)、もしくはアドミッションコントローラーを使用して回避策を実装できる場合があります。
|
||||
Kubernetesのネットワークセキュリティを初めて使用する場合は、ネットワークポリシーAPIを使用して以下ののユーザーストーリーを(まだ)実装できないことに注意してください。これらのユーザーストーリーの一部(全てではありません)は、ネットワークポリシーAPIの将来のリリースで活発に議論されています。
|
||||
|
||||
- クラスター内トラフィックを強制的に共通ゲートウェイを通過させる(これは、サービスメッシュもしくは他のプロキシで提供するのが最適な場合があります)。
|
||||
- TLS関連のもの(これにはサービスメッシュまたはIngressコントローラを使用します)。
|
||||
- ノードの固有のポリシー(これらにはCIDR表記を使用できますが、Kubernetesのアイデンティティでノードを指定することはできません)。
|
||||
- 名前空間またはサービスを名前で指定する(ただし、Podまたは名前空間を{{< glossary_tooltip text="ラベル" term_id="label" >}}で指定することができます。これは多くの場合で実行可能な回避策です)。
|
||||
- サードパーティによって実行される「ポリシー要求」の作成または管理
|
||||
- 全ての名前空間もしくはPodに適用されるデフォルトのポリシー(これを実現できるサードパーティのKubernetesディストリビューションとプロジェクトがいくつか存在します)。
|
||||
- 高度なポリシークエリと到達可能性ツール
|
||||
- 単一のポリシー宣言でポートの範囲を指定する機能
|
||||
- ネットワークセキュリティイベント(例えばブロックされた接続や受け入れられた接続)をログに記録する機能
|
||||
- ポリシーを明示的に拒否する機能(現在、ネットワークポリシーのモデルはデフォルトで拒否されており、許可ルールを追加する機能のみが存在します)。
|
||||
- ループバックまたは内向きのホストトラフィックを拒否する機能(Podは現在localhostのアクセスやそれらが配置されているノードからのアクセスをブロックすることはできません)。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
- [ネットワークポリシーを宣言する](/ja/docs/tasks/administer-cluster/declare-network-policy/)で追加の例の説明を読む。
|
||||
|
||||
@@ -23,7 +23,7 @@ KubernetesはPodにそれぞれのIPアドレス割り振りや、Podのセッ
|
||||
|
||||
## Serviceを利用する動機
|
||||
|
||||
{{< glossary_tooltip term_id="pod" text="Pod" >}}は停止が想定して設計されています。 Podが作成され、もしそれらが停止する時、Podは再作成されません。
|
||||
Kubernetes {{< glossary_tooltip term_id="pod" text="Pod" >}}はクラスターの状態に合わせて作成され削除されます。Podは揮発的なリソースです。
|
||||
{{< glossary_tooltip term_id="deployment" >}}をアプリケーションを稼働させるために使用すると、Podを動的に作成・削除してくれます。
|
||||
|
||||
各Podはそれ自身のIPアドレスを持ちます。しかしDeploymentでは、ある時点において同時に稼働しているPodのセットは、その後のある時点において稼働しているPodのセットとは異なる場合があります。
|
||||
@@ -35,7 +35,8 @@ KubernetesはPodにそれぞれのIPアドレス割り振りや、Podのセッ
|
||||
## Serviceリソース {#service-resource}
|
||||
|
||||
Kubernetesにおいて、ServiceはPodの論理的なセットや、そのPodのセットにアクセスするためのポリシーを定義します(このパターンはよくマイクロサービスと呼ばることがあります)。
|
||||
ServiceによってターゲットとされたPodのセットは、たいてい {{< glossary_tooltip text="セレクター" term_id="selector" >}} (セレクターなしのServiceを利用したい場合は[下記](#services-without-selectors)を参照してください)によって定義されます。
|
||||
ServiceによってターゲットとされたPodのセットは、たいてい {{< glossary_tooltip text="セレクター" term_id="selector" >}}によって定義されます。
|
||||
その他の方法について知りたい場合は[セレクターなしのService](#services-without-selectors)を参照してください。
|
||||
|
||||
例えば、3つのレプリカが稼働しているステートレスな画像処理用のバックエンドを考えます。これらのレプリカは代替可能です。— フロントエンドはバックエンドが何であろうと気にしません。バックエンドのセットを構成する実際のPodのセットが変更された際、フロントエンドクライアントはその変更を気にしたり、バックエンドのPodのセットの情報を記録しておく必要はありません。
|
||||
|
||||
@@ -90,9 +91,9 @@ ServiceのデフォルトプロトコルはTCPです。また、他の[サポー
|
||||
Serviceは多くの場合、KubernetesのPodに対するアクセスを抽象化しますが、他の種類のバックエンドも抽象化できます。
|
||||
例えば:
|
||||
|
||||
* プロダクション環境で外部のデータベースクラスターを利用したいが、テスト環境では、自身のクラスターが持つデータベースを利用したい場合
|
||||
* Serviceを、異なるNamespace内のServiceや他のクラスターのServiceに向ける場合
|
||||
* ワークロードをKubernetesに移行するとき、アプリケーションに対する処理をしながら、バックエンドの一部をKubernetesで実行する場合
|
||||
* プロダクション環境で外部のデータベースクラスターを利用したいが、テスト環境では、自身のクラスターが持つデータベースを利用したい場合
|
||||
* Serviceを、異なる{{< glossary_tooltip term_id="namespace" >}}のServiceや他のクラスターのServiceに向ける場合
|
||||
* ワークロードをKubernetesに移行するとき、アプリケーションに対する処理をしながら、バックエンドの一部をKubernetesで実行する場合
|
||||
|
||||
このような場合において、ユーザーはPodセレクター_なしで_ Serviceを定義できます。
|
||||
|
||||
@@ -137,20 +138,19 @@ link-local (169.254.0.0/16 and 224.0.0.0/24 for IPv4, fe80::/64 for IPv6)に設
|
||||
ExternalName Serviceはセレクターの代わりにDNS名を使用する特殊なケースのServiceです。さらなる情報は、このドキュメントの後で紹介する[ExternalName](#externalname)を参照ください。
|
||||
|
||||
### エンドポイントスライス
|
||||
|
||||
{{< feature-state for_k8s_version="v1.17" state="beta" >}}
|
||||
|
||||
エンドポイントスライスは、Endpointsに対してよりスケーラブルな代替手段を提供できるAPIリソースです。概念的にはEndpointsに非常に似ていますが、エンドポイントスライスを使用すると、ネットワークエンドポイントを複数のリソースに分割できます。デフォルトでは、エンドポイントスライスは、100個のエンドポイントに到達すると「いっぱいである」と見なされ、その時点で追加のエンドポイントスライスが作成され、追加のエンドポイントが保存されます。
|
||||
|
||||
エンドポイントスライスは、[エンドポイントスライスのドキュメント](/docs/concepts/services-networking/endpoint-slices/)にて詳しく説明されている追加の属性と機能を提供します。
|
||||
エンドポイントスライスは、[エンドポイントスライスのドキュメント](/ja/docs/concepts/services-networking/endpoint-slices/)にて詳しく説明されている追加の属性と機能を提供します。
|
||||
|
||||
### アプリケーションプロトコル
|
||||
|
||||
{{< feature-state for_k8s_version="v1.18" state="alpha" >}}
|
||||
|
||||
AppProtocolフィールドは、各Serviceのポートで使用されるアプリケーションプロトコルを指定する方法を提供します。
|
||||
|
||||
アルファ機能のため、このフィールドはデフォルトで有効化されていません。このフィールドを使用するには、 `ServiceAppProtocol` という[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効化してください。
|
||||
{{< feature-state for_k8s_version="v1.19" state="beta" >}}
|
||||
|
||||
`AppProtocol`フィールドによってServiceの各ポートに対して特定のアプリケーションプロトコルを指定することができます。
|
||||
この値は、対応するEndpointsオブジェクトとEndpointSliceオブジェクトに反映されます。
|
||||
## 仮想IPとサービスプロキシー {#virtual-ips-and-service-proxies}
|
||||
|
||||
Kubernetesクラスターの各Nodeは`kube-proxy`を稼働させています。`kube-proxy`は[`ExternalName`](#externalname)タイプ以外の`Service`用に仮想IPを実装する責務があります。
|
||||
@@ -162,9 +162,9 @@ Kubernetesクラスターの各Nodeは`kube-proxy`を稼働させています。
|
||||
|
||||
Serviceにおいてプロキシーを使う理由はいくつかあります。
|
||||
|
||||
* DNSの実装がレコードのTTLをうまく扱わず、期限が切れた後も名前解決の結果をキャッシュするという長い歴史がある。
|
||||
* いくつかのアプリケーションではDNSルックアップを1度だけ行い、その結果を無期限にキャッシュする。
|
||||
* アプリケーションとライブラリーが適切なDNS名の再解決を行ったとしても、DNSレコード上の0もしくは低い値のTTLがDNSに負荷をかけることがあり、管理が難しい。
|
||||
* DNSの実装がレコードのTTLをうまく扱わず、期限が切れた後も名前解決の結果をキャッシュするという長い歴史がある。
|
||||
* いくつかのアプリケーションではDNSルックアップを1度だけ行い、その結果を無期限にキャッシュする。
|
||||
* アプリケーションとライブラリーが適切なDNS名の再解決を行ったとしても、DNSレコード上の0もしくは低い値のTTLがDNSに負荷をかけることがあり、管理が難しい。
|
||||
|
||||
### user-spaceプロキシーモード {#proxy-mode-userspace}
|
||||
|
||||
@@ -211,12 +211,12 @@ IPVSプロキシーモードはiptablesモードと同様に、netfilterのフ
|
||||
|
||||
IPVSはバックエンドPodに対するトラフィックのバランシングのために多くのオプションを下記のとおりに提供します。
|
||||
|
||||
- `rr`: ラウンドロビン
|
||||
- `lc`: 最低コネクション数(オープンされているコネクション数がもっとも小さいもの)
|
||||
- `dh`: 送信先IPによって割り当てられたハッシュ値をもとに割り当てる(Destination Hashing)
|
||||
- `sh`: 送信元IPによって割り当てられたハッシュ値をもとに割り当てる(Source Hashing)
|
||||
- `sed`: 見込み遅延が最小なもの
|
||||
- `nq`: キューなしスケジューリング
|
||||
* `rr`: ラウンドロビン
|
||||
* `lc`: 最低コネクション数(オープンされているコネクション数がもっとも小さいもの)
|
||||
* `dh`: 送信先IPによって割り当てられたハッシュ値をもとに割り当てる(Destination Hashing)
|
||||
* `sh`: 送信元IPによって割り当てられたハッシュ値をもとに割り当てる(Source Hashing)
|
||||
* `sed`: 見込み遅延が最小なもの
|
||||
* `nq`: キューなしスケジューリング
|
||||
|
||||
{{< note >}}
|
||||
IPVSモードでkube-proxyを稼働させるためには、kube-proxyを稼働させる前にNode上でIPVSを有効にしなければなりません。
|
||||
@@ -282,7 +282,7 @@ PodがNode上で稼働するとき、kubeletはアクティブな各Serviceに
|
||||
これは[Docker links互換性](https://docs.docker.com/userguide/dockerlinks/)のある変数(
|
||||
[makeLinkVariables関数](https://releases.k8s.io/{{< param "githubbranch" >}}/pkg/kubelet/envvars/envvars.go#L72)を確認してください)や、より簡単な`{SVCNAME}_SERVICE_HOST`や、`{SVCNAME}_SERVICE_PORT`変数をサポートします。この変数名で使われるService名は大文字に変換され、`-`は`_`に変換されます。
|
||||
|
||||
例えば、TCPポート6379番を公開していて、さらにclusterIPが10.0.0.11に割り当てられている`"redis-master"`というServiceは、下記のような環境変数を生成します。
|
||||
例えば、TCPポート6379番を公開していて、さらにclusterIPが10.0.0.11に割り当てられている`redis-master`というServiceは、下記のような環境変数を生成します。
|
||||
|
||||
```shell
|
||||
REDIS_MASTER_SERVICE_HOST=10.0.0.11
|
||||
@@ -308,12 +308,12 @@ ServiceのclusterIPを発見するためにDNSのみを使う場合、このよ
|
||||
CoreDNSなどのクラスター対応のDNSサーバーは新しいServiceや、各Service用のDNSレコードのセットのためにKubernetes APIを常に監視します。
|
||||
もしクラスターを通してDNSが有効になっている場合、全てのPodはDNS名によって自動的にServiceに対する名前解決をするようにできるはずです。
|
||||
|
||||
例えば、Kubernetesの`"my-ns"`というNamespace内で`"my-service"`というServiceがある場合、KubernetesコントロールプレーンとDNS Serviceが協調して動作し、`"my-service.my-ns"`というDNSレコードを作成します。
|
||||
`"my-ns"`というNamespace内のPodは`my-service`という名前で簡単に名前解決できるはずです(`"my-service.my-ns"`でも動作します)。
|
||||
例えば、Kubernetesの`my-ns`というNamespace内で`my-service`というServiceがある場合、KubernetesコントロールプレーンとDNS Serviceが協調して動作し、`my-service.my-ns`というDNSレコードを作成します。
|
||||
`my-ns`というNamespace内のPodは`my-service`という名前で簡単に名前解決できるはずです(`my-service.my-ns`でも動作します)。
|
||||
|
||||
他のNamespace内でのPodは`my-service.my-ns`といった形で指定しなくてはなりません。これらのDNS名は、そのServiceのclusterIPに名前解決されます。
|
||||
|
||||
Kubernetesは名前付きのポートに対するDNS SRV(Service)レコードもサポートしています。もし`"my-service.my-ns"`というServiceが`"http"`という名前のTCPポートを持っていた場合、IPアドレスと同様に、`"http"`のポート番号を探すために`_http._tcp.my-service.my-ns`というDNS SRVクエリを実行できます。
|
||||
Kubernetesは名前付きのポートに対するDNS SRV(Service)レコードもサポートしています。もし`my-service.my-ns`というServiceが`http`という名前のTCPポートを持っていた場合、IPアドレスと同様に、`http`のポート番号を探すために`_http._tcp.my-service.my-ns`というDNS SRVクエリを実行できます。
|
||||
|
||||
KubernetesのDNSサーバーは`ExternalName` Serviceにアクセスする唯一の方法です。
|
||||
[DNS Pods と Service](/ja/docs/concepts/services-networking/dns-pod-service/)にて`ExternalName`による名前解決に関するさらなる情報を確認できます。
|
||||
@@ -337,8 +337,8 @@ KubernetesのDNSサーバーは`ExternalName` Serviceにアクセスする唯一
|
||||
ラベルセレクターを定義しないHeadless Serviceにおいては、Endpointsコントローラーは`Endpoints`レコードを作成しません。
|
||||
しかしDNSのシステムは下記の2つ両方を探索し、設定します。
|
||||
|
||||
* [`ExternalName`](#externalname)タイプのServiceに対するCNAMEレコード
|
||||
* 他の全てのServiceタイプを含む、Service名を共有している全ての`Endpoints`レコード
|
||||
* [`ExternalName`](#externalname)タイプのServiceに対するCNAMEレコード
|
||||
* 他の全てのServiceタイプを含む、Service名を共有している全ての`Endpoints`レコード
|
||||
|
||||
## Serviceの公開 (Serviceのタイプ) {#publishing-services-service-types}
|
||||
|
||||
@@ -349,16 +349,15 @@ Kubernetesの`ServiceTypes`によって、ユーザーがどのような種類
|
||||
|
||||
`Type`項目の値と、そのふるまいは以下のようになります。
|
||||
|
||||
* `ClusterIP`: クラスター内部のIPでServiceを公開する。このタイプではServiceはクラスター内部からのみ疎通性があります。このタイプはデフォルトの`ServiceType`です。
|
||||
* [`NodePort`](#nodeport): 各NodeのIPにて、静的なポート(`NodePort`)上でServiceを公開します。その`NodePort` のServiceが転送する先の`ClusterIP` Serviceが自動的に作成されます。`<NodeIP>:<NodePort>`にアクセスすることによって`NodePort` Serviceにアクセスできるようになります。
|
||||
* [`LoadBalancer`](#loadbalancer): クラウドプロバイダーのロードバランサーを使用して、Serviceを外部に公開します。クラスター外部にあるロードバランサーが転送する先の`NodePort`と`ClusterIP` Serviceは自動的に作成されます。
|
||||
* [`ExternalName`](#externalname): `CNAME`レコードを返すことにより、`externalName`フィールドに指定したコンテンツ(例: `foo.bar.example.com`)とServiceを紐づけます。しかし、いかなる種類のプロキシーも設定されません。
|
||||
* `ClusterIP`: クラスター内部のIPでServiceを公開する。このタイプではServiceはクラスター内部からのみ疎通性があります。このタイプはデフォルトの`ServiceType`です。
|
||||
* [`NodePort`](#nodeport): 各NodeのIPにて、静的なポート(`NodePort`)上でServiceを公開します。その`NodePort` のServiceが転送する先の`ClusterIP` Serviceが自動的に作成されます。`<NodeIP>:<NodePort>`にアクセスすることによって`NodePort` Serviceにアクセスできるようになります。
|
||||
* [`LoadBalancer`](#loadbalancer): クラウドプロバイダーのロードバランサーを使用して、Serviceを外部に公開します。クラスター外部にあるロードバランサーが転送する先の`NodePort`と`ClusterIP` Serviceは自動的に作成されます。
|
||||
* [`ExternalName`](#externalname): `CNAME`レコードを返すことにより、`externalName`フィールドに指定したコンテンツ(例: `foo.bar.example.com`)とServiceを紐づけます。しかし、いかなる種類のプロキシーも設定されません。
|
||||
{{< note >}}
|
||||
`ExternalName`タイプのServiceを利用するためには、kube-dnsのバージョン1.7かCoreDNSのバージョン0.0.8以上が必要となります。
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
`ExternalName`タイプのServiceを利用するためには、kube-dnsのバージョン1.7かCoreDNSのバージョン0.0.8以上が必要となります。
|
||||
{{< /note >}}
|
||||
|
||||
また、Serviceを公開するために[Ingress](/docs/concepts/services-networking/ingress/)も利用可能です。IngressはServiceのタイプではありませんが、クラスターに対するエントリーポイントとして動作します。
|
||||
また、Serviceを公開するために[Ingress](/ja/docs/concepts/services-networking/ingress/)も利用可能です。IngressはServiceのタイプではありませんが、クラスターに対するエントリーポイントとして動作します。
|
||||
Ingressは同一のIPアドレスにおいて、複数のServiceを公開するように、ユーザーの設定した転送ルールを1つのリソースにまとめることができます。
|
||||
|
||||
### NodePort タイプ {#nodeport}
|
||||
@@ -461,6 +460,7 @@ Split-HorizonなDNS環境において、ユーザーは2つのServiceを外部
|
||||
タブを選択してください。
|
||||
{{% /tab %}}
|
||||
{{% tab name="GCP" %}}
|
||||
|
||||
```yaml
|
||||
[...]
|
||||
metadata:
|
||||
@@ -469,8 +469,10 @@ metadata:
|
||||
cloud.google.com/load-balancer-type: "Internal"
|
||||
[...]
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="AWS" %}}
|
||||
|
||||
```yaml
|
||||
[...]
|
||||
metadata:
|
||||
@@ -479,8 +481,10 @@ metadata:
|
||||
service.beta.kubernetes.io/aws-load-balancer-internal: 0.0.0.0/0
|
||||
[...]
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="Azure" %}}
|
||||
|
||||
```yaml
|
||||
[...]
|
||||
metadata:
|
||||
@@ -489,8 +493,10 @@ metadata:
|
||||
service.beta.kubernetes.io/azure-load-balancer-internal: "true"
|
||||
[...]
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="IBM Cloud" %}}
|
||||
|
||||
```yaml
|
||||
[...]
|
||||
metadata:
|
||||
@@ -502,6 +508,7 @@ metadata:
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="OpenStack" %}}
|
||||
|
||||
```yaml
|
||||
[...]
|
||||
metadata:
|
||||
@@ -510,8 +517,10 @@ metadata:
|
||||
service.beta.kubernetes.io/openstack-internal-load-balancer: "true"
|
||||
[...]
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="Baidu Cloud" %}}
|
||||
|
||||
```yaml
|
||||
[...]
|
||||
metadata:
|
||||
@@ -520,8 +529,10 @@ metadata:
|
||||
service.beta.kubernetes.io/cce-load-balancer-internal-vpc: "true"
|
||||
[...]
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="Tencent Cloud" %}}
|
||||
|
||||
```yaml
|
||||
[...]
|
||||
metadata:
|
||||
@@ -529,6 +540,7 @@ metadata:
|
||||
service.kubernetes.io/qcloud-loadbalancer-internal-subnetid: subnet-xxxxx
|
||||
[...]
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
@@ -675,8 +687,16 @@ AWS上でのELB Service用のアクセスログを管理するためにはいく
|
||||
# この値はservice.beta.kubernetes.io/aws-load-balancer-healthcheck-intervalの値以下である必要があります。
|
||||
# デフォルトでは5 この値は2から60の間で設定可能
|
||||
|
||||
service.beta.kubernetes.io/aws-load-balancer-security-groups: "sg-53fae93f"
|
||||
# ELBが作成される際に追加されるセキュリティグループのリスト
|
||||
# service.beta.kubernetes.io/aws-load-balancer-extra-security-groupsアノテーションと異なり
|
||||
# 元々ELBに付与されていたセキュリティグループを置き換えることになります。
|
||||
|
||||
service.beta.kubernetes.io/aws-load-balancer-extra-security-groups: "sg-53fae93f,sg-42efd82e"
|
||||
# ELBに追加される予定のセキュリティーグループのリスト
|
||||
|
||||
service.beta.kubernetes.io/aws-load-balancer-target-node-labels: "ingress-gw,gw-name=public-api"
|
||||
# ロードバランサーがターゲットノードを指定する際に利用するキーバリューのペアのコンマ区切りリストです。
|
||||
```
|
||||
|
||||
#### AWSでのNetwork Load Balancerのサポート {#aws-nlb-support}
|
||||
@@ -712,7 +732,7 @@ NLBの背後にあるインスタンスに対してクライアントのトラ
|
||||
|------|----------|---------|------------|---------------------|
|
||||
| ヘルスチェック | TCP | NodePort(s) (`.spec.healthCheckNodePort` for `.spec.externalTrafficPolicy = Local`) | VPC CIDR | kubernetes.io/rule/nlb/health=\<loadBalancerName\> |
|
||||
| クライアントのトラフィック | TCP | NodePort(s) | `.spec.loadBalancerSourceRanges` (デフォルト: `0.0.0.0/0`) | kubernetes.io/rule/nlb/client=\<loadBalancerName\> |
|
||||
| MTCによるサービスディスカバリー | ICMP | 3,4 | `.spec.loadBalancerSourceRanges` (デフォルト: `0.0.0.0/0`) | kubernetes.io/rule/nlb/mtu=\<loadBalancerName\> |
|
||||
| MTUによるサービスディスカバリー | ICMP | 3,4 | `.spec.loadBalancerSourceRanges` (デフォルト: `0.0.0.0/0`) | kubernetes.io/rule/nlb/mtu=\<loadBalancerName\> |
|
||||
|
||||
どのクライアントIPがNLBにアクセス可能かを制限するためには、`loadBalancerSourceRanges`を指定してください。
|
||||
|
||||
@@ -738,8 +758,9 @@ spec:
|
||||
annotations:
|
||||
# 指定したノードでロードバランサーをバインドします
|
||||
service.kubernetes.io/qcloud-loadbalancer-backends-label: key in (value1, value2)
|
||||
|
||||
# 既存のロードバランサーのID
|
||||
service.kubernetes.io/tke-existed-lbid:lb-6swtxxxx
|
||||
service.kubernetes.io/tke-existed-lbid: lb-6swtxxxx
|
||||
|
||||
# ロードバランサー(LB)のカスタムパラメーターは、LBタイプの変更をまだサポートしていません
|
||||
service.kubernetes.io/service.extensiveParameters: ""
|
||||
@@ -750,11 +771,14 @@ spec:
|
||||
# ロードバランサーのタイプを指定します
|
||||
# 有効な値: classic(Classic Cloud Load Balancer)またはapplication(Application Cloud Load Balancer)
|
||||
service.kubernetes.io/loadbalance-type: xxxxx
|
||||
|
||||
# パブリックネットワーク帯域幅の課金方法を指定します
|
||||
# 有効な値: TRAFFIC_POSTPAID_BY_HOUR(bill-by-traffic)およびBANDWIDTH_POSTPAID_BY_HOUR(bill-by-bandwidth)
|
||||
service.kubernetes.io/qcloud-loadbalancer-internet-charge-type: xxxxxx
|
||||
|
||||
# 帯域幅の値を指定します(値の範囲:[1-2000] Mbps)。
|
||||
service.kubernetes.io/qcloud-loadbalancer-internet-max-bandwidth-out: "10"
|
||||
|
||||
# この注釈が設定されている場合、ロードバランサーはポッドが実行されているノードのみを登録します
|
||||
# そうでない場合、すべてのノードが登録されます
|
||||
service.kubernetes.io/local-svc-only-bind-node-with-pod: true
|
||||
@@ -777,6 +801,7 @@ spec:
|
||||
type: ExternalName
|
||||
externalName: my.database.example.com
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
ExternalNameはIpv4のアドレスの文字列のみ受け付けますが、IPアドレスではなく、数字で構成されるDNS名として受け入れます。
|
||||
IPv4アドレスに似ているExternalNamesはCoreDNSもしくはIngress-Nginxによって名前解決されず、これはExternalNameは正規のDNS名を指定することを目的としているためです。
|
||||
@@ -914,12 +939,12 @@ ServiceはKubernetesのREST APIにおいてトップレベルのリソースで
|
||||
もしクラウドプロバイダーがサポートしている場合、ServiceのEndpointsに転送される外部のHTTP/HTTPSでのリバースプロキシーをセットアップするために、LoadBalancerモードでServiceを作成可能です。
|
||||
|
||||
{{< note >}}
|
||||
ユーザーはまた、HTTP / HTTPS Serviceを公開するために、Serviceの代わりに{{< glossary_tooltip term_id="ingress" >}}を利用することもできます。
|
||||
ユーザーはまた、HTTP/HTTPS Serviceを公開するために、Serviceの代わりに{{< glossary_tooltip term_id="ingress" >}}を利用することもできます。
|
||||
{{< /note >}}
|
||||
|
||||
### PROXY プロトコル
|
||||
|
||||
もしクラウドプロバイダーがサポートしている場合(例: [AWS](/docs/concepts/cluster-administration/cloud-providers/#aws))、Kubernetesクラスターの外部のロードバランサーを設定するためにLoadBalancerモードでServiceを利用できます。これは[PROXY protocol](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)がついた接続を転送します。
|
||||
もしクラウドプロバイダーがサポートしている場合、Kubernetesクラスターの外部のロードバランサーを設定するためにLoadBalancerモードでServiceを利用できます。これは[PROXY protocol](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)がついた接続を転送します。
|
||||
|
||||
ロードバランサーは、最初の一連のオクテットを送信します。
|
||||
下記のような例となります。
|
||||
@@ -927,15 +952,16 @@ ServiceはKubernetesのREST APIにおいてトップレベルのリソースで
|
||||
```
|
||||
PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n
|
||||
```
|
||||
|
||||
クライアントからのデータのあとに追加されます。
|
||||
|
||||
### SCTP
|
||||
|
||||
{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
|
||||
{{< feature-state for_k8s_version="v1.19" state="beta" >}}
|
||||
|
||||
KubernetesはService、Endpoints、NetworkPolicyとPodの定義においてα版の機能として`protocol`フィールドの値でSCTPをサポートしています。この機能を有効にするために、クラスター管理者はAPI Serverにおいて`SCTPSupport`というフィーチャーゲートを有効にする必要があります。例えば、`--feature-gates=SCTPSupport=true,…`といったように設定します。
|
||||
KubernetesはService、Endpoints、EndpointSlice、NetworkPolicyとPodの定義において`protocol`フィールドの値でSCTPをサポートしています。ベータ版の機能のため、この機能はデフォルトで有効になっています。SCTPをクラスターレベルで無効にするには、クラスター管理者はAPI Serverにおいて`SCTPSupport` [フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を`--feature-gates=SCTPSupport=false,…`と設定して無効にする必要があります。
|
||||
|
||||
そのフィーチャーゲートが有効になった時、ユーザーはService、Endpoints、NetworkPolicyの`protocol`フィールドと、Podの`SCTP`フィールドを設定できます。
|
||||
そのフィーチャーゲートが有効になった時、ユーザーはService、Endpoints、EndpointSlice、NetworkPolicy、またはPodの`protocol`フィールドに`SCTP`を設定できます。
|
||||
Kubernetesは、TCP接続と同様に、SCTPアソシエーションに応じてネットワークをセットアップします。
|
||||
|
||||
#### 警告 {#caveat-sctp-overview}
|
||||
@@ -967,11 +993,8 @@ SCTPはWindowsベースのNodeではサポートされていません。
|
||||
kube-proxyはuserspaceモードにおいてSCTPアソシエーションの管理をサポートしません。
|
||||
{{< /warning >}}
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)を参照してください。
|
||||
* [Ingress](/docs/concepts/services-networking/ingress/)を参照してください。
|
||||
* [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/)を参照してください。
|
||||
* [Connecting Applications with Services](/ja/docs/concepts/services-networking/connect-applications-service/)を参照してください。
|
||||
* [Ingress](/ja/docs/concepts/services-networking/ingress/)を参照してください。
|
||||
* [EndpointSlices](/ja/docs/concepts/services-networking/endpoint-slices/)を参照してください。
|
||||
|
||||
@@ -54,7 +54,7 @@ parameters:
|
||||
|
||||
ユーザーは`PersistentVolumeClaim`リソース内でStorageClassを含むことで、動的にプロビジョンされたStorageをリクエストできます。Kubernetes v1.6以前では、この機能は`volume.beta.kubernetes.io/storage-class`アノテーションを介して使うことができました。しかしこのアノテーションではv1.6から廃止になりました。その代わりユーザーは現在では`PersistentVolumeClaim`オブジェクトの`storageClassName`を使う必要があります。このフィールドの値は、管理者によって設定された`StorageClass`の名前と一致しなければなりません([下記](#enabling-dynamic-provisioning)のセクションも参照ください)。
|
||||
|
||||
"fast"というStorageClassを選択するために、例としてユーザーは下記の`PersistentVolumeClaim`を作成します。
|
||||
"fast"というStorageClassを選択するために、例としてユーザーは下記のPersistentVolumeClaimを作成します。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
|
||||
@@ -162,6 +162,49 @@ spec:
|
||||
```
|
||||
ただし、カスタムリサイクラーPodテンプレートの`volumes`パート内で指定された特定のパスは、リサイクルされるボリュームの特定のパスに置き換えられます。
|
||||
|
||||
### 永続ボリュームの予約
|
||||
|
||||
コントロールプレーンは、永続ボリュームクレームをクラスター内の一致する永続ボリュームに[バインド](#バインディング)できます。
|
||||
ただし、永続ボリュームクレームを特定の永続ボリュームにバインドする場合、それらを事前にバインドする必要があります。
|
||||
|
||||
永続ボリュームクレームで永続ボリュームを指定することにより、その特定の永続ボリュームと永続ボリュームクレームの間のバインディングを宣言します。
|
||||
永続ボリュームが存在し、その`claimRef`フィールドで永続ボリュームクレームを予約していない場合に永続ボリュームと永続ボリュームクレームがバインドされます。
|
||||
|
||||
バインディングは、ノードアフィニティを含むいくつかのボリュームの一致基準に関係なく発生します。
|
||||
コントロールプレーンは、依然として[ストレージクラス](/docs/concepts/storage/storage-classes/)、アクセスモード、および要求されたストレージサイズが有効であることをチェックします。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: PersistentVolumeClaim
|
||||
metadata:
|
||||
name: foo-pvc
|
||||
namespace: foo
|
||||
spec:
|
||||
storageClassName: "" # 空の文字列を明示的に指定する必要があります。そうしないとデフォルトのストレージクラスが設定されてしまいます。
|
||||
volumeName: foo-pv
|
||||
...
|
||||
```
|
||||
|
||||
この方法は、永続ボリュームへのバインド特権を保証するものではありません。
|
||||
他の永続ボリュームクレームが指定した永続ボリュームを使用できる場合、最初にそのストレージボリュームを予約する必要があります。
|
||||
永続ボリュームの`claimRef`フィールドに関連する永続ボリュームクレームを指定して、他の永続ボリュームクレームがその永続ボリュームにバインドできないようにしてください。
|
||||
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: PersistentVolume
|
||||
metadata:
|
||||
name: foo-pv
|
||||
spec:
|
||||
storageClassName: ""
|
||||
claimRef:
|
||||
name: foo-pvc
|
||||
namespace: foo
|
||||
...
|
||||
```
|
||||
|
||||
これは、既存の永続ボリュームを再利用する場合など、`claimPolicy`が`Retain`に設定されている永続ボリュームを使用する場合に役立ちます。
|
||||
|
||||
### 永続ボリュームクレームの拡大
|
||||
|
||||
{{< feature-state for_k8s_version="v1.11" state="beta" >}}
|
||||
@@ -247,26 +290,32 @@ EBSの拡張は時間がかかる操作です。また変更は、ボリュー
|
||||
|
||||
PersistentVolumeの種類はプラグインとして実装されます。Kubernetesは現在次のプラグインに対応しています。
|
||||
|
||||
* GCEPersistentDisk
|
||||
* AWSElasticBlockStore
|
||||
* AzureFile
|
||||
* AzureDisk
|
||||
* CSI
|
||||
* FC (Fibre Channel)
|
||||
* FlexVolume
|
||||
* Flocker
|
||||
* NFS
|
||||
* iSCSI
|
||||
* RBD (Ceph Block Device)
|
||||
* CephFS
|
||||
* Cinder (OpenStack block storage)
|
||||
* Glusterfs
|
||||
* VsphereVolume
|
||||
* Quobyte Volumes
|
||||
* HostPath (テスト用の単一ノードのみ。ローカルストレージはどのような方法でもサポートされておらず、またマルチノードクラスターでは動作しません)
|
||||
* Portworx Volumes
|
||||
* ScaleIO Volumes
|
||||
* StorageOS
|
||||
* [`awsElasticBlockStore`](/docs/concepts/storage/volumes/#awselasticblockstore) - AWS Elastic Block Store (EBS)
|
||||
* [`azureDisk`](/docs/concepts/storage/volumes/#azuredisk) - Azure Disk
|
||||
* [`azureFile`](/docs/concepts/storage/volumes/#azurefile) - Azure File
|
||||
* [`cephfs`](/docs/concepts/storage/volumes/#cephfs) - CephFS volume
|
||||
* [`cinder`](/docs/concepts/storage/volumes/#cinder) - Cinder (OpenStack block storage)
|
||||
(**非推奨**)
|
||||
* [`csi`](/docs/concepts/storage/volumes/#csi) - Container Storage Interface (CSI)
|
||||
* [`fc`](/docs/concepts/storage/volumes/#fc) - Fibre Channel (FC) storage
|
||||
* [`flexVolume`](/docs/concepts/storage/volumes/#flexVolume) - FlexVolume
|
||||
* [`flocker`](/docs/concepts/storage/volumes/#flocker) - Flocker storage
|
||||
* [`gcePersistentDisk`](/docs/concepts/storage/volumes/#gcepersistentdisk) - GCE Persistent Disk
|
||||
* [`glusterfs`](/docs/concepts/storage/volumes/#glusterfs) - Glusterfs volume
|
||||
* [`hostPath`](/docs/concepts/storage/volumes/#hostpath) - HostPath volume
|
||||
(テスト用の単一ノードのみ。マルチノードクラスターでは動作しません。代わりに`local`ボリュームを利用することを検討してください。)
|
||||
* [`iscsi`](/docs/concepts/storage/volumes/#iscsi) - iSCSI (SCSI over IP) storage
|
||||
* [`local`](/docs/concepts/storage/volumes/#local) - ノードにマウントされたローカルストレージデバイス
|
||||
* [`nfs`](/docs/concepts/storage/volumes/#nfs) - Network File System (NFS) storage
|
||||
* `photonPersistentDisk` - Photon controller persistent disk
|
||||
(対応するクラウドプロバイダーが削除されたため、このボリュームタイプは機能しなくなりました。)
|
||||
* [`portworxVolume`](/docs/concepts/storage/volumes/#portworxvolume) - Portworx volume
|
||||
* [`quobyte`](/docs/concepts/storage/volumes/#quobyte) - Quobyte volume
|
||||
* [`rbd`](/docs/concepts/storage/volumes/#rbd) - Rados Block Device (RBD) volume
|
||||
* [`scaleIO`](/docs/concepts/storage/volumes/#scaleio) - ScaleIO volume
|
||||
(**非推奨**)
|
||||
* [`storageos`](/docs/concepts/storage/volumes/#storageos) - StorageOS volume
|
||||
* [`vsphereVolume`](/docs/concepts/storage/volumes/#vspherevolume) - vSphere VMDK volume
|
||||
|
||||
## 永続ボリューム
|
||||
|
||||
|
||||
@@ -1,5 +1,37 @@
|
||||
---
|
||||
title: "ワークロード"
|
||||
weight: 50
|
||||
description: >
|
||||
Kubernetesにおけるデプロイ可能な最小のオブジェクトであるPodと、高レベルな抽象化がPodの実行を助けることを理解します。
|
||||
no_list: true
|
||||
---
|
||||
|
||||
{{< glossary_definition term_id="workload" length="short" >}}
|
||||
ワークロードが1つのコンポーネントからなる場合でも、複数のコンポーネントが協調して動作する場合でも、Kubernetesではそれらは[Pod](/ja/docs/concepts/workloads/pods)の集合として実行されます。Kubernetesでは、Podはクラスター上で実行中の{{< glossary_tooltip text="コンテナ" term_id="container" >}}の集合として表されます。
|
||||
|
||||
Podには定義されたライフサイクルがあります。たとえば、一度Podがクラスター上で実行中になると、そのPodが実行中の{{< glossary_tooltip text="ノード" term_id="node" >}}上で深刻な障害が起こったとき、そのノード上のすべてのPodは停止してしまうことになります。Kubernetesではそのようなレベルの障害を最終的なものとして扱うため、たとえノードが後で復元したとしても、ユーザーは新しいPodを作成し直す必要があります。
|
||||
|
||||
しかし、生活をかなり楽にするためには、それぞれのPodを直接管理する必要はありません。_ワークロードリソース_ を利用すれば、あなたの代わりにPodの集合の管理を行ってもらえます。これらのリソースはあなたが指定した状態に一致するように{{< glossary_tooltip term_id="controller" text="コントローラー" >}}を設定し、正しい種類のPodが正しい数だけ実行中になることを保証してくれます。
|
||||
|
||||
ワークロードリソースには、次のような種類があります。
|
||||
|
||||
* [Deployment](/ja/docs/concepts/workloads/controllers/deployment/)と[ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)(レガシーなリソース{{< glossary_tooltip text="ReplicationController" term_id="replication-controller" >}}を置き換えるものです)
|
||||
* [StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/)
|
||||
* [DaemonSet](/ja/docs/concepts/workloads/controllers/daemonset/)(ストレージドライバやネットワークプラグインなど、ノードローカルな機能を提供するためのPodを実行するために使われます)
|
||||
* [Job](/docs/concepts/workloads/controllers/job/)と[CronJob](/ja/docs/concepts/workloads/controllers/cron-jobs/)(実行後に完了するようなタスクのために使われます)
|
||||
|
||||
多少関連のある2種類の補助的な概念もあります。
|
||||
* [ガベージコレクション](/ja/docs/concepts/workloads/controllers/garbage-collection/)は、オブジェクトが _所有するリソース_ が削除された後に、そのオブジェクトをクラスターからクリーンアップします。
|
||||
* [終了したリソースのためのTTLコントローラー](/ja/docs/concepts/workloads/controllers/ttlafterfinished/)は、Jobの完了後、定義した時間が経過した後にJobを削除します。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
各リソースについて読む以外にも、以下のページでそれぞれのワークロードに関連する特定のタスクについて学ぶことができます。
|
||||
|
||||
* [Deploymentを使用してステートレスアプリケーションを実行する](/ja/docs/tasks/run-application/run-stateless-application-deployment/)
|
||||
* [単一レプリカ](/ja/docs/tasks/run-application/run-single-instance-stateful-application/)または[レプリカセット](/ja/docs/tasks/run-application/run-replicated-stateful-application/)のいずれかとしてステートフルなアプリケーションを実行する
|
||||
* [CronJobを使用して自動タスクを実行する](/ja/docs/tasks/job/automated-tasks-with-cron-jobs/)
|
||||
|
||||
アプリケーションが実行できるようになったら、インターネット上で公開したくなるかもしれません。その場合には、[Service](/ja/docs/concepts/services-networking/service/)として公開したり、ウェブアプリケーションだけの場合、[Ingress](/ja/docs/concepts/services-networking/ingress)を使用することができます。
|
||||
|
||||
コードを設定から分離するKubernetesのしくみについて学ぶには、[設定](/ja/docs/concepts/configuration/)を読んでください。
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
---
|
||||
title: "コントローラー"
|
||||
title: "ワークロードリソース"
|
||||
weight: 20
|
||||
---
|
||||
|
||||
@@ -70,8 +70,6 @@ Kubernetes1.8のように、ユーザーは`.spec.template`のラベルにマッ
|
||||
|
||||
もし`spec.selector`が指定されたとき、`.spec.template.metadata.labels`とマッチしなければなりません。この2つの値がマッチしない設定をした場合、APIによってリジェクトされます。
|
||||
|
||||
また、ユーザーは通常、別のDaemonSetやReplicaSetなどの別のワークロードリソースを使用する場合であっても直接であっても、このセレクターマッチするラベルを持つPodを作成すべきではありません。さもないと、DaemonSet {{<glossary_tooltip term_id = "controller">}}は、それらのPodが作成されたものとみなすためです。Kubernetesはこれを行うことを止めません。ユーザーがこれを行いたい1つのケースとしては、テスト用にノード上に異なる値を持つPodを手動で作成するような場合があります。
|
||||
|
||||
### 選択したNode上でPodを稼働させる
|
||||
|
||||
もしユーザーが`.spec.template.spec.nodeSelector`を指定したとき、DaemonSetコントローラーは、その[node
|
||||
|
||||
@@ -31,8 +31,9 @@ Deploymentによって作成されたReplicaSetを管理しないでください
|
||||
* ReplicaSetをロールアウトするために[Deploymentの作成](#creating-a-deployment)を行う: ReplicaSetはバックグラウンドでPodを作成します。Podの作成が完了したかどうかは、ロールアウトのステータスを確認してください。
|
||||
* DeploymentのPodTemplateSpecを更新することにより[Podの新しい状態を宣言する](#updating-a-deployment): 新しいReplicaSetが作成され、Deploymentは指定された頻度で古いReplicaSetから新しいReplicaSetへのPodの移行を管理します。新しいReplicaSetはDeploymentのリビジョンを更新します。
|
||||
* Deploymentの現在の状態が不安定な場合、[Deploymentのロールバック](#rolling-back-a-deployment)をする: ロールバックによる各更新作業は、Deploymentのリビジョンを更新します。
|
||||
* より多くの負荷をさばけるように、[Deploymentをスケールアップ](#scaling-a-deployment)する
|
||||
* より多くの負荷をさばけるように、[Deploymentをスケールアップ](#scaling-a-deployment)する。
|
||||
* PodTemplateSpecに対する複数の修正を適用するために[Deploymentを停止(Pause)し](#pausing-and-resuming-a-deployment)、それを再開して新しいロールアウトを開始します。
|
||||
* [Deploymentのステータス](#deployment-status) をロールアウトが失敗したサインとして利用する。
|
||||
* 今後必要としない[古いReplicaSetのクリーンアップ](#clean-up-policy)
|
||||
|
||||
## Deploymentの作成 {#creating-a-deployment}
|
||||
@@ -82,7 +83,7 @@ Deploymentによって作成されたReplicaSetを管理しないでください
|
||||
```
|
||||
クラスターにてDeploymentを調査するとき、以下のフィールドが出力されます。
|
||||
* `NAME`は、クラスター内にあるDeploymentの名前一覧です。
|
||||
* `READY`は、ユーザーが使用できるアプリケーションのレプリカの数です。
|
||||
* `READY`は、ユーザーが使用できるアプリケーションのレプリカの数です。使用可能な数/理想的な数の形式で表示されます。
|
||||
* `UP-TO-DATE`は、理想的な状態を満たすためにアップデートが完了したレプリカの数です。
|
||||
* `AVAILABLE`は、ユーザーが利用可能なレプリカの数です。
|
||||
* `AGE`は、アプリケーションが稼働してからの時間です。
|
||||
@@ -94,7 +95,7 @@ Deploymentによって作成されたReplicaSetを管理しないでください
|
||||
コマンドの実行結果は以下のとおりです。
|
||||
```shell
|
||||
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
|
||||
deployment.apps/nginx-deployment successfully rolled out
|
||||
deployment "nginx-deployment" successfully rolled out
|
||||
```
|
||||
|
||||
4. 数秒後、再度`kubectl get deployments`を実行してください。
|
||||
@@ -133,7 +134,7 @@ Deploymentによって作成されたReplicaSetを管理しないでください
|
||||
{{< note >}}
|
||||
Deploymentに対して適切なセレクターとPodテンプレートのラベルを設定する必要があります(このケースでは`app: nginx`)。
|
||||
|
||||
ラベルやセレクターを他のコントローラーと重複させないでください(他のDeploymentやStatefulSetを含む)。Kubernetesはユーザーがラベルを重複させることを止めないため、複数のコントローラーでセレクターの重複が発生すると、コントローラー間で衝突し予期せぬふるまいをすることになります。
|
||||
ラベルやセレクターを他のコントローラーと重複させないでください(他のDeploymentやStatefulSetを含む)。Kubernetesはユーザーがラベルを重複させることを阻止しないため、複数のコントローラーでセレクターの重複が発生すると、コントローラー間で衝突し予期せぬふるまいをすることになります。
|
||||
{{< /note >}}
|
||||
|
||||
### pod-template-hashラベル
|
||||
@@ -146,7 +147,7 @@ Deploymentに対して適切なセレクターとPodテンプレートのラベ
|
||||
|
||||
このラベルはDeploymentが管理するReplicaSetが重複しないことを保証します。このラベルはReplicaSetの`PodTemplate`をハッシュ化することにより生成され、生成されたハッシュ値はラベル値としてReplicaSetセレクター、Podテンプレートラベル、ReplicaSetが作成した全てのPodに対して追加されます。
|
||||
|
||||
## Deploymentの更新
|
||||
## Deploymentの更新 {#updating-a-deployment}
|
||||
|
||||
{{< note >}}
|
||||
Deploymentのロールアウトは、DeploymentのPodテンプレート(この場合`.spec.template`)が変更された場合にのみトリガーされます。例えばテンプレートのラベルもしくはコンテナーイメージが更新された場合です。Deploymentのスケールのような更新では、ロールアウトはトリガーされません。
|
||||
@@ -193,7 +194,7 @@ Deploymentを更新するには以下のステップに従ってください。
|
||||
```
|
||||
もしくは
|
||||
```
|
||||
deployment.apps/nginx-deployment successfully rolled out
|
||||
deployment "nginx-deployment" successfully rolled out
|
||||
```
|
||||
|
||||
更新されたDeploymentのさらなる情報を取得するには、以下を確認してください。
|
||||
@@ -589,13 +590,11 @@ Deploymentのローリングアップデートは、同時に複数のバージ
|
||||
```
|
||||
|
||||
* クラスター内で、解決できない新しいイメージに更新します。
|
||||
* You update to a new image which happens to be unresolvable from inside the cluster.
|
||||
```shell
|
||||
kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:sometag
|
||||
```
|
||||
|
||||
実行結果は以下のとおりです。
|
||||
The output is similar to this:
|
||||
```
|
||||
deployment.apps/nginx-deployment image updated
|
||||
```
|
||||
@@ -604,7 +603,8 @@ Deploymentのローリングアップデートは、同時に複数のバージ
|
||||
```shell
|
||||
kubectl get rs
|
||||
```
|
||||
実行結果は以下のとおりです。
|
||||
|
||||
実行結果は以下のとおりです。
|
||||
```
|
||||
NAME DESIRED CURRENT READY AGE
|
||||
nginx-deployment-1989198191 5 5 0 9s
|
||||
@@ -615,24 +615,26 @@ Deploymentのローリングアップデートは、同時に複数のバージ
|
||||
|
||||
上記の例では、3つのレプリカが古いReplicaSetに追加され、2つのレプリカが新しいReplicaSetに追加されました。ロールアウトの処理では、新しいレプリカ数のPodが正常になったと仮定すると、最終的に新しいReplicaSetに全てのレプリカを移動させます。これを確認するためには以下のコマンドを実行して下さい。
|
||||
|
||||
```shell
|
||||
kubectl get deploy
|
||||
```
|
||||
実行結果は以下のとおりです。
|
||||
```
|
||||
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
|
||||
nginx-deployment 15 18 7 8 7m
|
||||
```
|
||||
ロールアウトのステータスでレプリカがどのように各ReplicaSetに追加されるか確認できます。
|
||||
```shell
|
||||
kubectl get rs
|
||||
```
|
||||
実行結果は以下のとおりです。
|
||||
```
|
||||
NAME DESIRED CURRENT READY AGE
|
||||
nginx-deployment-1989198191 7 7 0 7m
|
||||
nginx-deployment-618515232 11 11 11 7m
|
||||
```
|
||||
```shell
|
||||
kubectl get deploy
|
||||
```
|
||||
|
||||
実行結果は以下のとおりです。
|
||||
```
|
||||
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
|
||||
nginx-deployment 15 18 7 8 7m
|
||||
```
|
||||
ロールアウトのステータスでレプリカがどのように各ReplicaSetに追加されるか確認できます。
|
||||
```shell
|
||||
kubectl get rs
|
||||
```
|
||||
|
||||
実行結果は以下のとおりです。
|
||||
```
|
||||
NAME DESIRED CURRENT READY AGE
|
||||
nginx-deployment-1989198191 7 7 0 7m
|
||||
nginx-deployment-618515232 11 11 11 7m
|
||||
```
|
||||
|
||||
## Deployment更新の一時停止と再開 {#pausing-and-resuming-a-deployment}
|
||||
|
||||
@@ -752,7 +754,7 @@ Deploymentのローリングアップデートは、同時に複数のバージ
|
||||
nginx-3926361531 3 3 3 28s
|
||||
```
|
||||
{{< note >}}
|
||||
一時停止したDeploymentの稼働を再開させない限り、Deploymentをロールバックすることはできません。
|
||||
Deploymentの稼働を再開させない限り、一時停止したDeploymentをロールバックすることはできません。
|
||||
{{< /note >}}
|
||||
|
||||
## Deploymentのステータス {#deployment-status}
|
||||
@@ -786,7 +788,7 @@ kubectl rollout status deployment.v1.apps/nginx-deployment
|
||||
実行結果は以下のとおりです。
|
||||
```
|
||||
Waiting for rollout to finish: 2 of 3 updated replicas are available...
|
||||
deployment.apps/nginx-deployment successfully rolled out
|
||||
deployment "nginx-deployment" successfully rolled out
|
||||
```
|
||||
そして`kubectl rollout`の終了ステータスが0となります（成功です）:
|
||||
```shell
|
||||
@@ -937,13 +939,13 @@ Deploymentが管理する古いReplicaSetをいくつ保持するかを指定す
|
||||
|
||||
## カナリアパターンによるデプロイ
|
||||
|
||||
Deploymentを使って一部のユーザーやサーバーに対してリリースのロールアウトをしたい場合、[リソースの管理](/docs/concepts/cluster-administration/manage-deployment/#canary-deployments)に記載されているカナリアパターンに従って、リリース毎に1つずつ、複数のDeploymentを作成できます。
|
||||
Deploymentを使って一部のユーザーやサーバーに対してリリースのロールアウトをしたい場合、[リソースの管理](/ja/docs/concepts/cluster-administration/manage-deployment/#canary-deployments-カナリアデプロイ)に記載されているカナリアパターンに従って、リリース毎に1つずつ、複数のDeploymentを作成できます。
|
||||
|
||||
## Deployment Specの記述
|
||||
|
||||
他の全てのKubernetesの設定と同様に、Deploymentは`.apiVersion`、`.kind`や`.metadata`フィールドを必要とします。
|
||||
設定ファイルの利用に関する情報は[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)を参照してください。コンテナーの設定に関しては[リソースを管理するためのkubectlの使用](/docs/concepts/overview/working-with-objects/object-management/)を参照してください。
|
||||
Deploymentオブジェクトの名前は、有効な[DNSサブドメイン名](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)でなければなりません。
|
||||
設定ファイルの利用に関する情報は[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)を参照してください。コンテナーの設定に関しては[リソースを管理するためのkubectlの使用](/ja/docs/concepts/overview/working-with-objects/object-management/)を参照してください。
|
||||
Deploymentオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)でなければなりません。
|
||||
Deploymentは[`.spec`セクション](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)も必要とします。
|
||||
|
||||
### Podテンプレート
|
||||
@@ -992,25 +994,25 @@ Deploymentのセレクターに一致するラベルを持つPodを直接作成
|
||||
|
||||
`.spec.strategy.type==RollingUpdate`と指定されているとき、DeploymentはローリングアップデートによりPodを更新します。ローリングアップデートの処理をコントロールするために`maxUnavailable`と`maxSurge`を指定できます。
|
||||
|
||||
##### maxUnavailable
|
||||
##### Max Unavailable {#max-unavailable}
|
||||
|
||||
`.spec.strategy.rollingUpdate.maxUnavailable`はオプションのフィールドで、更新処理において利用不可となる最大のPod数を指定します。値は絶対値(例: 5)を指定するか、理想状態のPodのパーセンテージを指定します(例: 10%)。パーセンテージを指定した場合、絶対値は小数切り捨てされて計算されます。`.spec.strategy.rollingUpdate.maxSurge`が0に指定されている場合、この値を0にできません。デフォルトでは25%です。
|
||||
|
||||
例えば、この値が30%と指定されているとき、ローリングアップデートが開始すると古いReplicaSetはすぐに理想状態の70%にスケールダウンされます。一度新しいPodが稼働できる状態になると、古いReplicaSetはさらにスケールダウンされ、続いて新しいReplicaSetがスケールアップされます。この間、利用可能なPodの総数は理想状態のPodの少なくとも70%以上になるように保証されます。
|
||||
|
||||
##### maxSurge
|
||||
##### Max Surge {#max-surge}
|
||||
|
||||
`.spec.strategy.rollingUpdate.maxSurge`はオプションのフィールドで、理想状態のPod数を超えて作成できる最大のPod数を指定します。値は絶対値(例: 5)を指定するか、理想状態のPodのパーセンテージを指定します(例: 10%)。パーセンテージを指定した場合、絶対値は小数切り上げで計算されます。`MaxUnavailable`が0に指定されている場合、この値を0にできません。デフォルトでは25%です。
|
||||
|
||||
例えば、この値が30%と指定されているとき、ローリングアップデートが開始すると新しいReplicaSetはすぐに更新されます。このとき古いPodと新しいPodの総数は理想状態の130%を超えないように更新されます。一度古いPodが削除されると、新しいReplicaSetはさらにスケールアップされます。この間、利用可能なPodの総数は理想状態のPodに対して最大130%になるように保証されます。
|
||||
|
||||
### progressDeadlineSeconds
|
||||
### Progress Deadline Seconds
|
||||
|
||||
`.spec.progressDeadlineSeconds`はオプションのフィールドで、システムがDeploymentの[更新に失敗](#failed-deployment)したと判断するまでに待つ秒数を指定します。更新に失敗したと判断されたとき、リソースのステータスは`Type=Progressing`、`Status=False`かつ`Reason=ProgressDeadlineExceeded`となるのを確認できます。DeploymentコントローラーはDeploymentの更新のリトライし続けます。デフォルト値は600です。今後、自動的なロールバックが実装されたとき、更新失敗状態になるとすぐにDeploymentコントローラーがロールバックを行うようになります。
|
||||
|
||||
この値が指定されているとき、`.spec.minReadySeconds`より大きい値を指定する必要があります。
|
||||
|
||||
### minReadySeconds {#min-ready-seconds}
|
||||
### Min Ready Seconds {#min-ready-seconds}
|
||||
|
||||
`.spec.minReadySeconds`はオプションのフィールドで、新しく作成されたPodが利用可能となるために、最低どれくらいの秒数コンテナーがクラッシュすることなく稼働し続ければよいかを指定するものです。デフォルトでは0です(Podは作成されるとすぐに利用可能と判断されます)。Podが利用可能と判断された場合についてさらに学ぶために[Container Probes](/ja/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)を参照してください。
|
||||
|
||||
@@ -1020,7 +1022,7 @@ Deploymentのリビジョン履歴は、Deploymentが管理するReplicaSetに
|
||||
|
||||
`.spec.revisionHistoryLimit`はオプションのフィールドで、ロールバック可能な古いReplicaSetの数を指定します。この古いReplicaSetは`etcd`内のリソースを消費し、`kubectl get rs`の出力結果を見にくくします。Deploymentの各リビジョンの設定はReplicaSetに保持されます。このため一度古いReplicaSetが削除されると、そのリビジョンのDeploymentにロールバックすることができなくなります。デフォルトでは10もの古いReplicaSetが保持されます。しかし、この値の最適値は新しいDeploymentの更新頻度と安定性に依存します。
|
||||
|
||||
さらに詳しく言うと、この値を0にすると、0のレプリカを持つ古い全てのReplicaSetが削除されます。このケースでは、リビジョン履歴が完全に削除されているため新しいDeploymentのロールアウトを完了することができません。
|
||||
さらに詳しく言うと、この値を0にすると、0のレプリカを持つ古い全てのReplicaSetが削除されます。このケースでは、リビジョン履歴が完全に削除されているため新しいDeploymentのロールアウトを元に戻すことができません。
|
||||
|
||||
### paused
|
||||
|
||||
|
||||
@@ -124,7 +124,7 @@ kubectl delete replicaset my-repset --cascade=false
|
||||
|
||||
### Deploymentsに関する追記事項
|
||||
|
||||
Kubernetes1.7以前では、Deploymentに対するカスケード削除において、作成されたReplicaSetだけでなく、それらのPodも削除するためには、ユーザーは`propagationPolicy: Foreground`と指定*しなくてはなりません* 。もしこのタイプの_propagationPolicy_ が使われなかった場合、そのReplicaSetは削除されますが、そのPodは削除されずみなしご状態になります。
|
||||
Kubernetes1.7以前では、Deploymentに対するカスケード削除において、作成されたReplicaSetだけでなく、それらのPodも削除するためには、ユーザーは`propagationPolicy: Foreground`と指定*しなくてはなりません* 。もしこのタイプの*propagationPolicy*が使われなかった場合、そのReplicaSetは削除されますが、そのPodは削除されずみなしご状態になります。
|
||||
さらなる詳細に関しては[kubeadm/#149](https://github.com/kubernetes/kubeadm/issues/149#issuecomment-284766613)を参照してください。
|
||||
|
||||
## 既知の問題について
|
||||
|
||||
@@ -197,7 +197,7 @@ ReplicaSetオブジェクトの名前は、有効な
|
||||
|
||||
### Pod テンプレート
|
||||
|
||||
`.spec.template`はラベルを持つことが必要な[Pod テンプレート](/ja/docs/concepts/workloads/pods/pod-overview/#podテンプレート) です。先ほど作成した`frontend.yaml`の例では、`tier: frontend`というラベルを1つ持っています。
|
||||
`.spec.template`はラベルを持つことが必要な[Pod テンプレート](/ja/docs/concepts/workloads/pods/#podテンプレート) です。先ほど作成した`frontend.yaml`の例では、`tier: frontend`というラベルを1つ持っています。
|
||||
他のコントローラーがこのPodを所有しようとしないためにも、他のコントローラーのセレクターでラベルを上書きしないように注意してください。
|
||||
|
||||
テンプレートの[再起動ポリシー](/docs/concepts/workloads/Pods/pod-lifecycle/#restart-policy)のためのフィールドである`.spec.template.spec.restartPolicy`は`Always`のみ許可されていて、そしてそれがデフォルト値です。
|
||||
@@ -300,7 +300,7 @@ ReplicaSetは、Node上のいくつかのエージェント(例えば、Kubelet
|
||||
|
||||
### Job
|
||||
|
||||
PodをPodそれ自身で停止させたいような場合(例えば、バッチ用のジョブなど)は、ReplicaSetの代わりに[`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/)を使用してください。
|
||||
PodをPodそれ自身で停止させたいような場合(例えば、バッチ用のジョブなど)は、ReplicaSetの代わりに[`Job`](/docs/concepts/workloads/controllers/job/)を使用してください。
|
||||
|
||||
### DaemonSet
|
||||
|
||||
|
||||
@@ -52,4 +52,4 @@ Kubernetesにおいてタイムスキューを避けるために、全てのNode
|
||||
|
||||
* [Jobの自動クリーンアップ](/ja/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically)
|
||||
|
||||
* [設計ドキュメント](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md)
|
||||
* [設計ドキュメント](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/592-ttl-after-finish/README.md)
|
||||
|
||||
@@ -1,4 +1,160 @@
|
||||
---
|
||||
title: "Pod"
|
||||
content_type: concept
|
||||
weight: 10
|
||||
no_list: true
|
||||
card:
|
||||
name: concepts
|
||||
weight: 60
|
||||
---
|
||||
|
||||
*Pod*は、Kubernetes内で作成・管理できるコンピューティングの最小のデプロイ可能なユニットです(Podという名前は、たとえばクジラの群れ(pod of whales)やえんどう豆のさや(pea pod)などの表現と同じような意味です)。
|
||||
|
||||
*Pod*は、1つまたは複数の{{< glossary_tooltip text="コンテナ" term_id="container" >}}のグループであり、ストレージやネットワークの共有リソースを持ち、コンテナの実行方法に関する仕様を持っています。同じPodに含まれるリソースは、常に同じ場所で同時にスケジューリングされ、共有されたコンテキストの中で実行されます。Podはアプリケーションに特化した「論理的なホスト」をモデル化します。つまり、1つのPod内には、1つまたは複数の比較的密に結合されたアプリケーションコンテナが含まれます。クラウド外の文脈で説明すると、アプリケーションが同じ物理ホストや同じバーチャルマシンで実行されることが、クラウドアプリケーションの場合には同じ論理ホスト上で実行されることに相当します。
|
||||
|
||||
アプリケーションコンテナと同様に、Podでも、Podのスタートアップ時に実行される[initコンテナ](/ja/docs/concepts/workloads/pods/init-containers/)を含めることができます。また、クラスターで利用できる場合には、[エフェメラルコンテナ](/ja/docs/concepts/workloads/pods/ephemeral-containers/)を注入してデバッグすることもできます。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Podとは何か？
|
||||
|
||||
{{< note >}}
|
||||
KubernetesはDockerだけでなく複数の{{< glossary_tooltip text="コンテナランタイム" term_id="container-runtime" >}}をサポートしていますが、[Docker](https://www.docker.com/)が最も一般的に知られたランタイムであるため、Docker由来の用語を使ってPodを説明するのが理解の助けとなります。
|
||||
{{< /note >}}
|
||||
|
||||
Podの共有コンテキストは、Dockerコンテナを隔離するのに使われているのと同じ、Linuxのnamespaces、cgroups、場合によっては他の隔離技術の集合を用いて作られます。Podのコンテキスト内では、各アプリケーションが追加の準隔離技術を適用することもあります。
|
||||
|
||||
Dockerの概念を使って説明すると、Podは共有の名前空間と共有ファイルシステムのボリュームを持つDockerコンテナのグループに似ています。
|
||||
|
||||
## Podを使用する
|
||||
|
||||
通常、たとえ単一のコンテナしか持たないシングルトンのPodだとしても、自分でPodを直接作成する必要はありません。その代わりに、{{< glossary_tooltip text="Deployment"
|
||||
term_id="deployment" >}}や{{< glossary_tooltip text="Job" term_id="job" >}}などのワークロードリソースを使用してPodを作成します。もしPodが状態を保持する必要がある場合は、{{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}リソースを使用することを検討してください。
|
||||
|
||||
Kubernetesクラスター内のPodは、主に次の2種類の方法で使われます。
|
||||
|
||||
* **単一のコンテナを稼働させるPod**。「1Pod1コンテナ」構成のモデルは、Kubernetesでは最も一般的なユースケースです。このケースでは、ユーザーはPodを単一のコンテナのラッパーとして考えることができます。Kubernetesはコンテナを直接管理するのではなく、Podを管理します。
|
||||
* **協調して稼働させる必要がある複数のコンテナを稼働させるPod**。単一のPodは、密に結合してリソースを共有する必要があるような、同じ場所で稼働する複数のコンテナからなるアプリケーションをカプセル化することもできます。これらの同じ場所で稼働するコンテナ群は、単一のまとまりのあるサービスのユニットを構成します。たとえば、1つのコンテナが共有ボリュームからファイルをパブリックに配信し、別の*サイドカー*コンテナがそれらのファイルを更新するという構成が考えられます。Podはこれらの複数のコンテナ、ストレージリソース、一時的なネットワークIDなどを、単一のユニットとしてまとめます。
|
||||
|
||||
{{< note >}}
|
||||
複数のコンテナを同じ場所で同時に管理するように単一のPod内にグループ化するのは、比較的高度なユースケースです。このパターンを使用するのは、コンテナが密に結合しているような特定のインスタンス内でのみにするべきです。
|
||||
{{< /note >}}
|
||||
|
||||
各Podは、与えられたアプリケーションの単一のインスタンスを稼働するためのものです。もしユーザーのアプリケーションを水平にスケールさせたい場合(例: 複数インスタンスを稼働させる)、複数のPodを使うべきです。1つのPodは各インスタンスに対応しています。Kubernetesでは、これは一般的に*レプリケーション*と呼ばれます。レプリケーションされたPodは、通常ワークロードリソースと、それに対応する{{< glossary_tooltip text="コントローラー" term_id="controller" >}}によって、作成・管理されます。
|
||||
|
||||
Kubernetesがワークロードリソースとそのコントローラーを活用して、スケーラブルで自動回復するアプリケーションを実装する方法については、詳しくは[Podとコントローラー](#pods-and-controllers)を参照してください。
|
||||
|
||||
### Podが複数のコンテナを管理する方法
|
||||
|
||||
Podは、まとまりの強いサービスのユニットを構成する、複数の協調する(コンテナとして実行される)プロセスをサポートするために設計されました。単一のPod内の複数のコンテナは、クラスター内の同じ物理または仮想マシン上で、自動的に同じ場所に配置・スケジューリングされます。コンテナ間では、リソースや依存関係を共有したり、お互いに通信したり、停止するときにはタイミングや方法を協調して実行できます。
|
||||
|
||||
たとえば、あるコンテナが共有ボリューム内のファイルを配信するウェブサーバーとして動作し、別の「サイドカー」コンテナがリモートのリソースからファイルをアップデートするような構成が考えられます。この構成を以下のダイアグラムに示します。
|
||||
|
||||
{{< figure src="/images/docs/pod.svg" alt="Podのダイアグラムの例" width="50%" >}}
|
||||
|
||||
Podによっては、{{< glossary_tooltip text="appコンテナ" term_id="app-container" >}}に加えて{{< glossary_tooltip text="initコンテナ" term_id="init-container" >}}を持っている場合があります。initコンテナはappコンテナが起動する前に実行・完了するコンテナです。
|
||||
|
||||
Podは、Podを構成する複数のコンテナに対して、[ネットワーク](#pod-networking)と[ストレージ](#pod-storage)の2種類の共有リソースを提供します。
|
||||
|
||||
## Podを利用する
|
||||
|
||||
通常Kubernetesでは、たとえ単一のコンテナしか持たないシングルトンのPodだとしても、個別のPodを直接作成することはめったにありません。その理由は、Podがある程度一時的で使い捨てできる存在として設計されているためです。Podが作成されると(あなたが直接作成した場合でも、{{< glossary_tooltip text="コントローラー" term_id="controller" >}}が間接的に作成した場合でも)、新しいPodはクラスター内の{{< glossary_tooltip term_id="node" >}}上で実行されるようにスケジューリングされます。Podは、実行が完了するか、Podオブジェクトが削除されるか、リソース不足によって*強制退去*されるか、ノードが停止するまで、そのノード上にとどまります。
|
||||
|
||||
{{< note >}}
|
||||
Pod内のコンテナの再起動とPodの再起動を混同しないでください。Podはプロセスではなく、コンテナが実行するための環境です。Podは削除されるまでは残り続けます。
|
||||
{{< /note >}}
|
||||
|
||||
Podオブジェクトのためのマニフェストを作成したときは、指定したPodの名前が有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)であることを確認してください。
|
||||
|
||||
### Podとコンテナコントローラー {#pods-and-controllers}
|
||||
|
||||
ワークロードリソースは、複数のPodを作成・管理するために利用できます。リソースに対応するコントローラーが、複製やロールアウトを扱い、Podの障害時には自動回復を行います。たとえば、あるノードに障害が発生した場合、コントローラーはそのノードの動作が停止したことを検知し、代わりのPodを作成します。そして、スケジューラーが代わりのPodを健全なノード上に配置します。
|
||||
|
||||
以下に、1つ以上のPodを管理するワークロードリソースの一例をあげます。
|
||||
|
||||
* {{< glossary_tooltip text="Deployment" term_id="deployment" >}}
|
||||
* {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}
|
||||
* {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}
|
||||
|
||||
### Podテンプレート
|
||||
|
||||
{{< glossary_tooltip text="workload" term_id="workload" >}}リソース向けのコントローラーは、Podを*Podテンプレート*を元に作成し、あなたの代わりにPodを管理してくれます。
|
||||
|
||||
PodTemplateはPodを作成するための仕様で、[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)、[Job](/ja/docs/concepts/workloads/controllers/job/)、[DaemonSet](/ja/docs/concepts/workloads/controllers/daemonset/)などのワークロードリソースの中に含まれています。
|
||||
|
||||
ワークロードリソースに対応する各コントローラーは、ワークロードオブジェクト内にある`PodTemplate`を使用して実際のPodを作成します。`PodTemplate`は、アプリを実行するために使われるワークロードリソースがどんな種類のものであれ、その目的の状態の一部を構成するものです。
|
||||
|
||||
以下は、単純なJobのマニフェストの一例で、1つのコンテナを実行する`template`があります。Pod内のコンテナはメッセージを出力した後、一時停止します。
|
||||
|
||||
```yaml
|
||||
apiVersion: batch/v1
|
||||
kind: Job
|
||||
metadata:
|
||||
name: hello
|
||||
spec:
|
||||
template:
|
||||
# これがPodテンプレートです
|
||||
spec:
|
||||
containers:
|
||||
- name: hello
|
||||
image: busybox
|
||||
command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']
|
||||
restartPolicy: OnFailure
|
||||
# Podテンプレートはここまでです
|
||||
```
|
||||
|
||||
Podテンプレートを修正するか新しいPodに切り替えたとしても、すでに存在するPodには直接の影響はありません。ワークロードリソース内のPodテンプレートを変更すると、そのリソースは更新されたテンプレートを使用して代わりとなるPodを作成する必要があります。
|
||||
|
||||
たとえば、StatefulSetコントローラーは、各StatefulSetごとに、実行中のPodが現在のPodテンプレートに一致することを保証します。Podテンプレートを変更するためにStatefulSetを編集すると、StatefulSetは更新されたテンプレートを元にした新しいPodを作成するようになります。最終的に、すべての古いPodが新しいPodで置き換えられ、更新は完了します。
|
||||
|
||||
各ワークロードリソースは、Podテンプレートへの変更を処理するための独自のルールを実装しています。特にStatefulSetについて更に詳しく知りたい場合は、StatefulSetの基本チュートリアル内の[アップデート戦略](/ja/docs/tutorials/stateful-application/basic-stateful-set/#updating-statefulsets)を読んでください。
|
||||
|
||||
ノード上では、{{< glossary_tooltip term_id="kubelet" text="kubelet" >}}はPodテンプレートに関する詳細について監視や管理を直接行うわけではありません。こうした詳細は抽象化されています。こうした抽象化や関心の分離のおかげでシステムのセマンティクスが単純化され、既存のコードを変更せずにクラスターの動作を容易に拡張できるようになっているのです。
|
||||
|
||||
## リソースの共有と通信
|
||||
|
||||
Podは、データの共有と構成するコンテナ間での通信を可能にします。
|
||||
|
||||
### Pod内のストレージ {#pod-storage}
|
||||
|
||||
Podでは、共有ストレージである{{< glossary_tooltip text="ボリューム" term_id="volume" >}}の集合を指定できます。Pod内のすべてのコンテナは共有ボリュームにアクセスできるため、それら複数のコンテナでデータを共有できるようになります。また、ボリュームを利用すれば、Pod内のコンテナの1つに再起動が必要になった場合にも、Pod内の永続化データを保持し続けられるようにできます。Kubernetesの共有ストレージの実装方法とPodで利用できるようにする方法に関するさらに詳しい情報は、[ストレージ](/ja/docs/concepts/storage/)を読んでください。
|
||||
|
||||
### Podネットワーク
|
||||
|
||||
各Podには、各アドレスファミリーごとにユニークなIPアドレスが割り当てられます。Pod内のすべてのコンテナは、IPアドレスとネットワークポートを含むネットワーク名前空間を共有します。Podの中では(かつその場合に**のみ**)、そのPod内のコンテナは`localhost`を使用して他のコンテナと通信できます。Podの内部にあるコンテナが*Podの外部にある*エンティティと通信する場合、(ポートなどの)共有ネットワークリソースの使い方をコンテナ間で調整しなければなりません。Pod内では、コンテナはIPアドレスとポートの空間を共有するため、`localhost`で他のコンテナにアクセスできます。また、Pod内のコンテナは、SystemVのセマフォやPOSIXの共有メモリなど、標準のプロセス間通信を使って他のコンテナと通信することもできます。異なるPod内のコンテナは異なるIPアドレスを持つため、[特別な設定](/docs/concepts/policy/pod-security-policy/)をしない限りIPCで通信することはできません。異なるPod上で実行中のコンテナ間でやり取りをしたい場合は、IPネットワークを使用して通信できます。
|
||||
|
||||
Pod内のコンテナは、システムのhostnameがPodに設定した`name`と同一であると考えます。ネットワークについての詳しい情報は、[ネットワーク](/ja/docs/concepts/cluster-administration/networking/)で説明しています。
|
||||
|
||||
## コンテナの特権モード
|
||||
|
||||
Pod内のどんなコンテナも、`privileged`フラグをコンテナのspecの[security context](/docs/tasks/configure-pod-container/security-context/)に設定することで、特権モード(privileged mode)を有効にできます。これは、ネットワークスタックの操作やハードウェアデバイスへのアクセスなど、オペレーティングシステムの管理者の権限が必要なコンテナの場合に役に立ちます。特権コンテナ内のプロセスはコンテナ外のプロセスが利用できるのとほぼ同等の権限を取得します。
|
||||
|
||||
{{< note >}}
|
||||
この設定を有効にするには、{{< glossary_tooltip text="コンテナランタイム" term_id="container-runtime" >}}が特権コンテナの概念をサポートしていなければなりません。
|
||||
{{< /note >}}
|
||||
|
||||
## static Pod
|
||||
|
||||
*static Pod*は、{{< glossary_tooltip text="APIサーバー" term_id="kube-apiserver" >}}には管理されない、特定のノード上でkubeletデーモンによって直接管理されるPodのことです。大部分のPodはコントロープレーン(たとえば{{< glossary_tooltip text="Deployment" term_id="deployment" >}})によって管理されますが、static Podの場合はkubeletが各static Podを直接管理します(障害時には再起動します)。
|
||||
|
||||
static Podは常に特定のノード上の1つの{{< glossary_tooltip term_id="kubelet" >}}に紐付けられます。static Podの主な用途は、セルフホストのコントロールプレーンを実行すること、言い換えると、kubeletを使用して個別の[コントロールプレーンコンポーネント](/ja/docs/concepts/overview/components/#control-plane-components)を管理することです。
|
||||
|
||||
kubeletは自動的にKubernetes APIサーバー上に各static Podに対応する{{< glossary_tooltip text="ミラーPod" term_id="mirror-pod" >}}の作成を試みます。つまり、ノード上で実行中のPodはAPIサーバー上でも見えるようになるけれども、APIサーバー上から制御はできないということです。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)について学ぶ。
|
||||
* [PodPreset](/ja/docs/concepts/workloads/pods/podpreset/)について学ぶ。
|
||||
* [RuntimeClass](/ja/docs/concepts/containers/runtime-class/)と、それを用いてPodごとに異なるコンテナランタイム設定する方法について学ぶ。
|
||||
* [Podトポロジー分布制約](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)について読む。
|
||||
* [PodDisruptionBudget](/ja/docs/concepts/workloads/pods/disruptions/)と、それを使用してクラスターの停止(disruption)中にアプリケーションの可用性を管理する方法について読む。
|
||||
* PodはKubernetes REST API内のトップレベルのリソースです。[Pod](/ja/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)オブジェクトの定義では、オブジェクトの詳細について記述されています。
|
||||
* [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)では、2つ以上のコンテナを利用する場合の一般的なレイアウトについて説明しています。
|
||||
|
||||
Kubernetesが共通のPod APIを他のリソース内(たとえば{{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}や{{< glossary_tooltip text="Deployment" term_id="deployment" >}}など)にラッピングしている理由の文脈を理解するためには、Kubernetes以前から存在する以下のような既存技術について読むのが助けになります。
|
||||
|
||||
* [Aurora](https://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)
|
||||
* [Borg](https://research.google.com/pubs/pub43438.html)
|
||||
* [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html)
|
||||
* [Omega](https://research.google/pubs/pub41684/)
|
||||
* [Tupperware](https://engineering.fb.com/data-center-engineering/tupperware/)
|
||||
|
||||
@@ -42,7 +42,7 @@ weight: 80
|
||||
|
||||
エフェメラルコンテナを利用する場合には、他のコンテナ内のプロセスにアクセスできるように、[プロセス名前空間の共有](/ja/docs/tasks/configure-pod-container/share-process-namespace/)を有効にすると便利です。
|
||||
|
||||
エフェメラルコンテナを利用してトラブルシューティングを行う例については、[デバッグ用のエフェメラルコンテナを使用してデバッグする](/docs/tasks/debug-application-cluster/debug-running-pod/#debugging-with-ephemeral-debug-container)を参照してください。
|
||||
エフェメラルコンテナを利用してトラブルシューティングを行う例については、[デバッグ用のエフェメラルコンテナを使用してデバッグする](/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container)を参照してください。
|
||||
|
||||
## Ephemeral containers API
|
||||
|
||||
@@ -59,7 +59,7 @@ weight: 80
|
||||
"apiVersion": "v1",
|
||||
"kind": "EphemeralContainers",
|
||||
"metadata": {
|
||||
"name": "example-pod"
|
||||
"name": "example-pod"
|
||||
},
|
||||
"ephemeralContainers": [{
|
||||
"command": [
|
||||
|
||||
@@ -20,7 +20,7 @@ Initコンテナは下記の項目をのぞいて、通常のコンテナと全
|
||||
* Initコンテナは常に完了するまで稼働します。
|
||||
* 各Initコンテナは、次のInitコンテナが稼働する前に正常に完了しなくてはなりません。
|
||||
|
||||
もしあるPodの単一のInitコンテナが失敗した場合、KubernetesはInitコンテナが成功するまで何度もそのPodを再起動します。しかし、もしそのPodの`restartPolicy`がNeverの場合、再起動されません。
|
||||
もしあるPodの単一のInitコンテナが失敗した場合、Kubeletは成功するまで何度もそのInitコンテナを再起動します。しかし、もしそのPodの`restartPolicy`がNeverで、そのPodの起動時にInitコンテナが失敗した場合、KubernetesはそのPod全体を失敗として扱います。
|
||||
|
||||
PodにInitコンテナを指定するためには、Podの仕様にそのアプリケーションの`containers`配列と並べて、`initContainers`フィールドを[Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)型のオブジェクトの配列として指定してください。
|
||||
Initコンテナのステータスは、`.status.initContainerStatuses`フィールドにコンテナのステータスの配列として返されます(`.status.containerStatuses`と同様)。
|
||||
|
||||
@@ -8,7 +8,7 @@ weight: 30
|
||||
|
||||
このページではPodのライフサイクルについて説明します。Podは定義されたライフサイクルに従い `Pending`[フェーズ](#pod-phase)から始まり、少なくとも1つのプライマリーコンテナが正常に開始した場合は`Running`を経由し、次に失敗により終了したコンテナの有無に応じて、`Succeeded`または`Failed`フェーズを経由します。
|
||||
|
||||
Podの実行中、kubeletはコンテナを再起動して、ある種の障害を処理できます。Pod内で、Kubernetesはさまざまなコンテナの[ステータス](#container-states)を追跡して、対処します。
|
||||
Podの実行中、kubeletはコンテナを再起動して、ある種の障害を処理できます。Pod内で、Kubernetesはさまざまなコンテナの[ステータス](#container-states)を追跡して、回復させるためのアクションを決定します。
|
||||
|
||||
Kubernetes APIでは、Podには仕様と実際のステータスの両方があります。Podオブジェクトのステータスは、[PodのCondition](#pod-conditions)のセットで構成されます。[カスタムのReadiness情報](#pod-readiness-gate)をPodのConditionデータに挿入することもできます。
|
||||
|
||||
@@ -43,13 +43,13 @@ Podの各フェーズの値と意味は厳重に守られています。ここ
|
||||
|
||||
これらが`phase`の取りうる値です。
|
||||
|
||||
値 | 概要
|
||||
:-----|:-----------
|
||||
`Pending` | PodがKubernetesクラスターによって承認されましたが、1つ以上のコンテナがセットアップされて稼働する準備ができていません。これには、スケジュールされるまでの時間と、ネットワーク経由でイメージをダウンロードするための時間などが含まれます。
|
||||
`Running` | PodがNodeにバインドされ、すべてのコンテナが作成されました。少なくとも1つのコンテナがまだ実行されているか、開始または再起動中です。
|
||||
`Succeeded` |Pod内のすべてのコンテナが正常に終了し、再起動されません。
|
||||
`Failed` | Pod内のすべてのコンテナが終了し、少なくとも1つのコンテナが異常終了しました。つまり、コンテナはゼロ以外のステータスで終了したか、システムによって終了されました。
|
||||
`Unknown` | 何らかの理由によりPodの状態を取得できませんでした。このフェーズは通常はPodのホストとの通信エラーにより発生します。
|
||||
値 | 概要
|
||||
:-----------|:-----------
|
||||
`Pending` | PodがKubernetesクラスターによって承認されましたが、1つ以上のコンテナがセットアップされて稼働する準備ができていません。これには、スケジュールされるまでの時間と、ネットワーク経由でイメージをダウンロードするための時間などが含まれます。
|
||||
`Running` | PodがNodeにバインドされ、すべてのコンテナが作成されました。少なくとも1つのコンテナがまだ実行されているか、開始または再起動中です。
|
||||
`Succeeded` | Pod内のすべてのコンテナが正常に終了し、再起動されません。
|
||||
`Failed` | Pod内のすべてのコンテナが終了し、少なくとも1つのコンテナが異常終了しました。つまり、コンテナはゼロ以外のステータスで終了したか、システムによって終了されました。
|
||||
`Unknown` | 何らかの理由によりPodの状態を取得できませんでした。このフェーズは通常はPodのホストとの通信エラーにより発生します。
|
||||
|
||||
Nodeが停止するか、クラスタの残りの部分から切断された場合、Kubernetesは失われたNode上のすべてのPodの`Phase`をFailedに設定するためのポリシーを適用します。
|
||||
|
||||
@@ -69,7 +69,7 @@ Podのコンテナの状態を確認するには`kubectl describe pod [POD_NAME]
|
||||
|
||||
### `Running` {#container-state-running}
|
||||
|
||||
`Running`状態はコンテナが問題なく実行されていることを示します。コンテナがRunning状態に入る前に`postStart`フック（もしあれば）が実行されます。`Running`状態のコンテナを持つPodに対して`kubectl`コマンドを使用すると、そのコンテナが`Running`状態になった時刻が表示されます。
|
||||
`Running`状態はコンテナが問題なく実行されていることを示します。`postStart`フックが構成されていた場合、それはすでに実行が完了しています。`Running`状態のコンテナを持つPodに対して`kubectl`コマンドを使用すると、そのコンテナが`Running`状態になった時刻が表示されます。
|
||||
|
||||
### `Terminated` {#container-state-terminated}
|
||||
|
||||
@@ -81,7 +81,7 @@ Podのコンテナの状態を確認するには`kubectl describe pod [POD_NAME]
|
||||
|
||||
Podの`spec`には、Always、OnFailure、またはNeverのいずれかの値を持つ`restartPolicy`フィールドがあります。デフォルト値はAlwaysです。
|
||||
|
||||
`restartPolicy`は、Pod内のすべてのコンテナに適用されます。`restartPolicy`は、同じNode上のkubeletによるコンテナの再起動のみを参照します。Pod内のコンテナが終了した後、kubeletは5分を上限とする指数バックオフ遅延（10秒、20秒、40秒...）でコンテナを再起動します。コンテナが10分間問題なく実行されると、kubeletはコンテナの再起動バックオフタイマーをリセットします。
|
||||
`restartPolicy`は、Pod内のすべてのコンテナに適用されます。`restartPolicy`は、同じNode上のkubeletによるコンテナの再起動のみを参照します。Pod内のコンテナが終了した後、kubeletは5分を上限とする指数バックオフ遅延（10秒、20秒、40秒...）でコンテナを再起動します。コンテナが10分間実行されると、kubeletはコンテナの再起動バックオフタイマーをリセットします。
|
||||
|
||||
## PodのCondition {#pod-conditions}
|
||||
|
||||
@@ -148,7 +148,7 @@ Podのコンテナは準備完了ですが、少なくとも1つのカスタム
|
||||
|
||||
## コンテナのProbe {#container-probes}
|
||||
|
||||
[Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) は [kubelet](/docs/admin/kubelet/) により定期的に実行されるコンテナの診断です。診断を行うために、kubeletはコンテナに実装された [Handler](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core)を呼びます。Handlerには次の3つの種類があります:
|
||||
[Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) は [kubelet](/docs/reference/command-line-tools-reference/kubelet/) により定期的に実行されるコンテナの診断です。診断を行うために、kubeletはコンテナに実装された [Handler](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core)を呼びます。Handlerには次の3つの種類があります:
|
||||
|
||||
* [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core):
|
||||
コンテナ内で特定のコマンドを実行します。コマンドがステータス0で終了した場合に診断を成功と見まします。
|
||||
@@ -209,7 +209,7 @@ Podが削除されたときにリクエストを来ないようにするため
|
||||
|
||||
### startupProbeをいつ使うべきか? {#when-should-you-use-a-startup-probe}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
|
||||
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
|
||||
|
||||
startupProbeは、サービスの開始に時間がかかるコンテナを持つポッドに役立ちます。livenessProbeの間隔を長く設定するのではなく、コンテナの起動時に別のProbeを構成して、livenessProbeの間隔よりも長い時間を許可できます。
|
||||
コンテナの起動時間が、`initialDelaySeconds + failureThreshold x periodSeconds`よりも長い場合は、livenessProbeと同じエンドポイントをチェックするためにstartupProbeを指定します。`periodSeconds`のデフォルトは30秒です。次に、`failureThreshold`をlivenessProbeのデフォルト値を変更せずにコンテナが起動できるように、十分に高い値を設定します。これによりデッドロックを防ぐことができます。
|
||||
@@ -220,7 +220,7 @@ Podは、クラスター内のNodeで実行中のプロセスを表すため、
|
||||
|
||||
ユーザーは削除を要求可能であるべきで、プロセスがいつ終了するかを知ることができなければなりませんが、削除が最終的に完了することも保証できるべきです。ユーザーがPodの削除を要求すると、システムはPodが強制終了される前に意図された猶予期間を記録および追跡します。強制削除までの猶予期間がある場合、{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}正常な終了を試みます。
|
||||
|
||||
通常、コンテナランタイムは各コンテナのメインプロセスにTERMシグナルを送信します。猶予期間が終了すると、プロセスにKILLシグナルが送信され、Podは{{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}から削除されます。プロセスの終了を待っている間にkubeletかコンテナランタイムの管理サービスが再起動されると、クラスターは元の猶予期間を含めて、最初からリトライされます。
|
||||
通常、コンテナランタイムは各コンテナのメインプロセスにTERMシグナルを送信します。多くのコンテナランタイムは、コンテナイメージで定義されたSTOPSIGNAL値を尊重し、TERMの代わりにこれを送信します。猶予期間が終了すると、プロセスにKILLシグナルが送信され、Podは{{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}から削除されます。プロセスの終了を待っている間にkubeletかコンテナランタイムの管理サービスが再起動されると、クラスターは元の猶予期間を含めて、最初からリトライされます。
|
||||
|
||||
フローの例は下のようになります。
|
||||
|
||||
|
||||
Reference in New Issue
Block a user