[ja] s/クラスタ/クラスター/g
ystkfujii
parent
7b7fa2c8ec
commit
26a4e5fd41
|
|
@ -13,7 +13,7 @@ Kubernetesはv1.20より新しいバージョンで、コンテナランタイ
|
|||
|
||||
概要: ランタイムとしてのDockerは、Kubernetesのために開発された[Container Runtime Interface(CRI)](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/)を利用しているランタイムを選んだ結果としてサポートされなくなります。しかし、Dockerによって生成されたイメージはこれからも、今までもそうだったように、みなさんのクラスターで使用可能です。
|
||||
|
||||
もし、あなたがKubernetesのエンドユーザーであるならば、多くの変化はないでしょう。これはDockerの死を意味するものではありませんし、開発ツールとして今後Dockerを使用するべきでない、使用することは出来ないと言っているのでもありません。Dockerはコンテナを作成するのに便利なツールですし、docker buildコマンドで作成されたイメージはKubernetesクラスタ上でこれからも動作可能なのです。
|
||||
もし、あなたがKubernetesのエンドユーザーであるならば、多くの変化はないでしょう。これはDockerの死を意味するものではありませんし、開発ツールとして今後Dockerを使用するべきでない、使用することは出来ないと言っているのでもありません。Dockerはコンテナを作成するのに便利なツールですし、docker buildコマンドで作成されたイメージはKubernetesクラスター上でこれからも動作可能なのです。
|
||||
|
||||
もし、GKE、EKS、AKSといったマネージドKubernetesサービス(それらはデフォルトで[containerdを使用しています](https://github.com/Azure/AKS/releases/tag/2020-11-16))を使っているのなら、ワーカーノードがサポート対象のランタイムを使用しているか、Dockerのサポートが将来のK8sバージョンで切れる前に確認しておく必要があるでしょう。
|
||||
もし、ノードをカスタマイズしているのなら、環境やRuntimeの仕様に合わせて更新する必要があるでしょう。サービスプロバイダーと確認し、アップグレードのための適切なテストと計画を立ててください。
|
||||
|
|
@ -24,7 +24,7 @@ Kubernetesはv1.20より新しいバージョンで、コンテナランタイ
|
|||
ここで議論になっているのは2つの異なる場面についてであり、それが混乱の原因になっています。Kubernetesクラスターの内部では、Container runtimeと呼ばれるものがあり、それはImageをPullし起動する役目を持っています。Dockerはその選択肢として人気があります(他にはcontainerdやCRI-Oが挙げられます)が、しかしDockerはそれ自体がKubernetesの一部として設計されているわけではありません。これが問題の原因となっています。
|
||||
|
||||
お分かりかと思いますが、ここで”Docker”と呼んでいるものは、ある1つのものではなく、その技術的な体系の全体であり、その一部には"containerd"と呼ばれるものもあり、これはそれ自体がハイレベルなContainer runtimeとなっています。Dockerは素晴らしいもので、便利です。なぜなら、多くのUXの改善がされており、それは人間が開発を行うための操作を簡単にしているのです。しかし、それらはKubernetesに必要なものではありません。Kubernetesは人間ではないからです。
|
||||
このhuman-friendlyな抽象化レイヤが作られてために、結果としてはKubernetesクラスタはDockershimと呼ばれるほかのツールを使い、本当に必要な機能つまりcontainerdを利用してきました。これは素晴らしいとは言えません。なぜなら、我々がメンテする必要のあるものが増えますし、それは問題が発生する要因ともなります。今回の変更で実際に行われることというのは、Dockershimを最も早い場合でv1.23のリリースでkubeletから除外することです。その結果として、Dockerのサポートがなくなるということなのです。
|
||||
このhuman-friendlyな抽象化レイヤが作られてために、結果としてはKubernetesクラスターはDockershimと呼ばれるほかのツールを使い、本当に必要な機能つまりcontainerdを利用してきました。これは素晴らしいとは言えません。なぜなら、我々がメンテする必要のあるものが増えますし、それは問題が発生する要因ともなります。今回の変更で実際に行われることというのは、Dockershimを最も早い場合でv1.23のリリースでkubeletから除外することです。その結果として、Dockerのサポートがなくなるということなのです。
|
||||
ここで、containerdがDockerに含まれているなら、なぜDockershimが必要なのかと疑問に思われる方もいるでしょう。
|
||||
|
||||
DockerはCRI([Container Runtime Interface](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/))に準拠していません。もしそうであればshimは必要ないのですが、現実はそうでありません。
|
||||
|
|
@ -35,7 +35,7 @@ DockerはCRI([Container Runtime Interface](https://kubernetes.io/blog/2016/12/co
|
|||
## では開発者にとって、この変更は何を意味するのか。これからもDockerfileを使ってよいのか。これからもDockerでビルドを行ってよいのか。
|
||||
|
||||
この変更は、Dockerを直接操作している多くのみなさんとは別の場面に影響を与えるでしょう。
|
||||
みなさんが開発を行う際に使用しているDockerと、Kubernetesクラスタの内部で使われているDocker runtimeは関係ありません。これがわかりにくいことは理解しています。開発者にとって、Dockerはこれからも便利なものであり、このアナウンスがあった前と変わらないでしょう。DockerでビルドされたImageは、決してDockerでだけ動作するというわけではありません。それはOCI([Open Container Initiative](https://opencontainers.org/)) Imageと呼ばれるものです。あらゆるOCI準拠のImageは、それを何のツールでビルドしたかによらず、Kubernetesから見れば同じものなのです。[containerd](https://containerd.io/)も[CRI-O](https://cri-o.io/)も、そのようなImageをPullし、起動することが出来ます。
|
||||
みなさんが開発を行う際に使用しているDockerと、Kubernetesクラスターの内部で使われているDocker runtimeは関係ありません。これがわかりにくいことは理解しています。開発者にとって、Dockerはこれからも便利なものであり、このアナウンスがあった前と変わらないでしょう。DockerでビルドされたImageは、決してDockerでだけ動作するというわけではありません。それはOCI([Open Container Initiative](https://opencontainers.org/)) Imageと呼ばれるものです。あらゆるOCI準拠のImageは、それを何のツールでビルドしたかによらず、Kubernetesから見れば同じものなのです。[containerd](https://containerd.io/)も[CRI-O](https://cri-o.io/)も、そのようなImageをPullし、起動することが出来ます。
|
||||
これがコンテナの仕様について、共通の仕様を策定している理由なのです。
|
||||
|
||||
さて、この変更は決定しています。いくつかの問題は発生するかもしてませんが、決して壊滅的なものではなく、ほとんどの場合は良い変化となるでしょう。Kubernetesをどのように使用しているかによりますが、この変更が特に何の影響も及ぼさない人もいるでしょうし、影響がとても少ない場合もあります。長期的に見れば、物事を簡単にするのに役立つものです。
|
||||
|
|
|
|||
|
|
@ -65,10 +65,10 @@ case_study_details:
|
|||
<p>Nordstrom Technologyの場合、クラウドネイティブへの移行によって、開発と運用の効率が大幅に向上しています。Kubernetesを利用する開発者はより迅速にデプロイでき、アプリケーションの価値の構築に専念できます。こうしたノウハウを取り入れるために、1つのチームにおいてクラウド上に仮想マシンを構築し、マージからデプロイまでに25分かかるところからスタートしました。Kubernetesへの切り替えにより、プロセスが5倍高速化され、マージからデプロイまでの時間が5分に改善しました。</p>
|
||||
|
||||
{{< case-studies/quote >}}
|
||||
「Kubernetesを使用することで、クラスタの効率化を図ることもなく、現在のCPU使用率は40%、つまり10倍になりました。直接クラウドに移行した場合には2600台以上のVMになるところが、同数の顧客用Podで済むようになりました。これらのPodを40台のVMで実行しているため、運用上のオーバーヘッドが大幅に削減されました。」
|
||||
「Kubernetesを使用することで、クラスターの効率化を図ることもなく、現在のCPU使用率は40%、つまり10倍になりました。直接クラウドに移行した場合には2600台以上のVMになるところが、同数の顧客用Podで済むようになりました。これらのPodを40台のVMで実行しているため、運用上のオーバーヘッドが大幅に削減されました。」
|
||||
{{< /case-studies/quote >}}
|
||||
|
||||
<p>スピードは素晴らしく、簡単に実証できますが、より大きな影響はおそらくその運用効率にあります。「AWSで何千ものVMを実行する場合、全体的な平均CPU使用率は約4%です。」とPatel氏は言います。「Kubernetesを使用することで、クラスタの効率化を図ることもなく、現在のCPU使用率は40%、つまり10倍になりました。直接クラウドに移行した場合には2600台以上のVMになるところが、同数の顧客用Podで済むようになりました。これらのPodを40台のVMで実行しているため、運用上のオーバーヘッドが大幅に削減されました。」</p>
|
||||
<p>スピードは素晴らしく、簡単に実証できますが、より大きな影響はおそらくその運用効率にあります。「AWSで何千ものVMを実行する場合、全体的な平均CPU使用率は約4%です。」とPatel氏は言います。「Kubernetesを使用することで、クラスターの効率化を図ることもなく、現在のCPU使用率は40%、つまり10倍になりました。直接クラウドに移行した場合には2600台以上のVMになるところが、同数の顧客用Podで済むようになりました。これらのPodを40台のVMで実行しているため、運用上のオーバーヘッドが大幅に削減されました。」</p>
|
||||
|
||||
<p>Nordstrom TechnologyはオンプレミスのベアメタルでKubernetesを実行することも検討しています。Patel氏は言います。「オンプレミスのKubernetesクラスターを構築できれば、クラウドの力を活用してオンプレミスでリソースを迅速にプロビジョニングできます。次に、開発者にとってのインターフェースはKubernetesです。Kubernetesのみと連携しているため、自社のサービスがオンプレミスにデプロイされていることに気付かないこともあります。」</p>
|
||||
|
||||
|
|
|
|||
|
|
@ -46,7 +46,7 @@ cloud-controller-managerは、プラグイン機構を用い、異なるクラ
|
|||
|
||||
#### ルートコントローラー
|
||||
|
||||
ルートコントローラーは、クラスタ内の異なるノード上で稼働しているコンテナが相互に通信できるように、クラウド内のルートを適切に設定する責務を持ちます。
|
||||
ルートコントローラーは、クラスター内の異なるノード上で稼働しているコンテナが相互に通信できるように、クラウド内のルートを適切に設定する責務を持ちます。
|
||||
|
||||
クラウドプロバイダーによっては、ルートコントローラーはPodネットワークのIPアドレスのブロックを割り当てることもあります。
|
||||
|
||||
|
|
|
|||
|
|
@ -217,7 +217,7 @@ kubeletが`NodeStatus`とLeaseオブジェクトの作成および更新を担
|
|||
|
||||
ノードを複数のアベイラビリティゾーンに分散させる主な理由は、1つのゾーン全体が停止したときにワークロードを正常なゾーンに移動できることです。
|
||||
したがって、ゾーン内のすべてのノードが異常である場合、ノードコントローラーは通常のレート `--node-eviction-rate`で退役します。
|
||||
コーナーケースは、すべてのゾーンが完全にUnhealthyである（すなわち、クラスタ内にHealthyなノードがない）場合です。
|
||||
コーナーケースは、すべてのゾーンが完全にUnhealthyである（すなわち、クラスター内にHealthyなノードがない）場合です。
|
||||
このような場合、ノードコントローラーはマスター接続に問題があると見なし、接続が回復するまですべての退役を停止します。
|
||||
|
||||
ノードコントローラーは、Podがtaintを許容しない場合、 `NoExecute`のtaintを持つノード上で実行されているPodを排除する責務もあります。
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ weight: 120
|
|||
|
||||
## インフラストラクチャ {#infrastructure}
|
||||
|
||||
* [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation)は仮想マシンをKubernetes上で実行するためのアドオンです。通常、ベアメタルのクラスタで実行します。
|
||||
* [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation)は仮想マシンをKubernetes上で実行するためのアドオンです。通常、ベアメタルのクラスターで実行します。
|
||||
* [node problem detector](https://github.com/kubernetes/node-problem-detector)はLinuxノード上で動作し、システムの問題を[Event](/docs/reference/kubernetes-api/cluster-resources/event-v1/)または[ノードのCondition](/ja/docs/concepts/architecture/nodes/#condition)として報告します。
|
||||
|
||||
## レガシーなアドオン {#legacy-add-ons}
|
||||
|
|
|
|||
|
|
@ -378,10 +378,10 @@ Kubernetesが使用しないようにする必要があります。
|
|||
## 拡張リソース {#extended-resources}
|
||||
|
||||
拡張リソースは`kubernetes.io`ドメインの外で完全に修飾されたリソース名です。
|
||||
これにより、クラスタオペレーターはKubernetesに組み込まれていないリソースをアドバタイズし、ユーザはそれを利用することができるようになります。
|
||||
これにより、クラスターオペレーターはKubernetesに組み込まれていないリソースをアドバタイズし、ユーザはそれを利用することができるようになります。
|
||||
|
||||
拡張リソースを使用するためには、2つのステップが必要です。
|
||||
第一に、クラスタオペレーターは拡張リソースをアドバタイズする必要があります。
|
||||
第一に、クラスターオペレーターは拡張リソースをアドバタイズする必要があります。
|
||||
第二に、ユーザーはPodで拡張リソースを要求する必要があります。
|
||||
|
||||
### 拡張リソースの管理 {#managing-extended-resources}
|
||||
|
|
@ -394,7 +394,7 @@ Nodeレベルの拡張リソースはNodeに関連付けられています。
|
|||
各Nodeにデバイスプラグインで管理されているリソースをアドバタイズする方法については、[デバイスプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)を参照してください。
|
||||
|
||||
##### その他のリソース {#other-resources}
|
||||
新しいNodeレベルの拡張リソースをアドバタイズするには、クラスタオペレーターはAPIサーバに`PATCH`HTTPリクエストを送信し、クラスタ内のNodeの`status.capacity`に利用可能な量を指定します。
|
||||
新しいNodeレベルの拡張リソースをアドバタイズするには、クラスターオペレーターはAPIサーバに`PATCH`HTTPリクエストを送信し、クラスター内のNodeの`status.capacity`に利用可能な量を指定します。
|
||||
この操作の後、ノードの`status.capacity`には新しいリソースが含まれます。
|
||||
`status.allocatable`フィールドは、kubeletによって非同期的に新しいリソースで自動的に更新されます。
|
||||
スケジューラはPodの適合性を評価する際にNodeの`status.allocatable`値を使用するため、Nodeの容量に新しいリソースを追加してから、そのNodeでリソースのスケジューリングを要求する最初のPodが現れるまでには、短い遅延が生じる可能性があることに注意してください。
|
||||
|
|
@ -513,7 +513,7 @@ Events:
|
|||
同様のエラーメッセージは、メモリー不足による失敗を示唆することもあります(PodExceedsFreeMemory)。
|
||||
一般的に、このタイプのメッセージでPodが保留されている場合は、いくつか試すべきことがあります。
|
||||
|
||||
- クラスタにNodeを追加します。
|
||||
- クラスターにNodeを追加します。
|
||||
- 不要なポッドを終了して、保留中のPodのためのスペースを空けます。
|
||||
- PodがすべてのNodeよりも大きくないことを確認してください。
|
||||
例えば、すべてのNodeが`cpu: 1`の容量を持っている場合、`cpu: 1.1`を要求するPodは決してスケジューリングされません。
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@ weight: 10
|
|||
|
||||
*これは順序付けの必要性を意味します* - `Pod`がアクセスしたい`Service`は`Pod`自身の前に作らなければならず、そうしないと環境変数は注入されません。DNSにはこの制限はありません。
|
||||
|
||||
- （強くお勧めしますが）[クラスターアドオン](/ja/docs/concepts/cluster-administration/addons/)の1つの選択肢はDNSサーバーです。DNSサーバーは、新しい`Service`についてKubernetes APIを監視し、それぞれに対して一連のDNSレコードを作成します。クラスタ全体でDNSが有効になっている場合は、すべての`Pod`が自動的に`Services`の名前解決を行えるはずです。
|
||||
- （強くお勧めしますが）[クラスターアドオン](/ja/docs/concepts/cluster-administration/addons/)の1つの選択肢はDNSサーバーです。DNSサーバーは、新しい`Service`についてKubernetes APIを監視し、それぞれに対して一連のDNSレコードを作成します。クラスター全体でDNSが有効になっている場合は、すべての`Pod`が自動的に`Services`の名前解決を行えるはずです。
|
||||
|
||||
- どうしても必要な場合以外は、Podに`hostPort`を指定しないでください。Podを`hostPort`にバインドすると、Podがスケジュールできる場所の数を制限します、それぞれの<`hostIP`、 `hostPort`、`protocol`>の組み合わせはユニークでなければならないからです。`hostIP`と`protocol`を明示的に指定しないと、Kubernetesはデフォルトの`hostIP`として`0.0.0.0`を、デフォルトの `protocol`として`TCP`を使います。
|
||||
|
||||
|
|
|
|||
|
|
@ -50,7 +50,7 @@ metadata:
|
|||
|
||||
## アプリケーションとアプリケーションのインスタンス
|
||||
|
||||
単一のアプリケーションは、Kubernetesクラスタ内で、いくつかのケースでは同一の名前空間に対して1回または複数回インストールされることがあります。
|
||||
単一のアプリケーションは、Kubernetesクラスター内で、いくつかのケースでは同一の名前空間に対して1回または複数回インストールされることがあります。
|
||||
例えば、WordPressは複数のウェブサイトがあれば、それぞれ別のWordPressが複数回インストールされることがあります。
|
||||
|
||||
アプリケーション名と、アプリケーションのインスタンス名はそれぞれ別に記録されます。
|
||||
|
|
|
|||
|
|
@ -52,7 +52,7 @@ kubectl create deployment nginx --image nginx
|
|||
オブジェクト設定手法に対する長所:
|
||||
|
||||
- コマンドは簡潔、簡単に学ぶことができ、そして覚えやすいです
|
||||
- コマンドではクラスタの設定を変えるのに、わずか1ステップしか必要としません
|
||||
- コマンドではクラスターの設定を変えるのに、わずか1ステップしか必要としません
|
||||
|
||||
オブジェクト設定手法に対する短所:
|
||||
|
||||
|
|
|
|||
|
|
@ -46,7 +46,7 @@ kubectl get pods -n kube-system | grep kube-scheduler
|
|||
|
||||
### デフォルトの閾値
|
||||
|
||||
閾値を指定しない場合、Kubernetesは100ノードのクラスタでは50%、5000ノードのクラスタでは10%になる線形方程式を使用して数値を計算します。自動計算の下限は5%です。
|
||||
閾値を指定しない場合、Kubernetesは100ノードのクラスターでは50%、5000ノードのクラスターでは10%になる線形方程式を使用して数値を計算します。自動計算の下限は5%です。
|
||||
|
||||
つまり、明示的に`percentageOfNodesToScore`を5未満の値を設定しない限り、クラスターの規模に関係なく、kube-schedulerは常に少なくともクラスターの5%のノードに対してスコア付けをします。
|
||||
|
||||
|
|
@ -72,9 +72,9 @@ percentageOfNodesToScore: 50
|
|||
`percentageOfNodesToScore`は1から100の間の範囲である必要があり、デフォルト値はクラスターのサイズに基づいて計算されます。また、クラスターのサイズの最小値は50ノードとハードコードされています。
|
||||
|
||||
{{< note >}}
|
||||
割り当て可能なノードが50以下のクラスタでは、スケジューラの検索を早期に停止するのに十分な割り当て可能なノードがないため、スケジューラはすべてのノードをチェックします。
|
||||
割り当て可能なノードが50以下のクラスターでは、スケジューラの検索を早期に停止するのに十分な割り当て可能なノードがないため、スケジューラはすべてのノードをチェックします。
|
||||
|
||||
小規模クラスタでは、`percentageOfNodesToScore`に低い値を設定したとしても、同様の理由で変更による影響は全くないか、ほとんどありません。
|
||||
小規模クラスターでは、`percentageOfNodesToScore`に低い値を設定したとしても、同様の理由で変更による影響は全くないか、ほとんどありません。
|
||||
|
||||
クラスターのノード数が数百以下の場合は、この設定オプションをデフォルト値のままにします。変更してもスケジューラの性能を大幅に改善する可能性はほとんどありません。
|
||||
{{< /note >}}
|
||||
|
|
|
|||
|
|
@ -9,4 +9,4 @@ Kubernetesのネットワーキングは4つの懸念事項に対処します。
|
|||
- Pod内のコンテナは、ネットワーキングを利用してループバック経由の通信を行います。
|
||||
- クラスターネットワーキングは、異なるPod間の通信を提供します。
|
||||
- Serviceリソースは、Pod内で動作しているアプリケーションへクラスターの外部から到達可能なように露出を許可します。
|
||||
- Serviceを利用して、クラスタ内部のみで使用するServiceの公開も可能です。
|
||||
- Serviceを利用して、クラスター内部のみで使用するServiceの公開も可能です。
|
||||
|
|
|
|||
|
|
@ -139,7 +139,7 @@ Service IPは完全に仮想的なもので、ホスト側のネットワーク
|
|||
## Serviceにアクセスする
|
||||
|
||||
Kubernetesは、環境変数とDNSの2つの主要なService検索モードをサポートしています。
|
||||
前者はそのまま使用でき、後者は[CoreDNSクラスタアドオン](https://releases.k8s.io/{{< param "fullversion" >}}/cluster/addons/dns/coredns)を必要とします。
|
||||
前者はそのまま使用でき、後者は[CoreDNSクラスターアドオン](https://releases.k8s.io/{{< param "fullversion" >}}/cluster/addons/dns/coredns)を必要とします。
|
||||
{{< note >}}
|
||||
サービス環境変数が望ましくない場合(予想されるプログラム変数と衝突する可能性がある、処理する変数が多すぎる、DNSのみを使用するなど)、[Pod仕様](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)で`enableServiceLinks`フラグを`false`に設定することでこのモードを無効にできます。
|
||||
{{< /note >}}
|
||||
|
|
|
|||
|
|
@ -83,7 +83,7 @@ CSIエフェメラルボリュームを使用すると、ユーザーはPod仕
|
|||
通常は管理者に制限されている`volumeAttributes`を許可するCSIドライバーは、インラインエフェメラルボリュームでの使用には適していません。
|
||||
たとえば、通常StorageClassで定義されるパラメーターは、インラインエフェメラルボリュームを使用してユーザーに公開しないでください。
|
||||
|
||||
Pod仕様内でインラインボリュームとして使用できるCSIドライバーを制限する必要があるクラスタ管理者は、次の方法で行うことができます。
|
||||
Pod仕様内でインラインボリュームとして使用できるCSIドライバーを制限する必要があるクラスター管理者は、次の方法で行うことができます。
|
||||
|
||||
- CSIドライバー仕様の`volumeLifecycleModes`から`Ephemeral`を削除します。これにより、ドライバーをインラインエフェメラルボリュームとして使用できなくなります。
|
||||
- [admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/)を使用して、このドライバーの使用方法を制限します。
|
||||
|
|
|
|||
|
|
@ -386,7 +386,7 @@ PersistentVolumeは、リソースプロバイダーがサポートする方法
|
|||
: ボリュームは多数のNodeで読み取り/書き込みとしてマウントできます
|
||||
|
||||
`ReadWriteOncePod`
|
||||
: ボリュームは、単一のPodで読み取り/書き込みとしてマウントできます。クラスタ全体で1つのPodのみがそのPVCの読み取りまたは書き込みを行えるようにする場合は、ReadWriteOncePodアクセスモードを使用します。これは、CSIボリュームとKubernetesバージョン1.22以降でのみサポートされます。
|
||||
: ボリュームは、単一のPodで読み取り/書き込みとしてマウントできます。クラスター全体で1つのPodのみがそのPVCの読み取りまたは書き込みを行えるようにする場合は、ReadWriteOncePodアクセスモードを使用します。これは、CSIボリュームとKubernetesバージョン1.22以降でのみサポートされます。
|
||||
|
||||
これについてはブログ[Introducing Single Pod Access Mode for PersistentVolumes](/blog/2021/09/13/read-write-once-pod-access-mode-alpha/)に詳細が記載されています。
|
||||
|
||||
|
|
|
|||
|
|
@ -159,7 +159,7 @@ spec:
|
|||
|
||||
### 許可されたトポロジー {#allowed-topologies}
|
||||
|
||||
クラスタオペレーターが`WaitForFirstConsumer`ボリュームバインディングモードを指定すると、ほとんどの状況でプロビジョニングを特定のトポロジに制限する必要がなくなります。ただし、それでも必要な場合は、`allowedTopologies`を指定できます。
|
||||
クラスターオペレーターが`WaitForFirstConsumer`ボリュームバインディングモードを指定すると、ほとんどの状況でプロビジョニングを特定のトポロジに制限する必要がなくなります。ただし、それでも必要な場合は、`allowedTopologies`を指定できます。
|
||||
|
||||
この例は、プロビジョニングされたボリュームのトポロジを特定のゾーンに制限する方法を示しており、サポートされているプラグインの`zone`および`zones`パラメーターの代わりとして使用する必要があります。
|
||||
|
||||
|
|
@ -274,7 +274,7 @@ parameters:
|
|||
|
||||
シークレットの例は[glusterfs-provisioning-secret.yaml](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/glusterfs/glusterfs-secret.yaml)にあります。
|
||||
|
||||
* `clusterid`:`630372ccdc720a92c681fb928f27b53f`は、ボリュームのプロビジョニング時にHeketiによって使用されるクラスターのIDです。また、クラスタIDのリストにすることもできます。これはオプションのパラメーターです。
|
||||
* `clusterid`:`630372ccdc720a92c681fb928f27b53f`は、ボリュームのプロビジョニング時にHeketiによって使用されるクラスターのIDです。また、クラスターIDのリストにすることもできます。これはオプションのパラメーターです。
|
||||
* `gidMin`、`gidMax`:StorageClassのGID範囲の最小値と最大値。この範囲内の一意の値(GID)(gidMin-gidMax)が、動的にプロビジョニングされたボリュームに使用されます。これらはオプションの値です。指定しない場合、ボリュームは、それぞれgidMinとgidMaxのデフォルトである2000から2147483647の間の値でプロビジョニングされます。
|
||||
* `volumetype`:ボリュームタイプとそのパラメーターは、このオプションの値で構成できます。ボリュームタイプが記載されていない場合、プロビジョニング担当者がボリュームタイプを決定します。
|
||||
例えば、
|
||||
|
|
@ -492,7 +492,7 @@ parameters:
|
|||
* `secretName`:Azureストレージアカウント名とキーを含むシークレットの名前。デフォルトは`azure-storage-account-<accountName>-secret`です
|
||||
* `readOnly`:ストレージが読み取り専用としてマウントされるかどうかを示すフラグ。デフォルトはfalseで、読み取り/書き込みマウントを意味します。この設定は、VolumeMountsの`ReadOnly`設定にも影響します。
|
||||
|
||||
ストレージのプロビジョニング中に、`secretName`という名前のシークレットがマウント資格証明用に作成されます。クラスタで[RBAC](/ja/docs/reference/access-authn-authz/rbac/)と[Controller Roles](/ja/docs/reference/access-authn-authz/rbac/#controller-roles)の両方が有効になっている場合は、追加します。clusterrole`system:controller:persistent-volume-binder`に対するリソース`secret`の`create`パーミッション。
|
||||
ストレージのプロビジョニング中に、`secretName`という名前のシークレットがマウント資格証明用に作成されます。クラスターで[RBAC](/ja/docs/reference/access-authn-authz/rbac/)と[Controller Roles](/ja/docs/reference/access-authn-authz/rbac/#controller-roles)の両方が有効になっている場合は、追加します。clusterrole`system:controller:persistent-volume-binder`に対するリソース`secret`の`create`パーミッション。
|
||||
|
||||
マルチテナンシーコンテキストでは、`secretNamespace`の値を明示的に設定することを強くお勧めします。そうしないと、ストレージアカウントの資格情報が他のユーザーに読み取られる可能性があります。
|
||||
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ weight: 80
|
|||
このページでは、特別な種類のコンテナであるエフェメラルコンテナの概要を説明します。エフェメラルコンテナは、トラブルシューティングなどのユーザーが開始するアクションを実行するために、すでに存在する{{< glossary_tooltip term_id="pod" >}}内で一時的に実行するコンテナです。エフェメラルコンテナは、アプリケーションの構築ではなく、serviceの調査のために利用します。
|
||||
|
||||
{{< warning >}}
|
||||
エフェメラルコンテナは初期のアルファ状態であり、本番クラスタには適しません。[Kubernetesの非推奨ポリシー](/docs/reference/using-api/deprecation-policy/)に従って、このアルファ機能は、将来大きく変更されたり、完全に削除される可能性があります。
|
||||
エフェメラルコンテナは初期のアルファ状態であり、本番クラスターには適しません。[Kubernetesの非推奨ポリシー](/docs/reference/using-api/deprecation-policy/)に従って、このアルファ機能は、将来大きく変更されたり、完全に削除される可能性があります。
|
||||
{{< /warning >}}
|
||||
|
||||
<!-- body -->
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ Podの各フェーズの値と意味は厳重に守られています。ここ
|
|||
Podの削除中に、kubectlコマンドには`Terminating`が出力されることがあります。この`Terminating`ステータスは、Podのフェーズではありません。Podには、正常に終了するための期間を与えられており、デフォルトは30秒です。`--force`フラグを使用して、[Podを強制的に削除する](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination-forced)ことができます。
|
||||
{{< /note >}}
|
||||
|
||||
Nodeが停止するか、クラスタの残りの部分から切断された場合、Kubernetesは失われたNode上のすべてのPodの`Phase`をFailedに設定するためのポリシーを適用します。
|
||||
Nodeが停止するか、クラスターの残りの部分から切断された場合、Kubernetesは失われたNode上のすべてのPodの`Phase`をFailedに設定するためのポリシーを適用します。
|
||||
|
||||
## コンテナのステータス {#container-states}
|
||||
|
||||
|
|
@ -310,7 +310,7 @@ Podは、クラスター内のNodeで実行中のプロセスを表すため、
|
|||
|
||||
{{< caution >}}
|
||||
即時削除では、実行中のリソースの終了を待ちません。
|
||||
リソースはクラスタ上で無期限に実行し続ける可能性があります。
|
||||
リソースはクラスター上で無期限に実行し続ける可能性があります。
|
||||
{{< /caution >}}
|
||||
|
||||
StatefulSetのPodについては、[StatefulSetからPodを削除するためのタスクのドキュメント](/ja/docs/tasks/run-application/force-delete-stateful-set-pod/)を参照してください。
|
||||
|
|
|
|||
|
|
@ -91,7 +91,7 @@ Authorization: Bearer 31ada4fd-adec-460c-809a-9e56ceb75269
|
|||
|
||||
{{< feature-state for_k8s_version="v1.18" state="stable" >}}
|
||||
|
||||
新しいクラスタの効率的なブートストラップを可能にするために、Kubernetesには*ブートストラップトークン*と呼ばれる動的に管理されたBearerトークンタイプが含まれています。これらのトークンは、`kube-system`名前空間にSecretsとして格納され、動的に管理したり作成したりすることができます。コントローラーマネージャーには、TokenCleanerコントローラーが含まれており、ブートストラップトークンの有効期限が切れると削除します。
|
||||
新しいクラスターの効率的なブートストラップを可能にするために、Kubernetesには*ブートストラップトークン*と呼ばれる動的に管理されたBearerトークンタイプが含まれています。これらのトークンは、`kube-system`名前空間にSecretsとして格納され、動的に管理したり作成したりすることができます。コントローラーマネージャーには、TokenCleanerコントローラーが含まれており、ブートストラップトークンの有効期限が切れると削除します。
|
||||
|
||||
トークンの形式は`[a-z0-9]{6}.[a-z0-9]{16}`です。最初のコンポーネントはトークンIDであり、第2のコンポーネントはToken Secretです。以下のように、トークンをHTTPヘッダーに指定します。
|
||||
|
||||
|
|
@ -101,7 +101,7 @@ Authorization: Bearer 781292.db7bc3a58fc5f07e
|
|||
|
||||
APIサーバーの`--enable-bootstrap-token-auth`フラグで、Bootstrap Token Authenticatorを有効にする必要があります。TokenCleanerコントローラーを有効にするには、コントローラーマネージャーの`--controllers`フラグを使います。`--controllers=*,tokencleaner`のようにして行います。クラスターをブートストラップするために`kubeadm`を使用している場合は、`kubeadm`がこれを代行してくれます。
|
||||
|
||||
認証機能は`system:bootstrap:<Token ID>`という名前で認証します。これは`system:bootstrappers`グループに含まれます。名前とグループは意図的に制限されており、ユーザーがブートストラップ後にこれらのトークンを使わないようにしています。ユーザー名とグループは、クラスタのブートストラップをサポートする適切な認可ポリシーを作成するために使用され、`kubeadm`によって使用されます。
|
||||
認証機能は`system:bootstrap:<Token ID>`という名前で認証します。これは`system:bootstrappers`グループに含まれます。名前とグループは意図的に制限されており、ユーザーがブートストラップ後にこれらのトークンを使わないようにしています。ユーザー名とグループは、クラスターのブートストラップをサポートする適切な認可ポリシーを作成するために使用され、`kubeadm`によって使用されます。
|
||||
|
||||
ブートストラップトークンの認証機能やコントローラーについての詳細な説明、`kubeadm`でこれらのトークンを管理する方法については、[ブートストラップトークン](/docs/reference/access-authn-authz/bootstrap-tokens/)を参照してください。
|
||||
|
||||
|
|
@ -184,7 +184,7 @@ type: kubernetes.io/service-account-token
|
|||
Secretは常にbase64でエンコードされるため、これらの値もbase64でエンコードされています。
|
||||
{{< /note >}}
|
||||
|
||||
署名されたJWTは、与えられたサービスアカウントとして認証するためのBearerトークンとして使用できます。トークンをリクエストに含める方法については、[リクエストにBearerトークンを含める](#putting-a-bearer-token-in-a-request)を参照してください。通常、これらのSecretはAPIサーバーへのクラスタ内アクセス用にPodにマウントされますが、クラスター外からも使用することができます。
|
||||
署名されたJWTは、与えられたサービスアカウントとして認証するためのBearerトークンとして使用できます。トークンをリクエストに含める方法については、[リクエストにBearerトークンを含める](#putting-a-bearer-token-in-a-request)を参照してください。通常、これらのSecretはAPIサーバーへのクラスター内アクセス用にPodにマウントされますが、クラスター外からも使用することができます。
|
||||
|
||||
サービスアカウントは、ユーザー名`system:serviceaccount:(NAMESPACE):(SERVICEACCOUNT)`で認証され、グループ`system:serviceaccounts`と`system:serviceaccounts:(NAMESPACE)`に割り当てられます。
|
||||
|
||||
|
|
|
|||
|
|
@ -508,7 +508,7 @@ APIサーバーは、デフォルトのClusterRoleオブジェクトとClusterRo
|
|||
|
||||
起動するたびに、APIサーバーはデフォルトのClusterRoleを不足している権限で更新し、
|
||||
デフォルトのClusterRoleBindingを不足しているsubjectsで更新します。
|
||||
これにより、誤った変更をクラスタが修復できるようになり、新しいKubernetesリリースで権限とsubjectsが変更されても、
|
||||
これにより、誤った変更をクラスターが修復できるようになり、新しいKubernetesリリースで権限とsubjectsが変更されても、
|
||||
RoleとRoleBindingを最新の状態に保つことができます。
|
||||
|
||||
この調整を無効化するには`rbac.authorization.kubernetes.io/autoupdate`をデフォルトのClusterRoleまたはRoleBindingのアノテーションを`false`に設定します。
|
||||
|
|
@ -557,7 +557,7 @@ ClusterRoleを編集すると、変更が[自動調整](#自動調整)によるA
|
|||
|
||||
### ユーザー向けRole
|
||||
|
||||
一部のデフォルトClusterRolesにはプレフィックス`system:`が付いていません。これらは、ユーザー向けのroleを想定しています。それらは、スーパーユーザのRole(`cluster-admin`)、ClusterRoleBindingsを使用してクラスタ全体に付与されることを意図しているRole、そしてRoleBindings(`admin`, `edit`, `view`)を使用して、特定のNamespace内に付与されることを意図しているRoleを含んでいます。
|
||||
一部のデフォルトClusterRolesにはプレフィックス`system:`が付いていません。これらは、ユーザー向けのroleを想定しています。それらは、スーパーユーザのRole(`cluster-admin`)、ClusterRoleBindingsを使用してクラスター全体に付与されることを意図しているRole、そしてRoleBindings(`admin`, `edit`, `view`)を使用して、特定のNamespace内に付与されることを意図しているRoleを含んでいます。
|
||||
|
||||
ユーザー向けのClusterRolesは[ClusterRoleの集約](#集約clusterrole)を使用して、管理者がこれらのClusterRolesにカスタムリソースのルールを含めることができるようにします。ルールを`admin`、`edit`、または`view` Roleに追加するには、次のラベルの一つ以上でClusterRoleを作成します。
|
||||
|
||||
|
|
@ -907,7 +907,7 @@ subjects:
|
|||
|
||||
### `kubectl create clusterrolebinding`
|
||||
|
||||
以下に、クラスタ全体(すべてのNamespace)にClusterRoleをいくつか例として付与します。
|
||||
以下に、クラスター全体(すべてのNamespace)にClusterRoleをいくつか例として付与します。
|
||||
|
||||
* クラスター全体で、ClusterRole「cluster-admin」へのアクセス許可を「root」という名前のユーザーに付与します。
|
||||
|
||||
|
|
|
|||
|
|
@ -441,7 +441,7 @@ GAになってからさらなる変更を加えることは現実的ではない
|
|||
- `ServiceAppProtocol`: サービスとエンドポイントで`AppProtocol`フィールドを有効にします。
|
||||
- `ServiceLoadBalancerFinalizer`: サービスロードバランサーのファイナライザー保護を有効にします。
|
||||
- `ServiceNodeExclusion`: クラウドプロバイダーによって作成されたロードバランサーからのノードの除外を有効にします。"`alpha.service-controller.kubernetes.io/exclude-balancer`"キーまたは`node.kubernetes.io/exclude-from-external-load-balancers`でラベル付けされている場合ノードは除外の対象となります。
|
||||
- `ServiceTopology`: クラスタのノードトポロジーに基づいてトラフィックをルーティングするサービスを有効にします。詳細については、[Serviceトポロジー](/ja/docs/concepts/services-networking/service-topology/)を参照してください。
|
||||
- `ServiceTopology`: クラスターのノードトポロジーに基づいてトラフィックをルーティングするサービスを有効にします。詳細については、[Serviceトポロジー](/ja/docs/concepts/services-networking/service-topology/)を参照してください。
|
||||
- `StartupProbe`: kubeletで[startup](/ja/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-startup-probe)プローブを有効にします。
|
||||
- `StorageObjectInUseProtection`: PersistentVolumeまたはPersistentVolumeClaimオブジェクトがまだ使用されている場合、それらの削除を延期します。
|
||||
- `StorageVersionHash`: apiserversがディスカバリーでストレージのバージョンハッシュを公開できるようにします。
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ tags:
|
|||
- architecture
|
||||
- operation
|
||||
---
|
||||
クラウド特有の制御ロジックを組み込むKubernetesの{{< glossary_tooltip text="control plane" term_id="control-plane" >}}コンポーネントです。クラウドコントロールマネージャーは、クラスターをクラウドプロバイダーAPIをリンクし、クラスタのみで相互作用するコンポーネントからクラウドプラットフォームで相互作用するコンポーネントを分離します。
|
||||
クラウド特有の制御ロジックを組み込むKubernetesの{{< glossary_tooltip text="control plane" term_id="control-plane" >}}コンポーネントです。クラウドコントロールマネージャーは、クラスターをクラウドプロバイダーAPIをリンクし、クラスターのみで相互作用するコンポーネントからクラウドプラットフォームで相互作用するコンポーネントを分離します。
|
||||
|
||||
<!--more-->
|
||||
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ tags:
|
|||
|
||||
<!--more-->
|
||||
|
||||
CSIはベンダーがKubernetesリポジトリにコードを追加することなく(Kubernetesリポジトリツリー外のプラグインとして)独自のストレージプラグインを作成することを可能にします。CSIドライバをストレージプロバイダから利用するには、はじめに[クラスタにCSIプラグインをデプロイする](https://kubernetes-csi.github.io/docs/deploying.html)必要があります。その後のCSIドライバーを使用するための{{< glossary_tooltip text="StorageClass" term_id="storage-class" >}}を作成することができます。
|
||||
CSIはベンダーがKubernetesリポジトリにコードを追加することなく(Kubernetesリポジトリツリー外のプラグインとして)独自のストレージプラグインを作成することを可能にします。CSIドライバをストレージプロバイダから利用するには、はじめに[クラスターにCSIプラグインをデプロイする](https://kubernetes-csi.github.io/docs/deploying.html)必要があります。その後のCSIドライバーを使用するための{{< glossary_tooltip text="StorageClass" term_id="storage-class" >}}を作成することができます。
|
||||
|
||||
* [KubernetesにおけるCSIのドキュメント](/docs/concepts/storage/volumes/#csi)
|
||||
* [利用可能なCSIドライバの一覧](https://kubernetes-csi.github.io/docs/drivers.html)
|
||||
|
|
|
|||
|
|
@ -134,7 +134,7 @@ kubectl config set-context --current --namespace=<namespace-name>
|
|||
`proxy` | `kubectl proxy [--port=PORT] [--www=static-dir] [--www-prefix=prefix] [--api-prefix=prefix] [flags]` | Kubernetes APIサーバーへのプロキシーを実行します。
|
||||
`replace` | `kubectl replace -f FILENAME` | ファイルや標準出力から、リソースを置き換えます。
|
||||
`rollout` | `kubectl rollout SUBCOMMAND [options]` | リソースのロールアウトを管理します。有効なリソースには、Deployment、DaemonSetとStatefulSetが含まれます。
|
||||
`run` | <code>kubectl run NAME --image=image [--env="key=value"] [--port=port] [--dry-run=server|client|none] [--overrides=inline-json] [flags]</code> | 指定したイメージを、クラスタ上で実行します。
|
||||
`run` | <code>kubectl run NAME --image=image [--env="key=value"] [--port=port] [--dry-run=server|client|none] [--overrides=inline-json] [flags]</code> | 指定したイメージを、クラスター上で実行します。
|
||||
`scale` | <code>kubectl scale (-f FILENAME | TYPE NAME | TYPE/NAME) --replicas=COUNT [--resource-version=version] [--current-replicas=count] [flags]</code> | 指定したReplicationControllerのサイズを更新します。
|
||||
`set` | `kubectl set SUBCOMMAND [options]` | アプリケーションリソースを設定します。
|
||||
`taint` | `kubectl taint NODE NAME KEY_1=VAL_1:TAINT_EFFECT_1 ... KEY_N=VAL_N:TAINT_EFFECT_N [options]` | 1つ以上のNodeのtaintを更新します。
|
||||
|
|
@ -415,7 +415,7 @@ kubectl logs <pod-name>
|
|||
kubectl logs -f <pod-name>
|
||||
```
|
||||
|
||||
`kubectl diff` - 提案されたクラスタに対する更新の差分を表示します。
|
||||
`kubectl diff` - 提案されたクラスターに対する更新の差分を表示します。
|
||||
|
||||
```shell
|
||||
# pod.jsonに含まれるリソースの差分を表示します。
|
||||
|
|
|
|||
|
|
@ -11,13 +11,13 @@ Kubernetesには、Kubernetesシステムの操作に役立ついくつかの組
|
|||
[`kubectl`](/ja/docs/tasks/tools/install-kubectl/)は、Kubernetesのためのコマンドラインツールです。このコマンドはKubernetes cluster managerを操作します。
|
||||
|
||||
## Kubeadm
|
||||
[`kubeadm`](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/)は、物理サーバやクラウドサーバ、仮想マシン上にKubernetesクラスタを容易にプロビジョニングするためのコマンドラインツールです(現在はアルファ版です)。
|
||||
[`kubeadm`](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/)は、物理サーバやクラウドサーバ、仮想マシン上にKubernetesクラスターを容易にプロビジョニングするためのコマンドラインツールです(現在はアルファ版です)。
|
||||
|
||||
## Minikube
|
||||
[`minikube`](https://minikube.sigs.k8s.io/docs/)は、開発やテストのためにワークステーション上でシングルノードのKubernetesクラスタをローカルで実行するツールです。
|
||||
[`minikube`](https://minikube.sigs.k8s.io/docs/)は、開発やテストのためにワークステーション上でシングルノードのKubernetesクラスターをローカルで実行するツールです。
|
||||
|
||||
## Dashboard
|
||||
[`Dashboard`](/ja/docs/tasks/access-application-cluster/web-ui-dashboard/)は、KubernetesのWebベースのユーザインタフェースで、コンテナ化されたアプリケーションをKubernetesクラスタにデプロイしたり、トラブルシューティングしたり、クラスタとそのリソース自体を管理したりすることが出来ます。
|
||||
[`Dashboard`](/ja/docs/tasks/access-application-cluster/web-ui-dashboard/)は、KubernetesのWebベースのユーザインタフェースで、コンテナ化されたアプリケーションをKubernetesクラスターにデプロイしたり、トラブルシューティングしたり、クラスターとそのリソース自体を管理したりすることが出来ます。
|
||||
|
||||
## Helm
|
||||
[`Kubernetes Helm`](https://github.com/helm/helm)は、事前に設定されたKubernetesリソースのパッケージ、別名Kubernetes chartsを管理するためのツールです。
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ card:
|
|||
Kubernetesをインストールする際には、メンテナンスの容易さ、セキュリティ、制御、利用可能なリソース、クラスターの運用及び管理に必要な専門知識に基づいてインストレーションタイプを選んでください。
|
||||
|
||||
|
||||
Kubernetesクラスタはローカルマシン、クラウド、オンプレのデータセンターにデプロイすることもできますし、マネージドのKubernetesクラスターを選択することもできます。複数のクラウドプロバイダーやベアメタルの環境に跨ったカスタムソリューションもあります。
|
||||
Kubernetesクラスターはローカルマシン、クラウド、オンプレのデータセンターにデプロイすることもできますし、マネージドのKubernetesクラスターを選択することもできます。複数のクラウドプロバイダーやベアメタルの環境に跨ったカスタムソリューションもあります。
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ Kubernetesでは、TLS認証のためにPKI証明書が必要です。
|
|||
|
||||
<!-- body -->
|
||||
|
||||
## クラスタではどのように証明書が使われているのか
|
||||
## クラスターではどのように証明書が使われているのか
|
||||
|
||||
Kubernetesは下記の用途でPKIを必要とします：
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ weight: 30
|
|||
|
||||
## ノード適合テスト
|
||||
|
||||
*ノード適合テスト* は、システムの検証とノードに対する機能テストを提供するコンテナ型のテストフレームワークです。このテストは、ノードがKubernetesの最小要件を満たしているかどうかを検証するもので、テストに合格したノードはKubernetesクラスタに参加する資格があることになります。
|
||||
*ノード適合テスト* は、システムの検証とノードに対する機能テストを提供するコンテナ型のテストフレームワークです。このテストは、ノードがKubernetesの最小要件を満たしているかどうかを検証するもので、テストに合格したノードはKubernetesクラスターに参加する資格があることになります。
|
||||
|
||||
## ノードの前提条件
|
||||
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ content_type: concept
|
|||
|
||||
<!-- overview -->
|
||||
|
||||
Minikubeはローカル環境でKubernetesを簡単に実行するためのツールです。Kubernetesを試したり日々の開発への使用を検討するユーザー向けに、PC上のVM内でシングルノードのKubernetesクラスタを実行することができます。
|
||||
Minikubeはローカル環境でKubernetesを簡単に実行するためのツールです。Kubernetesを試したり日々の開発への使用を検討するユーザー向けに、PC上のVM内でシングルノードのKubernetesクラスターを実行することができます。
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ kops is an automated provisioning system:
|
|||
|
||||
<!-- steps -->
|
||||
|
||||
## クラスタの作成
|
||||
## クラスターの作成
|
||||
|
||||
### (1/5) kopsのインストール
|
||||
|
||||
|
|
@ -122,7 +122,7 @@ brew update && brew install kops
|
|||
{{< /tabs >}}
|
||||
|
||||
|
||||
### (2/5) クラスタ用のroute53ドメインの作成
|
||||
### (2/5) クラスター用のroute53ドメインの作成
|
||||
|
||||
kops uses DNS for discovery, both inside the cluster and outside, so that you can reach the kubernetes API server
|
||||
from clients.
|
||||
|
|
@ -154,7 +154,7 @@ your cluster is configured correctly if you have the dig tool by running:
|
|||
|
||||
You should see the 4 NS records that Route53 assigned your hosted zone.
|
||||
|
||||
### (3/5) クラスタの状態を保存するS3バケットの作成
|
||||
### (3/5) クラスターの状態を保存するS3バケットの作成
|
||||
|
||||
kops lets you manage your clusters even after installation. To do this, it must keep track of the clusters
|
||||
that you have created, along with their configuration, the keys they are using etc. This information is stored
|
||||
|
|
@ -179,7 +179,7 @@ the S3 bucket name.
|
|||
We suggest putting this in your bash profile or similar.
|
||||
|
||||
|
||||
### (4/5) クラスタ設定の構築
|
||||
### (4/5) クラスター設定の構築
|
||||
|
||||
Run `kops create cluster` to create your cluster configuration:
|
||||
|
||||
|
|
@ -202,7 +202,7 @@ You can have several instance groups, for example if you wanted nodes that are a
|
|||
GPU and non-GPU instances.
|
||||
|
||||
|
||||
### (5/5) AWSにクラスタを作成
|
||||
### (5/5) AWSにクラスターを作成
|
||||
|
||||
Run "kops update cluster" to create your cluster in AWS:
|
||||
|
||||
|
|
|
|||
|
|
@ -64,7 +64,7 @@ ComponentConfigの詳細については、[このセクション](#configure-kub
|
|||
|
||||
### `kubeadm init`実行時の流れ
|
||||
|
||||
`kubeadm init`を実行した場合、kubeletの設定は`/var/lib/kubelet/config.yaml`に格納され、クラスターのConfigMapにもアップロードされます。ConfigMapは`kubelet-config-1.X`という名前で、`X`は初期化するKubernetesのマイナーバージョンを表します。またこの設定ファイルは、クラスタ内の全てのkubeletのために、クラスター全体設定の基準と共に`/etc/kubernetes/kubelet.conf`にも書き込まれます。この設定ファイルは、kubeletがAPIサーバと通信するためのクライアント証明書を指し示します。これは、[各kubeletにクラスターレベルの設定を配布](#propagating-cluster-level-configuration-to-each-kubelet)することの必要性を示しています。
|
||||
`kubeadm init`を実行した場合、kubeletの設定は`/var/lib/kubelet/config.yaml`に格納され、クラスターのConfigMapにもアップロードされます。ConfigMapは`kubelet-config-1.X`という名前で、`X`は初期化するKubernetesのマイナーバージョンを表します。またこの設定ファイルは、クラスター内の全てのkubeletのために、クラスター全体設定の基準と共に`/etc/kubernetes/kubelet.conf`にも書き込まれます。この設定ファイルは、kubeletがAPIサーバと通信するためのクライアント証明書を指し示します。これは、[各kubeletにクラスターレベルの設定を配布](#propagating-cluster-level-configuration-to-each-kubelet)することの必要性を示しています。
|
||||
|
||||
二つ目のパターンである、[インスタンス固有の設定内容を適用](#providing-instance-specific-configuration-details)するために、kubeadmは環境ファイルを`/var/lib/kubelet/kubeadm-flags.env`へ書き出します。このファイルは以下のように、kubelet起動時に渡されるフラグのリストを含んでいます。
|
||||
|
||||
|
|
|
|||
|
|
@ -18,10 +18,10 @@ weight: 20
|
|||
|
||||
<!-- body -->
|
||||
|
||||
## RBACがないため、v1.18ノードをv1.17クラスタに結合できない
|
||||
v1.18では、同名のノードが既に存在する場合にクラスタ内のノードに参加しないようにする機能を追加しました。これには、ブートストラップトークンユーザがNodeオブジェクトをGETできるようにRBACを追加する必要がありました。
|
||||
## RBACがないため、v1.18ノードをv1.17クラスターに結合できない
|
||||
v1.18では、同名のノードが既に存在する場合にクラスター内のノードに参加しないようにする機能を追加しました。これには、ブートストラップトークンユーザがNodeオブジェクトをGETできるようにRBACを追加する必要がありました。
|
||||
|
||||
しかし、これによりv1.18の`kubeadm join`がkubeadm v1.17で作成したクラスタに参加できないという問題が発生します。
|
||||
しかし、これによりv1.18の`kubeadm join`がkubeadm v1.17で作成したクラスターに参加できないという問題が発生します。
|
||||
|
||||
この問題を回避するには、次の2つの方法があります。
|
||||
- kubeadm v1.18を用いて、コントロールプレーンノード上で`kubeadm init phase bootstrap-token`を実行します。
|
||||
|
|
@ -240,7 +240,7 @@ kubectl -n kube-system get deployment coredns -o yaml | \
|
|||
CoreDNSに`CrashLoopBackOff`が発生する別の原因は、KubernetesにデプロイされたCoreDNS Podがループを検出したときに発生します。CoreDNSがループを検出して終了するたびに、KubernetesがCoreDNS Podを再起動しようとするのを避けるために、[いくつかの回避策](https://github.com/coredns/coredns/tree/master/plugin/loop#troubleshooting-loops-in-kubernetes-clusters)が用意されています。
|
||||
|
||||
{{< warning >}}
|
||||
SELinuxを無効にするか`allowPrivilegeEscalation`を`true`に設定すると、クラスタのセキュリティが損なわれる可能性があります。
|
||||
SELinuxを無効にするか`allowPrivilegeEscalation`を`true`に設定すると、クラスターのセキュリティが損なわれる可能性があります。
|
||||
{{< /warning >}}
|
||||
|
||||
## etcdのpodが継続的に再起動する
|
||||
|
|
@ -343,6 +343,6 @@ nodeRegistration:
|
|||
あるいは、`/usr`マウントを書き込み可能にするために `/etc/fstab`を変更することもできますが、これはLinuxディストリビューションの設計原理を変更していることに注意してください。
|
||||
|
||||
## `kubeadm upgrade plan`が`context deadline exceeded`エラーメッセージを表示する
|
||||
このエラーメッセージは、外部etcdを実行している場合に`kubeadm`でKubernetesクラスタをアップグレードする際に表示されます。これは致命的なバグではなく、古いバージョンのkubeadmが外部etcdクラスタのバージョンチェックを行うために発生します。`kubeadm upgrade apply ...`で進めることができます。
|
||||
このエラーメッセージは、外部etcdを実行している場合に`kubeadm`でKubernetesクラスターをアップグレードする際に表示されます。これは致命的なバグではなく、古いバージョンのkubeadmが外部etcdクラスターのバージョンチェックを行うために発生します。`kubeadm upgrade apply ...`で進めることができます。
|
||||
|
||||
この問題はバージョン1.19で修正されます。
|
||||
|
|
|
|||
|
|
@ -195,7 +195,7 @@ Windowsでは、次のIPAMオプションがサポートされています。
|
|||
|
||||
#### コントロールプレーン
|
||||
|
||||
Windowsは、Kubernetesアーキテクチャとコンポーネントマトリックスのワーカーノードとしてのみサポートされています。つまり、Kubernetesクラスタには常にLinuxマスターノード、0以上のLinuxワーカーノード、0以上のWindowsワーカーノードが含まれている必要があります。
|
||||
Windowsは、Kubernetesアーキテクチャとコンポーネントマトリックスのワーカーノードとしてのみサポートされています。つまり、Kubernetesクラスターには常にLinuxマスターノード、0以上のLinuxワーカーノード、0以上のWindowsワーカーノードが含まれている必要があります。
|
||||
|
||||
#### コンピュート
|
||||
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ weight: 60
|
|||
|
||||
{{< codenew file="service/access/hello-application.yaml" >}}
|
||||
|
||||
1. クラスタでHello Worldアプリケーションを稼働させます:
|
||||
1. クラスターでHello Worldアプリケーションを稼働させます:
|
||||
上記のファイルを使用し、アプリケーションのDeploymentを作成します:
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/service/access/hello-application.yaml
|
||||
|
|
|
|||
|
|
@ -89,7 +89,7 @@ Kubeconfigの認証方法は、外部IDプロバイダーやx509証明書ベー
|
|||
- **Container image** (必須): 任意のレジストリ上の公開Docker[コンテナイメージ](/docs/concepts/containers/images/)、またはプライベートイメージ(一般的にはGoogle Container RegistryやDocker Hub上でホストされている)のURLです。
|
||||
コンテナイメージの指定はコロンで終わらせる必要があります。
|
||||
|
||||
クラスタ全体で必要な数のPodを維持するために、[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)が作成されます。
|
||||
クラスター全体で必要な数のPodを維持するために、[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)が作成されます。
|
||||
|
||||
- **Service** (任意): アプリケーションのいくつかの部分(たとえばフロントエンド)では、
|
||||
[Service](/ja/docs/concepts/services-networking/service/)をクラスター外の外部、おそらくパブリックIPアドレス(外部サービス)に公開したいと思うかもしれません。
|
||||
|
|
@ -124,7 +124,7 @@ Kubeconfigの認証方法は、外部IDプロバイダーやx509証明書ベー
|
|||
```
|
||||
|
||||
- **Namespace**: Kubernetesは、同じ物理クラスターを基盤とする複数の仮想クラスターをサポートしています。
|
||||
これらの仮想クラスタは[名前空間](/docs/tasks/administer-cluster/namespaces/) と呼ばれます。
|
||||
これらの仮想クラスターは[名前空間](/docs/tasks/administer-cluster/namespaces/) と呼ばれます。
|
||||
これにより、リソースを論理的に名前のついたグループに分割することができます。
|
||||
|
||||
ダッシュボードでは、利用可能なすべての名前空間がドロップダウンリストに表示され、新しい名前空間を作成することができます。
|
||||
|
|
|
|||
|
|
@ -217,7 +217,7 @@ LimitRangeによってNamespaceに課される最大および最小のメモリ
|
|||
|
||||
例:
|
||||
|
||||
* クラスター内の各ノードは2GBのメモリーを持っています。クラスタ内のどのノードもその要求をサポートできないため、2GB以上のメモリーを要求するPodは受け入れたくありません。
|
||||
* クラスター内の各ノードは2GBのメモリーを持っています。クラスター内のどのノードもその要求をサポートできないため、2GB以上のメモリーを要求するPodは受け入れたくありません。
|
||||
|
||||
|
||||
* クラスターは運用部門と開発部門で共有されています。 本番用のワークロードでは最大8GBのメモリーを消費しますが、開発用のワークロードでは512MBに制限したいとします。本番用と開発用に別々のNamespaceを作成し、それぞれのNamespaceにメモリー制限を適用します。
|
||||
|
|
|
|||
|
|
@ -46,7 +46,7 @@ NodeLocal DNSキャッシュは、クラスターノード上でDNSキャッシ
|
|||
{{< figure src="/images/docs/nodelocaldns.svg" alt="NodeLocal DNSCache flow" title="Nodelocal DNSCacheのフロー" caption="この図は、NodeLocal DNSキャッシュがDNSクエリーをどう扱うかを表したものです。" >}}
|
||||
|
||||
## 設定
|
||||
{{< note >}} NodeLocal DNSキャッシュのローカルリッスン用のIPアドレスは、クラスタ内の既存のIPと衝突しないことが保証できるものであれば、どのようなアドレスでもかまいません。例えば、IPv4のリンクローカル範囲169.254.0.0/16やIPv6のユニークローカルアドレス範囲fd00::/8から、ローカルスコープのアドレスを使用することが推奨されています。
|
||||
{{< note >}} NodeLocal DNSキャッシュのローカルリッスン用のIPアドレスは、クラスター内の既存のIPと衝突しないことが保証できるものであれば、どのようなアドレスでもかまいません。例えば、IPv4のリンクローカル範囲169.254.0.0/16やIPv6のユニークローカルアドレス範囲fd00::/8から、ローカルスコープのアドレスを使用することが推奨されています。
|
||||
{{< /note >}}
|
||||
|
||||
この機能は、下記の手順により有効化できます。
|
||||
|
|
|
|||
|
|
@ -74,7 +74,7 @@ Kubeletsは、ノードやコンテナの強力な制御を可能にするHTTPS
|
|||
|
||||
Kubernetesにおける権限付与は、意図的にハイレベルであり、リソースに対する粗いアクションに焦点を当てています。
|
||||
|
||||
より強力なコントロールは**policies**として存在し、それらのオブジェクトがクラスタや自身、その他のリソースにどのように作用するかをユースケースによって制限します。
|
||||
より強力なコントロールは**policies**として存在し、それらのオブジェクトがクラスターや自身、その他のリソースにどのように作用するかをユースケースによって制限します。
|
||||
|
||||
### クラスターのリソース使用量の制限
|
||||
|
||||
|
|
@ -106,7 +106,7 @@ Linuxカーネルは、ハードウェアが接続されたときやファイル
|
|||
# DCCPは必要性が低く、複数の深刻な脆弱性があり、保守も十分ではありません。
|
||||
blacklist dccp
|
||||
|
||||
# SCTPはほとんどのKubernetesクラスタでは使用されておらず、また過去には脆弱性がありました。
|
||||
# SCTPはほとんどのKubernetesクラスターでは使用されておらず、また過去には脆弱性がありました。
|
||||
blacklist sctp
|
||||
```
|
||||
|
||||
|
|
@ -120,7 +120,7 @@ blacklist sctp
|
|||
|
||||
サポートされている[Kubernetes networking providers](/ja/docs/concepts/cluster-administration/networking/)の多くは、ネットワークポリシーを尊重するようになりました。
|
||||
クォータやリミットの範囲は、ユーザーがノードポートや負荷分散サービスを要求するかどうかを制御するためにも使用でき、多くのクラスターでは、ユーザーのアプリケーションがクラスターの外で見えるかどうかを制御できます。
|
||||
ノードごとのファイアウォール、クロストークを防ぐための物理的なクラスタノードの分離、高度なネットワークポリシーなど、プラグインや環境ごとにネットワークルールを制御する追加の保護機能が利用できる場合もあります。
|
||||
ノードごとのファイアウォール、クロストークを防ぐための物理的なクラスターノードの分離、高度なネットワークポリシーなど、プラグインや環境ごとにネットワークルールを制御する追加の保護機能が利用できる場合もあります。
|
||||
|
||||
### クラウドメタデータのAPIアクセスを制限
|
||||
|
||||
|
|
@ -145,7 +145,7 @@ Kubernetesは、エンドユーザーが利用できる[Node上へのPodのス
|
|||
|
||||
### etcdへのアクセスの制限
|
||||
|
||||
API用のetcdバックエンドへの書き込みアクセスは、クラスタ全体のrootを取得するのと同等であり、読み取りアクセスはかなり迅速にエスカレートするために使用できます。
|
||||
API用のetcdバックエンドへの書き込みアクセスは、クラスター全体のrootを取得するのと同等であり、読み取りアクセスはかなり迅速にエスカレートするために使用できます。
|
||||
管理者は、TLSクライアント証明書による相互認証など、APIサーバーからetcdサーバーへの強力な認証情報を常に使用すべきであり、API サーバーのみがアクセスできるファイアウォールの後ろにetcdサーバーを隔離することがしばしば推奨されます。
|
||||
|
||||
{{< caution >}}
|
||||
|
|
|
|||
|
|
@ -139,7 +139,7 @@ kubectl delete deployment nginx-deployment --cascade=background
|
|||
|
||||
## オーナーオブジェクトの削除と従属オブジェクトの孤立 {#set-orphan-deletion-policy}
|
||||
|
||||
デフォルトでは、Kubernetesにオブジェクトの削除を指示すると、{{<glossary_tooltip text="コントローラー" term_id="controller">}}は従属オブジェクトも削除します。クラスタが動作しているKubernetesのバージョンに応じて、`kubectl`またはKubernetes APIを使用して、これらの従属オブジェクトをKubernetesで*orphan*にすることができます。{{<version-check>}}
|
||||
デフォルトでは、Kubernetesにオブジェクトの削除を指示すると、{{<glossary_tooltip text="コントローラー" term_id="controller">}}は従属オブジェクトも削除します。クラスターが動作しているKubernetesのバージョンに応じて、`kubectl`またはKubernetes APIを使用して、これらの従属オブジェクトをKubernetesで*orphan*にすることができます。{{<version-check>}}
|
||||
|
||||
**kubectlを使用する**
|
||||
|
||||
|
|
|
|||
|
|
@ -230,7 +230,7 @@ crictl logs --tail=1 87d3992f84f74
|
|||
### Podサンドボックスの実行
|
||||
|
||||
`crictl`を使ってPodサンドボックスを実行することは、コンテナのランタイムをデバッグするのに便利です。
|
||||
稼働中のKubernetesクラスタでは、サンドボックスは最終的にKubeletによって停止され、削除されます。
|
||||
稼働中のKubernetesクラスターでは、サンドボックスは最終的にKubeletによって停止され、削除されます。
|
||||
|
||||
1. 以下のようなJSONファイルを作成します:
|
||||
|
||||
|
|
@ -259,7 +259,7 @@ crictl logs --tail=1 87d3992f84f74
|
|||
### コンテナの作成
|
||||
|
||||
コンテナの作成に`crictl`を使うと、コンテナのランタイムをデバッグするのに便利です。
|
||||
稼働中のKubernetesクラスタでは、サンドボックスは最終的にKubeletによって停止され、削除されます。
|
||||
稼働中のKubernetesクラスターでは、サンドボックスは最終的にKubeletによって停止され、削除されます。
|
||||
|
||||
1. busyboxイメージをプルします:
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ Kubernetesアプリケーションは通常、複数の独立したサービス
|
|||
`telepresence`は、リモートKubernetesクラスターにサービスをプロキシーしながら、ローカルでサービスを開発・デバッグするプロセスを容易にするためのツールです。
|
||||
`telepresence` を使用すると、デバッガーやIDEなどのカスタムツールをローカルサービスで使用でき、ConfigMapやsecret、リモートクラスター上で動作しているサービスへのフルアクセスをサービスに提供します。
|
||||
|
||||
このドキュメントでは、リモートクラスタ上で動作しているサービスをローカルで開発・デバッグするために`telepresence`を使用する方法を説明します。
|
||||
このドキュメントでは、リモートクラスター上で動作しているサービスをローカルで開発・デバッグするために`telepresence`を使用する方法を説明します。
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
|
|
|||
|
|
@ -79,10 +79,10 @@ kubectl apply -f https://k8s.io/examples/application/mysql/mysql-services.yaml
|
|||
|
||||
ヘッドレスサービスは、StatefulSetコントローラーが
|
||||
StatefulSetの一部であるPodごとに作成するDNSエントリーのベースエントリーを提供します。
|
||||
この例ではヘッドレスサービスの名前は`mysql`なので、同じKubernetesクラスタの
|
||||
この例ではヘッドレスサービスの名前は`mysql`なので、同じKubernetesクラスターの
|
||||
同じ名前空間内の他のPodは、`<pod-name>.mysql`を名前解決することでPodにアクセスできます。
|
||||
|
||||
`mysql-read`と呼ばれるクライアントサービスは、独自のクラスタIPを持つ通常のServiceであり、
|
||||
`mysql-read`と呼ばれるクライアントサービスは、独自のクラスターIPを持つ通常のServiceであり、
|
||||
Ready状態のすべてのMySQL Podに接続を分散します。
|
||||
Serviceのエンドポイントには、MySQLマスターとすべてのスレーブが含まれる可能性があります。
|
||||
|
||||
|
|
@ -313,7 +313,7 @@ StatefulSetコントローラーは`mysql-2` Podがもう存在しないこと
|
|||
|
||||
### ノードをdrainする
|
||||
|
||||
Kubernetesクラスタに複数のノードがある場合は、
|
||||
Kubernetesクラスターに複数のノードがある場合は、
|
||||
[drain](/docs/reference/generated/kubectl/kubectl-commands/#drain)を発行して
|
||||
ノードのダウンタイム(例えばノードのアップグレード時など)をシミュレートできます。
|
||||
|
||||
|
|
@ -335,7 +335,7 @@ mysql-2 2/2 Running 0 15m 10.244.5.27 kubernetes-mini
|
|||
`<node-name>`は前のステップで確認したノードの名前に置き換えてください。
|
||||
|
||||
この操作はノード上の他のアプリケーションに影響を与える可能性があるため、
|
||||
**テストクラスタでのみこの操作を実行**するのが最善です。
|
||||
**テストクラスターでのみこの操作を実行**するのが最善です。
|
||||
|
||||
```shell
|
||||
kubectl drain <node-name> --force --delete-local-data --ignore-daemonsets
|
||||
|
|
|
|||
|
|
@ -70,7 +70,7 @@ spec.replicas > 1の場合、Kubernetesは不健康なPodの理由を判断で
|
|||
|
||||
永続的な障害が原因でPodが正常でない場合、障害を修正せずにスケーリングすると、StatefulSetメンバーシップが正しく機能するために必要な特定の最小レプリカ数を下回る状態になる可能性があります。これにより、StatefulSetが利用できなくなる可能性があります。
|
||||
|
||||
一時的な障害によってPodが正常でなくなり、Podが再び使用可能になる可能性がある場合は、一時的なエラーがスケールアップまたはスケールダウン操作の妨げになる可能性があります。一部の分散データベースでは、ノードが同時に参加および脱退するときに問題があります。このような場合は、アプリケーションレベルでスケーリング操作を考えることをお勧めします。また、ステートフルアプリケーションクラスタが完全に健全であることが確実な場合にのみスケーリングを実行してください。
|
||||
一時的な障害によってPodが正常でなくなり、Podが再び使用可能になる可能性がある場合は、一時的なエラーがスケールアップまたはスケールダウン操作の妨げになる可能性があります。一部の分散データベースでは、ノードが同時に参加および脱退するときに問題があります。このような場合は、アプリケーションレベルでスケーリング操作を考えることをお勧めします。また、ステートフルアプリケーションクラスターが完全に健全であることが確実な場合にのみスケーリングを実行してください。
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -289,7 +289,7 @@ PodのステータスはPendingとなり、`Pod Cannot enforce AppArmor: profile
|
|||
|
||||
### PodSecurityPolicyを使用したプロファイルの制限
|
||||
|
||||
PodSecurityPolicy extensionが有効になっている場合、クラスタ全体でAppArmorn制限が適用されます。PodSecurityPolicyを有効にするには、`apiserver`上で次のフラグを設定する必要があります。
|
||||
PodSecurityPolicy extensionが有効になっている場合、クラスター全体でAppArmorn制限が適用されます。PodSecurityPolicyを有効にするには、`apiserver`上で次のフラグを設定する必要があります。
|
||||
|
||||
```
|
||||
--enable-admission-plugins=PodSecurityPolicy[,others...]
|
||||
|
|
@ -306,7 +306,7 @@ defaultProfileNameオプションには、何も指定されなかった場合
|
|||
|
||||
### AppArmorの無効化
|
||||
|
||||
クラスタ上でAppArmorを利用可能にしたくない場合、次のコマンドラインフラグで無効化できます。
|
||||
クラスター上でAppArmorを利用可能にしたくない場合、次のコマンドラインフラグで無効化できます。
|
||||
|
||||
```
|
||||
--feature-gates=AppArmor=false
|
||||
|
|
@ -316,7 +316,7 @@ defaultProfileNameオプションには、何も指定されなかった場合
|
|||
|
||||
### AppArmorを使用するKubernetes v1.4にアップグレードする
|
||||
|
||||
クラスタをv1.4にアップグレードするために、AppArmorに関する操作は必要ありません。ただし、既存のPodがAppArmorのアノテーションを持っている場合、検証(またはPodSecurityPolicy admission)は行われません。もしpermissiveなプロファイルがノードに読み込まれていた場合、悪意のあるユーザーがPodの権限を上述のdocker-defaultより昇格させるために、permissiveなプロファイルを再適用する恐れがあります。これが問題となる場合、`apparmor.security.beta.kubernetes.io`のアノテーションを含むすべてのPodのクラスターをクリーンアップすることを推奨します。
|
||||
クラスターをv1.4にアップグレードするために、AppArmorに関する操作は必要ありません。ただし、既存のPodがAppArmorのアノテーションを持っている場合、検証(またはPodSecurityPolicy admission)は行われません。もしpermissiveなプロファイルがノードに読み込まれていた場合、悪意のあるユーザーがPodの権限を上述のdocker-defaultより昇格させるために、permissiveなプロファイルを再適用する恐れがあります。これが問題となる場合、`apparmor.security.beta.kubernetes.io`のアノテーションを含むすべてのPodのクラスターをクリーンアップすることを推奨します。
|
||||
|
||||
### 一般利用可能(General Availability)への更新パス {#upgrade-path-to-general-availability}
|
||||
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ card:
|
|||
|
||||
MySQLとWordpressはそれぞれ、データを保存するためのPersistentVolumeを必要とします。各PersistentVolumeClaimはデプロイの段階で作成されます。
|
||||
|
||||
多くのクラスタ環境では、デフォルトのStorageClassがインストールされています。StorageClassがPersistentVolumeClaim中で指定されていなかった場合、クラスターのデフォルトのStorageClassが代わりに使われます。
|
||||
多くのクラスター環境では、デフォルトのStorageClassがインストールされています。StorageClassがPersistentVolumeClaim中で指定されていなかった場合、クラスターのデフォルトのStorageClassが代わりに使われます。
|
||||
|
||||
PersistentVolumeClaimが作成されるとき、StorageClassの設定に基づいてPersistentVolumeが動的にプロビジョニングされます。
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue