From 75cd79a13614c884a2cb1bdc106a97e18f54bb54 Mon Sep 17 00:00:00 2001 From: amyXia1994 Date: Mon, 7 Dec 2020 21:28:37 +0800 Subject: [PATCH 01/62] Update secret.md fix minor syntax error --- content/en/docs/concepts/configuration/secret.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/configuration/secret.md b/content/en/docs/concepts/configuration/secret.md index c28e3e1133..3548b6fb5d 100644 --- a/content/en/docs/concepts/configuration/secret.md +++ b/content/en/docs/concepts/configuration/secret.md @@ -701,7 +701,7 @@ spec: #### Consuming Secret Values from environment variables -Inside a container that consumes a secret in an environment variables, the secret keys appear as +Inside a container that consumes a secret in the environment variables, the secret keys appear as normal environment variables containing the base64 decoded values of the secret data. This is the result of commands executed inside the container from the example above: From a170fbdce026ded8d6ec5ff5b3a5f9cd59374eb7 Mon Sep 17 00:00:00 2001 From: Zhizhen He Date: Thu, 10 Dec 2020 18:28:21 +0800 Subject: [PATCH 02/62] Fix syntax error --- content/en/docs/concepts/services-networking/service.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/services-networking/service.md b/content/en/docs/concepts/services-networking/service.md index 58d9bb9a2d..a6dd80ba63 100644 --- a/content/en/docs/concepts/services-networking/service.md +++ b/content/en/docs/concepts/services-networking/service.md @@ -74,7 +74,7 @@ a new instance. The name of a Service object must be a valid [DNS label name](/docs/concepts/overview/working-with-objects/names#dns-label-names). -For example, suppose you have a set of Pods that each listen on TCP port 9376 +For example, suppose you have a set of Pods that each listens on TCP port 9376 and carry a label `app=MyApp`: ```yaml From d7e94dc7e05576cb29d90daef8a1efb67c27281c Mon Sep 17 00:00:00 2001 From: Frank Villaro-Dixon Date: Tue, 15 Dec 2020 17:18:58 +0100 Subject: [PATCH 03/62] Update client-libraries.md : add python pykorm lib --- content/en/docs/reference/using-api/client-libraries.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/en/docs/reference/using-api/client-libraries.md b/content/en/docs/reference/using-api/client-libraries.md index c14f0fa9c7..ef819f903f 100644 --- a/content/en/docs/reference/using-api/client-libraries.md +++ b/content/en/docs/reference/using-api/client-libraries.md @@ -67,6 +67,7 @@ their authors, not the Kubernetes team. | Python | [github.com/fiaas/k8s](https://github.com/fiaas/k8s) | | Python | [github.com/mnubo/kubernetes-py](https://github.com/mnubo/kubernetes-py) | | Python | [github.com/tomplus/kubernetes_asyncio](https://github.com/tomplus/kubernetes_asyncio) | +| Python | [github.com/Frankkkkk/pykorm](https://github.com/Frankkkkk/pykorm) | | Ruby | [github.com/abonas/kubeclient](https://github.com/abonas/kubeclient) | | Ruby | [github.com/Ch00k/kuber](https://github.com/Ch00k/kuber) | | Ruby | [github.com/kontena/k8s-client](https://github.com/kontena/k8s-client) | From 34f1d1911c820b9712c4f4f33f06a21bf583223e Mon Sep 17 00:00:00 2001 From: slashr Date: Sun, 3 Jan 2021 00:26:17 +0530 Subject: [PATCH 04/62] Replaced deprecated ReplicationController with JobController for reference --- content/en/docs/concepts/overview/components.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/content/en/docs/concepts/overview/components.md b/content/en/docs/concepts/overview/components.md index eb17e2dd7e..f30c08a287 100644 --- a/content/en/docs/concepts/overview/components.md +++ b/content/en/docs/concepts/overview/components.md @@ -51,11 +51,10 @@ the same machine, and do not run user containers on this machine. See {{< glossary_definition term_id="kube-controller-manager" length="all" >}} -These controllers include: +Some types of these controllers are: * Node controller: Responsible for noticing and responding when nodes go down. - * Replication controller: Responsible for maintaining the correct number of pods for every replication - controller object in the system. + * Job controller: Responsible for noticing tasks and creating Pods to run the tasks to completion * Endpoints controller: Populates the Endpoints object (that is, joins Services & Pods). * Service Account & Token controllers: Create default accounts and API access tokens for new namespaces. From 976c260ef4cfca0d6707168978543ff82829050f Mon Sep 17 00:00:00 2001 From: slashr Date: Sun, 3 Jan 2021 10:22:36 +0530 Subject: [PATCH 05/62] Modified description --- content/en/docs/concepts/overview/components.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/content/en/docs/concepts/overview/components.md b/content/en/docs/concepts/overview/components.md index f30c08a287..763308887d 100644 --- a/content/en/docs/concepts/overview/components.md +++ b/content/en/docs/concepts/overview/components.md @@ -54,7 +54,8 @@ the same machine, and do not run user containers on this machine. See Some types of these controllers are: * Node controller: Responsible for noticing and responding when nodes go down. - * Job controller: Responsible for noticing tasks and creating Pods to run the tasks to completion + * Job controller: Watches for Job objects that represent one-off tasks, then creates + Pods to run those tasks to completion. * Endpoints controller: Populates the Endpoints object (that is, joins Services & Pods). * Service Account & Token controllers: Create default accounts and API access tokens for new namespaces. From bda3cea5a6b3ea222be305f79d091ac77dd1a633 Mon Sep 17 00:00:00 2001 From: Aldo Culquicondor <1299064+alculquicondor@users.noreply.github.com> Date: Thu, 14 Jan 2021 14:47:31 -0500 Subject: [PATCH 06/62] Remove indication that a failed scheduling attempt removes the Pod /sig scheduling --- content/en/docs/concepts/workloads/pods/pod-lifecycle.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md index df83f7c5f3..832785923a 100644 --- a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md @@ -38,8 +38,7 @@ If a {{< glossary_tooltip term_id="node" >}} dies, the Pods scheduled to that no are [scheduled for deletion](#pod-garbage-collection) after a timeout period. Pods do not, by themselves, self-heal. If a Pod is scheduled to a -{{< glossary_tooltip text="node" term_id="node" >}} that then fails, -or if the scheduling operation itself fails, the Pod is deleted; likewise, a Pod won't +{{< glossary_tooltip text="node" term_id="node" >}} that then fails, the Pod is deleted; likewise, a Pod won't survive an eviction due to a lack of resources or Node maintenance. Kubernetes uses a higher-level abstraction, called a {{< glossary_tooltip term_id="controller" text="controller" >}}, that handles the work of From bee671b57957fde9b97a9c4030856fc8036ffc36 Mon Sep 17 00:00:00 2001 From: Caleb Collins-Parks <46505081+caleb15@users.noreply.github.com> Date: Thu, 4 Feb 2021 10:37:31 -0800 Subject: [PATCH 07/62] add warning about counterintuitive readiness probe As evidenced by https://github.com/kubernetes/kubernetes/issues/27114 the naming leads one to think that a liveness probe executes after a readiness probe. This is not the case. --- .../configure-liveness-readiness-startup-probes.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index 45d56531f2..e12e2684a6 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -293,6 +293,10 @@ Services. Readiness probes runs on the container during its whole lifecycle. {{< /note >}} +{{< warning >}} +Liveness probes *do not* wait for readiness probes to succeed. If you want to wait before executing a liveness probe you should use initialDelaySeconds or a startupProbe. +{{< /warning >}} + Readiness probes are configured similarly to liveness probes. The only difference is that you use the `readinessProbe` field instead of the `livenessProbe` field. From 9ba5ddd01f3e1826df81fd85d497905f6f693737 Mon Sep 17 00:00:00 2001 From: Brad Jones Date: Fri, 29 Jan 2021 16:02:10 -0700 Subject: [PATCH 08/62] Clarify language regarding environment variable order --- .../define-environment-variable-container.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/content/en/docs/tasks/inject-data-application/define-environment-variable-container.md b/content/en/docs/tasks/inject-data-application/define-environment-variable-container.md index 9cefdca03d..02677d6204 100644 --- a/content/en/docs/tasks/inject-data-application/define-environment-variable-container.md +++ b/content/en/docs/tasks/inject-data-application/define-environment-variable-container.md @@ -70,8 +70,9 @@ override any environment variables specified in the container image. {{< /note >}} {{< note >}} -The environment variables can reference each other, and cycles are possible, -pay attention to the order before using +Environment variables may reference each other, however ordering is important. +Variables making use of others defined in the same context must come later in +the list. Similarly, avoid circular references. {{< /note >}} ## Using environment variables inside of your config From 52920a9a853dc4e45124ec09c032a90a0961b4f1 Mon Sep 17 00:00:00 2001 From: Peri Thompson <11655452+perithompson@users.noreply.github.com> Date: Thu, 11 Feb 2021 10:32:24 +0000 Subject: [PATCH 09/62] Added limitation with windows network services --- .../windows/intro-windows-in-kubernetes.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md b/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md index 014df012c7..57f867d0db 100644 --- a/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md +++ b/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md @@ -308,6 +308,7 @@ The following networking functionality is not supported on Windows nodes * Host networking mode is not available for Windows pods * Local NodePort access from the node itself fails (works for other nodes or external clients) * Accessing service VIPs from nodes will be available with a future release of Windows Server +* A single service can only support up to 64 backend pods / unique destination IPs * Overlay networking support in kube-proxy is an alpha release. In addition, it requires [KB4482887](https://support.microsoft.com/en-us/help/4482887/windows-10-update-kb4482887) to be installed on Windows Server 2019 * Local Traffic Policy and DSR mode * Windows containers connected to l2bridge, l2tunnel, or overlay networks do not support communicating over the IPv6 stack. There is outstanding Windows platform work required to enable these network drivers to consume IPv6 addresses and subsequent Kubernetes work in kubelet, kube-proxy, and CNI plugins. From deabf8430a748bea80756de9cb0464638b5d5e36 Mon Sep 17 00:00:00 2001 From: task4233 Date: Sat, 13 Feb 2021 17:32:41 +0900 Subject: [PATCH 10/62] ja: Make docs/reference/tools.md referencing en/docs/reference/tools.md --- content/ja/docs/reference/tools.md | 46 ++++++++++++++++++++++++++++++ 1 file changed, 46 insertions(+) create mode 100644 content/ja/docs/reference/tools.md diff --git a/content/ja/docs/reference/tools.md b/content/ja/docs/reference/tools.md new file mode 100644 index 0000000000..b1543b0eed --- /dev/null +++ b/content/ja/docs/reference/tools.md @@ -0,0 +1,46 @@ +--- +title: ツール +content_type: concept +--- + + +Kubernetesには、Kubernetesシステムの操作に役立ついくつかの組み込みツールが含まれています。 + + +## Kubectl +[`kubectl`](/docs/tasks/tools/install-kubectl/)は、Kubernetesのためのコマンドラインツールです。このコマンドはKubernetes cluster managerを操作します。 + +## Kubeadm +[`kubeadm`](docs/setup/production-environment/tools/kubeadm/install-kubeadm/)は、物理サーバやクラウドサーバ、仮想マシン上にKubenetesクラスタを容易にプロビジョニングするためのコマンドラインツールです(現在はアルファ版です)。 + +## Minikube +[`minikube`](https://minikube.sigs.k8s.io/docs/)は、開発やテストのためにワークステーション上でシングルノードのKubernetesクラスタをローカルで実行するツールです。 + +## Dashboard +[`Dashboard`](/docs/tasks/access-application-cluster/web-ui-dashboard/)は、KubernetesのWebベースのユーザインタフェースで、コンテナ化されたアプリケーションをKubernetesクラスタにデプロイしたり、トラブルシューティングしたり、クラスタとそのリソース自体を管理したりすることが出来ます。 + +## Helm +[`Kubernetes Helm`](https://github.com/helm/helm)は、事前に設定されたKubernetesリソースのパッケージ、別名Kubernetes chartsを管理するためのツールです。 + +Helmを用いて以下のことを行います。 + +* Kubernetes chartsとしてパッケージ化された人気のあるソフトウェアの検索と利用 + +* Kubernetes chartsとして所有するアプリケーションの共有すること + +* Kubernetesアプリケーションの再現性のあるビルドの作成 + +* 知的なKubernetesマニフェストファイルの管理 + +* Helmパッケージのリリース管理 + +## Kompose +[`Kompose`](https://github.com/kubernetes/kompose)は、Docker ComposeユーザがKubernetesに移行する手助けをするツールです。 + +Komposeを用いて以下のことを行います。 + +* Docker ComposeファイルのKubernetesオブジェクトへの変換 + +* ローカルのDocker開発からKubernetesを経由したアプリケーション管理への移行 + +* v1またはv2のDocker Compose用 `yaml` ファイルならびに[分散されたアプリケーションバンドル](https://docs.docker.com/compose/bundles/)の変換 From f58d7b5d1a70d864dc2f05dfaaaa02540116a43f Mon Sep 17 00:00:00 2001 From: sibucan Date: Sat, 13 Feb 2021 10:16:43 -0500 Subject: [PATCH 11/62] Mention time range where kubelet might renew cert The docs don't mention when the kubelet will attempt to renew a cert, which causes concern when one notices that certain certificates are being renewed and others are not. Adding the time frame adds certainty, so that if an user notices a kubelet cert expiring in less than 30d, they know something is misconfigured and should be looked at. --- content/en/docs/tasks/tls/certificate-rotation.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/content/en/docs/tasks/tls/certificate-rotation.md b/content/en/docs/tasks/tls/certificate-rotation.md index ea3602fbb0..5dd9b85714 100644 --- a/content/en/docs/tasks/tls/certificate-rotation.md +++ b/content/en/docs/tasks/tls/certificate-rotation.md @@ -69,8 +69,9 @@ write that to disk, in the location specified by `--cert-dir`. Then the kubelet will use the new certificate to connect to the Kubernetes API. As the expiration of the signed certificate approaches, the kubelet will -automatically issue a new certificate signing request, using the Kubernetes -API. Again, the controller manager will automatically approve the certificate +automatically issue a new certificate signing request, using the Kubernetes API. +This can happen at any point between 30% and 10% of the time remaining on the +certificate. Again, the controller manager will automatically approve the certificate request and attach a signed certificate to the certificate signing request. The kubelet will retrieve the new signed certificate from the Kubernetes API and write that to disk. Then it will update the connections it has to the From 7bea1dba77f490e8d88487fb3a96c17d03559e5e Mon Sep 17 00:00:00 2001 From: task4233 Date: Tue, 16 Feb 2021 23:42:56 +0900 Subject: [PATCH 12/62] Update content/ja/docs/reference/tools.md Co-authored-by: Kei Ak --- content/ja/docs/reference/tools.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/reference/tools.md b/content/ja/docs/reference/tools.md index b1543b0eed..924330afb5 100644 --- a/content/ja/docs/reference/tools.md +++ b/content/ja/docs/reference/tools.md @@ -30,7 +30,7 @@ Helmを用いて以下のことを行います。 * Kubernetesアプリケーションの再現性のあるビルドの作成 -* 知的なKubernetesマニフェストファイルの管理 +* Kubernetesマニフェストファイルを知的な方法で管理 * Helmパッケージのリリース管理 From 5b83d03add20f2defe5c1ffda4c60aa0fbdc85c3 Mon Sep 17 00:00:00 2001 From: task4233 Date: Tue, 16 Feb 2021 23:43:15 +0900 Subject: [PATCH 13/62] Update content/ja/docs/reference/tools.md Co-authored-by: Kei Ak --- content/ja/docs/reference/tools.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/reference/tools.md b/content/ja/docs/reference/tools.md index 924330afb5..0fedb1cf9d 100644 --- a/content/ja/docs/reference/tools.md +++ b/content/ja/docs/reference/tools.md @@ -26,7 +26,7 @@ Helmを用いて以下のことを行います。 * Kubernetes chartsとしてパッケージ化された人気のあるソフトウェアの検索と利用 -* Kubernetes chartsとして所有するアプリケーションの共有すること +* Kubernetes chartsとして所有するアプリケーションを共有すること * Kubernetesアプリケーションの再現性のあるビルドの作成 From e13661c5fe17c8da3ff98c7e9b3a13ef364ddd21 Mon Sep 17 00:00:00 2001 From: Karen Bradshaw Date: Tue, 16 Feb 2021 19:06:12 -0500 Subject: [PATCH 14/62] update style guide --- .../en/docs/contribute/style/style-guide.md | 89 ++++++++++--------- 1 file changed, 48 insertions(+), 41 deletions(-) diff --git a/content/en/docs/contribute/style/style-guide.md b/content/en/docs/contribute/style/style-guide.md index 0047799fb0..2439bff1af 100644 --- a/content/en/docs/contribute/style/style-guide.md +++ b/content/en/docs/contribute/style/style-guide.md @@ -17,8 +17,6 @@ Changes to the style guide are made by SIG Docs as a group. To propose a change or addition, [add it to the agenda](https://docs.google.com/document/d/1ddHwLK3kUMX1wVFIwlksjTk0MsqitBnWPe1LRa1Rx5A/edit) for an upcoming SIG Docs meeting, and attend the meeting to participate in the discussion. - - {{< note >}} @@ -48,12 +46,11 @@ When you refer specifically to interacting with an API object, use [UpperCamelCa When you are generally discussing an API object, use [sentence-style capitalization](https://docs.microsoft.com/en-us/style-guide/text-formatting/using-type/use-sentence-style-capitalization). -You may use the word "resource", "API", or "object" to clarify a Kubernetes resource type in a sentence. +You may use the word "resource", "API", or "object" to clarify a Kubernetes resource type in a sentence. -Don't split the API object name into separate words. For example, use -PodTemplateList, not Pod Template List. +Don't split an API object name into separate words. For example, use PodTemplateList, not Pod Template List. -The following examples focus on capitalization. Review the related guidance on [Code Style](#code-style-inline-code) for more information on formatting API objects. +The following examples focus on capitalization. For more information about formatting API object names, review the related guidance on [Code Style](#code-style-inline-code). {{< table caption = "Do and Don't - Use Pascal case for API objects" >}} Do | Don't @@ -65,17 +62,18 @@ Every ConfigMap object is part of a namespace. | Every configMap object is part For managing confidential data, consider using the Secret API. | For managing confidential data, consider using the secret API. {{< /table >}} - ### Use angle brackets for placeholders Use angle brackets for placeholders. Tell the reader what a placeholder -represents. +represents, for example: -1. Display information about a pod: +Display information about a pod: - kubectl describe pod -n +```shell +kubectl describe pod -n +``` - If the namespace of the pod is `default`, you can omit the '-n' parameter. +If the namespace of the pod is `default`, you can omit the '-n' parameter. ### Use bold for user interface elements @@ -189,7 +187,6 @@ Set the value of `image` to nginx:1.16. | Set the value of `image` to `nginx:1.1 Set the value of the `replicas` field to 2. | Set the value of the `replicas` field to `2`. {{< /table >}} - ## Code snippet formatting ### Don't include the command prompt @@ -200,17 +197,20 @@ Do | Don't kubectl get pods | $ kubectl get pods {{< /table >}} - ### Separate commands from output Verify that the pod is running on your chosen node: - kubectl get pods --output=wide +```shell +kubectl get pods --output=wide +``` The output is similar to this: - NAME READY STATUS RESTARTS AGE IP NODE - nginx 1/1 Running 0 13s 10.200.0.4 worker0 +```console +NAME READY STATUS RESTARTS AGE IP NODE +nginx 1/1 Running 0 13s 10.200.0.4 worker0 +``` ### Versioning Kubernetes examples @@ -263,17 +263,17 @@ Hugo [Shortcodes](https://gohugo.io/content-management/shortcodes) help create d 2. Use the following syntax to apply a style: - ``` - {{}} - No need to include a prefix; the shortcode automatically provides one. (Note:, Caution:, etc.) - {{}} - ``` + ```none + {{}} + No need to include a prefix; the shortcode automatically provides one. (Note:, Caution:, etc.) + {{}} + ``` -The output is: + The output is: -{{< note >}} -The prefix you choose is the same text for the tag. -{{< /note >}} + {{< note >}} + The prefix you choose is the same text for the tag. + {{< /note >}} ### Note @@ -403,7 +403,7 @@ The output is: 1. Prepare the batter, and pour into springform pan. - {{< note >}}Grease the pan for best results.{{< /note >}} + {{< note >}}Grease the pan for best results.{{< /note >}} 1. Bake for 20-25 minutes or until set. @@ -417,13 +417,14 @@ Shortcodes inside include statements will break the build. You must insert them {{}} ``` - ## Markdown elements ### Line breaks + Use a single newline to separate block-level content like headings, lists, images, code blocks, and others. The exception is second-level headings, where it should be two newlines. Second-level headings follow the first-level (or the title) without any preceding paragraphs or texts. A two line spacing helps visualize the overall structure of content in a code editor better. ### Headings + People accessing this documentation may use a screen reader or other assistive technology (AT). [Screen readers](https://en.wikipedia.org/wiki/Screen_reader) are linear output devices, they output items on a page one at a time. If there is a lot of content on a page, you can use headings to give the page an internal structure. A good page structure helps all readers to easily navigate the page or filter topics of interest. {{< table caption = "Do and Don't - Headings" >}} @@ -453,24 +454,24 @@ Write hyperlinks that give you context for the content they link to. For example Write Markdown-style links: `[link text](URL)`. For example: `[Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/#table-captions)` and the output is [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/#table-captions). | Write HTML-style links: `Visit our tutorial!`, or create links that open in new tabs or windows. For example: `[example website](https://example.com){target="_blank"}` {{< /table >}} - ### Lists + Group items in a list that are related to each other and need to appear in a specific order or to indicate a correlation between multiple items. When a screen reader comes across a list—whether it is an ordered or unordered list—it will be announced to the user that there is a group of list items. The user can then use the arrow keys to move up and down between the various items in the list. Website navigation links can also be marked up as list items; after all they are nothing but a group of related links. - - End each item in a list with a period if one or more items in the list are complete sentences. For the sake of consistency, normally either all items or none should be complete sentences. +- End each item in a list with a period if one or more items in the list are complete sentences. For the sake of consistency, normally either all items or none should be complete sentences. - {{< note >}} Ordered lists that are part of an incomplete introductory sentence can be in lowercase and punctuated as if each item was a part of the introductory sentence.{{< /note >}} + {{< note >}} Ordered lists that are part of an incomplete introductory sentence can be in lowercase and punctuated as if each item was a part of the introductory sentence.{{< /note >}} - - Use the number one (`1.`) for ordered lists. +- Use the number one (`1.`) for ordered lists. - - Use (`+`), (`*`), or (`-`) for unordered lists. +- Use (`+`), (`*`), or (`-`) for unordered lists. - - Leave a blank line after each list. +- Leave a blank line after each list. - - Indent nested lists with four spaces (for example, ⋅⋅⋅⋅). +- Indent nested lists with four spaces (for example, ⋅⋅⋅⋅). - - List items may consist of multiple paragraphs. Each subsequent paragraph in a list item must be indented by either four spaces or one tab. +- List items may consist of multiple paragraphs. Each subsequent paragraph in a list item must be indented by either four spaces or one tab. ### Tables @@ -490,7 +491,6 @@ Do | Don't This command starts a proxy. | This command will start a proxy. {{< /table >}} - Exception: Use future or past tense if it is required to convey the correct meaning. @@ -503,7 +503,6 @@ You can explore the API using a browser. | The API can be explored using a brows The YAML file specifies the replica count. | The replica count is specified in the YAML file. {{< /table >}} - Exception: Use passive voice if active voice leads to an awkward construction. ### Use simple and direct language @@ -527,7 +526,6 @@ You can create a Deployment by ... | We'll create a Deployment by ... In the preceding output, you can see... | In the preceding output, we can see ... {{< /table >}} - ### Avoid Latin phrases Prefer English terms over Latin abbreviations. @@ -539,7 +537,6 @@ For example, ... | e.g., ... That is, ...| i.e., ... {{< /table >}} - Exception: Use "etc." for et cetera. ## Patterns to avoid @@ -557,7 +554,6 @@ Kubernetes provides a new feature for ... | We provide a new feature ... This page teaches you how to use pods. | In this page, we are going to learn about pods. {{< /table >}} - ### Avoid jargon and idioms Some readers speak English as a second language. Avoid jargon and idioms to help them understand better. @@ -569,7 +565,6 @@ Internally, ... | Under the hood, ... Create a new cluster. | Turn up a new cluster. {{< /table >}} - ### Avoid statements about the future Avoid making promises or giving hints about the future. If you need to talk about @@ -588,6 +583,18 @@ In version 1.4, ... | In the current version, ... The Federation feature provides ... | The new Federation feature provides ... {{< /table >}} +### Avoid words that assume a specific level of understanding + +Avoid words such as "just", "simply", "easy", "easily", or "simple". These words do not add value. + +{{< table caption = "Do and Don't - Avoid insensitive words" >}} +Do | Don't +:--| :----- +Include one command in ... | Include just one command in ... +Run the container ... | Simply run the container ... +You can easily remove ... | You can remove ... +These simple steps ... | These steps ... +{{< /table >}} ## {{% heading "whatsnext" %}} From d71ec88c5c33af4f16e65cf05c600125dccf4ded Mon Sep 17 00:00:00 2001 From: Kazuki Suda Date: Wed, 17 Feb 2021 12:38:03 +0900 Subject: [PATCH 15/62] ja: Fix the translation about nodeSelectorTerms of Node affinity --- .../ja/docs/concepts/scheduling-eviction/assign-pod-node.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md index 0733690f0b..18b767cbb4 100644 --- a/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -140,9 +140,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をスケジュールする際にのみ考慮されます。 From 8cb0137b7ca058dc953e3ee2cbe119491bca40d4 Mon Sep 17 00:00:00 2001 From: marosset Date: Wed, 17 Feb 2021 11:13:09 -0800 Subject: [PATCH 16/62] Updating containerd on Windows install steps to add Defender Exclusion --- .../container-runtimes.md | 23 +++++++++++++------ 1 file changed, 16 insertions(+), 7 deletions(-) diff --git a/content/en/docs/setup/production-environment/container-runtimes.md b/content/en/docs/setup/production-environment/container-runtimes.md index 59725188d8..15bb4b3df7 100644 --- a/content/en/docs/setup/production-environment/container-runtimes.md +++ b/content/en/docs/setup/production-environment/container-runtimes.md @@ -219,30 +219,39 @@ sudo systemctl restart containerd ``` {{% /tab %}} {{% tab name="Windows (PowerShell)" %}} + +
+Start a Powershell session, set `$Version` to the desired version (ex: `$Version=1.4.3`), and then run the following commands: +
+ ```powershell # (Install containerd) -# download containerd -cmd /c curl -OL https://github.com/containerd/containerd/releases/download/v1.4.1/containerd-1.4.1-windows-amd64.tar.gz -cmd /c tar xvf .\containerd-1.4.1-windows-amd64.tar.gz +# Download containerd +curl.exe -L https://github.com/containerd/containerd/releases/download/v$Version/containerd-$Version-windows-amd64.tar.gz -o containerd-windows-amd64.tar.gz +tar.exe xvf .\containerd-windows-amd64.tar.gz ``` ```powershell -# extract and configure +# Extract and configure Copy-Item -Path ".\bin\" -Destination "$Env:ProgramFiles\containerd" -Recurse -Force cd $Env:ProgramFiles\containerd\ .\containerd.exe config default | Out-File config.toml -Encoding ascii -# review the configuration. depending on setup you may want to adjust: -# - the sandbox_image (kubernetes pause image) +# Review the configuration. Depending on setup you may want to adjust: +# - the sandbox_image (Kubernetes pause image) # - cni bin_dir and conf_dir locations Get-Content config.toml + +# (Optional - but highly recommended) Exclude containerd form Windows Defender Scans +Add-MpPreference -ExclusionProcess "$Env:ProgramFiles\containerd\containerd.exe" ``` ```powershell -# start containerd +# Start containerd .\containerd.exe --register-service Start-Service containerd ``` + {{% /tab %}} {{< /tabs >}} From 682d3c2550b2f3120aa4fcf41ba641f9ed019dec Mon Sep 17 00:00:00 2001 From: Zhizhen He Date: Sat, 20 Feb 2021 16:47:02 +0800 Subject: [PATCH 17/62] Rephrase the sentence --- content/en/docs/concepts/services-networking/service.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/en/docs/concepts/services-networking/service.md b/content/en/docs/concepts/services-networking/service.md index a6dd80ba63..ea0f01ab0d 100644 --- a/content/en/docs/concepts/services-networking/service.md +++ b/content/en/docs/concepts/services-networking/service.md @@ -74,8 +74,8 @@ a new instance. The name of a Service object must be a valid [DNS label name](/docs/concepts/overview/working-with-objects/names#dns-label-names). -For example, suppose you have a set of Pods that each listens on TCP port 9376 -and carry a label `app=MyApp`: +For example, suppose you have a set of Pods and each of them listens on TCP port 9376 +and contains a label `app=MyApp`: ```yaml apiVersion: v1 From f381ec8dc3ac60f5afa9d928d76fe17737ff6d25 Mon Sep 17 00:00:00 2001 From: Jailton Lopes Date: Sat, 20 Feb 2021 16:04:00 -0300 Subject: [PATCH 18/62] Update docs/tutorials/kubernetes-basics/public/images/module_01_cluster.svg to to use the "control plane" terminology Signed-off-by: Jailton Lopes --- .../public/images/module_01_cluster.svg | 633 +++++++++++++----- 1 file changed, 460 insertions(+), 173 deletions(-) diff --git a/content/en/docs/tutorials/kubernetes-basics/public/images/module_01_cluster.svg b/content/en/docs/tutorials/kubernetes-basics/public/images/module_01_cluster.svg index e1f92dace0..b183377467 100644 --- a/content/en/docs/tutorials/kubernetes-basics/public/images/module_01_cluster.svg +++ b/content/en/docs/tutorials/kubernetes-basics/public/images/module_01_cluster.svg @@ -1,6 +1,32 @@ - - - From 25a21cb87abd250e2f832ef6f5619ac7f270f1cb Mon Sep 17 00:00:00 2001 From: Jailton Lopes Date: Sat, 20 Feb 2021 16:17:31 -0300 Subject: [PATCH 19/62] Update content/en/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html to to use the "control plane" terminology Signed-off-by: Jailton Lopes --- .../create-cluster/cluster-intro.html | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/content/en/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html b/content/en/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html index 5ac682d7af..47a2629feb 100644 --- a/content/en/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html +++ b/content/en/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html @@ -33,7 +33,7 @@ weight: 10

A Kubernetes cluster consists of two types of resources:

    -
  • The Master coordinates the cluster
    • +
  • The Control Plane coordinates the cluster
  • Nodes are the workers that run applications

@@ -71,22 +71,22 @@ weight: 10
-

The Master is responsible for managing the cluster. The master coordinates all activities in your cluster, such as scheduling applications, maintaining applications' desired state, scaling applications, and rolling out new updates.

-

A node is a VM or a physical computer that serves as a worker machine in a Kubernetes cluster. Each node has a Kubelet, which is an agent for managing the node and communicating with the Kubernetes master. The node should also have tools for handling container operations, such as containerd or Docker. A Kubernetes cluster that handles production traffic should have a minimum of three nodes.

+

The Control Plane is responsible for managing the cluster. The Control Plane coordinates all activities in your cluster, such as scheduling applications, maintaining applications' desired state, scaling applications, and rolling out new updates.

+

A node is a VM or a physical computer that serves as a worker machine in a Kubernetes cluster. Each node has a Kubelet, which is an agent for managing the node and communicating with the Kubernetes control plane. The node should also have tools for handling container operations, such as containerd or Docker. A Kubernetes cluster that handles production traffic should have a minimum of three nodes.

-

Masters manage the cluster and the nodes that are used to host the running applications.

+

Control Planes manage the cluster and the nodes that are used to host the running applications.

-

When you deploy applications on Kubernetes, you tell the master to start the application containers. The master schedules the containers to run on the cluster's nodes. The nodes communicate with the master using the Kubernetes API, which the master exposes. End users can also use the Kubernetes API directly to interact with the cluster.

+

When you deploy applications on Kubernetes, you tell the control plane to start the application containers. The control plane schedules the containers to run on the cluster's nodes. The nodes communicate with the control plane using the Kubernetes API, which the control plane exposes. End users can also use the Kubernetes API directly to interact with the cluster.

-

A Kubernetes cluster can be deployed on either physical or virtual machines. To get started with Kubernetes development, you can use Minikube. Minikube is a lightweight Kubernetes implementation that creates a VM on your local machine and deploys a simple cluster containing only one node. Minikube is available for Linux, macOS, and Windows systems. The Minikube CLI provides basic bootstrapping operations for working with your cluster, including start, stop, status, and delete. For this tutorial, however, you'll use a provided online terminal with Minikube pre-installed.

+

A Kubernetes cluster can be deployed on either physical or virtual machines. To get started with Kubernetes development, you can use Minikube. Minikube is a lightweight Kubernetes implementation that creates a VM on your local machine and deploys a simple cluster containing only one node. Minikube is available for Linux, macOS, and Windows systems. The Minikube CLI provides basic bootstrapping operations for working with your cluster, including start, stop, status, and delete. For this tutorial, however, you'll use a provided online terminal with Minikube pre-installed.

Now that you know what Kubernetes is, let's go to the online tutorial and start our first cluster!

From 89d90304c6e53af1a34dcf49f76b7a05e79f87bf Mon Sep 17 00:00:00 2001 From: Michael Washer Date: Sun, 21 Feb 2021 17:36:37 +1300 Subject: [PATCH 20/62] Update container-environment.md with fix about service environment variables not being cluster-wide --- content/en/docs/concepts/containers/container-environment.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/en/docs/concepts/containers/container-environment.md b/content/en/docs/concepts/containers/container-environment.md index 7ec28e97b4..8173cc9d8d 100644 --- a/content/en/docs/concepts/containers/container-environment.md +++ b/content/en/docs/concepts/containers/container-environment.md @@ -40,6 +40,7 @@ as are any environment variables specified statically in the Docker image. ### Cluster information A list of all services that were running when a Container was created is available to that Container as environment variables. +This list is limited to services within the same namespace as the new Container's Pod and Kubernetes master services. Those environment variables match the syntax of Docker links. For a service named *foo* that maps to a Container named *bar*, From 7373ebbb38254cd97ac00e99711cb4d2a1a76592 Mon Sep 17 00:00:00 2001 From: Guilherme Zanelato Date: Sat, 20 Feb 2021 07:57:14 -0300 Subject: [PATCH 21/62] Add content/pt/docs/concepts/configuration/organize-cluster-access-kubeconfig.md --- .../organize-cluster-access-kubeconfig.md | 131 ++++++++++++++++++ 1 file changed, 131 insertions(+) create mode 100644 content/pt/docs/concepts/configuration/organize-cluster-access-kubeconfig.md diff --git a/content/pt/docs/concepts/configuration/organize-cluster-access-kubeconfig.md b/content/pt/docs/concepts/configuration/organize-cluster-access-kubeconfig.md new file mode 100644 index 0000000000..4b431b486f --- /dev/null +++ b/content/pt/docs/concepts/configuration/organize-cluster-access-kubeconfig.md @@ -0,0 +1,131 @@ +--- +title: Organizando o acesso ao cluster usando arquivos kubeconfig +content_type: concept +weight: 60 +--- + + + +Utilize arquivos kubeconfig para organizar informações sobre clusters, usuários, namespaces e mecanismos de autenticação. A ferramenta de linha de comando `kubectl` faz uso dos arquivos kubeconfig para encontrar as informações necessárias para escolher e se comunicar com o serviço de API de um cluster. + + +{{< note >}} +Um arquivo que é utilizado para configurar o acesso aos clusters é chamado de *kubeconfig*. Esta á uma forma genérica de referenciamento para um arquivo de configuração desta natureza. Isso não significa que existe um arquivo com o nome `kubeconfig`. +{{< /note >}} + +Por padrão, o `kubectl` procura por um arquivo de nome `config` no diretório `$HOME/.kube` + +Você pode especificar outros arquivos kubeconfig através da variável de ambiente `KUBECONFIG` ou adicionando a opção [`--kubeconfig`](/docs/reference/generated/kubectl/kubectl/). + +Para maiores detalhes na criação e especificação de um kubeconfig, veja o passo a passo em [Configurar Acesso para Múltiplos Clusters](/docs/tasks/access-application-cluster/configure-access-multiple-clusters). + + + + +## Suportando múltiplos clusters, usuários e mecanismos de autenticação + +Imagine que você possua inúmeros clusters, e seus usuários e componentes se autenticam de várias formas. Por exemplo: + +- Um kubelet ativo pode se autenticar utilizando certificados +- Um usuário pode se autenticar através de tokens +- Administradores podem possuir conjuntos de certificados os quais provém acesso aos usuários de forma individual. + +Através de arquivos kubeconfig, você pode organizar os seus clusters, usuários, e namespaces. Você também pode definir contextos para uma fácil troca entre clusters e namespaces. + + +## Contexto + +Um elemento de *contexto* em um kubeconfig é utilizado para agrupar parâmetros de acesso em um nome conveniente. Cada contexto possui três parâmetros: cluster, namespace, e usuário. + +Por padrão, a ferramenta de linha de comando `kubectl` utiliza os parâmetros do _contexto atual_ para se comunicar com o cluster. + +Para escolher o contexto atual: + +```shell +kubectl config use-context +``` + +## A variável de ambiente KUBECONFIG + +A variável de ambiente `KUBECONFIG` possui uma lista dos arquivos kubeconfig. Para Linux e Mac, esta lista é delimitada por vírgula. No Windows, a lista é delimitada por ponto e vírgula. A variável de ambiente `KUBECONFIG` não é um requisito obrigatório - caso ela não exista o `kubectl` utilizará o arquivo kubeconfig padrão localizado no caminho `$HOME/.kube/config`. + +Se a variável de ambiente `KUBECONFIG` existir, o `kubectl` utilizará uma configuração que é o resultado da combinação dos arquivos listados na variável de ambiente `KUBECONFIG`. + +## Combinando arquivos kubeconfig + +Para inspecionar a sua configuração atual, execute o seguinte comando: + +```shell +kubectl config view +``` + +Como descrito anteriormente, a saída poderá ser resultado de um único arquivo kubeconfig, ou poderá ser o resultado da junção de vários arquivos kubeconfig. + +Aqui estão as regras que o `kubectl` utiliza quando realiza a combinação de arquivos kubeconfig: + +1. Se o argumento `--kubeconfig` está definido, apenas o arquivo especificado será utilizado. Apenas uma instância desta flag é permitida. + + Caso contrário, se a variável de ambiente `KUBECONFIG` estiver definida, esta deverá ser utilizada como uma lista de arquivos a serem combinados, seguindo o fluxo a seguir: + + * Ignorar arquivos vazios. + * Produzir erros para aquivos cujo conteúdo não for possível desserializar. + * O primeiro arquivo que definir um valor ou mapear uma chave determinada, será o escolhido. + * Nunca modificar um valor ou mapear uma chave. + Exemplo: Preservar o contexto do primeiro arquivo que definir `current-context`. + Exemplo: Se dois arquivos especificarem um `red-user`, use apenas os valores do primeiro `red-user`. Mesmo se um segundo arquivo possuir entradas não conflitantes sobre a mesma entrada `red-user`, estas deverão ser descartadas. + + Para um exemplo de definição da variável de ambiente `KUBECONFIG` veja [Definido a variável de ambiente KUBECONFIG](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable). + + Caso contrário, utilize o arquivo kubeconfig padrão encontrado no diretório `$HOME/.kube/config`, sem qualquer tipo de combinação. + +1. Determine o contexto a ser utilizado baseado no primeiro padrão encontrado, nesta ordem: + + 1. Usar o conteúdo da flag `--context` caso ela existir. + 1. Usar o `current-context` a partir da combinação dos arquivos kubeconfig. + + + Um contexto vazio é permitido neste momento. + + +1. Determinar o cluster e o usuário. Neste ponto, poderá ou não existir um contexto. + Determinar o cluster e o usuário no primeiro padrão encontrado de acordo com a ordem à seguir. Este procedimento deverá executado duas vezes: uma para definir o usuário a outra para definir o cluster. + + 1. Utilizar a flag caso ela existir: `--user` ou `--cluster`. + 1. Se o contexto não estiver vazio, utilizar o cluster ou usuário deste contexto. + + O usuário e o cluster poderão estar vazios neste ponto. + +1. Determinar as informações do cluster atual a serem utilizadas. Neste ponto, poderá ou não existir informações de um cluster. + + Construir cada peça de informação do cluster baseado nas opções à seguir; a primeira ocorrência encontrada será a opção vencedora: + + 1. Usar as flags de linha de comando caso existirem: `--server`, `--certificate-authority`, `--insecure-skip-tls-verify`. + 1. Se algum atributo do cluster existir a partir da combinação de kubeconfigs, estes deverão ser utilizados. + 1. Se não existir informação de localização do servidor falhar. + +1. Determinar a informação atual de usuário a ser utilizada. Construir a informação de usuário utilizando as mesmas regras utilizadas para o caso de informações de cluster, exceto para a regra de técnica de autenticação que deverá ser única por usuário: + + 1. Usar as flags, caso existirem: `--client-certificate`, `--client-key`, `--username`, `--password`, `--token`. + 1. Usar os campos `user` resultado da combinação de arquivos kubeconfig. + 1. Se existirem duas técnicas conflitantes, falhar. + +1. Para qualquer informação que ainda estiver ausente, utilizar os valores padrão e potencialmente solicitar informações de autenticação a partir do prompt de comando. + + +## Referências de arquivos + +Arquivos e caminhos referenciados em um arquivo kubeconfig são relativos à localização do arquivo kubeconfig. + +Referências de arquivos na linha de comando são relativas ao diretório de trabalho vigente. + +No arquivo `$HOME/.kube/config`, caminhos relativos são armazenados de forma relativa, e caminhos absolutos são armazenados de forma absoluta. + +## {{% heading "whatsnext" %}} + + +* [Configurar Accesso para Multiplos Clusters](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) +* [`kubectl config`](/docs/reference/generated/kubectl/kubectl-commands#config) + + + + From 13379c974cf079296c5e7f0f7d86f586b771529a Mon Sep 17 00:00:00 2001 From: BITLIU Date: Tue, 23 Feb 2021 21:37:58 +0800 Subject: [PATCH 22/62] Fix Markdown Error --- content/zh/docs/concepts/architecture/nodes.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/zh/docs/concepts/architecture/nodes.md b/content/zh/docs/concepts/architecture/nodes.md index 7c6000268f..dab5e341ff 100644 --- a/content/zh/docs/concepts/architecture/nodes.md +++ b/content/zh/docs/concepts/architecture/nodes.md @@ -457,8 +457,7 @@ of the node heartbeats as the cluster scales. #### 心跳机制 {#heartbeats} Kubernetes 节点发送的心跳（Heartbeats）有助于确定节点的可用性。 -心跳有两种形式：`NodeStatus` 和 [`Lease` 对象] -(/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#lease-v1-coordination-k8s-io)。 +心跳有两种形式：`NodeStatus` 和 [`Lease` 对象](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#lease-v1-coordination-k8s-io)。 每个节点在 `kube-node-lease`{{< glossary_tooltip term_id="namespace" text="名字空间">}} 中都有一个与之关联的 `Lease` 对象。 `Lease` 是一种轻量级的资源，可在集群规模扩大时提高节点心跳机制的性能。 From 072ac32064dcced698c9a39bacfc4d588e3907e6 Mon Sep 17 00:00:00 2001 From: diegonuevo <79473549+diegonuevo@users.noreply.github.com> Date: Tue, 23 Feb 2021 16:28:08 +0100 Subject: [PATCH 23/62] Corrected Docker(shim) UNIX domain socket file This page listed `/var/run/docker.sock` as the UNIX domain socket path for the Docker container runtime, but it's actually `/var/run/dockershim.sock`, as the kubelet documentation indicates as the default value for the `--container-runtime-endpoint` argument: https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/ The socket file specified (`/var/run/docker.sock`) is where the Docker daemon listens for requests for the Docker API, not the CRI interface. --- .../production-environment/tools/kubeadm/install-kubeadm.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md index 394820324d..33d41ed8a9 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md @@ -122,7 +122,7 @@ The following table lists container runtimes and their associated socket paths: {{< table caption = "Container runtimes and their socket paths" >}} | Runtime | Path to Unix domain socket | |------------|-----------------------------------| -| Docker | `/var/run/docker.sock` | +| Docker | `/var/run/dockershim.sock` | | containerd | `/run/containerd/containerd.sock` | | CRI-O | `/var/run/crio/crio.sock` | {{< /table >}} From 4875e21a48f94ffa5dc50e9eaf788702bfdad388 Mon Sep 17 00:00:00 2001 From: Michael Washer Date: Wed, 24 Feb 2021 16:00:18 +1300 Subject: [PATCH 24/62] Resolve Control Plane misnaming --- content/en/docs/concepts/containers/container-environment.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/containers/container-environment.md b/content/en/docs/concepts/containers/container-environment.md index 8173cc9d8d..a1eba4d96d 100644 --- a/content/en/docs/concepts/containers/container-environment.md +++ b/content/en/docs/concepts/containers/container-environment.md @@ -40,7 +40,7 @@ as are any environment variables specified statically in the Docker image. ### Cluster information A list of all services that were running when a Container was created is available to that Container as environment variables. -This list is limited to services within the same namespace as the new Container's Pod and Kubernetes master services. +This list is limited to services within the same namespace as the new Container's Pod and Kubernetes control plane services. Those environment variables match the syntax of Docker links. For a service named *foo* that maps to a Container named *bar*, From 0e2aea53be53539a1124cebaafb37ae5ba7a1372 Mon Sep 17 00:00:00 2001 From: Dominic Yin Date: Wed, 24 Feb 2021 14:26:18 +0800 Subject: [PATCH 25/62] remove period at end of a list line #25656 --- content/zh/docs/concepts/overview/components.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/zh/docs/concepts/overview/components.md b/content/zh/docs/concepts/overview/components.md index 1e42cdcbaa..090468282a 100644 --- a/content/zh/docs/concepts/overview/components.md +++ b/content/zh/docs/concepts/overview/components.md @@ -92,10 +92,10 @@ These controllers include: --> 这些控制器包括: -* 节点控制器（Node Controller）: 负责在节点出现故障时进行通知和响应。 -* 副本控制器（Replication Controller）: 负责为系统中的每个副本控制器对象维护正确数量的 Pod。 -* 端点控制器（Endpoints Controller）: 填充端点(Endpoints)对象(即加入 Service 与 Pod)。 -* 服务帐户和令牌控制器（Service Account & Token Controllers）: 为新的命名空间创建默认帐户和 API 访问令牌. +* 节点控制器（Node Controller）: 负责在节点出现故障时进行通知和响应 +* 副本控制器（Replication Controller）: 负责为系统中的每个副本控制器对象维护正确数量的 Pod +* 端点控制器（Endpoints Controller）: 填充端点(Endpoints)对象(即加入 Service 与 Pod) +* 服务帐户和令牌控制器（Service Account & Token Controllers）: 为新的命名空间创建默认帐户和 API 访问令牌 Kubernetes 通过将容器放入在节点（Node）上运行的 Pod 中来执行你的工作负载。 -节点可以是一个虚拟机或者物理机器，取决于所在的集群配置。每个节点由 -{{< glossary_tooltip text="控制面" term_id="control-plane" >}} 负责管理， -并包含运行 {{< glossary_tooltip text="Pods" term_id="pod" >}} 所需的服务。 +节点可以是一个虚拟机或者物理机器，取决于所在的集群配置。 +每个节点包含运行 {{< glossary_tooltip text="Pods" term_id="pod" >}} 所需的服务， +这些 Pods 由 {{< glossary_tooltip text="控制面" term_id="control-plane" >}} 负责管理。 通常集群中会有若干个节点；而在一个学习用或者资源受限的环境中，你的集群中也可能 只有一个节点。 @@ -121,7 +120,7 @@ register itself with the API server. This is the preferred pattern, used by mos For self-registration, the kubelet is started with the following options: --> -### 节点自注册 +### 节点自注册 {#self-registration-of-nodes} 当 kubelet 标志 `--register-node` 为 true（默认）时，它会尝试向 API 服务注册自己。 这是首选模式，被绝大多数发行版选用。 @@ -171,7 +170,7 @@ When you want to create Node objects manually, set the kubelet flag `--register- You can modify Node objects regardless of the setting of `--register-node`. For example, you can set labels on an existing Node, or mark it unschedulable. --> -### 手动节点管理 +### 手动节点管理 {#manual-node-administration} 你可以使用 {{< glossary_tooltip text="kubectl" term_id="kubectl" >}} 来创建和修改 Node 对象。 From 6b092d754823a03576abb8aa73b19ece989a8e9e Mon Sep 17 00:00:00 2001 From: BITLIU Date: Wed, 24 Feb 2021 18:10:28 +0800 Subject: [PATCH 27/62] Update deprecated URL update https://www.haproxy.org/download/1.5/doc/proxy-protocol.txt to https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt --- content/en/docs/tutorials/services/source-ip.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/tutorials/services/source-ip.md b/content/en/docs/tutorials/services/source-ip.md index 2d938f3031..4ed574e158 100644 --- a/content/en/docs/tutorials/services/source-ip.md +++ b/content/en/docs/tutorials/services/source-ip.md @@ -412,7 +412,7 @@ protocol between the loadbalancer and backend to communicate the true client IP such as the HTTP [Forwarded](https://tools.ietf.org/html/rfc7239#section-5.2) or [X-FORWARDED-FOR](https://en.wikipedia.org/wiki/X-Forwarded-For) headers, or the -[proxy protocol](https://www.haproxy.org/download/1.5/doc/proxy-protocol.txt). +[proxy protocol](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt). Load balancers in the second category can leverage the feature described above by creating an HTTP health check pointing at the port stored in the `service.spec.healthCheckNodePort` field on the Service. From 3a7c478d65604662d174519a2b55070bf49144e4 Mon Sep 17 00:00:00 2001 From: BITLIU Date: Wed, 24 Feb 2021 18:39:13 +0800 Subject: [PATCH 28/62] Fix Helm install instruction URL https://github.com/kubernetes/helm/blob/master/docs/install.md is deprecated --- .../tasks/service-catalog/install-service-catalog-using-helm.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/zh/docs/tasks/service-catalog/install-service-catalog-using-helm.md b/content/zh/docs/tasks/service-catalog/install-service-catalog-using-helm.md index ecc001e62d..66f0dd1e1e 100644 --- a/content/zh/docs/tasks/service-catalog/install-service-catalog-using-helm.md +++ b/content/zh/docs/tasks/service-catalog/install-service-catalog-using-helm.md @@ -39,7 +39,7 @@ Use [Helm](https://helm.sh/) to install Service Catalog on your Kubernetes clust * 如果你正在使用 `hack/local-up-cluster.sh`，请确保设置了 `KUBE_ENABLE_CLUSTER_DNS` 环境变量，然后运行安装脚本。 * [安装和设置 v1.7 或更高版本的 kubectl](/zh/docs/tasks/tools/install-kubectl/)，确保将其配置为连接到 Kubernetes 集群。 * 安装 v2.7.0 或更高版本的 [Helm](https://helm.sh/)。 - * 遵照 [Helm 安装说明](https://github.com/kubernetes/helm/blob/master/docs/install.md)。 + * 遵照 [Helm 安装说明](https://helm.sh/docs/intro/install/)。 * 如果已经安装了适当版本的 Helm，请执行 `helm init` 来安装 Helm 的服务器端组件 Tiller。 From bd55d498df830825f7e9f9a8fd02e41afe048e99 Mon Sep 17 00:00:00 2001 From: veyu Date: Wed, 24 Feb 2021 18:58:22 +0100 Subject: [PATCH 29/62] Clarify requirements for label value syntax --- .../en/docs/concepts/overview/working-with-objects/labels.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/content/en/docs/concepts/overview/working-with-objects/labels.md b/content/en/docs/concepts/overview/working-with-objects/labels.md index 7ff6f267a0..811d9fb3f7 100644 --- a/content/en/docs/concepts/overview/working-with-objects/labels.md +++ b/content/en/docs/concepts/overview/working-with-objects/labels.md @@ -52,7 +52,10 @@ If the prefix is omitted, the label Key is presumed to be private to the user. A The `kubernetes.io/` and `k8s.io/` prefixes are reserved for Kubernetes core components. -Valid label values must be 63 characters or less and must be empty or begin and end with an alphanumeric character (`[a-z0-9A-Z]`) with dashes (`-`), underscores (`_`), dots (`.`), and alphanumerics between. +Valid label value: +* must be 63 characters or less (cannot be empty), +* must begin and end with an alphanumeric character (`[a-z0-9A-Z]`), +* could contain dashes (`-`), underscores (`_`), dots (`.`), and alphanumerics between. For example, here's the configuration file for a Pod that has two labels `environment: production` and `app: nginx` : From 41220636ec55c393f6b2725f79d0a375d61059b3 Mon Sep 17 00:00:00 2001 From: Neha Viswanathan Date: Sat, 16 Jan 2021 19:16:46 -0800 Subject: [PATCH 30/62] Migrate https://kubernetes.io/docs/concepts/cluster-administration/certificates/ to tasks section --- .../concepts/cluster-administration/_index.md | 2 +- .../cluster-administration/certificates.md | 245 +---------------- .../access-authn-authz/authentication.md | 2 +- .../tasks/administer-cluster/certificates.md | 252 ++++++++++++++++++ .../tls/manual-rotation-of-ca-certificates.md | 4 +- 5 files changed, 257 insertions(+), 248 deletions(-) create mode 100644 content/en/docs/tasks/administer-cluster/certificates.md diff --git a/content/en/docs/concepts/cluster-administration/_index.md b/content/en/docs/concepts/cluster-administration/_index.md index cac156b53b..7d5aec5078 100644 --- a/content/en/docs/concepts/cluster-administration/_index.md +++ b/content/en/docs/concepts/cluster-administration/_index.md @@ -45,7 +45,7 @@ Before choosing a guide, here are some considerations: ## Securing a cluster -* [Certificates](/docs/concepts/cluster-administration/certificates/) describes the steps to generate certificates using different tool chains. +* [Generate Certificates](/docs/tasks/administer-cluster/certificates/) describes the steps to generate certificates using different tool chains. * [Kubernetes Container Environment](/docs/concepts/containers/container-environment/) describes the environment for Kubelet managed containers on a Kubernetes node. diff --git a/content/en/docs/concepts/cluster-administration/certificates.md b/content/en/docs/concepts/cluster-administration/certificates.md index 6314420c01..6cce47f13c 100644 --- a/content/en/docs/concepts/cluster-administration/certificates.md +++ b/content/en/docs/concepts/cluster-administration/certificates.md @@ -4,249 +4,6 @@ content_type: concept weight: 20 --- - -When using client certificate authentication, you can generate certificates -manually through `easyrsa`, `openssl` or `cfssl`. - - - - - - -### easyrsa - -**easyrsa** can manually generate certificates for your cluster. - -1. Download, unpack, and initialize the patched version of easyrsa3. - - curl -LO https://storage.googleapis.com/kubernetes-release/easy-rsa/easy-rsa.tar.gz - tar xzf easy-rsa.tar.gz - cd easy-rsa-master/easyrsa3 - ./easyrsa init-pki -1. Generate a new certificate authority (CA). `--batch` sets automatic mode; - `--req-cn` specifies the Common Name (CN) for the CA's new root certificate. - - ./easyrsa --batch "--req-cn=${MASTER_IP}@`date +%s`" build-ca nopass -1. Generate server certificate and key. - The argument `--subject-alt-name` sets the possible IPs and DNS names the API server will - be accessed with. The `MASTER_CLUSTER_IP` is usually the first IP from the service CIDR - that is specified as the `--service-cluster-ip-range` argument for both the API server and - the controller manager component. The argument `--days` is used to set the number of days - after which the certificate expires. - The sample below also assumes that you are using `cluster.local` as the default - DNS domain name. - - ./easyrsa --subject-alt-name="IP:${MASTER_IP},"\ - "IP:${MASTER_CLUSTER_IP},"\ - "DNS:kubernetes,"\ - "DNS:kubernetes.default,"\ - "DNS:kubernetes.default.svc,"\ - "DNS:kubernetes.default.svc.cluster,"\ - "DNS:kubernetes.default.svc.cluster.local" \ - --days=10000 \ - build-server-full server nopass -1. Copy `pki/ca.crt`, `pki/issued/server.crt`, and `pki/private/server.key` to your directory. -1. Fill in and add the following parameters into the API server start parameters: - - --client-ca-file=/yourdirectory/ca.crt - --tls-cert-file=/yourdirectory/server.crt - --tls-private-key-file=/yourdirectory/server.key - -### openssl - -**openssl** can manually generate certificates for your cluster. - -1. Generate a ca.key with 2048bit: - - openssl genrsa -out ca.key 2048 -1. According to the ca.key generate a ca.crt (use -days to set the certificate effective time): - - openssl req -x509 -new -nodes -key ca.key -subj "/CN=${MASTER_IP}" -days 10000 -out ca.crt -1. Generate a server.key with 2048bit: - - openssl genrsa -out server.key 2048 -1. Create a config file for generating a Certificate Signing Request (CSR). - Be sure to substitute the values marked with angle brackets (e.g. ``) - with real values before saving this to a file (e.g. `csr.conf`). - Note that the value for `MASTER_CLUSTER_IP` is the service cluster IP for the - API server as described in previous subsection. - The sample below also assumes that you are using `cluster.local` as the default - DNS domain name. - - [ req ] - default_bits = 2048 - prompt = no - default_md = sha256 - req_extensions = req_ext - distinguished_name = dn - - [ dn ] - C = - ST = - L = - O = - OU = - CN = - - [ req_ext ] - subjectAltName = @alt_names - - [ alt_names ] - DNS.1 = kubernetes - DNS.2 = kubernetes.default - DNS.3 = kubernetes.default.svc - DNS.4 = kubernetes.default.svc.cluster - DNS.5 = kubernetes.default.svc.cluster.local - IP.1 = - IP.2 = - - [ v3_ext ] - authorityKeyIdentifier=keyid,issuer:always - basicConstraints=CA:FALSE - keyUsage=keyEncipherment,dataEncipherment - extendedKeyUsage=serverAuth,clientAuth - subjectAltName=@alt_names -1. Generate the certificate signing request based on the config file: - - openssl req -new -key server.key -out server.csr -config csr.conf -1. Generate the server certificate using the ca.key, ca.crt and server.csr: - - openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \ - -CAcreateserial -out server.crt -days 10000 \ - -extensions v3_ext -extfile csr.conf -1. View the certificate: - - openssl x509 -noout -text -in ./server.crt - -Finally, add the same parameters into the API server start parameters. - -### cfssl - -**cfssl** is another tool for certificate generation. - -1. Download, unpack and prepare the command line tools as shown below. - Note that you may need to adapt the sample commands based on the hardware - architecture and cfssl version you are using. - - 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.5.0/cfssljson_1.5.0_linux_amd64 -o cfssljson - chmod +x cfssljson - 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. Create a directory to hold the artifacts and initialize cfssl: - - mkdir cert - cd cert - ../cfssl print-defaults config > config.json - ../cfssl print-defaults csr > csr.json -1. Create a JSON config file for generating the CA file, for example, `ca-config.json`: - - { - "signing": { - "default": { - "expiry": "8760h" - }, - "profiles": { - "kubernetes": { - "usages": [ - "signing", - "key encipherment", - "server auth", - "client auth" - ], - "expiry": "8760h" - } - } - } - } -1. Create a JSON config file for CA certificate signing request (CSR), for example, - `ca-csr.json`. Be sure to replace the values marked with angle brackets with - real values you want to use. - - { - "CN": "kubernetes", - "key": { - "algo": "rsa", - "size": 2048 - }, - "names":[{ - "C": "", - "ST": "", - "L": "", - "O": "", - "OU": "" - }] - } -1. Generate CA key (`ca-key.pem`) and certificate (`ca.pem`): - - ../cfssl gencert -initca ca-csr.json | ../cfssljson -bare ca -1. Create a JSON config file for generating keys and certificates for the API - server, for example, `server-csr.json`. Be sure to replace the values in angle brackets with - real values you want to use. The `MASTER_CLUSTER_IP` is the service cluster - IP for the API server as described in previous subsection. - The sample below also assumes that you are using `cluster.local` as the default - DNS domain name. - - { - "CN": "kubernetes", - "hosts": [ - "127.0.0.1", - "", - "", - "kubernetes", - "kubernetes.default", - "kubernetes.default.svc", - "kubernetes.default.svc.cluster", - "kubernetes.default.svc.cluster.local" - ], - "key": { - "algo": "rsa", - "size": 2048 - }, - "names": [{ - "C": "", - "ST": "", - "L": "", - "O": "", - "OU": "" - }] - } -1. Generate the key and certificate for the API server, which are by default - saved into file `server-key.pem` and `server.pem` respectively: - - ../cfssl gencert -ca=ca.pem -ca-key=ca-key.pem \ - --config=ca-config.json -profile=kubernetes \ - server-csr.json | ../cfssljson -bare server - - -## Distributing Self-Signed CA Certificate - -A client node may refuse to recognize a self-signed CA certificate as valid. -For a non-production deployment, or for a deployment that runs behind a company -firewall, you can distribute a self-signed CA certificate to all clients and -refresh the local list for valid certificates. - -On each client, perform the following operations: - -```bash -sudo cp ca.crt /usr/local/share/ca-certificates/kubernetes.crt -sudo update-ca-certificates -``` - -``` -Updating certificates in /etc/ssl/certs... -1 added, 0 removed; done. -Running hooks in /etc/ca-certificates/update.d.... -done. -``` - -## Certificates API - -You can use the `certificates.k8s.io` API to provision -x509 certificates to use for authentication as documented -[here](/docs/tasks/tls/managing-tls-in-a-cluster). - - +To learn how to generate certificates for your cluster, see [Certificates](/docs/tasks/administer-cluster/certificates/). diff --git a/content/en/docs/reference/access-authn-authz/authentication.md b/content/en/docs/reference/access-authn-authz/authentication.md index fc76cbb2f4..674adc8aa9 100644 --- a/content/en/docs/reference/access-authn-authz/authentication.md +++ b/content/en/docs/reference/access-authn-authz/authentication.md @@ -99,7 +99,7 @@ openssl req -new -key jbeda.pem -out jbeda-csr.pem -subj "/CN=jbeda/O=app1/O=app This would create a CSR for the username "jbeda", belonging to two groups, "app1" and "app2". -See [Managing Certificates](/docs/concepts/cluster-administration/certificates/) for how to generate a client cert. +See [Managing Certificates](/docs/tasks/administer-cluster/certificates/) for how to generate a client cert. ### Static Token File diff --git a/content/en/docs/tasks/administer-cluster/certificates.md b/content/en/docs/tasks/administer-cluster/certificates.md new file mode 100644 index 0000000000..6361b20d16 --- /dev/null +++ b/content/en/docs/tasks/administer-cluster/certificates.md @@ -0,0 +1,252 @@ +--- +title: Certificates +content_type: task +weight: 20 +--- + + + + +When using client certificate authentication, you can generate certificates +manually through `easyrsa`, `openssl` or `cfssl`. + + + + + + +### easyrsa + +**easyrsa** can manually generate certificates for your cluster. + +1. Download, unpack, and initialize the patched version of easyrsa3. + + curl -LO https://storage.googleapis.com/kubernetes-release/easy-rsa/easy-rsa.tar.gz + tar xzf easy-rsa.tar.gz + cd easy-rsa-master/easyrsa3 + ./easyrsa init-pki +1. Generate a new certificate authority (CA). `--batch` sets automatic mode; + `--req-cn` specifies the Common Name (CN) for the CA's new root certificate. + + ./easyrsa --batch "--req-cn=${MASTER_IP}@`date +%s`" build-ca nopass +1. Generate server certificate and key. + The argument `--subject-alt-name` sets the possible IPs and DNS names the API server will + be accessed with. The `MASTER_CLUSTER_IP` is usually the first IP from the service CIDR + that is specified as the `--service-cluster-ip-range` argument for both the API server and + the controller manager component. The argument `--days` is used to set the number of days + after which the certificate expires. + The sample below also assumes that you are using `cluster.local` as the default + DNS domain name. + + ./easyrsa --subject-alt-name="IP:${MASTER_IP},"\ + "IP:${MASTER_CLUSTER_IP},"\ + "DNS:kubernetes,"\ + "DNS:kubernetes.default,"\ + "DNS:kubernetes.default.svc,"\ + "DNS:kubernetes.default.svc.cluster,"\ + "DNS:kubernetes.default.svc.cluster.local" \ + --days=10000 \ + build-server-full server nopass +1. Copy `pki/ca.crt`, `pki/issued/server.crt`, and `pki/private/server.key` to your directory. +1. Fill in and add the following parameters into the API server start parameters: + + --client-ca-file=/yourdirectory/ca.crt + --tls-cert-file=/yourdirectory/server.crt + --tls-private-key-file=/yourdirectory/server.key + +### openssl + +**openssl** can manually generate certificates for your cluster. + +1. Generate a ca.key with 2048bit: + + openssl genrsa -out ca.key 2048 +1. According to the ca.key generate a ca.crt (use -days to set the certificate effective time): + + openssl req -x509 -new -nodes -key ca.key -subj "/CN=${MASTER_IP}" -days 10000 -out ca.crt +1. Generate a server.key with 2048bit: + + openssl genrsa -out server.key 2048 +1. Create a config file for generating a Certificate Signing Request (CSR). + Be sure to substitute the values marked with angle brackets (e.g. ``) + with real values before saving this to a file (e.g. `csr.conf`). + Note that the value for `MASTER_CLUSTER_IP` is the service cluster IP for the + API server as described in previous subsection. + The sample below also assumes that you are using `cluster.local` as the default + DNS domain name. + + [ req ] + default_bits = 2048 + prompt = no + default_md = sha256 + req_extensions = req_ext + distinguished_name = dn + + [ dn ] + C = + ST = + L = + O = + OU = + CN = + + [ req_ext ] + subjectAltName = @alt_names + + [ alt_names ] + DNS.1 = kubernetes + DNS.2 = kubernetes.default + DNS.3 = kubernetes.default.svc + DNS.4 = kubernetes.default.svc.cluster + DNS.5 = kubernetes.default.svc.cluster.local + IP.1 = + IP.2 = + + [ v3_ext ] + authorityKeyIdentifier=keyid,issuer:always + basicConstraints=CA:FALSE + keyUsage=keyEncipherment,dataEncipherment + extendedKeyUsage=serverAuth,clientAuth + subjectAltName=@alt_names +1. Generate the certificate signing request based on the config file: + + openssl req -new -key server.key -out server.csr -config csr.conf +1. Generate the server certificate using the ca.key, ca.crt and server.csr: + + openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \ + -CAcreateserial -out server.crt -days 10000 \ + -extensions v3_ext -extfile csr.conf +1. View the certificate: + + openssl x509 -noout -text -in ./server.crt + +Finally, add the same parameters into the API server start parameters. + +### cfssl + +**cfssl** is another tool for certificate generation. + +1. Download, unpack and prepare the command line tools as shown below. + Note that you may need to adapt the sample commands based on the hardware + architecture and cfssl version you are using. + + 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.5.0/cfssljson_1.5.0_linux_amd64 -o cfssljson + chmod +x cfssljson + 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. Create a directory to hold the artifacts and initialize cfssl: + + mkdir cert + cd cert + ../cfssl print-defaults config > config.json + ../cfssl print-defaults csr > csr.json +1. Create a JSON config file for generating the CA file, for example, `ca-config.json`: + + { + "signing": { + "default": { + "expiry": "8760h" + }, + "profiles": { + "kubernetes": { + "usages": [ + "signing", + "key encipherment", + "server auth", + "client auth" + ], + "expiry": "8760h" + } + } + } + } +1. Create a JSON config file for CA certificate signing request (CSR), for example, + `ca-csr.json`. Be sure to replace the values marked with angle brackets with + real values you want to use. + + { + "CN": "kubernetes", + "key": { + "algo": "rsa", + "size": 2048 + }, + "names":[{ + "C": "", + "ST": "", + "L": "", + "O": "", + "OU": "" + }] + } +1. Generate CA key (`ca-key.pem`) and certificate (`ca.pem`): + + ../cfssl gencert -initca ca-csr.json | ../cfssljson -bare ca +1. Create a JSON config file for generating keys and certificates for the API + server, for example, `server-csr.json`. Be sure to replace the values in angle brackets with + real values you want to use. The `MASTER_CLUSTER_IP` is the service cluster + IP for the API server as described in previous subsection. + The sample below also assumes that you are using `cluster.local` as the default + DNS domain name. + + { + "CN": "kubernetes", + "hosts": [ + "127.0.0.1", + "", + "", + "kubernetes", + "kubernetes.default", + "kubernetes.default.svc", + "kubernetes.default.svc.cluster", + "kubernetes.default.svc.cluster.local" + ], + "key": { + "algo": "rsa", + "size": 2048 + }, + "names": [{ + "C": "", + "ST": "", + "L": "", + "O": "", + "OU": "" + }] + } +1. Generate the key and certificate for the API server, which are by default + saved into file `server-key.pem` and `server.pem` respectively: + + ../cfssl gencert -ca=ca.pem -ca-key=ca-key.pem \ + --config=ca-config.json -profile=kubernetes \ + server-csr.json | ../cfssljson -bare server + + +## Distributing Self-Signed CA Certificate + +A client node may refuse to recognize a self-signed CA certificate as valid. +For a non-production deployment, or for a deployment that runs behind a company +firewall, you can distribute a self-signed CA certificate to all clients and +refresh the local list for valid certificates. + +On each client, perform the following operations: + +```bash +sudo cp ca.crt /usr/local/share/ca-certificates/kubernetes.crt +sudo update-ca-certificates +``` + +``` +Updating certificates in /etc/ssl/certs... +1 added, 0 removed; done. +Running hooks in /etc/ca-certificates/update.d.... +done. +``` + +## Certificates API + +You can use the `certificates.k8s.io` API to provision +x509 certificates to use for authentication as documented +[here](/docs/tasks/tls/managing-tls-in-a-cluster). + + diff --git a/content/en/docs/tasks/tls/manual-rotation-of-ca-certificates.md b/content/en/docs/tasks/tls/manual-rotation-of-ca-certificates.md index 1720ab34a2..e56322cbec 100644 --- a/content/en/docs/tasks/tls/manual-rotation-of-ca-certificates.md +++ b/content/en/docs/tasks/tls/manual-rotation-of-ca-certificates.md @@ -105,8 +105,8 @@ Configurations with a single API server will experience unavailability while the * Make sure control plane components logs no TLS errors. {{< note >}} - To generate certificates and private keys for your cluster using the `openssl` command line tool, see [Certificates (`openssl`)](/docs/concepts/cluster-administration/certificates/#openssl). - You can also use [`cfssl`](/docs/concepts/cluster-administration/certificates/#cfssl). + To generate certificates and private keys for your cluster using the `openssl` command line tool, see [Certificates (`openssl`)](/docs/tasks/administer-cluster/certificates/#openssl). + You can also use [`cfssl`](/docs/tasks/administer-cluster/certificates/#cfssl). {{< /note >}} 1. Annotate any Daemonsets and Deployments to trigger pod replacement in a safer rolling fashion. From fd227a8405149614ca89c95d1293b9195ee2bfff Mon Sep 17 00:00:00 2001 From: Ricardo Katz Date: Thu, 25 Feb 2021 10:49:24 -0300 Subject: [PATCH 31/62] Add EndpointSlice blog post in pt language (#26708) * Add EndpointSlice blog post in pt language * Apply corrections into endpointslice blog post translation Co-authored-by: Jhon Mike Co-authored-by: Jhon Mike --- ...ng-kubernetes-networking-endpointslices.md | 47 +++++++++++++++++++ 1 file changed, 47 insertions(+) create mode 100644 content/pt/blog/_posts/2020-09-02-scaling-kubernetes-networking-endpointslices.md diff --git a/content/pt/blog/_posts/2020-09-02-scaling-kubernetes-networking-endpointslices.md b/content/pt/blog/_posts/2020-09-02-scaling-kubernetes-networking-endpointslices.md new file mode 100644 index 0000000000..7440689d5f --- /dev/null +++ b/content/pt/blog/_posts/2020-09-02-scaling-kubernetes-networking-endpointslices.md @@ -0,0 +1,47 @@ +--- +layout: blog +title: 'Escalando a rede do Kubernetes com EndpointSlices' +date: 2020-09-02 +slug: scaling-kubernetes-networking-with-endpointslices +--- + +**Autor:** Rob Scott (Google) + +EndpointSlices é um novo tipo de API que provê uma alternativa escalável e extensível à API de Endpoints. EndpointSlices mantém o rastreio dos endereços IP, portas, informações de topologia e prontidão de Pods que compõem um serviço. + +No Kubernetes 1.19 essa funcionalidade está habilitada por padrão, com o kube-proxy lendo os [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/) ao invés de Endpoints. Apesar de isso ser uma mudança praticamente transparente, resulta numa melhoria notável de escalabilidade em grandes clusters. Também permite a adição de novas funcionalidades em releases futuras do Kubernetes, como o [Roteamento baseado em topologia.](/docs/concepts/services-networking/service-topology/). + +## Limitações de escalabilidade da API de Endpoints +Na API de Endpoints, existia apenas um recurso de Endpoint por serviço (Service). Isso significa que +era necessário ser possível armazenar endereços IPs e portas para cada Pod que compunha o serviço correspondente. Isso resultava em recursos imensos de API. Para piorar, o kube-proxy rodava em cada um dos nós e observava qualquer alteração nos recursos de Endpoint. Mesmo que fosse uma simples mudança em um Endpoint, todo o objeto precisava ser enviado para cada uma das instâncias do kube-proxy. + +Outra limitação da API de Endpoints era que ela limitava o número de objetos que podiam ser associados a um _Service_. O tamanho padrão de um objeto armazenado no etcd é 1.5MB. Em alguns casos, isso poderia limitar um Endpoint a 5,000 IPs de Pod. Isso não chega a ser um problema para a maioria dos usuários, mas torna-se um problema significativo para serviços que se aproximem desse tamanho. + +Para demonstrar o quão significante se torna esse problema em grande escala, vamos usar de um simples exemplo: Imagine um _Service_ que possua 5,000 Pods, e que possa causar o Endpoint a ter 1.5Mb . Se apenas um Endpoint nessa lista sofra uma alteração, todo o objeto de Endpoint precisará ser redistribuído para cada um dos nós do cluster. Em um cluster com 3.000 nós, essa atualização causará o envio de 4.5Gb de dados (1.5Mb de Endpoints * 3,000 nós) para todo o cluster. Isso é quase que o suficiente para encher um DVD, e acontecerá para cada mudança de Endpoint. Agora imagine uma atualização gradual em um _Deployment_ que resulte nos 5,000 Pods serem substituídos - isso é mais que 22Tb (ou 5,000 DVDs) de dados transferidos. + +## Dividindo os endpoints com a API de EndpointSlice +A API de EndpointSlice foi desenhada para resolver esse problema com um modelo similar de _sharding_. Ao invés de rastrar todos os IPs dos Pods para um _Service_, com um único recurso de Endpoint, nós dividimos eles em múltiplos EndpointSlices menores. + +Usemos por exemplo um serviço com 15 pods. Nós teríamos um único recurso de Endpoints referente a todos eles. Se o EndpointSlices for configurado para armazenar 5 _endpoints_ cada, nós teríamos 3 EndpointSlices diferentes: +![EndpointSlices](/images/blog/2020-09-02-scaling-kubernetes-networking-endpointslices/endpoint-slices.png) + +Por padrão, o EndpointSlices armazena um máximo de 100 _endpoints_ cada, podendo isso ser configurado com a flag `--max-endpoints-per-slice` no kube-controller-manager. + +## EndpointSlices provê uma melhoria de escalabilidade em 10x +Essa API melhora dramaticamente a escalabilidade da rede. Agora quando um Pod é adicionado ou removido, apenas 1 pequeno EndpointSlice necessita ser atualizado. Essa diferença começa a ser notada quando centenas ou milhares de Pods compõem um único _Service_. + +Mais significativo, agora que todos os IPs de Pods para um _Service_ não precisam ser armazenados em um único recurso, nós não precisamos nos preocupar com o limite de tamanho para objetos armazendos no etcd. EndpointSlices já foram utilizados para escalar um serviço além de 100,000 endpoints de rede. + +Tudo isso é possível com uma melhoria significativa de performance feita no kube-proxy. Quando o EndpointSlices é usado em grande escala, muito menos dados serão transferidos para as atualizações de endpoints e o kube-proxy torna-se mais rápido para atualizar regras do iptables ou do ipvs. Além disso, os _Services_ podem escalar agora para pelo menos 10x mais além dos limites anteriores. + +## EndpointSlices permitem novas funcionalidades +Introduzido como uma funcionalidade alpha no Kubernetes v1.16, os EndpointSlices foram construídos para permitir algumas novas funcionalidades arrebatadoras em futuras versões do Kubernetes. Isso inclui serviços dual-stack, roteamento baseado em topologia e subconjuntos de _endpoints_. + +Serviços Dual-stack são uma nova funcionalidade que foi desenvolvida juntamente com o EndpointSlices. Eles irão utilizar simultâneamente endereços IPv4 e IPv6 para serviços, e dependem do campo addressType do Endpointslices para conter esses novos tipos de endereço por família de IP. + +O roteamento baseado por topologia irá atualizar o kube-proxy para dar preferência no roteamento de requisições para a mesma região ou zona, utilizando-se de campos de topologia armazenados em cada endpoint dentro de um EndpointSlice. Como uma melhoria futura disso, estamos explorando o potencial de subconjuntos de endpoint. Isso irá permitir o kube-proxy apenas observar um subconjunto de EndpointSlices. Por exemplo, isso pode ser combinado com o roteamento baseado em topologia e assim, o kube-proxy precisará observar apenas EndpointSlices contendo _endpoints_ na mesma zona. Isso irá permitir uma outra melhoria significativa de escalabilidade. + +## O que isso significa para a API de Endpoints? +Apesar da API de EndpointSlice prover uma alternativa nova e escalável à API de Endpoints, a API de Endpoints continuará a ser considerada uma funcionalidade estável. A mudança mais significativa para a API de Endpoints envolve começar a truncar Endpoints que podem causar problemas de escalabilidade. + +A API de Endpoints não será removida, mas muitas novas funcionalidades irão depender da nova API EndpointSlice. Para obter vantágem da funcionalidade e escalabilidade que os EndpointSlices provém, aplicações que hoje consomem a API de Endpoints devem considerar suportar EndpointSlices no futuro. From c10057bd5a2b80d0386065a9fb411b6411fda2de Mon Sep 17 00:00:00 2001 From: Tim Bannister Date: Thu, 25 Feb 2021 23:44:53 +0000 Subject: [PATCH 32/62] Add sftim as blog reviewer --- OWNERS_ALIASES | 1 + 1 file changed, 1 insertion(+) diff --git a/OWNERS_ALIASES b/OWNERS_ALIASES index 01894721d1..2c90bb82a4 100644 --- a/OWNERS_ALIASES +++ b/OWNERS_ALIASES @@ -10,6 +10,7 @@ aliases: - kbarnard10 - mrbobbytables - onlydole + - sftim sig-docs-de-owners: # Admins for German content - bene2k1 - mkorbi From de1b4d76355981e4297dde112f58f46b5ae81787 Mon Sep 17 00:00:00 2001 From: Shu Muto Date: Thu, 24 Dec 2020 14:35:01 +0900 Subject: [PATCH 33/62] Fix `Source files` in localization document. Fix `Source files` section in localization document, and remove {{< release-branch >}} variable due to `release-1.20` branch does not exist. - improve sentence - Fix latest branch for latest version - Add description if latest branch does not exist - Describe about master branch - Apply suggestions from code review - Unify `development branch` to` localization branch` - Remove description for switching upstream branch - Add description for switching upstream - Also, add description for merging to master and new release branch. Co-authored-by: Qiming Teng Co-authored-by: Tim Bannister Co-authored-by: Seokho Son --- content/en/docs/contribute/localization.md | 48 +++++++++++++--------- 1 file changed, 29 insertions(+), 19 deletions(-) diff --git a/content/en/docs/contribute/localization.md b/content/en/docs/contribute/localization.md index 2d89ee7e74..ad0b9420c5 100644 --- a/content/en/docs/contribute/localization.md +++ b/content/en/docs/contribute/localization.md @@ -61,7 +61,7 @@ Members of `@kubernetes/sig-docs-**-owners` can approve PRs that change content For each localization, The `@kubernetes/sig-docs-**-reviews` team automates review assignment for new PRs. -Members of `@kubernetes/website-maintainers` can create new development branches to coordinate translation efforts. +Members of `@kubernetes/website-maintainers` can create new localization branches to coordinate translation efforts. Members of `@kubernetes/website-milestone-maintainers` can use the `/milestone` [Prow command](https://prow.k8s.io/command-help) to assign a milestone to issues or PRs. @@ -205,14 +205,20 @@ To ensure accuracy in grammar and meaning, members of your localization team sho ### Source files -Localizations must be based on the English files from the most recent release, {{< latest-version >}}. +Localizations must be based on the English files from a specific release targeted by the localization team. +Each localization team can decide which release to target which is referred to as the _target version_ below. -To find source files for the most recent release: +To find source files for your target version: 1. Navigate to the Kubernetes website repository at https://github.com/kubernetes/website. -2. Select the `release-1.X` branch for the most recent version. +2. Select a branch for your target version from the following table: + Target version | Branch + -----|----- + Next version | [`dev-{{< skew nextMinorVersion >}}`](https://github.com/kubernetes/website/tree/dev-{{< skew nextMinorVersion >}}) + Latest version | [`master`](https://github.com/kubernetes/website/tree/master) + Previous version | `release-*.**` -The latest version is {{< latest-version >}}, so the most recent release branch is [`{{< release-branch >}}`](https://github.com/kubernetes/website/tree/{{< release-branch >}}). +The `master` branch holds content for the current release `{{< latest-version >}}`. The release team will create `{{< release-branch >}}` branch shortly before the next release: v{{< skew nextMinorVersion >}}. ### Site strings in i18n @@ -239,11 +245,11 @@ Some language teams have their own language-specific style guide and glossary. F ## Branching strategy -Because localization projects are highly collaborative efforts, we encourage teams to work in shared development branches. +Because localization projects are highly collaborative efforts, we encourage teams to work in shared localization branches. -To collaborate on a development branch: +To collaborate on a localization branch: -1. A team member of [@kubernetes/website-maintainers](https://github.com/orgs/kubernetes/teams/website-maintainers) opens a development branch from a source branch on https://github.com/kubernetes/website. +1. A team member of [@kubernetes/website-maintainers](https://github.com/orgs/kubernetes/teams/website-maintainers) opens a localization branch from a source branch on https://github.com/kubernetes/website. Your team approvers joined the `@kubernetes/website-maintainers` team when you [added your localization team](#add-your-localization-team-in-github) to the [`kubernetes/org`](https://github.com/kubernetes/org) repository. @@ -251,25 +257,31 @@ To collaborate on a development branch: `dev--.` - For example, an approver on a German localization team opens the development branch `dev-1.12-de.1` directly against the k/website repository, based on the source branch for Kubernetes v1.12. + For example, an approver on a German localization team opens the localization branch `dev-1.12-de.1` directly against the k/website repository, based on the source branch for Kubernetes v1.12. -2. Individual contributors open feature branches based on the development branch. +2. Individual contributors open feature branches based on the localization branch. For example, a German contributor opens a pull request with changes to `kubernetes:dev-1.12-de.1` from `username:local-branch-name`. -3. Approvers review and merge feature branches into the development branch. +3. Approvers review and merge feature branches into the localization branch. -4. Periodically, an approver merges the development branch to its source branch by opening and approving a new pull request. Be sure to squash the commits before approving the pull request. +4. Periodically, an approver merges the localization branch to its source branch by opening and approving a new pull request. Be sure to squash the commits before approving the pull request. -Repeat steps 1-4 as needed until the localization is complete. For example, subsequent German development branches would be: `dev-1.12-de.2`, `dev-1.12-de.3`, etc. +Repeat steps 1-4 as needed until the localization is complete. For example, subsequent German localization branches would be: `dev-1.12-de.2`, `dev-1.12-de.3`, etc. -Teams must merge localized content into the same release branch from which the content was sourced. For example, a development branch sourced from {{< release-branch >}} must be based on {{< release-branch >}}. +Teams must merge localized content into the same branch from which the content was sourced. -An approver must maintain a development branch by keeping it current with its source branch and resolving merge conflicts. The longer a development branch stays open, the more maintenance it typically requires. Consider periodically merging development branches and opening new ones, rather than maintaining one extremely long-running development branch. +For example: +- a localization branch sourced from `master` must be merged into `master`. +- a localization branch sourced from `release-1.19` must be merged into `release-1.19`. -At the beginning of every team milestone, it's helpful to open an issue comparing upstream changes between the previous development branch and the current development branch. There are two scripts for comparing upstream changes. [`upstream_changes.py`](https://github.com/kubernetes/website/tree/master/scripts#upstream_changespy) is useful for checking the changes made to a specific file. And [`diff_l10n_branches.py`](https://github.com/kubernetes/website/tree/master/scripts#diff_l10n_branchespy) is useful for creating a list of outdated files for a specific localization branch. +{{< note >}} +If your localization branch was created from `master` branch but it is not merged into `master` before new release branch `{{< release-branch >}}` created, merge it into both `master` and new release branch `{{< release-branch >}}`. To merge your localization branch into new release branch `{{< release-branch >}}`, you need to switch upstream branch of your localization branch to `{{< release-branch >}}`. +{{< /note >}} - While only approvers can open a new development branch and merge pull requests, anyone can open a pull request for a new development branch. No special permissions are required. +At the beginning of every team milestone, it's helpful to open an issue comparing upstream changes between the previous localization branch and the current localization branch. There are two scripts for comparing upstream changes. [`upstream_changes.py`](https://github.com/kubernetes/website/tree/master/scripts#upstream_changespy) is useful for checking the changes made to a specific file. And [`diff_l10n_branches.py`](https://github.com/kubernetes/website/tree/master/scripts#diff_l10n_branchespy) is useful for creating a list of outdated files for a specific localization branch. + +While only approvers can open a new localization branch and merge pull requests, anyone can open a pull request for a new localization branch. No special permissions are required. For more information about working from forks or directly from the repository, see ["fork and clone the repo"](#fork-and-clone-the-repo). @@ -290,5 +302,3 @@ Once a localization meets requirements for workflow and minimum output, SIG docs - Enable language selection on the website - Publicize the localization's availability through [Cloud Native Computing Foundation](https://www.cncf.io/about/) (CNCF) channels, including the [Kubernetes blog](https://kubernetes.io/blog/). - - From b9acba6987eba634c51243296fe38f7a8e25203e Mon Sep 17 00:00:00 2001 From: wwgfhf <51694849+wwgfhf@users.noreply.github.com> Date: Fri, 26 Feb 2021 17:27:21 +0800 Subject: [PATCH 34/62] Update job.md --- content/zh/docs/concepts/workloads/controllers/job.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/zh/docs/concepts/workloads/controllers/job.md b/content/zh/docs/concepts/workloads/controllers/job.md index e79bf11dc1..06853f27b7 100644 --- a/content/zh/docs/concepts/workloads/controllers/job.md +++ b/content/zh/docs/concepts/workloads/controllers/job.md @@ -349,7 +349,7 @@ caused by previous runs. `.spec.template.spec.restartPolicy = "Never"`。 当 Pod 失败时，Job 控制器会启动一个新的 Pod。 这意味着，你的应用需要处理在一个新 Pod 中被重启的情况。 -尤其是应用需要处理之前运行所触碰或产生的临时文件、锁、不完整的输出等问题。 +尤其是应用需要处理之前运行所产生的临时文件、锁、不完整的输出等问题。 支持以下两种方式配置调度器的过滤和打分行为： - -1. [调度策略](/zh/docs/reference/scheduling/policies) 允许你配置过滤的 _谓词(Predicates)_ +1. [调度策略](/zh/docs/reference/scheduling/policies) 允许你配置过滤的 _断言(Predicates)_ 和打分的 _优先级(Priorities)_ 。 2. [调度配置](/zh/docs/reference/scheduling/config/#profiles) 允许你配置实现不同调度阶段的插件， 包括：`QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit` 等等。 你也可以配置 kube-scheduler 运行不同的配置文件。 ## {{% heading "whatsnext" %}} - {{< feature-state for_k8s_version="v1.19" state="beta" >}} - 你可以通过编写配置文件，并将其路径传给 `kube-scheduler` 的命令行参数，定制 `kube-scheduler` 的行为。 @@ -82,14 +82,14 @@ extension points: --> 1. `QueueSort`：这些插件对调度队列中的悬决的 Pod 排序。 一次只能启用一个队列排序插件。 - 2. `PreFilter`：这些插件用于在过滤之前预处理或检查 Pod 或集群的信息。 它们可以将 Pod 标记为不可调度。 - @@ -127,13 +127,13 @@ extension points: least one bind plugin is required. --> 9. `Bind`：这个插件将 Pod 与节点绑定。绑定插件是按顺序调用的，只要有一个插件完成了绑定，其余插件都会跳过。绑定插件至少需要一个。 - 10. `PostBind`：这是一个信息扩展点，在 Pod 绑定了节点之后调用。 - @@ -154,18 +154,18 @@ profiles: weight: 1 ``` - 你可以在 `disabled` 数组中使用 `*` 禁用该扩展点的所有默认插件。 如果需要，这个字段也可以用来对插件重新顺序。 - + ### 调度插件 {#scheduling-plugin} - @@ -190,7 +190,7 @@ extension points: - `SelectorSpread`：对于属于 {{< glossary_tooltip text="Services" term_id="service" >}}、 {{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}} 和 {{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}} 的 Pod，偏好跨多个节点部署。 - + 实现的扩展点：`PreScore`，`Score`。 - `ImageLocality`：选择已经存在 Pod 运行所需容器镜像的节点。 - + 实现的扩展点：`Score`。 - `TaintToleration`：实现了[污点和容忍](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)。 - + 实现的扩展点：`Filter`，`Prescore`，`Score`。 - `NodeName`：检查 Pod 指定的节点名称与当前节点是否匹配。 - + 实现的扩展点：`Filter`。 - `NodePorts`：检查 Pod 请求的端口在节点上是否可用。 - + 实现的扩展点：`PreFilter`，`Filter`。 -- `NodePreferAvoidPods`：基于节点的 {{< glossary_tooltip text="注解" term_id="annotation" >}} +- `NodePreferAvoidPods`：基于节点的 {{< glossary_tooltip text="注解" term_id="annotation" >}} `scheduler.alpha.kubernetes.io/preferAvoidPods` 打分。 - + 实现的扩展点：`Score`。 - `NodeAffinity`：实现了[节点选择器](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector) 和[节点亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity)。 - + 实现的扩展点：`Filter`，`Score`. - `PodTopologySpread`：实现了 [Pod 拓扑分布](/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints/)。 - + 实现的扩展点：`PreFilter`，`Filter`，`PreScore`，`Score`。 - `NodeUnschedulable`：过滤 `.spec.unschedulable` 值为 true 的节点。 - + 实现的扩展点：`Filter`。 - `NodeResourcesFit`：检查节点是否拥有 Pod 请求的所有资源。 - + 实现的扩展点：`PreFilter`，`Filter`。 - `NodeResourcesBalancedAllocation`：调度 Pod 时，选择资源使用更为均衡的节点。 - + 实现的扩展点：`Score`。 - `NodeResourcesLeastAllocated`：选择资源分配较少的节点。 - + 实现的扩展点：`Score`。 - `VolumeBinding`：检查节点是否有请求的卷，或是否可以绑定请求的卷。 - + 实现的扩展点: `PreFilter`，`Filter`，`Reserve`，`PreBind`。 - - `VolumeRestrictions`：检查挂载到节点上的卷是否满足卷提供程序的限制。 - + 实现的扩展点：`Filter`。 - `VolumeZone`：检查请求的卷是否在任何区域都满足。 - + 实现的扩展点：`Filter`。 - - `NodeVolumeLimits`：检查该节点是否满足 CSI 卷限制。 - + 实现的扩展点：`Filter`。 - `EBSLimits`：检查节点是否满足 AWS EBS 卷限制。 - + 实现的扩展点：`Filter`。 - `GCEPDLimits`：检查该节点是否满足 GCP-PD 卷限制。 - + 实现的扩展点：`Filter`。 - `AzureDiskLimits`：检查该节点是否满足 Azure 卷限制。 - + 实现的扩展点：`Filter`。 - `InterPodAffinity`：实现 [Pod 间亲和性与反亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)。 - + 实现的扩展点：`PreFilter`，`Filter`，`PreScore`，`Score`。 - `PrioritySort`：提供默认的基于优先级的排序。 - + 实现的扩展点：`QueueSort`。 - `DefaultBinder`：提供默认的绑定机制。 - + 实现的扩展点：`Bind`。 - `DefaultPreemption`：提供默认的抢占机制。 - + 实现的扩展点：`PostFilter`。 - `NodeResourcesMostAllocated`：选择已分配资源多的节点。 - + 实现的扩展点：`Score`。 - `RequestedToCapacityRatio`：根据已分配资源的某函数设置选择节点。 - + 实现的扩展点：`Score`。 - `NodeResourceLimits`：选择满足 Pod 资源限制的节点。 - + 实现的扩展点：`PreScore`，`Score`。 - `CinderVolume`：检查该节点是否满足 OpenStack Cinder 卷限制。 - + 实现的扩展点：`Filter`。 -- `NodeLabel`：根据配置的 {{< glossary_tooltip text="标签" term_id="label" >}} +- `NodeLabel`：根据配置的 {{< glossary_tooltip text="标签" term_id="label" >}} 过滤节点和/或给节点打分。 - + 实现的扩展点：`Filter`，`Score`。 @@ -462,14 +462,14 @@ profiles: Pods that want to be scheduled according to a specific profile can include the corresponding scheduler name in its `.spec.schedulerName`. --> -希望根据特定配置文件调度的 Pod，可以在 `.spec.schedulerName` 字段指定相应的调度器名称。 +对于那些希望根据特定配置文件来进行调度的 Pod，可以在 `.spec.schedulerName` 字段指定相应的调度器名称。 -默认情况下，将创建一个名为 `default-scheduler` 的配置文件。 +默认情况下，将创建一个调度器名为 `default-scheduler` 的配置文件。 这个配置文件包括上面描述的所有默认插件。 声明多个配置文件时，每个配置文件中调度器名称必须唯一。 @@ -478,8 +478,8 @@ If a Pod doesn't specify a scheduler name, kube-apiserver will set it to `default-scheduler`. Therefore, a profile with this scheduler name should exist to get those pods scheduled. --> -如果 Pod 未指定调度器名称，kube-apiserver 将会把它设置为 `default-scheduler`。 -因此，应该存在一个名为 `default-scheduler` 的配置文件来调度这些 Pod。 +如果 Pod 未指定调度器名称，kube-apiserver 将会把调度器名设置为 `default-scheduler`。 +因此，应该存在一个调度器名为 `default-scheduler` 的配置文件来调度这些 Pod。 {{< note >}} Pod 的调度事件把 `.spec.schedulerName` 字段值作为 ReportingController。 -领导者选择事件使用列表中第一个配置文件的调度器名称。 +领导者选举事件使用列表中第一个配置文件的调度器名称。 {{< /note >}} {{< note >}} @@ -498,7 +498,7 @@ the same configuration parameters (if applicable). This is because the scheduler only has one pending pods queue. --> 所有配置文件必须在 QueueSort 扩展点使用相同的插件，并具有相同的配置参数（如果适用）。 -这是因为调度器只有一个的队列保存悬决的 Pod。 +这是因为调度器只有一个保存 pending 状态 Pod 的队列。 {{< /note >}} @@ -509,4 +509,4 @@ only has one pending pods queue. * Learn about [scheduling](/docs/concepts/scheduling-eviction/kube-scheduler/) --> * 阅读 [kube-scheduler 参考](/zh/docs/reference/command-line-tools-reference/kube-scheduler/) -* 了解[调度](/zh/docs/concepts/scheduling-eviction/kube-scheduler/) \ No newline at end of file +* 了解[调度](/zh/docs/concepts/scheduling-eviction/kube-scheduler/) From 35fd22c03a74d4524a7362955a46769cd252e1ec Mon Sep 17 00:00:00 2001 From: GoodGameZoo Date: Sat, 27 Feb 2021 01:04:19 -0800 Subject: [PATCH 39/62] Update page scheduling eviction --- .../concepts/scheduling-eviction/taint-and-toleration.md | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/content/zh/docs/concepts/scheduling-eviction/taint-and-toleration.md b/content/zh/docs/concepts/scheduling-eviction/taint-and-toleration.md index e20c15890f..1e6a079186 100644 --- a/content/zh/docs/concepts/scheduling-eviction/taint-and-toleration.md +++ b/content/zh/docs/concepts/scheduling-eviction/taint-and-toleration.md @@ -8,7 +8,7 @@ weight: 40 节点亲和性（详见[这里](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)） @@ -140,7 +140,7 @@ This is a "preference" or "soft" version of `NoSchedule` - the system will *try* pod that does not tolerate the taint on the node, but it is not required. The third kind of `effect` is `NoExecute`, described later. --> -上述例子使用到的 `effect` 的一个值 `NoSchedule`，您也可以使用另外一个值 `PreferNoSchedule`。 +上述例子中 `effect` 使用的值为 `NoSchedule`，您也可以使用另外一个值 `PreferNoSchedule`。 这是“优化”或“软”版本的 `NoSchedule` —— 系统会 *尽量* 避免将 Pod 调度到存在其不能容忍污点的节点上， 但这不是强制的。`effect` 的值还可以设置为 `NoExecute`，下文会详细描述这个值。 @@ -438,7 +438,7 @@ by the user already has a toleration for `node.kubernetes.io/unreachable`. {{< note >}} Kubernetes 会自动给 Pod 添加一个 key 为 `node.kubernetes.io/not-ready` 的容忍度 -并配置 `tolerationSeconds=300`，除非用户提供的 Pod 配置中已经已存在了 key 为 +并配置 `tolerationSeconds=300`，除非用户提供的 Pod 配置中已经已存在了 key 为 `node.kubernetes.io/not-ready` 的容忍度。 同样，Kubernetes 会给 Pod 添加一个 key 为 `node.kubernetes.io/unreachable` 的容忍度 @@ -517,5 +517,3 @@ arbitrary tolerations to DaemonSets. --> * 阅读[资源耗尽的处理](/zh/docs/tasks/administer-cluster/out-of-resource/)，以及如何配置其行为 * 阅读 [Pod 优先级](/zh/docs/concepts/configuration/pod-priority-preemption/) - - From 9d644accea9d41665306aaae0dd40369433dacac Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Sat, 27 Feb 2021 22:24:45 +0900 Subject: [PATCH 40/62] chore: fix an invalid location.hash --- content/en/docs/tutorials/stateless-application/guestbook.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/tutorials/stateless-application/guestbook.md b/content/en/docs/tutorials/stateless-application/guestbook.md index 27cc649edf..0a84483716 100644 --- a/content/en/docs/tutorials/stateless-application/guestbook.md +++ b/content/en/docs/tutorials/stateless-application/guestbook.md @@ -148,7 +148,7 @@ kubectl apply -f ./content/en/examples/application/guestbook/frontend-deployment ### Creating the Frontend Service -The `mongo` Services you applied is only accessible within the Kubernetes cluster because the default type for a Service is [ClusterIP](/docs/concepts/services-networking/service/#publishing-services---service-types). `ClusterIP` provides a single IP address for the set of Pods the Service is pointing to. This IP address is accessible only within the cluster. +The `mongo` Services you applied is only accessible within the Kubernetes cluster because the default type for a Service is [ClusterIP](/docs/concepts/services-networking/service/#publishing-services-service-types). `ClusterIP` provides a single IP address for the set of Pods the Service is pointing to. This IP address is accessible only within the cluster. If you want guests to be able to access your guestbook, you must configure the frontend Service to be externally visible, so a client can request the Service from outside the Kubernetes cluster. However a Kubernetes user you can use `kubectl port-forward` to access the service even though it uses a `ClusterIP`. From e864d7f3cafcf5aa7e6e8da752ee3e479c3ae056 Mon Sep 17 00:00:00 2001 From: Jens Heinrich <59469646+JensHeinrich@users.noreply.github.com> Date: Sat, 27 Feb 2021 15:37:33 +0100 Subject: [PATCH 41/62] Fix sentence Add missing verb --- content/en/docs/reference/access-authn-authz/authentication.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/reference/access-authn-authz/authentication.md b/content/en/docs/reference/access-authn-authz/authentication.md index fc76cbb2f4..4a9aee91d9 100644 --- a/content/en/docs/reference/access-authn-authz/authentication.md +++ b/content/en/docs/reference/access-authn-authz/authentication.md @@ -328,7 +328,7 @@ Since all of the data needed to validate who you are is in the `id_token`, Kuber 1. Kubernetes has no "web interface" to trigger the authentication process. There is no browser or interface to collect credentials which is why you need to authenticate to your identity provider first. 2. The `id_token` can't be revoked, it's like a certificate so it should be short-lived (only a few minutes) so it can be very annoying to have to get a new token every few minutes. -3. To authenticate to the Kubernetes dashboard, you must the `kubectl proxy` command or a reverse proxy that injects the `id_token`. +3. To authenticate to the Kubernetes dashboard, you must use the `kubectl proxy` command or a reverse proxy that injects the `id_token`. #### Configuring the API Server From e78c03800ac5588b7610ead3268b0dbd4ba11ce4 Mon Sep 17 00:00:00 2001 From: Jailton Lopes Date: Sat, 27 Feb 2021 13:44:20 -0300 Subject: [PATCH 42/62] Update Tutorial Deploy App to use the "control plane" terminology. * Update page content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html * Update image content/en/docs/tutorials/kubernetes-basics/public/images/module_02_first_app.svg Signed-off-by: Jailton Lopes --- .../deploy-app/deploy-intro.html | 2 +- .../public/images/module_02_first_app.svg | 783 +++++++++++++----- 2 files changed, 558 insertions(+), 227 deletions(-) diff --git a/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html b/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html index 2ee67382fd..15b6d00a6c 100644 --- a/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html +++ b/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html @@ -31,7 +31,7 @@ weight: 10 Once you have a running Kubernetes cluster, you can deploy your containerized applications on top of it. To do so, you create a Kubernetes Deployment configuration. The Deployment instructs Kubernetes how to create and update instances of your application. Once you've created a Deployment, the Kubernetes - master schedules the application instances included in that Deployment to run on individual Nodes in the + control plane schedules the application instances included in that Deployment to run on individual Nodes in the cluster.

diff --git a/content/en/docs/tutorials/kubernetes-basics/public/images/module_02_first_app.svg b/content/en/docs/tutorials/kubernetes-basics/public/images/module_02_first_app.svg index e0ae8fa504..cf8c922916 100644 --- a/content/en/docs/tutorials/kubernetes-basics/public/images/module_02_first_app.svg +++ b/content/en/docs/tutorials/kubernetes-basics/public/images/module_02_first_app.svg @@ -1,5 +1,32 @@ - -