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/blog/_posts/2020-12-02-dockershim-faq.md b/content/en/blog/_posts/2020-12-02-dockershim-faq.md index f8dbe7f7c7..918a969e51 100644 --- a/content/en/blog/_posts/2020-12-02-dockershim-faq.md +++ b/content/en/blog/_posts/2020-12-02-dockershim-faq.md @@ -114,7 +114,7 @@ will have strictly better performance and less overhead. However, we encourage y to explore all the options from the [CNCF landscape] in case another would be an even better fit for your environment. -[CNCF landscape]: https://landscape.cncf.io/category=container-runtime&format=card-mode&grouping=category +[CNCF landscape]: https://landscape.cncf.io/card-mode?category=container-runtime&grouping=category ### What should I look out for when changing CRI implementations? diff --git a/content/en/docs/concepts/cluster-administration/_index.md b/content/en/docs/concepts/cluster-administration/_index.md index cac156b53b..7d5aec5078 100644 --- a/content/en/docs/concepts/cluster-administration/_index.md +++ b/content/en/docs/concepts/cluster-administration/_index.md @@ -45,7 +45,7 @@ Before choosing a guide, here are some considerations: ## Securing a cluster -* [Certificates](/docs/concepts/cluster-administration/certificates/) describes the steps to generate certificates using different tool chains. +* [Generate Certificates](/docs/tasks/administer-cluster/certificates/) describes the steps to generate certificates using different tool chains. * [Kubernetes Container Environment](/docs/concepts/containers/container-environment/) describes the environment for Kubelet managed containers on a Kubernetes node. diff --git a/content/en/docs/concepts/cluster-administration/certificates.md b/content/en/docs/concepts/cluster-administration/certificates.md index 6314420c01..6cce47f13c 100644 --- a/content/en/docs/concepts/cluster-administration/certificates.md +++ b/content/en/docs/concepts/cluster-administration/certificates.md @@ -4,249 +4,6 @@ content_type: concept weight: 20 --- - -When using client certificate authentication, you can generate certificates -manually through `easyrsa`, `openssl` or `cfssl`. - - - - - - -### easyrsa - -**easyrsa** can manually generate certificates for your cluster. - -1. Download, unpack, and initialize the patched version of easyrsa3. - - curl -LO https://storage.googleapis.com/kubernetes-release/easy-rsa/easy-rsa.tar.gz - tar xzf easy-rsa.tar.gz - cd easy-rsa-master/easyrsa3 - ./easyrsa init-pki -1. Generate a new certificate authority (CA). `--batch` sets automatic mode; - `--req-cn` specifies the Common Name (CN) for the CA's new root certificate. - - ./easyrsa --batch "--req-cn=${MASTER_IP}@`date +%s`" build-ca nopass -1. Generate server certificate and key. - The argument `--subject-alt-name` sets the possible IPs and DNS names the API server will - be accessed with. The `MASTER_CLUSTER_IP` is usually the first IP from the service CIDR - that is specified as the `--service-cluster-ip-range` argument for both the API server and - the controller manager component. The argument `--days` is used to set the number of days - after which the certificate expires. - The sample below also assumes that you are using `cluster.local` as the default - DNS domain name. - - ./easyrsa --subject-alt-name="IP:${MASTER_IP},"\ - "IP:${MASTER_CLUSTER_IP},"\ - "DNS:kubernetes,"\ - "DNS:kubernetes.default,"\ - "DNS:kubernetes.default.svc,"\ - "DNS:kubernetes.default.svc.cluster,"\ - "DNS:kubernetes.default.svc.cluster.local" \ - --days=10000 \ - build-server-full server nopass -1. Copy `pki/ca.crt`, `pki/issued/server.crt`, and `pki/private/server.key` to your directory. -1. Fill in and add the following parameters into the API server start parameters: - - --client-ca-file=/yourdirectory/ca.crt - --tls-cert-file=/yourdirectory/server.crt - --tls-private-key-file=/yourdirectory/server.key - -### openssl - -**openssl** can manually generate certificates for your cluster. - -1. Generate a ca.key with 2048bit: - - openssl genrsa -out ca.key 2048 -1. According to the ca.key generate a ca.crt (use -days to set the certificate effective time): - - openssl req -x509 -new -nodes -key ca.key -subj "/CN=${MASTER_IP}" -days 10000 -out ca.crt -1. Generate a server.key with 2048bit: - - openssl genrsa -out server.key 2048 -1. Create a config file for generating a Certificate Signing Request (CSR). - Be sure to substitute the values marked with angle brackets (e.g. ``) - with real values before saving this to a file (e.g. `csr.conf`). - Note that the value for `MASTER_CLUSTER_IP` is the service cluster IP for the - API server as described in previous subsection. - The sample below also assumes that you are using `cluster.local` as the default - DNS domain name. - - [ req ] - default_bits = 2048 - prompt = no - default_md = sha256 - req_extensions = req_ext - distinguished_name = dn - - [ dn ] - C = - ST = - L = - O = - OU = - CN = - - [ req_ext ] - subjectAltName = @alt_names - - [ alt_names ] - DNS.1 = kubernetes - DNS.2 = kubernetes.default - DNS.3 = kubernetes.default.svc - DNS.4 = kubernetes.default.svc.cluster - DNS.5 = kubernetes.default.svc.cluster.local - IP.1 = - IP.2 = - - [ v3_ext ] - authorityKeyIdentifier=keyid,issuer:always - basicConstraints=CA:FALSE - keyUsage=keyEncipherment,dataEncipherment - extendedKeyUsage=serverAuth,clientAuth - subjectAltName=@alt_names -1. Generate the certificate signing request based on the config file: - - openssl req -new -key server.key -out server.csr -config csr.conf -1. Generate the server certificate using the ca.key, ca.crt and server.csr: - - openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \ - -CAcreateserial -out server.crt -days 10000 \ - -extensions v3_ext -extfile csr.conf -1. View the certificate: - - openssl x509 -noout -text -in ./server.crt - -Finally, add the same parameters into the API server start parameters. - -### cfssl - -**cfssl** is another tool for certificate generation. - -1. Download, unpack and prepare the command line tools as shown below. - Note that you may need to adapt the sample commands based on the hardware - architecture and cfssl version you are using. - - curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl_1.5.0_linux_amd64 -o cfssl - chmod +x cfssl - curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssljson_1.5.0_linux_amd64 -o cfssljson - chmod +x cfssljson - curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl-certinfo_1.5.0_linux_amd64 -o cfssl-certinfo - chmod +x cfssl-certinfo -1. Create a directory to hold the artifacts and initialize cfssl: - - mkdir cert - cd cert - ../cfssl print-defaults config > config.json - ../cfssl print-defaults csr > csr.json -1. Create a JSON config file for generating the CA file, for example, `ca-config.json`: - - { - "signing": { - "default": { - "expiry": "8760h" - }, - "profiles": { - "kubernetes": { - "usages": [ - "signing", - "key encipherment", - "server auth", - "client auth" - ], - "expiry": "8760h" - } - } - } - } -1. Create a JSON config file for CA certificate signing request (CSR), for example, - `ca-csr.json`. Be sure to replace the values marked with angle brackets with - real values you want to use. - - { - "CN": "kubernetes", - "key": { - "algo": "rsa", - "size": 2048 - }, - "names":[{ - "C": "", - "ST": "", - "L": "", - "O": "", - "OU": "" - }] - } -1. Generate CA key (`ca-key.pem`) and certificate (`ca.pem`): - - ../cfssl gencert -initca ca-csr.json | ../cfssljson -bare ca -1. Create a JSON config file for generating keys and certificates for the API - server, for example, `server-csr.json`. Be sure to replace the values in angle brackets with - real values you want to use. The `MASTER_CLUSTER_IP` is the service cluster - IP for the API server as described in previous subsection. - The sample below also assumes that you are using `cluster.local` as the default - DNS domain name. - - { - "CN": "kubernetes", - "hosts": [ - "127.0.0.1", - "", - "", - "kubernetes", - "kubernetes.default", - "kubernetes.default.svc", - "kubernetes.default.svc.cluster", - "kubernetes.default.svc.cluster.local" - ], - "key": { - "algo": "rsa", - "size": 2048 - }, - "names": [{ - "C": "", - "ST": "", - "L": "", - "O": "", - "OU": "" - }] - } -1. Generate the key and certificate for the API server, which are by default - saved into file `server-key.pem` and `server.pem` respectively: - - ../cfssl gencert -ca=ca.pem -ca-key=ca-key.pem \ - --config=ca-config.json -profile=kubernetes \ - server-csr.json | ../cfssljson -bare server - - -## Distributing Self-Signed CA Certificate - -A client node may refuse to recognize a self-signed CA certificate as valid. -For a non-production deployment, or for a deployment that runs behind a company -firewall, you can distribute a self-signed CA certificate to all clients and -refresh the local list for valid certificates. - -On each client, perform the following operations: - -```bash -sudo cp ca.crt /usr/local/share/ca-certificates/kubernetes.crt -sudo update-ca-certificates -``` - -``` -Updating certificates in /etc/ssl/certs... -1 added, 0 removed; done. -Running hooks in /etc/ca-certificates/update.d.... -done. -``` - -## Certificates API - -You can use the `certificates.k8s.io` API to provision -x509 certificates to use for authentication as documented -[here](/docs/tasks/tls/managing-tls-in-a-cluster). - - +To learn how to generate certificates for your cluster, see [Certificates](/docs/tasks/administer-cluster/certificates/). diff --git a/content/en/docs/concepts/configuration/secret.md b/content/en/docs/concepts/configuration/secret.md index 45cf9297ca..0a3688df71 100644 --- a/content/en/docs/concepts/configuration/secret.md +++ b/content/en/docs/concepts/configuration/secret.md @@ -718,7 +718,7 @@ spec: #### Consuming Secret Values from environment variables -Inside a container that consumes a secret in an environment variables, the secret keys appear as +Inside a container that consumes a secret in the environment variables, the secret keys appear as normal environment variables containing the base64 decoded values of the secret data. This is the result of commands executed inside the container from the example above: diff --git a/content/en/docs/concepts/containers/container-environment.md b/content/en/docs/concepts/containers/container-environment.md index 7ec28e97b4..a1eba4d96d 100644 --- a/content/en/docs/concepts/containers/container-environment.md +++ b/content/en/docs/concepts/containers/container-environment.md @@ -40,6 +40,7 @@ as are any environment variables specified statically in the Docker image. ### Cluster information A list of all services that were running when a Container was created is available to that Container as environment variables. +This list is limited to services within the same namespace as the new Container's Pod and Kubernetes control plane services. Those environment variables match the syntax of Docker links. For a service named *foo* that maps to a Container named *bar*, diff --git a/content/en/docs/concepts/overview/components.md b/content/en/docs/concepts/overview/components.md index eb17e2dd7e..763308887d 100644 --- a/content/en/docs/concepts/overview/components.md +++ b/content/en/docs/concepts/overview/components.md @@ -51,11 +51,11 @@ the same machine, and do not run user containers on this machine. See {{< glossary_definition term_id="kube-controller-manager" length="all" >}} -These controllers include: +Some types of these controllers are: * Node controller: Responsible for noticing and responding when nodes go down. - * Replication controller: Responsible for maintaining the correct number of pods for every replication - controller object in the system. + * Job controller: Watches for Job objects that represent one-off tasks, then creates + Pods to run those tasks to completion. * Endpoints controller: Populates the Endpoints object (that is, joins Services & Pods). * Service Account & Token controllers: Create default accounts and API access tokens for new namespaces. 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/services-networking/service.md b/content/en/docs/concepts/services-networking/service.md index bcbf7d7f75..b7a7edcd38 100644 --- a/content/en/docs/concepts/services-networking/service.md +++ b/content/en/docs/concepts/services-networking/service.md @@ -74,8 +74,8 @@ a new instance. The name of a Service object must be a valid [DNS label name](/docs/concepts/overview/working-with-objects/names#dns-label-names). -For example, suppose you have a set of Pods that each listen on TCP port 9376 -and carry a label `app=MyApp`: +For example, suppose you have a set of Pods where each listens on TCP port 9376 +and contains a label `app=MyApp`: ```yaml apiVersion: v1 diff --git a/content/en/docs/concepts/workloads/pods/disruptions.md b/content/en/docs/concepts/workloads/pods/disruptions.md index 3d4248443d..d0a8bbf5a9 100644 --- a/content/en/docs/concepts/workloads/pods/disruptions.md +++ b/content/en/docs/concepts/workloads/pods/disruptions.md @@ -75,7 +75,7 @@ Here are some ways to mitigate involuntary disruptions: and [stateful](/docs/tasks/run-application/run-replicated-stateful-application/) applications.) - For even higher availability when running replicated applications, spread applications across racks (using - [anti-affinity](/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature)) + [anti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)) or across zones (if using a [multi-zone cluster](/docs/setup/multiple-zones).) @@ -104,7 +104,7 @@ ensure that the number of replicas serving load never falls below a certain percentage of the total. Cluster managers and hosting providers should use tools which -respect PodDisruptionBudgets by calling the [Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api) +respect PodDisruptionBudgets by calling the [Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#eviction-api) instead of directly deleting pods or deployments. For example, the `kubectl drain` subcommand lets you mark a node as going out of 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 2d89ee7e74..ad0b9420c5 100644 --- a/content/en/docs/contribute/localization.md +++ b/content/en/docs/contribute/localization.md @@ -61,7 +61,7 @@ Members of `@kubernetes/sig-docs-**-owners` can approve PRs that change content For each localization, The `@kubernetes/sig-docs-**-reviews` team automates review assignment for new PRs. -Members of `@kubernetes/website-maintainers` can create new development branches to coordinate translation efforts. +Members of `@kubernetes/website-maintainers` can create new localization branches to coordinate translation efforts. Members of `@kubernetes/website-milestone-maintainers` can use the `/milestone` [Prow command](https://prow.k8s.io/command-help) to assign a milestone to issues or PRs. @@ -205,14 +205,20 @@ To ensure accuracy in grammar and meaning, members of your localization team sho ### Source files -Localizations must be based on the English files from the most recent release, {{< latest-version >}}. +Localizations must be based on the English files from a specific release targeted by the localization team. +Each localization team can decide which release to target which is referred to as the _target version_ below. -To find source files for the most recent release: +To find source files for your target version: 1. Navigate to the Kubernetes website repository at https://github.com/kubernetes/website. -2. Select the `release-1.X` branch for the most recent version. +2. Select a branch for your target version from the following table: + Target version | Branch + -----|----- + Next version | [`dev-{{< skew nextMinorVersion >}}`](https://github.com/kubernetes/website/tree/dev-{{< skew nextMinorVersion >}}) + Latest version | [`master`](https://github.com/kubernetes/website/tree/master) + Previous version | `release-*.**` -The latest version is {{< latest-version >}}, so the most recent release branch is [`{{< release-branch >}}`](https://github.com/kubernetes/website/tree/{{< release-branch >}}). +The `master` branch holds content for the current release `{{< latest-version >}}`. The release team will create `{{< release-branch >}}` branch shortly before the next release: v{{< skew nextMinorVersion >}}. ### Site strings in i18n @@ -239,11 +245,11 @@ Some language teams have their own language-specific style guide and glossary. F ## Branching strategy -Because localization projects are highly collaborative efforts, we encourage teams to work in shared development branches. +Because localization projects are highly collaborative efforts, we encourage teams to work in shared localization branches. -To collaborate on a development branch: +To collaborate on a localization branch: -1. A team member of [@kubernetes/website-maintainers](https://github.com/orgs/kubernetes/teams/website-maintainers) opens a development branch from a source branch on https://github.com/kubernetes/website. +1. A team member of [@kubernetes/website-maintainers](https://github.com/orgs/kubernetes/teams/website-maintainers) opens a localization branch from a source branch on https://github.com/kubernetes/website. Your team approvers joined the `@kubernetes/website-maintainers` team when you [added your localization team](#add-your-localization-team-in-github) to the [`kubernetes/org`](https://github.com/kubernetes/org) repository. @@ -251,25 +257,31 @@ To collaborate on a development branch: `dev--.` - For example, an approver on a German localization team opens the development branch `dev-1.12-de.1` directly against the k/website repository, based on the source branch for Kubernetes v1.12. + For example, an approver on a German localization team opens the localization branch `dev-1.12-de.1` directly against the k/website repository, based on the source branch for Kubernetes v1.12. -2. Individual contributors open feature branches based on the development branch. +2. Individual contributors open feature branches based on the localization branch. For example, a German contributor opens a pull request with changes to `kubernetes:dev-1.12-de.1` from `username:local-branch-name`. -3. Approvers review and merge feature branches into the development branch. +3. Approvers review and merge feature branches into the localization branch. -4. Periodically, an approver merges the development branch to its source branch by opening and approving a new pull request. Be sure to squash the commits before approving the pull request. +4. Periodically, an approver merges the localization branch to its source branch by opening and approving a new pull request. Be sure to squash the commits before approving the pull request. -Repeat steps 1-4 as needed until the localization is complete. For example, subsequent German development branches would be: `dev-1.12-de.2`, `dev-1.12-de.3`, etc. +Repeat steps 1-4 as needed until the localization is complete. For example, subsequent German localization branches would be: `dev-1.12-de.2`, `dev-1.12-de.3`, etc. -Teams must merge localized content into the same release branch from which the content was sourced. For example, a development branch sourced from {{< release-branch >}} must be based on {{< release-branch >}}. +Teams must merge localized content into the same branch from which the content was sourced. -An approver must maintain a development branch by keeping it current with its source branch and resolving merge conflicts. The longer a development branch stays open, the more maintenance it typically requires. Consider periodically merging development branches and opening new ones, rather than maintaining one extremely long-running development branch. +For example: +- a localization branch sourced from `master` must be merged into `master`. +- a localization branch sourced from `release-1.19` must be merged into `release-1.19`. -At the beginning of every team milestone, it's helpful to open an issue comparing upstream changes between the previous development branch and the current development branch. There are two scripts for comparing upstream changes. [`upstream_changes.py`](https://github.com/kubernetes/website/tree/master/scripts#upstream_changespy) is useful for checking the changes made to a specific file. And [`diff_l10n_branches.py`](https://github.com/kubernetes/website/tree/master/scripts#diff_l10n_branchespy) is useful for creating a list of outdated files for a specific localization branch. +{{< note >}} +If your localization branch was created from `master` branch but it is not merged into `master` before new release branch `{{< release-branch >}}` created, merge it into both `master` and new release branch `{{< release-branch >}}`. To merge your localization branch into new release branch `{{< release-branch >}}`, you need to switch upstream branch of your localization branch to `{{< release-branch >}}`. +{{< /note >}} - While only approvers can open a new development branch and merge pull requests, anyone can open a pull request for a new development branch. No special permissions are required. +At the beginning of every team milestone, it's helpful to open an issue comparing upstream changes between the previous localization branch and the current localization branch. There are two scripts for comparing upstream changes. [`upstream_changes.py`](https://github.com/kubernetes/website/tree/master/scripts#upstream_changespy) is useful for checking the changes made to a specific file. And [`diff_l10n_branches.py`](https://github.com/kubernetes/website/tree/master/scripts#diff_l10n_branchespy) is useful for creating a list of outdated files for a specific localization branch. + +While only approvers can open a new localization branch and merge pull requests, anyone can open a pull request for a new localization branch. No special permissions are required. For more information about working from forks or directly from the repository, see ["fork and clone the repo"](#fork-and-clone-the-repo). @@ -290,5 +302,3 @@ Once a localization meets requirements for workflow and minimum output, SIG docs - Enable language selection on the website - Publicize the localization's availability through [Cloud Native Computing Foundation](https://www.cncf.io/about/) (CNCF) channels, including the [Kubernetes blog](https://kubernetes.io/blog/). - - 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/reference/access-authn-authz/admission-controllers.md b/content/en/docs/reference/access-authn-authz/admission-controllers.md index ef1d9a03a5..8841723344 100644 --- a/content/en/docs/reference/access-authn-authz/admission-controllers.md +++ b/content/en/docs/reference/access-authn-authz/admission-controllers.md @@ -565,6 +565,8 @@ Starting from 1.11, this admission controller is disabled by default. ### PodNodeSelector {#podnodeselector} +{{< feature-state for_k8s_version="v1.5" state="alpha" >}} + This admission controller defaults and limits what node selectors may be used within a namespace by reading a namespace annotation and a global configuration. #### Configuration File Format @@ -675,6 +677,8 @@ for more information. ### PodTolerationRestriction {#podtolerationrestriction} +{{< feature-state for_k8s_version="v1.7" state="alpha" >}} + The PodTolerationRestriction admission controller verifies any conflict between tolerations of a pod and the tolerations of its namespace. It rejects the pod request if there is a conflict. It then merges the tolerations annotated on the namespace into the tolerations of the pod. diff --git a/content/en/docs/reference/access-authn-authz/authentication.md b/content/en/docs/reference/access-authn-authz/authentication.md index fc76cbb2f4..17702520e4 100644 --- a/content/en/docs/reference/access-authn-authz/authentication.md +++ b/content/en/docs/reference/access-authn-authz/authentication.md @@ -99,7 +99,7 @@ openssl req -new -key jbeda.pem -out jbeda-csr.pem -subj "/CN=jbeda/O=app1/O=app This would create a CSR for the username "jbeda", belonging to two groups, "app1" and "app2". -See [Managing Certificates](/docs/concepts/cluster-administration/certificates/) for how to generate a client cert. +See [Managing Certificates](/docs/tasks/administer-cluster/certificates/) for how to generate a client cert. ### Static Token File @@ -328,7 +328,7 @@ Since all of the data needed to validate who you are is in the `id_token`, Kuber 1. Kubernetes has no "web interface" to trigger the authentication process. There is no browser or interface to collect credentials which is why you need to authenticate to your identity provider first. 2. The `id_token` can't be revoked, it's like a certificate so it should be short-lived (only a few minutes) so it can be very annoying to have to get a new token every few minutes. -3. To authenticate to the Kubernetes dashboard, you must the `kubectl proxy` command or a reverse proxy that injects the `id_token`. +3. To authenticate to the Kubernetes dashboard, you must use the `kubectl proxy` command or a reverse proxy that injects the `id_token`. #### Configuring the API Server diff --git a/content/en/docs/reference/using-api/client-libraries.md b/content/en/docs/reference/using-api/client-libraries.md index 96589c6a55..6860008914 100644 --- a/content/en/docs/reference/using-api/client-libraries.md +++ b/content/en/docs/reference/using-api/client-libraries.md @@ -67,6 +67,7 @@ their authors, not the Kubernetes team. | Python | [github.com/fiaas/k8s](https://github.com/fiaas/k8s) | | Python | [github.com/mnubo/kubernetes-py](https://github.com/mnubo/kubernetes-py) | | Python | [github.com/tomplus/kubernetes_asyncio](https://github.com/tomplus/kubernetes_asyncio) | +| Python | [github.com/Frankkkkk/pykorm](https://github.com/Frankkkkk/pykorm) | | Ruby | [github.com/abonas/kubeclient](https://github.com/abonas/kubeclient) | | Ruby | [github.com/Ch00k/kuber](https://github.com/Ch00k/kuber) | | Ruby | [github.com/kontena/k8s-client](https://github.com/kontena/k8s-client) | diff --git a/content/en/docs/setup/production-environment/container-runtimes.md b/content/en/docs/setup/production-environment/container-runtimes.md index 5aa4ac894e..e59b497302 100644 --- a/content/en/docs/setup/production-environment/container-runtimes.md +++ b/content/en/docs/setup/production-environment/container-runtimes.md @@ -219,30 +219,39 @@ sudo systemctl restart containerd ``` {{% /tab %}} {{% tab name="Windows (PowerShell)" %}} + +
+Start a Powershell session, set `$Version` to the desired version (ex: `$Version=1.4.3`), and then run the following commands: +
+ ```powershell # (Install containerd) -# download containerd -cmd /c curl -OL https://github.com/containerd/containerd/releases/download/v1.4.1/containerd-1.4.1-windows-amd64.tar.gz -cmd /c tar xvf .\containerd-1.4.1-windows-amd64.tar.gz +# Download containerd +curl.exe -L https://github.com/containerd/containerd/releases/download/v$Version/containerd-$Version-windows-amd64.tar.gz -o containerd-windows-amd64.tar.gz +tar.exe xvf .\containerd-windows-amd64.tar.gz ``` ```powershell -# extract and configure +# Extract and configure Copy-Item -Path ".\bin\" -Destination "$Env:ProgramFiles\containerd" -Recurse -Force cd $Env:ProgramFiles\containerd\ .\containerd.exe config default | Out-File config.toml -Encoding ascii -# review the configuration. depending on setup you may want to adjust: -# - the sandbox_image (kubernetes pause image) +# Review the configuration. Depending on setup you may want to adjust: +# - the sandbox_image (Kubernetes pause image) # - cni bin_dir and conf_dir locations Get-Content config.toml + +# (Optional - but highly recommended) Exclude containerd form Windows Defender Scans +Add-MpPreference -ExclusionProcess "$Env:ProgramFiles\containerd\containerd.exe" ``` ```powershell -# start containerd +# Start containerd .\containerd.exe --register-service Start-Service containerd ``` + {{% /tab %}} {{< /tabs >}} diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md index 394820324d..3f6e991eac 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md @@ -18,14 +18,7 @@ For information how to create a cluster with kubeadm once you have performed thi ## {{% heading "prerequisites" %}} -* One or more machines running one of: - - Ubuntu 16.04+ - - Debian 9+ - - CentOS 7+ - - Red Hat Enterprise Linux (RHEL) 7+ - - Fedora 25+ - - HypriotOS v1.0.1+ - - Flatcar Container Linux (tested with 2512.3.0) +* A compatible Linux host. The Kubernetes project provides generic instructions for Linux distributions based on Debian and Red Hat, and those distributions without a package manager. * 2 GB or more of RAM per machine (any less will leave little room for your apps). * 2 CPUs or more. * Full network connectivity between all machines in the cluster (public or private network is fine). @@ -122,7 +115,7 @@ The following table lists container runtimes and their associated socket paths: {{< table caption = "Container runtimes and their socket paths" >}} | Runtime | Path to Unix domain socket | |------------|-----------------------------------| -| Docker | `/var/run/docker.sock` | +| Docker | `/var/run/dockershim.sock` | | containerd | `/run/containerd/containerd.sock` | | CRI-O | `/var/run/crio/crio.sock` | {{< /table >}} @@ -181,7 +174,7 @@ For more information on version skews, see: * Kubeadm-specific [version skew policy](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#version-skew-policy) {{< tabs name="k8s_install" >}} -{{% tab name="Ubuntu, Debian or HypriotOS" %}} +{{% tab name="Debian-based distributions" %}} ```bash sudo apt-get update && sudo apt-get install -y apt-transport-https curl curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add - @@ -193,7 +186,7 @@ sudo apt-get install -y kubelet kubeadm kubectl sudo apt-mark hold kubelet kubeadm kubectl ``` {{% /tab %}} -{{% tab name="CentOS, RHEL or Fedora" %}} +{{% tab name="Red Hat-based distributions" %}} ```bash cat < + +When using client certificate authentication, you can generate certificates +manually through `easyrsa`, `openssl` or `cfssl`. + + + + + + +### easyrsa + +**easyrsa** can manually generate certificates for your cluster. + +1. Download, unpack, and initialize the patched version of easyrsa3. + + curl -LO https://storage.googleapis.com/kubernetes-release/easy-rsa/easy-rsa.tar.gz + tar xzf easy-rsa.tar.gz + cd easy-rsa-master/easyrsa3 + ./easyrsa init-pki +1. Generate a new certificate authority (CA). `--batch` sets automatic mode; + `--req-cn` specifies the Common Name (CN) for the CA's new root certificate. + + ./easyrsa --batch "--req-cn=${MASTER_IP}@`date +%s`" build-ca nopass +1. Generate server certificate and key. + The argument `--subject-alt-name` sets the possible IPs and DNS names the API server will + be accessed with. The `MASTER_CLUSTER_IP` is usually the first IP from the service CIDR + that is specified as the `--service-cluster-ip-range` argument for both the API server and + the controller manager component. The argument `--days` is used to set the number of days + after which the certificate expires. + The sample below also assumes that you are using `cluster.local` as the default + DNS domain name. + + ./easyrsa --subject-alt-name="IP:${MASTER_IP},"\ + "IP:${MASTER_CLUSTER_IP},"\ + "DNS:kubernetes,"\ + "DNS:kubernetes.default,"\ + "DNS:kubernetes.default.svc,"\ + "DNS:kubernetes.default.svc.cluster,"\ + "DNS:kubernetes.default.svc.cluster.local" \ + --days=10000 \ + build-server-full server nopass +1. Copy `pki/ca.crt`, `pki/issued/server.crt`, and `pki/private/server.key` to your directory. +1. Fill in and add the following parameters into the API server start parameters: + + --client-ca-file=/yourdirectory/ca.crt + --tls-cert-file=/yourdirectory/server.crt + --tls-private-key-file=/yourdirectory/server.key + +### openssl + +**openssl** can manually generate certificates for your cluster. + +1. Generate a ca.key with 2048bit: + + openssl genrsa -out ca.key 2048 +1. According to the ca.key generate a ca.crt (use -days to set the certificate effective time): + + openssl req -x509 -new -nodes -key ca.key -subj "/CN=${MASTER_IP}" -days 10000 -out ca.crt +1. Generate a server.key with 2048bit: + + openssl genrsa -out server.key 2048 +1. Create a config file for generating a Certificate Signing Request (CSR). + Be sure to substitute the values marked with angle brackets (e.g. ``) + with real values before saving this to a file (e.g. `csr.conf`). + Note that the value for `MASTER_CLUSTER_IP` is the service cluster IP for the + API server as described in previous subsection. + The sample below also assumes that you are using `cluster.local` as the default + DNS domain name. + + [ req ] + default_bits = 2048 + prompt = no + default_md = sha256 + req_extensions = req_ext + distinguished_name = dn + + [ dn ] + C = + ST = + L = + O = + OU = + CN = + + [ req_ext ] + subjectAltName = @alt_names + + [ alt_names ] + DNS.1 = kubernetes + DNS.2 = kubernetes.default + DNS.3 = kubernetes.default.svc + DNS.4 = kubernetes.default.svc.cluster + DNS.5 = kubernetes.default.svc.cluster.local + IP.1 = + IP.2 = + + [ v3_ext ] + authorityKeyIdentifier=keyid,issuer:always + basicConstraints=CA:FALSE + keyUsage=keyEncipherment,dataEncipherment + extendedKeyUsage=serverAuth,clientAuth + subjectAltName=@alt_names +1. Generate the certificate signing request based on the config file: + + openssl req -new -key server.key -out server.csr -config csr.conf +1. Generate the server certificate using the ca.key, ca.crt and server.csr: + + openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \ + -CAcreateserial -out server.crt -days 10000 \ + -extensions v3_ext -extfile csr.conf +1. View the certificate: + + openssl x509 -noout -text -in ./server.crt + +Finally, add the same parameters into the API server start parameters. + +### cfssl + +**cfssl** is another tool for certificate generation. + +1. Download, unpack and prepare the command line tools as shown below. + Note that you may need to adapt the sample commands based on the hardware + architecture and cfssl version you are using. + + curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl_1.5.0_linux_amd64 -o cfssl + chmod +x cfssl + curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssljson_1.5.0_linux_amd64 -o cfssljson + chmod +x cfssljson + curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl-certinfo_1.5.0_linux_amd64 -o cfssl-certinfo + chmod +x cfssl-certinfo +1. Create a directory to hold the artifacts and initialize cfssl: + + mkdir cert + cd cert + ../cfssl print-defaults config > config.json + ../cfssl print-defaults csr > csr.json +1. Create a JSON config file for generating the CA file, for example, `ca-config.json`: + + { + "signing": { + "default": { + "expiry": "8760h" + }, + "profiles": { + "kubernetes": { + "usages": [ + "signing", + "key encipherment", + "server auth", + "client auth" + ], + "expiry": "8760h" + } + } + } + } +1. Create a JSON config file for CA certificate signing request (CSR), for example, + `ca-csr.json`. Be sure to replace the values marked with angle brackets with + real values you want to use. + + { + "CN": "kubernetes", + "key": { + "algo": "rsa", + "size": 2048 + }, + "names":[{ + "C": "", + "ST": "", + "L": "", + "O": "", + "OU": "" + }] + } +1. Generate CA key (`ca-key.pem`) and certificate (`ca.pem`): + + ../cfssl gencert -initca ca-csr.json | ../cfssljson -bare ca +1. Create a JSON config file for generating keys and certificates for the API + server, for example, `server-csr.json`. Be sure to replace the values in angle brackets with + real values you want to use. The `MASTER_CLUSTER_IP` is the service cluster + IP for the API server as described in previous subsection. + The sample below also assumes that you are using `cluster.local` as the default + DNS domain name. + + { + "CN": "kubernetes", + "hosts": [ + "127.0.0.1", + "", + "", + "kubernetes", + "kubernetes.default", + "kubernetes.default.svc", + "kubernetes.default.svc.cluster", + "kubernetes.default.svc.cluster.local" + ], + "key": { + "algo": "rsa", + "size": 2048 + }, + "names": [{ + "C": "", + "ST": "", + "L": "", + "O": "", + "OU": "" + }] + } +1. Generate the key and certificate for the API server, which are by default + saved into file `server-key.pem` and `server.pem` respectively: + + ../cfssl gencert -ca=ca.pem -ca-key=ca-key.pem \ + --config=ca-config.json -profile=kubernetes \ + server-csr.json | ../cfssljson -bare server + + +## Distributing Self-Signed CA Certificate + +A client node may refuse to recognize a self-signed CA certificate as valid. +For a non-production deployment, or for a deployment that runs behind a company +firewall, you can distribute a self-signed CA certificate to all clients and +refresh the local list for valid certificates. + +On each client, perform the following operations: + +```bash +sudo cp ca.crt /usr/local/share/ca-certificates/kubernetes.crt +sudo update-ca-certificates +``` + +``` +Updating certificates in /etc/ssl/certs... +1 added, 0 removed; done. +Running hooks in /etc/ca-certificates/update.d.... +done. +``` + +## Certificates API + +You can use the `certificates.k8s.io` API to provision +x509 certificates to use for authentication as documented +[here](/docs/tasks/tls/managing-tls-in-a-cluster). + + diff --git a/content/en/docs/tasks/configmap-secret/managing-secret-using-kustomize.md b/content/en/docs/tasks/configmap-secret/managing-secret-using-kustomize.md index d7b1f48a4a..5cbb30b99b 100644 --- a/content/en/docs/tasks/configmap-secret/managing-secret-using-kustomize.md +++ b/content/en/docs/tasks/configmap-secret/managing-secret-using-kustomize.md @@ -92,7 +92,7 @@ kubectl describe secrets/db-user-pass-96mffmfh4k The output is similar to: ``` -Name: db-user-pass +Name: db-user-pass-96mffmfh4k Namespace: default Labels: Annotations: diff --git a/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index 45d56531f2..0cdfd28258 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -293,6 +293,10 @@ Services. Readiness probes runs on the container during its whole lifecycle. {{< /note >}} +{{< caution >}} +Liveness probes *do not* wait for readiness probes to succeed. If you want to wait before executing a liveness probe you should use initialDelaySeconds or a startupProbe. +{{< /caution >}} + Readiness probes are configured similarly to liveness probes. The only difference is that you use the `readinessProbe` field instead of the `livenessProbe` field. diff --git a/content/en/docs/tasks/debug-application-cluster/debug-running-pod.md b/content/en/docs/tasks/debug-application-cluster/debug-running-pod.md index 54e474429c..59a83e87c7 100644 --- a/content/en/docs/tasks/debug-application-cluster/debug-running-pod.md +++ b/content/en/docs/tasks/debug-application-cluster/debug-running-pod.md @@ -99,7 +99,7 @@ kubectl run ephemeral-demo --image=k8s.gcr.io/pause:3.1 --restart=Never ``` The examples in this section use the `pause` container image because it does not -contain userland debugging utilities, but this method works with all container +contain debugging utilities, but this method works with all container images. If you attempt to use `kubectl exec` to create a shell you will see an error diff --git a/content/en/docs/tasks/inject-data-application/define-environment-variable-container.md b/content/en/docs/tasks/inject-data-application/define-environment-variable-container.md index 9cefdca03d..02677d6204 100644 --- a/content/en/docs/tasks/inject-data-application/define-environment-variable-container.md +++ b/content/en/docs/tasks/inject-data-application/define-environment-variable-container.md @@ -70,8 +70,9 @@ override any environment variables specified in the container image. {{< /note >}} {{< note >}} -The environment variables can reference each other, and cycles are possible, -pay attention to the order before using +Environment variables may reference each other, however ordering is important. +Variables making use of others defined in the same context must come later in +the list. Similarly, avoid circular references. {{< /note >}} ## Using environment variables inside of your config diff --git a/content/en/docs/tasks/tls/certificate-rotation.md b/content/en/docs/tasks/tls/certificate-rotation.md index ea3602fbb0..5dd9b85714 100644 --- a/content/en/docs/tasks/tls/certificate-rotation.md +++ b/content/en/docs/tasks/tls/certificate-rotation.md @@ -69,8 +69,9 @@ write that to disk, in the location specified by `--cert-dir`. Then the kubelet will use the new certificate to connect to the Kubernetes API. As the expiration of the signed certificate approaches, the kubelet will -automatically issue a new certificate signing request, using the Kubernetes -API. Again, the controller manager will automatically approve the certificate +automatically issue a new certificate signing request, using the Kubernetes API. +This can happen at any point between 30% and 10% of the time remaining on the +certificate. Again, the controller manager will automatically approve the certificate request and attach a signed certificate to the certificate signing request. The kubelet will retrieve the new signed certificate from the Kubernetes API and write that to disk. Then it will update the connections it has to the diff --git a/content/en/docs/tasks/tls/manual-rotation-of-ca-certificates.md b/content/en/docs/tasks/tls/manual-rotation-of-ca-certificates.md index 1720ab34a2..e56322cbec 100644 --- a/content/en/docs/tasks/tls/manual-rotation-of-ca-certificates.md +++ b/content/en/docs/tasks/tls/manual-rotation-of-ca-certificates.md @@ -105,8 +105,8 @@ Configurations with a single API server will experience unavailability while the * Make sure control plane components logs no TLS errors. {{< note >}} - To generate certificates and private keys for your cluster using the `openssl` command line tool, see [Certificates (`openssl`)](/docs/concepts/cluster-administration/certificates/#openssl). - You can also use [`cfssl`](/docs/concepts/cluster-administration/certificates/#cfssl). + To generate certificates and private keys for your cluster using the `openssl` command line tool, see [Certificates (`openssl`)](/docs/tasks/administer-cluster/certificates/#openssl). + You can also use [`cfssl`](/docs/tasks/administer-cluster/certificates/#cfssl). {{< /note >}} 1. Annotate any Daemonsets and Deployments to trigger pod replacement in a safer rolling fashion. 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/deploy-app/deploy-intro.html b/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html index 2ee67382fd..15b6d00a6c 100644 --- a/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html +++ b/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html @@ -31,7 +31,7 @@ weight: 10 Once you have a running Kubernetes cluster, you can deploy your containerized applications on top of it. To do so, you create a Kubernetes Deployment configuration. The Deployment instructs Kubernetes how to create and update instances of your application. Once you've created a Deployment, the Kubernetes - master schedules the application instances included in that Deployment to run on individual Nodes in the + control plane schedules the application instances included in that Deployment to run on individual Nodes in the cluster.

diff --git a/content/en/docs/tutorials/kubernetes-basics/public/images/module_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/kubernetes-basics/public/images/module_02_first_app.svg b/content/en/docs/tutorials/kubernetes-basics/public/images/module_02_first_app.svg index e0ae8fa504..cf8c922916 100644 --- a/content/en/docs/tutorials/kubernetes-basics/public/images/module_02_first_app.svg +++ b/content/en/docs/tutorials/kubernetes-basics/public/images/module_02_first_app.svg @@ -1,5 +1,32 @@ - -
{{ if ( .Get "category" ) }} - + {{ else }} - + {{ end }}