Merge branch 'master' into dev-1.18

This commit is contained in:
Zach Corleissen
2020-02-25 12:37:49 -08:00
committed by GitHub
45 changed files with 1034 additions and 57 deletions
+1 -1
View File
@@ -28,7 +28,7 @@ El método recomendado para levantar una copia local del sitio web kubernetes.io
> Para Windows, algunas otras herramientas como Make son necesarias. Puede instalarlas utilizando el gestor [Chocolatey](https://chocolatey.org). `choco install make` o siguiendo las instrucciones de [Make for Windows](http://gnuwin32.sourceforge.net/packages/make.htm). > Para Windows, algunas otras herramientas como Make son necesarias. Puede instalarlas utilizando el gestor [Chocolatey](https://chocolatey.org). `choco install make` o siguiendo las instrucciones de [Make for Windows](http://gnuwin32.sourceforge.net/packages/make.htm).
> Si prefiere levantar el sitio web sin utilizar **Docker**, puede seguir las instrucciones disponibles en la sección [Levantando kubernetes.io en local con Hugo](#levantando-kubernetes.io-en-local-con-hugo). > Si prefiere levantar el sitio web sin utilizar **Docker**, puede seguir las instrucciones disponibles en la sección [Levantando kubernetes.io en local con Hugo](#levantando-kubernetesio-en-local-con-hugo).
Una vez tenga Docker [configurado en su máquina](https://www.docker.com/get-started), puede construir la imagen de Docker `kubernetes-hugo` localmente ejecutando el siguiente comando en la raíz del repositorio: Una vez tenga Docker [configurado en su máquina](https://www.docker.com/get-started), puede construir la imagen de Docker `kubernetes-hugo` localmente ejecutando el siguiente comando en la raíz del repositorio:
+1 -1
View File
@@ -33,7 +33,7 @@ La façon recommandée d'exécuter le site web Kubernetes localement est d'utili
> Si vous êtes sous Windows, vous aurez besoin de quelques outils supplémentaires que vous pouvez installer avec [Chocolatey](https://chocolatey.org). `choco install install make` > Si vous êtes sous Windows, vous aurez besoin de quelques outils supplémentaires que vous pouvez installer avec [Chocolatey](https://chocolatey.org). `choco install install make`
> Si vous préférez exécuter le site Web localement sans Docker, voir [Exécuter le site localement avec Hugo](#running-the-site-locally-using-hugo) ci-dessous. > Si vous préférez exécuter le site Web localement sans Docker, voir [Exécuter le site localement avec Hugo](#exécuter-le-site-localement-en-utilisant-hugo) ci-dessous.
Si vous avez Docker [up and running](https://www.docker.com/get-started), construisez l'image Docker `kubernetes-hugo' localement: Si vous avez Docker [up and running](https://www.docker.com/get-started), construisez l'image Docker `kubernetes-hugo' localement:
+2 -2
View File
@@ -175,7 +175,7 @@ language_alternatives = ["en"]
[languages.fr] [languages.fr]
title = "Kubernetes" title = "Kubernetes"
description = "Production-Grade Container Orchestration" description = "Solution professionnelle dorchestration de conteneurs"
languageName ="Français" languageName ="Français"
weight = 5 weight = 5
contentDir = "content/fr" contentDir = "content/fr"
@@ -223,7 +223,7 @@ language_alternatives = ["en"]
[languages.es] [languages.es]
title = "Kubernetes" title = "Kubernetes"
description = "Production-Grade Container Orchestration" description = "Orquestación de contenedores para producción"
languageName ="Español" languageName ="Español"
weight = 9 weight = 9
contentDir = "content/es" contentDir = "content/es"
@@ -180,7 +180,7 @@ kubectl get events --sort-by=.metadata.creationTimestamp
## Ressourcen aktualisieren ## Ressourcen aktualisieren
Ab Version 1.11 ist das `rolling-update` veraltet (Lesen Sie [CHANGELOG-1.11.md](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.11.md) für weitere Informationen), verwenden Sie stattdessen `rollout`. Ab Version 1.11 ist das `rolling-update` veraltet (Lesen Sie [CHANGELOG-1.11.md](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.11.md) für weitere Informationen), verwenden Sie stattdessen `rollout`.
```bash ```bash
kubectl set image deployment/frontend www=image:v2 # Fortlaufende Aktualisierung der "www" Container der "Frontend"-Bereitstellung, Aktualisierung des Images kubectl set image deployment/frontend www=image:v2 # Fortlaufende Aktualisierung der "www" Container der "Frontend"-Bereitstellung, Aktualisierung des Images
@@ -186,7 +186,7 @@ not recommend using them in clusters larger than several hundred nodes.
{{< /note >}} {{< /note >}}
{{< note >}} {{< note >}}
Pod anti-affinity requires nodes to be consistently labelled, i.e. every node in the cluster must have an appropriate label matching `topologyKey`. If some or all nodes are missing the specified `topologyKey` label, it can lead to unintended behavior. Pod anti-affinity requires nodes to be consistently labelled, in other words every node in the cluster must have an appropriate label matching `topologyKey`. If some or all nodes are missing the specified `topologyKey` label, it can lead to unintended behavior.
{{< /note >}} {{< /note >}}
As with node affinity, there are currently two types of pod affinity and anti-affinity, called `requiredDuringSchedulingIgnoredDuringExecution` and As with node affinity, there are currently two types of pod affinity and anti-affinity, called `requiredDuringSchedulingIgnoredDuringExecution` and
@@ -87,7 +87,7 @@ The [imagePullPolicy](/docs/concepts/containers/images/#updating-images) and the
- `imagePullPolicy: Never`: the image is assumed to exist locally. No attempt is made to pull the image. - `imagePullPolicy: Never`: the image is assumed to exist locally. No attempt is made to pull the image.
{{< note >}} {{< note >}}
To make sure the container always uses the same version of the image, you can specify its [digest](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier), for example `sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`. The digest uniquely identifies a specific version of the image, so it is never updated by Kubernetes unless you change the digest value. To make sure the container always uses the same version of the image, you can specify its [digest](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier); replace `<image-name>:<tag>` with `<image-name>@<digest>` (for example, `image@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`). The digest uniquely identifies a specific version of the image, so it is never updated by Kubernetes unless you change the digest value.
{{< /note >}} {{< /note >}}
{{< note >}} {{< note >}}
@@ -67,6 +67,7 @@ Credentials can be provided in several ways:
- use IAM roles and policies to control access to OCIR repositories - use IAM roles and policies to control access to OCIR repositories
- Using Azure Container Registry (ACR) - Using Azure Container Registry (ACR)
- Using IBM Cloud Container Registry - Using IBM Cloud Container Registry
- use IAM roles and policies to grant access to IBM Cloud Container Registry
- Configuring Nodes to Authenticate to a Private Registry - Configuring Nodes to Authenticate to a Private Registry
- all pods can read any configured private registries - all pods can read any configured private registries
- requires node configuration by cluster administrator - requires node configuration by cluster administrator
@@ -148,11 +149,11 @@ Once you have those variables filled in you can
[configure a Kubernetes Secret and use it to deploy a Pod](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod). [configure a Kubernetes Secret and use it to deploy a Pod](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod).
### Using IBM Cloud Container Registry ### Using IBM Cloud Container Registry
IBM Cloud Container Registry provides a multi-tenant private image registry that you can use to safely store and share your Docker images. By default, images in your private registry are scanned by the integrated Vulnerability Advisor to detect security issues and potential vulnerabilities. Users in your IBM Cloud account can access your images, or you can create a token to grant access to registry namespaces. IBM Cloud Container Registry provides a multi-tenant private image registry that you can use to safely store and share your images. By default, images in your private registry are scanned by the integrated Vulnerability Advisor to detect security issues and potential vulnerabilities. Users in your IBM Cloud account can access your images, or you can use IAM roles and policies to grant access to IBM Cloud Container Registry namespaces.
To install the IBM Cloud Container Registry CLI plug-in and create a namespace for your images, see [Getting started with IBM Cloud Container Registry](https://cloud.ibm.com/docs/services/Registry?topic=registry-getting-started). To install the IBM Cloud Container Registry CLI plug-in and create a namespace for your images, see [Getting started with IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=registry-getting-started).
You can use the IBM Cloud Container Registry to deploy containers from [IBM Cloud public images](https://cloud.ibm.com/docs/services/Registry?topic=registry-public_images) and your private images into the `default` namespace of your IBM Cloud Kubernetes Service cluster. To deploy a container into other namespaces, or to use an image from a different IBM Cloud Container Registry region or IBM Cloud account, create a Kubernetes `imagePullSecret`. For more information, see [Building containers from images](https://cloud.ibm.com/docs/containers?topic=containers-images). If you are using the same account and region, you can deploy images that are stored in IBM Cloud Container Registry into the default namespace of your IBM Cloud Kubernetes Service cluster without any additional configuration, see [Building containers from images](https://cloud.ibm.com/docs/containers?topic=containers-images). For other configuration options, see [Understanding how to authorize your cluster to pull images from a registry](https://cloud.ibm.com/docs/containers?topic=containers-registry#cluster_registry_auth).
### Configuring Nodes to Authenticate to a Private Registry ### Configuring Nodes to Authenticate to a Private Registry
@@ -336,7 +336,7 @@ spec:
{{< note >}} {{< note >}}
There is a gap between TLS features supported by various Ingress There is a gap between TLS features supported by various Ingress
controllers. Please refer to documentation on controllers. Please refer to documentation on
[nginx](https://git.k8s.io/ingress-nginx/README.md#https), [nginx](https://kubernetes.github.io/ingress-nginx/user-guide/tls/),
[GCE](https://git.k8s.io/ingress-gce/README.md#frontend-https), or any other [GCE](https://git.k8s.io/ingress-gce/README.md#frontend-https), or any other
platform specific Ingress controller to understand how TLS works in your environment. platform specific Ingress controller to understand how TLS works in your environment.
{{< /note >}} {{< /note >}}
@@ -17,9 +17,14 @@ A _Cron Job_ creates [Jobs](/docs/concepts/workloads/controllers/jobs-run-to-com
One CronJob object is like one line of a _crontab_ (cron table) file. It runs a job periodically One CronJob object is like one line of a _crontab_ (cron table) file. It runs a job periodically
on a given schedule, written in [Cron](https://en.wikipedia.org/wiki/Cron) format. on a given schedule, written in [Cron](https://en.wikipedia.org/wiki/Cron) format.
{{< note >}} {{< caution >}}
All **CronJob** `schedule:` times are based on the timezone of the master where the job is initiated. All **CronJob** `schedule:` times are based on the timezone of the
{{< /note >}} {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}.
If your control plane runs the kube-controller-manager in Pods or bare
containers, the timezone set for the kube-controller-manager container determines the timezone
that the cron job controller uses.
{{< /caution >}}
When creating the manifest for a CronJob resource, make sure the name you provide When creating the manifest for a CronJob resource, make sure the name you provide
is no longer than 52 characters. This is because the CronJob controller will automatically is no longer than 52 characters. This is because the CronJob controller will automatically
@@ -36,7 +36,7 @@ up finished Jobs (either `Complete` or `Failed`) automatically by specifying the
[example](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically). [example](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically).
The TTL controller will assume that a resource is eligible to be cleaned up The TTL controller will assume that a resource is eligible to be cleaned up
TTL seconds after the resource has finished, in other words, when the TTL has expired. When the TTL seconds after the resource has finished, in other words, when the TTL has expired. When the
TTL controller cleans up a resource, it will delete it cascadingly, i.e. delete TTL controller cleans up a resource, it will delete it cascadingly, that is to say it will delete
its dependent objects together with it. Note that when the resource is deleted, its dependent objects together with it. Note that when the resource is deleted,
its lifecycle guarantees, such as finalizers, will be honored. its lifecycle guarantees, such as finalizers, will be honored.
+12 -12
View File
@@ -69,31 +69,31 @@ The following table includes short descriptions and the general syntax for all o
Operation | Syntax | Description Operation | Syntax | Description
-------------------- | -------------------- | -------------------- -------------------- | -------------------- | --------------------
`annotate` | `kubectl annotate (-f FILENAME \| TYPE NAME \| TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags]` | Add or update the annotations of one or more resources. `annotate` | `kubectl annotate (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags]` | Add or update the annotations of one or more resources.
`api-versions` | `kubectl api-versions [flags]` | List the API versions that are available. `api-versions` | `kubectl api-versions [flags]` | List the API versions that are available.
`apply` | `kubectl apply -f FILENAME [flags]`| Apply a configuration change to a resource from a file or stdin. `apply` | `kubectl apply -f FILENAME [flags]`| Apply a configuration change to a resource from a file or stdin.
`attach` | `kubectl attach POD -c CONTAINER [-i] [-t] [flags]` | Attach to a running container either to view the output stream or interact with the container (stdin). `attach` | `kubectl attach POD -c CONTAINER [-i] [-t] [flags]` | Attach to a running container either to view the output stream or interact with the container (stdin).
`autoscale` | `kubectl autoscale (-f FILENAME \| TYPE NAME \| TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU] [flags]` | Automatically scale the set of pods that are managed by a replication controller. `autoscale` | `kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU] [flags]` | Automatically scale the set of pods that are managed by a replication controller.
`cluster-info` | `kubectl cluster-info [flags]` | Display endpoint information about the master and services in the cluster. `cluster-info` | `kubectl cluster-info [flags]` | Display endpoint information about the master and services in the cluster.
`config` | `kubectl config SUBCOMMAND [flags]` | Modifies kubeconfig files. See the individual subcommands for details. `config` | `kubectl config SUBCOMMAND [flags]` | Modifies kubeconfig files. See the individual subcommands for details.
`create` | `kubectl create -f FILENAME [flags]` | Create one or more resources from a file or stdin. `create` | `kubectl create -f FILENAME [flags]` | Create one or more resources from a file or stdin.
`delete` | `kubectl delete (-f FILENAME \| TYPE [NAME \| /NAME \| -l label \| --all]) [flags]` | Delete resources either from a file, stdin, or specifying label selectors, names, resource selectors, or resources. `delete` | `kubectl delete (-f FILENAME | TYPE [NAME | /NAME | -l label | --all]) [flags]` | Delete resources either from a file, stdin, or specifying label selectors, names, resource selectors, or resources.
`describe` | `kubectl describe (-f FILENAME \| TYPE [NAME_PREFIX \| /NAME \| -l label]) [flags]` | Display the detailed state of one or more resources. `describe` | `kubectl describe (-f FILENAME | TYPE [NAME_PREFIX | /NAME | -l label]) [flags]` | Display the detailed state of one or more resources.
`diff` | `kubectl diff -f FILENAME [flags]`| Diff file or stdin against live configuration `diff` | `kubectl diff -f FILENAME [flags]`| Diff file or stdin against live configuration.
`edit` | `kubectl edit (-f FILENAME \| TYPE NAME \| TYPE/NAME) [flags]` | Edit and update the definition of one or more resources on the server by using the default editor. `edit` | `kubectl edit (-f FILENAME | TYPE NAME | TYPE/NAME) [flags]` | Edit and update the definition of one or more resources on the server by using the default editor.
`exec` | `kubectl exec POD [-c CONTAINER] [-i] [-t] [flags] [-- COMMAND [args...]]` | Execute a command against a container in a pod. `exec` | `kubectl exec POD [-c CONTAINER] [-i] [-t] [flags] [-- COMMAND [args...]]` | Execute a command against a container in a pod.
`explain` | `kubectl explain [--recursive=false] [flags]` | Get documentation of various resources. For instance pods, nodes, services, etc. `explain` | `kubectl explain [--recursive=false] [flags]` | Get documentation of various resources. For instance pods, nodes, services, etc.
`expose` | `kubectl expose (-f FILENAME \| TYPE NAME \| TYPE/NAME) [--port=port] [--protocol=TCP\|UDP] [--target-port=number-or-name] [--name=name] [--external-ip=external-ip-of-service] [--type=type] [flags]` | Expose a replication controller, service, or pod as a new Kubernetes service. `expose` | `kubectl expose (-f FILENAME | TYPE NAME | TYPE/NAME) [--port=port] [--protocol=TCP|UDP] [--target-port=number-or-name] [--name=name] [--external-ip=external-ip-of-service] [--type=type] [flags]` | Expose a replication controller, service, or pod as a new Kubernetes service.
`get` | `kubectl get (-f FILENAME \| TYPE [NAME \| /NAME \| -l label]) [--watch] [--sort-by=FIELD] [[-o \| --output]=OUTPUT_FORMAT] [flags]` | List one or more resources. `get` | `kubectl get (-f FILENAME | TYPE [NAME | /NAME | -l label]) [--watch] [--sort-by=FIELD] [[-o | --output]=OUTPUT_FORMAT] [flags]` | List one or more resources.
`label` | `kubectl label (-f FILENAME \| TYPE NAME \| TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags]` | Add or update the labels of one or more resources. `label` | `kubectl label (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags]` | Add or update the labels of one or more resources.
`logs` | `kubectl logs POD [-c CONTAINER] [--follow] [flags]` | Print the logs for a container in a pod. `logs` | `kubectl logs POD [-c CONTAINER] [--follow] [flags]` | Print the logs for a container in a pod.
`patch` | `kubectl patch (-f FILENAME \| TYPE NAME \| TYPE/NAME) --patch PATCH [flags]` | Update one or more fields of a resource by using the strategic merge patch process. `patch` | `kubectl patch (-f FILENAME | TYPE NAME | TYPE/NAME) --patch PATCH [flags]` | Update one or more fields of a resource by using the strategic merge patch process.
`port-forward` | `kubectl port-forward POD [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N] [flags]` | Forward one or more local ports to a pod. `port-forward` | `kubectl port-forward POD [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N] [flags]` | Forward one or more local ports to a pod.
`proxy` | `kubectl proxy [--port=PORT] [--www=static-dir] [--www-prefix=prefix] [--api-prefix=prefix] [flags]` | Run a proxy to the Kubernetes API server. `proxy` | `kubectl proxy [--port=PORT] [--www=static-dir] [--www-prefix=prefix] [--api-prefix=prefix] [flags]` | Run a proxy to the Kubernetes API server.
`replace` | `kubectl replace -f FILENAME` | Replace a resource from a file or stdin. `replace` | `kubectl replace -f FILENAME` | Replace a resource from a file or stdin.
`rolling-update` | `kubectl rolling-update OLD_CONTROLLER_NAME ([NEW_CONTROLLER_NAME] --image=NEW_CONTAINER_IMAGE \| -f NEW_CONTROLLER_SPEC) [flags]` | Perform a rolling update by gradually replacing the specified replication controller and its pods. `rolling-update` | `kubectl rolling-update OLD_CONTROLLER_NAME ([NEW_CONTROLLER_NAME] --image=NEW_CONTAINER_IMAGE | -f NEW_CONTROLLER_SPEC) [flags]` | Perform a rolling update by gradually replacing the specified replication controller and its pods.
`run` | `kubectl run NAME --image=image [--env="key=value"] [--port=port] [--replicas=replicas] [--dry-run=bool] [--overrides=inline-json] [flags]` | Run a specified image on the cluster. `run` | `kubectl run NAME --image=image [--env="key=value"] [--port=port] [--replicas=replicas] [--dry-run=bool] [--overrides=inline-json] [flags]` | Run a specified image on the cluster.
`scale` | `kubectl scale (-f FILENAME \| TYPE NAME \| TYPE/NAME) --replicas=COUNT [--resource-version=version] [--current-replicas=count] [flags]` | Update the size of the specified replication controller. `scale` | `kubectl scale (-f FILENAME | TYPE NAME | TYPE/NAME) --replicas=COUNT [--resource-version=version] [--current-replicas=count] [flags]` | Update the size of the specified replication controller.
`version` | `kubectl version [--client] [flags]` | Display the Kubernetes version running on the client and server. `version` | `kubectl version [--client] [flags]` | Display the Kubernetes version running on the client and server.
Remember: For more about command operations, see the [kubectl](/docs/user-guide/kubectl/) reference documentation. Remember: For more about command operations, see the [kubectl](/docs/user-guide/kubectl/) reference documentation.
@@ -89,7 +89,7 @@ A given Kubernetes server will only preserve a historical list of changes for a
### Watch bookmarks ### Watch bookmarks
To mitigate the impact of short history window, we introduced a concept of `bookmark` watch event. It is a special kind of event to pass an information that all changes up to a given `resourceVersion` client is requesting has already been send. Object returned in that event is of the type requested by the request, but only `resourceVersion` field is set, e.g.: To mitigate the impact of short history window, we introduced a concept of `bookmark` watch event. It is a special kind of event to pass an information that all changes up to a given `resourceVersion` client is requesting has already been sent. Object returned in that event is of the type requested by the request, but only `resourceVersion` field is set, e.g.:
GET /api/v1/namespaces/test/pods?watch=1&resourceVersion=10245&allowWatchBookmarks=true GET /api/v1/namespaces/test/pods?watch=1&resourceVersion=10245&allowWatchBookmarks=true
--- ---
@@ -30,7 +30,7 @@ The upgrade workflow at high level is the following:
- You need to have a kubeadm Kubernetes cluster running version 1.16.0 or later. - You need to have a kubeadm Kubernetes cluster running version 1.16.0 or later.
- [Swap must be disabled](https://serverfault.com/questions/684771/best-way-to-disable-swap-in-linux). - [Swap must be disabled](https://serverfault.com/questions/684771/best-way-to-disable-swap-in-linux).
- The cluster should use a static control plane and etcd pods or external etcd. - The cluster should use a static control plane and etcd pods or external etcd.
- Make sure you read the [release notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.17.md) carefully. - Make sure you read the [release notes]({{< latest-release-notes >}}) carefully.
- Make sure to back up any important components, such as app-level state stored in a database. - Make sure to back up any important components, such as app-level state stored in a database.
`kubeadm upgrade` does not touch your workloads, only components internal to Kubernetes, but backups are always a best practice. `kubeadm upgrade` does not touch your workloads, only components internal to Kubernetes, but backups are always a best practice.
@@ -19,7 +19,7 @@ Kubernetes cluster.
## Add a label to a node ## Add a label to a node
1. List the nodes in your cluster, along with their labels: 1. List the {{< glossary_tooltip term_id="node" text="nodes" >}} in your cluster, along with their labels:
```shell ```shell
kubectl get nodes --show-labels kubectl get nodes --show-labels
@@ -97,7 +97,7 @@ Use the configuration file to create a pod that will get scheduled on `foo-node`
{{% /capture %}} {{% /capture %}}
{{% capture whatsnext %}} {{% capture whatsnext %}}
Learn more about * Learn more about [labels and selectors](/docs/concepts/overview/working-with-objects/labels/).
[labels and selectors](/docs/concepts/overview/working-with-objects/labels/). * Learn more about [nodes](/docs/concepts/architecture/nodes/).
{{% /capture %}} {{% /capture %}}
@@ -39,8 +39,6 @@ Here are some of the sites that offer online training for Kubernetes:
* [Hands-on Introduction to Kubernetes (Instruqt)](https://play.instruqt.com/public/topics/getting-started-with-kubernetes) * [Hands-on Introduction to Kubernetes (Instruqt)](https://play.instruqt.com/public/topics/getting-started-with-kubernetes)
* [IBM Cloud: Deploying Microservices with Kubernetes (Coursera)](https://www.coursera.org/learn/deploy-micro-kube-ibm-cloud)
* [Introduction to Kubernetes (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x) * [Introduction to Kubernetes (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x)
* [Kubernetes Essentials with Hands-On Labs (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/kubernetes-essentials) * [Kubernetes Essentials with Hands-On Labs (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/kubernetes-essentials)
+2 -2
View File
@@ -1,6 +1,6 @@
--- ---
title: "La meilleure solution d'orchestration de conteneurs en production" title: "Solution professionnelle dorchestration de conteneurs"
abstract: "Déploiement, mise à l'échelle et gestion automatisés des conteneurs" abstract: "Déploiement, mise à l'échelle et gestion automatisée des conteneurs"
cid: home cid: home
--- ---
@@ -16,4 +16,4 @@ tags:
<!--more--> <!--more-->
Logiquement, chaque {{< glossary_tooltip text="contrôleur" term_id="controller" >}} est un processus à part mais, Logiquement, chaque {{< glossary_tooltip text="contrôleur" term_id="controller" >}} est un processus à part mais,
pour réduire la compléxité, les contrôleurs sont tous compilés dans un seul binaire et s'exécutent dans un seul processus. pour réduire la complexité, les contrôleurs sont tous compilés dans un seul binaire et s'exécutent dans un seul processus.
@@ -197,7 +197,7 @@ kubectl get events --sort-by=.metadata.creationTimestamp
## Mise à jour de ressources ## Mise à jour de ressources
Depuis la version 1.11, `rolling-update` a été déprécié (voir [CHANGELOG-1.11.md](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.11.md)), utilisez plutôt `rollout`. Depuis la version 1.11, `rolling-update` a été déprécié (voir [CHANGELOG-1.11.md](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.11.md)), utilisez plutôt `rollout`.
```bash ```bash
kubectl set image deployment/frontend www=image:v2 # Rolling update du conteneur "www" du déploiement "frontend", par mise à jour de son image kubectl set image deployment/frontend www=image:v2 # Rolling update du conteneur "www" du déploiement "frontend", par mise à jour de son image
@@ -96,7 +96,7 @@ Kubespray fournit des playbooks supplémentaires qui permettent de gérer votre
### Mise à l'échelle du cluster ### Mise à l'échelle du cluster
Vous pouvez ajouter des noeuds à votre cluter en exécutant le playbook `scale`. Pour plus d'informations se référer à [Adding nodes](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#adding-nodes). Vous pouvez ajouter des noeuds à votre cluster en exécutant le playbook `scale`. Pour plus d'informations se référer à [Adding nodes](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#adding-nodes).
vous pouvez retirer des noeuds de votre cluster en exécutant le playbook `remove-node`. Se référer à [Remove nodes](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#remove-nodes). vous pouvez retirer des noeuds de votre cluster en exécutant le playbook `remove-node`. Se référer à [Remove nodes](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#remove-nodes).
### Mise à jour du cluster ### Mise à jour du cluster
@@ -0,0 +1,54 @@
---
title: Overhead Pod
content_template: templates/concept
weight: 20
---
{{% capture overview %}}
{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
Ketika kamu menjalankan Pod pada Node, Pod itu akan mengambil sejumlah sumber daya sistem. Sumber daya ini adalah tambahan terhadap sumber daya yang diperlukan untuk menjalankan Container di dalam Pod (_overhead_).
_Pod Overhead_ adalah fitur yang berfungsi untuk menghitung sumber daya digunakan oleh infrastruktur Pod selain permintaan dan limit Container.
{{% /capture %}}
{{% capture body %}}
## Overhead Pod
Pada Kubernetes, Overhead Pod ditentukan pada
[saat admisi](/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks) sesuai dengan Overhead yang ditentukan di dalam
[RuntimeClass](/docs/concepts/containers/runtime-class/) milik Pod.
Ketika Overhead Pod diaktifkan, Overhead akan dipertimbangkan sebagai tambahan terhadap jumlah permintaan sumber daya Container
saat menjadwalkan Pod. Begitu pula Kubelet, yang akan memasukkan Overhead Pod saat menentukan ukuran
cgroup milik Pod, dan saat melakukan pemeringkatan pengusiran (_eviction_) Pod.
### Yang perlu disiapkan
Kamu harus memastikan bahwa
[_feature gate_](/docs/reference/command-line-tools-reference/feature-gates/) `PodOverhead` telah diaktifkan (secara bawaan dinonaktifkan)
di seluruh klaster kamu, yang berarti:
- Pada {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}
- Pada {{< glossary_tooltip text="kube-apiserver" term_id="kube-apiserver" >}}
- Pada {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} di setiap Node
- Pada peladen API khusus (_custom_) apa pun yang menggunakan _feature gate_
{{< note >}}
Pengguna yang dapat mengubah sumber daya RuntimeClass dapat memengaruhi kinerja beban kerja klaster secara keseluruhan. Kamu dapat membatasi akses terhadap kemampuan ini dengan kontrol akses Kubernetes.
Lihat [Ringkasan Otorisasi](/docs/reference/access-authn-authz/authorization/) untuk lebih lanjut.
{{< /note >}}
{{% /capture %}}
{{% capture whatsnext %}}
* [RuntimeClass](/docs/concepts/containers/runtime-class/)
* [Desain PodOverhead](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)
{{% /capture %}}
@@ -202,7 +202,7 @@ kubectl get events --sort-by=.metadata.creationTimestamp
## リソースのアップデート ## リソースのアップデート
version 1.11で`rolling-update`は廃止されました、代わりに`rollout`コマンドをお使いください(詳しくはこちらをご覧ください [CHANGELOG-1.11.md](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.11.md))。 version 1.11で`rolling-update`は廃止されました、代わりに`rollout`コマンドをお使いください(詳しくはこちらをご覧ください [CHANGELOG-1.11.md](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.11.md))。
```bash ```bash
kubectl set image deployment/frontend www=image:v2 # frontend Deploymentのwwwコンテナイメージをv2にローリングアップデートします kubectl set image deployment/frontend www=image:v2 # frontend Deploymentのwwwコンテナイメージをv2にローリングアップデートします
@@ -195,7 +195,7 @@ kubectl get events --sort-by=.metadata.creationTimestamp
## 리소스 업데이트 ## 리소스 업데이트
1.11 버전에서 `rolling-update`는 사용 중단(deprecated)되었다. ([CHANGELOG-1.11.md](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.11.md) 참고) 대신 `rollout`를 사용한다. 1.11 버전에서 `rolling-update`는 사용 중단(deprecated)되었다. ([CHANGELOG-1.11.md](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.11.md) 참고) 대신 `rollout`를 사용한다.
```bash ```bash
kubectl set image deployment/frontend www=image:v2 # "frontend" 디플로이먼트의 "www" 컨테이너 이미지를 업데이트하는 롤링 업데이트 kubectl set image deployment/frontend www=image:v2 # "frontend" 디플로이먼트의 "www" 컨테이너 이미지를 업데이트하는 롤링 업데이트
@@ -0,0 +1,11 @@
---
title: Обзор справочной документации
main_menu: true
weight: 80
---
Темы в этом разделе описывают, как генерировать справочные руководства Kubernetes.
Для сборки справочной документации посмотрите следующий ресурс:
* [Краткое руководство по генерации справочной документации](/docs/contribute/generate-ref-docs/quickstart/)
@@ -0,0 +1,185 @@
---
title: Участие в основном коде Kubernetes
content_template: templates/task
weight: 20
---
{{% capture overview %}}
На этой странице показано, как поучаствовать в основном содержимом проекта `kubernetes/kubernetes`.
Вы можете исправить баги, найденные в документации по API Kubernetes или содержимом таких компонентов Kubernetes, как `kubeadm`, `kube-apiserver` и `kube-controller-manager`.
Если вместо этого вы хотите перегенерировать справочную документацию для API Kubernetes или компонентов с именем `kube-*` в основном коде, изучите следующие инструкции:
- [Генерация справочной документации для API Kubernetes](/ru/docs/contribute/generate-ref-docs/kubernetes-api/)
- [Генерация справочной документации для компонентов и инструментов Kubernetes](/ru/docs/contribute/generate-ref-docs/kubernetes-components/)
{{% /capture %}}
{{% capture prerequisites %}}
- Установленные инструменты:
- [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)
- [Golang](https://golang.org/doc/install) версии 1.13+
- [Docker](https://docs.docker.com/engine/installation/)
- [etcd](https://github.com/coreos/etcd/)
- Созданная переменная окружения `GOPATH`, а путь к `etcd` должен быть прописан в переменной окружения `PATH`.
- Вам необходимо знать, как создать пулреквест в репозитории на GitHub.
Это обычно предполагает создание копии репозитория.
Для получения дополнительной информации смотрите страницы [Создание пулреквеста](https://help.github.com/articles/creating-a-pull-request/) и [Стандартный рабочий процесс в GitHub по работе с копией и пулреквестом](https://gist.github.com/Chaser324/ce0505fbed06b947d962).
{{% /capture %}}
{{% capture steps %}}
## Рассмотрение процесса в целом
Справочная документация для API Kubernetes и таких компонентов с `kube-*`, как `kube-apiserver`, `kube-controller-manager`, автоматически генерируются из исходного кода в [основном репозитории Kubernetes](https://github.com/kubernetes/kubernetes/).
Если вы заметили баги в сгенерированной документации, попробуйте его исправить через пулреквест в основной проект.
## Клонирование репозитория Kubernetes
Если вы ещё не склонировали репозиторий kubernetes/kubernetes, сделайте это:
```shell
mkdir $GOPATH/src
cd $GOPATH/src
go get github.com/kubernetes/kubernetes
```
Определите базовую директорию вашей копии репозитория [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes).
Например, если вы выполнили предыдущий шаг, чтобы получить репозиторий, вашей базовой директорией будет `$GOPATH/src/github.com/kubernetes/kubernetes`.
В остальных команд базовая директория будет именоваться как `<k8s-base>`.
Определите базовую директорию вашей копии репозитория [kubernetes-sigs/reference-docs](https://github.com/kubernetes-sigs/reference-docs). Например, если вы выполнили предыдущий шаг, чтобы получить репозиторий, вашей базовой директорией будет `$GOPATH/src/github.com/kubernetes-sigs/reference-docs`.
В остальных команд базовая директория будет именоваться как `<rdocs-base>`.
## Редактирование исходного кода Kubernetes
Справочная документация API Kubernetes генерируется автоматически из спецификации OpenAPI в исходном коде Kubernetes. Если вы хотите изменить справочную документацию API, сначала нужно изменить один или несколько комментариев в исходном коде Kubernetes.
Документация для компонентов `kube-*` также генерируется из основного исходного кода. Для изменения генерируемой документации вам нужно изменить соответствующий код компонента.
### Внесение изменений в основной исходный код
{{< note >}}
Следующие шаги служат примером, а не общим порядком действий. Детали могут отличаться в вашей ситуации.
{{< /note >}}
Рассмотрим пример редактирования комментария в исходном коде Kubernetes.
В вашем локальном репозитории kubernetes/kubernetes переключитесь на ветку master и проверьте, что она актуальна:
```shell
cd <k8s-base>
git checkout master
git pull https://github.com/kubernetes/kubernetes master
```
Предположим, что в исходном файле в ветке master есть опечатка "atmost":
[kubernetes/kubernetes/staging/src/k8s.io/api/apps/v1/types.go](https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/api/apps/v1/types.go)
В вашем локальном окружении откройте `types.go` и измените "atmost" на "at most".
Убедитесь, что вы изменили файл:
```shell
git status
```
Вывод этой команды покажет, что вы находитесь в ветке master и был изменён исходный файл `types.go`:
```shell
On branch master
...
modified: staging/src/k8s.io/api/apps/v1/types.go
```
### Фиксация отредактированного файла
Выполните команду `git add` и `git commit`, чтобы зафиксировать внесенные вами изменения. На следующем шаге вы сделаете второй коммит. Следует отметить, что ваши изменения должны быть разделены на коммита.
### Генерация спецификации OpenAPI и сопутствующих файлов
Перейдите в директорию `<k8s-base>` и выполните следующие скрипты:
```shell
hack/update-generated-swagger-docs.sh
hack/update-openapi-spec.sh
hack/update-generated-protobuf.sh
hack/update-api-reference-docs.sh
```
Выполните команду `git status`, чтобы посмотреть, какие файлы изменились.
```shell
On branch master
...
modified: api/openapi-spec/swagger.json
modified: api/swagger-spec/apps_v1.json
modified: docs/api-reference/apps/v1/definitions.html
modified: staging/src/k8s.io/api/apps/v1/generated.proto
modified: staging/src/k8s.io/api/apps/v1/types.go
modified: staging/src/k8s.io/api/apps/v1/types_swagger_doc_generated.go
```
Изучите содержимое файла `api/openapi-spec/swagger.json`, чтобы убедиться в том, что опечатка была исправлена.
Например, для этого вы можете выполнить команду `git diff -a api/openapi-spec/swagger.json`.
Это важно, потому что изменённый файл `swagger.json` является результатом второй стадии процесса генерации документации.
Выполните команду `git add` и `git commit` для фиксации ваших изменения. Теперь вы можете увидеть два новых коммита:
первый содержит отредактированный файл `types.go`, а второй — сгенерированную спецификацию OpenAPI и сопутствующие файлы. Оформляйте эти изменения в виде двух отдельных коммитов. Это означает, что не нужно объединять коммиты.
Отправьте свои изменения как [пулреквест](https://help.github.com/articles/creating-a-pull-request/) в ветку master репозитория [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes).
Отслеживайте пулреквест и по мере необходимости отвечайте на комментарии рецензента. Не забывайте отслеживать активность в пулреквест до тех пор, пока он не будет принят.
[PR 57758](https://github.com/kubernetes/kubernetes/pull/57758) — пример пулреквеста, который исправляет опечатку в исходном коде Kubernetes.
{{< note >}}
Не всегда легко правильно определить, какой исходный файл нужно изменить. В предыдущем примере нужный исходный файл находится в директории `staging` в репозитории `kubernetes/kubernetes`. Однако в вашей ситуации файл для изменения может находится в другом месте, нежели чем в директории `staging`. Для получения помощи изучите файлы `README` в репозитории [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes/tree/master/staging) и в смежных репозиториях, например, [kubernetes/apiserver](https://github.com/kubernetes/apiserver/blob/master/README.md).
{{< /note >}}
### Применение вашего коммита в ветку выпуска
В предыдущем разделе вы отредактировали файл в ветке master, а затем запустили скрипты для генерации спецификации OpenAPI и смежных файлов. Затем вы отправили свои изменения в виде пулреквеста в ветку master репозитория kubernetes/kubernetes. Теперь представим, что вам нужно бэкпортировать изменения в ветку выпуска. К примеру, ветка master используется для разработки Kubernetes версии 1.10, а вы хотите применить ваши изменения в ветке release-1.9.
Напомним, что в вашем пулреквесте есть два коммита: первый для редактирования `types.go`, а второй — для файлов, сгенерированных скриптами. Следующий шаг — применить сделанный вами первый коммит в ветку release-1.9. Суть в том, чтобы выбрать коммит, который изменяет файл `types.go`, а не коммит с результатами выполнения скриптов. За инструкциями обратитесь к странице [Propose a Cherry Pick](https://git.k8s.io/community/contributors/devel/sig-release/cherry-picks.md).
{{< note >}}
Применение коммита требует наличия возможности добавить метку и этап в вашем пулреквесте. Если у вас нет таких разрешений, вам нужно переговорить с кем-то, кто может сделать это для вас.
{{< /note >}}
Когда в вашем пулреквесте есть определённый коммит, который нужно применить в ветке release-1.9, вам нужно запустить перечисленные ниже скрипты в этой вете из вашего локального окружения.
```shell
hack/update-generated-swagger-docs.sh
hack/update-openapi-spec.sh
hack/update-generated-protobuf.sh
hack/update-api-reference-docs.sh
```
Теперь зафиксируйте изменения в вашем пулреквесте с применённым коммитом, теперь там будет сгенерированная спецификация OpenAPI и связанные с ней файлы. Отслеживайте этот пулреквест до тех пор, пока он не будет объединен в ветке release-1.9.
Сейчас у вас и в ветке master, и в ветке release-1.9 есть обновленный файл `types.go` вместе с множеством сгенерированных файлов, в которых отражаются изменения, внесенные вами в `types.go`. Обратите внимание, что сгенерированная спецификация OpenAPI и другие сгенерированные файлы в ветке release-1.9 не обязательно совпадают с сгенерированными файлами в ветке master. Сгенерированные файлы в ветке release-1.9 содержат элементы API только из Kubernetes 1.9. Сгенерированные файлы в ветке master могут содержать элементы API не только для версии 1.9, но и для 1.10, которая ещё находится в разработке.
## Генерация справочной документации
В предыдущем разделе было показано, как отредактировать исходный файл, а затем сгенерировать несколько файлов, включая `api/openapi-spec/swagger.json` в репозитории `kubernetes/kubernetes`.
Файл `swagger.json` — это файл определения OpenAPI, который используется для генерации справочной документации API.
Теперь вы можете приступить к изучению руководству [Генерация справочной документации для API Kubernetes](/ru/docs/contribute/generate-ref-docs/kubernetes-api/), чтобы создать [справочную документацию API Kubernetes](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/).
{{% /capture %}}
{{% capture whatsnext %}}
* [Генерация справочной документации для API Kubernetes](/ru/docs/contribute/generate-ref-docs/kubernetes-api/)
* [Генерация справочной документации для компонентов и инструментов Kubernetes](/ru/docs/contribute/generate-ref-docs/kubernetes-components/)
* [Генерация справочной документации для команд kubectl](/ru/docs/contribute/generate-ref-docs/kubectl/)
{{% /capture %}}
@@ -0,0 +1,224 @@
---
title: Генерация справочной документации для команд kubectl
content_template: templates/task
weight: 90
---
{{% capture overview %}}
На этой странице показано, как сгенерировать справочник для команды `kubectl`.
{{< note >}}
На этой странице показывается, как сгенерировать справочную документацию для таких [команд kubectl](/ru/docs/reference/generated/kubectl/kubectl-commands), как [kubectl apply](/ru/docs/reference/generated/kubectl/kubectl-commands#apply) и [kubectl taint](/ru/docs/reference/generated/kubectl/kubectl-commands#taint).
Этот раздел не рассматривает генерацию справочной страницы для опций [kubectl](/ru/docs/reference/generated/kubectl/kubectl/). Инструкции по генерации справочной страницы опций kubectl смотрите в разделе [Генерация справочной документации для компонентов и инструментов Kubernetes](/ru/docs/contribute/generate-ref-docs/kubernetes-components/).
{{< /note >}}
{{% /capture %}}
{{% capture prerequisites %}}
{{< include "prerequisites-ref-docs.md" >}}
{{% /capture %}}
{{% capture steps %}}
## Настройка локальных репозиториев
Создайте рабочую область и определите переменную окружения `GOPATH`.
```shell
mkdir -p $HOME/<workspace>
export GOPATH=$HOME/<workspace>
```
Загрузите локальные копии следующих репозиториев:
```shell
go get -u github.com/spf13/pflag
go get -u github.com/spf13/cobra
go get -u gopkg.in/yaml.v2
go get -u kubernetes-sigs/reference-docs
```
Если у вас ещё нет копии репозитория kubernetes/website, клонируйте её на свой компьютер:
```shell
git clone https://github.com/<your-username>/website $GOPATH/src/github.com/<your-username>/website
```
Склонируйте репозиторий kubernetes/kubernetes по пути k8s.io/kubernetes:
```shell
git clone https://github.com/kubernetes/kubernetes $GOPATH/src/k8s.io/kubernetes
```
Удалите пакет spf13 в `$GOPATH/src/k8s.io/kubernetes/vendor/github.com`.
```shell
rm -rf $GOPATH/src/k8s.io/kubernetes/vendor/github.com/spf13
```
В репозитории kubernetes/kubernetes использует исходный код `kubectl` и `kustomize`.
* Определите базовую директорию вашей копии репозитория [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes).
Например, если вы выполнили предыдущий шаг, чтобы получить репозиторий, вашей базовой директорией будет `$GOPATH/src/k8s.io/kubernetes`.
В остальных командах базовая директория будет именоваться как `<k8s-base>`.
* Определите базовую директорию вашей копии репозитория [kubernetes/website](https://github.com/kubernetes/website).
Например, если вы выполнили предыдущий шаг, чтобы получить репозиторий, вашей базовой директорией будет `$GOPATH/src/github.com/<your-username>/website`.
В остальных команд базовая директория будет именоваться как `<web-base>`.
* Определите базовую директорию вашей копии репозитория [kubernetes-sigs/reference-docs](https://github.com/kubernetes-sigs/reference-docs).
Например, если вы выполнили предыдущий шаг, чтобы получить репозиторий, вашей базовой директорией будет `$GOPATH/src/github.com/kubernetes-sigs/reference-docs`.
В остальных команд базовая директория будет именоваться как `<rdocs-base>`.
В вашем локальном репозитории k8s.io/kubernetes переключитесь в нужную вам ветку и убедитесь, что она в актуальном состоянии. Например, если вам нужно сгенерировать документацию для Kubernetes 1.17, вы можете использовать эти команды:
```shell
cd <k8s-base>
git checkout v1.17.0
git pull https://github.com/kubernetes/kubernetes v1.17.0
```
Если вам не нужно изменять исходный код `kubectl`, следуйте инструкциям по [определению переменных сборки](#настройка-переменных-для-сборки).
## Редактирование исходного кода kubectl
Справочная документация по команде kubectl генерируется автоматически из исходного кода kubectl. Если вы хотите изменить справочную документацию, сначала измените один или несколько комментариев в исходном коде kubectl. Сделайте изменения в локальный репозиторий kubernetes/kubernetes, а затем отправьте пулреквест в ветку master репозитория [github.com/kubernetes/kubernetes](https://github.com/kubernetes/kubernetes).
[PR 56673](https://github.com/kubernetes/kubernetes/pull/56673/files) — пример пулреквеста, который исправляет опечатку в исходном коде kubectl.
Отслеживайте пулреквест и по мере необходимости отвечайте на комментарии рецензента. Не забывайте отслеживать активность в пулреквест до тех пор, пока он не будет принят в ветку master репозитория kubernetes/kubernetes.
## Применение вашего изменения в ветку выпуска
Теперь ваше изменение в ветке master, которая используется для разработки следующего выпуска Kubernetes. Если вы хотите добавить ваше изменение в документацию для уже выпущенной версии Kubernetes, вам нужно применить коммит с соответствующим изменением в нужную ветку выпуска.
Например, предположим, что ветка master используется для разработки Kubernetes 1.10, а вам нужно бэкпортировать ваше изменение в ветку release-1.15. За инструкциями обратитесь к странице [Propose a Cherry Pick](https://git.k8s.io/community/contributors/devel/sig-release/cherry-picks.md).
Отслеживайте ваш пулреквест с применённым изменением до тех пор, пока он не будет объединён в ветку выпуска.
{{< note >}}
Применение коммита требует наличия возможности добавить метку и этап в вашем пулреквесте. Если у вас нет таких разрешений, вам нужно переговорить с кем-то, кто может сделать это для вас.
{{< /note >}}
## Настройка переменных для сборки
Перейдите на `<rdocs-base>`. В командной строке установите следующие переменные окружения.
* `K8S_ROOT` со значением `<k8s-base>`.
* `WEB_ROOT` со значением `<web-base>`.
* `K8S_RELEASE` со значением нужной версии документации.
Например, если вы хотите собрать документацию для Kubernetes версии 1.17, определите переменную окружения `K8S_RELEASE` со значением 1.17.
Примеры:
```shell
export WEB_ROOT=$(GOPATH)/src/github.com/<your-username>/website
export K8S_ROOT=$(GOPATH)/src/k8s.io/kubernetes
export K8S_RELEASE=1.17
```
## Создание версионированной директории
Скрипт сборки `createversiondirs` создаёт версионированную директорию и копирует туда конфигурационные файлы справочника kubectl.
Имя версионированной директории имеет следующий вид: `v<major>_<minor>`.
В директории `<rdocs-base>` выполнение следующий скрипт сборки:
```shell
cd <rdocs-base>
make createversiondirs
```
## Переход в тег выпуска в k8s.io/kubernetes
В вашем локальном репозитории `<k8s-base>` перейдите в ветку с версией Kubernetes, для которой вы хотите получить документацию. Например, если вы хотите сгенерировать документацию для Kubernetes 1.17, перейдите в тег `v1.17.0`. Убедитесь, что ваша локальная ветка содержит актуальные изменения.
```shell
cd <k8s-base>
git checkout v1.17.0
git pull https://github.com/kubernetes/kubernetes v1.17.0
```
## Выполнение кода для генерации документации
В вашей локальной директории `<rdocs-base>` запустите скрипт сборки `copycli`. Команда выполняется от пользователя `root`:
```shell
cd <rdocs-base>
make copycli
```
Команда `copycli` удаляет временную директорию сборки, генерирует файлы команды kubectl и копирует полученную HTML-страницу справочника команде kubectl и ресурсы в `<web-base>`.
## Проверка сгенерированных файлов
Убедитесь в том, что перечисленные ниже два файлы были сгенерированы:
```shell
[ -e "<rdocs-base>/gen-kubectldocs/generators/build/index.html" ] && echo "index.html built" || echo "no index.html"
[ -e "<rdocs-base>/gen-kubectldocs/generators/build/navData.js" ] && echo "navData.js built" || echo "no navData.js"
```
## Проверка скопированных файлов
Убедитесь в том, все сгенерированные файлы были скопированы в вашу директорию `<web-base>`:
```shell
cd <web-base>
git status
```
В выводе должны перечислены изменённые файлы:
```
static/docs/reference/generated/kubectl/kubectl-commands.html
static/docs/reference/generated/kubectl/navData.js
```
Также в выводе должно быть:
```
static/docs/reference/generated/kubectl/scroll.js
static/docs/reference/generated/kubectl/stylesheet.css
static/docs/reference/generated/kubectl/tabvisibility.js
static/docs/reference/generated/kubectl/node_modules/bootstrap/dist/css/bootstrap.min.css
static/docs/reference/generated/kubectl/node_modules/highlight.js/styles/default.css
static/docs/reference/generated/kubectl/node_modules/jquery.scrollto/jquery.scrollTo.min.js
static/docs/reference/generated/kubectl/node_modules/jquery/dist/jquery.min.js
static/docs/reference/generated/kubectl/node_modules/font-awesome/css/font-awesome.min.css
```
## Проверка документации локально
Соберите документацию Kubernetes в вашей директории `<web-base>`.
```shell
cd <web-base>
make docker-serve
```
Посмотрите [локальную предварительную версию сайта](https://localhost:1313/docs/reference/generated/kubectl/kubectl-commands/).
## Добавление и фиксация изменений в kubernetes/website
Выполните команду `git add` и `git commit` для фиксации файлов.
## Создание пулреквеста
Создайте пулреквест в репозиторий `kubernetes/website`. Отслеживайте изменения в пулреквесте и по мере необходимости отвечайте на комментарии рецензента. Не забывайте проверять пулреквест до тех пор, пока он не будет принят.
Спустя несколько минут после принятия вашего пулреквеста, обновленные темы справочника будут отображены в [документации](/ru/docs/home/).
{{% /capture %}}
{{% capture whatsnext %}}
* [Руководство по быстрому старту генерации справочной документации](/ru/docs/contribute/generate-ref-docs/quickstart/)
* [Генерация справочной документации для компонентов и инструментов Kubernetes](/ru/docs/contribute/generate-ref-docs/kubernetes-components/)
* [Генерация справочной документации для API Kubernetes](/ru/docs/contribute/generate-ref-docs/kubernetes-api/)
{{% /capture %}}
@@ -0,0 +1,188 @@
---
title: Генерация справочной документации для API Kubernetes
content_template: templates/task
weight: 50
---
{{% capture overview %}}
На этой странице рассказывается про обновление справочной документации по API Kubernetes.
Справочная документация по API Kubernetes собирается из [спецификации OpenAPI Kubernetes](https://github.com/kubernetes/kubernetes/blob/master/api/openapi-spec/swagger.json) с использованием инструмента генерации [kubernetes-sigs/reference-docs](https://github.com/kubernetes-sigs/reference-docs).
Если вы нашли баги в сгенерированной документации, то можете [исправить их в основном коде](/docs/contribute/generate-ref-docs/contribute-upstream/).
Продолжайте чтение данной странице, если вы хотите перегенерировать справочную документацию из спецификации [OpenAPI](https://github.com/OAI/OpenAPI-Specification).
{{% /capture %}}
{{% capture prerequisites %}}
{{< include "prerequisites-ref-docs.md" >}}
{{% /capture %}}
{{% capture steps %}}
## Настройка локальных репозиториев
Создайте рабочую область и определите переменную окружения `GOPATH`.
```shell
mkdir -p $HOME/<workspace>
export GOPATH=$HOME/<workspace>
```
Загрузите локальные копии следующих репозиториев:
```shell
go get -u github.com/kubernetes-sigs/reference-docs
go get -u github.com/go-openapi/loads
go get -u github.com/go-openapi/spec
```
Если у вас ещё нет копии репозитория kubernetes/website, клонируйте её на свой компьютер:
```shell
git clone https://github.com/<your-username>/website $GOPATH/src/github.com/<your-username>/website
```
Склонируйте репозиторий kubernetes/kubernetes по пути k8s.io/kubernetes:
```shell
git clone https://github.com/kubernetes/kubernetes $GOPATH/src/k8s.io/kubernetes
```
* Определите базовую директорию вашей копии репозитория [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes).
Например, если вы выполнили предыдущий шаг, чтобы получить репозиторий, вашей базовой директорией будет `$GOPATH/src/k8s.io/kubernetes`.
В остальных командах базовая директория будет именоваться как `<k8s-base>`.
* Определите базовую директорию вашей копии репозитория [kubernetes/website](https://github.com/kubernetes/website).
Например, если вы выполнили предыдущий шаг, чтобы получить репозиторий, вашей базовой директорией будет `$GOPATH/src/github.com/<your-username>/website`.
В остальных командах базовая директория будет именоваться как `<web-base>`.
* Определите базовую директорию вашей копии репозитория [kubernetes-sigs/reference-docs](https://github.com/kubernetes-sigs/reference-docs).
Например, если вы выполнили предыдущий шаг, чтобы получить репозиторий, вашей базовой директорией будет `$GOPATH/src/github.com/kubernetes-sigs/reference-docs`.
В остальных командах базовая директория будет именоваться как `<rdocs-base>`.
## Генерация справочной документации API
Далее в этом разделе рассматривается генерация [справочной документации по API Kubernetes](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/).
### Настройка переменных для сборки
* `K8S_ROOT` со значением `<k8s-base>`.
* `WEB_ROOT` со значением `<web-base>`.
* `K8S_RELEASE` со значением нужной версии документации.
Например, если вы хотите собрать документацию для Kubernetes версии 1.17, определите переменную окружения `K8S_RELEASE` со значением 1.17.
Примеры:
```shell
export WEB_ROOT=$(GOPATH)/src/github.com/<your-username>/website
export K8S_ROOT=$(GOPATH)/src/k8s.io/kubernetes
export K8S_RELEASE=1.17
```
### Создание версионированной директории и получение Open API spec
Скрипт сборки `updateapispec` создает версионированную директорию для сборки.
После создания директории спецификация Open API генерируется из репозитория `<k8s-base>`. Таким образом версия конфигурационных файлов и спецификация Kubernetes Open API будут совпадать с версией выпуска.
Имя версионированной директории имеет следующий вид: `v<major>_<minor>`.
В директории `<rdocs-base>` выполните следующий скрипт сборки:
```shell
cd <rdocs-base>
make updateapispec
```
### Сборка справочной документации API
Скрипт сборки `copyapi` создает справочник API и копирует генерированные файлы в каталоги в `<web-base>`.
Выполните следующую команду в `<rdocs-base>`:
```shell
cd <rdocs-base>
make copyapi
```
Убедитесь в том, что перечисленные ниже два файлы были сгенерированы:
```shell
[ -e "<rdocs-base>/gen-apidocs/generators/build/index.html" ] && echo "index.html built" || echo "no index.html"
[ -e "<rdocs-base>/gen-apidocs/generators/build/navData.js" ] && echo "navData.js built" || echo "no navData.js"
```
Перейдите в корень директории `<web-base>` и посмотрите, какие файлы были изменены:
```shell
cd <web-base>
git status
```
Вывод команды будет примерно следующим:
```
static/docs/reference/generated/kubernetes-api/v1.17/css/bootstrap.min.css
static/docs/reference/generated/kubernetes-api/v1.17/css/font-awesome.min.css
static/docs/reference/generated/kubernetes-api/v1.17/css/stylesheet.css
static/docs/reference/generated/kubernetes-api/v1.17/fonts/FontAwesome.otf
static/docs/reference/generated/kubernetes-api/v1.17/fonts/fontawesome-webfont.eot
static/docs/reference/generated/kubernetes-api/v1.17/fonts/fontawesome-webfont.svg
static/docs/reference/generated/kubernetes-api/v1.17/fonts/fontawesome-webfont.ttf
static/docs/reference/generated/kubernetes-api/v1.17/fonts/fontawesome-webfont.woff
static/docs/reference/generated/kubernetes-api/v1.17/fonts/fontawesome-webfont.woff2
static/docs/reference/generated/kubernetes-api/v1.17/index.html
static/docs/reference/generated/kubernetes-api/v1.17/js/jquery.scrollTo.min.js
static/docs/reference/generated/kubernetes-api/v1.17/js/navData.js
static/docs/reference/generated/kubernetes-api/v1.17/js/scroll.js
```
## Обновление указателя API-справочника
При генерации справочной документации для нового выпуска в файле `<web-base>/content/en/docs/reference/kubernetes-api/api-index.md` нужно прописать номер предстоящей версии.
* Откройте файл `<web-base>/content/en/docs/reference/kubernetes-api/api-index.md` и обновите номер версии справочника API. Например:
```
---
title: v1.17
---
[Kubernetes API v1.17](/docs/reference/generated/kubernetes-api/v1.17/)
```
* Откройте файл `<web-base>/content/en/docs/reference/_index.md` и добавьте ссылку на последний справочник API. Удалите самую старую версию справочника API.
В этом файле должно быть 5 ссылок на новейшие API-справочники.
## Тестирование справочника API локально
Соберите обновлённую версию API-справочника на своём компьютере.
Проверьте ваши изменения на [локальной предварительной версии сайта](http://localhost:1313/docs/reference/generated/kubernetes-api/v1.17/).
```shell
cd <web-base>
make docker-serve
```
## Фиксация изменений
В директории `<web-base>` выполните команду `git add` и `git commit` для фиксации изменений в репозитории.
Создайте пулреквест в репозиторий `kubernetes/website`. Отслеживайте свой пулреквест и при необходимости отвечайте на комментарии. Не забывайте отслеживать активность в собственном пулреквесте до тех пор, пока он не будет принят.
Отправьте свои изменения в виде [пулреквеста](/ru/docs/contribute/start/) в репозиторий [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes).
Отслеживайте изменения в пулреквесте и по мере необходимости отвечайте на комментарии рецензента. Не забывайте проверять пулреквест до тех пор, пока он не будет принят.
{{% /capture %}}
{{% capture whatsnext %}}
* [Руководство по быстрому старту генерации справочной документации](/ru/docs/contribute/generate-ref-docs/quickstart/)
* [Генерация справочной документации для компонентов и инструментов Kubernetes](/ru/docs/contribute/generate-ref-docs/kubernetes-components/)
* [Генерация справочной документации для команд kubectl](/ru/docs/contribute/generate-ref-docs/kubectl/)
{{% /capture %}}
@@ -0,0 +1,32 @@
---
title: Генерация справочных страниц для компонентов и инструментов Kubernetes
content_template: templates/task
weight: 120
---
{{% capture overview %}}
На этой странице показывается, как собирать справочные страницы компонентов и инструментов Kubernetes.
{{% /capture %}}
{{% capture prerequisites %}}
Начните с [раздела с требованиями](/ru/docs/contribute/generate-ref-docs/quickstart/#подготовка-к-работе) в руководстве по быстрому старту.
{{% /capture %}}
{{% capture steps %}}
Для генерации справочных страниц компонентов и инструментов Kubernetes изучите страницу [руководство по быстрому старту в справочной документации](/docs/contribute/generate-ref-docs/quickstart/).
{{% /capture %}}
{{% capture whatsnext %}}
* [Краткое руководство по генерации справочной документации](/ru/docs/contribute/generate-ref-docs/quickstart/)
* [Генерация справочной документации для команд kubectl](/ru/docs/contribute/generate-ref-docs/kubectl/)
* [Генерация справочной документации для API Kubernetes](/ru/docs/contribute/generate-ref-docs/kubernetes-api/)
* [Участие в документации основного кода проекта Kubernetes](/ru/docs/contribute/generate-ref-docs/contribute-upstream/)
{{% /capture %}}
@@ -0,0 +1,220 @@
---
title: Руководство по быстрому старту
content_template: templates/task
weight: 40
---
{{% capture overview %}}
На этой странице показано, как использовать скрипт `update-imported-docs` для генерации справочной документации Kubernetes. Скрипт автоматизирует настройку сборки и генерирует справочную документацию для выпуска.
{{% /capture %}}
{{% capture prerequisites %}}
{{< include "prerequisites-ref-docs.md" >}}
{{% /capture %}}
{{% capture steps %}}
## Получение репозитория документации
Убедитесь, что ваша копия репозитория `website` обновлена в соответствии с оригинальным репозиторием `kubernetes/website`, а затем склонируйте вашу копию `website`.
```shell
mkdir github.com
cd github.com
git clone git@github.com:<your_github_username>/website.git
```
Определите базовую директорию вашей копии. Например, при выполнении предыдущего блока команд, то базовой директорией будет `website`. Далее в этом руководстве базовая директория в командах будет обозначаться `<web-base>`.
{{< note>}}
Если вы хотите изменить контент инструментов компонента и справочник API, посмотрите [руководство по участию в оригинальной документации](/docs/contribute/generate-ref-docs/contribute-upstream).
{{< /note >}}
## Краткий обзор update-imported-docs
Скрипт `update-imported-docs` находится в директории `<web-base>/update-imported-docs/`.
Этот скрипт генерирует следующие справочники:
* Справочные страницы для компонентов и инструментов
* Справочник команды `kubectl`
* API-справочник Kubernetes
Скрипт `update-imported-docs` генерирует справочную документацию Kubernetes из исходного кода Kubernetes. Скрипт создает временную директорию `/tmp` на вашем компьютере и клонирует необходимые репозитории в эту директорию: `kubernetes/kubernetes` и `kubernetes-sigs/reference-docs`.
Скрипт добавляет путь временной директории в переменную окружения `GOPATH`.
Кроме этого определяются три дополнительные переменные среды:
* `K8S_RELEASE`
* `K8S_ROOT`
* `K8S_WEBROOT`
Для успешного выполнения скрипта нужно передать два аргумента:
* Конфигурационный файл в формате YAML (`reference.yml`)
* Версия выпуска, например, `1.17`
Конфигурационный файл содержит поле `generate-command`.
Поле `generate-command` определяет ряд инструкций для сборки из `kubernetes-sigs/reference-docs/Makefile`. Переменная `K8S_RELEASE` определяет версию выпуска.
Скрипт `update-imported-docs` выполняет следующие шаги:
1. Клонирует репозитории, указанные в конфигурационном файле. Для генерации справочной документации клонируемым репозиторием по умолчанию является `kubernetes-sigs/reference-docs`.
1. Запускает команды в клонированных репозиториях для подготовки генератора документации, а затем генерирует файлы HTML и Markdown.
1. Копирует сгенерированные файлы HTML и Markdown в локальную копию репозитория `<web-base>` в директории, указанные в конфигурационном файле.
1. Обновляет ссылки на команды `kubectl` из `kubectl`.md, ссылаясь на разделы в справочнике по команде `kubectl`.
.
Когда сгенерированные файлы находятся в вашем локальной копии репозитория `<web-base>`, вы можете отправить их в виде [пулреквеста](/ru/docs/contribute/start/) в оригинальный репозиторий `<web-base>`.
## Формат конфигурационного файла
Каждый конфигурационный файл может содержать несколько репозиториев, которые будут импортированы вместе. При необходимости вы можете вручную изменить конфигурационный файл. Вы можете создавать новые конфигурационные файлы для импорта других групп документации.
Ниже приведен пример файла конфигурации в формате YAML:
```yaml
repos:
- name: community
remote: https://github.com/kubernetes/community.git
branch: master
files:
- src: contributors/devel/README.md
dst: docs/imported/community/devel.md
- src: contributors/guide/README.md
dst: docs/imported/community/guide.md
```
Каждый Markdown-файл документации, импортированный инструментом, должен соответствовать [руководству по оформлению документации](/docs/contribute/style/style-guide/).
## Настройка reference.yml
Откройте файл `<web-base>/update-imported-docs/reference.yml` для редактирования.
Не изменяйте значение в поле `generate-command`, если не понимаете, как эта команда используется для сборки справочников.
Вам нет необходимости править файл `reference.yml`. В некоторых случаях изменения в исходном коде основного репозитория могут потребовать внесения изменений в конфигурационный файл (например, зависимости версий golang и изменения сторонних библиотек).
Если у вас возникли проблемы со сборкой, обратитесь за помощью к команде SIG-Docs на канале [#sig-docs в Slack Kubernetes](https://kubernetes.slack.com).
{{< note >}}
Команда `generate-command` является необязательной, её можно использовать для выполнения указанной команды или небольшого скрипта, чтобы сгенерировать документацию из репозитория.
{{< /note >}}
В файле `reference.yml` секция `files` содержат список полей `src` и `dst`.
В поле `src` хранится путь к сгенерированному Markdown-файлу в клонированной директории сборки `kubernetes-sigs/reference-docs`, а поле `dst` определяет, куда скопировать этот файл в клонированном репозитории `kubernetes/website`.
Например:
```yaml
repos:
- name: reference-docs
remote: https://github.com/kubernetes-sigs/reference-docs.git
files:
- src: gen-compdocs/build/kube-apiserver.md
dst: content/en/docs/reference/command-line-tools-reference/kube-apiserver.md
...
```
Обратите внимание, что в случае наличия множества файлов, которые нужно скопировать из одной директории в другую, то для это можете воспользоваться подстановочными знаки в поле `src`. Вам нужно указать имя директории в поле `dst`.
Например:
```yaml
files:
- src: gen-compdocs/build/kubeadm*.md
dst: content/en/docs/reference/setup-tools/kubeadm/generated/
```
## Запуск инструмента update-imported-docs
Вы можете запустить инструмент `update-imported-docs` следующим образом:
```shell
cd <web-base>/update-imported-docs
./update-imported-docs <configuration-file.yml> <release-version>
```
Например:
```shell
./update-imported-docs reference.yml 1.17
```
<!-- Revisit: is the release configuration used -->
## Исправление ссылок
Конфигурационный файл `release.yml` содержит инструкции по исправлению относительных ссылок
Для исправления относительных ссылок в импортированных файлах, установите для свойство `gen-absolute-links` в значение `true`. В качестве примера можете посмотреть файл [`release.yml`](https://github.com/kubernetes/website/blob/master/update-imported-docs/release.yml).
## Внесение изменений в kubernetes/website
Список сгенерированных и скопированных файлов в `<web-base>` можно узнать, как показано ниже:
```shell
cd <web-base>
git status
```
В выводе команды будут показаны новые и измененные файлы. Полученный вывод может отличаться в зависимости от изменений основного исходного кода.
### Сгенерированные файлы инструментом
```
content/en/docs/reference/command-line-tools-reference/cloud-controller-manager.md
content/en/docs/reference/command-line-tools-reference/kube-apiserver.md
content/en/docs/reference/command-line-tools-reference/kube-controller-manager.md
content/en/docs/reference/command-line-tools-reference/kube-proxy.md
content/en/docs/reference/command-line-tools-reference/kube-scheduler.md
content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm.md
content/en/docs/reference/kubectl/kubectl.md
```
### Сгенерированные справочные файлы для команды kubectl
```
static/docs/reference/generated/kubectl/kubectl-commands.html
static/docs/reference/generated/kubectl/navData.js
static/docs/reference/generated/kubectl/scroll.js
static/docs/reference/generated/kubectl/stylesheet.css
static/docs/reference/generated/kubectl/tabvisibility.js
static/docs/reference/generated/kubectl/node_modules/bootstrap/dist/css/bootstrap.min.css
static/docs/reference/generated/kubectl/node_modules/highlight.js/styles/default.css
static/docs/reference/generated/kubectl/node_modules/jquery.scrollto/jquery.scrollTo.min.js
static/docs/reference/generated/kubectl/node_modules/jquery/dist/jquery.min.js
static/docs/reference/generated/kubectl/css/font-awesome.min.css
```
### Сгенерированные файлы и директории для справочника API Kubernetes
```
static/docs/reference/generated/kubernetes-api/v1.17/index.html
static/docs/reference/generated/kubernetes-api/v1.17/js/navData.js
static/docs/reference/generated/kubernetes-api/v1.17/js/scroll.js
static/docs/reference/generated/kubernetes-api/v1.17/js/query.scrollTo.min.js
static/docs/reference/generated/kubernetes-api/v1.17/css/font-awesome.min.css
static/docs/reference/generated/kubernetes-api/v1.17/css/bootstrap.min.css
static/docs/reference/generated/kubernetes-api/v1.17/css/stylesheet.css
static/docs/reference/generated/kubernetes-api/v1.17/fonts/FontAwesome.otf
static/docs/reference/generated/kubernetes-api/v1.17/fonts/fontawesome-webfont.eot
static/docs/reference/generated/kubernetes-api/v1.17/fonts/fontawesome-webfont.svg
static/docs/reference/generated/kubernetes-api/v1.17/fonts/fontawesome-webfont.ttf
static/docs/reference/generated/kubernetes-api/v1.17/fonts/fontawesome-webfont.woff
static/docs/reference/generated/kubernetes-api/v1.17/fonts/fontawesome-webfont.woff2
```
Выполните `git add` и `git commit`, чтобы зафиксировать файлы в репозитории.
## Создание пулреквеста
Создайте пулреквест в репозиторий `kubernetes/website`. Отслеживайте свой пулреквест и при необходимости отвечайте на комментарии. Не забывайте отслеживать активность в собственном пулреквесте до тех пор, пока он не будет принят.
Спустя несколько минут после принятия вашего пулреквеста, обновленные темы справочника будут отображены в [документации](/ru/docs/home/).
{{% /capture %}}
{{% capture whatsnext %}}
Для генерации отдельной взятой справочной документации путём ручной настройки необходимых репозиториев сборки и выполнении скриптов сборки обратитесь к следующим руководствам:
* [Генерация справочной документации для компонентов и инструментов Kubernetes](/ru/docs/contribute/generate-ref-docs/kubernetes-components/)
* [Генерация справочной документации для команд kubectl](/ru/docs/contribute/generate-ref-docs/kubectl/)
* [Генерация справочной документации для API Kubernetes](/ru/docs/contribute/generate-ref-docs/kubernetes-api/)
{{% /capture %}}
+7
View File
@@ -0,0 +1,7 @@
В настоящее время данная функциональность находится в состоянии *alpha*, это означает, что:
* Названия версий включают надпись "alpha" (например, v1alpha1).
* Могут быть баги. Работа с этой функциональностью может привести к ошибкам. Поэтому по умолчанию она отключена.
* Поддержка функциональности может быть прекращена в любое время без предупреждения.
* API может быть несовместим с более поздними версиями без предупреждения.
* Рекомендуется для использования только в тестировочных кластерах с коротким жизненным циклом из-за высокого риска наличия багов и отсутствия долгосрочной поддержки.
+8
View File
@@ -0,0 +1,8 @@
В настоящее время данная функциональность находится в состоянии *beta*, это означает, что:
* Названия версий включают надпись "beta" (например, v2beta3).
* Код хорошо протестирован. Активация этой функциональности — безопасно. Поэтому она включена по умолчанию.
* Поддержка функциональности в целом не будет прекращена, хотя детали могут измениться.
* Схема и/или семантика объектов может стать несовместимой с более поздними бета-версиями или стабильными выпусками. Когда это случится, мы даим инструкции по миграции на следующую версию. Это обновление может включать удаление, редактирование и повторного создание API-объектов. Этот процесс может потребовать тщательного анализа. Кроме этого, он может привести к простою приложений, которые используют данную функциональность.
* Рекомендуется только для неосновного производственного использования из-за риска возникновения возможных несовместимых изменений с будущими версиями. Если у вас есть несколько кластеров, которые возможно обновить независимо, вы можете снять это ограничение.
* **Пожалуйста, попробуйте в действии бета-версии функциональности и поделитесь своими впечатлениями! После того, как функциональность выйдет из бета-версии, нам может быть нецелесообразно что-то дальше изменять.**
@@ -0,0 +1,2 @@
Данная функциональность объявлена *устаревшей*. Для получения дополнительной информации об этом состоянии перейдите на страницу [Политика управления устаревшими версиями Kubernetes](/docs/reference/deprecation-policy/).
+5
View File
@@ -0,0 +1,5 @@
Данная функциональность является *стабильной*, это означает, что:
* Версии именуются по шаблону vX, где X — это целое число.
* Стабильные версии функциональности будут доступны во многих последующих выпусках.
+13
View File
@@ -0,0 +1,13 @@
---
headless: true
resources:
- src: "*alpha*"
title: "alpha"
- src: "*beta*"
title: "beta"
- src: "*deprecated*"
title: "deprecated"
- src: "*stable*"
title: "stable"
---
@@ -0,0 +1,20 @@
### Требования:
- Наличие компьютера под управлением ОС Linux или macOS.
- Установленные следующие инструменты:
- [Python](https://www.python.org/downloads/) версии 3.7.x
- [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)
- [Golang](https://golang.org/doc/install) версии 1.13+
- [Pip](https://pypi.org/project/pip/), который потребуется для установки PyYAML
- [PyYAML](https://pyyaml.org/) версии 5.1.2
- [make](https://www.gnu.org/software/make/)
- [gcc compiler/linker](https://gcc.gnu.org/)
- [Docker](https://docs.docker.com/engine/installation/) (требуется только для справочника команды `kubectl`)
- В переменной окружении `PATH` должны прописаны пути до необходимых инструментов сборки, таких как `Go` и `python`.
- Вам нужно знать, как создать пулреквест в репозитории на GitHub.
Для этого нужно создание собственной копии репозитория. Для получения дополнительной информации смотрите раздел [Работа из локальной копии](/ru/docs/contribute/intermediate/#работа-из-локальной-копии).
@@ -197,7 +197,7 @@ kubectl get events --sort-by=.metadata.creationTimestamp
## Cập nhật các tài nguyên ## Cập nhật các tài nguyên
Theo như phiên bản 1.11, `rolling-update` đã không còn được dùng nữa (xem [CHANGELOG-1.11.md](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.11.md)), sử dụng `rollout` thay thế. Theo như phiên bản 1.11, `rolling-update` đã không còn được dùng nữa (xem [CHANGELOG-1.11.md](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.11.md)), sử dụng `rollout` thay thế.
```bash ```bash
kubectl set image deployment/frontend www=image:v2 # Cập nhận container "www" của deployment "frontend", cập nhật image kubectl set image deployment/frontend www=image:v2 # Cập nhận container "www" của deployment "frontend", cập nhật image
@@ -45,7 +45,7 @@ By convention, the names of Kubernetes resources should be up to maximum length
For example, heres the configuration file with a Pod name as `nginx-demo` and a Container name as `nginx`: For example, heres the configuration file with a Pod name as `nginx-demo` and a Container name as `nginx`:
--> -->
例如,下面是一个配置文件,Pod 名为 `nginx demo`,容器名为 `nginx` 例如,下面是一个配置文件,Pod 名为 `nginx-demo`,容器名为 `nginx`
```yaml ```yaml
apiVersion: v1 apiVersion: v1
@@ -82,8 +82,8 @@ The following manifest creates a storage class "slow" which provisions standard
disk-like persistent disks. disk-like persistent disks.
--> -->
要启用动态供应功能,集群管理员需要为用户预先创建一个或多个 `StorageClass` 对象。 要启用动态供应功能,集群管理员需要为用户预先创建一个或多个 `StorageClass` 对象。
`StorageClass` 对象定义在进行动态供应时应使用哪个卷供应商,以及应该将哪些参数传递给该供应商 `StorageClass` 对象定义动态供应被调用时,哪一个驱动将被使用和哪些参数将被传递给驱动
以下清单创建了一个存储类 "slow",它提供类似标准磁盘的永久磁盘。 以下清单创建了一个 `StorageClass` 存储类 "slow",它提供类似标准磁盘的永久磁盘。
```yaml ```yaml
apiVersion: storage.k8s.io/v1 apiVersion: storage.k8s.io/v1
@@ -135,7 +135,7 @@ Refer to the [CSI specifications](https://github.com/container-storage-interface
* 在 * 在
<a href="https://cloud.google.com/compute/">Google Compute Engine</a>环境中, <a href="https://cloud.google.com/compute/">Google Compute Engine</a>环境中,
[根据节点类型](https://cloud.google.com/compute/docs/disks/#pdnumberlimits)最多可以将128个卷关联到节点。 [根据节点类型](https://cloud.google.com/compute/docs/disks/#pdnumberlimits)最多可以将127个卷关联到节点。
* 对于 M5、C5、R5、T3 和 Z1D 类型实例的 Amazon EBS 磁盘,Kubernetes 仅允许 25 个卷关联到节点。 * 对于 M5、C5、R5、T3 和 Z1D 类型实例的 Amazon EBS 磁盘,Kubernetes 仅允许 25 个卷关联到节点。
对于 ec2 上的其他实例类型 对于 ec2 上的其他实例类型
@@ -141,7 +141,7 @@ While a snapshot is being taken of a PersistentVolumeClaim, that PersistentVolum
--> -->
如果一个 PVC 正在被快照用来作为源进行快照创建,则该 PVC 是使用中的。如果用户删除正作为快照源的 PVC API 对象,则 PVC 对象不会立即被删除掉。相反,PVC 对象的删除将推迟到任何快照不在主动使用它为止。当快照的 `Status` 中的 `ReadyToUse`值为 `true` 时,PVC 将不再用作快照源。 如果一个 PVC 正在被快照用来作为源进行快照创建,则该 PVC 是使用中的。如果用户删除正作为快照源的 PVC API 对象,则 PVC 对象不会立即被删除掉。相反,PVC 对象的删除将推迟到任何快照不在主动使用它为止。当快照的 `Status` 中的 `ReadyToUse`值为 `true` 时,PVC 将不再用作快照源。
当从 `PersistentVolumeClaim` 中生成快照时,`PersistentVolumeClaim` 就在被使用了。如果删除一个作为快照源的 `PersistentVolumeClaim` 对象,这个 `PersistentVolumeClaim` 对象不会立即被删除的。相反,在快照可以被使用或者被放弃之后,才会执行删除 `PersistentVolumeClaim` 对象的动作。 当从 `PersistentVolumeClaim` 中生成快照时,`PersistentVolumeClaim` 就在被使用了。如果删除一个作为快照源的 `PersistentVolumeClaim` 对象,这个 `PersistentVolumeClaim` 对象不会立即被删除的。相反,删除 `PersistentVolumeClaim` 对象的动作会被放弃,或者推迟到快照的 Status 为 ReadyToUse时再执行
<!-- <!--
### Delete ### Delete
@@ -358,8 +358,8 @@ kubectl get events --sort-by=.metadata.creationTimestamp
<!-- ## Updating Resources --> <!-- ## Updating Resources -->
## 更新资源 ## 更新资源
<!-- As of version 1.11 `rolling-update` have been deprecated (see [CHANGELOG-1.11.md](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.11.md)), use `rollout` instead. --> <!-- As of version 1.11 `rolling-update` have been deprecated (see [CHANGELOG-1.11.md](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.11.md)), use `rollout` instead. -->
从版本 1.11 开始,`rolling-update` 已被弃用(参见 [CHANGELOG-1.11.md](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.11.md)),请使用 `rollout` 代替。 从版本 1.11 开始,`rolling-update` 已被弃用(参见 [CHANGELOG-1.11.md](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.11.md)),请使用 `rollout` 代替。
<!-- ```bash <!-- ```bash
kubectl set image deployment/frontend www=image:v2 # Rolling update "www" containers of "frontend" deployment, updating the image kubectl set image deployment/frontend www=image:v2 # Rolling update "www" containers of "frontend" deployment, updating the image
@@ -26,7 +26,7 @@ kubeadm 通过执行必要的操作来启动和运行一个最小可用的集群
<!-- * [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token) to manage tokens for `kubeadm join` --> <!-- * [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token) to manage tokens for `kubeadm join` -->
* [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token) 使用 `kubeadm join` 来管理令牌 * [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token) 使用 `kubeadm join` 来管理令牌
<!-- * [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset) to revert any changes made to this host by `kubeadm init` or `kubeadm join` --> <!-- * [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset) to revert any changes made to this host by `kubeadm init` or `kubeadm join` -->
* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset) 使用 `kubeadm init` 或者 `kubeadm join` 来恢复对节点的改变 * [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset) 还原之前使用 `kubeadm init` 或者 `kubeadm join` 对节点产生的改变
<!-- * [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version) to print the kubeadm version --> <!-- * [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version) to print the kubeadm version -->
* [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version) 打印出 kubeadm 版本 * [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version) 打印出 kubeadm 版本
<!-- * [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha) to preview a set of features made available for gathering feedback from the community --> <!-- * [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha) to preview a set of features made available for gathering feedback from the community -->
@@ -57,14 +57,14 @@ The upgrade workflow at high level is the following:
- You need to have a kubeadm Kubernetes cluster running version 1.16.0 or later. - You need to have a kubeadm Kubernetes cluster running version 1.16.0 or later.
- [Swap must be disabled](https://serverfault.com/questions/684771/best-way-to-disable-swap-in-linux). - [Swap must be disabled](https://serverfault.com/questions/684771/best-way-to-disable-swap-in-linux).
- The cluster should use a static control plane and etcd pods or external etcd. - The cluster should use a static control plane and etcd pods or external etcd.
- Make sure you read the [release notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.16.md) carefully. - Make sure you read the [release notes]({{< latest-release-notes >}}) carefully.
- Make sure to back up any important components, such as app-level state stored in a database. - Make sure to back up any important components, such as app-level state stored in a database.
`kubeadm upgrade` does not touch your workloads, only components internal to Kubernetes, but backups are always a best practice. `kubeadm upgrade` does not touch your workloads, only components internal to Kubernetes, but backups are always a best practice.
--> -->
- 您需要有一个由 `kubeadm` 创建并运行着 1.16.0 或更高版本的 Kubernetes 集群。 - 您需要有一个由 `kubeadm` 创建并运行着 1.16.0 或更高版本的 Kubernetes 集群。
- [禁用 Swap](https://serverfault.com/questions/684771/best-way-to-disable-swap-in-linux)。 - [禁用 Swap](https://serverfault.com/questions/684771/best-way-to-disable-swap-in-linux)。
- 集群应使用静态的控制平面和 etcd pod 或者 外部 etcd。 - 集群应使用静态的控制平面和 etcd pod 或者 外部 etcd。
- 务必仔细认真阅读[发行说明](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.16.md)。 - 务必仔细认真阅读[发行说明]({{< latest-release-notes >}})。
- 务必备份所有重要组件,例如存储在数据库中应用层面的状态。 - 务必备份所有重要组件,例如存储在数据库中应用层面的状态。
`kubeadm upgrade` 不会影响您的工作负载,只会涉及 Kubernetes 内部的组件,但备份终究是好的。 `kubeadm upgrade` 不会影响您的工作负载,只会涉及 Kubernetes 内部的组件,但备份终究是好的。
+1 -1
View File
@@ -13,7 +13,7 @@ other = "Цели"
other = "Очистка" other = "Очистка"
[prerequisites_heading] [prerequisites_heading]
other = режде чем вы начнете" other = одготовка к работе"
[whatsnext_heading] [whatsnext_heading]
other = "Что дальше" other = "Что дальше"
+2 -1
View File
@@ -14,6 +14,7 @@
<link href="https://cdn-images.mailchimp.com/embedcode/horizontal-slim-10_7.css" rel="stylesheet" type="text/css"> <link href="https://cdn-images.mailchimp.com/embedcode/horizontal-slim-10_7.css" rel="stylesheet" type="text/css">
<style type="text/css"> <style type="text/css">
#mc_embed_signup{clear:left; width:100%;} #mc_embed_signup{clear:left; width:100%;}
#mc_embed_signup .button, #mc_embed_signup input.email {margin-right:15px; vertical-align: bottom}
/* Add your own MailChimp form style overrides in your site stylesheet or in this style block. /* Add your own MailChimp form style overrides in your site stylesheet or in this style block.
We recommend moving this block and the preceding CSS link to the HEAD of your HTML file. */ We recommend moving this block and the preceding CSS link to the HEAD of your HTML file. */
</style> </style>
@@ -27,7 +28,7 @@
<input type="email" value="" name="EMAIL" class="email" id="mce-EMAIL" placeholder="email address" aria-label="email" required> <input type="email" value="" name="EMAIL" class="email" id="mce-EMAIL" placeholder="email address" aria-label="email" required>
<!-- real people should not fill this in and expect good things - do not remove this or risk form bot signups--> <!-- real people should not fill this in and expect good things - do not remove this or risk form bot signups-->
<div style="position: absolute; left: -5000px;" aria-hidden="true"><input type="text" name="b_3885586f8f1175194017967d6_11c1b8bcb2" tabindex="-1" value=""></div> <div style="position: absolute; left: -5000px;" aria-hidden="true"><input type="text" name="b_3885586f8f1175194017967d6_11c1b8bcb2" tabindex="-1" value=""></div>
<div class="clear" style="margin-left: 15px;"><input type="submit" value="Subscribe" name="subscribe" id="mc-embedded-subscribe" class="button"></div> <div class="clear"><input type="submit" value="Subscribe" name="subscribe" id="mc-embedded-subscribe" class="button"></div>
</div> </div>
</form> </form>
<h5 style="text-align: center"><a href="https://us10.campaign-archive.com/home/?u=3885586f8f1175194017967d6&id=11c1b8bcb2" aria-label="Kube Weekly" style="color: #3371E3; font-weight: 400; font-size: 20px">{{ T "main_kubeweekly_past_link" }}</a></h5> <h5 style="text-align: center"><a href="https://us10.campaign-archive.com/home/?u=3885586f8f1175194017967d6&id=11c1b8bcb2" aria-label="Kube Weekly" style="color: #3371E3; font-weight: 400; font-size: 20px">{{ T "main_kubeweekly_past_link" }}</a></h5>
@@ -0,0 +1,3 @@
{{- $latestVersion := site.Params.latest }}
{{- $latestReleaseNotes := print "https://git.k8s.io/kubernetes/CHANGELOG/CHANGELOG-" (replace $latestVersion "v" "") ".md" }}
{{- $latestReleaseNotes }}