From edad9d9e8d669d79622d8765a64d8000e775891d Mon Sep 17 00:00:00 2001 From: Enrique Medina Montenegro Date: Wed, 12 Jun 2019 16:56:34 +0200 Subject: [PATCH 001/218] Spanish Translation --- .../controllers/jobs-run-to-completion.md | 457 ++++++++++++++++++ .../workloads/controllers/replicaset.md | 370 ++++++++++++++ content/es/examples/controllers/frontend.yaml | 21 + content/es/examples/controllers/hpa-rs.yaml | 11 + content/es/examples/controllers/job.yaml | 14 + content/es/examples/pods/pod-rs.yaml | 23 + 6 files changed, 896 insertions(+) create mode 100644 content/es/docs/concepts/workloads/controllers/jobs-run-to-completion.md create mode 100644 content/es/docs/concepts/workloads/controllers/replicaset.md create mode 100644 content/es/examples/controllers/frontend.yaml create mode 100644 content/es/examples/controllers/hpa-rs.yaml create mode 100644 content/es/examples/controllers/job.yaml create mode 100644 content/es/examples/pods/pod-rs.yaml diff --git a/content/es/docs/concepts/workloads/controllers/jobs-run-to-completion.md b/content/es/docs/concepts/workloads/controllers/jobs-run-to-completion.md new file mode 100644 index 0000000000..480999af1d --- /dev/null +++ b/content/es/docs/concepts/workloads/controllers/jobs-run-to-completion.md @@ -0,0 +1,457 @@ +--- +title: Jobs - Ejecución hasta el final +content_template: templates/concept +feature: + title: Ejecución en lotes + description: > + Además de los servicios, Kubernetes puede gestionar tus trabajos por lotes y CI, sustituyendo los contenedores que fallen, si así se desea. +weight: 70 +--- + +{{% capture overview %}} + +Un Job crea uno o más Pods y se asegura de que un número específico de ellos termina de forma satisfactoria. +Conforme los pods terminan satisfactoriamente, el Job realiza el seguimiento de las ejecuciones satisfactorias. +Cuando se alcanza un número específico de ejecuciones satisfactorias, la tarea (esto es, el Job) se completa. +Al eliminar un Job se eliminan los Pods que haya creado. + +Un caso simple de uso es crear un objeto Job para que se ejecute un Pod de manera fiable hasta el final. +El objeto Job arrancará un nuevo Pod si el primer Pod falla o se elimina (por ejemplo +como consecuencia de un fallo de hardware o un reinicio en un nodo). + +También se puede usar un Job para ejecutar múltiples Pods en paralelo. + +{{% /capture %}} + + +{{% capture body %}} + +## Ejecutar un Job de ejemplo + +Aquí se muestra un ejemplo de configuración de Job. Este ejemplo calcula los primeros 2000 decimales de π y los imprime por pantalla. +Tarda unos 10s en completarse. + +{{< codenew file="controllers/job.yaml" >}} + +Puedes ejecutar el ejemplo con este comando: + +```shell +kubectl apply -f https://k8s.io/examples/controllers/job.yaml +``` +``` +job "pi" created +``` + +Comprueba el estado del Job con `kubectl`: + +```shell +kubectl describe jobs/pi +``` +``` +Name: pi +Namespace: default +Selector: controller-uid=b1db589a-2c8d-11e6-b324-0209dc45a495 +Labels: controller-uid=b1db589a-2c8d-11e6-b324-0209dc45a495 + job-name=pi +Annotations: +Parallelism: 1 +Completions: 1 +Start Time: Tue, 07 Jun 2016 10:56:16 +0200 +Pods Statuses: 0 Running / 1 Succeeded / 0 Failed +Pod Template: + Labels: controller-uid=b1db589a-2c8d-11e6-b324-0209dc45a495 + job-name=pi + Containers: + pi: + Image: perl + Port: + Command: + perl + -Mbignum=bpi + -wle + print bpi(2000) + Environment: + Mounts: + Volumes: +Events: + FirstSeen LastSeen Count From SubobjectPath Type Reason Message + --------- -------- ----- ---- ------------- -------- ------ ------- + 1m 1m 1 {job-controller } Normal SuccessfulCreate Created pod: pi-dtn4q +``` + +Para ver los Pods de un Job que se han completado, usa `kubectl get pods`. + +Para listar todos los Pods que pertenecen a un Job de forma que sea legible, puedes usar un comando como: + +```shell +pods=$(kubectl get pods --selector=job-name=pi --output=jsonpath='{.items[*].metadata.name}') +echo $pods +``` +``` +pi-aiw0a +``` + +En este caso, el selector es el mismo que el selector del Job. La opción `--output=jsonpath` indica un expresión +que simplemente obtiene el nombre de cada Pod en la lista devuelta. + +Mira la salida estándar de uno de los Pods: + +```shell +$ kubectl logs $pods +3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901 +``` + +## Escribir una especificación de Job + +Como con el resto de configuraciones de Kubernetes, un Job necesita los campos `apiVersion`, `kind`, y `metadata`. + +Un Job también necesita la [sección `.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status). + +### Plantilla Pod + +El campo `.spec.template` es el único campo obligatorio 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/user-guide/pods), +excepto por el hecho de que está anidado y no tiene el campo `apiVersion` o `kind`. + +Además de los campos olbigatorios de un Pod, una plantilla Pod de un Job debe indicar las etiquetas apropiadas +(ver [selector de pod](#pod-selector)) y una regla de reinicio apropiada. + +Sólo se permite los valores `Never` o `OnFailure` para [`RestartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy). + +### Selector de Pod + +El campo `.spec.selector` es opcional. En la práctica mayoría de los casos no deberías configurarlo. +Mira la sección sobre [configurar tu propio selector de pod](#specifying-your-own-pod-selector). + + +### Jobs en paralelo + +Hay tres tipos principales de tarea aptos para ejecutarse como un Job: + +1. Jobs no paralelos + - normalmente, sólo se arranca un Pod, a menos que el Pod falle. + - el Job se completa tan pronto como su Pod termine de forma satisfactoria. +1. Jobs en paralelo con un *cupo fijo de terminación*: + - se configura un valor positivo distinto de cero para el campo `.spec.completions`. + - el Job representa la tarea en general, y se completa cuando hay una ejecución satisfactoria de un Pod por cada valor dentro del rango de 1 a `.spec.completions`. + - **no implementado todavía:** A cada Pod se le pasa un índice diferenente dentro del rango de 1 a `.spec.completions`. +1. Jobs en paralelo con una *cola de trabajo*: + - no se especifica el campo `.spec.completions`, por defecto `.spec.parallelism`. + - los Pods deben coordinarse entre ellos mismos o a través de un servicio externo que determine quién debe trabajar en qué. + Por ejemplo, un Pod podría ir a buscar un lote de hasta N ítems de una cola de trabajo. + - cada Pod es capaz de forma independiente de determinar si sus compañeros han terminado o no, y como consecuencia el Job entero ha terminado. + - cuando _cualquier_ Pod del Job termina con éxito, no se crean nuevos Pods. + - una vez que al menos uno de los Pods ha terminado con éxito y todos los Pods han terminado, entonces el Job termina con éxito. + - una vez que cualquier Pod ha terminado con éxito, ningún otro Pod debería continuar trabajando en la misma tarea o escribiendo ningún resultado. Todos ellos deberían estar en proceso de terminarse. + +En un Job _no paralelo_, no debes indicar el valor de `.spec.completions` ni `.spec.parallelism`. Cuando ambos se dejan + sin valor, ambos se predeterminan a 1. + +En un Job con _cupo fijo de terminación_, deberías poner el valor de `.spec.completions` al número de terminaciones que se necesiten. +Puedes dar un valor a `.spec.parallelism`, o dejarlo sin valor, en cuyo caso se predetermina a 1. + +En un Job con _cola de trabajo_, no debes indicar el valor de `.spec.completions`, y poner el valor de `.spec.parallelism` a +un entero no negativo. + +Para más información acerca de cómo usar los distintos tipos de Job, ver la sección de [patrones de job](#job-patterns). + + +#### Controlar el paralelismo + +El paralelismo solicitado (`.spec.parallelism`) puede usar cualquier valor no negativo. +Si no se indica, se predeterminad a 1. +Si se indica como 0, entonces el Job se pausa de forma efectiva hasta que se incremente. + +El paralelismo actual (número de pods ejecutándose en cada momento) puede que sea mayor o menor que el solicitado, +por los siguientes motivos: + +- Para los Jobs con _cupo fijo de terminaciones_, el número actual de pods ejecutándose en paralelo no excede el número de terminaciones pendientes. + Los valores superiores de `.spec.parallelism` se ignoran. +- Para los Jobs con _cola de trabajo_, no se arranca nuevos Pods después de que cualquier Pod se haya completado -- sin embargo, se permite que se completen los Pods pendientes. +- Cuando el controlador no ha tenido tiempo para reaccionar. +- Cuando el controlador no pudo crear los Pods por el motivo que fuera (falta de `ResourceQuota`, falta de permisos, etc.), + entonces puede que haya menos pods que los solicitados. +- El controlador puede que regule la creación de nuevos Pods debido al excesivo número de fallos anteriores en el mismo Job. +- Cuando un Pod se para de forma controlada, lleva tiempo pararlo. + +## Gestionar Fallos de Pod y Contenedor + +Un contenedor de un Pod puede fallar por cualquier motivo, como porque el proceso que se estaba ejecutando termina con un código de salida distinto de cero, +o porque se mató el contenedor por exceder un límite de memoria, etc. Si esto ocurre, y se tiene +`.spec.template.spec.restartPolicy = "OnFailure"`, entonces el Pod permance en el nodo, +pero el contenedor se vuelve a ejecutar. Por lo tanto, tu aplicación debe poder gestionar el caso en que se reinicia de forma local, +o bien especificar `.spec.template.spec.restartPolicy = "Never"`. +Ver el [ciclo de vida de un pod](/docs/concepts/workloads/pods/pod-lifecycle/#example-states) para más información sobre `restartPolicy`. + +Un Pod entero puede también fallar por cualquier motivo, como cuando se expulsa al Pod del nodo +(porque el nodo se actualiza, reinicia, elimina, etc.), o si un contenedor del Pod falla +cuando `.spec.template.spec.restartPolicy = "Never"`. Cuando un Pod falla, entonces el controlador del Job +arranca un nuevo Pod. Esto quiere decir que tu aplicación debe ser capaz de gestionar el caso en que se reinicia en un nuevo pod. +En particular, debe ser capaz de gestionar los ficheros temporales, los bloqueos, los resultados incompletos, y cualquier otra dependencia +de ejecuciones previas. + +Nótese que incluso si se configura `.spec.parallelism = 1` y `.spec.completions = 1` y +`.spec.template.spec.restartPolicy = "Never"`, el mismo programa puede arrancarse dos veces. + +Si se especifica `.spec.parallelism` y `.spec.completions` con valores mayores que 1, +entonces puede que haya múltiples pods ejecutándose a la vez. Por ello, tus pods deben tolerar la concurrencia. + +### Regla de retroceso de Pod por fallo + +Hay situaciones en que quieres que el Job falle después de intentar ejecutarlo unas cuantas veces debido +a un error lógico en la configuración, etc. +Para hacerlo, pon el valor de `.spec.backoffLimit` al número de reintentos que quieres +antes de considerar el Job como fallido. El límite de retroceso se predetermina a 6. +Los Pods fallidos asociados al Job son recreados por el controlador del Job con un +retroceso exponencial (10s, 20s, 40s ...) limitado a seis minutos. El contador +de retroceso se resetea si no aparecen Pods fallidos antes del siguiente chequeo de estado del Job. + +{{< note >}} +El problema [#54870](https://github.com/kubernetes/kubernetes/issues/54870) todavía existe en las versiones de Kubernetes anteriores a la versión 1.12 +{{< /note >}} + +## Terminación y Limpieza de un Job + +Cuando un Job se completa, ya no se crea ningún Pod, pero tampoco se elimina los Pods. Guardarlos permite +ver todavía los logs de los pods acabados para comprobar errores, avisos, o cualquier otro resultado de diagnóstico. +El objeto job también se conserva una vez que se ha completado para que se pueda ver su estado. Es decisión del usuario si elimina +los viejos jobs después de comprobar su estado. Eliminar el job con el comando `kubectl` (ej. `kubectl delete jobs/pi` o `kubectl delete -f ./job.yaml`). +Cuando eliminas un job usando el comando `kubectl`, todos los pods que creó se eliminan también. + +Por defecto, un Job se ejecutará de forma ininterrumpida a menos que uno de los Pods falle, en cuyo caso el Job se fija en el valor de +`.spec.backoffLimit` descrito arriba. Otra forma de acabar un Job es poniéndole un vencimiento activo. +Haz esto poniendo el valor del campo `.spec.activeDeadlineSeconds` del Job a un número de segundos. + +El campo `activeDeadlineSeconds` se aplica a la duración del job, independientemente de cuántos Pods se hayan creado. +Una vez que el Job alcanza `activeDeadlineSeconds`, se terminan todos sus Pods y el estado del Job se pone como `type: Failed` con `reason: DeadlineExceeded`. + +Fíjate que el campo `.spec.activeDeadlineSeconds` de un Job tiene precedencia sobre el campo `.spec.backoffLimit`. +Por lo tanto, un Job que está reintentando uno o más Pods fallidos no desplegará nuevos Pods una vez que alcance el límite de tiempo especificado por `activeDeadlineSeconds`, +incluso si todavía no se ha alcanzado el `backoffLimit`. + +Ejemplo: + +```yaml +apiVersion: batch/v1 +kind: Job +metadata: + name: pi-with-timeout +spec: + backoffLimit: 5 + activeDeadlineSeconds: 100 + template: + spec: + containers: + - name: pi + image: perl + command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] + restartPolicy: Never +``` + +Fíjate que tanto la especificación del Job como la [especificación de la plantilla Pod](/docs/concepts/workloads/pods/init-containers/#detailed-behavior) +dentro del Job tienen un campo `activeDeadlineSeconds`. Asegúrate que pones el valor de este campo de forma adecuada. + +## Limpiar los Jobs terminados automáticamente + +Normalmente, los Jobs que han terminado ya no se necesitan en el sistema. Conservarlos sólo añade +más presión al servidor API. Si dichos Jobs no se gestionan de forma directa por un controlador de más alto nivel, +como los [CronJobs](/docs/concepts/workloads/controllers/cron-jobs/), los Jobs pueden +limpiarse por medio de CronJobs en base a la regla de limpieza basada en capacidad que se haya especificado. + +### Mecanismo TTL para Jobs terminados + +{{< feature-state for_k8s_version="v1.12" state="alpha" >}} + +Otra forma de limpiar los Jobs terminados (bien `Complete` o `Failed`) +de forma automática es usando un mecanismo TTL proporcionado por un +[controlador TTL](/docs/concepts/workloads/controllers/ttlafterfinished/) de recursos finalizados, +indicando el valor `.spec.ttlSecondsAfterFinished` del Job. + +Cuando el controlador TTL limpia el Job, lo eliminará en cascada, +esto es, eliminará sus objetos subordinados, como Pods, junto con el Job. Nótese +que cuando se elimina el Job, sus garantías de ciclo de vida, como los finalizadores, +se tendrán en cuenta. + +Por ejemplo: + +```yaml +apiVersion: batch/v1 +kind: Job +metadata: + name: pi-with-ttl +spec: + ttlSecondsAfterFinished: 100 + template: + spec: + containers: + - name: pi + image: perl + command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] + restartPolicy: Never +``` + +Aquí el Job `pi-with-ttl` será candidato a ser automáticamente eliminado, `100` +segundos después de que termine. + +Si el campo se pone a `0`, el Job será candidato a ser automáticamente eliminado +inmediatamente después de haber terminado. Si no se pone valor al campo, este Job no será eliminado +por el controlador TTL una vez concluya. + +Nótese que este mecanismo TTL está todavía en alpha, a través de la característica denominada `TTLAfterFinished`. +Para más información, ver la documentación del [controlador TTL](/docs/concepts/workloads/controllers/ttlafterfinished/) para +recursos terminados. + +## Patrones de Job + +El objeto Job puede usarse para dar soporte a la ejecución fiable de Pods en paralelo. El objeto Job +no se diseñó para dar soporte a procesos paralelos estrechamente comunicados, como los que comúnmente +se encuentran en la computación científica. Eso sí, permite el proceso paralelo de un conjunto de *ítems de trabajo* independientes, pero relacionados entre sí. +Estos pueden ser correos a enviar, marcos a renderizar, archivos a codificar, rangos de claves en una base de datos NoSQL a escanear, y demás. + +En un sistema complejo, puede haber múltiples diferentes conjuntos de ítems de trabajo. Aquí sólo se está +considerando un conjunto de ítems de trabajo que el usuario quiere gestionar de forma conjunta — un *proceso por lotes*. + +Hay varios patrones diferentes para computación en paralelo, cada uno con sus fortalezas y sus debilidades. +Los sacrificios a tener en cuenta son: + +- Un objeto Job para cada ítem de trabajo vs. un objeto Job simple para todos los ítems de trabajo. El último es mejor + para grandes números de ítems de trabajo. El primero añade sobrecarga para el usuario y para el sistema + al tener que gestionar grandes números de objetos Job. +- El número de pods creados es igual al número de ítems de trabajo vs. cada Pod puede procesar múltiplese ítems de trabajo. + El primero típicamente requiere menos modificaciones al código existente y a los contenedores. + El último es mejor cuanto mayor sea el número de ítems de trabajo, por las mismas razones que antes.. +- Varios enfoques usan una cola de trabajo. Ello requiere ejecutar un servicio de colas, + y modificaciones a las aplicaciones o contenedores existentes para que hagan uso de la cola de trabajo. + Otras estrategias son más fáciles de adaptar a una aplicación ya usando contenedores. + + +Los sacrificios a tener en cuenta se indican a continuación, donde las columnas 2 a 4 representan los sacrificios de arriba. +Los nombres de los patrones son también enlaces a ejemplos e información más detallada. + +| Patrón | Objeto Job simple | ¿Menos pods que ítems de trabajo? | ¿No modificar la aplicación? | ¿Funciona en Kube 1.1? | +| -------------------------------------------------------------------- |:-----------------:|:---------------------------:|:-------------------:|:-------------------:| +| [Extensión de la Plantilla Job](/docs/tasks/job/parallel-processing-expansion/) | | | ✓ | ✓ | +| [Cola con Pod por Ítem de Trabajo](/docs/tasks/job/coarse-parallel-processing-work-queue/) | ✓ | | a veces | ✓ | +| [Cola con Cuenta Variable de Pods](/docs/tasks/job/fine-parallel-processing-work-queue/) | ✓ | ✓ | | ✓ | +| Job simple con Asignación Estática de Trabajo | ✓ | | ✓ | | + +Cuando se especifican terminaciones con `.spec.completions`, cada Pod creado por el controlado del Job +tiene un [`spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)idéntico. +Esto significa que todos los pods de una tarea tendrán la misma línea de comandos y la +misma imagne, los mismo volúmenes, y (casi) las mismas variables de entorno. +Estos patrones otorgan diferentes formas de organizar los pods para que trabajen en cosas distintas. + +Esta tabla muestra la configuración necesaria para `.spec.parallelism` y `.spec.completions` para cada uno de los patrones. +Aquí, `T` es el número de ítems de trabajo. + +| Patrón | `.spec.completions` | `.spec.parallelism` | +| -------------------------------------------------------------------- |:-------------------:|:--------------------:| +| [Extensión de la Plantilla Job](/docs/tasks/job/parallel-processing-expansion/) | 1 | debería ser 1 | +| [Cola con Pod por Ítem de Trabajo](/docs/tasks/job/coarse-parallel-processing-work-queue/) | T | cualquiera | +| [Cola con Cuenta Variable de Pods](/docs/tasks/job/fine-parallel-processing-work-queue/) | 1 | cualquiera | +| Job simple con Asignación Estática de Trabajo | T | cualquiera | + + +## Uso Avanzado + +### Especificar tu propio selector de pod + +Normalmente, cuando creas un objeto Job, no especificas el campo `.spec.selector`. +La lógica por defecto del sistema añade este campo cuando se crea el Job. +Se elige un valor de selector que no se entremezcle con otras tareas. + +Sin embargo, en algunos casos, puede que necesites sobreescribir este selector que se configura de forma automática. +Para ello, puedes indicar el valor de `.spec.selector` en el Job. + +Pero ten mucho cuidado cuando lo hagas. Si configuras un selector de etiquta que no + es único para los pods de ese Job, y que selecciona Pods que no tienen que ver, + entonces estos últimos pueden ser eliminados, o este Job puede contar los otros + Pods para terminarse, o uno o ambos Jobs pueden negarse a crear Pods o ejecutarse hasta el final. + Si se elige un selector que no es único, entonces otros controladores (ej. ReplicationController) + y sus Pods puede comportarse de forma impredecibles también. Kubernetes no te impide cometer un error + especificando el `.spec.selector`. + +Aquí se muestra un ejemplo de un caso en que puede que necesites usar esta característica. + +Digamos que el Job `viejo` todavía está ejeuctándose. Quieres que los Pods existentes +sigan corriendo, pero quieres que el resto de los Pods que se creen +usen una plantilla pod diferente y que el Job tenga un nombre nuevo. +Como no puedes modificar el Job porque esos campos no son modificables, eliminas el Job `old`, + pero _dejas sus pods ejecutándose_ mediante el comando `kubectl delete jobs/old --cascade=false`. +Antes de eliminarlo, apúntate el selector actual que está usando: + +``` +kind: Job +metadata: + name: viejo + ... +spec: + selector: + matchLabels: + job-uid: a8f3d00d-c6d2-11e5-9f87-42010af00002 + ... +``` + +Entonces, creas un nuevo Job con el nombre `nuevo` y le configuras explícitamente el mismo selector. +Puesto que los Pods existentes tienen la etiqueta `job-uid=a8f3d00d-c6d2-11e5-9f87-42010af00002`, +son controlados por el Job `nuevo` igualmente. + +Necesitas configurar `manualSelector: true` en el nuevo Job, ya qye no estás usando + el selector que normalmente se genera de forma automática por el sistema. + +``` +kind: Job +metadata: + name: nuevo + ... +spec: + manualSelector: true + selector: + matchLabels: + job-uid: a8f3d00d-c6d2-11e5-9f87-42010af00002 + ... +``` + +El mismo Job nuevo tendrá un uid distinto a `a8f3d00d-c6d2-11e5-9f87-42010af00002`. +Poniendo `manualSelector: true` le dice al sistema que sabes lo que estás haciendo + y que te permita hacer este desajuste. + +## Alternativas + +### Pods simples + +Cuando el nodo donde un Pod simple se estaba ejecutando se reinicia o falla, dicho pod se termina +y no será reinicado. Sin embargo, un Job creará nuevos Pods para sustituir a los que se han terminando. +Por esta razón, se recomienda que se use un Job en vez de un Pod simple, incluso si tu aplicación +sólo necesita un único Pod. + +### Replication Controller + +Los Jobs son complementarios a los [Replication Controllers](/docs/user-guide/replication-controller). +Un Replication Controller gestiona aquellos Pods que se espera que no terminen (ej. servidores web), y un Job +gestiona aquellos Pods que se espera que terminen (ej. tareas por lotes). + +Como se discutió en el [Ciclo de vida de un Pod](/docs/concepts/workloads/pods/pod-lifecycle/), un `Job` *sólo* es apropiado +para aquellos pods con `RestartPolicy` igual a `OnFailure` o `Never`. +(Nota: Si `RestartPolicy` no se pone, el valor predeterminado es `Always`.) + +### Job simple arranca que arranca un controlador de Pod + +Otro patrón es aquel donde un Job simple crea un Pod que, a su vez, crea otros Pods, actuando como una especie +de controlador personalizado para esos Pods. Esto da la máxima flexibilidad, pero puede que +cueste un poco más de entender y ofrece menos integración con Kubernetes. + +Un ejemplo de este patrón sería un Job que arranca un Pod que ejecuta una secuencia de comandos que, a su vez, +arranca un controlador maestro de Spark (ver el [ejemplo de spark](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/spark/README.md)), +ejecuta un manejador de spark, y a continuación lo limpia todo. + +Una ventaja de este enfoque es que el proceso general obtiene la garantía del objeto Job, +además del control completo de los Pods que se crean y cómo se les asigna trabajo. + +## Cron Jobs {#cron-jobs} + +Puedes utilizar un [`CronJob`](/docs/concepts/workloads/controllers/cron-jobs/) para crear un Job que se ejecute en una hora/fecha determinadas, de forma similar +a la herramienta `cron` de Unix. + +{{% /capture %}} diff --git a/content/es/docs/concepts/workloads/controllers/replicaset.md b/content/es/docs/concepts/workloads/controllers/replicaset.md new file mode 100644 index 0000000000..a8a92c7860 --- /dev/null +++ b/content/es/docs/concepts/workloads/controllers/replicaset.md @@ -0,0 +1,370 @@ +--- +title: ReplicaSet +content_template: templates/concept +weight: 10 +--- + +{{% capture overview %}} + +El objeto de un ReplicaSet es el de mantener un conjunto estable de réplicas de Pods ejecutándose +en todo momento. Así, se usa en numerosas ocasiones para garantizar la disponibilidad de un +número específico de Pods idénticos. + + +{{% /capture %}} + +{{% capture body %}} + +## Cómo funciona un ReplicaSet + +Un ReplicaSet se define con campos, incluyendo un selector que indica cómo identificar a los Pods que puede adquirir, +un número de réplicas indicando cuántos Pods debería gestionar, y una plantilla pod especificando los datos de los nuevos Pods +que debería crear para conseguir el número de réplicas esperado. Un ReplicaSet alcanza entonces su propósito + mediante la creación y eliminación de los Pods que sea necesario para alcanzar el número esperado. + Cuando un ReplicaSet necesita crear nuevos Pods, utiliza su plantilla Pod. + +El enlace que un ReplicaSet tiene hacia sus Pods es a través del campo del Pod denominado [metadata.ownerReferences](/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents), +el cual indica qué recurso es el propietario del objeto actual. Todos los Pods adquiridos por un ReplicaSet tienen su propia +información de identificación del ReplicaSet en su campo ownerReferences. Y es a través de este enlace +cómo el ReplicaSet conoce el estado de los Pods que está gestionando y actúa en consecuencia. + +Un ReplicaSet identifica los nuevos Pods a adquirir usando su selector. Si hay un Pod que no tiene OwnerReference +o donde OwnerReference no es un controlador, pero coincide con el selector del ReplicaSet, +este será inmediatamente adquirido por dicho ReplicaSet. + +## Cuándo usar un ReplicaSet + +Un ReplicaSet garantiza que un número específico de réplicas de un pod se está ejeuctando en todo momento. +Sin embargo, un Deployment es un concepto de más alto nivel que gestiona ReplicaSets y +proporciona actualizaciones de forma declarativa de los Pods junto con muchas otras características útiles. +Por lo tanto, se recomienda el uso de Deployments en vez del uso directo de ReplicaSets, a no ser +que se necesite una orquestración personalizada de actualización o no se necesite las actualizaciones en absoluto. + +En realidad, esto quiere decir que puede que nunca necesites manipular los objetos ReplicaSet: +en vez de ello, usa un Deployment, y define tu aplicación en la sección spec. + +## Ejemplo + +{{< codenew file="controllers/frontend.yaml" >}} + +Si guardas este manifiesto en un archivo llamado `frontend.yaml` y lo lanzas en un clúster de Kubernetes, + se creará el ReplicaSet definido y los Pods que maneja. + +```shell +kubectl apply -f http://k8s.io/examples/controllers/frontend.yaml +``` + +Puedes ver los ReplicaSets actuales desplegados: +```shell +kubectl get rs +``` + +Y ver el frontend que has creado: +```shell +NAME DESIRED CURRENT READY AGE +frontend 3 3 3 6s +``` + +También puedes comprobar el estado del replicaset: +```shell +kubectl describe rs/frontend +``` + +Y verás una salida parecida a la siguiente: +```shell +Name: frontend +Namespace: default +Selector: tier=frontend,tier in (frontend) +Labels: app=guestbook + tier=frontend +Annotations: +Replicas: 3 current / 3 desired +Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed +Pod Template: + Labels: app=guestbook + tier=frontend + Containers: + php-redis: + Image: gcr.io/google_samples/gb-frontend:v3 + Port: 80/TCP + Requests: + cpu: 100m + memory: 100Mi + Environment: + GET_HOSTS_FROM: dns + Mounts: + Volumes: +Events: + FirstSeen LastSeen Count From SubobjectPath Type Reason Message + --------- -------- ----- ---- ------------- -------- ------ ------- + 1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-qhloh + 1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-dnjpy + 1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-9si5l +``` + +Y por último, puedes comprobar los Pods que ha arrancado: +```shell +kubectl get Pods +``` + +Deberías ver la información de cada Pod similar a: +```shell +NAME READY STATUS RESTARTS AGE +frontend-9si5l 1/1 Running 0 1m +frontend-dnjpy 1/1 Running 0 1m +frontend-qhloh 1/1 Running 0 1m +``` + +También puedes verificar que la referencia de propietario de dichos pods está puesta al ReplicaSet frontend. +Para ello, obtén el yaml de uno de los Pods ejecutándose: +```shell +kubectl get pods frontend-9si5l -o yaml +``` + +La salida será parecida a esta, donde la información sobre el ReplicaSet aparece en el campo ownerReferences de los metadatos: +```shell +apiVersion: v1 +kind: Pod +metadata: + creationTimestamp: 2019-01-31T17:20:41Z + generateName: frontend- + labels: + tier: frontend + name: frontend-9si5l + namespace: default + ownerReferences: + - apiVersion: extensions/v1beta1 + blockOwnerDeletion: true + controller: true + kind: ReplicaSet + name: frontend + uid: 892a2330-257c-11e9-aecd-025000000001 +... +``` + +## Adquisiciones de Pods fuera de la plantilla + +Aunque puedes crear Pods simples sin problemas, se recomienda encarecidamente asegurarse de que dichos Pods no tienen +etiquetas que puedan coincidir con el selector de alguno de tus ReplicaSets. +La razón de esta recomendación es que un ReplicaSet no se limita a poseer los Pods +especificados en su plantilla -- sino que puede adquirir otros Pods como se explicó en secciones anteriores. + +Toma el ejemplo anterior del ReplicaSet frontend, y los Pods especificados en el siguiente manifiesto: + +{{< codenew file="pods/pod-rs.yaml" >}} + +Como estos Pods no tienen un Controlador (o cualquier otro objeto) como referencia de propietario +y como además su selector coincide con el del ReplicaSet frontend, este último los terminará adquiriendo de forma inmediata. + +Supón que creas los Pods después de que el ReplicaSet frontend haya desplegado los suyos +para satisfacer su requisito de cuenta de réplicas: + +```shell +kubectl apply -f http://k8s.io/examples/pods/pod-rs.yaml +``` + +Los nuevos Pods serán adquiridos por el ReplicaSet, e inmediatamente terminados ya que + el ReplicaSet estaría por encima del número deseado. + +Obtener los Pods: +```shell +kubectl get Pods +``` + +La salida muestra que los nuevos Pods se han terminado, o están en el proceso de terminarse: +```shell +NAME READY STATUS RESTARTS AGE +frontend-9si5l 1/1 Running 0 1m +frontend-dnjpy 1/1 Running 0 1m +frontend-qhloh 1/1 Running 0 1m +pod2 0/1 Terminating 0 4s +``` + +Si creas primero los Pods: +```shell +kubectl apply -f http://k8s.io/examples/pods/pod-rs.yaml +``` + +Y entonces creas el ReplicaSet: +```shell +kubectl apply -f http://k8s.io/examples/controllers/frontend.yaml +``` + +Verás que el ReplicaSet ha adquirido dichos Pods y simplemente ha creado tantos nuevos +como necesarios para cumplir con su especificación hasta que el número de +sus nuevos Pods y los originales coincidan con la cuenta deseado. Al obtener los Pods: +```shell +kubectl get Pods +``` + +Veremos su salida: +```shell +NAME READY STATUS RESTARTS AGE +frontend-pxj4r 1/1 Running 0 5s +pod1 1/1 Running 0 13s +pod2 1/1 Running 0 13s +``` + +De esta forma, un ReplicaSet puede poseer un conjunto no homogéneo de Pods + +## Escribir un manifiesto de ReplicaSet + +Al igual que con el esto de los objeto de la API de Kubernetes, un ReplicaSet necesita los campos +`apiVersion`, `kind`, y `metadata`. Para los ReplicaSets, el tipo es siempre ReplicaSet. +En la versión 1.9 de Kubernetes, la versión `apps/v1` de la API en un tipo ReplicaSet es la versión actual y está habilitada por defecto. +La versión `apps/v1beta2` de la API se ha desaprobado. +Consulta las primeras líneas del ejemplo `frontend.yaml` como guía. + +Un ReplicaSet también necesita una [sección `.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status). + +### Plantilla Pod + +El campo `.spec.template` es una [plantilla pod](/docs/concepts/workloads/Pods/pod-overview/#pod-templates) que es + también necesita obligatoriamente tener etiquetas definidas. En nuestro ejemplo `frontend.yaml` teníamos una etiqueta: `tier: frontend`. +Lleva cuidado de que no se entremezcle con los selectores de otros controladores, no sea que traten de adquirir este Pod. + +Para el campo de [regla de reinicio](/docs/concepts/workloads/Pods/pod-lifecycle/#restart-policy) de la plantilla, +`.spec.template.spec.restartPolicy`, el único valor permitido es `Always`, que es el valor predeterminado. + +### Selector de Pod + +El campo `.spec.selector` es un [selector de etiqueta](/docs/concepts/overview/working-with-objects/labels/). +Como se explicó [anteriormente](#how-a-replicaset-works), estas son las etiquetas que se usan para + identificar los Pods potenciales a adquirir. En nuestro ejemplo `frontend.yaml`, el selector era: +```shell +matchLabels: + tier: frontend +``` + +El el ReplicaSet, `.spec.template.metadata.labels` debe coincidir con `spec.selector`, o será + rechazado por la API. + +{{< note >}} +Cuando 2 ReplicaSets especifican el mismo campo `.spec.selector`, pero los campos +`.spec.template.metadata.labels` y `.spec.template.spec` diferentes, cada ReplicaSet +ignora los Pods creados por el otro ReplicaSet. +{{< /note >}} + +### Réplicas + +Puedes configurar cuántos Pods deberían ejecutarse de forma concurrente indicando el campo `.spec.replicas`. +El ReplicaSet creará/eliminará sus Pods para alcanzar este número. + +Si no indicas el valor del campo `.spec.replicas`, entonces por defecto se inicializa a 1. + +## Trabajar con ReplicaSets + +### Eliminar un ReplicaSet y sus Pods + +Para eliminar un ReplicaSet y todos sus Pods, utiliza el comando [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete). +El [Recolector de basura](/docs/concepts/workloads/controllers/garbage-collection/) eliminará automáticamente + todos los Pods subordinados por defecto. + +Cuando se usa la API REST o la librería `client-go`, se debe poner el valor de `propagationPolicy` a `Background` o +`Foreground` en la opción -d. +Por ejemplo: +```shell +kubectl proxy --port=8080 +curl -X DELETE 'localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/frontend' \ +> -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \ +> -H "Content-Type: application/json" +``` + +### Eliminar sólo un ReplicaSet + +Se puede eliminar un ReplicaSet sin afectar a ninguno de sus Pods usando el comando [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) con la opción `--cascade=false`. +Cuando se usa la API REST o la librería `client-go`, se debe poner `propagationPolicy` a `Orphan`. +Por ejemplo: +```shell +kubectl proxy --port=8080 +curl -X DELETE 'localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/frontend' \ +> -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \ +> -H "Content-Type: application/json" +``` + +Una vez que se ha eliminado el original, se puede crear un nuevo ReplicaSet para sustituirlo. +Mientras el viejo y el nuevo `.spec.selector` sean el mismo, el nuevo adoptará a los viejos Pods. +Sin embargo, no se esforzará en conseguir que los Pods existentes coincidan con una plantilla pod nueva, diferente. +Para actualizar dichos Pods a la nueva especificación de forma controlada, +usa una [actualización en línea](#rolling-updates). + +### Aislar Pods de un ReplicaSet + +Es posible aislar Pods de un ReplicaSet cambiando sus etiquetas. Esta técnica puede usarse +para eliminar Pods de un servicio para poder depurar, recuperar datos, etc. Los Pods +que se eliminar de esta forma serán sustituidos de forma automática (siempre que el +número de réplicas no haya cambiado). + +### Escalar un ReplicaSet + +Se puede aumentar o reducir fácilmente un ReplicaSet simplemente actualizando el campo `.spec.replicas`. +El controlador del ReplicaSet se asegura de que el número deseado de Pods con un selector +de etiquetas coincidente está disponible y operacional. + +### ReplicaSet como blanco de un Horizontal Pod Autoscaler + +Un ReplicaSet puede también ser el blanco de un +[Horizontal Pod Autoscalers (HPA)](/docs/tasks/run-application/horizontal-pod-autoscale/). Esto es, +un ReplicaSet puede auto-escalarse mediante un HPA. Aquí se muestra un ejemplo de HPA dirigido +al ReplicaSet que creamos en el ejemplo anterior. + +{{< codenew file="controllers/hpa-rs.yaml" >}} + +Si guardas este manifiesto en un archivo `hpa-rs.yaml` y lo lanzas contra el clúster de Kubernetes, +debería crear el HPA definido que auto-escala el ReplicaSet destino dependiendo del uso +de CPU de los Pods replicados. + +```shell +kubectl apply -f https://k8s.io/examples/controllers/hpa-rs.yaml +``` + +Alternativamente, puedes usar el comando `kubectl autoscale` para conseguir el mismo objetivo +(¡y mucho más fácil!) + +```shell +kubectl autoscale rs frontend --max=10 +``` + +## Alternativas al ReplicaSet + +### Deployment (recomendado) + +Un[`Deployment`](/docs/concepts/workloads/controllers/deployment/) es un objeto que puede poseer ReplicaSets +y actualizar a estos y a sus Pods mediante actualizaciones en línea declarativas en el servidor. +Aunque que los ReplicaSets puede usarse independientemente, hoy en día se usan principalmente a través de los Deployments +como el mecanismo para orquestrar la creación, eliminación y actualización de los Pods. +Cuando usas Deployments no tienes que preocuparte de gestionar los ReplicaSets que crean. +Los Deployments poseen y gestionan sus ReplicaSets. +Por tanto, se recomienda que se use Deployments cuando se quiera ReplicaSets. + +### Pods simples + +A diferencia del caso en que un usuario creaba Pods de forma directa, un ReplicaSet sustituye los Pods que se eliminan +o se terminan por la razón que sea, como en el caso de un fallo de un nodo o +una intervención disruptiva de mantenimiento, como una actualización de kernel. +Por esta razón, se recomienda que se use un ReplicaSet incluso cuando la aplicación +sólo necesita un único Pod. Entiéndelo de forma similar a un proceso supervisor, +donde se supervisa múltiples Pods entre múltiples nodos en vez de procesos individuales +en un único nodo. Un ReplicaSet delega los reinicios del contenedor local a algún agente +del nodo (por ejemplo, Kubelet o Docker). + +### Job + +Usa un [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) en vez de un ReplicaSet para + aquellos Pods que se esperan que terminen por ellos mismos (esto es, trabajos por lotes). + +### DaemonSet + +Usa un [`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/) en vez de un ReplicaSet para aquellos + Pods que proporcionan funcionalidad a nivel de servidor, como monitorización de servidor o + logging de servidor. Estos Pods tienen un ciclo de vida asociado al del servidor mismo: + el Pod necesita ejecutarse en el servidor antes de que los otros Pods comiencen, y es seguro + que terminen cuando el servidor esté listo para ser reiniciado/apagado. + +### ReplicationController +Los ReplicaSets son los sucesores de los [_ReplicationControllers_](/docs/concepts/workloads/controllers/replicationcontroller/). +Los dos sirven al mismo propósito, y se comportan de forma similar, excepto porque un ReplicationController +no soporta los requisitos del selector basado en conjunto, como se describe en la [guía de usuario de etiquetas](/docs/concepts/overview/working-with-objects/labels/#label-selectors). +Por ello, se prefiere los ReplicaSets a los ReplicationControllers. + +{{% /capture %}} diff --git a/content/es/examples/controllers/frontend.yaml b/content/es/examples/controllers/frontend.yaml new file mode 100644 index 0000000000..4a10c52a7d --- /dev/null +++ b/content/es/examples/controllers/frontend.yaml @@ -0,0 +1,21 @@ +apiVersion: apps/v1 +kind: ReplicaSet +metadata: + name: frontend + labels: + app: guestbook + tier: frontend +spec: + # modifica las réplicas según tu caso de uso + replicas: 3 + selector: + matchLabels: + tier: frontend + template: + metadata: + labels: + tier: frontend + spec: + containers: + - name: php-redis + image: gcr.io/google_samples/gb-frontend:v3 diff --git a/content/es/examples/controllers/hpa-rs.yaml b/content/es/examples/controllers/hpa-rs.yaml new file mode 100644 index 0000000000..a8388530dc --- /dev/null +++ b/content/es/examples/controllers/hpa-rs.yaml @@ -0,0 +1,11 @@ +apiVersion: autoscaling/v1 +kind: HorizontalPodAutoscaler +metadata: + name: frontend-scaler +spec: + scaleTargetRef: + kind: ReplicaSet + name: frontend + minReplicas: 3 + maxReplicas: 10 + targetCPUUtilizationPercentage: 50 diff --git a/content/es/examples/controllers/job.yaml b/content/es/examples/controllers/job.yaml new file mode 100644 index 0000000000..b448f2eb81 --- /dev/null +++ b/content/es/examples/controllers/job.yaml @@ -0,0 +1,14 @@ +apiVersion: batch/v1 +kind: Job +metadata: + name: pi +spec: + template: + spec: + containers: + - name: pi + image: perl + command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] + restartPolicy: Never + backoffLimit: 4 + diff --git a/content/es/examples/pods/pod-rs.yaml b/content/es/examples/pods/pod-rs.yaml new file mode 100644 index 0000000000..df7b390597 --- /dev/null +++ b/content/es/examples/pods/pod-rs.yaml @@ -0,0 +1,23 @@ +apiVersion: v1 +kind: Pod +metadata: + name: pod1 + labels: + tier: frontend +spec: + containers: + - name: hello1 + image: gcr.io/google-samples/hello-app:2.0 + +--- + +apiVersion: v1 +kind: Pod +metadata: + name: pod2 + labels: + tier: frontend +spec: + containers: + - name: hello2 + image: gcr.io/google-samples/hello-app:1.0 From a3f977aaec05b09b5fe20c749703c7ece1e8546c Mon Sep 17 00:00:00 2001 From: Cheikhrouhou ines Date: Thu, 12 Sep 2019 21:58:31 +0200 Subject: [PATCH 002/218] 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 003/218] 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 004/218] 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 65fdb62395925e7cf70c5118e3dfc522ae05b7e5 Mon Sep 17 00:00:00 2001 From: Zhang Yong Date: Fri, 28 Feb 2020 10:35:22 +0800 Subject: [PATCH 005/218] =?UTF-8?q?Localize=20=E2=80=9Cemail=20address?= =?UTF-8?q?=E2=80=9D=20placeholder=20on=20home=20page?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- i18n/es.toml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/i18n/es.toml b/i18n/es.toml index c70d1a18d4..e78b2d46ad 100644 --- a/i18n/es.toml +++ b/i18n/es.toml @@ -193,3 +193,6 @@ other = "Calendario de eventos" # UI elements [ui_search_placeholder] other = "Buscar" + +[input_placeholder_email_address] +other = "dirección de correo electrónico" \ No newline at end of file From 40496c2b7d8e2dc9f47f2da21c1ede2db6b93420 Mon Sep 17 00:00:00 2001 From: icheikhrouhou Date: Mon, 13 Apr 2020 10:18:36 +0200 Subject: [PATCH 006/218] 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 5a9aeb7d269acd4a20a70eb6056071be317a81b2 Mon Sep 17 00:00:00 2001 From: Fernando Karnagi Date: Mon, 20 Apr 2020 09:20:28 +0800 Subject: [PATCH 007/218] Added steps for normal user authentication --- .../access-authn-authz/authentication.md | 2 + .../certificate-signing-requests.md | 94 +++++++++++++++++++ 2 files changed, 96 insertions(+) diff --git a/content/en/docs/reference/access-authn-authz/authentication.md b/content/en/docs/reference/access-authn-authz/authentication.md index 31ae364222..03816a36a8 100644 --- a/content/en/docs/reference/access-authn-authz/authentication.md +++ b/content/en/docs/reference/access-authn-authz/authentication.md @@ -26,6 +26,8 @@ even a file with a list of usernames and passwords. In this regard, _Kubernetes does not have objects which represent normal user accounts._ Normal users cannot be added to a cluster through an API call. +Even though normal user cannot be added via an API call, but any user that presents a valid certificate signed by the cluster’s certificate authority (CA) is considered authenticated. In this configuration, Kubernetes determines the username from the common name field in the ‘subject’ of the cert (e.g., “/CN=bob”). From there, the role based access control (RBAC) sub-system would determine whether the user is authorized to perform a specific operation a resource. You can refer to [creating user certificate request](/docs/reference/access-authn-authz/certificate-signing-requests/#user-csr) for more details about this. + In contrast, service accounts are users managed by the Kubernetes API. They are bound to specific namespaces, and created automatically by the API server or manually through API calls. Service accounts are tied to a set of credentials 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 3e81215dd8..5f4fc41541 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 @@ -226,6 +226,100 @@ rules: - sign ``` +## Normal User + +Few steps are required in order to get normal to be able to authenticate and invoke API. First, this user must have certificate issued by the Kubernetes Cluster, and then present that Certificate into the API call as the Certificate Header, or through the kubectl. + +### Create Private Key + +The following scripts show how to generate PKI private key and CSR. It is important to set CN and O attribute of the CSR. CN is the name of the user and O is the group that this user will belong to. You can refer to [RBAC](/docs/reference/access-authn-authz/rbac/) for standard groups. + +``` +openssl genrsa -out john.key 2048 +openssl req -new -key john.key -out john.csr +``` + +### Create Certificate Request Kubernetes Object + +You then need to create a CertificateSigningRequest and submit it to Kubernetes Cluster via kubectl. Below is script to generate one. + +``` +cat < Date: Tue, 21 Apr 2020 09:00:01 +0800 Subject: [PATCH 008/218] Updated instruction on Create Certificate Request Kubernetes Object --- .../access-authn-authz/certificate-signing-requests.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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 5f4fc41541..1c35be0708 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 @@ -241,7 +241,7 @@ openssl req -new -key john.key -out john.csr ### Create Certificate Request Kubernetes Object -You then need to create a CertificateSigningRequest and submit it to Kubernetes Cluster via kubectl. Below is script to generate one. +Create a CertificateSigningRequest and submit it to Kubernetes Cluster via kubectl. Below is script to generate one. ``` cat < Date: Tue, 21 Apr 2020 09:12:17 +0800 Subject: [PATCH 009/218] Various updates --- .../access-authn-authz/certificate-signing-requests.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) 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 1c35be0708..7f6c181a34 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 @@ -264,7 +264,7 @@ Few points to note: ### Approve Certificate Request -You will need to use kubeadmin to get CSR and approve it. +Use kubeadmin to create a CSR and approve it. Get the list of CSRs ``` @@ -278,10 +278,10 @@ kubectl certificate approve john ### Get the Certificate -Once the CSR is approved, you can collect the Certificate by getting it from the CSR itself. +Retrieve the Certificate from the CSR. ``` -kubectl get csr/john -oyaml +kubectl get csr/john -o yaml ``` The Certifcate value is in Base64 format, under status.certificate. From b2d21616d8c527c7ad3c55d904f96b427a2af654 Mon Sep 17 00:00:00 2001 From: Fernando Karnagi Date: Tue, 21 Apr 2020 09:15:09 +0800 Subject: [PATCH 010/218] updated mistypo --- .../access-authn-authz/certificate-signing-requests.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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 7f6c181a34..fb62c7692d 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 @@ -228,7 +228,7 @@ rules: ## Normal User -Few steps are required in order to get normal to be able to authenticate and invoke API. First, this user must have certificate issued by the Kubernetes Cluster, and then present that Certificate into the API call as the Certificate Header, or through the kubectl. +Few steps are required in order to get normal user to be able to authenticate and invoke API. First, this user must have certificate issued by the Kubernetes Cluster, and then present that Certificate into the API call as the Certificate Header, or through the kubectl. ### Create Private Key From bdc18d99f053aa0c1a7db2d127cc8a59cc73c032 Mon Sep 17 00:00:00 2001 From: lou-lan Date: Tue, 28 Apr 2020 00:51:31 +0800 Subject: [PATCH 011/218] Fix minikube image 'project:hello-minikube-zero-install' has been suspended. --- content/fr/docs/tutorials/hello-minikube.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/fr/docs/tutorials/hello-minikube.md b/content/fr/docs/tutorials/hello-minikube.md index 71f9d0f1ee..b2acb150a1 100644 --- a/content/fr/docs/tutorials/hello-minikube.md +++ b/content/fr/docs/tutorials/hello-minikube.md @@ -76,7 +76,7 @@ Les déploiements sont le moyen recommandé pour gérer la création et la mise Pod utilise un conteneur basé sur l'image Docker fournie. ```shell - kubectl create deployment hello-node --image=gcr.io/hello-minikube-zero-install/hello-node + kubectl create deployment hello-node --image=k8s.gcr.io/echoserver:1.4 ``` 2. Affichez le déploiement : From 4afaf21c6c045855293f6868c23b888455b7b6cf Mon Sep 17 00:00:00 2001 From: dupengcheng Date: Wed, 13 May 2020 16:01:54 +0800 Subject: [PATCH 012/218] Fix zh language misspell --- content/zh/docs/concepts/workloads/controllers/deployment.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/zh/docs/concepts/workloads/controllers/deployment.md b/content/zh/docs/concepts/workloads/controllers/deployment.md index ecddfa645d..cbc5e8217b 100644 --- a/content/zh/docs/concepts/workloads/controllers/deployment.md +++ b/content/zh/docs/concepts/workloads/controllers/deployment.md @@ -109,7 +109,7 @@ The following are typical use cases for Deployments: * [Clean up older ReplicaSets](#clean-up-policy) that you don't need anymore. --> -* [清理较旧的 ReplicaSets ](#clean-up-policy) ，那些不在需要的。 +* [清理较旧的 ReplicaSets ](#clean-up-policy) ，那些不再需要的。 ```shell # 启动运行 nginx 的 Pod -kubectl run --image=nginx nginx-app --port=80 --env="DOMAIN=cluster" +kubectl create deployment --image=nginx nginx-app --port=80 --env="DOMAIN=cluster" ``` ``` deployment "nginx-app" created diff --git a/content/zh/docs/tasks/administer-cluster/declare-network-policy.md b/content/zh/docs/tasks/administer-cluster/declare-network-policy.md index 30798bb20b..7cb488aaee 100644 --- a/content/zh/docs/tasks/administer-cluster/declare-network-policy.md +++ b/content/zh/docs/tasks/administer-cluster/declare-network-policy.md @@ -36,7 +36,7 @@ content_template: templates/task 为了查看 Kubernetes 网络策略是怎样工作的，可以从创建一个`nginx` deployment 并且通过服务将其暴露开始 ```console -$ kubectl run nginx --image=nginx --replicas=2 +$ kubectl create deployment nginx --image=nginx deployment "nginx" created $ kubectl expose deployment nginx --port=80 service "nginx" exposed @@ -53,7 +53,6 @@ svc/nginx 10.100.0.16 80/TCP 33s NAME READY STATUS RESTARTS AGE po/nginx-701339712-e0qfq 1/1 Running 0 35s -po/nginx-701339712-o00ef 1/1 Running 0 35s ``` From 7512752ad0a68e1da6af6dc04a07994fbddba44b Mon Sep 17 00:00:00 2001 From: ZhiFeng1993 Date: Wed, 3 Jun 2020 17:54:59 -0700 Subject: [PATCH 016/218] Update installation info for kubelet and kubernetes-cni --- .../tools/kubeadm/kubelet-integration.md | 3 +-- .../tools/kubeadm/kubelet-integration.md | 3 +-- .../tools/kubeadm/kubelet-integration.md | 3 +-- 3 files changed, 3 insertions(+), 6 deletions(-) diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md b/content/en/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md index 070dbd7274..023aa0c1f8 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md @@ -198,9 +198,8 @@ The DEB and RPM packages shipped with the Kubernetes releases are: | Package name | Description | |--------------|-------------| | `kubeadm` | Installs the `/usr/bin/kubeadm` CLI tool and the [kubelet drop-in file](#the-kubelet-drop-in-file-for-systemd) for the kubelet. | -| `kubelet` | Installs the `/usr/bin/kubelet` binary. | +| `kubelet` | Installs the kubelet binary in `/usr/bin` and CNI binaries in `/opt/cni/bin`. | | `kubectl` | Installs the `/usr/bin/kubectl` binary. | -| `kubernetes-cni` | Installs the official CNI binaries into the `/opt/cni/bin` directory. | | `cri-tools` | Installs the `/usr/bin/crictl` binary from the [cri-tools git repository](https://github.com/kubernetes-incubator/cri-tools). | {{% /capture %}} diff --git a/content/ja/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md b/content/ja/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md index b53e0462b9..809ce687f9 100644 --- a/content/ja/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md +++ b/content/ja/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md @@ -192,9 +192,8 @@ The DEB and RPM packages shipped with the Kubernetes releases are: | Package name | Description | |--------------|-------------| | `kubeadm` | Installs the `/usr/bin/kubeadm` CLI tool and the [kubelet drop-in file](#the-kubelet-drop-in-file-for-systemd) for the kubelet. | -| `kubelet` | Installs the `/usr/bin/kubelet` binary. | +| `kubelet` | Installs the kubelet binary in `/usr/bin` and CNI binaries in `/opt/cni/bin`. | | `kubectl` | Installs the `/usr/bin/kubectl` binary. | -| `kubernetes-cni` | Installs the official CNI binaries into the `/opt/cni/bin` directory. | | `cri-tools` | Installs the `/usr/bin/crictl` binary from the [cri-tools git repository](https://github.com/kubernetes-incubator/cri-tools). | {{% /capture %}} diff --git a/content/zh/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md b/content/zh/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md index 6618de8e48..cc791a3940 100644 --- a/content/zh/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md +++ b/content/zh/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md @@ -373,9 +373,8 @@ Kubernetes 版本对应的 DEB 和 RPM 软件包是： | Package name | Description | |--------------|-------------| | `kubeadm` | 给 kubelet 安装 `/usr/bin/kubeadm` CLI 工具和 [kubelet 插件](#the-kubelet-drop-in-file-for-systemd)。 | -| `kubelet` | 安装 `/usr/bin/kubelet` 二进制文件。 | +| `kubelet` | 安装 `/usr/bin/kubelet` 二进制文件和 `/opt/cni/bin` CNI 二进制文件。 | | `kubectl` | 安装 `/usr/bin/kubectl` 二进制文件。 | -| `kubernetes-cni` | 将官方的 CNI 二进制文件安装到 `/opt/cni/bin` 目录中 | | `cri-tools` | 从 [cri-tools git 仓库](https://github.com/kubernetes-incubator/cri-tools)中安装 `/usr/bin/crictl` 二进制文件。 | {{% /capture %}} From 841db869b22296feeb711a9e82a0198947822899 Mon Sep 17 00:00:00 2001 From: Hector Sam Date: Thu, 11 Jun 2020 18:32:21 +0200 Subject: [PATCH 017/218] 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 373e4cdfde527447f560ed07634dd723ab4d5756 Mon Sep 17 00:00:00 2001 From: Jerry Park Date: Sat, 30 May 2020 20:53:30 +0900 Subject: [PATCH 018/218] Change the words for limit/request on the glossary --- content/ko/docs/contribute/localization_ko.md | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/content/ko/docs/contribute/localization_ko.md b/content/ko/docs/contribute/localization_ko.md index 72d6c7f3d7..c8628b9bc0 100644 --- a/content/ko/docs/contribute/localization_ko.md +++ b/content/ko/docs/contribute/localization_ko.md @@ -287,8 +287,6 @@ Daemon | 데몬 | DaemonSet | 데몬셋(DaemonSet) | API 오브젝트인 경우 Dashboard | 대시보드 | Data Plane | 데이터 플레인 | -Default Limit | 기본 상한 | -Default Request | 기본 요청량 | Deployment | 디플로이먼트(Deployment) | API 오브젝트인 경우 deprecated | 사용 중단(deprecated) | descriptor | 디스크립터, 식별자 | @@ -348,6 +346,7 @@ label | 레이블 | Lease | 리스(Lease) | API 오브젝트인 경우 lifecycle | 라이프사이클 | LimitRange | 리밋레인지(LimitRange) | API 오브젝트인 경우 +limit | 한도(limit) | 리소스의 개수나 용량을 한정하기 위한 수치로 사용된 경우 선택적으로 사용 (API 오브젝트의 속성으로 limit을 사용한 경우는 가능한 영문 유지) Linux | 리눅스 | load | 부하 | LocalSubjectAccessReview | 로컬서브젝트액세스리뷰(LocalSubjectAccessReview) | API 오브젝트인 경우 @@ -357,7 +356,6 @@ Lost | Lost | 클레임의 상태에 한함 Machine | 머신 | manifest | 매니페스트 | Master | 마스터 | -max limit/request ratio | 최대 상한/요청량 비율 | metadata | 메타데이터 | metric | 메트릭 | masquerading | 마스커레이딩 | @@ -410,8 +408,8 @@ ReplicaSet | 레플리카셋(ReplicaSet) | API 오브젝트인 경우 replicas | 레플리카 | ReplicationController | 레플리케이션컨트롤러(ReplicationController) | API 오브젝트인 경우 repository | 리포지터리 | +request | 요청(request) | 리소스의 개수나 용량에 대한 요청 수치를 표현하기 위해 사용된 경우 선택적으로 사용 (API 오브젝트 속성으로 request를 사용한 경우는 가능한 영문을 유지) resource | 리소스 | -Resource Limit | 리소스 상한 | ResourceQuota | 리소스쿼터(ResourceQuota) | API 오브젝트인 경우 return | 반환하다 | revision | 리비전 | From f21baa1eb43053963d6ca146fe7cd9bde43e30d0 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Sat, 13 Jun 2020 14:53:14 +0800 Subject: [PATCH 019/218] [zh] Fix typo in sample yaml --- content/zh/docs/concepts/configuration/configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/zh/docs/concepts/configuration/configmap.md b/content/zh/docs/concepts/configuration/configmap.md index 77f8ecf846..9de6e2b9f8 100644 --- a/content/zh/docs/concepts/configuration/configmap.md +++ b/content/zh/docs/concepts/configuration/configmap.md @@ -84,7 +84,7 @@ format. apiVersion: v1 kind: ConfigMap metadata: - Name: game-demo + name: game-demo data: # 类属性键；每一个键都映射到一个简单的值 player_initial_lives: 3 From 3cf5f56c33817b350e135440a9c7d8d93ec4502c Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Sat, 13 Jun 2020 16:18:05 +0800 Subject: [PATCH 020/218] [WIP][zh] Fix minikube install note --- content/zh/docs/tasks/tools/install-minikube.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/content/zh/docs/tasks/tools/install-minikube.md b/content/zh/docs/tasks/tools/install-minikube.md index b5dd10fa35..55439a64e0 100644 --- a/content/zh/docs/tasks/tools/install-minikube.md +++ b/content/zh/docs/tasks/tools/install-minikube.md @@ -393,14 +393,13 @@ To confirm successful installation of both a hypervisor and Minikube, you can ru 要确认 hypervisor 和 Minikube 均已成功安装，可以运行以下命令来启动本地 Kubernetes 集群： -{{< note >}} -通过 `minikube start` 设置 `--vm-driver`。在下面提到 `` 的地方，用小写字母，输入你安装的 hypervisor 的名称。 -[指定 VM 驱动程序](https://kubernetes.io/docs/setup/learning-environment/minikube/#specifying-the-vm-driver) 列举了 `--vm-driver` 值的完整列表 - +{{< note >}} +若要为 `minikube start` 设置 `--vm-driver`，在下面提到 `` 的地方，用小写字母输入你安装的 hypervisor 的名称。 +[指定 VM 驱动程序](/docs/setup/learning-environment/minikube/#specifying-the-vm-driver) 列举了 `--vm-driver` 值的完整列表。 {{< /note >}} ```shell From f4a9676043fef29a631e351b9e6fe7ff8a31a550 Mon Sep 17 00:00:00 2001 From: cristiano-degiorgis Date: Mon, 1 Jun 2020 18:30:41 +0200 Subject: [PATCH 021/218] docs/concepts/controller --- .../docs/concepts/architecture/controller.md | 95 +++++++++++++++++++ .../it/docs/reference/glossary/controller.md | 21 ++++ content/it/docs/reference/glossary/job.md | 20 ++++ content/it/docs/reference/glossary/node.md | 2 +- 4 files changed, 137 insertions(+), 1 deletion(-) create mode 100644 content/it/docs/concepts/architecture/controller.md create mode 100755 content/it/docs/reference/glossary/controller.md create mode 100755 content/it/docs/reference/glossary/job.md diff --git a/content/it/docs/concepts/architecture/controller.md b/content/it/docs/concepts/architecture/controller.md new file mode 100644 index 0000000000..b37dd33957 --- /dev/null +++ b/content/it/docs/concepts/architecture/controller.md @@ -0,0 +1,95 @@ +--- +title: Controller +content_template: templates/concept +weight: 40 +--- + +{{% capture overview %}} + +Nella robotica e nell'automazione, un _circuito di controllo_ (_control loop_) è un un'iterazione senza soluzione di continuità che regola lo stato di un sistema. + +Ecco un esempio di un circuito di controllo: il termostato di una stanza. + +Quando viene impostata la temperatura, si definisce attraverso il termostato lo *stato desiderato*. L'attuale temperatura nella stanza è invece lo *stato corrente*. Il termostato agisce per portare lo stato corrente il più vicino possibile allo stato desiderato accendendo e spegnendo le apparecchiature. + +{{< glossary_definition term_id="controller" length="short" >}} + +{{% /capture %}} + + +{{% capture body %}} + +## Il modello del controller + +Un _controller_ monitora almeno una tipo di risorsa registrata in Kubernetes. +Questi [oggetti](/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects) hanno una proprietà chiamata *spec* (specifica) che rappresenta lo stato desiderato. Il o i *controller* per quella risorsa sono responsabili di mantenere lo stato corrente il più simile possibile rispetto allo stato desiderato. + +Il _controller_ potrebbe eseguire l'azione relativa alla risorsa in questione da sé; più comunemente, in Kubernetes, un _controller_ invia messaggi all'{{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} che a sua volta li rende disponibili ad altri componenti nel cluster. Di seguito troverete esempi per questo scenario. + +{{< comment >}} +Alcuni controller nativi, come ad esempio l'_endpoints_ controller, agiscono su oggetti che non hanno una specifica. Per semplicità, questa pagina non entra in quel dettaglio. +{{< /comment >}} + +### Controllo attraverso l'API server + +Il {{< glossary_tooltip term_id="job" >}} _controller_ è un esempio di un _controller_ nativo in Kubernetes. I _controller_ nativi gestiscono lo stato interagendo con l'API server presente nel cluster. + +Il Job è una risorsa di Kubernetes che lancia uno o più {{< glossary_tooltip term_id="pod" text="Pod" >}} per eseguire un lavoro (task) e poi fermarsi. + +(Una volta che è stato [schedulato](/docs/concepts/scheduling-eviction/), un oggetto _Pod_ diventa parte dello stato desisderato di un dato _kubelet_). + +Quando il Job _controller_ vede un nuovo lavoro da svolgere si assicura che, da qualche parte nel cluster, i _kubelet_ anche sparsi su più nodi eseguano il numero corretto di _Pod_ necessari per eseguire il lavoro richiesto. Il Job _controller_ non esegue direttamente alcun _Pod_ o _container_ bensì chiede all'API server di creare o rimuovere i _Pod_. Altri componenti appartenenti al {{< glossary_tooltip text="control plane" term_id="control-plane" >}} reagiscono in base alle nuove informazioni (ci sono nuovi _Pod_ da creare e gestire) e cooperano al completamento del job. + +Dopo che un nuovo Job è stato creato, lo stato desiderato per quel Job è il suo completamento. Il Job _controller_ fa sì che lo stato corrente per quel Job sia il più vicino possibile allo stato desiderato: creare _Pod_ che eseguano il lavoro che deve essere effettuato attraverso il Job, così che il Job sia prossimo al completamento. + +I _controller_ aggiornano anche gli oggetti che hanno configurato. Ad esempio: una volta che il lavoro relativo ad un dato Job è stato completato, il Job _controller_ aggiorna l'oggetto Job segnandolo come `Finished`. + +(Questo è simile allo scenario del termostato che spegne un certo led per indicare che ora la stanza ha raggiungo la temperatura impostata) + +### Controllo diretto + +A differenza del Job, alcuni _controller_ devono eseguire delle modifiche a parti esterne al cluster. + +Per esempio, se viene usato un circuito di controllo per assicurare che ci sia un numero sufficiente di {{< glossary_tooltip text="Nodi" term_id="node" >}} nel cluster, allora il _controller_ ha bisogno che qualcosa al di fuori del cluster configuri i nuovi _Nodi_ quando sarà necessario. + +I _controller_ che interagiscono con un sistema esterno trovano il loro stato desiderato attraverso l'API server, quindi comunicano direttamente con un sistema esterno per portare il loro stato corrente più in linea possibile con lo stato desiderato + +(In realtà c'è un _controller_ che scala orizzontalmente i nodi nel cluster. Vedi [Cluster autoscaling](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling)). + +## Stato desiderato versus corrente {#desiderato-vs-corrente} + +Kubernetes ha una visione *cloud-native* dei sistemi, ed è in grado di gestire continue modifiche. + +Il cluster viene modificato continuamente durante la sua attività ed il _circuito di controllo_ è in grado di risolvere automaticamente i possibili guasti. + +Fino a che i _controller_ del cluster sono in funzione ed in grado di apportare le dovute modifiche, non è rilevante che lo stato complessivo del cluster sia o meno stabile. + +## Progettazione + +Come cardine della sua progettazione, Kubernetes usa vari _controller_ ognuno dei quali è responsabile per un particolare aspetto dello stato del cluster. Più comunemente, un dato _circuito di controllo_ (_controller_) usa un tipo di risorsa per il suo stato desiderato, ed utilizza anche risorse di altro tipo per raggiungere questo stato desiderato. Per esempio il Job _controller_ tiene traccia degli oggetti di tipo _Job_ (per scoprire nuove attività da eseguire) e degli oggetti di tipo _Pod_ (questi ultimi usati per eseguire i _Job_, e quindi per controllare quando il loro lavoro è terminato). In questo caso, qualcos'altro crea i _Job_, mentre il _Job_ _controller_ crea i _Pod_. + +È utile avere semplici _controller_ piuttosto che un unico, monolitico, _circuito di controllo_. I _controller_ possono guastarsi, quindi Kubernetes è stato disegnato per gestire questa eventualità. + +{{< note >}} +Ci possono essere diversi _controller_ che creato o aggiornano lo stesso tipo di oggetti. Dietro le quinte, i _controller_ di Kubernetes si preoccupano esclusivamente delle risorse (di altro tipo) collegate alla risorsa primaria da essi controllata. + +Per esempio, si possono avere _Deployment_ e _Job_; entrambe creano _Pod_. Il Job _controller_ non distrugge i _Pod_ creati da un _Deployment_, perché ci sono informazioni (*{{< glossary_tooltip term_id="label" text="labels" >}}*) che vengono usate dal _controller_ per distinguere i _Pod_. +{{< /note >}} + +## I modi per eseguire i _controller_ {#eseguire-controller} + +Kubernetes annovera un insieme di _controller_ nativi che sono in esecuzione all'interno del {{< glossary_tooltip term_id="kube-controller-manager" >}}. Questi _controller_ nativi forniscono importanti funzionalità di base. + +Il Deployment _controller_ ed il Job _controller_ sono esempi di _controller_ che vengono forniti direttamente da Kubernetes stesso (ovvero _controller_ "nativi"). +Kubernetes consente di eseguire un _piano di controllo_(_control plane_) resiliente, di modo che se un dei _controller_ nativi dovesse fallire, un'altra parte del piano di controllo si occuperà di eseguire quel lavoro. + +Al fine di estendere Kubernetes, si possono avere _controller_ in esecuzione al di fuori del piano di controllo. Oppure, se si desidera, è possibile scriversi un nuovo _controller_. È possibile eseguire il proprio controller come una serie di _Pod_, oppure esternamente rispetto a Kubernetes. Quale sia la soluzione migliore, dipende dalla responsabilità di un dato controller. + +{{% /capture %}} + +{{% capture whatsnext %}} +* Leggi in merito [Kubernetes control plane](/docs/concepts/#kubernetes-control-plane) +* Scopri alcune delle basi degli [oggetti di Kubernetes](/docs/concepts/#kubernetes-objects) +* Per saperne di più riguardo alle [API di Kubernetes](/docs/concepts/overview/kubernetes-api/) +* Se vuoi creare un tuo _controller_, guarda [i modelli per l'estensibilità](/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns) in Estendere Kubernetes. +{{% /capture %}} diff --git a/content/it/docs/reference/glossary/controller.md b/content/it/docs/reference/glossary/controller.md new file mode 100755 index 0000000000..df5a7cfb94 --- /dev/null +++ b/content/it/docs/reference/glossary/controller.md @@ -0,0 +1,21 @@ +--- +title: Controller +id: controller +date: 2018-04-12 +full_link: /docs/concepts/architecture/controller/ +short_description: > + Un software che implementa un circuito di controllo che osserva lo stato condiviso del cluster attraverso l'API server e apporta le modifiche necessarie per portate lo stato corrente verso lo stato desiderato. + +aka: +tags: +- architecture +- fundamental +--- +In Kubernetes, i _controller_ sono circuiti di controllo che osservano lo stato del {{< glossary_tooltip term_id="cluster" text="cluster">}}, e apportano o richiedono modifiche quando necessario. Ogni _controller_ prova a portare lo stato corrente del cluster verso lo stato desiderato. + + + +I _controller_ osservano lo stato condiviso del cluster attraverso il {{< glossary_tooltip text="apiserver" term_id="kube-apiserver" >}} (che è parte del {{< glossary_tooltip term_id="control-plane" >}}). + +Alcuni _controller_ vengono eseguiti all'interno del _piano di controllo_ (_control plane_), e forniscono circuiti di controllo che sono parte dell'operatività base di Kubernetes. Ad esempio: il _deployment_ _controller_, il _daemonset_ _controller_, il _namespace_ _controller_, ed il _persistent volume_ +_controller_ (e altri) vengono tutti eseguiti all'interno del {{< glossary_tooltip term_id="kube-controller-manager" >}}. diff --git a/content/it/docs/reference/glossary/job.md b/content/it/docs/reference/glossary/job.md new file mode 100755 index 0000000000..6d3f8ef3af --- /dev/null +++ b/content/it/docs/reference/glossary/job.md @@ -0,0 +1,20 @@ +--- +title: Job +id: job +date: 2018-04-12 +full_link: /docs/concepts/workloads/controllers/jobs-run-to-completion +short_description: > + Uno o più lavori (task) che vengono eseguiti fino al loro completamento. + +aka: +tags: +- fundamental +- core-object +- workload +--- + Uno o più lavori (task) che vengono eseguiti fino al loro completamento. + + + +Crea uno o più oggetti di tipo {{< glossary_tooltip term_id="pod" >}} ed assicura che un numero preciso di questi venga completato con successo. Quando i _Pod_ vengono eseguiti con successo, il _Job_ tiene traccia della completamento andato a buon fine. + diff --git a/content/it/docs/reference/glossary/node.md b/content/it/docs/reference/glossary/node.md index 25bd25f3d0..3bc3df62bf 100755 --- a/content/it/docs/reference/glossary/node.md +++ b/content/it/docs/reference/glossary/node.md @@ -16,4 +16,4 @@ tags: Un worker node può essere una VM o una macchina fisica, in base al cluster. Possiede daemon locali o servizi ncessari a eseguire {{< glossary_tooltip text="Pods" term_id="pod" >}} e viene gestito dalla control plane. I deamon i un node includono {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}, {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}, e un container runtiome che implementa {{< glossary_tooltip text="CRI" term_id="cri" >}} come ad esempio {{< glossary_tooltip term_id="docker" >}}. -Nelle prime versioni di Kubernetes, i Node venivano chiamati "Minions". \ No newline at end of file +Nelle prime versioni di Kubernetes, i Node venivano chiamati "Minion". From 020daedd05d14c66b7b6cf3aed8f41a88b1b9eb7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jos=C3=A9=20Fernando=20Cordova?= Date: Sun, 14 Jun 2020 14:11:38 -0300 Subject: [PATCH 022/218] Fix wrong translations in Spanish language Some words in spanish weren't translated correctly. --- content/es/docs/concepts/architecture/cloud-controller.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/es/docs/concepts/architecture/cloud-controller.md b/content/es/docs/concepts/architecture/cloud-controller.md index 4de5b4418a..744a3ee046 100644 --- a/content/es/docs/concepts/architecture/cloud-controller.md +++ b/content/es/docs/concepts/architecture/cloud-controller.md @@ -6,13 +6,13 @@ weight: 30 -El concepto del Cloud Controller Manager (CCM) (no confundir con el ejecutable) fue creado originalmente para permitir que Kubernetes y el código específico de proveedores de servicios en la nube evolucionasen de forma independiente. El Cloud Controller Manager se ejecuta a la par con otros componentes maestros como el Kubernetes Controller Manager, el API Server y el planificador. También puede ejecutarse como un extra, en cuyo caso se ejecuta por encima de Kubernetes. +El concepto del Cloud Controller Manager (CCM) (no confundir con el ejecutable) fue creado originalmente para permitir que Kubernetes y el código específico de proveedores de servicios en la nube evolucionen de forma independiente. El Cloud Controller Manager se ejecuta a la par con otros componentes maestros como el Kubernetes Controller Manager, el API Server y el planificador. También puede ejecutarse como un extra, en cuyo caso se ejecuta por encima de Kubernetes. -El diseño del Cloud Controller Manager está basado en un sistema de plugins, lo que permite a nuevos proveedores de servicios integrarse de forma fácil con Kubernetes. Se está trabajando en incorporar nuevos proveedores de servicios y para migrar los existentes del viejo modelo al nuevo CCM. +El diseño del Cloud Controller Manager está basado en un sistema de plugins, lo que permite a nuevos proveedores de servicios integrarse de forma fácil con Kubernetes. Se está trabajando en implementar nuevos proveedores de servicios y para migrar los existentes del antiguo modelo al nuevo CCM. -Este documento describe los conceptos tras el Cloud Controller Manager y da detalles sobre sus funciones asociadas. +Este documento describe los conceptos tras el Cloud Controller Manager e informar detalles sobre sus funciones asociadas. -En la siguiente imagen, se puede ver la arquitectura de un cluster de Kubernetes que no utiliza el Cloud Controller Manager: +En la siguiente imagen, se puede visualizar la arquitectura de un cluster de Kubernetes que no utiliza el Cloud Controller Manager: ![Arquitectura previa a CCM](/images/docs/pre-ccm-arch.png) From 24ff96eb8f0154f303e6a5ee3d9e1aab99a5bf91 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jos=C3=A9=20Fernando=20Cordova?= Date: Sun, 14 Jun 2020 14:35:12 -0300 Subject: [PATCH 023/218] Fix Spanish typos --- content/es/docs/concepts/architecture/nodes.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/es/docs/concepts/architecture/nodes.md b/content/es/docs/concepts/architecture/nodes.md index 34b0303082..d2313849ef 100644 --- a/content/es/docs/concepts/architecture/nodes.md +++ b/content/es/docs/concepts/architecture/nodes.md @@ -111,7 +111,7 @@ El controlador juega múltiples papeles en la vida de un nodo. El primero es asi El segundo es mantener actualizada la lista interna del controlador con la lista de máquinas disponibles a través del proveedor de servicios en la nube. Cuando Kubernetes se ejecuta en la nube, si un nodo deja de responder, el controlador del nodo preguntará al proveedor si la máquina virtual de dicho nodo continúa estando disponible. Si no lo está, el controlador borrará dicho nodo de su lista interna. -El tercero es el de monitorizar la salud de los nodos. El controlador de nodos es el responsable de actualizar la condición `NodeReady` del campo `NodeStatus` a `ConditionUnknown` cuando un nodo deja de estar accesible (por ejemplo, si deja de recibir señales de vida del nodo indicando que está disponible, conocidas como latidos o `hearbeats` en inglés) y, también es responsable de posteriormente desalojar todos los pods del nodo si este continúa estando inalcanzable. Por defecto, cuando un nodo deja de responder, el controlador sigue re-intentando contactar con el nodo durante 40 segundos antes de marcar el nodo con `ConditionUnknown` y, si el nodo no se recupera de ese estado pasados 5 minutos, empezará a drenar los pods del nodo para desplegarlos en otro nodo que esté disponible. El controlador comprueba el estado de cada nodo cada `--node-monitor-period` segundos. +El tercero es el de monitorizar la salud de los nodos. El controlador de nodos es el responsable de actualizar la condición `NodeReady` del campo `NodeStatus` a `ConditionUnknown` cuando un nodo deja de estar accesible (por ejemplo, si deja de recibir señales de vida del nodo indicando que está disponible, conocidas como latidos o `hearbeats` en inglés) y, también es responsable de posteriormente desalojar todos los pods del nodo si este continúa estando inalcanzable. Por defecto, cuando un nodo deja de responder, el controlador sigue reintentando contactar con el nodo durante 40 segundos antes de marcar el nodo con `ConditionUnknown` y, si el nodo no se recupera de ese estado pasados 5 minutos, empezará a drenar los pods del nodo para desplegarlos en otro nodo que esté disponible. El controlador comprueba el estado de cada nodo cada `--node-monitor-period` segundos. En versiones de Kubernetes previas a 1.13, `NodeStatus` es el `heartbeat` del nodo. Empezando con 1.13 la funcionalidad de `node lease` se introduce como alfa (`NodeLease`, [KEP-0009](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/0009-node-heartbeat.md)). Cuando la funcionalidad está habilitada, cada nodo tiene un objeto `Lease` asociado en el namespace `kube-node-lease` que se renueva periódicamente y ambos, el `NodeStatus` y el `Lease` son considerados como `hearbeats` del nodo. `Node leases` se renuevan con frecuencia, mientras que `NodeStatus` se transmite desde el nodo al máster únicamente si hay cambios o si ha pasado cierto tiempo (por defecto, 1 minuto, que es más que la cuenta atrás por defecto de 40 segundos que marca un nodo como inalcanzable). Al ser los `node lease` más ligeros que `NodeStatus`, los `hearbeats` resultan más económicos desde las perspectivas de escalabilidad y de rendimiento. @@ -123,7 +123,7 @@ En la mayoría de los casos, el controlador de nodos limita el ritmo de desalojo El comportamiento de desalojo de nodos cambia cuando un nodo en una zona de disponibilidad tiene problemas. El controlador de nodos comprobará qué porcentaje de nodos en la zona no se encuentran en buen estado (es decir, que su condición `NodeReady` tiene un valor `ConditionUnknown` o `ConditionFalse`) al mismo tiempo. Si la fracción de nodos con problemas es de al menos `--unhealthy-zone-threshold` (0.55 por defecto) entonces se reduce el ratio de desalojos: si el clúster es pequeño (por ejemplo, tiene menos o los mismos nodos que `--large-cluster-size-threshold` - 50 por defecto) entonces los desalojos se paran. Sino, el ratio se reduce a `--secondary-node-eviction-rate` (0.01 por defecto) por segundo. La razón por la que estas políticas se implementan por zonas de disponibilidad es debido a que una zona puede quedarse aislada del nodo máster mientras que las demás continúan conectadas. Si un clúster no comprende más de una zona, todo el clúster se considera una única zona. La razón principal por la que se distribuyen nodos entre varias zonas de disponibilidad es para que el volumen de trabajo se transfiera a aquellas zonas que se encuentren en buen estado cuando una de las zonas se caiga. -Por consiguiente, si todos los nodos de una zona se encuentran en mal estado, el nodo controlador desaloja al ritmo normal `--node-eviction-rate`. En el caso extremo de que todas las zonas se encuentran en mal estado (es decir, no responda ningún nodo del clúster), el controlador de nodos asume que hay algún tipo de problema con la conectividad del nodo máster y paraliza todos los desalojos hasta que se re-establece la conectividad. +Por consiguiente, si todos los nodos de una zona se encuentran en mal estado, el nodo controlador desaloja al ritmo normal `--node-eviction-rate`. En el caso extremo de que todas las zonas se encuentran en mal estado (es decir, no responda ningún nodo del clúster), el controlador de nodos asume que hay algún tipo de problema con la conectividad del nodo máster y paraliza todos los desalojos hasta que se restablezca la conectividad. Desde la versión 1.6 de Kubernetes el controlador de nodos también es el responsable de desalojar pods que están ejecutándose en nodos con `NoExecute` taints, cuando los pods no permiten dichos taints. De forma adicional, como una funcionalidad alfa que permanece deshabilitada por defecto, el `NodeController` es responsable de añadir taints que se corresponden con problemas en los nodos del tipo nodo inalcanzable o nodo no preparado. En [esta sección de la documentación](/docs/concepts/configuration/taint-and-toleration/) hay más detalles acerca de los taints `NoExecute` y de la funcionalidad alfa. From 6f37fbb1db51de3799f7ed33eeee82bbb2505348 Mon Sep 17 00:00:00 2001 From: Makise <844082183@qq.com> Date: Mon, 15 Jun 2020 14:07:04 +0800 Subject: [PATCH 024/218] kube-scheduler.md has wrong indent MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 缩进错了，网页样式不对 --- .../kube-scheduler.md | 1934 ++++++++--------- 1 file changed, 967 insertions(+), 967 deletions(-) diff --git a/content/zh/docs/reference/command-line-tools-reference/kube-scheduler.md b/content/zh/docs/reference/command-line-tools-reference/kube-scheduler.md index 183bdf46d9..89d8914642 100644 --- a/content/zh/docs/reference/command-line-tools-reference/kube-scheduler.md +++ b/content/zh/docs/reference/command-line-tools-reference/kube-scheduler.md @@ -42,973 +42,973 @@ kube-scheduler [flags] - - --add-dir-header - - - - - 如果为 true，则将文件目录添加到标题中 - - - - - - - --address string     默认: "0.0.0.0" - - - - - - 弃用: 要监听 --port 端口的 IP 地址（对于所有 IPv4 接口设置为 0.0.0.0，对于所有 IPv6 接口设置为 ::）。 请参阅 --bind-address。 - - - - - --algorithm-provider string - - - - - 弃用: 要使用的调度算法，可选值：ClusterAutoscalerProvider | DefaultProvider - - - - - --alsologtostderr - - - - - - - - - --authentication-kubeconfig string - - - - - - - - - --authentication-skip-lookup - - - - - 如果为 false，则 authentication-kubeconfig 将用于从集群中查找缺少的身份验证配置。 - - - - - - - --authentication-token-webhook-cache-ttl duration     默认: 10s - - - - - - 缓存来自 Webhook 令牌身份验证器的响应的持续时间。 - - - - - - - --authentication-tolerate-lookup-failure     默认: true - - - - - - 如果为 true，则无法从集群中查找缺少的身份验证配置是致命的。请注意，这可能导致身份验证将所有请求视为匿名。 - - - - - - - --authorization-always-allow-paths stringSlice     默认: [/healthz] - - - - - - 在授权过程中跳过的 HTTP 路径列表，即在不联系 'core' kubernetes 服务器的情况下被授权的 HTTP 路径。 - - - - - --authorization-kubeconfig string - - - - - 指向具有足够权限以创建 subjectaccessreviews.authorization.k8s.io 的 'core' kubernetes 服务器的 kubeconfig 文件。这是可选的。如果为空，则禁止所有未经授权跳过的请求。 - - - - - - - --authorization-webhook-cache-authorized-ttl duration     默认: 10s - - - - - - 缓存来自 Webhook 授权者的 'authorized' 响应的持续时间。 - - - - - - - --authorization-webhook-cache-unauthorized-ttl duration     默认: 10s - - - - - - 缓存来自 Webhook 授权者的 'unauthorized' 响应的持续时间。 - - - - - --azure-container-registry-config string - - - - - 包含 Azure 容器仓库配置信息的文件的路径。 - - - - - - - --bind-address ip     默认: 0.0.0.0 - - - - - - 侦听 --secure-port 端口的 IP 地址。集群的其余部分以及 CLI/ Web 客户端必须可以访问关联的接口。如果为空，将使用所有接口（所有 IPv4 接口使用 0.0.0.0，所有 IPv6 接口使用 ::）。 - - - - - --cert-dir string - - - - - TLS 证书所在的目录。如果提供了--tls-cert-file 和 --tls private-key-file，则将忽略此参数。 - - - - - --client-ca-file string - - - - - 如果已设置，由 client-ca-file 中的授权机构签名的客户端证书的任何请求都将使用与客户端证书的 CommonName 对应的身份进行身份验证。 - - - - - --config string - - - - - 配置文件的路径。标志会覆盖此文件中的值。 - - - - - --contention-profiling - - - - - 弃用: 如果启用了性能分析，则启用锁竞争分析 - - - - - --feature-gates mapStringBool - - - - - 一组 key=value 对，描述了 alpha/experimental 特征开关。选项包括：
APIListChunking=true|false (BETA - 默认值=true)
APIResponseCompression=true|false (BETA - 默认值=true)
AllAlpha=true|false (ALPHA - 默认值=false)
AppArmor=true|false (BETA - 默认值=true)
AttachVolumeLimit=true|false (BETA - 默认值=true)
BalanceAttachedNodeVolumes=true|false (ALPHA - 默认值=false)
BlockVolume=true|false (BETA - 默认值=true)
BoundServiceAccountTokenVolume=true|false (ALPHA - 默认值=false)
CPUManager=true|false (BETA - 默认值=true)
CRIContainerLogRotation=true|false (BETA - 默认值=true)
CSIBlockVolume=true|false (BETA - 默认值=true)
CSIDriverRegistry=true|false (BETA - 默认值=true)
CSIInlineVolume=true|false (BETA - 默认值=true)
CSIMigration=true|false (ALPHA - 默认值=false)
CSIMigrationAWS=true|false (ALPHA - 默认值=false)
CSIMigrationAzureDisk=true|false (ALPHA - 默认值=false)
CSIMigrationAzureFile=true|false (ALPHA - 默认值=false)
CSIMigrationGCE=true|false (ALPHA - 默认值=false)
CSIMigrationOpenStack=true|false (ALPHA - 默认值=false)
CSINodeInfo=true|false (BETA - 默认值=true)
CustomCPUCFSQuotaPeriod=true|false (ALPHA - 默认值=false)
CustomResourceDefaulting=true|false (BETA - 默认值=true)
DevicePlugins=true|false (BETA - 默认值=true)
DryRun=true|false (BETA - 默认值=true)
DynamicAuditing=true|false (ALPHA - 默认值=false)
DynamicKubeletConfig=true|false (BETA - 默认值=true)
EndpointSlice=true|false (ALPHA - 默认值=false)
EphemeralContainers=true|false (ALPHA - 默认值=false)
EvenPodsSpread=true|false (ALPHA - 默认值=false)
ExpandCSIVolumes=true|false (BETA - 默认值=true)
ExpandInUsePersistentVolumes=true|false (BETA - 默认值=true)
ExpandPersistentVolumes=true|false (BETA - 默认值=true)
ExperimentalHostUserNamespaceDefaulting=true|false (BETA - 默认值=false)
HPAScaleToZero=true|false (ALPHA - 默认值=false)
HyperVContainer=true|false (ALPHA - 默认值=false)
IPv6DualStack=true|false (ALPHA - 默认值=false)
KubeletPodResources=true|false (BETA - 默认值=true)
LegacyNodeRoleBehavior=true|false (ALPHA - 默认值=true)
LocalStorageCapacityIsolation=true|false (BETA - 默认值=true)
LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - 默认值=false)
MountContainers=true|false (ALPHA - 默认值=false)
NodeDisruptionExclusion=true|false (ALPHA - 默认值=false)
NodeLease=true|false (BETA - 默认值=true)
NonPreemptingPriority=true|false (ALPHA - 默认值=false)
PodOverhead=true|false (ALPHA - 默认值=false)
PodShareProcessNamespace=true|false (BETA - 默认值=true)
ProcMountType=true|false (ALPHA - 默认值=false)
QOSReserved=true|false (ALPHA - 默认值=false)
RemainingItemCount=true|false (BETA - 默认值=true)
RemoveSelfLink=true|false (ALPHA - 默认值=false)
RequestManagement=true|false (ALPHA - 默认值=false)
ResourceLimitsPriorityFunction=true|false (ALPHA - 默认值=false)
ResourceQuotaScopeSelectors=true|false (BETA - 默认值=true)
RotateKubeletClientCertificate=true|false (BETA - 默认值=true)
RotateKubeletServerCertificate=true|false (BETA - 默认值=true)
RunAsGroup=true|false (BETA - 默认值=true)
RuntimeClass=true|false (BETA - 默认值=true)
SCTPSupport=true|false (ALPHA - 默认值=false)
ScheduleDaemonSetPods=true|false (BETA - 默认值=true)
ServerSideApply=true|false (BETA - 默认值=true)
ServiceLoadBalancerFinalizer=true|false (BETA - 默认值=true)
ServiceNodeExclusion=true|false (ALPHA - 默认值=false)
StartupProbe=true|false (BETA - 默认值=true)
StorageVersionHash=true|false (BETA - 默认值=true)
StreamingProxyRedirects=true|false (BETA - 默认值=true)
SupportNodePidsLimit=true|false (BETA - 默认值=true)
SupportPodPidsLimit=true|false (BETA - 默认值=true)
Sysctls=true|false (BETA - 默认值=true)
TTLAfterFinished=true|false (ALPHA - 默认值=false)
TaintBasedEvictions=true|false (BETA - 默认值=true)
TaintNodesByCondition=true|false (BETA - 默认值=true)
TokenRequest=true|false (BETA - 默认值=true)
TokenRequestProjection=true|false (BETA - 默认值=true)
TopologyManager=true|false (ALPHA - 默认值=false)
ValidateProxyRedirects=true|false (BETA - 默认值=true)
VolumePVCDataSource=true|false (BETA - 默认值=true)
VolumeSnapshotDataSource=true|false (ALPHA - 默认值=false)
VolumeSubpathEnvExpansion=true|false (BETA - 默认值=true)
WatchBookmark=true|false (BETA - 默认值=true)
WinDSR=true|false (ALPHA - 默认值=false)
WinOverlay=true|false (ALPHA - 默认值=false)
WindowsGMSA=true|false (BETA - 默认值=true)
WindowsRunAsUserName=true|false (ALPHA - 默认值=false) - - - - - - - --hard-pod-affinity-symmetric-weight int32     默认: 1 - - - - - - 弃用: RequiredDuringScheduling 亲和力不是对称的，但是存在与每个 RequiredDuringScheduling 关联性规则相对应的隐式 PreferredDuringScheduling 关联性规则 --hard-pod-affinity-symmetric-weight 代表隐式 PreferredDuringScheduling 关联性规则的权重。权重必须在 0-100 范围内。此选项已移至策略配置文件。 - - - - - -h, --help - - - - - kube-scheduler 帮助命令 - - - - - --http2-max-streams-per-connection int - - - - - 服务器为客户端提供的 HTTP/2 连接最大限制。零表示使用 golang 的默认值。 - - - - - - - --kube-api-burst int32     默认: 100 - - - - - - 弃用: 与 kubernetes apiserver 通信时使用 - - - - - - - --kube-api-content-type string     默认: "application/vnd.kubernetes.protobuf" - - - - - - 弃用: 发送到 apiserver 的请求的内容类型。 - - - - - - - --kube-api-qps float32     默认: 50 - - - - - - 弃用: 与 kubernetes apiserver 通信时要使用的 QPS - - - - - --kubeconfig string - - - - - 弃用: 具有授权和主节点位置信息的 kubeconfig 文件的路径。 - - - - - - - --leader-elect     默认: true - - - - - - 在执行主循环之前，开始领导者选举并选出领导者。为实现高可用性，运行多副本的组件并选出领导者。 - - - - - - - --leader-elect-lease-duration duration     默认: 15s - - - - - - 非领导者候选人在观察到领导者更新后将等待直到试图获得领导但未更新的领导者职位的等待时间。这实际上是领导者在被另一位候选人替代之前可以停止的最大持续时间。该情况仅在启用了领导者选举的情况下才适用。 - - - - - - - --leader-elect-renew-deadline duration     默认: 10s - - - - - - - 领导者尝试在停止领导之前更新领导职位的间隔时间。该时间必须小于或等于租赁期限。仅在启用了领导者选举的情况下才适用。 - - - - - - --leader-elect-resource-lock endpoints     默认: "endpoints" - - - - - - 在领导者选举期间用于锁定的资源对象的类型。支持的选项是端点（默认）和 `configmaps` - - - - - - - --leader-elect-resource-name string     默认: "kube-scheduler" - - - - - - 在领导者选举期间用于锁定的资源对象的名称。 - - - - - - - --leader-elect-resource-namespace string     默认: "kube-system" - - - - - - 在领导者选举期间用于锁定的资源对象的命名空间。 - - - - - - - --leader-elect-retry-period duration     默认: 2s - - - - - - 客户应在尝试获取和更新领导之间等待的时间。仅在启用了领导者选举的情况下才适用。 - - - - - - - --lock-object-name string     默认: "kube-scheduler" - - - - - - 弃用: 定义锁对象的名称。将被删除以便使用 Leader-elect-resource-name - - - - - - - --lock-object-namespace string     默认: "kube-system" - - - - - - 弃用: 定义锁对象的命名空间。将被删除以便使用 leader-elect-resource-namespace。 - - - - - - - --log-backtrace-at traceLocation     默认: :0 - - - - - - 当记录命中行文件：N 时发出堆栈跟踪 - - - - - --log-dir string - - - - - 如果为非空，则在此目录中写入日志文件 - - - - - --log-file string - - - - - 如果为非空，请使用此日志文件 - - - - - - - --log-file-max-size uint     默认: 1800 - - - - - - 定义日志文件可以增长到的最大值。单位为兆字节。如果值为0，则最大文件大小为无限制。 - - - - - - - --log-flush-frequency duration     默认: 5s - - - - - - 两次日志刷新之间的最大秒数 - - - - - - - --logtostderr     默认: true - - - - - - 日志记录到标准错误而不是文件 - - - - - --master string - - - - - Kubernetes API 服务器的地址（覆盖 kubeconfig 中的任何值） - - - - - --policy-config-file string - - - - - 弃用：具有调度程序策略配置的文件。如果未提供 policy ConfigMap 或 --use-legacy-policy-config = true，则使用此文件 - - - - - --policy-configmap string - - - - - 弃用: 包含调度程序策略配置的 ConfigMap 对象的名称。如果 --use-legacy-policy-config = false，则它必须在调度程序初始化之前存在于系统命名空间中。必须将配置作为键为 'policy.cfg' 的 'Data' 映射中元素的值提供 - - - - - - - --policy-configmap-namespace string     默认: "kube-system" - - - - - - 弃用: 策略 ConfigMap 所在的命名空间。如果未提供或为空，则将使用 kube-system 命名空间。 - - - - - - - --port int     默认: 10251 - - - - - - 弃用: 在没有身份验证和授权的情况下不安全地为 HTTP 服务的端口。如果为0，则根本不提供 HTTP。请参见--secure-port。 - - - - - --profiling - - - - - 弃用: 通过 Web 界面主机启用配置文件：port/debug/pprof/ - - - - - --requestheader-allowed-names stringSlice - - - - - 客户端证书通用名称列表允许在 --requestheader-username-headers 指定的头部中提供用户名。如果为空，则允许任何由权威机构 --requestheader-client-ca-file 验证的客户端证书。 - - - - - --requestheader-client-ca-file string - - - - - 在信任 --requestheader-username-headers 指定的头部中的用户名之前用于验证传入请求上的客户端证书的根证书包。警告：通常不依赖于传入请求已经完成的授权。 - - - - - - - --requestheader-extra-headers-prefix stringSlice     默认: [x-remote-extra-] - - - - - - 要检查请求头部前缀列表。建议使用 X-Remote-Extra- - - - - - - - --requestheader-group-headers stringSlice     默认: [x-remote-group] - - - - - - 用于检查组的请求头部列表。建议使用 X-Remote-Group。 - - - - - - - --requestheader-username-headers stringSlice     默认: [x-remote-user] - - - - - - 用于检查用户名的请求头部列表。 X-Remote-User 很常见。 - - - - - - - --scheduler-name string     默认: "default-scheduler" - - - - - - 弃用: 调度程序名称用于根据 Pod 的 "spec.schedulerName" 选择此调度程序将处理的 Pod。 - - - - - - - --secure-port int     默认: 10259 - - - - - - 通过身份验证和授权为 HTTPS 服务的端口。如果为 0，则根本不提供 HTTPS。 - - - - - --skip-headers - - - - - 如果为 true，请在日志消息中避免头部前缀 - - - - - --skip-log-headers - - - - - 如果为true，则在打开日志文件时避免头部 - - - - - - - --stderrthreshold severity     默认: 2 - - - - - - 达到或超过此阈值的日志转到 stderr - - - - - --tls-cert-file string - - - - - 包含默认的 HTTPS x509 证书的文件。（CA证书（如果有）在服务器证书之后并置）。如果启用了 HTTPS 服务，并且未提供 --tls-cert-file 和 --tls-private-key-file，则会为公共地址生成一个自签名证书和密钥，并将其保存到 --cert-dir 指定的目录中。 - - - - - --tls-cipher-suites stringSlice - - - - - 服务器的密码套件列表，以逗号分隔。如果省略，将使用默认的 Go 密码套件。可能的值： - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_RC4_128_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_RC4_128_SHA - - - - - --tls-min-version string - - - - - 支持的最低 TLS 版本。可能的值：VersionTLS10, VersionTLS11, VersionTLS12, VersionTLS13 - - - - - --tls-private-key-file string - - - - - 包含与 --tls-cert-file 匹配的默认 x509 私钥的文件。 - - - - - - - --tls-sni-cert-key namedCertKey     默认: [] - - - - - - 一对 x509 证书和私钥文件路径，可选地后缀为完全限定域名的域模式列表，并可能带有前缀的通配符段。如果未提供域模式，则获取证书名称。非通配符匹配胜过通配符匹配，显式域模式胜过获取名称。 对于多个密钥/证书对，请多次使用 --tls-sni-cert-key。例如: "example.crt,example.key" 或者 "foo.crt,foo.key:*.foo.com,foo.com"。 - - - - - --use-legacy-policy-config - - - - - 弃用: 设置为 true 时，调度程序将忽略策略 ConfigMap 并使用策略配置文件 - - - - - -v, --v Level - - - - - 日志级别详细程度的数字 - - - - - --version version[=true] - - - - - 打印版本信息并退出 - - - - - --vmodule moduleSpec - - - - - 以逗号分隔的 pattern = N 设置列表，用于文件过滤的日志记录 - - - - - --write-config-to string - - - - - 如果已设置，请将配置值写入此文件并退出。 - - + + --add-dir-header + + + + + 如果为 true，则将文件目录添加到标题中 + + + + + + + --address string     默认: "0.0.0.0" + + + + + + 弃用: 要监听 --port 端口的 IP 地址（对于所有 IPv4 接口设置为 0.0.0.0，对于所有 IPv6 接口设置为 ::）。 请参阅 --bind-address。 + + + + + --algorithm-provider string + + + + + 弃用: 要使用的调度算法，可选值：ClusterAutoscalerProvider | DefaultProvider + + + + + --alsologtostderr + + + + + + + + + --authentication-kubeconfig string + + + + + + + + + --authentication-skip-lookup + + + + + 如果为 false，则 authentication-kubeconfig 将用于从集群中查找缺少的身份验证配置。 + + + + + + + --authentication-token-webhook-cache-ttl duration     默认: 10s + + + + + + 缓存来自 Webhook 令牌身份验证器的响应的持续时间。 + + + + + + + --authentication-tolerate-lookup-failure     默认: true + + + + + + 如果为 true，则无法从集群中查找缺少的身份验证配置是致命的。请注意，这可能导致身份验证将所有请求视为匿名。 + + + + + + + --authorization-always-allow-paths stringSlice     默认: [/healthz] + + + + + + 在授权过程中跳过的 HTTP 路径列表，即在不联系 'core' kubernetes 服务器的情况下被授权的 HTTP 路径。 + + + + + --authorization-kubeconfig string + + + + + 指向具有足够权限以创建 subjectaccessreviews.authorization.k8s.io 的 'core' kubernetes 服务器的 kubeconfig 文件。这是可选的。如果为空，则禁止所有未经授权跳过的请求。 + + + + + + + --authorization-webhook-cache-authorized-ttl duration     默认: 10s + + + + + + 缓存来自 Webhook 授权者的 'authorized' 响应的持续时间。 + + + + + + + --authorization-webhook-cache-unauthorized-ttl duration     默认: 10s + + + + + + 缓存来自 Webhook 授权者的 'unauthorized' 响应的持续时间。 + + + + + --azure-container-registry-config string + + + + + 包含 Azure 容器仓库配置信息的文件的路径。 + + + + + + + --bind-address ip     默认: 0.0.0.0 + + + + + + 侦听 --secure-port 端口的 IP 地址。集群的其余部分以及 CLI/ Web 客户端必须可以访问关联的接口。如果为空，将使用所有接口（所有 IPv4 接口使用 0.0.0.0，所有 IPv6 接口使用 ::）。 + + + + + --cert-dir string + + + + + TLS 证书所在的目录。如果提供了--tls-cert-file 和 --tls private-key-file，则将忽略此参数。 + + + + + --client-ca-file string + + + + + 如果已设置，由 client-ca-file 中的授权机构签名的客户端证书的任何请求都将使用与客户端证书的 CommonName 对应的身份进行身份验证。 + + + + + --config string + + + + + 配置文件的路径。标志会覆盖此文件中的值。 + + + + + --contention-profiling + + + + + 弃用: 如果启用了性能分析，则启用锁竞争分析 + + + + + --feature-gates mapStringBool + + + + + 一组 key=value 对，描述了 alpha/experimental 特征开关。选项包括：
APIListChunking=true|false (BETA - 默认值=true)
APIResponseCompression=true|false (BETA - 默认值=true)
AllAlpha=true|false (ALPHA - 默认值=false)
AppArmor=true|false (BETA - 默认值=true)
AttachVolumeLimit=true|false (BETA - 默认值=true)
BalanceAttachedNodeVolumes=true|false (ALPHA - 默认值=false)
BlockVolume=true|false (BETA - 默认值=true)
BoundServiceAccountTokenVolume=true|false (ALPHA - 默认值=false)
CPUManager=true|false (BETA - 默认值=true)
CRIContainerLogRotation=true|false (BETA - 默认值=true)
CSIBlockVolume=true|false (BETA - 默认值=true)
CSIDriverRegistry=true|false (BETA - 默认值=true)
CSIInlineVolume=true|false (BETA - 默认值=true)
CSIMigration=true|false (ALPHA - 默认值=false)
CSIMigrationAWS=true|false (ALPHA - 默认值=false)
CSIMigrationAzureDisk=true|false (ALPHA - 默认值=false)
CSIMigrationAzureFile=true|false (ALPHA - 默认值=false)
CSIMigrationGCE=true|false (ALPHA - 默认值=false)
CSIMigrationOpenStack=true|false (ALPHA - 默认值=false)
CSINodeInfo=true|false (BETA - 默认值=true)
CustomCPUCFSQuotaPeriod=true|false (ALPHA - 默认值=false)
CustomResourceDefaulting=true|false (BETA - 默认值=true)
DevicePlugins=true|false (BETA - 默认值=true)
DryRun=true|false (BETA - 默认值=true)
DynamicAuditing=true|false (ALPHA - 默认值=false)
DynamicKubeletConfig=true|false (BETA - 默认值=true)
EndpointSlice=true|false (ALPHA - 默认值=false)
EphemeralContainers=true|false (ALPHA - 默认值=false)
EvenPodsSpread=true|false (ALPHA - 默认值=false)
ExpandCSIVolumes=true|false (BETA - 默认值=true)
ExpandInUsePersistentVolumes=true|false (BETA - 默认值=true)
ExpandPersistentVolumes=true|false (BETA - 默认值=true)
ExperimentalHostUserNamespaceDefaulting=true|false (BETA - 默认值=false)
HPAScaleToZero=true|false (ALPHA - 默认值=false)
HyperVContainer=true|false (ALPHA - 默认值=false)
IPv6DualStack=true|false (ALPHA - 默认值=false)
KubeletPodResources=true|false (BETA - 默认值=true)
LegacyNodeRoleBehavior=true|false (ALPHA - 默认值=true)
LocalStorageCapacityIsolation=true|false (BETA - 默认值=true)
LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - 默认值=false)
MountContainers=true|false (ALPHA - 默认值=false)
NodeDisruptionExclusion=true|false (ALPHA - 默认值=false)
NodeLease=true|false (BETA - 默认值=true)
NonPreemptingPriority=true|false (ALPHA - 默认值=false)
PodOverhead=true|false (ALPHA - 默认值=false)
PodShareProcessNamespace=true|false (BETA - 默认值=true)
ProcMountType=true|false (ALPHA - 默认值=false)
QOSReserved=true|false (ALPHA - 默认值=false)
RemainingItemCount=true|false (BETA - 默认值=true)
RemoveSelfLink=true|false (ALPHA - 默认值=false)
RequestManagement=true|false (ALPHA - 默认值=false)
ResourceLimitsPriorityFunction=true|false (ALPHA - 默认值=false)
ResourceQuotaScopeSelectors=true|false (BETA - 默认值=true)
RotateKubeletClientCertificate=true|false (BETA - 默认值=true)
RotateKubeletServerCertificate=true|false (BETA - 默认值=true)
RunAsGroup=true|false (BETA - 默认值=true)
RuntimeClass=true|false (BETA - 默认值=true)
SCTPSupport=true|false (ALPHA - 默认值=false)
ScheduleDaemonSetPods=true|false (BETA - 默认值=true)
ServerSideApply=true|false (BETA - 默认值=true)
ServiceLoadBalancerFinalizer=true|false (BETA - 默认值=true)
ServiceNodeExclusion=true|false (ALPHA - 默认值=false)
StartupProbe=true|false (BETA - 默认值=true)
StorageVersionHash=true|false (BETA - 默认值=true)
StreamingProxyRedirects=true|false (BETA - 默认值=true)
SupportNodePidsLimit=true|false (BETA - 默认值=true)
SupportPodPidsLimit=true|false (BETA - 默认值=true)
Sysctls=true|false (BETA - 默认值=true)
TTLAfterFinished=true|false (ALPHA - 默认值=false)
TaintBasedEvictions=true|false (BETA - 默认值=true)
TaintNodesByCondition=true|false (BETA - 默认值=true)
TokenRequest=true|false (BETA - 默认值=true)
TokenRequestProjection=true|false (BETA - 默认值=true)
TopologyManager=true|false (ALPHA - 默认值=false)
ValidateProxyRedirects=true|false (BETA - 默认值=true)
VolumePVCDataSource=true|false (BETA - 默认值=true)
VolumeSnapshotDataSource=true|false (ALPHA - 默认值=false)
VolumeSubpathEnvExpansion=true|false (BETA - 默认值=true)
WatchBookmark=true|false (BETA - 默认值=true)
WinDSR=true|false (ALPHA - 默认值=false)
WinOverlay=true|false (ALPHA - 默认值=false)
WindowsGMSA=true|false (BETA - 默认值=true)
WindowsRunAsUserName=true|false (ALPHA - 默认值=false) + + + + + + + --hard-pod-affinity-symmetric-weight int32     默认: 1 + + + + + + 弃用: RequiredDuringScheduling 亲和力不是对称的，但是存在与每个 RequiredDuringScheduling 关联性规则相对应的隐式 PreferredDuringScheduling 关联性规则 --hard-pod-affinity-symmetric-weight 代表隐式 PreferredDuringScheduling 关联性规则的权重。权重必须在 0-100 范围内。此选项已移至策略配置文件。 + + + + + -h, --help + + + + + kube-scheduler 帮助命令 + + + + + --http2-max-streams-per-connection int + + + + + 服务器为客户端提供的 HTTP/2 连接最大限制。零表示使用 golang 的默认值。 + + + + + + + --kube-api-burst int32     默认: 100 + + + + + + 弃用: 与 kubernetes apiserver 通信时使用 + + + + + + + --kube-api-content-type string     默认: "application/vnd.kubernetes.protobuf" + + + + + + 弃用: 发送到 apiserver 的请求的内容类型。 + + + + + + + --kube-api-qps float32     默认: 50 + + + + + + 弃用: 与 kubernetes apiserver 通信时要使用的 QPS + + + + + --kubeconfig string + + + + + 弃用: 具有授权和主节点位置信息的 kubeconfig 文件的路径。 + + + + + + + --leader-elect     默认: true + + + + + + 在执行主循环之前，开始领导者选举并选出领导者。为实现高可用性，运行多副本的组件并选出领导者。 + + + + + + + --leader-elect-lease-duration duration     默认: 15s + + + + + + 非领导者候选人在观察到领导者更新后将等待直到试图获得领导但未更新的领导者职位的等待时间。这实际上是领导者在被另一位候选人替代之前可以停止的最大持续时间。该情况仅在启用了领导者选举的情况下才适用。 + + + + + + + --leader-elect-renew-deadline duration     默认: 10s + + + + + + + 领导者尝试在停止领导之前更新领导职位的间隔时间。该时间必须小于或等于租赁期限。仅在启用了领导者选举的情况下才适用。 + + + + + + --leader-elect-resource-lock endpoints     默认: "endpoints" + + + + + + 在领导者选举期间用于锁定的资源对象的类型。支持的选项是端点（默认）和 `configmaps` + + + + + + + --leader-elect-resource-name string     默认: "kube-scheduler" + + + + + + 在领导者选举期间用于锁定的资源对象的名称。 + + + + + + + --leader-elect-resource-namespace string     默认: "kube-system" + + + + + + 在领导者选举期间用于锁定的资源对象的命名空间。 + + + + + + + --leader-elect-retry-period duration     默认: 2s + + + + + + 客户应在尝试获取和更新领导之间等待的时间。仅在启用了领导者选举的情况下才适用。 + + + + + + + --lock-object-name string     默认: "kube-scheduler" + + + + + + 弃用: 定义锁对象的名称。将被删除以便使用 Leader-elect-resource-name + + + + + + + --lock-object-namespace string     默认: "kube-system" + + + + + + 弃用: 定义锁对象的命名空间。将被删除以便使用 leader-elect-resource-namespace。 + + + + + + + --log-backtrace-at traceLocation     默认: :0 + + + + + + 当记录命中行文件：N 时发出堆栈跟踪 + + + + + --log-dir string + + + + + 如果为非空，则在此目录中写入日志文件 + + + + + --log-file string + + + + + 如果为非空，请使用此日志文件 + + + + + + + --log-file-max-size uint     默认: 1800 + + + + + + 定义日志文件可以增长到的最大值。单位为兆字节。如果值为0，则最大文件大小为无限制。 + + + + + + + --log-flush-frequency duration     默认: 5s + + + + + + 两次日志刷新之间的最大秒数 + + + + + + + --logtostderr     默认: true + + + + + + 日志记录到标准错误而不是文件 + + + + + --master string + + + + + Kubernetes API 服务器的地址（覆盖 kubeconfig 中的任何值） + + + + + --policy-config-file string + + + + + 弃用：具有调度程序策略配置的文件。如果未提供 policy ConfigMap 或 --use-legacy-policy-config = true，则使用此文件 + + + + + --policy-configmap string + + + + + 弃用: 包含调度程序策略配置的 ConfigMap 对象的名称。如果 --use-legacy-policy-config = false，则它必须在调度程序初始化之前存在于系统命名空间中。必须将配置作为键为 'policy.cfg' 的 'Data' 映射中元素的值提供 + + + + + + + --policy-configmap-namespace string     默认: "kube-system" + + + + + + 弃用: 策略 ConfigMap 所在的命名空间。如果未提供或为空，则将使用 kube-system 命名空间。 + + + + + + + --port int     默认: 10251 + + + + + + 弃用: 在没有身份验证和授权的情况下不安全地为 HTTP 服务的端口。如果为0，则根本不提供 HTTP。请参见--secure-port。 + + + + + --profiling + + + + + 弃用: 通过 Web 界面主机启用配置文件：port/debug/pprof/ + + + + + --requestheader-allowed-names stringSlice + + + + + 客户端证书通用名称列表允许在 --requestheader-username-headers 指定的头部中提供用户名。如果为空，则允许任何由权威机构 --requestheader-client-ca-file 验证的客户端证书。 + + + + + --requestheader-client-ca-file string + + + + + 在信任 --requestheader-username-headers 指定的头部中的用户名之前用于验证传入请求上的客户端证书的根证书包。警告：通常不依赖于传入请求已经完成的授权。 + + + + + + + --requestheader-extra-headers-prefix stringSlice     默认: [x-remote-extra-] + + + + + + 要检查请求头部前缀列表。建议使用 X-Remote-Extra- + + + + + + + --requestheader-group-headers stringSlice     默认: [x-remote-group] + + + + + + 用于检查组的请求头部列表。建议使用 X-Remote-Group。 + + + + + + + --requestheader-username-headers stringSlice     默认: [x-remote-user] + + + + + + 用于检查用户名的请求头部列表。 X-Remote-User 很常见。 + + + + + + + --scheduler-name string     默认: "default-scheduler" + + + + + + 弃用: 调度程序名称用于根据 Pod 的 "spec.schedulerName" 选择此调度程序将处理的 Pod。 + + + + + + + --secure-port int     默认: 10259 + + + + + + 通过身份验证和授权为 HTTPS 服务的端口。如果为 0，则根本不提供 HTTPS。 + + + + + --skip-headers + + + + + 如果为 true，请在日志消息中避免头部前缀 + + + + + --skip-log-headers + + + + + 如果为true，则在打开日志文件时避免头部 + + + + + + + --stderrthreshold severity     默认: 2 + + + + + + 达到或超过此阈值的日志转到 stderr + + + + + --tls-cert-file string + + + + + 包含默认的 HTTPS x509 证书的文件。（CA证书（如果有）在服务器证书之后并置）。如果启用了 HTTPS 服务，并且未提供 --tls-cert-file 和 --tls-private-key-file，则会为公共地址生成一个自签名证书和密钥，并将其保存到 --cert-dir 指定的目录中。 + + + + + --tls-cipher-suites stringSlice + + + + + 服务器的密码套件列表，以逗号分隔。如果省略，将使用默认的 Go 密码套件。可能的值： + TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_RC4_128_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_RC4_128_SHA + + + + + --tls-min-version string + + + + + 支持的最低 TLS 版本。可能的值：VersionTLS10, VersionTLS11, VersionTLS12, VersionTLS13 + + + + + --tls-private-key-file string + + + + + 包含与 --tls-cert-file 匹配的默认 x509 私钥的文件。 + + + + + + + --tls-sni-cert-key namedCertKey     默认: [] + + + + + + 一对 x509 证书和私钥文件路径，可选地后缀为完全限定域名的域模式列表，并可能带有前缀的通配符段。如果未提供域模式，则获取证书名称。非通配符匹配胜过通配符匹配，显式域模式胜过获取名称。 对于多个密钥/证书对，请多次使用 --tls-sni-cert-key。例如: "example.crt,example.key" 或者 "foo.crt,foo.key:*.foo.com,foo.com"。 + + + + + --use-legacy-policy-config + + + + + 弃用: 设置为 true 时，调度程序将忽略策略 ConfigMap 并使用策略配置文件 + + + + + -v, --v Level + + + + + 日志级别详细程度的数字 + + + + + --version version[=true] + + + + + 打印版本信息并退出 + + + + + --vmodule moduleSpec + + + + + 以逗号分隔的 pattern = N 设置列表，用于文件过滤的日志记录 + + + + + --write-config-to string + + + + + 如果已设置，请将配置值写入此文件并退出。 + + From bdc173ce13ed9572b82325af6548cc959f9d566a Mon Sep 17 00:00:00 2001 From: Roy Lenferink Date: Mon, 15 Jun 2020 12:28:23 +0200 Subject: [PATCH 025/218] Update docs for new container- Makefile targets --- .../docs/contribute/new-content/open-a-pr.md | 22 ++++++++++++++++--- 1 file changed, 19 insertions(+), 3 deletions(-) diff --git a/content/en/docs/contribute/new-content/open-a-pr.md b/content/en/docs/contribute/new-content/open-a-pr.md index 05a576a74b..5b2642dd39 100644 --- a/content/en/docs/contribute/new-content/open-a-pr.md +++ b/content/en/docs/contribute/new-content/open-a-pr.md @@ -217,21 +217,37 @@ When you are ready to submit a pull request, commit your changes. It's a good idea to preview your changes locally before pushing them or opening a pull request. A preview lets you catch build errors or markdown formatting problems. -You can either build the website's docker image or run Hugo locally. Building the docker image is slower but displays [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/), which can be useful for debugging. +You can either build the website's container image or run Hugo locally. Building the container image is slower but displays [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/), which can be useful for debugging. {{< tabs name="tab_with_hugo" >}} {{% tab name="Hugo in a container" %}} +{{< note >}} +The commands below use Docker as default container engine. Set the `CONTAINER_ENGINE` environment variable to override this behaviour. +{{< /note >}} + 1. Build the image locally: ```bash - make docker-image + # Use docker (default) + make container-image + + ### OR ### + + # Use podman + CONTAINER_ENGINE=podman make container-image ``` 2. After building the `kubernetes-hugo` image locally, build and serve the site: ```bash - make docker-serve + # Use docker (default) + make container-serve + + ### OR ### + + # Use podman + CONTAINER_ENGINE=podman make container-serve ``` 3. In a web browser, navigate to `https://localhost:1313`. Hugo watches the From 622e5f97131586e36bd018b9b361e7a4dbb93f2d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Wang=28=E3=82=8F=E3=82=93=29?= Date: Mon, 15 Jun 2020 21:06:55 +0900 Subject: [PATCH 026/218] update latest kubectl run syntax --dry-run is deprecated `--restart=Never` flag is unnecessary to create a pod from 1.18 --- content/en/docs/reference/kubectl/cheatsheet.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/en/docs/reference/kubectl/cheatsheet.md b/content/en/docs/reference/kubectl/cheatsheet.md index 23d074456c..36629d2c29 100644 --- a/content/en/docs/reference/kubectl/cheatsheet.md +++ b/content/en/docs/reference/kubectl/cheatsheet.md @@ -290,10 +290,10 @@ kubectl logs -f my-pod # stream pod logs (stdout) kubectl logs -f my-pod -c my-container # stream pod container logs (stdout, multi-container case) kubectl logs -f -l name=myLabel --all-containers # stream all pods logs with label name=myLabel (stdout) kubectl run -i --tty busybox --image=busybox -- sh # Run pod as interactive shell -kubectl run nginx --image=nginx --restart=Never -n +kubectl run nginx --image=nginx -n mynamespace # Run pod nginx in a specific namespace -kubectl run nginx --image=nginx --restart=Never # Run pod nginx and write its spec into a file called pod.yaml ---dry-run -o yaml > pod.yaml +kubectl run nginx --image=nginx # Run pod nginx and write its spec into a file called pod.yaml +--dry-run=client -o yaml > pod.yaml kubectl attach my-pod -i # Attach to Running Container kubectl port-forward my-pod 5000:6000 # Listen on port 5000 on the local machine and forward to port 6000 on my-pod From 462d34ef75abd7e879d9159e369ea754fe5d943f Mon Sep 17 00:00:00 2001 From: Tim Bannister Date: Sat, 13 Jun 2020 18:43:50 +0100 Subject: [PATCH 027/218] Separate commands from output in Deployment concept --- .../concepts/workloads/controllers/deployment.md | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/content/en/docs/concepts/workloads/controllers/deployment.md b/content/en/docs/concepts/workloads/controllers/deployment.md index 6287c0d98e..6b117cdc44 100644 --- a/content/en/docs/concepts/workloads/controllers/deployment.md +++ b/content/en/docs/concepts/workloads/controllers/deployment.md @@ -861,7 +861,12 @@ The output is similar to this: ``` Waiting for rollout to finish: 2 of 3 updated replicas are available... deployment.apps/nginx-deployment successfully rolled out -$ echo $? +``` +and the exit status from `kubectl rollout` is 0 (success): +```shell +echo $? +``` +``` 0 ``` @@ -1003,7 +1008,12 @@ The output is similar to this: ``` Waiting for rollout to finish: 2 out of 3 new replicas have been updated... error: deployment "nginx" exceeded its progress deadline -$ echo $? +``` +and the exit status from `kubectl rollout` is 1 (indicating an error): +```shell +echo $? +``` +``` 1 ``` From 4cf2e8e4cb007e84b7d429421ac4669401dfba9f Mon Sep 17 00:00:00 2001 From: Roman Mazurenko Date: Mon, 15 Jun 2020 23:34:04 +0300 Subject: [PATCH 028/218] Clarify imagePullPolicy for empty value imagePullPolicy when defined without a value defaults to Always not to IfNotPresent --- content/en/docs/concepts/containers/images.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/content/en/docs/concepts/containers/images.md b/content/en/docs/concepts/containers/images.md index 47f395841a..b50180b850 100644 --- a/content/en/docs/concepts/containers/images.md +++ b/content/en/docs/concepts/containers/images.md @@ -61,6 +61,8 @@ you can do one of the following: - omit the `imagePullPolicy` and the tag for the image to use. - enable the [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) admission controller. +When `imagePullPolicy` is defined without a specific value, it is also set to `Always`. + ## Multi-architecture Images with Manifests As well as providing binary images, a container registry can also server a [container image manifest](https://github.com/opencontainers/image-spec/blob/master/manifest.md). A manifest can reference image manifests for architecturew-specific versions of an container. The idea is that you can have a name for an image (for example: `pause`, `example/mycontainer`, `kube-apiserver`) and allow different systems to fetch the right binary image for the machine architecture they are using. From 412b4ef0ed78ed9952df479eccf86dce960f9bf0 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Wed, 17 Jun 2020 00:43:46 +0900 Subject: [PATCH 029/218] Fix the no search result error when the keyword includes spaces. --- static/js/search.js | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/static/js/search.js b/static/js/search.js index 74eeff657c..2a4a03aff8 100644 --- a/static/js/search.js +++ b/static/js/search.js @@ -11,7 +11,7 @@ } window.getPaginationAnchors = (pages) => { - var pageAnchors = '', searchTerm = window.location.search.split("=")[1].split("&")[0]; + var pageAnchors = '', searchTerm = window.location.search.split("=")[1].split("&")[0].replace(/%20/g, ' '); var currentPage = window.location.search.split("=")[2]; currentPage = (!currentPage) ? 1 : currentPage.split("&")[0]; @@ -33,7 +33,7 @@ } window.renderBingSearchResults = () => { - var searchTerm = window.location.search.split("=")[1].split("&")[0], + var searchTerm = window.location.search.split("=")[1].split("&")[0].replace(/%20/g,' '), page = window.location.search.split("=")[2], q = "site:kubernetes.io " + searchTerm; @@ -47,6 +47,7 @@ ajaxConf.beforeSend = function(xhr){ xhr.setRequestHeader('Ocp-Apim-Subscription-Key', '51efd23677624e04b4abe921225ea7ec'); }; $.ajax(ajaxConf).done(function(res) { + if (res.webPages == null) return; // If no result, 'webPages' is 'undefined' var paginationAnchors = window.getPaginationAnchors(Math.ceil(res.webPages.totalEstimatedMatches / 10)); res.webPages.value.map(ob => { results += window.getResultMarkupString(ob); }) From cd37817af8774d0f6c435634ade3db188fadea07 Mon Sep 17 00:00:00 2001 From: divya bhushan Date: Tue, 16 Jun 2020 20:27:20 +0200 Subject: [PATCH 030/218] Add Kubernetes download button --- content/en/docs/home/_index.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/content/en/docs/home/_index.md b/content/en/docs/home/_index.md index b4f9a2ee66..8864e4781a 100644 --- a/content/en/docs/home/_index.md +++ b/content/en/docs/home/_index.md @@ -59,6 +59,8 @@ cards: - name: release-notes title: Release Notes description: If you are installing Kubernetes or upgrading to the newest version, refer to the current release notes. + button: "Download Kubernetes" + button_path: "/docs/setup/release/notes" - name: about title: About the documentation description: This website contains documentation for the current and previous 4 versions of Kubernetes. From 7b85bc3b49685cca6339e0f6834306a0659f31f0 Mon Sep 17 00:00:00 2001 From: Tim Bannister Date: Tue, 16 Jun 2020 20:33:01 +0100 Subject: [PATCH 031/218] Use a shallow clone for submodules in Netlify --- netlify.toml | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/netlify.toml b/netlify.toml index e17b26ac21..681e1ea7ab 100644 --- a/netlify.toml +++ b/netlify.toml @@ -4,7 +4,7 @@ # DO NOT REMOVE THIS (contact @kubernetes/sig-docs-leads) publish = "public" functions = "functions" -command = "git submodule update --init --recursive && make non-production-build" +command = "git submodule update --init --recursive --depth 1 && make non-production-build" [build.environment] HUGO_VERSION = "0.70.0" @@ -16,13 +16,13 @@ HUGO_ENV = "production" HUGO_ENABLEGITINFO = "true" [context.deploy-preview] -command = "git submodule update --init --recursive && make deploy-preview" +command = "git submodule update --init --recursive --depth 1 && make deploy-preview" [context.branch-deploy] -command = "git submodule update --init --recursive && make deploy-preview" +command = "git submodule update --init --recursive --depth 1 && make deploy-preview" [context.master] # This context is triggered by the `master` branch and allows search indexing # DO NOT REMOVE THIS (contact @kubernetes/sig-docs-leads) publish = "public" -command = "git submodule update --init --recursive && make production-build" +command = "git submodule update --init --recursive --depth 1 && make production-build" From 6f54e80d123f8e2ce72dde7f3a04a1c287ea234a Mon Sep 17 00:00:00 2001 From: Karen Bradshaw Date: Mon, 15 Jun 2020 17:24:20 -0400 Subject: [PATCH 032/218] add redirects for snapshot api refs --- static/_redirects | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/static/_redirects b/static/_redirects index bb2c0aeba1..242518f7ef 100644 --- a/static/_redirects +++ b/static/_redirects @@ -185,6 +185,12 @@ /docs/reference/kubectl/kubectl/kubectl_*.md /docs/reference/generated/kubectl/kubectl-commands#:splat 301 +/docs/reference/generated/kubernetes-api/v1.14/ https://v1-14.docs.kubernetes.io/docs/reference/generated/kubernetes-api/v1.14/ 301 +/docs/reference/generated/kubernetes-api/v1.15/ https://v1-15.docs.kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/ 301 +/docs/reference/generated/kubernetes-api/v1.16/ https://v1-16.docs.kubernetes.io/docs/reference/generated/kubernetes-api/v1.16/ 301 +/docs/reference/generated/kubernetes-api/v1.17/ https://v1-17.docs.kubernetes.io/docs/reference/generated/kubernetes-api/v1.17/ 301 + + /docs/reporting-security-issues/ /security/ 301 /docs/roadmap/ https://github.com/kubernetes/kubernetes/milestones/ 301 From f8c1f91d97ad0907b55ace52db781ad835847036 Mon Sep 17 00:00:00 2001 From: Arhell Date: Wed, 17 Jun 2020 01:12:13 +0300 Subject: [PATCH 033/218] update to right styling for VolumeSnapshotClass concept --- .../storage/volume-snapshot-classes.md | 22 +++++++++---------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/content/en/docs/concepts/storage/volume-snapshot-classes.md b/content/en/docs/concepts/storage/volume-snapshot-classes.md index f50db19520..7f107b2059 100644 --- a/content/en/docs/concepts/storage/volume-snapshot-classes.md +++ b/content/en/docs/concepts/storage/volume-snapshot-classes.md @@ -13,7 +13,7 @@ weight: 30 -This document describes the concept of `VolumeSnapshotClass` in Kubernetes. Familiarity +This document describes the concept of VolumeSnapshotClass in Kubernetes. Familiarity with [volume snapshots](/docs/concepts/storage/volume-snapshots/) and [storage classes](/docs/concepts/storage/storage-classes) is suggested. @@ -24,22 +24,22 @@ with [volume snapshots](/docs/concepts/storage/volume-snapshots/) and ## Introduction -Just like `StorageClass` provides a way for administrators to describe the "classes" -of storage they offer when provisioning a volume, `VolumeSnapshotClass` provides a +Just like StorageClass provides a way for administrators to describe the "classes" +of storage they offer when provisioning a volume, VolumeSnapshotClass provides a way to describe the "classes" of storage when provisioning a volume snapshot. ## The VolumeSnapshotClass Resource -Each `VolumeSnapshotClass` contains the fields `driver`, `deletionPolicy`, and `parameters`, -which are used when a `VolumeSnapshot` belonging to the class needs to be +Each VolumeSnapshotClass contains the fields `driver`, `deletionPolicy`, and `parameters`, +which are used when a VolumeSnapshot belonging to the class needs to be dynamically provisioned. -The name of a `VolumeSnapshotClass` object is significant, and is how users can +The name of a VolumeSnapshotClass object is significant, and is how users can request a particular class. Administrators set the name and other parameters -of a class when first creating `VolumeSnapshotClass` objects, and the objects cannot +of a class when first creating VolumeSnapshotClass objects, and the objects cannot be updated once they are created. -Administrators can specify a default `VolumeSnapshotClass` just for VolumeSnapshots +Administrators can specify a default VolumeSnapshotClass just for VolumeSnapshots that don't request any particular class to bind to. ```yaml @@ -47,7 +47,7 @@ apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshotClass metadata: name: csi-hostpath-snapclass -driver: hostpath.csi.k8s.io +driver: hostpath.csi.k8s.io deletionPolicy: Delete parameters: ``` @@ -59,9 +59,9 @@ used for provisioning VolumeSnapshots. This field must be specified. ### DeletionPolicy -Volume snapshot classes have a deletionPolicy. It enables you to configure what happens to a `VolumeSnapshotContent` when the `VolumeSnapshot` object it is bound to is to be deleted. The deletionPolicy of a volume snapshot can either be `Retain` or `Delete`. This field must be specified. +Volume snapshot classes have a deletionPolicy. It enables you to configure what happens to a VolumeSnapshotContent when the VolumeSnapshot object it is bound to is to be deleted. The deletionPolicy of a volume snapshot can either be `Retain` or `Delete`. This field must be specified. -If the deletionPolicy is `Delete`, then the underlying storage snapshot will be deleted along with the `VolumeSnapshotContent` object. If the deletionPolicy is `Retain`, then both the underlying snapshot and `VolumeSnapshotContent` remain. +If the deletionPolicy is `Delete`, then the underlying storage snapshot will be deleted along with the VolumeSnapshotContent object. If the deletionPolicy is `Retain`, then both the underlying snapshot and VolumeSnapshotContent remain. ## Parameters From 04dca60eb7b063cb0628b3a813fe5ccfe13cb126 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jos=C3=A9=20Fernando=20Cordova?= Date: Tue, 16 Jun 2020 21:24:52 -0300 Subject: [PATCH 034/218] Typo Spanish Doc --- content/es/docs/concepts/overview/what-is-kubernetes.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/es/docs/concepts/overview/what-is-kubernetes.md b/content/es/docs/concepts/overview/what-is-kubernetes.md index 0c53e120c3..4b2d829b1b 100644 --- a/content/es/docs/concepts/overview/what-is-kubernetes.md +++ b/content/es/docs/concepts/overview/what-is-kubernetes.md @@ -49,7 +49,7 @@ una plataforma: para poder construir un ecosistema de componentes y herramientas más fácil el desplegar, escalar y administrar aplicaciones. Las etiquetas, o [Labels](/es/docs/concepts/overview/working-with-objects/labels/), le -permiten a los usuarios organizar sus recursos como deseen. Las anotaciones , o [Annotations](/es/docs/concepts/overview/working-with-objects/annotations/), les permiten asignar información arbitraria a un recurso para +permiten a los usuarios organizar sus recursos como deseen. Las anotaciones, o [Annotations](/es/docs/concepts/overview/working-with-objects/annotations/), les permiten asignar información arbitraria a un recurso para facilitar sus flujos de trabajo y hacer más fácil a las herramientas administrativas inspeccionar el estado. Además, el [Plano de Control](/docs/concepts/overview/components/) de Kubernetes usa las mismas @@ -127,7 +127,7 @@ En resumen, los beneficios de usar contenedores incluyen: * **Ágil creación y despliegue de aplicaciones**: Mayor facilidad y eficiencia al crear imágenes de contenedor en vez de máquinas virtuales -* **Desarrollo, integración y despliegue continuos**: +* **Desarrollo, integración y despliegue continuo**: Permite que la imagen de contenedor se construya y despliegue de forma frecuente y confiable, facilitando los rollbacks pues la imagen es inmutable * **Separación de tareas entre Dev y Ops**: From 5286dbbce1d8d5c5a4bb814b606b24d78ca52234 Mon Sep 17 00:00:00 2001 From: makocchi-git Date: Wed, 17 Jun 2020 09:59:57 +0900 Subject: [PATCH 035/218] follow upstream README --- README-ja.md | 84 ++++++++++++++++++++++++---------------------------- 1 file changed, 38 insertions(+), 46 deletions(-) diff --git a/README-ja.md b/README-ja.md index 2c69491e2f..cc42a471a5 100644 --- a/README-ja.md +++ b/README-ja.md @@ -3,7 +3,31 @@ [![Build Status](https://api.travis-ci.org/kubernetes/website.svg?branch=master)](https://travis-ci.org/kubernetes/website) [![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest) -ようこそ！このリポジトリには、[KubernetesのWebサイトとドキュメント](https://kubernetes.io/)をビルドするために必要な全アセットが格納されています。貢献に興味を持っていただきありがとうございます！ +このリポジトリには、[KubernetesのWebサイトとドキュメント](https://kubernetes.io/)をビルドするために必要な全アセットが格納されています。貢献に興味を持っていただきありがとうございます！ + +## Hugoを使ってローカル環境でWebサイトを動かす + +Hugoのインストール方法については[Hugoの公式ドキュメント](https://gohugo.io/getting-started/installing/)をご覧ください。このとき、[`netlify.toml`](netlify.toml#L10)ファイルに記述されている`HUGO_VERSION`と同じバージョンをインストールするようにしてください。 + +Hugoがインストールできたら、以下のコマンドを使ってWebサイトをローカル上で動かすことができます: + +```bash +git clone https://github.com/kubernetes/website.git +cd website +git submodule update --init --recursive +hugo server --buildFuture +``` + +これで、Hugoのサーバーが1313番ポートを使って開始します。 お使いのブラウザにて http://localhost:1313 にアクセスしてください。リポジトリ内のソースファイルに変更を加えると、HugoがWebサイトの内容を更新してブラウザに反映します。 + +## SIG Docsに参加する + +[コミュニティのページ](https://github.com/kubernetes/community/tree/master/sig-docs#meetings)をご覧になることで、SIG Docs Kubernetesコミュニティとの関わり方を学ぶことができます。 + +本プロジェクトのメンテナーには以下の方法で連絡することができます: + +- [Slack](https://kubernetes.slack.com/messages/kubernetes-docs-ja) +- [メーリングリスト](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) ## ドキュメントに貢献する @@ -12,63 +36,31 @@ GitHubの画面右上にある**Fork**ボタンをクリックすると、お使 Pull Requestが作成されると、レビュー担当者が責任を持って明確かつ実用的なフィードバックを返します。 Pull Requestの所有者は作成者であるため、**ご自身で作成したPull Requestを編集し、フィードバックに対応するのはご自身の役目です。** また、状況によっては2人以上のレビュアーからフィードバックが返されたり、アサインされていないレビュー担当者からのフィードバックが来ることがある点もご注意ください。 -さらに、特定のケースにおいては、レビュー担当者が[Kubernetes tech reviewer](https://github.com/kubernetes/website/wiki/Tech-reviewers)に対してレビューを依頼することもあります。 +さらに、特定のケースにおいては、レビュー担当者がKubernetesの技術的なレビュアーに対してレビューを依頼することもあります。 レビュー担当者はタイムリーにフィードバックを提供するために最善を尽くしますが、応答時間は状況に応じて異なる場合があります。 Kubernetesのドキュメントへの貢献に関する詳細については以下のページをご覧ください: -* [貢献のはじめ方](https://kubernetes.io/docs/contribute/start/) -* [ドキュメントの変更をステージする](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally) +* [Kubernetesのドキュメントへの貢献](https://kubernetes.io/docs/contribute/) * [ページテンプレートの使い方](http://kubernetes.io/docs/contribute/style/page-templates/) * [ドキュメントのスタイルガイド](http://kubernetes.io/docs/contribute/style/style-guide/) * [Kubernetesドキュメントの翻訳方法](https://kubernetes.io/docs/contribute/localization/) -## Dockerを使ってローカル環境でWebサイトを動かす +## 翻訳された`README.md`一覧 -ローカル環境で本ページを動かすのに推奨される方法は、静的サイトジェネレータの[Hugo](https://gohugo.io)を動かすのに特化した[Docker](https://docker.com)イメージを使うことです。 - -> Windows上で環境を作る場合は[Chocolatey](https://chocolatey.org)を使ってインストール可能な追加のツールが必要になります。 `choco install make` - -> Dockerを使わずに環境を構築したい場合は、[Hugoをローカル環境で動かす](#hugoをローカル環境で動かす)をご覧ください。 - -既に[Dockerが動いている環境](https://www.docker.com/get-started)であれば、以下のコマンドを使って`kubernetes-hugo`イメージをローカルでビルドします: - -```bash -make docker-image -``` - -イメージが作成されたら、以下のコマンドを使ってWebサイトをローカル上で動かすことができます: - -```bash -make docker-serve -``` - -お使いのブラウザにて http://localhost:1313 にアクセスすることでWebサイトが開きます。リポジトリ内のソースファイルに変更を加えると、HugoがWebサイトの内容を更新してブラウザに反映します。 - -## Hugoをローカル環境で動かす - -Hugoのインストール方法については[Hugoの公式ドキュメント](https://gohugo.io/getting-started/installing/)をご覧ください。このとき、[`netlify.toml`](netlify.toml#L9)ファイルに記述されている`HUGO_VERSION`と同じバージョンをインストールするようにしてください。 - -Hugoがインストールできたら、以下のコマンドを使ってWebサイトをローカル上で動かすことができます: - -```bash -make serve -``` - -これで、Hugoのサーバーが1313番ポートを使って開始します。 お使いのブラウザにて http://localhost:1313 にアクセスしてください。リポジトリ内のソースファイルに変更を加えると、HugoがWebサイトの内容を更新してブラウザに反映します。 - -## コミュニティ内での議論、貢献、サポートなどについて - -[コミュニティのページ](http://kubernetes.io/community/)をご覧になることで、Kubernetesコミュニティとの関わり方を学ぶことができます。 - -本プロジェクトのメンテナーには以下の方法で連絡することができます: - -- [Slack](https://kubernetes.slack.com/messages/kubernetes-docs-ja) -- [メーリングリスト](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) +| Language | Language | +|---|---| +|[中国語](README-zh.md)|[韓国語](README-ko.md)| +|[フランス語](README-fr.md)|[ポーランド語](README-pl.md)| +|[ドイツ語](README-de.md)|[ポルトガル語](README-pt.md)| +|[ヒンズー語](README-hi.md)|[ロシア語](README-ru.md)| +|[インドネシア語](README-id.md)|[スペイン語](README-es.md)| +|[イタリア語](README-it.md)|[ウクライナ語](README-uk.md)| +|[日本語](README-ja.md)|[ベトナム語](README-vi.md)| ### 行動規範 -Kubernetesコミュニティへの参加については、[Kubernetesの行動規範](code-of-conduct.md)によって管理されています。 +Kubernetesコミュニティへの参加については、[CNCFの行動規範](https://github.com/cncf/foundation/blob/master/code-of-conduct.md)によって管理されています。 ## ありがとうございます！ From 9a6e4c260db150692e8c5678ff5fb8adca7559bd Mon Sep 17 00:00:00 2001 From: Richard Mokua Date: Wed, 17 Jun 2020 07:45:19 +0200 Subject: [PATCH 036/218] Update configmap.md --- content/en/docs/concepts/configuration/configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/configuration/configmap.md b/content/en/docs/concepts/configuration/configmap.md index c6dd70ee19..f8e66ac1ed 100644 --- a/content/en/docs/concepts/configuration/configmap.md +++ b/content/en/docs/concepts/configuration/configmap.md @@ -131,7 +131,7 @@ spec: A ConfigMap doesn't differentiate between single line property values and multi-line file-like values. -What matters how Pods and other objects consume those values. +What matters is how Pods and other objects consume those values. For this example, defining a volume and mounting it inside the `demo` container as `/config` creates four files: From 69c280df026e07331a85bcaf0dabbc7404993725 Mon Sep 17 00:00:00 2001 From: Richard Mokua Date: Wed, 17 Jun 2020 07:53:27 +0200 Subject: [PATCH 037/218] Update configmap.md --- content/en/docs/concepts/configuration/configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/configuration/configmap.md b/content/en/docs/concepts/configuration/configmap.md index c6dd70ee19..324f2c3c43 100644 --- a/content/en/docs/concepts/configuration/configmap.md +++ b/content/en/docs/concepts/configuration/configmap.md @@ -168,7 +168,7 @@ ConfigMaps can hold data that other parts of the system should use for configura To consume a ConfigMap in a volume in a Pod: 1. Create a config map or use an existing one. Multiple Pods can reference the same config map. -1. Modify your Pod definition to add a volume under `.spec.volumes[]`. Name the volume anything, and have a `.spec.volumes[].configmap.localObjectReference` field set to reference your ConfigMap object. +1. Modify your Pod definition to add a volume under `.spec.volumes[]`. Name the volume anything, and have a `.spec.volumes[].configMap.name` field set to reference your ConfigMap object. 1. Add a `.spec.containers[].volumeMounts[]` to each container that needs the config map. Specify `.spec.containers[].volumeMounts[].readOnly = true` and `.spec.containers[].volumeMounts[].mountPath` to an unused directory name where you would like the config map to appear. 1. Modify your image or command line so that the program looks for files in that directory. Each key in the config map `data` map becomes the filename under `mountPath`. From 92e9bf96b526c60757355baa70b39d982db00ef7 Mon Sep 17 00:00:00 2001 From: Timo Reimann Date: Mon, 15 Jun 2020 22:37:08 +0200 Subject: [PATCH 038/218] Document annotation to set default VolumeSnapshotClass --- .../concepts/storage/volume-snapshot-classes.md | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/content/en/docs/concepts/storage/volume-snapshot-classes.md b/content/en/docs/concepts/storage/volume-snapshot-classes.md index 7f107b2059..f3b7025270 100644 --- a/content/en/docs/concepts/storage/volume-snapshot-classes.md +++ b/content/en/docs/concepts/storage/volume-snapshot-classes.md @@ -39,14 +39,27 @@ request a particular class. Administrators set the name and other parameters of a class when first creating VolumeSnapshotClass objects, and the objects cannot be updated once they are created. -Administrators can specify a default VolumeSnapshotClass just for VolumeSnapshots -that don't request any particular class to bind to. +```yaml +apiVersion: snapshot.storage.k8s.io/v1beta1 +kind: VolumeSnapshotClass +metadata: + name: csi-hostpath-snapclass +driver: hostpath.csi.k8s.io +deletionPolicy: Delete +parameters: +``` + +Administrators can specify a default VolumeSnapshotClass for VolumeSnapshots +that don't request any particular class to bind to by adding the +`snapshot.storage.kubernetes.io/is-default-class: "true"` annotation: ```yaml apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshotClass metadata: name: csi-hostpath-snapclass + annotations: + snapshot.storage.kubernetes.io/is-default-class: "true" driver: hostpath.csi.k8s.io deletionPolicy: Delete parameters: From 469df0a4c7bc6198b25cf97c41f6f8ec3158ac06 Mon Sep 17 00:00:00 2001 From: kunzhijia <757246444@qq.com> Date: Wed, 17 Jun 2020 17:22:07 +0800 Subject: [PATCH 039/218] =?UTF-8?q?=E5=BA=95=E9=83=A8=E9=93=BE=E6=8E=A5?= =?UTF-8?q?=E8=B7=B3=E8=BD=AC=E4=BF=AE=E5=A4=8D=EF=BC=8C=E4=BF=AE=E5=A4=8D?= =?UTF-8?q?=E4=B9=8B=E5=89=8D=E8=B7=B3=E8=BD=AC=E5=88=B0=E8=8B=B1=E6=96=87?= =?UTF-8?q?=E6=96=87=E6=A1=A3=EF=BC=8C=E4=BD=93=E9=AA=8C=E4=B8=8D=E6=98=AF?= =?UTF-8?q?=E5=BE=88=E5=A5=BD?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- content/zh/docs/concepts/overview/what-is-kubernetes.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/content/zh/docs/concepts/overview/what-is-kubernetes.md b/content/zh/docs/concepts/overview/what-is-kubernetes.md index a4e7f98e4a..d4c9bfc47b 100644 --- a/content/zh/docs/concepts/overview/what-is-kubernetes.md +++ b/content/zh/docs/concepts/overview/what-is-kubernetes.md @@ -213,6 +213,5 @@ Kubernetes： * Take a look at the [Kubernetes Components](/docs/concepts/overview/components/) * Ready to [Get Started](/docs/setup/)? --> -* 查阅 [Kubernetes 组件](/docs/concepts/overview/components/) -* 开始 [Kubernetes 入门](/docs/setup/)? - +* 查阅 [Kubernetes 组件](/zh/docs/concepts/overview/components/) +* 开始 [Kubernetes 入门](/zh/docs/setup/)? \ No newline at end of file From 2dfc94ef251b24ebd80550d52bcb977d6aa83f14 Mon Sep 17 00:00:00 2001 From: popozy <18868108662@163.com> Date: Wed, 17 Jun 2020 17:39:03 +0800 Subject: [PATCH 040/218] =?UTF-8?q?=E4=BF=AE=E6=94=B9=E6=96=87=E6=A1=A3?= =?UTF-8?q?=E6=8F=8F=E8=BF=B0=E9=94=99=E8=AF=AF?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 当前原文会导致如下文本 “ConfigMap 是 configMap 是一种 API 对象，用来将非机密性的数据保存到健值对中。使用时可以用作环境变量、命令行参数或者存储卷中的配置文件。” --- content/zh/docs/concepts/configuration/configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/zh/docs/concepts/configuration/configmap.md b/content/zh/docs/concepts/configuration/configmap.md index 77f8ecf846..c907b508de 100644 --- a/content/zh/docs/concepts/configuration/configmap.md +++ b/content/zh/docs/concepts/configuration/configmap.md @@ -6,7 +6,7 @@ weight: 20 -{{< glossary_definition term_id="configmap" prepend="ConfigMap 是" length="all" >}} +{{< glossary_definition term_id="configmap" prepend="" length="all" >}} {{< caution >}} -{{< glossary_definition term_id="configmap" prepend="" length="all" >}} +{{< glossary_definition term_id="configmap" length="all" >}} {{< caution >}} ## Jak zacząć? @@ -49,7 +47,7 @@ ról i uprawnień. - [Otwórz *pull request* przy pomocy GitHub-a](/docs/contribute/new-content/new-content/#changes-using-github) dotyczący zmiany istniejącej dokumentacji i dowiedz się, jak otwierać zgłoszenia przy GitHub-ie. - [Zrecenzuj *pull requests*](/docs/contribute/review/reviewing-prs/) innego członka społeczności Kubernetes pod kątem dokładności i stylu. - Zapoznaj się z poradnikami Kubernetesa dotyczącymi [zawartości](/docs/contribute/style/content-guide/) i [stylu](/docs/contribute/style/style-guide/), aby twoje uwagi były zgodne z tymi wytycznymi. -- Dowiedz się, jak [używać szablonów stron](/docs/contribute/style/page-templates/) i [skrótów Hugo](/docs/contribute/style/hugo-shortcodes/), aby wprowadzać większe zmiany. +- Przeczytaj o [różnych typach zawartości na stronie](/docs/contribute/style/page-content-types/) i [skrótach Hugo](/docs/contribute/style/hugo-shortcodes/). ## Co dalej? diff --git a/content/pl/docs/home/_index.md b/content/pl/docs/home/_index.md index cae9bb4dc5..5c8facdbc5 100644 --- a/content/pl/docs/home/_index.md +++ b/content/pl/docs/home/_index.md @@ -13,7 +13,7 @@ menu: title: "Dokumentacja" weight: 20 post: > -

Naucz się, jak korzystać z Kubernetesa z pomocą dokumentacji, która opisuje pojęcia, zawiera samouczki i informacje źródłowe. Możesz także pomóc w jej tworzeniu!

+

Naucz się, jak korzystać z Kubernetesa z pomocą dokumentacji, która opisuje pojęcia, zawiera samouczki i informacje źródłowe. Możesz także pomóc w jej tworzeniu!

description: > Kubernetes to otwarte oprogramowanie służące do automatyzacji procesów uruchamiania, skalowania i zarządzania aplikacjami w kontenerach. Gospodarzem tego projektu o otwartym kodzie źródłowym jest Cloud Native Computing Foundation. overview: > @@ -54,8 +54,8 @@ cards: description: Każdy może przyczynić się do tworzenia dokumentacji - zarówno nowicjusze, jak i starzy wyjadacze. button: Weź udział button_path: /docs/contribute -- name: download - title: Pobierz Kubernetesa +- name: release-notes + title: Informacje o wydaniu description: Jeśli instalujesz lub aktualizujesz Kubernetesa, zajrzyj do informacji o najnowszym wydaniu. - name: about title: O dokumentacji diff --git a/content/pl/docs/home/supported-doc-versions.md b/content/pl/docs/home/supported-doc-versions.md index 4744e68071..19e08be721 100644 --- a/content/pl/docs/home/supported-doc-versions.md +++ b/content/pl/docs/home/supported-doc-versions.md @@ -23,5 +23,3 @@ Bieżąca wersja to ## Poprzednie wersje {{< versions-other >}} - - diff --git a/content/pl/docs/setup/_index.md b/content/pl/docs/setup/_index.md index cd00fb0e4f..2b014be8a4 100644 --- a/content/pl/docs/setup/_index.md +++ b/content/pl/docs/setup/_index.md @@ -24,8 +24,6 @@ Klaster Kubernetes możesz zainstalować na lokalnym komputerze, w chmurze czy w W dużym uproszczeniu, możesz zbudować klaster Kubernetes zarówno w środowisku szkoleniowym, jak i na potrzeby produkcyjne. - - ## Środowisko do nauki {#srodowisko-do-nauki} @@ -45,5 +43,3 @@ Aby uruchomić klaster Kubernetes do nauki na lokalnym komputerze, skorzystaj z Wybierając rozwiązanie dla środowiska produkcyjnego musisz zdecydować, którymi poziomami zarządzania klastrem (_abstrakcjami_) chcesz zajmować się sam, a które będą realizowane po stronie zewnętrznego operatora. Na stronie [Partnerzy Kubernetes](https://kubernetes.io/partners/#conformance) znajdziesz listę dostawców posiadających [certyfikację Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes). - - diff --git a/content/pl/docs/setup/release/_index.md b/content/pl/docs/setup/release/_index.md new file mode 100755 index 0000000000..2783105198 --- /dev/null +++ b/content/pl/docs/setup/release/_index.md @@ -0,0 +1,4 @@ +--- +title: "Informacje o wydaniach i dozwolonych różnicach wersji" +weight: 10 +--- diff --git a/content/pl/docs/tasks/_index.md b/content/pl/docs/tasks/_index.md index 60f8f9808b..5a185543c3 100644 --- a/content/pl/docs/tasks/_index.md +++ b/content/pl/docs/tasks/_index.md @@ -5,80 +5,13 @@ weight: 50 content_type: concept --- -{{< toc >}} - W tej części dokumentacji Kubernetesa znajdują się opisy sposobu realizacji różnych zadań. Przedstawione są one zazwyczaj jako krótka sekwencja kilku kroków związanych z pojedynczym zadaniem. - - - - -## Graficzny interfejs użytkownika _(Dashboard)_ - -Instalacja i użycie graficznego interfejsu użytkownika z poziomu przeglądarki do zarządzania aplikacjami w kontenerach uruchomionymi na klastrze Kubernetes. - -## Jak używać polecenia kubectl - -Instalacja i konfiguracja polecenia `kubectl` do bezpośredniego zarządzania klastrami Kubernetes. - -## Konfigurowanie podów i kontenerów - -Najpopularniejsze czynności związane z konfiguracją podów i kontenerów. - -## Uruchamianie aplikacji - -Standardowe metody zarządzania aplikacjami, m. in. prowadzenie stopniowych aktualizacji _(rolling updates)_, przekazywanie konfiguracji oraz skalowanie horyzontalne podów. - -## Uruchamianie zadań - -Uruchamianie zadań w trybie równoległym. - -## Dostęp do aplikacji na klastrze - -Rozkładanie obciążenia i przekierowywanie ruchu sieciowego, konfigurowanie firewalla i usług DNS w celu zapewnienia dostępu do aplikacji w klastrze. - -## Monitoring, rejestracja i znajdowanie błędów - -Konfigurowanie monitoringu oraz rejestrowanie zdarzeń i komunikatów, pomagające rozwiązywać problemy związane z pracą klastra lub aplikacji uruchamianych w kontenerach. - -## Dostęp do API Kubernetes - -Różne metody bezpośredniego dostępu do API Kubernetes. - -## Używanie TLS - -Konfigurowanie aplikacji w taki sposób, aby korzystała i ufała łańcuchowi certyfikatów wydawanych przez Urząd Certyfikacji (CA) klastra. - -## Administracja klastrem - -Standardowe metody zarządzania klasterem. - -## Zarządzanie aplikacjami ze stanem (_Stateful_) - -Popularne zadania związane z zarządzaniem aplikacjami stanowymi _(Stateful)_, w tym: skalowanie, usuwanie i rozwiązywanie problemów dotyczących _StatefulSets_. - -## Procesy klastra typu _daemon_ - -Standardowe metody zarządzania _DaemonSet_, włączając sposoby prowadzenia stopniowej aktualizacji (_rolling update_). - -## Zarządzanie procesorami graficznymi (GPU) - -Konfiguracja i przydzielanie węzłom klastra procesorów GPU NVIDIA jako zasobów. - -## Zarządzanie HugePages - -Konfiguracja i dysponowanie _huge pages_ jako zasobu klastra. - - - ## {{% heading "whatsnext" %}} - Jeśli chciałbyś stworzyć nową stronę poświęconą jakiemuś zadaniu, przeczytaj [Jak przygotować propozycję zmian (PR)](/docs/home/contribute/create-pull-request/). - - From 28979628c5549b90ef756be769f1029d603edb86 Mon Sep 17 00:00:00 2001 From: Abhinav Date: Wed, 17 Jun 2020 14:31:00 +0900 Subject: [PATCH 057/218] Grammar correction Made a small gramatical correction to a sentence. Update create-cluster-kubeadm.md --- .../tools/kubeadm/create-cluster-kubeadm.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md index ace94edad2..2c40d7ec68 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md @@ -118,7 +118,7 @@ While `--apiserver-advertise-address` can be used to set the advertise address f control-plane node's API server, `--control-plane-endpoint` can be used to set the shared endpoint for all control-plane nodes. -`--control-plane-endpoint` allows IP addresses but also DNS names that can map to IP addresses. +`--control-plane-endpoint` allows both IP addresses and DNS names that can map to IP addresses. Please contact your network administrator to evaluate possible solutions with respect to such mapping. Here is an example mapping: From ab71197dcc5969950fb48743b8d3ae4023d573bf Mon Sep 17 00:00:00 2001 From: Kazuki Shikata Date: Thu, 18 Jun 2020 20:10:22 +0900 Subject: [PATCH 058/218] Fix a typo in service.md --- content/ja/docs/concepts/services-networking/service.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/services-networking/service.md b/content/ja/docs/concepts/services-networking/service.md index a6d1d8f17d..e23ab9312f 100644 --- a/content/ja/docs/concepts/services-networking/service.md +++ b/content/ja/docs/concepts/services-networking/service.md @@ -894,7 +894,7 @@ PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n {{< feature-state for_k8s_version="v1.12" state="alpha" >}} -KubernetseはService、Endpoints、NetworkPolicyとPodの定義においてα版の機能として`protocol`フィールドの値でSCTPをサポートしています。この機能を有効にするために、クラスター管理者はAPI Serverにおいて`SCTPSupport`というFeature Gateを有効にする必要があります。例えば、`--feature-gates=SCTPSupport=true,…`といったように設定します。 +KubernetesはService、Endpoints、NetworkPolicyとPodの定義においてα版の機能として`protocol`フィールドの値でSCTPをサポートしています。この機能を有効にするために、クラスター管理者はAPI Serverにおいて`SCTPSupport`というFeature Gateを有効にする必要があります。例えば、`--feature-gates=SCTPSupport=true,…`といったように設定します。 そのFeature Gateが有効になった時、ユーザーはService、Endpoints、NetworkPolicyの`protocol`フィールドと、Podの`SCTP`フィールドを設定できます。 Kubernetesは、TCP接続と同様に、SCTPアソシエーションに応じてネットワークをセットアップします。 From 04d6eda1187e7337c86202d5eb690105409d7f46 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jos=C3=A9=20Fernando=20Cordova?= Date: Thu, 18 Jun 2020 10:07:37 -0300 Subject: [PATCH 059/218] Update content/es/docs/concepts/architecture/cloud-controller.md Co-authored-by: Rael Garcia --- content/es/docs/concepts/architecture/cloud-controller.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/es/docs/concepts/architecture/cloud-controller.md b/content/es/docs/concepts/architecture/cloud-controller.md index 744a3ee046..b166ca0e80 100644 --- a/content/es/docs/concepts/architecture/cloud-controller.md +++ b/content/es/docs/concepts/architecture/cloud-controller.md @@ -10,7 +10,7 @@ El concepto del Cloud Controller Manager (CCM) (no confundir con el ejecutable) El diseño del Cloud Controller Manager está basado en un sistema de plugins, lo que permite a nuevos proveedores de servicios integrarse de forma fácil con Kubernetes. Se está trabajando en implementar nuevos proveedores de servicios y para migrar los existentes del antiguo modelo al nuevo CCM. -Este documento describe los conceptos tras el Cloud Controller Manager e informar detalles sobre sus funciones asociadas. +Este documento describe los conceptos tras el Cloud Controller Manager y detalla sus funciones asociadas. En la siguiente imagen, se puede visualizar la arquitectura de un cluster de Kubernetes que no utiliza el Cloud Controller Manager: @@ -235,4 +235,3 @@ Los siguientes proveedores de servicios en la nube han implementado CCMs: Instrucciones para configurar y ejecutar el CCM pueden encontrarse [aquí](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager). - From e4b5e0247f273f1ed1951f720ff7c8a3231c01da Mon Sep 17 00:00:00 2001 From: Imre Nagi Date: Thu, 18 Jun 2020 21:50:45 +0700 Subject: [PATCH 060/218] Translation for access-authn-authz Signed-off-by: Imre Nagi --- .../docs/reference/access-authn-authz/rbac.md | 1195 +++++++++++++++++ 1 file changed, 1195 insertions(+) create mode 100644 content/id/docs/reference/access-authn-authz/rbac.md diff --git a/content/id/docs/reference/access-authn-authz/rbac.md b/content/id/docs/reference/access-authn-authz/rbac.md new file mode 100644 index 0000000000..d6214dd3f2 --- /dev/null +++ b/content/id/docs/reference/access-authn-authz/rbac.md @@ -0,0 +1,1195 @@ +--- +title: Menggunakan Otorisasi RBAC +content_template: templates/concept +aliases: [../../../rbac/] +weight: 70 +--- + +{{% capture overview %}} +Kontrol akses berbasis peran (RBAC) adalah metode pengaturan akses ke sumber daya komputer +atau jaringan berdasarkan peran pengguna individu dalam organisasi kamu. +{{% /capture %}} + +{{% capture body %}} +Otorisasi RBAC menggunakan `rbac.authorization.k8s.io` kelompok API untuk mengendalikan keputusan +otorisasi, memungkinkan kamu untuk mengkonfigurasi kebijakan secara dinamis melalui API Kubernetes. + +Untuk mengaktifkan RBAC, jalankan Kubernetes dengan _flag_ `--authorization-mode` atur +dengan daftar yang dipisahkan koma dengan menyertakan `RBAC`; +sebagai contoh: +```shell +kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options +``` + +## Objek API {#api-overview} + +API RBAC mendeklarasikan empat jenis objek Kubernetes: Role, ClusterRole, +RoleBinding and ClusterRoleBinding. kamu bisa [mendeskripsikan beberapa objek](/docs/concepts/overview/working-with-objects/kubernetes-objects/#understanding-kubernetes-objects), atau mengubahnya menggunakan alat seperti `kubectl`, seperti objek Kubernetes lain. + +{{< caution >}} +Objek-objek ini, dengan disengaja, memaksakan pembatasan akses. Jika kamu melakukan perubahan +ke klaster saat kamu belajar, lihat +[pencegahan eskalasi hak istimewa dan _bootstrap_](#privilege-eskalasi-pencegahan-dan-bootstrap) +untuk memahami bagaimana pembatasan tersebut dapat mencegah kamu melakukan beberapa perubahan. +{{< /caution >}} + +### Role dan ClusterRole + +Sebuah RBAC Role atau ClusterRole berisi aturan yang mewakili sekumpulan izin. +Izin bersifat aditif (tidak ada aturan "tolak"). + +Sebuah Role selalu mengatur izin dalam _namespace_ tertentu; +ketika kamu membuat Role, kamu harus menentukan _namespace_ tempat Role tersebut berada. + +ClusterRole, sebaliknya, adalah sumber daya tanpa _namespace_. Sumber daya tersebut memiliki nama yang berbeda (Role +dan ClusterRole) karena objek Kubernetes selalu harus menggunakan _namespace_ atau tanpa _namespace_; +tidak mungkin keduanya. + +ClusterRoles memiliki beberapa kegunaan. kamu bisa menggunakan ClusterRole untuk: + +1. mendefinisikan izin pada sumber daya dalam _namespace_ dan diberikan dalam sebuah _namespace_ atau lebih +1. mendefinisikan izin pada sumber daya dalam _namespace_ dan diberikan dalam seluruh _namespace_ +1. mendefinisikan izin pada sumber daya yang dicakup klaster + +Jika kamu ingin mendefinisikan sebuah peran dalam _namespace_, gunakan Role; jika kamu ingin mendefinisikan +peran di level klaster, gunakan ClusterRole. + +#### Contoh Role + +Berikut adalah contoh Role dalam _namespace_ bawaan yang dapat digunakan +untuk memberikan akses baca pada Pod: + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: Role +metadata: + namespace: default + name: pod-reader +rules: +- apiGroups: [""] # "" mengindikasikan core API group + resources: ["pods"] + verbs: ["get", "watch", "list"] +``` + +#### Contoh ClusterRole + +ClusterRole dapat digunakan untuk memberikan izin yang sama dengan Role. +Karena ClusterRoles memiliki lingkup-klaster, kamu juga dapat menggunakannya untuk memberikan akses ke: + +* sumber daya lingkup-klaster (seperti Nodes) +* _endpoints_ non-sumber daya (seperti `/healthz`) +* sumber daya _namespace_ (seperti Pod), di semua _namespace_ + Sebagai contoh: kamu bisa menggunakan ClusterRole untuk memungkinkan pengguna tertentu untuk menjalankan +`kubectl get pods --all-namespaces`. + +Berikut adalah contoh ClusterRole yang dapat digunakan untuk memberikan akses baca pada +Secret di _namespace_ tertentu, atau di semua _namespace_ (tergantung bagaimana itu [terikat](#rolebinding-and-clusterrolebinding)): + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + # "namespace" dihilangkan karena ClusterRoles tidak menggunakan namespace + name: secret-reader +rules: +- apiGroups: [""] + # +  # di tingkat HTTP, nama sumber daya untuk mengakses objek Secret +  # adalah "secrets" + resources: ["secrets"] + verbs: ["get", "watch", "list"] +``` + +Nama objek Role dan ClusterRole harus menggunakan [nama _path segment_](/docs/concepts/overview/working-with-objects/names#path-segment-names) yang valid. + +### RoleBinding dan ClusterRoleBinding + +Sebuah RoleBinding memberikan izin yang ditentukan dalam sebuah Role kepada pengguna atau sekelompok pengguna. +Ini menyimpan daftar subjek (pengguna, grup, atau _service accounts_), dan referensi ke +peran yang diberikan. +RoleBinding memberikan izin dalam _namespace_ tertentu sedangkan ClusterRoleBinding +memberikan akses tersebut pada lingkup klaster. + +RoleBinding dapat merujuk Role apa pun di _namespace_ yang sama. Atau, RoleBinding +dapat mereferensikan ClusterRole dan memasangkan ClusterRole tersebut ke _namespace_ dari RoleBinding. +Jika kamu ingin memasangkan ClusterRole ke semua _namespace_ di klaster kamu, kamu dapat menggunakan +ClusterRoleBinding. + +Nama objek RoleBinding atau ClusterRoleBinding harus valid menggunakan +[nama _path segment_](/docs/concepts/overview/working-with-objects/names#path-segment-names) yang valid. + +#### Contoh RoleBinding {#rolebinding-example} + +Berikut adalah contoh dari RoleBinding yang memberikan Role "pod-reader" kepada pengguna "jane" +pada _namespace_ bawaan. +Ini memungkinkan "jane" untuk membaca Pod di _namespace_ bawaan. + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +# Role binding memungkinkan "jane" untuk membaca Pod di namespace bawaan +# Kamu harus sudah memiliki Role bernama "pod-reader" di namespace tersebut. +kind: RoleBinding +metadata: + name: read-pods + namespace: default +subjects: +# Kamu bisa mencantumkan lebih dari satu "subjek" +- kind: User + name: jane # "name" peka huruf besar-kecil + apiGroup: rbac.authorization.k8s.io +roleRef: + # "roleRef" menentukan pengikatan ke Role / ClusterRole + kind: Role # ini harus Role atau ClusterRole + name: pod-reader # ini harus sesuai dengan nama Role atau ClusterRole yang ingin kamu gunakan + apiGroup: rbac.authorization.k8s.io +``` + +RoleBinding juga bisa mereferensikan ClusterRole untuk memberikan izin yang didenisifikan di dalam +ClusterRole ke sumber daya di dalam _namespace_ RoleBinding. Referensi semacam ini +memungkinkan kamu menentukan sekumpulan peran yang umum di seluruh klaster kamu, lalu menggunakannya kembali di dalam +beberapa _namespace_. + +Sebagai contoh, meskipun RoleBinding berikut merujuk ke ClusterRole, +"dave" (subjek, peka huruf besar-kecil) hanya akan dapat membaca Secrets di dalam _namespace_ "development", +karena _namespace_ RoleBinding (di dalam metadata-nya) adalah "development". + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +# role binding memungkinkan "dave" untuk membaca Secrets di namespace "development". +# Kamu sudah harus memiliki ClusterRole bernama "secret-reader". +kind: RoleBinding +metadata: + name: read-secrets + # + # Namespace dari RoleBinding menentukan dimana izin akan diberikan. + # Ini hanya memberikan izin di dalam namespace "development". + namespace: development +subjects: +- kind: User + name: dave # Nama peka huruf besar-kecil + apiGroup: rbac.authorization.k8s.io +roleRef: + kind: ClusterRole + name: secret-reader + apiGroup: rbac.authorization.k8s.io +``` + +#### Contoh ClusterRoleBinding + +Untuk memberikan izin diseluruh klaster, kamu dapat menggunakan ClusterRoleBinding. +ClusterRoleBinding berikut memungkinkan seluruh pengguna di dalam kelompok "manager" untuk +membaca rahasia di berbagai _namespace_. + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +# Cluster role binding ini memungkinkan siapapun di dalam kelompok "manager" untuk membaca rahasia di berbagai namespace. +kind: ClusterRoleBinding +metadata: + name: read-secrets-global +subjects: +- kind: Group + name: manager # Nama peka huruf besar-kecil + apiGroup: rbac.authorization.k8s.io +roleRef: + kind: ClusterRole + name: secret-reader + apiGroup: rbac.authorization.k8s.io +``` +Setelah kamu membuat sebuat ikatan, kamu tidak dapat mengganti Role atau ClusterRole dirujuk. +Jika kamu mencoba mengganti sebuah ikatan `roleRef`, kamu mendapatkan kesalahan validasi. Jika kamu +tidak ingin mengganti `roleRef` untuk sebuah ikatan, kamu harus menghapus objek ikatan tersebut dan membuat +sebuah pengganti. + +Ada dua alasan untuk pembatasan tersebut: + +1. Membuat `roleRef` tidak dapat diubah memungkinkan seseorang untuk melakukan `update` pada objek ikatan yang ada, +sehingga mereka dapat mengelola daftar subyek, tanpa bisa berubah +peran yang diberikan kepada subyek tersebut. + +1. Ikatan pada peran yang berbeda adalah ikatan yang berbeda secara fundamental. +Mengharuskan sebuah ikatan untuk dihapus/diciptakan kembali untuk dalam upaya mengubah `roleRef` akan +memastikan daftar lengkap subyek dalam ikatan akan diberikan diberikan +peran baru (sebagai langkah untuk mencegah modifikasi secara tidak sengaja hanya pada roleRef +tanpa memverifikasi semua subyek yang seharusnya diberikan izin pada peran baru). + +Utilitas baris perintah `kubectl auth reconcile` membuat atau memperbaharui berkas manifes yang mengandung objek RBAC, +dan menangani penghapusan dan pembuatan objek ikatan jika dibutuhkan untuk mengganti peran yang dirunjuk. +Lihat [penggunaan perintah dan contoh](#kubectl-auth-reconcile) untuk informasi tambahan. + +### Mengacu pada sumber daya + +Pada API Kubernetes, sebagian besar sumber daya diwakili dan diakses menggunakan representasi +nama objek, seperti `pods` untuk Pod. RBAC mengacu pada sumber daya yang menggunakan nama yang persis sama +dengan yang muncul di URL untuk _endpoints_ API yang relevan. +Beberapa Kubernetes APIs melibatkan +_subresource_, seperti catatan untuk Pod. Permintaan untuk catatan Pod terlihat seperti: + +```http +GET /api/v1/namespaces/{namespace}/pods/{name}/log +``` + +Dalam hal ini, `pods` adalah sumber daya _namespaced_ untuk sumber daya Pod, dan` log` adalah a +sub-sumber daya `pods`. Untuk mewakili ini dalam sebuah peran RBAC, gunakan garis miring (`/`) untuk +membatasi sumber daya dan sub-sumber daya. Untuk memungkinkan subjek membaca `pods` dan +juga mengakses sub-sumber daya `log` untuk masing-masing Pod tersebut, kamu dapat menulis: + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: Role +metadata: + namespace: default + name: pod-and-pod-logs-reader +rules: +- apiGroups: [""] + resources: ["pods", "pods/log"] + verbs: ["get", "list"] +``` + +Kamu juga dapat merujuk ke sumber daya dengan nama untuk permintaan tertentu melalui daftar `resourceNames`. +Ketika nama dicantumkan, permintaan dapat dibatasi untuk setiap objek sumber daya. +Berikut adalah contoh yang membatasi subjeknya hanya untuk melakukan `get` atau` update` pada sebuah +ConfigMap bernama `my-configmap`: + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: Role +metadata: + namespace: default + name: configmap-updater +rules: +- apiGroups: [""] + # + # pada level HTTP, nama sumber daya untuk mengakses objek ConfigMap + # adalah "configmaps" + resources: ["configmaps"] + resourceNames: ["my-configmap"] + verbs: ["update", "get"] +``` + +{{< note >}} +Kamu tidak dapat membatasi permintaan `create` atau` deletecollection` dengan nama sumber daya. Untuk `create`, +Keterbatasan ini dikarenakan nama objek yang tidak dikenal pada waktu otorisasi. +{{< /note >}} + +### Agregat ClusterRoles + +Kamu dapat mengumpulkan beberapa ClusterRoles menjadi satu ClusterRole gabungan. +Controller, yang berjalan sebagai bagian dari _control plane_ klaster, mengamati objek ClusterRole +dengan `aggregationRule`. `AggregationRule` mendefinisikan label +Selector yang digunakan oleh Controller untuk mencocokkan objek ClusterRole lain +yang harus digabungkan ke dalam `rules`. + +Berikut adalah contoh ClusterRole agregat: + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: monitoring +aggregationRule: + clusterRoleSelectors: + - matchLabels: + rbac.example.com/aggregate-to-monitoring: "true" +rules: [] # _Control plane_ secara otomatis mengisi rules +``` + +Jika kamu membuat ClusterRole baru yang cocok dengan _selector_ label dari ClusterRole agregat yang ada, +perubahan itu memicu penambahan aturan baru ke dalam ClusterRole agregat. +Berikut adalah contoh yang menambahkan aturan ke "monitoring" ClusterRole, dengan membuat sebuah +ClusterRole lain berlabel `rbac.example.com/aggregate-to-monitoring: true`. + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: monitoring-endpoints + labels: + rbac.example.com/aggregate-to-monitoring: "true" +# ketika kamu membuat ClusterRole "monitoring-endpoints", +# aturan di bawah ini akan ditambahkan ke ClusterRole "monitoring". +rules: +- apiGroups: [""] + resources: ["services", "endpoints", "pods"] + verbs: ["get", "list", "watch"] +``` + +[Peran bawaan pengguna](#default-roles-and-role-bindings) menggunakan agregasi ClusterRole. Ini memungkinkan kamu, +sebagai administrator klaster, menambahkan aturan untuk sumber daya kustom, seperti yang dilayani oleh CustomResourceDefinition +atau _aggregated_ server API, untuk memperluas peran bawaan. + +Sebagai contoh: ClusterRoles berikut mengizinkan peran bawaan "admin" dan "edit" mengelola sumber daya kustom +bernama CronTab, sedangkan peran "view" hanya dapat melakukan tindakan membaca sumber daya CronTab. +Kamu dapat mengasumsikan bahwa objek CronTab dinamai `"crontab"` dalam URL yang terlihat oleh server API. + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: aggregate-cron-tabs-edit + labels: + # Tambahkan izin berikut ke peran bawaan "admin" and "edit". + rbac.authorization.k8s.io/aggregate-to-admin: "true" + rbac.authorization.k8s.io/aggregate-to-edit: "true" +rules: +- apiGroups: ["stable.example.com"] + resources: ["crontabs"] + verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] +--- +kind: ClusterRole +apiVersion: rbac.authorization.k8s.io/v1 +metadata: + name: aggregate-cron-tabs-view + labels: + # Tambahkan izin berikut ke peran bawaan "view" + rbac.authorization.k8s.io/aggregate-to-view: "true" +rules: +- apiGroups: ["stable.example.com"] + resources: ["crontabs"] + verbs: ["get", "list", "watch"] +``` + +#### Contoh Role + +Contoh berikut adalah potongan dari objek Peran atau ClusterRole, yang hanya menampilkan +bagian `rules`. + +Mengizinkan pembacaan sumber daya `"pods`` pada kumpulan API inti: + +```yaml +rules: +- apiGroups: [""] + # + # pada tingkat HTTP, nama dari sumber daya untuk mengakses objek Pod + # adalah "pods" + resources: ["pods"] + verbs: ["get", "list", "watch"] +``` + +Mengizinkan pembacaan/penulisan Deployments (pada tingkat HTTP: objek dengan `"deployments"` +di bagian sumber daya dari URL) pada masing-masing kumpulan API `"extensions"` dan `"apps"`: + +```yaml +rules: +- apiGroups: ["extensions", "apps"] + # + # pada tingkat HTTP, nama dari sumber daya untuk mengakses objek Deployment + # adalah "deployments" + resources: ["deployments"] + verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] +``` + +Mengizinkan pembacaan pada Pods pada kumpulan API inti, dan juga serta pembacaan atau penulisan Job +di kumpulan API `"batch"` atau `"extensions"`: + +```yaml +rules: +- apiGroups: [""] + # + # pada tingkat HTTP, nama dari sumber daya untuk mengakses objek Pod + # adalah "pods" + resources: ["pods"] + verbs: ["get", "list", "watch"] +- apiGroups: ["batch", "extensions"] + # + # pada tingkat HTTP, nama dari sumber daya untuk mengakses objek Job + # adalah "jobs" + resources: ["jobs"] + verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] +``` + +Mengizinkan pembacaan ConfigMap bernama "my-config" (harus terikat dengan +RoleBinding untuk membatasi pada sebuah ConfigMap di sebuah _namespace_): + +```yaml +rules: +- apiGroups: [""] + # + # pada tingkat HTTP, nama dari sumber daya untuk mengakses objek ConfigMap + # adalah "configmaps" + resources: ["configmaps"] + resourceNames: ["my-config"] + verbs: ["get"] +``` + +Mengizinkan pembacaan sumber daya `"nodes"` pada kumpulan API inti (karena sebuah node +ada pada lingkup-klaster, ini harus berupa ClusterRole yang terikat dengan ClusterRoleBinding +agar efektif): + +```yaml +rules: +- apiGroups: [""] + # + # pada tingkat HTTP, nama dari sumber daya untuk mengakses objek Node + # adalah "nodes" + resources: ["nodes"] + verbs: ["get", "list", "watch"] +``` + +Mengizinkan permintaan GET dan POST kepada _endpoint_ non-sumber daya `/healthz` dan seluruh _subpath_ +(harus berada di dalam ClusterRole yang terikat dengan ClusterRoleBinding agar efektif): + +```yaml +rules: +- nonResourceURLs: ["/healthz", "/healthz/*"] # '*' in a nonResourceURL is a suffix glob match + verbs: ["get", "post"] +``` + +### Mengacu Pada Subjek + +RoleBinding atau ClusterRoleBinding mengikat sebuah peran ke subjek. +Subjek dapat berupa kelompok, pengguna atau ServiceAccounts. + +Kubernetes merepresentasikan _usernames_ sebagai string. +Ini bisa berupa: nama sederhana, seperti "alice"; email, seperti "bob@example.com"; +atau ID pengguna numerik yang direpresentasikan sebagai string. Terserah kamu sebagai administrator klaster +untuk mengkonfigurasi [authentication modules](/docs/reference/access-authn-authz/authentication/) +sehingga otentikasi menghasilkan _usernames_ dalam format yang kamu inginkan. + +{{< caution >}} +Awalan `system:` direservasi untuk sistem Kubernetes, jadi kamu harus memastikan +bahwa kamu tidak memiliki pengguna atau grup dengan nama yang dimulai dengan `system:` secara tidak sengaja. +Selain awalan khusus ini, sistem otorisasi RBAC tidak memerlukan format apa pun +untuk nama pengguna. +{{< /caution >}} + +Di Kubernetes, modul otentikasi menyediakan informasi grup. +Grup, seperti halnya pengguna, direpresentasikan sebagai string, dan string tersebut tidak memiliki format tertentu, +selain awalan `system:` yang sudah direservasi. + +[ServiceAccounts](/docs/tasks/configure-pod-container/configure-service-account/) memiliki nama yang diawali dengan `system:serviceaccount:`, dan menjadi milik grup yang diawali dengan nama `system:serviceaccounts:`. + +{{< note >}} +- `system:serviceaccount:` (tunggal) adalah awalan untuk _service account usernames_. +- `system:serviceaccounts:` (jamak) adalah awalan untuk _service account_ grup. +{{< /note >}} + +#### Contoh RoleBinding {#role-binding-examples} + +Contoh-contoh berikut ini hanya potongan `RoleBinding` yang hanya memperlihatkan +bagian `subjects`. + +Untuk pengguna bernama `alice@example.com`: + +```yaml +subjects: +- kind: User + name: "alice@example.com" + apiGroup: rbac.authorization.k8s.io +``` + +Untuk grup bernama `frontend-admins`: + +```yaml +subjects: +- kind: Group + name: "frontend-admins" + apiGroup: rbac.authorization.k8s.io +``` + +Untuk _service account_ bawaan di _namespace_ "kube-system": + +```yaml +subjects: +- kind: ServiceAccount + name: default + namespace: kube-system +``` + +Untuk seluruh _service account_ di _namespace_ qa: + +```yaml +subjects: +- kind: Group + name: system:serviceaccounts:qa + apiGroup: rbac.authorization.k8s.io +``` + +Untuk seluruh _service account_ di _namespace_ apapun: + +```yaml +subjects: +- kind: Group + name: system:serviceaccounts + apiGroup: rbac.authorization.k8s.io +``` + +Untuk seluruh pengguna yang terotentikasi: + +```yaml +subjects: +- kind: Group + name: system:authenticated + apiGroup: rbac.authorization.k8s.io +``` + +Untuk seluruh pengguna yang tidak terotentikasi: + +```yaml +subjects: +- kind: Group + name: system:unauthenticated + apiGroup: rbac.authorization.k8s.io +``` + +Untuk seluruh pengguna: + +```yaml +subjects: +- kind: Group + name: system:authenticated + apiGroup: rbac.authorization.k8s.io +- kind: Group + name: system:unauthenticated + apiGroup: rbac.authorization.k8s.io +``` + +## Role dan RoleBindings Bawaan + +API membuat satu set objek ClusterRole dan ClusterRoleBinding bawaan. +Sebagian besar dari objek berawalan `system:`, menunjukkan bahwa sumber daya tersebut +secara langsung dikelolah oleh _control plane_ klaster. Seluruh ClusterRole dan ClusterRoleBinding dilabeli dengan +`kubernetes.io/bootstrapping=rbac-defaults`. + +{{< caution >}} +Berhati-hatilah saat memodifikasih CLusterRole dan ClusterRoleBinding dengan nama yang +memiliki awalan `system:`. +Modifikasi sumber daya ini dapat mengakibatkan klaster yang malfungsi. +{{< /caution >}} + +### Rekonsiliasi Otomatis + +Pada setiap _start-up-_, server API memperbaharui ClusterRole bawaan dengan berbagai izin yang hilang, +dan memperbaharui ikatan ClusterRole bawaan dengan subjek yang hilang. +Ini memungkinkan klaster untuk memperbaiki modifikasi yang tidak disengaja, dan membantu menjaga peran +dan ikatan peran selalu terkini karena izin dan subjek berubah pada rilis terbaru Kubernetes. + +Untuk menon-aktifkan rekonsiliasi ini, setel anotasi `rbac.authorization.kubernetes.io/autoupdate` +pada ClusterRole bawaan atau ikatan peran bawaan menjadi `false`. +Ingat bahwa hilangnya izin dan subjek bawaan dapat mengakibatkan klaster tidak berfungsi. + +Rekonsiliasi otomatis diaktifkan secara bawaan jika otorizer RBAC aktif. + +### API discovery roles {#discovery-roles} + +Ikatan peran bawaan memberi otorisasi kepada pengguna yang tidak terotentikasi untuk membaca informasi API yang dianggap aman +untuk diakses publik (termasuk CustomResourceDefinitions). Untuk menonaktifkan akses anonim, tambahkan `--anonymous-auth=false` ke konfigurasi server API. + +Untuk melihat konfigurasi peran ini melalui `kubectl` jalankan perintah: + +```shell +kubectl get clusterroles system:discovery -o yaml +``` + +{{< note >}} +Jika kamu mengubah ClusterRole tersebut, perubahan kamu akan ditimpa pada penyalaan ulang server API melalui +[rekonsiliasi-otomatis](#auto-reconciliation). Untuk menghindari penulisan ulang tersebut, hindari mengubah peran secara manual, +atau nonaktifkan rekonsiliasi otomatis +{{< /note >}} + + + + + + + + + + + + + + + + + + + + + + + + +
Kubernetes RBAC API discovery roles
ClusterRole BawaanClusterRoleBinding BawaanDeskripsi
system:basic-usersystem:authenticated groupMengizinkan pengguna hanya dengan akses baca untuk mengakses informasi dasar tentang diri mereka sendiri. Sebelum v1.14, peran ini juga terikat pada system:unauthenticated secara bawaan.
system:discoverysystem:authenticated groupMengizinkan akses baca pada _API discovery endpoints_ yang dibutuhkan untuk menemukan dan melakukan negosiasi pada tingkat API. Sebelum v1.14, peran ini juga terikat pada system:unauthenticated secara bawaan.
system:public-info-viewersystem:authenticated and system:unauthenticated groupsMengizinkan akses baca pada informasi yang tidak sensitif tentang klaster. Diperkenalkan pada Kubernetes v1.14.
+ +### Peran Pengguna + +Beberapa ClusterRole bawaan tidak diawali dengan `system:`. Ini dimaksudkan untuk peran pengguna. +Ini termasuk peran super-user (`cluster-admin`), peran yang dimaksudkan untuk diberikan akses seluruh klaster dengan +menggunakan ClusterRoleBinding, dan peran yang dimaksudkan untuk diberikan pada namespace tertentu +dengan menggunakan RoleBinding (`admin`, `edit`, `view`). + +ClusterRoles menggunakan [aggregasi ClusterRole](#aggregated-clusterroles) untuk mengizinkan admin untuk memasukan peraturan untuk sumber daya khusus pada ClusterRole ini. Untuk menambahkan aturan kepada peran `admin`, `edit`, atau `view`, buat sebuah CLusterRole +dengan satu atau lebih label berikut: + +```yaml +metadata: + labels: + rbac.authorization.k8s.io/aggregate-to-admin: "true" + rbac.authorization.k8s.io/aggregate-to-edit: "true" + rbac.authorization.k8s.io/aggregate-to-view: "true" +``` + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ClusterRole BawaanClusterRoleBinding BawaanDeskripsi
cluster-adminsystem:masters groupMengizinkan akses super-user access untuk melakukan berbagai aksi pada berbagai sumber daya. +Ketika digunakan pada ClusterRoleBinding, ini memberikan kendali penuh terhadap seluruh sumber daya pada klaster dan seluruh namespace. +Ketika digunakan pada RoleBinding, ini memberikan kendali penuh terhadap setiap sumber daya pada namespace ikatan peran, termasuk namespace itu sendiri.
adminNonemengizinkan akses admin, yang dimaksudkan untuk diberikan dalam sebuah namespace menggunakan RoleBinding. +Jika digunakan dalam RoleBinding, ini memungkikan akses baca/tulis ke sebagian besar sumber daya di sebuah namespace, +termasuk kemampuan untuk membuat peran dan ikatan peran dalam namespace. +Peran ini tidak memungkinkan akses tulis pada kuota sumber daya atau ke namespace itu sendiri.
editNoneMengizinkan akses baca/tulis pada seluruh objek dalam namespace. + +Peran ini tidak memungkinkan untuk melihat dan merubah peran dan ikatan peran. +Namun, peran ini memungkinkan untuk mengakses secret dan menjalankan pod seperti ServiceAccount dalam namespace, +sehingga dapat digunakan untuk mendapatkan tingkat akses API dari setiap ServiceAccount di namespace. +
viewNoneMengizinkan akses baca untuk melihat hampir seluruh objek dalam namespace. + +Ini tidak memungkinkan untuk melihat peran dan ikatan peran. + +Peran ini tidak memungkikan melihat Secret, karena pembacaan konten Secret memungkinkan +akses ke kredensial ServiceAccount dalam namespace, yang akan memungkinkan akses API sebagai +ServiceAccount apapun di namespace (bentuk eskalasi hak istimewa). +
+ +### Core component roles + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Default ClusterRoleDefault ClusterRoleBindingDescription
system:kube-schedulersystem:kube-scheduler userAllows access to the resources required by the {{< glossary_tooltip term_id="kube-scheduler" text="scheduler" >}} component.
system:volume-schedulersystem:kube-scheduler userAllows access to the volume resources required by the kube-scheduler component.
system:kube-controller-managersystem:kube-controller-manager userAllows access to the resources required by the {{< glossary_tooltip term_id="kube-controller-manager" text="controller manager" >}} component. +The permissions required by individual controllers are detailed in the controller roles.
system:nodeNoneAllows access to resources required by the kubelet, including read access to all secrets, and write access to all pod status objects. + +You should use the Node authorizer and NodeRestriction admission plugin instead of the system:node role, and allow granting API access to kubelets based on the Pods scheduled to run on them. + +The system:node role only exists for compatibility with Kubernetes clusters upgraded from versions prior to v1.8. +
system:node-proxiersystem:kube-proxy userAllows access to the resources required by the {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}} component.
+ +### Other component roles + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Default ClusterRoleDefault ClusterRoleBindingDescription
system:auth-delegatorNoneAllows delegated authentication and authorization checks. +This is commonly used by add-on API servers for unified authentication and authorization.
system:heapsterNoneRole for the Heapster component (deprecated).
system:kube-aggregatorNoneRole for the kube-aggregator component.
system:kube-dnskube-dns service account in the kube-system namespaceRole for the kube-dns component.
system:kubelet-api-adminNoneAllows full access to the kubelet API.
system:node-bootstrapperNoneAllows access to the resources required to perform +kubelet TLS bootstrapping.
system:node-problem-detectorNoneRole for the node-problem-detector component.
system:persistent-volume-provisionerNoneAllows access to the resources required by most dynamic volume provisioners.
+ +### Roles for built-in controllers {#controller-roles} + +The Kubernetes {{< glossary_tooltip term_id="kube-controller-manager" text="controller manager" >}} runs +{{< glossary_tooltip term_id="controller" text="controllers" >}} that are built in to the Kubernetes +control plane. +When invoked with `--use-service-account-credentials`, kube-controller-manager starts each controller +using a separate service account. +Corresponding roles exist for each built-in controller, prefixed with `system:controller:`. +If the controller manager is not started with `--use-service-account-credentials`, it runs all control loops +using its own credential, which must be granted all the relevant roles. +These roles include: + +* `system:controller:attachdetach-controller` +* `system:controller:certificate-controller` +* `system:controller:clusterrole-aggregation-controller` +* `system:controller:cronjob-controller` +* `system:controller:daemon-set-controller` +* `system:controller:deployment-controller` +* `system:controller:disruption-controller` +* `system:controller:endpoint-controller` +* `system:controller:expand-controller` +* `system:controller:generic-garbage-collector` +* `system:controller:horizontal-pod-autoscaler` +* `system:controller:job-controller` +* `system:controller:namespace-controller` +* `system:controller:node-controller` +* `system:controller:persistent-volume-binder` +* `system:controller:pod-garbage-collector` +* `system:controller:pv-protection-controller` +* `system:controller:pvc-protection-controller` +* `system:controller:replicaset-controller` +* `system:controller:replication-controller` +* `system:controller:resourcequota-controller` +* `system:controller:root-ca-cert-publisher` +* `system:controller:route-controller` +* `system:controller:service-account-controller` +* `system:controller:service-controller` +* `system:controller:statefulset-controller` +* `system:controller:ttl-controller` + +## Privilege escalation prevention and bootstrapping + +The RBAC API prevents users from escalating privileges by editing roles or role bindings. +Because this is enforced at the API level, it applies even when the RBAC authorizer is not in use. + +### Restrictions on role creation or update + +You can only create/update a role if at least one of the following things is true: + +1. You already have all the permissions contained in the role, at the same scope as the object being modified +(cluster-wide for a ClusterRole, within the same namespace or cluster-wide for a Role). +2. You are granted explicit permission to perform the `escalate` verb on the `roles` or `clusterroles` resource in the `rbac.authorization.k8s.io` API group. + +For example, if `user-1` does not have the ability to list Secrets cluster-wide, they cannot create a ClusterRole +containing that permission. To allow a user to create/update roles: + +1. Grant them a role that allows them to create/update Role or ClusterRole objects, as desired. +2. Grant them permission to include specific permissions in the roles they create/update: + * implicitly, by giving them those permissions (if they attempt to create or modify a Role or ClusterRole with permissions they themselves have not been granted, the API request will be forbidden) + * or explicitly allow specifying any permission in a `Role` or `ClusterRole` by giving them permission to perform the `escalate` verb on `roles` or `clusterroles` resources in the `rbac.authorization.k8s.io` API group + +### Restrictions on role binding creation or update + +You can only create/update a role binding if you already have all the permissions contained in the referenced role +(at the same scope as the role binding) *or* if you have been authorized to perform the `bind` verb on the referenced role. +For example, if `user-1` does not have the ability to list Secrets cluster-wide, they cannot create a ClusterRoleBinding +to a role that grants that permission. To allow a user to create/update role bindings: + +1. Grant them a role that allows them to create/update RoleBinding or ClusterRoleBinding objects, as desired. +2. Grant them permissions needed to bind a particular role: + * implicitly, by giving them the permissions contained in the role. + * explicitly, by giving them permission to perform the `bind` verb on the particular Role (or ClusterRole). + +For example, this ClusterRole and RoleBinding would allow `user-1` to grant other users the `admin`, `edit`, and `view` roles in the namespace `user-1-namespace`: + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: role-grantor +rules: +- apiGroups: ["rbac.authorization.k8s.io"] + resources: ["rolebindings"] + verbs: ["create"] +- apiGroups: ["rbac.authorization.k8s.io"] + resources: ["clusterroles"] + verbs: ["bind"] + resourceNames: ["admin","edit","view"] +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: RoleBinding +metadata: + name: role-grantor-binding + namespace: user-1-namespace +roleRef: + apiGroup: rbac.authorization.k8s.io + kind: ClusterRole + name: role-grantor +subjects: +- apiGroup: rbac.authorization.k8s.io + kind: User + name: user-1 +``` + +When bootstrapping the first roles and role bindings, it is necessary for the initial user to grant permissions they do not yet have. +To bootstrap initial roles and role bindings: + +* Use a credential with the "system:masters" group, which is bound to the "cluster-admin" super-user role by the default bindings. +* If your API server runs with the insecure port enabled (`--insecure-port`), you can also make API calls via that port, which does not enforce authentication or authorization. + +## Command-line utilities + +### `kubectl create role` + +Creates a Role object defining permissions within a single namespace. Examples: + +* Create a Role named "pod-reader" that allows users to perform `get`, `watch` and `list` on pods: + + ```shell + kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods + ``` + +* Create a Role named "pod-reader" with resourceNames specified: + + ```shell + kubectl create role pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod + ``` + +* Create a Role named "foo" with apiGroups specified: + + ```shell + kubectl create role foo --verb=get,list,watch --resource=replicasets.apps + ``` + +* Create a Role named "foo" with subresource permissions: + + ```shell + kubectl create role foo --verb=get,list,watch --resource=pods,pods/status + ``` + +* Create a Role named "my-component-lease-holder" with permissions to get/update a resource with a specific name: + + ```shell + kubectl create role my-component-lease-holder --verb=get,list,watch,update --resource=lease --resource-name=my-component + ``` + +### `kubectl create clusterrole` + +Creates a ClusterRole. Examples: + +* Create a ClusterRole named "pod-reader" that allows user to perform `get`, `watch` and `list` on pods: + + ```shell + kubectl create clusterrole pod-reader --verb=get,list,watch --resource=pods + ``` + +* Create a ClusterRole named "pod-reader" with resourceNames specified: + + ```shell + kubectl create clusterrole pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod + ``` + +* Create a ClusterRole named "foo" with apiGroups specified: + + ```shell + kubectl create clusterrole foo --verb=get,list,watch --resource=replicasets.apps + ``` + +* Create a ClusterRole named "foo" with subresource permissions: + + ```shell + kubectl create clusterrole foo --verb=get,list,watch --resource=pods,pods/status + ``` + +* Create a ClusterRole named "foo" with nonResourceURL specified: + + ```shell + kubectl create clusterrole "foo" --verb=get --non-resource-url=/logs/* + ``` + +* Create a ClusterRole named "monitoring" with an aggregationRule specified: + + ```shell + kubectl create clusterrole monitoring --aggregation-rule="rbac.example.com/aggregate-to-monitoring=true" + ``` + +### `kubectl create rolebinding` + +Grants a Role or ClusterRole within a specific namespace. Examples: + +* Within the namespace "acme", grant the permissions in the "admin" ClusterRole to a user named "bob": + + ```shell + kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme + ``` + +* Within the namespace "acme", grant the permissions in the "view" ClusterRole to the service account in the namespace "acme" named "myapp": + + ```shell + kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme + ``` + +* Within the namespace "acme", grant the permissions in the "view" ClusterRole to a service account in the namespace "myappnamespace" named "myapp": + + ```shell + kubectl create rolebinding myappnamespace-myapp-view-binding --clusterrole=view --serviceaccount=myappnamespace:myapp --namespace=acme + ``` + +### `kubectl create clusterrolebinding` + +Grants a ClusterRole across the entire cluster (all namespaces). Examples: + +* Across the entire cluster, grant the permissions in the "cluster-admin" ClusterRole to a user named "root": + + ```shell + kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root + ``` + +* Across the entire cluster, grant the permissions in the "system:node-proxier" ClusterRole to a user named "system:kube-proxy": + + ```shell + kubectl create clusterrolebinding kube-proxy-binding --clusterrole=system:node-proxier --user=system:kube-proxy + ``` + +* Across the entire cluster, grant the permissions in the "view" ClusterRole to a service account named "myapp" in the namespace "acme": + + ```shell + kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp + ``` + +### `kubectl auth reconcile` {#kubectl-auth-reconcile} + +Creates or updates `rbac.authorization.k8s.io/v1` API objects from a manifest file. + +Missing objects are created, and the containing namespace is created for namespaced objects, if required. + +Existing roles are updated to include the permissions in the input objects, +and remove extra permissions if `--remove-extra-permissions` is specified. + +Existing bindings are updated to include the subjects in the input objects, +and remove extra subjects if `--remove-extra-subjects` is specified. + +Examples: + +* Test applying a manifest file of RBAC objects, displaying changes that would be made: + + ``` + kubectl auth reconcile -f my-rbac-rules.yaml --dry-run=client + ``` + +* Apply a manifest file of RBAC objects, preserving any extra permissions (in roles) and any extra subjects (in bindings): + + ```shell + kubectl auth reconcile -f my-rbac-rules.yaml + ``` + +* Apply a manifest file of RBAC objects, removing any extra permissions (in roles) and any extra subjects (in bindings): + + ```shell + kubectl auth reconcile -f my-rbac-rules.yaml --remove-extra-subjects --remove-extra-permissions + ``` + +## ServiceAccount permissions {#service-account-permissions} + +Default RBAC policies grant scoped permissions to control-plane components, nodes, +and controllers, but grant *no permissions* to service accounts outside the `kube-system` namespace +(beyond discovery permissions given to all authenticated users). + +This allows you to grant particular roles to particular ServiceAccounts as needed. +Fine-grained role bindings provide greater security, but require more effort to administrate. +Broader grants can give unnecessary (and potentially escalating) API access to +ServiceAccounts, but are easier to administrate. + +In order from most secure to least secure, the approaches are: + +1. Grant a role to an application-specific service account (best practice) + + This requires the application to specify a `serviceAccountName` in its pod spec, + and for the service account to be created (via the API, application manifest, `kubectl create serviceaccount`, etc.). + + For example, grant read-only permission within "my-namespace" to the "my-sa" service account: + + ```shell + kubectl create rolebinding my-sa-view \ + --clusterrole=view \ + --serviceaccount=my-namespace:my-sa \ + --namespace=my-namespace + ``` + +2. Grant a role to the "default" service account in a namespace + + If an application does not specify a `serviceAccountName`, it uses the "default" service account. + + {{< note >}} + Permissions given to the "default" service account are available to any pod + in the namespace that does not specify a `serviceAccountName`. + {{< /note >}} + + For example, grant read-only permission within "my-namespace" to the "default" service account: + + ```shell + kubectl create rolebinding default-view \ + --clusterrole=view \ + --serviceaccount=my-namespace:default \ + --namespace=my-namespace + ``` + + Many [add-ons](/docs/concepts/cluster-administration/addons/) run as the + "default" service account in the `kube-system` namespace. + To allow those add-ons to run with super-user access, grant cluster-admin + permissions to the "default" service account in the `kube-system` namespace. + + {{< caution >}} + Enabling this means the `kube-system` namespace contains Secrets + that grant super-user access to your cluster's API. + {{< /caution >}} + + ```shell + kubectl create clusterrolebinding add-on-cluster-admin \ + --clusterrole=cluster-admin \ + --serviceaccount=kube-system:default + ``` + +3. Grant a role to all service accounts in a namespace + + If you want all applications in a namespace to have a role, no matter what service account they use, + you can grant a role to the service account group for that namespace. + + For example, grant read-only permission within "my-namespace" to all service accounts in that namespace: + + ```shell + kubectl create rolebinding serviceaccounts-view \ + --clusterrole=view \ + --group=system:serviceaccounts:my-namespace \ + --namespace=my-namespace + ``` + +4. Grant a limited role to all service accounts cluster-wide (discouraged) + + If you don't want to manage permissions per-namespace, you can grant a cluster-wide role to all service accounts. + + For example, grant read-only permission across all namespaces to all service accounts in the cluster: + + ```shell + kubectl create clusterrolebinding serviceaccounts-view \ + --clusterrole=view \ + --group=system:serviceaccounts + ``` + +5. Grant super-user access to all service accounts cluster-wide (strongly discouraged) + + If you don't care about partitioning permissions at all, you can grant super-user access to all service accounts. + + {{< warning >}} + This allows any application full access to your cluster, and also grants + any user with read access to Secrets (or the ability to create any pod) + full access to your cluster. + {{< /warning >}} + + ```shell + kubectl create clusterrolebinding serviceaccounts-cluster-admin \ + --clusterrole=cluster-admin \ + --group=system:serviceaccounts + ``` + +## Upgrading from ABAC + +Clusters that originally ran older Kubernetes versions often used +permissive ABAC policies, including granting full API access to all +service accounts. + +Default RBAC policies grant scoped permissions to control-plane components, nodes, +and controllers, but grant *no permissions* to service accounts outside the `kube-system` namespace +(beyond discovery permissions given to all authenticated users). + +While far more secure, this can be disruptive to existing workloads expecting to automatically receive API permissions. +Here are two approaches for managing this transition: + +### Parallel authorizers + +Run both the RBAC and ABAC authorizers, and specify a policy file that contains +the [legacy ABAC policy](/docs/reference/access-authn-authz/abac/#policy-file-format): + +``` +--authorization-mode=...,RBAC,ABAC --authorization-policy-file=mypolicy.json +``` + +To explain that first command line option in detail: if earlier authorizers, such as Node, +deny a request, then the the RBAC authorizer attempts to authorize the API request. If RBAC +also denies that API request, the ABAC authorizer is then run. This means that any request +allowed by *either* the RBAC or ABAC policies is allowed. + +When the kube-apiserver is run with a log level of 5 or higher for the RBAC component +(`--vmodule=rbac*=5` or `--v=5`), you can see RBAC denials in the API server log +(prefixed with `RBAC`). +You can use that information to determine which roles need to be granted to which users, groups, or service accounts. + +Once you have [granted roles to service accounts](#service-account-permissions) and workloads +are running with no RBAC denial messages in the server logs, you can remove the ABAC authorizer. + +### Permissive RBAC permissions + +You can replicate a permissive ABAC policy using RBAC role bindings. + +{{< warning >}} +The following policy allows **ALL** service accounts to act as cluster administrators. +Any application running in a container receives service account credentials automatically, +and could perform any action against the API, including viewing secrets and modifying permissions. +This is not a recommended policy. + +```shell +kubectl create clusterrolebinding permissive-binding \ + --clusterrole=cluster-admin \ + --user=admin \ + --user=kubelet \ + --group=system:serviceaccounts +``` +{{< /warning >}} + +After you have transitioned to use RBAC, you should adjust the access controls +for your cluster to ensure that these meet your information security needs. + +{{% /capture %}} From a81a2b600f1317488ed9f2e6172a905cd213af08 Mon Sep 17 00:00:00 2001 From: Imre Nagi Date: Thu, 18 Jun 2020 22:08:15 +0700 Subject: [PATCH 061/218] Use RoleBinding term Signed-off-by: Imre Nagi --- .../id/docs/reference/access-authn-authz/rbac.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/content/id/docs/reference/access-authn-authz/rbac.md b/content/id/docs/reference/access-authn-authz/rbac.md index d6214dd3f2..44e6262f1c 100644 --- a/content/id/docs/reference/access-authn-authz/rbac.md +++ b/content/id/docs/reference/access-authn-authz/rbac.md @@ -561,17 +561,17 @@ Modifikasi sumber daya ini dapat mengakibatkan klaster yang malfungsi. Pada setiap _start-up-_, server API memperbaharui ClusterRole bawaan dengan berbagai izin yang hilang, dan memperbaharui ikatan ClusterRole bawaan dengan subjek yang hilang. Ini memungkinkan klaster untuk memperbaiki modifikasi yang tidak disengaja, dan membantu menjaga peran -dan ikatan peran selalu terkini karena izin dan subjek berubah pada rilis terbaru Kubernetes. +dan RoleBinding selalu terkini karena izin dan subjek berubah pada rilis terbaru Kubernetes. Untuk menon-aktifkan rekonsiliasi ini, setel anotasi `rbac.authorization.kubernetes.io/autoupdate` -pada ClusterRole bawaan atau ikatan peran bawaan menjadi `false`. +pada ClusterRole bawaan atau RoleBinding bawaan menjadi `false`. Ingat bahwa hilangnya izin dan subjek bawaan dapat mengakibatkan klaster tidak berfungsi. Rekonsiliasi otomatis diaktifkan secara bawaan jika otorizer RBAC aktif. ### API discovery roles {#discovery-roles} -Ikatan peran bawaan memberi otorisasi kepada pengguna yang tidak terotentikasi untuk membaca informasi API yang dianggap aman +RoleBinding bawaan memberi otorisasi kepada pengguna yang tidak terotentikasi untuk membaca informasi API yang dianggap aman untuk diakses publik (termasuk CustomResourceDefinitions). Untuk menonaktifkan akses anonim, tambahkan `--anonymous-auth=false` ke konfigurasi server API. Untuk melihat konfigurasi peran ini melalui `kubectl` jalankan perintah: @@ -641,14 +641,14 @@ metadata: system:masters group Mengizinkan akses super-user access untuk melakukan berbagai aksi pada berbagai sumber daya. Ketika digunakan pada ClusterRoleBinding, ini memberikan kendali penuh terhadap seluruh sumber daya pada klaster dan seluruh namespace. -Ketika digunakan pada RoleBinding, ini memberikan kendali penuh terhadap setiap sumber daya pada namespace ikatan peran, termasuk namespace itu sendiri. +Ketika digunakan pada RoleBinding, ini memberikan kendali penuh terhadap setiap sumber daya pada namespace RoleBinding, termasuk namespace itu sendiri. admin None mengizinkan akses admin, yang dimaksudkan untuk diberikan dalam sebuah namespace menggunakan RoleBinding. Jika digunakan dalam RoleBinding, ini memungkikan akses baca/tulis ke sebagian besar sumber daya di sebuah namespace, -termasuk kemampuan untuk membuat peran dan ikatan peran dalam namespace. +termasuk kemampuan untuk membuat Role dan RoleBinding dalam namespace. Peran ini tidak memungkinkan akses tulis pada kuota sumber daya atau ke namespace itu sendiri. @@ -656,7 +656,7 @@ Peran ini tidak memungkinkan akses tulis pada kuota sumber daya atau ke namespac None Mengizinkan akses baca/tulis pada seluruh objek dalam namespace. -Peran ini tidak memungkinkan untuk melihat dan merubah peran dan ikatan peran. +Peran ini tidak memungkinkan untuk melihat dan merubah Role dan RoleBinding. Namun, peran ini memungkinkan untuk mengakses secret dan menjalankan pod seperti ServiceAccount dalam namespace, sehingga dapat digunakan untuk mendapatkan tingkat akses API dari setiap ServiceAccount di namespace. @@ -666,7 +666,7 @@ sehingga dapat digunakan untuk mendapatkan tingkat akses API dari setiap Service None Mengizinkan akses baca untuk melihat hampir seluruh objek dalam namespace. -Ini tidak memungkinkan untuk melihat peran dan ikatan peran. +Ini tidak memungkinkan untuk melihat peran dan RoleBinding. Peran ini tidak memungkikan melihat Secret, karena pembacaan konten Secret memungkinkan akses ke kredensial ServiceAccount dalam namespace, yang akan memungkinkan akses API sebagai From 1f45d53e25e817ce4c4dcc73ac2bd745f5c04eb8 Mon Sep 17 00:00:00 2001 From: Brandon DeVries Date: Thu, 18 Jun 2020 13:08:07 -0400 Subject: [PATCH 062/218] ommitted "not" From context and general understanding, it looks like this was intended to be "most Kubernetes users will *not* need to install extensions and fewer will need to author new ones." --- content/en/docs/concepts/extend-kubernetes/extend-cluster.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/extend-kubernetes/extend-cluster.md b/content/en/docs/concepts/extend-kubernetes/extend-cluster.md index 7914b1cab5..bc06bd4ab0 100644 --- a/content/en/docs/concepts/extend-kubernetes/extend-cluster.md +++ b/content/en/docs/concepts/extend-kubernetes/extend-cluster.md @@ -50,7 +50,7 @@ Extensions are software components that extend and deeply integrate with Kuberne They adapt it to support new types and new kinds of hardware. Most cluster administrators will use a hosted or distribution -instance of Kubernetes. As a result, most Kubernetes users will need to +instance of Kubernetes. As a result, most Kubernetes users will not need to install extensions and fewer will need to author new ones. ## Extension Patterns From c6e70fc79f09c02406b4b898dda0c693e46231c6 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Fri, 19 Jun 2020 09:57:12 +0800 Subject: [PATCH 063/218] [zh] Fix task list We now seem to have two sections on extending Kubernetes. This turns out to be a folder name change problem after a closer investigation. The English folder changed 'access-kubernetes-api' to 'extend-kubernetes', but this change was not propagated to Chinese localization. --- content/zh/docs/tasks/access-kubernetes-api/_index.md | 4 ---- content/zh/docs/tasks/extend-kubernetes/_index.md | 5 +++++ .../configure-aggregation-layer.md | 0 .../custom-resources/_index.md | 0 .../custom-resource-definition-versioning.md | 0 .../http-proxy-access-api.md | 0 .../setup-extension-api-server.md | 0 7 files changed, 5 insertions(+), 4 deletions(-) delete mode 100755 content/zh/docs/tasks/access-kubernetes-api/_index.md create mode 100755 content/zh/docs/tasks/extend-kubernetes/_index.md rename content/zh/docs/tasks/{access-kubernetes-api => extend-kubernetes}/configure-aggregation-layer.md (100%) rename content/zh/docs/tasks/{access-kubernetes-api => extend-kubernetes}/custom-resources/_index.md (100%) rename content/zh/docs/tasks/{access-kubernetes-api => extend-kubernetes}/custom-resources/custom-resource-definition-versioning.md (100%) rename content/zh/docs/tasks/{access-kubernetes-api => extend-kubernetes}/http-proxy-access-api.md (100%) rename content/zh/docs/tasks/{access-kubernetes-api => extend-kubernetes}/setup-extension-api-server.md (100%) diff --git a/content/zh/docs/tasks/access-kubernetes-api/_index.md b/content/zh/docs/tasks/access-kubernetes-api/_index.md deleted file mode 100755 index 36c224ddda..0000000000 --- a/content/zh/docs/tasks/access-kubernetes-api/_index.md +++ /dev/null @@ -1,4 +0,0 @@ ---- -title: "扩展 Kubernetes" -weight: 90 ---- diff --git a/content/zh/docs/tasks/extend-kubernetes/_index.md b/content/zh/docs/tasks/extend-kubernetes/_index.md new file mode 100755 index 0000000000..2bf9ad2537 --- /dev/null +++ b/content/zh/docs/tasks/extend-kubernetes/_index.md @@ -0,0 +1,5 @@ +--- +title: "扩展 Kubernetes" +description: 了解针对工作环境需要来调整 Kubernetes 集群的进阶方法 +weight: 90 +--- diff --git a/content/zh/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md b/content/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer.md similarity index 100% rename from content/zh/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md rename to content/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer.md diff --git a/content/zh/docs/tasks/access-kubernetes-api/custom-resources/_index.md b/content/zh/docs/tasks/extend-kubernetes/custom-resources/_index.md similarity index 100% rename from content/zh/docs/tasks/access-kubernetes-api/custom-resources/_index.md rename to content/zh/docs/tasks/extend-kubernetes/custom-resources/_index.md diff --git a/content/zh/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning.md b/content/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md similarity index 100% rename from content/zh/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning.md rename to content/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md diff --git a/content/zh/docs/tasks/access-kubernetes-api/http-proxy-access-api.md b/content/zh/docs/tasks/extend-kubernetes/http-proxy-access-api.md similarity index 100% rename from content/zh/docs/tasks/access-kubernetes-api/http-proxy-access-api.md rename to content/zh/docs/tasks/extend-kubernetes/http-proxy-access-api.md diff --git a/content/zh/docs/tasks/access-kubernetes-api/setup-extension-api-server.md b/content/zh/docs/tasks/extend-kubernetes/setup-extension-api-server.md similarity index 100% rename from content/zh/docs/tasks/access-kubernetes-api/setup-extension-api-server.md rename to content/zh/docs/tasks/extend-kubernetes/setup-extension-api-server.md From bf33cf01108a5a4bfb9c57fdbe160fe1638f8ba3 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Tue, 16 Jun 2020 14:06:57 +0800 Subject: [PATCH 064/218] [zh] Fix content in DNS debugging --- .../dns-debugging-resolution.md | 34 +++---------------- 1 file changed, 4 insertions(+), 30 deletions(-) diff --git a/content/zh/docs/tasks/administer-cluster/dns-debugging-resolution.md b/content/zh/docs/tasks/administer-cluster/dns-debugging-resolution.md index 011cf99550..41b392fd07 100644 --- a/content/zh/docs/tasks/administer-cluster/dns-debugging-resolution.md +++ b/content/zh/docs/tasks/administer-cluster/dns-debugging-resolution.md @@ -1,51 +1,27 @@ --- -translator: -- nicksu -reviewers: -- bowei -- zihongz -title: Debug DNS 方案 +title: 调试 DNS 问题 content_type: task --- - + - 这篇文章提供了一些关于 DNS 问题诊断的方法。 - - ---> - ## {{% heading "prerequisites" %}} + - {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - Kubernetes 1.6 或者以上版本。 - 集群必须使用了 `coredns` (或者 `kube-dns`)插件。 - - - ### 创建一个简单的 Pod 作为测试环境 @@ -134,7 +109,6 @@ search default.svc.cluster.local svc.cluster.local cluster.local google.internal nameserver 10.0.0.10 options ndots:5 ``` - --> ### 先检查本地的 DNS 配置 From 8f791213ab39204254827af606d6c8bcb8c63045 Mon Sep 17 00:00:00 2001 From: Maciej Filocha Date: Fri, 19 Jun 2020 09:54:34 +0200 Subject: [PATCH 065/218] Kubernetes API overview Polish docs sync --- .../docs/concepts/overview/kubernetes-api.md | 130 ++++++++++++------ 1 file changed, 87 insertions(+), 43 deletions(-) diff --git a/content/pl/docs/concepts/overview/kubernetes-api.md b/content/pl/docs/concepts/overview/kubernetes-api.md index 9126c6cfa3..79deb51add 100644 --- a/content/pl/docs/concepts/overview/kubernetes-api.md +++ b/content/pl/docs/concepts/overview/kubernetes-api.md @@ -9,17 +9,13 @@ card: -Ogólne reguły dotyczące API opisane są w dokumentacji [API conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md). +Sercem {{< glossary_tooltip text="warstwy sterowania" term_id="control-plane" >}} Kubernetes +jest {{< glossary_tooltip text="serwer API" term_id="kube-apiserver" >}}. Serwer udostępnia +API poprzez HTTP, umożliwiając wzajemną komunikację pomiędzy użytkownikami, częściami składowymi klastra i komponentami zewnętrznymi. -Punkty dostępowe *(endpoints)* API, typy zasobów oraz przykłady są dostępne w [API Reference](/docs/reference). +API Kubernetes pozwala na sprawdzanie i zmianę stanu obiektów (przykładowo: pody, _Namespaces_, _ConfigMaps_, _Events_). -Zdalny dostęp do API omówiono w dokumentacji [Controlling API Access](/docs/reference/access-authn-authz/controlling-access/). - -API Kubernetes to także podstawa deklaratywnego schematu konfiguracji dla systemu. Obiekty API mogą być tworzone, zmieniane, kasowane i odpytywane sa pomocą narzędzia linii poleceń [kubectl](/docs/reference/kubectl/overview/). - -Kubernetes przechowuje także swój serializowany stan (obecnie w [etcd](https://coreos.com/docs/distributed-configuration/getting-started-with-etcd/)) w postaci obiektów API. - -Kubernetes jako taki składa się z wielu elementów składowych, które komunikują się ze sobą poprzez swoje API. +Punkt dostępowe _(endpoints)_ API, typy zasobów i przykłady opisane są w [API Reference](/docs/reference/kubernetes-api/). @@ -28,48 +24,76 @@ Kubernetes jako taki składa się z wielu elementów składowych, które komunik ## Zmiany w API -Z naszego doświadczenia wynika, że każdy system, który odniósł sukces, musi się nieustająco rozwijać w miarę zmieniających się potrzeb. Dlatego oczekujemy, że API też będzie się zmieniało i rozrastało. W dłuższym horyzoncie nie planujemy jednak żadnych zmian, które mogą być niezgodne z istniejącymi klientami. W ogólności, nowe zasoby i pola definiujące zasoby API są dodawane stosunkowo często. Usuwanie zasobów lub pól jest regulowane przez [API deprecation policy](/docs/reference/using-api/deprecation-policy/). +Jednym z wymagań, które odnoszą się do każdego systemu, który odniósł sukces, jest zdolność do rozwoju i ewolucji w miarę pojawiających się i zmieniających potrzeb. +Dlatego Kubernetes został zaprojektowany tak, aby umożliwić ciągły rozwój i zmiany w API. +Celem projektu Kubernetes jest _zachowanie_ zgodności z istniejącymi klientami i utrzymanie tej zgodności +przez odpowiednio długi czas, pozwalający innym projektom na stopniowe dostosowanie. -Definicja zmiany zgodnej (kompatybilnej) oraz metody wprowadzania zmian w API opisano w szczegółach w [API change document](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md). +W skrócie, nowe zasoby API i nowe pola dla konkretnych zasobów mogą być dodawane stosunkowo często. +Usunięcie zasobów lub pól wymaga stosowania +[API deprecation policy](/docs/reference/using-api/deprecation-policy/). -## Definicje OpenAPI i Swagger +Szczegółowe objaśnienia, jak wygląda zmiana, która zachowuje zgodność i jak zmieniać API, znajdują się w dokumencie +[API changes](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme). -Pełne szczegóły API są udokumentowane zgodnie z [OpenAPI](https://www.openapis.org/). +## Specyfikacja OpenAPI {#api-specification} -Począwszy od Kubernetes w wersji 1.10, serwer Kubernetes API dostarcza specyfikację OpenAPI poprzez punkt końcowy `/openapi/v2`. -Wymagany format określa się w nagłówkach HTTP: +Pełną specyfikację API udokumentowano za pomocą [OpenAPI](https://www.openapis.org/). -Nagłówek | Dopuszczalne wartości ------- | --------------- -Accept | `application/json`, `application/com.github.proto-openapi.spec.v2@v1.0+protobuf` (domyślnie content-type to `application/json` dla `*/*` lub pominięcie tego nagłówka) -Accept-Encoding | `gzip` (pominięcie nagłówka jest dozwolone) +Serwer API Kubernetes API udostępnia specyfikację OpenAPI poprzez ścieżkę `/openapi/v2`. +Aby wybrać format odpowiedzi, użyj nagłówków żądania zgodnie z: -W wersjach wcześniejszych niż 1.14, punkty końcowe określone przez ich format (`/swagger.json`, `/swagger-2.0.0.json`, `/swagger-2.0.0.pb-v1`, `/swagger-2.0.0.pb-v1.gz`) udostępniały specyfikację OpenAPI zgodnie z tymi formatami. Te punkty końcowe były stopniowo wycofywane i ostatecznie usunięte w wersji 1.14 Kubernetes. - -**Przykłady pobierania specyfikacji OpenAPI**: - -Przed 1.10 | Kubernetes 1.10 i nowszy ------------ | ----------------------------- -GET /swagger.json | GET /openapi/v2 **Accept**: application/json -GET /swagger-2.0.0.pb-v1 | GET /openapi/v2 **Accept**: application/com.github.proto-openapi.spec.v2@v1.0+protobuf -GET /swagger-2.0.0.pb-v1.gz | GET /openapi/v2 **Accept**: application/com.github.proto-openapi.spec.v2@v1.0+protobuf **Accept-Encoding**: gzip + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
NagłówekDopuszczalne wartościUwagi
Accept-Encodinggzippominięcie tego nagłówka jest dozwolone
Acceptapplication/com.github.proto-openapi.spec.v2@v1.0+protobufgłównie do celu komunikacji wewnątrz klastra
application/jsondomyślne
*udostępnia application/json
Dozwolone nagłówki żądań dla zapytania OpenAPI v2
W Kubernetes zaimplementowany jest alternatywny format serializacji na potrzeby API oparty o Protobuf, który jest przede wszystkim przeznaczony na potrzeby wewnętrznej komunikacji w klastrze i opisany w [design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md). Pliki IDL dla każdego ze schematów można znaleźć w pakietach Go, które definiują obiekty API. -Przed wersją 1.14, apiserver Kubernetes udostępniał też specyfikację API [Swagger v1.2](http://swagger.io/) poprzez `/swaggerapi`. -Ten punkt końcowy został skierowany do wycofania i ostatecznie usunięty w wersji Kubernetes 1.14. - ## Obsługa wersji API -Aby ułatwić usuwanie poszczególnych pól lub restrukturyzację reprezentacji zasobów, Kubernetes obsługuje równocześnie wiele wersji API, każde poprzez osobną ścieżkę API, na przykład: `/api/v1` lub +Aby ułatwić usuwanie poszczególnych pól lub restrukturyzację reprezentacji zasobów, Kubernetes obsługuje +równocześnie wiele wersji API, każde poprzez osobną ścieżkę API, na przykład: `/api/v1` lub `/apis/extensions/v1beta1`. -Zdecydowaliśmy się na rozdział wersji na poziomie całego API, a nie na poziomie poszczególnych zasobów lub pól, aby być pewnym, że API odzwierciedla w sposób przejrzysty i spójny zasoby systemowe i ich zachowania i pozwala na kontrolowany dostęp do tych API, które są w fazie wycofywania lub fazie eksperymentalnej. Schematy serializacji JSON i Protobuf stosują się do tych samych reguł wprowadzania zmian schematów — cały opis poniżej odnosi się do obydwu z nich. +Zdecydowaliśmy się na rozdział wersji na poziomie całego API, a nie na poziomie poszczególnych zasobów lub pól, aby być pewnym, +że API odzwierciedla w sposób przejrzysty i spójny zasoby systemowe i ich zachowania i pozwala +na kontrolowany dostęp do tych API, które są w fazie wycofywania lub fazie eksperymentalnej. -Należy mieć na uwadze, że wersje API i wersje oprogramowania są powiązane ze sobą w sposób niebezpośredni. [API and release -versioning proposal](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) opisuje związki pomiędzy zarządzaniem wersjami API i oprogramowania. +Schematy serializacji JSON i Protobuf stosują się do tych samych reguł wprowadzania zmian schematów — cały opis poniżej odnosi się do obydwu z nich. -Różne wersje API oznaczają inną stabilność i poziom wsparcia. Kryteria dla każdego z tych poziomów opisano szczegółowo w [API Changes documentation](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions). Podsumowanie zamieszczono poniżej poniżej: +Należy mieć na uwadze, że wersje API i wersje oprogramowania są powiązane ze sobą w sposób niebezpośredni. Proponowany +[Kubernetes Release Versioning](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) opisuje związki pomiędzy zarządzaniem wersjami API i oprogramowania. + +Różne wersje API oznaczają inną stabilność i poziom wsparcia. Kryteria dla każdego z tych poziomów opisano szczegółowo +w [API Changes documentation](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions). +Podsumowanie zamieszczono poniżej: - Poziom Alfa: - Nazwa wersji zawiera słowo `alpha` (np. `v1alpha1`). @@ -81,8 +105,11 @@ Różne wersje API oznaczają inną stabilność i poziom wsparcia. Kryteria dla - Nazwa wersji zawiera słowo `beta` (np. `v2beta3`). - Oprogramowanie jest dobrze przetestowane. Włączenie tej funkcjonalności uznaje się za bezpieczne. Funkcjonalność domyślnie włączona. - Wsparcie dla funkcjonalności będzie utrzymywane, choć może zmieniać się w niektórych szczegółach. - - Schemat lub semantyka obiektu może się zmienić w sposób niezgodny z poprzednimi wersjami w następnych wydaniach beta lub stabilnych. Jeśli taka zmiana będzie miała miejsce, dostarczymy instrukcję migracji do kolejnej wersji. Możemy wymagać skasowania, zmiany i odtworzenia obiektów API. Proces zmiany może wymagać dodatkowych wstępnych analiz. W czasie wprowadzania zmian mogą wystąpić przerwy w dostępności aplikacji, które z tej funkcjonalności korzystają. - - Rekomendowane tylko dla zastosowań niekrytycznych dla biznesu ze względu na potencjalnie niezgodne zmiany w kolejnych wersjach oprogramowania. Jeśli masz wiele klastrów, które mogą być aktualizowane niezależnie, można to ograniczenie pominąć. + - Schemat lub semantyka obiektu może się zmienić w sposób niezgodny z poprzednimi wersjami w następnych wydaniach beta lub stabilnych. Jeśli taka zmiana będzie miała miejsce, + dostarczymy instrukcję migracji do kolejnej wersji. Możemy wymagać skasowania, zmiany i odtworzenia obiektów API. + Proces zmiany może wymagać dodatkowych wstępnych analiz. W czasie wprowadzania zmian mogą wystąpić przerwy w dostępności aplikacji, które z tej funkcjonalności korzystają. + - Rekomendowane tylko dla zastosowań niekrytycznych dla biznesu ze względu na potencjalnie niezgodne zmiany w kolejnych wersjach oprogramowania. + Jeśli masz wiele klastrów, które mogą być aktualizowane niezależnie, można to ograniczenie pominąć. - **Testuj nasze funkcjonalności w fazie beta i zgłaszaj swoje uwagi! Po wyjściu z fazy beta, możemy nie mieć już możliwości — ze względów praktycznych — wprowadzać w nich żadnych zmian.** - Poziom Stabilny: - Nazwa wersji jest w postaci `vX`, gdzie `X` jest liczbą naturalną. @@ -111,18 +138,35 @@ API może być rozbudowane na dwa sposoby przy użyciu [custom resources](/docs/ ## Włączanie i wyłączanie grup API Określone zasoby i grupy API są włączone domyślnie. Włączanie i wyłączanie odbywa się poprzez ustawienie `--runtime-config` -w apiserwerze. `--runtime-config` przyjmuje wartości oddzielane przecinkami. Przykładowo, aby wyłączyć batch/v1, należy ustawić +w kube-apiserver. + +`--runtime-config` przyjmuje wartości oddzielane przecinkami. Przykładowo, aby wyłączyć batch/v1, należy ustawić `--runtime-config=batch/v1=false`, aby włączyć batch/v2alpha1, należy ustawić `--runtime-config=batch/v2alpha1`. -Ta opcja przyjmuje rozdzielony przecinkami zbiór par klucz=wartość, który opisuje konfigurację wykonawczą apiserwera. +Ta opcja przyjmuje rozdzielony przecinkami zbiór par klucz=wartość, który opisuje konfigurację wykonawczą serwera API. -{{< note >}}Włączenie lub wyłączenie grup lub zasobów wymaga restartu apiserver i controller-manager, aby zmiany w `--runtime-config` zostały wprowadzone.{{< /note >}} +{{< note >}}Włączenie lub wyłączenie grup lub zasobów wymaga restartu kube-apiserver i kube-controller-manager, +aby zmiany w `--runtime-config` zostały wprowadzone.{{< /note >}} -## Jak włączać dostęp do grup zasobów extensions/v1beta1 +## Dostęp do grup zasobów _extensions/v1beta1_ -DaemonSets, Deployments, HorizontalPodAutoscalers, Ingresses, Jobs i ReplicaSets znajdują się w grupie API `extensions/v1beta1` i są domyślnie włączone. +DaemonSets, Deployments, HorizontalPodAutoscalers, Ingresses, Jobs i ReplicaSets znajdują się w grupie API `extensions/v1beta1` i są domyślnie wyłączone. Przykładowo: aby włączyć deployments i daemonsets, ustaw `--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true`. {{< note >}}Włączanie i wyłączanie pojedynczych zasobów możliwe jest jedynie w ramach grupy API `extensions/v1beta1` z przyczyn historycznych{{< /note >}} +## Trwałość +Kubernetes przechowuje swój stan w postaci serializowanej jako zasoby API zapisywane w +{{< glossary_tooltip term_id="etcd" >}}. + + +## {{% heading "whatsnext" %}} + +[Controlling API Access](/docs/reference/access-authn-authz/controlling-access/) opisuje +sposoby, jakimi klaster zarządza dostępem do API. + +Ogólne wytyczne dotyczące API opisano w +[API conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#api-conventions). + +Punkty dostępowe API endpoints, typy zasobów i przykłady zamieszczono w [API Reference](/docs/reference/kubernetes-api/). From 05fdfcbb45b53f75bf79cde759b58ca5b2823f1d Mon Sep 17 00:00:00 2001 From: Maciej Filocha <12587791+mfilocha@users.noreply.github.com> Date: Fri, 19 Jun 2020 11:46:25 +0200 Subject: [PATCH 066/218] Fix tanslation style MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Karol Pucyński <9209870+kpucynski@users.noreply.github.com> --- content/pl/docs/concepts/overview/kubernetes-api.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/pl/docs/concepts/overview/kubernetes-api.md b/content/pl/docs/concepts/overview/kubernetes-api.md index 79deb51add..e13a77196f 100644 --- a/content/pl/docs/concepts/overview/kubernetes-api.md +++ b/content/pl/docs/concepts/overview/kubernetes-api.md @@ -169,4 +169,4 @@ sposoby, jakimi klaster zarządza dostępem do API. Ogólne wytyczne dotyczące API opisano w [API conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#api-conventions). -Punkty dostępowe API endpoints, typy zasobów i przykłady zamieszczono w [API Reference](/docs/reference/kubernetes-api/). +Punkty dostępowe API _(endpoints)_, typy zasobów i przykłady zamieszczono w [API Reference](/docs/reference/kubernetes-api/). From 67a65198ff3cb82dfcbbfce02abc5c4fadea7c73 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Fri, 19 Jun 2020 19:17:53 +0800 Subject: [PATCH 067/218] [zh] Improve translation for resource bin packing --- .../configuration/resource-bin-packing.md | 166 ++++++++---------- 1 file changed, 77 insertions(+), 89 deletions(-) diff --git a/content/zh/docs/concepts/configuration/resource-bin-packing.md b/content/zh/docs/concepts/configuration/resource-bin-packing.md index b43257f47f..dd4584c989 100644 --- a/content/zh/docs/concepts/configuration/resource-bin-packing.md +++ b/content/zh/docs/concepts/configuration/resource-bin-packing.md @@ -1,22 +1,12 @@ --- -reviewers: -- bsalamat -- k82cn -- ahg-g -title: 扩展资源的资源箱打包 +title: 扩展资源的资源装箱 content_type: concept -weight: 10 +weight: 50 --- @@ -26,46 +16,48 @@ weight: 10 -可以将 kube-scheduler 配置为使用 `RequestedToCapacityRatioResourceAllocation` 优先级函数启用资源箱打包以及扩展资源。 + +使用 `RequestedToCapacityRatioResourceAllocation` 优先级函数，可以将 kube-scheduler +配置为支持包含扩展资源在内的资源装箱操作。 优先级函数可用于根据自定义需求微调 kube-scheduler 。 - - -## 使用 RequestedToCapacityRatioResourceAllocation 启用装箱 - -在 Kubernetes 1.15 之前，Kube-scheduler 用于允许根据主要资源，如 CPU 和内存对容量之比的请求对节点进行评分。 -Kubernetes 1.16 在优先级函数中添加了一个新参数，该参数允许用户指定资源以及每个资源的权重，以便根据容量之比的请求为节点评分。 -这允许用户通过使用适当的参数来打包扩展资源，从而提高了大型集群中稀缺资源的利用率。 -`RequestedToCapacityRatioResourceAllocation` 优先级函数的行为可以通过名为 `requestedToCapacityRatioArguments` 的配置选项进行控制。 -这个论证由两个参数 `shape` 和 `resources` 组成。 -Shape 允许用户根据 `utilization` 和 `score` 值将功能调整为要求最少或要求最高的功能。 -资源由 `name` 和 `weight` 组成，`name` 指定评分时要考虑的资源，`weight` 指定每种资源的权重。 + +## 使用 RequestedToCapacityRatioResourceAllocation 启用装箱 + +在 Kubernetes 1.15 之前，Kube-scheduler 通常允许根据对主要资源（如 CPU 和内存）的请求数量和可用容量 +之比率对节点评分。 +Kubernetes 1.16 在优先级函数中添加了一个新参数，该参数允许用户指定资源以及每类资源的权重， +以便根据请求数量与可用容量之比率为节点评分。 +这就使得用户可以通过使用适当的参数来对扩展资源执行装箱操作，从而提高了大型集群中稀缺资源的利用率。 +`RequestedToCapacityRatioResourceAllocation` 优先级函数的行为可以通过名为 +`requestedToCapacityRatioArguments` 的配置选项进行控制。 +该标志由两个参数 `shape` 和 `resources` 组成。 +shape 允许用户根据 `utilization` 和 `score` 值将函数调整为最少请求（least requested）或 +最多请求（most requested）计算。 +resources 由 `name` 和 `weight` 组成，`name` 指定评分时要考虑的资源，`weight` 指定每种资源的权重。 -以下是一个配置示例，该配置将 `requestedToCapacityRatioArguments` 设置为扩展资源 `intel.com/foo` 和 `intel.com/bar` 的装箱行为 + +以下是一个配置示例，该配置将 `requestedToCapacityRatioArguments` 设置为对扩展资源 +`intel.com/foo` 和 `intel.com/bar` 的装箱行为 ```json { "kind" : "Policy", "apiVersion" : "v1", - ... - "priorities" : [ - ... - { "name": "RequestedToCapacityRatioPriority", "weight": 2, @@ -89,16 +81,17 @@ Below is an example configuration that sets `requestedToCapacityRatioArguments` -**默认情况下禁用此功能** + +**默认情况下此功能处于被禁用状态** -### 调整 RequestedToCapacityRatioResourceAllocation 优先级函数 - + +### 调整 RequestedToCapacityRatioResourceAllocation 优先级函数 + `shape` 用于指定 `RequestedToCapacityRatioPriority` 函数的行为。 ```yaml @@ -109,8 +102,9 @@ Below is an example configuration that sets `requestedToCapacityRatioArguments` -上面的参数在利用率为 0% 时给节点评分为0，在利用率为 100% 时给节点评分为10，因此启用了装箱行为。 -要启用最少请求，必须按如下方式反转得分值。 + +上面的参数在 utilization 为 0% 时给节点评分为 0，在 utilization 为 100% 时给节点评分为 10， +因此启用了装箱行为。要启用最少请求（least requested）模式，必须按如下方式反转得分值。 ```yaml {"utilization": 0, "score": 100}, @@ -124,9 +118,9 @@ The above arguments give the node a score of 0 if utilization is 0% and 10 for u ``` yaml "resources": [ - {"name": "CPU", "weight": 1}, - {"name": "Memory", "weight": 1} - ] + {"name": "CPU", "weight": 1}, + {"name": "Memory", "weight": 1} +] ``` -weight 参数是可选的，如果未指定，则设置为1。 -同样， weight 不能设置为负值。 +weight 参数是可选的，如果未指定，则设置为 1。 +同时，weight 不能设置为负值。 -### RequestedToCapacityRatioResourceAllocation 优先级函数如何对节点评分 - -本部分适用于希望了解此功能的内部细节的人员。 -以下是如何针对给定的一组值计算节点得分的示例。 + +### RequestedToCapacityRatioResourceAllocation 优先级函数如何对节点评分 + +本节适用于希望了解此功能的内部细节的人员。 +以下是如何针对给定的一组值来计算节点得分的示例。 ``` -Requested Resources +请求的资源 -intel.com/foo : 2 +intel.com/foo: 2 Memory: 256MB CPU: 2 -Resource Weights +资源权重 -intel.com/foo : 5 +intel.com/foo: 5 Memory: 1 CPU: 3 FunctionShapePoint {{0, 0}, {100, 10}} -Node 1 Spec +节点 Node 1 配置 -Available: -intel.com/foo : 4 -Memory : 1 GB -CPU: 8 +可用： + intel.com/foo : 4 + Memory : 1 GB + CPU: 8 -Used: -intel.com/foo: 1 -Memory: 256MB -CPU: 1 +已用： + intel.com/foo: 1 + Memory: 256MB + CPU: 1 - -Node Score: +节点得分： intel.com/foo = resourceScoringFunction((2+1),4) - = (100 - ((4-3)*100/4) - = (100 - 25) - = 75 - = rawScoringFunction(75) + = (100 - ((4-3)*100/4) + = (100 - 25) + = 75 + = rawScoringFunction(75) = 7 Memory = resourceScoringFunction((256+256),1024) @@ -214,27 +207,25 @@ NodeScore = (7 * 5) + (5 * 1) + (3 * 3) / (5 + 1 + 3) = 5 -Node 2 Spec +节点 Node 2 配置 -Available: -intel.com/foo: 8 -Memory: 1GB -CPU: 8 +可用： + intel.com/foo: 8 + Memory: 1GB + CPU: 8 -Used: +已用： + intel.com/foo: 2 + Memory: 512MB + CPU: 6 -intel.com/foo: 2 -Memory: 512MB -CPU: 6 - - -Node Score: +节点得分： intel.com/foo = resourceScoringFunction((2+2),8) - = (100 - ((8-4)*100/8) - = (100 - 25) - = 50 - = rawScoringFunction(50) + = (100 - ((8-4)*100/8) + = (100 - 25) + = 50 + = rawScoringFunction(50) = 5 Memory = resourceScoringFunction((256+512),1024) @@ -251,8 +242,5 @@ CPU = resourceScoringFunction((2+6),8) NodeScore = (5 * 5) + (7 * 1) + (10 * 3) / (5 + 1 + 3) = 7 - ``` - - From e7970d51c58e428fc623882c61b82bea310fdc37 Mon Sep 17 00:00:00 2001 From: June Yi Date: Fri, 19 Jun 2020 21:08:05 +0900 Subject: [PATCH 068/218] Update glossary for Korean l10n --- content/ko/docs/contribute/localization_ko.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ko/docs/contribute/localization_ko.md b/content/ko/docs/contribute/localization_ko.md index 862f741ab7..76b22e5529 100644 --- a/content/ko/docs/contribute/localization_ko.md +++ b/content/ko/docs/contribute/localization_ko.md @@ -390,7 +390,7 @@ PersistentVolume | 퍼시스턴트볼륨(PersistentVolume) | API 오브젝트인 PersistentVolumeClaim | 퍼시스턴트볼륨클레임(PersistentVolumeClaim) | API 오브젝트인 경우 pipeline | 파이프라인 | placeholder pod | 플레이스홀더(placeholder) 파드 | -Pod | 파드(Pod) | API 오브젝트인 경우 +Pod | 파드 | API 오브젝트인 경우에도 표현의 간결함을 위해 한영병기를 하지 않음 Pod Preset | 파드 프리셋 | PodAntiAffinity | 파드안티어피니티(PodAntiAffinity) | PodDisruptionBudget | PodDisruptionBudget | API 오브젝트인 경우 @@ -439,7 +439,7 @@ Selector | 셀렉터 | Self-healing | 자가 치유 | SelfSubjectAccessReview | 셀프서브젝트액세스리뷰(SelfSubjectAccessReview) | API 오브젝트인 경우 SelfSubjectRulesReview | SelfSubjectRulesReview | API 오브젝트이지만 용어를 구성하는 단어 중 복수형 Rules를 '룰스'로 외래어 표기하는 경우 한국어 독자에게 다소 생경할 수 있어 예외적으로 영문 용어를 사용함 -Service | 서비스(Service) | API 오브젝트인 경우 +Service | 서비스 | API 오브젝트인 경우에도 표현의 간결함을 위해 한영병기를 하지 않음 ServiceAccount | 서비스어카운트(ServiceAccount) | API 오브젝트인 경우 service discovery | 서비스 디스커버리 | service mesh | 서비스 메시 | From 60f0422f3a054fa7a6f08670c62a7a2eb9e500bf Mon Sep 17 00:00:00 2001 From: Brad Topol Date: Fri, 19 Jun 2020 10:42:43 -0400 Subject: [PATCH 069/218] updated wrangler doc to denote agreed to relaxing of style guidelines for good technical content as agreed at last planning meeting Signed-off-by: Brad Topol --- content/en/docs/contribute/advanced.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/en/docs/contribute/advanced.md b/content/en/docs/contribute/advanced.md index 9cf6a65883..5bed4259d7 100644 --- a/content/en/docs/contribute/advanced.md +++ b/content/en/docs/contribute/advanced.md @@ -39,6 +39,7 @@ The PR wrangler’s duties include: - Assign `Doc Review: Open Issues` or `Tech Review: Open Issues` for PRs that have been reviewed and require further input or action before merging. - Assign `/lgtm` and `/approve` labels to PRs that can be merged. - Merge PRs when they are ready, or close PRs that shouldn’t be accepted. + - Because we are limited on resources, we are willing to accept solid technical content even if all [style guidelines](/docs/contribute/style/style-guide/) are not met. Consider merging this type of content and opening a good first issue to address the style concerns. - Triage and tag incoming issues daily. See [Triage and categorize issues](/docs/contribute/review/for-approvers/#triage-and-categorize-issues) for guidelines on how SIG Docs uses metadata. ### Helpful GitHub queries for wranglers From 38248db194b18f87188302cecd0e08f8a54782dc Mon Sep 17 00:00:00 2001 From: Celeste Horgan Date: Fri, 19 Jun 2020 08:50:33 -0700 Subject: [PATCH 070/218] Fix feature state tags --- .../admission-controllers.md | 44 +++++++++++++------ 1 file changed, 31 insertions(+), 13 deletions(-) diff --git a/content/en/docs/reference/access-authn-authz/admission-controllers.md b/content/en/docs/reference/access-authn-authz/admission-controllers.md index e0f5ea0f43..874bcbeb1c 100644 --- a/content/en/docs/reference/access-authn-authz/admission-controllers.md +++ b/content/en/docs/reference/access-authn-authz/admission-controllers.md @@ -99,7 +99,9 @@ NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, Priority ## What does each admission controller do? -### AlwaysAdmit {#alwaysadmit} {{< feature-state for_k8s_version="v1.13" state="deprecated" >}} +### AlwaysAdmit {#alwaysadmit} + +{{< feature-state for_k8s_version="v1.13" state="deprecated" >}} This admission controller allows all pods into the cluster. It is deprecated because its behavior is the same as if there were no admission controller at all. @@ -113,7 +115,9 @@ scheduled onto the right node), without any authorization check against the imag is enabled, images are always pulled prior to starting containers, which means valid credentials are required. -### AlwaysDeny {#alwaysdeny} {{< feature-state for_k8s_version="v1.13" state="deprecated" >}} +### AlwaysDeny {#alwaysdeny} + +{{< feature-state for_k8s_version="v1.13" state="deprecated" >}} Rejects all requests. AlwaysDeny is DEPRECATED as no real meaning. @@ -164,7 +168,9 @@ if the pods don't already have toleration for taints `node.kubernetes.io/not-ready:NoExecute` or `node.alpha.kubernetes.io/unreachable:NoExecute`. -### DenyExecOnPrivileged {#denyexeconprivileged} {{< feature-state for_k8s_version="v1.13" state="deprecated" >}} +### DenyExecOnPrivileged {#denyexeconprivileged} + +{{< feature-state for_k8s_version="v1.13" state="deprecated" >}} This admission controller will intercept all requests to exec a command in a pod if that pod has a privileged container. @@ -175,7 +181,9 @@ Use of a policy-based admission plugin (like [PodSecurityPolicy](#podsecuritypol which can be targeted at specific users or Namespaces and also protects against creation of overly privileged Pods is recommended instead. -### DenyEscalatingExec {#denyescalatingexec} {{< feature-state for_k8s_version="v1.13" state="deprecated" >}} +### DenyEscalatingExec {#denyescalatingexec} + +{{< feature-state for_k8s_version="v1.13" state="deprecated" >}} This admission controller will deny exec and attach commands to pods that run with escalated privileges that allow host access. This includes pods that run as privileged, have access to the host IPC namespace, and @@ -187,7 +195,9 @@ Use of a policy-based admission plugin (like [PodSecurityPolicy](#podsecuritypol which can be targeted at specific users or Namespaces and also protects against creation of overly privileged Pods is recommended instead. -### EventRateLimit {#eventratelimit} {{< feature-state for_k8s_version="v1.13" state="alpha" >}} +### EventRateLimit {#eventratelimit} + +{{< feature-state for_k8s_version="v1.13" state="alpha" >}} This admission controller mitigates the problem where the API server gets flooded by event requests. The cluster admin can specify event rate limits by: @@ -446,7 +456,9 @@ applies a 0.1 CPU requirement to all Pods in the `default` namespace. See the [limitRange design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) and the [example of Limit Range](/docs/tasks/configure-pod-container/limit-range/) for more details. -### MutatingAdmissionWebhook {#mutatingadmissionwebhook} {{< feature-state for_k8s_version="v1.13" state="beta" >}} +### MutatingAdmissionWebhook {#mutatingadmissionwebhook} + +{{< feature-state for_k8s_version="v1.13" state="beta" >}} This admission controller calls any mutating webhooks which match the request. Matching webhooks are called in serial; each one may modify the object if it desires. @@ -537,7 +549,9 @@ This admission controller also protects the access to `metadata.ownerReferences[ of an object, so that only users with "update" permission to the `finalizers` subresource of the referenced *owner* can change it. -### PersistentVolumeLabel {#persistentvolumelabel} {{< feature-state for_k8s_version="v1.13" state="deprecated" >}} +### PersistentVolumeLabel {#persistentvolumelabel} + +{{< feature-state for_k8s_version="v1.13" state="deprecated" >}} This admission controller automatically attaches region or zone labels to PersistentVolumes as defined by the cloud provider (for example, GCE or AWS). @@ -708,7 +722,9 @@ objects in your Kubernetes deployment, you MUST use this admission controller to See the [resourceQuota design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md) and the [example of Resource Quota](/docs/concepts/policy/resource-quotas/) for more details. -### RuntimeClass {#runtimeclass} {{< feature-state for_k8s_version="v1.16" state="alpha" >}} +### RuntimeClass {#runtimeclass} + +{{< feature-state for_k8s_version="v1.16" state="alpha" >}} For [RuntimeClass](/docs/concepts/containers/runtime-class/) definitions which describe an overhead associated with running a pod, this admission controller will set the pod.Spec.Overhead field accordingly. @@ -729,11 +745,15 @@ We strongly recommend using this admission controller if you intend to make use The `StorageObjectInUseProtection` plugin adds the `kubernetes.io/pvc-protection` or `kubernetes.io/pv-protection` finalizers to newly created Persistent Volume Claims (PVCs) or Persistent Volumes (PV). In case a user deletes a PVC or PV the PVC or PV is not removed until the finalizer is removed from the PVC or PV by PVC or PV Protection Controller. Refer to the [Storage Object in Use Protection](/docs/concepts/storage/persistent-volumes/#storage-object-in-use-protection) for more detailed information. -### TaintNodesByCondition {#taintnodesbycondition} {{< feature-state for_k8s_version="v1.12" state="beta" >}} +### TaintNodesByCondition {#taintnodesbycondition} + +{{< feature-state for_k8s_version="v1.12" state="beta" >}} This admission controller {{< glossary_tooltip text="taints" term_id="taint" >}} newly created Nodes as `NotReady` and `NoSchedule`. That tainting avoids a race condition that could cause Pods to be scheduled on new Nodes before their taints were updated to accurately reflect their reported conditions. -### ValidatingAdmissionWebhook {#validatingadmissionwebhook} {{< feature-state for_k8s_version="v1.13" state="beta" >}} +### ValidatingAdmissionWebhook {#validatingadmissionwebhook} + +{{< feature-state for_k8s_version="v1.13" state="beta" >}} This admission controller calls any validating webhooks which match the request. Matching webhooks are called in parallel; if any of them rejects the request, the request @@ -773,6 +793,4 @@ phase, and therefore is the last admission controller to run. in the mutating phase. For earlier versions, there was no concept of validating versus mutating and the -admission controllers ran in the exact order specified. - - +admission controllers ran in the exact order specified. \ No newline at end of file From 439f9f437f99c48af3164c71e6f5990214ed76b9 Mon Sep 17 00:00:00 2001 From: Behzad <54417472+behzadm18@users.noreply.github.com> Date: Fri, 19 Jun 2020 17:57:40 +0200 Subject: [PATCH 071/218] Update configmap.md Add quotation marks around the value of the key "player_initial_lives" in configuration file of the ConfigMap called "game-demo". Otherwise, kubectl version 1.18 gives the following error with the command "kubectl apply -f game-demo-configMap.yaml" Error from server (BadRequest): error when creating "game-demo-configMap.yaml": ConfigMap in version "v1" cannot be handled as a ConfigMap: v1.ConfigMap.Data: ReadString: expects " or n, but found 3, error found in #10 byte of ...|l_lives":3,"ui_prope|..., bigger context ...|player.maximum-lives=5\n","player_initial_lives":3,"ui_properties_file_name":"user-interface.propert|... --- content/en/docs/concepts/configuration/configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/configuration/configmap.md b/content/en/docs/concepts/configuration/configmap.md index 23d2a9dbed..1c1a24106e 100644 --- a/content/en/docs/concepts/configuration/configmap.md +++ b/content/en/docs/concepts/configuration/configmap.md @@ -60,7 +60,7 @@ metadata: name: game-demo data: # property-like keys; each key maps to a simple value - player_initial_lives: 3 + player_initial_lives: "3" ui_properties_file_name: "user-interface.properties" # # file-like keys From ae5413c86868deead467709fa064875198a1039f Mon Sep 17 00:00:00 2001 From: Dan Kohn Date: Fri, 19 Jun 2020 12:15:03 -0400 Subject: [PATCH 072/218] Fix broken link Signed-off-by: Dan Kohn --- config.toml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/config.toml b/config.toml index 423562ee81..13961c17c0 100644 --- a/config.toml +++ b/config.toml @@ -237,7 +237,7 @@ no = 'Sorry to hear that. Please Date: Sat, 20 Jun 2020 10:06:56 +0800 Subject: [PATCH 073/218] Update typo in zh install-kubectl Make the change according to English page, and also the issue [here](https://github.com/minishift/minishift/issues/3440#issuecomment-617506530) --- .../zh/docs/tasks/tools/install-kubectl.md | 24 +++++++++---------- 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/content/zh/docs/tasks/tools/install-kubectl.md b/content/zh/docs/tasks/tools/install-kubectl.md index 9607f9f937..723c6c25b0 100644 --- a/content/zh/docs/tasks/tools/install-kubectl.md +++ b/content/zh/docs/tasks/tools/install-kubectl.md @@ -104,7 +104,7 @@ If you are on Ubuntu or one of other Linux distributions that support [snap](htt 2. Test to ensure the version you installed is sufficiently up-to-date: ``` - kubectl version + kubectl version --client ``` --> ## 在 Ubuntu 上使用 snap 安装 kubectl @@ -120,7 +120,7 @@ If you are on Ubuntu or one of other Linux distributions that support [snap](htt 2. 测试以确保您安装的版本是最新的： ``` - kubectl version + kubectl version --client ``` ## 在 macOS 上用 Homebrew 安装 kubectl @@ -153,7 +153,7 @@ If you are on macOS and using [Homebrew](https://brew.sh/) package manager, you 2. 测试以确保您安装的版本是最新的： ``` - kubectl version + kubectl version --client ``` @@ -171,7 +171,7 @@ If you are on macOS and using [Macports](https://macports.org/) package manager, 2. Test to ensure the version you installed is sufficiently up-to-date: ``` - kubectl version + kubectl version --client ``` --> @@ -188,7 +188,7 @@ If you are on macOS and using [Macports](https://macports.org/) package manager, 2. 测试以确保您安装的版本是最新的： ``` - kubectl version + kubectl version --client ``` ## 将 kubectl 作为 Google Cloud SDK 的一部分下载 @@ -360,7 +360,7 @@ kubectl 可以作为 Google Cloud SDK 的一部分进行安装。 3. 测试以确保您安装的版本是最新的： ``` - kubectl version + kubectl version --client ``` -要运行 nginx 部署并将其暴露，请参见 [kubectl 运行](/docs/reference/generated/kubectl/kubectl-commands/#run)。 - +要运行 nginx 部署并将其暴露，请参见[kubectl create deployment](/docs/reference/generated/kubectl/kubectl-commands#-em-deployment-em-) docker: ```shell @@ -57,10 +56,18 @@ kubectl run --image=nginx nginx-app --port=80 --env="DOMAIN=cluster" --> ```shell # 启动运行 nginx 的 Pod -kubectl create deployment --image=nginx nginx-app --port=80 --env="DOMAIN=cluster" +kubectl create deployment --image=nginx nginx-app ``` ``` -deployment "nginx-app" created +deployment.apps/nginx-app created +``` + +``` +# add env to nginx-app +kubectl set env deployment/nginx-app DOMAIN=cluster +``` +``` +deployment.apps/nginx-app env updated ``` {{< note >}} @@ -89,10 +96,10 @@ By using kubectl, you can create a [Deployment](/docs/concepts/workloads/control --> 在 kubectl 命令中，我们创建了一个 [Deployment](/docs/concepts/workloads/controllers/deployment/)，这将保证有 N 个运行 nginx 的 pod(N 代表 spec 中声明的 replica 数，默认为 1)。我们还创建了一个 [service](/docs/concepts/services-networking/service/)，其选择器与容器标签匹配。查看[使用服务访问群集中的应用程序](/docs/tasks/access-application-cluster/service-access-application-cluster) 获取更多信息。 - -默认情况下镜像会在后台运行，与 `docker run -d ...` 类似，如果您想在前台运行，使用: +默认情况下镜像会在后台运行，与 `docker run -d ...` 类似，如果您想在前台运行，使用 [`kubectl run`](/docs/reference/generated/kubectl/kubectl-commands/#run) 在前台运行 Pod: ```shell kubectl run [-i] [--tty] --attach --image= From 2c3ec99c731e8efff35ca35a07fe16929c26242f Mon Sep 17 00:00:00 2001 From: Joel Smith Date: Fri, 19 Jun 2020 22:27:27 -0600 Subject: [PATCH 075/218] Update link for HPA object to point to API docs instead of old design doc --- .../en/docs/tasks/run-application/horizontal-pod-autoscale.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md index 6dc61f8d4f..f84744cdd7 100644 --- a/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -181,7 +181,8 @@ are preserved as annotations when working with `autoscaling/v1`. When you create a HorizontalPodAutoscaler API object, make sure the name specified is a valid [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). More details about the API object can be found at -[HorizontalPodAutoscaler Object](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object). +[HorizontalPodAutoscaler Object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#horizontalpodautoscaler-v1-autoscaling). + ## Support for Horizontal Pod Autoscaler in kubectl From 1752d9ee2d0a4468c32f05493479f07176a528bc Mon Sep 17 00:00:00 2001 From: Brad Topol Date: Sat, 20 Jun 2020 00:39:12 -0400 Subject: [PATCH 076/218] updated phrasing --- content/en/docs/contribute/advanced.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/contribute/advanced.md b/content/en/docs/contribute/advanced.md index 5bed4259d7..594816a2b5 100644 --- a/content/en/docs/contribute/advanced.md +++ b/content/en/docs/contribute/advanced.md @@ -39,7 +39,7 @@ The PR wrangler’s duties include: - Assign `Doc Review: Open Issues` or `Tech Review: Open Issues` for PRs that have been reviewed and require further input or action before merging. - Assign `/lgtm` and `/approve` labels to PRs that can be merged. - Merge PRs when they are ready, or close PRs that shouldn’t be accepted. - - Because we are limited on resources, we are willing to accept solid technical content even if all [style guidelines](/docs/contribute/style/style-guide/) are not met. Consider merging this type of content and opening a good first issue to address the style concerns. + - Consider accepting accurate technical content even if the content meets only some of the docs' [style guidelines](/docs/contribute/style/style-guide/). Open a new issue with the label `good first issue` to address style concerns. - Triage and tag incoming issues daily. See [Triage and categorize issues](/docs/contribute/review/for-approvers/#triage-and-categorize-issues) for guidelines on how SIG Docs uses metadata. ### Helpful GitHub queries for wranglers From d757b2da39dd8bd0652c1fb669680d81aa305d50 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Sat, 20 Jun 2020 12:45:55 +0800 Subject: [PATCH 077/218] Move DNS debugging page back to cluster administration DNS resolution is a task in the control plane rather than application layer. --- .../dns-debugging-resolution.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename content/en/docs/tasks/{debug-application-cluster => administer-cluster}/dns-debugging-resolution.md (100%) diff --git a/content/en/docs/tasks/debug-application-cluster/dns-debugging-resolution.md b/content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md similarity index 100% rename from content/en/docs/tasks/debug-application-cluster/dns-debugging-resolution.md rename to content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md From e15f2eb9318c3acc977db32f519621188f9b8e55 Mon Sep 17 00:00:00 2001 From: Shuyang Wu Date: Sat, 20 Jun 2020 14:59:30 +0800 Subject: [PATCH 078/218] [zh] Update install-minikube, add alibaba image As commented [here](https://github.com/kubernetes/minikube/issues/5860#issuecomment-553201689) --- content/zh/docs/tasks/tools/install-minikube.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/content/zh/docs/tasks/tools/install-minikube.md b/content/zh/docs/tasks/tools/install-minikube.md index 55439a64e0..e4d16a1a2c 100644 --- a/content/zh/docs/tasks/tools/install-minikube.md +++ b/content/zh/docs/tasks/tools/install-minikube.md @@ -402,8 +402,14 @@ For setting the `--vm-driver` with `minikube start`, enter the name of the hyper [指定 VM 驱动程序](/docs/setup/learning-environment/minikube/#specifying-the-vm-driver) 列举了 `--vm-driver` 值的完整列表。 {{< /note >}} +{{< note >}} +由于国内无法直接连接k8s.gcr.io，推荐使用阿里云镜像，在`minikube start`中添加镜像参数 +{{< /note >}} + ```shell minikube start --vm-driver= +# Or when you need +minikube start --vm-driver= --image-repository=registry.cn-hangzhou.aliyuncs.com/google_containers ``` @@ -26,18 +24,11 @@ architecture design doc for more details. --> 在 Kubernetes 中，节点（Node）是执行工作的机器，以前叫做 `minion`。根据你的集群环境，节点可以是一个虚拟机或者物理机器。每个节点都包含用于运行 [pods](/docs/concepts/workloads/pods/pod/) 的必要服务，并由主控组件管理。节点上的服务包括 [容器运行时](/docs/concepts/overview/components/#node-components)、kubelet 和 kube-proxy。查阅架构设计文档中 [Kubernetes 节点](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) 一节获取更多细节。 - - - - -## 节点状态 - + +## 节点状态 + 一个节点的状态包含以下信息: * [地址](#addresses) @@ -52,11 +46,11 @@ A node's status contains the following information: * [容量与可分配](#capacity) * [信息](#info) - 可以使用以下命令显示节点状态和有关节点的其他详细信息： + ```shell kubectl describe node ``` @@ -67,32 +61,29 @@ Each section is described in detail below. ### 地址 - 这些字段组合的用法取决于你的云服务商或者裸机配置。 -* HostName：由节点的内核指定。可以通过 kubelet 的 `--hostname-override` 参数覆盖。 -* ExternalIP：通常是可以外部路由的节点 IP 地址（从集群外可访问）。 -* InternalIP：通常是仅可在集群内部路由的节点 IP 地址。 - +* HostName：由节点的内核设置。可以通过 kubelet 的 `--hostname-override` 参数覆盖。 +* ExternalIP：通常是节点的可以外部路由（从集群外可访问）的 IP 地址。 +* InternalIP：通常是节点的仅可在集群内部路由的 IP 地址。 ### 条件 {#condition} - `conditions` 字段描述了所有 `Running` 节点的状态。条件的示例包括： -| 节点条件 | 描述 | +| 节点条件 | 描述 | |----------------|-------------| -| `OutOfDisk` | `True` 表示节点的空闲空间不足以用于添加新 pods, 否则为 `False` | -| `Ready` | 表示节点是健康的并已经准备好接受 pods；`False` 表示节点不健康而且不能接受 pods；`Unknown` 表示节点控制器在最近 40 秒内没有收到节点的消息 | -| `MemoryPressure` | `True` 表示节点存在内存压力 -- 即节点内存用量低，否则为 `False` | -| `PIDPressure` | `True` 表示节点存在进程压力 -- 即进程过多；否则为 `False` | -| `DiskPressure` | `True` 表示节点存在磁盘压力 -- 即磁盘可用量低，否则为 `False` | -| `NetworkUnavailable` | `True` 表示节点网络配置不正确；否则为 `False` | +| `OutOfDisk` | `True` 表示节点的空闲空间不足以用于添加新 Pods, 否则为 `False` | +| `Ready` | 表示节点是健康的并已经准备好接收 Pods；`False` 表示节点不健康而且不能接收 Pods；`Unknown` 表示节点控制器在最近 `node-monitor-grace-period` 期间（默认 40 秒）没有收到节点的消息 | +| `MemoryPressure` | `True` 表示节点存在内存压力，即节点内存可用量低，否则为 `False` | +| `PIDPressure` | `True` 表示节点存在进程压力，即进程过多；否则为 `False` | +| `DiskPressure` | `True` 表示节点存在磁盘压力，即磁盘可用量低，否则为 `False` | +| `NetworkUnavailable` | `True` 表示节点网络配置不正确；否则为 `False` | -节点条件使用一个 JSON 对象表示。例如，下面的响应描述了一个健康的节点。 +节点条件使用 JSON 对象表示。例如，下面的响应描述了一个健康的节点。 ```json "conditions": [ @@ -135,8 +126,12 @@ The node condition is represented as a JSON object. For example, the following r -如果 Ready 条件处于状态 `Unknown` 或者 `False` 的时间超过了 `pod-eviction-timeout`（一个传递给 [kube-controller-manager](/docs/admin/kube-controller-manager/) 的参数），节点上的所有 Pods 都会被节点控制器计划删除。默认的删除超时时长为**5 分钟**。某些情况下，当节点不可访问时，apiserver 不能和其上的 kubelet 通信。删除 pods 的决定不能传达给 kubelet，直到它重新建立和 apiserver 的连接为止。与此同时，被计划删除的 pods 可能会继续在分区节点上运行。 - +如果 Ready 条件处于状态 `Unknown` 或者 `False` 的时间超过了 `pod-eviction-timeout` +（一个传递给 [kube-controller-manager](/docs/admin/kube-controller-manager/) 的参数）， +节点上的所有 Pods 都会被节点控制器计划删除。默认的逐出超时时长为 **5 分钟**。 +某些情况下，当节点不可访问时，apiserver 不能和其上的 kubelet 通信。 +删除 Pods 的决定不能传达给 kubelet，直到它重新建立和 apiserver 的连接为止。 +与此同时，被计划删除的 Pods 可能会继续在游离的节点上运行。 -在 1.5 版本之前的 Kubernetes 里，节点控制器会将不能访问的 pods 从 apiserver 中[强制删除](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods)。但在 1.5 或更高的版本里，在节点控制器确认这些 pods 已经在集群停止运行前不会强制删除它们。你可以看到这些处于 `Terminating` 或者 `Unknown` 状态的 pods 可能在无法访问的节点上运行。为了防止 kubernetes 不能从底层基础设施中推断出一个节点是否已经永久的离开了集群，集群管理员可能需要手动删除这个节点对象。从 Kubernetes 删除节点对象将导致 apiserver 删除节点上所有运行的 Pod 对象并释放它们的名字。 - +在 1.5 版本之前的 Kubernetes 上，节点控制器会将不能访问的 Pods 从 apiserver 中 +[强制删除](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods)。 +但在 1.5 或更高的版本里，在节点控制器确认这些 Pods 在集群中已经停止运行前，不会强制删除它们。 +你可以看到这些可能在无法访问的节点上运行的 Pods 处于 `Terminating` 或者 `Unknown` 状态。 +如果 kubernetes 不能基于下层基础设施推断出某节点是否已经永久离开了集群，集群管理员可能需要手动删除该节点对象。 +从 Kubernetes 删除节点对象将导致 apiserver 删除节点上所有运行的 Pod 对象并释放它们的名字。 节点生命周期控制器会自动创建代表条件的[污点](/docs/concepts/configuration/taint-and-toleration/)。 -当调度器将 Pod 分配给节点时，调度器会考虑节点上的污点，但是 Pod 可以容忍的污点除外。 +当调度器将 Pod 指派给某节点时，调度器会考虑节点上的污点，但是 Pod 可以容忍的污点除外。 -### 容量与可分配 {#capacity} - -描述节点上的可用资源：CPU、内存和可以调度到节点上的 pods 的最大数量。 +### 容量与可分配 {#capacity} + +描述节点上的可用资源：CPU、内存和可以调度到节点上的 Pods 的个数上限。 -可以在学习如何在节点上[保留计算资源](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)的同时阅读有关容量和可分配资源的更多信息。 +可以在学习如何在节点上[保留计算资源](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) +的同时阅读有关容量和可分配资源的更多信息。 -### 信息 - -关于节点的通用信息，例如内核版本、Kubernetes 版本（kubelet 和 kube-proxy 版本）、Docker 版本（如果使用了）和操作系统名称。这些信息由 kubelet 从节点上搜集而来。 + +### 信息 {#info} + +关于节点的通用信息，例如内核版本、Kubernetes 版本（kubelet 和 kube-proxy 版本）、Docker 版本 +（如果使用了）和操作系统名称。这些信息由 kubelet 从节点上搜集而来。 -## 管理 - -与 [pods](/docs/concepts/workloads/pods/pod/) 和 [services](/docs/concepts/services-networking/service/) 不同，节点并不是在 Kubernetes 内部创建的：它是被外部的云服务商创建，例如 Google Compute Engine 或者你的集群中的物理或者虚拟机。这意味着当 Kubernetes 创建一个节点时，它其实仅仅创建了一个对象来代表这个节点。创建以后，Kubernetes 将检查这个节点是否可用。例如，如果你尝试使用如下内容创建一个节点： +## 管理 +与 [Pods](/docs/concepts/workloads/pods/pod/) 和 [Services](/docs/concepts/services-networking/service/) 不同， +节点并不是在 Kubernetes 中从头创建的：它们由外部的云服务商（例如 Google Compute Engine）创建，或者是来自你的资源池 +中的物理机或者虚拟机。 +这意味着当 Kubernetes 创建一个节点时，它其实仅仅创建了一个对象来代表这个节点。 +创建以后，Kubernetes 将检查这个节点是否可用。例如，如果你尝试使用如下内容创建一个节点： ```json { @@ -229,12 +231,19 @@ validates the node by health checking based on the `metadata.name` field. If the services are running -- it is eligible to run a pod. Otherwise, it is ignored for any cluster activity until it becomes valid. --> -Kubernetes 会在内部创一个 Node 对象（用以表示节点），并基于 `metadata.name` 字段执行健康检查，对节点进行验证。如果节点可用，意即所有必要服务都已运行，它就符合了运行一个 pod 的条件；否则它将被所有的集群动作忽略直到变为可用。 +Kubernetes 会在内部创一个 Node 对象（用以表示节点），并基于 `metadata.name` 字段执行健康检查， +如果节点合法，即所有必要服务都处于运行状态，它就有资格运行 Pod；否则它将被所有的集群活动忽略直到其变为合法为止。 + + {{< note >}} - Kubernetes 保留无效节点的对象，并继续检查它是否有效。必须显式删除 Node 对象以停止此过程。 +Kubernetes 保留无效节点所对应的对象，并持续检查它是否合法。 +若要停止这种检查，必须显式删除 Node 对象。 {{< /note >}} -### 节点控制器 - -节点控制器是一个 Kubernetes master 组件，管理节点的方方面面。 - -节点控制器在节点的生命周期中扮演了多个角色。第一个是当节点注册时为它分配一个 CIDR block（如果打开了 CIDR 分配）。 +### 节点控制器 + +节点控制器是一个 Kubernetes 控制面组件，管理节点的方方面面。 + +节点控制器在节点的生命周期中扮演多个角色。第一个是当节点注册时为它分配一个 CIDR 区间（如果启用了 CIDR 分配）。 -第二个是使用云服务商提供了可用节点列表保持节点控制器内部的节点列表更新。如果在云环境下运行，任何时候当一个节点不健康时节点控制器将询问云服务节点的虚拟机是否可用。如果不可用，节点控制器会将这个节点从它的节点列表删除。 +第二个保持节点控制器内部的节点列表与云服务商所提供的可用机器列表同步。 +如果在云环境下运行，当某节点不健康时，节点控制器将询问云服务是否节点的虚拟机可用。 +如果不可用，节点控制器会将该节点从它的节点列表删除。 -第三个是监控节点的健康情况。节点控制器负责在节点不能访问时（也即是节点控制器因为某些原因没有收到心跳，例如节点宕机）将它的 NodeStatus 的 NodeReady 状态更新为 ConditionUnknown。后续如果节点持续不可访问，节点控制器将删除节点上的所有 pods（使用优雅终止）。（默认情况下 40s 开始报告 ConditionUnknown，在那之后 5m 开始删除 pods。）节点控制器每隔 `--node-monitor-period` 秒检查每个节点的状态。 +第三个是监控节点的健康情况。节点控制器负责在节点不可达 +（即，节点控制器因为某些原因没有收到心跳，例如节点宕机）时， +将它的 NodeStatus 的 NodeReady 条件更新为 ConditionUnknown。 +后续如果节点持续不可达，节点控制器将逐出节点上的所有 Pods（使用体面终止）。 +（默认情况下 40s 后开始报告 ConditionUnknown，在那之后 5m 开始逐出 Pods。） +节点控制器每隔 `--node-monitor-period` 秒检查每个节点的状态。 -#### 心跳机制 - +#### 心跳机制 + Kubernetes 节点发送的心跳有助于确定节点的可用性。 心跳有两种形式：`NodeStatus` 和 [`Lease` 对象](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#lease-v1-coordination-k8s-io)。 每个节点在 `kube-node-lease`{{< glossary_tooltip term_id="namespace" text="命名空间">}} 中都有一个关联的 `Lease` 对象。 @@ -316,57 +329,69 @@ kubelet 负责创建和更新 `NodeStatus` 和 `Lease` 对象。 `NodeStatus` updates. --> - 当状态发生变化时，或者在配置的时间间隔内没有更新时，kubelet 会更新 `NodeStatus`。 -`NodeStatus` 更新的默认间隔为 5 分钟（比无法访问的节点的 40 秒默认超时时间长很多）。 + `NodeStatus` 更新的默认间隔为 5 分钟（比不可达节点的 40 秒默认超时时间长很多）。 - kubelet 会每 10 秒（默认更新间隔时间）创建并更新其 `Lease` 对象。`Lease` 更新独立于 `NodeStatus` 更新而发生。 -#### 可靠性 - -在 Kubernetes 1.4 中我们更新了节点控制器逻辑以更好地处理大批量节点访问 master 出问题的情况（例如 master 的网络出了问题）。从 1.4 开始，节点控制器在决定删除 pod 之前会检查集群中所有节点的状态。 +#### 可靠性 + +在 Kubernetes 1.4 中我们更新了节点控制器逻辑以更好地处理大批量节点访问控制面而出问题的情况 +（例如，控制面节点的网络出了问题）。从 1.4 开始，节点控制器在决定逐出 Pod 之前 +会检查集群中所有节点的状态。 -大部分情况下，节点控制器把驱逐频率限制在每秒 `--node-eviction-rate` 个（默认为 0.1）。这表示它每 10 秒钟内至多从一个节点驱逐 Pods。 + +大部分情况下，节点控制器把驱逐速率限制在每秒 `--node-eviction-rate` 个（默认为 0.1）。 +这表示它每 10 秒钟内至多从一个节点驱逐 Pods。 -当一个可用区域中的节点变为不健康时，它的驱逐行为将发生改变。节点控制器会同时检查可用区域中不健康（NodeReady 状态为 ConditionUnknown 或 ConditionFalse）的节点的百分比。如果不健康节点的部分超过 `--unhealthy-zone-threshold` （默认为 0.55），驱逐速率将会减小：如果集群较小（意即小于等于 `--large-cluster-size-threshold` 个 节点 - 默认为 50），驱逐操作将会停止，否则驱逐速率将降为每秒 `--secondary-node-eviction-rate` 个（默认为 0.01）。在单个可用区域实施这些策略的原因是当一个可用区域可能从 master 分区时其它的仍然保持连接。如果你的集群没有跨越云服务商的多个可用区域，那就只有一个可用区域整个集群）。 +当一个可用区域（Availability Zone）中的节点变为不健康时，节点的驱逐行为将发生改变。 +节点控制器会同时检查可用区域中不健康（NodeReady 状态为 ConditionUnknown 或 ConditionFalse） +的节点的百分比。如果不健康节点的比例超过 `--unhealthy-zone-threshold` （默认为 0.55）， +驱逐速率将会降低：如果集群较小（意即小于等于 `--large-cluster-size-threshold` 个节点 - 默认为 50）， +驱逐操作将会停止，否则驱逐速率将降为每秒 `--secondary-node-eviction-rate` 个（默认为 0.01）。 +在单个可用区域实施这些策略的原因是当一个可用区域可能从控制面脱离时其它可用区域可能仍然保持连接。 +如果你的集群没有跨越云服务商的多个可用区域，那（整个集群）就只有一个可用区域。 -在多个可用区域分布你的节点的一个关键原因是当整个可用区域故障时，工作负载可以转移到健康的可用区域。因此，如果一个可用区域中的所有节点都不健康时，节点控制器会以正常的速率 `--node-eviction-rate` 进行驱逐操作。在所有的可用区域都不健康（也即集群中没有健康节点）的极端情况下，节点控制器将假设 master 的连接出了某些问题，它将停止所有驱逐动作直到一些连接恢复。 +跨多个可用区域部署你的节点的一个关键原因是当某个可用区域整体出现故障时，工作负载可以转移到健康的可用区域。 +因此，如果一个可用区域中的所有节点都不健康时，节点控制器会以正常的速率 `--node-eviction-rate` 进行驱逐操作。 +在所有的可用区域都不健康（也即集群中没有健康节点）的极端情况下，节点控制器将假设控制面节点的连接出了某些问题， +它将停止所有驱逐动作直到一些连接恢复。 -从 Kubernetes 1.6 开始，NodeController 还负责驱逐运行在拥有 `NoExecute` 污点的节点上的 pods，如果这些 pods 没有容忍这些污点。此外，作为一个默认禁用的 alpha 特性，NodeController 还负责根据节点故障（例如节点不可访问或没有 ready）添加污点。请查看[这个文档](/docs/concepts/configuration/assign-pod-node/#taints-and-tolerations-beta-feature)了解关于 `NoExecute` 污点和这个 alpha 特性。 - +从 Kubernetes 1.6 开始，NodeController 还负责驱逐运行在拥有 `NoExecute` 污点的节点上的 Pods，如果这些 Pods 没有容忍这些污点。 +此外，作为一个默认禁用的 alpha 特性，NodeController 还负责根据节点故障（例如节点不可访问或没有就绪）为其添加污点。 +请查看[这个文档](/docs/concepts/configuration/assign-pod-node/#taints-and-tolerations-beta-feature)了解 `NoExecute` 污点 +和这个 alpha 特性。 ### 节点自注册 - -当 kubelet 标志 `--register-node` 为 true （默认）时，它会尝试向 API 服务注册自己。这是首选模式，被绝大多数发行版选用。 +当 kubelet 标志 `--register-node` 为 true （默认）时，它会尝试向 API 服务注册自己。 +这是首选模式，被绝大多数发行版选用。 - 对于自注册模式，kubelet 使用下列参数启动： +对于自注册模式，kubelet 使用下列参数启动： - - `--kubeconfig` - 用于向 apiserver 验证自己的凭据路径。 + - `--kubeconfig` - 用于向 apiserver 表明身份的凭据路径。 - `--cloud-provider` - 如何从云服务商读取关于自己的元数据。 - `--register-node` - 自动向 API 服务注册。 - - `--register-with-taints` - 使用 taints 列表（逗号分隔的 `=:`）注册节点。当 `register-node` 为 false 时无效。 + - `--register-with-taints` - 使用污点列表（逗号分隔的 `=:`）注册节点。当 `register-node` 为 false 时无效。 - `--node-ip` - 节点 IP 地址。 - - `--node-labels` - 在集群中注册节点时要添加的标签（请参阅 [NodeRestriction 准入插件](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) 在 1.13+ 中实施的标签限制）。 - - `--node-status-update-frequency` - 指定 kubelet 向 master 发送状态的频率。 + - `--node-labels` - 在集群中注册节点时要添加的标签（请参阅 + [NodeRestriction 准入插件](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) 在 1.13+ 中实施的标签限制）。 + - `--node-status-update-frequency` - 指定 kubelet 向控制面组件发送状态的频率。 -启用[节点授权模式](/docs/reference/access-authn-authz/node/) 和 [NodeRestriction 准入插件](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)时，仅授权小组件创建或修改其自己的节点资源。 +启用[节点授权模式](/docs/reference/access-authn-authz/node/) 和 +[NodeRestriction 准入插件](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)时， +仅授权 kubelet 创建或修改其自己的节点资源。 #### 手动节点管理 - 集群管理员可以创建及修改节点对象。 -如果管理员希望手动创建节点对象，请设置 kubelet 标记 `--register-node=false`。 +如果管理员希望手动创建节点对象，请设置 kubelet 标志 `--register-node=false`。 -管理员可以修改节点资源（忽略 `--register-node` 设置）。修改包括在节点上设置 labels 及标记它为不可调度。 +管理员可以修改节点资源（忽略 `--register-node` 设置）。修改包括在节点上设置标签及 +标记它为不可调度。 -节点上的 labels 可以和 pods 的节点 selectors 一起使用来控制调度，例如限制一个 pod 只能在一个符合要求的节点子集上运行。 +节点上的标签可以和 Pods 的节点选择算符一起使用来控制调度，例如限制某 pod 只能在符合要求的节点子集上运行。 -标记一个节点为不可调度的将防止新建 pods 调度到那个节点之上，但不会影响任何已经在它之上的 pods。这是重启节点等操作之前的一个有用的准备步骤。例如，标记一个节点为不可调度的，执行以下命令： - +如果标记节点为不可调度的（unschedulable），将阻止新 Pods 调度到该节点之上，但不会影响任何已经在其上的 Pods。 +这是重启节点等操作之前的一个有用的准备步骤。例如，要标记一个节点为不可调度的，执行以下命令： ```shell kubectl cordon $NODENAME ``` -{{< note >}} -请注意，被 daemonSet 控制器创建的 pods 将忽略 Kubernetes 调度器，且不会遵照节点上不可调度的属性。这个假设基于守护程序属于节点机器，即使在准备重启而隔离应用的时候。 + +{{< note >}} +请注意，被 DaemonSet 控制器创建的 Pods 将忽略 Kubernetes 调度器，且不会遵照节点上不可调度的属性。 +这个假设基于守护程序属于节点机器，即使在准备重启而隔离应用的时候。 {{< /note >}} -### 节点容量 - -节点的容量（cpu 数量和内存容量）是节点对象的一部分。通常情况下，在创建节点对象时，它们会注册自己并报告自己的容量。如果你正在执行[手动节点管理](#manual-node-administration)，那么你需要在添加节点时手动设置节点容量。 +### 节点容量 + +节点的容量（cpu 数量和内存容量）是节点对象的一部分。 +通常情况下，在创建节点对象时，它们会注册自己并报告自己的容量。 +如果你正在执行[手动节点管理](#manual-node-administration)，那么你需要在添加节点时手动设置节点容量。 -Kubernetes 调度器保证一个节点上有足够的资源供其上的所有 pods 使用。它会检查节点上所有容器要求的总和不会超过节点的容量。这包括由 kubelet 启动的所有容器，但不包括由 [container runtime](/docs/concepts/overview/components/#node-components) 直接启动的容器，也不包括在容器外部运行的任何进程。 +Kubernetes 调度器保证一个节点上有足够的资源供其上的所有 Pods 使用。 +它会检查节点上所有容器的请求的总和不会超过节点的容量。 +这包括由 kubelet 启动的所有容器，但不包括由[容器运行时](/docs/concepts/overview/components/#node-components) +直接启动的容器，也不包括在容器外部运行的任何进程。 -如果要为非 Pod 进程显式保留资源。请按照本教程[为系统守护程序保留资源](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved)。 +如果要为非 Pod 进程显式保留资源。请参考[为系统守护程序保留资源](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved)教程。 -如果启用了 `TopologyManager` [功能开关](/docs/reference/command-line-tools-reference/feature-gates/)，则 kubelet 可以在做出资源分配决策时使用拓扑提示。 +如果启用了 `TopologyManager` [特性门控](/docs/reference/command-line-tools-reference/feature-gates/)， +则 kubelet 可以在做出资源分配决策时使用拓扑提示。 -## API 对象 - -节点是 Kubernetes REST API 的顶级资源。更多关于 API 对象的细节可以在这里找到：[节点 API 对象](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core)。 +## API 对象 +节点是 Kubernetes REST API 的顶级资源。 +更多关于 API 对象的细节可以在这里找到：[节点 API 对象](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core)。 ## {{% heading "whatsnext" %}} @@ -534,6 +570,6 @@ API object can be found at: * Read about [node components](https://kubernetes.io/docs/concepts/overview/components/#node-components) * Read about node-level topology: [Control Topology Management Policies on a node](/docs/tasks/administer-cluster/topology-manager/) --> -* 了解有关[节点组件](https://kubernetes.io/docs/concepts/overview/components/#node-components)的信息。 +* 了解有关[节点组件](/docs/concepts/overview/components/#node-components)的信息。 * 阅读有关节点级拓扑的信息：[控制节点上的拓扑管理策略](/docs/tasks/administer-cluster/topology-manager/)。 From 872ed87f1c2ac0a6864399ef7e9b434008aad559 Mon Sep 17 00:00:00 2001 From: Alexios Polyzos Date: Sat, 20 Jun 2020 10:47:29 +0300 Subject: [PATCH 080/218] Minor typo fix on Services Networking Host Aliases Signed-off-by: Alexios Polyzos --- .../add-entries-to-pod-etc-hosts-with-host-aliases.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md b/content/en/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md index d4218f38f6..4e40307401 100644 --- a/content/en/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md +++ b/content/en/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md @@ -71,7 +71,7 @@ For example: to resolve `foo.local`, `bar.local` to `127.0.0.1` and `foo.remote` {{< codenew file="service/networking/hostaliases-pod.yaml" >}} -Yoyu can start a Pod with that configuration by running: +You can start a Pod with that configuration by running: ```shell kubectl apply -f https://k8s.io/examples/service/networking/hostaliases-pod.yaml From c66b8d4290d648f194a96d178be2db2c8230feec Mon Sep 17 00:00:00 2001 From: June Yi Date: Sat, 20 Jun 2020 23:55:45 +0900 Subject: [PATCH 081/218] Add sitemap for Korean contents --- content/ko/docs/sitemap.md | 114 +++++++++++++++++++++++++++++++++++++ 1 file changed, 114 insertions(+) create mode 100644 content/ko/docs/sitemap.md diff --git a/content/ko/docs/sitemap.md b/content/ko/docs/sitemap.md new file mode 100644 index 0000000000..c0a8e6c299 --- /dev/null +++ b/content/ko/docs/sitemap.md @@ -0,0 +1,114 @@ +--- +--- + + + +필터하려면 태그를 클릭하거나 드롭 다운을 사용하세요. 정순 또는 역순으로 정렬하려면 테이블 헤더를 클릭하세요. + +

+개념으로 필터:
+오브젝트로 필터:
+커맨드로 필터: +

+ +
From 045e81dd8c7d7d83a22f0061b805f0baae728c36 Mon Sep 17 00:00:00 2001 From: Gede Wahyu Date: Wed, 8 Apr 2020 00:40:47 +0700 Subject: [PATCH 082/218] ID translation for pod topology spread constraints --- .../pods/pod-topology-spread-constraints.md | 290 ++++++++++++++++++ .../one-constraint-with-nodeaffinity.yaml | 26 ++ .../one-constraint.yaml | 17 + .../two-constraints.yaml | 23 ++ 4 files changed, 356 insertions(+) create mode 100644 content/id/docs/concepts/workloads/pods/pod-topology-spread-constraints.md create mode 100644 content/id/examples/pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml create mode 100644 content/id/examples/pods/topology-spread-constraints/one-constraint.yaml create mode 100644 content/id/examples/pods/topology-spread-constraints/two-constraints.yaml diff --git a/content/id/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/id/docs/concepts/workloads/pods/pod-topology-spread-constraints.md new file mode 100644 index 0000000000..e723edee9c --- /dev/null +++ b/content/id/docs/concepts/workloads/pods/pod-topology-spread-constraints.md @@ -0,0 +1,290 @@ +--- +title: Batasan Persebaran Topologi Pod +content_template: templates/concept +weight: 50 +--- + +{{% capture overview %}} + +{{< feature-state for_k8s_version="v1.18" state="beta" >}} + +Kamu dapat menggunakan batasan perseberan topologi (_topology spread constraints_) +untuk mengatur bagaimana {{< glossary_tooltip text="Pod" term_id="Pod" >}} akan disebarkan +pada klaster yang ditetapkan sebagai _failure-domains_, seperti wilayah, zona, Node dan domain +topologi yang ditentukan oleh pengguna. Ini akan membantu untuk mencapai ketersediaan yang tinggi +dan juga penggunaan sumber daya yang efisien. + +{{% /capture %}} + +{{% capture body %}} + +## Persyaratan + +### Mengaktifkan Gerbang Fitur + +[Gerbang fitur (_feature gate_)](/docs/reference/command-line-tools-reference/feature-gates/) +`EvenPodsSpread` harus diaktifkan untuk +{{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}} **dan** +{{< glossary_tooltip text="penjadwal (_scheduler_)" term_id="kube-scheduler" >}}. + +### Label Node + +Batasan persebaran topologi bergantung dengan label pada Node untuk menentukan +domain topologi yang memenuhi untuk semua Node. Misalnya saja, sebuah Node bisa memiliki +label sebagai berikut: `node=node1,zone=us-east-1a,region=us-east-1` + +Misalkan kamu memiliki klaster dengan 4 Node dengan label sebagai berikut: + +``` +NAME STATUS ROLES AGE VERSION LABELS +node1 Ready 4m26s v1.16.0 node=node1,zone=zoneA +node2 Ready 3m58s v1.16.0 node=node2,zone=zoneA +node3 Ready 3m17s v1.16.0 node=node3,zone=zoneB +node4 Ready 2m43s v1.16.0 node=node4,zone=zoneB +``` + +Maka klaster tersebut secara logika akan dilihat sebagai berikut: + +``` ++---------------+---------------+ +| zoneA | zoneB | ++-------+-------+-------+-------+ +| node1 | node2 | node3 | node4 | ++-------+-------+-------+-------+ +``` + +Tanpa harus memberi label secara manual, kamu dapat menggunakan [label ternama] +(/docs/reference/kubernetes-api/labels-annotations-taints/) yang terbuat dan terkumpulkan +secara otomatis pada kebanyakan klaster. + +## Batasan Persebaran untuk Pod + +### API + +_Field_ `pod.spec.topologySpreadConstraints` diperkenalkan pada versi 1.16 sebagai berikut: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + topologySpreadConstraints: + - maxSkew: + topologyKey: + whenUnsatisfiable: + labelSelector: +``` + +Kamu dapat mendefinisikan satu atau lebih `topologySpreadConstraint` untuk menginstruksikan +kube-scheduler mengenai cara peletakan tiap Pod baru dengan menggunakan kondisi Pod yang +sudah ada dalam klaster kamu. _Field_ yang ada adalah: + +- **maxSkew** menentukan batasan yang menandakan Pod tidak tersebar secara merata. +Ini merupakan nilai maksimal dari selisih jumlah Pod yang sama untuk setiap 2 domain topologi +yang sama. Nilai ini harus lebih dari 0. +- **topologyKey** adalah kunci dari label Node. Jika terdapat dua Node memiliki label dengan +kunci ini dan memiliki nilai yang identik untuk label tersebut, maka penjadwal akan menganggap +kedua Noode dalam topologi yang sama. Penjadwal akan mencoba untuk menyeimbangkan jumlah Pod +dalam setiap domain topologi. +- **whenUnsatisfiable** mengindikasikan cara menangani Pod yang tidak memenuhi batasan persebaran: + - `DoNotSchedule` (_default_) memberitahukan penjadwal untuk tidak menjadwalkan Pod tersebut. + - `ScheduleAnyway` memberitahukan penjadwal untuk tetap menjadwalkan Pod namun tetap menjaga ketidakseimbangan Node sekecil mungkin. +- **labelSelector** digunakan untuk mencari Pod yang sesuai. Pod dengan label yang sama dengan ini akan dihitung untuk menentukan jumlah Pod dalam domain topologi yang sesuai. Silakan baca [Label dan Selector](/id/docs/concepts/overview/working-with-objects/labels/#selektor-label) untuk lebih detailnya. + +Kamu juga bisa membaca lebih detail mengenai _field_ ini dengan menjalankan perintah +`kubectl explain Pod.spec.topologySpreadConstraints`. + +### Contoh: Satu TopologySpreadConstraint + +Misalkan kamu memiliki klaster dengan 4 Node dimana 3 Pod berlabel `foo:bar` terdapat pada node1, +node2 dan node3 (`P` merepresentasikan Pod): + +``` ++---------------+---------------+ +| zoneA | zoneB | ++-------+-------+-------+-------+ +| node1 | node2 | node3 | node4 | ++-------+-------+-------+-------+ +| P | P | P | | ++-------+-------+-------+-------+ +``` + +Jika kita ingin Pod baru akan disebar secara merata berdasarkan Pod yang telah ada pada semua zona, +maka _spec_ bernilai sebagai berikut: + +{{< codenew file="pods/topology-spread-constraints/one-constraint.yaml" >}} + +`topologyKey: zone` berarti persebaran merata hanya akan digunakan pada Node dengan pasangan label +"zone: ". `whenUnsatisfiable: DoNotSchedule` memberitahukan penjadwal untuk membiarkan +tetap ditunda jika Pod yang baru tidak memenuhi batasan yang diterapkan. + +Jika penjadwal menempatkan Pod baru pada "zoneA", persebaran Pod akan menjadi [3, 1], menjadikan +ketidakseimbangan menjadi bernilai 2 (3 - 1), yang mana akan melanggar batasan `maxSkew: 1`. +Dalam contoh ini, Pod baru hanya dapat ditempatkan pada "zoneB": + +``` ++---------------+---------------+ +---------------+---------------+ +| zoneA | zoneB | | zoneA | zoneB | ++-------+-------+-------+-------+ +-------+-------+-------+-------+ +| node1 | node2 | node3 | node4 | OR | node1 | node2 | node3 | node4 | ++-------+-------+-------+-------+ +-------+-------+-------+-------+ +| P | P | P | P | | P | P | P P | | ++-------+-------+-------+-------+ +-------+-------+-------+-------+ +``` + +Kamu dapat mengatur spesifikasi Pod untuk memenuhi beberapa persyaratan berikut: + +- Ubah nilai `maxSkew` menjadi lebih besar, misal "2", sehingga Pod baru dapat ditempatkan pada "zoneA". +- Ubah nilai `topologyKey` menjadi "node" agar Pod disebarkan secara merata pada semua Node, bukan zona. Pada contoh di atas, jika `maxSkew` tetap bernilai "1", maka Pod baru hanya akan ditempatkan pada "node4". +- Ubah nilai `whenUnsatisfiable: DoNotSchedule` menjadi `whenUnsatisfiable: ScheduleAnyway` untuk +menjamin agar semua Pod baru akan tetap dijadwalkan (misalkan saja API penjadwalan lain tetap +terpenuhi). Namun, ini lebih suka ditempatkan pada domain topologi yang memiliki lebih sedikit +Pod yang sesuai. (Harap diperhatikan bahwa preferensi ini digabungkan bersama dengan prioritas +penjadwalan internal yang lain, seperti rasio penggunaan sumber daya, dan lain sebagainya.) + +### Contoh: Beberapa TopologySpreadConstraint + +Ini dibuat berdasarkan contoh sebelumnya. Misalkan kamu memiliki klaster dengan 4 Node dengan +3 Pod berlabel `foo:bar` yang ditempatkan pada node1, node2 dan node3. (`P` merepresentasikan Pod): + +``` ++---------------+---------------+ +| zoneA | zoneB | ++-------+-------+-------+-------+ +| node1 | node2 | node3 | node4 | ++-------+-------+-------+-------+ +| P | P | P | | ++-------+-------+-------+-------+ +``` + +Kamu dapat menggunakan 2 TopologySpreadConstraint untuk mengatur persebaran Pod pada zona dan Node: + +{{< codenew file="pods/topology-spread-constraints/two-constraints.yaml" >}} + +Dalam contoh ini, untuk memenuhi batasan pertama, Pod yang baru hanya akan ditempatkan pada "zoneB", +sedangkan untuk batasan kedua, Pod yang baru hanya akan ditempatkan pada "node4". Maka hasil dari +2 batasan ini akan digunakan (_AND_), sehingga opsi untuk menempatkan Pod hanya pada "node4". + +Beberapa batasan dapat berujung pada konflik. Misalnya saja kamu memiliki klaster dengan 3 Node +pada 2 zona berbeda: + +``` ++---------------+-------+ +| zoneA | zoneB | ++-------+-------+-------+ +| node1 | node2 | node3 | ++-------+-------+-------+ +| P P | P | P P | ++-------+-------+-------+ +``` + +Jika kamu menerapkan "two-constraints.yaml" pada klaster ini, kamu akan mendapatkan "mypod" tetap +dalam kondisi `Pending`. Ini dikarenakan oleh: untuk memenuhi batasan pertama, "mypod" hanya dapat +ditempatkan pada "zoneB", sedangkan untuk batasan kedua, "mypod" hanya dapat ditempatkan pada +"node2". Tidak ada hasil penggabungan dari "zoneB" dan "node2". + +Untuk mengatasi situasi ini, kamu bisa menambahkan nilai `maxSkew` atau mengubah salah satu dari +batasan untuk menggunakan `whenUnsatisfiable: ScheduleAnyway`. + +### Konvensi + +Ada beberapa konvensi implisit yang perlu diperhatikan di sini: + +- Hanya Pod dengan Namespace yang sama dengan Pod baru yang bisa menjadi kandidat yang cocok. + +- Node tanpa memiliki `topologySpreadConstraints[*].topologyKey` akan dilewatkan. Ini berarti: + 1. Pod yang ditempatkan pada Node tersebut tidak berpengaruh pada perhitungan `maxSkew`. Dalam contoh di atas, misalkan "node1" tidak memiliki label "zone", maka kedua Pod tidak diperhitungkan dan menyebabkan Pod yang baru akan dijadwalkan masuk ke "zoneA". + 2. Pod yang baru tidak memiliki kesempatan untuk dijadwalkan ke Node tersebut, pada contoh di atas, misalkan terdapat "node5" dengan label `{zone-typo: zoneC}` bergabung dalam klaster, Node ini akan dilewatkan karena tidak memiliki label dengan kunci "zone". + +- Harap diperhatikan mengenai hal yang terjadi jika nilai `topologySpreadConstraints[*].labelSelector` pada Pod yang baru tidak sesuai dengan labelnya. +Pada contoh di atas, jika kita menghapus label pada Pod yang baru, maka Pod akan tetap ditempatkan +pada "zoneB" karena batasan yang ada masih terpenuhi. Namun, setelah ditempatkan, nilai +ketidakseimbangan pada klaster masih tetap tidak berubah, zoneA tetap memiliki 2 Pod dengan label +{foo:bar} dan zoneB memiliki 1 Pod dengan label {foo:bar}. Jadi jika ini tidak yang kamu harapkan, +kami menyarankan nilai dari `topologySpreadConstraints[*].labelSelector` disamakan dengan labelnya. + +- Jika Pod yang baru memiliki `spec.nodeSelector` atau `spec.affinity.nodeAffinity`, Node yang tidak +sesuai dengan nilai tersebut akan dilewatkan. + + Misalkan kamu memiliki klaster dengan 5 Node dari zoneA sampai zoneC: + + ``` + +---------------+---------------+-------+ + | zoneA | zoneB | zoneC | + +-------+-------+-------+-------+-------+ + | node1 | node2 | node3 | node4 | node5 | + +-------+-------+-------+-------+-------+ + | P | P | P | | | + +-------+-------+-------+-------+-------+ + ``` + + dan kamu mengetahui bahwa "zoneC" harus tidak diperhitungkan. Dalam kasus ini, kamu dapat membuat + berkas yaml seperti di bawah, jadi "mypod" akan ditempatkan pada "zoneB", bukan "zoneC". + Demikian juga `spec.nodeSelector` akan digunakan. + + {{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}} + +### Batasan _default_ pada tingkat klaster + +{{< feature-state for_k8s_version="v1.18" state="alpha" >}} + +Ini memungkinkan untuk mengatur batasan persebaran topologi bawaan untuk klaster. +Batasan persebaran topologi bawaan akan digunakan pada Pod jika dan hanya jika: + +- Hal ini tidak mendefinisikan batasan apapun pada `.spec.topologySpreadConstraints`. +- Hal ini milik sebuah Service, ReplicationController, ReplicaSet atau StatefulSet. + +Batasan bawaan akan diatur sebagai bagian dari argumen pada _plugin_ `PodTopologySpread` +di dalam sebuah [profil penjadwalan](/docs/reference/scheduling/profiles). +Batasan dispesifikasikan dengan [API yang sama dengan di atas](#api), kecuali bagian `labelSelector` +harus kosong. _selector_ akan dihitung dari Service, ReplicationController, ReplicaSet atau +StatefulSet yang dimiliki oleh Pod tersebut. + +Sebuah contoh konfigurasi sebagai berikut: + + +```yaml +apiVersion: kubescheduler.config.k8s.io/v1alpha2 +kind: KubeSchedulerConfiguration + +profiles: + pluginConfig: + - name: PodTopologySpread + args: + defaultConstraints: + - maxSkew: 1 + topologyKey: failure-domain.beta.kubernetes.io/zone + whenUnsatisfiable: ScheduleAnyway +``` + +{{< note >}} +Nilai yang dihasilkan oleh batasan penjadwalan bawaan mungkin akan konflik dengan +nilai yang dihasilkan oleh +[`DefaultPodTopologySpread` plugin](/docs/reference/scheduling/profiles/#scheduling-plugins). +Direkomendasikan untuk kamu menonaktifkan _plugin_ ini dalam profil penjadwalan ketika +menggunakan batasan _default_ untuk `PodTopologySpread`. +{{< /note >}} + +## Perbandingan dengan PodAffinity/PodAntiAffinity + +Di Kubernetes, arahan yang terkait dengan "Afinitas" mengontrol bagaimana Pod dijadwalkan - +lebih terkumpul atau lebih tersebar. + +- Untuk `PodAffinity`, kamu dapat mencoba mengumpulkan beberapa Pod ke dalam suatu +domain topologi yang memenuhi syarat. +- Untuk `PodAntiAffinity`, hanya satu Pod yang dalam dijadwalkan pada sebuah domain topologi. + +Fitur "EvenPodsSpread" memberikan opsi fleksibilas untuk mendistribusikan Pod secara merata +pada domain topologi yang berbeda, untuk meraih ketersediaan yang tinggi atau menghemat biaya. +Ini juga dapat membantu saat perbaruan bergilir dan menaikan jumlah replika dengan lancar. +Silakan baca [motivasi](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20190221-even-pods-spreading.md#motivation) untuk lebih detail. + +## Limitasi yang diketahui + +Pada versi 1.18, dimana fitur ini masih Beta, beberapa limitasi yang sudah diketahui: + +- Pengurangan jumlah Deployment akan membuat ketidakseimbangan pada persebaran Pod. +- Pod yang cocok pada _tainted_ Node akan dihargai. Lihat [Issue 80921](https://github.com/kubernetes/kubernetes/issues/80921) + +{{% /capture %}} diff --git a/content/id/examples/pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml b/content/id/examples/pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml new file mode 100644 index 0000000000..98823f9d86 --- /dev/null +++ b/content/id/examples/pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml @@ -0,0 +1,26 @@ +kind: Pod +apiVersion: v1 +metadata: + name: mypod + labels: + foo: bar +spec: + topologySpreadConstraints: + - maxSkew: 1 + topologyKey: zone + whenUnsatisfiable: DoNotSchedule + labelSelector: + matchLabels: + foo: bar + affinity: + nodeAffinity: + requiredDuringSchedulingIgnoredDuringExecution: + nodeSelectorTerms: + - matchExpressions: + - key: zone + operator: NotIn + values: + - zoneC + containers: + - name: pause + image: k8s.gcr.io/pause:3.1 \ No newline at end of file diff --git a/content/id/examples/pods/topology-spread-constraints/one-constraint.yaml b/content/id/examples/pods/topology-spread-constraints/one-constraint.yaml new file mode 100644 index 0000000000..a0a41188ec --- /dev/null +++ b/content/id/examples/pods/topology-spread-constraints/one-constraint.yaml @@ -0,0 +1,17 @@ +kind: Pod +apiVersion: v1 +metadata: + name: mypod + labels: + foo: bar +spec: + topologySpreadConstraints: + - maxSkew: 1 + topologyKey: zone + whenUnsatisfiable: DoNotSchedule + labelSelector: + matchLabels: + foo: bar + containers: + - name: pause + image: k8s.gcr.io/pause:3.1 \ No newline at end of file diff --git a/content/id/examples/pods/topology-spread-constraints/two-constraints.yaml b/content/id/examples/pods/topology-spread-constraints/two-constraints.yaml new file mode 100644 index 0000000000..aa142b7abb --- /dev/null +++ b/content/id/examples/pods/topology-spread-constraints/two-constraints.yaml @@ -0,0 +1,23 @@ +kind: Pod +apiVersion: v1 +metadata: + name: mypod + labels: + foo: bar +spec: + topologySpreadConstraints: + - maxSkew: 1 + topologyKey: zone + whenUnsatisfiable: DoNotSchedule + labelSelector: + matchLabels: + foo: bar + - maxSkew: 1 + topologyKey: node + whenUnsatisfiable: DoNotSchedule + labelSelector: + matchLabels: + foo: bar + containers: + - name: pause + image: k8s.gcr.io/pause:3.1 \ No newline at end of file From 966215f88a260378787538896e96fd17038adc0f Mon Sep 17 00:00:00 2001 From: Luke Wendling <12628+lukewendling@users.noreply.github.com> Date: Sat, 20 Jun 2020 12:45:12 -0500 Subject: [PATCH 083/218] Correct wordpress service command output per the instructions, the wordpress service is a LoadBalancer. --- .../stateful-application/mysql-wordpress-persistent-volume.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/en/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md b/content/en/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md index d43d9b736f..d22d7df5ca 100644 --- a/content/en/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md +++ b/content/en/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md @@ -190,8 +190,8 @@ Now you can verify that all objects exist. The response should be like this: ``` - NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE - wordpress ClusterIP 10.0.0.89 80:32406/TCP 4m + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + wordpress LoadBalancer 10.0.0.89 80:32406/TCP 4m ``` {{< note >}} From 03092eed1c5816e5c198d7fb5eb37175ac7d8326 Mon Sep 17 00:00:00 2001 From: Weiping Cai Date: Sun, 21 Jun 2020 12:58:43 +0800 Subject: [PATCH 084/218] remove unnecessary note Signed-off-by: Weiping Cai --- content/en/docs/concepts/workloads/controllers/job.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/content/en/docs/concepts/workloads/controllers/job.md b/content/en/docs/concepts/workloads/controllers/job.md index 45fa66bd3d..a55759c300 100644 --- a/content/en/docs/concepts/workloads/controllers/job.md +++ b/content/en/docs/concepts/workloads/controllers/job.md @@ -218,9 +218,6 @@ exponential back-off delay (10s, 20s, 40s ...) capped at six minutes. The back-off count is reset if no new failed Pods appear before the Job's next status check. -{{< note >}} -Issue [#54870](https://github.com/kubernetes/kubernetes/issues/54870) still exists for versions of Kubernetes prior to version 1.12 -{{< /note >}} {{< note >}} If your job has `restartPolicy = "OnFailure"`, keep in mind that your container running the Job will be terminated once the job backoff limit has been reached. This can make debugging the Job's executable more difficult. We suggest setting From cc63c1dbd54fd1b14c38c727848dd7ee2f87d320 Mon Sep 17 00:00:00 2001 From: Dery Rahman Ahaddienata Date: Mon, 1 Jun 2020 22:15:53 +0700 Subject: [PATCH 085/218] Translate create external load balancer to ID --- .../create-external-load-balancer.md | 196 ++++++++++++++++++ 1 file changed, 196 insertions(+) create mode 100644 content/id/docs/tasks/access-application-cluster/create-external-load-balancer.md diff --git a/content/id/docs/tasks/access-application-cluster/create-external-load-balancer.md b/content/id/docs/tasks/access-application-cluster/create-external-load-balancer.md new file mode 100644 index 0000000000..dfc42d93c5 --- /dev/null +++ b/content/id/docs/tasks/access-application-cluster/create-external-load-balancer.md @@ -0,0 +1,196 @@ +--- +title: Membuat Load Balancer Eksternal +content_template: templates/task +weight: 80 +--- + + +{{% capture overview %}} + +Halaman ini menjelaskan bagaimana membuat _Load Balancer_ Eksternal. + +{{< note >}} +Fitur ini hanya tersedia untuk penyedia _cloud_ atau lingkungan yang mendukung _load balancer_ eksternal. +{{< /note >}} + +Ketika membuat servis, kamu mempunyai opsi untuk membuat jaringan _cloud load balancer_ secara otomatis. +Hal ini menyediakan akses eksternal alamat IP yang dapat mengirim lalu lintas melalui porta yang tepat pada klaster _node_ kamu +_asalkan klaster kamu beroperasi pada lingkungan yang mendukung dan terkonfigurasi dengan paket penyedia cloud load balancer yang benar_. + +Untuk informasi mengenai penyediaan dan penggunaan sumber daya _Ingress_ yang dapat memberikan +servis URL yang dapat dijangkau secara eksternal, penyeimbang beban lalu lintas, terminasi SSL, dll., +silahkan cek dokumentasi [_Ingress_](/docs/concepts/services-networking/ingress/) + +{{% /capture %}} + +{{% capture prerequisites %}} + +* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +{{% /capture %}} + +{{% capture steps %}} + +## Berkas konfigurasi + +Untuk membuat _load balancer_ eksternal, tambahkan baris dibawah ini ke +[berkas konfigurasi servis](/docs/concepts/services-networking/service/#loadbalancer) kamu: + +```yaml + type: LoadBalancer +``` + +Berkas konfigurasi kamu mungkin terlihat seperti ini: + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: example-service +spec: + selector: + app: example + ports: + - port: 8765 + targetPort: 9376 + type: LoadBalancer +``` + +## Menggunakan kubectl + +Kamu dapat membuat servis dengan perintah `kubectl expose` dan +_flag_ `--type=LoadBalancer`: + +```bash +kubectl expose rc example --port=8765 --target-port=9376 \ + --name=example-service --type=LoadBalancer +``` + +Perintah ini membuat servis baru dengan menggunakan pemilih yang sama dengan +sumber daya yang dirujuk (dalam hal contoh diatas, pengendali replikasi bernama `example`). + +Untuk informasi lebih lanjut, termasuk opsi _flag_, mengacu kepada +[referensi `kubectl expose`](/docs/reference/generated/kubectl/kubectl-commands/#expose). + +## Menemukan alamat IP kamu + +Kamu dapat menemukan alamat IP yang telah dibuat untuk servis kamu dengan mendapatkan +informasi servis melalui `kubectl`: + +```bash +kubectl describe services example-service +``` + +yang seharusnya menghasilkan keluaran seperti ini: + +```bash + Name: example-service + Namespace: default + Labels: + Annotations: + Selector: app=example + Type: LoadBalancer + IP: 10.67.252.103 + LoadBalancer Ingress: 192.0.2.89 + Port: 80/TCP + NodePort: 32445/TCP + Endpoints: 10.64.0.4:80,10.64.1.5:80,10.64.2.4:80 + Session Affinity: None + Events: +``` + +Alamat IP tercantum di sebelah `LoadBalancer Ingress`. + +{{< note >}} +Juka kamu menjalankan servis dari Minikube, kamu dapat menemukan alamat IP dan porta yang ditetapkan dengan: +{{< /note >}} + +```bash +minikube service example-service --url +``` + +## Preservasi IP sumber klien + +Dikarenakan implementasi fitur ini, sumber IP yang terlihat pada _container_ +target *bukan sebagai sumber IP asli* dari klien. Untuk mengaktifkan +preservasi IP klien, bidang berikut dapat dikonfigurasikan didalam +spek servis (mendukung lingkungan GCE/Google Kubernetes Engine): + +* `service.spec.externalTrafficPolicy` - menunjukan jika Service menginginkan untuk merute lalu lintas +eksternal ke titik akhir _node-local_ atau _cluster-wide_. Terdapat dua opsi yang tersedia: +Cluster (_default_) dan Local. Cluster mengaburkan sumber IP klien dan mungkin menyebabkan +hop kedua ke _node_ berbeda, namun harus mempunyai _load-spreading_ yang baik secara keseluruhan. +Local mempreservasi sumber IP client dan menghindari hop kedua _LoadBalancer_ dan servis tipe _NodePort_, namun +resiko berpotensi penyebaran lalu lintas yang tidak merata. +* `service.spec.healthCheckNodePort` - menentukan cek kesehatan _node_ porta (nomor porta numerik) untuk servis. +Jika `healthCheckNodePort` tidak ditentukan, pengendali servis mengalokasi +porta dari bentangan _NodePort_ dari klaster kamu. Kamu dapat mengonfigurasi +bentangan tersebut dari pengaturan opsi barisan perintah API server, +`--service-node-port-range`. Hal itu menggunakan nilai `healthCheckNodePort` pengguna spesifik +jika ditentukan oleh klien. Hal itu dapat berefek hanya ketika `type` diset ke _LoadBalancer_ dan +`externalTrafficPolicy` diset ke Local. + +Pengaturan `externalTrafficPolicy` ke Local pada berkas konfigurasi Service mengaktifkan +fitur ini. + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: example-service +spec: + selector: + app: example + ports: + - port: 8765 + targetPort: 9376 + externalTrafficPolicy: Local + type: LoadBalancer +``` + +## Pengumpul Sampah Load Balancers + +{{< feature-state for_k8s_version="v1.17" state="stable" >}} + +Pada kasus biasa, sumber daya _load balancer_ yang berkorelasi pada penyedia _cloud_ perlu +dibersihkan segera setelah Service bertipe _LoadBalancer_ dihapus. Namun perlu diketahui +bahwa terdapat kasus tepi dimana sumber daya _cloud_ yatim piatu (_orphaned_) setelah +Service yang berkaitan dihapus. _Finalizer Protection_ untuk Service _LoadBalancer_ +diperkenalkan untuk mencegah hal ini terjadi. Dengan menggunakan _finalizers_, sebuah sumber daya Service +tidak akan pernah dihapus hingga sumber daya _load balancer_ yang berkorelasi juga dihapus. + +Secara khusus, jika Service mempunyai `type` _LoadBalancer_, pengendali servis akan melekatkan +_finalizer_ bernama `service.kubernetes.io/load-balancer-cleanup`. +_Finalizer_ hanya akan dihapus setelah sumber daya _load balancer_ dibersihkan. +Hal ini mencegah sumber daya _load balancer_ yang teruntai bahkan setelah kasus tepi seperti +pengendali servis berhenti. + +## Penyedia Load Balancer Eksternal + +Penting untuk dicatat bahwa jalur data untuk fungsionalitas ini disediakan oleh _load balancer_ eksternal ke klaster Kubernetes. + +Ketika Service `type` diset `LoadBalancer`, Kubernetes menediakan fungsionalitas yang ekuivalen dengan `type` sebanding ClusterIP +ke _pods_ dalam klaster dan mengekstensinya dengan pemrograman (eksternal ke Kubernetes) _load balancer_ dengan entri pada pods +Kubernetes. Pengendali servis Kubernetes mengotomasi pembuatan _load balancer_ eksternal, cek kesehatan (jika dibutuhkan), +dinding api (jika dibutuhkan), dan mengambil IP eksternal yang dialokasikan oleh penyedia _cloud_ dan mengisinya pada objek servis. + +## Peringatan dan and Limitasi ketika preservasi sumber IP + +_Load balancers_ GCE/AWS tidak menyediakan bobot pada kolam targetnya. Hal ini bukan merupakan isu dengan aturan kube-proxy +LB lama yang akan menyeimbangkan semua titik akhir dengan benar. + +Dengan fungsionalitas yang baru, lalu lintas eksternal tidak menyeimbangkan beban secara merata pada seluruh pods, namun +sebaliknya menyeimbangkan secara merata pada level _node_ (karena GCE/AWS dan implementasi LB eksternal lainnya tidak mempunyai +kemampuan untuk menentukan bobot setiap _node_, mereka menyeimbangkan secara merata pada semua _node_ target, mengabaikan jumlah +_pods_ pada tiap _node_). + + +Namun demikian, kita dapat menyatakan bahwa NumServicePods << NumNodes or NumServicePods >> NumNodes, distribusi yang cukup mendekati +sama akan terlihat, meski tanpa bobot. + +Sekali _load balancers_ eksternal menyediakan bobot, fungsionalitas ini dapat ditambahkan pada jalur pemrograman LB. +*Pekerjaan Masa Depan: Tidak adanya dukungan untuk bobot yang disediakan untuk rilis 1.4, namun dapat ditambahkan di masa mendatang* + +_Pod_ internal ke lalu lintas _pod_ harus berperilaku sama seperti servis ClusterIP, dengan probabilitas yang sama pada seluruh _pods_. + +{{% /capture %}} From 959f1a39ace3137d8576fafbec41ac04f733faee Mon Sep 17 00:00:00 2001 From: Dery Rahman Ahaddienata Date: Mon, 1 Jun 2020 22:26:45 +0700 Subject: [PATCH 086/218] bentangan -> rentang --- .../create-external-load-balancer.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/id/docs/tasks/access-application-cluster/create-external-load-balancer.md b/content/id/docs/tasks/access-application-cluster/create-external-load-balancer.md index dfc42d93c5..68ab08c225 100644 --- a/content/id/docs/tasks/access-application-cluster/create-external-load-balancer.md +++ b/content/id/docs/tasks/access-application-cluster/create-external-load-balancer.md @@ -124,8 +124,8 @@ Local mempreservasi sumber IP client dan menghindari hop kedua _LoadBalancer_ da resiko berpotensi penyebaran lalu lintas yang tidak merata. * `service.spec.healthCheckNodePort` - menentukan cek kesehatan _node_ porta (nomor porta numerik) untuk servis. Jika `healthCheckNodePort` tidak ditentukan, pengendali servis mengalokasi -porta dari bentangan _NodePort_ dari klaster kamu. Kamu dapat mengonfigurasi -bentangan tersebut dari pengaturan opsi barisan perintah API server, +porta dari rentang _NodePort_ dari klaster kamu. Kamu dapat mengonfigurasi +rentangan tersebut dari pengaturan opsi barisan perintah API server, `--service-node-port-range`. Hal itu menggunakan nilai `healthCheckNodePort` pengguna spesifik jika ditentukan oleh klien. Hal itu dapat berefek hanya ketika `type` diset ke _LoadBalancer_ dan `externalTrafficPolicy` diset ke Local. From 9e182b619933c6158b84e4afc80fc9376524df9d Mon Sep 17 00:00:00 2001 From: Dery Rahman Ahaddienata Date: Fri, 12 Jun 2020 05:37:28 +0700 Subject: [PATCH 087/218] Apply suggestions from code review Co-authored-by: Giri Kuncoro --- .../create-external-load-balancer.md | 88 +++++++++---------- 1 file changed, 44 insertions(+), 44 deletions(-) diff --git a/content/id/docs/tasks/access-application-cluster/create-external-load-balancer.md b/content/id/docs/tasks/access-application-cluster/create-external-load-balancer.md index 68ab08c225..56debc18e6 100644 --- a/content/id/docs/tasks/access-application-cluster/create-external-load-balancer.md +++ b/content/id/docs/tasks/access-application-cluster/create-external-load-balancer.md @@ -7,19 +7,19 @@ weight: 80 {{% capture overview %}} -Halaman ini menjelaskan bagaimana membuat _Load Balancer_ Eksternal. +Laman ini menjelaskan bagaimana membuat _Load Balancer_ Eksternal. {{< note >}} -Fitur ini hanya tersedia untuk penyedia _cloud_ atau lingkungan yang mendukung _load balancer_ eksternal. +Fitur ini hanya tersedia untuk penyedia cloud atau lingkungan yang mendukung _load balancer_ eksternal. {{< /note >}} -Ketika membuat servis, kamu mempunyai opsi untuk membuat jaringan _cloud load balancer_ secara otomatis. -Hal ini menyediakan akses eksternal alamat IP yang dapat mengirim lalu lintas melalui porta yang tepat pada klaster _node_ kamu +Ketika membuat Service, kamu mempunyai opsi untuk tersambung dengan jaringan cloud _load balancer_ secara otomatis. +Hal ini menyediakan akses eksternal alamat IP yang dapat mengirim lalu lintas melalui porta yang tepat pada klaster Node kamu _asalkan klaster kamu beroperasi pada lingkungan yang mendukung dan terkonfigurasi dengan paket penyedia cloud load balancer yang benar_. -Untuk informasi mengenai penyediaan dan penggunaan sumber daya _Ingress_ yang dapat memberikan +Untuk informasi mengenai penyediaan dan penggunaan sumber daya Ingress yang dapat memberikan servis URL yang dapat dijangkau secara eksternal, penyeimbang beban lalu lintas, terminasi SSL, dll., -silahkan cek dokumentasi [_Ingress_](/docs/concepts/services-networking/ingress/) +silahkan cek dokumentasi [Ingress](/docs/concepts/services-networking/ingress/) {{% /capture %}} @@ -33,8 +33,8 @@ silahkan cek dokumentasi [_Ingress_](/docs/concepts/services-networking/ingress/ ## Berkas konfigurasi -Untuk membuat _load balancer_ eksternal, tambahkan baris dibawah ini ke -[berkas konfigurasi servis](/docs/concepts/services-networking/service/#loadbalancer) kamu: +Untuk membuat _load balancer_ eksternal, tambahkan baris di bawah ini ke +[berkas konfigurasi Service](/docs/concepts/services-networking/service/#loadbalancer) kamu: ```yaml type: LoadBalancer @@ -58,7 +58,7 @@ spec: ## Menggunakan kubectl -Kamu dapat membuat servis dengan perintah `kubectl expose` dan +Kamu dapat membuat Service dengan perintah `kubectl expose` dan _flag_ `--type=LoadBalancer`: ```bash @@ -66,16 +66,16 @@ kubectl expose rc example --port=8765 --target-port=9376 \ --name=example-service --type=LoadBalancer ``` -Perintah ini membuat servis baru dengan menggunakan pemilih yang sama dengan -sumber daya yang dirujuk (dalam hal contoh diatas, pengendali replikasi bernama `example`). +Perintah ini membuat Service baru dengan menggunakan pemilih yang sama dengan +sumber daya yang dirujuk (dalam hal contoh di atas, ReplicationController bernama `example`). Untuk informasi lebih lanjut, termasuk opsi _flag_, mengacu kepada [referensi `kubectl expose`](/docs/reference/generated/kubectl/kubectl-commands/#expose). ## Menemukan alamat IP kamu -Kamu dapat menemukan alamat IP yang telah dibuat untuk servis kamu dengan mendapatkan -informasi servis melalui `kubectl`: +Kamu dapat menemukan alamat IP yang telah dibuat untuk Service kamu dengan mendapatkan +informasi Service melalui `kubectl`: ```bash kubectl describe services example-service @@ -102,7 +102,7 @@ yang seharusnya menghasilkan keluaran seperti ini: Alamat IP tercantum di sebelah `LoadBalancer Ingress`. {{< note >}} -Juka kamu menjalankan servis dari Minikube, kamu dapat menemukan alamat IP dan porta yang ditetapkan dengan: +Jika kamu menjalankan Service dari Minikube, kamu dapat menemukan alamat IP dan porta yang ditetapkan dengan: {{< /note >}} ```bash @@ -111,26 +111,26 @@ minikube service example-service --url ## Preservasi IP sumber klien -Dikarenakan implementasi fitur ini, sumber IP yang terlihat pada _container_ +Implementasi dari fitur ini menyebabkan sumber IP yang terlihat pada Container target *bukan sebagai sumber IP asli* dari klien. Untuk mengaktifkan -preservasi IP klien, bidang berikut dapat dikonfigurasikan didalam -spek servis (mendukung lingkungan GCE/Google Kubernetes Engine): +preservasi IP klien, bidang berikut dapat dikonfigurasikan di dalam +spek Service (mendukung lingkungan GCE/Google Kubernetes Engine): -* `service.spec.externalTrafficPolicy` - menunjukan jika Service menginginkan untuk merute lalu lintas +* `service.spec.externalTrafficPolicy` - menunjukkan jika Service menginginkan rute lalu lintas eksternal ke titik akhir _node-local_ atau _cluster-wide_. Terdapat dua opsi yang tersedia: -Cluster (_default_) dan Local. Cluster mengaburkan sumber IP klien dan mungkin menyebabkan -hop kedua ke _node_ berbeda, namun harus mempunyai _load-spreading_ yang baik secara keseluruhan. -Local mempreservasi sumber IP client dan menghindari hop kedua _LoadBalancer_ dan servis tipe _NodePort_, namun +`Cluster` (bawaan) dan `Local`. `Cluster` mengaburkan sumber IP klien dan mungkin menyebabkan +hop kedua ke Node berbeda, namun harus mempunyai penyebaran beban (_load-spreading_) yang baik secara keseluruhan. +`Local` mempreservasi sumber IP client dan menghindari hop kedua `LoadBalancer` dan Service dengan tipe `NodePort`, namun resiko berpotensi penyebaran lalu lintas yang tidak merata. -* `service.spec.healthCheckNodePort` - menentukan cek kesehatan _node_ porta (nomor porta numerik) untuk servis. -Jika `healthCheckNodePort` tidak ditentukan, pengendali servis mengalokasi -porta dari rentang _NodePort_ dari klaster kamu. Kamu dapat mengonfigurasi +* `service.spec.healthCheckNodePort` - menentukan pemeriksaan kesehatan porta dari sebuah Node (angka porta numerik) untuk Service. +Jika `healthCheckNodePort` tidak ditentukan, pengendali Service mengalokasi +porta dari rentang `NodePort` dari klaster kamu. Kamu dapat mengonfigurasi rentangan tersebut dari pengaturan opsi barisan perintah API server, `--service-node-port-range`. Hal itu menggunakan nilai `healthCheckNodePort` pengguna spesifik -jika ditentukan oleh klien. Hal itu dapat berefek hanya ketika `type` diset ke _LoadBalancer_ dan -`externalTrafficPolicy` diset ke Local. +jika ditentukan oleh klien. Hal itu dapat berefek hanya ketika `type` diset ke `LoadBalancer` dan +`externalTrafficPolicy` diset ke `Local`. -Pengaturan `externalTrafficPolicy` ke Local pada berkas konfigurasi Service mengaktifkan +Pengaturan `externalTrafficPolicy` ke `Local` pada berkas konfigurasi Service mengaktifkan fitur ini. ```yaml @@ -148,49 +148,49 @@ spec: type: LoadBalancer ``` -## Pengumpul Sampah Load Balancers +## Pengumpul Sampah (Garbage Collector) Load Balancer {{< feature-state for_k8s_version="v1.17" state="stable" >}} -Pada kasus biasa, sumber daya _load balancer_ yang berkorelasi pada penyedia _cloud_ perlu +Pada kasus biasa, sumber daya _load balancer_ yang berkorelasi pada penyedia cloud perlu dibersihkan segera setelah Service bertipe _LoadBalancer_ dihapus. Namun perlu diketahui -bahwa terdapat kasus tepi dimana sumber daya _cloud_ yatim piatu (_orphaned_) setelah +bahwa terdapat kasus tepi dimana sumber daya cloud yatim piatu (_orphaned_) setelah Service yang berkaitan dihapus. _Finalizer Protection_ untuk Service _LoadBalancer_ diperkenalkan untuk mencegah hal ini terjadi. Dengan menggunakan _finalizers_, sebuah sumber daya Service tidak akan pernah dihapus hingga sumber daya _load balancer_ yang berkorelasi juga dihapus. -Secara khusus, jika Service mempunyai `type` _LoadBalancer_, pengendali servis akan melekatkan +Secara khusus, jika Service mempunyai `type LoadBalancer`, pengendali Service akan melekatkan _finalizer_ bernama `service.kubernetes.io/load-balancer-cleanup`. _Finalizer_ hanya akan dihapus setelah sumber daya _load balancer_ dibersihkan. Hal ini mencegah sumber daya _load balancer_ yang teruntai bahkan setelah kasus tepi seperti -pengendali servis berhenti. +pengendali Service berhenti. ## Penyedia Load Balancer Eksternal Penting untuk dicatat bahwa jalur data untuk fungsionalitas ini disediakan oleh _load balancer_ eksternal ke klaster Kubernetes. -Ketika Service `type` diset `LoadBalancer`, Kubernetes menediakan fungsionalitas yang ekuivalen dengan `type` sebanding ClusterIP -ke _pods_ dalam klaster dan mengekstensinya dengan pemrograman (eksternal ke Kubernetes) _load balancer_ dengan entri pada pods -Kubernetes. Pengendali servis Kubernetes mengotomasi pembuatan _load balancer_ eksternal, cek kesehatan (jika dibutuhkan), -dinding api (jika dibutuhkan), dan mengambil IP eksternal yang dialokasikan oleh penyedia _cloud_ dan mengisinya pada objek servis. +Ketika Service `type` diset `LoadBalancer`, Kubernetes menyediakan fungsionalitas yang ekuivalen dengan `type` sebanding `ClusterIP` +ke berbagai Pod di dalam klaster dan mengekstensinya dengan pemrograman (eksternal dari Kubernetes) _load balancer_ dengan entri pada Pod +Kubernetes. Pengendali Service Kubernetes mengotomasi pembuatan _load balancer_ eksternal, cek kesehatan (jika dibutuhkan), +dinding api (_firewall_) (jika dibutuhkan), dan mengambil IP eksternal yang dialokasikan oleh penyedia cloud dan mengisinya pada objek Service. ## Peringatan dan and Limitasi ketika preservasi sumber IP _Load balancers_ GCE/AWS tidak menyediakan bobot pada kolam targetnya. Hal ini bukan merupakan isu dengan aturan kube-proxy -LB lama yang akan menyeimbangkan semua titik akhir dengan benar. +_Load balancer_ lama yang akan menyeimbangkan semua titik akhir dengan benar. -Dengan fungsionalitas yang baru, lalu lintas eksternal tidak menyeimbangkan beban secara merata pada seluruh pods, namun -sebaliknya menyeimbangkan secara merata pada level _node_ (karena GCE/AWS dan implementasi LB eksternal lainnya tidak mempunyai -kemampuan untuk menentukan bobot setiap _node_, mereka menyeimbangkan secara merata pada semua _node_ target, mengabaikan jumlah -_pods_ pada tiap _node_). +Dengan fungsionalitas yang baru, lalu lintas eksternal tidak menyeimbangkan beban secara merata pada seluruh Pod, namun +sebaliknya menyeimbangkan secara merata pada level Node (karena GCE/AWS dan implementasi _load balancer_ eksternal lainnya tidak mempunyai +kemampuan untuk menentukan bobot setiap Node, mereka menyeimbangkan secara merata pada semua Node target, mengabaikan jumlah +Pod pada tiap Node). -Namun demikian, kita dapat menyatakan bahwa NumServicePods << NumNodes or NumServicePods >> NumNodes, distribusi yang cukup mendekati +Namun demikian, kita dapat menyatakan bahwa NumServicePods << NumNodes atau NumServicePods >> NumNodes, distribusi yang cukup mendekati sama akan terlihat, meski tanpa bobot. -Sekali _load balancers_ eksternal menyediakan bobot, fungsionalitas ini dapat ditambahkan pada jalur pemrograman LB. +Sekali _load balancer_ eksternal menyediakan bobot, fungsionalitas ini dapat ditambahkan pada jalur pemrograman _load balancer_. *Pekerjaan Masa Depan: Tidak adanya dukungan untuk bobot yang disediakan untuk rilis 1.4, namun dapat ditambahkan di masa mendatang* -_Pod_ internal ke lalu lintas _pod_ harus berperilaku sama seperti servis ClusterIP, dengan probabilitas yang sama pada seluruh _pods_. +Pod internal ke lalu lintas Pod harus berperilaku sama seperti Service ClusterIP, dengan probabilitas yang sama pada seluruh Pod. {{% /capture %}} From 9992812c0dfb9299f0ea0739c4cebc0075d5a260 Mon Sep 17 00:00:00 2001 From: Dery Rahman Ahaddienata Date: Sun, 21 Jun 2020 18:19:21 +0700 Subject: [PATCH 088/218] Target pools for kolam target --- .../access-application-cluster/create-external-load-balancer.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/id/docs/tasks/access-application-cluster/create-external-load-balancer.md b/content/id/docs/tasks/access-application-cluster/create-external-load-balancer.md index 56debc18e6..0d306a559a 100644 --- a/content/id/docs/tasks/access-application-cluster/create-external-load-balancer.md +++ b/content/id/docs/tasks/access-application-cluster/create-external-load-balancer.md @@ -176,7 +176,7 @@ dinding api (_firewall_) (jika dibutuhkan), dan mengambil IP eksternal yang dial ## Peringatan dan and Limitasi ketika preservasi sumber IP -_Load balancers_ GCE/AWS tidak menyediakan bobot pada kolam targetnya. Hal ini bukan merupakan isu dengan aturan kube-proxy +_Load balancers_ GCE/AWS tidak menyediakan bobot pada kolam targetnya (target pools). Hal ini bukan merupakan isu dengan aturan kube-proxy _Load balancer_ lama yang akan menyeimbangkan semua titik akhir dengan benar. Dengan fungsionalitas yang baru, lalu lintas eksternal tidak menyeimbangkan beban secara merata pada seluruh Pod, namun From 75c695dbda4aae5fc89ccfdb29842c15ed97c234 Mon Sep 17 00:00:00 2001 From: Maciej Filocha Date: Sun, 21 Jun 2020 13:55:30 +0200 Subject: [PATCH 089/218] Polish localization update - June 2020 - part 2 An update of localized Polish content up to c1dcada5deda43ec72e30a11ad0afa74ccb93608. --- content/pl/docs/concepts/_index.md | 6 +++--- content/pl/docs/tutorials/_index.md | 6 +++--- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/content/pl/docs/concepts/_index.md b/content/pl/docs/concepts/_index.md index f1eb3cd621..6d773fc5ab 100644 --- a/content/pl/docs/concepts/_index.md +++ b/content/pl/docs/concepts/_index.md @@ -41,7 +41,7 @@ Kubernetes zawiera także obiekty abstrakcyjne wyższego poziomu, zbudowane z ob * [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) * [StatefulSet](/docs/concepts/workloads/controllers/statefulset/) * [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) - * [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) + * [Job](/docs/concepts/workloads/controllers/job/) ## Warstwa sterowania (*Kubernetes Control Plane*) {#warstwa-sterowania} @@ -65,7 +65,7 @@ Węzły klastra to maszyny (wirtualne, fizyczne i in.), na których uruchamiane Jeśli chcesz dodać stronę z nowym pojęciem, odwiedź -[Jak używać szablonu strony](/docs/home/contribute/page-templates/) -aby dowiedzieć się o tworzeniu stron opisujących pojęcia i o dostępnych szablonach. +[Page Content Types](/docs/home/contribute/style/page-content-types/#concept), +aby dowiedzieć się o tworzeniu stron opisujących pojęcia. diff --git a/content/pl/docs/tutorials/_index.md b/content/pl/docs/tutorials/_index.md index 19e4bf8d24..c86414ccff 100644 --- a/content/pl/docs/tutorials/_index.md +++ b/content/pl/docs/tutorials/_index.md @@ -69,8 +69,8 @@ Przed zapoznaniem się z samouczkami warto stworzyć zakładkę do ## {{% heading "whatsnext" %}} -Jeśli chciałbyś napisać nowy samouczek, zajrzyj na stronę -[Jak używać szablonów stron](/docs/home/contribute/page-templates/) -gdzie znajdziesz dodatkowe informacje na temat stron i szablonów samouczków. +Jeśli chciałbyś napisać nowy samouczek, odwiedź +[Content Page Types](/docs/home/contribute/style/page-content-types/), +gdzie znajdziesz dodatkowe informacje o tym typie strony. From 6cf46d12d30642ec8b9efda4ede643a446e307fe Mon Sep 17 00:00:00 2001 From: joshuabezaleel Date: Sun, 21 Jun 2020 22:12:51 +0700 Subject: [PATCH 090/218] Add translation for configuring service account for ID localization --- .../configure-service-account.md | 333 ++++++++++++++++++ .../pods/pod-projected-svc-token.yaml | 20 ++ 2 files changed, 353 insertions(+) create mode 100644 content/id/docs/tasks/configure-pod-container/configure-service-account.md create mode 100644 content/id/examples/pods/pod-projected-svc-token.yaml diff --git a/content/id/docs/tasks/configure-pod-container/configure-service-account.md b/content/id/docs/tasks/configure-pod-container/configure-service-account.md new file mode 100644 index 0000000000..072abd936b --- /dev/null +++ b/content/id/docs/tasks/configure-pod-container/configure-service-account.md @@ -0,0 +1,333 @@ +--- +title: Mengatur Service Account untuk Pod +content_type: task +weight: 90 +--- + + +Akun servis (_service account_) menyediakan identitas untuk proses yang sedang berjalan dalam sebuah Pod. + +{{< note >}} +Dokumen ini digunakan sebagai pengenalan untuk pengguna terhadap _Service Account_ dan menjelaskan bagaimana perilaku _service account_ dalam konfigurasi kluster seperti yang direkomendasikan Kubernetes. Pengubahan perilaku yang bisa saja dilakukan administrator kluster terhadap kluster tidak menjadi bagian pembahasan dokumentasi ini. +{{< /note >}} + +Ketika kamu mengakses kluster (contohnya menggunakan `kubectl`), kamu terautentikasi oleh apiserver sebagai sebuah User Account (untuk sekarang umumnya sebagai `admin`, kecuali jika administrator klustermu telah melakukan pengubahan). Berbagai proses yang ada di dalam kontainer dalam pod juga dapat mengontak apiserver. Ketika itu terjadi, mereka akan diautentikasi sebagai sebuah Service Account (contohnya sebagai `default`). + + + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + + + +## Menggunakan Default Service Account untuk Mengakses API server. + +Ketika kamu membuat sebuah pod, jika kamu tidak menentukan sebuah _service account_, maka ia akan otomatis ditetapkan sebagai _service account_`default` di namespace yang sama. Jika kamu mendapatkan json atau yaml mentah untuk sebuah pod yang telah kamu buat (contohnya menggunakan `kubectl get pods/ -o yaml`), kamu akan melihat _field_ `spec.serviceAccountName` yang telah secara [otomatis ditentukan](/docs/user-guide/working-with-resources/#resources-are-automatically-modified). + +Kamu dapat mengakses API dari dalam pod menggunakan kredensial _service account_ yang ditambahkan secara otomatis seperti yang dijelaskan dalam [Mengakses Klaster](/docs/user-guide/accessing-the-cluster/#accessing-the-api-from-a-pod). +Hak akses API dari _service account_ menyesuaikan dengan [kebijakan dan plugin otorisasi](/docs/reference/access-authn-authz/authorization/#authorization-modules) yang sedang digunakan. + +Di versi 1.6+, kamu dapat tidak memilih _automounting_ kredensial API dari sebuah _service account_ dengan mengatur `automountServiceAccountToken: false` pada _service account_: + +```yaml +apiVersion: v1 +kind: ServiceAccount +metadata: + name: build-robot +automountServiceAccountToken: false +... +``` + +Di versi 1.6+, kamu juga dapat tidak memilih _automounting_ kredensial API dari suatu pod tertentu: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: my-pod +spec: + serviceAccountName: build-robot + automountServiceAccountToken: false + ... +``` + +Pengaturan dari spesifikasi pod didahulukan dibanding _service account_ jika keduanya menentukan nilai dari `automountServiceAccountToken`. + +## Menggunakan Beberapa Service Account. + +Setiap namespace memiliki _resource_ _service account_ standar `default`. +Kamu dapat melihatnya dan _resource_ serviceAccount lainnya di namespace tersebut dengan perintah: + +```shell +kubectl get serviceaccounts +``` +Keluarannya akan serupa dengan: + +``` +NAME SECRETS AGE +default 1 1d +``` + +Kamu dapat membuat obyek ServiceAccount tambahan seperti ini: + +```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 >}} +Isi dari `token` tidak dirinci di sini. +{{< /note >}} + +## Menambahkan ImagePullSecrets ke service account. + +### Membuat imagePullSecret + +- Membuat sebuah imagePullSecret, seperti yang dijelaskan pada [Menentukan ImagePullSecrets pada Pod](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod). + + ```shell + kubectl create secret docker-registry myregistrykey --docker-server=DUMMY_SERVER \ + --docker-username=DUMMY_USERNAME --docker-password=DUMMY_DOCKER_PASSWORD \ + --docker-email=DUMMY_DOCKER_EMAIL + ``` + +- Memastikan bahwa _secret_ telah terbuat. + ```shell + kubectl get secrets myregistrykey + ``` + + Keluarannya akan serupa dengan: + + ``` + NAME TYPE DATA AGE + myregistrykey   kubernetes.io/.dockerconfigjson   1       1d + ``` + +### Menambahkan imagePullSecret ke service account + +Selanjutnya, modifikasi _service account_ standar dari namespace untuk menggunakan _secret_ ini sebagai imagePullSecret. + + +```shell +kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "myregistrykey"}]}' +``` + +Sebagai gantinya kamu dapat menggunakan `kubectl edit`, atau melakukan pengubahan secara manual _manifest_ YAML seperti di bawah ini: + +```shell +kubectl get serviceaccounts default -o yaml > ./sa.yaml +``` + +Keluaran dari _file_ `sa.yaml` akan serupa dengan: + +```shell +apiVersion: v1 +kind: ServiceAccount +metadata: + creationTimestamp: 2015-08-07T22:02:39Z + name: default + namespace: default + resourceVersion: "243024" + uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6 +secrets: +- name: default-token-uudge +``` + +Menggunakan _editor_ pilihanmu (misalnya `vi`), buka _file_ `sa.yaml`, hapus baris dengan _key_ `resourceVersion`, tambahkan baris dengan `imagePullSecrets:` dan simpan. + +Keluaran dari _file_ `sa.yaml` akan serupa dengan: + +```shell +apiVersion: v1 +kind: ServiceAccount +metadata: + creationTimestamp: 2015-08-07T22:02:39Z + name: default + namespace: default + uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6 +secrets: +- name: default-token-uudge +imagePullSecrets: +- name: myregistrykey +``` + +Terakhir ganti serviceaccount dengan _file_ `sa.yaml` yang telah diperbarui. + +```shell +kubectl replace serviceaccount default -f ./sa.yaml +``` + +### Memverifikasi imagePullSecrets sudah ditambahkan ke spesifikasi pod + +Ketika Pod baru dibuat dalam namespace yang sedang aktif dan menggunakan ServiceAccount, Pod baru akan memiliki _field_ `spec.imagePullSecrets` yang ditentukan secara otomatis: + +```shell +kubectl run nginx --image=nginx --restart=Never +kubectl get pod nginx -o=jsonpath='{.spec.imagePullSecrets[0].name}{"\n"}' +``` + +Keluarannya adalah: + +``` +myregistrykey +``` + + + +## Service Account Token Volume Projection + +{{< feature-state for_k8s_version="v1.12" state="beta" >}} + +{{< note >}} +ServiceAccountTokenVolumeProjection masih dalam tahap __beta__ untuk versi 1.12 dan diaktifkan dengan memberikan _flag_ berikut ini ke API _server_: + +* `--service-account-issuer` +* `--service-account-signing-key-file` +* `--service-account-api-audiences` + +{{< /note >}} + +Kubelet juga dapat memproyeksikan _token_ _service account_ ke Pod. Kamu dapat menentukan properti yang diinginkan dari _token_ seperti target pengguna dan durasi validitas. Properti tersebut tidak dapat diubah pada _token_ _service account_ standar. _Token_ _service account_ juga akan menjadi tidak valid terhadap API ketika Pod atau ServiceAccount dihapus. + +Perilaku ini diatur pada PodSpec menggunakan tipe ProjectedVolume yaitu [ServiceAccountToken](/docs/concepts/storage/volumes/#projected). Untuk memungkinkan pod dengan _token_ dengan pengguna bertipe _"vault"_ dan durasi validitas selama dua jam, kamu harus mengubah bagian ini pada PodSpec: + +{{< codenew file="pods/pod-projected-svc-token.yaml" >}} + +Buat Pod: + +```shell +kubectl create -f https://k8s.io/examples/pods/pod-projected-svc-token.yaml +``` + +Kubelet akan me-_request_ dan menyimpan _token_ mewakili pod, buat _token_ dapat diakses oleh pod pada _file path_ yang ditentukan, dan _refresh_ _token_ ketika telah mendekati waktu berakhir. Kubelet akan mengganti _token_ jika _token_ telah melewati 80% dari total TTL, atau jika _token_ telah melebihi waktu 24 jam. + +Aplikasi bertanggung jawab untuk memuat ulang _token_ ketika terjadi penggantian. Pemuatan ulang teratur (misalnya sekali setiap 5 menit) cukup untuk mencakup kebanyakan kasus. + +## Service Account Issuer Discovery + +{{< feature-state for_k8s_version="v1.18" state="alpha" >}} + +Fitur _Service Account Issuer Discovery_ diaktifkan dengan mengaktifkan _[feature gate](/docs/reference/command-line-tools-reference/feature-gate)_ `ServiceAccountIssuerDiscovery` dan mengaktifkan fitur _Service Account Token Volume Projection_ seperti yang telah dijelaskan [di atas](#service-account-token-volume-projection). + +{{< note >}} +URL _issuer_ harus sesuai dengan _[OIDC Discovery Spec](https://openid.net/specs/openid-connect-discovery-1_0.html)_. Pada implementasinya, hal ini berarti URL harus menggunakan skema `https` dan harus menyediakan konfigurasi penyedia OpenID pada `{service-account-issuer}/.well-known/openid-configuration`. + +Jika URL tidak sesuai dengan aturan, _endpoint_ `ServiceAccountIssuerDiscovery` tidak akan didaftarkan meskipun fitur telah diaktifkan. +{{< /note >}} + +Fitur _Service Account Issuer Discovery_ memungkinkan federasi dari berbagai _token_ _service account_ Kubernetes yang dibuat oleh sebuah kluster (penyedia identitas) dan sistem eksternal. + +Ketika diaktifkan, _server_ API Kubernetes menyediakan dokumen OpenID Provider Configuration pada `/.well-known/openid-configuration` dan JSON Web Key Set (JWKS) terkait pada `/openid/v1/jwks`. OpenID Provider Configuration terkadang disebut juga dengan sebutan _discovery document_. + +Ketika diaktifkan, kluster juga dikonfigurasi dengan RBAC ClusterRole standar yaitu `system:service-account-issuer-discovery`. _Role binding_ tidak disediakan secara _default_. Administrator dimungkinkan untuk, sebagai contoh, menentukan apakah peran akan disematkan ke `system:authenticated` atau `system:unauthenticated` tergantung terhadap kebutuhan keamanan dan sistem eksternal yang direncakanan untuk diintegrasikan. + +{{< note >}} +Respons yang disediakan pada `/.well-known/openid-configuration` dan`/openid/v1/jwks` dirancang untuk kompatibel dengan OIDC, tetapi tidak sepenuhnya sesuai dengan ketentuan OIDC. Dokumen tersebut hanya berisi parameter yang dibutuhkan untuk melakukan validasi terhadap _token_ _service account_ Kubernetes. +{{< /note >}} + +Respons JWKS memuat kunci publik yang dapat digunakan oleh sistem eksternal untuk melakukan validasi _token_ _service account_ Kubernetes. Awalnya sistem eksternal akan mengkueri OpenID Provider Configuration, dan selanjutnya dapat menggunakan _field_ `jwks_uri` pada respons kueri untuk mendapatkan JWKS. + +Pada banyak kasus, _server_ API Kubernetes tidak tersedia di internet publik, namun _endpoint_ publik yang menyediakan respons hasil _cache_ dari _server_ API dapat dibuat menjadi tersedia oleh pengguna atau penyedia servis. Pada kasus ini, dimungkinkan untuk mengganti `jwks_uri` pada OpenID Provider Configuration untuk diarahkan ke _endpoint_ publik sebagai ganti alamat _server_ API dengan memberikan _flag_ `--service-account-jwks-uri` ke API server. serupa dengan URL _issuer_, URI JWKS diharuskan untuk menggunakan skema `https`. + + +## {{% heading "whatsnext" %}} + + +Lihat juga: + +- [Panduan Admin Kluster mengenai Service Account](/docs/reference/access-authn-authz/service-accounts-admin/) +- [Service Account Signing Key Retrieval KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/20190730-oidc-discovery.md) +- [OIDC Discovery Spec](https://openid.net/specs/openid-connect-discovery-1_0.html) + + diff --git a/content/id/examples/pods/pod-projected-svc-token.yaml b/content/id/examples/pods/pod-projected-svc-token.yaml new file mode 100644 index 0000000000..985073c8d3 --- /dev/null +++ b/content/id/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 0a76ba0149405284ee1047ba9b62e095bbc253ca Mon Sep 17 00:00:00 2001 From: joshuabezaleel Date: Sun, 21 Jun 2020 22:21:35 +0700 Subject: [PATCH 091/218] Fix redirect link for feature-gates page on configure-service-account --- .../tasks/configure-pod-container/configure-service-account.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/tasks/configure-pod-container/configure-service-account.md b/content/en/docs/tasks/configure-pod-container/configure-service-account.md index eaaabb9e94..2486e520e1 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-service-account.md +++ b/content/en/docs/tasks/configure-pod-container/configure-service-account.md @@ -323,7 +323,7 @@ The application is responsible for reloading the token when it rotates. Periodic {{< feature-state for_k8s_version="v1.18" state="alpha" >}} The Service Account Issuer Discovery feature is enabled by enabling the -`ServiceAccountIssuerDiscovery` [feature gate](/docs/reference/command-line-tools-reference/feature) +`ServiceAccountIssuerDiscovery` [feature gate](/docs/reference/command-line-tools-reference/feature-gates) and then enabling the Service Account Token Projection feature as described [above](#service-account-token-volume-projection). From ba8f6aff6a0d33dd3a112e73b29372f54ad24e40 Mon Sep 17 00:00:00 2001 From: Maciej Filocha Date: Sun, 21 Jun 2020 18:30:40 +0200 Subject: [PATCH 092/218] Synchronize Polish translation 2020-06-21 Update Polish translation up to 6ef6812c8e204ae7e6504e408141708c1a5408b2. --- content/pl/docs/concepts/_index.md | 2 +- content/pl/docs/concepts/overview/what-is-kubernetes.md | 2 +- content/pl/docs/tutorials/_index.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/content/pl/docs/concepts/_index.md b/content/pl/docs/concepts/_index.md index 6d773fc5ab..ec7abd87ce 100644 --- a/content/pl/docs/concepts/_index.md +++ b/content/pl/docs/concepts/_index.md @@ -65,7 +65,7 @@ Węzły klastra to maszyny (wirtualne, fizyczne i in.), na których uruchamiane Jeśli chcesz dodać stronę z nowym pojęciem, odwiedź -[Page Content Types](/docs/home/contribute/style/page-content-types/#concept), +[Page Content Types](/docs/contribute/style/page-content-types/#concept), aby dowiedzieć się o tworzeniu stron opisujących pojęcia. diff --git a/content/pl/docs/concepts/overview/what-is-kubernetes.md b/content/pl/docs/concepts/overview/what-is-kubernetes.md index fcb8f7714c..861476a561 100644 --- a/content/pl/docs/concepts/overview/what-is-kubernetes.md +++ b/content/pl/docs/concepts/overview/what-is-kubernetes.md @@ -73,7 +73,7 @@ Kubernetes pozwala składować i zarządzać informacjami poufnymi, takimi jak h ## Czym Kubernetes nie jest -Kubernetes nie jest tradycyjnym, zawierającym wszystko systemem PaaS *(Platform as a Service)*. Ponieważ Kubernetes działa w warstwie kontenerów, a nie sprzętu, posiada różne funkcjonalności ogólnego zastosowania, wspólne dla innych rozwiązań PaaS, takie jak: instalacje *(deployments)*, skalowanie, balansowanie ruchu, logowanie i monitoring. Co ważne, Kubernetes nie jest monolitem i te domyślnie dostępne rozwiązania są opcjonalne i działają jako wtyczki. Kubernetes dostarcza elementy, z których może być zbudowana platforma deweloperska, ale pozostawia użytkownikowi wybór i elastyczność tam, gdzie jest to ważne. +Kubernetes nie jest tradycyjnym, zawierającym wszystko systemem PaaS *(Platform as a Service)*. Ponieważ Kubernetes działa w warstwie kontenerów, a nie sprzętu, posiada różne funkcjonalności ogólnego zastosowania, wspólne dla innych rozwiązań PaaS, takie jak: instalacje *(deployments)*, skalowanie i balansowanie ruchu, umożliwiając użytkownikom integrację rozwiązań służących do logowania, monitoringu i ostrzegania. Co ważne, Kubernetes nie jest monolitem i domyślnie dostępne rozwiązania są opcjonalne i działają jako wtyczki. Kubernetes dostarcza elementy, z których może być zbudowana platforma deweloperska, ale pozostawia użytkownikowi wybór i elastyczność tam, gdzie jest to ważne. Kubernetes: diff --git a/content/pl/docs/tutorials/_index.md b/content/pl/docs/tutorials/_index.md index c86414ccff..0f9d7ac723 100644 --- a/content/pl/docs/tutorials/_index.md +++ b/content/pl/docs/tutorials/_index.md @@ -70,7 +70,7 @@ Przed zapoznaniem się z samouczkami warto stworzyć zakładkę do Jeśli chciałbyś napisać nowy samouczek, odwiedź -[Content Page Types](/docs/home/contribute/style/page-content-types/), +[Content Page Types](/docs/contribute/style/page-content-types/), gdzie znajdziesz dodatkowe informacje o tym typie strony. From e0f01428be9aa6e5c7d60faa3104c42a2b77f88e Mon Sep 17 00:00:00 2001 From: TomorJM Date: Mon, 22 Jun 2020 00:42:26 +0800 Subject: [PATCH 093/218] 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 384de5991f925bf6d2dfdc6450a1de2c9a5418d5 Mon Sep 17 00:00:00 2001 From: Alex Lin <57118637+lnregalias@users.noreply.github.com> Date: Mon, 22 Jun 2020 10:37:28 +1000 Subject: [PATCH 094/218] Update content/en/docs/concepts/cluster-administration/cloud-providers.md Co-authored-by: Jim Angel --- .../en/docs/concepts/cluster-administration/cloud-providers.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/cluster-administration/cloud-providers.md b/content/en/docs/concepts/cluster-administration/cloud-providers.md index 3e73cd403d..7c6f325fb3 100644 --- a/content/en/docs/concepts/cluster-administration/cloud-providers.md +++ b/content/en/docs/concepts/cluster-administration/cloud-providers.md @@ -99,7 +99,7 @@ Different settings can be applied to a load balancer service in AWS using _annot * `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout`: Used on the service to specify a connection draining timeout. * `service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout`: Used on the service to specify the idle connection timeout. * `service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled`: Used on the service to enable or disable cross-zone load balancing. -* `service.beta.kubernetes.io/aws-load-balancer-security-groups`: Used to specify the security groups to be added to ELB created. This replaces all other security groups previously assigned to the ELB. Under current behaviour, security groups defined here should not be shared between multiple services. +* `service.beta.kubernetes.io/aws-load-balancer-security-groups`: Used to specify the security groups to be added to ELB created. This replaces all other security groups previously assigned to the ELB. Security groups defined here should not be shared between services. * `service.beta.kubernetes.io/aws-load-balancer-extra-security-groups`: Used on the service to specify additional security groups to be added to ELB created * `service.beta.kubernetes.io/aws-load-balancer-internal`: Used on the service to indicate that we want an internal ELB. * `service.beta.kubernetes.io/aws-load-balancer-proxy-protocol`: Used on the service to enable the proxy protocol on an ELB. Right now we only accept the value `*` which means enabling the proxy protocol on all ELB backends. In the future we could adjust this to allow setting the proxy protocol only on certain backends. From 0ae9f8221b8117df27f234a2424724f86549d853 Mon Sep 17 00:00:00 2001 From: Shuyang Wu Date: Mon, 22 Jun 2020 10:39:20 +0800 Subject: [PATCH 095/218] Update content/zh/docs/tasks/tools/install-minikube.md Co-authored-by: SataQiu <1527062125@qq.com> --- content/zh/docs/tasks/tools/install-minikube.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/zh/docs/tasks/tools/install-minikube.md b/content/zh/docs/tasks/tools/install-minikube.md index e4d16a1a2c..fce7facc9d 100644 --- a/content/zh/docs/tasks/tools/install-minikube.md +++ b/content/zh/docs/tasks/tools/install-minikube.md @@ -403,7 +403,7 @@ For setting the `--vm-driver` with `minikube start`, enter the name of the hyper {{< /note >}} {{< note >}} -由于国内无法直接连接k8s.gcr.io，推荐使用阿里云镜像，在`minikube start`中添加镜像参数 +由于国内无法直接连接 k8s.gcr.io，推荐使用阿里云镜像仓库，在 `minikube start` 中添加 `--image-repository` 参数。 {{< /note >}} ```shell @@ -487,4 +487,3 @@ minikube delete --> * [使用 Minikube 在本地运行 Kubernetes](/docs/setup/learning-environment/minikube/) - From 473c56aa4f3cf778ffc54691b16625c0012d73f6 Mon Sep 17 00:00:00 2001 From: Prasad Katti Date: Fri, 8 May 2020 11:37:19 -0700 Subject: [PATCH 096/218] move configure-multiple-schedulers.md --- .../configure-multiple-schedulers.md | 1 + static/_redirects | 1 + 2 files changed, 2 insertions(+) rename content/en/docs/tasks/{administer-cluster => extend-kubernetes}/configure-multiple-schedulers.md (99%) diff --git a/content/en/docs/tasks/administer-cluster/configure-multiple-schedulers.md b/content/en/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md similarity index 99% rename from content/en/docs/tasks/administer-cluster/configure-multiple-schedulers.md rename to content/en/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md index e4b58b70e3..4afbee21c8 100644 --- a/content/en/docs/tasks/administer-cluster/configure-multiple-schedulers.md +++ b/content/en/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md @@ -4,6 +4,7 @@ reviewers: - madhusudancs title: Configure Multiple Schedulers content_type: task +weight: 20 --- diff --git a/static/_redirects b/static/_redirects index 242518f7ef..042e411deb 100644 --- a/static/_redirects +++ b/static/_redirects @@ -213,6 +213,7 @@ /docs/tasks/administer-cluster/certificate-rotation/ /docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/ 301 /docs/tasks/administer-cluster/cilium-network-policy/ /docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy/ 301 /docs/tasks/administer-cluster/configure-namespace-isolation/ /docs/concepts/services-networking/network-policies/ 301 +/docs/tasks/administer-cluster/configure-multiple-schedulers/ /docs/tasks/extend-kubernetes/configure-multiple-schedulers/ 301 /docs/tasks/administer-cluster/configure-pod-disruption-budget/ /docs/tasks/run-application/configure-pdb/ 301 /docs/tasks/administer-cluster/cpu-constraint-namespace/ /docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/ 301 /docs/tasks/administer-cluster/cpu-default-namespace/ /docs/tasks/administer-cluster/manage-resources/cpu-default-namespace 301 From 2d31450e89facb555dd2bc9d49dc75ef28239e47 Mon Sep 17 00:00:00 2001 From: TomorJM Date: Mon, 22 Jun 2020 11:48:12 +0800 Subject: [PATCH 097/218] 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 d8c8d6a881c3a97fd37f7e428442ccff59887ade Mon Sep 17 00:00:00 2001 From: Kiyoshi Muranaka Date: Mon, 22 Jun 2020 17:00:01 +0900 Subject: [PATCH 098/218] [en] Fix broken link to Xilinx FPGA device plugins --- .../extend-kubernetes/compute-storage-net/device-plugins.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md index d27dddd384..c8388478f5 100644 --- a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md +++ b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md @@ -223,7 +223,7 @@ Here are some examples of device plugin implementations: * The [RDMA device plugin](https://github.com/hustcat/k8s-rdma-device-plugin) * The [Solarflare device plugin](https://github.com/vikaschoudhary16/sfc-device-plugin) * The [SR-IOV Network device plugin](https://github.com/intel/sriov-network-device-plugin) -* The [Xilinx FPGA device plugins](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin/trunk) for Xilinx FPGA devices +* The [Xilinx FPGA device plugins](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin) for Xilinx FPGA devices ## {{% heading "whatsnext" %}} From f52ab1241be72f5ca8f3b619e57431aee24dedea Mon Sep 17 00:00:00 2001 From: Josef Brandl Date: Mon, 22 Jun 2020 10:08:40 +0200 Subject: [PATCH 099/218] Fix description of failureThreshold --- .../configure-liveness-readiness-startup-probes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index ed5aa24044..1630708182 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -332,7 +332,7 @@ to 1 second. Minimum value is 1. * `successThreshold`: Minimum consecutive successes for the probe to be considered successful after having failed. Defaults to 1. Must be 1 for liveness. Minimum value is 1. -* `failureThreshold`: When a Pod starts and the probe fails, Kubernetes will +* `failureThreshold`: When a probe fails, Kubernetes will try `failureThreshold` times before giving up. Giving up in case of liveness probe means restarting the container. In case of readiness probe the Pod will be marked Unready. Defaults to 3. Minimum value is 1. From f82fb613aa5df551c57b56b26780af7c4b05d508 Mon Sep 17 00:00:00 2001 From: Kiyoshi Muranaka Date: Mon, 22 Jun 2020 17:10:07 +0900 Subject: [PATCH 100/218] [id] Fix broken link to Xilinx FPGA device plugins --- .../extend-kubernetes/compute-storage-net/device-plugins.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/id/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/id/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md index 014a40171e..3bde2909ca 100644 --- a/content/id/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md +++ b/content/id/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md @@ -221,7 +221,7 @@ Berikut beberapa contoh implementasi _plugin_ perangkat: * [Plugin perangkat RDMA](https://github.com/hustcat/k8s-rdma-device-plugin) * [Plugin perangkat Solarflare](https://github.com/vikaschoudhary16/sfc-device-plugin) * [Plugin perangkat SR-IOV Network](https://github.com/intel/sriov-network-device-plugin) -* [Plugin perangkat Xilinx FPGA](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin/trunk) untuk perangkat Xilinx FPGA +* [Plugin perangkat Xilinx FPGA](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin) untuk perangkat Xilinx FPGA ## {{% heading "whatsnext" %}} From 20d2da4d707c36f0e22bc90ab58936eaf7420a3d Mon Sep 17 00:00:00 2001 From: Kiyoshi Muranaka Date: Mon, 22 Jun 2020 17:11:26 +0900 Subject: [PATCH 101/218] [zh] Fix broken link to Xilinx FPGA device plugins --- .../extend-kubernetes/compute-storage-net/device-plugins.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md index ce02f811f2..e7d020a8b2 100644 --- a/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md +++ b/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md @@ -322,7 +322,7 @@ Here are some examples of device plugin implementations: * The [RDMA device plugin](https://github.com/hustcat/k8s-rdma-device-plugin) * The [Solarflare device plugin](https://github.com/vikaschoudhary16/sfc-device-plugin) * The [SR-IOV Network device plugin](https://github.com/intel/sriov-network-device-plugin) -* The [Xilinx FPGA device plugins](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin/trunk) for Xilinx FPGA devices +* The [Xilinx FPGA device plugins](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin) for Xilinx FPGA devices --> ## 设备插件示例 {#examples} @@ -337,7 +337,7 @@ Here are some examples of device plugin implementations: * [RDMA device plugin](https://github.com/hustcat/k8s-rdma-device-plugin) * [Solarflare device plugin](https://github.com/vikaschoudhary16/sfc-device-plugin) * [SR-IOV Network device plugin](https://github.com/intel/sriov-network-device-plugin) -* [Xilinx FPGA device plugins](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin/trunk) +* [Xilinx FPGA device plugins](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin) ## {{% heading "whatsnext" %}} From 7323837ccbf30dce3a7d36203b2298d3cd5d3f54 Mon Sep 17 00:00:00 2001 From: Kiyoshi Muranaka Date: Mon, 22 Jun 2020 17:12:04 +0900 Subject: [PATCH 102/218] [ko] Fix broken link to Xilinx FPGA device plugins --- .../extend-kubernetes/compute-storage-net/device-plugins.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md index d75601de9f..f81289215e 100644 --- a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md +++ b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md @@ -222,7 +222,7 @@ pluginapi.Device{ID: "25102017", Health: pluginapi.Healthy, Topology:&pluginapi. * [RDMA 장치 플러그인](https://github.com/hustcat/k8s-rdma-device-plugin) * [Solarflare 장치 플러그인](https://github.com/vikaschoudhary16/sfc-device-plugin) * [SR-IOV 네트워크 장치 플러그인](https://github.com/intel/sriov-network-device-plugin) -* Xilinx FPGA 장치용 [Xilinx FPGA 장치 플러그인](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin/trunk) +* Xilinx FPGA 장치용 [Xilinx FPGA 장치 플러그인](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin) ## {{% heading "whatsnext" %}} From 976d81067cb35c22f3c8ad1a8e7d450a43311583 Mon Sep 17 00:00:00 2001 From: woblerr Date: Mon, 22 Jun 2020 11:34:11 +0300 Subject: [PATCH 103/218] translate into Russian: concepts-nodes; glossary-cloud-provider; glossary-controller --- .../ru/docs/concepts/architecture/_index.md | 5 + .../ru/docs/concepts/architecture/nodes.md | 340 ++++++++++++++++++ .../docs/reference/glossary/cloud-provider.md | 32 ++ .../ru/docs/reference/glossary/controller.md | 29 ++ 4 files changed, 406 insertions(+) create mode 100755 content/ru/docs/concepts/architecture/_index.md create mode 100644 content/ru/docs/concepts/architecture/nodes.md create mode 100755 content/ru/docs/reference/glossary/cloud-provider.md create mode 100755 content/ru/docs/reference/glossary/controller.md diff --git a/content/ru/docs/concepts/architecture/_index.md b/content/ru/docs/concepts/architecture/_index.md new file mode 100755 index 0000000000..eb68a67e53 --- /dev/null +++ b/content/ru/docs/concepts/architecture/_index.md @@ -0,0 +1,5 @@ +--- +title: "Кластерная Архитектура" +weight: 30 +--- + diff --git a/content/ru/docs/concepts/architecture/nodes.md b/content/ru/docs/concepts/architecture/nodes.md new file mode 100644 index 0000000000..1cd0a41ac2 --- /dev/null +++ b/content/ru/docs/concepts/architecture/nodes.md @@ -0,0 +1,340 @@ +--- +reviewers: +- caesarxuchao +- dchen1107 +title: Узлы +content_template: concept +weight: 10 +--- + + + +Kubernetes запускает ваши приложения, помещая контейнеры в Поды для запуска на Узлах (_Nodes_). +В зависимотри от кластера узел может быть виртуальной или физической машиной. Каждый узел +содержит сервисы, необходимые для запуска +{{< glossary_tooltip text="Подов" term_id="pod" >}}, управляемых +{{< glossary_tooltip text="плоскостью управления" term_id="control-plane" >}}. + +Обычно у вас есть несколько узлов в кластере; в среде обучения или среде +с ограниченными ресурсами у вас может быть только один. + +[Компоненты](/ru/docs/concepts/overview/components/##компоненты-узла) на узле включают +{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}, +{{< glossary_tooltip text="среду выполнения контейнера" term_id="container-runtime" >}} и +{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}. + + + +## Управление + +Существует два основных способа добавления Узлов в {{< glossary_tooltip text="API сервер" term_id="kube-apiserver" >}}: + +1. Kubelet на узле саморегистрируется узел в плоскости управления +2. Вы или другой пользователь вручную добавляете объект Узла + +После того как вы создадите объект Узла или kubelet на узле самозарегистируется, +плоскость управления проверяет, является ли новый объект Узла валидным (правильным). Например, если вы +попробуйте создать Узел при помощи следующего JSON манифеста: + +```json +{ + "kind": "Node", + "apiVersion": "v1", + "metadata": { + "name": "10.240.79.157", + "labels": { + "name": "my-first-k8s-node" + } + } +} +``` + +Kubernetes создает внутри себя объект Узла (представление). Kubernetes проверяет, +что kubelet зарегистрировался на API сервере, который совпадает с значением поля `metadata.name` Узла. +Если узел здоров (если все необходимые сервисы запущены), +он имеет право на запуск Пода. В противном случае, этот узел игнорируется для любой активности кластера +до тех пор, пока он не станет здоровым. + +{{< note >}} +Kubernetes сохраняет объект для невалидного Узла и продолжает проверять, становится ли он здоровым. + +Вы или {{< glossary_tooltip term_id="controller" text="контроллер">}} должны явно удалить объект Узла, чтобы +остановить проверку здоровья узла. +{{< /note >}} + +Имя объекта Узла дожно быть валидным +[именем поддомена DNS](/ru/docs/concepts/overview/working-with-objects/names#имена-поддоменов-dns). + +### Саморегистрация Узлов + +Когда kubelet флаг `--register-node` имеет значение _true_ (по умолчанию), то kubelet будет пытаться +зарегистрировать себя на API сервере. Это наиболее предпочтительная модель, используемая большиством дистрибутивов. + +Для саморегистрации kubelet запускается со следующими опциями: + + - `--kubeconfig` - Путь к учетным данным для аутентификации на API сервере. + - `--cloud-provider` - Как общаться с {{< glossary_tooltip text="облачным провайдером" term_id="cloud-provider" >}}, чтобы прочитать метаданные о себе. + - `--register-node` - Автоматически зарегистрироваться на API сервере. + - `--register-with-taints` - Зарегистрировать узел с приведенным списком {{< glossary_tooltip text="ограничений (taints)" term_id="taint" >}} (разделенных запятыми `=:`). + + Ничего не делает, если `register-node` - _false_. + - `--node-ip` - IP-адрес узла. + - `--node-labels` - {{< glossary_tooltip text="Метки" term_id="label" >}} для добавления при регистрации узла в кластере (смотрите ограничения для меток, установленные [плагином согласования (admission plugin) NodeRestriction](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)). + - `--node-status-update-frequency` - Указывает, как часто kubelet отправляет статус узла мастеру. + +Когда [режим авторизации Узла](/docs/reference/access-authn-authz/node/) и +[плагин согласования NodeRestriction](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) включены, +kubelet'ы имеют право только создавать/изменять свой собственный ресурс Узла. + +### Ручное администрирование узла + +Вы можете создавать и изменять объекты узла используя +{{< glossary_tooltip text="kubectl" term_id="kubectl" >}}. + +Когда вы хотите создать объекты Узла вручную, установите kubelet флаг `--register-node=false`. + +Вы можете изменять объекты Узла независимо от настройки `--register-node`. +Например, вы можете установить метки на существующем Узле или пометить его неназначаемым. + +Вы можете использовать метки на Узлах в сочетании с селекторами узла на Подах для управления планированием. +Например, вы можете ограничить Под иметь право на запуск только на группе доступных узлов. + +Маркировка узла как неназначаемого предотвращает размещение планировщиком новых подов на этом Узле, +но не влияет на существующие Поды на Узле. Это полезно в качестве +подготовительного шага перед перезагрузкой узла или другим обслуживанием. + +Чтобы отметить Узел неназначемым, выполните: + +```shell +kubectl cordon $NODENAME +``` + +{{< note >}} +Поды, являющиеся частью {{< glossary_tooltip term_id="daemonset" >}} допускают +запуск на неназначаемом Узле. DaemonSets обычно обеспечивает локальные сервисы узла, +которые должны запускаться на Узле, даже если узел вытесняется для запуска приложений. +{{< /note >}} + +## Статус Узла + +Статус узла содержит следующие данные: + +* [Адреса (Addresses)](#адреса) +* [Условия (Conditions)](#условие) +* [Емкость и Выделяемые ресурсы (Capacity and Allocatable)](#емкость) +* [Информация (Info)](#информация) + +Вы можете использовать `kubectl` для просмотра статуса Узла и других деталей: + +```shell +kubectl describe node +``` + +Каждая секция из вывода команды описана ниже. + +### Адреса (Addresses) + +Использование этих полей варьируется в зависимости от вашего облачного провайдера или конфигурации физических серверов (_bare metal_). + +* HostName: Имя хоста, сообщаемое ядром узла. Может быть переопределено через kubelet `--hostname-override` параметр. +* ExternalIP: Обычно, IP адрес узла, который является внешне маршрутизируемым (доступен за пределами кластера). +* InternalIP: Обычно, IP адрес узла, который маршрутизируется только внутри кластера. + +### Условия (Conditions) {#условие} + +Поле `conditions` описывает статус всех `Running` узлов. Примеры условий включают в себя: + +{{< table caption = "Условия узла и описание того, когда применяется каждое условие." >}} +| Условие Узла | Описание | +|----------------------|-------------| +| `Ready` | `True` если узел здоров и готов принять поды, `False` если узел нездоров и не принимает поды, и `Unknown` если контроллер узла не получал информацию от узла в течение последнего периода `node-monitor-grace-period` (по умолчанию 40 секунд) | +| `DiskPressure` | `True` если присутствует давление на размер диска - то есть, если емкость диска мала; иначе `False` | +| `MemoryPressure` | `True` если существует давление на память узла - то есть, если памяти на узле мало; иначе `False` | +| `PIDPressure` | `True` если существует давление на процессы - то есть, если на узле слишком много процессов; иначе `False` | +| `NetworkUnavailable` | `True` если сеть для узла настроена некорректно, иначе `False` | +{{< /table >}} + +{{< note >}} +Если вы используете инструменты командной строки для вывода сведений об блокированном узле, +то Условие включает `SchedulingDisabled`. `SchedulingDisabled` не является Условием в Kubernetes API; +вместо этого блокированные узлы помечены как Неназначемые в их спецификации. +{{< /note >}} + +Состояние узла представлено в виде JSON объекта. Например, следующая структура описывает здоровый узел: + +```json +"conditions": [ + { + "type": "Ready", + "status": "True", + "reason": "KubeletReady", + "message": "kubelet is posting ready status", + "lastHeartbeatTime": "2019-06-05T18:38:35Z", + "lastTransitionTime": "2019-06-05T11:41:27Z" + } +] +``` + +Если значение параметра Status для условия Ready остается `Unknown` или `False` +дольше чем период `pod-eviction-timeout`(аргумент, переданный в +{{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}), то все Поды +на узле планируются к удалению контроллером узла. По умолчанию таймаут выселения **пять минут**. +В некоторых случаях, когда узел недоступен, API сервер не может связаться с kubelet на узле. +Решение об удалении подов не может быть передано в kubelet до тех пор, пока связь с API сервером не будет восстановлена. +В то же время поды, которые запланированы к удалению, могут продолжать работать на отделенном узле. + +Контроллер узла не будет принудительно удалять поды до тех пор, пока не будет подтверждено, +что они перестали работать в кластере. Вы можете видеть, что поды, которые могут работать на недоступном узле, +находятся в состоянии `Terminating` или `Unknown`. В тех случаях, когда Kubernetes не может сделать вывод +из основной инфраструктуры о том, что узел окончательно покинул кластер, администратору кластера может потребоваться +удалить объект узла вручную. Удаление объекта узла из Kubernetes приводит к удалению всех объектов Подов, запущенных +на узле, с API сервера и освобождает их имена. + +Контроллер жизненного цикла узла автоматически создает +[ограничения (taints)](/docs/concepts/scheduling-eviction/taint-and-toleration/), которые представляют собой условия. +Планировщик учитывает ограничения Узла при назначении Пода на Узел. +Поды так же могут иметь допуски (tolerations), что позволяет им сопротивляться ограничениям Узла. + +Смотрите раздел [Ограничить Узлы по Условию](/docs/concepts/configuration/taint-and-toleration/#taint-nodes-by-condition) +для дополнительной информации. + +### Емкость и Выделяемые ресурсы (Capacity and Allocatable) {#емкость} + +Описывает ресурсы, доступные на узле: CPU, память и максимальное количество подов, +которые могут быть запланированы на узле. + +Поля в блоке capasity указывают общее количество ресурсов, которые есть на Узле. +Блок allocatable указывает количество ресурсовна Узле, +которые доступны для использования обычными Подами. + +Вы можете прочитать больше о емкости и выделяемых ресурсах, изучая, как [зарезервировать вычислительные ресурсы](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) на Узле. + +### Информация (Info) + +Описывает общую информацию об узле, такую как версия ядра, версия Kubernetes (версии kubelet и kube-proxy), версия Docker (если используется) и название ОС. +Эта информация соберается Kubelet'ом на узле. + +### Контроллер узла + +{{< glossary_tooltip text="Контроллер " term_id="controller" >}} узла является компонентом +плоскости управления Kubernetes, который управляет различными аспектами узлов. + +Контроллер узла играет различные роли в жизни узла. Первая - назначение CIDR-блока узлу +при его регистрации (если включено назначение CIDR). + +Вторая - поддержание в актуальном состоянии внутреннего списка узлов контроллера узла +согласно списку доступных машин облачного провайдера. При работе в облачной среде всякий раз, +когда узел неисправен, контроллер узла запрашивает облачного провайдера, доступна ли +виртуальная машина для этого узла. Если нет, то контроллер узла удаляет узел из +своего списка узлов. + +Третья - это мониторинг работоспособности узлов. Контроллер узла +отвечает за обновление условия NodeReady для NodeStatus на +ConditionUnknown, когда узел становится недоступным (т.е. контроллер узла +по какой-то причине перестает получать сердцебиения (heartbeats) от узла, +например, из-за того, что узел упал), и затем позже выселяет все поды с узла +(используя мягкое (graceful) завершение) если узел продолжает быть недоступным. +(По умолчанию таймауты составляют 40 секунд, чтобы начать сообщать `ConditionUnknown`, +и 5 минут после, чтобы начать выселять поды.) Контроллер узла проверяет состояние каждого узла +каждые `--node-monitor-period` секунд. + +#### Сердцебиения + +Сердцебиения, посылаемые узлами Kubernetes, помогают определить доступность узла. + +Существует две формы сердцебиений: обновление `NodeStatus` и +[Lease объект](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#lease-v1-coordination-k8s-io). +Каждый узел имеет связанный с ним Lease объект в `kube-node-lease` +{{< glossary_tooltip term_id="namespace" text="namespace">}}. +Lease - это легковестный ресурс, который улучшает производительность +сердцебиений узла при масштабировании кластера. + +Kubelet отвечает за создание и обновление `NodeStatus` и Lease объекта. + +- Kubelet обновляет `NodeStatus` либо когда происходит изменение статуса, + либо если в течение настронного интервала обновления не было. По умолчанию + интервал для обновлений `NodeStatus` составляет 5 минут (намного больше, + чем 40-секундный стандартный таймаут для недоступных узлов). +- Kubelet созадет и затем обновляет свой Lease объект каждый 10 секунд + (интервал обновления по умолчанию). Lease обновления происходят независимо от + `NodeStatus` обновлений. Если обновление Lease завершается неудачно, + kubelet повторяет попытку с экспоненциальным откатом, начинающимся с 200 миллисекунд и ограниченным 7 секундами. + +#### Надежность + +В большинстве случаев контроллер узла ограничивает скорость выселения +до `--node-eviction-rate` (по умолчанию 0,1) в секунду, что означает, +что он не выселяет поды с узлов быстрее чем c 1 узела в 10 секунд. + +Поведение выселения узла изменяется, когда узел в текущей зоне доступности +становится нездоровым. Контроллер узла проверяет, какой процент узлов в зоне +нездоров (NodeReady условие в значении ConditionUnknown или ConditiononFalse) +в одно и то же время. Если доля нездоровых узлов не меньше +`--unhealthy-zone-threshold` (по умолчанию 0.55), то скорость выселения уменьшается: +если кластер небольшой (т.е. количество узлов меньше или равно +`--large-cluster-size-threshold` - по умолчанию, 50), то выселения прекращаются, +в противном случае скорость выселения снижается до +`--secondary-node-eviction-rate` (по умолчанию, 0.01) в секунду. Причина, по которой +эти политики реализуются для каждой зоны доступности, заключается в том, +что одна зона доступности может стать отделенной от мастера, в то время как другие +остаются подключенными. Если ваш кластер не охватывает несколько зон доступности +облачного провайдера, то существует только одна зона доступности (весь кластер). + +Основная причина разнесения ваших узлов по зонам доступности заключается в том, +что приложения могут быть перенесены в здоровые зоны, когда одна из зон полностью +становится недоступной. Поэтому, если все узлы в зоне нездоровы, то контроллер узла +выселяет поды с нормальной скоростью `--node-eviction-rate`. Крайний случай - когда все зоны +полностью нездоровы (т.е. в кластере нет здоровых узлов). В таком случае +контроллер узла предполагает, что существует некоторая проблема с подключением к мастеру, +и останавеливает все выселения, пока какое-нибудь подключение не будет восстановлено. + +Контроллер узла также отвечает за выселение подов, запущенных на узлах с +`NoExecute` ограничениями, за исключением тех подов, которые сопротивляются этим ограничениям. +Контроллер узла так же добавляет {{< glossary_tooltip text="ограничения" term_id="taint" >}} +соотвествующие проблемам узла, таким как узел недоступен или не готов. Это означает, +что планировщик не будет размещать поды на нездоровых узлах. + +{{< caution >}} +`kubectl cordon` помечает узел как 'неназначемый', что имеет побочный эфект от контроллера сервисов, +удаляющего узел из любых списков целей LoadBalancer узла, на которые он ранее имел право, +эффектино убирая входящий трафик балансировщика нагрузки с блокированного узла(ов). +{{< /caution >}} + +### Емкость узла + +Объекты узла отслеживают информацию о емкости ресурсов узла (например, +объем доступной памяти и количество CPU). +Узлы, которые [самостоятельно зарегистировались](#саморегистрация-узлов) сообщают +о свое емкости во время регистрации. Если вы [вручную](#ручное-администрирование-узла) +добавляете узел, то вам нужно задать информацию о емкости узла при его добавлении. + +{{< glossary_tooltip text="Планировщик" term_id="kube-scheduler" >}} Kubernetes гарантирует, +что для всех Подов на Узле достаточно ресурсов. Планировщик проверяет, +что сумма requests от контейнеров на узле не превышает емкость узла. +Эта сумма requests включает все контейнеры, управляемые kubelet, +но исключает любые контейнеры, запущенные непосредственно средой выполнения контейнера, +а также исключает любые процессы, запущенные вне контроля kubelet. + +{{< note >}} +Если вы явно хотите зарезервировать ресурсы для процессов, не связанныз с Подами, смотрите раздел +[зарезервировать ресурсы для системных демонов](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved). +{{< /note >}} + +## Топология узла + +{{< feature-state state="alpha" for_k8s_version="v1.16" >}} + +Если вы включили `TopologyManager` +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/), то kubelet +может использовать подсказки топологии при принятии решений о выделении ресурсов. +Смотрите [Контроль Политик Управления Топологией на Узле](/docs/tasks/administer-cluster/topology-manager/) +для дополнительной информации. + +## {{% heading "whatsnext" %}} + +* Подробнее про[компоненты](/ru/docs/concepts/overview/components/#компоненты-узла) из которых состоит узел. +* Подробнее про [Определение API для Узла](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core). +* Подробнее про [Узлы](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) + of the architecture design document. +* Подробнее про [ограничения и допуски](/docs/concepts/configuration/taint-and-toleration/). +* Подробнее про [автомаштабирование кластера](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling). diff --git a/content/ru/docs/reference/glossary/cloud-provider.md b/content/ru/docs/reference/glossary/cloud-provider.md new file mode 100755 index 0000000000..55414a63ee --- /dev/null +++ b/content/ru/docs/reference/glossary/cloud-provider.md @@ -0,0 +1,32 @@ +--- +title: Облачный Провайдер (Cloud Provider) +id: cloud-provider +date: 2018-04-12 +full_link: /docs/concepts/cluster-administration/cloud-providers +short_description: > + Организация, которая предлагает платформу облачных вычислений. + +aka: +- Поставщик Облачных Услуг (Cloud Service Provider) +tags: +- community +--- + Бизнес или другая организация, которая предлагает платформу облачных вычислений. + + + +Облачные Провайдеры, иногда называемые Поставщиками Облачных Услуг (Cloud Service Provider, CSPs), +предлагают облачные вычислительные платформы или услуги. + +Многие облачные провайдеры предлагают управляемую инфраструктуру (также называемую +Инфраструктура как Услуга (Infrastructure as a Service) или IaaS). +С управляемой инфраструктурой облачный провайдер отвечает за +сервера, хранилище и сеть, в то время как вы управляете слоями поверх этого, +такими как запуск Kubernetes кластера. + +Вы также можете найти Kubernetes в качестве управляемого сервиса; иногда его называют +Платформа как Услуга (Platform as a Service) или PaaS. С упарвляемым Kubernetes +ваш облачный провайдер отвечает за +{{< glossary_tooltip term_id="control-plane" text="плоскость управления" >}} Kubernetes, а также за +{{< glossary_tooltip term_id="node" text="узлы" >}} и инфраструктуру, на которую они полагаются: +сеть, хранилище и, возможно, другие элементы, такие как балансировщики нагрузки. diff --git a/content/ru/docs/reference/glossary/controller.md b/content/ru/docs/reference/glossary/controller.md new file mode 100755 index 0000000000..c1efc41d1b --- /dev/null +++ b/content/ru/docs/reference/glossary/controller.md @@ -0,0 +1,29 @@ +--- +title: Контроллер (Controller) +id: controller +date: 2018-04-12 +full_link: /docs/concepts/architecture/controller/ +short_description: > + Управляющий цикл который отслеживает общее состояние кластера через API-сервер и вносит изменения пытаясь приветси текушее состояние к желаемому состоянию. + +aka: +tags: +- architecture +- fundamental +--- +Контроллеры в Kubernetes - управляющие циклы, которые отслеживают состояние вашего +{{< glossary_tooltip term_id="cluster" text="кластера">}}, затем вносят или запрашивают +изменения там, где это необходимо. +Каждый контроллер пытается привести текущее состояние кластера ближе к желаемому состоянию. + + + +Контроллеры отсллеживают общее состояние вашего кластера через +{{< glossary_tooltip text="API-сервер" term_id="kube-apiserver" >}} (часть +{{< glossary_tooltip text="плоскости управления" term_id="control-plane" >}}). + +Некоторые контроллеры также работают внутри плоскости управления, обеспечивая +управляющие циклы, которые являются ядром для операций Kubernetes. Например: +контроллер развертывания (deployment controller), контроллер daemonset (daemonset controller), +контроллер пространства имен (namespace controller) и контроллер постоянных томов (persistent volume +controller) (и другие) работают с {{< glossary_tooltip term_id="kube-controller-manager" >}}. From ffe0090d2ce5194a72a58c00abecb4ef0c86cdf9 Mon Sep 17 00:00:00 2001 From: Jerry Park Date: Mon, 22 Jun 2020 09:32:29 +0000 Subject: [PATCH 104/218] Fix with concepts/extend-kubernetes/api-extension/custom-resources/ --- .../extend-kubernetes/api-extension/custom-resources.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md index f2ca2e2435..bd7d27305e 100644 --- a/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md +++ b/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md @@ -178,7 +178,7 @@ Aggregated APIs offer more advanced API features and customization of other feat | Feature | Description | CRDs | Aggregated API | | ------- | ----------- | ---- | -------------- | -| Validation | Help users prevent errors and allow you to evolve your API independently of your clients. These features are most useful when there are many clients who can't all update at the same time. | Yes. Most validation can be specified in the CRD using [OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/extend-api-custom-resource-definitions/#validation). Any other validations supported by addition of a [Validating Webhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9). | Yes, arbitrary validation checks | +| Validation | Help users prevent errors and allow you to evolve your API independently of your clients. These features are most useful when there are many clients who can't all update at the same time. | Yes. Most validation can be specified in the CRD using [OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation). Any other validations supported by addition of a [Validating Webhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9). | Yes, arbitrary validation checks | | Defaulting | See above | Yes, either via [OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#defaulting) `default` keyword (GA in 1.17), or via a [Mutating Webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook) (though this will not be run when reading from etcd for old objects). | Yes | | Multi-versioning | Allows serving the same object through two API versions. Can help ease API changes like renaming fields. Less important if you control your client versions. | [Yes](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning) | Yes | | Custom Storage | If you need storage with a different performance mode (for example, a time-series database instead of key-value store) or isolation for security (for example, encryption of sensitive information, etc.) | No | Yes | From 8691fd5cf15207640021ce1cf567dac981e5d568 Mon Sep 17 00:00:00 2001 From: woblerr <45575813+woblerr@users.noreply.github.com> Date: Mon, 22 Jun 2020 13:24:21 +0300 Subject: [PATCH 105/218] Update content/ru/docs/concepts/architecture/nodes.md Co-authored-by: Nikita Potapenko --- content/ru/docs/concepts/architecture/nodes.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/content/ru/docs/concepts/architecture/nodes.md b/content/ru/docs/concepts/architecture/nodes.md index 1cd0a41ac2..7c10f75e1b 100644 --- a/content/ru/docs/concepts/architecture/nodes.md +++ b/content/ru/docs/concepts/architecture/nodes.md @@ -10,12 +10,12 @@ weight: 10 Kubernetes запускает ваши приложения, помещая контейнеры в Поды для запуска на Узлах (_Nodes_). -В зависимотри от кластера узел может быть виртуальной или физической машиной. Каждый узел +В зависимости от кластера, узел может быть виртуальной или физической машиной. Каждый узел содержит сервисы, необходимые для запуска {{< glossary_tooltip text="Подов" term_id="pod" >}}, управляемых {{< glossary_tooltip text="плоскостью управления" term_id="control-plane" >}}. -Обычно у вас есть несколько узлов в кластере; в среде обучения или среде +Обычно у вас есть несколько узлов в кластере; однако в среде обучения или среде с ограниченными ресурсами у вас может быть только один. [Компоненты](/ru/docs/concepts/overview/components/##компоненты-узла) на узле включают @@ -29,12 +29,12 @@ Kubernetes запускает ваши приложения, помещая ко Существует два основных способа добавления Узлов в {{< glossary_tooltip text="API сервер" term_id="kube-apiserver" >}}: -1. Kubelet на узле саморегистрируется узел в плоскости управления +1. Kubelet на узле саморегистрируется в плоскости управления 2. Вы или другой пользователь вручную добавляете объект Узла -После того как вы создадите объект Узла или kubelet на узле самозарегистируется, +После того, как вы создадите объект Узла или kubelet на узле самозарегистируется, плоскость управления проверяет, является ли новый объект Узла валидным (правильным). Например, если вы -попробуйте создать Узел при помощи следующего JSON манифеста: +попробуете создать Узел при помощи следующего JSON манифеста: ```json { @@ -59,7 +59,7 @@ Kubernetes создает внутри себя объект Узла (пред Kubernetes сохраняет объект для невалидного Узла и продолжает проверять, становится ли он здоровым. Вы или {{< glossary_tooltip term_id="controller" text="контроллер">}} должны явно удалить объект Узла, чтобы -остановить проверку здоровья узла. +остановить проверку доступности узла. {{< /note >}} Имя объекта Узла дожно быть валидным From 11c6aec3424ba74a7cf5935be677dbbfc1ab11b2 Mon Sep 17 00:00:00 2001 From: "Orwill Q. Song" Date: Mon, 22 Jun 2020 19:42:52 +0800 Subject: [PATCH 106/218] Annotate redundant English part --- content/zh/docs/setup/release/version-skew-policy.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/content/zh/docs/setup/release/version-skew-policy.md b/content/zh/docs/setup/release/version-skew-policy.md index 25bfbb8cf6..1eeadd2276 100644 --- a/content/zh/docs/setup/release/version-skew-policy.md +++ b/content/zh/docs/setup/release/version-skew-policy.md @@ -58,7 +58,9 @@ Minor releases occur approximately every 3 months, so each minor release branch ### kube-apiserver + 在 [高可用（HA）集群](/docs/setup/production-environment/tools/kubeadm/high-availability/) 中， 多个 `kube-apiserver` 实例小版本号最多差1。 From ae31c48889b464661ec8332a57349108623d8051 Mon Sep 17 00:00:00 2001 From: "Orwill Q. Song" Date: Mon, 22 Jun 2020 20:08:15 +0800 Subject: [PATCH 107/218] Translate few titles to Chinese. --- content/zh/docs/setup/release/version-skew-policy.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/content/zh/docs/setup/release/version-skew-policy.md b/content/zh/docs/setup/release/version-skew-policy.md index 1eeadd2276..0bc7b4e4e0 100644 --- a/content/zh/docs/setup/release/version-skew-policy.md +++ b/content/zh/docs/setup/release/version-skew-policy.md @@ -22,7 +22,10 @@ Specific cluster deployment tools may place additional restrictions on version s + +## 版本支持策略 小版本大约每3个月发布一个，所以每个小版本分支会维护9个月。 + +## 版本倾斜策略 ### kube-apiserver @@ -111,7 +117,10 @@ Example: * 如果 `kube-apiserver` 的多个实例同时存在 **1.13** 和 **1.12** * `kubelet` 只能是 **1.12** 或 **1.11**（**1.13** 不再支持，因为它比**1.12**版本的 `kube-apiserver` 更新） + +### kube-controller-manager、 kube-scheduler 和 cloud-controller-manager +### kube-controller-manager、 kube-scheduler 和 cloud-controller-manager -Akun servis (_service account_) menyediakan identitas untuk proses yang sedang berjalan dalam sebuah Pod. +ServiceAccount menyediakan identitas untuk proses yang sedang berjalan dalam sebuah Pod. {{< note >}} -Dokumen ini digunakan sebagai pengenalan untuk pengguna terhadap _Service Account_ dan menjelaskan bagaimana perilaku _service account_ dalam konfigurasi kluster seperti yang direkomendasikan Kubernetes. Pengubahan perilaku yang bisa saja dilakukan administrator kluster terhadap kluster tidak menjadi bagian pembahasan dokumentasi ini. +Dokumen ini digunakan sebagai pengenalan untuk pengguna terhadap ServiceAccount dan menjelaskan bagaimana perilaku ServiceAccount dalam konfigurasi kluster seperti yang direkomendasikan Kubernetes. Pengubahan perilaku yang bisa saja dilakukan administrator kluster terhadap kluster tidak menjadi bagian pembahasan dokumentasi ini. {{< /note >}} -Ketika kamu mengakses kluster (contohnya menggunakan `kubectl`), kamu terautentikasi oleh apiserver sebagai sebuah User Account (untuk sekarang umumnya sebagai `admin`, kecuali jika administrator klustermu telah melakukan pengubahan). Berbagai proses yang ada di dalam kontainer dalam pod juga dapat mengontak apiserver. Ketika itu terjadi, mereka akan diautentikasi sebagai sebuah Service Account (contohnya sebagai `default`). +Ketika kamu mengakses kluster (contohnya menggunakan `kubectl`), kamu terautentikasi oleh apiserver sebagai sebuah User Account (untuk sekarang umumnya sebagai `admin`, kecuali jika administrator klustermu telah melakukan pengubahan). Berbagai proses yang ada di dalam kontainer dalam pod juga dapat mengontak apiserver. Ketika itu terjadi, mereka akan diautentikasi sebagai sebuah ServiceAccount (contohnya sebagai `default`). @@ -25,14 +25,14 @@ Ketika kamu mengakses kluster (contohnya menggunakan `kubectl`), kamu terautenti -## Menggunakan Default Service Account untuk Mengakses API server. +## Menggunakan Default ServiceAccount untuk Mengakses API server. -Ketika kamu membuat sebuah pod, jika kamu tidak menentukan sebuah _service account_, maka ia akan otomatis ditetapkan sebagai _service account_`default` di namespace yang sama. Jika kamu mendapatkan json atau yaml mentah untuk sebuah pod yang telah kamu buat (contohnya menggunakan `kubectl get pods/ -o yaml`), kamu akan melihat _field_ `spec.serviceAccountName` yang telah secara [otomatis ditentukan](/docs/user-guide/working-with-resources/#resources-are-automatically-modified). +Ketika kamu membuat sebuah pod, jika kamu tidak menentukan sebuah ServiceAccount, maka ia akan otomatis ditetapkan sebagai ServiceAccount`default` di namespace yang sama. Jika kamu mendapatkan json atau yaml mentah untuk sebuah pod yang telah kamu buat (contohnya menggunakan `kubectl get pods/ -o yaml`), kamu akan melihat _field_ `spec.serviceAccountName` yang telah secara [otomatis ditentukan](/docs/user-guide/working-with-resources/#resources-are-automatically-modified). -Kamu dapat mengakses API dari dalam pod menggunakan kredensial _service account_ yang ditambahkan secara otomatis seperti yang dijelaskan dalam [Mengakses Klaster](/docs/user-guide/accessing-the-cluster/#accessing-the-api-from-a-pod). -Hak akses API dari _service account_ menyesuaikan dengan [kebijakan dan plugin otorisasi](/docs/reference/access-authn-authz/authorization/#authorization-modules) yang sedang digunakan. +Kamu dapat mengakses API dari dalam pod menggunakan kredensial ServiceAccount yang ditambahkan secara otomatis seperti yang dijelaskan dalam [Mengakses Klaster](/docs/user-guide/accessing-the-cluster/#accessing-the-api-from-a-pod). +Hak akses API dari ServiceAccount menyesuaikan dengan [kebijakan dan plugin otorisasi](/docs/reference/access-authn-authz/authorization/#authorization-modules) yang sedang digunakan. -Di versi 1.6+, kamu dapat tidak memilih _automounting_ kredensial API dari sebuah _service account_ dengan mengatur `automountServiceAccountToken: false` pada _service account_: +Di versi 1.6+, kamu dapat tidak memilih _automounting_ kredensial API dari sebuah ServiceAccount dengan mengatur `automountServiceAccountToken: false` pada ServiceAccount: ```yaml apiVersion: v1 @@ -56,11 +56,11 @@ spec: ... ``` -Pengaturan dari spesifikasi pod didahulukan dibanding _service account_ jika keduanya menentukan nilai dari `automountServiceAccountToken`. +Pengaturan dari spesifikasi pod didahulukan dibanding ServiceAccount jika keduanya menentukan nilai dari `automountServiceAccountToken`. -## Menggunakan Beberapa Service Account. +## Menggunakan Beberapa ServiceAccount. -Setiap namespace memiliki _resource_ _service account_ standar `default`. +Setiap namespace memiliki _resource_ ServiceAccount standar `default`. Kamu dapat melihatnya dan _resource_ serviceAccount lainnya di namespace tersebut dengan perintah: ```shell @@ -86,7 +86,7 @@ EOF Nama dari obyek ServiceAccount haruslah sebuah [nama subdomain DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) yang valid. -Jika kamu mendapatkan obyek _service account_ secara komplit, seperti ini: +Jika kamu mendapatkan obyek ServiceAccount secara komplit, seperti ini: ```shell kubectl get serviceaccounts/build-robot -o yaml @@ -106,25 +106,25 @@ secrets: - name: build-robot-token-bvbk5 ``` -maka kamu dapat melihat bahwa _token_ telah dibuat secara otomatis dan dirujuk oleh _service account_. +maka kamu dapat melihat bahwa _token_ telah dibuat secara otomatis dan dirujuk oleh ServiceAccount. -Kamu dapat menggunakan _plugin_ otorisasi untuk [mengatur hak akses dari service account](/docs/reference/access-authn-authz/rbac/#service-account-permissions). +Kamu dapat menggunakan _plugin_ otorisasi untuk [mengatur hak akses dari ServiceAccount](/docs/reference/access-authn-authz/rbac/#service-account-permissions). -Untuk menggunakan _service account_ selain nilai standar, atur _field_ `spec.serviceAccountName` dari pod menjadi nama dari _service account_ yang hendak kamu gunakan. +Untuk menggunakan ServiceAccount selain nilai standar, atur _field_ `spec.serviceAccountName` dari pod menjadi nama dari ServiceAccount yang hendak kamu gunakan. _Service account_ harus ada ketika pod dibuat, jika tidak maka akan ditolak. -Kamu tidak dapat memperbarui _service account_ dari pod yang telah dibuat. +Kamu tidak dapat memperbarui ServiceAccount dari pod yang telah dibuat. -Kamu dapat menghapus _service account_ dari contoh seperti ini: +Kamu dapat menghapus ServiceAccount dari contoh seperti ini: ```shell kubectl delete serviceaccount/build-robot ``` -## Membuat token API service account secara manual. +## Membuat token API ServiceAccount secara manual. -Asumsikan kita memiliki _service account_ dengan nama "build-robot" seperti yang disebukan di atas, dan kita membuat _secret_ secara manual. +Asumsikan kita memiliki ServiceAccount dengan nama "build-robot" seperti yang disebukan di atas, dan kita membuat _secret_ secara manual. ```shell kubectl apply -f - <}} -## Menambahkan ImagePullSecrets ke service account. +## Menambahkan ImagePullSecrets ke ServiceAccount. ### Membuat imagePullSecret @@ -191,9 +191,9 @@ Isi dari `token` tidak dirinci di sini. myregistrykey   kubernetes.io/.dockerconfigjson   1       1d ``` -### Menambahkan imagePullSecret ke service account +### Menambahkan imagePullSecret ke ServiceAccount -Selanjutnya, modifikasi _service account_ standar dari namespace untuk menggunakan _secret_ ini sebagai imagePullSecret. +Selanjutnya, modifikasi ServiceAccount standar dari namespace untuk menggunakan _secret_ ini sebagai imagePullSecret. ```shell @@ -260,12 +260,12 @@ Keluarannya adalah: myregistrykey ``` - -## Service Account Token Volume Projection +## ServiceAccount Token Volume Projection {{< feature-state for_k8s_version="v1.12" state="beta" >}} @@ -278,7 +278,7 @@ ServiceAccountTokenVolumeProjection masih dalam tahap __beta__ untuk versi 1.12 {{< /note >}} -Kubelet juga dapat memproyeksikan _token_ _service account_ ke Pod. Kamu dapat menentukan properti yang diinginkan dari _token_ seperti target pengguna dan durasi validitas. Properti tersebut tidak dapat diubah pada _token_ _service account_ standar. _Token_ _service account_ juga akan menjadi tidak valid terhadap API ketika Pod atau ServiceAccount dihapus. +Kubelet juga dapat memproyeksikan _token_ ServiceAccount ke Pod. Kamu dapat menentukan properti yang diinginkan dari _token_ seperti target pengguna dan durasi validitas. Properti tersebut tidak dapat diubah pada _token_ ServiceAccount standar. _Token_ ServiceAccount juga akan menjadi tidak valid terhadap API ketika Pod atau ServiceAccount dihapus. Perilaku ini diatur pada PodSpec menggunakan tipe ProjectedVolume yaitu [ServiceAccountToken](/docs/concepts/storage/volumes/#projected). Untuk memungkinkan pod dengan _token_ dengan pengguna bertipe _"vault"_ dan durasi validitas selama dua jam, kamu harus mengubah bagian ini pada PodSpec: @@ -294,7 +294,7 @@ Kubelet akan me-_request_ dan menyimpan _token_ mewakili pod, buat _token_ dapat Aplikasi bertanggung jawab untuk memuat ulang _token_ ketika terjadi penggantian. Pemuatan ulang teratur (misalnya sekali setiap 5 menit) cukup untuk mencakup kebanyakan kasus. -## Service Account Issuer Discovery +## ServiceAccount Issuer Discovery {{< feature-state for_k8s_version="v1.18" state="alpha" >}} @@ -306,17 +306,17 @@ URL _issuer_ harus sesuai dengan _[OIDC Discovery Spec](https://openid.net/specs Jika URL tidak sesuai dengan aturan, _endpoint_ `ServiceAccountIssuerDiscovery` tidak akan didaftarkan meskipun fitur telah diaktifkan. {{< /note >}} -Fitur _Service Account Issuer Discovery_ memungkinkan federasi dari berbagai _token_ _service account_ Kubernetes yang dibuat oleh sebuah kluster (penyedia identitas) dan sistem eksternal. +Fitur _Service Account Issuer Discovery_ memungkinkan federasi dari berbagai _token_ ServiceAccount Kubernetes yang dibuat oleh sebuah kluster (penyedia identitas) dan sistem eksternal. Ketika diaktifkan, _server_ API Kubernetes menyediakan dokumen OpenID Provider Configuration pada `/.well-known/openid-configuration` dan JSON Web Key Set (JWKS) terkait pada `/openid/v1/jwks`. OpenID Provider Configuration terkadang disebut juga dengan sebutan _discovery document_. Ketika diaktifkan, kluster juga dikonfigurasi dengan RBAC ClusterRole standar yaitu `system:service-account-issuer-discovery`. _Role binding_ tidak disediakan secara _default_. Administrator dimungkinkan untuk, sebagai contoh, menentukan apakah peran akan disematkan ke `system:authenticated` atau `system:unauthenticated` tergantung terhadap kebutuhan keamanan dan sistem eksternal yang direncakanan untuk diintegrasikan. {{< note >}} -Respons yang disediakan pada `/.well-known/openid-configuration` dan`/openid/v1/jwks` dirancang untuk kompatibel dengan OIDC, tetapi tidak sepenuhnya sesuai dengan ketentuan OIDC. Dokumen tersebut hanya berisi parameter yang dibutuhkan untuk melakukan validasi terhadap _token_ _service account_ Kubernetes. +Respons yang disediakan pada `/.well-known/openid-configuration` dan`/openid/v1/jwks` dirancang untuk kompatibel dengan OIDC, tetapi tidak sepenuhnya sesuai dengan ketentuan OIDC. Dokumen tersebut hanya berisi parameter yang dibutuhkan untuk melakukan validasi terhadap _token_ ServiceAccount Kubernetes. {{< /note >}} -Respons JWKS memuat kunci publik yang dapat digunakan oleh sistem eksternal untuk melakukan validasi _token_ _service account_ Kubernetes. Awalnya sistem eksternal akan mengkueri OpenID Provider Configuration, dan selanjutnya dapat menggunakan _field_ `jwks_uri` pada respons kueri untuk mendapatkan JWKS. +Respons JWKS memuat kunci publik yang dapat digunakan oleh sistem eksternal untuk melakukan validasi _token_ ServiceAccount Kubernetes. Awalnya sistem eksternal akan mengkueri OpenID Provider Configuration, dan selanjutnya dapat menggunakan _field_ `jwks_uri` pada respons kueri untuk mendapatkan JWKS. Pada banyak kasus, _server_ API Kubernetes tidak tersedia di internet publik, namun _endpoint_ publik yang menyediakan respons hasil _cache_ dari _server_ API dapat dibuat menjadi tersedia oleh pengguna atau penyedia servis. Pada kasus ini, dimungkinkan untuk mengganti `jwks_uri` pada OpenID Provider Configuration untuk diarahkan ke _endpoint_ publik sebagai ganti alamat _server_ API dengan memberikan _flag_ `--service-account-jwks-uri` ke API server. serupa dengan URL _issuer_, URI JWKS diharuskan untuk menggunakan skema `https`. @@ -326,8 +326,8 @@ Pada banyak kasus, _server_ API Kubernetes tidak tersedia di internet publik, na Lihat juga: -- [Panduan Admin Kluster mengenai Service Account](/docs/reference/access-authn-authz/service-accounts-admin/) -- [Service Account Signing Key Retrieval KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/20190730-oidc-discovery.md) +- [Panduan Admin Kluster mengenai ServiceAccount](/docs/reference/access-authn-authz/service-accounts-admin/) +- [ServiceAccount Signing Key Retrieval KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/20190730-oidc-discovery.md) - [OIDC Discovery Spec](https://openid.net/specs/openid-connect-discovery-1_0.html) From c9acaa521f492c174364e27e33798916e26de07d Mon Sep 17 00:00:00 2001 From: joshuabezaleel Date: Tue, 23 Jun 2020 11:08:20 +0700 Subject: [PATCH 114/218] kluster to klaster --- .../configure-pod-container/configure-service-account.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/id/docs/tasks/configure-pod-container/configure-service-account.md b/content/id/docs/tasks/configure-pod-container/configure-service-account.md index f62d3d0bfd..1a10aed15c 100644 --- a/content/id/docs/tasks/configure-pod-container/configure-service-account.md +++ b/content/id/docs/tasks/configure-pod-container/configure-service-account.md @@ -8,10 +8,10 @@ weight: 90 ServiceAccount menyediakan identitas untuk proses yang sedang berjalan dalam sebuah Pod. {{< note >}} -Dokumen ini digunakan sebagai pengenalan untuk pengguna terhadap ServiceAccount dan menjelaskan bagaimana perilaku ServiceAccount dalam konfigurasi kluster seperti yang direkomendasikan Kubernetes. Pengubahan perilaku yang bisa saja dilakukan administrator kluster terhadap kluster tidak menjadi bagian pembahasan dokumentasi ini. +Dokumen ini digunakan sebagai pengenalan untuk pengguna terhadap ServiceAccount dan menjelaskan bagaimana perilaku ServiceAccount dalam konfigurasi klaster seperti yang direkomendasikan Kubernetes. Pengubahan perilaku yang bisa saja dilakukan administrator klaster terhadap klaster tidak menjadi bagian pembahasan dokumentasi ini. {{< /note >}} -Ketika kamu mengakses kluster (contohnya menggunakan `kubectl`), kamu terautentikasi oleh apiserver sebagai sebuah User Account (untuk sekarang umumnya sebagai `admin`, kecuali jika administrator klustermu telah melakukan pengubahan). Berbagai proses yang ada di dalam kontainer dalam pod juga dapat mengontak apiserver. Ketika itu terjadi, mereka akan diautentikasi sebagai sebuah ServiceAccount (contohnya sebagai `default`). +Ketika kamu mengakses klaster (contohnya menggunakan `kubectl`), kamu terautentikasi oleh apiserver sebagai sebuah User Account (untuk sekarang umumnya sebagai `admin`, kecuali jika administrator klustermu telah melakukan pengubahan). Berbagai proses yang ada di dalam kontainer dalam pod juga dapat mengontak apiserver. Ketika itu terjadi, mereka akan diautentikasi sebagai sebuah ServiceAccount (contohnya sebagai `default`). @@ -306,11 +306,11 @@ URL _issuer_ harus sesuai dengan _[OIDC Discovery Spec](https://openid.net/specs Jika URL tidak sesuai dengan aturan, _endpoint_ `ServiceAccountIssuerDiscovery` tidak akan didaftarkan meskipun fitur telah diaktifkan. {{< /note >}} -Fitur _Service Account Issuer Discovery_ memungkinkan federasi dari berbagai _token_ ServiceAccount Kubernetes yang dibuat oleh sebuah kluster (penyedia identitas) dan sistem eksternal. +Fitur _Service Account Issuer Discovery_ memungkinkan federasi dari berbagai _token_ ServiceAccount Kubernetes yang dibuat oleh sebuah klaster (penyedia identitas) dan sistem eksternal. Ketika diaktifkan, _server_ API Kubernetes menyediakan dokumen OpenID Provider Configuration pada `/.well-known/openid-configuration` dan JSON Web Key Set (JWKS) terkait pada `/openid/v1/jwks`. OpenID Provider Configuration terkadang disebut juga dengan sebutan _discovery document_. -Ketika diaktifkan, kluster juga dikonfigurasi dengan RBAC ClusterRole standar yaitu `system:service-account-issuer-discovery`. _Role binding_ tidak disediakan secara _default_. Administrator dimungkinkan untuk, sebagai contoh, menentukan apakah peran akan disematkan ke `system:authenticated` atau `system:unauthenticated` tergantung terhadap kebutuhan keamanan dan sistem eksternal yang direncakanan untuk diintegrasikan. +Ketika diaktifkan, klaster juga dikonfigurasi dengan RBAC ClusterRole standar yaitu `system:service-account-issuer-discovery`. _Role binding_ tidak disediakan secara _default_. Administrator dimungkinkan untuk, sebagai contoh, menentukan apakah peran akan disematkan ke `system:authenticated` atau `system:unauthenticated` tergantung terhadap kebutuhan keamanan dan sistem eksternal yang direncakanan untuk diintegrasikan. {{< note >}} Respons yang disediakan pada `/.well-known/openid-configuration` dan`/openid/v1/jwks` dirancang untuk kompatibel dengan OIDC, tetapi tidak sepenuhnya sesuai dengan ketentuan OIDC. Dokumen tersebut hanya berisi parameter yang dibutuhkan untuk melakukan validasi terhadap _token_ ServiceAccount Kubernetes. From b1aa8c0469bd584f15bd795c0f3d885f82cc2ea4 Mon Sep 17 00:00:00 2001 From: joshuabezaleel Date: Tue, 23 Jun 2020 11:08:48 +0700 Subject: [PATCH 115/218] User Account to akun pengguna --- .../tasks/configure-pod-container/configure-service-account.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/id/docs/tasks/configure-pod-container/configure-service-account.md b/content/id/docs/tasks/configure-pod-container/configure-service-account.md index 1a10aed15c..8f3f02516c 100644 --- a/content/id/docs/tasks/configure-pod-container/configure-service-account.md +++ b/content/id/docs/tasks/configure-pod-container/configure-service-account.md @@ -11,7 +11,7 @@ ServiceAccount menyediakan identitas untuk proses yang sedang berjalan dalam seb Dokumen ini digunakan sebagai pengenalan untuk pengguna terhadap ServiceAccount dan menjelaskan bagaimana perilaku ServiceAccount dalam konfigurasi klaster seperti yang direkomendasikan Kubernetes. Pengubahan perilaku yang bisa saja dilakukan administrator klaster terhadap klaster tidak menjadi bagian pembahasan dokumentasi ini. {{< /note >}} -Ketika kamu mengakses klaster (contohnya menggunakan `kubectl`), kamu terautentikasi oleh apiserver sebagai sebuah User Account (untuk sekarang umumnya sebagai `admin`, kecuali jika administrator klustermu telah melakukan pengubahan). Berbagai proses yang ada di dalam kontainer dalam pod juga dapat mengontak apiserver. Ketika itu terjadi, mereka akan diautentikasi sebagai sebuah ServiceAccount (contohnya sebagai `default`). +Ketika kamu mengakses klaster (contohnya menggunakan `kubectl`), kamu terautentikasi oleh apiserver sebagai sebuah akun pengguna (untuk sekarang umumnya sebagai `admin`, kecuali jika administrator klustermu telah melakukan pengubahan). Berbagai proses yang ada di dalam kontainer dalam pod juga dapat mengontak apiserver. Ketika itu terjadi, mereka akan diautentikasi sebagai sebuah ServiceAccount (contohnya sebagai `default`). From 6a68161f61dc189c55e4d9d7f5ee7d72891c7989 Mon Sep 17 00:00:00 2001 From: joshuabezaleel Date: Tue, 23 Jun 2020 11:13:44 +0700 Subject: [PATCH 116/218] pod to Pod --- .../configure-service-account.md | 22 +++++++++---------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/content/id/docs/tasks/configure-pod-container/configure-service-account.md b/content/id/docs/tasks/configure-pod-container/configure-service-account.md index 8f3f02516c..065cfd25ad 100644 --- a/content/id/docs/tasks/configure-pod-container/configure-service-account.md +++ b/content/id/docs/tasks/configure-pod-container/configure-service-account.md @@ -11,7 +11,7 @@ ServiceAccount menyediakan identitas untuk proses yang sedang berjalan dalam seb Dokumen ini digunakan sebagai pengenalan untuk pengguna terhadap ServiceAccount dan menjelaskan bagaimana perilaku ServiceAccount dalam konfigurasi klaster seperti yang direkomendasikan Kubernetes. Pengubahan perilaku yang bisa saja dilakukan administrator klaster terhadap klaster tidak menjadi bagian pembahasan dokumentasi ini. {{< /note >}} -Ketika kamu mengakses klaster (contohnya menggunakan `kubectl`), kamu terautentikasi oleh apiserver sebagai sebuah akun pengguna (untuk sekarang umumnya sebagai `admin`, kecuali jika administrator klustermu telah melakukan pengubahan). Berbagai proses yang ada di dalam kontainer dalam pod juga dapat mengontak apiserver. Ketika itu terjadi, mereka akan diautentikasi sebagai sebuah ServiceAccount (contohnya sebagai `default`). +Ketika kamu mengakses klaster (contohnya menggunakan `kubectl`), kamu terautentikasi oleh apiserver sebagai sebuah akun pengguna (untuk sekarang umumnya sebagai `admin`, kecuali jika administrator klustermu telah melakukan pengubahan). Berbagai proses yang ada di dalam kontainer dalam Pod juga dapat mengontak apiserver. Ketika itu terjadi, mereka akan diautentikasi sebagai sebuah ServiceAccount (contohnya sebagai `default`). @@ -27,9 +27,9 @@ Ketika kamu mengakses klaster (contohnya menggunakan `kubectl`), kamu terautenti ## Menggunakan Default ServiceAccount untuk Mengakses API server. -Ketika kamu membuat sebuah pod, jika kamu tidak menentukan sebuah ServiceAccount, maka ia akan otomatis ditetapkan sebagai ServiceAccount`default` di namespace yang sama. Jika kamu mendapatkan json atau yaml mentah untuk sebuah pod yang telah kamu buat (contohnya menggunakan `kubectl get pods/ -o yaml`), kamu akan melihat _field_ `spec.serviceAccountName` yang telah secara [otomatis ditentukan](/docs/user-guide/working-with-resources/#resources-are-automatically-modified). +Ketika kamu membuat sebuah Pod, jika kamu tidak menentukan sebuah ServiceAccount, maka ia akan otomatis ditetapkan sebagai ServiceAccount`default` di namespace yang sama. Jika kamu mendapatkan json atau yaml mentah untuk sebuah Pod yang telah kamu buat (contohnya menggunakan `kubectl get pods/ -o yaml`), kamu akan melihat _field_ `spec.serviceAccountName` yang telah secara [otomatis ditentukan](/docs/user-guide/working-with-resources/#resources-are-automatically-modified). -Kamu dapat mengakses API dari dalam pod menggunakan kredensial ServiceAccount yang ditambahkan secara otomatis seperti yang dijelaskan dalam [Mengakses Klaster](/docs/user-guide/accessing-the-cluster/#accessing-the-api-from-a-pod). +Kamu dapat mengakses API dari dalam Pod menggunakan kredensial ServiceAccount yang ditambahkan secara otomatis seperti yang dijelaskan dalam [Mengakses Klaster](/docs/user-guide/accessing-the-cluster/#accessing-the-api-from-a-pod). Hak akses API dari ServiceAccount menyesuaikan dengan [kebijakan dan plugin otorisasi](/docs/reference/access-authn-authz/authorization/#authorization-modules) yang sedang digunakan. Di versi 1.6+, kamu dapat tidak memilih _automounting_ kredensial API dari sebuah ServiceAccount dengan mengatur `automountServiceAccountToken: false` pada ServiceAccount: @@ -43,7 +43,7 @@ automountServiceAccountToken: false ... ``` -Di versi 1.6+, kamu juga dapat tidak memilih _automounting_ kredensial API dari suatu pod tertentu: +Di versi 1.6+, kamu juga dapat tidak memilih _automounting_ kredensial API dari suatu Pod tertentu: ```yaml apiVersion: v1 @@ -56,7 +56,7 @@ spec: ... ``` -Pengaturan dari spesifikasi pod didahulukan dibanding ServiceAccount jika keduanya menentukan nilai dari `automountServiceAccountToken`. +Pengaturan dari spesifikasi Pod didahulukan dibanding ServiceAccount jika keduanya menentukan nilai dari `automountServiceAccountToken`. ## Menggunakan Beberapa ServiceAccount. @@ -110,11 +110,11 @@ maka kamu dapat melihat bahwa _token_ telah dibuat secara otomatis dan dirujuk o Kamu dapat menggunakan _plugin_ otorisasi untuk [mengatur hak akses dari ServiceAccount](/docs/reference/access-authn-authz/rbac/#service-account-permissions). -Untuk menggunakan ServiceAccount selain nilai standar, atur _field_ `spec.serviceAccountName` dari pod menjadi nama dari ServiceAccount yang hendak kamu gunakan. +Untuk menggunakan ServiceAccount selain nilai standar, atur _field_ `spec.serviceAccountName` dari Pod menjadi nama dari ServiceAccount yang hendak kamu gunakan. -_Service account_ harus ada ketika pod dibuat, jika tidak maka akan ditolak. +_Service account_ harus ada ketika Pod dibuat, jika tidak maka akan ditolak. -Kamu tidak dapat memperbarui ServiceAccount dari pod yang telah dibuat. +Kamu tidak dapat memperbarui ServiceAccount dari Pod yang telah dibuat. Kamu dapat menghapus ServiceAccount dari contoh seperti ini: @@ -245,7 +245,7 @@ Terakhir ganti serviceaccount dengan _file_ `sa.yaml` yang telah diperbarui. kubectl replace serviceaccount default -f ./sa.yaml ``` -### Memverifikasi imagePullSecrets sudah ditambahkan ke spesifikasi pod +### Memverifikasi imagePullSecrets sudah ditambahkan ke spesifikasi Pod Ketika Pod baru dibuat dalam namespace yang sedang aktif dan menggunakan ServiceAccount, Pod baru akan memiliki _field_ `spec.imagePullSecrets` yang ditentukan secara otomatis: @@ -280,7 +280,7 @@ ServiceAccountTokenVolumeProjection masih dalam tahap __beta__ untuk versi 1.12 Kubelet juga dapat memproyeksikan _token_ ServiceAccount ke Pod. Kamu dapat menentukan properti yang diinginkan dari _token_ seperti target pengguna dan durasi validitas. Properti tersebut tidak dapat diubah pada _token_ ServiceAccount standar. _Token_ ServiceAccount juga akan menjadi tidak valid terhadap API ketika Pod atau ServiceAccount dihapus. -Perilaku ini diatur pada PodSpec menggunakan tipe ProjectedVolume yaitu [ServiceAccountToken](/docs/concepts/storage/volumes/#projected). Untuk memungkinkan pod dengan _token_ dengan pengguna bertipe _"vault"_ dan durasi validitas selama dua jam, kamu harus mengubah bagian ini pada PodSpec: +Perilaku ini diatur pada PodSpec menggunakan tipe ProjectedVolume yaitu [ServiceAccountToken](/docs/concepts/storage/volumes/#projected). Untuk memungkinkan Pod dengan _token_ dengan pengguna bertipe _"vault"_ dan durasi validitas selama dua jam, kamu harus mengubah bagian ini pada PodSpec: {{< codenew file="pods/pod-projected-svc-token.yaml" >}} @@ -290,7 +290,7 @@ Buat Pod: kubectl create -f https://k8s.io/examples/pods/pod-projected-svc-token.yaml ``` -Kubelet akan me-_request_ dan menyimpan _token_ mewakili pod, buat _token_ dapat diakses oleh pod pada _file path_ yang ditentukan, dan _refresh_ _token_ ketika telah mendekati waktu berakhir. Kubelet akan mengganti _token_ jika _token_ telah melewati 80% dari total TTL, atau jika _token_ telah melebihi waktu 24 jam. +Kubelet akan me-_request_ dan menyimpan _token_ mewakili Pod, buat _token_ dapat diakses oleh Pod pada _file path_ yang ditentukan, dan _refresh_ _token_ ketika telah mendekati waktu berakhir. Kubelet akan mengganti _token_ jika _token_ telah melewati 80% dari total TTL, atau jika _token_ telah melebihi waktu 24 jam. Aplikasi bertanggung jawab untuk memuat ulang _token_ ketika terjadi penggantian. Pemuatan ulang teratur (misalnya sekali setiap 5 menit) cukup untuk mencakup kebanyakan kasus. From 9405ad3aa1a1f757f62cd41eef91fea101df386d Mon Sep 17 00:00:00 2001 From: joshuabezaleel Date: Tue, 23 Jun 2020 11:14:37 +0700 Subject: [PATCH 117/218] namespace to Namespace --- .../configure-service-account.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/content/id/docs/tasks/configure-pod-container/configure-service-account.md b/content/id/docs/tasks/configure-pod-container/configure-service-account.md index 065cfd25ad..e9bdab5857 100644 --- a/content/id/docs/tasks/configure-pod-container/configure-service-account.md +++ b/content/id/docs/tasks/configure-pod-container/configure-service-account.md @@ -27,7 +27,7 @@ Ketika kamu mengakses klaster (contohnya menggunakan `kubectl`), kamu terautenti ## Menggunakan Default ServiceAccount untuk Mengakses API server. -Ketika kamu membuat sebuah Pod, jika kamu tidak menentukan sebuah ServiceAccount, maka ia akan otomatis ditetapkan sebagai ServiceAccount`default` di namespace yang sama. Jika kamu mendapatkan json atau yaml mentah untuk sebuah Pod yang telah kamu buat (contohnya menggunakan `kubectl get pods/ -o yaml`), kamu akan melihat _field_ `spec.serviceAccountName` yang telah secara [otomatis ditentukan](/docs/user-guide/working-with-resources/#resources-are-automatically-modified). +Ketika kamu membuat sebuah Pod, jika kamu tidak menentukan sebuah ServiceAccount, maka ia akan otomatis ditetapkan sebagai ServiceAccount`default` di Namespace yang sama. Jika kamu mendapatkan json atau yaml mentah untuk sebuah Pod yang telah kamu buat (contohnya menggunakan `kubectl get pods/ -o yaml`), kamu akan melihat _field_ `spec.serviceAccountName` yang telah secara [otomatis ditentukan](/docs/user-guide/working-with-resources/#resources-are-automatically-modified). Kamu dapat mengakses API dari dalam Pod menggunakan kredensial ServiceAccount yang ditambahkan secara otomatis seperti yang dijelaskan dalam [Mengakses Klaster](/docs/user-guide/accessing-the-cluster/#accessing-the-api-from-a-pod). Hak akses API dari ServiceAccount menyesuaikan dengan [kebijakan dan plugin otorisasi](/docs/reference/access-authn-authz/authorization/#authorization-modules) yang sedang digunakan. @@ -60,8 +60,8 @@ Pengaturan dari spesifikasi Pod didahulukan dibanding ServiceAccount jika keduan ## Menggunakan Beberapa ServiceAccount. -Setiap namespace memiliki _resource_ ServiceAccount standar `default`. -Kamu dapat melihatnya dan _resource_ serviceAccount lainnya di namespace tersebut dengan perintah: +Setiap Namespace memiliki _resource_ ServiceAccount standar `default`. +Kamu dapat melihatnya dan _resource_ serviceAccount lainnya di Namespace tersebut dengan perintah: ```shell kubectl get serviceaccounts @@ -193,7 +193,7 @@ Isi dari `token` tidak dirinci di sini. ### Menambahkan imagePullSecret ke ServiceAccount -Selanjutnya, modifikasi ServiceAccount standar dari namespace untuk menggunakan _secret_ ini sebagai imagePullSecret. +Selanjutnya, modifikasi ServiceAccount standar dari Namespace untuk menggunakan _secret_ ini sebagai imagePullSecret. ```shell @@ -247,7 +247,7 @@ kubectl replace serviceaccount default -f ./sa.yaml ### Memverifikasi imagePullSecrets sudah ditambahkan ke spesifikasi Pod -Ketika Pod baru dibuat dalam namespace yang sedang aktif dan menggunakan ServiceAccount, Pod baru akan memiliki _field_ `spec.imagePullSecrets` yang ditentukan secara otomatis: +Ketika Pod baru dibuat dalam Namespace yang sedang aktif dan menggunakan ServiceAccount, Pod baru akan memiliki _field_ `spec.imagePullSecrets` yang ditentukan secara otomatis: ```shell kubectl run nginx --image=nginx --restart=Never From 9373ed1ef9542b3ff4677e2194c1d7b9b309473b Mon Sep 17 00:00:00 2001 From: joshuabezaleel Date: Tue, 23 Jun 2020 11:15:16 +0700 Subject: [PATCH 118/218] resource to sumber daya --- .../configure-pod-container/configure-service-account.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/id/docs/tasks/configure-pod-container/configure-service-account.md b/content/id/docs/tasks/configure-pod-container/configure-service-account.md index e9bdab5857..ad80af59fb 100644 --- a/content/id/docs/tasks/configure-pod-container/configure-service-account.md +++ b/content/id/docs/tasks/configure-pod-container/configure-service-account.md @@ -60,8 +60,8 @@ Pengaturan dari spesifikasi Pod didahulukan dibanding ServiceAccount jika keduan ## Menggunakan Beberapa ServiceAccount. -Setiap Namespace memiliki _resource_ ServiceAccount standar `default`. -Kamu dapat melihatnya dan _resource_ serviceAccount lainnya di Namespace tersebut dengan perintah: +Setiap Namespace memiliki sumber daya ServiceAccount standar `default`. +Kamu dapat melihatnya dan sumber daya serviceAccount lainnya di Namespace tersebut dengan perintah: ```shell kubectl get serviceaccounts From 5f7e7ada8172b492886bfd082263a9be57522089 Mon Sep 17 00:00:00 2001 From: joshuabezaleel Date: Tue, 23 Jun 2020 11:15:34 +0700 Subject: [PATCH 119/218] obyek to objek --- .../configure-pod-container/configure-service-account.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/id/docs/tasks/configure-pod-container/configure-service-account.md b/content/id/docs/tasks/configure-pod-container/configure-service-account.md index ad80af59fb..8d4b2ed51f 100644 --- a/content/id/docs/tasks/configure-pod-container/configure-service-account.md +++ b/content/id/docs/tasks/configure-pod-container/configure-service-account.md @@ -73,7 +73,7 @@ NAME SECRETS AGE default 1 1d ``` -Kamu dapat membuat obyek ServiceAccount tambahan seperti ini: +Kamu dapat membuat objek ServiceAccount tambahan seperti ini: ```shell kubectl apply -f - < Date: Tue, 23 Jun 2020 11:16:35 +0700 Subject: [PATCH 120/218] secret to Secret --- .../configure-service-account.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/content/id/docs/tasks/configure-pod-container/configure-service-account.md b/content/id/docs/tasks/configure-pod-container/configure-service-account.md index 8d4b2ed51f..79f2c38644 100644 --- a/content/id/docs/tasks/configure-pod-container/configure-service-account.md +++ b/content/id/docs/tasks/configure-pod-container/configure-service-account.md @@ -124,7 +124,7 @@ kubectl delete serviceaccount/build-robot ## Membuat token API ServiceAccount secara manual. -Asumsikan kita memiliki ServiceAccount dengan nama "build-robot" seperti yang disebukan di atas, dan kita membuat _secret_ secara manual. +Asumsikan kita memiliki ServiceAccount dengan nama "build-robot" seperti yang disebukan di atas, dan kita membuat Secret secara manual. ```shell kubectl apply -f - < ## ServiceAccount Token Volume Projection From a6107816ddd3f80477e9d63d64a380e88b40c560 Mon Sep 17 00:00:00 2001 From: joshuabezaleel Date: Tue, 23 Jun 2020 11:17:03 +0700 Subject: [PATCH 121/218] Singular form of ImagePullSecret --- .../configure-pod-container/configure-service-account.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/id/docs/tasks/configure-pod-container/configure-service-account.md b/content/id/docs/tasks/configure-pod-container/configure-service-account.md index 79f2c38644..98aafd5802 100644 --- a/content/id/docs/tasks/configure-pod-container/configure-service-account.md +++ b/content/id/docs/tasks/configure-pod-container/configure-service-account.md @@ -167,11 +167,11 @@ token: ... Isi dari `token` tidak dirinci di sini. {{< /note >}} -## Menambahkan ImagePullSecrets ke ServiceAccount. +## Menambahkan ImagePullSecret ke ServiceAccount. ### Membuat imagePullSecret -- Membuat sebuah imagePullSecret, seperti yang dijelaskan pada [Menentukan ImagePullSecrets pada Pod](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod). +- Membuat sebuah imagePullSecret, seperti yang dijelaskan pada [Menentukan ImagePullSecret pada Pod](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod). ```shell kubectl create secret docker-registry myregistrykey --docker-server=DUMMY_SERVER \ From 68f855ba80a209b665b65a55e8a09ed130bee85d Mon Sep 17 00:00:00 2001 From: joshuabezaleel Date: Tue, 23 Jun 2020 11:17:44 +0700 Subject: [PATCH 122/218] Redirect to Indonesian page for imagepullsecret link --- .../tasks/configure-pod-container/configure-service-account.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/id/docs/tasks/configure-pod-container/configure-service-account.md b/content/id/docs/tasks/configure-pod-container/configure-service-account.md index 98aafd5802..9729db5fa2 100644 --- a/content/id/docs/tasks/configure-pod-container/configure-service-account.md +++ b/content/id/docs/tasks/configure-pod-container/configure-service-account.md @@ -171,7 +171,7 @@ Isi dari `token` tidak dirinci di sini. ### Membuat imagePullSecret -- Membuat sebuah imagePullSecret, seperti yang dijelaskan pada [Menentukan ImagePullSecret pada Pod](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod). +- Membuat sebuah imagePullSecret, seperti yang dijelaskan pada [Menentukan ImagePullSecret pada Pod](/id/docs/concepts/containers/images/#tentukan-imagepullsecrets-pada-sebuah-pod). ```shell kubectl create secret docker-registry myregistrykey --docker-server=DUMMY_SERVER \ From a3f5cd9a38253d717475becaa3d11adcf68d54df Mon Sep 17 00:00:00 2001 From: joshuabezaleel Date: Tue, 23 Jun 2020 11:18:05 +0700 Subject: [PATCH 123/218] manifest to manifes --- .../tasks/configure-pod-container/configure-service-account.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/id/docs/tasks/configure-pod-container/configure-service-account.md b/content/id/docs/tasks/configure-pod-container/configure-service-account.md index 9729db5fa2..33c2d22532 100644 --- a/content/id/docs/tasks/configure-pod-container/configure-service-account.md +++ b/content/id/docs/tasks/configure-pod-container/configure-service-account.md @@ -200,7 +200,7 @@ Selanjutnya, modifikasi ServiceAccount standar dari Namespace untuk menggunakan kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "myregistrykey"}]}' ``` -Sebagai gantinya kamu dapat menggunakan `kubectl edit`, atau melakukan pengubahan secara manual _manifest_ YAML seperti di bawah ini: +Sebagai gantinya kamu dapat menggunakan `kubectl edit`, atau melakukan pengubahan secara manual manifes YAML seperti di bawah ini: ```shell kubectl get serviceaccounts default -o yaml > ./sa.yaml From 02b8a2696a8be3afb32d26e770bbbcb9fa532839 Mon Sep 17 00:00:00 2001 From: joshuabezaleel Date: Tue, 23 Jun 2020 11:18:30 +0700 Subject: [PATCH 124/218] _berkas_ to berkas --- .../configure-pod-container/configure-service-account.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/id/docs/tasks/configure-pod-container/configure-service-account.md b/content/id/docs/tasks/configure-pod-container/configure-service-account.md index 33c2d22532..ba12daadb0 100644 --- a/content/id/docs/tasks/configure-pod-container/configure-service-account.md +++ b/content/id/docs/tasks/configure-pod-container/configure-service-account.md @@ -206,7 +206,7 @@ Sebagai gantinya kamu dapat menggunakan `kubectl edit`, atau melakukan pengubaha kubectl get serviceaccounts default -o yaml > ./sa.yaml ``` -Keluaran dari _file_ `sa.yaml` akan serupa dengan: +Keluaran dari berkas `sa.yaml` akan serupa dengan: ```shell apiVersion: v1 @@ -221,9 +221,9 @@ secrets: - name: default-token-uudge ``` -Menggunakan _editor_ pilihanmu (misalnya `vi`), buka _file_ `sa.yaml`, hapus baris dengan _key_ `resourceVersion`, tambahkan baris dengan `imagePullSecrets:` dan simpan. +Menggunakan _editor_ pilihanmu (misalnya `vi`), buka berkas `sa.yaml`, hapus baris dengan _key_ `resourceVersion`, tambahkan baris dengan `imagePullSecrets:` dan simpan. -Keluaran dari _file_ `sa.yaml` akan serupa dengan: +Keluaran dari berkas `sa.yaml` akan serupa dengan: ```shell apiVersion: v1 @@ -239,7 +239,7 @@ imagePullSecrets: - name: myregistrykey ``` -Terakhir ganti serviceaccount dengan _file_ `sa.yaml` yang telah diperbarui. +Terakhir ganti serviceaccount dengan berkas `sa.yaml` yang telah diperbarui. ```shell kubectl replace serviceaccount default -f ./sa.yaml From 6e1e5dc54ac232a7030e6aab3e14f9df2e691f68 Mon Sep 17 00:00:00 2001 From: joshuabezaleel Date: Tue, 23 Jun 2020 11:18:51 +0700 Subject: [PATCH 125/218] _key_ to kunci --- .../tasks/configure-pod-container/configure-service-account.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/id/docs/tasks/configure-pod-container/configure-service-account.md b/content/id/docs/tasks/configure-pod-container/configure-service-account.md index ba12daadb0..101f0d2e0e 100644 --- a/content/id/docs/tasks/configure-pod-container/configure-service-account.md +++ b/content/id/docs/tasks/configure-pod-container/configure-service-account.md @@ -221,7 +221,7 @@ secrets: - name: default-token-uudge ``` -Menggunakan _editor_ pilihanmu (misalnya `vi`), buka berkas `sa.yaml`, hapus baris dengan _key_ `resourceVersion`, tambahkan baris dengan `imagePullSecrets:` dan simpan. +Menggunakan _editor_ pilihanmu (misalnya `vi`), buka berkas `sa.yaml`, hapus baris dengan key `resourceVersion`, tambahkan baris dengan `imagePullSecrets:` dan simpan. Keluaran dari berkas `sa.yaml` akan serupa dengan: From 268aad165071d7db642318a7cdf6412c64d53d38 Mon Sep 17 00:00:00 2001 From: joshuabezaleel Date: Tue, 23 Jun 2020 11:19:43 +0700 Subject: [PATCH 126/218] Unitalicize _server_ --- .../configure-pod-container/configure-service-account.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/id/docs/tasks/configure-pod-container/configure-service-account.md b/content/id/docs/tasks/configure-pod-container/configure-service-account.md index 101f0d2e0e..7eab5ff55b 100644 --- a/content/id/docs/tasks/configure-pod-container/configure-service-account.md +++ b/content/id/docs/tasks/configure-pod-container/configure-service-account.md @@ -270,7 +270,7 @@ TODO: Tes dan jelaskan bagaimana cara menambahkan Secret tambahan non-K8s dengan {{< feature-state for_k8s_version="v1.12" state="beta" >}} {{< note >}} -ServiceAccountTokenVolumeProjection masih dalam tahap __beta__ untuk versi 1.12 dan diaktifkan dengan memberikan _flag_ berikut ini ke API _server_: +ServiceAccountTokenVolumeProjection masih dalam tahap __beta__ untuk versi 1.12 dan diaktifkan dengan memberikan _flag_ berikut ini ke API server: * `--service-account-issuer` * `--service-account-signing-key-file` @@ -308,7 +308,7 @@ Jika URL tidak sesuai dengan aturan, _endpoint_ `ServiceAccountIssuerDiscovery` Fitur _Service Account Issuer Discovery_ memungkinkan federasi dari berbagai _token_ ServiceAccount Kubernetes yang dibuat oleh sebuah klaster (penyedia identitas) dan sistem eksternal. -Ketika diaktifkan, _server_ API Kubernetes menyediakan dokumen OpenID Provider Configuration pada `/.well-known/openid-configuration` dan JSON Web Key Set (JWKS) terkait pada `/openid/v1/jwks`. OpenID Provider Configuration terkadang disebut juga dengan sebutan _discovery document_. +Ketika diaktifkan, server API Kubernetes menyediakan dokumen OpenID Provider Configuration pada `/.well-known/openid-configuration` dan JSON Web Key Set (JWKS) terkait pada `/openid/v1/jwks`. OpenID Provider Configuration terkadang disebut juga dengan sebutan _discovery document_. Ketika diaktifkan, klaster juga dikonfigurasi dengan RBAC ClusterRole standar yaitu `system:service-account-issuer-discovery`. _Role binding_ tidak disediakan secara _default_. Administrator dimungkinkan untuk, sebagai contoh, menentukan apakah peran akan disematkan ke `system:authenticated` atau `system:unauthenticated` tergantung terhadap kebutuhan keamanan dan sistem eksternal yang direncakanan untuk diintegrasikan. @@ -318,7 +318,7 @@ Respons yang disediakan pada `/.well-known/openid-configuration` dan`/openid/v1/ Respons JWKS memuat kunci publik yang dapat digunakan oleh sistem eksternal untuk melakukan validasi _token_ ServiceAccount Kubernetes. Awalnya sistem eksternal akan mengkueri OpenID Provider Configuration, dan selanjutnya dapat menggunakan _field_ `jwks_uri` pada respons kueri untuk mendapatkan JWKS. -Pada banyak kasus, _server_ API Kubernetes tidak tersedia di internet publik, namun _endpoint_ publik yang menyediakan respons hasil _cache_ dari _server_ API dapat dibuat menjadi tersedia oleh pengguna atau penyedia servis. Pada kasus ini, dimungkinkan untuk mengganti `jwks_uri` pada OpenID Provider Configuration untuk diarahkan ke _endpoint_ publik sebagai ganti alamat _server_ API dengan memberikan _flag_ `--service-account-jwks-uri` ke API server. serupa dengan URL _issuer_, URI JWKS diharuskan untuk menggunakan skema `https`. +Pada banyak kasus, server API Kubernetes tidak tersedia di internet publik, namun _endpoint_ publik yang menyediakan respons hasil _cache_ dari server API dapat dibuat menjadi tersedia oleh pengguna atau penyedia servis. Pada kasus ini, dimungkinkan untuk mengganti `jwks_uri` pada OpenID Provider Configuration untuk diarahkan ke _endpoint_ publik sebagai ganti alamat server API dengan memberikan _flag_ `--service-account-jwks-uri` ke API server. serupa dengan URL _issuer_, URI JWKS diharuskan untuk menggunakan skema `https`. ## {{% heading "whatsnext" %}} From 053e97fc447182319b6eda045ca1a3aa701a339c Mon Sep 17 00:00:00 2001 From: joshuabezaleel Date: Tue, 23 Jun 2020 11:21:24 +0700 Subject: [PATCH 127/218] Reword paragraph to enable lowercase for kubelet --- .../tasks/configure-pod-container/configure-service-account.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/id/docs/tasks/configure-pod-container/configure-service-account.md b/content/id/docs/tasks/configure-pod-container/configure-service-account.md index 7eab5ff55b..4aa2afa7db 100644 --- a/content/id/docs/tasks/configure-pod-container/configure-service-account.md +++ b/content/id/docs/tasks/configure-pod-container/configure-service-account.md @@ -290,7 +290,7 @@ Buat Pod: kubectl create -f https://k8s.io/examples/pods/pod-projected-svc-token.yaml ``` -Kubelet akan me-_request_ dan menyimpan _token_ mewakili Pod, buat _token_ dapat diakses oleh Pod pada _file path_ yang ditentukan, dan _refresh_ _token_ ketika telah mendekati waktu berakhir. Kubelet akan mengganti _token_ jika _token_ telah melewati 80% dari total TTL, atau jika _token_ telah melebihi waktu 24 jam. +_Token_ yang mewakili Pod akan diminta dan disimpan kubelet, lalu kubelet akan membuat _token_ yang dapat diakses oleh Pod pada _file path_ yang ditentukan, dan melakukan _refresh_ _token_ ketika telah mendekati waktu berakhir. _Token_ akan diganti oleh kubelet jika _token_ telah melewati 80% dari total TTL, atau jika _token_ telah melebihi waktu 24 jam. Aplikasi bertanggung jawab untuk memuat ulang _token_ ketika terjadi penggantian. Pemuatan ulang teratur (misalnya sekali setiap 5 menit) cukup untuk mencakup kebanyakan kasus. From 223a6cd2763645fa91d051a5dbc26acab7f128ef Mon Sep 17 00:00:00 2001 From: joshuabezaleel Date: Tue, 23 Jun 2020 11:21:53 +0700 Subject: [PATCH 128/218] Gerbang fitur instead of feature gate --- .../tasks/configure-pod-container/configure-service-account.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/id/docs/tasks/configure-pod-container/configure-service-account.md b/content/id/docs/tasks/configure-pod-container/configure-service-account.md index 4aa2afa7db..003a62be4e 100644 --- a/content/id/docs/tasks/configure-pod-container/configure-service-account.md +++ b/content/id/docs/tasks/configure-pod-container/configure-service-account.md @@ -298,7 +298,7 @@ Aplikasi bertanggung jawab untuk memuat ulang _token_ ketika terjadi penggantian {{< feature-state for_k8s_version="v1.18" state="alpha" >}} -Fitur _Service Account Issuer Discovery_ diaktifkan dengan mengaktifkan _[feature gate](/docs/reference/command-line-tools-reference/feature-gate)_ `ServiceAccountIssuerDiscovery` dan mengaktifkan fitur _Service Account Token Volume Projection_ seperti yang telah dijelaskan [di atas](#service-account-token-volume-projection). +Fitur _Service Account Issuer Discovery_ diaktifkan dengan mengaktifkan [gerbang fitur](/docs/reference/command-line-tools-reference/feature-gate) `ServiceAccountIssuerDiscovery` dan mengaktifkan fitur _Service Account Token Volume Projection_ seperti yang telah dijelaskan [di atas](#service-account-token-volume-projection). {{< note >}} URL _issuer_ harus sesuai dengan _[OIDC Discovery Spec](https://openid.net/specs/openid-connect-discovery-1_0.html)_. Pada implementasinya, hal ini berarti URL harus menggunakan skema `https` dan harus menyediakan konfigurasi penyedia OpenID pada `{service-account-issuer}/.well-known/openid-configuration`. From 00c186aae87b7dfd0fe25a80db3c4b74f41ff185 Mon Sep 17 00:00:00 2001 From: joshuabezaleel Date: Tue, 23 Jun 2020 11:25:06 +0700 Subject: [PATCH 129/218] Use API object writing for ServiceAccountTokenVolumeProjection and ServiceAccountIssuerDiscovery --- .../configure-pod-container/configure-service-account.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/id/docs/tasks/configure-pod-container/configure-service-account.md b/content/id/docs/tasks/configure-pod-container/configure-service-account.md index 003a62be4e..73c0946b8f 100644 --- a/content/id/docs/tasks/configure-pod-container/configure-service-account.md +++ b/content/id/docs/tasks/configure-pod-container/configure-service-account.md @@ -265,7 +265,7 @@ myregistrykey TODO: Tes dan jelaskan bagaimana cara menambahkan Secret tambahan non-K8s dengan ServiceAccount yang sudah ada. --> -## ServiceAccount Token Volume Projection +## ServiceAccountTokenVolumeProjection {{< feature-state for_k8s_version="v1.12" state="beta" >}} @@ -294,11 +294,11 @@ _Token_ yang mewakili Pod akan diminta dan disimpan kubelet, lalu kubelet akan m Aplikasi bertanggung jawab untuk memuat ulang _token_ ketika terjadi penggantian. Pemuatan ulang teratur (misalnya sekali setiap 5 menit) cukup untuk mencakup kebanyakan kasus. -## ServiceAccount Issuer Discovery +## ServiceAccountIssuerDiscovery {{< feature-state for_k8s_version="v1.18" state="alpha" >}} -Fitur _Service Account Issuer Discovery_ diaktifkan dengan mengaktifkan [gerbang fitur](/docs/reference/command-line-tools-reference/feature-gate) `ServiceAccountIssuerDiscovery` dan mengaktifkan fitur _Service Account Token Volume Projection_ seperti yang telah dijelaskan [di atas](#service-account-token-volume-projection). +Fitur ServiceAccountIssuerDiscovery diaktifkan dengan mengaktifkan [gerbang fitur](/docs/reference/command-line-tools-reference/feature-gate) `ServiceAccountIssuerDiscovery` dan mengaktifkan fitur _Service Account Token Volume Projection_ seperti yang telah dijelaskan [di atas](#service-account-token-volume-projection). {{< note >}} URL _issuer_ harus sesuai dengan _[OIDC Discovery Spec](https://openid.net/specs/openid-connect-discovery-1_0.html)_. Pada implementasinya, hal ini berarti URL harus menggunakan skema `https` dan harus menyediakan konfigurasi penyedia OpenID pada `{service-account-issuer}/.well-known/openid-configuration`. From 38e0a8b10d53fd03073fc429e63b3b6ec4f75633 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Fri, 19 Jun 2020 15:12:19 +0800 Subject: [PATCH 130/218] [zh] Sync manage resources for containers The manage-compute-resources-container.md file was renamed in the English site. The content in it has been reorganized for *who knows* reasons. This PR fixes the Chinese localization to make things work again. --- .../manage-compute-resources-container.md | 972 ------------ .../manage-resources-containers.md | 1310 +++++++++++++++++ 2 files changed, 1310 insertions(+), 972 deletions(-) delete mode 100644 content/zh/docs/concepts/configuration/manage-compute-resources-container.md create mode 100644 content/zh/docs/concepts/configuration/manage-resources-containers.md diff --git a/content/zh/docs/concepts/configuration/manage-compute-resources-container.md b/content/zh/docs/concepts/configuration/manage-compute-resources-container.md deleted file mode 100644 index 776b977736..0000000000 --- a/content/zh/docs/concepts/configuration/manage-compute-resources-container.md +++ /dev/null @@ -1,972 +0,0 @@ ---- -title: 为容器管理计算资源 -content_type: concept -weight: 20 -feature: - title: 自动装箱 - description: > - 根据资源需求和其他约束自动放置容器，同时不会牺牲可用性，将任务关键工作负载和尽力服务工作负载进行混合放置，以提高资源利用率并节省更多资源。 ---- - - - - - - -当您定义 [Pod](/docs/user-guide/pods) 的时候可以选择为每个容器指定需要的 CPU 和内存（RAM）大小。当为容器指定了资源请求后，调度器就能够更好的判断出将容器调度到哪个节点上。如果您还为容器指定了资源限制，Kubernetes 就可以按照指定的方式来处理节点上的资源竞争。关于资源请求和限制的不同点和更多资料请参考 [Resource QoS](https://git.k8s.io/community/contributors/design-proposals/resource-qos.md)。 - - - - - - - - -## 资源类型 - -*CPU* 和*内存*都是*资源类型*。资源类型具有基本单位。CPU 的单位是核心数，内存的单位是字节。 - -如果您使用的是 Kubernetes v1.14 或更高版本，则可以指定巨页资源。巨页是 Linux 特有的功能，节点内核在其中分配的内存块比默认页大小大得多。 - -例如，在默认页面大小为 4KiB 的系统上，您可以指定一个限制，`hugepages-2Mi: 80Mi`。如果容器尝试分配 40 个 2MiB 大页面（总共 80 MiB ），则分配失败。 - -{{< note >}} -您不能过量使用`hugepages- *`资源。 -这与`memory`和`cpu`资源不同。 -{{< /note >}} - -CPU和内存统称为*计算资源*，也可以称为*资源*。计算资源的数量是可以被请求、分配、消耗和可测量的。它们与 [API 资源](/docs/concepts/overview/kubernetes-api/) 不同。 API 资源（如 Pod 和 [Service](/docs/concepts/services-networking/service/)）是可通过 Kubernetes API server 读取和修改的对象。 - - - -## Pod 和 容器的资源请求和限制 - -Pod 中的每个容器都可以指定以下的一个或者多个值： - -- `spec.containers[].resources.limits.cpu` -- `spec.containers[].resources.limits.memory` -- `spec.containers[].resources.requests.cpu` -- `spec.containers[].resources.requests.memory` - -尽管只能在个别容器上指定请求和限制，但是我们可以方便地计算出 Pod 资源请求和限制。特定资源类型的Pod 资源请求/限制是 Pod 中每个容器的该类型的资源请求/限制的总和。 - - - -## CPU 的含义 - -CPU 资源的限制和请求以 *cpu* 为单位。 - -Kubernetes 中的一个 cpu 等于： - -- 1 AWS vCPU -- 1 GCP Core -- 1 Azure vCore -- 1 *Hyperthread* 在带有超线程的裸机 Intel 处理器上 - -允许浮点数请求。具有 `spec.containers[].resources.requests.cpu` 为 0.5 的容器保证了一半 CPU 要求 1 CPU的一半。表达式 `0.1` 等价于表达式 `100m`，可以看作 “100 millicpu”。有些人说成是“一百毫 cpu”，其实说的是同样的事情。具有小数点（如 `0.1`）的请求由 API 转换为`100m`，精度不超过 `1m`。因此，可能会优先选择 `100m` 的形式。 - -CPU 总是要用绝对数量，不可以使用相对数量；0.1 的 CPU 在单核、双核、48核的机器中的意义是一样的。 - - - -## 内存的含义 - -内存的限制和请求以字节为单位。您可以使用以下后缀之一作为平均整数或定点整数表示内存：E，P，T，G，M，K。您还可以使用两个字母的等效的幂数：Ei，Pi，Ti ，Gi，Mi，Ki。例如，以下代表大致相同的值： - -```shell -128974848, 129e6, 129M, 123Mi -``` - - - -下面是个例子。 - -以下 Pod 有两个容器。每个容器的请求为 0.25 cpu 和 64MiB（226 字节）内存，每个容器的限制为 0.5 cpu 和 128MiB 内存。您可以说该 Pod 请求 0.5 cpu 和 128 MiB 的内存，限制为 1 cpu 和 256MiB 的内存。 - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: frontend -spec: - containers: - - name: db - image: mysql - env: - - name: MYSQL_ROOT_PASSWORD - value: "password" - resources: - requests: - memory: "64Mi" - cpu: "250m" - limits: - memory: "128Mi" - cpu: "500m" - - name: wp - image: wordpress - resources: - requests: - memory: "64Mi" - cpu: "250m" - limits: - memory: "128Mi" - cpu: "500m" -``` - - - -## 具有资源请求的 Pod 如何调度 - -当您创建一个 Pod 时，Kubernetes 调度程序将为 Pod 选择一个节点。每个节点具有每种资源类型的最大容量：可为 Pod 提供的 CPU 和内存量。调度程序确保对于每种资源类型，调度的容器的资源请求的总和小于节点的容量。请注意，尽管节点上的实际内存或 CPU 资源使用量非常低，但如果容量检查失败，则调度程序仍然拒绝在该节点上放置 Pod。当资源使用量稍后增加时，例如在请求率的每日峰值期间，这可以防止节点上的资源短缺。 - - - -## 具有资源限制的 Pod 如何运行 - -当 kubelet 启动一个 Pod 的容器时，它会将 CPU 和内存限制传递到容器运行时。 - -当使用 Docker 时： - - - -- `spec.containers[].resources.requests.cpu` 先被转换为可能是小数的 core 值，再乘以 1024，这个数字和 2 的较大者用作 `docker run` 命令中的[ `--cpu-shares`](https://docs.docker.com/engine/reference/run/#/cpu-share-constraint) 标志的值。 - -- `spec.containers[].resources.limits.cpu` 先被转换为 millicore 值，再乘以 100，结果就是每 100ms 内 container 可以使用的 CPU 总时间。在此时间间隔（100ms）内，一个 container 使用的 CPU 时间不会超过它被分配的时间。 - - - - {{< note >}} - 默认的配额（quota）周期为 100 毫秒。 CPU配额的最小精度为 1 毫秒。 - {{}} - - - -- `spec.containers[].resources.limits.memory` 被转换为整型，作为 `docker run` 命令中的 [`--memory`](https://docs.docker.com/engine/reference/run/#/user-memory-constraints) 标志的值。 - - - -如果容器超过其内存限制，则可能会被终止。如果可重新启动，则与所有其他类型的运行时故障一样，kubelet 将重新启动它。 - -如果一个容器超过其内存请求，那么当节点内存不足时，它的 Pod 可能被逐出。 - -容器可能被允许也可能不被允许超过其 CPU 限制时间。但是，由于 CPU 使用率过高，不会被杀死。 - -要确定容器是否由于资源限制而无法安排或被杀死，请参阅[疑难解答](#troubleshooting) 部分。 - - - -## 监控计算资源使用 - -Pod 的资源使用情况被报告为 Pod 状态的一部分。 - -如果为集群配置了可选 [监控工具](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)，则可以直接从 -[指标 API](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#the-metrics-api) 或者监控工具检索 Pod 资源的使用情况。 - - - -## 疑难解答 - -### 我的 Pod 处于 pending 状态且事件信息显示 failedScheduling - -如果调度器找不到任何该 Pod 可以匹配的节点，则该 Pod 将保持不可调度状态，直到找到一个可以被调度到的位置。每当调度器找不到 Pod 可以调度的地方时，会产生一个事件，如下所示： - -```shell -kubectl describe pod frontend | grep -A 3 Events -``` -``` -Events: - FirstSeen LastSeen Count From Subobject PathReason Message - 36s 5s 6 {scheduler } FailedScheduling Failed for reason PodExceedsFreeCPU and possibly others -``` - - - -在上述示例中，由于节点上的 CPU 资源不足，名为 “frontend” 的 Pod 将无法调度。由于内存不足（PodExceedsFreeMemory），类似的错误消息也可能会导致失败。一般来说，如果有这种类型的消息而处于 pending 状态，您可以尝试如下几件事情： - -- 向集群添加更多节点。 -- 终止不需要的 Pod，为待处理的 Pod 腾出空间。 -- 检查 Pod 所需的资源是否大于所有节点的资源。 例如，如果全部节点的容量为`cpu：1`，那么一个请求为 `cpu：1.1`的 Pod 永远不会被调度。 - -您可以使用 `kubectl describe nodes` 命令检查节点容量和分配的数量。 例如： - - -```shell -kubectl describe nodes e2e-test-node-pool-4lw4 -``` -``` -Name: e2e-test-node-pool-4lw4 -[ ... lines removed for clarity ...] -Capacity: - cpu: 2 - memory: 7679792Ki - pods: 110 -Allocatable: - cpu: 1800m - memory: 7474992Ki - pods: 110 -[ ... lines removed for clarity ...] -Non-terminated Pods: (5 in total) - Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits - --------- ---- ------------ ---------- --------------- ------------- - kube-system fluentd-gcp-v1.38-28bv1 100m (5%) 0 (0%) 200Mi (2%) 200Mi (2%) - kube-system kube-dns-3297075139-61lj3 260m (13%) 0 (0%) 100Mi (1%) 170Mi (2%) - kube-system kube-proxy-e2e-test-... 100m (5%) 0 (0%) 0 (0%) 0 (0%) - kube-system monitoring-influxdb-grafana-v4-z1m12 200m (10%) 200m (10%) 600Mi (8%) 600Mi (8%) - kube-system node-problem-detector-v0.1-fj7m3 20m (1%) 200m (10%) 20Mi (0%) 100Mi (1%) -Allocated resources: - (Total limits may be over 100 percent, i.e., overcommitted.) - CPU Requests CPU Limits Memory Requests Memory Limits - ------------ ---------- --------------- ------------- - 680m (34%) 400m (20%) 920Mi (12%) 1070Mi (14%) -``` - - - -在上面的输出中，您可以看到如果 Pod 请求超过 1120m CPU 或者 6.23Gi 内存，节点将无法满足。 - -通过查看 `Pods` 部分，您将看到哪些 Pod 占用的节点上的资源。 - -Pod 可用的资源量小于节点容量，因为系统守护程序使用一部分可用资源。 -[NodeStatus](/docs/resources-reference/{{< param "version" >}}/#nodestatus-v1-core) 的 `allocatable` 字段给出了可用于 Pod 的资源量。 -有关更多信息，请参阅 [节点可分配资源](https://git.k8s.io/community/contributors/design-proposals/node-allocatable.md)。 - -可以将 [资源配额](/docs/concepts/policy/resource-quotas/) 功能配置为限制可以使用的资源总量。如果与 namespace 配合一起使用，就可以防止一个团队占用所有资源。 - - - -## 我的容器被终止了 - -您的容器可能因为资源枯竭而被终止了。要查看容器是否因为遇到资源限制而被杀死，请在相关的 Pod 上调用 `kubectl describe pod`： - -```shell -kubectl describe pod simmemleak-hra99 -``` -``` -Name: simmemleak-hra99 -Namespace: default -Image(s): saadali/simmemleak -Node: kubernetes-node-tf0f/10.240.216.66 -Labels: name=simmemleak -Status: Running -Reason: -Message: -IP: 10.244.2.75 -Replication Controllers: simmemleak (1/1 replicas created) -Containers: - simmemleak: - Image: saadali/simmemleak - Limits: - cpu: 100m - memory: 50Mi - State: Running - Started: Tue, 07 Jul 2015 12:54:41 -0700 - Last Termination State: Terminated - Exit Code: 1 - Started: Fri, 07 Jul 2015 12:54:30 -0700 - Finished: Fri, 07 Jul 2015 12:54:33 -0700 - Ready: False - Restart Count: 5 -Conditions: - Type Status - Ready False -Events: - FirstSeen LastSeen Count From SubobjectPath Reason Message - Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {scheduler } scheduled Successfully assigned simmemleak-hra99 to kubernetes-node-tf0f - Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD pulled Pod container image "k8s.gcr.io/pause:0.8.0" already present on machine - Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD created Created with docker id 6a41280f516d - Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD started Started with docker id 6a41280f516d - Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} spec.containers{simmemleak} created Created with docker id 87348f12526a -``` - - - -在上面的例子中，`Restart Count: 5` 意味着 Pod 中的 `simmemleak` 容器被终止并重启了五次。 - -您可以使用 `kubectl get pod` 命令加上 `-o go-template=...` 选项来获取之前终止容器的状态。 - - -```shell -kubectl get pod -o go-template='{{range.status.containerStatuses}}{{"Container Name: "}}{{.name}}{{"\r\nLastState: "}}{{.lastState}}{{end}}' simmemleak-hra99 -``` -``` -Container Name: simmemleak -LastState: map[terminated:map[exitCode:137 reason:OOM Killed startedAt:2015-07-07T20:58:43Z finishedAt:2015-07-07T20:58:43Z containerID:docker://0e4095bba1feccdfe7ef9fb6ebffe972b4b14285d5acdec6f0d3ae8a22fad8b2]] -``` - - - -您可以看到容器因为 `reason:OOM killed` 被终止，`OOM` 表示 Out Of Memory。 - - - -## 本地临时存储 - -Kubernetes版本1.8引入了新资源_ephemeral-storage_，用于管理本地临时存储。 -在每个Kubernetes节点中，kubelet的根目录（默认为 /var/lib/kubelet）和日志目录（ /var/log ）存储在节点的根分区上。 -Pods还通过emptyDir卷，容器日志，镜像层和容器可写层共享和使用此分区。 - -该分区是“临时”分区，应用程序无法从该分区获得任何性能SLA（例如磁盘IOPS）。 本地临时存储管理仅适用于根分区。 图像层和可写层的可选分区超出范围。 - -{{< note >}} -如果使用可选的运行时分区，则根分区将不保存任何镜像层或可写层。 -{{< /note >}} - - - -### 本地临时存储的请求和限制设置 -Pod 的每个容器可以指定以下一项或多项： - -* `spec.containers[].resources.limits.ephemeral-storage` -* `spec.containers[].resources.requests.ephemeral-storage` - - - -对“临时存储”的限制和请求以字节为单位。您可以使用以下后缀之一将存储表示为纯整数或小数形式：E，P，T，G，M，K。您还可以使用2的幂次方：Ei，Pi，Ti，Gi，Mi，Ki。例如，以下内容表示的值其实大致相同： - -```shell -128974848, 129e6, 129M, 123Mi -``` - - - -例如，以下Pod具有两个容器。每个容器都有一个2GiB的本地临时存储请求。每个容器的本地临时存储限制为4GiB。因此，该Pod要求本地临时存储空间为4GiB，存储空间限制为8GiB。 - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: frontend -spec: - containers: - - name: db - image: mysql - env: - - name: MYSQL_ROOT_PASSWORD - value: "password" - resources: - requests: - ephemeral-storage: "2Gi" - limits: - ephemeral-storage: "4Gi" - - name: wp - image: wordpress - resources: - requests: - ephemeral-storage: "2Gi" - limits: - ephemeral-storage: "4Gi" -``` - - - -### 如何调度临时存储请求的 Pod - -创建Pod时，Kubernetes调度程序会选择一个节点来运行Pod。每个节点都可以为Pod提供最大数量的本地临时存储。 -有关更多信息，请参见[节点可分配](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)。 - -调度程序会确保调度的容器的资源请求的总和小于节点的容量。 - - - -### 具有临时存储限制的 Pod 如何运行 - -对于容器级隔离，如果容器的可写层和日志使用量超出其存储限制，则将驱逐Pod。对于 pod 级别的隔离，如果来自所有容器的本地临时存储使用量以及 Pod 的 emptyDir 卷的总和超过限制，则将驱逐Pod。 - - - -### 监控临时存储消耗 - -使用本地临时存储时，kubelet 会持续对本地临时存储时进行监视。 -通过定期扫描，来监视每个 emptyDir 卷，日志目录和可写层。 -从Kubernetes 1.15开始，作为集群操作员的一个选项，可以通过[项目配额](http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html) 来管理 emptyDir 卷（但是不包括日志目录或可写层）。 -项目配额最初是在XFS中实现的，最近又被移植到ext4fs中。 项目配额可用于监视和执行； 从Kubernetes 1.15开始，它们可用作Alpha功能仅用于监视。 - - - -配额比目录扫描更快，更准确。 -将目录分配给项目时，在该目录下创建的所有文件都将在该项目中创建，内核仅需跟踪该项目中的文件正在使用多少块。 -如果创建并删除了文件，但是文件描述符已打开，它将继续占用空间。 该空间将由配额跟踪，但目录扫描不会检查。 - - - -Kubernetes使用从1048576开始的项目ID。正在使用的ID注册于 `/etc/projects` 和 `/etc/projid`。 -如果此范围内的项目ID用于系统上的其他目的，则这些项目ID必须在 `/etc/projects` 和 `/etc/projid` 中注册，以防止Kubernetes使用它们。 - - - -要启用项目配额，集群操作员必须执行以下操作： - -* 在kubelet配置中启用 `LocalStorageCapacityIsolationFSQuotaMonitoring = true` 功能。 在Kubernetes 1.15中默认为 false，因此必须显式设置为 true。 - -* 确保根分区（或可选的运行时分区）是在启用项目配额的情况下构建的。 所有 XFS 文件系统都支持项目配额，但是 ext4 文件系统必须专门构建。 - -* 确保在启用了项目配额的情况下挂载了根分区（或可选的运行时分区）。 - - - -#### 在启用项目配额的情况下构建和挂载文件系统 - -XFS文件系统在构建时不需要任何特殊操作; 它们是在启用项目配额的情况下自动构建的。 - -Ext4fs文件系统必须在启用了配额的情况下构建，然后必须在文件系统中启用它们： - -``` -% sudo mkfs.ext4 other_ext4fs_args... -E quotatype=prjquota /dev/block_device -% sudo tune2fs -O project -Q prjquota /dev/block_device - -``` - - - -要挂载文件系统，ext4fs 和 XFS 都需要在 `/etc/fstab` 中设置 `prjquota` 选项： - -``` -/dev/block_device /var/kubernetes_data defaults,prjquota 0 0 -``` - - - - -## 拓展资源 - -拓展资源是 `kubernetes.io` 域名之外的标准资源名称。它们允许集群管理员做分发，而且用户可以使用非Kubernetes内置资源。 -使用扩展资源需要两个步骤。 首先，集群管理员必须分发拓展资源。 其次，用户必须在 Pod 中请求拓展资源。 - -```shell -curl --header "Content-Type: application/json-patch+json" \ ---request PATCH \ ---data '[{"op": "add", "path": "/status/capacity/example.com~1foo", "value": "5"}]' \ -http://k8s-master:8080/api/v1/nodes/k8s-node-1/status -``` - - - -### 管理拓展资源 - -#### 节点级拓展资源 - -节点级拓展资源绑定到节点。 - - - -##### 设备插件托管资源 - -有关如何在每个节点上分发设备插件托管资源的信息，请参阅[设备插件](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)。 - - - -##### 其他资源 -为了发布新的节点级拓展资源，集群操作员可以向API服务器提交 `PATCH` HTTP 请求， -以在 `status.capacity` 中为集群中的节点指定可用数量。 -完成此操作后，节点的 `status.capacity` 将包含新资源。 -由kubelet异步使用新资源自动更新 `status.allocatable` 字段。 -请注意，由于调度程序在评估Pod适合性时使用节点的状态 `status.allocatable` 值， -因此在用新资源修补节点容量和请求在该节点上调度资源的第一个Pod之间可能会有短暂的延迟。 - - - -**示例:** - -这是一个示例，显示了如何使用 `curl` 进行HTTP请求，该请求在主节点为 `k8s-master` 的子节点 `k8s-node-1` -上通告五个 `example.com/foo` 资源。 - -```shell -curl --header "Content-Type: application/json-patch+json" \ ---request PATCH \ ---data '[{"op": "add", "path": "/status/capacity/example.com~1foo", "value": "5"}]' \ -http://k8s-master:8080/api/v1/nodes/k8s-node-1/status -``` - -{{< note >}} - - - -在前面的请求中，`~1` 是 Patch 路径中字符 `/` 的编码。 JSON-Patch中的操作路径值被解释为JSON-Pointer。 -有关更多详细信息，请参见 -[IETF RFC 6901, section 3](https://tools.ietf.org/html/rfc6901#section-3). -{{< /note >}} - - - -#### 集群级扩展资源 - -群集级扩展资源不绑定到节点。 它们通常由调度程序扩展程序管理，这些程序处理资源消耗和资源配额。 - -您可以在[调度程序策略配置](https://github.com/kubernetes/kubernetes/blob/release-1.10/pkg/scheduler/api/v1/types.go#L31)中指定由调度程序扩展程序处理的扩展资源。 - - - -**示例:** - -通过调度程序策略的以下配置，指示群集级扩展资源 "example.com/foo" 由调度程序扩展程序处理。 - -- 仅当Pod请求 "example.com/foo" 时，调度程序才会将 Pod 发送到调度程序扩展程序。 -- `ignoredByScheduler` 字段指定调度程序不在其 `PodFitsResources` 字段中检查 "example.com/foo" 资源。 - -```json -{ - "kind": "Policy", - "apiVersion": "v1", - "extenders": [ - { - "urlPrefix":"", - "bindVerb": "bind", - "managedResources": [ - { - "name": "example.com/foo", - "ignoredByScheduler": true - } - ] - } - ] -} -``` - - - -### 消耗扩展资源 - -就像 CPU 和内存一样，用户可以使用 Pod 的扩展资源。 -调度程序负责核算资源，因此不会同时将过多的可用资源分配给 Pod。 - -{{< note >}} - - - -扩展资源取代了 Opaque 整数资源。 用户可以使用保留字 `kubernetes.io` 以外的任何域名前缀。 - -{{< /note >}} - - - -要在Pod中使用扩展资源，请在容器规范的 `spec.containers[].resources.limits` 映射中包含资源名称作为键。 - -{{< note >}} - - - -扩展资源不能过量使用，因此如果容器规范中存在请求和限制，则它们必须一致。 - -{{< /note >}} - - - -仅当满足所有资源请求(包括 CPU ，内存和任何扩展资源)时，才能调度 Pod。 只要资源请求无法满足，则 Pod 保持在 `PENDING` 状态。 - -**示例:** - -下面的 Pod 请求2个 CPU 和1个"example.com/foo"(扩展资源)。 - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: my-pod -spec: - containers: - - name: my-container - image: myimage - resources: - requests: - cpu: 2 - example.com/foo: 1 - limits: - example.com/foo: 1 -``` - - - - -## {{% heading "whatsnext" %}} - - - - -* 获取将 [分配内存资源给容器和 Pod ](/docs/tasks/configure-pod-container/assign-memory-resource/) 的实践经验 - -* 获取将 [分配 CPU 资源给容器和 Pod ](/docs/tasks/configure-pod-container/assign-cpu-resource/) 的实践经验 - -* [容器](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) - -* [资源需求](/docs/resources-reference/{{< param "version" >}}/#resourcerequirements-v1-core) - - diff --git a/content/zh/docs/concepts/configuration/manage-resources-containers.md b/content/zh/docs/concepts/configuration/manage-resources-containers.md new file mode 100644 index 0000000000..5b7b359848 --- /dev/null +++ b/content/zh/docs/concepts/configuration/manage-resources-containers.md @@ -0,0 +1,1310 @@ +--- +title: 为容器管理资源 +content_type: concept +weight: 40 +feature: + title: 自动装箱 + description: > + 根据资源需求和其他约束自动放置容器，同时避免影响可用性。将关键性工作负载和尽力而为性质的服务工作负载进行混合放置，以提高资源利用率并节省更多资源。 +--- + + + + + + + +当你定义 {{< glossary_tooltip term_id="pod" >}} 时可以选择性地为每个 +{{< glossary_tooltip text="容器" term_id="container" >}}设定所需要的资源数量。 +最常见的可设定资源是 CPU 和内存（RAM）大小；此外还有其他类型的资源。 + +当你为 Pod 中的 Container 指定了资源 __请求__ 时，调度器就利用该信息决定将 Pod 调度到哪个节点上。 +当你还为 Container 指定了资源 __约束__ 时，kubelet 就可以确保运行的容器不会使用超出所设约束的资源。 +kubelet 还会为容器预留所 __请求__ 数量的系统资源，供其使用。 + + + + + +## 请求和约束 + +如果 Pod 运行所在的节点具有足够的可用资源，容器可能（且可以）使用超出对应资源 +`request` 属性所设置的资源量。不过，容器不可以使用超出其资源 `limit` +属性所设置的资源量。 + +例如，如果你将容器的 `memory` 的请求量设置为 256 MiB，而该容器所处的 Pod +被调度到一个具有 8 GiB 内存的节点上，并且该节点上没有其他 Pods +运行，那么该容器就可以尝试使用更多的内存。 + + + +如果你将某容器的 `memory` 约束设置为 4 GiB，kubelet （和 +{{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}}） +就会确保该约束生效。 +容器运行时会禁止容器使用超出所设置资源约束的资源。 +例如：当容器中进程尝试使用超出所允许内存量的资源时，系统内核会将尝试申请内存的进程终止， +并引发内存不足（OOM）错误。 + +约束值可以以被动方式来实现（系统会在发现违例时进行干预），或者通过强制生效的方式实现 +（系统会避免容器用量超出约束值）。不同的容器运行时采用不同方式来实现相同的限制。 + + + +## 资源类型 + +*CPU* 和*内存*都是*资源类型*。每种资源类型具有其基本单位。 +CPU 表达的是计算处理能力，其单位是 [Kubernetes CPUs](#meaning-of-cpu)。 +内存的单位是字节。 +如果你使用的是 Kubernetes v1.14 或更高版本，则可以指定巨页（Huge Page）资源。 +巨页是 Linux 特有的功能，节点内核在其中分配的内存块比默认页大小大得多。 + +例如，在默认页面大小为 4KiB 的系统上，您可以指定约束 `hugepages-2Mi: 80Mi`。 +如果容器尝试分配 40 个 2MiB 大小的巨页（总共 80 MiB ），则分配请求会失败。 + + + + +{{< note >}} +您不能过量使用 `hugepages- * `资源。 +这与 `memory` 和 `cpu` 资源不同。 +{{< /note >}} + +CPU 和内存统称为*计算资源*，或简称为*资源*。 +计算资源的数量是可测量的，可以被请求、被分配、被消耗。 +它们与 [API 资源](/docs/concepts/overview/kubernetes-api/) 不同。 +API 资源（如 Pod 和 [Service](/docs/concepts/services-networking/service/)）是可通过 +Kubernetes API 服务器读取和修改的对象。 + + + +## Pod 和 容器的资源请求和约束 + +Pod 中的每个容器都可以指定以下的一个或者多个值： + +- `spec.containers[].resources.limits.cpu` +- `spec.containers[].resources.limits.memory` +- `spec.containers[].resources.limits.hugepages-` +- `spec.containers[].resources.requests.cpu` +- `spec.containers[].resources.requests.memory` +- `spec.containers[].resources.requests.hugepages-` + +尽管请求和限制值只能在单个容器上指定，我们仍可方便地计算出 Pod 的资源请求和约束。 +Pod 对特定资源类型的请求/约束值是 Pod 中各容器对该类型资源的请求/约束值的总和。 + + + +## CPU 的含义 {#meaning-of-cpu} + +CPU 资源的约束和请求以 *cpu* 为单位。 + +Kubernetes 中的一个 cpu 等于云平台上的 **1 个 vCPU/核**和裸机 Intel +处理器上的 **1 个超线程 **。 + +你也可以表达带小数 CPU 的请求。`spec.containers[].resources.requests.cpu` 为 0.5 +的 Container 肯定能够获得请求 1 CPU 的容器的一半 CPU 资源。表达式 `0.1` 等价于表达式 `100m`， +可以看作 “100 millicpu”。有些人说成是“一百毫 cpu”，其实说的是同样的事情。 +具有小数点（如 `0.1`）的请求由 API 转换为 `100m`；最大精度是 `1m`。 +因此，或许你应该优先考虑使用 `100m` 的形式。 + +CPU 总是按绝对数量来请求的，不可以使用相对数量； +0.1 的 CPU 在单核、双核、48 核的机器上的意义是一样的。 + + + +## 内存的含义 + +内存的约束和请求以字节为单位。你可以使用以下后缀之一以一般整数或定点整数形式来表示内存： +E、P、T、G、M、K。你也可以使用对应的 2 的幂数：Ei、Pi、Ti、Gi、Mi、Ki。 +例如，以下表达式所代表的是大致相同的值： + +```shell +128974848、129e6、129M、123Mi +``` + + + +下面是个例子。 + +以下 Pod 有两个 Container。每个 Container 的请求为 0.25 cpu 和 64MiB（226 字节）内存， +每个容器的资源约束为 0.5 cpu 和 128MiB 内存。 +你可以认为该 Pod 的资源请求为 0.5 cpu 和 128 MiB 内存，资源限制为 1 cpu 和 256MiB 内存。 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: frontend +spec: + containers: + - name: db + image: mysql + env: + - name: MYSQL_ROOT_PASSWORD + value: "password" + resources: + requests: + memory: "64Mi" + cpu: "250m" + limits: + memory: "128Mi" + cpu: "500m" + - name: wp + image: wordpress + resources: + requests: + memory: "64Mi" + cpu: "250m" + limits: + memory: "128Mi" + cpu: "500m" +``` + + + +## 带资源请求的 Pod 如何调度 + +当你创建一个 Pod 时，Kubernetes 调度程序将为 Pod 选择一个节点。 +每个节点对每种资源类型都有一个容量上限：可为 Pod 提供的 CPU 和内存量。 +调度程序确保对于每种资源类型，所调度的容器的资源请求的总和小于节点的容量。 +请注意，尽管节点上的实际内存或 CPU 资源使用量非常低，如果容量检查失败， +调度程序仍会拒绝在该节点上放置 Pod。 +当稍后节点上资源用量增加，例如到达请求率的每日峰值区间时，节点上也不会出现资源不足的问题。 + + + +## 带资源约束的 Pod 如何运行 + +当 kubelet 启动 Pod 中的 Container 时，它会将 CPU 和内存约束信息传递给容器运行时。 + +当使用 Docker 时： + + + +- `spec.containers[].resources.requests.cpu` 先被转换为可能是小数的基础值，再乘以 1024。 + 这个数值和 2 的较大者用作 `docker run` 命令中的 + [`--cpu-shares`](https://docs.docker.com/engine/reference/run/#/cpu-share-constraint) + 标志的值。 +- `spec.containers[].resources.limits.cpu` 先被转换为 millicore 值，再乘以 100。 + 其结果就是每 100 毫秒内容器可以使用的 CPU 时间总量。在此期间（100ms），容器所使用的 CPU + 时间不会超过它被分配的时间。 + + {{< note >}} + 默认的配额（quota）周期为 100 毫秒。 CPU配额的最小精度为 1 毫秒。 + {{}} + +- `spec.containers[].resources.limits.memory` 被转换为整数值，作为 `docker run` 命令中的 + [`--memory`](https://docs.docker.com/engine/reference/run/#/user-memory-constraints) + 参数值。 + + + +如果 Container 超过其内存限制，则可能会被终止。如果容器可重新启动，则与所有其他类型的 +运行时失效一样，kubelet 将重新启动容器。 + +如果一个 Container 内存用量超过其内存请求值，那么当节点内存不足时，容器所处的 Pod 可能被逐出。 + +每个 Container 可能被允许也可能不被允许使用超过其 CPU 约束的处理时间。 +但是，容器不会由于 CPU 使用率过高而被杀死。 + +要确定 Container 是否会由于资源约束而无法调度或被杀死，请参阅[疑难解答](#troubleshooting) 部分。 + + + +## 监控计算和内存资源用量 + +Pod 的资源使用情况是作为 Pod 状态的一部分来报告的。 + +如果为集群配置了可选的 +[监控工具](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)， +则可以直接从 +[指标 API](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#the-metrics-api) +或者监控工具获得 Pod 的资源使用情况。 + + + +## 本地临时存储 + + +{{< feature-state for_k8s_version="v1.10" state="beta" >}} + +节点通常还可以具有本地的临时性存储，由本地挂接的可写入设备或者有时也用 RAM +来提供支持。 +“临时（Ephemeral）”意味着对所存储的数据不提供长期可用性的保证。 + +Pods 通常可以使用临时性本地存储来实现缓冲区、保存日志等功能。 +kubelet 可以为使用本地临时存储的 Pods 提供这种存储空间，允许后者使用 +[`emptyDir`](/docs/concepts/storage/volumes/#emptydir) 类型的 +{{< glossary_tooltip term_id="volume" text="卷" >}}将其挂载到容器中。 + + + +kubelet 也使用此类存储来保存 +[节点层面的容器日志](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)， +容器镜像文件、以及运行中容器的可写入层。 + +{{< caution >}} +如果节点失效，存储在临时性存储中的数据会丢失。 +你的应用不能对本地临时性存储的性能 SLA（例如磁盘 IOPS）作任何假定。 +{{< /caution >}} + +作为一种 beta 阶段功能特性，Kubernetes 允许你跟踪、预留和限制 Pod +可消耗的临时性本地存储数量。 + + + +### 本地临时性存储的配置 + +Kubernetes 有两种方式支持节点上配置本地临时性存储： + +{{< tabs name="local_storage_configurations" >}} +{{% tab name="单一文件系统" %}} +采用这种配置时，你会把所有类型的临时性本地数据（包括 `emptyDir` +卷、可写入容器层、容器镜像、日志等）放到同一个文件系统中。 +作为最有效的 kubelet 配置方式，这意味着该文件系统是专门提供给 Kubernetes +（kubelet）来保存数据的。 + +kubelet 也会生成 +[节点层面的容器日志](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)， +并按临时性本地存储的方式对待之。 + + + +kubelet 会将日志写入到所配置的日志目录（默认为 `/var/log`）下的文件中； +还会针对其他本地存储的数据使用同一个基础目录（默认为 `/var/lib/kubelet`）。 + +通常，`/var/lib/kubelet` 和 `/var/log` 都是在系统的根文件系统中。kubelet +的设计也考虑到这一点。 + +你的集群节点当然可以包含其他的、并非用于 Kubernetes 的很多文件系统。 +{{% /tab %}} + + + +{{% tab name="双文件系统" %}} + +你使用节点上的某个文件系统来保存运行 Pods 时产生的临时性数据：日志和 +`emptyDir` 卷等。你可以使用这个文件系统来保存其他数据（例如：与 Kubernetes +无关的其他系统日志）；这个文件系统还可以是根文件系统。 + +kubelet 也将 +[节点层面的容器日志](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level) +写入到第一个文件系统中，并按临时性本地存储的方式对待之。 + +同时你使用另一个由不同逻辑存储设备支持的文件系统。在这种配置下，你会告诉 +kubelet 将容器镜像层和可写层保存到这第二个文件系统上的某个目录中。 + +第一个文件系统中不包含任何镜像层和可写层数据。 + +当然，你的集群节点上还可以有很多其他与 Kubernetes 没有关联的文件系统。 +{{% /tab %}} +{{< /tabs >}} + + + +kubelet 能够度量其本地存储的用量。实现度量机制的前提是： + +- `LocalStorageCapacityIsolation` [特性门控](/docs/reference/command-line-tools-reference/feature-gates/)被启用（默认状态），并且 +- 你已经对节点进行了配置，使之使用所支持的本地临时性储存配置方式之一 + +如果你的节点配置不同于以上预期，kubelet 就无法对临时性本地存储的资源约束实施限制。 + +{{< note >}} +kubelet 会将 `tmpfs` emptyDir 卷的用量当作容器内存用量，而不是本地临时性存储来统计。 +{{< /note >}} + + + +### 为本地临时性存储设置请求和约束值 + +你可以使用_ephemeral-storage_来管理本地临时性存储。 +Pod 中的每个 Container 可以设置以下属性： + +* `spec.containers[].resources.limits.ephemeral-storage` +* `spec.containers[].resources.requests.ephemeral-storage` + +`ephemeral-storage` 的请求和约束值是按字节计量的。你可以使用一般整数或者定点整数 +加上下面的后缀来表达存储量：E、P、T、G、M、K。 +你也可以使用对应的 2 的幂级数来表达：Ei、Pi、Ti、Gi、Mi、Ki。 +例如，下面的表达式所表达的大致是同一个值： + +```shell +128974848, 129e6, 129M, 123Mi +``` + + + +在下面的例子中，Pod 包含两个 Container。每个 Container 请求 2 GiB 大小的本地临时性存储。 +每个 Container 都设置了 4 GiB 作为其本地临时性存储的约束值。 +因此，整个 Pod 的本地临时性存储请求是 4 GiB，且其本地临时性存储的约束为 8 GiB。 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: frontend +spec: + containers: + - name: db + image: mysql + env: + - name: MYSQL_ROOT_PASSWORD + value: "password" + resources: + requests: + ephemeral-storage: "2Gi" + limits: + ephemeral-storage: "4Gi" + - name: wp + image: wordpress + resources: + requests: + ephemeral-storage: "2Gi" + limits: + ephemeral-storage: "4Gi" +``` + + + +### 带 ephemeral-storage 的 Pods 的调度行为 + +当你创建一个 Pod 时，Kubernetes 调度器会为 Pod 选择一个节点来运行之。 +每个节点都有一个本地临时性存储的上限，是其可提供给 Pods 使用的总量。 +欲了解更多信息，可参考 +[节点可分配资源](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) +节。 + +调度器会确保所调度的 Containers 的资源请求总和不会超出节点的资源容量。 + + + +### 临时性存储消耗的管理 {#resource-emphemeralstorage-consumption} + +如果 kubelet 将本地临时性存储作为资源来管理，则 kubelet 会度量以下各处的存储用量： + +- `emptyDir` 卷，除了 _tmpfs_ `emptyDir` 卷 +- 保存节点层面日志的目录 +- 可写入的容器镜像层 + +如果某 Pod 的临时存储用量超出了你所允许的范围，kubelet +会向其发出逐出（eviction）信号，触发该 Pod 被逐出所在节点。 + +就容器层面的隔离而言，如果某容器的可写入镜像层和日志用量超出其存储约束， +kubelet 也会将所在的 Pod 标记为逐出候选。 + +就 Pod 层面的隔离而言，kubelet 会将 Pod 中所有容器的约束值相加，得到 Pod +存储约束的总值。如果所有容器的本地临时性存储用量总和加上 Pod 的 `emptyDir` +卷的用量超出 Pod 存储约束值，kubelet 也会将该 Pod 标记为逐出候选。 + + + +{{< caution >}} +如果 kubelet 没有度量本地临时性存储的用量，即使 Pod +的本地存储用量超出其约束值也不会被逐出。 + +不过，如果用于可写入容器镜像层、节点层面日志或者 `emptyDir` 卷的文件系统中可用空间太少， +节点会为自身设置本地存储不足的{{< glossary_tooltip text="污点" term_id="taint" >}} 标签。 +这一污点会触发对那些无法容忍该污点的 Pods 的逐出操作。 + +关于临时性本地存储的配置信息，请参考[这里](#configurations-for-local-ephemeral-storage) +{{< /caution >}} + + + +kubelet 支持使用不同方式来度量 Pod 的存储用量： + +{{< tabs name="resource-emphemeralstorage-measurement" >}} +{{% tab name="周期性扫描" %}} +kubelet 按预定周期执行扫描操作，检查 `emptyDir` 卷、容器日志目录以及可写入容器镜像层。 + +这一扫描会度量存储空间用量。 + +{{< note >}} +在这种模式下，kubelet 并不检查已删除文件所对应的、仍处于打开状态的文件描述符。 + +如果你（或者容器）在 `emptyDir` 卷中创建了一个文件，写入一些内容之后再次打开 +该文件并执行了删除操作，所删除文件对应的 inode 仍然存在，直到你关闭该文件为止。 +kubelet 不会将该文件所占用的空间视为已使用空间。 +{{< /note >}} + +{{% /tab %}} + + + +{{% tab name="文件系统项目配额" %}} + +{{< feature-state for_k8s_version="v1.15" state="alpha" >}} + +项目配额（Project Quota）是一个操作系统层的功能特性，用来管理文件系统中的存储用量。 +在 Kubernetes 中，你可以启用项目配额以监视存储用量。 +你需要确保节点上为 `emptyDir` 提供存储的文件系统支持项目配额。 +例如，XFS 和 ext4fs 文件系统都支持项目配额。 + +{{< note >}} +项目配额可以帮你监视存储用量，但无法对存储约束执行限制。 +{{< /note >}} + + + +Kubernetes 所使用的项目 ID 始于 `1048576`。 +所使用的 IDs 会注册在 `/etc/projects` 和 `/etc/projid` 文件中。 +如果该范围中的项目 ID 已经在系统中被用于其他目的，则已占用的项目 IDs +也必须注册到 `/etc/projects` 和 `/etc/projid` 中，这样 Kubernetes +才不会使用它们。 + +配额方式与目录扫描方式相比速度更快，结果更精确。当某个目录被分配给某个项目时， +该目录下所创建的所有文件都属于该项目，内核只需要跟踪该项目中的文件所使用的存储块个数。 +如果某文件被创建后又被删除，但对应文件描述符仍处于打开状态， +该文件会继续耗用存储空间。配额跟踪技术能够精确第记录对应存储空间的状态， +而目录扫描方式会忽略被删除文件所占用的空间。 + + + +如果你希望使用项目配额，你需要： + +* 在 kubelet 配置中启用 `LocalStorageCapacityIsolationFSQuotaMonitoring=true` + [特性门控](/docs/reference/command-line-tools-reference/feature-gates/)。 + +* 确保根文件系统（或者可选的运行时文件系统）启用了项目配额。所有 XFS + 文件系统都支持项目配额。 + 对 extf 文件系统而言，你需要在文件系统尚未被挂载时启用项目配额跟踪特性： + + ```bash + # 对 ext4 而言，在 /dev/block-device 尚未被挂载时执行下面操作 + sudo tune2fs -O project -Q prjquota /dev/block-device + ``` + +* 确保根文件系统（或者可选的运行时文件系统）在挂载时项目配额特性是被启用了的。 + 对于 XFS 和 ext4fs 而言，对应的挂载选项称作 `prjquota`。 + +{{% /tab %}} +{{< /tabs >}} + + + +## 扩展资源（Extended Resources） + +扩展资源是 `kubernetes.io` 域名之外的标准资源名称。 +它们使得集群管理员能够颁布非 Kubernetes 内置资源，而用户可以使用他们。 + +使用扩展资源需要两个步骤。首先，集群管理员必须颁布扩展资源。 +其次，用户必须在 Pod 中请求扩展资源。 + + + +### 管理扩展资源 + +#### 节点级扩展资源 + +节点级扩展资源绑定到节点。 + +##### 设备插件管理的资源 + +有关如何颁布在各节点上由设备插件所管理的资源，请参阅[设备插件](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)。 + + + +##### 其他资源 + +为了颁布新的节点级扩展资源，集群操作员可以向 API 服务器提交 `PATCH` HTTP 请求， +以在集群中节点的 `status.capacity` 中为其配置可用数量。 +完成此操作后，节点的 `status.capacity` 字段中将包含新资源。 +kubelet 会异步地对 `status.allocatable` 字段执行自动更新操作，使之包含新资源。 +请注意，由于调度器在评估 Pod 是否适合在某节点上执行时会使用节点的 `status.allocatable` 值， +在更新节点容量使之包含新资源之后和请求该资源的第一个 Pod 被调度到该节点之间， +可能会有短暂的延迟。 + + + +**示例：** + +这是一个示例，显示了如何使用 `curl` 构造 HTTP 请求，公告主节点为 `k8s-master` +的节点 `k8s-node-1` 上存在五个 `example.com/foo` 资源。 + +```shell +curl --header "Content-Type: application/json-patch+json" \ +--request PATCH \ +--data '[{"op": "add", "path": "/status/capacity/example.com~1foo", "value": "5"}]' \ +http://k8s-master:8080/api/v1/nodes/k8s-node-1/status +``` + + + +{{< note >}} +在前面的请求中，`~1` 是在 patch 路径中对字符 `/` 的编码。 +JSON-Patch 中的操作路径的值被视为 JSON-Pointer 类型。 +有关更多详细信息，请参见 +[IETF RFC 6901 第 3 节](https://tools.ietf.org/html/rfc6901#section-3)。 +{{< /note >}} + + + +#### 集群层面的扩展资源 + +集群层面的扩展资源并不绑定到具体节点。 +它们通常由调度器扩展程序（Scheduler Extenders）管理，这些程序处理资源消耗和资源配额。 + +您可以在[调度器策略配置](https://github.com/kubernetes/kubernetes/blob/release-1.10/pkg/scheduler/api/v1/types.go#L31)中指定由调度器扩展程序处理的扩展资源。 + + + +**示例：** + +下面的调度器策略配置标明集群层扩展资源 "example.com/foo" 由调度器扩展程序处理。 + +- 仅当 Pod 请求 "example.com/foo" 时，调度器才会将 Pod 发送到调度器扩展程序。 +- `ignoredByScheduler` 字段指定调度器不要在其 `PodFitsResources` 断言中检查 + "example.com/foo" 资源。 + +```json +{ + "kind": "Policy", + "apiVersion": "v1", + "extenders": [ + { + "urlPrefix":"", + "bindVerb": "bind", + "managedResources": [ + { + "name": "example.com/foo", + "ignoredByScheduler": true + } + ] + } + ] +} +``` + + + +### 使用扩展资源 + +就像 CPU 和内存一样，用户可以在 Pod 的规约中使用扩展资源。 +调度器负责资源的核算，确保同时分配给 Pod 的资源总量不会超过可用数量。 + + + +{{< note >}} +扩展资源取代了非透明整数资源（Opaque Integer Resources，OIR）。 +用户可以使用 `kubernetes.io` （保留）以外的任何域名前缀。 +{{< /note >}} + + + +要在 Pod 中使用扩展资源，请在容器规范的 `spec.containers[].resources.limits` +映射中包含资源名称作为键。 + +{{< note >}} +扩展资源不能过量使用，因此如果容器规范中同时存在请求和约束，则它们的取值必须相同。 +{{< /note >}} + + + +仅当所有资源请求（包括 CPU、内存和任何扩展资源）都被满足时，Pod 才能被调度。 +在资源请求无法满足时，Pod 会保持在 `PENDING` 状态。 + +**示例：** + +下面的 Pod 请求 2 个 CPU 和 1 个 "example.com/foo"（扩展资源）。 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: my-pod +spec: + containers: + - name: my-container + image: myimage + resources: + requests: + cpu: 2 + example.com/foo: 1 + limits: + example.com/foo: 1 +``` + + + +## 疑难解答 + +### 我的 Pod 处于悬决状态且事件信息显示 failedScheduling + +如果调度器找不到该 Pod 可以匹配的任何节点，则该 Pod 将保持未被调度状态， +直到找到一个可以被调度到的位置。每当调度器找不到 Pod 可以调度的地方时， +会产生一个事件，如下所示： + +```shell +kubectl describe pod frontend | grep -A 3 Events +``` +``` +Events: + FirstSeen LastSeen Count From Subobject PathReason Message + 36s 5s 6 {scheduler} FailedScheduling Failed for reason PodExceedsFreeCPU and possibly others +``` + + + +在上述示例中，由于节点上的 CPU 资源不足，名为 “frontend” 的 Pod 无法被调度。 +由于内存不足（PodExceedsFreeMemory）而导致失败时，也有类似的错误消息。 +一般来说，如果 Pod 处于悬决状态且有这种类型的消息时，你可以尝试如下几件事情： + +- 向集群添加更多节点。 +- 终止不需要的 Pod，为悬决的 Pod 腾出空间。 +- 检查 Pod 所需的资源是否超出所有节点的资源容量。例如，如果所有节点的容量都是`cpu：1`， + 那么一个请求为 `cpu: 1.1` 的 Pod 永远不会被调度。 + +您可以使用 `kubectl describe nodes` 命令检查节点容量和已分配的资源数量。 例如： + +```shell +kubectl describe nodes e2e-test-node-pool-4lw4 +``` +``` +Name: e2e-test-node-pool-4lw4 +[ ... 这里忽略了若干行以便阅读 ...] +Capacity: + cpu: 2 + memory: 7679792Ki + pods: 110 +Allocatable: + cpu: 1800m + memory: 7474992Ki + pods: 110 +[ ... 这里忽略了若干行以便阅读 ...] +Non-terminated Pods: (5 in total) + Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits + --------- ---- ------------ ---------- --------------- ------------- + kube-system fluentd-gcp-v1.38-28bv1 100m (5%) 0 (0%) 200Mi (2%) 200Mi (2%) + kube-system kube-dns-3297075139-61lj3 260m (13%) 0 (0%) 100Mi (1%) 170Mi (2%) + kube-system kube-proxy-e2e-test-... 100m (5%) 0 (0%) 0 (0%) 0 (0%) + kube-system monitoring-influxdb-grafana-v4-z1m12 200m (10%) 200m (10%) 600Mi (8%) 600Mi (8%) + kube-system node-problem-detector-v0.1-fj7m3 20m (1%) 200m (10%) 20Mi (0%) 100Mi (1%) +Allocated resources: + (Total limits may be over 100 percent, i.e., overcommitted.) + CPU Requests CPU Limits Memory Requests Memory Limits + ------------ ---------- --------------- ------------- + 680m (34%) 400m (20%) 920Mi (12%) 1070Mi (14%) +``` + + + +在上面的输出中，你可以看到如果 Pod 请求超过 1120m CPU 或者 6.23Gi 内存，节点将无法满足。 + +通过查看 `Pods` 部分，您将看到哪些 Pod 占用了节点上的资源。 + +可供 Pod 使用的资源量小于节点容量，因为系统守护程序也会使用一部分可用资源。 +[NodeStatus](/docs/resources-reference/{{< param "version" >}}/#nodestatus-v1-core) +的 `allocatable` 字段给出了可用于 Pod 的资源量。 +有关更多信息，请参阅 [节点可分配资源](https://git.k8s.io/community/contributors/design-proposals/node-allocatable.md)。 + +可以配置 [资源配额](/docs/concepts/policy/resource-quotas/) 功能特性以限制可以使用的资源总量。 +如果与名字空间配合一起使用，就可以防止一个团队占用所有资源。 + + + +### 我的容器被终止了 + +你的容器可能因为资源紧张而被终止。要查看容器是否因为遇到资源限制而被杀死， +请针对相关的 Pod 执行 `kubectl describe pod`： + +```shell +kubectl describe pod simmemleak-hra99 +``` + +``` +Name: simmemleak-hra99 +Namespace: default +Image(s): saadali/simmemleak +Node: kubernetes-node-tf0f/10.240.216.66 +Labels: name=simmemleak +Status: Running +Reason: +Message: +IP: 10.244.2.75 +Replication Controllers: simmemleak (1/1 replicas created) +Containers: + simmemleak: + Image: saadali/simmemleak + Limits: + cpu: 100m + memory: 50Mi + State: Running + Started: Tue, 07 Jul 2015 12:54:41 -0700 + Last Termination State: Terminated + Exit Code: 1 + Started: Fri, 07 Jul 2015 12:54:30 -0700 + Finished: Fri, 07 Jul 2015 12:54:33 -0700 + Ready: False + Restart Count: 5 +Conditions: + Type Status + Ready False +Events: + FirstSeen LastSeen Count From SubobjectPath Reason Message + Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {scheduler } scheduled Successfully assigned simmemleak-hra99 to kubernetes-node-tf0f + Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD pulled Pod container image "k8s.gcr.io/pause:0.8.0" already present on machine + Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD created Created with docker id 6a41280f516d + Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD started Started with docker id 6a41280f516d + Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} spec.containers{simmemleak} created Created with docker id 87348f12526a +``` + + + +在上面的例子中，`Restart Count: 5` 意味着 Pod 中的 `simmemleak` 容器被终止并重启了五次。 + +你可以使用 `kubectl get pod` 命令加上 `-o go-template=...` 选项来获取之前终止容器的状态。 + +```shell +kubectl get pod -o go-template='{{range.status.containerStatuses}}{{"Container Name: "}}{{.name}}{{"\r\nLastState: "}}{{.lastState}}{{end}}' simmemleak-hra99 +``` +``` +Container Name: simmemleak +LastState: map[terminated:map[exitCode:137 reason:OOM Killed startedAt:2015-07-07T20:58:43Z finishedAt:2015-07-07T20:58:43Z containerID:docker://0e4095bba1feccdfe7ef9fb6ebffe972b4b14285d5acdec6f0d3ae8a22fad8b2]] +``` + + + +你可以看到容器因为 `reason:OOM killed` 而被终止，`OOM` 表示内存不足（Out Of Memory）。 + +## {{% heading "whatsnext" %}} + + + +* 获取将 [分配内存资源给容器和 Pod ](/docs/tasks/configure-pod-container/assign-memory-resource/) 的实践经验 +* 获取将 [分配 CPU 资源给容器和 Pod ](/docs/tasks/configure-pod-container/assign-cpu-resource/) 的实践经验 +* 关于请求和约束之间的区别，细节信息可参见[资源服务质量](https://git.k8s.io/community/contributors/design-proposals/node/resource-qos.md) +* 阅读 API 参考文档中 [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) 部分。 +* 阅读 API 参考文档中 [ResourceRequirements](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcerequirements-v1-core) 部分。 +* 阅读 XFS 中关于 [项目配额](http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html) 的文档。 + From 01252c53ed73f4444aaf72a3be37068f946f7a67 Mon Sep 17 00:00:00 2001 From: yiyiyimu Date: Tue, 23 Jun 2020 17:47:47 +0800 Subject: [PATCH 131/218] Rename titles of two levels to the same --- .../tutorials/kubernetes-basics/update/update-interactive.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/zh/docs/tutorials/kubernetes-basics/update/update-interactive.html b/content/zh/docs/tutorials/kubernetes-basics/update/update-interactive.html index c917534b56..6f52711e17 100644 --- a/content/zh/docs/tutorials/kubernetes-basics/update/update-interactive.html +++ b/content/zh/docs/tutorials/kubernetes-basics/update/update-interactive.html @@ -1,5 +1,5 @@ --- -title: 交互式教程 - 更新应用 +title: 交互式教程 - 更新你的应用 weight: 20 --- + +Laman ini menunjukkan cara untuk menginstal `kubeadm`. +Untuk informasi mengenai cara membuat sebuah klaster dengan kubeadm setelah kamu melakukan proses instalasi ini, lihat laman [Menggunakan kubeadm untuk Membuat Sebuah Klaster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/). + + + +## {{% heading "prerequisites" %}} + + +* Satu mesin atau lebih yang menjalankan: + - Ubuntu 16.04+ + - Debian 9+ + - CentOS 7 + - Red Hat Enterprise Linux (RHEL) 7 + - Fedora 25+ + - HypriotOS v1.0.1+ + - Container Linux (teruji pada versi 1800.6.0) +* 2 GB RAM atau lebih per mesin (kurang dari nilai tersebut akan menyisakan sedikit ruang untuk + aplikasi-aplikasimu) +* 2 CPU atau lebih +* Koneksi internet pada seluruh mesin pada klaster (kamu dapat menggunakan internet + publik ataupun pribadi) +* _Hostname_ yang unik, alamat MAC, dan product_uuid untuk setiap Node. Lihat [di sini](#memastikan-alamat-mac) untuk detail lebih lanjut. +* Porta tertentu pada mesin. Lihat [di sini](#memeriksa-porta-yang-dibutuhkan) untuk detail lebih lanjut. +* _Swap_ dinonaktifkan. Kamu **HARUS** menonaktifkan _swap_ agar kubelet dapat berfungsi dengan baik. + + + + + +## Memastikan alamat MAC dan product_uuid yang unik untuk setiap Node {#memastikan-alamat-mac} + +* Kamu bisa mendapatkan alamat MAC dari antarmuka jaringan menggunakan perintah `ip link` atau `ifconfig -a` +* product_uuid didapatkan dengan perintah `sudo cat /sys/class/dmi/id/product_uuid` + +Sangat memungkinkan bagi perangkat keras untuk memiliki alamat yang unik, namun beberapa mesin virtual bisa memiliki +nilai yang identik. Kubernetes menggunakan nilai-nilai tersebut untuk mengidentifikasi Node-Node secara unik pada klaster. +Jika nilai-nilai tersebut tidak unik pada tiap Node, proses instalasi +bisa saja [gagal](https://github.com/kubernetes/kubeadm/issues/31). + +## Memeriksa adaptor jaringan + +Jika kamu memiliki lebih dari satu adaptor jaringan, dan komponen Kubernetes tidak dapat dijangkau melalui rute bawaan (_default route_), +kami merekomendasikan kamu untuk menambahkan rute IP sehingga alamat-alamat klaster Kubernetes melewati adaptor yang tepat. + +## Membuat iptables melihat _bridged traffic_ + +Agar iptables pada Node Linux dapat melihat _bridged traffic_ dengan benar, kamu harus memastikan `net.bridge.bridge-nf-call-iptables` bernilai 1 pada pengaturan `sysctl`, misalnya. + +```bash +cat <}}. + +{{< tabs name="container_runtime" >}} +{{% tab name="Linux nodes" %}} + +Secara bawaan, Kubernetes menggunakan +{{< glossary_tooltip term_id="cri" text="Container Runtime Interface">}} (CRI) +sebagai perantara dengan _runtime_ Container pilihanmu. + +Jika kamu tidak menentukan _runtime_, kubeadm secara otomatis mencoba untuk mendeteksi +_runtime_ Container yang terinstal dengan memindai sekumpulan soket domain Unix yang umum digunakan. +Tabel berikut menunjukkan _runtime_ Container dan lokasi soketnya: + +{{< table caption = "_Runtime_ Container dan lokasi soketnya" >}} +| _Runtime_ | Lokasi domain soket Unix | +|------------|-----------------------------------| +| Docker | `/var/run/docker.sock` | +| containerd | `/run/containerd/containerd.sock` | +| CRI-O | `/var/run/crio/crio.sock` | +{{< /table >}} + +
+Jika ditemukan Docker dan containerd secara bersamaan, Docker akan terpilih. Hal ini diperlukan +karena Docker 18.09 dirilis dengan containerd dan keduanya dapat ditemukan meskipun kamu +hanya menginstal Docker. +Jika ditemukan selain dari kedua _runtime_ Container tersebut, kubeadm akan berhenti dengan kegagalan. + +Komponen kubelet berintegrasi dengan Docker melalui implementasi CRI `dockershim` bawaannya. + +Lihat [_runtime_ Container](/docs/setup/production-environment/container-runtimes/) +untuk informasi lebih lanjut. +{{% /tab %}} +{{% tab name="sistem operasi lainnya" %}} +Secara bawaan, kubeadm menggunakan {{< glossary_tooltip term_id="docker" >}} sebagai _runtime_ Container. +Komponen kubelet berintegrasi dengan Docker melalui implementasi CRI `dockershim` bawaannya. + +Lihat [_runtime_ Container](/docs/setup/production-environment/container-runtimes/) +untuk informasi lebih lanjut. +{{% /tab %}} +{{< /tabs >}} + + +## Menginstal kubeadm, kubelet, dan kubectl + +Kamu akan menginstal _package_ berikut pada semua mesinmu: + +* `kubeadm`: alat untuk mem-_bootstrap_ klaster. + +* `kubelet`: komponen yang berjalan pada seluruh mesin pada klaster + dan memiliki tugas seperti menjalankan Pod dan Container. + +* `kubectl`: alat untuk berinteraksi dengan klastermu. + +Alat kubeadm **tidak akan** menginstal atau mengelola `kubelet` ataupun `kubectl` untukmu, jadi kamu harus memastikan +keduanya memiliki versi yang cocok dengan _control plane_ Kubernetes yang akan kamu instal +dengan kubeadm. Jika tidak, ada risiko _version skew_ yang dapat terjadi dan +dapat berujung pada perangai yang bermasalah dan tidak terduga. Namun, _satu_ _version skew_ minor antara +kubelet dan _control plane_ masih diperbolehkan, tetapi versi kubelet tidak boleh melebihi versi API +Server. Sebagai contoh, kubelet yang berjalan pada versi 1.7.0 akan kompatibel dengan API Server versi 1.8.0, tetapi tidak sebaliknya. + +Untuk informasi mengenai instalasi `kubectl`, lihat [Menginstal dan mengatur kubectl](/id/docs/tasks/tools/install-kubectl/). + +{{< warning >}} +Instruksi ini membuat seluruh _package_ Kubernetes keluar dari _system upgrade_. +Hal ini karena kubeadm dan Kubernetes membutuhkan +[perhatian khusus untuk pembaharuan](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/). +{{}} + +Untuk informasi lebih lanjut mengenai _version skew_, lihat: + +* [Kebijakan _version-skew_ dan versi Kubernetes](/docs/setup/release/version-skew-policy/) +* [Kebijakan _version skew_](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#version-skew-policy) yang spesifik untuk kubeadm + +{{< tabs name="k8s_install" >}} +{{% tab name="Ubuntu, Debian atau HypriotOS" %}} +```bash +sudo apt-get update && sudo apt-get install -y apt-transport-https curl +curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add - +cat < /etc/yum.repos.d/kubernetes.repo +[kubernetes] +name=Kubernetes +baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-\$basearch +enabled=1 +gpgcheck=1 +repo_gpgcheck=1 +gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg +exclude=kubelet kubeadm kubectl +EOF + +# Mengatur SELinux menjadi permissive mode (menonaktifkannya secara efektif) +setenforce 0 +sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config + +yum install -y kubelet kubeadm kubectl --disableexcludes=kubernetes + +systemctl enable --now kubelet +``` + + **Catatan:** + + - Mengatur SELinux menjadi _permissive mode_ dengan menjalankan `setenforce 0` dan `sed ...` menonaktifkannya secara efektif. + Hal ini diperlukan untuk mengizinkan Container untuk mengakses _filesystem_ hos, yang dibutuhkan untuk jaringan Pod sebagai contoh. + Kamu harus melakukan ini sampai dukungan SELinux ditingkatkan pada kubelet. + + - Kamu dapat membiarkan SELinux aktif jika kamu mengetahui cara mengonfigurasinya, tetapi hal tersebut mungkin membutuhkan pengaturan yang tidak didukung oleh kubeadm. + +{{% /tab %}} +{{% tab name="Container Linux" %}} +Menginstal _plugin_ CNI (dibutuhkan untuk kebanyakan jaringan Pod): + +```bash +CNI_VERSION="v0.8.2" +mkdir -p /opt/cni/bin +curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-linux-amd64-${CNI_VERSION}.tgz" | tar -C /opt/cni/bin -xz +``` + +Menginstal crictl (dibutuhkan untuk kubeadm / Kubelet Container Runtime Interface (CRI)) + +```bash +CRICTL_VERSION="v1.17.0" +mkdir -p /opt/bin +curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-amd64.tar.gz" | tar -C /opt/bin -xz +``` + +Menginstal `kubeadm`, `kubelet`, `kubectl` dan menambahkan _systemd service_ `kubelet`: + +```bash +RELEASE="$(curl -sSL https://dl.k8s.io/release/stable.txt)" + +mkdir -p /opt/bin +cd /opt/bin +curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/release/${RELEASE}/bin/linux/amd64/{kubeadm,kubelet,kubectl} +chmod +x {kubeadm,kubelet,kubectl} + +RELEASE_VERSION="v0.2.7" +curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/kubepkg/templates/latest/deb/kubelet/lib/systemd/system/kubelet.service" | sed "s:/usr/bin:/opt/bin:g" > /etc/systemd/system/kubelet.service +mkdir -p /etc/systemd/system/kubelet.service.d +curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/kubepkg/templates/latest/deb/kubeadm/10-kubeadm.conf" | sed "s:/usr/bin:/opt/bin:g" > /etc/systemd/system/kubelet.service.d/10-kubeadm.conf +``` + +Mengaktifkan dan menjalankan `kubelet`: + +```bash +systemctl enable --now kubelet +``` +{{% /tab %}} +{{< /tabs >}} + + +Sekarang kubelet akan melakukan _restart_ setiap beberapa detik, sambil menunggu dalam kondisi _crashloop_ sampai kubeadm memberikan instruksi yang harus dilakukan. + +## Mengonfigurasi _driver_ cgroup yang digunakan oleh kubelet pada Node _control-plane_ + +Ketika menggunakan Docker, kubeadm akan mendeteksi secara otomatis _driver_ cgroup untuk kubelet +dan mengaturnya pada berkas `/var/lib/kubelet/config.yaml` pada saat _runtime_. + +Jika kamu menggunakan CRI yang berbeda, kamu harus memodifikasi berkasnya dengan nilai `cgroupDriver` yang kamu gunakan, seperti berikut: + +```yaml +apiVersion: kubelet.config.k8s.io/v1beta1 +kind: KubeletConfiguration +cgroupDriver: +``` + +Harap diperhatikan, kamu **hanya** perlu melakukannya jika _driver_ cgroup dari CRI pilihanmu +bukanlah `cgroupfs`, karena nilai tersebut merupakan nilai bawaan yang digunakan oleh kubelet. + +{{< note >}} +Karena opsi `--cgroup-driver` sudah dihilangkan pada kubelet, jika kamu memilikinya pada `/var/lib/kubelet/kubeadm-flags.env` +atau `/etc/default/kubelet`(`/etc/sysconfig/kubelet` untuk RPM), silakan hapus dan gunakan KubeletConfiguration +(secara bawaan disimpan di `/var/lib/kubelet/config.yaml`). +{{< /note >}} + +Kamu harus melakukan _restart_ pada kubelet: + +```bash +systemctl daemon-reload +systemctl restart kubelet +``` + +Deteksi _driver_ cgroup secara otomatis untuk _runtime_ Container lainnya +seperti CRI-O dan containerd masih dalam proses pengembangan. + + +## Penyelesaian masalah + +Jika kamu menemui kesulitan dengan kubeadm, silakan merujuk pada [dokumen penyelesaian masalah](/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/). + +## {{% heading "whatsnext" %}} + + +* [Menggunakan kubeadm untuk Membuat Sebuah Klaster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) From a3af36a5afe40a9552d2a452aaaf84d88d0cb71d Mon Sep 17 00:00:00 2001 From: Arhell Date: Tue, 23 Jun 2020 16:41:48 +0300 Subject: [PATCH 135/218] update search placeholder --- layouts/partials/search-input.html | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/layouts/partials/search-input.html b/layouts/partials/search-input.html index f6ec2bc000..7278ac3b81 100644 --- a/layouts/partials/search-input.html +++ b/layouts/partials/search-input.html @@ -1,10 +1,10 @@ {{ if or .Site.Params.gcs_engine_id .Site.Params.algolia_docsearch }} - + {{ else if .Site.Params.offlineSearch }}
- +
{{ else if .Site.Params.k8s_search }} - + {{ end }} \ No newline at end of file From d8c12dd53a0aa2cd007dfc61bbeb2194a5e83cb2 Mon Sep 17 00:00:00 2001 From: Aris Cahyadi Risdianto Date: Sat, 13 Jun 2020 23:24:16 +0800 Subject: [PATCH 136/218] ID localization for pull-image-private-registry task. Fixing typos and translation words. --- .../pull-image-private-registry.md | 212 ++++++++++++++++++ content/id/examples/pods/private-reg-pod.yaml | 11 + 2 files changed, 223 insertions(+) create mode 100644 content/id/docs/tasks/configure-pod-container/pull-image-private-registry.md create mode 100644 content/id/examples/pods/private-reg-pod.yaml diff --git a/content/id/docs/tasks/configure-pod-container/pull-image-private-registry.md b/content/id/docs/tasks/configure-pod-container/pull-image-private-registry.md new file mode 100644 index 0000000000..2158afcf35 --- /dev/null +++ b/content/id/docs/tasks/configure-pod-container/pull-image-private-registry.md @@ -0,0 +1,212 @@ +--- +title: Menarik Image dari Register Pribadi +content_type: task +weight: 100 +--- + + + +Laman ini menunjukkan cara membuat Pod dengan menggunakan Secret untuk menarik _image_ dari sebuah +register atau repositori pribadi untuk Docker. + + +## {{% heading "prerequisites" %}} + + +* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +* Untuk melakukan latihan ini, kamu memerlukan sebuah +[nama pengguna (ID) Docker](https://docs.docker.com/docker-id/) dan kata sandi (_password_). + + + + +## Masuk (_login_) ke Docker {#masuk-ke-docker} + +Pada laptop kamu, kamu harus melakukan autentikasi dengan register untuk menarik _image_ pribadi: + +```shell +docker login +``` + +Ketika diminta, masukkan nama pengguna dan kata sandi Docker kamu. + +Proses _login_ membuat atau memperbarui berkas `config.json` yang menyimpan sebuah _token_ otorisasi. + +Lihatlah berkas `config.json`: + + +```shell +cat ~/.docker/config.json +``` + +Keluaran berisi bagian yang serupa dengan ini: + +```json +{ + "auths": { + "https://index.docker.io/v1/": { + "auth": "c3R...zE2" + } + } +} +``` + +{{< note >}} +Jika kamu menggunakan tempat penyimpanan kredensial (_credential_) untuk Docker, maka kamu tidak akan melihat entri `auth` tetapi entri `credsStore` dengan nama tempat penyimpanan sebagai nilainya. +{{< /note >}} + +## Membuat Secret berdasarkan kredensial Docker yang sudah ada {#register-secret-kredensial-yang-ada} + +Klaster Kubernetes menggunakan Secret dari tipe `docker-registry` untuk melakukan autentikasi dengan +register Container untuk menarik _image_ pribadi. + +Jika kamu sudah menjalankan `docker login`, kamu dapat menyalin kredensial itu ke Kubernetes: + +```shell +kubectl create secret generic regcred \ + --from-file=.dockerconfigjson= \ + --type=kubernetes.io/dockerconfigjson +``` + +Jika kamu memerlukan lebih banyak kontrol (misalnya, untuk mengatur Namespace atau label baru pada Secret) +maka kamu dapat menyesuaikan Secret tersebut sebelum menyimpannya. +Pastikan untuk: + + +- Mengatur nama dari pokok (_item_) data menjadi `.dockerconfigjson` +- Melakukan enkode secara _base64_ dari Dockerfile (berkas Docker) dan memindahkan urutan huruf (_string_) tersebut, secara tidak terputus sebagai nilai untuk bidang `data[".dockerconfigjson"]` +- Mengatur `type` menjadi `kubernetes.io/dockerconfigjson` + +Sebagai contoh: + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: myregistrykey + namespace: awesomeapps +data: + .dockerconfigjson: UmVhbGx5IHJlYWxseSByZWVlZWVlZWVlZWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGx5eXl5eXl5eXl5eXl5eXl5eXl5eSBsbGxsbGxsbGxsbGxsbG9vb29vb29vb29vb29vb29vb29vb29vb29vb25ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg== +type: kubernetes.io/dockerconfigjson +``` + +Jika kamu mendapat pesan kesalahan `error: no objects passed to create`, ini berarti pengkodean _base64_ dari urutan huruf tersebut tidak valid. +Jika kamu mendapat pesan kesalahan seperti `Secret "myregistrykey" is invalid: data[.dockerconfigjson]: invalid value ...`, ini berarti +enkode _base64_ dari urutan huruf dalam data tersebut sukses didekodekan, tetapi tidak bisa diuraikan menjadi berkas `.docker/config.json`. + +## Membuat Secret dengan memberikan kredensial pada baris perintah + +Buatlah Secret ini, dan berilah nama `regcred`: + +```shell +kubectl create secret docker-registry regcred --docker-server= --docker-username= --docker-password= --docker-email= +``` + +dimana: + +* `` merupakan FQDN dari register privat Docker kamu. (https://index.docker.io/v1/ untuk DockerHub) +* `` adalah nama pengguna Docker kamu. +* `` adalah kata sandi Docker kamu. +* `` adalah alamat email Docker kamu. + +Kamu telah berhasil mengatur kredensial untuk Docker kamu pada klaster sebagai sebuah Secret yang dipanggil dengan nama `regcred`. + +{{< note >}} + +Mengetik Secret pada baris perintah dapat menyimpannya dalam riwayat (_history_) dari _shell_ kamu tanpa perlindungan, dan +Secret tersebut mungkin juga terlihat oleh pengguna lain dalam PC kamu selama perintah `kubectl` sedang berjalan. +{{< /note >}} + + +## Menginspeksi Secret `regcred` {#menginspeksi-secret-regcred} + +Untuk memahami isi Secret `regcred` yang baru saja kamu buat, mulailah dengan melihat Secret dalam format YAML: + +```shell +kubectl get secret regcred --output=yaml +``` +Keluarannya akan seperti ini: + +```yaml +apiVersion: v1 +kind: Secret +metadata: + ... + name: regcred + ... +data: + .dockerconfigjson: eyJodHRwczovL2luZGV4L ... J0QUl6RTIifX0= +type: kubernetes.io/dockerconfigjson +``` + +Nilai dari bidang `.dockerconfigjson` merupakan representasi dalam _base64_ dari kredensial Docker kamu. + +Untuk memahami apa yang ada dalam bidang `.dockerconfigjson`, ubahlah data Secret menjadi format yang bisa terbaca: + +```shell +kubectl get secret regcred --output="jsonpath={.data.\.dockerconfigjson}" | base64 --decode +``` + +Keluarannya akan seperti ini: + +```json +{"auths":{"your.private.registry.example.com":{"username":"janedoe","password":"xxxxxxxxxxx","email":"jdoe@example.com","auth":"c3R...zE2"}}} +``` + +Untuk memahami apa yang ada dalam bidang `auth`, ubahlah data Secret menjadi format yang bisa terbaca: + +```shell +echo "c3R...zE2" | base64 --decode +``` + +Keluarannya, nama pengguna dan kata sandi yang digabungkan dengan tanda `:`, seperti dibawah ini: + +```none +janedoe:xxxxxxxxxxx +``` + +Perhatikan bahwa data Secret berisi token otorisasi yang serupa dengan berkas `~/.docker/config.json` lokal kamu. + +Kamu telah berhasil menetapkan kredensial Docker kamu sebagai sebuah Secret yang dipanggil dengan `regcred` pada klaster. + + +## Membuat Pod yang menggunakan Secret kamu + + +Berikut ini adalah berkas konfigurasi untuk Pod yang memerlukan akses ke kredensial Docker kamu pada `regcred`: + +{{< codenew file="pods/private-reg-pod.yaml" >}} + +Unduh berkas diatas: + +```shell +wget -O my-private-reg-pod.yaml https://k8s.io/examples/pods/private-reg-pod.yaml +``` + +Dalam berkas `my-private-reg-pod.yaml`, ubah `` dengan tautan ke _image_ dalam register pribadi seperti ini: + +```none +your.private.registry.example.com/janedoe/jdoe-private:v1 +``` + +Untuk menarik _image_ dari register pribadi, Kubernetes memerlukan kredensial. +Bidang `imagePullSecrets` dalam berkas konfigurasi menentukan bahwa Kubernetes harus mendapatkan kredensial dari Secret yang bernama `regcred`. + +Buatlah Pod yang menggunakan Secret kamu, dan verifikasi bahwa Pod tersebut berjalan: + +```shell +kubectl apply -f my-private-reg-pod.yaml +kubectl get pod private-reg +``` + + +## {{% heading "whatsnext" %}} + + +* Pelajari lebih lanjut tentang [Secret](/id/docs/concepts/configuration/secret/). +* Pelajari lebih lanjut tentang [menggunakan register pribadi](/id/docs/concepts/containers/images/#menggunakan-register-privat). +* Pelajari lebih lanjut tentang [menambahkan Secret untuk menarik _image_ ke dalam sebuah akun service](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account). +* Lihatlah [kubectl create secret docker-registry](/docs/reference/generated/kubectl/kubectl-commands/#-em-secret-docker-registry-em-). +* Lihatlah [Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core). +* Lihatlah bidang `imagePullSecrets` dari [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core). diff --git a/content/id/examples/pods/private-reg-pod.yaml b/content/id/examples/pods/private-reg-pod.yaml new file mode 100644 index 0000000000..594e47a7c5 --- /dev/null +++ b/content/id/examples/pods/private-reg-pod.yaml @@ -0,0 +1,11 @@ +apiVersion: v1 +kind: Pod +metadata: + name: private-reg +spec: + containers: + - name: private-reg-container + image: + imagePullSecrets: + - name: regcred + From 821f01b9da69963d6c24b532bbac0a7eb1cb741e Mon Sep 17 00:00:00 2001 From: Imre Nagi Date: Tue, 23 Jun 2020 22:39:45 +0700 Subject: [PATCH 137/218] Fix typo Signed-off-by: Imre Nagi --- .../docs/reference/access-authn-authz/rbac.md | 196 +++++++++--------- 1 file changed, 98 insertions(+), 98 deletions(-) diff --git a/content/id/docs/reference/access-authn-authz/rbac.md b/content/id/docs/reference/access-authn-authz/rbac.md index 44e6262f1c..27d060329f 100644 --- a/content/id/docs/reference/access-authn-authz/rbac.md +++ b/content/id/docs/reference/access-authn-authz/rbac.md @@ -38,32 +38,32 @@ untuk memahami bagaimana pembatasan tersebut dapat mencegah kamu melakukan beber Sebuah RBAC Role atau ClusterRole berisi aturan yang mewakili sekumpulan izin. Izin bersifat aditif (tidak ada aturan "tolak"). -Sebuah Role selalu mengatur izin dalam _namespace_ tertentu; -ketika kamu membuat Role, kamu harus menentukan _namespace_ tempat Role tersebut berada. +Sebuah Role selalu mengatur izin dalam Namespace tertentu; +ketika kamu membuat Role, kamu harus menentukan Namespace tempat Role tersebut berada. -ClusterRole, sebaliknya, adalah sumber daya tanpa _namespace_. Sumber daya tersebut memiliki nama yang berbeda (Role -dan ClusterRole) karena objek Kubernetes selalu harus menggunakan _namespace_ atau tanpa _namespace_; +ClusterRole, sebaliknya, adalah sumber daya tanpa Namespace. Sumber daya tersebut memiliki nama yang berbeda (Role +dan ClusterRole) karena objek Kubernetes selalu harus menggunakan Namespace atau tanpa Namespace; tidak mungkin keduanya. -ClusterRoles memiliki beberapa kegunaan. kamu bisa menggunakan ClusterRole untuk: +ClusterRole memiliki beberapa kegunaan. Kamu bisa menggunakan ClusterRole untuk: -1. mendefinisikan izin pada sumber daya dalam _namespace_ dan diberikan dalam sebuah _namespace_ atau lebih -1. mendefinisikan izin pada sumber daya dalam _namespace_ dan diberikan dalam seluruh _namespace_ +1. mendefinisikan izin pada sumber daya dalam Namespace dan diberikan dalam sebuah Namespace atau lebih +1. mendefinisikan izin pada sumber daya dalam Namespace dan diberikan dalam seluruh Namespace 1. mendefinisikan izin pada sumber daya yang dicakup klaster -Jika kamu ingin mendefinisikan sebuah peran dalam _namespace_, gunakan Role; jika kamu ingin mendefinisikan +Jika kamu ingin mendefinisikan sebuah peran dalam Namespace, gunakan Role; jika kamu ingin mendefinisikan peran di level klaster, gunakan ClusterRole. #### Contoh Role -Berikut adalah contoh Role dalam _namespace_ bawaan yang dapat digunakan +Berikut adalah contoh Role dalam Namespace bawaan yang dapat digunakan untuk memberikan akses baca pada Pod: ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: - namespace: default + Namespace: default name: pod-reader rules: - apiGroups: [""] # "" mengindikasikan core API group @@ -74,22 +74,22 @@ rules: #### Contoh ClusterRole ClusterRole dapat digunakan untuk memberikan izin yang sama dengan Role. -Karena ClusterRoles memiliki lingkup-klaster, kamu juga dapat menggunakannya untuk memberikan akses ke: +Karena ClusterRole memiliki lingkup-klaster, kamu juga dapat menggunakannya untuk memberikan akses ke: * sumber daya lingkup-klaster (seperti Nodes) -* _endpoints_ non-sumber daya (seperti `/healthz`) -* sumber daya _namespace_ (seperti Pod), di semua _namespace_ +* berbagai _endpoint_ non-sumber daya (seperti `/healthz`) +* sumber daya Namespace (seperti Pod), di semua Namespace Sebagai contoh: kamu bisa menggunakan ClusterRole untuk memungkinkan pengguna tertentu untuk menjalankan `kubectl get pods --all-namespaces`. Berikut adalah contoh ClusterRole yang dapat digunakan untuk memberikan akses baca pada -Secret di _namespace_ tertentu, atau di semua _namespace_ (tergantung bagaimana itu [terikat](#rolebinding-and-clusterrolebinding)): +Secret di Namespace tertentu, atau di semua Namespace (tergantung bagaimana itu [terikat](#rolebinding-dan-clusterrolebinding)): ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: - # "namespace" dihilangkan karena ClusterRoles tidak menggunakan namespace + # "namespace" dihilangkan karena ClusterRole tidak menggunakan Namespace name: secret-reader rules: - apiGroups: [""] @@ -105,29 +105,29 @@ Nama objek Role dan ClusterRole harus menggunakan [nama _path segment_](/docs/co ### RoleBinding dan ClusterRoleBinding Sebuah RoleBinding memberikan izin yang ditentukan dalam sebuah Role kepada pengguna atau sekelompok pengguna. -Ini menyimpan daftar subjek (pengguna, grup, atau _service accounts_), dan referensi ke -peran yang diberikan. -RoleBinding memberikan izin dalam _namespace_ tertentu sedangkan ClusterRoleBinding +Ini menyimpan daftar subjek (pengguna, grup, atau ServiceAccount), dan referensi ke +Role yang diberikan. +RoleBinding memberikan izin dalam Namespace tertentu sedangkan ClusterRoleBinding memberikan akses tersebut pada lingkup klaster. -RoleBinding dapat merujuk Role apa pun di _namespace_ yang sama. Atau, RoleBinding -dapat mereferensikan ClusterRole dan memasangkan ClusterRole tersebut ke _namespace_ dari RoleBinding. -Jika kamu ingin memasangkan ClusterRole ke semua _namespace_ di klaster kamu, kamu dapat menggunakan +RoleBinding dapat merujuk Role apa pun di Namespace yang sama. Atau, RoleBinding +dapat mereferensikan ClusterRole dan memasangkan ClusterRole tersebut ke Namespace dari RoleBinding. +Jika kamu ingin memasangkan ClusterRole ke semua Namespace di klaster kamu, kamu dapat menggunakan ClusterRoleBinding. Nama objek RoleBinding atau ClusterRoleBinding harus valid menggunakan [nama _path segment_](/docs/concepts/overview/working-with-objects/names#path-segment-names) yang valid. -#### Contoh RoleBinding {#rolebinding-example} +#### Contoh RoleBinding Berikut adalah contoh dari RoleBinding yang memberikan Role "pod-reader" kepada pengguna "jane" -pada _namespace_ bawaan. -Ini memungkinkan "jane" untuk membaca Pod di _namespace_ bawaan. +pada Namespace bawaan. +Ini memungkinkan "jane" untuk membaca Pod di Namespace bawaan. ```yaml apiVersion: rbac.authorization.k8s.io/v1 -# Role binding memungkinkan "jane" untuk membaca Pod di namespace bawaan -# Kamu harus sudah memiliki Role bernama "pod-reader" di namespace tersebut. +# Role binding memungkinkan "jane" untuk membaca Pod di Namespace bawaan +# Kamu harus sudah memiliki Role bernama "pod-reader" di Namespace tersebut. kind: RoleBinding metadata: name: read-pods @@ -144,25 +144,25 @@ roleRef: apiGroup: rbac.authorization.k8s.io ``` -RoleBinding juga bisa mereferensikan ClusterRole untuk memberikan izin yang didenisifikan di dalam -ClusterRole ke sumber daya di dalam _namespace_ RoleBinding. Referensi semacam ini -memungkinkan kamu menentukan sekumpulan peran yang umum di seluruh klaster kamu, lalu menggunakannya kembali di dalam -beberapa _namespace_. +RoleBinding juga bisa mereferensikan ClusterRole untuk memberikan izin yang didefinisikan di dalam +ClusterRole ke sumber daya di dalam Namespace RoleBinding. Referensi semacam ini +memungkinkan kamu menentukan sekumpulan Role yang umum di seluruh klaster kamu, lalu menggunakannya kembali di dalam +beberapa Namespace. Sebagai contoh, meskipun RoleBinding berikut merujuk ke ClusterRole, -"dave" (subjek, peka huruf besar-kecil) hanya akan dapat membaca Secrets di dalam _namespace_ "development", -karena _namespace_ RoleBinding (di dalam metadata-nya) adalah "development". +"dave" (subjek, peka huruf besar-kecil) hanya akan dapat membaca Secret di dalam Namespace "development", +karena Namespace RoleBinding (di dalam metadata-nya) adalah "development". ```yaml apiVersion: rbac.authorization.k8s.io/v1 -# role binding memungkinkan "dave" untuk membaca Secrets di namespace "development". +# role binding memungkinkan "dave" untuk membaca Secret di Namespace "development". # Kamu sudah harus memiliki ClusterRole bernama "secret-reader". kind: RoleBinding metadata: name: read-secrets # # Namespace dari RoleBinding menentukan dimana izin akan diberikan. - # Ini hanya memberikan izin di dalam namespace "development". + # Ini hanya memberikan izin di dalam Namespace "development". namespace: development subjects: - kind: User @@ -176,13 +176,13 @@ roleRef: #### Contoh ClusterRoleBinding -Untuk memberikan izin diseluruh klaster, kamu dapat menggunakan ClusterRoleBinding. +Untuk memberikan izin di seluruh klaster, kamu dapat menggunakan ClusterRoleBinding. ClusterRoleBinding berikut memungkinkan seluruh pengguna di dalam kelompok "manager" untuk -membaca rahasia di berbagai _namespace_. +membaca Secret di berbagai Namespace. ```yaml apiVersion: rbac.authorization.k8s.io/v1 -# Cluster role binding ini memungkinkan siapapun di dalam kelompok "manager" untuk membaca rahasia di berbagai namespace. +# Cluster role binding ini memungkinkan siapapun di dalam kelompok "manager" untuk membaca Secret di berbagai Namespace. kind: ClusterRoleBinding metadata: name: read-secrets-global @@ -204,23 +204,23 @@ Ada dua alasan untuk pembatasan tersebut: 1. Membuat `roleRef` tidak dapat diubah memungkinkan seseorang untuk melakukan `update` pada objek ikatan yang ada, sehingga mereka dapat mengelola daftar subyek, tanpa bisa berubah -peran yang diberikan kepada subyek tersebut. +Role yang diberikan kepada subyek tersebut. -1. Ikatan pada peran yang berbeda adalah ikatan yang berbeda secara fundamental. +1. Ikatan pada Role yang berbeda adalah ikatan yang berbeda secara fundamental. Mengharuskan sebuah ikatan untuk dihapus/diciptakan kembali untuk dalam upaya mengubah `roleRef` akan memastikan daftar lengkap subyek dalam ikatan akan diberikan diberikan -peran baru (sebagai langkah untuk mencegah modifikasi secara tidak sengaja hanya pada roleRef -tanpa memverifikasi semua subyek yang seharusnya diberikan izin pada peran baru). +Role baru (sebagai langkah untuk mencegah modifikasi secara tidak sengaja hanya pada roleRef +tanpa memverifikasi semua subyek yang seharusnya diberikan izin pada Role baru). Utilitas baris perintah `kubectl auth reconcile` membuat atau memperbaharui berkas manifes yang mengandung objek RBAC, -dan menangani penghapusan dan pembuatan objek ikatan jika dibutuhkan untuk mengganti peran yang dirunjuk. +dan menangani penghapusan dan pembuatan objek ikatan jika dibutuhkan untuk mengganti Role yang dirujuk. Lihat [penggunaan perintah dan contoh](#kubectl-auth-reconcile) untuk informasi tambahan. ### Mengacu pada sumber daya Pada API Kubernetes, sebagian besar sumber daya diwakili dan diakses menggunakan representasi nama objek, seperti `pods` untuk Pod. RBAC mengacu pada sumber daya yang menggunakan nama yang persis sama -dengan yang muncul di URL untuk _endpoints_ API yang relevan. +dengan yang muncul di URL untuk berbagai _endpoint_ API yang relevan. Beberapa Kubernetes APIs melibatkan _subresource_, seperti catatan untuk Pod. Permintaan untuk catatan Pod terlihat seperti: @@ -228,8 +228,8 @@ _subresource_, seperti catatan untuk Pod. Permintaan untuk catatan Pod terlihat GET /api/v1/namespaces/{namespace}/pods/{name}/log ``` -Dalam hal ini, `pods` adalah sumber daya _namespaced_ untuk sumber daya Pod, dan` log` adalah a -sub-sumber daya `pods`. Untuk mewakili ini dalam sebuah peran RBAC, gunakan garis miring (`/`) untuk +Dalam hal ini, `pods` adalah sumber daya Namespace untuk sumber daya Pod, dan `log` adalah sebuah +sub-sumber daya `pods`. Untuk mewakili ini dalam sebuah Role RBAC, gunakan garis miring (`/`) untuk membatasi sumber daya dan sub-sumber daya. Untuk memungkinkan subjek membaca `pods` dan juga mengakses sub-sumber daya `log` untuk masing-masing Pod tersebut, kamu dapat menulis: @@ -271,12 +271,12 @@ Kamu tidak dapat membatasi permintaan `create` atau` deletecollection` dengan na Keterbatasan ini dikarenakan nama objek yang tidak dikenal pada waktu otorisasi. {{< /note >}} -### Agregat ClusterRoles +### Agregat ClusterRole -Kamu dapat mengumpulkan beberapa ClusterRoles menjadi satu ClusterRole gabungan. -Controller, yang berjalan sebagai bagian dari _control plane_ klaster, mengamati objek ClusterRole +Kamu dapat mengumpulkan beberapa ClusterRole menjadi satu ClusterRole gabungan. +_Controller_, yang berjalan sebagai bagian dari _control plane_ klaster, mengamati objek ClusterRole dengan `aggregationRule`. `AggregationRule` mendefinisikan label -Selector yang digunakan oleh Controller untuk mencocokkan objek ClusterRole lain +Selector yang digunakan oleh _Controller_ untuk mencocokkan objek ClusterRole lain yang harus digabungkan ke dalam `rules`. Berikut adalah contoh ClusterRole agregat: @@ -313,12 +313,12 @@ rules: verbs: ["get", "list", "watch"] ``` -[Peran bawaan pengguna](#default-roles-and-role-bindings) menggunakan agregasi ClusterRole. Ini memungkinkan kamu, +[Role bawaan pengguna](#role-dan-role-binding-bawaan) menggunakan agregasi ClusterRole. Ini memungkinkan kamu, sebagai administrator klaster, menambahkan aturan untuk sumber daya kustom, seperti yang dilayani oleh CustomResourceDefinition -atau _aggregated_ server API, untuk memperluas peran bawaan. +atau _aggregated_ server API, untuk memperluas Role bawaan. -Sebagai contoh: ClusterRoles berikut mengizinkan peran bawaan "admin" dan "edit" mengelola sumber daya kustom -bernama CronTab, sedangkan peran "view" hanya dapat melakukan tindakan membaca sumber daya CronTab. +Sebagai contoh: ClusterRole berikut mengizinkan Role bawaan "admin" dan "edit" mengelola sumber daya kustom +bernama CronTab, sedangkan Role "view" hanya dapat melakukan tindakan membaca sumber daya CronTab. Kamu dapat mengasumsikan bahwa objek CronTab dinamai `"crontab"` dalam URL yang terlihat oleh server API. ```yaml @@ -327,7 +327,7 @@ kind: ClusterRole metadata: name: aggregate-cron-tabs-edit labels: - # Tambahkan izin berikut ke peran bawaan "admin" and "edit". + # Tambahkan izin berikut ke Role bawaan "admin" and "edit". rbac.authorization.k8s.io/aggregate-to-admin: "true" rbac.authorization.k8s.io/aggregate-to-edit: "true" rules: @@ -340,7 +340,7 @@ apiVersion: rbac.authorization.k8s.io/v1 metadata: name: aggregate-cron-tabs-view labels: - # Tambahkan izin berikut ke peran bawaan "view" + # Tambahkan izin berikut ke Role bawaan "view" rbac.authorization.k8s.io/aggregate-to-view: "true" rules: - apiGroups: ["stable.example.com"] @@ -350,7 +350,7 @@ rules: #### Contoh Role -Contoh berikut adalah potongan dari objek Peran atau ClusterRole, yang hanya menampilkan +Contoh berikut adalah potongan dari objek Role atau ClusterRole, yang hanya menampilkan bagian `rules`. Mengizinkan pembacaan sumber daya `"pods`` pada kumpulan API inti: @@ -365,7 +365,7 @@ rules: verbs: ["get", "list", "watch"] ``` -Mengizinkan pembacaan/penulisan Deployments (pada tingkat HTTP: objek dengan `"deployments"` +Mengizinkan pembacaan/penulisan Deployment (pada tingkat HTTP: objek dengan `"deployments"` di bagian sumber daya dari URL) pada masing-masing kumpulan API `"extensions"` dan `"apps"`: ```yaml @@ -398,7 +398,7 @@ rules: ``` Mengizinkan pembacaan ConfigMap bernama "my-config" (harus terikat dengan -RoleBinding untuk membatasi pada sebuah ConfigMap di sebuah _namespace_): +RoleBinding untuk membatasi pada sebuah ConfigMap di sebuah Namespace): ```yaml rules: @@ -436,14 +436,14 @@ rules: ### Mengacu Pada Subjek -RoleBinding atau ClusterRoleBinding mengikat sebuah peran ke subjek. -Subjek dapat berupa kelompok, pengguna atau ServiceAccounts. +RoleBinding atau ClusterRoleBinding mengikat sebuah Role ke subjek. +Subjek dapat berupa kelompok, pengguna atau ServiceAccount. -Kubernetes merepresentasikan _usernames_ sebagai string. +Kubernetes merepresentasikan _username_ sebagai string. Ini bisa berupa: nama sederhana, seperti "alice"; email, seperti "bob@example.com"; atau ID pengguna numerik yang direpresentasikan sebagai string. Terserah kamu sebagai administrator klaster -untuk mengkonfigurasi [authentication modules](/docs/reference/access-authn-authz/authentication/) -sehingga otentikasi menghasilkan _usernames_ dalam format yang kamu inginkan. +untuk mengkonfigurasi [modul otentikasi](/docs/reference/access-authn-authz/authentication/) +sehingga otentikasi menghasilkan _username_ dalam format yang kamu inginkan. {{< caution >}} Awalan `system:` direservasi untuk sistem Kubernetes, jadi kamu harus memastikan @@ -456,16 +456,16 @@ Di Kubernetes, modul otentikasi menyediakan informasi grup. Grup, seperti halnya pengguna, direpresentasikan sebagai string, dan string tersebut tidak memiliki format tertentu, selain awalan `system:` yang sudah direservasi. -[ServiceAccounts](/docs/tasks/configure-pod-container/configure-service-account/) memiliki nama yang diawali dengan `system:serviceaccount:`, dan menjadi milik grup yang diawali dengan nama `system:serviceaccounts:`. +[ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/) memiliki nama yang diawali dengan `system:serviceaccount:`, dan menjadi milik grup yang diawali dengan nama `system:serviceaccounts:`. {{< note >}} -- `system:serviceaccount:` (tunggal) adalah awalan untuk _service account usernames_. -- `system:serviceaccounts:` (jamak) adalah awalan untuk _service account_ grup. +- `system:serviceaccount:` (tunggal) adalah awalan untuk ServiceAccount _username_. +- `system:serviceaccounts:` (jamak) adalah awalan untuk ServiceAccount grup. {{< /note >}} #### Contoh RoleBinding {#role-binding-examples} -Contoh-contoh berikut ini hanya potongan `RoleBinding` yang hanya memperlihatkan +Contoh-contoh berikut ini hanya potongan RoleBinding yang hanya memperlihatkan bagian `subjects`. Untuk pengguna bernama `alice@example.com`: @@ -486,7 +486,7 @@ subjects: apiGroup: rbac.authorization.k8s.io ``` -Untuk _service account_ bawaan di _namespace_ "kube-system": +Untuk ServiceAccount bawaan di Namespace "kube-system": ```yaml subjects: @@ -495,7 +495,7 @@ subjects: namespace: kube-system ``` -Untuk seluruh _service account_ di _namespace_ qa: +Untuk seluruh ServiceAccount di Namespace qa: ```yaml subjects: @@ -504,7 +504,7 @@ subjects: apiGroup: rbac.authorization.k8s.io ``` -Untuk seluruh _service account_ di _namespace_ apapun: +Untuk seluruh ServiceAccount di Namespace apapun: ```yaml subjects: @@ -543,7 +543,7 @@ subjects: apiGroup: rbac.authorization.k8s.io ``` -## Role dan RoleBindings Bawaan +## Role dan RoleBinding Bawaan API membuat satu set objek ClusterRole dan ClusterRoleBinding bawaan. Sebagian besar dari objek berawalan `system:`, menunjukkan bahwa sumber daya tersebut @@ -551,7 +551,7 @@ secara langsung dikelolah oleh _control plane_ klaster. Seluruh ClusterRole dan `kubernetes.io/bootstrapping=rbac-defaults`. {{< caution >}} -Berhati-hatilah saat memodifikasih CLusterRole dan ClusterRoleBinding dengan nama yang +Berhati-hatilah saat memodifikasi CLusterRole dan ClusterRoleBinding dengan nama yang memiliki awalan `system:`. Modifikasi sumber daya ini dapat mengakibatkan klaster yang malfungsi. {{< /caution >}} @@ -560,7 +560,7 @@ Modifikasi sumber daya ini dapat mengakibatkan klaster yang malfungsi. Pada setiap _start-up-_, server API memperbaharui ClusterRole bawaan dengan berbagai izin yang hilang, dan memperbaharui ikatan ClusterRole bawaan dengan subjek yang hilang. -Ini memungkinkan klaster untuk memperbaiki modifikasi yang tidak disengaja, dan membantu menjaga peran +Ini memungkinkan klaster untuk memperbaiki modifikasi yang tidak disengaja, dan membantu menjaga Role dan RoleBinding selalu terkini karena izin dan subjek berubah pada rilis terbaru Kubernetes. Untuk menon-aktifkan rekonsiliasi ini, setel anotasi `rbac.authorization.kubernetes.io/autoupdate` @@ -569,12 +569,12 @@ Ingat bahwa hilangnya izin dan subjek bawaan dapat mengakibatkan klaster tidak b Rekonsiliasi otomatis diaktifkan secara bawaan jika otorizer RBAC aktif. -### API discovery roles {#discovery-roles} +### Role API discovery {#discovery-roles} RoleBinding bawaan memberi otorisasi kepada pengguna yang tidak terotentikasi untuk membaca informasi API yang dianggap aman untuk diakses publik (termasuk CustomResourceDefinitions). Untuk menonaktifkan akses anonim, tambahkan `--anonymous-auth=false` ke konfigurasi server API. -Untuk melihat konfigurasi peran ini melalui `kubectl` jalankan perintah: +Untuk melihat konfigurasi Role ini melalui `kubectl` jalankan perintah: ```shell kubectl get clusterroles system:discovery -o yaml @@ -582,7 +582,7 @@ kubectl get clusterroles system:discovery -o yaml {{< note >}} Jika kamu mengubah ClusterRole tersebut, perubahan kamu akan ditimpa pada penyalaan ulang server API melalui -[rekonsiliasi-otomatis](#auto-reconciliation). Untuk menghindari penulisan ulang tersebut, hindari mengubah peran secara manual, +[rekonsiliasi-otomatis](#auto-reconciliation). Untuk menghindari penulisan ulang tersebut, hindari mengubah Role secara manual, atau nonaktifkan rekonsiliasi otomatis {{< /note >}} @@ -597,12 +597,12 @@ atau nonaktifkan rekonsiliasi otomatis system:basic-user system:authenticated group -Mengizinkan pengguna hanya dengan akses baca untuk mengakses informasi dasar tentang diri mereka sendiri. Sebelum v1.14, peran ini juga terikat pada system:unauthenticated secara bawaan. +Mengizinkan pengguna hanya dengan akses baca untuk mengakses informasi dasar tentang diri mereka sendiri. Sebelum v1.14, Role ini juga terikat pada system:unauthenticated secara bawaan. system:discovery system:authenticated group -Mengizinkan akses baca pada _API discovery endpoints_ yang dibutuhkan untuk menemukan dan melakukan negosiasi pada tingkat API. Sebelum v1.14, peran ini juga terikat pada system:unauthenticated secara bawaan. +Mengizinkan akses baca pada berbagai _API discovery endpoint_ yang dibutuhkan untuk menemukan dan melakukan negosiasi pada tingkat API. Sebelum v1.14, Role ini juga terikat pada system:unauthenticated secara bawaan. system:public-info-viewer @@ -611,14 +611,14 @@ atau nonaktifkan rekonsiliasi otomatis -### Peran Pengguna +### Role Pengguna -Beberapa ClusterRole bawaan tidak diawali dengan `system:`. Ini dimaksudkan untuk peran pengguna. -Ini termasuk peran super-user (`cluster-admin`), peran yang dimaksudkan untuk diberikan akses seluruh klaster dengan -menggunakan ClusterRoleBinding, dan peran yang dimaksudkan untuk diberikan pada namespace tertentu +Beberapa ClusterRole bawaan tidak diawali dengan `system:`. Ini dimaksudkan untuk Role pengguna. +Ini termasuk Role super-user (`cluster-admin`), Role yang dimaksudkan untuk diberikan akses seluruh klaster dengan +menggunakan ClusterRoleBinding, dan Role yang dimaksudkan untuk diberikan pada Namespace tertentu dengan menggunakan RoleBinding (`admin`, `edit`, `view`). -ClusterRoles menggunakan [aggregasi ClusterRole](#aggregated-clusterroles) untuk mengizinkan admin untuk memasukan peraturan untuk sumber daya khusus pada ClusterRole ini. Untuk menambahkan aturan kepada peran `admin`, `edit`, atau `view`, buat sebuah CLusterRole +ClusterRole menggunakan [aggregasi ClusterRole](#aggregated-clusterroles) untuk mengizinkan admin untuk memasukan peraturan untuk sumber daya khusus pada ClusterRole ini. Untuk menambahkan aturan kepada Role `admin`, `edit`, atau `view`, buat sebuah CLusterRole dengan satu atau lebih label berikut: ```yaml @@ -640,37 +640,37 @@ metadata: cluster-admin system:masters group Mengizinkan akses super-user access untuk melakukan berbagai aksi pada berbagai sumber daya. -Ketika digunakan pada ClusterRoleBinding, ini memberikan kendali penuh terhadap seluruh sumber daya pada klaster dan seluruh namespace. -Ketika digunakan pada RoleBinding, ini memberikan kendali penuh terhadap setiap sumber daya pada namespace RoleBinding, termasuk namespace itu sendiri. +Ketika digunakan pada ClusterRoleBinding, ini memberikan kendali penuh terhadap seluruh sumber daya pada klaster dan seluruh Namespace. +Ketika digunakan pada RoleBinding, ini memberikan kendali penuh terhadap setiap sumber daya pada Namespace RoleBinding, termasuk Namespace itu sendiri. admin None -mengizinkan akses admin, yang dimaksudkan untuk diberikan dalam sebuah namespace menggunakan RoleBinding. -Jika digunakan dalam RoleBinding, ini memungkikan akses baca/tulis ke sebagian besar sumber daya di sebuah namespace, -termasuk kemampuan untuk membuat Role dan RoleBinding dalam namespace. -Peran ini tidak memungkinkan akses tulis pada kuota sumber daya atau ke namespace itu sendiri. +mengizinkan akses admin, yang dimaksudkan untuk diberikan dalam sebuah Namespace menggunakan RoleBinding. +Jika digunakan dalam RoleBinding, ini memungkikan akses baca/tulis ke sebagian besar sumber daya di sebuah Namespace, +termasuk kemampuan untuk membuat Role dan RoleBinding dalam Namespace. +Role ini tidak memungkinkan akses tulis pada kuota sumber daya atau ke Namespace itu sendiri. edit None -Mengizinkan akses baca/tulis pada seluruh objek dalam namespace. +Mengizinkan akses baca/tulis pada seluruh objek dalam Namespace. -Peran ini tidak memungkinkan untuk melihat dan merubah Role dan RoleBinding. -Namun, peran ini memungkinkan untuk mengakses secret dan menjalankan pod seperti ServiceAccount dalam namespace, -sehingga dapat digunakan untuk mendapatkan tingkat akses API dari setiap ServiceAccount di namespace. +Role ini tidak memungkinkan untuk melihat dan merubah Role dan RoleBinding. +Namun, Role ini memungkinkan untuk mengakses Secret dan menjalankan Pod seperti ServiceAccount dalam Namespace, +sehingga dapat digunakan untuk mendapatkan tingkat akses API dari setiap ServiceAccount di Namespace. view None -Mengizinkan akses baca untuk melihat hampir seluruh objek dalam namespace. +Mengizinkan akses baca untuk melihat hampir seluruh objek dalam Namespace. -Ini tidak memungkinkan untuk melihat peran dan RoleBinding. +Ini tidak memungkinkan untuk melihat Role dan RoleBinding. -Peran ini tidak memungkikan melihat Secret, karena pembacaan konten Secret memungkinkan -akses ke kredensial ServiceAccount dalam namespace, yang akan memungkinkan akses API sebagai -ServiceAccount apapun di namespace (bentuk eskalasi hak istimewa). +Role ini tidak memungkikan melihat Secret, karena pembacaan konten Secret memungkinkan +akses ke kredensial ServiceAccount dalam Namespace, yang akan memungkinkan akses API sebagai +ServiceAccount apapun di Namespace (bentuk eskalasi hak istimewa). From a0bfa31a4ba62e338384c13f6fbc674840780755 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Justin=20Br=C3=BBlotte?= Date: Tue, 23 Jun 2020 14:56:43 -0400 Subject: [PATCH 138/218] Remove extra space in documentation --- .../en/docs/tasks/administer-cluster/cpu-management-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/tasks/administer-cluster/cpu-management-policies.md b/content/en/docs/tasks/administer-cluster/cpu-management-policies.md index 1b29abf17c..5ffc40781a 100644 --- a/content/en/docs/tasks/administer-cluster/cpu-management-policies.md +++ b/content/en/docs/tasks/administer-cluster/cpu-management-policies.md @@ -36,7 +36,7 @@ By default, the kubelet uses [CFS quota](https://en.wikipedia.org/wiki/Completel to enforce pod CPU limits.  When the node runs many CPU-bound pods, the workload can move to different CPU cores depending on whether the pod is throttled and which CPU cores are available at -scheduling time.  Many workloads are not sensitive to this migration and thus +scheduling time. Many workloads are not sensitive to this migration and thus work fine without any intervention. However, in workloads where CPU cache affinity and scheduling latency From d41074866edbd91ab80f94f4f38e1869e7d60769 Mon Sep 17 00:00:00 2001 From: Rohit Mohta Date: Mon, 22 Jun 2020 13:32:10 -0700 Subject: [PATCH 139/218] Add a note about reserved namespace prefix A namespace with prefix 'kube-' is reserved, even though k8s will let you create that --- .../docs/concepts/overview/working-with-objects/namespaces.md | 4 ++++ content/en/docs/tasks/administer-cluster/namespaces.md | 4 ++++ 2 files changed, 8 insertions(+) diff --git a/content/en/docs/concepts/overview/working-with-objects/namespaces.md b/content/en/docs/concepts/overview/working-with-objects/namespaces.md index 5e3acc5123..07e7dac726 100644 --- a/content/en/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/en/docs/concepts/overview/working-with-objects/namespaces.md @@ -43,6 +43,10 @@ resources within the same namespace. Creation and deletion of namespaces are described in the [Admin Guide documentation for namespaces](/docs/admin/namespaces). +{{< note >}} + Avoid creating namespace with prefix `kube-`, since it is reserved for Kubernetes system namespaces. +{{< /note >}} + ### Viewing namespaces You can list the current namespaces in a cluster using: diff --git a/content/en/docs/tasks/administer-cluster/namespaces.md b/content/en/docs/tasks/administer-cluster/namespaces.md index be7906e40f..eabf58ff0b 100644 --- a/content/en/docs/tasks/administer-cluster/namespaces.md +++ b/content/en/docs/tasks/administer-cluster/namespaces.md @@ -82,6 +82,10 @@ See the [design doc](https://git.k8s.io/community/contributors/design-proposals/ ## Creating a new namespace +{{< note >}} + Avoid creating namespace with prefix `kube-`, since it is reserved for Kubernetes system namespaces. +{{< /note >}} + 1. Create a new YAML file called `my-namespace.yaml` with the contents: ```yaml From a4919b4e5023269eaa5fa3e23d82a10645d55916 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Wed, 24 Jun 2020 15:21:48 +0800 Subject: [PATCH 140/218] [zh] Sync kubectl cheatsheet This PR resync the Chinese translation of the kubectl cheatsheet. I realized that it is is out of sync because it still contains deprecated kubectl options such as `--export`. --- .../zh/docs/reference/kubectl/cheatsheet.md | 541 +++++++++++------- 1 file changed, 323 insertions(+), 218 deletions(-) diff --git a/content/zh/docs/reference/kubectl/cheatsheet.md b/content/zh/docs/reference/kubectl/cheatsheet.md index 4ef61cac63..b157fefd71 100644 --- a/content/zh/docs/reference/kubectl/cheatsheet.md +++ b/content/zh/docs/reference/kubectl/cheatsheet.md @@ -1,9 +1,5 @@ --- title: kubectl 备忘单 -reviewers: -- erictune -- krousey -- clove content_type: concept card: name: reference @@ -23,34 +19,42 @@ card: - -也可以看下: [Kubectl 概述](/docs/reference/kubectl/overview/) 和 [JsonPath 指南](/docs/reference/kubectl/jsonpath)。 + +另见: [Kubectl 概述](/docs/reference/kubectl/overview/) 和 [JsonPath 指南](/docs/reference/kubectl/jsonpath)。 - 本页面是 `kubectl` 命令的概述。 - - -## kubectl - 备忘单 + +# kubectl - 备忘单 - ## Kubectl 自动补全 ### BASH - +``` + +You can also use a shorthand alias for `kubectl` that also works with completion: +--> ```bash source <(kubectl completion bash) # 在 bash 中设置当前 shell 的自动补全，要先安装 bash-completion 包。 echo "source <(kubectl completion bash)" >> ~/.bashrc # 在您的 bash shell 中永久的添加自动补全 ``` - 您还可以为 `kubectl` 使用一个速记别名，该别名也可以与 completion 一起使用： ```bash @@ -60,25 +64,32 @@ complete -F __start_kubectl k ### ZSH - +``` +--> ```bash source <(kubectl completion zsh) # 在 zsh 中设置当前 shell 的自动补全 echo "if [ $commands[kubectl] ]; then source <(kubectl completion zsh); fi" >> ~/.zshrc # 在您的 zsh shell 中永久的添加自动补全 ``` - +detailed config file information. +--> ## Kubectl 上下文和配置 -设置 `kubectl` 与哪个 Kubernetes 集群进行通信并修改配置信息。查看 [使用 kubeconfig 跨集群授权访问](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) 文档获取详情配置文件信息。 +设置 `kubectl` 与哪个 Kubernetes 集群进行通信并修改配置信息。查看 +[使用 kubeconfig 跨集群授权访问](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) +文档获取配置文件详细信息。 - +``` +--> ```bash kubectl config view # 显示合并的 kubeconfig 配置。 @@ -115,36 +128,54 @@ KUBECONFIG=~/.kube/config:~/.kube/kubconfig2 kubectl config view # 获取 e2e 用户的密码 kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}' -kubectl config current-context # 展示当前所处的上下文 -kubectl config use-context my-cluster-name # 设置默认的上下文为 my-cluster-name +kubectl config view -o jsonpath='{.users[].name}' # 显示第一个用户 +kubectl config view -o jsonpath='{.users[*].name}' # 获取用户列表 +kubectl config get-contexts # 显示上下文列表 +kubectl config current-context # 展示当前所处的上下文 +kubectl config use-context my-cluster-name # 设置默认的上下文为 my-cluster-name -# 添加新的集群配置到 kubeconf 中，使用 basic auth 进行鉴权 +# 添加新的集群配置到 kubeconf 中，使用 basic auth 进行身份认证 kubectl config set-credentials kubeuser/foo.kubernetes.com --username=kubeuser --password=kubepassword -# 使用特定的用户名和命名空间设置上下文。 +# 在指定上下文中持久性地保存名字空间，供所有后续 kubectl 命令使用 +kubectl config set-context --current --namespace=ggckad-s2 + +# 使用特定的用户名和名字空间设置上下文 kubectl config set-context gce --user=cluster-admin --namespace=foo \ && kubectl config use-context gce + +kubectl config unset users.foo # 删除用户 foo ``` - + +## Apply +`apply` 通过定义 Kubernetes 资源的文件来管理应用。它通过运行 +`kubectl apply` 在集群中创建和更新资源。 +这是在生产中管理 Kubernetes 应用的推荐方法。 +参见 [Kubectl 文档](https://kubectl.docs.kubernetes.io)。 - -## 创建对象 + -Kubernetes 配置可以用 json 或 yaml 定义。可以使用的文件扩展名有 `.yaml`，`.yml` 和 `.json`。 +Kubernetes manifests can be defined in YAML or JSON. The file extension `.yaml`, +`.yml`, and `.json` can be used. +--> +## 创建对象 {#creating-objects} - +``` +--> ```bash kubectl apply -f ./my-manifest.yaml # 创建资源 kubectl apply -f ./my1.yaml -f ./my2.yaml # 使用多个文件创建 -kubectl apply -f ./dir # 从目录下的全部配置文件创建资源 -kubectl apply -f https://git.io/vPieo # 从 url 中创建资源 -kubectl create deployment nginx --image=nginx # 启动单实例 nginx -kubectl explain pods,svc # 获取 pod，svc 配置的文档说明 +kubectl apply -f ./dir # 基于目录下的所有清单文件创建资源 +kubectl apply -f https://git.io/vPieo # 从 URL 中创建资源 +kubectl create deployment nginx --image=nginx # 启动单实例 nginx +kubectl explain pods,svc # 获取 pod 清单的文档说明 -# 从标准输入中的多个 YAML 对象中创建 +# 从标准输入创建多个 YAML 对象 cat < -## 获取和查找资源 + +## 查看和查找资源 - -```bash -# 使用 get 命令获取基本输出 -kubectl get services # 列出当前命名空间下的所有 services -kubectl get pods --all-namespaces # 列出所有命名空间下的全部的 pods -kubectl get pods -o wide # 列出当前命名空间下的全部 pods，有更多的详细信息 -kubectl get deployment my-dep # 列出某个特定的 deployment -kubectl get pods --include-uninitialized # 列出当前命名空间下的全部 pods，包含未初始化的 -kubectl get pod my-pod -o yaml # 获取一个 pod 的 YAML -kubectl get pod my-pod -o yaml --export # 获取一个没有集群特定信息的 YAML -# 使用 describe 命令获取详细输出 +# Compares the current state of the cluster against the state that the cluster would be in if the manifest was applied. +kubectl diff -f ./my-manifest.yaml +``` +--> +```bash +# get 命令的基本输出 +kubectl get services # 列出当前命名空间下的所有 services +kubectl get pods --all-namespaces # 列出所有命名空间下的全部的 Pods +kubectl get pods -o wide # 列出当前命名空间下的全部 Pods，并显示更详细的信息 +kubectl get deployment my-dep # 列出某个特定的 Deployment +kubectl get pods # 列出当前命名空间下的全部 Pods +kubectl get pod my-pod -o yaml # 获取一个 pod 的 YAML + +# describe 命令的详细输出 kubectl describe nodes my-node kubectl describe pods my-pod -kubectl get services --sort-by=.metadata.name # 列出当前命名空间下所有 services，按照名称排序 +# 列出当前名字空间下所有 Services，按名称排序 +kubectl get services --sort-by=.metadata.name -# 列出 pods 按照重启次数进行排序 +# 列出 Pods，按重启次数排序 kubectl get pods --sort-by='.status.containerStatuses[0].restartCount' -# 列出测试命名空间中的 Pod，按容量排序 -kubectl get pods -n test --sort-by=.spec.capacity.storage +# 列举所有 PV 持久卷，按容量排序 +kubectl get pv --sort-by=.spec.capacity.storage -# 获取包含 app=cassandra 标签全部 pods 的 version 标签 +# 获取包含 app=cassandra 标签的所有 Pods 的 version 标签 kubectl get pods --selector=app=cassandra -o \ jsonpath='{.items[*].metadata.labels.version}' -# 获取所有工作节点(使用选择器以排除标签名称为 'node-role.kubernetes.io/master' 的结果) +# 获取所有工作节点（使用选择器以排除标签名称为 'node-role.kubernetes.io/master' 的结果） kubectl get node --selector='!node-role.kubernetes.io/master' -# 获取当前命名空间中正在运行的 pods +# 获取当前命名空间中正在运行的 Pods kubectl get pods --field-selector=status.phase=Running -# 获取全部 node 的 ExternalIP 地址 +# 获取全部节点的 ExternalIP 地址 kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}' -# 列出属于某个特定 RC 的 pods 的名称 -# "jq" 命令对于 jsonpath 过于复杂的转换非常有用，可以在 https://stedolan.github.io/jq/ 找到它。 +# 列出属于某个特定 RC 的 Pods 的名称 +# 在转换对于 jsonpath 过于复杂的场合，"jq" 命令很有用；可以在 https://stedolan.github.io/jq/ 找到它。 sel=${$(kubectl get rc my-rc --output=json | jq -j '.spec.selector | to_entries | .[] | "\(.key)=\(.value),"')%?} echo $(kubectl get pods --selector=$sel --output=jsonpath={.items..metadata.name}) -# 显示所有 Pod 的标签(或任何其他支持标签的 Kubernetes 对象) -# 也可以使用 "jq" -for item in $( kubectl get pod --output=name); do printf "Labels for %s\n" "$item" | grep --color -E '[^/]+$' && kubectl get "$item" --output=json | jq -r -S '.metadata.labels | to_entries | .[] | " \(.key)=\(.value)"' 2>/dev/null; printf "\n"; done - -# 或也可以使用此命令来获取与容器关联的所有标签 +# 显示所有 Pods 的标签（或任何其他支持标签的 Kubernetes 对象） kubectl get pods --show-labels -# 检查哪些节点处于 ready +# 检查哪些节点处于就绪状态 JSONPATH='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status};{end}{end}' \ && kubectl get nodes -o jsonpath="$JSONPATH" | grep "Ready=True" -# 列出被一个 pod 使用的全部 secret +# 列出被一个 Pod 使用的全部 Secret kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq -# 列出 events，按照创建时间排序 +# 列举所有 Pods 中初始化容器的容器 ID（containerID） +# Helpful when cleaning up stopped containers, while avoiding removal of initContainers. +kubectl get pods --all-namespaces -o jsonpath='{range .items[*].status.initContainerStatuses[*]}{.containerID}{"\n"}{end}' | cut -d/ -f3 + +# 列出事件（Events），按时间戳排序 kubectl get events --sort-by=.metadata.creationTimestamp + +# 比较当前的集群状态和假定某清单被应用之后的集群状态 +kubectl diff -f ./my-manifest.yaml ``` - + ## 更新资源 - -从版本 1.11 开始，`rolling-update` 已被弃用（参见 [CHANGELOG-1.11.md](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.11.md))，请使用 `rollout` 代替。 - - +``` +--> ```bash -kubectl set image deployment/frontend www=image:v2 # 滚动更新 "frontend" deployment 的 "www" 容器镜像 -kubectl rollout history deployment/frontend # 检查部署的历史记录，包括版本 +kubectl set image deployment/frontend www=image:v2 # 滚动更新 "frontend" Deployment 的 "www" 容器镜像 +kubectl rollout history deployment/frontend # 检查 Deployment 的历史记录，包括版本 kubectl rollout undo deployment/frontend # 回滚到上次部署版本 kubectl rollout undo deployment/frontend --to-revision=2 # 回滚到特定部署版本 -kubectl rollout status -w deployment/frontend # Watch "frontend" deployment 的滚动升级状态直到完成 +kubectl rollout status -w deployment/frontend # 监视 "frontend" Deployment 的滚动升级状态直到完成 +kubectl rollout restart deployment/frontend # 轮替重启 "frontend" Deployment -# 从 1.11 版本开始弃用 -kubectl rolling-update frontend-v1 -f frontend-v2.json # (弃用) 滚动升级 frontend-v1 的 pods -kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2 # (弃用) 修改资源的名称并更新镜像 -kubectl rolling-update frontend --image=image:v2 # (弃用) 更新 frontend 的 pods 的镜像 -kubectl rolling-update frontend-v1 frontend-v2 --rollback # (弃用) 终止已经进行中的 rollout +cat pod.json | kubectl replace -f - # 通过传入到标准输入的 JSON 来替换 Pod -cat pod.json | kubectl replace -f - # 通过传入到标准输入的 JSON 来替换 pod - -# 强制进行替换，会删除然后再创建资源，会导致服务不可用。 +# 强制替换，删除后重建资源。会导致服务不可用。 kubectl replace --force -f ./pod.json # 为多副本的 nginx 创建服务，使用 80 端口提供服务，连接到容器的 8000 端口。 kubectl expose rc nginx --port=80 --target-port=8000 -# 更新单容器 pod 的镜像标签到 v4 +# 将某单容器 Pod 的镜像版本（标签）更新到 v4 kubectl get pod mypod -o yaml | sed 's/\(image: myimage\):.*$/\1:v4/' | kubectl replace -f - kubectl label pods my-pod new-label=awesome # 添加标签 kubectl annotate pods my-pod icon-url=http://goo.gl/XXBTWq # 添加注解 -kubectl autoscale deployment foo --min=2 --max=10 # 使 "foo" deployment 自动伸缩容 +kubectl autoscale deployment foo --min=2 --max=10 # 对 "foo" Deployment 自动伸缩容 ``` -## 局部更新资源 +## 部分更新资源 - +``` +--> ```bash -kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}' # 部分更新 node +# 部分更新某节点 +kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}' -#更新容器的镜像；spec.containers[*].name 是必须的。因为它是一个合并 key。 +# 更新容器的镜像；spec.containers[*].name 是必须的。因为它是一个合并性质的主键。 kubectl patch pod valid-pod -p '{"spec":{"containers":[{"name":"kubernetes-serve-hostname","image":"new image"}]}}' -# 使用带位置数组的 json patch 更新容器的镜像 +# 使用带位置数组的 JSON patch 更新容器的镜像 kubectl patch pod valid-pod --type='json' -p='[{"op": "replace", "path": "/spec/containers/0/image", "value":"new image"}]' -# 使用带位置数组的 json patch 禁用 deployment 的 livenessProbe +# 使用带位置数组的 JSON patch 禁用某 Deployment 的 livenessProbe kubectl patch deployment valid-deployment --type json -p='[{"op": "remove", "path": "/spec/template/spec/containers/0/livenessProbe"}]' # 在带位置数组中添加元素 kubectl patch sa default --type='json' -p='[{"op": "add", "path": "/secrets/1", "value": {"name": "whatever" } }]' ``` - -## 编辑资源 - -在编辑器中编辑任何 API 资源 + +## 编辑资源 + +使用你偏爱的编辑器编辑 API 资源。 + + +``` +--> ```bash -kubectl edit svc/docker-registry # 编辑名为 docker-registry 的 service +kubectl edit svc/docker-registry # 编辑名为 docker-registry 的服务 KUBE_EDITOR="nano" kubectl edit svc/docker-registry # 使用其他编辑器 ``` - + ## 对资源进行伸缩 +``` +--> ```bash kubectl scale --replicas=3 rs/foo # 将名为 'foo' 的副本集伸缩到 3 副本 kubectl scale --replicas=3 -f foo.yaml # 将在 "foo.yaml" 中的特定资源伸缩到 3 个副本 -kubectl scale --current-replicas=2 --replicas=3 deployment/mysql # 如果名为 mysql 的 deployment 的副本当前是 2，那么将它伸缩到 3 -kubectl scale --replicas=5 rc/foo rc/bar rc/baz # 伸缩多个 replication controllers +kubectl scale --current-replicas=2 --replicas=3 deployment/mysql # 如果名为 mysql 的 Deployment 的副本当前是 2，那么将它伸缩到 3 +kubectl scale --replicas=5 rc/foo rc/bar rc/baz # 伸缩多个副本控制器 ``` - + ## 删除资源 +``` +--> ```bash -kubectl delete -f ./pod.json # 删除在 pod.json 中指定的类型和名称的 pod -kubectl delete pod,service baz foo # 删除名称为 "baz" 和 "foo" 的 pod 和 service -kubectl delete pods,services -l name=myLabel # 删除包含 name=myLabel 标签的 pods 和 services -kubectl delete pods,services -l name=myLabel --include-uninitialized # 删除包含 label name=myLabel 标签的 pods 和 services，包括未初始化的 -kubectl -n my-ns delete po,svc --all # 删除在 my-ns 命名空间中全部的 pods 和 services ，包括未初始化的 -# 删除所有与 pattern1 或 pattern2 匹配的 pod +kubectl delete -f ./pod.json # 删除在 pod.json 中指定的类型和名称的 Pod +kubectl delete pod,service baz foo # 删除名称为 "baz" 和 "foo" 的 Pod 和服务 +kubectl delete pods,services -l name=myLabel # 删除包含 name=myLabel 标签的 pods 和服务 +kubectl delete pods,services -l name=myLabel --include-uninitialized # 删除包含 label name=myLabel 标签的 Pods 和服务 +kubectl -n my-ns delete po,svc --all # 删除在 my-ns 名字空间中全部的 Pods 和服务 +# 删除所有与 pattern1 或 pattern2 awk 模式匹配的 Pods kubectl get pods -n mynamespace --no-headers=true | awk '/pattern1|pattern2/{print $1}' | xargs kubectl delete -n mynamespace pod ``` - + ## 与运行中的 Pods 进行交互 - +``` +--> ```bash -kubectl logs my-pod # 获取 pod 日志(标准输出) -kubectl logs -l name=myLabel # 获取 pod label name=myLabel 日志(标准输出) -kubectl logs my-pod --previous # 获取上个容器实例的 pod 日志(标准输出) -kubectl logs my-pod -c my-container # 获取 pod 的容器日志 (标准输出, 多容器的场景) -kubectl logs -l name=myLabel -c my-container # 获取 label name=myLabel pod 的容器日志 (标准输出, 多容器的场景) -kubectl logs my-pod -c my-container --previous # 获取 pod 的上个容器实例日志 (标准输出, 多容器的场景) -kubectl logs -f my-pod # 流式输出 pod 的日志 (标准输出) -kubectl logs -f my-pod -c my-container # 流式输出 pod 容器的日志 (标准输出, 多容器的场景) -kubectl logs -f -l name=myLabel --all-containers # 流式输出 label name=myLabel pod 的日志 (标准输出) -kubectl run -i --tty busybox --image=busybox -- sh # 以交互式 shell 运行 pod -kubectl attach my-pod -i # 进入到一个运行中的容器中 +kubectl logs my-pod # 获取 pod 日志（标准输出） +kubectl logs -l name=myLabel # 获取含 name=myLabel 标签的 Pods 的日志（标准输出） +kubectl logs my-pod --previous # 获取上个容器实例的 pod 日志（标准输出） +kubectl logs my-pod -c my-container # 获取 Pod 容器的日志（标准输出, 多容器场景） +kubectl logs -l name=myLabel -c my-container # 获取含 name=myLabel 标签的 Pod 容器日志（标准输出, 多容器场景） +kubectl logs my-pod -c my-container --previous # 获取 Pod 中某容器的上个实例的日志（标准输出, 多容器场景） +kubectl logs -f my-pod # 流式输出 Pod 的日志（标准输出） +kubectl logs -f my-pod -c my-container # 流式输出 Pod 容器的日志（标准输出, 多容器场景） +kubectl logs -f -l name=myLabel --all-containers # 流式输出含 name=myLabel 标签的 Pod 的所有日志（标准输出） +kubectl run -i --tty busybox --image=busybox -- sh # 以交互式 Shell 运行 Pod +kubectl run nginx --image=nginx -n mynamespace # 在指定名字空间中运行 nginx Pod +kubectl run nginx --image=nginx # 运行 ngins Pod 并将其规约写入到名为 pod.yaml 的文件 + --dry-run=client -o yaml > pod.yaml + +kubectl attach my-pod -i # 挂接到一个运行的容器中 kubectl port-forward my-pod 5000:6000 # 在本地计算机上侦听端口 5000 并转发到 my-pod 上的端口 6000 -kubectl exec my-pod -- ls / # 在已有的 pod 中运行命令(单容器的场景) -kubectl exec my-pod -c my-container -- ls / # 在已有的 pod 中运行命令(多容器的场景) -kubectl top pod POD_NAME --containers # 显示给定 pod 和容器的监控数据 +kubectl exec my-pod -- ls / # 在已有的 Pod 中运行命令（单容器场景） +kubectl exec my-pod -c my-container -- ls / # 在已有的 Pod 中运行命令（多容器场景） +kubectl top pod POD_NAME --containers # 显示给定 Pod 和其中容器的监控数据 ``` - + ## 与节点和集群进行交互 - +``` +--> ```bash -kubectl cordon my-node # 设置 my-node 节点为不可调度 -kubectl drain my-node # 对 my-node 节点进行驱逐操作，为节点维护做准备 -kubectl uncordon my-node # 设置 my-node 节点为可以调度 -kubectl top node my-node # 显示给定 node 的指标 -kubectl cluster-info # 显示 master 和 services 的地址 -kubectl cluster-info dump # 将当前集群状态输出到标准输出 +kubectl cordon my-node # 标记 my-node 节点为不可调度 +kubectl drain my-node # 对 my-node 节点进行清空操作，为节点维护做准备 +kubectl uncordon my-node # 标记 my-node 节点为可以调度 +kubectl top node my-node # 显示给定节点的度量值 +kubectl cluster-info # 显示主控节点和服务的地址 +kubectl cluster-info dump # 将当前集群状态转储到标准输出 kubectl cluster-info dump --output-directory=/path/to/cluster-state # 将当前集群状态输出到 /path/to/cluster-state -# 如果已存在具有该键和效果的污点，则其值将按指定替换 +# 如果已存在具有指定键和效果的污点，则替换其值为指定值 kubectl taint nodes foo dedicated=special-user:NoSchedule ``` - + ### 资源类型 - -列出全部支持的资源类型和它们的简称, [API group](/docs/concepts/overview/kubernetes-api/#api-groups), 无论它们是否是 [namespaced](/docs/concepts/overview/working-with-objects/namespaces), [Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects)。 + +列出所支持的全部资源类型和它们的简称、[API 组](/docs/concepts/overview/kubernetes-api/#api-groups), 是否是[名字空间作用域](/docs/concepts/overview/working-with-objects/namespaces) 和 [Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects)。 ```bash kubectl api-resources ``` - + 用于探索 API 资源的其他操作： - +``` +--> ```bash -kubectl api-resources --namespaced=true # 所有在命名空间中的资源 -kubectl api-resources --namespaced=false # 所有不在命名空间中的资源 -kubectl api-resources -o name # 输出简单的所有资源（只是资源名称） -kubectl api-resources -o wide # 具有扩展（又称 "wide"）输出的所有资源 +kubectl api-resources --namespaced=true # 所有命名空间作用域的资源 +kubectl api-resources --namespaced=false # 所有非命名空间作用域的资源 +kubectl api-resources -o name # 用简单格式列举所有资源（仅显示资源名称） +kubectl api-resources -o wide # 用扩展格式列举所有资源（又称 "wide" 格式） kubectl api-resources --verbs=list,get # 支持 "list" 和 "get" 请求动词的所有资源 kubectl api-resources --api-group=extensions # "extensions" API 组中的所有资源 ``` - + ### 格式化输出 - 要以特定格式将详细信息输出到终端窗口，可以将 `-o` 或 `--output` 参数添加到支持的 `kubectl` 命令。 - -输出格式 | 描述 +`-o=yaml` | Output a YAML formatted API object +--> +输出格式 | 描述 --------------| ----------- -`-o=custom-columns=` | 使用逗号分隔的自定义列列表打印表格 +`-o=custom-columns=` | 使用逗号分隔的自定义列来打印表格 `-o=custom-columns-file=` | 使用 `` 文件中的自定义列模板打印表格 `-o=json` | 输出 JSON 格式的 API 对象 `-o=jsonpath=