@@ -36,7 +36,7 @@ kubeadmはディスク上のCAキーがなくても処理を進めます。
36
36
37
37
代わりに、Controller-managerをスタンドアロンで、` --controllers=csrsigner ` と実行し、CA証明書と鍵を指し示します。
38
38
39
- [ PKI certificates and requirements] ( /docs/setup/best-practices/certificates/ ) には、外部CAを使用するためのクラスタのセットアップに関するガイダンスが含まれています 。
39
+ [ PKI certificates and requirements] ( /docs/setup/best-practices/certificates/ ) には、外部CAを使用するためのクラスターのセットアップに関するガイダンスが含まれています 。
40
40
41
41
## 証明書の有効期限の確認
42
42
@@ -97,10 +97,10 @@ client-key: /var/lib/kubelet/pki/kubelet-client-current.pem
97
97
kubeadmはコントロールプレーンの[アップグレード](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)時にすべての証明書を更新します。
98
98
99
99
この機能は、最もシンプルなユースケースに対応するために設計されています。
100
- 証明書の更新に特別な要件がなく、Kubernetesのバージョンアップを定期的に行う場合(各アップグレードの間隔が1年未満)、kubeadmがクラスタを最新かつ適度に安全に保つための処理を行います 。
100
+ 証明書の更新に特別な要件がなく、Kubernetesのバージョンアップを定期的に行う場合(各アップグレードの間隔が1年未満)、kubeadmがクラスターを最新かつ適度に安全に保つための処理を行います 。
101
101
102
102
{{< note >}}
103
- 安全性を維持するために、クラスタを頻繁にアップグレードすることがベストプラクティスです 。
103
+ 安全性を維持するために、クラスターを頻繁にアップグレードすることがベストプラクティスです 。
104
104
{{< /note >}}
105
105
106
106
証明書の更新に関してより複雑な要求がある場合は、` --certificate-renewal=false`を`kubeadm upgrade apply`や`kubeadm upgrade node`に渡して、デフォルトの動作から外れるようにすることができます。
@@ -125,7 +125,7 @@ kubeadmバージョン1.17より前のバージョンでは、`kubeadm upgrade n
125
125
その後ファイルを戻して、さらに`fileCheckFrequency`期間後に、kubeletはPodを再作成し、コンポーネントの証明書更新を完了することができます。
126
126
127
127
{{< warning >}}
128
- HAクラスタを実行している場合 、このコマンドはすべての制御プレーンノードで実行する必要があります。
128
+ HAクラスターを実行している場合 、このコマンドはすべての制御プレーンノードで実行する必要があります。
129
129
{{< /warning >}}
130
130
131
131
{{< note >}}
@@ -145,7 +145,7 @@ Kubernetesの証明書は通常1年後に有効期限を迎えます。
145
145
ここでは、Kubernetes certificates APIを使用して手動で証明書更新を実行する方法について詳しく説明します。
146
146
147
147
{{< caution >}}
148
- これらは、組織の証明書インフラをkubeadmで構築されたクラスタに統合する必要があるユーザー向けの上級者向けのトピックです 。
148
+ これらは、組織の証明書インフラをkubeadmで構築されたクラスターに統合する必要があるユーザー向けの上級者向けのトピックです 。
149
149
kubeadmのデフォルトの設定で満足できる場合は、代わりにkubeadmに証明書を管理させる必要があります。
150
150
{{< /caution >}}
151
151
@@ -158,7 +158,7 @@ Kubernetesの認証局は、そのままでは機能しません。
158
158
159
159
ビルトインサイナーを有効にするには、`--cluster-signing-cert-file`と`--cluster-signing-key-file`フラグを渡す必要があります。
160
160
161
- 新しいクラスタを作成する場合は 、kubeadm[設定ファイル](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3)を使用します。
161
+ 新しいクラスターを作成する場合は 、kubeadm[設定ファイル](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3)を使用します。
162
162
163
163
` ` ` yaml
164
164
apiVersion: kubeadm.k8s.io/v1beta3
@@ -211,7 +211,7 @@ CAの手動ローテーションや交換についての詳細は、[manual rota
211
211
212
212
デフォルトでは、kubeadmによって展開されるkubeletサービング証明書は自己署名されています。
213
213
これは、[metrics-server](https://github.com/kubernetes-sigs/metrics-server)のような外部サービスからキューブレットへの接続がTLSで保護されないことを意味します。
214
- 新しいkubeadmクラスタ内のkubeletが適切に署名されたサービング証明書を取得するように設定するには 、`kubeadm init`に以下の最小限の設定を渡す必要があります。
214
+ 新しいkubeadmクラスター内のkubeletが適切に署名されたサービング証明書を取得するように設定するには 、`kubeadm init`に以下の最小限の設定を渡す必要があります。
215
215
216
216
` ` ` yaml
217
217
apiVersion: kubeadm.k8s.io/v1beta3
@@ -222,11 +222,11 @@ kind: KubeletConfiguration
222
222
serverTLSBootstrap: true
223
223
` ` `
224
224
225
- すでにクラスタを作成している場合は 、以下の手順で適応させる必要があります。
225
+ すでにクラスターを作成している場合は 、以下の手順で適応させる必要があります。
226
226
227
- - kube-system` ネームスペースにある `kubelet-config-{{< skew latestVersion >}}` ConfigMap を見つけて編集します 。
227
+ - kube-system` ネームスペースにある `kubelet-config-{{< skew latestVersion >}}` ConfigMapを見つけて編集します 。
228
228
229
- そのConfigMapの`kubelet`キーの値として[KubeletConfiguration](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) ドキュメントを指定します。KubeletConfigurationドキュメントを編集し、`serverTLSBootstrap: true`を設定します。
229
+ そのConfigMapの`kubelet`キーの値として[KubeletConfiguration](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)ドキュメントを指定します。KubeletConfigurationドキュメントを編集し、`serverTLSBootstrap: true`を設定します。
230
230
231
231
- 各ノードで、`/var/lib/kubelet/config.yaml`に`serverTLSBootstrap : true`フィールドを追加し、`systemctl restart kubelet`でkubeletを再起動します。
232
232
@@ -236,7 +236,7 @@ serverTLSBootstrap: true
236
236
既知の制限事項として、これらの証明書のCSR(Certificate Signing Requests)はkube-controller-managerのデフォルトサイナーによって自動的に承認されないことがあります。
237
237
[`kubernetes.io/kubelet-serving`](/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers) を参照してください。
238
238
239
- これには、ユーザーまたはサードパーティのコントローラからのアクションが必要です 。
239
+ これには、ユーザーまたはサードパーティーのコントローラーからのアクションが必要です 。
240
240
241
241
これらのCSRは、以下を使用して表示できます :
242
242
@@ -263,7 +263,7 @@ Kubeadmは`KubeletConfiguration`フィールド`rotateCertificates`を`true`に
263
263
264
264
{{% thirdparty-content %}}
265
265
266
- サードパーティのカスタムコントローラを使用することができます 。
266
+ サードパーティーのカスタムコントローラーを使用することができます 。
267
267
- [kubelet-csr-approver](https://github.com/postfinance/kubelet-csr-approver)
268
268
269
- このようなコントローラは 、CSRのCommonNameを検証するだけでなく、要求されたIPやドメイン名も検証しなければ、安全なメカニズムとは言えません。これにより、kubeletクライアント証明書にアクセスできる悪意のあるアクターが、任意のIPやドメイン名に対してサービング証明書を要求するCSRを作成することを防ぐことができます。
269
+ このようなコントローラーは 、CSRのCommonNameを検証するだけでなく、要求されたIPやドメイン名も検証しなければ、安全なメカニズムとは言えません。これにより、kubeletクライアント証明書にアクセスできる悪意のあるアクターが、任意のIPやドメイン名に対してサービング証明書を要求するCSRを作成することを防ぐことができます。
0 commit comments