From a3f977aaec05b09b5fe20c749703c7ece1e8546c Mon Sep 17 00:00:00 2001 From: Cheikhrouhou ines Date: Thu, 12 Sep 2019 21:58:31 +0200 Subject: [PATCH 01/19] translate service account fr --- .../configure-service-account.md | 288 ++++++++++++++++++ .../pods/pod-projected-svc-token.yaml | 20 ++ 2 files changed, 308 insertions(+) create mode 100644 content/fr/docs/tasks/configure-pod-container/configure-service-account.md create mode 100644 content/fr/examples/pods/pod-projected-svc-token.yaml diff --git a/content/fr/docs/tasks/configure-pod-container/configure-service-account.md b/content/fr/docs/tasks/configure-pod-container/configure-service-account.md new file mode 100644 index 0000000000..c90a7de585 --- /dev/null +++ b/content/fr/docs/tasks/configure-pod-container/configure-service-account.md @@ -0,0 +1,288 @@ +--- +title: Configurer les comptes de service pour les pods +content_template: templates/task +weight: 90 +--- + +{{% capture overview %}} +Un compte de service fournit une identité pour les processus qui s'exécutent dans un Pod. + +*Ceci est une introduction aux comptes de service pour les utilisateurs. Voir aussi +[Guide de l'administrateur du cluster des comptes de service](/docs/reference/access-authn-authz/service-accounts-admin/).* + +{{< note >}} +Ce document décrit le comportement des comptes de service dans un cluster mis en place conformément aux recommandations du projet Kubernetes. L'administrateur de votre cluster a peut-être personnalisé le comportement dans votre cluster, dans ce cas cette documentation pourrait être non applicable. +{{< /note >}} + +Lorsque vous (un humain) accédez au cluster (par exemple, en utilisant `kubectl`), vous êtes +authentifié par l'apiserver en tant que compte d'utilisateur particulier (actuellement, il s'agit +généralement de l'utilisateur `admin`, à moins que votre administrateur de cluster n'ait personnalisé votre cluster).Les processus dans les conteneurs dans les pods peuvent également contacter l'apiserver. Dans ce cas, ils sont authentifiés en tant que compte de service particulier (par exemple, `default`). + +{{% /capture %}} + + +{{% capture prerequisites %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +{{% /capture %}} + +{{% capture steps %}} + +## Utiliser le compte de service par défaut pour accéder au API server. + +Si vous obtenez le raw json ou yaml pour un pod que vous avez créé (par exemple, `kubectl get pods/ -o yaml`), vous pouvez voir que le champ `spec.serviceAccountName` a été [automatiquement assigné](/docs/user-guide/working-with-resources/#resources-are-automatically-modified). + +Vous pouvez accéder à l'API depuis l'intérieur d'un pod en utilisant les identifiants de compte de service montés automatiquement, comme décrit dans [Accès au cluster](/docs/user-guide/accessing-the-cluster/#accessing-the-api-from-a-pod). +Les permissions API du compte de service dépendent du [plugin d'autorisation et de la politique](/docs/reference/access-authn-authz/authorization/#authorization-modules) en usage. + +Dans la version 1.6+, vous pouvez choisir de ne pas utiliser le montage automatique des identifiants API pour un compte de service en définissant `automountServiceAccountToken : false` sur le compte de service : + +```yaml +apiVersion: v1 +kind: ServiceAccount +metadata: + name: build-robot +automountServiceAccountToken: false +... +``` + +Dans la version 1.6+, vous pouvez également choisir de ne pas monter automatiquement les identifiants API pour un pod particulier : + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: my-pod +spec: + serviceAccountName: build-robot + automountServiceAccountToken: false + ... +``` + +La spéc de pod a prépondérance par rapport au compte de service si les deux spécifient la valeur `automountServiceAccountToken`. + +## Utiliser plusieurs comptes de services. + +Chaque namespace possède une ressource de compte de service par défaut appelée `default`. +Vous pouvez lister cette ressource et toutes les autres ressources de serviceAccount dans le namespace avec cette commande : + +```shell +kubectl get serviceAccounts +``` +La sortie est comme la suivante : + +``` +NAME SECRETS AGE +default 1 1d +``` + +Vous pouvez créer des objets ServiceAccount supplémentaires comme ceci : + +```shell +kubectl apply -f - < +Annotations: kubernetes.io/service-account.name=build-robot + kubernetes.io/service-account.uid=da68f9c6-9d26-11e7-b84e-002dc52800da + +Type: kubernetes.io/service-account-token + +Data +==== +ca.crt: 1338 bytes +namespace: 7 bytes +token: ... +``` + +{{< note >}} +Le contenu de `token` est éludé ici. +{{< /note >}} + +## Ajouter ImagePullSecrets à un compte de service + +Tout d'abord, créez un imagePullSecret, comme décrit [ici](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod). +Puis, vérifiez qu'il a été créé. Par exemple : + +```shell +kubectl get secrets myregistrykey +``` + +La sortie est comme la suivante : + +``` +NAME TYPE DATA AGE +myregistrykey   kubernetes.io/.dockerconfigjson   1       1d +``` + +Ensuite, modifiez le compte de service par défaut du namespace pour utiliser ce secret comme un imagePullSecret. + +```shell +kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "myregistrykey"}]}' +``` + +La version interactive nécessite un traitement manuel : + +```shell +kubectl get serviceaccounts default -o yaml > ./sa.yaml +``` + +La sortie du fichier `sa.yaml` est similaire à celle-ci : + +```shell +apiVersion: v1 +kind: ServiceAccount +metadata: + creationTimestamp: 2015-08-07T22:02:39Z + name: default + namespace: default + resourceVersion: "243024" + selfLink: /api/v1/namespaces/default/serviceaccounts/default + uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6 +secrets: +- name: default-token-uudge +``` + +En utilisant l'éditeur de votre choix (par exemple `vi`), ouvrez le fichier `sa.yaml`, supprimez la ligne avec la clé `resourceVersion`, ajouter les lignes avec `imagePullSecrets:` et sauvegarder. + +La sortie du fichier `sa.yaml` est similaire à celle-ci : + +```shell +apiVersion: v1 +kind: ServiceAccount +metadata: + creationTimestamp: 2015-08-07T22:02:39Z + name: default + namespace: default + selfLink: /api/v1/namespaces/default/serviceaccounts/default + uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6 +secrets: +- name: default-token-uudge +imagePullSecrets: +- name: myregistrykey +``` + +Enfin, remplacez le compte de service par le nouveau fichier `sa.yaml` mis à jour. + +```shell +kubectl replace serviceaccount default -f ./sa.yaml +``` + +Maintenant, tous les nouveaux pods créés dans le namespace courant auront ceci ajouté à leurs spécifications : + +```yaml +spec: + imagePullSecrets: + - name: myregistrykey +``` + + + +## Projection du volume des tokens de compte de service + +{{< feature-state for_k8s_version="v1.12" state="beta" >}} + +{{< note >}} +Ce ServiceAccountTokenVolumeProjection est __beta__ en 1.12 et +activé en passant tous les paramètres suivants au serveur API : + +* `--service-account-issuer` +* `--service-account-signing-key-file` +* `--service-account-api-audiences` + +{{< /note >}} + +Le kubelet peut également projeter un token de compte de service dans un Pod. Vous pouvez spécifier les propriétés souhaitées du token, telles que l'audience et la durée de validité. +Ces propriétés ne sont pas configurables sur le compte de service par défaut. Le token de compte de service devient également invalide par l'API lorsque le Pod ou le ServiceAccount est supprimé + +Ce comportement est configuré sur un PodSpec utilisant un type de ProjectedVolume appelé +[ServiceAccountToken](/docs/concepts/storage/volumes/#projected). Pour fournir un +pod avec un token avec une audience de "vault" et une durée de validité de deux heures, vous devriez configurer ce qui suit dans votre PodSpec : + +{{< codenew file="pods/pod-projected-svc-token.yaml" >}} + +Créez le pod + +```shell +kubectl create -f https://k8s.io/examples/pods/pod-projected-svc-token.yaml +``` + +Le kubelet demandera et stockera le token a la place du pod, rendra le token disponible pour le pod à un chemin d'accès configurable, et rafraîchissez le token à l'approche de son expiration. Kubelet fait tourner le token de manière proactive s'il est plus vieux que 80% de son TTL total, ou si le token est plus vieux que 24 heures. + +L'application est responsable du rechargement du token lorsqu'il tourne. Un rechargement périodique (par ex. toutes les 5 minutes) est suffisant pour la plupart des cas d'utilisation. + +{{% /capture %}} diff --git a/content/fr/examples/pods/pod-projected-svc-token.yaml b/content/fr/examples/pods/pod-projected-svc-token.yaml new file mode 100644 index 0000000000..985073c8d3 --- /dev/null +++ b/content/fr/examples/pods/pod-projected-svc-token.yaml @@ -0,0 +1,20 @@ +apiVersion: v1 +kind: Pod +metadata: + name: nginx +spec: + containers: + - image: nginx + name: nginx + volumeMounts: + - mountPath: /var/run/secrets/tokens + name: vault-token + serviceAccountName: build-robot + volumes: + - name: vault-token + projected: + sources: + - serviceAccountToken: + path: vault-token + expirationSeconds: 7200 + audience: vault From eab4f2199e6c8170fbb3bc9a7f175e8f9fd91be8 Mon Sep 17 00:00:00 2001 From: Enrique Medina Montenegro Date: Wed, 12 Jun 2019 16:47:44 +0200 Subject: [PATCH 02/19] Spanish Translation --- .../workloads/controllers/deployment.md | 1110 +++++++++++++++++ .../controllers/garbage-collection.md | 183 +++ .../controllers/nginx-deployment.yaml | 21 + .../es/examples/controllers/replicaset.yaml | 17 + 4 files changed, 1331 insertions(+) create mode 100644 content/es/docs/concepts/workloads/controllers/deployment.md create mode 100644 content/es/docs/concepts/workloads/controllers/garbage-collection.md create mode 100644 content/es/examples/controllers/nginx-deployment.yaml create mode 100644 content/es/examples/controllers/replicaset.yaml diff --git a/content/es/docs/concepts/workloads/controllers/deployment.md b/content/es/docs/concepts/workloads/controllers/deployment.md new file mode 100644 index 0000000000..6a717481f7 --- /dev/null +++ b/content/es/docs/concepts/workloads/controllers/deployment.md @@ -0,0 +1,1110 @@ +--- +title: Despliegues +feature: + title: Despliegues y retrocesiones automáticos + description: > + Kubernetes despliega los cambios a tu aplicación o su configuración de forma progresiva mientras monitoriza la salud de la aplicación para asegurarse que no elimina todas tus instancias al mismo tiempo. Si algo sale mal, Kubernetes retrocederá el cambio por ti. Aprovéchate del creciente ecosistema de soluciones de despliegue. + +content_template: templates/concept +weight: 30 +--- + +{{% capture overview %}} + +Un controlador de _Deployment_ proporciona actualizaciones declarativas para los [Pods](/docs/concepts/workloads/pods/pod/) y los +[ReplicaSets](/docs/concepts/workloads/controllers/replicaset/). + +Cuando describes el _estado deseado_ en un objeto Deployment, el controlador del Deployment se encarga de cambiar el estado actual al estado deseado de forma controlada. +Puedes definir Deployments para crear nuevos ReplicaSets, o eliminar Deployments existentes y adoptar todos sus recursos con nuevos Deployments. + +{{< note >}} +No deberías gestionar directamente los ReplicaSets que pertenecen a un Deployment. +Todos los casos de uso deberían cubrirse manipulando el objeto Deployment. +Considera la posibilidad de abrir un incidente en el repositorio principal de Kubernetes si tu caso de uso no está soportado por el motivo que sea. +{{< /note >}} + +{{% /capture %}} + + +{{% capture body %}} + +## Casos de uso + +A continuación se presentan los casos de uso típicos de los Deployments: + +* [Crear un Deployment para desplegar un ReplicaSet](#creating-a-deployment). El ReplicaSet crea los Pods en segundo plano. Comprueba el estado del despliegue para comprobar si es satisfactorio o no. +* [Declarar el nuevo estado de los Pods](#updating-a-deployment) actualizando el PodTemplateSpec del Deployment. Ello crea un nuevo ReplicaSet y el Deployment gestiona el cambio de los Pods del viejo ReplicaSet al nuevo de forma controlada. Cada nuevo ReplicaSet actualiza la revisión del Deployment. +* [Retroceder a una revisión anterior del Deployment](#rolling-back-a-deployment) si el estado actual de un Deployment no es estable. Cada retroceso actualiza la revisión del Deployment. +* [Escalar horizontalmente el Deployment para soportar más carga](#scaling-a-deployment). +* [Pausar el Deployment](#pausing-and-resuming-a-deployment) para aplicar múltiples arreglos a su PodTemplateSpec y, a continuación, reanúdalo para que comience un nuevo despliegue. +* [Usar el estado del Deployment](#deployment-status) como un indicador de que el despliegue se ha atascado. +* [Limpiar los viejos ReplicaSets](#clean-up-policy) que no necesites más. + +## Crear un Deployment + +El siguiente ejemplo de un Deployment crea un ReplicaSet para arrancar tres Pods con `nginx`: + +{{< codenew file="controllers/nginx-deployment.yaml" >}} + +En este ejemplo: + +* Se crea un Deployment denominado `nginx-deployment`, indicado a través del campo `.metadata.name`. +* El Deployment crea tres Pods replicados, indicado a través del campo `replicas`. +* El campo `selector` define cómo el Deployment identifica los Pods que debe gestionar. + En este caso, simplemente seleccionas una etiqueta que se define en la plantilla Pod (`app: nginx`). + Sin embargo, es posible definir reglas de selección más sofisticadas, + siempre que la plantilla Pod misma satisfaga la regla. + + {{< note >}} + `matchLabels` es un mapa de entradas {clave,valor}. Una entrada simple {clave,valor} en el mapa `matchLabels` + es equivalente a un elemento de `matchExpressions` cuyo campo sea la "clave", el operador sea "In", + y la matriz de valores contenga únicamente un "valor". Todos los requisitos se concatenan con AND. + {{< /note >}} + +* El campo `template` contiene los siguientes sub-campos: + * Los Pods se etiquetan como `app: nginx` usando el campo `labels`. + * La especificación de la plantilla Pod, o el campo `.template.spec`, indica + que los Pods ejecutan un contenedor, `nginx`, que utiliza la versión 1.7.9 de la imagen de `nginx` de + [Docker Hub](https://hub.docker.com/). + * Crea un contenedor y lo llamar `nginx` usando el campo `name`. + * Ejecuta la imagen `nginx` en su versión `1.7.9`. + * Abre el puerto `80` para que el contenedor pueda enviar y recibir tráfico. + +Para crear este Deployment, ejecuta el siguiente comando: + +```shell +kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml +``` + +{{< note >}} +Debes indicar el parámetro `--record` para registrar el comando ejecutado en la anotación de recurso `kubernetes.io/change-cause`. +Esto es útil para futuras introspecciones, por ejemplo para comprobar qué comando se ha ejecutado en cada revisión del Deployment. +{{< /note >}} + +A continuación, ejecuta el comando `kubectl get deployments`. La salida debe ser parecida a la siguiente: + +```shell +NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE +nginx-deployment 3 0 0 0 1s +``` + +Cuando inspeccionas los Deployments de tu clúster, se muestran los siguientes campos: + +* `NAME` enumera los nombre de los Deployments del clúster. +* `DESIRED` muestra el número deseado de _réplicas_ de la aplicación, que se define + cuando se crea el Deployment. Esto se conoce como el _estado deseado_. +* `CURRENT` muestra cuántas réplicas se están ejecutando actualment. +* `UP-TO-DATE` muestra el número de réplicas que se ha actualizado para alcanzar el estado deseado. +* `AVAILABLE` muestra cuántas réplicas de la aplicación están disponibles para los usuarios. +* `AGE` muestra la cantidad de tiempo que la aplicación lleva ejecutándose. + +Nótese cómo los valores de cada campo corresponden a los valores de la especificación del Deployment: + +* El número de réplicas deseadas es 3 de acuerdo con el campo `.spec.replicas`. +* El número de réplicas actuales es 0 de acuerdo con el campo `.status.replicas`. +* El número de réplicas actualizadas es 0 de acuerdo con el campo `.status.updatedReplicas`. +* El número de réplicas disponibles es 0 de acuerdo con el campo `.status.availableReplicas`. + +Para ver el estado del Deployment, ejecuta el comando `kubectl rollout status deployment.v1.apps/nginx-deployment`. Este comando devuelve el siguiente resultado: + +```shell +Waiting for rollout to finish: 2 out of 3 new replicas have been updated... +deployment.apps/nginx-deployment successfully rolled out +``` + +Ejecuta de nuevo el comando `kubectl get deployments` unos segundos más tarde: + +```shell +NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE +nginx-deployment 3 3 3 3 18s +``` + +Fíjate que el Deployment ha creado todas las tres réplicas, y que todas las réplicas están actualizadas (contienen +la última plantilla Pod) y están disponibles (el estado del Pod tiene el valor Ready al menos para el campo `.spec.minReadySeconds` del Deployment). + +Para ver el ReplicaSet (`rs`) creado por el Deployment, ejecuta el comando `kubectl get rs`: + +```shell +NAME DESIRED CURRENT READY AGE +nginx-deployment-75675f5897 3 3 3 18s +``` + +Fíjate que el nombre del ReplicaSet siempre se formatea con el patrón `[DEPLOYMENT-NAME]-[RANDOM-STRING]`. La cadena aleatoria se +genera de forma aleatoria y usa el pod-template-hash como semilla. + +Para ver las etiquetas generadas automáticamente en cada pod, ejecuta el comando `kubectl get pods --show-labels`. Se devuelve la siguiente salida: + +```shell +NAME READY STATUS RESTARTS AGE LABELS +nginx-deployment-75675f5897-7ci7o 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453 +nginx-deployment-75675f5897-kzszj 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453 +nginx-deployment-75675f5897-qqcnn 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453 +``` + +El ReplicaSet creado garantiza que hay tres Pods de `nginx` ejecutándose en todo momento. + +{{< note >}} +En un Deployment, debes especificar un selector apropiado y etiquetas de plantilla Pod (en este caso, +`app: nginx`). No entremezcles etiquetas o selectores con otros controladores (incluyendo otros Deployments y StatefulSets). +Kubernetes no te impide que lo hagas, pero en el caso de que múltiples controladores tengan selectores mezclados, dichos controladores pueden entrar en conflicto y provocar resultados inesperados. +{{< /note >}} + +### Etiqueta pod-template-hash + +{{< note >}} +No cambies esta etiqueta. +{{< /note >}} + +La etiqueta `pod-template-hash` es añadida por el controlador del Deployment a cada ReplicaSet que el Deployment crea o adopta. + +Esta etiqueta garantiza que todos los hijos ReplicaSets de un Deployment no se entremezclan. Se genera mediante una función hash aplicada al `PodTemplate` del ReplicaSet +y usando el resultado de la función hash como el valor de la etiqueta que se añade al selector del ReplicaSet, en las etiquetas de la plantilla Pod, +y en cualquier Pod existente que el ReplicaSet tenga. + +## Actualizar un Deployment + +{{< note >}} +El lanzamiento de un Deployment se activa si y sólo si la plantilla Pod del Deployment (esto es, `.spec.template`) +se cambia, por ejemplo si se actualiza las etiquetas o las imágenes de contenedor de la plantilla. +Otras actualizaciones, como el escalado del Deployment, no conllevan un lanzamiento de despliegue. +{{< /note >}} + +Asumiendo que ahora quieres actualizar los Pods nginx para que usen la imagen `nginx:1.9.1` +en vez de la imagen `nginx:1.7.9`. + +```shell +kubectl --record deployment.apps/nginx-deployment set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 +``` +``` +image updated +``` + +De forma alternativa, puedes `editar` el Deployment y cambiar el valor del campo `.spec.template.spec.containers[0].image` de `nginx:1.7.9` a `nginx:1.9.1`: + +```shell +kubectl edit deployment.v1.apps/nginx-deployment +``` +``` +deployment.apps/nginx-deployment edited +``` + +Para ver el estado del despliegue, ejecuta: + +```shell +kubectl rollout status deployment.v1.apps/nginx-deployment +``` +``` +Waiting for rollout to finish: 2 out of 3 new replicas have been updated... +deployment.apps/nginx-deployment successfully rolled out +``` + +Cuando el despliegue funciona, puede que quieras `obtener` el Deployment: + +```shell +kubectl get deployments +``` +``` +NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE +nginx-deployment 3 3 3 3 36s +``` + +El número de réplicas actualizadas indica que el Deployment ha actualizado las réplicas según la última configuración. +Las réplicas actuales indican el total de réplicas que gestiona este Deployment, y las réplicas disponibles indican +el número de réplicas actuales que están disponibles. + +Puedes ejecutar el comando `kubectl get rs` para ver que el Deployment actualizó los Pods creando un nuevo ReplicaSet y escalándolo +hasta las 3 réplicas, así como escalando el viejo ReplicaSet a 0 réplicas. + +```shell +kubectl get rs +``` +``` +NAME DESIRED CURRENT READY AGE +nginx-deployment-1564180365 3 3 3 6s +nginx-deployment-2035384211 0 0 0 36s +``` + +Si ejecutas el comando `get pods` deberías ver los nuevos Pods: + +```shell +kubectl get pods +``` +``` +NAME READY STATUS RESTARTS AGE +nginx-deployment-1564180365-khku8 1/1 Running 0 14s +nginx-deployment-1564180365-nacti 1/1 Running 0 14s +nginx-deployment-1564180365-z9gth 1/1 Running 0 14s +``` + +La próxima vez que quieras actualizar estos Pods, sólo necesitas actualizar la plantilla Pod del Deployment otra vez. + +El Deployment permite garantizar que sólo un número determinado de Pods puede eliminarse mientras se están actualizando. +Por defecto, garantiza que al menos el 25% menos del número deseado de Pods se está ejecutando (máx. 25% no disponible). + +El Deployment tmabién permite garantizar que sólo un número determinado de Pods puede crearse por encima del número deseado de +Pods. Por defecto, garantiza que al menos el 25% más del número deseado de Pods se está ejecutando (máx. 25% de aumento). + +Por ejemplo, si miras detenidamente el Deployment de arriba, verás que primero creó un Pod, +luego eliminó algunos viejos Pods y creó otros nuevos. No elimina los viejos Pods hasta que un número suficiente de +nuevos Pods han arrancado, y no crea nuevos Pods hasta que un número suficiente de viejos Pods se han eliminado. +De esta forma, asegura que el número de Pods disponibles siempre es al menos 2, y el número de Pods totales es cómo máximo 4. + +```shell +kubectl describe deployments +``` +``` +Name: nginx-deployment +Namespace: default +CreationTimestamp: Thu, 30 Nov 2017 10:56:25 +0000 +Labels: app=nginx +Annotations: deployment.kubernetes.io/revision=2 +Selector: app=nginx +Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable +StrategyType: RollingUpdate +MinReadySeconds: 0 +RollingUpdateStrategy: 25% max unavailable, 25% max surge +Pod Template: + Labels: app=nginx + Containers: + nginx: + Image: nginx:1.9.1 + Port: 80/TCP + Environment: + Mounts: + Volumes: +Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing True NewReplicaSetAvailable +OldReplicaSets: +NewReplicaSet: nginx-deployment-1564180365 (3/3 replicas created) +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal ScalingReplicaSet 2m deployment-controller Scaled up replica set nginx-deployment-2035384211 to 3 + Normal ScalingReplicaSet 24s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 1 + Normal ScalingReplicaSet 22s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 2 + Normal ScalingReplicaSet 22s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 2 + Normal ScalingReplicaSet 19s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 1 + Normal ScalingReplicaSet 19s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 3 + Normal ScalingReplicaSet 14s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 0 +``` + +Aquí puedes ver que cuando creaste por primera vez el Deployment, este creó un ReplicaSet (nginx-deployment-2035384211) +y lo escaló a 3 réplicas directamente. Cuando actualizaste el Deployment, creó un nuevo ReplicaSet +(nginx-deployment-1564180365) y lo escaló a 1 y entonces escaló el viejo ReplicaSet a 2, de forma que al menos +hubiera 2 Pods disponibles y como mucho 4 Pods en total en todo momento. Entonces, continuó escalando +el nuevo y el viejo ReplicaSet con la misma estrategia de actualización continua. Finalmente, el nuevo ReplicaSet acaba con 3 réplicas +disponibles, y el viejo ReplicaSet se escala a 0. + +### Sobrescritura (o sea, múltiples actualizaciones a la vez) + +Cada vez que el controlador del Deployment observa un nuevo objeto de despliegue, se crea un ReplicaSet para arrancar +los Pods deseados si es que no existe otro ReplicaSet haciéndolo. Los ReplicaSet existentes que controlan los Pods cuyas etiquetas +coinciden con el valor del campo `.spec.selector`, pero cuya plantilla no coincide con el valor del campo `.spec.template` se reducen. Al final, +el nuevo ReplicaSet se escala hasta el valor del campo `.spec.replicas` y todos los viejos ReplicaSets se escalan a 0. + +Si actualizas un Deployment mientras otro despliegue está en curso, el Deployment creará un nuevo ReplicaSet +como consecuencia de la actualización y comenzará a escalarlo, y sobrescribirá al ReplicaSet que estaba escalando anteriormente + -- lo añadirá a su lista de viejos ReplicaSets y comenzará a reducirlos. + +Por ejemplo, supongamos que creamos un Deployment para crear 5 réplicas de `nginx:1.7.9`, +pero entonces actualizamos el Deployment para crear 5 réplicas de `nginx:1.9.1` cuando sólo se ha creado 3 +réplicas de `nginx:1.7.9`. En este caso, el Deployment comenzará automáticamente a matar los 3 Pods de `nginx:1.7.9` +que había creado, y empezará a crear los Pods de `nginx:1.9.1`. Es decir, no esperará a que se creen las 5 réplicas de `nginx:1.7.9` +antes de aplicar la nueva configuración. + +### Actualizaciones del selector de etiquetas + +No se recomienda hacer cambios al selector del etiquetas y, por ello, se aconseja encarecidamente planificar el valor de dichos selectores por adelantado. +En cualquier caso, si necesitas cambiar un selector de etiquetas, hazlo con mucho cuidado y asegúrate que entiendes todas sus implicaciones. + +{{< note >}} +En la versión `apps/v1` de la API, el selector de etiquetas del Deployment es inmutable una vez se ha creado. +{{< /note >}} + +* Las adiciones posteriores al selector obligan también a actualizar las etiquetas de la plantilla Pod en la especificación del Deployment con los nuevos valores, +ya que de lo contrario se devolvería un error. Este cambio no es de superposición, es decir, que el nuevo selector +no selecciona los ReplicaSets y Pods creados con el viejo selector, lo que provoca que todos los viejos ReplicaSets se marquen como huérfanos y +la creación de un nuevo ReplicaSet. +* Las actualizaciones de selector -- esto es, cambiar el valor actual en una clave de selector -- provocan el mismo comportamiento que las adiciones. +* Las eliminaciones de selector -- esto es, eliminar una clave actual del selector del Deployment -- no necesitan de cambios en las etiquetas de la plantilla Pod. +No se marca ningún ReplicaSet existente como huérfano, y no se crea ningún ReplicaSet nuevo, pero debe tenerse en cuenta que +la etiqueta eliminada todavía existe en los Pods y ReplicaSets que se están ejecutando. + +## Retroceder un Deployment + +En ocasiones necesitas retroceder un Deployment; por ejemplo, cuando el Deployment no es estable, como cuando no para de reiniciarse. +Por defecto, toda la historia de despliegue del Deployment se mantiene en el sistema de forma que puedes retroceder en cualquier momento +(se puede modificar este comportamiento cambiando el límite de la historia de revisiones de modificaciones). + +{{< note >}} +Cuando se lanza el despligue de un Deployment, se crea una nueva revisión. Esto quiere decir que +la nueva revisión se crea si y sólo si la plantilla Pod del Deployment (`.spec.template`) se cambia; +por ejemplo, si cambias las etiquetas o la imagen del contenedor de la plantilla. +Otras actualizaciones, como escalar el Deployment, +no generan una nueva revisión del Deployment, para poder facilitar el escalado manual simultáneo - o auto-escalado. +Esto significa que cuando retrocedes a una versión anterior, sólo la parte de la plantilla Pod del Deployment se retrocede. +{{< /note >}} + +Vamos a suponer que hemos cometido un error al actualizar el Deployment, poniendo como nombre de imagen `nginx:1.91` en vez de `nginx:1.9.1`: + +```shell +kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.91 --record=true +``` +``` +deployment.apps/nginx-deployment image updated +``` + +El despliegue se atasca y no progresa. + +```shell +kubectl rollout status deployment.v1.apps/nginx-deployment +``` +``` +Waiting for rollout to finish: 1 out of 3 new replicas have been updated... +``` + +Presiona Ctrl-C para detener la monitorización del despliegue de arriba. Para obtener más información sobre despliegues atascados, +[lee más aquí](#deployment-status). + +Verás que el número de réplicas viejas (nginx-deployment-1564180365 y nginx-deployment-2035384211) es 2, y el número de nuevas réplicas (nginx-deployment-3066724191) es 1. + +```shell +kubectl get rs +``` +``` +NAME DESIRED CURRENT READY AGE +nginx-deployment-1564180365 3 3 3 25s +nginx-deployment-2035384211 0 0 0 36s +nginx-deployment-3066724191 1 1 0 6s +``` + +Echando un vistazo a los Pods creados, verás que uno de los Pods creados por el nuevo ReplicaSet está atascado en un bucle intentando bajar la imagen: + +```shell +kubectl get pods +``` +``` +NAME READY STATUS RESTARTS AGE +nginx-deployment-1564180365-70iae 1/1 Running 0 25s +nginx-deployment-1564180365-jbqqo 1/1 Running 0 25s +nginx-deployment-1564180365-hysrc 1/1 Running 0 25s +nginx-deployment-3066724191-08mng 0/1 ImagePullBackOff 0 6s +``` + +{{< note >}} +El controlador del Deployment parará el despliegue erróneo de forma automática, y detendrá el escalado del nuevo +ReplicaSet. Esto depende de los parámetros del rollingUpdate (`maxUnavailable` específicamente) que hayas configurado. +Kubernetes por defecto establece el valor en el 25%. +{{< /note >}} + +```shell +kubectl describe deployment +``` +``` +Name: nginx-deployment +Namespace: default +CreationTimestamp: Tue, 15 Mar 2016 14:48:04 -0700 +Labels: app=nginx +Selector: app=nginx +Replicas: 3 desired | 1 updated | 4 total | 3 available | 1 unavailable +StrategyType: RollingUpdate +MinReadySeconds: 0 +RollingUpdateStrategy: 25% max unavailable, 25% max surge +Pod Template: + Labels: app=nginx + Containers: + nginx: + Image: nginx:1.91 + Port: 80/TCP + Host Port: 0/TCP + Environment: + Mounts: + Volumes: +Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing True ReplicaSetUpdated +OldReplicaSets: nginx-deployment-1564180365 (3/3 replicas created) +NewReplicaSet: nginx-deployment-3066724191 (1/1 replicas created) +Events: + FirstSeen LastSeen Count From SubobjectPath Type Reason Message + --------- -------- ----- ---- ------------- -------- ------ ------- + 1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-2035384211 to 3 + 22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 1 + 22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 2 + 22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 2 + 21s 21s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 1 + 21s 21s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 3 + 13s 13s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 0 + 13s 13s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-3066724191 to 1 +``` + +Para arreglar este problema, necesitas retroceder a una revisión previa del Deployment que sea estable. + +### Comprobar la Historia de Despliegues de un Deployment + +Primero, comprobemos las revisiones de este despliegue: + +```shell +kubectl rollout history deployment.v1.apps/nginx-deployment +``` +``` +deployments "nginx-deployment" +REVISION CHANGE-CAUSE +1 kubectl apply --filename=https://k8s.io/examples/controllers/nginx-deployment.yaml --record=true +2 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true +3 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.91 --record=true +``` +En el momento de la creación, el mensaje en `CHANGE-CAUSE` se copia de la anotación `kubernetes.io/change-cause` del Deployment a sus revisiones. Podrías indicar el mensaje `CHANGE-CAUSE`: + +* Anotando el Deployment con el comando `kubectl annotate deployment.v1.apps/nginx-deployment kubernetes.io/change-cause="image updated to 1.9.1"` +* Añadiendo el parámetro `--record` para registrar el comando `kubectl` que está haciendo cambios en el recurso. +* Manualmente editando el manifiesto del recursos. + +Para ver más detalles de cada revisión, ejecuta: + +```shell +kubectl rollout history deployment.v1.apps/nginx-deployment --revision=2 +``` +``` +deployments "nginx-deployment" revision 2 + Labels: app=nginx + pod-template-hash=1159050644 + Annotations: kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true + Containers: + nginx: + Image: nginx:1.9.1 + Port: 80/TCP + QoS Tier: + cpu: BestEffort + memory: BestEffort + Environment Variables: + No volumes. +``` + +### Retroceder a una Revisión Previa + +Ahora has decidido que quieres deshacer el despliegue actual y retrocederlo a la revisñion previa: + +```shell +kubectl rollout undo deployment.v1.apps/nginx-deployment +``` +``` +deployment.apps/nginx-deployment +``` + +Alternativamente, puedes retroceder a una revisión específica con el parámetro `--to-revision`: + +```shell +kubectl rollout undo deployment.v1.apps/nginx-deployment --to-revision=2 +``` +``` +deployment.apps/nginx-deployment +``` + +Para más detalles acerca de los comandos relacionados con el retroceso de revisiones, echa un vistazo a [`kubectl rollout`](/docs/reference/generated/kubectl/kubectl-commands#rollout). + +El Deployment se ha retrocedido ahora a una revisión previa estable. Como se puede comprobar, el controlador del Deployment genera un evento `DeploymentRollback` +al retroceder a la revisión 2. + +```shell +kubectl get deployment nginx-deployment +``` +``` +NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE +nginx-deployment 3 3 3 3 30m +``` + +```shell +kubectl describe deployment nginx-deployment +``` +``` +Name: nginx-deployment +Namespace: default +CreationTimestamp: Sun, 02 Sep 2018 18:17:55 -0500 +Labels: app=nginx +Annotations: deployment.kubernetes.io/revision=4 + kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true +Selector: app=nginx +Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable +StrategyType: RollingUpdate +MinReadySeconds: 0 +RollingUpdateStrategy: 25% max unavailable, 25% max surge +Pod Template: + Labels: app=nginx + Containers: + nginx: + Image: nginx:1.9.1 + Port: 80/TCP + Host Port: 0/TCP + Environment: + Mounts: + Volumes: +Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing True NewReplicaSetAvailable +OldReplicaSets: +NewReplicaSet: nginx-deployment-c4747d96c (3/3 replicas created) +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal ScalingReplicaSet 12m deployment-controller Scaled up replica set nginx-deployment-75675f5897 to 3 + Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-c4747d96c to 1 + Normal ScalingReplicaSet 11m deployment-controller Scaled down replica set nginx-deployment-75675f5897 to 2 + Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-c4747d96c to 2 + Normal ScalingReplicaSet 11m deployment-controller Scaled down replica set nginx-deployment-75675f5897 to 1 + Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-c4747d96c to 3 + Normal ScalingReplicaSet 11m deployment-controller Scaled down replica set nginx-deployment-75675f5897 to 0 + Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-595696685f to 1 + Normal DeploymentRollback 15s deployment-controller Rolled back deployment "nginx-deployment" to revision 2 + Normal ScalingReplicaSet 15s deployment-controller Scaled down replica set nginx-deployment-595696685f to 0 +``` + +## Escalar un Deployment + +Puedes escalar un Deployment usando el siguiente comando: + +```shell +kubectl scale deployment.v1.apps/nginx-deployment --replicas=10 +``` +``` +deployment.apps/nginx-deployment scaled +``` + +Asumiendo que se ha habilitado el [escalado horizontal de pod](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) +en tu clúster, puedes configurar un auto-escalado para tu Deployment y elegir el mínimo y máximo número de Pods +que quieres ejecutar en base al uso de CPU de tus Pods actuales. + +```shell +kubectl autoscale deployment.v1.apps/nginx-deployment --min=10 --max=15 --cpu-percent=80 +``` +``` +deployment.apps/nginx-deployment scaled +``` + +### Escalado proporcional + +La actualización continua de los Deployments permite la ejecución de múltiples versiones de una aplicación al mismo tiempo. +Cuando tú o un auto-escalado escala un Deployment con actualización continua que está en medio de otro despliegue (bien en curso o pausado), +entonces el controlador del Deployment balanceará las réplicas adicionales de los ReplicaSets activos (ReplicaSets con Pods) +para así poder mitigar el riesgo. Esto se conoce como *escalado proporcional*. + +Por ejemplo, imagina que estás ejecutando un Deployment con 10 réplicas, donde [maxSurge](#max-surge)=3, y [maxUnavailable](#max-unavailable)=2. + +```shell +kubectl get deploy +``` +``` +NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE +nginx-deployment 10 10 10 10 50s +``` + +Si actualizas a una nueva imagen que no puede descargarse desde el clúster: + +```shell +kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:sometag +``` +``` +deployment.apps/nginx-deployment image updated +``` + +La actualización de la imagen arranca un nuevo despliegue con el ReplicaSet nginx-deployment-1989198191, +pero se bloquea debido al requisito `maxUnavailable` indicado arriba: + +```shell +kubectl get rs +``` +``` +NAME DESIRED CURRENT READY AGE +nginx-deployment-1989198191 5 5 0 9s +nginx-deployment-618515232 8 8 8 1m +``` + +Y entonces se origina una nueva petición de escalado para el Deployment. El auto-escalado incrementa las réplicas del Deployment +a 15. El controlador del Deployment necesita ahora decidir dónde añadir esas nuevas 5 réplicas. +Si no estuvieras usando el escalado proporcional, las 5 se añadirían al nuevo ReplicaSet. Pero con el escalado proporcional, +las réplicas adicionales se distribuyen entre todos los ReplicaSets. Las partes más grandes van a los ReplicaSets +con el mayor número de réplicas y las partes más pequeñas van a los ReplicaSets con menos réplicas. Cualquier resto sobrante se añade +al ReplicaSet con mayor número de réplicas. Aquellos ReplicaSets con 0 réplicas no se escalan. + +En nuestro ejemplo anterior, se añadirán 3 réplicas al viejo ReplicaSet y 2 réplicas al nuevo ReplicaSet. +EL proceso de despliegue debería al final mover todas las réplicas al nuevo ReplicaSet, siempre que las nuevas +réplicas arranquen positivamente. + +```shell +kubectl get deploy +``` +``` +NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE +nginx-deployment 15 18 7 8 7m +``` + +```shell +kubectl get rs +``` +``` +NAME DESIRED CURRENT READY AGE +nginx-deployment-1989198191 7 7 0 7m +nginx-deployment-618515232 11 11 11 7m +``` + +## Pausar y Reanudar un Deployment + +Puedes pausar un Deployment antes de arrancar una o más modificaciones y luego reanudarlo. Esto te permite aplicar múltiples arreglos +entre la pausa y la reanudación sin necesidad de arrancar despliegues innecesarios. + +Por ejemplo, con un Deployment que acaba de crearse: + +```shell +kubectl get deploy +``` +``` +NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE +nginx 3 3 3 3 1m +``` +```shell +kubectl get rs +``` +``` +NAME DESIRED CURRENT READY AGE +nginx-2142116321 3 3 3 1m +``` + +Lo pausamos ejecutando el siguiente comando: + +```shell +kubectl rollout pause deployment.v1.apps/nginx-deployment +``` +``` +deployment.apps/nginx-deployment paused +``` + +Y luego actualizamos la imagen del Deployment: + +```shell +kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 +``` +``` +deployment.apps/nginx-deployment image updated +``` + +Nótese que no se arranca ningún despliegue nuevo: + +```shell +kubectl rollout history deployment.v1.apps/nginx-deployment +``` +``` +deployments "nginx" +REVISION CHANGE-CAUSE +1 +``` + +```shell +kubectl get rs +``` +``` +NAME DESIRED CURRENT READY AGE +nginx-2142116321 3 3 3 2m +``` + +Puedes realizar tantas modificaciones como quieras, por ejemplo, para actualizar los recursos a utilizar: + +```shell +kubectl set resources deployment.v1.apps/nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi +``` +``` +deployment.apps/nginx-deployment resource requirements updated +``` + +El estado inicial del Deployment anterior a la pausa continuará su función, pero las nuevas modificaciones +del Deployment no tendrán efecto ya que el Deployment está pausado. + +Al final, reanuda el Deployment y observa cómo se genera un nuevo ReplicaSet con todos los cambios: + +```shell +kubectl rollout resume deployment.v1.apps/nginx-deployment +``` + +``` +deployment.apps/nginx-deployment resumed +``` + +```shell +kubectl get rs -w +``` + +``` +NAME DESIRED CURRENT READY AGE +nginx-2142116321 2 2 2 2m +nginx-3926361531 2 2 0 6s +nginx-3926361531 2 2 1 18s +nginx-2142116321 1 2 2 2m +nginx-2142116321 1 2 2 2m +nginx-3926361531 3 2 1 18s +nginx-3926361531 3 2 1 18s +nginx-2142116321 1 1 1 2m +nginx-3926361531 3 3 1 18s +nginx-3926361531 3 3 2 19s +nginx-2142116321 0 1 1 2m +nginx-2142116321 0 1 1 2m +nginx-2142116321 0 0 0 2m +nginx-3926361531 3 3 3 20s + +``` +```shell +kubectl get rs +``` +``` +NAME DESIRED CURRENT READY AGE +nginx-2142116321 0 0 0 2m +nginx-3926361531 3 3 3 28s +``` + +{{< note >}} +No se puede retroceder un Deployment pausado hasta que se vuelve a reanudar. +{{< /note >}} + +## Estado del Deployment + +Un Deployment pasa por varios estados a lo largo de su ciclo de vida. Así, puede estar [avanzando](#progressing-deployment) mientras +se despliega un nuevo ReplicaSet, puede estar [completo](#complete-deployment), o puede [fallar en su avance](#failed-deployment). + +### Avanzar un Deployment + +Kubernetes marca un Deployment como _avanzando_ cuando se realizar cualquiera de las siguientes tareas: + +* El Deployment crea un nuevo ReplicaSet. +* El Deployment está escalando su ReplicaSet más nuevo. +* El Deployment está reduciendo su(s) ReplicaSet(s) más antiguo(s). +* Hay nuevos Pods disponibles y listos (listo por lo menos [MinReadySeconds](#min-ready-seconds)). + +Puedes monitorizar el avance de un Deployment usando el comando `kubectl rollout status`. + +### Completar un Deployment + +Kubernetes marca un Deployment como _completado_ cuando presenta las siguientes características: + +* Todas las réplicas asociadas con el Deployment han sido actualizadas a la última versión indicada, lo cual quiere decir +que todas las actualizaciones se han completado. +* Todas las réplicas asociadas con el Deployment están disponibles. +* No están ejecutándose viejas réplicas del Deployment. + +Puedes comprobar si un Deployment se ha completado usando el comando `kubectl rollout status`. Si el despliegue se ha completado +de forma satisfactoria, el comando `kubectl rollout status` devuelve un código 0 de salida. + +```shell +kubectl rollout status deployment.v1.apps/nginx-deployment +``` +``` +Waiting for rollout to finish: 2 of 3 updated replicas are available... +deployment.apps/nginx-deployment successfully rolled out +$ echo $? +0 +``` + +### Deployment fallido + +Tu Deployment puede quedarse bloqueado intentando desplegar su nuevo ReplicaSet sin nunca completarse. Esto puede ocurrir +debido a algunos de los factores siguientes: + +* Cuota insuficiente +* Fallos en la prueba de estar listo +* Errores en la descarga de imágenes +* Permisos insuficientes +* Rangos de límites de recursos +* Mala configuración del motor de ejecución de la aplicación + +Una forma de detectar este tipo de situación es especificar un parámetro de vencimiento en la especificación de tu Deployment: +([`.spec.progressDeadlineSeconds`](#progress-deadline-seconds)). `.spec.progressDeadlineSeconds` denota el número +de segundos que el controlador del Deployment debe esperar antes de indicar (en el estado del Deployment) que el +Deployment no avanza. + +El siguiente comando `kubectl` configura el campo `progressDeadlineSeconds` para forzar al controlador a +informar de la falta de avance de un Deployment después de 10 minutos: + +```shell +kubectl patch deployment.v1.apps/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}' +``` +``` +deployment.apps/nginx-deployment patched +``` +Una vez que se ha excedido el vencimiento, el controlador del Deployment añade una DeploymentCondition +con los siguientes atributos al campo `.status.conditions` del Deployment: + +* Type=Progressing +* Status=False +* Reason=ProgressDeadlineExceeded + +Ver las [convenciones de la API de Kubernetes](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties) para más información acerca de las condiciones de estado. + +{{< note >}} +Kubernetes no emprenderá ninguna acción ante un Deployment parado que no sea la de reportar el estado mediante +`Reason=ProgressDeadlineExceeded`. Los orquestradores de alto nivel pueden aprovecharse y actuar consecuentemente, por ejemplo, +retrocediendo el Deployment a su versión previa. +{{< /note >}} + +{{< note >}} +Si pausas un Deployment, Kubernetes no comprueba el avance en base al vencimiento indicado. Así, es posible pausar +de forma segura un Deployment en medio de un despliegue y reanudarlo sin que se arranque el estado de exceso de vencimiento. +{{< /note >}} + +Puede que notes errores transitorios en tus Deployments, bien debido a un tiempo de vencimiento muy pequeño que hayas configurado +o bien a cualquier otro tipo de error que puede considerarse como transitorio. Por ejemplo, +supongamos que no tienes suficiente cuota. Si describes el Deployment, te darás cuenta de la sección siguiente: + +```shell +kubectl describe deployment nginx-deployment +``` +``` +<...> +Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing True ReplicaSetUpdated + ReplicaFailure True FailedCreate +<...> +``` + +Si ejecutas el comando `kubectl get deployment nginx-deployment -o yaml`, el estado del Deployment puede parecerse a: + +``` +status: + availableReplicas: 2 + conditions: + - lastTransitionTime: 2016-10-04T12:25:39Z + lastUpdateTime: 2016-10-04T12:25:39Z + message: Replica set "nginx-deployment-4262182780" is progressing. + reason: ReplicaSetUpdated + status: "True" + type: Progressing + - lastTransitionTime: 2016-10-04T12:25:42Z + lastUpdateTime: 2016-10-04T12:25:42Z + message: Deployment has minimum availability. + reason: MinimumReplicasAvailable + status: "True" + type: Available + - lastTransitionTime: 2016-10-04T12:25:39Z + lastUpdateTime: 2016-10-04T12:25:39Z + message: 'Error creating: pods "nginx-deployment-4262182780-" is forbidden: exceeded quota: + object-counts, requested: pods=1, used: pods=3, limited: pods=2' + reason: FailedCreate + status: "True" + type: ReplicaFailure + observedGeneration: 3 + replicas: 2 + unavailableReplicas: 2 +``` + +Al final, una vez que se supera el vencimiento del avance del Deployment, Kubernetes actualiza el estado +y la razón de el estado de avance: + +``` +Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing False ProgressDeadlineExceeded + ReplicaFailure True FailedCreate +``` + +Puedes solucionar un problema de cuota insuficiente simplemente reduciendo el número de réplicas de tu Deployment, reduciendo +otros controladores que puedas estar ejecutando, o incrementando la cuota en tu espacio de nombres. Si una vez satisfechas las condiciones de tu cuota, +el controlador del Deployment completa el despliegue, entonces verás que el estado del Deployment se actualiza al estado satisfactorio (`Status=True` y `Reason=NewReplicaSetAvailable`). + +``` +Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing True NewReplicaSetAvailable +``` + +`Type=Available` con `Status=True` significa que tu Deployment tiene disponibilidad mínima. La disponibilidad mínima se prescribe +mediante los parámetros indicados en la estrategia de despligue. `Type=Progressing` con `Status=True` significa que tu Deployment +está bien en medio de un despliegue y está avanzando o bien que se ha completado de forma satisfactoria y el número mímino +requerido de nuevas réplicas ya está disponible (ver la Razón del estado para cada caso particular - en nuestro caso +`Reason=NewReplicaSetAvailable` significa que el Deployment se ha completado). + +Puedes comprobar si un Deployment ha fallado en su avance usando el comando `kubectl rollout status`. `kubectl rollout status` +devuelve un código de salida distinto de 0 si el Deployment ha excedido su tiempo de vencimiento. + +```shell +kubectl rollout status deployment.v1.apps/nginx-deployment +``` +``` +Waiting for rollout to finish: 2 out of 3 new replicas have been updated... +error: deployment "nginx" exceeded its progress deadline +$ echo $? +1 +``` + +### Actuar ante un despliegue fallido + +Todas las acciones que aplican a un Deployment completado también aplican a un Deployment fallido. Puedes escalarlo/reducirlo, retrocederlo +a una revisión previa, o incluso pausarlo si necesitas realizar múltiples cambios a la plantilla Pod del Deployment. + +## Regla de Limpieza + +Puedes configurar el campo `.spec.revisionHistoryLimit` de un Deployment para especificar cuántos ReplicaSets viejos quieres conservar +para este Deployment. El resto será eliminado en segundo plano. Por defecto, es 10. + +{{< note >}} +Poner este campo de forma explícita a 0 resulta en la limpieza de toda la historia de tu Deployment, +por lo que tu Deployment no podrá retroceder a revisiones previas. +{{< /note >}} + +## Casos de Uso + +### Despligue Canary + +Si quieres desplegar nuevas versiones a un sub-conjunto de usuarios o servidores usando el Deployment, +puedes hacerlo creando múltiples Deployments, uno para cada versión nueva, siguiendo el patrón canary descrito en +[gestionar recursos](/docs/concepts/cluster-administration/manage-deployment/#canary-deployments). + +## Escribir una especificación de Deployment + +Al igual que con el resto de configuraciones de Kubernetes, un Deployment requiere los campos `apiVersion`, `kind`, y `metadata`. +Para información general acerca de cómo trabajar con ficheros de configuración, ver los documentos acerca de [desplegar aplicaciones](/docs/tutorials/stateless-application/run-stateless-application-deployment/), +configurar contenedores, y [usar kubectl para gestionar recursos](/docs/concepts/overview/object-management-kubectl/overview/). + +Un Deployment también necesita una [sección `.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status). + +### Plantilla Pod + +Tanto `.spec.template` como `.spec.selector` sin campos obligatorios dentro de `.spec`. + +El campo `.spec.template` es una [plantilla Pod](/docs/concepts/workloads/pods/pod-overview/#pod-templates). Tiene exactamente el mismo esquema que un [Pod](/docs/concepts/workloads/pods/pod/), +excepto por el hecho de que está anidado y no tiene `apiVersion` ni `kind`. + +Junto con los campos obligatorios de un Pod, una plantilla Pod de un Deployment debe indicar las etiquetas +y las reglas de reinicio apropiadas. Para el caso de las etiquetas, asegúrate que no se entremezclan con otros controladores. Ver [selector](#selector)). + +Únicamente se permite una [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) igual a `Always`, +que es el valor por defecto si no se indica. + +### Réplicas + +`.spec.replicas` es un campo opcional que indica el número de Pods deseados. Su valor por defecto es 1. + +### Selector + +`.spec.selector` es un campo opcional que indica un [selector de etiquetas](/docs/concepts/overview/working-with-objects/labels/) +para los Pods objetivo del deployment. + +`.spec.selector` debe coincidir con `.spec.template.metadata.labels`, o será descartado por la API. + +A partir de la versión `apps/v1` de la API, `.spec.selector` y `.metadata.labels` no toman como valor por defecto el valor de `.spec.template.metadata.labels` si no se indica. +Por ello, debe especificarse de forma explícita. Además hay que mencionar que `.spec.selector` es inmutable tras la creación del Deployment en `apps/v1`. + +Un Deployment puede finalizar aquellos Pods cuyas etiquetas coincidan con el selector si su plantilla es diferente +de `.spec.template` o si el número total de dichos Pods excede `.spec.replicas`. Arranca nuevos +Pods con `.spec.template` si el número de Pods es menor que el número deseado. + +{{< note >}} +No deberías crear otros Pods cuyas etiquetas coincidan con este selector, ni directamente creando +otro Deployment, ni creando otro controlador como un ReplicaSet o un ReplicationController. Si lo haces, +el primer Deployment pensará que también creó esos otros Pods. Kubernetes no te impide hacerlo. +{{< /note >}} + +Si tienes múltiples controladores que entremezclan sus selectores, dichos controladores competirán entre ellos +y no se comportarán de forma correcta. + +### Estrategia + +`.spec.strategy` especifica la estrategia usada para remplazar los Pods viejos con los nuevos. +`.spec.strategy.type` puede tener el valor "Recreate" o "RollingUpdate". "RollingUpdate" el valor predeterminado. + +#### Despliegue de recreación + +Todos los Pods actuales se eliminan antes de que los nuevos se creen cuando `.spec.strategy.type==Recreate`. + +#### Despliegue de Actualización Continua + +El Deployment actualiza los Pods en modo de [actualización continua](/docs/tasks/run-application/rolling-update-replication-controller/) +cuando `.spec.strategy.type==RollingUpdate`. Puedes configurar los valores de `maxUnavailable` y `maxSurge` +para controlar el proceso de actualización continua. + +##### Máx. no disponible + +`.spec.strategy.rollingUpdate.maxUnavailable` es un campo opcional que indica el número máximo +de Pods que pueden no estar disponibles durante el proceso de actualización. El valor puede ser un número absoluto (por ejemplo, 5) +o un porcentaje de los Pods deseados (por ejemplo, 10%). El número absoluto se calcula a partir del porcentaje +con redondeo a la baja. El valor no puede ser 0 si `.spec.strategy.rollingUpdate.maxSurge` es 0. El valor predeterminado es 25%. + +Por ejemplo, cuando este valor es 30%, el ReplicaSet viejo puede escalarse al 70% de los +Pods deseados de forma inmediata tras comenzar el proceso de actualización. Una vez que los Pods están listos, +el ReplicaSet viejo puede reducirse aún mas, seguido de un escalado del nuevo ReplicaSet, +asegurándose que el número total de Pods disponibles en todo momento durante la actualización +es de al menos el 70% de los Pods deseados. + +##### Máx. Aumento + +`.spec.strategy.rollingUpdate.maxSurge` es un campo opcional que indica el número máximo de Pods +que puede crearse por encima del número deseado de Pods. El valor puede ser un número absoluto (por ejemplo, 5) +o un porcentaje de los Pods deseados (por ejemplo, 10%). El valor no puede ser 0 si `MaxUnavailable` es 0. +El número absoluto se calcula a partir del porcentaje con redondeo al alza. El valor predeterminado es 25%. + +Por ejemplo, cuando este valor es 30%, el nuevo ReplicaSet puede escalarse inmediatamente cuando +comienza la actualización continua, de forma que el número total de Pods viejos y nuevos no +excede el 130% de los Pods deseados. Una vez que los viejos Pods se han eliminado, el nuevo ReplicaSet +puede seguir escalándose, asegurándose que el número total de Pods ejecutándose en todo momento +durante la actualización es como mucho del 130% de los Pods deseados. + +### Segundos para vencimiento del avance + +`.spec.progressDeadlineSeconds` es un campo opcional que indica el número de segundos que quieres +esperar a que tu Deployment avance antes de que el sistema reporte que dicho Deployment +[ha fallado en su avance](#failed-deployment) - expresado como un estado con `Type=Progressing`, `Status=False`. +y `Reason=ProgressDeadlineExceeded` en el recurso. El controlador del Deployment seguirá intentando +el despliegue. En el futuro, una vez que se implemente el retroceso automático, el controlador del Deployment +retrocederá el despliegue en cuanto detecte ese estado. + +Si se especifica, este campo debe ser mayor que `.spec.minReadySeconds`. + +### Segundos Mínimos para Listo + +`.spec.minReadySeconds` es un campo opcional que indica el número mínimo de segundos en que +un Pod recién creado debería estar listo sin que falle ninguno de sus contenedores, para que se considere disponible. +Por defecto su valor es 0 (el Pod se considera disponible en el momento que está listo). Para aprender más acerca de +cuándo un Pod se considera que está listo, ver las [pruebas de contenedor](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes). + +### Vuelta atrás + +El campo `.spec.rollbackTo` se ha quitado de las versiones `extensions/v1beta1` y `apps/v1beta1` de la API, y ya no se permite en las versiones de la API a partir de `apps/v1beta2`. +En su caso, se debería usar `kubectl rollout undo`, tal y como se explicó en [Retroceder a una Revisión Previa](#rolling-back-to-a-previous-revision). + +### Límite de Historia de Revisiones + +La historia de revisiones de un Deployment se almacena en los ReplicaSets que este controla. + +`.spec.revisionHistoryLimit` es un campo opcional que indica el número de ReplicaSets viejos a retener +para permitir los retrocesos. Estos ReplicaSets viejos consumen recursos en `etcd` y rebosan la salida de `kubectl get rs`. +La configuración de cada revisión de Deployment se almacena en sus ReplicaSets; +por lo tanto, una vez que se elimina el ReplicaSet viejo, se pierde la posibilidad de retroceder a dicha revisión del Deployment. +Por defecto, se retienen hasta 10 ReplicaSets viejos; pero su valor ideal depende de la frecuencia y la estabilidad de los nuevos Deployments. + +De forma más específica, si ponemos este campo a cero quiere decir que todos los ReplicaSets viejos con 0 réplicas se limpiarán. +En este caso, el nuevo despliegue del Deployment no se puede deshacer, ya que su historia de revisiones se habrá limpiado. + +### Pausa + +`.spec.paused` es un campo booleano opcional para pausar y reanudar un Deployment. La única diferencia entre +un Deployment pausado y otro que no lo está es que cualquier cambio al PodTemplateSpec del Deployment pausado +no generará nuevos despliegues mientras esté pausado. Un Deployment se pausa de forma predeterminada cuando se crea. + +## Alternativa a los Deployments + +### kubectl rolling update + +[`kubectl rolling update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update) actualiza los Pods y los ReplicationControllers +de forma similar. Pero se recomienda el uso de Deployments porque se declaran del lado del servidor, y proporcionan características adicionales +como la posibilidad de retroceder a revisiones anteriores incluso después de haber terminado una actualización continua. + +{{% /capture %}} diff --git a/content/es/docs/concepts/workloads/controllers/garbage-collection.md b/content/es/docs/concepts/workloads/controllers/garbage-collection.md new file mode 100644 index 0000000000..5e93f00d9b --- /dev/null +++ b/content/es/docs/concepts/workloads/controllers/garbage-collection.md @@ -0,0 +1,183 @@ +--- +title: Recolección de Basura +content_template: templates/concept +weight: 60 +--- + +{{% capture overview %}} + +El papel del recolector de basura de Kubernetes es el de eliminar determinados objetos +que en algún momento tuvieron un propietario, pero que ahora ya no. + +{{% /capture %}} + + +{{% capture body %}}referencias de propietario + +## Propietarios y subordinados + +Algunos objetos de Kubernetes son propietarios de otros objetos. Por ejemplo, un ReplicaSet +es el propietario de un conjunto de Pods. Los objetos que se poseen se denominan *subordinados* del +objeto propietario. Cada objeto subordinado tiene un campo `metadata.ownerReferences` +que apunta al objeto propietario. + +En ocasiones, Kubernetes pone el valor del campo `ownerReference` automáticamente. + Por ejemplo, cuando creas un ReplicaSet, Kubernetes automáticamente pone el valor del campo +`ownerReference` de cada Pod en el ReplicaSet. A partir de la versión 1.8, Kubernetes +automáticamente pone el valor de `ownerReference` para los objetos creados o adoptados +por un ReplicationController, ReplicaSet, StatefulSet, DaemonSet, Deployment, Job +y CronJob. + +También puedes configurar las relaciones entre los propietarios y sus subordinados +de forma manual indicando el valor del campo `ownerReference`. + +Aquí se muestra un archivo de configuración para un ReplicaSet que tiene tres Pods: + +{{< codenew file="controllers/replicaset.yaml" >}} + +Si se crea el ReplicaSet y entonces se muestra los metadatos del Pod, se puede +observar el campo OwnerReferences: + +```shell +kubectl apply -f https://k8s.io/examples/controllers/replicaset.yaml +kubectl get pods --output=yaml +``` + +La salida muestra que el propietario del Pod es el ReplicaSet denominado `my-repset`: + +```shell +apiVersion: v1 +kind: Pod +metadata: + ... + ownerReferences: + - apiVersion: apps/v1 + controller: true + blockOwnerDeletion: true + kind: ReplicaSet + name: my-repset + uid: d9607e19-f88f-11e6-a518-42010a800195 + ... +``` + +{{< note >}} +No se recomienda el uso de OwnerReferences entre Namespaces por diseño. Esto quiere decir que: +1) Los subordinados dentro del ámbito de Namespaces sólo pueden definir propietarios en ese mismo Namespace, +y propietarios dentro del ámbito de clúster. +2) Los subordinados dentro del ámbito del clúster sólo pueden definir propietarios dentro del ámbito del clúster, pero no +propietarios dentro del ámbito de Namespaces. +{{< /note >}} + +## Controlar cómo el recolector de basura elimina los subordinados + +Cuando eliminas un objeto, puedes indicar si sus subordinados deben eliminarse también +de forma automática. Eliminar los subordinados automáticamente se denomina *borrado en cascada*. +Hay dos modos de *borrado en cascada*: *en segundo plano* y *en primer plano*. + +Si eliminas un objeto sin borrar sus subordinados de forma automática, +dichos subordinados se convierten en *huérfanos*. + +### Borrado en cascada en primer plano + +En el *borrado en cascada en primer plano*, el objeto raíz primero entra en un estado +llamado "deletion in progress". En este estado "deletion in progress", +se cumplen las siguientes premisas: + + * El objeto todavía es visible a través de la API REST + * Se pone el valor del campo `deletionTimestamp` del objeto + * El campo `metadata.finalizers` del objeto contiene el valor "foregroundDeletion". + +Una vez que se pone el estado "deletion in progress", el recolector de basura elimina +los subordinados del objeto. Una vez que el recolector de basura ha eliminado todos +los subordinados "bloqueantes" (los objetos con `ownerReference.blockOwnerDeletion=true`), elimina +el objeto propietario. + +Cabe mencionar que usando "foregroundDeletion", sólo los subordinados con valor en +`ownerReference.blockOwnerDeletion` bloquean la eliminación del objeto propietario. +A partir de la versión 1.7, Kubernetes añadió un [controlador de admisión](/docs/reference/access-authn-authz/admission-controllers/#ownerreferencespermissionenforcement) +que controla el acceso de usuario cuando se intenta poner el campo `blockOwnerDeletion` a true +con base a los permisos de borrado del objeto propietario, de forma que aquellos subordinados no autorizados +no puedan retrasar la eliminación del objeto propietario. + +Si un controlador (como un Deployment o un ReplicaSet) establece el valor del campo `ownerReferences` de un objeto, +se pone blockOwnerDeletion automáticamente y no se necesita modificar de forma manual este campo. + +### Borrado en cascada en segundo plano + +En el *borrado en cascada en segundo plano*, Kubernetes elimina el objeto propietario +inmediatamente y es el recolector de basura quien se encarga de eliminar los subordinados en segundo plano. + +### Configurar la regla de borrado en cascada + +Para controlar la regla de borrado en cascada, configura el campo `propagationPolicy` +del parámetro `deleteOptions` cuando elimines un objeto. Los valores posibles incluyen "Orphan", +"Foreground", o "Background". + +Antes de la versión 1.9 de Kubernetes, la regla predeterminada del recolector de basura para la mayoría de controladores era `orphan`. +Esto incluía al ReplicationController, ReplicaSet, StatefulSet, DaemonSet, y al Deployment. +Para los tipos dentro de las versiones de grupo `extensions/v1beta1`, `apps/v1beta1`, y `apps/v1beta2`, a menos que +se indique de otra manera, los objetos subordinados se quedan huérfanos por defecto. +En Kubernetes 1.9, para todos los tipos de la versión de grupo `apps/v1`, los objetos subordinados se eliminan por defecto. + +Aquí se muestra un ejemplo que elimina los subordinados en segundo plano: + +```shell +kubectl proxy --port=8080 +curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \ +-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Background"}' \ +-H "Content-Type: application/json" +``` + +Aquí se muestra un ejemplo que elimina los subordinados en primer plano: + +```shell +kubectl proxy --port=8080 +curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \ +-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \ +-H "Content-Type: application/json" +``` + +Aquí se muestra un ejemplo de subordinados huérfanos: + +```shell +kubectl proxy --port=8080 +curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \ +-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \ +-H "Content-Type: application/json" +``` + +kubectl también permite el borrado en cascada. +Para eliminar los subordinados automáticamente, utiliza el parámetro `--cascade` a true. + Usa false para subordinados huérfanos. Por defecto, el valor de `--cascade` +es true. + +Aquí se muestra un ejemplo de huérfanos de subordinados de un ReplicaSet: + +```shell +kubectl delete replicaset my-repset --cascade=false +``` + +### Nota adicional sobre los Deployments + +Antes de la versión 1.7, cuando se usaba el borrado en cascada con Deployments se *debía* usar `propagationPolicy: Foreground` +para eliminar no sólo los ReplicaSets creados, sino también sus Pods correspondientes. Si este tipo de _propagationPolicy_ +no se usa, solo se elimina los ReplicaSets, y los Pods se quedan huérfanos. +Ver [kubeadm/#149](https://github.com/kubernetes/kubeadm/issues/149#issuecomment-284766613) para más información. + +## Problemas conocidos + +Seguimiento en [#26120](https://github.com/kubernetes/kubernetes/issues/26120) + +{{% /capture %}} + + +{{% capture whatsnext %}} + +[Documento de Diseño 1](https://git.k8s.io/community/contributors/design-proposals/api-machinery/garbage-collection.md) + +[Documento de Diseño 2](https://git.k8s.io/community/contributors/design-proposals/api-machinery/synchronous-garbage-collection.md) + +{{% /capture %}} + + + diff --git a/content/es/examples/controllers/nginx-deployment.yaml b/content/es/examples/controllers/nginx-deployment.yaml new file mode 100644 index 0000000000..f7f95deebb --- /dev/null +++ b/content/es/examples/controllers/nginx-deployment.yaml @@ -0,0 +1,21 @@ +apiVersion: apps/v1 +kind: Deployment +metadata: + name: nginx-deployment + labels: + app: nginx +spec: + replicas: 3 + selector: + matchLabels: + app: nginx + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: nginx + image: nginx:1.7.9 + ports: + - containerPort: 80 diff --git a/content/es/examples/controllers/replicaset.yaml b/content/es/examples/controllers/replicaset.yaml new file mode 100644 index 0000000000..e5dfdf6c43 --- /dev/null +++ b/content/es/examples/controllers/replicaset.yaml @@ -0,0 +1,17 @@ +apiVersion: apps/v1 +kind: ReplicaSet +metadata: + name: my-repset +spec: + replicas: 3 + selector: + matchLabels: + pod-is-for: garbage-collection-example + template: + metadata: + labels: + pod-is-for: garbage-collection-example + spec: + containers: + - name: nginx + image: nginx From 496fad77bbf9a1362c332fdfca26f7c876532c02 Mon Sep 17 00:00:00 2001 From: Cheikhrouhou ines Date: Fri, 20 Dec 2019 16:52:34 +0100 Subject: [PATCH 03/19] renaming and fix for service account fr --- .../configure-service-account.md | 44 +++++++++---------- 1 file changed, 22 insertions(+), 22 deletions(-) diff --git a/content/fr/docs/tasks/configure-pod-container/configure-service-account.md b/content/fr/docs/tasks/configure-pod-container/configure-service-account.md index c90a7de585..872256503b 100644 --- a/content/fr/docs/tasks/configure-pod-container/configure-service-account.md +++ b/content/fr/docs/tasks/configure-pod-container/configure-service-account.md @@ -5,7 +5,7 @@ weight: 90 --- {{% capture overview %}} -Un compte de service fournit une identité pour les processus qui s'exécutent dans un Pod. +Un ServiceAccount (compte de service) fournit une identité pour les processus qui s'exécutent dans un Pod. *Ceci est une introduction aux comptes de service pour les utilisateurs. Voir aussi [Guide de l'administrateur du cluster des comptes de service](/docs/reference/access-authn-authz/service-accounts-admin/).* @@ -16,7 +16,7 @@ Ce document décrit le comportement des comptes de service dans un cluster mis e Lorsque vous (un humain) accédez au cluster (par exemple, en utilisant `kubectl`), vous êtes authentifié par l'apiserver en tant que compte d'utilisateur particulier (actuellement, il s'agit -généralement de l'utilisateur `admin`, à moins que votre administrateur de cluster n'ait personnalisé votre cluster).Les processus dans les conteneurs dans les pods peuvent également contacter l'apiserver. Dans ce cas, ils sont authentifiés en tant que compte de service particulier (par exemple, `default`). +généralement de l'utilisateur `admin`, à moins que votre administrateur de cluster n'ait personnalisé votre cluster). Les processus dans les conteneurs dans les Pods peuvent également contacter l'apiserver. Dans ce cas, ils sont authentifiés en tant que compte de service particulier (par exemple, `default`). {{% /capture %}} @@ -31,12 +31,12 @@ généralement de l'utilisateur `admin`, à moins que votre administrateur de cl ## Utiliser le compte de service par défaut pour accéder au API server. -Si vous obtenez le raw json ou yaml pour un pod que vous avez créé (par exemple, `kubectl get pods/ -o yaml`), vous pouvez voir que le champ `spec.serviceAccountName` a été [automatiquement assigné](/docs/user-guide/working-with-resources/#resources-are-automatically-modified). +Si vous obtenez le raw json ou yaml pour un Pod que vous avez créé (par exemple, `kubectl get pods/ -o yaml`), vous pouvez voir que le champ `spec.serviceAccountName` a été [automatiquement assigné](/docs/user-guide/working-with-resources/#resources-are-automatically-modified). -Vous pouvez accéder à l'API depuis l'intérieur d'un pod en utilisant les identifiants de compte de service montés automatiquement, comme décrit dans [Accès au cluster](/docs/user-guide/accessing-the-cluster/#accessing-the-api-from-a-pod). +Vous pouvez accéder à l'API depuis l'intérieur d'un Pod en utilisant les identifiants de compte de service montés automatiquement, comme décrit dans [Accès au cluster](/docs/user-guide/accessing-the-cluster/#accessing-the-api-from-a-pod). Les permissions API du compte de service dépendent du [plugin d'autorisation et de la politique](/docs/reference/access-authn-authz/authorization/#authorization-modules) en usage. -Dans la version 1.6+, vous pouvez choisir de ne pas utiliser le montage automatique des identifiants API pour un compte de service en définissant `automountServiceAccountToken : false` sur le compte de service : +Dans la version 1.6+, vous pouvez choisir de ne pas utiliser le montage automatique des identifiants API pour un compte de service en définissant `automountServiceAccountToken: false` sur le compte de service : ```yaml apiVersion: v1 @@ -47,7 +47,7 @@ automountServiceAccountToken: false ... ``` -Dans la version 1.6+, vous pouvez également choisir de ne pas monter automatiquement les identifiants API pour un pod particulier : +Dans la version 1.6+, vous pouvez également choisir de ne pas monter automatiquement les identifiants API pour un Pod particulier : ```yaml apiVersion: v1 @@ -60,12 +60,12 @@ spec: ... ``` -La spéc de pod a prépondérance par rapport au compte de service si les deux spécifient la valeur `automountServiceAccountToken`. +La spéc de Pod a prépondérance par rapport au compte de service si les deux spécifient la valeur `automountServiceAccountToken`. ## Utiliser plusieurs comptes de services. -Chaque namespace possède une ressource de compte de service par défaut appelée `default`. -Vous pouvez lister cette ressource et toutes les autres ressources de serviceAccount dans le namespace avec cette commande : +Chaque Namespace possède une ressource ServiceAccount par défaut appelée `default`. +Vous pouvez lister cette ressource et toutes les autres ressources de ServiceAccount dans le Namespace avec cette commande : ```shell kubectl get serviceAccounts @@ -111,13 +111,13 @@ secrets: vous verrez alors qu'un token a été automatiquement créé et est référencé par le compte de service. -Vous pouvez utiliser des plugins d'autorisation pour[définir les permissions sur les comptes de service](/docs/reference/access-authn-authz/rbac/#service-account-permissions). +Vous pouvez utiliser des plugins d'autorisation pour [définir les permissions sur les comptes de service](/docs/reference/access-authn-authz/rbac/#service-account-permissions). -Pour utiliser un compte de service autre que par défaut, il suffit de spécifier le `spec.serviceAccountName` d'un pod au nom du compte de service que vous souhaitez utiliser. +Pour utiliser un compte de service autre que par défaut, il suffit de spécifier le `spec.serviceAccountName` d'un Pod au nom du compte de service que vous souhaitez utiliser. -Le compte de service doit exister au moment de la création du pod, sinon il sera rejeté. +Le compte de service doit exister au moment de la création du Pod, sinon il sera rejeté. -Vous ne pouvez pas mettre à jour le compte de service d'un pod déjà créé. +Vous ne pouvez pas mettre à jour le compte de service d'un Pod déjà créé. Vous pouvez supprimer le compte de service de cet exemple comme ceci : @@ -127,7 +127,7 @@ kubectl delete serviceaccount/build-robot ## Créez manuellement un API token de compte de service. -Supposons que nous ayons un compte de service existant nommé "build-robot" comme mentionné ci-dessus,et que nous allons créer un nouveau secret manuellement. +Supposons que nous ayons un compte de service existant nommé "build-robot" comme mentionné ci-dessus,et que nous allons créer un nouveau Secret manuellement. ```shell kubectl apply -f - <}} -Le kubelet peut également projeter un token de compte de service dans un Pod. Vous pouvez spécifier les propriétés souhaitées du token, telles que l'audience et la durée de validité. +Kubelet peut également projeter un token de compte de service dans un Pod. Vous pouvez spécifier les propriétés souhaitées du token, telles que l'audience et la durée de validité. Ces propriétés ne sont pas configurables sur le compte de service par défaut. Le token de compte de service devient également invalide par l'API lorsque le Pod ou le ServiceAccount est supprimé Ce comportement est configuré sur un PodSpec utilisant un type de ProjectedVolume appelé [ServiceAccountToken](/docs/concepts/storage/volumes/#projected). Pour fournir un -pod avec un token avec une audience de "vault" et une durée de validité de deux heures, vous devriez configurer ce qui suit dans votre PodSpec : +Pod avec un token avec une audience de "vault" et une durée de validité de deux heures, vous devriez configurer ce qui suit dans votre PodSpec : {{< codenew file="pods/pod-projected-svc-token.yaml" >}} -Créez le pod +Créez le Pod ```shell kubectl create -f https://k8s.io/examples/pods/pod-projected-svc-token.yaml ``` -Le kubelet demandera et stockera le token a la place du pod, rendra le token disponible pour le pod à un chemin d'accès configurable, et rafraîchissez le token à l'approche de son expiration. Kubelet fait tourner le token de manière proactive s'il est plus vieux que 80% de son TTL total, ou si le token est plus vieux que 24 heures. +Kubelet demandera et stockera le token a la place du Pod, rendra le token disponible pour le Pod à un chemin d'accès configurable, et rafraîchissez le token à l'approche de son expiration. Kubelet fait tourner le token de manière proactive s'il est plus vieux que 80% de son TTL total, ou si le token est plus vieux que 24 heures. -L'application est responsable du rechargement du token lorsqu'il tourne. Un rechargement périodique (par ex. toutes les 5 minutes) est suffisant pour la plupart des cas d'utilisation. +L'application est responsable du rechargement du token lorsque celui ci est renouvelé. Un rechargement périodique (par ex. toutes les 5 minutes) est suffisant pour la plupart des cas d'utilisation. {{% /capture %}} From 40496c2b7d8e2dc9f47f2da21c1ede2db6b93420 Mon Sep 17 00:00:00 2001 From: icheikhrouhou Date: Mon, 13 Apr 2020 10:18:36 +0200 Subject: [PATCH 04/19] fix translate configure service account --- .../configure-pod-container/configure-service-account.md | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/content/fr/docs/tasks/configure-pod-container/configure-service-account.md b/content/fr/docs/tasks/configure-pod-container/configure-service-account.md index 872256503b..5d8df1af62 100644 --- a/content/fr/docs/tasks/configure-pod-container/configure-service-account.md +++ b/content/fr/docs/tasks/configure-pod-container/configure-service-account.md @@ -214,7 +214,7 @@ secrets: - name: default-token-uudge ``` -En utilisant l'éditeur de votre choix (par exemple `vi`), ouvrez le fichier `sa.yaml`, supprimez la ligne avec la clé `resourceVersion`, ajouter les lignes avec `imagePullSecrets:` et sauvegarder. +En utilisant l'éditeur de votre choix (par exemple `vi`), ouvrez le fichier `sa.yaml`, supprimez la ligne avec la clé `resourceVersion`, ajoutez les lignes avec `imagePullSecrets:` et sauvegardez. La sortie du fichier `sa.yaml` est similaire à celle-ci : @@ -247,11 +247,6 @@ spec: - name: myregistrykey ``` - - ## Projection du volume des tokens de compte de service {{< feature-state for_k8s_version="v1.12" state="beta" >}} From 841db869b22296feeb711a9e82a0198947822899 Mon Sep 17 00:00:00 2001 From: Hector Sam Date: Thu, 11 Jun 2020 18:32:21 +0200 Subject: [PATCH 05/19] Lang: FR, Removing announcement and deprecationwarning --- content/fr/_index.html | 2 -- 1 file changed, 2 deletions(-) diff --git a/content/fr/_index.html b/content/fr/_index.html index 89a66f48b6..250932ba3e 100644 --- a/content/fr/_index.html +++ b/content/fr/_index.html @@ -3,9 +3,7 @@ title: "Solution professionnelle d’orchestration de conteneurs" abstract: "Déploiement, mise à l'échelle et gestion automatisée des conteneurs" cid: home --- -{{< announcement >}} -{{< deprecationwarning >}} {{< blocks/section id="oceanNodes" >}} {{% blocks/feature image="flower" %}} From e0f01428be9aa6e5c7d60faa3104c42a2b77f88e Mon Sep 17 00:00:00 2001 From: TomorJM Date: Mon, 22 Jun 2020 00:42:26 +0800 Subject: [PATCH 06/19] translate k8s.io/zh/docs/tutorials/kubernetes-basics/expose/expose-intro into Chinese --- .../expose/expose-intro.html | 58 +++++++++---------- 1 file changed, 29 insertions(+), 29 deletions(-) diff --git a/content/zh/docs/tutorials/kubernetes-basics/expose/expose-intro.html b/content/zh/docs/tutorials/kubernetes-basics/expose/expose-intro.html index 8adf05965b..49fb32cc78 100644 --- a/content/zh/docs/tutorials/kubernetes-basics/expose/expose-intro.html +++ b/content/zh/docs/tutorials/kubernetes-basics/expose/expose-intro.html @@ -1,5 +1,5 @@ --- -title: Using a Service to Expose Your App +title: 使用 Service 暴露您的应用 weight: 10 --- @@ -17,42 +17,42 @@ weight: 10
-

Objectives

+

目标

    -
  • Learn about a Service in Kubernetes
    • -
  • Understand how labels and LabelSelector objects relate to a Service
    • -
  • Expose an application outside a Kubernetes cluster using a Service
    • +
  • 了解 Kubernetes 中的 Service
    • +
  • 了解 selector 和 LabelSelector 对象如何与 Service 关联
    • +
  • 在 Kubernetes 集群外用 Service 暴露应用
-

Overview of Kubernetes Services

+

Kubernetes Service 总览

-

Kubernetes Pods are mortal. Pods in fact have a lifecycle. When a worker node dies, the Pods running on the Node are also lost. A ReplicaSet might then dynamically drive the cluster back to desired state via creation of new Pods to keep your application running. As another example, consider an image-processing backend with 3 replicas. Those replicas are exchangeable; the front-end system should not care about backend replicas or even if a Pod is lost and recreated. That said, each Pod in a Kubernetes cluster has a unique IP address, even Pods on the same Node, so there needs to be a way of automatically reconciling changes among Pods so that your applications continue to function.

+

Kubernetes Pod 是转瞬即逝的。 Pod 实际上拥有 生命周期. 当一个工作 Node 挂掉后, 在Node上运行的 Pod 也会消亡。 ReplicaSet 会自动地通过创建新的 Pod 驱动集群回到目标状态，以保证应用程序正常运行。 换一个例子，考虑一个具有3个副本数的用作图像处理的后端程序。这些副本是可交换的; 前端系统不应该关心后端副本，即使 Pod 丢失或重新创建。也就是说，Kubernetes集群中的每个 Pod (即使是在同一个 Node 上的 Pod )都有一个惟一的IP地址，因此需要一种方法自动协调 Pod 之间的变更，以便应用程序保持运行。

-

A Service in Kubernetes is an abstraction which defines a logical set of Pods and a policy by which to access them. Services enable a loose coupling between dependent Pods. A Service is defined using YAML (preferred) or JSON, like all Kubernetes objects. The set of Pods targeted by a Service is usually determined by a LabelSelector (see below for why you might want a Service without including selector in the spec).

+

Kubernetes 中的 Service 是一种抽象概念，它定义了 Pod 的逻辑集和访问 Pod 的协议。Service 使从属 Pod 之间的松耦合成为可能。 和其他 Kubernetes 对象一样, Service 用 YAML (更推荐) 或者 JSON 来定义. Service 下的一组 Pod 通常由 LabelSelector (请参阅下面的说明为什么您可能想要一个 spec 中不包含selector的服务)来标记。

-

Although each Pod has a unique IP address, those IPs are not exposed outside the cluster without a Service. Services allow your applications to receive traffic. Services can be exposed in different ways by specifying a type in the ServiceSpec:

+

尽管每个 Pod 都有一个唯一的IP地址，但是如果没有 Service ，这些IP不会暴露在群集外部。Service 允许您的应用程序接收流量。Service 也可以用在 ServiceSpec 标记type的方式暴露

    -
  • ClusterIP (default) - Exposes the Service on an internal IP in the cluster. This type makes the Service only reachable from within the cluster.
    • -
  • NodePort - Exposes the Service on the same port of each selected Node in the cluster using NAT. Makes a Service accessible from outside the cluster using <NodeIP>:<NodePort>. Superset of ClusterIP.
    • -
  • LoadBalancer - Creates an external load balancer in the current cloud (if supported) and assigns a fixed, external IP to the Service. Superset of NodePort.
    • -
  • ExternalName - Exposes the Service using an arbitrary name (specified by externalName in the spec) by returning a CNAME record with the name. No proxy is used. This type requires v1.7 or higher of kube-dns.
    • +
  • ClusterIP (默认) - 在集群的内部IP上公开 Service 。这种类型使得 Service 只能从集群内访问。
    • +
  • NodePort - 使用 NAT 在集群中每个选定 Node 的相同端口上公开 Service 。使用<NodeIP>:<NodePort> 从集群外部访问 Service。是 ClusterIP 的超集
    • +
  • LoadBalancer - 在当前云中创建一个外部负载均衡器(如果支持的话)，并为 Service 分配一个固定的外部IP。是 NodePort 的超集。
    • +
  • ExternalName - 通过返回带有该名称的 CNAME 记录，使用任意名称(由规范中的externalName指定)公开 Service。不使用代理。这种类型需要kube-dns的v1.7或更高版本。
-

More information about the different types of Services can be found in the Using Source IP tutorial. Also see Connecting Applications with Services.

-

Additionally, note that there are some use cases with Services that involve not defining selector in the spec. A Service created without selector will also not create the corresponding Endpoints object. This allows users to manually map a Service to specific endpoints. Another possibility why there may be no selector is you are strictly using type: ExternalName.

+

更多关于不同 Service 类型的信息可以在使用源 IP 教程。 也请参阅 连接应用程序和 Service .

+

另外，需要注意的是有一些 Service 的用例没有在 spec 中定义selector。 一个没有selector创建的 Service 也不会创建相应的端点对象。这允许用户手动将服务映射到特定的端点。没有 selector 的另一种可能是您严格使用type: ExternalName来标记。

-

Summary

+

总结

    -
  • Exposing Pods to external traffic
    • -
  • Load balancing traffic across multiple Pods
    • -
  • Using labels
    • +
  • 将 Pod 暴露给外部通信
    • +
  • 跨多个 Pod 的负载均衡
    • +
  • 使用 Label
-

A Kubernetes Service is an abstraction layer which defines a logical set of Pods and enables external traffic exposure, load balancing and service discovery for those Pods.

+

Kubernetes 的 Service 是一个抽象层，它定义了一组 Pod 的逻辑集，并为这些 Pod 支持外部流量暴露、负载平衡和服务发现

@@ -60,7 +60,7 @@ weight: 10
-

Services and Labels

+

Service 和 Label

@@ -72,18 +72,18 @@ weight: 10
-

A Service routes traffic across a set of Pods. Services are the abstraction that allow pods to die and replicate in Kubernetes without impacting your application. Discovery and routing among dependent Pods (such as the frontend and backend components in an application) is handled by Kubernetes Services.

-

Services match a set of Pods using labels and selectors, a grouping primitive that allows logical operation on objects in Kubernetes. Labels are key/value pairs attached to objects and can be used in any number of ways:

+

Service 通过一组 Pod 路由通信。Service 是一种抽象，它允许 Pod 死亡并在 Kubernetes 中复制，而不会影响应用程序。在依赖的 Pod (如应用程序中的前端和后端组件)之间进行发现和路由是由Kubernetes Service 处理的。

+

Service 匹配一组Pod 是使用 label 和 selector, 它们是允许对 Kubernetes 中的对象进行逻辑操作的一种分组原语。selector 是附加在对象上的键/值对，可以以多种方式使用:

    -
  • Designate objects for development, test, and production
    • -
  • Embed version tags
    • -
  • Classify an object using tags
    • +
  • 指定用于开发，测试和生产的对象
    • +
  • 嵌入版本标签
    • +
  • 使用 Label 将对象进行分类
-

You can create a Service at the same time you create a Deployment by using
--expose in kubectl.

+

你也可以在创建 Deployment 的同时用 --expose创建一个 Service 。

@@ -98,13 +98,13 @@ weight: 10
-

Labels can be attached to objects at creation time or later on. They can be modified at any time. Let's expose our application now using a Service and apply some labels.

+

Label 可以在创建时或之后附加到对象上。他们可以随时被修改。现在使用 Service 发布我们的应用程序并添加一些 Label 。


- Start Interactive Tutorial› + 开始交互式教程›
From 2d31450e89facb555dd2bc9d49dc75ef28239e47 Mon Sep 17 00:00:00 2001 From: TomorJM Date: Mon, 22 Jun 2020 11:48:12 +0800 Subject: [PATCH 07/19] supplement the chapter Using a Service to Expose Your App --- .../expose/expose-intro.html | 66 +++++++++++++------ 1 file changed, 47 insertions(+), 19 deletions(-) diff --git a/content/zh/docs/tutorials/kubernetes-basics/expose/expose-intro.html b/content/zh/docs/tutorials/kubernetes-basics/expose/expose-intro.html index 49fb32cc78..3806ef7f69 100644 --- a/content/zh/docs/tutorials/kubernetes-basics/expose/expose-intro.html +++ b/content/zh/docs/tutorials/kubernetes-basics/expose/expose-intro.html @@ -1,4 +1,5 @@ --- + title: 使用 Service 暴露您的应用 weight: 10 --- @@ -17,42 +18,61 @@ weight: 10
-

目标

+ +

目标

    + + +
  • 了解 Kubernetes 中的 Service
    • -
  • 了解 selector 和 LabelSelector 对象如何与 Service 关联
    • +
  • 了解 标签(Label) 和 标签选择器(Label Selector) 对象如何与 Service 关联
  • 在 Kubernetes 集群外用 Service 暴露应用
-

Kubernetes Service 总览

+ +

Kubernetes Service 总览

-

Kubernetes Pod 是转瞬即逝的。 Pod 实际上拥有 生命周期. 当一个工作 Node 挂掉后, 在Node上运行的 Pod 也会消亡。 ReplicaSet 会自动地通过创建新的 Pod 驱动集群回到目标状态，以保证应用程序正常运行。 换一个例子，考虑一个具有3个副本数的用作图像处理的后端程序。这些副本是可交换的; 前端系统不应该关心后端副本，即使 Pod 丢失或重新创建。也就是说，Kubernetes集群中的每个 Pod (即使是在同一个 Node 上的 Pod )都有一个惟一的IP地址，因此需要一种方法自动协调 Pod 之间的变更，以便应用程序保持运行。

+ +

Kubernetes Pod 是转瞬即逝的。 Pod 实际上拥有 生命周期。 当一个工作 Node 挂掉后, 在 Node 上运行的 Pod 也会消亡。 ReplicaSet 会自动地通过创建新的 Pod 驱动集群回到目标状态，以保证应用程序正常运行。 换一个例子，考虑一个具有3个副本数的用作图像处理的后端程序。这些副本是可替换的; 前端系统不应该关心后端副本，即使 Pod 丢失或重新创建。也就是说，Kubernetes 集群中的每个 Pod (即使是在同一个 Node 上的 Pod )都有一个惟一的 IP 地址，因此需要一种方法自动协调 Pod 之间的变更，以便应用程序保持运行。

-

Kubernetes 中的 Service 是一种抽象概念，它定义了 Pod 的逻辑集和访问 Pod 的协议。Service 使从属 Pod 之间的松耦合成为可能。 和其他 Kubernetes 对象一样, Service 用 YAML (更推荐) 或者 JSON 来定义. Service 下的一组 Pod 通常由 LabelSelector (请参阅下面的说明为什么您可能想要一个 spec 中不包含selector的服务)来标记。

+ +

Kubernetes 中的服务(Service)是一种抽象概念，它定义了 Pod 的逻辑集和访问 Pod 的协议。Service 使从属 Pod 之间的松耦合成为可能。 和其他 Kubernetes 对象一样, Service 用 YAML (更推荐) 或者 JSON 来定义. Service 下的一组 Pod 通常由 LabelSelector (请参阅下面的说明为什么您可能想要一个 spec 中不包含selector的服务)来标记。

-

尽管每个 Pod 都有一个唯一的IP地址，但是如果没有 Service ，这些IP不会暴露在群集外部。Service 允许您的应用程序接收流量。Service 也可以用在 ServiceSpec 标记type的方式暴露

+ +

尽管每个 Pod 都有一个唯一的 IP 地址，但是如果没有 Service ，这些 IP 不会暴露在群集外部。Service 允许您的应用程序接收流量。Service 也可以用在 ServiceSpec 标记type的方式暴露

    -
  • ClusterIP (默认) - 在集群的内部IP上公开 Service 。这种类型使得 Service 只能从集群内访问。
    • -
  • NodePort - 使用 NAT 在集群中每个选定 Node 的相同端口上公开 Service 。使用<NodeIP>:<NodePort> 从集群外部访问 Service。是 ClusterIP 的超集
    • + + + + +
  • ClusterIP (默认) - 在集群的内部 IP 上公开 Service 。这种类型使得 Service 只能从集群内访问。
    • +
  • NodePort - 使用 NAT 在集群中每个选定 Node 的相同端口上公开 Service 。使用<NodeIP>:<NodePort> 从集群外部访问 Service。是 ClusterIP 的超集。
  • LoadBalancer - 在当前云中创建一个外部负载均衡器(如果支持的话)，并为 Service 分配一个固定的外部IP。是 NodePort 的超集。
    • -
  • ExternalName - 通过返回带有该名称的 CNAME 记录，使用任意名称(由规范中的externalName指定)公开 Service。不使用代理。这种类型需要kube-dns的v1.7或更高版本。
    • +
  • ExternalName - 通过返回带有该名称的 CNAME 记录，使用任意名称(由 spec 中的externalName指定)公开 Service。不使用代理。这种类型需要kube-dns的v1.7或更高版本。
-

更多关于不同 Service 类型的信息可以在使用源 IP 教程。 也请参阅 连接应用程序和 Service .

-

另外，需要注意的是有一些 Service 的用例没有在 spec 中定义selector。 一个没有selector创建的 Service 也不会创建相应的端点对象。这允许用户手动将服务映射到特定的端点。没有 selector 的另一种可能是您严格使用type: ExternalName来标记。

+ +

更多关于不同 Service 类型的信息可以在使用源 IP 教程。 也请参阅 连接应用程序和 Service 。

+ +

另外，需要注意的是有一些 Service 的用例没有在 spec 中定义selector。 一个没有selector创建的 Service 也不会创建相应的端点对象。这允许用户手动将服务映射到特定的端点。没有 selector 的另一种可能是您严格使用type: ExternalName来标记。

-

总结

+ +

总结

    + + +
  • 将 Pod 暴露给外部通信
  • 跨多个 Pod 的负载均衡
    • -
  • 使用 Label
    • +
  • 使用标签(Label)
-

Kubernetes 的 Service 是一个抽象层，它定义了一组 Pod 的逻辑集，并为这些 Pod 支持外部流量暴露、负载平衡和服务发现

+ +

Kubernetes 的 Service 是一个抽象层，它定义了一组 Pod 的逻辑集，并为这些 Pod 支持外部流量暴露、负载平衡和服务发现。

@@ -72,9 +92,14 @@ weight: 10
-

Service 通过一组 Pod 路由通信。Service 是一种抽象，它允许 Pod 死亡并在 Kubernetes 中复制，而不会影响应用程序。在依赖的 Pod (如应用程序中的前端和后端组件)之间进行发现和路由是由Kubernetes Service 处理的。

-

Service 匹配一组Pod 是使用 label 和 selector, 它们是允许对 Kubernetes 中的对象进行逻辑操作的一种分组原语。selector 是附加在对象上的键/值对，可以以多种方式使用:

+ +

Service 通过一组 Pod 路由通信。Service 是一种抽象，它允许 Pod 死亡并在 Kubernetes 中复制，而不会影响应用程序。在依赖的 Pod (如应用程序中的前端和后端组件)之间进行发现和路由是由Kubernetes Service 处理的。

+ +

Service 匹配一组 Pod 是使用 标签(Label)和选择器(Selector), 它们是允许对 Kubernetes 中的对象进行逻辑操作的一种分组原语。标签(Label)是附加在对象上的键/值对，可以以多种方式使用:

    + + +
  • 指定用于开发，测试和生产的对象
  • 嵌入版本标签
  • 使用 Label 将对象进行分类
    • @@ -83,7 +108,8 @@ weight: 10
-

你也可以在创建 Deployment 的同时用 --expose创建一个 Service 。

+ +

你也可以在创建 Deployment 的同时用 --expose创建一个 Service 。

@@ -98,13 +124,15 @@ weight: 10
-

Label 可以在创建时或之后附加到对象上。他们可以随时被修改。现在使用 Service 发布我们的应用程序并添加一些 Label 。

+ +

标签(Label)可以在创建时或之后附加到对象上。他们可以随时被修改。现在使用 Service 发布我们的应用程序并添加一些 Label 。


- 开始交互式教程› + + 开始交互式教程›
From 781b13b38d071f271f11c08983139c649cf3afa5 Mon Sep 17 00:00:00 2001 From: Tim Bannister Date: Sun, 14 Jun 2020 19:51:51 +0100 Subject: [PATCH 08/19] Warn from make if submodules are not initialized If you forget to "git submodule update --init --recursive" before running a local preview, the error from Hugo is cryptic. Add a more helpful warning. --- Makefile | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/Makefile b/Makefile index be53b5eac9..4957ac3ba2 100644 --- a/Makefile +++ b/Makefile @@ -17,12 +17,15 @@ CCEND=\033[0m help: ## Show this help. @awk 'BEGIN {FS = ":.*?## "} /^[a-zA-Z_-]+:.*?## / {sub("\\\\n",sprintf("\n%22c"," "), $$2);printf "\033[36m%-20s\033[0m %s\n", $$1, $$2}' $(MAKEFILE_LIST) +module-check: + @git submodule status --recursive | awk '/^[+-]/ {printf "\033[31mWARNING\033[0m Submodule not initialized: \033[34m%s\033[0m\n",$$2}' 1>&2 + all: build ## Build site with production settings and put deliverables in ./public -build: ## Build site with production settings and put deliverables in ./public +build: module-check ## Build site with production settings and put deliverables in ./public hugo --minify -build-preview: ## Build site with drafts and future posts enabled +build-preview: module-check ## Build site with drafts and future posts enabled hugo --buildDrafts --buildFuture deploy-preview: ## Deploy preview site via netlify @@ -39,7 +42,7 @@ production-build: build check-headers-file ## Build the production site and ensu non-production-build: ## Build the non-production site, which adds noindex headers to prevent indexing hugo --enableGitInfo -serve: ## Boot the development server. +serve: module-check ## Boot the development server. hugo server --buildFuture docker-image: @@ -60,10 +63,10 @@ container-image: --tag $(CONTAINER_IMAGE) \ --build-arg HUGO_VERSION=$(HUGO_VERSION) -container-build: +container-build: module-check $(CONTAINER_RUN) $(CONTAINER_IMAGE) hugo -container-serve: +container-serve: module-check $(CONTAINER_RUN) --mount type=tmpfs,destination=/src/resources,tmpfs-mode=0755 -p 1313:1313 $(CONTAINER_IMAGE) hugo server --buildFuture --bind 0.0.0.0 test-examples: @@ -81,4 +84,3 @@ docker-internal-linkcheck: container-internal-linkcheck: link-checker-image-pull $(CONTAINER_RUN) $(CONTAINER_IMAGE) hugo --config config.toml,linkcheck-config.toml --buildFuture $(CONTAINER_ENGINE) run --mount type=bind,source=$(CURDIR),target=/test --rm wjdp/htmltest htmltest - From 3028119b68f97eea3463399e901eb7efeb8088de Mon Sep 17 00:00:00 2001 From: Enrique Medina Montenegro Date: Fri, 26 Jun 2020 14:34:47 +0200 Subject: [PATCH 09/19] --amend --- .../workloads/controllers/deployment.md | 112 +++++++++--------- 1 file changed, 56 insertions(+), 56 deletions(-) diff --git a/content/es/docs/concepts/workloads/controllers/deployment.md b/content/es/docs/concepts/workloads/controllers/deployment.md index 6a717481f7..b92c675921 100644 --- a/content/es/docs/concepts/workloads/controllers/deployment.md +++ b/content/es/docs/concepts/workloads/controllers/deployment.md @@ -1,9 +1,9 @@ --- -title: Despliegues +title: Deployment feature: - title: Despliegues y retrocesiones automáticos + title: Despliegues y _rollback_ automáticos description: > - Kubernetes despliega los cambios a tu aplicación o su configuración de forma progresiva mientras monitoriza la salud de la aplicación para asegurarse que no elimina todas tus instancias al mismo tiempo. Si algo sale mal, Kubernetes retrocederá el cambio por ti. Aprovéchate del creciente ecosistema de soluciones de despliegue. + Kubernetes despliega los cambios a tu aplicación o su configuración de forma progresiva mientras monitoriza la salud de la aplicación para asegurarse que no elimina todas tus instancias al mismo tiempo. Si algo sale mal, Kubernetes revertirá el cambio por ti. Aprovéchate del creciente ecosistema de soluciones de despliegue. content_template: templates/concept weight: 30 @@ -14,11 +14,11 @@ weight: 30 Un controlador de _Deployment_ proporciona actualizaciones declarativas para los [Pods](/docs/concepts/workloads/pods/pod/) y los [ReplicaSets](/docs/concepts/workloads/controllers/replicaset/). -Cuando describes el _estado deseado_ en un objeto Deployment, el controlador del Deployment se encarga de cambiar el estado actual al estado deseado de forma controlada. +Cuando describes el _estado deseado_ en un objeto Deployment, el controlador del Deployment se encarga de cambiar el estado actual al estado deseado de forma controlada. Puedes definir Deployments para crear nuevos ReplicaSets, o eliminar Deployments existentes y adoptar todos sus recursos con nuevos Deployments. {{< note >}} -No deberías gestionar directamente los ReplicaSets que pertenecen a un Deployment. +No deberías gestionar directamente los ReplicaSets que pertenecen a un Deployment. Todos los casos de uso deberían cubrirse manipulando el objeto Deployment. Considera la posibilidad de abrir un incidente en el repositorio principal de Kubernetes si tu caso de uso no está soportado por el motivo que sea. {{< /note >}} @@ -64,7 +64,7 @@ En este ejemplo: * El campo `template` contiene los siguientes sub-campos: * Los Pods se etiquetan como `app: nginx` usando el campo `labels`. * La especificación de la plantilla Pod, o el campo `.template.spec`, indica - que los Pods ejecutan un contenedor, `nginx`, que utiliza la versión 1.7.9 de la imagen de `nginx` de + que los Pods ejecutan un contenedor, `nginx`, que utiliza la versión 1.7.9 de la imagen de `nginx` de [Docker Hub](https://hub.docker.com/). * Crea un contenedor y lo llamar `nginx` usando el campo `name`. * Ejecuta la imagen `nginx` en su versión `1.7.9`. @@ -77,7 +77,7 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml ``` {{< note >}} -Debes indicar el parámetro `--record` para registrar el comando ejecutado en la anotación de recurso `kubernetes.io/change-cause`. +Debes indicar el parámetro `--record` para registrar el comando ejecutado en la anotación de recurso `kubernetes.io/change-cause`. Esto es útil para futuras introspecciones, por ejemplo para comprobar qué comando se ha ejecutado en cada revisión del Deployment. {{< /note >}} @@ -119,7 +119,7 @@ NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE nginx-deployment 3 3 3 3 18s ``` -Fíjate que el Deployment ha creado todas las tres réplicas, y que todas las réplicas están actualizadas (contienen +Fíjate que el Deployment ha creado todas las tres réplicas, y que todas las réplicas están actualizadas (contienen la última plantilla Pod) y están disponibles (el estado del Pod tiene el valor Ready al menos para el campo `.spec.minReadySeconds` del Deployment). Para ver el ReplicaSet (`rs`) creado por el Deployment, ejecuta el comando `kubectl get rs`: @@ -129,7 +129,7 @@ NAME DESIRED CURRENT READY AGE nginx-deployment-75675f5897 3 3 3 18s ``` -Fíjate que el nombre del ReplicaSet siempre se formatea con el patrón `[DEPLOYMENT-NAME]-[RANDOM-STRING]`. La cadena aleatoria se +Fíjate que el nombre del ReplicaSet siempre se formatea con el patrón `[DEPLOYMENT-NAME]-[RANDOM-STRING]`. La cadena aleatoria se genera de forma aleatoria y usa el pod-template-hash como semilla. Para ver las etiquetas generadas automáticamente en cada pod, ejecuta el comando `kubectl get pods --show-labels`. Se devuelve la siguiente salida: @@ -145,7 +145,7 @@ El ReplicaSet creado garantiza que hay tres Pods de `nginx` ejecutándose en tod {{< note >}} En un Deployment, debes especificar un selector apropiado y etiquetas de plantilla Pod (en este caso, -`app: nginx`). No entremezcles etiquetas o selectores con otros controladores (incluyendo otros Deployments y StatefulSets). +`app: nginx`). No entremezcles etiquetas o selectores con otros controladores (incluyendo otros Deployments y StatefulSets). Kubernetes no te impide que lo hagas, pero en el caso de que múltiples controladores tengan selectores mezclados, dichos controladores pueden entrar en conflicto y provocar resultados inesperados. {{< /note >}} @@ -157,7 +157,7 @@ No cambies esta etiqueta. La etiqueta `pod-template-hash` es añadida por el controlador del Deployment a cada ReplicaSet que el Deployment crea o adopta. -Esta etiqueta garantiza que todos los hijos ReplicaSets de un Deployment no se entremezclan. Se genera mediante una función hash aplicada al `PodTemplate` del ReplicaSet +Esta etiqueta garantiza que todos los hijos ReplicaSets de un Deployment no se entremezclan. Se genera mediante una función hash aplicada al `PodTemplate` del ReplicaSet y usando el resultado de la función hash como el valor de la etiqueta que se añade al selector del ReplicaSet, en las etiquetas de la plantilla Pod, y en cualquier Pod existente que el ReplicaSet tenga. @@ -165,7 +165,7 @@ y en cualquier Pod existente que el ReplicaSet tenga. {{< note >}} El lanzamiento de un Deployment se activa si y sólo si la plantilla Pod del Deployment (esto es, `.spec.template`) -se cambia, por ejemplo si se actualiza las etiquetas o las imágenes de contenedor de la plantilla. +se cambia, por ejemplo si se actualiza las etiquetas o las imágenes de contenedor de la plantilla. Otras actualizaciones, como el escalado del Deployment, no conllevan un lanzamiento de despliegue. {{< /note >}} @@ -238,7 +238,7 @@ nginx-deployment-1564180365-z9gth 1/1 Running 0 14s La próxima vez que quieras actualizar estos Pods, sólo necesitas actualizar la plantilla Pod del Deployment otra vez. -El Deployment permite garantizar que sólo un número determinado de Pods puede eliminarse mientras se están actualizando. +El Deployment permite garantizar que sólo un número determinado de Pods puede eliminarse mientras se están actualizando. Por defecto, garantiza que al menos el 25% menos del número deseado de Pods se está ejecutando (máx. 25% no disponible). El Deployment tmabién permite garantizar que sólo un número determinado de Pods puede crearse por encima del número deseado de @@ -294,7 +294,7 @@ Events: Aquí puedes ver que cuando creaste por primera vez el Deployment, este creó un ReplicaSet (nginx-deployment-2035384211) y lo escaló a 3 réplicas directamente. Cuando actualizaste el Deployment, creó un nuevo ReplicaSet (nginx-deployment-1564180365) y lo escaló a 1 y entonces escaló el viejo ReplicaSet a 2, de forma que al menos -hubiera 2 Pods disponibles y como mucho 4 Pods en total en todo momento. Entonces, continuó escalando +hubiera 2 Pods disponibles y como mucho 4 Pods en total en todo momento. Entonces, continuó escalando el nuevo y el viejo ReplicaSet con la misma estrategia de actualización continua. Finalmente, el nuevo ReplicaSet acaba con 3 réplicas disponibles, y el viejo ReplicaSet se escala a 0. @@ -302,7 +302,7 @@ disponibles, y el viejo ReplicaSet se escala a 0. Cada vez que el controlador del Deployment observa un nuevo objeto de despliegue, se crea un ReplicaSet para arrancar los Pods deseados si es que no existe otro ReplicaSet haciéndolo. Los ReplicaSet existentes que controlan los Pods cuyas etiquetas -coinciden con el valor del campo `.spec.selector`, pero cuya plantilla no coincide con el valor del campo `.spec.template` se reducen. Al final, +coinciden con el valor del campo `.spec.selector`, pero cuya plantilla no coincide con el valor del campo `.spec.template` se reducen. Al final, el nuevo ReplicaSet se escala hasta el valor del campo `.spec.replicas` y todos los viejos ReplicaSets se escalan a 0. Si actualizas un Deployment mientras otro despliegue está en curso, el Deployment creará un nuevo ReplicaSet @@ -311,8 +311,8 @@ como consecuencia de la actualización y comenzará a escalarlo, y sobrescribir Por ejemplo, supongamos que creamos un Deployment para crear 5 réplicas de `nginx:1.7.9`, pero entonces actualizamos el Deployment para crear 5 réplicas de `nginx:1.9.1` cuando sólo se ha creado 3 -réplicas de `nginx:1.7.9`. En este caso, el Deployment comenzará automáticamente a matar los 3 Pods de `nginx:1.7.9` -que había creado, y empezará a crear los Pods de `nginx:1.9.1`. Es decir, no esperará a que se creen las 5 réplicas de `nginx:1.7.9` +réplicas de `nginx:1.7.9`. En este caso, el Deployment comenzará automáticamente a matar los 3 Pods de `nginx:1.7.9` +que había creado, y empezará a crear los Pods de `nginx:1.9.1`. Es decir, no esperará a que se creen las 5 réplicas de `nginx:1.7.9` antes de aplicar la nueva configuración. ### Actualizaciones del selector de etiquetas @@ -330,19 +330,19 @@ no selecciona los ReplicaSets y Pods creados con el viejo selector, lo que provo la creación de un nuevo ReplicaSet. * Las actualizaciones de selector -- esto es, cambiar el valor actual en una clave de selector -- provocan el mismo comportamiento que las adiciones. * Las eliminaciones de selector -- esto es, eliminar una clave actual del selector del Deployment -- no necesitan de cambios en las etiquetas de la plantilla Pod. -No se marca ningún ReplicaSet existente como huérfano, y no se crea ningún ReplicaSet nuevo, pero debe tenerse en cuenta que +No se marca ningún ReplicaSet existente como huérfano, y no se crea ningún ReplicaSet nuevo, pero debe tenerse en cuenta que la etiqueta eliminada todavía existe en los Pods y ReplicaSets que se están ejecutando. -## Retroceder un Deployment +## Revertir un Deployment -En ocasiones necesitas retroceder un Deployment; por ejemplo, cuando el Deployment no es estable, como cuando no para de reiniciarse. +En ocasiones necesitas revertir un Deployment; por ejemplo, cuando el Deployment no es estable, como cuando no para de reiniciarse. Por defecto, toda la historia de despliegue del Deployment se mantiene en el sistema de forma que puedes retroceder en cualquier momento (se puede modificar este comportamiento cambiando el límite de la historia de revisiones de modificaciones). {{< note >}} Cuando se lanza el despligue de un Deployment, se crea una nueva revisión. Esto quiere decir que la nueva revisión se crea si y sólo si la plantilla Pod del Deployment (`.spec.template`) se cambia; -por ejemplo, si cambias las etiquetas o la imagen del contenedor de la plantilla. +por ejemplo, si cambias las etiquetas o la imagen del contenedor de la plantilla. Otras actualizaciones, como escalar el Deployment, no generan una nueva revisión del Deployment, para poder facilitar el escalado manual simultáneo - o auto-escalado. Esto significa que cuando retrocedes a una versión anterior, sólo la parte de la plantilla Pod del Deployment se retrocede. @@ -577,7 +577,7 @@ kubectl scale deployment.v1.apps/nginx-deployment --replicas=10 deployment.apps/nginx-deployment scaled ``` -Asumiendo que se ha habilitado el [escalado horizontal de pod](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) +Asumiendo que se ha habilitado el [escalado horizontal de pod](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) en tu clúster, puedes configurar un auto-escalado para tu Deployment y elegir el mínimo y máximo número de Pods que quieres ejecutar en base al uso de CPU de tus Pods actuales. @@ -591,8 +591,8 @@ deployment.apps/nginx-deployment scaled ### Escalado proporcional La actualización continua de los Deployments permite la ejecución de múltiples versiones de una aplicación al mismo tiempo. -Cuando tú o un auto-escalado escala un Deployment con actualización continua que está en medio de otro despliegue (bien en curso o pausado), -entonces el controlador del Deployment balanceará las réplicas adicionales de los ReplicaSets activos (ReplicaSets con Pods) +Cuando tú o un auto-escalado escala un Deployment con actualización continua que está en medio de otro despliegue (bien en curso o pausado), +entonces el controlador del Deployment balanceará las réplicas adicionales de los ReplicaSets activos (ReplicaSets con Pods) para así poder mitigar el riesgo. Esto se conoce como *escalado proporcional*. Por ejemplo, imagina que estás ejecutando un Deployment con 10 réplicas, donde [maxSurge](#max-surge)=3, y [maxUnavailable](#max-unavailable)=2. @@ -614,7 +614,7 @@ kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:sometag deployment.apps/nginx-deployment image updated ``` -La actualización de la imagen arranca un nuevo despliegue con el ReplicaSet nginx-deployment-1989198191, +La actualización de la imagen arranca un nuevo despliegue con el ReplicaSet nginx-deployment-1989198191, pero se bloquea debido al requisito `maxUnavailable` indicado arriba: ```shell @@ -630,10 +630,10 @@ Y entonces se origina una nueva petición de escalado para el Deployment. El aut a 15. El controlador del Deployment necesita ahora decidir dónde añadir esas nuevas 5 réplicas. Si no estuvieras usando el escalado proporcional, las 5 se añadirían al nuevo ReplicaSet. Pero con el escalado proporcional, las réplicas adicionales se distribuyen entre todos los ReplicaSets. Las partes más grandes van a los ReplicaSets -con el mayor número de réplicas y las partes más pequeñas van a los ReplicaSets con menos réplicas. Cualquier resto sobrante se añade +con el mayor número de réplicas y las partes más pequeñas van a los ReplicaSets con menos réplicas. Cualquier resto sobrante se añade al ReplicaSet con mayor número de réplicas. Aquellos ReplicaSets con 0 réplicas no se escalan. -En nuestro ejemplo anterior, se añadirán 3 réplicas al viejo ReplicaSet y 2 réplicas al nuevo ReplicaSet. +En nuestro ejemplo anterior, se añadirán 3 réplicas al viejo ReplicaSet y 2 réplicas al nuevo ReplicaSet. EL proceso de despliegue debería al final mover todas las réplicas al nuevo ReplicaSet, siempre que las nuevas réplicas arranquen positivamente. @@ -834,7 +834,7 @@ kubectl patch deployment.v1.apps/nginx-deployment -p '{"spec":{"progressDeadline ``` deployment.apps/nginx-deployment patched ``` -Una vez que se ha excedido el vencimiento, el controlador del Deployment añade una DeploymentCondition +Una vez que se ha excedido el vencimiento, el controlador del Deployment añade una DeploymentCondition con los siguientes atributos al campo `.status.conditions` del Deployment: * Type=Progressing @@ -855,7 +855,7 @@ de forma segura un Deployment en medio de un despliegue y reanudarlo sin que se {{< /note >}} Puede que notes errores transitorios en tus Deployments, bien debido a un tiempo de vencimiento muy pequeño que hayas configurado -o bien a cualquier otro tipo de error que puede considerarse como transitorio. Por ejemplo, +o bien a cualquier otro tipo de error que puede considerarse como transitorio. Por ejemplo, supongamos que no tienes suficiente cuota. Si describes el Deployment, te darás cuenta de la sección siguiente: ```shell @@ -929,7 +929,7 @@ Conditions: `Type=Available` con `Status=True` significa que tu Deployment tiene disponibilidad mínima. La disponibilidad mínima se prescribe mediante los parámetros indicados en la estrategia de despligue. `Type=Progressing` con `Status=True` significa que tu Deployment está bien en medio de un despliegue y está avanzando o bien que se ha completado de forma satisfactoria y el número mímino -requerido de nuevas réplicas ya está disponible (ver la Razón del estado para cada caso particular - en nuestro caso +requerido de nuevas réplicas ya está disponible (ver la Razón del estado para cada caso particular - en nuestro caso `Reason=NewReplicaSetAvailable` significa que el Deployment se ha completado). Puedes comprobar si un Deployment ha fallado en su avance usando el comando `kubectl rollout status`. `kubectl rollout status` @@ -964,7 +964,7 @@ por lo que tu Deployment no podrá retroceder a revisiones previas. ### Despligue Canary -Si quieres desplegar nuevas versiones a un sub-conjunto de usuarios o servidores usando el Deployment, +Si quieres desplegar nuevas versiones a un sub-conjunto de usuarios o servidores usando el Deployment, puedes hacerlo creando múltiples Deployments, uno para cada versión nueva, siguiendo el patrón canary descrito en [gestionar recursos](/docs/concepts/cluster-administration/manage-deployment/#canary-deployments). @@ -980,13 +980,13 @@ Un Deployment también necesita una [sección `.spec`](https://git.k8s.io/commun Tanto `.spec.template` como `.spec.selector` sin campos obligatorios dentro de `.spec`. -El campo `.spec.template` es una [plantilla Pod](/docs/concepts/workloads/pods/pod-overview/#pod-templates). Tiene exactamente el mismo esquema que un [Pod](/docs/concepts/workloads/pods/pod/), +El campo `.spec.template` es una [plantilla Pod](/docs/concepts/workloads/pods/pod-overview/#pod-templates). Tiene exactamente el mismo esquema que un [Pod](/docs/concepts/workloads/pods/pod/), excepto por el hecho de que está anidado y no tiene `apiVersion` ni `kind`. -Junto con los campos obligatorios de un Pod, una plantilla Pod de un Deployment debe indicar las etiquetas +Junto con los campos obligatorios de un Pod, una plantilla Pod de un Deployment debe indicar las etiquetas y las reglas de reinicio apropiadas. Para el caso de las etiquetas, asegúrate que no se entremezclan con otros controladores. Ver [selector](#selector)). -Únicamente se permite una [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) igual a `Always`, +Únicamente se permite una [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) igual a `Always`, que es el valor por defecto si no se indica. ### Réplicas @@ -1000,16 +1000,16 @@ para los Pods objetivo del deployment. `.spec.selector` debe coincidir con `.spec.template.metadata.labels`, o será descartado por la API. -A partir de la versión `apps/v1` de la API, `.spec.selector` y `.metadata.labels` no toman como valor por defecto el valor de `.spec.template.metadata.labels` si no se indica. +A partir de la versión `apps/v1` de la API, `.spec.selector` y `.metadata.labels` no toman como valor por defecto el valor de `.spec.template.metadata.labels` si no se indica. Por ello, debe especificarse de forma explícita. Además hay que mencionar que `.spec.selector` es inmutable tras la creación del Deployment en `apps/v1`. Un Deployment puede finalizar aquellos Pods cuyas etiquetas coincidan con el selector si su plantilla es diferente -de `.spec.template` o si el número total de dichos Pods excede `.spec.replicas`. Arranca nuevos +de `.spec.template` o si el número total de dichos Pods excede `.spec.replicas`. Arranca nuevos Pods con `.spec.template` si el número de Pods es menor que el número deseado. {{< note >}} -No deberías crear otros Pods cuyas etiquetas coincidan con este selector, ni directamente creando -otro Deployment, ni creando otro controlador como un ReplicaSet o un ReplicationController. Si lo haces, +No deberías crear otros Pods cuyas etiquetas coincidan con este selector, ni directamente creando +otro Deployment, ni creando otro controlador como un ReplicaSet o un ReplicationController. Si lo haces, el primer Deployment pensará que también creó esos otros Pods. Kubernetes no te impide hacerlo. {{< /note >}} @@ -1021,14 +1021,14 @@ y no se comportarán de forma correcta. `.spec.strategy` especifica la estrategia usada para remplazar los Pods viejos con los nuevos. `.spec.strategy.type` puede tener el valor "Recreate" o "RollingUpdate". "RollingUpdate" el valor predeterminado. -#### Despliegue de recreación +#### Despliegue mediante recreación Todos los Pods actuales se eliminan antes de que los nuevos se creen cuando `.spec.strategy.type==Recreate`. #### Despliegue de Actualización Continua El Deployment actualiza los Pods en modo de [actualización continua](/docs/tasks/run-application/rolling-update-replication-controller/) -cuando `.spec.strategy.type==RollingUpdate`. Puedes configurar los valores de `maxUnavailable` y `maxSurge` +cuando `.spec.strategy.type==RollingUpdate`. Puedes configurar los valores de `maxUnavailable` y `maxSurge` para controlar el proceso de actualización continua. ##### Máx. no disponible @@ -1038,29 +1038,29 @@ de Pods que pueden no estar disponibles durante el proceso de actualización. El o un porcentaje de los Pods deseados (por ejemplo, 10%). El número absoluto se calcula a partir del porcentaje con redondeo a la baja. El valor no puede ser 0 si `.spec.strategy.rollingUpdate.maxSurge` es 0. El valor predeterminado es 25%. -Por ejemplo, cuando este valor es 30%, el ReplicaSet viejo puede escalarse al 70% de los -Pods deseados de forma inmediata tras comenzar el proceso de actualización. Una vez que los Pods están listos, -el ReplicaSet viejo puede reducirse aún mas, seguido de un escalado del nuevo ReplicaSet, +Por ejemplo, cuando este valor es 30%, el ReplicaSet viejo puede escalarse al 70% de los +Pods deseados de forma inmediata tras comenzar el proceso de actualización. Una vez que los Pods están listos, +el ReplicaSet viejo puede reducirse aún mas, seguido de un escalado del nuevo ReplicaSet, asegurándose que el número total de Pods disponibles en todo momento durante la actualización es de al menos el 70% de los Pods deseados. -##### Máx. Aumento +##### Número máximo de pods por encima del número deseado `.spec.strategy.rollingUpdate.maxSurge` es un campo opcional que indica el número máximo de Pods que puede crearse por encima del número deseado de Pods. El valor puede ser un número absoluto (por ejemplo, 5) -o un porcentaje de los Pods deseados (por ejemplo, 10%). El valor no puede ser 0 si `MaxUnavailable` es 0. +o un porcentaje de los Pods deseados (por ejemplo, 10%). El valor no puede ser 0 si `MaxUnavailable` es 0. El número absoluto se calcula a partir del porcentaje con redondeo al alza. El valor predeterminado es 25%. Por ejemplo, cuando este valor es 30%, el nuevo ReplicaSet puede escalarse inmediatamente cuando -comienza la actualización continua, de forma que el número total de Pods viejos y nuevos no -excede el 130% de los Pods deseados. Una vez que los viejos Pods se han eliminado, el nuevo ReplicaSet +comienza la actualización continua, de forma que el número total de Pods viejos y nuevos no +excede el 130% de los Pods deseados. Una vez que los viejos Pods se han eliminado, el nuevo ReplicaSet puede seguir escalándose, asegurándose que el número total de Pods ejecutándose en todo momento durante la actualización es como mucho del 130% de los Pods deseados. -### Segundos para vencimiento del avance +### Segundos para vencimiento del progreso `.spec.progressDeadlineSeconds` es un campo opcional que indica el número de segundos que quieres -esperar a que tu Deployment avance antes de que el sistema reporte que dicho Deployment +esperar a que tu Deployment avance antes de que el sistema reporte que dicho Deployment [ha fallado en su avance](#failed-deployment) - expresado como un estado con `Type=Progressing`, `Status=False`. y `Reason=ProgressDeadlineExceeded` en el recurso. El controlador del Deployment seguirá intentando el despliegue. En el futuro, una vez que se implemente el retroceso automático, el controlador del Deployment @@ -1068,26 +1068,26 @@ retrocederá el despliegue en cuanto detecte ese estado. Si se especifica, este campo debe ser mayor que `.spec.minReadySeconds`. -### Segundos Mínimos para Listo +### Tiempo mínimo para considerar el Pod disponible `.spec.minReadySeconds` es un campo opcional que indica el número mínimo de segundos en que un Pod recién creado debería estar listo sin que falle ninguno de sus contenedores, para que se considere disponible. -Por defecto su valor es 0 (el Pod se considera disponible en el momento que está listo). Para aprender más acerca de +Por defecto su valor es 0 (el Pod se considera disponible en el momento que está listo). Para aprender más acerca de cuándo un Pod se considera que está listo, ver las [pruebas de contenedor](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes). ### Vuelta atrás -El campo `.spec.rollbackTo` se ha quitado de las versiones `extensions/v1beta1` y `apps/v1beta1` de la API, y ya no se permite en las versiones de la API a partir de `apps/v1beta2`. +El campo `.spec.rollbackTo` se ha quitado de las versiones `extensions/v1beta1` y `apps/v1beta1` de la API, y ya no se permite en las versiones de la API a partir de `apps/v1beta2`. En su caso, se debería usar `kubectl rollout undo`, tal y como se explicó en [Retroceder a una Revisión Previa](#rolling-back-to-a-previous-revision). -### Límite de Historia de Revisiones +### Límite del histórico de revisiones La historia de revisiones de un Deployment se almacena en los ReplicaSets que este controla. `.spec.revisionHistoryLimit` es un campo opcional que indica el número de ReplicaSets viejos a retener -para permitir los retrocesos. Estos ReplicaSets viejos consumen recursos en `etcd` y rebosan la salida de `kubectl get rs`. -La configuración de cada revisión de Deployment se almacena en sus ReplicaSets; -por lo tanto, una vez que se elimina el ReplicaSet viejo, se pierde la posibilidad de retroceder a dicha revisión del Deployment. +para permitir los retrocesos. Estos ReplicaSets viejos consumen recursos en `etcd` y rebosan la salida de `kubectl get rs`. +La configuración de cada revisión de Deployment se almacena en sus ReplicaSets; +por lo tanto, una vez que se elimina el ReplicaSet viejo, se pierde la posibilidad de retroceder a dicha revisión del Deployment. Por defecto, se retienen hasta 10 ReplicaSets viejos; pero su valor ideal depende de la frecuencia y la estabilidad de los nuevos Deployments. De forma más específica, si ponemos este campo a cero quiere decir que todos los ReplicaSets viejos con 0 réplicas se limpiarán. From 1d5c6b53e68aeeb96cfa5e8b89fba7fbc10d00cc Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Sun, 28 Jun 2020 09:56:04 +0800 Subject: [PATCH 10/19] Tune the code snippet in the list environment --- .../access-application-cluster/web-ui-dashboard.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md index 7a37fdc20b..6d7c1cced2 100644 --- a/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md +++ b/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md @@ -101,12 +101,12 @@ If needed, you can expand the **Advanced options** section where you can specify Example: -```conf -release=1.0 -tier=frontend -environment=pod -track=stable -``` + ```conf + release=1.0 + tier=frontend + environment=pod + track=stable + ``` - **Namespace**: Kubernetes supports multiple virtual clusters backed by the same physical cluster. These virtual clusters are called [namespaces](/docs/tasks/administer-cluster/namespaces/). They let you partition resources into logically named groups. From 4658821c4cc0dc6d10c0dd5663521834bb9c556f Mon Sep 17 00:00:00 2001 From: "wangjibao.lc" Date: Sun, 28 Jun 2020 10:01:12 +0800 Subject: [PATCH 11/19] update en --- ...9-03-28-running-kubernetes-locally-on-linux-with-minikube.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/blog/_posts/2019-03-28-running-kubernetes-locally-on-linux-with-minikube.md b/content/en/blog/_posts/2019-03-28-running-kubernetes-locally-on-linux-with-minikube.md index c33b805b4d..ebbf591772 100644 --- a/content/en/blog/_posts/2019-03-28-running-kubernetes-locally-on-linux-with-minikube.md +++ b/content/en/blog/_posts/2019-03-28-running-kubernetes-locally-on-linux-with-minikube.md @@ -18,7 +18,7 @@ This is post #1 in a series about the local deployment options on Linux, and it [Minikube](https://github.com/kubernetes/minikube) is a cross-platform, community-driven [Kubernetes](https://kubernetes.io/) distribution, which is targeted to be used primarily in local environments. It deploys a single-node cluster, which is an excellent option for having a simple Kubernetes cluster up and running on localhost. -Minikube is designed to be used as a virtual machine (VM), and the default VM runtime is [VirtualBox](https://www.virtualbox.org/). At the same time, extensibility is one of the critical benefits of Minikube, so it's possible to use it with [drivers](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md) outside of VirtualBox. +Minikube is designed to be used as a virtual machine (VM), and the default VM runtime is [VirtualBox](https://www.virtualbox.org/). At the same time, extensibility is one of the critical benefits of Minikube, so it's possible to use it with [drivers](https://minikube.sigs.k8s.io/docs/drivers/) outside of VirtualBox. By default, Minikube uses Virtualbox as a runtime for running the virtual machine. Virtualbox is a cross-platform solution, which can be used on a variety of operating systems, including GNU/Linux, Windows, and macOS. From e5b8dd0e4d73841675fd91a0948c42d68ef47d6c Mon Sep 17 00:00:00 2001 From: "wangjibao.lc" Date: Sun, 28 Jun 2020 10:07:01 +0800 Subject: [PATCH 12/19] update france_minikuber --- content/fr/docs/setup/learning-environment/minikube.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/fr/docs/setup/learning-environment/minikube.md b/content/fr/docs/setup/learning-environment/minikube.md index 77ddde7f4d..9b801a4453 100644 --- a/content/fr/docs/setup/learning-environment/minikube.md +++ b/content/fr/docs/setup/learning-environment/minikube.md @@ -242,9 +242,9 @@ Voir [DRIVERS](https://git.k8s.io/minikube/docs/drivers.md) pour plus de détail * vmwarefusion * kvm2 ([installation du pilote](https://git.k8s.io/minikube/docs/drivers.md#kvm2-driver)) * hyperkit ([installation du pilote](https://git.k8s.io/minikube/docs/drivers.md#hyperkit-driver)) -* hyperv ([installation du pilote](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#hyperv-driver)) +* hyperv ([installation du pilote](https://minikube.sigs.k8s.io/docs/drivers/#hyperv-driver)) Notez que l'adresse IP ci-dessous est dynamique et peut changer. Il peut être récupéré avec `minikube ip`. -* vmware ([installation du pilote](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#vmware-unified-driver)) (VMware unified driver) +* vmware ([installation du pilote](https://minikube.sigs.k8s.io/docs/drivers/#vmware-unified-driver)) (VMware unified driver) * none (Exécute les composants Kubernetes sur l’hôte et non sur une machine virtuelle. Il n'est pas recommandé d'exécuter le pilote none sur des postes de travail personnels. L'utilisation de ce pilote nécessite Docker ([docker installer](https://docs.docker.com/install/linux/docker-ce/ubuntu/)) et un environnement Linux) #### Démarrage d'un cluster sur des exécutions de conteneur alternatives From 8e9076b2ae457cf4a7ec65bef86550dc99fa1831 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Sun, 28 Jun 2020 10:41:39 +0800 Subject: [PATCH 13/19] [zh] Revise translation for notes shortcode MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Currently, the three types of notes are translated as: - `note` --> `注意：` - `caution` --> `警告:` - `warning` --> `警告：` This PR revises the translation to: - `note` --> `说明：` - `caution` --> `注意：` - `warning` --> `警告：` --- i18n/zh.toml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/i18n/zh.toml b/i18n/zh.toml index c42c53fd70..fae5bb3c15 100644 --- a/i18n/zh.toml +++ b/i18n/zh.toml @@ -2,7 +2,7 @@ # 注意：修改此文件时请维持字符串名称的字母顺序并与英文版保持一致 [caution] -other = "警告:" +other = "注意：" [cleanup_heading] other = "清理现场" @@ -164,7 +164,7 @@ other = "了解" other = "了解更多" [note] -other = "注意：" +other = "说明：" [objectives_heading] other = "教程目标" From d33dc9f1783944ff78920cea52d09d1973ed10c5 Mon Sep 17 00:00:00 2001 From: wawa Date: Sun, 28 Jun 2020 15:51:22 +0800 Subject: [PATCH 14/19] shell fix Fix missing'EOF' terminator --- .../reference/access-authn-authz/certificate-signing-requests.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/en/docs/reference/access-authn-authz/certificate-signing-requests.md b/content/en/docs/reference/access-authn-authz/certificate-signing-requests.md index d3d072ad71..576cde3d88 100644 --- a/content/en/docs/reference/access-authn-authz/certificate-signing-requests.md +++ b/content/en/docs/reference/access-authn-authz/certificate-signing-requests.md @@ -254,6 +254,7 @@ spec: request: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0KTUlJQ1ZqQ0NBVDRDQVFBd0VURVBNQTBHQTFVRUF3d0dZVzVuWld4aE1JSUJJakFOQmdrcWhraUc5dzBCQVFFRgpBQU9DQVE4QU1JSUJDZ0tDQVFFQTByczhJTHRHdTYxakx2dHhWTTJSVlRWMDNHWlJTWWw0dWluVWo4RElaWjBOCnR2MUZtRVFSd3VoaUZsOFEzcWl0Qm0wMUFSMkNJVXBGd2ZzSjZ4MXF3ckJzVkhZbGlBNVhwRVpZM3ExcGswSDQKM3Z3aGJlK1o2MVNrVHF5SVBYUUwrTWM5T1Nsbm0xb0R2N0NtSkZNMUlMRVI3QTVGZnZKOEdFRjJ6dHBoaUlFMwpub1dtdHNZb3JuT2wzc2lHQ2ZGZzR4Zmd4eW8ybmlneFNVekl1bXNnVm9PM2ttT0x1RVF6cXpkakJ3TFJXbWlECklmMXBMWnoyalVnald4UkhCM1gyWnVVV1d1T09PZnpXM01LaE8ybHEvZi9DdS8wYk83c0x0MCt3U2ZMSU91TFcKcW90blZtRmxMMytqTy82WDNDKzBERHk5aUtwbXJjVDBnWGZLemE1dHJRSURBUUFCb0FBd0RRWUpLb1pJaHZjTgpBUUVMQlFBRGdnRUJBR05WdmVIOGR4ZzNvK21VeVRkbmFjVmQ1N24zSkExdnZEU1JWREkyQTZ1eXN3ZFp1L1BVCkkwZXpZWFV0RVNnSk1IRmQycVVNMjNuNVJsSXJ3R0xuUXFISUh5VStWWHhsdnZsRnpNOVpEWllSTmU3QlJvYXgKQVlEdUI5STZXT3FYbkFvczFqRmxNUG5NbFpqdU5kSGxpT1BjTU1oNndLaTZzZFhpVStHYTJ2RUVLY01jSVUyRgpvU2djUWdMYTk0aEpacGk3ZnNMdm1OQUxoT045UHdNMGM1dVJVejV4T0dGMUtCbWRSeEgvbUNOS2JKYjFRQm1HCkkwYitEUEdaTktXTU0xMzhIQXdoV0tkNjVoVHdYOWl4V3ZHMkh4TG1WQzg0L1BHT0tWQW9FNkpsYWFHdTlQVmkKdjlOSjVaZlZrcXdCd0hKbzZXdk9xVlA3SVFjZmg3d0drWm89Ci0tLS0tRU5EIENFUlRJRklDQVRFIFJFUVVFU1QtLS0tLQo= usages: - client auth +EOF ``` Some points to note: From 26b8ceb110f20dfef94c9248a8768b2e30176baf Mon Sep 17 00:00:00 2001 From: Bertrand C <66913901+bcheronn@users.noreply.github.com> Date: Sun, 28 Jun 2020 17:35:10 +0200 Subject: [PATCH 15/19] Add UID to French glossary --- content/fr/docs/reference/glossary/uid.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 content/fr/docs/reference/glossary/uid.md diff --git a/content/fr/docs/reference/glossary/uid.md b/content/fr/docs/reference/glossary/uid.md new file mode 100644 index 0000000000..80f73c9c5c --- /dev/null +++ b/content/fr/docs/reference/glossary/uid.md @@ -0,0 +1,17 @@ +--- +title: UID +id: uid +date: 2018-04-12 +full_link: /docs/concepts/overview/working-with-objects/names +short_description: > + Chaîne de caractères générée par les systèmes Kubernetes pour identifier de manière unique les objets. + +aka: +tags: +- fundamental +--- + Chaîne de caractères générée par les systèmes Kubernetes pour identifier de manière unique les objets. + + + +Chaque objet créé pendant toute la durée de vie d'un cluster Kubernetes possède un UID distinct. Il vise à distinguer les occurrences historiques d'entités similaires. \ No newline at end of file From 6d1087fc05946dee20fd658d1a368612716b571b Mon Sep 17 00:00:00 2001 From: Zhang Yong Date: Mon, 29 Jun 2020 11:24:28 +0800 Subject: [PATCH 16/19] Remove invalid /static/images/logos --- static/images/logos/redhat_logo.png | Bin 2725 -> 0 bytes static/images/logos/soundcloud_logo.png | Bin 4039 -> 0 bytes static/images/logos/verizon_logo.png | Bin 2995 -> 0 bytes static/images/logos/viacom_logo.png | Bin 2963 -> 0 bytes static/images/logos/wepay_logo.png | Bin 3531 -> 0 bytes 5 files changed, 0 insertions(+), 0 deletions(-) delete mode 100755 static/images/logos/redhat_logo.png delete mode 100755 static/images/logos/soundcloud_logo.png delete mode 100755 static/images/logos/verizon_logo.png delete mode 100755 static/images/logos/viacom_logo.png delete mode 100755 static/images/logos/wepay_logo.png diff --git a/static/images/logos/redhat_logo.png b/static/images/logos/redhat_logo.png deleted file mode 100755 index c62e9572cba03ed11a2487876979d2505ce8eb6f..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 2725 zcmV;W3R?AvP)?GJ-nsXV5t58*b_^5!mffe+7L`ca)T2n7DLwsASZV1O36&qEA4;e#wS-EE z3Y8~?qIy<&jFL7RmWE0ynh;@L`^WdkJ>UEN-aGeBc%Gf(dTVu5rqDR&K6xe#e+N z3v(5dq;C2-qhYq{3a4jW@qq1L12IOGYblNK3Bhyd$O(kpazh632LEC{gNaymXWS&2Op0!IS7DGkK9jN6&O61()E(`T)ttizR^kyEQ7#;|g&A45!mD}dgJ5v*nv z3wWF5Db{8M^_*Ta5*k0A4&&l#htb}G4Ya~5Fb23SsnaznK;Ds%IVEvSq%q0YS38U` z#iSx_NETQKz>RjP69X8|{1h11CHgHe|DF^ccSBWFGmK%yrIz7RIpR z(#V8=(wZLhq$k}GcV&g~C&!~fXmKU$@#_OSwdd`3T6M56MiuQ~6^og{b{EP{gt&vP zS%7S34n8)q9)0Iys{=i?f7);KgI&(&A9Om97-I_k*II|$JV=(>LWeS#l^J4uz&rej zjz#Lz*TW7L#%aWCTyn)xwCmD9^A+~l)R72L)R8aq{sh%G0p>W zf-r^)onqfWI4k)(^^-bI43wO~0HajSsR-R~osI^^L$$*ks~$~gOjGLG<<1PG#PhUT zbf6#iFpw_JpX1B9oJT+IgT%)`I z{O7Y&*O}bM-lmd_P40B5Jwhi*Vbia!rSHrqU1G>@;B2?PnTyv{a94WpgeiCXo|_cl zOUAg{fNy5lmR2|K%0y94DA`GgvC{W*v)bWfg~xxC;B$m}+DNlJ_%X<72nAGuwQagg(p*R5 z&C(zZRM>Nw(A@j1OWj_7G-?Yfea3C}q^#?;S!^8Z{`5W5yx}smQOYwho|+2dX&!4Ku@?5Qj|wW1 zjF~IlOAaXY&0u1cFkT42b)NQ8$YeD}_Lx6s0_>h&X;5}Yv z0{v-A9dr08nyS~-LyDUQPZ#e?ba9_?dWs8-qbQ(|#uQRS5k)kmm}bNgvuv4d#)mOh ze!2=64+ZdrV?NIWW27*&!|_Vn^Bh}P%~^>2q%~LJaRxKU`_$Xvmg5bS-Qtz(8i-M@ z>D@ogQ%1Rc+oU*_vcWhA=;dqwGy{wu>4!^L#5~^TTf^|MoULR}Wjy(=n|=ZPI1X_t zw{jw)5f6CIHtjKQW1?xkmbfeh#tE+1lp15ZK)*(u6zIiNhH+k?&feg`_^zkqU__i8 zaKf$NVv0T9fOD}>N-1mk)h;`BWf{9YPL&Xvl)xAoq-FZIows{mqFV}#iT7G$7#xnT z9kR{upIoW?+}1+l7Bd@+i+nm;G)!_A=Lg0c16N(u(j@;Yo?&n4ap|^yDvV;X+wu!j zxRFj=#MRu(BExj)?uotM%Pl-@#{~A+U%_RLalCOS@8spcK92O9x#tFBY>_px3f9@b zHoA2;`(JU2B*iX@(1IQ`Pl56Blo+jT7Mv36ZBG6*~KiN ziRVwBXM`>aD50fO%r+D;4bgx;SN|0CcS`}ZC8zUs{YUIE~6x_aI$%zuCnxRX&lLxgq=r+?yx zCA+ka7dgkXAu%Gw1)NStE}+%&V^l}l9;ZFMIL#k?w{6imyvA$Hb|>S_M>C9tl(Cat z{KQ%oFq-qch869Y#n(Uu>zPU$M1+~lW;QR|{_-KrF-}i24`Qydwl6kJy{E`SoXzXB z@|b(ixf($f(VO!VjW_F zgKHARAdDjFM)5L9Ke~=#BHdK8AO>R;VrZ3h_DasIX%JIm6fJovYlPo1pynY=k5Py- z-ER*vu^b1dHI8dAMj@Irkav@eYH!-avs`9=uKYX3RJo8Yj9@xT_<{{=VlAb-$>a2= fjsM%znwS3v%@%5=?RF)W00000NkvXXu0mjf2=_bY diff --git a/static/images/logos/soundcloud_logo.png b/static/images/logos/soundcloud_logo.png deleted file mode 100755 index 8d2ee48e92da82771c6ea4210693dceae2b88190..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 4039 zcmeHK_dnE+1AcSH*=I%PY}vXqvbVF!&Zul6C9{ysbKI)j z{MW$$aRY5P^&J0A;_A7X(OrOq6huZ&K?$a!rlF;yXMiv=F|)8aAPRQFDNW3F8NqmR$fv0sj9l>^OxGX`i91) z=9bpB_Kwc3?w;Ph{;%H#zW*2;8vZ#l`U^icJ~25pJu^EuzwrCd;?nZU>e~9o=GOMk z?%w{v;a|eh@yY4g`Nbu16Fhkf0B8dAks9W1bK99gsTTOa_OPJb@sOcxN`%w_Q~<(^ z%()HG6v5`>#2#bDHafG+Z%iRMlGdK!RV@wDZ)QmN;k%(6{9k=7N-YfHEw|sir_%m# z102~0fIx>%t~)Kya#!~W*q}UPS7s57QZ2`%9JX3irUmG)*;f7%;9nU&oYu=dPeV09lZIP z1a{GPJWvZLzj(OM%ev-25zuzWK@=I)cZ3h8FCsNX-Mw7W>0M|nNlaNO$vX$yk1>Ls zl28MdbVqFjt(J4IsY3!!cBKc5RsM8MiaolMT~|6uJ|R8N$Dlxxb5z|riqxHq7w58E z+t-)0~Jj5O;w_K5h4<{UFuGPjYx_igK1gqh1yJ2IhB5QB9M`I}VU}xOp34 zSzX7m6i*k!W1O8GCT}~s_3=7=@P1#2G80^g&wuEiDGBwCkpITZG$Q-jS(sLO3sOto zX*x~TWe!Pa4Bspw9h*o$`P9UnX55z;&!QFi9%U%}o;97*-vnp!?I%ux?l+^G_{QDb zd%mXbBj5h+5|>L$u)uWc#|5`v2~N5+ynH_8RqwpPsbniM|7kj1Yo+=ASKSW3+-2-7TV9QNg>$XB;lCUE$ ze)a(?j?dZVC|SXc0#<*AHf79KdF%>Fe(L$2{hbU!)s_OBB!z(0}sb6MR;6<#AUnOKvSa4AEJ!eYI$My4(4^;4p&;@M0l z;+5d{mxDc$#r!(T6p%3}r%s+nx%zeLKlFI@5}nj*YBtc;nAQtf_963)EKKqzOmerL zFvzL#Psq1w8Q~Ar5mb-Wvo+9SWjPf?Z)xacoHFAJOeJG1e?1(H)G2Q_$2}!qE|KVC zu)x>5z8o-{9fr9;%WFMGHDQB!RLSY&geVFv^~ndQTA-^qf{n&e3viL%2j!hP%u! z-_pBAR(`%rNU@_@FOvMv1j4Q)c0iPzjIZk#^WZ(`7YzX@+UEfymA*@Pcge;&IW_pB z{BAzN|aMU)_zg{*$zRP}_<1OgdigD~uo8WCSlb<9o`DanERknEzseVa9c z4LAar0U{!})lEJ|sE|YekSl|BCA0z1L2L|6ZN~}&BUsF%DK*L$ z>in#ZAc1FxAwt6GHs1RV!-R$6RWt`UIRKQHY@TXJVdnBJEe;p{>mR|cSMD$O09c`za3IVPLZ2K#e;cz&pR`V} z>4u;5C!U;KKHj@c-Jc(#cX|uO`WE}v*f5eyQJ*eRaPdJ1tY@D0{~s(jA{wH2V9hLxQC&>cNnM(sVi-Jzp4AZt@fm7Shq-Q8#Y*d z{+@ZZW3zl4o|P&2;p^9EyTFZA?ob&>&AH?2Q07OMM{;2Mwu0<+`-M2#Xze>W zK^cdYAx}8if(eh{QbaMh=cAt&jV~su#I@WDOoiHvAxS)YprL1X3N$NB3{vhS3VG}#emD$YU6y@eiOk>4ybmN9g7{8rGvm)aKGlw#>_U=WR|4~CS7dG} z)5AltnE57`6_JIv+EW2bOFhDb>F%II+ob5HsF!UYvTL$TEE>|xeS+X}A)nt3?9r}9_FxB1QoIa*n(Vly%>JH7>Z z4psYyj^j%$J)LG>;hl{3$jA?gjb`g2L_d7&9fr?y9#ZENtu0URUp(dy<8e$06?ar? z4zlpri8|!|z~%$+a4dKEgTQBJ&2+s8Z#8DuGwZ7jk6%oL5oRI9-3jJ~rPMQpg+dGb zs`RXGZktMdSsMOmhf+~7tbT>aYfFW8UOBJh;t3jB=*i8O7gwh{+L?dOP&&j(5h`%& zvf(P^pb%2EzXkZV;TmkFEI$98Y`yW^%ekZsMgDZVwrEd(PLU+F&DjnbHAjRizxUFN20I4 zl>9;&YE7z~VSQozh!4|9iC);t%9Z}Erf1!`h4|SUOo(Vp9#>-M7BB-Pp})iE-Q^9q`?gsx+$nv6TF&7_zB*DRdE_Y`HN-*s3J4Yx~%4qpl`0tGX`r1aw3QdQI{{gEj BBf|gy diff --git a/static/images/logos/verizon_logo.png b/static/images/logos/verizon_logo.png deleted file mode 100755 index e4ca861a77689ec4c140e54274bcc3f51fe5b47e..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 2995 zcmeHJ_dgVlA3kZ&*`qVc$`x^E-IqUW!004khPZw!)s!gYmWMVvJiM#K$in zc=?Kuu!yMGRdMjO>k^VTq@*EG8Cf}b1sGgWNm)fz?WVehCPM2rQdVJkiH#$~CnP2%r=$|o(lau%vU76t@?RFbDtuj3TvGa`to&_7WmRSytENK%T`SG4S2=^DZ#Gxt(`Oe6^@-!lvwD9OS4Kn~Lr$Iw z*RkJ>x^5nS2tI0JWx>1RK0DplZ^H+TQ^Kj|>8ZgK>Mqe9T^Zm%=;Z{dASdi?s?*eM z^50Ag`8GF#q^2<`Ey%`d=gb>N8HyQ%eEG@I$>8Ie>8nWzkLbU5d>g(Sua3;$3<@r> zyaBxpv!Np;s-xLl!4rwuWtB_DoN~h-%6&8+_?+O)^&LkVrc%qKj(il=8WY={zf`AS zx-ARLv7A43fkT5cd9xR}IN@o&@0ih2Rn|K(rzI(vA?+#$bjyZ6o;CH5AD9v}5lUk3RZ-mh3}4C4RpNRaR9 zE8QK84m!T7Vdu%>HE+9)NDYs(<3_-f!SvJw$x!}A7?4Cw zt$Y7=FdzKLJ8mx}0fj?=%P*uoxHA`4ZmXJ|O@fkFWWZegY|0c=UzJp5!8ncTvdt7RcT10}o@e069pW*1crhVGJiUK`&3)pMdu3?R zdG{V>D@YA+4(cGBN-H4hB6#7<$O$LtwZ|V@ek7IkEHr`=h>l)|3bVQzl~XVsM+#p_ zzfQQi<+C|K1%Lq*=UvKR)$9_sD-A=Y1d<}EZHF^ltB)a~)PlTLXmWOTPH3i?E!YKQ zFlhCWXmR{8f=jz5^Mq~?v?ZvWl!{f0upN>e(Ak)HgzYXl)1L>i#JexKFOOUi+&4-W zBHcWvwjt?~u~|1_nir?XMgF#wDe5cq)m(M3;;$5Lhvghy9@Qepyaw5i^=I@7&{k~p ze9Sq8v6=JA z^G0qbh~~4%XWOro#$G1{SQXdU%;ukwPv`Q^n($YoH;?s|&zfYN)}mFa;?1%5w$aTG)_Igs1HW^Kx zTpFH3j}OCD?f*Rhf%khpmdE*+;{vwtZbMrZgp+sH+p%fqoY^y4h!I*kO=a zeH56Cg{#$t)ovN~X_SRzZq4Jh`xFdsg?wyFV5yM4Lv*4D?;InB=FgXF5d;!!(<`%4at&>kw(^*QAN^(t%az=S4#el=(^X*ncK_@bxY0-@wnT9Z5(IyiXQ(%L&YsPEJt>HKSCs5 z+ay{S()slqEEriK5Y38SFmRE}Pg-!cK+gWn68Dp1%bW=w%=Wn)Nn*SFC`27LfS1y~vuZ3#X7cSxlt1;bKUpc6R&AE#502;5w)p~>*MZ@jx z*pQ;?AkEEKMbVNuRAG&wNxaB}B#H&?MNd`c6Ns;+4x=W@5@&oSb!>tc-*R$;^>E zt2#5YoK5z(|Kt04Ua#kQet*B7AD(!WxgiKB2&AK<0~s6Xq5pN+KMMmG{$(eLae^E?+f4=*481pz@J z;fo@oV&W2)B&DQfWFd0$3W}GZO3Es#SFWn5UxUFB8c5CSTG~2#`UZwZ#wIsR&CD%O zmS`)Cwav|2wsyDe9qu?fIlEw8-Q4ebczWHt@9p!z*Uvv7FzDf<$HAdt;So8L|9rMP+r(yV|mX@p_}d7XGCDRsG5P(+PwLe4%<(1Xn zf7WR08=G6(JG*=Pe-93ij!#apn^WO*bSzfJdfJ#6>kQ=0s1+xjx) zJsR2R5JQ(DcjCtZn8qH!L&e{al+OLVzJiyvTV^qKnV=H{19Bw!kD~J>!kXMRD)*zA zTWqyMNe?jVwYs{0H8*ih&Z#qQdG z?HKd3djH61-Lotbx#9PE$qKJvodl}hmzx_m1(?{Vzhww_F2xN=zsmIL2e_}S9)?4i zGenDV>i8t)AaBk?4RLdJ*4Mkce7a#><#pWqc+Xgt_Dr}W>(#7AAu*)XE^`7v*`YZM`QXcI(n}i z@XD(;gr4L5c4=fPlTtrDme59jUDJ@_F@ZoyK*(iqB`GvMl28Zd#%)a?2l`GO&O|3S}Kh<%~;pt~QHMj}R>l!JT9TbGHCiX;Pi{+)@y1qN6mvC;3Z$SSXJY z)7)^vviz8FmosMWR8)e|+lGm1@qFbH?J*~)A^*zr*&rb0ldFY9Il%K-o6MK<#+u=3T0L`GHUu@J&tZPG# zsT}e&E+A*jLhP04;#6sP4t`gwou*<{+!f=@4!XHly{soXrv zF2aMRa^@pty2enA)`oRuRM5yhvA~KY4r|ho?_L}VFGOTyEGdLmtU%7m=5jc7-}gib zFu}P>#fPZxs*~I-RM}eMKPYTrALA!`+r+8UC7&vjGJ+pn+LK#+Ii516%aCn6T4Re= zC~XX4bcm5@=i-p$gZiq7FK;lLmx9xB3?Zobqlv>6IS_g4d*7KU;r=)+muwiF7pAF#&D&~ zG67C?UX6WRcjxcg|HYanEY*Br@|wF(NYA~bg(;%#eOT2$}IhY6S%z7 zpsBNKF!)A4@KdOq(zwBG|2$vP1Y5dFaIsL`P=_4e)!WTlKiD?G#Q$B(VO6CAiQ3WN zeqxU~ArugsnuxRB4rT{+6gqC_xCrqq$F}mD^&SVq-^a$D1>+!UziYj0mnxtyE|>(x zml3Pvs8yzS2;jH!^8Jp7a@MN0w$?!)q`)>`$lybMhsVNdJpoTvw73L6$-4d^J*Uq8 zP^;L=RVA6<2-L03Z@W)@zk#$=j+>hU540`RrEm9lB{r&#Kt&y|6WFNO*fWWBh=Khr oQwNP{GFCdjvXUCccW}mbJ{{M2vh($ diff --git a/static/images/logos/wepay_logo.png b/static/images/logos/wepay_logo.png deleted file mode 100755 index 3f5e91baaf1cc6338288688d56c714e36edd58b5..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 3531 zcmeHJ={FP(7sePeNM)3rWXU$+Cu1wJ@5`7mWE)$g!PqI=kaa4NEs>p!eVI&S8)RRz z)L5b+TPABsLa+D3`&Ycbd(OT0ocrOP`#kqN_uM24GktatFNltgj@{5e2X>Z;XD)LN za2Bb&F$HvV3`Z6waNWQE+P@6^UoyZ2EjTjB!^#~0)09}pN6911p)wT7FZ=1C5TiZLkd;33r9{f7|ee~z}fyT2=PLEo)86Qf4XvS%{qNI zrs-?_ytCkggtzXE<&FDcZCl$Rqk^L|Z)&nMwibL(;t!k6qW`E)-!$B;qxn>*_S~k) zJx8)}R6vr#D$dzVyK<^mtBUS&lGP-7DJ;eCka;3!KhN?wm&A2}0#eb!av1qwA?+02 zp9;ZWTUyNk;OqtzS%RIaNQDnnF-I>wZCAUq&QAm1s&N1kPGvOy7=>B|bqU0gXCa`( zp~vM2iPm$&-Zh}C@8#&a(`}ySHjM5PNjoL3a$+P7EGB6X8vEwW^%g0WA`!Tlf|LTj zogvqoIpy!r`ogXfqCroxWxP z-1XO5;8#`M1A6W=jxI$~LBZc!X_tf!lbg*w@dx?nd1Awh-pEFup$R4Y zYVPaQcE1|DE}MNQcrsN7_=@dSG1vRoOtfT6P3R31ShV-$x{f%LTOVO!QNjQG?ulgX zn^TM$GcHYwt45U0(CqPUfm_c39Y3ZDE`5nav>bV$8l)&{CiB)Y?qln6Ko(;x$ELJR zlo0qQg1m@bN!`PZG29zeRLDm?_$!Q~#&45qMJUaN_;KfJoo_!AIMgA!wZKee#0pTj zy!!ab9p5$Q0lQPpDlP8(PIz46BK>fB{&E00;OQ~bVF9tcgbK{|w{DepZJ)#4w=;gp z26gl8X_5~5Sk(lu32x4CGKOZh2@Qt_bwVA#lsl1^(|R-RIO-$3T7id1VoBZm@_&rv zem9)@d6#&3o&eN~EE=&R^$md<*!xe8Pg&4DGC@Q1gKH8u)2Cbv#LJot4CDDax{K#1 zqWTGv5^}Nu{a^z3B(*+?ns$lFw`XiQZPpE7j-RORu~0UEO@wn~=4WY4X%T|du-lj8 zNLyg=yy%dPjC8I7PfN66+CFE&dc7RbzK(GcbJlt2pawtgp;6Z2PO4<1_z|QOqnL4h zVl#^j^YtK1D|3ljsab-2*ssxb_fIc>$cVJGX-yB&IkIPcwNGAIFID(#$*6)fiZvpu z-9h9;u(;_N#q&*4A$b227L--fl(K;GgejsZ%Vm!!Dt1NtP82Xuok?B%KK=9NBdoP5 zuGd#6bfJ(}oMF*XwBo1V^@F80WZ66NH@TTBbd`DdVAtE}9O-OOi&J8ZI&->{#Ls;O zPOh)BoY8$^l1IjRzVZ0eAyzmSZRh97v|K@_H#c_C_$BZP<|m(4{;H~TO_+JK^ts>qd&4(SG? zLwQ2&6&!MaY%fYf1anD_Wl-$W4~f}L84^ErQ+Ya&qi(=L>vC0N3UJ$E#tE>Hsz_md z-2|+dhA9DfOx=mtJ}wtP#1W8Ytdo z9xzy%1NkiodJ%-=F@cv~3LUwJPT0ey#RupuiuYpxAyV&AUp(#S>94=Dy?Uwf45!#T zy1iK=66VHX@8FHyl{}k0q(*p>R}1YN8&Z}vdgCE`GQ?^a`Fuw7w<4|8Vj?g1!@<2X z%1%J?@0sleV+(OUP%|xB*b*J!CYM z>2?bILSLU|&bLwqCp}3D_zb7ht8R<%SXH6eE=SOZV6^y*&5M3wZTfcLi}bGL zlpT!r@cMq2b-Bs26>_c|Fv)vDdGsoek8pEBOyC%EuW<@}*a=wFS>kNAu>**lwmCq$ z7_MDRFO>VfNyD*IFghP%EnDMMS9R0vAxnqE3UrXU;|GFp@y~%rH77Vf5y9h|inROnOh$U^Y^og%041Feez!M9{`9(^;l|wv8^_dA^Q&c( z$blP?e09w@sh=vK;pc9|dXw66(6cM@vi=6teYp`FtTcgDKFl8E*~FB*w%U0RnrGSN zU>+1Gu!=LoPu<4tIpe>7fEDcM*)IJ;9Z@Qx)dr&@n&XF-TGzOD@)`eoPD1VuY%hha zM3+~ZV>&(X#9d*Yk@lz}Y9gcAL@nCA>Uc}GGjKhF-ViDNH{yzg4WnR|l&D~5 z+UCRz!Hy%n72Q8}a8U;4{S1zJW*P}FrvA}EcpWN5y1zT*dXm_8uwCQhJE&II97cEv*WLE!tBr%4vc!W zsTR=^L-DaiJkH;yYzlx;M64fa^#ucine29@u)~6?ndU~k-PF&LPk#c;5y=!f8oFw6 z{1GeWVa`=a$*h=m{K&_MuR`DP<6B#EMO-4J#Q@_8Xw>UH3lGGZdO{_Owx^m1cI`(P zm{7S^kU&O*!Zp{Gs=1{S3cYs1`DClo-bdK`N2V+l*_pxVcRjk>RIjk}_Vp;kM=*e8 z_oQTRFP(2}{2xqnbmkCqm@jT=k#-cKJ!%o9TN}F;ber1;)jDcOL27ytBU9SdqGKf4 z*T_YfJmz>l?%DwVh^y)I6^rH5S|&pZ)RX^}6#$1dsgdPJoO`>E?AKzcOud`-O-J Date: Sun, 28 Jun 2020 22:31:39 -0700 Subject: [PATCH 17/19] Correct link Chinese page viewing-and-setting-quotas --- content/zh/docs/concepts/policy/resource-quotas.md | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/content/zh/docs/concepts/policy/resource-quotas.md b/content/zh/docs/concepts/policy/resource-quotas.md index 25e92ac78d..29d222a63c 100644 --- a/content/zh/docs/concepts/policy/resource-quotas.md +++ b/content/zh/docs/concepts/policy/resource-quotas.md @@ -150,7 +150,7 @@ The following resource types are supported: In addition to the resources mentioned above, in release 1.10, quota support for [extended resources](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) is added. --> -除上述资源外，在 Kubernetes 1.10 版本中，还添加了对[扩展资源](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)的支持。 +除上述资源外，在 Kubernetes 1.10 版本中，还添加了对[扩展资源](/zh/docs/concepts/configuration/manage-resources-containers/#扩展资源-extended-resources)的支持。 查看[资源配额设计文档](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)了解更多信息。 - - From d8a8a62f08c984475bfe071b0747c0d0a330d30c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?R=C3=A9my=20L=C3=A9one?= Date: Mon, 29 Jun 2020 11:00:11 +0200 Subject: [PATCH 18/19] Fix --- content/fr/_index.html | 1 - 1 file changed, 1 deletion(-) diff --git a/content/fr/_index.html b/content/fr/_index.html index 250932ba3e..3b659534e8 100644 --- a/content/fr/_index.html +++ b/content/fr/_index.html @@ -4,7 +4,6 @@ abstract: "Déploiement, mise à l'échelle et gestion automatisée des conteneu cid: home --- - {{< blocks/section id="oceanNodes" >}} {{% blocks/feature image="flower" %}} ### [Kubernetes (K8s)]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}}) est un système open-source permettant d'automatiser le déploiement, la mise à l'échelle et la gestion des applications conteneurisées. From cdab227b2b3007023ad0167bdbbe7a514eb24deb Mon Sep 17 00:00:00 2001 From: GoodGameZoo Date: Mon, 29 Jun 2020 05:07:59 -0700 Subject: [PATCH 19/19] Update Chinese page dynamic-provisioning.md --- content/zh/docs/concepts/storage/dynamic-provisioning.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/content/zh/docs/concepts/storage/dynamic-provisioning.md b/content/zh/docs/concepts/storage/dynamic-provisioning.md index 56ae59f48a..3388a7bd6b 100644 --- a/content/zh/docs/concepts/storage/dynamic-provisioning.md +++ b/content/zh/docs/concepts/storage/dynamic-provisioning.md @@ -176,7 +176,7 @@ can enable this behavior by: is enabled on the API server. --> - 标记一个 `StorageClass` 为 *默认*； -- 确保 [`DefaultStorageClass` 准入控制器](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)在 API 服务端被启用。 +- 确保 [`DefaultStorageClass` 准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)在 API 服务端被启用。