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 diff --git a/content/en/docs/concepts/extend-kubernetes/operator.md b/content/en/docs/concepts/extend-kubernetes/operator.md index 0e9d227a53..64b9ed3eb8 100644 --- a/content/en/docs/concepts/extend-kubernetes/operator.md +++ b/content/en/docs/concepts/extend-kubernetes/operator.md @@ -124,6 +124,6 @@ that can act as a [client for the Kubernetes API](/docs/reference/using-api/clie you implement yourself * using the [Operator Framework](https://operatorframework.io) * [Publish](https://operatorhub.io/) your operator for other people to use -* Read [CoreOS' original article](https://coreos.com/blog/introducing-operators.html) that introduced the Operator pattern +* Read [CoreOS' original article](https://web.archive.org/web/20170129131616/https://coreos.com/blog/introducing-operators.html) that introduced the Operator pattern (this is an archived version of the original article). * Read an [article](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps) from Google Cloud about best practices for building Operators 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` : diff --git a/content/en/docs/concepts/policy/resource-quotas.md b/content/en/docs/concepts/policy/resource-quotas.md index d5c94d99cf..bc5eca8754 100644 --- a/content/en/docs/concepts/policy/resource-quotas.md +++ b/content/en/docs/concepts/policy/resource-quotas.md @@ -58,7 +58,7 @@ Neither contention nor changes to quota will affect already created resources. ## Enabling Resource Quota Resource Quota support is enabled by default for many Kubernetes distributions. It is -enabled when the API server `--enable-admission-plugins=` flag has `ResourceQuota` as +enabled when the {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} `--enable-admission-plugins=` flag has `ResourceQuota` as one of its arguments. A resource quota is enforced in a particular namespace when there is a 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 diff --git a/content/en/docs/contribute/localization.md b/content/en/docs/contribute/localization.md index 48c48b6ed3..2d89ee7e74 100644 --- a/content/en/docs/contribute/localization.md +++ b/content/en/docs/contribute/localization.md @@ -267,7 +267,7 @@ Teams must merge localized content into the same release branch from which the c 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. -At the beginning of every team milestone, it's helpful to open an issue [comparing upstream changes](https://github.com/kubernetes/website/blob/master/scripts/upstream_changes.py) between the previous development branch and the current development branch. +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. 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. diff --git a/content/en/docs/contribute/style/style-guide.md b/content/en/docs/contribute/style/style-guide.md index 2f0c39168c..5931422e95 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 @@ -592,6 +587,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" %}} 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. diff --git a/content/en/docs/tasks/administer-cluster/configure-upgrade-etcd.md b/content/en/docs/tasks/administer-cluster/configure-upgrade-etcd.md index 72f069d6ac..25cd61a710 100644 --- a/content/en/docs/tasks/administer-cluster/configure-upgrade-etcd.md +++ b/content/en/docs/tasks/administer-cluster/configure-upgrade-etcd.md @@ -10,35 +10,40 @@ content_type: task {{< glossary_definition term_id="etcd" length="all" prepend="etcd is a ">}} - - - ## {{% heading "prerequisites" %}} - {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - - ## Prerequisites * Run etcd as a cluster of odd members. -* etcd is a leader-based distributed system. Ensure that the leader periodically send heartbeats on time to all followers to keep the cluster stable. +* etcd is a leader-based distributed system. Ensure that the leader + periodically send heartbeats on time to all followers to keep the cluster + stable. * Ensure that no resource starvation occurs. - Performance and stability of the cluster is sensitive to network and disk IO. Any resource starvation can lead to heartbeat timeout, causing instability of the cluster. An unstable etcd indicates that no leader is elected. Under such circumstances, a cluster cannot make any changes to its current state, which implies no new pods can be scheduled. + Performance and stability of the cluster is sensitive to network and disk + I/O. Any resource starvation can lead to heartbeat timeout, causing instability + of the cluster. An unstable etcd indicates that no leader is elected. Under + such circumstances, a cluster cannot make any changes to its current state, + which implies no new pods can be scheduled. -* Keeping stable etcd clusters is critical to the stability of Kubernetes clusters. Therefore, run etcd clusters on dedicated machines or isolated environments for [guaranteed resource requirements](https://github.com/coreos/etcd/blob/master/Documentation/op-guide/hardware.md#hardware-recommendations). +* Keeping etcd clusters stable is critical to the stability of Kubernetes + clusters. Therefore, run etcd clusters on dedicated machines or isolated + environments for [guaranteed resource requirements](https://etcd.io/docs/current/op-guide/hardware/). * The minimum recommended version of etcd to run in production is `3.2.10+`. ## Resource requirements -Operating etcd with limited resources is suitable only for testing purposes. For deploying in production, advanced hardware configuration is required. Before deploying etcd in production, see [resource requirement reference documentation](https://github.com/coreos/etcd/blob/master/Documentation/op-guide/hardware.md#example-hardware-configurations). +Operating etcd with limited resources is suitable only for testing purposes. +For deploying in production, advanced hardware configuration is required. +Before deploying etcd in production, see +[resource requirement reference](https://etcd.io/docs/current/op-guide/hardware/#example-hardware-configurations). ## Starting etcd clusters @@ -50,33 +55,43 @@ Use a single-node etcd cluster only for testing purpose. 1. Run the following: - ```sh - ./etcd --listen-client-urls=http://$PRIVATE_IP:2379 --advertise-client-urls=http://$PRIVATE_IP:2379 - ``` + ```sh + etcd --listen-client-urls=http://$PRIVATE_IP:2379 \ + --advertise-client-urls=http://$PRIVATE_IP:2379 + ``` -2. Start Kubernetes API server with the flag `--etcd-servers=$PRIVATE_IP:2379`. +2. Start the Kubernetes API server with the flag + `--etcd-servers=$PRIVATE_IP:2379`. - Replace `PRIVATE_IP` with your etcd client IP. + Make sure `PRIVATE_IP` is set to your etcd client IP. ### Multi-node etcd cluster -For durability and high availability, run etcd as a multi-node cluster in production and back it up periodically. A five-member cluster is recommended in production. For more information, see [FAQ Documentation](https://github.com/coreos/etcd/blob/master/Documentation/faq.md#what-is-failure-tolerance). +For durability and high availability, run etcd as a multi-node cluster in +production and back it up periodically. A five-member cluster is recommended +in production. For more information, see +[FAQ documentation](https://etcd.io/docs/current/faq/#what-is-failure-tolerance). -Configure an etcd cluster either by static member information or by dynamic discovery. For more information on clustering, see [etcd Clustering Documentation](https://github.com/coreos/etcd/blob/master/Documentation/op-guide/clustering.md). +Configure an etcd cluster either by static member information or by dynamic +discovery. For more information on clustering, see +[etcd clustering documentation](https://etcd.io/docs/current/op-guide/clustering/). -For an example, consider a five-member etcd cluster running with the following client URLs: `http://$IP1:2379`, `http://$IP2:2379`, `http://$IP3:2379`, `http://$IP4:2379`, and `http://$IP5:2379`. To start a Kubernetes API server: +For an example, consider a five-member etcd cluster running with the following +client URLs: `http://$IP1:2379`, `http://$IP2:2379`, `http://$IP3:2379`, +`http://$IP4:2379`, and `http://$IP5:2379`. To start a Kubernetes API server: 1. Run the following: - ```sh - ./etcd --listen-client-urls=http://$IP1:2379, http://$IP2:2379, http://$IP3:2379, http://$IP4:2379, http://$IP5:2379 --advertise-client-urls=http://$IP1:2379, http://$IP2:2379, http://$IP3:2379, http://$IP4:2379, http://$IP5:2379 - ``` + ```shell + etcd --listen-client-urls=http://$IP1:2379,http://$IP2:2379,http://$IP3:2379,http://$IP4:2379,http://$IP5:2379 --advertise-client-urls=http://$IP1:2379,http://$IP2:2379,http://$IP3:2379,http://$IP4:2379,http://$IP5:2379 + ``` -2. Start Kubernetes API servers with the flag `--etcd-servers=$IP1:2379, $IP2:2379, $IP3:2379, $IP4:2379, $IP5:2379`. +2. Start the Kubernetes API servers with the flag + `--etcd-servers=$IP1:2379,$IP2:2379,$IP3:2379,$IP4:2379,$IP5:2379`. - Replace `IP` with your client IP addresses. + Make sure the `IP` variables are set to your client IP addresses. -### Multi-node etcd cluster with load balancer +### Multi-node etcd cluster with load balancer To run a load balancing etcd cluster: @@ -87,92 +102,160 @@ To run a load balancing etcd cluster: ## Securing etcd clusters -Access to etcd is equivalent to root permission in the cluster so ideally only the API server should have access to it. Considering the sensitivity of the data, it is recommended to grant permission to only those nodes that require access to etcd clusters. +Access to etcd is equivalent to root permission in the cluster so ideally only +the API server should have access to it. Considering the sensitivity of the +data, it is recommended to grant permission to only those nodes that require +access to etcd clusters. -To secure etcd, either set up firewall rules or use the security features provided by etcd. etcd security features depend on x509 Public Key Infrastructure (PKI). To begin, establish secure communication channels by generating a key and certificate pair. For example, use key pairs `peer.key` and `peer.cert` for securing communication between etcd members, and `client.key` and `client.cert` for securing communication between etcd and its clients. See the [example scripts](https://github.com/coreos/etcd/tree/master/hack/tls-setup) provided by the etcd project to generate key pairs and CA files for client authentication. +To secure etcd, either set up firewall rules or use the security features +provided by etcd. etcd security features depend on x509 Public Key +Infrastructure (PKI). To begin, establish secure communication channels by +generating a key and certificate pair. For example, use key pairs `peer.key` +and `peer.cert` for securing communication between etcd members, and +`client.key` and `client.cert` for securing communication between etcd and its +clients. See the [example scripts](https://github.com/coreos/etcd/tree/master/hack/tls-setup) +provided by the etcd project to generate key pairs and CA files for client +authentication. ### Securing communication -To configure etcd with secure peer communication, specify flags `--peer-key-file=peer.key` and `--peer-cert-file=peer.cert`, and use https as URL schema. +To configure etcd with secure peer communication, specify flags +`--peer-key-file=peer.key` and `--peer-cert-file=peer.cert`, and use HTTPS as +the URL schema. -Similarly, to configure etcd with secure client communication, specify flags `--key-file=k8sclient.key` and `--cert-file=k8sclient.cert`, and use https as URL schema. +Similarly, to configure etcd with secure client communication, specify flags +`--key-file=k8sclient.key` and `--cert-file=k8sclient.cert`, and use HTTPS as +the URL schema. ### Limiting access of etcd clusters -After configuring secure communication, restrict the access of etcd cluster to only the Kubernetes API server. Use TLS authentication to do so. +After configuring secure communication, restrict the access of etcd cluster to +only the Kubernetes API servers. Use TLS authentication to do so. -For example, consider key pairs `k8sclient.key` and `k8sclient.cert` that are trusted by the CA `etcd.ca`. When etcd is configured with `--client-cert-auth` along with TLS, it verifies the certificates from clients by using system CAs or the CA passed in by `--trusted-ca-file` flag. Specifying flags `--client-cert-auth=true` and `--trusted-ca-file=etcd.ca` will restrict the access to clients with the certificate `k8sclient.cert`. +For example, consider key pairs `k8sclient.key` and `k8sclient.cert` that are +trusted by the CA `etcd.ca`. When etcd is configured with `--client-cert-auth` +along with TLS, it verifies the certificates from clients by using system CAs +or the CA passed in by `--trusted-ca-file` flag. Specifying flags +`--client-cert-auth=true` and `--trusted-ca-file=etcd.ca` will restrict the +access to clients with the certificate `k8sclient.cert`. -Once etcd is configured correctly, only clients with valid certificates can access it. To give Kubernetes API server the access, configure it with the flags `--etcd-certfile=k8sclient.cert`,`--etcd-keyfile=k8sclient.key` and `--etcd-cafile=ca.cert`. +Once etcd is configured correctly, only clients with valid certificates can +access it. To give Kubernetes API servers the access, configure them with the +flags `--etcd-certfile=k8sclient.cert`,`--etcd-keyfile=k8sclient.key` and +`--etcd-cafile=ca.cert`. {{< note >}} -etcd authentication is not currently supported by Kubernetes. For more information, see the related issue [Support Basic Auth for Etcd v2](https://github.com/kubernetes/kubernetes/issues/23398). +etcd authentication is not currently supported by Kubernetes. For more +information, see the related issue +[Support Basic Auth for Etcd v2](https://github.com/kubernetes/kubernetes/issues/23398). {{< /note >}} ## Replacing a failed etcd member -etcd cluster achieves high availability by tolerating minor member failures. However, to improve the overall health of the cluster, replace failed members immediately. When multiple members fail, replace them one by one. Replacing a failed member involves two steps: removing the failed member and adding a new member. +etcd cluster achieves high availability by tolerating minor member failures. +However, to improve the overall health of the cluster, replace failed members +immediately. When multiple members fail, replace them one by one. Replacing a +failed member involves two steps: removing the failed member and adding a new +member. -Though etcd keeps unique member IDs internally, it is recommended to use a unique name for each member to avoid human errors. For example, consider a three-member etcd cluster. Let the URLs be, member1=http://10.0.0.1, member2=http://10.0.0.2, and member3=http://10.0.0.3. When member1 fails, replace it with member4=http://10.0.0.4. +Though etcd keeps unique member IDs internally, it is recommended to use a +unique name for each member to avoid human errors. For example, consider a +three-member etcd cluster. Let the URLs be, `member1=http://10.0.0.1`, +`member2=http://10.0.0.2`, and `member3=http://10.0.0.3`. When `member1` fails, +replace it with `member4=http://10.0.0.4`. -1. Get the member ID of the failed member1: +1. Get the member ID of the failed `member1`: - `etcdctl --endpoints=http://10.0.0.2,http://10.0.0.3 member list` + ```shell + etcdctl --endpoints=http://10.0.0.2,http://10.0.0.3 member list + ``` - The following message is displayed: + The following message is displayed: - 8211f1d0f64f3269, started, member1, http://10.0.0.1:2380, http://10.0.0.1:2379 - 91bc3c398fb3c146, started, member2, http://10.0.0.2:2380, http://10.0.0.2:2379 - fd422379fda50e48, started, member3, http://10.0.0.3:2380, http://10.0.0.3:2379 + ```console + 8211f1d0f64f3269, started, member1, http://10.0.0.1:2380, http://10.0.0.1:2379 + 91bc3c398fb3c146, started, member2, http://10.0.0.2:2380, http://10.0.0.2:2379 + fd422379fda50e48, started, member3, http://10.0.0.3:2380, http://10.0.0.3:2379 + ``` 2. Remove the failed member: - `etcdctl member remove 8211f1d0f64f3269` + ```shell + etcdctl member remove 8211f1d0f64f3269 + ``` - The following message is displayed: + The following message is displayed: - Removed member 8211f1d0f64f3269 from cluster + ```console + Removed member 8211f1d0f64f3269 from cluster + ``` 3. Add the new member: - `./etcdctl member add member4 --peer-urls=http://10.0.0.4:2380` + ```shell + etcdctl member add member4 --peer-urls=http://10.0.0.4:2380 + ``` - The following message is displayed: + The following message is displayed: - Member 2be1eb8f84b7f63e added to cluster ef37ad9dc622a7c4 + ```console + Member 2be1eb8f84b7f63e added to cluster ef37ad9dc622a7c4 + ``` 4. Start the newly added member on a machine with the IP `10.0.0.4`: - export ETCD_NAME="member4" - export ETCD_INITIAL_CLUSTER="member2=http://10.0.0.2:2380,member3=http://10.0.0.3:2380,member4=http://10.0.0.4:2380" - export ETCD_INITIAL_CLUSTER_STATE=existing - etcd [flags] + ```shell + export ETCD_NAME="member4" + export ETCD_INITIAL_CLUSTER="member2=http://10.0.0.2:2380,member3=http://10.0.0.3:2380,member4=http://10.0.0.4:2380" + export ETCD_INITIAL_CLUSTER_STATE=existing + etcd [flags] + ``` 5. Do either of the following: - 1. Update its `--etcd-servers` flag to make Kubernetes aware of the configuration changes, then restart the Kubernetes API server. - 2. Update the load balancer configuration if a load balancer is used in the deployment. + 1. Update the `--etcd-servers` flag for the Kubernetes API servers to make + Kubernetes aware of the configuration changes, then restart the + Kubernetes API servers. + 2. Update the load balancer configuration if a load balancer is used in the + deployment. -For more information on cluster reconfiguration, see [etcd Reconfiguration Documentation](https://github.com/coreos/etcd/blob/master/Documentation/op-guide/runtime-configuration.md#remove-a-member). +For more information on cluster reconfiguration, see +[etcd reconfiguration documentation](https://etcd.io/docs/current/op-guide/runtime-configuration/#remove-a-member). ## Backing up an etcd cluster -All Kubernetes objects are stored on etcd. Periodically backing up the etcd cluster data is important to recover Kubernetes clusters under disaster scenarios, such as losing all master nodes. The snapshot file contains all the Kubernetes states and critical information. In order to keep the sensitive Kubernetes data safe, encrypt the snapshot files. +All Kubernetes objects are stored on etcd. Periodically backing up the etcd +cluster data is important to recover Kubernetes clusters under disaster +scenarios, such as losing all control plane nodes. The snapshot file contains +all the Kubernetes states and critical information. In order to keep the +sensitive Kubernetes data safe, encrypt the snapshot files. -Backing up an etcd cluster can be accomplished in two ways: etcd built-in snapshot and volume snapshot. +Backing up an etcd cluster can be accomplished in two ways: etcd built-in +snapshot and volume snapshot. ### Built-in snapshot -etcd supports built-in snapshot. A snapshot may either be taken from a live member with the `etcdctl snapshot save` command or by copying the `member/snap/db` file from an etcd [data directory](https://github.com/coreos/etcd/blob/master/Documentation/op-guide/configuration.md#--data-dir) that is not currently used by an etcd process. Taking the snapshot will normally not affect the performance of the member. +etcd supports built-in snapshot. A snapshot may either be taken from a live +member with the `etcdctl snapshot save` command or by copying the +`member/snap/db` file from an etcd +[data directory](https://etcd.io/docs/current/op-guide/configuration/#--data-dir) +that is not currently used by an etcd process. Taking the snapshot will +not affect the performance of the member. -Below is an example for taking a snapshot of the keyspace served by `$ENDPOINT` to the file `snapshotdb`: +Below is an example for taking a snapshot of the keyspace served by +`$ENDPOINT` to the file `snapshotdb`: -```sh +```shell ETCDCTL_API=3 etcdctl --endpoints $ENDPOINT snapshot save snapshotdb -# exit 0 +``` -# verify the snapshot +Verify the snapshot: + +```shell ETCDCTL_API=3 etcdctl --write-out=table snapshot status snapshotdb +``` + +```console +----------+----------+------------+------------+ | HASH | REVISION | TOTAL KEYS | TOTAL SIZE | +----------+----------+------------+------------+ @@ -182,74 +265,63 @@ ETCDCTL_API=3 etcdctl --write-out=table snapshot status snapshotdb ### Volume snapshot -If etcd is running on a storage volume that supports backup, such as Amazon Elastic Block Store, back up etcd data by taking a snapshot of the storage volume. +If etcd is running on a storage volume that supports backup, such as Amazon +Elastic Block Store, back up etcd data by taking a snapshot of the storage +volume. ## Scaling up etcd clusters -Scaling up etcd clusters increases availability by trading off performance. Scaling does not increase cluster performance nor capability. A general rule is not to scale up or down etcd clusters. Do not configure any auto scaling groups for etcd clusters. It is highly recommended to always run a static five-member etcd cluster for production Kubernetes clusters at any officially supported scale. +Scaling up etcd clusters increases availability by trading off performance. +Scaling does not increase cluster performance nor capability. A general rule +is not to scale up or down etcd clusters. Do not configure any auto scaling +groups for etcd clusters. It is highly recommended to always run a static +five-member etcd cluster for production Kubernetes clusters at any officially +supported scale. -A reasonable scaling is to upgrade a three-member cluster to a five-member one, when more reliability is desired. See [etcd Reconfiguration Documentation](https://github.com/coreos/etcd/blob/master/Documentation/op-guide/runtime-configuration.md#remove-a-member) for information on how to add members into an existing cluster. +A reasonable scaling is to upgrade a three-member cluster to a five-member +one, when more reliability is desired. See +[etcd reconfiguration documentation](https://etcd.io/docs/current/op-guide/runtime-configuration/#remove-a-member) +for information on how to add members into an existing cluster. ## Restoring an etcd cluster -etcd supports restoring from snapshots that are taken from an etcd process of the [major.minor](http://semver.org/) version. Restoring a version from a different patch version of etcd also is supported. A restore operation is employed to recover the data of a failed cluster. +etcd supports restoring from snapshots that are taken from an etcd process of +the [major.minor](http://semver.org/) version. Restoring a version from a +different patch version of etcd also is supported. A restore operation is +employed to recover the data of a failed cluster. -Before starting the restore operation, a snapshot file must be present. It can either be a snapshot file from a previous backup operation, or from a remaining [data directory](https://github.com/coreos/etcd/blob/master/Documentation/op-guide/configuration.md#--data-dir). For more information and examples on restoring a cluster from a snapshot file, see [etcd disaster recovery documentation](https://github.com/coreos/etcd/blob/master/Documentation/op-guide/recovery.md#restoring-a-cluster). +Before starting the restore operation, a snapshot file must be present. It can +either be a snapshot file from a previous backup operation, or from a remaining +[data directory]( https://etcd.io/docs/current/op-guide/configuration/#--data-dir). +For more information and examples on restoring a cluster from a snapshot file, see +[etcd disaster recovery documentation](https://etcd.io/docs/current/op-guide/recovery/#restoring-a-cluster). -If the access URLs of the restored cluster is changed from the previous cluster, the Kubernetes API server must be reconfigured accordingly. In this case, restart Kubernetes API server with the flag `--etcd-servers=$NEW_ETCD_CLUSTER` instead of the flag `--etcd-servers=$OLD_ETCD_CLUSTER`. Replace `$NEW_ETCD_CLUSTER` and `$OLD_ETCD_CLUSTER` with the respective IP addresses. If a load balancer is used in front of an etcd cluster, you might need to update the load balancer instead. +If the access URLs of the restored cluster is changed from the previous +cluster, the Kubernetes API server must be reconfigured accordingly. In this +case, restart Kubernetes API servers with the flag +`--etcd-servers=$NEW_ETCD_CLUSTER` instead of the flag +`--etcd-servers=$OLD_ETCD_CLUSTER`. Replace `$NEW_ETCD_CLUSTER` and +`$OLD_ETCD_CLUSTER` with the respective IP addresses. If a load balancer is +used in front of an etcd cluster, you might need to update the load balancer +instead. -If the majority of etcd members have permanently failed, the etcd cluster is considered failed. In this scenario, Kubernetes cannot make any changes to its current state. Although the scheduled pods might continue to run, no new pods can be scheduled. In such cases, recover the etcd cluster and potentially reconfigure Kubernetes API server to fix the issue. +If the majority of etcd members have permanently failed, the etcd cluster is +considered failed. In this scenario, Kubernetes cannot make any changes to its +current state. Although the scheduled pods might continue to run, no new pods +can be scheduled. In such cases, recover the etcd cluster and potentially +reconfigure Kubernetes API servers to fix the issue. {{< note >}} -If any API servers are running in your cluster, you should not attempt to restore instances of etcd. -Instead, follow these steps to restore etcd: +If any API servers are running in your cluster, you should not attempt to +restore instances of etcd. Instead, follow these steps to restore etcd: -- stop *all* kube-apiserver instances +- stop *all* API server instances - restore state in all etcd instances -- restart all kube-apiserver instances +- restart all API server instances -We also recommend restarting any components (e.g. kube-scheduler, kube-controller-manager, kubelet) to ensure that they don't -rely on some stale data. Note that in practice, the restore takes a bit of time. -During the restoration, critical components will lose leader lock and restart themselves. +We also recommend restarting any components (e.g. `kube-scheduler`, +`kube-controller-manager`, `kubelet`) to ensure that they don't rely on some +stale data. Note that in practice, the restore takes a bit of time. During the +restoration, critical components will lose leader lock and restart themselves. {{< /note >}} -## Upgrading and rolling back etcd clusters - -As of Kubernetes v1.13.0, etcd2 is no longer supported as a storage backend for -new or existing Kubernetes clusters. The timeline for Kubernetes support for -etcd2 and etcd3 is as follows: - -- Kubernetes v1.0: etcd2 only -- Kubernetes v1.5.1: etcd3 support added, new clusters still default to etcd2 -- Kubernetes v1.6.0: new clusters created with `kube-up.sh` default to etcd3, - and `kube-apiserver` defaults to etcd3 -- Kubernetes v1.9.0: deprecation of etcd2 storage backend announced -- Kubernetes v1.13.0: etcd2 storage backend removed, `kube-apiserver` will - refuse to start with `--storage-backend=etcd2`, with the - message `etcd2 is no longer a supported storage backend` - -Before upgrading a v1.12.x kube-apiserver using `--storage-backend=etcd2` to -v1.13.x, etcd v2 data must be migrated to the v3 storage backend and -kube-apiserver invocations must be changed to use `--storage-backend=etcd3`. - -The process for migrating from etcd2 to etcd3 is highly dependent on how the -etcd cluster was deployed and configured, as well as how the Kubernetes -cluster was deployed and configured. We recommend that you consult your cluster -provider's documentation to see if there is a predefined solution. - -If your cluster was created via `kube-up.sh` and is still using etcd2 as its -storage backend, please consult the [Kubernetes v1.12 etcd cluster upgrade docs](https://v1-12.docs.kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/#upgrading-and-rolling-back-etcd-clusters) - -## Known issue: etcd client balancer with secure endpoints - -The etcd v3 client, released in etcd v3.3.13 or earlier, has a [critical bug](https://github.com/kubernetes/kubernetes/issues/72102) which affects the kube-apiserver and HA deployments. The etcd client balancer failover does not properly work against secure endpoints. As a result, etcd servers may fail or disconnect briefly from the kube-apiserver. This affects kube-apiserver HA deployments. - -The fix was made in [etcd v3.4](https://github.com/etcd-io/etcd/pull/10911) (and backported to v3.3.14 or later): the new client now creates its own credential bundle to correctly set authority target in dial function. - -Because the fix requires gRPC dependency upgrade (to v1.23.0), downstream Kubernetes [did not backport etcd upgrades](https://github.com/kubernetes/kubernetes/issues/72102#issuecomment-526645978). Which means the [etcd fix in kube-apiserver](https://github.com/etcd-io/etcd/pull/10911/commits/db61ee106ca9363ba3f188ecf27d1a8843da33ab) is only available from Kubernetes 1.16. - -To urgently fix this bug for Kubernetes 1.15 or earlier, build a custom kube-apiserver. You can make local changes to [`vendor/google.golang.org/grpc/credentials/credentials.go`](https://github.com/kubernetes/kubernetes/blob/7b85be021cd2943167cd3d6b7020f44735d9d90b/vendor/google.golang.org/grpc/credentials/credentials.go#L135) with [etcd@db61ee106](https://github.com/etcd-io/etcd/pull/10911/commits/db61ee106ca9363ba3f188ecf27d1a8843da33ab). - -See ["kube-apiserver 1.13.x refuses to work when first etcd-server is not available"](https://github.com/kubernetes/kubernetes/issues/72102). - - 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!

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 @@ - - - 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. diff --git a/content/en/docs/tutorials/stateless-application/guestbook.md b/content/en/docs/tutorials/stateless-application/guestbook.md index b60afcf5f8..27cc649edf 100644 --- a/content/en/docs/tutorials/stateless-application/guestbook.md +++ b/content/en/docs/tutorials/stateless-application/guestbook.md @@ -134,7 +134,7 @@ kubectl apply -f ./content/en/examples/application/guestbook/frontend-deployment 1. Query the list of Pods to verify that the three frontend replicas are running: ```shell - kubectl get pods -l app=guestbook -l tier=frontend + kubectl get pods -l app.kubernetes.io/name=guestbook -l app.kubernetes.io/component=frontend ``` The response should be similar to this: diff --git a/content/es/docs/contribute/_index.md b/content/es/docs/contribute/_index.md index 46157bab39..24851d8db0 100644 --- a/content/es/docs/contribute/_index.md +++ b/content/es/docs/contribute/_index.md @@ -83,3 +83,7 @@ para proporcionar un punto de partida. - Proponer mejoras al sitio web de Kubernetes y otras herramientas +## {{% heading "whatsnext" %}} + +También puedes leer la +[guía de localización para español](/es/docs/contribute/localization_es/). diff --git a/content/es/docs/contribute/localization_es.md b/content/es/docs/contribute/localization_es.md new file mode 100644 index 0000000000..22602d3ed9 --- /dev/null +++ b/content/es/docs/contribute/localization_es.md @@ -0,0 +1,43 @@ +--- +title: Contribuir a la documentación de Kubernetes en español +content_type: concept +--- + + + +¡Bienvenido(a)! + +En esta página encontrarás información sobre convenciones utilizadas en la documentación en castellano y un glosario de términos con sus traducciones. + + + +## Glosario de terminología {#terminologia} + +| English | Español | Género | Commentarios | +| ----------------- | ---------------------- | ------------ | ------------------------ | +| availability zone | zona de disponibilidad | femenino | | +| bearer token | bearer token | masculino | | +| built-in | incorporados | masculino | | +| conditions | condiciones | masculino | para node conditions | +| container | contenedor | masculino | | +| controller | controlador | masculino | | +| deploy | desplegar | | | +| Deployment | Deployment | masculino | objeto Kubernetes | +| Endpoints | Endpoints | masculino | objeto Kubernetes | +| file | archivo | masculino | | +| frontend | frontend | masculino | | +| healthy | operativo | | | +| high availability | alta disponibilidad | | | +| hook | hook | masculino | | +| instance | instancia | femenino | | +| Lease | Lease | masculino | objeto Kubernetes | +| Pod | Pod | masculino | objeto Kubernetes | +| ratio | ritmo | | | +| runtime | motor de ejecución | masculino | Container Runtime | +| scheduler | planificador | masculino | | +| Secret | Secret | masculino | objeto Kubernetes | +| secret | secreto | masculino | información confidencial | +| shell | terminal | femenino | | +| stateless | stateless | | | +| taint | contaminación | | | +| worker node | nodo de trabajo | masculino | | 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をスケジュールする際にのみ考慮されます。 diff --git a/content/ja/docs/reference/tools.md b/content/ja/docs/reference/tools.md new file mode 100644 index 0000000000..0fedb1cf9d --- /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/)の変換 diff --git a/content/ko/docs/reference/glossary/cloud-controller-manager.md b/content/ko/docs/reference/glossary/cloud-controller-manager.md index 20121a9371..ebfa3d926c 100644 --- a/content/ko/docs/reference/glossary/cloud-controller-manager.md +++ b/content/ko/docs/reference/glossary/cloud-controller-manager.md @@ -5,7 +5,7 @@ date: 2018-04-12 full_link: /ko/docs/concepts/architecture/cloud-controller/ short_description: > 쿠버네티스를 타사 클라우드 공급자와 통합하는 컨트롤 플레인 컴포넌트. -aka: +aka: tags: - core-object - architecture @@ -13,7 +13,7 @@ tags: --- 클라우드별 컨트롤 로직을 포함하는 쿠버네티스 {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}} 컴포넌트이다. -클라우트 컨트롤러 매니저를 통해 클러스터를 클라우드 공급자의 API에 연결하고, +클라우드 컨트롤러 매니저를 통해 클러스터를 클라우드 공급자의 API에 연결하고, 해당 클라우드 플랫폼과 상호 작용하는 컴포넌트와 클러스터와 상호 작용하는 컴포넌트를 분리할 수 있다. diff --git a/content/pl/docs/concepts/overview/kubernetes-api.md b/content/pl/docs/concepts/overview/kubernetes-api.md index cd376dab1d..731b22cacc 100644 --- a/content/pl/docs/concepts/overview/kubernetes-api.md +++ b/content/pl/docs/concepts/overview/kubernetes-api.md @@ -4,7 +4,7 @@ content_type: concept weight: 30 description: > API Kubernetesa służy do odpytywania i zmiany stanu obiektów Kubernetesa. - Sercem warstwy sterowania Kubernetesa jest serwer API i udostępniane przez niego HTTP API. Przez ten serwer odbywa się komunikacja pomiędzy użytkownikami, różnymi częściami składowymi klastra oraz komponentami zewnętrznymi. + Sercem warstwy sterowania Kubernetesa jest serwer API i udostępniane po HTTP API. Przez ten serwer odbywa się komunikacja pomiędzy użytkownikami, różnymi częściami składowymi klastra oraz komponentami zewnętrznymi. card: name: concepts weight: 30 @@ -14,13 +14,16 @@ card: Sercem {{< glossary_tooltip text="warstwy sterowania" term_id="control-plane" >}} Kubernetes jest {{< glossary_tooltip text="serwer API" term_id="kube-apiserver" >}}. Serwer udostępnia -API poprzez HTTP, umożliwiając wzajemną komunikację pomiędzy użytkownikami, częściami składowymi klastra i komponentami zewnętrznymi. +API poprzez HTTP, umożliwiając wzajemną komunikację pomiędzy użytkownikami, częściami składowymi klastra +i komponentami zewnętrznymi. -API Kubernetes pozwala na sprawdzanie i zmianę stanu obiektów (przykładowo: pody, _Namespaces_, _ConfigMaps_, _Events_). +API Kubernetesa pozwala na sprawdzanie i zmianę stanu obiektów +(przykładowo: pody, _Namespaces_, _ConfigMaps_, _Events_). Większość operacji może zostać wykonana poprzez interfejs linii komend (CLI) [kubectl](/docs/reference/kubectl/overview/) lub inne -programy, takie jak [kubeadm](/docs/reference/setup-tools/kubeadm/), które używają +programy, takie jak +[kubeadm](/docs/reference/setup-tools/kubeadm/), które używają API. Możesz też korzystać z API bezpośrednio przez wywołania typu REST. Jeśli piszesz aplikację używającą API Kubernetesa, @@ -66,54 +69,77 @@ Aby wybrać format odpowiedzi, użyj nagłówków żądania zgodnie z tabelą: -W Kubernetesie zaimplementowany jest alternatywny format serializacji na potrzeby API oparty o Protobuf, -który jest przede wszystkim przeznaczony na potrzeby wewnętrznej komunikacji w klastrze -i opisany w [design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md). -Pliki IDL dla każdego ze schematów można znaleźć w pakietach Go, które definiują obiekty API. +W Kubernetesie zaimplementowany jest alternatywny format serializacji na potrzeby API oparty o +Protobuf, który jest przede wszystkim przeznaczony na potrzeby wewnętrznej komunikacji w klastrze. +Więcej szczegółów znajduje się w dokumencie [Kubernetes Protobuf serialization](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md). +oraz w plikach *Interface Definition Language* (IDL) dla każdego ze schematów +zamieszczonych w pakietach Go, które definiują obiekty API. -## Zmiany API +## Przechowywanie stanu + +Kubernetes przechowuje serializowany stan swoich obiektów w +{{< glossary_tooltip term_id="etcd" >}}. + +## Grupy i wersje API + +Aby ułatwić usuwanie poszczególnych pól lub restrukturyzację reprezentacji zasobów, Kubernetes obsługuje +równocześnie wiele wersji API, każde poprzez osobną ścieżkę API, +na przykład: `/api/v1` lub `/apis/rbac.authorization.k8s.io/v1alpha1`. + +Rozdział wersji wprowadzony jest na poziomie całego API, a nie na poziomach poszczególnych zasobów lub pól, +aby być pewnym, że API odzwierciedla w sposób przejrzysty i spójny zasoby systemowe +i ich zachowania oraz pozwala na kontrolowany dostęp do tych API, które są w fazie wycofywania +lub fazie eksperymentalnej. + +Aby ułatwić rozbudowę API Kubernetes, wprowadziliśmy +[*grupy API*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md), które mogą +być [włączane i wyłączane](/docs/reference/using-api/#enabling-or-disabling). + +Zasoby API są rozróżniane poprzez przynależność do grupy API, typ zasobu, przestrzeń nazw (_namespace_, +o ile ma zastosowanie) oraz nazwę. Serwer API może przeprowadzać konwersję między +różnymi wersjami API w sposób niewidoczny dla użytkownika: wszystkie te różne wersje +reprezentują w rzeczywistości ten sam zasób. Serwer API może udostępniać te same dane +poprzez kilka różnych wersji API. + +Załóżmy przykładowo, że istnieją dwie wersje `v1` i `v1beta1` tego samego zasobu. +Obiekt utworzony przez wersję `v1beta1` może być odczytany, +zaktualizowany i skasowany zarówno przez wersję +`v1beta1`, jak i `v1`. + +## Trwałość API Z naszego doświadczenia wynika, że każdy system, który odniósł sukces, musi się nieustająco rozwijać w miarę zmieniających się potrzeb. Dlatego Kubernetes został tak zaprojektowany, aby API mogło się zmieniać i rozrastać. Projekt Kubernetes dąży do tego, aby nie wprowadzać zmian niezgodnych z istniejącymi aplikacjami klienckimi i utrzymywać zgodność przez wystarczająco długi czas, aby inne projekty zdążyły się dostosować do zmian. -W ogólności, nowe zasoby i pola definiujące zasoby API są dodawane stosunkowo często. Usuwanie zasobów lub pól -jest regulowane przez [API deprecation policy](/docs/reference/using-api/deprecation-policy/). -Definicja zmiany zgodnej (kompatybilnej) oraz metody wprowadzania zmian w API opisano w szczegółach -w [API change document](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md). +W ogólności, nowe zasoby i pola definiujące zasoby API są dodawane stosunkowo często. +Usuwanie zasobów lub pól jest regulowane przez +[API deprecation policy](/docs/reference/using-api/deprecation-policy/). -## Grupy i wersje API +Po osiągnięciu przez API statusu ogólnej dostępności (_general availability_ - GA), +oznaczanej zazwyczaj jako wersja API `v1`, bardzo zależy nam na utrzymaniu jej zgodności w kolejnych wydaniach. +Kubernetes utrzymuje także zgodność dla wersji _beta_ API tam, gdzie jest to możliwe: +jeśli zdecydowałeś się używać API w wersji beta, możesz z niego korzystać także później, +kiedy dana funkcjonalność osiągnie status stabilnej. -Aby ułatwić usuwanie poszczególnych pól lub restrukturyzację reprezentacji zasobów, Kubernetes obsługuje -równocześnie wiele wersji API, każde poprzez osobną ścieżkę API, na przykład: `/api/v1` lub -`/apis/rbac.authorization.k8s.io/v1alpha1`. - -Rozdział wersji wprowadzony jest na poziomie całego API, a nie na poziomach poszczególnych zasobów lub pól, aby być pewnym, -że API odzwierciedla w sposób przejrzysty i spójny zasoby systemowe i ich zachowania i pozwala -na kontrolowany dostęp do tych API, które są w fazie wycofywania lub fazie eksperymentalnej. - -Aby ułatwić rozbudowę API Kubernetes, wprowadziliśmy [*grupy API*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md), -które mogą być [włączane i wyłączane](/docs/reference/using-api/#enabling-or-disabling). - -Zasoby API są rozróżniane poprzez przynależność do grupy API, typ zasobu, przestrzeń nazw (_namespace_, -o ile ma zastosowanie) oraz nazwę. Serwer API może obsługiwać -te same dane poprzez różne wersje API i przeprowadzać konwersję między -różnymi wersjami API w sposób niewidoczny dla użytkownika. Wszystkie te różne wersje -reprezentują w rzeczywistości ten sam zasób. Załóżmy przykładowo, że istnieją dwie -wersje `v1` i `v1beta1` tego samego zasobu. Obiekt utworzony przez -wersję `v1beta1` może być odczytany, zaktualizowany i skasowany zarówno przez wersję -`v1beta1`, jak i `v1`. +{{< note >}} +Mimo, że Kubernetes stara się także zachować zgodność dla API w wersji _alpha_, zdarzają się przypadki, +kiedy nie jest to możliwe. Jeśli korzystasz z API w wersji alfa, przed aktualizacją klastra do nowej wersji +zalecamy sprawdzenie w informacjach o wydaniu, czy nie nastąpiła jakaś zmiana w tej części API. +{{< /note >}} Zajrzyj do [API versions reference](/docs/reference/using-api/#api-versioning) -po szczegółowe informacje, jak definiuje się poziomy wersji API. +po szczegółowe definicje różnych poziomów wersji API. + + ## Rozbudowa API -API Kubernetesa można rozbudowywać (rozszerzać) na dwa sposoby: +API Kubernetesa można rozszerzać na dwa sposoby: -1. [Definicje zasobów własnych](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) - pozwalają deklaratywnie określać, jak serwer API powinien dostarczać wybrane zasoby API. +1. [Definicje zasobów własnych (_custom resources_)](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) + pozwalają deklaratywnie określać, jak serwer API powinien dostarczać wybrane przez Ciebie zasoby API. 1. Można także rozszerzać API Kubernetesa implementując [warstwę agregacji](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/). @@ -121,6 +147,9 @@ API Kubernetesa można rozbudowywać (rozszerzać) na dwa sposoby: - Naucz się, jak rozbudowywać API Kubernetesa poprzez dodawanie własnych [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/). -- [Controlling API Access](/docs/reference/access-authn-authz/controlling-access/) opisuje +- [Controlling Access To The Kubernetes API](/docs/concepts/security/controlling-access/) opisuje sposoby, jakimi klaster zarządza dostępem do API. -- Punkty dostępowe API _(endpoints)_, typy zasobów i przykłady zamieszczono w [API Reference](/docs/reference/kubernetes-api/). +- Punkty dostępowe API _(endpoints)_, typy zasobów i przykłady zamieszczono w + [API Reference](/docs/reference/kubernetes-api/). +- Aby dowiedzieć się, jaki rodzaj zmian można określić jako zgodne i jak zmieniać API, zajrzyj do + [API changes](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme). diff --git a/content/pl/docs/concepts/overview/what-is-kubernetes.md b/content/pl/docs/concepts/overview/what-is-kubernetes.md index db8ea18b70..d28c841553 100644 --- a/content/pl/docs/concepts/overview/what-is-kubernetes.md +++ b/content/pl/docs/concepts/overview/what-is-kubernetes.md @@ -42,7 +42,7 @@ Kontenery działają w sposób zbliżony do maszyn wirtualnych, ale mają mniejs Kontenery zyskały popularność ze względu na swoje zalety, takie jak: * Szybkość i elastyczność w tworzeniu i instalacji aplikacji: obraz kontenera buduje się łatwiej niż obraz VM. -* Ułatwienie ciągłego rozwoju, integracji oraz wdrażania aplikacji (*Continuous development, integration, and deployment*): obrazy kontenerów mogą być budowane w sposób wiarygodny i częsty. Wycofanie zmian jest łatwe i szybkie (ponieważ obrazy są niezmienne). +* Ułatwienie ciągłego rozwoju, integracji oraz wdrażania aplikacji (*Continuous development, integration, and deployment*): obrazy kontenerów mogą być budowane w sposób wiarygodny i częsty. Wycofywanie zmian jest skuteczne i szybkie (ponieważ obrazy są niezmienne). * Rozdzielenie zadań *Dev* i *Ops*: obrazy kontenerów powstają w fazie *build/release*, oddzielając w ten sposób aplikacje od infrastruktury. * Obserwowalność obejmuje nie tylko informacje i metryki z poziomu systemu operacyjnego, ale także poprawność działania samej aplikacji i inne sygnały. * Spójność środowiska na etapach rozwoju oprogramowania, testowania i działania w trybie produkcyjnym: działa w ten sam sposób na laptopie i w chmurze. diff --git a/content/pl/docs/reference/_index.md b/content/pl/docs/reference/_index.md index bfc120218c..d598908162 100644 --- a/content/pl/docs/reference/_index.md +++ b/content/pl/docs/reference/_index.md @@ -8,13 +8,14 @@ content_type: concept -Tutaj znajdziesz dokumentację źródłową Kubernetes. +Tutaj znajdziesz dokumentację źródłową Kubernetesa. ## Dokumentacja API -* [Dokumentacja źródłowa API Kubernetesa {{< latest-version >}}](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/) +* [Kubernetes API Reference](/docs/reference/kubernetes-api/) +* [One-page API Reference for Kubernetes {{< param "version" >}}](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) * [Using The Kubernetes API](/docs/reference/using-api/) - ogólne informacje na temat API Kubernetesa. ## Biblioteki klientów API diff --git a/content/pl/docs/reference/tools.md b/content/pl/docs/reference/tools.md index 5d60370ee3..2ec66964ed 100644 --- a/content/pl/docs/reference/tools.md +++ b/content/pl/docs/reference/tools.md @@ -18,7 +18,7 @@ Kubernetes zawiera różne wbudowane narzędzia służące do pracy z systemem: ## Minikube -[`minikube`](https://minikube.sigs.k8s.io/docs/) to narzędzie do łatwego uruchamiania lokalnego klastra Kubernetes na twojej stacji roboczej na potrzeby rozwoju oprogramowania lub prowadzenia testów. +[`minikube`](https://minikube.sigs.k8s.io/docs/) to narzędzie do uruchamiania jednowęzłowego klastra Kubernetes na twojej stacji roboczej na potrzeby rozwoju oprogramowania lub prowadzenia testów. ## Pulpit *(Dashboard)* diff --git a/content/pl/docs/tutorials/_index.md b/content/pl/docs/tutorials/_index.md index e9f8ed32d8..c55fd9c3ff 100644 --- a/content/pl/docs/tutorials/_index.md +++ b/content/pl/docs/tutorials/_index.md @@ -32,7 +32,7 @@ Przed zapoznaniem się z samouczkami warto stworzyć zakładkę do * [Exposing an External IP Address to Access an Application in a Cluster](/docs/tutorials/stateless-application/expose-external-ip-address/) -* [Example: Deploying PHP Guestbook application with Redis](/docs/tutorials/stateless-application/guestbook/) +* [Example: Deploying PHP Guestbook application with MongoDB](/docs/tutorials/stateless-application/guestbook/) ## Aplikacje stanowe *(Stateful Applications)* diff --git a/content/pl/docs/tutorials/kubernetes-basics/_index.html b/content/pl/docs/tutorials/kubernetes-basics/_index.html index 39d8bf63c9..e27a3ad6bf 100644 --- a/content/pl/docs/tutorials/kubernetes-basics/_index.html +++ b/content/pl/docs/tutorials/kubernetes-basics/_index.html @@ -41,7 +41,7 @@ card:

Co Kubernetes może dla Ciebie zrobić?

-

Użytkownicy oczekują od współczesnych serwisów internetowych dostępności non-stop, a deweloperzy chcą móc instalować nowe wersje swoich serwisów kilka razy dziennie. Używając kontenerów można przygotowywać oprogramowanie w taki sposób, aby mogło być instalowane i aktualizowane łatwo i nie powodując żadnych przestojów. Kubernetes pomaga uruchamiać te aplikacje w kontenerach tam, gdzie chcesz i kiedy chcesz i znajdować niezbędne zasoby i narzędzia wymagane do ich pracy. Kubernetes może działać w środowiskach produkcyjnych, jest otwartym oprogramowaniem zaprojektowanym z wykorzystaniem nagromadzonego przez Google doświadczenia w zarządzaniu kontenerami, w połączeniu z najcenniejszymi ideami społeczności.

+

Użytkownicy oczekują od współczesnych serwisów internetowych dostępności non-stop, a deweloperzy chcą móc instalować nowe wersje swoich serwisów kilka razy dziennie. Używając kontenerów można przygotowywać oprogramowanie w taki sposób, aby mogło być instalowane i aktualizowane nie powodując żadnych przestojów. Kubernetes pomaga uruchamiać te aplikacje w kontenerach tam, gdzie chcesz i kiedy chcesz i znajdować niezbędne zasoby i narzędzia wymagane do ich pracy. Kubernetes może działać w środowiskach produkcyjnych, jest otwartym oprogramowaniem zaprojektowanym z wykorzystaniem nagromadzonego przez Google doświadczenia w zarządzaniu kontenerami, w połączeniu z najcenniejszymi ideami społeczności.

diff --git a/content/pl/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html b/content/pl/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html index 5b90420c5a..c879aa82b9 100644 --- a/content/pl/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html +++ b/content/pl/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html @@ -91,9 +91,7 @@ weight: 10

- Na potrzeby pierwszej instalacji użyjesz aplikacji na Node.js zapakowaną w kontener Docker-a. (Jeśli jeszcze nie próbowałeś stworzyć - aplikacji na Node.js i uruchomić za pomocą kontenerów, możesz spróbować teraz, kierując się instrukcjami samouczka - Hello Minikube). + Na potrzeby pierwszej instalacji użyjesz aplikacji hello-node zapakowaną w kontener Docker-a, która korzysta z NGINXa i powtarza wszystkie wysłane do niej zapytania. (Jeśli jeszcze nie próbowałeś stworzyć aplikacji hello-node i uruchomić za pomocą kontenerów, możesz spróbować teraz, kierując się instrukcjami samouczka Hello Minikube).

Teraz, kiedy wiesz, czym są Deploymenty, przejdźmy do samouczka online, żeby zainstalować naszą pierwszą aplikację!

diff --git a/content/pl/docs/tutorials/kubernetes-basics/expose/expose-intro.html b/content/pl/docs/tutorials/kubernetes-basics/expose/expose-intro.html index 4ad9a7be76..f9f9134e4a 100644 --- a/content/pl/docs/tutorials/kubernetes-basics/expose/expose-intro.html +++ b/content/pl/docs/tutorials/kubernetes-basics/expose/expose-intro.html @@ -64,12 +64,6 @@ weight: 10
-
-
-

-
-
-

Serwis kieruje przychodzący ruch do grupy Podów. Serwisy są obiektami abstrakcyjnymi, dzięki którym pody mogą się psuć i być zastępowane przez Kubernetes nowymi bez ujemnego wpływu na działanie twoich aplikacji. Detekcją nowych podów i kierowaniem ruchu pomiędzy zależnymi podami (takimi, jak składowe front-end i back-end w aplikacji) zajmują się Serwisy Kubernetes.

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. 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) + + + + diff --git a/content/zh/docs/concepts/architecture/nodes.md b/content/zh/docs/concepts/architecture/nodes.md index 7c6000268f..908b8ddde6 100644 --- a/content/zh/docs/concepts/architecture/nodes.md +++ b/content/zh/docs/concepts/architecture/nodes.md @@ -17,10 +17,9 @@ weight: 10 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 对象。 @@ -457,8 +456,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` 是一种轻量级的资源，可在集群规模扩大时提高节点心跳机制的性能。 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 访问令牌 {{< note >}} - 如果你在使用本地 Minikube 环境，你可以从浏览器中访问 hellow-world.info。 + 如果你在使用本地 Minikube 环境，你可以从浏览器中访问 hello-world.info。 {{< /note >}} {{< note >}} 如果你在本地运行 Minikube 环境，你可以使用浏览器来访问 - hellow-world.info 和 hello-world.info/v2。 + hello-world.info 和 hello-world.info/v2。 {{< /note >}} ## {{% heading "whatsnext" %}} diff --git a/content/zh/docs/tasks/configure-pod-container/translate-compose-kubernetes.md b/content/zh/docs/tasks/configure-pod-container/translate-compose-kubernetes.md index 6250e452a8..23577048b2 100644 --- a/content/zh/docs/tasks/configure-pod-container/translate-compose-kubernetes.md +++ b/content/zh/docs/tasks/configure-pod-container/translate-compose-kubernetes.md @@ -40,26 +40,25 @@ We have multiple ways to install Kompose. Our preferred method is downloading th 我们有很多种方式安装 Kompose。首选方式是从最新的 GitHub 发布页面下载二进制文件。 - -## GitHub 发布版本 - -Kompose 通过 GitHub 发布版本，发布周期为三星期。 +Kompose 通过 GitHub 发布，发布周期为三星期。 你可以在 [GitHub 发布页面](https://github.com/kubernetes/kompose/releases) 上看到所有当前版本。 ```shell # Linux -curl -L https://github.com/kubernetes/kompose/releases/download/v1.16.0/kompose-linux-amd64 -o kompose +curl -L https://github.com/kubernetes/kompose/releases/download/v1.22.0/kompose-linux-amd64 -o kompose # macOS -curl -L https://github.com/kubernetes/kompose/releases/download/v1.16.0/kompose-darwin-amd64 -o kompose +curl -L https://github.com/kubernetes/kompose/releases/download/v1.22.0/kompose-darwin-amd64 -o kompose # Windows -curl -L https://github.com/kubernetes/kompose/releases/download/v1.16.0/kompose-windows-amd64.exe -o kompose.exe +curl -L https://github.com/kubernetes/kompose/releases/download/v1.22.0/kompose-windows-amd64.exe -o kompose.exe chmod +x kompose sudo mv ./kompose /usr/local/bin/kompose @@ -68,9 +67,10 @@ sudo mv ./kompose /usr/local/bin/kompose -或者，你可以下载 [tarball](https://github.com/kubernetes/kompose/releases)。 +或者，你可以下载 [tar 包](https://github.com/kubernetes/kompose/releases)。 -## Go +{{% /tab %}} +{{% tab name="基于源代码构建" %}} @@ -135,129 +141,139 @@ you need is an existing `docker-compose.yml` file. 再需几步，我们就把你从 Docker Compose 带到 Kubernetes。 你只需要一个现有的 `docker-compose.yml` 文件。 -1. - 进入 `docker-compose.yml` 文件所在的目录。如果没有，请使用下面这个进行测试。 +1. + 进入 `docker-compose.yml` 文件所在的目录。如果没有，请使用下面这个进行测试。 - ```yaml - version: "2" + ```yaml + version: "2" - services: + services: - redis-master: - image: k8s.gcr.io/redis:e2e - ports: - - "6379" + redis-master: + image: k8s.gcr.io/redis:e2e + ports: + - "6379" - redis-slave: - image: gcr.io/google_samples/gb-redisslave:v3 - ports: - - "6379" - environment: - - GET_HOSTS_FROM=dns + redis-slave: + image: gcr.io/google_samples/gb-redisslave:v3 + ports: + - "6379" + environment: + - GET_HOSTS_FROM=dns - frontend: - image: gcr.io/google-samples/gb-frontend:v4 - ports: - - "80:80" - environment: - - GET_HOSTS_FROM=dns - labels: - kompose.service.type: LoadBalancer - ``` + frontend: + image: gcr.io/google-samples/gb-frontend:v4 + ports: + - "80:80" + environment: + - GET_HOSTS_FROM=dns + labels: + kompose.service.type: LoadBalancer + ``` -2. - 运行 `kompose up` 命令直接部署到 Kubernetes，或者跳到下一步，生成 `kubectl` 使用的文件。 + +2. 要将 `docker-compose.yml` 转换为 `kubectl` 可用的文件，请运行 `kompose convert` + 命令进行转换，然后运行 `kubectl create -f ` 进行创建。 - ```bash - $ kompose up - We are going to create Kubernetes Deployments, Services and PersistentVolumeClaims for your Dockerized application. - If you need different kind of resources, use the 'kompose convert' and 'kubectl create -f' commands instead. + ```shell + kompose convert + ``` - INFO Successfully created Service: redis - INFO Successfully created Service: web - INFO Successfully created Deployment: redis - INFO Successfully created Deployment: web + ```none + INFO Kubernetes file "frontend-service.yaml" created + INFO Kubernetes file "frontend-service.yaml" created + INFO Kubernetes file "frontend-service.yaml" created + INFO Kubernetes file "redis-master-service.yaml" created + INFO Kubernetes file "redis-master-service.yaml" created + INFO Kubernetes file "redis-master-service.yaml" created + INFO Kubernetes file "redis-slave-service.yaml" created + INFO Kubernetes file "redis-slave-service.yaml" created + INFO Kubernetes file "redis-slave-service.yaml" created + INFO Kubernetes file "frontend-deployment.yaml" created + INFO Kubernetes file "frontend-deployment.yaml" created + INFO Kubernetes file "frontend-deployment.yaml" created + INFO Kubernetes file "redis-master-deployment.yaml" created + INFO Kubernetes file "redis-master-deployment.yaml" created + INFO Kubernetes file "redis-master-deployment.yaml" created + INFO Kubernetes file "redis-slave-deployment.yaml" created + INFO Kubernetes file "redis-slave-deployment.yaml" created + INFO Kubernetes file "redis-slave-deployment.yaml" created + ``` - Your application has been deployed to Kubernetes. You can run 'kubectl get deployment,svc,pods,pvc' for details. - ``` + ```bash + kubectl apply -f frontend-service.yaml,redis-master-service.yaml,redis-slave-service.yaml,frontend-deployment.yaml, + ``` -3. - 要将 `docker-compose.yml` 转换为 `kubectl` 可用的文件，请运行 `kompose convert` 命令进行转换， - 然后运行 `kubectl create -f ` 进行创建。 + + 输出类似于： - ```shell - kompose convert - ``` + ```none + service/frontend created + service/redis-master created + service/redis-slave created + deployment.apps/frontend created + deployment.apps/redis-master created + deployment.apps/redis-slave created + ``` - ``` - INFO Kubernetes file "frontend-service.yaml" created - INFO Kubernetes file "redis-master-service.yaml" created - INFO Kubernetes file "redis-slave-service.yaml" created - INFO Kubernetes file "frontend-deployment.yaml" created - INFO Kubernetes file "redis-master-deployment.yaml" created - INFO Kubernetes file "redis-slave-deployment.yaml" created - ``` + + 你部署的应用在 Kubernetes 中运行起来了。 - ```shell - kubectl create -f frontend-service.yaml,redis-master-service.yaml,redis-slave-service.yaml,frontend-deployment.yaml,redis-master-deployment.yaml,redis-slave-deployment.yaml - ``` + +3. 访问你的应用 - ``` - service/frontend created - service/redis-master created - service/redis-slave created - deployment.apps/frontend created - deployment.apps/redis-master created - deployment.apps/redis-slave created - ``` + - - 你部署的应用在 Kubernetes 中运行起来了。 + 如果你在开发过程中使用 `minikube`，请执行： -4. - 访问你的应用 + ```shell + minikube service frontend + ``` - + + 否则，我们要查看一下你的服务使用了什么 IP！ - 如果你在开发过程中使用 `minikube`，请执行： + ```shell + kubectl describe svc frontend + ``` - ```shell - minikube service frontend - ``` + ```none + Name: frontend + Namespace: default + Labels: service=frontend + Selector: service=frontend + Type: LoadBalancer + IP: 10.0.0.183 + LoadBalancer Ingress: 192.0.2.89 + Port: 80 80/TCP + NodePort: 80 31144/TCP + Endpoints: 172.17.0.4:80 + Session Affinity: None + No events. + ``` - - 否则，我们要查看一下你的服务使用了什么 IP！ + + 如果你使用的是云提供商，你的 IP 将在 `LoadBalancer Ingress` 字段给出。 - ```shell - kubectl describe svc frontend - ``` - - ``` - Name: frontend - Namespace: default - Labels: service=frontend - Selector: service=frontend - Type: LoadBalancer - IP: 10.0.0.183 - LoadBalancer Ingress: 192.0.2.89 - Port: 80 80/TCP - NodePort: 80 31144/TCP - Endpoints: 172.17.0.4:80 - Session Affinity: None - No events. - ``` - - - 如果你使用的是云提供商，你的 IP 将在 `LoadBalancer Ingress` 字段给出。 - - ```shell - curl http://192.0.2.89 - ``` + ```shell + curl http://192.0.2.89 + ``` @@ -284,29 +300,37 @@ you need is an existing `docker-compose.yml` file. - [`kompose down`](#kompose-down) - 文档 - - [构建和推送 Docker 镜像](#构建和推送-docker-镜像) + - [构建和推送 Docker 镜像](#build-and-push-docker-images) - [其他转换方式](#其他转换方式) - - [标签](#标签) - - [重启](#重启) - - [Docker Compose 版本](#docker-compose-版本) + - [标签](#labels) + - [重启](#restart) + - [Docker Compose 版本](#docker-compose-versions) Kompose 支持两种驱动：OpenShift 和 Kubernetes。 -你可以通过全局选项 `--provider` 选择驱动方式。如果没有指定，会将 Kubernetes 作为默认驱动。 +你可以通过全局选项 `--provider` 选择驱动。如果没有指定， +会将 Kubernetes 作为默认驱动。 ## `kompose convert` + Kompose 支持将 V1、V2 和 V3 版本的 Docker Compose 文件转换为 Kubernetes 和 OpenShift 资源对象。 -### Kubernetes + +### Kubernetes `kompose convert` 示例 ```shell kompose --file docker-voting.yml convert ``` -``` + +```none WARN Unsupported key networks - ignoring WARN Unsupported key build - ignoring INFO Kubernetes file "worker-svc.yaml" created @@ -325,7 +349,7 @@ INFO Kubernetes file "db-deployment.yaml" created ls ``` -``` +```none db-deployment.yaml docker-compose.yml docker-gitlab.yml redis-deployment.yaml result-deployment.yaml vote-deployment.yaml worker-deployment.yaml db-svc.yaml docker-voting.yml redis-svc.yaml result-svc.yaml vote-svc.yaml worker-svc.yaml ``` @@ -338,7 +362,8 @@ You can also provide multiple docker-compose files at the same time: ```shell kompose -f docker-compose.yml -f docker-guestbook.yml convert ``` -``` + +```none INFO Kubernetes file "frontend-service.yaml" created INFO Kubernetes file "mlbparks-service.yaml" created INFO Kubernetes file "mongodb-service.yaml" created @@ -368,7 +393,10 @@ When multiple docker-compose files are provided the configuration is merged. Any --> 当提供多个 docker-compose 文件时，配置将会合并。任何通用的配置都将被后续文件覆盖。 -### OpenShift + +### OpenShift `kompose convert` 示例 ```shell kompose --provider openshift --file docker-voting.yml convert @@ -403,7 +431,7 @@ kompose 还支持为服务中的构建指令创建 buildconfig。 kompose --provider openshift --file buildconfig/docker-compose.yml convert ``` -``` +```none WARN [foo] Service cannot be created because of missing port. INFO OpenShift Buildconfig using git@github.com:rtnpro/kompose.git::master as source. INFO OpenShift file "foo-deploymentconfig.yaml" created @@ -424,15 +452,19 @@ imagestream 工件，以解决 Openshift 的这个问题：https://github.com/op -Kompose 支持通过 `kompose up` 直接将你的"复合的（composed）" 应用程序部署到 Kubernetes 或 OpenShift。 +Kompose 支持通过 `kompose up` 直接将你的"复合的（composed）" 应用程序 +部署到 Kubernetes 或 OpenShift。 -### Kubernetes + +### Kubernetes `kompose up` 示例 ```shell kompose --file ./examples/docker-guestbook.yml up ``` -``` +```none We are going to create Kubernetes deployments and services for your Dockerized application. If you need different kind of resources, use the 'kompose convert' and 'kubectl create -f' commands instead. @@ -468,26 +500,27 @@ pod/redis-master-1432129712-63jn8 1/1 Running 0 4m pod/redis-slave-2504961300-nve7b 1/1 Running 0 4m ``` + +{{< note >}} - -**注意**： - - 你必须有一个运行正常的 Kubernetes 集群，该集群具有预先配置的 kubectl 上下文。 - 此操作仅生成 Deployment 和 Service 对象并将其部署到 Kubernetes。 如果需要部署其他不同类型的资源，请使用 `kompose convert` 和 `kubectl create -f` 命令。 +{{< /note >}} - -### OpenShift + +### OpenShift `kompose up` 示例 ```shell kompose --file ./examples/docker-guestbook.yml --provider openshift up ``` -``` +```none We are going to create OpenShift DeploymentConfigs and Services for your Dockerized application. If you need different kind of resources, use the 'kompose convert' and 'oc create -f' commands instead. @@ -508,7 +541,7 @@ Your application has been deployed to OpenShift. You can run 'oc get dc,svc,is' oc get dc,svc,is ``` -``` +```none NAME REVISION DESIRED CURRENT TRIGGERED BY dc/frontend 0 1 0 config,image(frontend:v4) dc/redis-master 0 1 0 config,image(redis-master:e2e) @@ -523,20 +556,18 @@ is/redis-master 172.30.12.200:5000/fff/redis-master is/redis-slave 172.30.12.200:5000/fff/redis-slave v1 ``` +{{< note >}} -**注意**： - -- 你必须有一个运行正常的 OpenShift 集群，该集群具有预先配置的 `oc` 上下文 (`oc login`)。 +你必须有一个运行正常的 OpenShift 集群，该集群具有预先配置的 `oc` 上下文 (`oc login`)。 +{{< /note >}} ## `kompose down` - 你一旦将"复合(composed)" 应用部署到 Kubernetes，`kompose down` 命令将能帮你通过删除 Deployment 和 Service 对象来删除应用。 如果需要删除其他资源，请使用 'kubectl' 命令。 @@ -554,26 +585,27 @@ INFO Successfully deleted service: frontend INFO Successfully deleted deployment: frontend ``` +{{< note >}} +- 你必须有一个运行正常的 Kubernetes 集群，该集群具有预先配置的 kubectl 上下文。 +{{< /note >}} + +## 构建和推送 Docker 镜像 {#build-and-push-docker-images} -**注意**： - -- 你必须有一个运行正常的 Kubernetes 集群，该集群具有预先配置的 kubectl 上下文。 - -## 构建和推送 Docker 镜像 - -Kompose 支持构建和推送 Docker 镜像。如果 Docker Compose 文件中使用了 `build` 关键字，你的镜像将会： +Kompose 支持构建和推送 Docker 镜像。如果 Docker Compose 文件中使用了 `build` +关键字，你的镜像将会： - 使用文档中指定的 `image` 键自动构建 Docker 镜像 - 使用本地凭据推送到正确的 Docker 仓库 @@ -598,7 +630,7 @@ Using `kompose up` with a `build` key: kompose up ``` -``` +```none INFO Build key detected. Attempting to build and push image 'docker.io/foo/bar' INFO Building image 'docker.io/foo/bar' from directory 'build' INFO Image 'docker.io/foo/bar' from directory 'build' built successfully @@ -621,10 +653,10 @@ In order to disable the functionality, or choose to use BuildConfig generation ( 可以通过传递 `--build (local|build-config|none)` 参数来实现。 ```shell -# Disable building/pushing Docker images +# 禁止构造和推送 Docker 镜像 kompose up --build none -# Generate Build Config artifacts for OpenShift +# 为 OpenShift 生成 Build Config 工件 kompose up --provider openshift --build build-config ``` @@ -633,7 +665,7 @@ kompose up --provider openshift --build build-config The default `kompose` transformation will generate Kubernetes [Deployments](/docs/concepts/workloads/controllers/deployment/) and [Services](/docs/concepts/services-networking/service/), in yaml format. You have alternative option to generate json with `-j`. Also, you can alternatively generate [Replication Controllers](/docs/concepts/workloads/controllers/replicationcontroller/) objects, [Daemon Sets](/docs/concepts/workloads/controllers/daemonset/), or [Helm](https://github.com/helm/helm) charts. --> -## 其他转换方式 +## 其他转换方式 {#alternative-conversions} 默认的 `kompose` 转换会生成 yaml 格式的 Kubernetes [Deployment](/zh/docs/concepts/workloads/controllers/deployment/) 和 @@ -646,7 +678,8 @@ The default `kompose` transformation will generate Kubernetes [Deployments](/doc ```shell kompose convert -j ``` -``` + +```none INFO Kubernetes file "redis-svc.json" created INFO Kubernetes file "web-svc.json" created INFO Kubernetes file "redis-deployment.json" created @@ -661,7 +694,8 @@ The `*-deployment.json` files contain the Deployment objects. ```shell kompose convert --replication-controller ``` -``` + +```none INFO Kubernetes file "redis-svc.yaml" created INFO Kubernetes file "web-svc.yaml" created INFO Kubernetes file "redis-replicationcontroller.yaml" created @@ -671,7 +705,6 @@ INFO Kubernetes file "web-replicationcontroller.yaml" created - `*-replicationcontroller.yaml` 文件包含 Replication Controller 对象。 如果你想指定副本数（默认为 1），可以使用 `--replicas` 参数： `kompose convert --replication-controller --replicas 3` @@ -680,7 +713,7 @@ The `*-replicationcontroller.yaml` files contain the Replication Controller obje kompose convert --daemon-set ``` -``` +```none INFO Kubernetes file "redis-svc.yaml" created INFO Kubernetes file "web-svc.yaml" created INFO Kubernetes file "redis-daemonset.yaml" created @@ -688,17 +721,19 @@ INFO Kubernetes file "web-daemonset.yaml" created ``` -`*-daemonset.yaml` 文件包含 Daemon Set 对象。 +`*-daemonset.yaml` 文件包含 DaemonSet 对象。 -如果你想生成 [Helm](https://github.com/kubernetes/helm) 可用的 Chart，只需简单的执行下面的命令： +如果你想生成 [Helm](https://github.com/kubernetes/helm) 可用的 Chart， +只需简单的执行下面的命令： ```shell kompose convert -c ``` -``` + +```none INFO Kubernetes file "web-svc.yaml" created INFO Kubernetes file "redis-svc.yaml" created INFO Kubernetes file "web-deployment.yaml" created @@ -734,9 +769,10 @@ The chart structure is aimed at providing a skeleton for building your Helm char For example: --> -## 标签 +## 标签 {#labels} -`kompose` 支持 `docker-compose.yml` 文件中用于 Kompose 的标签，以便在转换时明确定义 Service 的行为。 +`kompose` 支持 `docker-compose.yml` 文件中用于 Kompose 的标签，以便 +在转换时明确定义 Service 的行为。 - `kompose.service.type` 定义要创建的 Service 类型。例如： @@ -761,11 +797,13 @@ For example: For example: --> - `kompose.service.expose` 定义是否允许从集群外部访问 Service。 - 如果该值被设置为 "true"，提供程序将自动设置端点，对于任何其他值，该值将被设置为主机名。 + 如果该值被设置为 "true"，提供程序将自动设置端点， + 对于任何其他值，该值将被设置为主机名。 如果在 Service 中定义了多个端口，则选择第一个端口作为公开端口。 - - 对于 Kubernetes 驱动程序，创建了一个 Ingress 资源，并且假定已经配置了相应的 Ingress 控制器。 - - 对于 OpenShift 驱动程序, 创建一个 route。 + - 如果使用 Kubernetes 驱动，会有一个 Ingress 资源被创建，并且假定 + 已经配置了相应的 Ingress 控制器。 + - 如果使用 OpenShift 驱动, 则会有一个 route 被创建。 例如： @@ -793,19 +831,18 @@ The currently supported options are: | kompose.service.type | nodeport / clusterip / loadbalancer | | kompose.service.expose| true / hostname | --> - 当前支持的选项有: -| 键 | 值 | -|----------------------|-------------------------------------| -| kompose.service.type | nodeport / clusterip / loadbalancer | -| kompose.service.expose| true / hostname | +| 键 | 值 | +|------------------------|-------------------------------------| +| kompose.service.type | nodeport / clusterip / loadbalancer | +| kompose.service.expose | true / hostname | +{{< note >}} -{{< note >}} -`kompose.service.type` 标签应该只用`ports`来定义，否则 `kompose` 会失败。 +`kompose.service.type` 标签应该只用 `ports` 来定义，否则 `kompose` 会失败。 {{< /note >}} -## 重启 +## 重启 {#restart} -如果你想创建没有控制器的普通 Pod，可以使用 docker-compose 的 `restart` 结构来定义它。 -请参考下表了解 `restart` 的不同参数。 +如果你想创建没有控制器的普通 Pod，可以使用 docker-compose 的 `restart` +结构来指定这一行为。请参考下表了解 `restart` 的不同参数。 -| `docker-compose` `restart` | 创建的对象 | Pod `restartPolicy` | +| `docker-compose` `restart` | 创建的对象 | Pod `restartPolicy` | |----------------------------|-------------------|---------------------| -| `""` | 控制器对象 | `Always` | -| `always` | 控制器对象 | `Always` | +| `""` | 控制器对象 | `Always` | +| `always` | 控制器对象 | `Always` | | `on-failure` | Pod | `OnFailure` | | `no` | Pod | `Never` | @@ -843,9 +880,9 @@ The controller object could be `deployment` or `replicationcontroller`, etc. {{< /note >}} -例如，`pival` Service 将在这里变成 Pod。这个容器的计算值为 `pi`。 +例如，`pival` Service 将在这里变成 Pod。这个容器计算 `pi` 的取值。 ```yaml version: '2' @@ -858,23 +895,22 @@ services: ``` - ### 关于 Deployment Config 的提醒 -如果 Docker Compose 文件中为服务声明了卷，Deployment (Kubernetes) 或 DeploymentConfig (OpenShift) -的策略会从 "RollingUpdate" (默认) 变为 "Recreate"。 +如果 Docker Compose 文件中为服务声明了卷，Deployment (Kubernetes) 或 +DeploymentConfig (OpenShift) 策略会从 "RollingUpdate" (默认) 变为 "Recreate"。 这样做的目的是为了避免服务的多个实例同时访问卷。 -如果 Docker Compose 文件中的服务名包含 `_` (例如 `web_service`)， -那么将会被替换为 `-`，服务也相应的会重命名(例如 `web-service`)。 +如果 Docker Compose 文件中的服务名包含 `_`（例如 `web_service`）， +那么将会被替换为 `-`，服务也相应的会重命名（例如 `web-service`）。 Kompose 这样做的原因是 "Kubernetes" 不允许对象名称中包含 `_`。 请注意，更改服务名称可能会破坏一些 `docker-compose` 文件。 @@ -883,14 +919,15 @@ Kompose 这样做的原因是 "Kubernetes" 不允许对象名称中包含 `_`。 ## Docker Compose Versions Kompose supports Docker Compose versions: 1, 2 and 3. We have limited support on versions 2.1 and 3.2 due to their experimental nature. + A full list on compatibility between all three versions is listed in our [conversion document](https://github.com/kubernetes/kompose/blob/master/docs/conversion.md) including a list of all incompatible Docker Compose keys. --> -## Docker Compose 版本 +## Docker Compose 版本 {#docker-compose-versions} -Kompose 支持的 Docker Compose 版本包括：1、2 和 3。有限支持 2.1 和 3.2 版本，因为它们还在实验阶段。 +Kompose 支持的 Docker Compose 版本包括：1、2 和 3。 +对 2.1 和 3.2 版本的支持还有限，因为它们还在实验阶段。 所有三个版本的兼容性列表请查看我们的 [转换文档](https://github.com/kubernetes/kompose/blob/master/docs/conversion.md)， 文档中列出了所有不兼容的 Docker Compose 关键字。 - diff --git a/content/zh/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/zh/docs/tasks/run-application/horizontal-pod-autoscale.md index fa96247305..4d4c8416c2 100644 --- a/content/zh/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/zh/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -434,6 +434,127 @@ usual. 如果延迟（冷却）时间设置的太短，那么副本数量有可能跟以前一样出现抖动。 {{< /note >}} + +## 对资源指标的支持 {#support-for-resource-metrics} + +HPA 的任何目标资源都可以基于其中的 Pods 的资源用量来实现扩缩。 +在定义 Pod 规约时，类似 `cpu` 和 `memory` 这类资源请求必须被设定。 +这些设定值被用来确定资源利用量并被 HPA 控制器用来对目标资源完成扩缩操作。 +要使用基于资源利用率的扩缩，可以像下面这样指定一个指标源： + +```yaml +type: Resource +resource: + name: cpu + target: + type: Utilization + averageUtilization: 60 +``` + + +基于这一指标设定，HPA 控制器会维持扩缩目标中的 Pods 的平均资源利用率在 60%。 +利用率是 Pod 的当前资源用量与其请求值之间的比值。关于如何计算利用率以及如何计算平均值 +的细节可参考[算法](#algorithm-details)小节。 + +{{< note >}} + +由于所有的容器的资源用量都会被累加起来，Pod 的总体资源用量值可能不会精确体现 +各个容器的资源用量。这一现象也会导致一些问题，例如某个容器运行时的资源用量非常 +高，但因为 Pod 层面的资源用量总值让人在可接受的约束范围内，HPA 不会执行扩大 +目标对象规模的操作。 +{{< /note >}} + + +### 容器资源指标 {#container-resource-metrics} + +{{< feature-state for_k8s_version="v1.20" state="alpha" >}} + + +`HorizontalPodAutoscaler` 也支持容器指标源，这时 HPA 可以跟踪记录一组 Pods 中各个容器的 +资源用量，进而触发扩缩目标对象的操作。 +容器资源指标的支持使得你可以为特定 Pod 中最重要的容器配置规模缩放阈值。 +例如，如果你有一个 Web 应用和一个执行日志操作的边车容器，你可以基于 Web 应用的 +资源用量来执行扩缩，忽略边车容器的存在及其资源用量。 + + +如果你更改缩放目标对象，令其使用新的、包含一组不同的容器的 Pod 规约，你就需要 +修改 HPA 的规约才能基于新添加的容器来执行规模扩缩操作。 +如果指标源中指定的容器不存在或者仅存在于部分 Pods 中，那么这些 Pods 会被忽略， +HPA 会重新计算资源用量值。参阅[算法](#algorithm-details)小节进一步了解计算细节。 +要使用容器资源用量来完成自动扩缩，可以像下面这样定义指标源： + +```yaml +type: ContainerResource +containerResource: + name: cpu + container: application + target: + type: Utilization + averageUtilization: 60 +``` + + +在上面的例子中，HPA 控制器会对目标对象执行扩缩操作以确保所有 Pods 中 +`application` 容器的平均 CPU 用量为 60%。 + +{{< note >}} + +如果你要更改 HorizontalPodAutoscaler 所跟踪记录的容器的名称，你可以按一定顺序 +来执行这一更改，确保在应用更改的过程中用来判定扩缩行为的容器可用。 +在更新定义容器的资源（如 Deployment）之前，你需要更新相关的 HPA，使之能够同时 +跟踪记录新的和老的容器名称。这样，HPA 就能够在整个更新过程中继续计算并提供扩缩操作建议。 + + +一旦你已经将容器名称变更这一操作应用到整个负载对象至上，就可以从 HPA +的规约中去掉老的容器名称，完成清理操作。 +{{< /note >}} +