From 57f12c366020c97c2d4e427dbaec77e841176361 Mon Sep 17 00:00:00 2001 From: Ray Wang Date: Thu, 3 Dec 2020 17:29:26 +0800 Subject: [PATCH 001/128] Better module checking/initializing mechanism 1. Print a message to tell if modules need to be initialized when running `make serve` or other similar targets, and stop current make procedure. 2. Provide `module-init` target to initialize all dependencies Co-authored-by: Tim Bannister --- Makefile | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 58babc3627..a05c18aea2 100644 --- a/Makefile +++ b/Makefile @@ -19,7 +19,11 @@ help: ## Show this help. @awk 'BEGIN {FS = ":.*?## "} /^[a-zA-Z_-]+:.*?## / {sub("\\\\n",sprintf("\n%22c"," "), $$2);printf "\033[36m%-20s\033[0m %s\n", $$1, $$2}' $(MAKEFILE_LIST) module-check: - @git submodule status --recursive | awk '/^[+-]/ {printf "\033[31mWARNING\033[0m Submodule not initialized: \033[34m%s\033[0m\n",$$2}' 1>&2 + @git submodule status --recursive | awk '/^[+-]/ {err = 1; printf "\033[31mWARNING\033[0m Submodule not initialized: \033[34m%s\033[0m\n",$$2} END { if (err != 0) print "You need to run \033[32mmake module-init\033[0m to initialize missing modules first"; exit err }' 1>&2 + +module-init: + @echo "Initializing submodules..." 1>&2 + @git submodule update --init --recursive --depth 1 all: build ## Build site with production settings and put deliverables in ./public From 9ac0ee96651dae09fef9667ad9a79fbd8ed7cf7e Mon Sep 17 00:00:00 2001 From: Emanuel Haine Date: Tue, 2 Mar 2021 21:11:23 -0300 Subject: [PATCH 002/128] persistent-volumes.md translation from storage directory --- .../concepts/storage/persistent-volumes.md | 751 ++++++++++++++++++ 1 file changed, 751 insertions(+) create mode 100644 content/pt/docs/concepts/storage/persistent-volumes.md diff --git a/content/pt/docs/concepts/storage/persistent-volumes.md b/content/pt/docs/concepts/storage/persistent-volumes.md new file mode 100644 index 0000000000..4ed1fccdfc --- /dev/null +++ b/content/pt/docs/concepts/storage/persistent-volumes.md @@ -0,0 +1,751 @@ +--- +reviewers: +- jsafrane +- saad-ali +- thockin +- msau42 +- xing-yang +título: Persistentes Volumes +funcionalidade: + title: Orquestração de Storage + descrição: > + Mountar automaticamente o storage de sua escolha, seja de um storage local, de um provedor de cloud pública, como GCP ou AWS, ou um storage de rede, como NFS, iSCSI, Gluster, Ceph, Cinder ou Flocker. + +content_type: conceito +weight: 20 +--- + + + +Esse documento descreve o estado atual dos _persistent volumes_ no Kubernetes. Sugerimos que esteja familiarizado com [volumes](/docs/concepts/storage/volumes/). + + + +## Introdução + +Gerenciamento storage é uma questão bem diferente de gerenciamento de compute instances. O PersistentVolume subsystem provê uma API para usuários e administradores que mostra de forma detalhada de como o storage é provido e como ele é consumido. Para isso, nós introduzidmos duas novas APIs: PersistentVolume e PersistentVolumeClaim. + +Um _PersistentVolume_ (PV) é uma parte do storage dentro do cluster que tenha sido provisionada por um administrador ou dinamicamente utilizando [Storage Classes](/docs/concepts/storage/storage-classes/). Isso é um recurso dentro do cluster da mesma forma que um nó é um recurso dentro do cluster. PVs são plugins de volume da mesma forma que Volumes, porém eles têm um ciclo de vida independente de qualquer Pod que utilize um PV. Essa API tem por objetivo mostrar os detalhes da implementação do storage, seja ele NFS, iSCSI, ou um storage específico de um provedor de cloud pública. + +Um _PersistentVolumeClaim_ (PVC) é uma requisição para storage por um usuário. É similar a um Pod. Pods utilizam recursos do nó e PVCs utilizam recursos do PV. Pods podem solicitar níveis específicos de recursos (CPU e Memória). Claims podem requisitar tamanho e modos de acesso específicos (exemplo: montagem como ReadWriteOnce, ReadOnlyMany ou ReadWriteMany, veja [AccessModes](#access-modes)). + +Enquanto PersistentVolumeClaims permite que um usuário utilize recursos de storage de forma abstrata, é comum que usuários precisem de PersistentVolumes com diversas propriedades, como performance, para problemas diversos. Os administradores de cluster precisam estar aptos a oferecer uma variedade de PersistentVolumes que sejam diferentes em tamanho e modo de acesso, sem expor os usuários a detalhes de como esses volumes são implementados. Para necessidades como essa, temos o recurso de _StorageClass_. + +Veja os [exemplos de passo a passo de forma detalhada](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/). + +## Requisição e ciclo de vida de um volume + +PVs são recursos dentro um cluster. PVCs são requisições para esses recursos e também atuam como uma validação da solicitação desses recursos. O ciclo de vida da interação entre PVs e PVCs funcionam da seguinte forma: + +### Provisionamento + +Existem duas formas de provisionar ujm PV: staticamente ou dinamicamente. + +#### Stático + +O administrador do cluster cria uma determinada quantidade de PVs. Eles possuem todos os detalhes do storage a qual estão atrelados, que neste caso fica disponível para utilização por um usuário dentro do cluster. Eles estão presentes na API do Kubernetes e disponíveis para utilização. + +#### Dinâmico + +Quando nenhum dos PVs estáticos, que foram criados anteriormente pelo administrator, satisfazem os critérios de um PersistentVolumeClaim enviado por um usário, o cluster pode tentar realizar um provisionamento dinâmico para atender a esse PVC. +Esse provisionamento é baseado em StorageClasses: o PVC deve solicitar um [storage class](/docs/concepts/storage/storage-classes/) e o administrador deve ter previamente criado e configurado essa classe para que o provisionamento dinâmico possa ocorrer. Requisições que solicitam a classe `""` efetivamente desabilitam o provisionamento dinâmico para elas mesmas. + +Para habilitar o provisionamento de storage dinâmico baseado em storage class, o administrador do cluster precisa habilitar a `DefaultStorageClass` [admission controller](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) no servidor da API. Isso pode ser feito, por exemplo, garantindo que `DefaultStorageClass` esteja entre aspas simples, ordenado por uma lista de valores para a flag `--enable-admission-plugins`, componente do servidor da API. Para maiores informações sobre ndo das flags do servidor de API, consulte a documentação do [kube-apiserver](/docs/admin/kube-apiserver/). + +### Binding + +Um usuário cria, ou em caso de um provisionamento dinâmico já ter criado, um PersistentVolumeClaim solicitando uma quantidade específica de storage e um determinado modo de acesso. Um controle de loop no master monitora por novos PVCs, encontra um PV (se possível) que satisfaça os requisitos e realiza o bind. Se o PV foi provisionado dinamicamente por um PVC, o loop sempre vai fazer o bind desse PV com esse específico PVC. Caso contrário, o usuário vai receber no mínimo o que ele tinha solicitado, porém o volume possa exceder em relação à solicitação. Uma vez realizado esse processo, PersistentVolumeClaim sempre vai ter um bind exclusivo, sem levar em conta como o isso aconteceu. Um bind entre um PVC e um PV é um mapeamento de um pra um, utilizando o ClaimRef que é um bind bidirecional entre o PersistentVolume e o PersistentVolumeClaim. + +Requisições permanecerão sem bind se o volume solicitado não existir. O bind ocorrerá somente se os requisitos forem atendidos exatamente da mesma forma como solicitado. Por exemplo, um bind de um PVC de 100GB não vai ocorrer num cluster que foi provisionado com vários PVs de 50GB. O bind ocorrerá somente no momento em que um PV de 100GB for adicionado. + +### Utilização + +Pods utilizam requisições como volumes. O cluster inspeciona a requisição para encontrar o volume atrelado a ela e monta esse volume para um Pod. Para volumes que suportam múltiplos modos de acesso, o usuário es +pecifica qual o modo desejado quando utiliza essas requisições. + +Uma vez que o usuário tem a requisição atrelada a um PV, ele pertence ao usuário pelo tempo que ele precisar. Usuários agendam Pods e acessam seus PVs requisitados através da seção `persistentVolumeClaim` no bloco `volumes` do Pod. Para mais detalhes sobre isso, veja [Claims As Volumes](#claims-as-volumes). + +### Storage Object in Proteção de Uso + +O propósito da funcionalidade do Storage Object in Use Protection é garantir que PersistentVolumeClaims (PVCs) que estejam sendo utilizados por um Pod e PersistentVolume (PVs) que pertecem aos PVCs não sejam removidos do sistema, pois isso pode resultar numa perda de dados. + +{{< note >}} +Um PVC está sendo utilizado por um Pod quando existe um Pod que está usando esse PVC. +{{< /note >}} + +Se um usuário deleta um PVC que está sendo utilizado por um Pod, este PVC não é removido imediatamente. A remoção do PVC é adiada até que o PVC não esteja mais sendo utilizado por nenhum Pod. Se um admin deleta um PV que está atrelado a um PVC, o PV não é removido imediatamente também. A remoção do PV é adiada até que o PV não esteja mais atrelado ao PVC. + +Você pode ver que um PVC é protegido quando o status do PVC é `Terminating` e a lista `Finalizers` contém `kubernetes.io/pvc-protection`: + +```shell +kubectl describe pvc hostpath +Name: hostpath +Namespace: default +StorageClass: example-hostpath +Status: Terminating +Volume: +Labels: +Annotations: volume.beta.kubernetes.io/storage-class=example-hostpath + volume.beta.kubernetes.io/storage-provisioner=example.com/hostpath +Finalizers: [kubernetes.io/pvc-protection] +... +``` + +Você pode ver que um PV é protegido quando o status do PVC é `Terminating` e a lista `Finalizers` contém `kubernetes.io/pv-protection` também: + +```shell +kubectl describe pv task-pv-volume +Name: task-pv-volume +Labels: type=local +Annotations: +Finalizers: [kubernetes.io/pv-protection] +StorageClass: standard +Status: Terminating +Claim: +Reclaim Policy: Delete +Access Modes: RWO +Capacity: 1Gi +Message: +Source: + Type: HostPath (bare host directory volume) + Path: /tmp/data + HostPathType: +Events: +``` + +### Recuperação + +Quando um usuário não precisar mais utilizar um volume, ele pode deletar o PVC pela API, que por sua vez permite a recuperação do recurso. A política de recuperação para um PersistentVolume diz ao cluster o que fazer com o volume após ele ter sido liberado da sua requisição. Atualmente, volumes podem ser Retidos, Reciclados ou Deletados. + +#### Retenção + +A política de `Retain` permite a recuperação de forma manual do recurso. Quando o PersistentVolumeClaim é deletado, ele continua existindo e o volume é considerado "liberado". Mas ele ainda não está disponível para outra requisição porque os dados da requisição anterior ainda permanecem no volume. Um administrador pode manuamente recuperar o volume executando os seguintes passos: + +1. Deletar o PersistentVolume. O storage assset associado à infraestrutura externa (AWS EBS, GCE PD, Azure Disk, or Cinder volume) ainda continuará existindo após o PV ser deletado. +1. Limpar os dados de forma manual no storage assset associado. +1. Deletar manualmente o storage associado. Caso você queira utilizar o mesmo storage asset, crie um novo PersistentVolume com esse storage asset. + +#### Deletar + +Para plugins de volume que suportam a política de recuperação `Delete`, a deleção vai remover o tanto PersistentVolume do Kubernetes, quanto o storage asset associado à infraestrutura externa, como AWS EBS, GCE PD, Azure Disk, ou Cinder volume. Volumes que foram provisionados dinamicamente herdam o [reclaim policy of their StorageClass](#reclaim-policy), que é `Delete` por padrão. O administrador precisa configurar o StorageClass de acordo com as necessidades dos usuários; caso contrário, o PV deve ser editado or reparado após sua criação. Veja [Change the Reclaim Policy of a PersistentVolume](/docs/tasks/administer-cluster/change-pv-reclaim-policy/). + +#### Reciclar + +{{< warning >}} +A política de retenção `Recycle` está depreciada. Ao invés disso, recomendamos a utilização de provisionametno dinâmico. +{{< /warning >}} + +Em caso do volume plugin ter suporte a essa operação, a política de retenção do `Recycle` faz uma limpeza básica (`rm -rf /thevolume/*`) no volume e torna ele disponível novamente para outra requisiçaõ. + +Contudo, um administrador pode configurar um template personalizado de um Pod reciclador utilizando a linha de comando do gerenciamento de controle do Kubernetes como descrito em [reference](/docs/reference/command-line-tools-reference/kube-controller-manager/). +O Pod reciclador personalizado deve conter a spec `volume` como é mostrado no exemplo abaixo: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: pv-recycler + namespace: default +spec: + restartPolicy: Never + volumes: + - name: vol + hostPath: + path: /any/path/it/will/be/replaced + containers: + - name: pv-recycler + image: "k8s.gcr.io/busybox" + command: ["/bin/sh", "-c", "test -e /scrub && rm -rf /scrub/..?* /scrub/.[!.]* /scrub/* && test -z \"$(ls -A /scrub)\" || exit 1"] + volumeMounts: + - name: vol + mountPath: /scrub +``` + +Contudo, o caminho especificado no Pod reciclador personalizado em `volumes` é substituído pelo caminho do volume que está sendo reciclado. + +### Reservando um PersistentVolume + +A camada de gerenciamento pode [fazer o bind de um PersistentVolumeClaims com PersistentVolumes equivalentes](#binding) no cluster. Contudo, se você quer que um PVC faça um bind com um PV específco, é preciso fazer o pre-bind deles. + +Especificando um PersistentVolume no PersistentVolumeClaim, você declara um bind entre um PVC e um PV específico. +O bind ocorrerá se o PersistentVolume existir e não estiver reservado por um PersistentVolumeClaims através do seu campo `claimRef`. + +O bind ocorre independente de algum volume atender ao critério, incluindo afinidade de nó. +A camada de gerenciamento verifica se a [storage class](/docs/concepts/storage/storage-classes/), modo de acesso e tamanho do storage solicitado ainda são válidos. + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: foo-pvc + namespace: foo +spec: + storageClassName: "" # Empty string must be explicitly set otherwise default StorageClass will be set + volumeName: foo-pv + ... +``` + +Esse método não garante nenhum privilégio de bind no PersistentVolume. Para evitar que algum outro PersistentVolumeClaims possa usar o PV que você especificar, você precisa primeiro reservar esse storage volume. Especifique seu PersistentVolumeClaim no campo `claimRef` do PV para outros PVCs não façam bind nele. + +```yaml +apiVersion: v1 +kind: PersistentVolume +metadata: + name: foo-pv +spec: + storageClassName: "" + claimRef: + name: foo-pvc + namespace: foo + ... +``` + +Isso é útil se você deseja utilizar PersistentVolumes que possuem suas `claimPolicy` configuradas para `Retain`, incluindo situações onde você estiver reutilizando um PV existente. + +### Expandindo Requisições de Persistent Volumes + +{{< feature-state for_k8s_version="v1.11" state="beta" >}} + +Agora o suporte para expansão de PersistentVolumeClaims (PVCs) já é habilitado por padrão. Você pode expandir os tipos de volumes abaixo: + +* gcePersistentDisk +* awsElasticBlockStore +* Cinder +* glusterfs +* rbd +* Azure File +* Azure Disk +* Portworx +* FlexVolumes +* {{< glossary_tooltip text="CSI" term_id="csi" >}} + +Você só pode expandir um PVC se o campo do storage class `allowVolumeExpansion` é true. + +``` yaml +apiVersion: storage.k8s.io/v1 +kind: StorageClass +metadata: + name: gluster-vol-default +provisioner: kubernetes.io/glusterfs +parameters: + resturl: "http://192.168.10.100:8080" + restusuário: "" + secretNamespace: "" + secretName: "" +allowVolumeExpansion: true +``` + +Para solicitar um volume maior para um PVC, edite o PVC e especifique um tamanho maior. Isso irá fazer com o que volume atrelado ao respectivo PersistentVolume seja expandido. Nunca um PersistentVolume é criado para satisfazer a requisição. Ao invès disso, um volume existente é redimensionado. + +#### Expansão de volume CSI + +{{< feature-state for_k8s_version="v1.16" state="beta" >}} + +O suporte à expansão de volumes CSI é habilitada por padrão, porém é necessário um driver CSI específico para suportar a expansão do volume. Verifique a documentação do driver CSI específico para mais informações. + +#### Redimensionando um volume que contém um sistema de arquivo + +Só podem ser redimensionados os volumes que contém os seguintes sistemas de arquivo: XFS, Ext3 ou Ext4. + +Quando um volume contém um sistema de arquivo, o sistema de arquivo somente é redimensionado quando um novo Pod está utilizando PersistentVolumeClaim no modo `ReadWrite`. Expansão de sistema de arquivo é feita quando um Pod estiver inicializando ou quando um Pod estiver em execução e o respectivo sistema de arquivo suporta expansão online. + +FlexVolumes permitem redimensionamento se o `RequiresFSResize` do drive é configurado como `true`. +O FlexVolume pode ser redimensionado na reinicialização do Pod. + +#### Redimensionamento de um PersistentVolumeClaim em uso + +{{< feature-state for_k8s_version="v1.15" state="beta" >}} + +{{< note >}} +Expansão de PVCs em uso está disponível como beta desde Kubernetes 1.15, e como alpha desde 1.11. A funcionalidade `ExpandInUsePersistentVolumes` precisa ser habilitada, o que já está automático para vários clusters que possuem funcionalidades beta. Verifique a documentação [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) para maiores informações. +{{< /note >}} + +Neste caso você não precisa deletar e recriar um Pod ou um deployment que está sendo utilizado por um PVC existente. +Automaticamente, qualquer PVC em uso fica disponível para o Pod assim que o sistema de arquivo for expandido. +Essa funcionalidade não tem efeito em PVCs que não estão em uso por um Pod ou deployment. Você deve criar um Pod que utilize o PVC antes que a expansão seja completada. + +Da mesma forma que outros tipos de volumes - volumes FlexVolume também podem ser expandidos quando estiverem em uso por um Pod. + +{{< note >}} +Redimensionamento de FlexVolume somente é possível quando o respectivo driver suportar essa operação. +{{< /note >}} + +{{< note >}} +Expandir volumes EBS é uma operação que toma muito tempo. Além disso, é possível fazer uma modificação por volume a cada 6 horas. +{{< /note >}} + +#### Recuperação em caso de falha na expansão de volumes + +Se a expansão do respectivo storage falhar, o administrador do cluster pode recuperar manualmente o estado do Persistent Volume Claim (PVC) e cancelar as solicitações de redimensionamento. Caso contrário, as tentativas de solicitação de redimensionamento ocorrerão de forma contínua pelo controlador sem nenhuma intervenção do administrador. + +1. Marque o PersistentVolume(PV) que está atrelado ao PersistentVolumeClaim(PVC) com a política de recuperação `Retain`. +2. Delete o PVC. Desde que o PV tenha a política de recuperação `Retain` - nenhum dado será perdido quando o PVC for recriado. +3. Delete a entrada `claimRef` da especificação do PV para que um PVC possa fazer bind com ele. Isso deve tornar o PV `Available`. +4. Recrie o PVC com um tamanho menor que o PV e configure o campo `volumeName` do PCV com o nome do PV. Isso deve fazer o bind de um novo PVC a um PV existente. +5. Não esqueça de restaurar a política de recuperação do PV. + +## Tipos de volumes persistentes. + +Tipos de PersistentVolume são implementados como plugins. Atualmente o Kubernetes suporta os plugins abaixo: + +* [`awsElasticBlockStore`](/docs/concepts/storage/volumes/#awselasticblockstore) - AWS Elastic Block Store (EBS) +* [`azureDisk`](/docs/concepts/storage/volumes/#azuredisk) - Azure Disk +* [`azureFile`](/docs/concepts/storage/volumes/#azurefile) - Azure File +* [`cephfs`](/docs/concepts/storage/volumes/#cephfs) - CephFS volume +* [`cinder`](/docs/concepts/storage/volumes/#cinder) - Cinder (OpenStack block storage) + (**depreciado**) +* [`csi`](/docs/concepts/storage/volumes/#csi) - Container Storage Interface (CSI) +* [`fc`](/docs/concepts/storage/volumes/#fc) - Fibre Channel (FC) storage +* [`flexVolume`](/docs/concepts/storage/volumes/#flexVolume) - FlexVolume +* [`flocker`](/docs/concepts/storage/volumes/#flocker) - Flocker storage +* [`gcePersistentDisk`](/docs/concepts/storage/volumes/#gcepersistentdisk) - GCE Persistent Disk +* [`glusterfs`](/docs/concepts/storage/volumes/#glusterfs) - Glusterfs volume +* [`hostPath`](/docs/concepts/storage/volumes/#hostpath) - HostPath volume + (somente para teste de nó único; ISSO NÃO FUNCIONARÁ num cluster multi-nós; ao invés disso, considere utilizari volume `local`.) +* [`iscsi`](/docs/concepts/storage/volumes/#iscsi) - iSCSI (SCSI over IP) storage +* [`local`](/docs/concepts/storage/volumes/#local) - storage local montados nos nós. +* [`nfs`](/docs/concepts/storage/volumes/#nfs) - Network File System (NFS) storage +* `photonPersistentDisk` - Controlador Photon para disco persistente. + (Esse tipo de volume não funciona mais desde a removação do provedor de cloud correspondente.) +* [`portworxVolume`](/docs/concepts/storage/volumes/#portworxvolume) - Volume Portworx +* [`quobyte`](/docs/concepts/storage/volumes/#quobyte) - Volume Quobyte +* [`rbd`](/docs/concepts/storage/volumes/#rbd) - Volume Rados Block Device (RBD) +* [`scaleIO`](/docs/concepts/storage/volumes/#scaleio) - Volume ScaleIO + (**depreciado**) +* [`storageos`](/docs/concepts/storage/volumes/#storageos) - Volume StorageOS +* [`vsphereVolume`](/docs/concepts/storage/volumes/#vspherevolume) - Volume vSphere VMDK + +## Volumes Persistentes + +Cada PV contém uma spec e um status, que é a espeficiação e o status do volume. O nome de PersistentVolume deve ser um [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)válido. + +```yaml +apiVersion: v1 +kind: PersistentVolume +metadata: + name: pv0003 +spec: + capacity: + storage: 5Gi + volumeMode: Filesystem + accessModes: + - ReadWriteOnce + persistentVolumeReclaimPolicy: Reciclar + storageClassName: slow + mountOptions: + - hard + - nfsvers=4.1 + nfs: + path: /tmp + server: 172.17.0.2 +``` + +{{< note >}} +Talvez sejam necessários programas auxiliares para um determinado tipo de volume utilizar um PersistentVolume no cluster. Neste exemplo, o PersistentVolume é do tipo NFS e o programa auxiliar /sbin/mount.nfs é necessário para suportar a montagem dos sistemas de arquivos NFS. +{{< /note >}} + +### Capacidade + +Geralmente, um PV terá uma capacidade de storage específica. Isso é configurado usando o atributo `capacity` do PV. Veja Kubernetes [Resource Model](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) para entender as unidades aceitas pelo atributo `capacity`. + +Atualmente, o tamanho do storage é o único recurso que pode ser configurado ou solicitado. Os futuros atributos podem incluir IOPS, throughput, etc. + +### Modo do Volume + +{{< feature-state for_k8s_version="v1.18" state="stable" >}} + +O Kubernetes suporta dois `volumeModes` de PersistentVolumes: `Filesystem` e `Block`. + +`volumeMode` é um parâmetro opicional da API. +`Filesystem` é o modo padrão utilizado quando o parâmetro `volumeMode` é omitido. + +Um volume com `volumeMode: Filesystem` é *mounted* em um diretório nos Pods. Se o volume for de um dispositivo de bloco e ele estiver vazio, o Kubernetes cria o sistema de arquivo no dispositivo antes de fazer a montagem pela primeira vez. + +Você pode configurar o valor do `volumeMode` para `Block` para utilizar um disco bruto como volume. Esse volume é apresentado num Pod como um dispositivo de bloco, sem nenhum sistema de arquivo. Esse modo é útil para prover ao Pod a forma mais rápida para acessar um volume, sem nenhuma cama de sistema de arquivo entre o Pod e o volume. Por outro lado, a aplicação que estiver rodando no Pod deverá saber como tratar um dispositivo de bloco. Veja [Raw Block Volume Support](#raw-block-volume-support) para um exemplo de como utilizar o volume como `volumeMode: Block` num Pod. + +### Modos de Acesso + +Um PersistentVolume pode ser montado num host das mais variadas formas suportadas pelo provedor. Como mostrado na tabela abaixo, os provedores terão diferentes capacidades e cada modo de acesso do PV são configurados nos modos específicos suportados para cada volume em particular. Por exemplo, o NFS pode suportar múltiplos clientes read/write, mas um PV NFS específico pode ser exportado no server como read-only. Cada PV recebe seu próprio modo de acesso que descreve suas capacidades específicas. + +Os modos de acesso são: + +* ReadWriteOnce -- o volume pode ser montado como read-write por um nó único +* ReadOnlyMany -- o volume pode ser montado como ready-only por vários nós +* ReadWriteMany -- o volume pode ser montado como read-write por vários nós + +Na linha de comando, os modos de acesso ficam abreviados: + +* RWO - ReadWriteOnce +* ROX - ReadOnlyMany +* RWX - ReadWriteMany + +> __Importante!__ Um volume somente pode ser montado utilizando um único modo de acesso por vez, independente se ele suportar mais de um. Por exemplo, um GCEPersistentDisk pode ser montado como ReadWriteOnce por um único nó ou ReadOnlyMany por vários nós, porém não ao mesmo tempo. + + +| Plugin de Volume | ReadWriteOnce | ReadOnlyMany | ReadWriteMany| +| :--- | :---: | :---: | :---: | +| AWSElasticBlockStore | ✓ | - | - | +| AzureFile | ✓ | ✓ | ✓ | +| AzureDisk | ✓ | - | - | +| CephFS | ✓ | ✓ | ✓ | +| Cinder | ✓ | - | - | +| CSI | depende do driver | depende do driver | depende do driver | +| FC | ✓ | ✓ | - | +| FlexVolume | ✓ | ✓ | depende do driver | +| Flocker | ✓ | - | - | +| GCEPersistentDisk | ✓ | ✓ | - | +| Glusterfs | ✓ | ✓ | ✓ | +| HostPath | ✓ | - | - | +| iSCSI | ✓ | ✓ | - | +| Quobyte | ✓ | ✓ | ✓ | +| NFS | ✓ | ✓ | ✓ | +| RBD | ✓ | ✓ | - | +| VsphereVolume | ✓ | - | - (funcionam quando os Pods são do tipo collocated) | +| PortworxVolume | ✓ | - | ✓ | +| ScaleIO | ✓ | ✓ | - | +| StorageOS | ✓ | - | - | + +### Classe + +Um PV pode ter uma classe, que é especificada na configuração do atribute `storageClassName` com o nome da [StorageClass](/docs/concepts/storage/storage-classes/). Um PV de uma classe específica só pode ser atrelado a requições PVCs dessa mesma classe. Um PV sem `storageClassName` não possuí nenhuma classe e pode ser montado somente a PVCs que não solicitem nenhuma classe em específico. + +No passado, a notação `volume.beta.kubernetes.io/storage-class` era utilizada no lugar do atributo `storageClassName`. Essa notação ainda funciona; contudo, ela será totalmente depreciada numa futura release do Kubernetes. + +### Política de Retenção + +Atuamente as políticas de retenção são: + +* Retenção -- recuperação manual +* Reciclar -- limpeza básica (`rm -rf /thevolume/*`) +* Delete -- storage associado como AWS EBS, GCE PD, Azure Disk ou OpenStack Cinder volume is deleted + +Atualmente, somente NFS e HostPath suportam reciclagem. Volumes AWS EBS, GCE PD, Azure Disk, and Cinder suportam delete. + +### Opções de Montagem + +Um administrador do Kubernetes pode especificar opções de montagem adicionais quando um Persistent Volume é montado num nó. + +{{< note >}} +Nem todos os tipos de Persistent Volume suportam opções de montagem. +{{< /note >}} + +Seguem os tipos de volumes que suportam opções de montagem. + +* AWSElasticBlockStore +* AzureDisk +* AzureFile +* CephFS +* Cinder (OpenStack block storage) +* GCEPersistentDisk +* Glusterfs +* NFS +* Quobyte Volumes +* RBD (Ceph Block Device) +* StorageOS +* VsphereVolume +* iSCSI + +Não há validação em relação às opções de montagem. A montagem irá falhar se houver uma opção de montagem inválida. + +No passado, a notação `volume.beta.kubernetes.io/mount-options` era usada no lugar do atributo `mountOptions`. Essa notação ainda funciona; contudo, ela será totalmente depreciada numa futura release do Kubernetes. + +### Afinidade de Nó + +{{< note >}} +Para a maioria dos tipos de volume, a configurção desse campo não se faz necessária. Isso é automaticamente populado pelos seguintes volumes do tipo bloco: [AWS EBS](/docs/concepts/storage/volumes/#awselasticblockstore), [GCE PD](/docs/concepts/storage/volumes/#gcepersistentdisk) e [Azure Disk](/docs/concepts/storage/volumes/#azuredisk). Você precisa deixar isso configurado para volumes do tipo [local](/docs/concepts/storage/volumes/#local). +{{< /note >}} + +Um PV pode especificar uma [afinidade de nó](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volumenodeaffinity-v1-core) para definir restrições em relação ao limite de nós que podem acessar esse volume. Pods que utilizam um PV serão somente reservados para nós selecionados pela afinidade de nó. + +### Estado + +Um volume sempre estará em dos seguintes estados: + +* Available -- um recurso que está livre e ainda não foi atrelado a nenhuma requisição +* Bound -- um volume atrelado a uma requisição +* Released -- a requisião foi deletada, mas o curso ainda não foi recuperado pelo cluster +* Failed -- o volume fracassou na sua recuperação automática + + +A CLI mostrará o nome do PV que foi atrelado ao PVC +The CLI will show the name of the PVC bound to the PV. + +## PersistentVolumeClaims + +Cada PVC contém uma spec e um status, que é a especificação e estado de uma requisição. O nome de um objeto PersistentVolumeClaim precisa ser um [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) válido. + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: myclaim +spec: + accessModes: + - ReadWriteOnce + volumeMode: Filesystem + resources: + requests: + storage: 8Gi + storageClassName: slow + selector: + matchLabels: + release: "stable" + matchExpressions: + - {key: environment, operator: In, values: [dev]} +``` + +### Modos de Acesso + +As requisições usam as mesmas convenções que os volumes quando eles solicitam um storage com um modo de acesso específico. + +### Modos de Volume + +As requisições usam as mesmas convenções que os volumes quando eles indicam o tipo de volume, seja ele um sistema de arquivo ou dispositivo de bloco. + +### Recursos + +Assim como Pods, as requisições podem solicitar quantidades específicas de recurso. Neste caso, a solicitação é por storage. O mesmo [modelo de recurso](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) valem para volumes e requisições. + +### Selector + +Requisições podem especifiar um [label selector](/docs/concepts/overview/working-with-objects/labels/#label-selectors) para posteriormente filtrar um grupo de volumes. Somente os volumes que possuam labels que safistaçam os critérios do selector podem ser atreladas à requisição. O selector podem conter dois campos: + +* `matchLabels` - o volume deve ter uma label com esse valor +* `matchExpressions` - uma lista de requisitos, como chave, lista de valores e operador relacionado aos valores e chaves. São operadores válidos: In, NotIn, Exists e DoesNotExist. + +Todos os requisitos de `matchLabels` e `matchExpressions`, são do tipo AND - todos eles juntos devem ser atendidos. + +### Classe + +Uma requisição pode solicitar uma classe específica através da [StorageClass](/docs/concepts/storage/storage-classes/) utilizando o atributo `storageClassName`. Neste caso o bind ocorrerá somente com os PVs que possuírem a mesma classe do `storageClassName` dos PVCs. + +Os PVCs não precisam necessariamente solicitar uma classe. Um PVC com seu `storageClassName` configurado como `""` sempre vai solicitar um PV sem classe, dessa forma ele sempre será atrelado a um PV sem classe (que não tenha nenhuma notação ou seja igual a `""`). Um PVC sem `storageClassName` não é a mesma coisa e será tratado pelo cluster de forma diferente, porém isso vai depender se o [`DefaultStorageClass` admission plugin](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) estiver habilitado. + +* Se o admission plugin estiver habilitado, o administrador pode especificar o StorageClass padrão. Todos os PVCs que não tiverem `storageClassName` podem ser atrelados somente a PVs que atendam a essa padrão. A especificação de um StorageClass padrão é feita através da notação `storageclass.kubernetes.io/is-default-class` recebendo o valor `true` no objeto do StorageClass. Se o administrador não especificar nenhum padrão, o cluster vai tratar a criação de um PVC como se o admission plugin estivesse desabilitado. Se mais de um valor padrão for especificado, o admission plugin proíbe a criação de todos os PVCs. +* Se o admission plugin estiver desabilitado, não haverá nenhuma notação para o StorageClass padrão. Todos os PVCs que não tiverem `storageClassName` poderão ser atrelados somente aos PVs que não possuem classe.Neste caso, os PVCs que não tiverem `storageClassName` são tratados da mesma forma como os PVCs que possuem seus `storageClassName` configurados como `""`. + +Dependendo do modo de instalação, um StorageClass padrão pode ser deployed num cluster Kubernetes durante a instalação pelo addon manager. + +Quando um PVC especifica um `selector` para solicitar um StorageClass, os requisitos são do tipo AND: somente um PV com a classe solicitada e com a label requisistada pode ser atrelado ao PVC. + +{{< note >}} +Atualmente, um PVC que tenha `selector` não pode ter um PV dinamicamente provisionado. +{{< /note >}} + +No passado, a notação `volume.beta.kubernetes.io/storage-class` era usada no lugar do atribute `storageClassName` Essa notação ainda funciona; contudo, ela será totalmente depreciada numa futura release do Kubernetes. + +## Requisições como Volumes + +Os Pods podem ter acesso ao storage utilizando a requisição como um volume. Para isso a requisição tem que estar no mesmo namespace que o Pod. Ao localizar a requisição no namespace do Pod, o cluster passa o PersistentVolume para a requisição. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + containers: + - name: myfrontend + image: nginx + volumeMounts: + - mountPath: "/var/www/html" + name: mypd + volumes: + - name: mypd + persistentVolumeClaim: + claimName: myclaim +``` + +### Sobre Namespaces + +Os binds dos PersistentVolumes são exclusivos e desde que PersistentVolumeClaims são objetos do namespace, fazer a montagem das requisições com "Muitos" nós (`ROX`, `RWX`) é possível somente para um namespace. + +### PersistentVolumes do tipo `hostPath` + +Um PersistentVolume do tipo `hostPath` utiliza um arquivo ou diretório no nó para emular um network-attached storage (NAS). +A `hostPath` PersistentVolume uses a file or directory on the Node to emulate network-attached storage. Veja um [um exemplo de volume do tipo `hostPath`](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume). + + +## Raw Block Volume Support + +{{< feature-state for_k8s_version="v1.18" state="stable" >}} + + +Os plugins de volume abaixo suportam raw block volumes, incluindo provisionamento dinâmico onde for possível: +applicable: + +* AWSElasticBlockStore +* AzureDisk +* CSI +* FC (Fibre Channel) +* GCEPersistentDisk +* iSCSI +* Local volume +* OpenStack Cinder +* RBD (Ceph Block Device) +* VsphereVolume + + +### PersistentVolume using a Raw Block Volume {#persistent-volume-using-a-raw-block-volume} + +```yaml +apiVersion: v1 +kind: PersistentVolume +metadata: + name: block-pv +spec: + capacity: + storage: 10Gi + accessModes: + - ReadWriteOnce + volumeMode: Block + persistentVolumeReclaimPolicy: Retain + fc: + targetWWNs: ["50060e801049cfd1"] + lun: 0 + readOnly: false +``` + +### PersistentVolumeClaim requesting a Raw Block Volume {#persistent-volume-claim-requesting-a-raw-block-volume} + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: block-pvc +spec: + accessModes: + - ReadWriteOnce + volumeMode: Block + resources: + requests: + storage: 10Gi +``` + + +### Pod specification adding Raw Block Device path in container + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: pod-with-block-volume +spec: + containers: + - name: fc-container + image: fedora:26 + command: ["/bin/sh", "-c"] + args: [ "tail -f /dev/null" ] + volumeDevices: + - name: data + devicePath: /dev/xvda + volumes: + - name: data + persistentVolumeClaim: + claimName: block-pvc +``` + +{{< note >}} + +Quando adicionar a raw block device para um Pod, você especifica o caminho do dispositivo no container ao invés de um mount path +{{< /note >}} + +### Bind de Volumes de Bloco + +Se um usuário solicita um raw block volume através do campo `volumeMode` na spec do PersistentVolumeClaim, as regras de bind agora têm uma pequena diferença em relação às versões anteriores que não vão considerar esse modo como parte da spec. + +A tabela abaixo mostra as possíveis combinações que um usuário e um admin pode especificar para requisitar um raw block device. A tabela indica se o volume será ou não atrelado com base nas combinações: +Matrix de bind de volume para provisionamento estático de volumes: + +| PV volumeMode | PVC volumeMode | Result | +| --------------|:---------------:| ----------------:| +| unspecified | unspecified | BIND | +| unspecified | Block | NO BIND | +| unspecified | Filesystem | BIND | +| Block | unspecified | NO BIND | +| Block | Block | BIND | +| Block | Filesystem | NO BIND | +| Filesystem | Filesystem | BIND | +| Filesystem | Block | NO BIND | +| Filesystem | unspecified | BIND | + +{{< note >}} + +O provisionamento estático de volumes é suportado somente na versão alpha. Administradores devem tomar cuidado ao considerar esses valores quando estiverem trabalhando com raw block devices. +{{< /note >}} + +## Snapshot de Volume e Restauração de Volume a partir de um Snapshot + +{{< feature-state for_k8s_version="v1.20" state="stable" >}} + +O snapshot de volume é suportado somente pelo plugin de volume CSI. Veja [Volume Snapshots](/docs/concepts/storage/volume-snapshots/) para mais detalhes. +Plugins de volume in-tree estão depreciados. Você pode consultar sobre os plugins de volume depreciados em [Volume Plugin FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md). + +### Criar um PersistentVolumeClaim a partir de um Snapshot de Volume {#create-persistent-volume-claim-from-volume-snapshot} + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: restore-pvc +spec: + storageClassName: csi-hostpath-sc + dataSource: + name: new-snapshot-test + kind: VolumeSnapshot + apiGroup: snapshot.storage.k8s.io + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 10Gi +``` + +## Clonagem de Volume + +[Volume Cloning](/docs/concepts/storage/volume-pvc-datasource/) only available for CSI volume plugins. + +### Criação de PersistentVolumeClaim a partir de um PVC já existente {#create-persistent-volume-claim-from-an-existing-pvc} + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: cloned-pvc +spec: + storageClassName: my-csi-plugin + dataSource: + name: existing-src-pvc-name + kind: PersistentVolumeClaim + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 10Gi +``` + +## Boas Práticas de Configuração + +Se você está criando templates ou exemplos que rodam numa grande quantidade de clusters e que precisam de storage persistente, recomendamos que utilize a estrutura abaixo: + +- Inclua objetos PersistentVolumeClaim em seu pacote de configuração (juntanemte com Deployments, ConfigMaps, etc). +- Não inclua objetos PersistentVolume na configuração, pois o usuário que irá instanciar a configuração talvez não tenha permissão para criar PersistentVolume. + the config may not have permission to create PersistentVolumes. +- Dê ao usuário a opção dele informar o nome de uma classe de storage quando instaciar o template. + - Se o usuário informar o nome de uma classe de storage, coloque esse valor no campo `persistentVolumeClaim.storageClassName`. Isso fará com que o PVC encontre a classe de storage correta se o cluster tiver o StorageClasses habilitado pelo administrador. + - Se o usuário não informar o nome da classe de storage, deixe o campo `persistentVolumeClaim.storageClassName` sem nenhum valor (null). Isso fará com que o PV seja provisionado automaticamente no cluster para o usuário com o StorageClass padrão. Em muitos ambientes, o StorageClass padrão já instalado no cluster, ou então, os administradores podem criar seus StorageClass padrão. +- Durante suas tarefas de administração, busque por PVCs que após um tempo não estão sendo atrelados, pois isso talvez indique que o cluster não tem provisionamento dinâmico (que no caso, o usuário deveria criar um PV que satisfaça os critérios do PVC) ou cluster não tem um sistema de storage (que no caso, o usuário não pode fazer deploy solicitando PVCs). + + ## {{% heading "whatsnext" %}} + + +* Saiba mais sobre [Criando um PersistentVolume](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume). +* Saiba mais sobre [Criando um PersistentVolumeClaim](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolumeclaim). +* Leia a [documentação sobre plajemamento de Storage Persistente](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md). + +### Referência + +* [PersistentVolume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolume-v1-core) +* [PersistentVolumeSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumespec-v1-core) +* [PersistentVolumeClaim](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core) + From 16793b7e7f011398fb885a7d280ea41f7f15ec72 Mon Sep 17 00:00:00 2001 From: Emanuel Haine Date: Fri, 5 Mar 2021 01:09:20 -0300 Subject: [PATCH 003/128] Fix word translations about push request #26806 --- .../concepts/storage/persistent-volumes.md | 58 +++++++++---------- 1 file changed, 29 insertions(+), 29 deletions(-) diff --git a/content/pt/docs/concepts/storage/persistent-volumes.md b/content/pt/docs/concepts/storage/persistent-volumes.md index 4ed1fccdfc..76341bed46 100644 --- a/content/pt/docs/concepts/storage/persistent-volumes.md +++ b/content/pt/docs/concepts/storage/persistent-volumes.md @@ -7,9 +7,9 @@ reviewers: - xing-yang título: Persistentes Volumes funcionalidade: - title: Orquestração de Storage + title: Orquestração de Armazenamento descrição: > - Mountar automaticamente o storage de sua escolha, seja de um storage local, de um provedor de cloud pública, como GCP ou AWS, ou um storage de rede, como NFS, iSCSI, Gluster, Ceph, Cinder ou Flocker. + Montar automaticamente o armazenamento de sua escolha, seja de um armazenamento local, de um provedor de cloud pública, como GCP ou AWS, ou um armazenameto de rede, como NFS, iSCSI, Gluster, Ceph, Cinder ou Flocker. content_type: conceito weight: 20 @@ -23,13 +23,13 @@ Esse documento descreve o estado atual dos _persistent volumes_ no Kubernetes. S ## Introdução -Gerenciamento storage é uma questão bem diferente de gerenciamento de compute instances. O PersistentVolume subsystem provê uma API para usuários e administradores que mostra de forma detalhada de como o storage é provido e como ele é consumido. Para isso, nós introduzidmos duas novas APIs: PersistentVolume e PersistentVolumeClaim. +Gerenciamento armazenamento é uma questão bem diferente de gerenciamento de instâncias computacionais. O PersistentVolume subsystem provê uma API para usuários e administradores que mostra de forma detalhada de como o armazenamento é provido e como ele é consumido. Para isso, nós introduzidmos duas novas APIs: PersistentVolume e PersistentVolumeClaim. -Um _PersistentVolume_ (PV) é uma parte do storage dentro do cluster que tenha sido provisionada por um administrador ou dinamicamente utilizando [Storage Classes](/docs/concepts/storage/storage-classes/). Isso é um recurso dentro do cluster da mesma forma que um nó é um recurso dentro do cluster. PVs são plugins de volume da mesma forma que Volumes, porém eles têm um ciclo de vida independente de qualquer Pod que utilize um PV. Essa API tem por objetivo mostrar os detalhes da implementação do storage, seja ele NFS, iSCSI, ou um storage específico de um provedor de cloud pública. +Um _PersistentVolume_ (PV) é uma parte do armazenamento dentro do cluster que tenha sido provisionada por um administrador ou dinamicamente utilizando [Storage Classes](/docs/concepts/storage/storage-classes/). Isso é um recurso dentro do cluster da mesma forma que um nó é um recurso dentro do cluster. PVs são plugins de volume da mesma forma que Volumes, porém eles têm um ciclo de vida independente de qualquer Pod que utilize um PV. Essa API tem por objetivo mostrar os detalhes da implementação do armazenamento, seja ele NFS, iSCSI, ou um armazenamento específico de um provedor de cloud pública. -Um _PersistentVolumeClaim_ (PVC) é uma requisição para storage por um usuário. É similar a um Pod. Pods utilizam recursos do nó e PVCs utilizam recursos do PV. Pods podem solicitar níveis específicos de recursos (CPU e Memória). Claims podem requisitar tamanho e modos de acesso específicos (exemplo: montagem como ReadWriteOnce, ReadOnlyMany ou ReadWriteMany, veja [AccessModes](#access-modes)). +Um _PersistentVolumeClaim_ (PVC) é uma requisição para armazenamento por um usuário. É similar a um Pod. Pods utilizam recursos do nó e PVCs utilizam recursos do PV. Pods podem solicitar níveis específicos de recursos (CPU e Memória). Claims podem requisitar tamanho e modos de acesso específicos (exemplo: montagem como ReadWriteOnce, ReadOnlyMany ou ReadWriteMany, veja [AccessModes](#access-modes)). -Enquanto PersistentVolumeClaims permite que um usuário utilize recursos de storage de forma abstrata, é comum que usuários precisem de PersistentVolumes com diversas propriedades, como performance, para problemas diversos. Os administradores de cluster precisam estar aptos a oferecer uma variedade de PersistentVolumes que sejam diferentes em tamanho e modo de acesso, sem expor os usuários a detalhes de como esses volumes são implementados. Para necessidades como essa, temos o recurso de _StorageClass_. +Enquanto PersistentVolumeClaims permite que um usuário utilize recursos de armazenamento de forma abstrata, é comum que usuários precisem de PersistentVolumes com diversas propriedades, como performance, para problemas diversos. Os administradores de cluster precisam estar aptos a oferecer uma variedade de PersistentVolumes que sejam diferentes em tamanho e modo de acesso, sem expor os usuários a detalhes de como esses volumes são implementados. Para necessidades como essa, temos o recurso de _StorageClass_. Veja os [exemplos de passo a passo de forma detalhada](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/). @@ -43,18 +43,18 @@ Existem duas formas de provisionar ujm PV: staticamente ou dinamicamente. #### Stático -O administrador do cluster cria uma determinada quantidade de PVs. Eles possuem todos os detalhes do storage a qual estão atrelados, que neste caso fica disponível para utilização por um usuário dentro do cluster. Eles estão presentes na API do Kubernetes e disponíveis para utilização. +O administrador do cluster cria uma determinada quantidade de PVs. Eles possuem todos os detalhes do armazenamento a qual estão atrelados, que neste caso fica disponível para utilização por um usuário dentro do cluster. Eles estão presentes na API do Kubernetes e disponíveis para utilização. #### Dinâmico Quando nenhum dos PVs estáticos, que foram criados anteriormente pelo administrator, satisfazem os critérios de um PersistentVolumeClaim enviado por um usário, o cluster pode tentar realizar um provisionamento dinâmico para atender a esse PVC. Esse provisionamento é baseado em StorageClasses: o PVC deve solicitar um [storage class](/docs/concepts/storage/storage-classes/) e o administrador deve ter previamente criado e configurado essa classe para que o provisionamento dinâmico possa ocorrer. Requisições que solicitam a classe `""` efetivamente desabilitam o provisionamento dinâmico para elas mesmas. -Para habilitar o provisionamento de storage dinâmico baseado em storage class, o administrador do cluster precisa habilitar a `DefaultStorageClass` [admission controller](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) no servidor da API. Isso pode ser feito, por exemplo, garantindo que `DefaultStorageClass` esteja entre aspas simples, ordenado por uma lista de valores para a flag `--enable-admission-plugins`, componente do servidor da API. Para maiores informações sobre ndo das flags do servidor de API, consulte a documentação do [kube-apiserver](/docs/admin/kube-apiserver/). +Para habilitar o provisionamento de armazenamento dinâmico baseado em classe de armazenamento, o administrador do cluster precisa habilitar a `DefaultStorageClass` [admission controller](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) no servidor da API. Isso pode ser feito, por exemplo, garantindo que `DefaultStorageClass` esteja entre aspas simples, ordenado por uma lista de valores para a flag `--enable-admission-plugins`, componente do servidor da API. Para maiores informações sobre ndo das flags do servidor de API, consulte a documentação do [kube-apiserver](/docs/admin/kube-apiserver/). ### Binding -Um usuário cria, ou em caso de um provisionamento dinâmico já ter criado, um PersistentVolumeClaim solicitando uma quantidade específica de storage e um determinado modo de acesso. Um controle de loop no master monitora por novos PVCs, encontra um PV (se possível) que satisfaça os requisitos e realiza o bind. Se o PV foi provisionado dinamicamente por um PVC, o loop sempre vai fazer o bind desse PV com esse específico PVC. Caso contrário, o usuário vai receber no mínimo o que ele tinha solicitado, porém o volume possa exceder em relação à solicitação. Uma vez realizado esse processo, PersistentVolumeClaim sempre vai ter um bind exclusivo, sem levar em conta como o isso aconteceu. Um bind entre um PVC e um PV é um mapeamento de um pra um, utilizando o ClaimRef que é um bind bidirecional entre o PersistentVolume e o PersistentVolumeClaim. +Um usuário cria, ou em caso de um provisionamento dinâmico já ter criado, um PersistentVolumeClaim solicitando uma quantidade específica de armazenamento e um determinado modo de acesso. Um controle de loop no master monitora por novos PVCs, encontra um PV (se possível) que satisfaça os requisitos e realiza o bind. Se o PV foi provisionado dinamicamente por um PVC, o loop sempre vai fazer o bind desse PV com esse específico PVC. Caso contrário, o usuário vai receber no mínimo o que ele tinha solicitado, porém o volume possa exceder em relação à solicitação. Uma vez realizado esse processo, PersistentVolumeClaim sempre vai ter um bind exclusivo, sem levar em conta como o isso aconteceu. Um bind entre um PVC e um PV é um mapeamento de um pra um, utilizando o ClaimRef que é um bind bidirecional entre o PersistentVolume e o PersistentVolumeClaim. Requisições permanecerão sem bind se o volume solicitado não existir. O bind ocorrerá somente se os requisitos forem atendidos exatamente da mesma forma como solicitado. Por exemplo, um bind de um PVC de 100GB não vai ocorrer num cluster que foi provisionado com vários PVs de 50GB. O bind ocorrerá somente no momento em que um PV de 100GB for adicionado. @@ -65,9 +65,9 @@ pecifica qual o modo desejado quando utiliza essas requisições. Uma vez que o usuário tem a requisição atrelada a um PV, ele pertence ao usuário pelo tempo que ele precisar. Usuários agendam Pods e acessam seus PVs requisitados através da seção `persistentVolumeClaim` no bloco `volumes` do Pod. Para mais detalhes sobre isso, veja [Claims As Volumes](#claims-as-volumes). -### Storage Object in Proteção de Uso +### Objeto de Armazenamento em Proteção de Uso -O propósito da funcionalidade do Storage Object in Use Protection é garantir que PersistentVolumeClaims (PVCs) que estejam sendo utilizados por um Pod e PersistentVolume (PVs) que pertecem aos PVCs não sejam removidos do sistema, pois isso pode resultar numa perda de dados. +O propósito da funcionalidade do Objeto de Armazenamento em Proteção de Uso é garantir que PersistentVolumeClaims (PVCs) que estejam sendo utilizados por um Pod e PersistentVolume (PVs) que pertecem aos PVCs não sejam removidos do sistema, pois isso pode resultar numa perda de dados. {{< note >}} Um PVC está sendo utilizado por um Pod quando existe um Pod que está usando esse PVC. @@ -121,13 +121,13 @@ Quando um usuário não precisar mais utilizar um volume, ele pode deletar o PVC A política de `Retain` permite a recuperação de forma manual do recurso. Quando o PersistentVolumeClaim é deletado, ele continua existindo e o volume é considerado "liberado". Mas ele ainda não está disponível para outra requisição porque os dados da requisição anterior ainda permanecem no volume. Um administrador pode manuamente recuperar o volume executando os seguintes passos: -1. Deletar o PersistentVolume. O storage assset associado à infraestrutura externa (AWS EBS, GCE PD, Azure Disk, or Cinder volume) ainda continuará existindo após o PV ser deletado. -1. Limpar os dados de forma manual no storage assset associado. -1. Deletar manualmente o storage associado. Caso você queira utilizar o mesmo storage asset, crie um novo PersistentVolume com esse storage asset. +1. Deletar o PersistentVolume. O armazenamento associado à infraestrutura externa (AWS EBS, GCE PD, Azure Disk, or Cinder volume) ainda continuará existindo após o PV ser deletado. +1. Limpar os dados de forma manual no armazenamento associado. +1. Deletar manualmente o armazenamento associado. Caso você queira utilizar o mesmo armazenamento, crie um novo PersistentVolume com esse armazenamento. #### Deletar -Para plugins de volume que suportam a política de recuperação `Delete`, a deleção vai remover o tanto PersistentVolume do Kubernetes, quanto o storage asset associado à infraestrutura externa, como AWS EBS, GCE PD, Azure Disk, ou Cinder volume. Volumes que foram provisionados dinamicamente herdam o [reclaim policy of their StorageClass](#reclaim-policy), que é `Delete` por padrão. O administrador precisa configurar o StorageClass de acordo com as necessidades dos usuários; caso contrário, o PV deve ser editado or reparado após sua criação. Veja [Change the Reclaim Policy of a PersistentVolume](/docs/tasks/administer-cluster/change-pv-reclaim-policy/). +Para plugins de volume que suportam a política de recuperação `Delete`, a deleção vai remover o tanto PersistentVolume do Kubernetes, quanto o armazenamento associado à infraestrutura externa, como AWS EBS, GCE PD, Azure Disk, ou Cinder volume. Volumes que foram provisionados dinamicamente herdam o [reclaim policy of their StorageClass](#reclaim-policy), que é `Delete` por padrão. O administrador precisa configurar o StorageClass de acordo com as necessidades dos usuários; caso contrário, o PV deve ser editado or reparado após sua criação. Veja [Change the Reclaim Policy of a PersistentVolume](/docs/tasks/administer-cluster/change-pv-reclaim-policy/). #### Reciclar @@ -171,7 +171,7 @@ Especificando um PersistentVolume no PersistentVolumeClaim, você declara um bin O bind ocorrerá se o PersistentVolume existir e não estiver reservado por um PersistentVolumeClaims através do seu campo `claimRef`. O bind ocorre independente de algum volume atender ao critério, incluindo afinidade de nó. -A camada de gerenciamento verifica se a [storage class](/docs/concepts/storage/storage-classes/), modo de acesso e tamanho do storage solicitado ainda são válidos. +A camada de gerenciamento verifica se a [storage class](/docs/concepts/storage/storage-classes/), modo de acesso e tamanho do armazenamento solicitado ainda são válidos. ```yaml apiVersion: v1 @@ -185,7 +185,7 @@ spec: ... ``` -Esse método não garante nenhum privilégio de bind no PersistentVolume. Para evitar que algum outro PersistentVolumeClaims possa usar o PV que você especificar, você precisa primeiro reservar esse storage volume. Especifique seu PersistentVolumeClaim no campo `claimRef` do PV para outros PVCs não façam bind nele. +Esse método não garante nenhum privilégio de bind no PersistentVolume. Para evitar que algum outro PersistentVolumeClaims possa usar o PV que você especificar, você precisa primeiro reservar esse volume de armazenamento. Especifique seu PersistentVolumeClaim no campo `claimRef` do PV para outros PVCs não façam bind nele. ```yaml apiVersion: v1 @@ -276,7 +276,7 @@ Expandir volumes EBS é uma operação que toma muito tempo. Além disso, é pos #### Recuperação em caso de falha na expansão de volumes -Se a expansão do respectivo storage falhar, o administrador do cluster pode recuperar manualmente o estado do Persistent Volume Claim (PVC) e cancelar as solicitações de redimensionamento. Caso contrário, as tentativas de solicitação de redimensionamento ocorrerão de forma contínua pelo controlador sem nenhuma intervenção do administrador. +Se a expansão do respectivo armazenamento falhar, o administrador do cluster pode recuperar manualmente o estado do Persistent Volume Claim (PVC) e cancelar as solicitações de redimensionamento. Caso contrário, as tentativas de solicitação de redimensionamento ocorrerão de forma contínua pelo controlador sem nenhuma intervenção do administrador. 1. Marque o PersistentVolume(PV) que está atrelado ao PersistentVolumeClaim(PVC) com a política de recuperação `Retain`. 2. Delete o PVC. Desde que o PV tenha a política de recuperação `Retain` - nenhum dado será perdido quando o PVC for recriado. @@ -346,9 +346,9 @@ Talvez sejam necessários programas auxiliares para um determinado tipo de volum ### Capacidade -Geralmente, um PV terá uma capacidade de storage específica. Isso é configurado usando o atributo `capacity` do PV. Veja Kubernetes [Resource Model](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) para entender as unidades aceitas pelo atributo `capacity`. +Geralmente, um PV terá uma capacidade de armazenamento específica. Isso é configurado usando o atributo `capacity` do PV. Veja Kubernetes [Resource Model](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) para entender as unidades aceitas pelo atributo `capacity`. -Atualmente, o tamanho do storage é o único recurso que pode ser configurado ou solicitado. Os futuros atributos podem incluir IOPS, throughput, etc. +Atualmente, o tamanho do armazenamento é o único recurso que pode ser configurado ou solicitado. Os futuros atributos podem incluir IOPS, throughput, etc. ### Modo do Volume @@ -417,7 +417,7 @@ Atuamente as políticas de retenção são: * Retenção -- recuperação manual * Reciclar -- limpeza básica (`rm -rf /thevolume/*`) -* Delete -- storage associado como AWS EBS, GCE PD, Azure Disk ou OpenStack Cinder volume is deleted +* Delete -- armazenamento associado como AWS EBS, GCE PD, Azure Disk ou OpenStack Cinder volume is deleted Atualmente, somente NFS e HostPath suportam reciclagem. Volumes AWS EBS, GCE PD, Azure Disk, and Cinder suportam delete. @@ -496,7 +496,7 @@ spec: ### Modos de Acesso -As requisições usam as mesmas convenções que os volumes quando eles solicitam um storage com um modo de acesso específico. +As requisições usam as mesmas convenções que os volumes quando eles solicitam um armazenamento com um modo de acesso específico. ### Modos de Volume @@ -504,7 +504,7 @@ As requisições usam as mesmas convenções que os volumes quando eles indicam ### Recursos -Assim como Pods, as requisições podem solicitar quantidades específicas de recurso. Neste caso, a solicitação é por storage. O mesmo [modelo de recurso](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) valem para volumes e requisições. +Assim como Pods, as requisições podem solicitar quantidades específicas de recurso. Neste caso, a solicitação é por armazenamento. O mesmo [modelo de recurso](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) valem para volumes e requisições. ### Selector @@ -536,7 +536,7 @@ No passado, a notação `volume.beta.kubernetes.io/storage-class` era usada no l ## Requisições como Volumes -Os Pods podem ter acesso ao storage utilizando a requisição como um volume. Para isso a requisição tem que estar no mesmo namespace que o Pod. Ao localizar a requisição no namespace do Pod, o cluster passa o PersistentVolume para a requisição. +Os Pods podem ter acesso ao armazenamento utilizando a requisição como um volume. Para isso a requisição tem que estar no mesmo namespace que o Pod. Ao localizar a requisição no namespace do Pod, o cluster passa o PersistentVolume para a requisição. ```yaml apiVersion: v1 @@ -726,15 +726,15 @@ spec: ## Boas Práticas de Configuração -Se você está criando templates ou exemplos que rodam numa grande quantidade de clusters e que precisam de storage persistente, recomendamos que utilize a estrutura abaixo: +Se você está criando templates ou exemplos que rodam numa grande quantidade de clusters e que precisam de armazenamento persistente, recomendamos que utilize a estrutura abaixo: - Inclua objetos PersistentVolumeClaim em seu pacote de configuração (juntanemte com Deployments, ConfigMaps, etc). - Não inclua objetos PersistentVolume na configuração, pois o usuário que irá instanciar a configuração talvez não tenha permissão para criar PersistentVolume. the config may not have permission to create PersistentVolumes. -- Dê ao usuário a opção dele informar o nome de uma classe de storage quando instaciar o template. - - Se o usuário informar o nome de uma classe de storage, coloque esse valor no campo `persistentVolumeClaim.storageClassName`. Isso fará com que o PVC encontre a classe de storage correta se o cluster tiver o StorageClasses habilitado pelo administrador. - - Se o usuário não informar o nome da classe de storage, deixe o campo `persistentVolumeClaim.storageClassName` sem nenhum valor (null). Isso fará com que o PV seja provisionado automaticamente no cluster para o usuário com o StorageClass padrão. Em muitos ambientes, o StorageClass padrão já instalado no cluster, ou então, os administradores podem criar seus StorageClass padrão. -- Durante suas tarefas de administração, busque por PVCs que após um tempo não estão sendo atrelados, pois isso talvez indique que o cluster não tem provisionamento dinâmico (que no caso, o usuário deveria criar um PV que satisfaça os critérios do PVC) ou cluster não tem um sistema de storage (que no caso, o usuário não pode fazer deploy solicitando PVCs). +- Dê ao usuário a opção dele informar o nome de uma classe de armazenamento quando instaciar o template. + - Se o usuário informar o nome de uma classe de armazenamento, coloque esse valor no campo `persistentVolumeClaim.storageClassName`. Isso fará com que o PVC encontre a classe de armazenamento correta se o cluster tiver o StorageClasses habilitado pelo administrador. + - Se o usuário não informar o nome da classe de armazenamento, deixe o campo `persistentVolumeClaim.storageClassName` sem nenhum valor (null). Isso fará com que o PV seja provisionado automaticamente no cluster para o usuário com o StorageClass padrão. Em muitos ambientes, o StorageClass padrão já instalado no cluster, ou então, os administradores podem criar seus StorageClass padrão. +- Durante suas tarefas de administração, busque por PVCs que após um tempo não estão sendo atrelados, pois isso talvez indique que o cluster não tem provisionamento dinâmico (que no caso, o usuário deveria criar um PV que satisfaça os critérios do PVC) ou cluster não tem um sistema de armazenamento (que no caso, o usuário não pode fazer deploy solicitando PVCs). ## {{% heading "whatsnext" %}} From 8bd82abd9feeb996a0eff10c43c60da99fc19b63 Mon Sep 17 00:00:00 2001 From: Emanuel Haine Date: Tue, 2 Mar 2021 21:11:23 -0300 Subject: [PATCH 004/128] persistent-volumes.md translation from storage directory --- .../concepts/storage/persistent-volumes.md | 85 ++++++++++++++++++- 1 file changed, 84 insertions(+), 1 deletion(-) diff --git a/content/pt/docs/concepts/storage/persistent-volumes.md b/content/pt/docs/concepts/storage/persistent-volumes.md index 76341bed46..98356ee15a 100644 --- a/content/pt/docs/concepts/storage/persistent-volumes.md +++ b/content/pt/docs/concepts/storage/persistent-volumes.md @@ -10,6 +10,9 @@ funcionalidade: title: Orquestração de Armazenamento descrição: > Montar automaticamente o armazenamento de sua escolha, seja de um armazenamento local, de um provedor de cloud pública, como GCP ou AWS, ou um armazenameto de rede, como NFS, iSCSI, Gluster, Ceph, Cinder ou Flocker. + title: Orquestração de Storage + descrição: > + Mountar automaticamente o storage de sua escolha, seja de um storage local, de um provedor de cloud pública, como GCP ou AWS, ou um storage de rede, como NFS, iSCSI, Gluster, Ceph, Cinder ou Flocker. content_type: conceito weight: 20 @@ -23,6 +26,7 @@ Esse documento descreve o estado atual dos _persistent volumes_ no Kubernetes. S ## Introdução + Gerenciamento armazenamento é uma questão bem diferente de gerenciamento de instâncias computacionais. O PersistentVolume subsystem provê uma API para usuários e administradores que mostra de forma detalhada de como o armazenamento é provido e como ele é consumido. Para isso, nós introduzidmos duas novas APIs: PersistentVolume e PersistentVolumeClaim. Um _PersistentVolume_ (PV) é uma parte do armazenamento dentro do cluster que tenha sido provisionada por um administrador ou dinamicamente utilizando [Storage Classes](/docs/concepts/storage/storage-classes/). Isso é um recurso dentro do cluster da mesma forma que um nó é um recurso dentro do cluster. PVs são plugins de volume da mesma forma que Volumes, porém eles têm um ciclo de vida independente de qualquer Pod que utilize um PV. Essa API tem por objetivo mostrar os detalhes da implementação do armazenamento, seja ele NFS, iSCSI, ou um armazenamento específico de um provedor de cloud pública. @@ -31,6 +35,15 @@ Um _PersistentVolumeClaim_ (PVC) é uma requisição para armazenamento por um u Enquanto PersistentVolumeClaims permite que um usuário utilize recursos de armazenamento de forma abstrata, é comum que usuários precisem de PersistentVolumes com diversas propriedades, como performance, para problemas diversos. Os administradores de cluster precisam estar aptos a oferecer uma variedade de PersistentVolumes que sejam diferentes em tamanho e modo de acesso, sem expor os usuários a detalhes de como esses volumes são implementados. Para necessidades como essa, temos o recurso de _StorageClass_. +Gerenciamento storage é uma questão bem diferente de gerenciamento de compute instances. O PersistentVolume subsystem provê uma API para usuários e administradores que mostra de forma detalhada de como o storage é provido e como ele é consumido. Para isso, nós introduzidmos duas novas APIs: PersistentVolume e PersistentVolumeClaim. + +Um _PersistentVolume_ (PV) é uma parte do storage dentro do cluster que tenha sido provisionada por um administrador ou dinamicamente utilizando [Storage Classes](/docs/concepts/storage/storage-classes/). Isso é um recurso dentro do cluster da mesma forma que um nó é um recurso dentro do cluster. PVs são plugins de volume da mesma forma que Volumes, porém eles têm um ciclo de vida independente de qualquer Pod que utilize um PV. Essa API tem por objetivo mostrar os detalhes da implementação do storage, seja ele NFS, iSCSI, ou um storage específico de um provedor de cloud pública. + +Um _PersistentVolumeClaim_ (PVC) é uma requisição para storage por um usuário. É similar a um Pod. Pods utilizam recursos do nó e PVCs utilizam recursos do PV. Pods podem solicitar níveis específicos de recursos (CPU e Memória). Claims podem requisitar tamanho e modos de acesso específicos (exemplo: montagem como ReadWriteOnce, ReadOnlyMany ou ReadWriteMany, veja [AccessModes](#access-modes)). + +Enquanto PersistentVolumeClaims permite que um usuário utilize recursos de storage de forma abstrata, é comum que usuários precisem de PersistentVolumes com diversas propriedades, como performance, para problemas diversos. Os administradores de cluster precisam estar aptos a oferecer uma variedade de PersistentVolumes que sejam diferentes em tamanho e modo de acesso, sem expor os usuários a detalhes de como esses volumes são implementados. Para necessidades como essa, temos o recurso de _StorageClass_. + + Veja os [exemplos de passo a passo de forma detalhada](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/). ## Requisição e ciclo de vida de um volume @@ -43,19 +56,31 @@ Existem duas formas de provisionar ujm PV: staticamente ou dinamicamente. #### Stático + O administrador do cluster cria uma determinada quantidade de PVs. Eles possuem todos os detalhes do armazenamento a qual estão atrelados, que neste caso fica disponível para utilização por um usuário dentro do cluster. Eles estão presentes na API do Kubernetes e disponíveis para utilização. +O administrador do cluster cria uma determinada quantidade de PVs. Eles possuem todos os detalhes do storage a qual estão atrelados, que neste caso fica disponível para utilização por um usuário dentro do cluster. Eles estão presentes na API do Kubernetes e disponíveis para utilização. + + #### Dinâmico Quando nenhum dos PVs estáticos, que foram criados anteriormente pelo administrator, satisfazem os critérios de um PersistentVolumeClaim enviado por um usário, o cluster pode tentar realizar um provisionamento dinâmico para atender a esse PVC. Esse provisionamento é baseado em StorageClasses: o PVC deve solicitar um [storage class](/docs/concepts/storage/storage-classes/) e o administrador deve ter previamente criado e configurado essa classe para que o provisionamento dinâmico possa ocorrer. Requisições que solicitam a classe `""` efetivamente desabilitam o provisionamento dinâmico para elas mesmas. + Para habilitar o provisionamento de armazenamento dinâmico baseado em classe de armazenamento, o administrador do cluster precisa habilitar a `DefaultStorageClass` [admission controller](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) no servidor da API. Isso pode ser feito, por exemplo, garantindo que `DefaultStorageClass` esteja entre aspas simples, ordenado por uma lista de valores para a flag `--enable-admission-plugins`, componente do servidor da API. Para maiores informações sobre ndo das flags do servidor de API, consulte a documentação do [kube-apiserver](/docs/admin/kube-apiserver/). ### Binding Um usuário cria, ou em caso de um provisionamento dinâmico já ter criado, um PersistentVolumeClaim solicitando uma quantidade específica de armazenamento e um determinado modo de acesso. Um controle de loop no master monitora por novos PVCs, encontra um PV (se possível) que satisfaça os requisitos e realiza o bind. Se o PV foi provisionado dinamicamente por um PVC, o loop sempre vai fazer o bind desse PV com esse específico PVC. Caso contrário, o usuário vai receber no mínimo o que ele tinha solicitado, porém o volume possa exceder em relação à solicitação. Uma vez realizado esse processo, PersistentVolumeClaim sempre vai ter um bind exclusivo, sem levar em conta como o isso aconteceu. Um bind entre um PVC e um PV é um mapeamento de um pra um, utilizando o ClaimRef que é um bind bidirecional entre o PersistentVolume e o PersistentVolumeClaim. +Para habilitar o provisionamento de storage dinâmico baseado em storage class, o administrador do cluster precisa habilitar a `DefaultStorageClass` [admission controller](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) no servidor da API. Isso pode ser feito, por exemplo, garantindo que `DefaultStorageClass` esteja entre aspas simples, ordenado por uma lista de valores para a flag `--enable-admission-plugins`, componente do servidor da API. Para maiores informações sobre ndo das flags do servidor de API, consulte a documentação do [kube-apiserver](/docs/admin/kube-apiserver/). + +### Binding + +Um usuário cria, ou em caso de um provisionamento dinâmico já ter criado, um PersistentVolumeClaim solicitando uma quantidade específica de storage e um determinado modo de acesso. Um controle de loop no master monitora por novos PVCs, encontra um PV (se possível) que satisfaça os requisitos e realiza o bind. Se o PV foi provisionado dinamicamente por um PVC, o loop sempre vai fazer o bind desse PV com esse específico PVC. Caso contrário, o usuário vai receber no mínimo o que ele tinha solicitado, porém o volume possa exceder em relação à solicitação. Uma vez realizado esse processo, PersistentVolumeClaim sempre vai ter um bind exclusivo, sem levar em conta como o isso aconteceu. Um bind entre um PVC e um PV é um mapeamento de um pra um, utilizando o ClaimRef que é um bind bidirecional entre o PersistentVolume e o PersistentVolumeClaim. + + Requisições permanecerão sem bind se o volume solicitado não existir. O bind ocorrerá somente se os requisitos forem atendidos exatamente da mesma forma como solicitado. Por exemplo, um bind de um PVC de 100GB não vai ocorrer num cluster que foi provisionado com vários PVs de 50GB. O bind ocorrerá somente no momento em que um PV de 100GB for adicionado. ### Utilização @@ -65,10 +90,16 @@ pecifica qual o modo desejado quando utiliza essas requisições. Uma vez que o usuário tem a requisição atrelada a um PV, ele pertence ao usuário pelo tempo que ele precisar. Usuários agendam Pods e acessam seus PVs requisitados através da seção `persistentVolumeClaim` no bloco `volumes` do Pod. Para mais detalhes sobre isso, veja [Claims As Volumes](#claims-as-volumes). + ### Objeto de Armazenamento em Proteção de Uso O propósito da funcionalidade do Objeto de Armazenamento em Proteção de Uso é garantir que PersistentVolumeClaims (PVCs) que estejam sendo utilizados por um Pod e PersistentVolume (PVs) que pertecem aos PVCs não sejam removidos do sistema, pois isso pode resultar numa perda de dados. +### Storage Object in Proteção de Uso + +O propósito da funcionalidade do Storage Object in Use Protection é garantir que PersistentVolumeClaims (PVCs) que estejam sendo utilizados por um Pod e PersistentVolume (PVs) que pertecem aos PVCs não sejam removidos do sistema, pois isso pode resultar numa perda de dados. + + {{< note >}} Um PVC está sendo utilizado por um Pod quando existe um Pod que está usando esse PVC. {{< /note >}} @@ -121,6 +152,7 @@ Quando um usuário não precisar mais utilizar um volume, ele pode deletar o PVC A política de `Retain` permite a recuperação de forma manual do recurso. Quando o PersistentVolumeClaim é deletado, ele continua existindo e o volume é considerado "liberado". Mas ele ainda não está disponível para outra requisição porque os dados da requisição anterior ainda permanecem no volume. Um administrador pode manuamente recuperar o volume executando os seguintes passos: + 1. Deletar o PersistentVolume. O armazenamento associado à infraestrutura externa (AWS EBS, GCE PD, Azure Disk, or Cinder volume) ainda continuará existindo após o PV ser deletado. 1. Limpar os dados de forma manual no armazenamento associado. 1. Deletar manualmente o armazenamento associado. Caso você queira utilizar o mesmo armazenamento, crie um novo PersistentVolume com esse armazenamento. @@ -129,6 +161,15 @@ A política de `Retain` permite a recuperação de forma manual do recurso. Quan Para plugins de volume que suportam a política de recuperação `Delete`, a deleção vai remover o tanto PersistentVolume do Kubernetes, quanto o armazenamento associado à infraestrutura externa, como AWS EBS, GCE PD, Azure Disk, ou Cinder volume. Volumes que foram provisionados dinamicamente herdam o [reclaim policy of their StorageClass](#reclaim-policy), que é `Delete` por padrão. O administrador precisa configurar o StorageClass de acordo com as necessidades dos usuários; caso contrário, o PV deve ser editado or reparado após sua criação. Veja [Change the Reclaim Policy of a PersistentVolume](/docs/tasks/administer-cluster/change-pv-reclaim-policy/). +1. Deletar o PersistentVolume. O storage assset associado à infraestrutura externa (AWS EBS, GCE PD, Azure Disk, or Cinder volume) ainda continuará existindo após o PV ser deletado. +1. Limpar os dados de forma manual no storage assset associado. +1. Deletar manualmente o storage associado. Caso você queira utilizar o mesmo storage asset, crie um novo PersistentVolume com esse storage asset. + +#### Deletar + +Para plugins de volume que suportam a política de recuperação `Delete`, a deleção vai remover o tanto PersistentVolume do Kubernetes, quanto o storage asset associado à infraestrutura externa, como AWS EBS, GCE PD, Azure Disk, ou Cinder volume. Volumes que foram provisionados dinamicamente herdam o [reclaim policy of their StorageClass](#reclaim-policy), que é `Delete` por padrão. O administrador precisa configurar o StorageClass de acordo com as necessidades dos usuários; caso contrário, o PV deve ser editado or reparado após sua criação. Veja [Change the Reclaim Policy of a PersistentVolume](/docs/tasks/administer-cluster/change-pv-reclaim-policy/). + + #### Reciclar {{< warning >}} @@ -171,8 +212,12 @@ Especificando um PersistentVolume no PersistentVolumeClaim, você declara um bin O bind ocorrerá se o PersistentVolume existir e não estiver reservado por um PersistentVolumeClaims através do seu campo `claimRef`. O bind ocorre independente de algum volume atender ao critério, incluindo afinidade de nó. + A camada de gerenciamento verifica se a [storage class](/docs/concepts/storage/storage-classes/), modo de acesso e tamanho do armazenamento solicitado ainda são válidos. +A camada de gerenciamento verifica se a [storage class](/docs/concepts/storage/storage-classes/), modo de acesso e tamanho do storage solicitado ainda são válidos. + + ```yaml apiVersion: v1 kind: PersistentVolumeClaim @@ -185,8 +230,12 @@ spec: ... ``` + Esse método não garante nenhum privilégio de bind no PersistentVolume. Para evitar que algum outro PersistentVolumeClaims possa usar o PV que você especificar, você precisa primeiro reservar esse volume de armazenamento. Especifique seu PersistentVolumeClaim no campo `claimRef` do PV para outros PVCs não façam bind nele. +Esse método não garante nenhum privilégio de bind no PersistentVolume. Para evitar que algum outro PersistentVolumeClaims possa usar o PV que você especificar, você precisa primeiro reservar esse storage volume. Especifique seu PersistentVolumeClaim no campo `claimRef` do PV para outros PVCs não façam bind nele. + + ```yaml apiVersion: v1 kind: PersistentVolume @@ -276,8 +325,12 @@ Expandir volumes EBS é uma operação que toma muito tempo. Além disso, é pos #### Recuperação em caso de falha na expansão de volumes + Se a expansão do respectivo armazenamento falhar, o administrador do cluster pode recuperar manualmente o estado do Persistent Volume Claim (PVC) e cancelar as solicitações de redimensionamento. Caso contrário, as tentativas de solicitação de redimensionamento ocorrerão de forma contínua pelo controlador sem nenhuma intervenção do administrador. +Se a expansão do respectivo storage falhar, o administrador do cluster pode recuperar manualmente o estado do Persistent Volume Claim (PVC) e cancelar as solicitações de redimensionamento. Caso contrário, as tentativas de solicitação de redimensionamento ocorrerão de forma contínua pelo controlador sem nenhuma intervenção do administrador. + + 1. Marque o PersistentVolume(PV) que está atrelado ao PersistentVolumeClaim(PVC) com a política de recuperação `Retain`. 2. Delete o PVC. Desde que o PV tenha a política de recuperação `Retain` - nenhum dado será perdido quando o PVC for recriado. 3. Delete a entrada `claimRef` da especificação do PV para que um PVC possa fazer bind com ele. Isso deve tornar o PV `Available`. @@ -346,10 +399,16 @@ Talvez sejam necessários programas auxiliares para um determinado tipo de volum ### Capacidade + Geralmente, um PV terá uma capacidade de armazenamento específica. Isso é configurado usando o atributo `capacity` do PV. Veja Kubernetes [Resource Model](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) para entender as unidades aceitas pelo atributo `capacity`. Atualmente, o tamanho do armazenamento é o único recurso que pode ser configurado ou solicitado. Os futuros atributos podem incluir IOPS, throughput, etc. +Geralmente, um PV terá uma capacidade de storage específica. Isso é configurado usando o atributo `capacity` do PV. Veja Kubernetes [Resource Model](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) para entender as unidades aceitas pelo atributo `capacity`. + +Atualmente, o tamanho do storage é o único recurso que pode ser configurado ou solicitado. Os futuros atributos podem incluir IOPS, throughput, etc. + + ### Modo do Volume {{< feature-state for_k8s_version="v1.18" state="stable" >}} @@ -417,8 +476,12 @@ Atuamente as políticas de retenção são: * Retenção -- recuperação manual * Reciclar -- limpeza básica (`rm -rf /thevolume/*`) + * Delete -- armazenamento associado como AWS EBS, GCE PD, Azure Disk ou OpenStack Cinder volume is deleted +* Delete -- storage associado como AWS EBS, GCE PD, Azure Disk ou OpenStack Cinder volume is deleted + + Atualmente, somente NFS e HostPath suportam reciclagem. Volumes AWS EBS, GCE PD, Azure Disk, and Cinder suportam delete. ### Opções de Montagem @@ -496,16 +559,24 @@ spec: ### Modos de Acesso + As requisições usam as mesmas convenções que os volumes quando eles solicitam um armazenamento com um modo de acesso específico. +As requisições usam as mesmas convenções que os volumes quando eles solicitam um storage com um modo de acesso específico. + + ### Modos de Volume As requisições usam as mesmas convenções que os volumes quando eles indicam o tipo de volume, seja ele um sistema de arquivo ou dispositivo de bloco. ### Recursos + Assim como Pods, as requisições podem solicitar quantidades específicas de recurso. Neste caso, a solicitação é por armazenamento. O mesmo [modelo de recurso](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) valem para volumes e requisições. +Assim como Pods, as requisições podem solicitar quantidades específicas de recurso. Neste caso, a solicitação é por storage. O mesmo [modelo de recurso](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) valem para volumes e requisições. + + ### Selector Requisições podem especifiar um [label selector](/docs/concepts/overview/working-with-objects/labels/#label-selectors) para posteriormente filtrar um grupo de volumes. Somente os volumes que possuam labels que safistaçam os critérios do selector podem ser atreladas à requisição. O selector podem conter dois campos: @@ -536,8 +607,12 @@ No passado, a notação `volume.beta.kubernetes.io/storage-class` era usada no l ## Requisições como Volumes + Os Pods podem ter acesso ao armazenamento utilizando a requisição como um volume. Para isso a requisição tem que estar no mesmo namespace que o Pod. Ao localizar a requisição no namespace do Pod, o cluster passa o PersistentVolume para a requisição. +Os Pods podem ter acesso ao storage utilizando a requisição como um volume. Para isso a requisição tem que estar no mesmo namespace que o Pod. Ao localizar a requisição no namespace do Pod, o cluster passa o PersistentVolume para a requisição. + + ```yaml apiVersion: v1 kind: Pod @@ -726,8 +801,12 @@ spec: ## Boas Práticas de Configuração + Se você está criando templates ou exemplos que rodam numa grande quantidade de clusters e que precisam de armazenamento persistente, recomendamos que utilize a estrutura abaixo: +Se você está criando templates ou exemplos que rodam numa grande quantidade de clusters e que precisam de storage persistente, recomendamos que utilize a estrutura abaixo: + + - Inclua objetos PersistentVolumeClaim em seu pacote de configuração (juntanemte com Deployments, ConfigMaps, etc). - Não inclua objetos PersistentVolume na configuração, pois o usuário que irá instanciar a configuração talvez não tenha permissão para criar PersistentVolume. the config may not have permission to create PersistentVolumes. @@ -735,6 +814,11 @@ Se você está criando templates ou exemplos que rodam numa grande quantidade de - Se o usuário informar o nome de uma classe de armazenamento, coloque esse valor no campo `persistentVolumeClaim.storageClassName`. Isso fará com que o PVC encontre a classe de armazenamento correta se o cluster tiver o StorageClasses habilitado pelo administrador. - Se o usuário não informar o nome da classe de armazenamento, deixe o campo `persistentVolumeClaim.storageClassName` sem nenhum valor (null). Isso fará com que o PV seja provisionado automaticamente no cluster para o usuário com o StorageClass padrão. Em muitos ambientes, o StorageClass padrão já instalado no cluster, ou então, os administradores podem criar seus StorageClass padrão. - Durante suas tarefas de administração, busque por PVCs que após um tempo não estão sendo atrelados, pois isso talvez indique que o cluster não tem provisionamento dinâmico (que no caso, o usuário deveria criar um PV que satisfaça os critérios do PVC) ou cluster não tem um sistema de armazenamento (que no caso, o usuário não pode fazer deploy solicitando PVCs). +- Dê ao usuário a opção dele informar o nome de uma classe de storage quando instaciar o template. + - Se o usuário informar o nome de uma classe de storage, coloque esse valor no campo `persistentVolumeClaim.storageClassName`. Isso fará com que o PVC encontre a classe de storage correta se o cluster tiver o StorageClasses habilitado pelo administrador. + - Se o usuário não informar o nome da classe de storage, deixe o campo `persistentVolumeClaim.storageClassName` sem nenhum valor (null). Isso fará com que o PV seja provisionado automaticamente no cluster para o usuário com o StorageClass padrão. Em muitos ambientes, o StorageClass padrão já instalado no cluster, ou então, os administradores podem criar seus StorageClass padrão. +- Durante suas tarefas de administração, busque por PVCs que após um tempo não estão sendo atrelados, pois isso talvez indique que o cluster não tem provisionamento dinâmico (que no caso, o usuário deveria criar um PV que satisfaça os critérios do PVC) ou cluster não tem um sistema de storage (que no caso, o usuário não pode fazer deploy solicitando PVCs). + ## {{% heading "whatsnext" %}} @@ -748,4 +832,3 @@ Se você está criando templates ou exemplos que rodam numa grande quantidade de * [PersistentVolume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolume-v1-core) * [PersistentVolumeSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumespec-v1-core) * [PersistentVolumeClaim](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core) - From 6b8f15bd22ca0a458d64d4c2f3a05cdd5312a711 Mon Sep 17 00:00:00 2001 From: Emanuel Haine Date: Sun, 7 Mar 2021 15:35:38 -0300 Subject: [PATCH 005/128] Fixing push request #26806 recommendations and I made some improvement on the translation --- .../concepts/storage/persistent-volumes.md | 312 ++++++------------ 1 file changed, 108 insertions(+), 204 deletions(-) diff --git a/content/pt/docs/concepts/storage/persistent-volumes.md b/content/pt/docs/concepts/storage/persistent-volumes.md index 98356ee15a..7236c4c56d 100644 --- a/content/pt/docs/concepts/storage/persistent-volumes.md +++ b/content/pt/docs/concepts/storage/persistent-volumes.md @@ -5,14 +5,11 @@ reviewers: - thockin - msau42 - xing-yang -título: Persistentes Volumes -funcionalidade: +title: Volumes Persistentes +feature: title: Orquestração de Armazenamento - descrição: > + description: > Montar automaticamente o armazenamento de sua escolha, seja de um armazenamento local, de um provedor de cloud pública, como GCP ou AWS, ou um armazenameto de rede, como NFS, iSCSI, Gluster, Ceph, Cinder ou Flocker. - title: Orquestração de Storage - descrição: > - Mountar automaticamente o storage de sua escolha, seja de um storage local, de um provedor de cloud pública, como GCP ou AWS, ou um storage de rede, como NFS, iSCSI, Gluster, Ceph, Cinder ou Flocker. content_type: conceito weight: 20 @@ -20,29 +17,20 @@ weight: 20 -Esse documento descreve o estado atual dos _persistent volumes_ no Kubernetes. Sugerimos que esteja familiarizado com [volumes](/docs/concepts/storage/volumes/). +Esse documento descreve o estado atual dos _volumes persistentes_ no Kubernetes. Sugerimos que esteja familiarizado com [volumes](/docs/concepts/storage/volumes/). ## Introdução -Gerenciamento armazenamento é uma questão bem diferente de gerenciamento de instâncias computacionais. O PersistentVolume subsystem provê uma API para usuários e administradores que mostra de forma detalhada de como o armazenamento é provido e como ele é consumido. Para isso, nós introduzidmos duas novas APIs: PersistentVolume e PersistentVolumeClaim. +O gerenciamento de armazenamento é uma questão bem diferente do gerenciamento de instâncias computacionais. O subsitema PersistentVolume provê uma API para usuários e administradores que mostra de forma detalhada de como o armazenamento é provido e como ele é consumido. Para isso, nós introduzidmos duas novas APIs: PersistentVolume e PersistentVolumeClaim. -Um _PersistentVolume_ (PV) é uma parte do armazenamento dentro do cluster que tenha sido provisionada por um administrador ou dinamicamente utilizando [Storage Classes](/docs/concepts/storage/storage-classes/). Isso é um recurso dentro do cluster da mesma forma que um nó é um recurso dentro do cluster. PVs são plugins de volume da mesma forma que Volumes, porém eles têm um ciclo de vida independente de qualquer Pod que utilize um PV. Essa API tem por objetivo mostrar os detalhes da implementação do armazenamento, seja ele NFS, iSCSI, ou um armazenamento específico de um provedor de cloud pública. +Um _PersistentVolume_ (PV) é uma parte do armazenamento dentro do cluster que tenha sido provisionada por um administrador, ou dinamicamente utilizando [Classes de Armazenamento](/docs/concepts/storage/storage-classes/). Isso é um recurso dentro do cluster da mesma forma que um nó também é. PVs são plugins de volume da mesma forma que Volumes, porém eles têm um ciclo de vida independente de qualquer Pod que utilize um PV. Essa API tem por objetivo mostrar os detalhes da implementação do armazenamento, seja ele NFS, iSCSI, ou um armazenamento específico de um provedor de cloud pública. -Um _PersistentVolumeClaim_ (PVC) é uma requisição para armazenamento por um usuário. É similar a um Pod. Pods utilizam recursos do nó e PVCs utilizam recursos do PV. Pods podem solicitar níveis específicos de recursos (CPU e Memória). Claims podem requisitar tamanho e modos de acesso específicos (exemplo: montagem como ReadWriteOnce, ReadOnlyMany ou ReadWriteMany, veja [AccessModes](#access-modes)). - -Enquanto PersistentVolumeClaims permite que um usuário utilize recursos de armazenamento de forma abstrata, é comum que usuários precisem de PersistentVolumes com diversas propriedades, como performance, para problemas diversos. Os administradores de cluster precisam estar aptos a oferecer uma variedade de PersistentVolumes que sejam diferentes em tamanho e modo de acesso, sem expor os usuários a detalhes de como esses volumes são implementados. Para necessidades como essa, temos o recurso de _StorageClass_. - -Gerenciamento storage é uma questão bem diferente de gerenciamento de compute instances. O PersistentVolume subsystem provê uma API para usuários e administradores que mostra de forma detalhada de como o storage é provido e como ele é consumido. Para isso, nós introduzidmos duas novas APIs: PersistentVolume e PersistentVolumeClaim. - -Um _PersistentVolume_ (PV) é uma parte do storage dentro do cluster que tenha sido provisionada por um administrador ou dinamicamente utilizando [Storage Classes](/docs/concepts/storage/storage-classes/). Isso é um recurso dentro do cluster da mesma forma que um nó é um recurso dentro do cluster. PVs são plugins de volume da mesma forma que Volumes, porém eles têm um ciclo de vida independente de qualquer Pod que utilize um PV. Essa API tem por objetivo mostrar os detalhes da implementação do storage, seja ele NFS, iSCSI, ou um storage específico de um provedor de cloud pública. - -Um _PersistentVolumeClaim_ (PVC) é uma requisição para storage por um usuário. É similar a um Pod. Pods utilizam recursos do nó e PVCs utilizam recursos do PV. Pods podem solicitar níveis específicos de recursos (CPU e Memória). Claims podem requisitar tamanho e modos de acesso específicos (exemplo: montagem como ReadWriteOnce, ReadOnlyMany ou ReadWriteMany, veja [AccessModes](#access-modes)). - -Enquanto PersistentVolumeClaims permite que um usuário utilize recursos de storage de forma abstrata, é comum que usuários precisem de PersistentVolumes com diversas propriedades, como performance, para problemas diversos. Os administradores de cluster precisam estar aptos a oferecer uma variedade de PersistentVolumes que sejam diferentes em tamanho e modo de acesso, sem expor os usuários a detalhes de como esses volumes são implementados. Para necessidades como essa, temos o recurso de _StorageClass_. +Uma_PersistentVolumeClaim_ (PVC) é uma requisição para armazenamento por um usuário. É similar a um Pod. Pods utilizam recursos do nó e PVCs utilizam recursos do PV. Pods podem solicitar níveis específicos de recursos (CPU e Memória). Claims podem solicitar tamanho e modos de acesso específicos (exemplo: montagem como ReadWriteOnce, ReadOnlyMany ou ReadWriteMany, veja [Modos de Acesso](#modos-de-acesso)). +Enquanto as PersistentVolumeClaims permitem que um usuário utilize recursos de armazenamento de forma limitada, é comum que usuários precisem de PersistentVolumes com diversas propriedades, como performance, para problemas diversos. Os administradores de cluster precisam estar aptos a oferecer uma variedade de PersistentVolumes que sejam diferentes em tamanho e modo de acesso, sem expor os usuários a detalhes de como esses volumes são implementados. Para necessidades como essas, temos o recurso de _StorageClass_. Veja os [exemplos de passo a passo de forma detalhada](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/). @@ -52,61 +40,41 @@ PVs são recursos dentro um cluster. PVCs são requisições para esses recursos ### Provisionamento -Existem duas formas de provisionar ujm PV: staticamente ou dinamicamente. - -#### Stático +Existem duas formas de provisionar um PV: staticamente ou dinamicamente. +#### Estático O administrador do cluster cria uma determinada quantidade de PVs. Eles possuem todos os detalhes do armazenamento a qual estão atrelados, que neste caso fica disponível para utilização por um usuário dentro do cluster. Eles estão presentes na API do Kubernetes e disponíveis para utilização. -O administrador do cluster cria uma determinada quantidade de PVs. Eles possuem todos os detalhes do storage a qual estão atrelados, que neste caso fica disponível para utilização por um usuário dentro do cluster. Eles estão presentes na API do Kubernetes e disponíveis para utilização. - - #### Dinâmico -Quando nenhum dos PVs estáticos, que foram criados anteriormente pelo administrator, satisfazem os critérios de um PersistentVolumeClaim enviado por um usário, o cluster pode tentar realizar um provisionamento dinâmico para atender a esse PVC. -Esse provisionamento é baseado em StorageClasses: o PVC deve solicitar um [storage class](/docs/concepts/storage/storage-classes/) e o administrador deve ter previamente criado e configurado essa classe para que o provisionamento dinâmico possa ocorrer. Requisições que solicitam a classe `""` efetivamente desabilitam o provisionamento dinâmico para elas mesmas. +Quando nenhum dos PVs estáticos, que foram criados anteriormente pelo administrator, satisfazem os critérios de uma PersistentVolumeClaim enviado por um usuário, o cluster pode tentar realizar um provisionamento dinâmico para atender a essa PVC. Esse provisionamento é baseado em StorageClasses: a PVC deve solicitar uma [classe de armazenamento](/docs/concepts/storage/storage-classes/) e o administrador deve ter previamente criado e configurado essa classe para que o provisionamento dinâmico possa ocorrer. Requisições que solicitam a classe `""` efetivamente desabilitam o provisionamento dinâmico para elas mesmas. - -Para habilitar o provisionamento de armazenamento dinâmico baseado em classe de armazenamento, o administrador do cluster precisa habilitar a `DefaultStorageClass` [admission controller](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) no servidor da API. Isso pode ser feito, por exemplo, garantindo que `DefaultStorageClass` esteja entre aspas simples, ordenado por uma lista de valores para a flag `--enable-admission-plugins`, componente do servidor da API. Para maiores informações sobre ndo das flags do servidor de API, consulte a documentação do [kube-apiserver](/docs/admin/kube-apiserver/). +Para habilitar o provisionamento de armazenamento dinâmico baseado em classe de armazenamento, o administrador do cluster precisa habilitar o [controle de admissão](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) `DefaultStorageClass` no servidor da API. Isso pode ser feito, por exemplo, garantindo que `DefaultStorageClass` esteja entre aspas simples, ordenado por uma lista de valores para a flag `--enable-admission-plugins`, componente do servidor da API. Para maiores informações sobre os comandos das flags do servidor da API, consulte a documentação [kube-apiserver](/docs/admin/kube-apiserver/). ### Binding -Um usuário cria, ou em caso de um provisionamento dinâmico já ter criado, um PersistentVolumeClaim solicitando uma quantidade específica de armazenamento e um determinado modo de acesso. Um controle de loop no master monitora por novos PVCs, encontra um PV (se possível) que satisfaça os requisitos e realiza o bind. Se o PV foi provisionado dinamicamente por um PVC, o loop sempre vai fazer o bind desse PV com esse específico PVC. Caso contrário, o usuário vai receber no mínimo o que ele tinha solicitado, porém o volume possa exceder em relação à solicitação. Uma vez realizado esse processo, PersistentVolumeClaim sempre vai ter um bind exclusivo, sem levar em conta como o isso aconteceu. Um bind entre um PVC e um PV é um mapeamento de um pra um, utilizando o ClaimRef que é um bind bidirecional entre o PersistentVolume e o PersistentVolumeClaim. +Um usuário cria, ou em caso de um provisionamento dinâmico já ter criado, uma PersistentVolumeClaim solicitando uma quantidade específica de armazenamento e um determinado modo de acesso. Um controle de loop no master monitora por novas PVCs, encontra um PV (se possível) que satisfaça os requisitos e realiza o bind. Se o PV foi provisionado dinamicamente por uma PVC, o loop sempre vai fazer o bind desse PV com essa PVC em específico. Caso contrário, o usuário vai receber no mínimo o que ele tinha solicitado, porém o volume possa exceder em relação à solicitação inicial. Uma vez realizado esse processo, PersistentVolumeClaim sempre vai ter um bind exclusivo, sem levar em conta como o isso aconteceu. Um bind entre uma PVC e um PV é um mapeamento de um pra um, utilizando o ClaimRef que é um bind bidirecional entre o PersistentVolume e o PersistentVolumeClaim. -Para habilitar o provisionamento de storage dinâmico baseado em storage class, o administrador do cluster precisa habilitar a `DefaultStorageClass` [admission controller](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) no servidor da API. Isso pode ser feito, por exemplo, garantindo que `DefaultStorageClass` esteja entre aspas simples, ordenado por uma lista de valores para a flag `--enable-admission-plugins`, componente do servidor da API. Para maiores informações sobre ndo das flags do servidor de API, consulte a documentação do [kube-apiserver](/docs/admin/kube-apiserver/). - -### Binding - -Um usuário cria, ou em caso de um provisionamento dinâmico já ter criado, um PersistentVolumeClaim solicitando uma quantidade específica de storage e um determinado modo de acesso. Um controle de loop no master monitora por novos PVCs, encontra um PV (se possível) que satisfaça os requisitos e realiza o bind. Se o PV foi provisionado dinamicamente por um PVC, o loop sempre vai fazer o bind desse PV com esse específico PVC. Caso contrário, o usuário vai receber no mínimo o que ele tinha solicitado, porém o volume possa exceder em relação à solicitação. Uma vez realizado esse processo, PersistentVolumeClaim sempre vai ter um bind exclusivo, sem levar em conta como o isso aconteceu. Um bind entre um PVC e um PV é um mapeamento de um pra um, utilizando o ClaimRef que é um bind bidirecional entre o PersistentVolume e o PersistentVolumeClaim. - - -Requisições permanecerão sem bind se o volume solicitado não existir. O bind ocorrerá somente se os requisitos forem atendidos exatamente da mesma forma como solicitado. Por exemplo, um bind de um PVC de 100GB não vai ocorrer num cluster que foi provisionado com vários PVs de 50GB. O bind ocorrerá somente no momento em que um PV de 100GB for adicionado. +As requisições permanecerão sem bind se o volume solicitado não existir. O bind ocorrerá somente se os requisitos forem atendidos exatamente da mesma forma como solicitado. Por exemplo, um bind de uma PVC de 100GB não vai ocorrer num cluster que foi provisionado com vários PVs de 50GB. O bind ocorrerá somente no momento em que um PV de 100GB for adicionado. ### Utilização -Pods utilizam requisições como volumes. O cluster inspeciona a requisição para encontrar o volume atrelado a ela e monta esse volume para um Pod. Para volumes que suportam múltiplos modos de acesso, o usuário es -pecifica qual o modo desejado quando utiliza essas requisições. +Pods utilizam requisições como volumes. O cluster inspeciona a requisição para encontrar o volume atrelado a ela e monta esse volume para um Pod. Para volumes que suportam múltiplos modos de acesso, o usuário especifica qual o modo desejado quando utiliza essas requisições. -Uma vez que o usuário tem a requisição atrelada a um PV, ele pertence ao usuário pelo tempo que ele precisar. Usuários agendam Pods e acessam seus PVs requisitados através da seção `persistentVolumeClaim` no bloco `volumes` do Pod. Para mais detalhes sobre isso, veja [Claims As Volumes](#claims-as-volumes). +Uma vez que o usuário tem a requisição atrelada a um PV, ele pertence ao usuário pelo tempo que ele precisar. Usuários agendam Pods e acessam seus PVs requisitados através da seção `persistentVolumeClaim` no bloco `volumes` do Pod. Para mais detalhes sobre isso, veja [Requisições como Volumes](#requisições-como-volumes). +### Proteção de Uso de um Objeto de Armazenamento -### Objeto de Armazenamento em Proteção de Uso - -O propósito da funcionalidade do Objeto de Armazenamento em Proteção de Uso é garantir que PersistentVolumeClaims (PVCs) que estejam sendo utilizados por um Pod e PersistentVolume (PVs) que pertecem aos PVCs não sejam removidos do sistema, pois isso pode resultar numa perda de dados. - -### Storage Object in Proteção de Uso - -O propósito da funcionalidade do Storage Object in Use Protection é garantir que PersistentVolumeClaims (PVCs) que estejam sendo utilizados por um Pod e PersistentVolume (PVs) que pertecem aos PVCs não sejam removidos do sistema, pois isso pode resultar numa perda de dados. - +O propósito da funcionalidade do Objeto de Armazenamento em Proteção de Uso é garantir que as PersistentVolumeClaims (PVCs) que estejam sendo utilizadas por um Pod e PersistentVolume (PVs) que pertençam aos PVCs não sejam removidos do sistema, pois isso pode resultar numa perda de dados. {{< note >}} -Um PVC está sendo utilizado por um Pod quando existe um Pod que está usando esse PVC. +Uma PVC está sendo utilizada por um Pod quando existe um Pod que está usando essa PVC. {{< /note >}} -Se um usuário deleta um PVC que está sendo utilizado por um Pod, este PVC não é removido imediatamente. A remoção do PVC é adiada até que o PVC não esteja mais sendo utilizado por nenhum Pod. Se um admin deleta um PV que está atrelado a um PVC, o PV não é removido imediatamente também. A remoção do PV é adiada até que o PV não esteja mais atrelado ao PVC. +Se um usuário deleta uma PVC que está sendo utilizada por um Pod, esta PVC não é removida imediatamente. A remoção da PVC é adiada até que a PVC não esteja mais sendo utilizado por nenhum Pod. Se um admin deleta um PV que está atrelado a uma PVC, o PV não é removido imediatamente também. A remoção do PV é adiada até que o PV não esteja mais atrelado à PVC. -Você pode ver que um PVC é protegido quando o status do PVC é `Terminating` e a lista `Finalizers` contém `kubernetes.io/pvc-protection`: +Você pode ver que uma PVC é protegida quando o status da PVC é `Terminating` e a lista `Finalizers` contém `kubernetes.io/pvc-protection`: ```shell kubectl describe pvc hostpath @@ -122,7 +90,7 @@ Finalizers: [kubernetes.io/pvc-protection] ... ``` -Você pode ver que um PV é protegido quando o status do PVC é `Terminating` e a lista `Finalizers` contém `kubernetes.io/pv-protection` também: +Você pode ver que um PV é protegido quando o status da PVC é `Terminating` e a lista `Finalizers` contém `kubernetes.io/pv-protection` também: ```shell kubectl describe pv task-pv-volume @@ -146,11 +114,11 @@ Events: ### Recuperação -Quando um usuário não precisar mais utilizar um volume, ele pode deletar o PVC pela API, que por sua vez permite a recuperação do recurso. A política de recuperação para um PersistentVolume diz ao cluster o que fazer com o volume após ele ter sido liberado da sua requisição. Atualmente, volumes podem ser Retidos, Reciclados ou Deletados. +Quando um usuário não precisar mais utilizar um volume, ele pode deletar a PVC pela API, que por sua vez permite a recuperação do recurso. A política de recuperação para um PersistentVolume diz ao cluster o que fazer com o volume após ele ter sido liberado da sua requisição. Atualmente, volumes podem ser Retidos, Reciclados ou Deletados. #### Retenção -A política de `Retain` permite a recuperação de forma manual do recurso. Quando o PersistentVolumeClaim é deletado, ele continua existindo e o volume é considerado "liberado". Mas ele ainda não está disponível para outra requisição porque os dados da requisição anterior ainda permanecem no volume. Um administrador pode manuamente recuperar o volume executando os seguintes passos: +A política `Retain` permite a recuperação de forma manual do recurso. Quando a PersistentVolumeClaim é deletada, ela continua existindo e o volume é considerado "livre". Mas ele ainda não está disponível para outra requisição porque os dados da requisição anterior ainda permanecem no volume. Um administrador pode manuamente recuperar o volume executando os seguintes passos: 1. Deletar o PersistentVolume. O armazenamento associado à infraestrutura externa (AWS EBS, GCE PD, Azure Disk, or Cinder volume) ainda continuará existindo após o PV ser deletado. @@ -159,16 +127,7 @@ A política de `Retain` permite a recuperação de forma manual do recurso. Quan #### Deletar -Para plugins de volume que suportam a política de recuperação `Delete`, a deleção vai remover o tanto PersistentVolume do Kubernetes, quanto o armazenamento associado à infraestrutura externa, como AWS EBS, GCE PD, Azure Disk, ou Cinder volume. Volumes que foram provisionados dinamicamente herdam o [reclaim policy of their StorageClass](#reclaim-policy), que é `Delete` por padrão. O administrador precisa configurar o StorageClass de acordo com as necessidades dos usuários; caso contrário, o PV deve ser editado or reparado após sua criação. Veja [Change the Reclaim Policy of a PersistentVolume](/docs/tasks/administer-cluster/change-pv-reclaim-policy/). - -1. Deletar o PersistentVolume. O storage assset associado à infraestrutura externa (AWS EBS, GCE PD, Azure Disk, or Cinder volume) ainda continuará existindo após o PV ser deletado. -1. Limpar os dados de forma manual no storage assset associado. -1. Deletar manualmente o storage associado. Caso você queira utilizar o mesmo storage asset, crie um novo PersistentVolume com esse storage asset. - -#### Deletar - -Para plugins de volume que suportam a política de recuperação `Delete`, a deleção vai remover o tanto PersistentVolume do Kubernetes, quanto o storage asset associado à infraestrutura externa, como AWS EBS, GCE PD, Azure Disk, ou Cinder volume. Volumes que foram provisionados dinamicamente herdam o [reclaim policy of their StorageClass](#reclaim-policy), que é `Delete` por padrão. O administrador precisa configurar o StorageClass de acordo com as necessidades dos usuários; caso contrário, o PV deve ser editado or reparado após sua criação. Veja [Change the Reclaim Policy of a PersistentVolume](/docs/tasks/administer-cluster/change-pv-reclaim-policy/). - +Para plugins de volume que suportam a política de recuperação `Delete`, a deleção vai remover o tanto o PersistentVolume do Kubernetes, quanto o armazenamento associado à infraestrutura externa, como AWS EBS, GCE PD, Azure Disk, ou Cinder volume. Volumes que foram provisionados dinamicamente herdam a [política de retenção da sua StorageClass](#política-de-retenção), que por padrão é `Delete`. O administrador precisa configurar a StorageClass de acordo com as necessidades dos usuários. Caso contrário, o PV deve ser editado ou reparado após sua criação. Veja [Alterar a política de renteção de um PersistentVolume](/docs/tasks/administer-cluster/change-pv-reclaim-policy/). #### Reciclar @@ -176,9 +135,9 @@ Para plugins de volume que suportam a política de recuperação `Delete`, a del A política de retenção `Recycle` está depreciada. Ao invés disso, recomendamos a utilização de provisionametno dinâmico. {{< /warning >}} -Em caso do volume plugin ter suporte a essa operação, a política de retenção do `Recycle` faz uma limpeza básica (`rm -rf /thevolume/*`) no volume e torna ele disponível novamente para outra requisiçaõ. +Em caso do volume plugin ter suporte a essa operação, a política de retenção `Recycle` faz uma limpeza básica (`rm -rf /thevolume/*`) no volume e torna ele disponível novamente para outra requisição. -Contudo, um administrador pode configurar um template personalizado de um Pod reciclador utilizando a linha de comando do gerenciamento de controle do Kubernetes como descrito em [reference](/docs/reference/command-line-tools-reference/kube-controller-manager/). +Contudo, um administrador pode configurar um template personalizado de um Pod reciclador utilizando a linha de comando do gerenciamento de controle do Kubernetes como descrito em [referência](/docs/reference/command-line-tools-reference/kube-controller-manager/). O Pod reciclador personalizado deve conter a spec `volume` como é mostrado no exemplo abaixo: ```yaml @@ -206,17 +165,11 @@ Contudo, o caminho especificado no Pod reciclador personalizado em `volumes` é ### Reservando um PersistentVolume -A camada de gerenciamento pode [fazer o bind de um PersistentVolumeClaims com PersistentVolumes equivalentes](#binding) no cluster. Contudo, se você quer que um PVC faça um bind com um PV específco, é preciso fazer o pre-bind deles. +A camada de gerenciamento pode [fazer o bind de um PersistentVolumeClaims com PersistentVolumes equivalentes](#binding) no cluster. Contudo, se você quer que uma PVC faça um bind com um PV específco, é preciso fazer o pré-bind deles. -Especificando um PersistentVolume no PersistentVolumeClaim, você declara um bind entre um PVC e um PV específico. -O bind ocorrerá se o PersistentVolume existir e não estiver reservado por um PersistentVolumeClaims através do seu campo `claimRef`. - -O bind ocorre independente de algum volume atender ao critério, incluindo afinidade de nó. - -A camada de gerenciamento verifica se a [storage class](/docs/concepts/storage/storage-classes/), modo de acesso e tamanho do armazenamento solicitado ainda são válidos. - -A camada de gerenciamento verifica se a [storage class](/docs/concepts/storage/storage-classes/), modo de acesso e tamanho do storage solicitado ainda são válidos. +Especificando um PersistentVolume na PersistentVolumeClaim, você declara um bind entre uma PVC e um PV específico. O bind ocorrerá se o PersistentVolume existir e não estiver reservado por uma PersistentVolumeClaims através do seu campo `claimRef`. +O bind ocorre independentemente se algum volume atender ao critério, incluindo afinidade de nó. A camada de gerenciamento verifica se a [classe de armazenamento](/docs/concepts/storage/storage-classes/), modo de acesso e tamanho do armazenamento solicitado ainda são válidos. ```yaml apiVersion: v1 @@ -230,11 +183,7 @@ spec: ... ``` - -Esse método não garante nenhum privilégio de bind no PersistentVolume. Para evitar que algum outro PersistentVolumeClaims possa usar o PV que você especificar, você precisa primeiro reservar esse volume de armazenamento. Especifique seu PersistentVolumeClaim no campo `claimRef` do PV para outros PVCs não façam bind nele. - -Esse método não garante nenhum privilégio de bind no PersistentVolume. Para evitar que algum outro PersistentVolumeClaims possa usar o PV que você especificar, você precisa primeiro reservar esse storage volume. Especifique seu PersistentVolumeClaim no campo `claimRef` do PV para outros PVCs não façam bind nele. - +Esse método não garante nenhum privilégio de bind no PersistentVolume. Para evitar que alguma outra PersistentVolumeClaims possa usar o PV que você especificar, você precisa primeiro reservar esse volume de armazenamento. Especifique sua PersistentVolumeClaim no campo `claimRef` do PV para que outras PVCs não façam bind nele. ```yaml apiVersion: v1 @@ -251,11 +200,11 @@ spec: Isso é útil se você deseja utilizar PersistentVolumes que possuem suas `claimPolicy` configuradas para `Retain`, incluindo situações onde você estiver reutilizando um PV existente. -### Expandindo Requisições de Persistent Volumes +### Expandindo Requisições de Volumes Persistentes {{< feature-state for_k8s_version="v1.11" state="beta" >}} -Agora o suporte para expansão de PersistentVolumeClaims (PVCs) já é habilitado por padrão. Você pode expandir os tipos de volumes abaixo: +Agora, o suporte à expansão de PersistentVolumeClaims (PVCs) já é habilitado por padrão. Você pode expandir os tipos de volumes abaixo: * gcePersistentDisk * awsElasticBlockStore @@ -268,7 +217,7 @@ Agora o suporte para expansão de PersistentVolumeClaims (PVCs) já é habilitad * FlexVolumes * {{< glossary_tooltip text="CSI" term_id="csi" >}} -Você só pode expandir um PVC se o campo do storage class `allowVolumeExpansion` é true. +Você só pode expandir uma PVC se o campo da classe de armazenamento `allowVolumeExpansion` é _true_. ``` yaml apiVersion: storage.k8s.io/v1 @@ -284,7 +233,7 @@ parameters: allowVolumeExpansion: true ``` -Para solicitar um volume maior para um PVC, edite o PVC e especifique um tamanho maior. Isso irá fazer com o que volume atrelado ao respectivo PersistentVolume seja expandido. Nunca um PersistentVolume é criado para satisfazer a requisição. Ao invès disso, um volume existente é redimensionado. +Para solicitar um volume maior para uma PVC, edite a PVC e especifique um tamanho maior. Isso irá fazer com o que volume atrelado ao respectivo PersistentVolume seja expandido. Nunca um PersistentVolume é criado para satisfazer a requisição. Ao invés disso, um volume existente é redimensionado. #### Expansão de volume CSI @@ -296,22 +245,21 @@ O suporte à expansão de volumes CSI é habilitada por padrão, porém é neces Só podem ser redimensionados os volumes que contém os seguintes sistemas de arquivo: XFS, Ext3 ou Ext4. -Quando um volume contém um sistema de arquivo, o sistema de arquivo somente é redimensionado quando um novo Pod está utilizando PersistentVolumeClaim no modo `ReadWrite`. Expansão de sistema de arquivo é feita quando um Pod estiver inicializando ou quando um Pod estiver em execução e o respectivo sistema de arquivo suporta expansão online. +Quando um volume contém um sistema de arquivo, o sistema de arquivo somente é redimensionado quando um novo Pod está utilizando a PersistentVolumeClaim no modo `ReadWrite`. A expansão de sistema de arquivo é feita quando um Pod estiver inicializando ou quando um Pod estiver em execução e o respectivo sistema de arquivo tenha suporte para expansão a quente. -FlexVolumes permitem redimensionamento se o `RequiresFSResize` do drive é configurado como `true`. -O FlexVolume pode ser redimensionado na reinicialização do Pod. +FlexVolumes permitem redimensionamento se o `RequiresFSResize` do drive é configurado como `true`. O FlexVolume pode ser redimensionado na reinicialização do Pod. -#### Redimensionamento de um PersistentVolumeClaim em uso +#### Redimensionamento de uma PersistentVolumeClaim em uso {{< feature-state for_k8s_version="v1.15" state="beta" >}} {{< note >}} -Expansão de PVCs em uso está disponível como beta desde Kubernetes 1.15, e como alpha desde 1.11. A funcionalidade `ExpandInUsePersistentVolumes` precisa ser habilitada, o que já está automático para vários clusters que possuem funcionalidades beta. Verifique a documentação [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) para maiores informações. +A Expansão de PVCs em uso está disponível como beta desde o Kubernetes 1.15, e como alpha desde a versão 1.11. A funcionalidade `ExpandInUsePersistentVolumes` precisa ser habilitada, o que já está automático para vários clusters que possuem funcionalidades beta. Verifique a documentação [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) para maiores informações. {{< /note >}} -Neste caso você não precisa deletar e recriar um Pod ou um deployment que está sendo utilizado por um PVC existente. +Neste caso, você não precisa deletar e recriar um Pod ou um deployment que está sendo utilizado por uma PVC existente. Automaticamente, qualquer PVC em uso fica disponível para o Pod assim que o sistema de arquivo for expandido. -Essa funcionalidade não tem efeito em PVCs que não estão em uso por um Pod ou deployment. Você deve criar um Pod que utilize o PVC antes que a expansão seja completada. +Essa funcionalidade não tem efeito em PVCs que não estão em uso por um Pod ou deployment. Você deve criar um Pod que utilize a PVC antes que a expansão seja completada. Da mesma forma que outros tipos de volumes - volumes FlexVolume também podem ser expandidos quando estiverem em uso por um Pod. @@ -320,24 +268,20 @@ Redimensionamento de FlexVolume somente é possível quando o respectivo driver {{< /note >}} {{< note >}} -Expandir volumes EBS é uma operação que toma muito tempo. Além disso, é possível fazer uma modificação por volume a cada 6 horas. +Expandir volumes do tipo EBS é uma operação que toma muito tempo. Além disso, só é possível fazer uma modificação por volume a cada 6 horas. {{< /note >}} #### Recuperação em caso de falha na expansão de volumes +Se a expansão do respectivo armazenamento falhar, o administrador do cluster pode recuperar manualmente o estado da Persistent Volume Claim (PVC) e cancelar as solicitações de redimensionamento. Caso contrário, as tentativas de solicitação de redimensionamento ocorrerão de forma contínua pelo controlador sem nenhuma intervenção do administrador. -Se a expansão do respectivo armazenamento falhar, o administrador do cluster pode recuperar manualmente o estado do Persistent Volume Claim (PVC) e cancelar as solicitações de redimensionamento. Caso contrário, as tentativas de solicitação de redimensionamento ocorrerão de forma contínua pelo controlador sem nenhuma intervenção do administrador. - -Se a expansão do respectivo storage falhar, o administrador do cluster pode recuperar manualmente o estado do Persistent Volume Claim (PVC) e cancelar as solicitações de redimensionamento. Caso contrário, as tentativas de solicitação de redimensionamento ocorrerão de forma contínua pelo controlador sem nenhuma intervenção do administrador. - - -1. Marque o PersistentVolume(PV) que está atrelado ao PersistentVolumeClaim(PVC) com a política de recuperação `Retain`. -2. Delete o PVC. Desde que o PV tenha a política de recuperação `Retain` - nenhum dado será perdido quando o PVC for recriado. -3. Delete a entrada `claimRef` da especificação do PV para que um PVC possa fazer bind com ele. Isso deve tornar o PV `Available`. -4. Recrie o PVC com um tamanho menor que o PV e configure o campo `volumeName` do PCV com o nome do PV. Isso deve fazer o bind de um novo PVC a um PV existente. +1. Marque o PersistentVolume(PV) que estiver atrelado à PersistentVolumeClaim(PVC) com a política de recuperação `Retain`. +2. Delete a PVC. Desde que o PV tenha a política de recuperação `Retain` - nenhum dado será perdido quando a PVC for recriada. +3. Delete a entrada `claimRef` da especificação do PV para que uma PVC possa fazer bind com ele. Isso deve tornar o PV `Available`. +4. Recrie a PVC com um tamanho menor que o PV e configure o campo `volumeName` da PCV com o nome do PV. Isso deve fazer o bind de uma nova PVC a um PV existente. 5. Não esqueça de restaurar a política de recuperação do PV. -## Tipos de volumes persistentes. +## Tipos de volumes persistentes Tipos de PersistentVolume são implementados como plugins. Atualmente o Kubernetes suporta os plugins abaixo: @@ -354,7 +298,7 @@ Tipos de PersistentVolume são implementados como plugins. Atualmente o Kubernet * [`gcePersistentDisk`](/docs/concepts/storage/volumes/#gcepersistentdisk) - GCE Persistent Disk * [`glusterfs`](/docs/concepts/storage/volumes/#glusterfs) - Glusterfs volume * [`hostPath`](/docs/concepts/storage/volumes/#hostpath) - HostPath volume - (somente para teste de nó único; ISSO NÃO FUNCIONARÁ num cluster multi-nós; ao invés disso, considere utilizari volume `local`.) + (somente para teste de nó único; ISSO NÃO FUNCIONARÁ num cluster multi-nós; ao invés disso, considere a utilização de volume `local`.) * [`iscsi`](/docs/concepts/storage/volumes/#iscsi) - iSCSI (SCSI over IP) storage * [`local`](/docs/concepts/storage/volumes/#local) - storage local montados nos nós. * [`nfs`](/docs/concepts/storage/volumes/#nfs) - Network File System (NFS) storage @@ -370,7 +314,7 @@ Tipos de PersistentVolume são implementados como plugins. Atualmente o Kubernet ## Volumes Persistentes -Cada PV contém uma spec e um status, que é a espeficiação e o status do volume. O nome de PersistentVolume deve ser um [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)válido. +Cada PV contém uma `spec` e um status, que é a espeficiação e o status do volume. O nome do PersistentVolume deve ser um [DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) válido. ```yaml apiVersion: v1 @@ -383,7 +327,7 @@ spec: volumeMode: Filesystem accessModes: - ReadWriteOnce - persistentVolumeReclaimPolicy: Reciclar + persistentVolumeReclaimPolicy: Retain storageClassName: slow mountOptions: - hard @@ -394,21 +338,15 @@ spec: ``` {{< note >}} -Talvez sejam necessários programas auxiliares para um determinado tipo de volume utilizar um PersistentVolume no cluster. Neste exemplo, o PersistentVolume é do tipo NFS e o programa auxiliar /sbin/mount.nfs é necessário para suportar a montagem dos sistemas de arquivos NFS. +Talvez sejam necessários programas auxiliares para um determinado tipo de volume utilizar um PersistentVolume no cluster. Neste exemplo, o PersistentVolume é do tipo NFS e o programa auxiliar _/sbin/mount.nfs_ é necessário para suportar a montagem dos sistemas de arquivos NFS. {{< /note >}} ### Capacidade - -Geralmente, um PV terá uma capacidade de armazenamento específica. Isso é configurado usando o atributo `capacity` do PV. Veja Kubernetes [Resource Model](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) para entender as unidades aceitas pelo atributo `capacity`. +Geralmente, um PV terá uma capacidade de armazenamento específica. Isso é configurado usando o atributo `capacity` do PV. Veja o [Modelo de Recurso](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) do Kubernetes para entender as unidades aceitas pelo atributo `capacity`. Atualmente, o tamanho do armazenamento é o único recurso que pode ser configurado ou solicitado. Os futuros atributos podem incluir IOPS, throughput, etc. -Geralmente, um PV terá uma capacidade de storage específica. Isso é configurado usando o atributo `capacity` do PV. Veja Kubernetes [Resource Model](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) para entender as unidades aceitas pelo atributo `capacity`. - -Atualmente, o tamanho do storage é o único recurso que pode ser configurado ou solicitado. Os futuros atributos podem incluir IOPS, throughput, etc. - - ### Modo do Volume {{< feature-state for_k8s_version="v1.18" state="stable" >}} @@ -418,9 +356,9 @@ O Kubernetes suporta dois `volumeModes` de PersistentVolumes: `Filesystem` e `Bl `volumeMode` é um parâmetro opicional da API. `Filesystem` é o modo padrão utilizado quando o parâmetro `volumeMode` é omitido. -Um volume com `volumeMode: Filesystem` é *mounted* em um diretório nos Pods. Se o volume for de um dispositivo de bloco e ele estiver vazio, o Kubernetes cria o sistema de arquivo no dispositivo antes de fazer a montagem pela primeira vez. +Um volume com `volumeMode: Filesystem` é *montado* em um diretório nos Pods. Se o volume for de um dispositivo de bloco e ele estiver vazio, o Kubernetes cria o sistema de arquivo no dispositivo antes de fazer a montagem pela primeira vez. -Você pode configurar o valor do `volumeMode` para `Block` para utilizar um disco bruto como volume. Esse volume é apresentado num Pod como um dispositivo de bloco, sem nenhum sistema de arquivo. Esse modo é útil para prover ao Pod a forma mais rápida para acessar um volume, sem nenhuma cama de sistema de arquivo entre o Pod e o volume. Por outro lado, a aplicação que estiver rodando no Pod deverá saber como tratar um dispositivo de bloco. Veja [Raw Block Volume Support](#raw-block-volume-support) para um exemplo de como utilizar o volume como `volumeMode: Block` num Pod. +Você pode configurar o valor do `volumeMode` para `Block` para utilizar um disco bruto como volume. Esse volume é apresentado num Pod como um dispositivo de bloco, sem nenhum sistema de arquivo. Esse modo é útil para prover ao Pod a forma mais rápida para acessar um volume, sem nenhuma camada de sistema de arquivo entre o Pod e o volume. Por outro lado, a aplicação que estiver rodando no Pod deverá saber como tratar um dispositivo de bloco. Veja [Suporte a Volume de Bloco Bruto](#raw-block-volume-support) para um exemplo de como utilizar o volume como `volumeMode: Block` num Pod. ### Modos de Acesso @@ -428,9 +366,9 @@ Um PersistentVolume pode ser montado num host das mais variadas formas suportada Os modos de acesso são: -* ReadWriteOnce -- o volume pode ser montado como read-write por um nó único -* ReadOnlyMany -- o volume pode ser montado como ready-only por vários nós -* ReadWriteMany -- o volume pode ser montado como read-write por vários nós +* ReadWriteOnce -- o volume pode ser montado como leitura-escrita por um nó único +* ReadOnlyMany -- o volume pode ser montado como somente-leitura por vários nós +* ReadWriteMany -- o volume pode ser montado como leitura-escrita por vários nós Na linha de comando, os modos de acesso ficam abreviados: @@ -459,37 +397,33 @@ Na linha de comando, os modos de acesso ficam abreviados: | Quobyte | ✓ | ✓ | ✓ | | NFS | ✓ | ✓ | ✓ | | RBD | ✓ | ✓ | - | -| VsphereVolume | ✓ | - | - (funcionam quando os Pods são do tipo collocated) | +| VsphereVolume | ✓ | - | (funcionam quando os Pods são do tipo collocated) | | PortworxVolume | ✓ | - | ✓ | | ScaleIO | ✓ | ✓ | - | | StorageOS | ✓ | - | - | ### Classe -Um PV pode ter uma classe, que é especificada na configuração do atribute `storageClassName` com o nome da [StorageClass](/docs/concepts/storage/storage-classes/). Um PV de uma classe específica só pode ser atrelado a requições PVCs dessa mesma classe. Um PV sem `storageClassName` não possuí nenhuma classe e pode ser montado somente a PVCs que não solicitem nenhuma classe em específico. +Um PV pode ter uma classe, que é especificada na configuração do atributo `storageClassName` com o nome da [StorageClass](/docs/concepts/storage/storage-classes/). Um PV de uma classe específica só pode ser atrelado a requições PVCs dessa mesma classe. Um PV sem `storageClassName` não possui nenhuma classe e pode ser montado somente a PVCs que não solicitem nenhuma classe em específico. -No passado, a notação `volume.beta.kubernetes.io/storage-class` era utilizada no lugar do atributo `storageClassName`. Essa notação ainda funciona; contudo, ela será totalmente depreciada numa futura release do Kubernetes. +No passado, a notação `volume.beta.kubernetes.io/storage-class` era utilizada no lugar do atributo `storageClassName`. Essa notação ainda funciona. Contudo, ela será totalmente depreciada numa futura versão do Kubernetes. ### Política de Retenção Atuamente as políticas de retenção são: -* Retenção -- recuperação manual -* Reciclar -- limpeza básica (`rm -rf /thevolume/*`) +* Retain -- recuperação manual +* Recycle -- limpeza básica (`rm -rf /thevolume/*`) +* Delete -- o volume de armazenamento associado, como AWS EBS, GCE PD, Azure Disk ou OpenStack Cinder é deletado -* Delete -- armazenamento associado como AWS EBS, GCE PD, Azure Disk ou OpenStack Cinder volume is deleted - -* Delete -- storage associado como AWS EBS, GCE PD, Azure Disk ou OpenStack Cinder volume is deleted - - -Atualmente, somente NFS e HostPath suportam reciclagem. Volumes AWS EBS, GCE PD, Azure Disk, and Cinder suportam delete. +Atualmente, somente NFS e HostPath suportam reciclagem. Volumes AWS EBS, GCE PD, Azure Disk e Cinder suportam delete. ### Opções de Montagem -Um administrador do Kubernetes pode especificar opções de montagem adicionais quando um Persistent Volume é montado num nó. +Um administrador do Kubernetes pode especificar opções de montagem adicionais quando um Volume Persistente é montado num nó. {{< note >}} -Nem todos os tipos de Persistent Volume suportam opções de montagem. +Nem todos os tipos de Volume Persistente suportam opções de montagem. {{< /note >}} Seguem os tipos de volumes que suportam opções de montagem. @@ -508,14 +442,14 @@ Seguem os tipos de volumes que suportam opções de montagem. * VsphereVolume * iSCSI -Não há validação em relação às opções de montagem. A montagem irá falhar se houver uma opção de montagem inválida. +Não há validação em relação às opções de montagem. A montagem irá falhar se houver alguma opção inválida. -No passado, a notação `volume.beta.kubernetes.io/mount-options` era usada no lugar do atributo `mountOptions`. Essa notação ainda funciona; contudo, ela será totalmente depreciada numa futura release do Kubernetes. +No passado, a notação `volume.beta.kubernetes.io/mount-options` era usada no lugar do atributo `mountOptions`. Essa notação ainda funciona. Contudo, ela será totalmente depreciada numa futura versão do Kubernetes. ### Afinidade de Nó {{< note >}} -Para a maioria dos tipos de volume, a configurção desse campo não se faz necessária. Isso é automaticamente populado pelos seguintes volumes do tipo bloco: [AWS EBS](/docs/concepts/storage/volumes/#awselasticblockstore), [GCE PD](/docs/concepts/storage/volumes/#gcepersistentdisk) e [Azure Disk](/docs/concepts/storage/volumes/#azuredisk). Você precisa deixar isso configurado para volumes do tipo [local](/docs/concepts/storage/volumes/#local). +Para a maioria dos tipos de volume, a configurção desse campo não se faz necessária. Isso é automaticamente populado pelos seguintes volumes de bloco do tipo: [AWS EBS](/docs/concepts/storage/volumes/#awselasticblockstore), [GCE PD](/docs/concepts/storage/volumes/#gcepersistentdisk) e [Azure Disk](/docs/concepts/storage/volumes/#azuredisk). Você precisa deixar isso configurado para volumes do tipo [local](/docs/concepts/storage/volumes/#local). {{< /note >}} Um PV pode especificar uma [afinidade de nó](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volumenodeaffinity-v1-core) para definir restrições em relação ao limite de nós que podem acessar esse volume. Pods que utilizam um PV serão somente reservados para nós selecionados pela afinidade de nó. @@ -530,12 +464,11 @@ Um volume sempre estará em dos seguintes estados: * Failed -- o volume fracassou na sua recuperação automática -A CLI mostrará o nome do PV que foi atrelado ao PVC -The CLI will show the name of the PVC bound to the PV. +A CLI mostrará o nome do PV que foi atrelado à PVC ## PersistentVolumeClaims -Cada PVC contém uma spec e um status, que é a especificação e estado de uma requisição. O nome de um objeto PersistentVolumeClaim precisa ser um [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) válido. +Cada PVC contém uma `spec` e um status, que é a especificação e estado de uma requisição. O nome de um objeto PersistentVolumeClaim precisa ser um [DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) válido. ```yaml apiVersion: v1 @@ -559,12 +492,8 @@ spec: ### Modos de Acesso - As requisições usam as mesmas convenções que os volumes quando eles solicitam um armazenamento com um modo de acesso específico. -As requisições usam as mesmas convenções que os volumes quando eles solicitam um storage com um modo de acesso específico. - - ### Modos de Volume As requisições usam as mesmas convenções que os volumes quando eles indicam o tipo de volume, seja ele um sistema de arquivo ou dispositivo de bloco. @@ -572,16 +501,13 @@ As requisições usam as mesmas convenções que os volumes quando eles indicam ### Recursos -Assim como Pods, as requisições podem solicitar quantidades específicas de recurso. Neste caso, a solicitação é por armazenamento. O mesmo [modelo de recurso](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) valem para volumes e requisições. +Assim como Pods, as requisições podem solicitar quantidades específicas de recurso. Neste caso, a solicitação é por armazenamento. O mesmo [modelo de recurso](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) vale para volumes e requisições. -Assim como Pods, as requisições podem solicitar quantidades específicas de recurso. Neste caso, a solicitação é por storage. O mesmo [modelo de recurso](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) valem para volumes e requisições. +### Seletor +Requisições podem especifiar um [seletor de rótulo](/docs/concepts/overview/working-with-objects/labels/#label-selectors) para posteriormente filtrar um grupo de volumes. Somente os volumes que possuam rótulos que safistaçam os critérios do seletor podem ser atrelados à requisição. O seletor pode conter dois campos: -### Selector - -Requisições podem especifiar um [label selector](/docs/concepts/overview/working-with-objects/labels/#label-selectors) para posteriormente filtrar um grupo de volumes. Somente os volumes que possuam labels que safistaçam os critérios do selector podem ser atreladas à requisição. O selector podem conter dois campos: - -* `matchLabels` - o volume deve ter uma label com esse valor +* `matchLabels` - o volume deve ter um rótulo com esse valor * `matchExpressions` - uma lista de requisitos, como chave, lista de valores e operador relacionado aos valores e chaves. São operadores válidos: In, NotIn, Exists e DoesNotExist. Todos os requisitos de `matchLabels` e `matchExpressions`, são do tipo AND - todos eles juntos devem ser atendidos. @@ -590,28 +516,24 @@ Todos os requisitos de `matchLabels` e `matchExpressions`, são do tipo AND - to Uma requisição pode solicitar uma classe específica através da [StorageClass](/docs/concepts/storage/storage-classes/) utilizando o atributo `storageClassName`. Neste caso o bind ocorrerá somente com os PVs que possuírem a mesma classe do `storageClassName` dos PVCs. -Os PVCs não precisam necessariamente solicitar uma classe. Um PVC com seu `storageClassName` configurado como `""` sempre vai solicitar um PV sem classe, dessa forma ele sempre será atrelado a um PV sem classe (que não tenha nenhuma notação ou seja igual a `""`). Um PVC sem `storageClassName` não é a mesma coisa e será tratado pelo cluster de forma diferente, porém isso vai depender se o [`DefaultStorageClass` admission plugin](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) estiver habilitado. +As PVCs não precisam necessariamente solicitar uma classe. Uma PVC com seu `storageClassName` configurada como `""` sempre vai solicitar um PV sem classe, dessa forma ela sempre será atrelada a um PV sem classe (que não tenha nenhuma notação ou seja igual a `""`). Uma PVC sem `storageClassName` não é a mesma coisa e será tratada pelo cluster de forma diferente, porém isso vai depender se o [puglin de admissão](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) `DefaultStorageClass` estiver habilitado. -* Se o admission plugin estiver habilitado, o administrador pode especificar o StorageClass padrão. Todos os PVCs que não tiverem `storageClassName` podem ser atrelados somente a PVs que atendam a essa padrão. A especificação de um StorageClass padrão é feita através da notação `storageclass.kubernetes.io/is-default-class` recebendo o valor `true` no objeto do StorageClass. Se o administrador não especificar nenhum padrão, o cluster vai tratar a criação de um PVC como se o admission plugin estivesse desabilitado. Se mais de um valor padrão for especificado, o admission plugin proíbe a criação de todos os PVCs. -* Se o admission plugin estiver desabilitado, não haverá nenhuma notação para o StorageClass padrão. Todos os PVCs que não tiverem `storageClassName` poderão ser atrelados somente aos PVs que não possuem classe.Neste caso, os PVCs que não tiverem `storageClassName` são tratados da mesma forma como os PVCs que possuem seus `storageClassName` configurados como `""`. +* Se o plugin de admissão estiver habilitado, o administrador poderá especificar a StorageClass padrão. Todas as PVCs que não tiverem `storageClassName` podem ser atreladas somente a PVs que atendam a essa padrão. A especificação de uma StorageClass padrão é feita através da notação `storageclass.kubernetes.io/is-default-class` recebendo o valor `true` no objeto da StorageClass. Se o administrador não especificar nenhum padrão, o cluster vai tratar a criação de uma PVC como se o plugin de admissão estivesse desabilitado. Se mais de um valor padrão for especificado, o plugin de admissã proíbe a criação de todas as PVCs. +* Se o plugin de admissão estiver desabilitado, não haverá nenhuma notação para a StorageClass padrão. Todas as PVCs que não tiverem `storageClassName` poderão ser atreladas somente aos PVs que não possuem classe. Neste caso, as PVCs que não tiverem `storageClassName` são tratadas da mesma forma como as PVCs que possuem suas `storageClassName` configuradas como `""`. -Dependendo do modo de instalação, um StorageClass padrão pode ser deployed num cluster Kubernetes durante a instalação pelo addon manager. +Dependendo do modo de instalação, uma StorageClass padrão pode ser implantada num cluster Kubernetes durante a instalação pelo addon manager. -Quando um PVC especifica um `selector` para solicitar um StorageClass, os requisitos são do tipo AND: somente um PV com a classe solicitada e com a label requisistada pode ser atrelado ao PVC. +Quando uma PVC especifica um `selector` para solicitar uma StorageClass, os requisitos são do tipo AND: somente um PV com a classe solicitada e com o rótulo requisistado pode ser atrelado à PVC. {{< note >}} -Atualmente, um PVC que tenha `selector` não pode ter um PV dinamicamente provisionado. +Atualmente, uma PVC que tenha `selector` não pode ter um PV dinamicamente provisionado. {{< /note >}} -No passado, a notação `volume.beta.kubernetes.io/storage-class` era usada no lugar do atribute `storageClassName` Essa notação ainda funciona; contudo, ela será totalmente depreciada numa futura release do Kubernetes. +No passado, a notação `volume.beta.kubernetes.io/storage-class` era usada no lugar do atributo `storageClassName` Essa notação ainda funciona. Contudo, ela será totalmente depreciada numa futura versão do Kubernetes. ## Requisições como Volumes - -Os Pods podem ter acesso ao armazenamento utilizando a requisição como um volume. Para isso a requisição tem que estar no mesmo namespace que o Pod. Ao localizar a requisição no namespace do Pod, o cluster passa o PersistentVolume para a requisição. - -Os Pods podem ter acesso ao storage utilizando a requisição como um volume. Para isso a requisição tem que estar no mesmo namespace que o Pod. Ao localizar a requisição no namespace do Pod, o cluster passa o PersistentVolume para a requisição. - +Os Pods podem ter acesso ao armazenamento utilizando a requisição como um volume. Para isso, a requisição tem que estar no mesmo namespace que o Pod. Ao localizar a requisição no namespace do Pod, o cluster passa o PersistentVolume para a requisição. ```yaml apiVersion: v1 @@ -633,21 +555,17 @@ spec: ### Sobre Namespaces -Os binds dos PersistentVolumes são exclusivos e desde que PersistentVolumeClaims são objetos do namespace, fazer a montagem das requisições com "Muitos" nós (`ROX`, `RWX`) é possível somente para um namespace. +Os binds dos PersistentVolumes são exclusivos e, desde que as PersistentVolumeClaims são objetos do namespace, fazer a montagem das requisições com "Muitos" nós (`ROX`, `RWX`) é possível somente para um namespace. ### PersistentVolumes do tipo `hostPath` -Um PersistentVolume do tipo `hostPath` utiliza um arquivo ou diretório no nó para emular um network-attached storage (NAS). -A `hostPath` PersistentVolume uses a file or directory on the Node to emulate network-attached storage. Veja um [um exemplo de volume do tipo `hostPath`](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume). +Um PersistentVolume do tipo `hostPath` utiliza um arquivo ou diretório no nó para emular um network-attached storage (NAS). Veja um [um exemplo de volume do tipo `hostPath`](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume). - -## Raw Block Volume Support +## Suporte a Volume de Bloco Bruto {{< feature-state for_k8s_version="v1.18" state="stable" >}} - -Os plugins de volume abaixo suportam raw block volumes, incluindo provisionamento dinâmico onde for possível: -applicable: +Os plugins de volume abaixo suportam volumes de bloco bruto, incluindo provisionamento dinâmico onde for aplicável: * AWSElasticBlockStore * AzureDisk @@ -660,8 +578,7 @@ applicable: * RBD (Ceph Block Device) * VsphereVolume - -### PersistentVolume using a Raw Block Volume {#persistent-volume-using-a-raw-block-volume} +### Utilização de PersistentVolume com Volume de Bloco Bruto {#persistent-volume-using-a-raw-block-volume} ```yaml apiVersion: v1 @@ -680,8 +597,8 @@ spec: lun: 0 readOnly: false ``` - -### PersistentVolumeClaim requesting a Raw Block Volume {#persistent-volume-claim-requesting-a-raw-block-volume} + +### Requisição de PersistentVolumeClaim com Volume de Bloco Bruto {#persistent-volume-claim-requesting-a-raw-block-volume} ```yaml apiVersion: v1 @@ -697,8 +614,7 @@ spec: storage: 10Gi ``` - -### Pod specification adding Raw Block Device path in container +### Especificação de Pod com Dipositivo de Bloco Bruto no contêiner ```yaml apiVersion: v1 @@ -721,16 +637,14 @@ spec: ``` {{< note >}} - -Quando adicionar a raw block device para um Pod, você especifica o caminho do dispositivo no container ao invés de um mount path +Quando adicionar um dispositivo de bloco bruto num Pod, você especifica o caminho do dispositivo no contêiner ao invés de um ponto de montagem. {{< /note >}} ### Bind de Volumes de Bloco -Se um usuário solicita um raw block volume através do campo `volumeMode` na spec do PersistentVolumeClaim, as regras de bind agora têm uma pequena diferença em relação às versões anteriores que não vão considerar esse modo como parte da spec. - -A tabela abaixo mostra as possíveis combinações que um usuário e um admin pode especificar para requisitar um raw block device. A tabela indica se o volume será ou não atrelado com base nas combinações: -Matrix de bind de volume para provisionamento estático de volumes: +Se um usuário solicita um volume de bloco bruto através do campo `volumeMode` na `spec` da PersistentVolumeClaim, as regras de bind agora têm uma pequena diferença em relação às versões anteriores que não consideravam esse modo como parte da `spec`. +A tabela abaixo mostra as possíveis combinações que um usuário e um admin pode especificar para requisitar um dispositivo de bloco bruto. A tabela indica se o volume será ou não atrelado com base nas combinações: +Matriz de bind de volume para provisionamento estático de volumes: | PV volumeMode | PVC volumeMode | Result | | --------------|:---------------:| ----------------:| @@ -745,18 +659,17 @@ Matrix de bind de volume para provisionamento estático de volumes: | Filesystem | unspecified | BIND | {{< note >}} - -O provisionamento estático de volumes é suportado somente na versão alpha. Administradores devem tomar cuidado ao considerar esses valores quando estiverem trabalhando com raw block devices. +O provisionamento estático de volumes é suportado somente na versão alpha. Os administradores devem tomar cuidado ao considerar esses valores quando estiverem trabalhando com dispositivos de bloco bruto. {{< /note >}} ## Snapshot de Volume e Restauração de Volume a partir de um Snapshot {{< feature-state for_k8s_version="v1.20" state="stable" >}} -O snapshot de volume é suportado somente pelo plugin de volume CSI. Veja [Volume Snapshots](/docs/concepts/storage/volume-snapshots/) para mais detalhes. -Plugins de volume in-tree estão depreciados. Você pode consultar sobre os plugins de volume depreciados em [Volume Plugin FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md). +O snapshot de volume é suportado somente pelo plugin de volume CSI. Veja [Snapshot de Volume](/docs/concepts/storage/volume-snapshots/) para mais detalhes. +Plugins de volume in-tree estão depreciados. Você pode consultar sobre os plugins de volume depreciados em [Perguntas Frequentes sobre Plugins de Volume](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md). -### Criar um PersistentVolumeClaim a partir de um Snapshot de Volume {#create-persistent-volume-claim-from-volume-snapshot} +### Criar uma PersistentVolumeClaim a partir de um Snapshot de Volume {#create-persistent-volume-claim-from-volume-snapshot} ```yaml apiVersion: v1 @@ -778,9 +691,9 @@ spec: ## Clonagem de Volume -[Volume Cloning](/docs/concepts/storage/volume-pvc-datasource/) only available for CSI volume plugins. +A [Clonagem de Volume](/docs/concepts/storage/volume-pvc-datasource/) é possível somente com plugins de volume CSI. -### Criação de PersistentVolumeClaim a partir de um PVC já existente {#create-persistent-volume-claim-from-an-existing-pvc} +### Criação de PersistentVolumeClaim a partir de uma PVC já existente {#create-persistent-volume-claim-from-an-existing-pvc} ```yaml apiVersion: v1 @@ -802,30 +715,21 @@ spec: ## Boas Práticas de Configuração -Se você está criando templates ou exemplos que rodam numa grande quantidade de clusters e que precisam de armazenamento persistente, recomendamos que utilize a estrutura abaixo: +Se você está criando templates ou exemplos que rodam numa grande quantidade de clusters e que precisam de armazenamento persistente, recomendamos que utilize o padrão abaixo: -Se você está criando templates ou exemplos que rodam numa grande quantidade de clusters e que precisam de storage persistente, recomendamos que utilize a estrutura abaixo: - - -- Inclua objetos PersistentVolumeClaim em seu pacote de configuração (juntanemte com Deployments, ConfigMaps, etc). +- Inclua objetos PersistentVolumeClaim em seu pacote de configuração (juntamente com Deployments, ConfigMaps, etc). - Não inclua objetos PersistentVolume na configuração, pois o usuário que irá instanciar a configuração talvez não tenha permissão para criar PersistentVolume. - the config may not have permission to create PersistentVolumes. - Dê ao usuário a opção dele informar o nome de uma classe de armazenamento quando instaciar o template. - - Se o usuário informar o nome de uma classe de armazenamento, coloque esse valor no campo `persistentVolumeClaim.storageClassName`. Isso fará com que o PVC encontre a classe de armazenamento correta se o cluster tiver o StorageClasses habilitado pelo administrador. - - Se o usuário não informar o nome da classe de armazenamento, deixe o campo `persistentVolumeClaim.storageClassName` sem nenhum valor (null). Isso fará com que o PV seja provisionado automaticamente no cluster para o usuário com o StorageClass padrão. Em muitos ambientes, o StorageClass padrão já instalado no cluster, ou então, os administradores podem criar seus StorageClass padrão. -- Durante suas tarefas de administração, busque por PVCs que após um tempo não estão sendo atrelados, pois isso talvez indique que o cluster não tem provisionamento dinâmico (que no caso, o usuário deveria criar um PV que satisfaça os critérios do PVC) ou cluster não tem um sistema de armazenamento (que no caso, o usuário não pode fazer deploy solicitando PVCs). -- Dê ao usuário a opção dele informar o nome de uma classe de storage quando instaciar o template. - - Se o usuário informar o nome de uma classe de storage, coloque esse valor no campo `persistentVolumeClaim.storageClassName`. Isso fará com que o PVC encontre a classe de storage correta se o cluster tiver o StorageClasses habilitado pelo administrador. - - Se o usuário não informar o nome da classe de storage, deixe o campo `persistentVolumeClaim.storageClassName` sem nenhum valor (null). Isso fará com que o PV seja provisionado automaticamente no cluster para o usuário com o StorageClass padrão. Em muitos ambientes, o StorageClass padrão já instalado no cluster, ou então, os administradores podem criar seus StorageClass padrão. -- Durante suas tarefas de administração, busque por PVCs que após um tempo não estão sendo atrelados, pois isso talvez indique que o cluster não tem provisionamento dinâmico (que no caso, o usuário deveria criar um PV que satisfaça os critérios do PVC) ou cluster não tem um sistema de storage (que no caso, o usuário não pode fazer deploy solicitando PVCs). - + - Se o usuário informar o nome de uma classe de armazenamento, coloque esse valor no campo `persistentVolumeClaim.storageClassName`. Isso fará com que a PVC encontre a classe de armazenamento correta se o cluster tiver a StorageClasses habilitado pelo administrador. + - Se o usuário não informar o nome da classe de armazenamento, deixe o campo `persistentVolumeClaim.storageClassName` sem nenhum valor (vazio). Isso fará com que o PV seja provisionado automaticamente no cluster para o usuário com o StorageClass padrão. Muitos ambientes de cluster já possuem uma StorageClass padrão, ou então os administradores podem criar suas StorageClass de acordo com seus critérios. +- Durante suas tarefas de administração, busque por PVCs que após um tempo não estão sendo atreladas, pois isso talvez indique que o cluster não tem provisionamento dinâmico (onde o usuário deveria criar um PV que satisfaça os critérios da PVC) ou cluster não tem um sistema de armazenamento (onde usuário não pode realizar um deploy solicitando PVCs). ## {{% heading "whatsnext" %}} * Saiba mais sobre [Criando um PersistentVolume](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume). * Saiba mais sobre [Criando um PersistentVolumeClaim](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolumeclaim). -* Leia a [documentação sobre plajemamento de Storage Persistente](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md). +* Leia a [documentação sobre plajemamento de Armazenamento Persistente](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md). ### Referência From 172de26c54ed9b53f7dff12b738d6e3c8decd17b Mon Sep 17 00:00:00 2001 From: Emanuel Haine Date: Sun, 7 Mar 2021 17:13:46 -0300 Subject: [PATCH 006/128] Miswritten corrections --- .../concepts/storage/persistent-volumes.md | 70 +++++++++---------- 1 file changed, 35 insertions(+), 35 deletions(-) diff --git a/content/pt/docs/concepts/storage/persistent-volumes.md b/content/pt/docs/concepts/storage/persistent-volumes.md index 7236c4c56d..8e952c607a 100644 --- a/content/pt/docs/concepts/storage/persistent-volumes.md +++ b/content/pt/docs/concepts/storage/persistent-volumes.md @@ -24,13 +24,13 @@ Esse documento descreve o estado atual dos _volumes persistentes_ no Kubernetes. ## Introdução -O gerenciamento de armazenamento é uma questão bem diferente do gerenciamento de instâncias computacionais. O subsitema PersistentVolume provê uma API para usuários e administradores que mostra de forma detalhada de como o armazenamento é provido e como ele é consumido. Para isso, nós introduzidmos duas novas APIs: PersistentVolume e PersistentVolumeClaim. +O gerenciamento de armazenamento é uma questão bem diferente do gerenciamento de instâncias computacionais. O subsistema PersistentVolume provê uma API para usuários e administradores que mostra de forma detalhada de como o armazenamento é provido e como ele é consumido. Para isso, nós introduzidmos duas novas APIs: PersistentVolume e PersistentVolumeClaim. Um _PersistentVolume_ (PV) é uma parte do armazenamento dentro do cluster que tenha sido provisionada por um administrador, ou dinamicamente utilizando [Classes de Armazenamento](/docs/concepts/storage/storage-classes/). Isso é um recurso dentro do cluster da mesma forma que um nó também é. PVs são plugins de volume da mesma forma que Volumes, porém eles têm um ciclo de vida independente de qualquer Pod que utilize um PV. Essa API tem por objetivo mostrar os detalhes da implementação do armazenamento, seja ele NFS, iSCSI, ou um armazenamento específico de um provedor de cloud pública. Uma_PersistentVolumeClaim_ (PVC) é uma requisição para armazenamento por um usuário. É similar a um Pod. Pods utilizam recursos do nó e PVCs utilizam recursos do PV. Pods podem solicitar níveis específicos de recursos (CPU e Memória). Claims podem solicitar tamanho e modos de acesso específicos (exemplo: montagem como ReadWriteOnce, ReadOnlyMany ou ReadWriteMany, veja [Modos de Acesso](#modos-de-acesso)). -Enquanto as PersistentVolumeClaims permitem que um usuário utilize recursos de armazenamento de forma limitada, é comum que usuários precisem de PersistentVolumes com diversas propriedades, como performance, para problemas diversos. Os administradores de cluster precisam estar aptos a oferecer uma variedade de PersistentVolumes que sejam diferentes em tamanho e modo de acesso, sem expor os usuários a detalhes de como esses volumes são implementados. Para necessidades como essas, temos o recurso de _StorageClass_. +Enquanto as PersistentVolumeClaims permitem que um usuário utilize recursos de armazenamento de forma limitada, é comum que usuários precisem de PersistentVolumes com diversas propriedades, como desempenho, para problemas diversos. Os administradores de cluster precisam estar aptos a oferecer uma variedade de PersistentVolumes que difiram em tamanho e modo de acesso, sem expor os usuários a detalhes de como esses volumes são implementados. Para necessidades como essas, temos o recurso de _StorageClass_. Veja os [exemplos de passo a passo de forma detalhada](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/). @@ -40,7 +40,7 @@ PVs são recursos dentro um cluster. PVCs são requisições para esses recursos ### Provisionamento -Existem duas formas de provisionar um PV: staticamente ou dinamicamente. +Existem duas formas de provisionar um PV: estaticamente ou dinamicamente. #### Estático @@ -48,15 +48,15 @@ O administrador do cluster cria uma determinada quantidade de PVs. Eles possuem #### Dinâmico -Quando nenhum dos PVs estáticos, que foram criados anteriormente pelo administrator, satisfazem os critérios de uma PersistentVolumeClaim enviado por um usuário, o cluster pode tentar realizar um provisionamento dinâmico para atender a essa PVC. Esse provisionamento é baseado em StorageClasses: a PVC deve solicitar uma [classe de armazenamento](/docs/concepts/storage/storage-classes/) e o administrador deve ter previamente criado e configurado essa classe para que o provisionamento dinâmico possa ocorrer. Requisições que solicitam a classe `""` efetivamente desabilitam o provisionamento dinâmico para elas mesmas. +Quando nenhum dos PVs estáticos, que foram criados anteriormente pelo administrador, satisfazem os critérios de uma PersistentVolumeClaim enviado por um usuário, o cluster pode tentar realizar um provisionamento dinâmico para atender a essa PVC. Esse provisionamento é baseado em StorageClasses: a PVC deve solicitar uma [classe de armazenamento](/docs/concepts/storage/storage-classes/) e o administrador deve ter previamente criado e configurado essa classe para que o provisionamento dinâmico possa ocorrer. Requisições que solicitam a classe `""` efetivamente desabilitam o provisionamento dinâmico para elas mesmas. -Para habilitar o provisionamento de armazenamento dinâmico baseado em classe de armazenamento, o administrador do cluster precisa habilitar o [controle de admissão](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) `DefaultStorageClass` no servidor da API. Isso pode ser feito, por exemplo, garantindo que `DefaultStorageClass` esteja entre aspas simples, ordenado por uma lista de valores para a flag `--enable-admission-plugins`, componente do servidor da API. Para maiores informações sobre os comandos das flags do servidor da API, consulte a documentação [kube-apiserver](/docs/admin/kube-apiserver/). +Para habilitar o provisionamento de armazenamento dinâmico baseado em classe de armazenamento, o administrador do cluster precisa habilitar o [controle de admissão](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) `DefaultStorageClass` no servidor da API. Isso pode ser feito, por exemplo, garantindo que `DefaultStorageClass` esteja entre aspas simples, ordenado por uma lista de valores para a flag `--enable-admission-plugins`, componente do servidor da API. Para mais informações sobre os comandos das flags do servidor da API, consulte a documentação [kube-apiserver](/docs/admin/kube-apiserver/). ### Binding -Um usuário cria, ou em caso de um provisionamento dinâmico já ter criado, uma PersistentVolumeClaim solicitando uma quantidade específica de armazenamento e um determinado modo de acesso. Um controle de loop no master monitora por novas PVCs, encontra um PV (se possível) que satisfaça os requisitos e realiza o bind. Se o PV foi provisionado dinamicamente por uma PVC, o loop sempre vai fazer o bind desse PV com essa PVC em específico. Caso contrário, o usuário vai receber no mínimo o que ele tinha solicitado, porém o volume possa exceder em relação à solicitação inicial. Uma vez realizado esse processo, PersistentVolumeClaim sempre vai ter um bind exclusivo, sem levar em conta como o isso aconteceu. Um bind entre uma PVC e um PV é um mapeamento de um pra um, utilizando o ClaimRef que é um bind bidirecional entre o PersistentVolume e o PersistentVolumeClaim. +Um usuário cria, ou em caso de um provisionamento dinâmico já ter criado, uma PersistentVolumeClaim solicitando uma quantidade específica de armazenamento e um determinado modo de acesso. Um controle de loop no master monitora por novas PVCs, encontra um PV (se possível) que satisfaça os requisitos e realiza o bind. Se o PV foi provisionado dinamicamente por uma PVC, o loop sempre vai fazer o bind desse PV com essa PVC em específico. Caso contrário, o usuário vai receber no mínimo o que ele havia solicitado, porém, o volume possa exceder em relação à solicitação inicial. Uma vez realizado esse processo, PersistentVolumeClaim sempre vai ter um bind exclusivo, sem levar em conta como o isso aconteceu. Um bind entre uma PVC e um PV é um mapeamento de um para um, utilizando o ClaimRef que é um bind bidirecional entre o PersistentVolume e o PersistentVolumeClaim. -As requisições permanecerão sem bind se o volume solicitado não existir. O bind ocorrerá somente se os requisitos forem atendidos exatamente da mesma forma como solicitado. Por exemplo, um bind de uma PVC de 100GB não vai ocorrer num cluster que foi provisionado com vários PVs de 50GB. O bind ocorrerá somente no momento em que um PV de 100GB for adicionado. +As requisições permanecerão sem bind se o volume solicitado não existir. O bind ocorrerá somente se os requisitos forem atendidos exatamente da mesma forma como solicitado. Por exemplo, um bind de uma PVC de 100 GB não ocorrerá num cluster que foi provisionado com vários PVs de 50 GB. O bind ocorrerá somente no momento em que um PV de 100 GB for adicionado. ### Utilização @@ -72,9 +72,9 @@ O propósito da funcionalidade do Objeto de Armazenamento em Proteção de Uso Uma PVC está sendo utilizada por um Pod quando existe um Pod que está usando essa PVC. {{< /note >}} -Se um usuário deleta uma PVC que está sendo utilizada por um Pod, esta PVC não é removida imediatamente. A remoção da PVC é adiada até que a PVC não esteja mais sendo utilizado por nenhum Pod. Se um admin deleta um PV que está atrelado a uma PVC, o PV não é removido imediatamente também. A remoção do PV é adiada até que o PV não esteja mais atrelado à PVC. +Se um usuário deleta uma PVC que está sendo utilizada por um Pod, esta PVC não é removida imediatamente. A remoção da PVC é adiada até que a PVC não esteja mais sendo utilizado por nenhum Pod. Se um administrador deleta um PV que está atrelado a uma PVC, o PV não é removido imediatamente também. A remoção do PV é adiada até que o PV não esteja mais atrelado à PVC. -Você pode ver que uma PVC é protegida quando o status da PVC é `Terminating` e a lista `Finalizers` contém `kubernetes.io/pvc-protection`: +Note que uma PVC é protegida quando o status da PVC é `Terminating` e a lista `Finalizers` contém `kubernetes.io/pvc-protection`: ```shell kubectl describe pvc hostpath @@ -90,7 +90,7 @@ Finalizers: [kubernetes.io/pvc-protection] ... ``` -Você pode ver que um PV é protegido quando o status da PVC é `Terminating` e a lista `Finalizers` contém `kubernetes.io/pv-protection` também: +Note que um PV é protegido quando o status da PVC é `Terminating` e a lista `Finalizers` contém `kubernetes.io/pv-protection` também: ```shell kubectl describe pv task-pv-volume @@ -114,25 +114,25 @@ Events: ### Recuperação -Quando um usuário não precisar mais utilizar um volume, ele pode deletar a PVC pela API, que por sua vez permite a recuperação do recurso. A política de recuperação para um PersistentVolume diz ao cluster o que fazer com o volume após ele ter sido liberado da sua requisição. Atualmente, volumes podem ser Retidos, Reciclados ou Deletados. +Quando um usuário não precisar mais utilizar um volume, ele pode deletar a PVC pela API, que, permite a recuperação do recurso. A política de recuperação para um PersistentVolume diz ao cluster o que fazer com o volume após ele ter sido liberado da sua requisição. Atualmente, volumes podem ser Retidos, Reciclados ou Deletados. #### Retenção A política `Retain` permite a recuperação de forma manual do recurso. Quando a PersistentVolumeClaim é deletada, ela continua existindo e o volume é considerado "livre". Mas ele ainda não está disponível para outra requisição porque os dados da requisição anterior ainda permanecem no volume. Um administrador pode manuamente recuperar o volume executando os seguintes passos: -1. Deletar o PersistentVolume. O armazenamento associado à infraestrutura externa (AWS EBS, GCE PD, Azure Disk, or Cinder volume) ainda continuará existindo após o PV ser deletado. +1. Deletar o PersistentVolume. O armazenamento associado à infraestrutura externa (AWS EBS, GCE PD, Azure Disk ou Cinder volume) ainda continuará existindo após o PV ser deletado. 1. Limpar os dados de forma manual no armazenamento associado. 1. Deletar manualmente o armazenamento associado. Caso você queira utilizar o mesmo armazenamento, crie um novo PersistentVolume com esse armazenamento. #### Deletar -Para plugins de volume que suportam a política de recuperação `Delete`, a deleção vai remover o tanto o PersistentVolume do Kubernetes, quanto o armazenamento associado à infraestrutura externa, como AWS EBS, GCE PD, Azure Disk, ou Cinder volume. Volumes que foram provisionados dinamicamente herdam a [política de retenção da sua StorageClass](#política-de-retenção), que por padrão é `Delete`. O administrador precisa configurar a StorageClass de acordo com as necessidades dos usuários. Caso contrário, o PV deve ser editado ou reparado após sua criação. Veja [Alterar a política de renteção de um PersistentVolume](/docs/tasks/administer-cluster/change-pv-reclaim-policy/). +Para plugins de volume que suportam a política de recuperação `Delete`, a deleção vai remover o tanto o PersistentVolume do Kubernetes, quanto o armazenamento associado à infraestrutura externa, como AWS EBS, GCE PD, Azure Disk, ou Cinder volume. Volumes que foram provisionados dinamicamente herdam a [política de retenção da sua StorageClass](#política-de-retenção), que por padrão é `Delete`. O administrador precisa configurar a StorageClass de acordo com as necessidades dos usuários. Caso contrário, o PV deve ser editado ou reparado após sua criação. Veja [Alterar a política de retenção de um PersistentVolume](/docs/tasks/administer-cluster/change-pv-reclaim-policy/). #### Reciclar {{< warning >}} -A política de retenção `Recycle` está depreciada. Ao invés disso, recomendamos a utilização de provisionametno dinâmico. +A política de retenção `Recycle` está depreciada. Ao invés disso, recomendamos a utilização de provisionamento dinâmico. {{< /warning >}} Em caso do volume plugin ter suporte a essa operação, a política de retenção `Recycle` faz uma limpeza básica (`rm -rf /thevolume/*`) no volume e torna ele disponível novamente para outra requisição. @@ -165,7 +165,7 @@ Contudo, o caminho especificado no Pod reciclador personalizado em `volumes` é ### Reservando um PersistentVolume -A camada de gerenciamento pode [fazer o bind de um PersistentVolumeClaims com PersistentVolumes equivalentes](#binding) no cluster. Contudo, se você quer que uma PVC faça um bind com um PV específco, é preciso fazer o pré-bind deles. +A camada de gerenciamento pode [fazer o bind de um PersistentVolumeClaims com PersistentVolumes equivalentes](#binding) no cluster. Contudo, se você quer que uma PVC faça um bind com um PV específico, é preciso fazer o pré-bind deles. Especificando um PersistentVolume na PersistentVolumeClaim, você declara um bind entre uma PVC e um PV específico. O bind ocorrerá se o PersistentVolume existir e não estiver reservado por uma PersistentVolumeClaims através do seu campo `claimRef`. @@ -217,7 +217,7 @@ Agora, o suporte à expansão de PersistentVolumeClaims (PVCs) já é habilitado * FlexVolumes * {{< glossary_tooltip text="CSI" term_id="csi" >}} -Você só pode expandir uma PVC se o campo da classe de armazenamento `allowVolumeExpansion` é _true_. +Você só pode expandir uma PVC se o campo da classe de armazenamento `allowVolumeExpansion` é `true`. ``` yaml apiVersion: storage.k8s.io/v1 @@ -254,7 +254,7 @@ FlexVolumes permitem redimensionamento se o `RequiresFSResize` do drive é confi {{< feature-state for_k8s_version="v1.15" state="beta" >}} {{< note >}} -A Expansão de PVCs em uso está disponível como beta desde o Kubernetes 1.15, e como alpha desde a versão 1.11. A funcionalidade `ExpandInUsePersistentVolumes` precisa ser habilitada, o que já está automático para vários clusters que possuem funcionalidades beta. Verifique a documentação [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) para maiores informações. +A Expansão de PVCs em uso está disponível como beta desde o Kubernetes 1.15, e como alpha desde a versão 1.11. A funcionalidade `ExpandInUsePersistentVolumes` precisa ser habilitada, o que já está automático para vários clusters que possuem funcionalidades beta. Verifique a documentação [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) para mais informações. {{< /note >}} Neste caso, você não precisa deletar e recriar um Pod ou um deployment que está sendo utilizado por uma PVC existente. @@ -314,7 +314,7 @@ Tipos de PersistentVolume são implementados como plugins. Atualmente o Kubernet ## Volumes Persistentes -Cada PV contém uma `spec` e um status, que é a espeficiação e o status do volume. O nome do PersistentVolume deve ser um [DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) válido. +Cada PV contém uma `spec` e um status, que é a especificação e o status do volume. O nome do PersistentVolume deve ser um [DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) válido. ```yaml apiVersion: v1 @@ -353,7 +353,7 @@ Atualmente, o tamanho do armazenamento é o único recurso que pode ser configur O Kubernetes suporta dois `volumeModes` de PersistentVolumes: `Filesystem` e `Block`. -`volumeMode` é um parâmetro opicional da API. +`volumeMode` é um parâmetro opcional da API. `Filesystem` é o modo padrão utilizado quando o parâmetro `volumeMode` é omitido. Um volume com `volumeMode: Filesystem` é *montado* em um diretório nos Pods. Se o volume for de um dispositivo de bloco e ele estiver vazio, o Kubernetes cria o sistema de arquivo no dispositivo antes de fazer a montagem pela primeira vez. @@ -376,7 +376,7 @@ Na linha de comando, os modos de acesso ficam abreviados: * ROX - ReadOnlyMany * RWX - ReadWriteMany -> __Importante!__ Um volume somente pode ser montado utilizando um único modo de acesso por vez, independente se ele suportar mais de um. Por exemplo, um GCEPersistentDisk pode ser montado como ReadWriteOnce por um único nó ou ReadOnlyMany por vários nós, porém não ao mesmo tempo. +> __Importante!__ Um volume somente pode ser montado utilizando um único modo de acesso por vez, independente se ele suportar mais de um. Por exemplo, um GCEPersistentDisk pode ser montado como ReadWriteOnce por um único nó ou ReadOnlyMany por vários nós, porém não simultaneamente. | Plugin de Volume | ReadWriteOnce | ReadOnlyMany | ReadWriteMany| @@ -404,13 +404,13 @@ Na linha de comando, os modos de acesso ficam abreviados: ### Classe -Um PV pode ter uma classe, que é especificada na configuração do atributo `storageClassName` com o nome da [StorageClass](/docs/concepts/storage/storage-classes/). Um PV de uma classe específica só pode ser atrelado a requições PVCs dessa mesma classe. Um PV sem `storageClassName` não possui nenhuma classe e pode ser montado somente a PVCs que não solicitem nenhuma classe em específico. +Um PV pode ter uma classe, que é especificada na configuração do atributo `storageClassName` com o nome da [StorageClass](/docs/concepts/storage/storage-classes/). Um PV de uma classe específica só pode ser atrelado a requisições PVCs dessa mesma classe. Um PV sem `storageClassName` não possui nenhuma classe e pode ser montado somente a PVCs que não solicitem nenhuma classe em específico. No passado, a notação `volume.beta.kubernetes.io/storage-class` era utilizada no lugar do atributo `storageClassName`. Essa notação ainda funciona. Contudo, ela será totalmente depreciada numa futura versão do Kubernetes. ### Política de Retenção -Atuamente as políticas de retenção são: +Atualmente as políticas de retenção são: * Retain -- recuperação manual * Recycle -- limpeza básica (`rm -rf /thevolume/*`) @@ -449,7 +449,7 @@ No passado, a notação `volume.beta.kubernetes.io/mount-options` era usada no l ### Afinidade de Nó {{< note >}} -Para a maioria dos tipos de volume, a configurção desse campo não se faz necessária. Isso é automaticamente populado pelos seguintes volumes de bloco do tipo: [AWS EBS](/docs/concepts/storage/volumes/#awselasticblockstore), [GCE PD](/docs/concepts/storage/volumes/#gcepersistentdisk) e [Azure Disk](/docs/concepts/storage/volumes/#azuredisk). Você precisa deixar isso configurado para volumes do tipo [local](/docs/concepts/storage/volumes/#local). +Para a maioria dos tipos de volume, a configuração desse campo não se faz necessária. Isso é automaticamente populado pelos seguintes volumes de bloco do tipo: [AWS EBS](/docs/concepts/storage/volumes/#awselasticblockstore), [GCE PD](/docs/concepts/storage/volumes/#gcepersistentdisk) e [Azure Disk](/docs/concepts/storage/volumes/#azuredisk). Você precisa deixar isso configurado para volumes do tipo [local](/docs/concepts/storage/volumes/#local). {{< /note >}} Um PV pode especificar uma [afinidade de nó](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volumenodeaffinity-v1-core) para definir restrições em relação ao limite de nós que podem acessar esse volume. Pods que utilizam um PV serão somente reservados para nós selecionados pela afinidade de nó. @@ -460,7 +460,7 @@ Um volume sempre estará em dos seguintes estados: * Available -- um recurso que está livre e ainda não foi atrelado a nenhuma requisição * Bound -- um volume atrelado a uma requisição -* Released -- a requisião foi deletada, mas o curso ainda não foi recuperado pelo cluster +* Released -- a requisição foi deletada, mas o curso ainda não foi recuperado pelo cluster * Failed -- o volume fracassou na sua recuperação automática @@ -505,7 +505,7 @@ Assim como Pods, as requisições podem solicitar quantidades específicas de re ### Seletor -Requisições podem especifiar um [seletor de rótulo](/docs/concepts/overview/working-with-objects/labels/#label-selectors) para posteriormente filtrar um grupo de volumes. Somente os volumes que possuam rótulos que safistaçam os critérios do seletor podem ser atrelados à requisição. O seletor pode conter dois campos: +Requisições podem especifiar um [seletor de rótulo](/docs/concepts/overview/working-with-objects/labels/#label-selectors) para posteriormente filtrar um grupo de volumes. Somente os volumes que possuam rótulos que satisfaçam os critérios do seletor podem ser atrelados à requisição. O seletor pode conter dois campos: * `matchLabels` - o volume deve ter um rótulo com esse valor * `matchExpressions` - uma lista de requisitos, como chave, lista de valores e operador relacionado aos valores e chaves. São operadores válidos: In, NotIn, Exists e DoesNotExist. @@ -516,14 +516,14 @@ Todos os requisitos de `matchLabels` e `matchExpressions`, são do tipo AND - to Uma requisição pode solicitar uma classe específica através da [StorageClass](/docs/concepts/storage/storage-classes/) utilizando o atributo `storageClassName`. Neste caso o bind ocorrerá somente com os PVs que possuírem a mesma classe do `storageClassName` dos PVCs. -As PVCs não precisam necessariamente solicitar uma classe. Uma PVC com seu `storageClassName` configurada como `""` sempre vai solicitar um PV sem classe, dessa forma ela sempre será atrelada a um PV sem classe (que não tenha nenhuma notação ou seja igual a `""`). Uma PVC sem `storageClassName` não é a mesma coisa e será tratada pelo cluster de forma diferente, porém isso vai depender se o [puglin de admissão](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) `DefaultStorageClass` estiver habilitado. +As PVCs não precisam necessariamente solicitar uma classe. Uma PVC com sua `storageClassName` configurada como `""` sempre solicitará um PV sem classe, dessa forma ela sempre será atrelada a um PV sem classe (que não tenha nenhuma notação, ou seja, igual a `""`). Uma PVC sem `storageClassName` não é a mesma coisa e será tratada pelo cluster de forma diferente, porém isso dependerá se o [puglin de admissão](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) `DefaultStorageClass` estiver habilitado. -* Se o plugin de admissão estiver habilitado, o administrador poderá especificar a StorageClass padrão. Todas as PVCs que não tiverem `storageClassName` podem ser atreladas somente a PVs que atendam a essa padrão. A especificação de uma StorageClass padrão é feita através da notação `storageclass.kubernetes.io/is-default-class` recebendo o valor `true` no objeto da StorageClass. Se o administrador não especificar nenhum padrão, o cluster vai tratar a criação de uma PVC como se o plugin de admissão estivesse desabilitado. Se mais de um valor padrão for especificado, o plugin de admissã proíbe a criação de todas as PVCs. +* Se o plugin de admissão estiver habilitado, o administrador poderá especificar a StorageClass padrão. Todas as PVCs que não tiverem `storageClassName` podem ser atreladas somente a PVs que atendam a esse padrão. A especificação de uma StorageClass padrão é feita através da notação `storageclass.kubernetes.io/is-default-class` recebendo o valor `true` no objeto da StorageClass. Se o administrador não especificar nenhum padrão, o cluster vai tratar a criação de uma PVC como se o plugin de admissão estivesse desabilitado. Se mais de um valor padrão for especificado, o plugin de admissão proíbe a criação de todas as PVCs. * Se o plugin de admissão estiver desabilitado, não haverá nenhuma notação para a StorageClass padrão. Todas as PVCs que não tiverem `storageClassName` poderão ser atreladas somente aos PVs que não possuem classe. Neste caso, as PVCs que não tiverem `storageClassName` são tratadas da mesma forma como as PVCs que possuem suas `storageClassName` configuradas como `""`. Dependendo do modo de instalação, uma StorageClass padrão pode ser implantada num cluster Kubernetes durante a instalação pelo addon manager. -Quando uma PVC especifica um `selector` para solicitar uma StorageClass, os requisitos são do tipo AND: somente um PV com a classe solicitada e com o rótulo requisistado pode ser atrelado à PVC. +Quando uma PVC especifica um `selector` para solicitar uma StorageClass, os requisitos são do tipo AND: somente um PV com a classe solicitada e com o rótulo requisitado pode ser atrelado à PVC. {{< note >}} Atualmente, uma PVC que tenha `selector` não pode ter um PV dinamicamente provisionado. @@ -559,7 +559,7 @@ Os binds dos PersistentVolumes são exclusivos e, desde que as PersistentVolumeC ### PersistentVolumes do tipo `hostPath` -Um PersistentVolume do tipo `hostPath` utiliza um arquivo ou diretório no nó para emular um network-attached storage (NAS). Veja um [um exemplo de volume do tipo `hostPath`](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume). +Um PersistentVolume do tipo `hostPath` utiliza um arquivo ou diretório no nó para emular um network-attached storage (NAS). Veja [um exemplo de volume do tipo `hostPath`](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume). ## Suporte a Volume de Bloco Bruto @@ -614,7 +614,7 @@ spec: storage: 10Gi ``` -### Especificação de Pod com Dipositivo de Bloco Bruto no contêiner +### Especificação de Pod com Dispositivo de Bloco Bruto no contêiner ```yaml apiVersion: v1 @@ -643,7 +643,7 @@ Quando adicionar um dispositivo de bloco bruto num Pod, você especifica o camin ### Bind de Volumes de Bloco Se um usuário solicita um volume de bloco bruto através do campo `volumeMode` na `spec` da PersistentVolumeClaim, as regras de bind agora têm uma pequena diferença em relação às versões anteriores que não consideravam esse modo como parte da `spec`. -A tabela abaixo mostra as possíveis combinações que um usuário e um admin pode especificar para requisitar um dispositivo de bloco bruto. A tabela indica se o volume será ou não atrelado com base nas combinações: +A tabela abaixo mostra as possíveis combinações que um usuário e um administrador pode especificar para requisitar um dispositivo de bloco bruto. A tabela indica se o volume será ou não atrelado com base nas combinações: Matriz de bind de volume para provisionamento estático de volumes: | PV volumeMode | PVC volumeMode | Result | @@ -717,19 +717,19 @@ spec: Se você está criando templates ou exemplos que rodam numa grande quantidade de clusters e que precisam de armazenamento persistente, recomendamos que utilize o padrão abaixo: -- Inclua objetos PersistentVolumeClaim em seu pacote de configuração (juntamente com Deployments, ConfigMaps, etc). +- Inclua objetos PersistentVolumeClaim em seu pacote de configuração (com Deployments, ConfigMaps, etc.). - Não inclua objetos PersistentVolume na configuração, pois o usuário que irá instanciar a configuração talvez não tenha permissão para criar PersistentVolume. -- Dê ao usuário a opção dele informar o nome de uma classe de armazenamento quando instaciar o template. +- Dê ao usuário a opção dele informar o nome de uma classe de armazenamento quando instanciar o template. - Se o usuário informar o nome de uma classe de armazenamento, coloque esse valor no campo `persistentVolumeClaim.storageClassName`. Isso fará com que a PVC encontre a classe de armazenamento correta se o cluster tiver a StorageClasses habilitado pelo administrador. - Se o usuário não informar o nome da classe de armazenamento, deixe o campo `persistentVolumeClaim.storageClassName` sem nenhum valor (vazio). Isso fará com que o PV seja provisionado automaticamente no cluster para o usuário com o StorageClass padrão. Muitos ambientes de cluster já possuem uma StorageClass padrão, ou então os administradores podem criar suas StorageClass de acordo com seus critérios. -- Durante suas tarefas de administração, busque por PVCs que após um tempo não estão sendo atreladas, pois isso talvez indique que o cluster não tem provisionamento dinâmico (onde o usuário deveria criar um PV que satisfaça os critérios da PVC) ou cluster não tem um sistema de armazenamento (onde usuário não pode realizar um deploy solicitando PVCs). +- Durante suas tarefas de administração, busque por PVCs que após um tempo não estão sendo atreladas, pois, isso talvez indique que o cluster não tem provisionamento dinâmico (onde o usuário deveria criar um PV que satisfaça os critérios da PVC) ou cluster não tem um sistema de armazenamento (onde usuário não pode realizar um deploy solicitando PVCs). ## {{% heading "whatsnext" %}} * Saiba mais sobre [Criando um PersistentVolume](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume). * Saiba mais sobre [Criando um PersistentVolumeClaim](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolumeclaim). -* Leia a [documentação sobre plajemamento de Armazenamento Persistente](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md). +* Leia a [documentação sobre planejamento de Armazenamento Persistente](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md). ### Referência From dc413834ea87700991dc53796dda76df417706d5 Mon Sep 17 00:00:00 2001 From: rosespecs <64780953+rosespecs@users.noreply.github.com> Date: Thu, 1 Apr 2021 10:52:56 +0100 Subject: [PATCH 007/128] Gramma fix for change-pv-reclaim-policy.md Changing `is` to `will` here makes more grammatical sense. --- .../docs/tasks/administer-cluster/change-pv-reclaim-policy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md b/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md index be7cbf2673..6a11b4f2d3 100644 --- a/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md +++ b/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md @@ -26,7 +26,7 @@ volume is automatically deleted when a user deletes the corresponding PersistentVolumeClaim. This automatic behavior might be inappropriate if the volume contains precious data. In that case, it is more appropriate to use the "Retain" policy. With the "Retain" policy, if a user deletes a PersistentVolumeClaim, -the corresponding PersistentVolume is not be deleted. Instead, it is moved to the +the corresponding PersistentVolume will not be deleted. Instead, it is moved to the Released phase, where all of its data can be manually recovered. ## Changing the reclaim policy of a PersistentVolume From a38531234fd4c27cdf6c9890783bf50e43a8d0aa Mon Sep 17 00:00:00 2001 From: dancnfoo Date: Thu, 15 Apr 2021 11:50:24 -0700 Subject: [PATCH 008/128] Update custom-resource-definition-versioning.md `stored` should be `storage` --- .../custom-resources/custom-resource-definition-versioning.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md index 671637c084..7800799008 100644 --- a/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md +++ b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md @@ -80,7 +80,7 @@ Removing an old version: If this occurs, switch back to using `served:true` on the old version, migrate the remaining clients to the new version and repeat this step. 1. Ensure the [upgrade of existing objects to the new stored version](#upgrade-existing-objects-to-a-new-stored-version) step has been completed. - 1. Verify that the `stored` is set to `true` for the new version in the `spec.versions` list in the CustomResourceDefinition. + 1. Verify that the `storage` is set to `true` for the new version in the `spec.versions` list in the CustomResourceDefinition. 1. Verify that the old version is no longer listed in the CustomResourceDefinition `status.storedVersions`. 1. Remove the old version from the CustomResourceDefinition `spec.versions` list. 1. Drop conversion support for the old version in conversion webhooks. From ce1f6287326a6fcaa75166adda292a349d93d496 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Sat, 17 Apr 2021 14:46:03 +0000 Subject: [PATCH 009/128] Translate tasks/manage-kubernetes-objects/ into Japanese --- content/ja/docs/tasks/manage-kubernetes-objects/_index.md | 5 +++++ 1 file changed, 5 insertions(+) create mode 100644 content/ja/docs/tasks/manage-kubernetes-objects/_index.md diff --git a/content/ja/docs/tasks/manage-kubernetes-objects/_index.md b/content/ja/docs/tasks/manage-kubernetes-objects/_index.md new file mode 100644 index 0000000000..16150cf3d7 --- /dev/null +++ b/content/ja/docs/tasks/manage-kubernetes-objects/_index.md @@ -0,0 +1,5 @@ +--- +title: "Kubernetesオブジェクトの管理" +description: Kubernetes APIと対話するための宣言型および命令型のパラダイム。 +weight: 25 +--- From 47a3422cc58f11260f47077e669d3467aba5c695 Mon Sep 17 00:00:00 2001 From: Mengjiao Liu Date: Mon, 19 Apr 2021 18:52:01 +0800 Subject: [PATCH 010/128] [ja] Update CronJob example yaml apiversion: batch/v1beta1 --> batch/v1 --- content/ja/examples/application/job/cronjob.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/examples/application/job/cronjob.yaml b/content/ja/examples/application/job/cronjob.yaml index 2ce31233c3..34ab2a3f06 100644 --- a/content/ja/examples/application/job/cronjob.yaml +++ b/content/ja/examples/application/job/cronjob.yaml @@ -1,4 +1,4 @@ -apiVersion: batch/v1beta1 +apiVersion: batch/v1 kind: CronJob metadata: name: hello From 37a6668fb2fd99ad3abd8ea0f1a4d65f30f36e1b Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Sat, 24 Apr 2021 05:39:06 +0000 Subject: [PATCH 011/128] Copy /content/en/docs/tasks/job/indexed-parallel-processing-static.md for Japanese translation --- .../job/indexed-parallel-processing-static.md | 190 ++++++++++++++++++ 1 file changed, 190 insertions(+) create mode 100644 content/ja/docs/tasks/job/indexed-parallel-processing-static.md diff --git a/content/ja/docs/tasks/job/indexed-parallel-processing-static.md b/content/ja/docs/tasks/job/indexed-parallel-processing-static.md new file mode 100644 index 0000000000..b5492eed6e --- /dev/null +++ b/content/ja/docs/tasks/job/indexed-parallel-processing-static.md @@ -0,0 +1,190 @@ +--- +title: Indexed Job for Parallel Processing with Static Work Assignment +content_type: task +min-kubernetes-server-version: v1.21 +weight: 30 +--- + +{{< feature-state for_k8s_version="v1.21" state="alpha" >}} + + + + +In this example, you will run a Kubernetes Job that uses multiple parallel +worker processes. +Each worker is a different container running in its own Pod. The Pods have an +_index number_ that the control plane sets automatically, which allows each Pod +to identify which part of the overall task to work on. + +The pod index is available in the {{< glossary_tooltip text="annotation" term_id="annotation" >}} +`batch.kubernetes.io/job-completion-index` as a string representing its +decimal value. In order for the containerized task process to obtain this index, +you can publish the value of the annotation using the [downward API](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#the-downward-api) +mechanism. +For convenience, the control plane automatically sets the downward API to +expose the index in the `JOB_COMPLETION_INDEX` environment variable. + +Here is an overview of the steps in this example: + +1. **Define a Job manifest using indexed completion**. + The downward API allows you to pass the pod index annotation as an + environment variable or file to the container. +2. **Start an `Indexed` Job based on that manifest**. + +## {{% heading "prerequisites" %}} + +You should already be familiar with the basic, +non-parallel, use of [Job](/docs/concepts/workloads/controllers/job/). + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +To be able to create Indexed Jobs, make sure to enable the `IndexedJob` +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) +on the [API server](/docs/reference/command-line-tools-reference/kube-apiserver/) +and the [controller manager](/docs/reference/command-line-tools-reference/kube-controller-manager/). + + + +## Choose an approach + +To access the work item from the worker program, you have a few options: + +1. Read the `JOB_COMPLETION_INDEX` environment variable. The Job + {{< glossary_tooltip text="controller" term_id="controller" >}} + automatically links this variable to the annotation containing the completion + index. +1. Read a file that contains the completion index. +1. Assuming that you can't modify the program, you can wrap it with a script + that reads the index using any of the methods above and converts it into + something that the program can use as input. + +For this example, imagine that you chose option 3 and you want to run the +[rev](https://man7.org/linux/man-pages/man1/rev.1.html) utility. This +program accepts a file as an argument and prints its content reversed. + +```shell +rev data.txt +``` + +You'll use the `rev` tool from the +[`busybox`](https://hub.docker.com/_/busybox) container image. + +As this is only an example, each Pod only does a tiny piece of work (reversing a short +string). In a real workload you might, for example, create a Job that represents + the +task of producing 60 seconds of video based on scene data. +Each work item in the video rendering Job would be to render a particular +frame of that video clip. Indexed completion would mean that each Pod in +the Job knows which frame to render and publish, by counting frames from +the start of the clip. + +## Define an Indexed Job + +Here is a sample Job manifest that uses `Indexed` completion mode: + +{{< codenew language="yaml" file="application/job/indexed-job.yaml" >}} + +In the example above, you use the builtin `JOB_COMPLETION_INDEX` environment +variable set by the Job controller for all containers. An [init container](/docs/concepts/workloads/pods/init-containers/) +maps the index to a static value and writes it to a file that is shared with the +container running the worker through an [emptyDir volume](/docs/concepts/storage/volumes/#emptydir). +Optionally, you can [define your own environment variable through the downward +API](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/) +to publish the index to containers. You can also choose to load a list of values +from a [ConfigMap as an environment variable or file](/docs/tasks/configure-pod-container/configure-pod-configmap/). + +Alternatively, you can directly [use the downward API to pass the annotation +value as a volume file](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#store-pod-fields), +like shown in the following example: + +{{< codenew language="yaml" file="application/job/indexed-job-vol.yaml" >}} + +## Running the Job + +Now run the Job: + +```shell +# This uses the first approach (relying on $JOB_COMPLETION_INDEX) +kubectl apply -f https://kubernetes.io/examples/application/job/indexed-job.yaml +``` + +When you create this Job, the control plane creates a series of Pods, one for each index you specified. The value of `.spec.parallelism` determines how many can run at once whereas `.spec.completions` determines how many Pods the Job creates in total. + +Because `.spec.parallelism` is less than `.spec.completions`, the control plane waits for some of the first Pods to complete before starting more of them. + +Once you have created the Job, wait a moment then check on progress: + +```shell +kubectl describe jobs/indexed-job +``` + +The output is similar to: + +``` +Name: indexed-job +Namespace: default +Selector: controller-uid=bf865e04-0b67-483b-9a90-74cfc4c3e756 +Labels: controller-uid=bf865e04-0b67-483b-9a90-74cfc4c3e756 + job-name=indexed-job +Annotations: +Parallelism: 3 +Completions: 5 +Start Time: Thu, 11 Mar 2021 15:47:34 +0000 +Pods Statuses: 2 Running / 3 Succeeded / 0 Failed +Completed Indexes: 0-2 +Pod Template: + Labels: controller-uid=bf865e04-0b67-483b-9a90-74cfc4c3e756 + job-name=indexed-job + Init Containers: + input: + Image: docker.io/library/bash + Port: + Host Port: + Command: + bash + -c + items=(foo bar baz qux xyz) + echo ${items[$JOB_COMPLETION_INDEX]} > /input/data.txt + + Environment: + Mounts: + /input from input (rw) + Containers: + worker: + Image: docker.io/library/busybox + Port: + Host Port: + Command: + rev + /input/data.txt + Environment: + Mounts: + /input from input (rw) + Volumes: + input: + Type: EmptyDir (a temporary directory that shares a pod's lifetime) + Medium: + SizeLimit: +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal SuccessfulCreate 4s job-controller Created pod: indexed-job-njkjj + Normal SuccessfulCreate 4s job-controller Created pod: indexed-job-9kd4h + Normal SuccessfulCreate 4s job-controller Created pod: indexed-job-qjwsz + Normal SuccessfulCreate 1s job-controller Created pod: indexed-job-fdhq5 + Normal SuccessfulCreate 1s job-controller Created pod: indexed-job-ncslj +``` + +In this example, you run the Job with custom values for each index. You can +inspect the output of one of the pods: + +```shell +kubectl logs indexed-job-fdhq5 # Change this to match the name of a Pod from that Job +``` + + +The output is similar to: + +``` +xuq +``` \ No newline at end of file From 17f688f533e0aba1fc86752fa7ef121b90010184 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Sat, 24 Apr 2021 13:45:35 +0000 Subject: [PATCH 012/128] Add two new example files --- .../application/job/indexed-job-vol.yaml | 27 ++++++++++++++ .../examples/application/job/indexed-job.yaml | 35 +++++++++++++++++++ 2 files changed, 62 insertions(+) create mode 100644 content/ja/examples/application/job/indexed-job-vol.yaml create mode 100644 content/ja/examples/application/job/indexed-job.yaml diff --git a/content/ja/examples/application/job/indexed-job-vol.yaml b/content/ja/examples/application/job/indexed-job-vol.yaml new file mode 100644 index 0000000000..ed40e1cc44 --- /dev/null +++ b/content/ja/examples/application/job/indexed-job-vol.yaml @@ -0,0 +1,27 @@ +apiVersion: batch/v1 +kind: Job +metadata: + name: 'indexed-job' +spec: + completions: 5 + parallelism: 3 + completionMode: Indexed + template: + spec: + restartPolicy: Never + containers: + - name: 'worker' + image: 'docker.io/library/busybox' + command: + - "rev" + - "/input/data.txt" + volumeMounts: + - mountPath: /input + name: input + volumes: + - name: input + downwardAPI: + items: + - path: "data.txt" + fieldRef: + fieldPath: metadata.annotations['batch.kubernetes.io/job-completion-index'] \ No newline at end of file diff --git a/content/ja/examples/application/job/indexed-job.yaml b/content/ja/examples/application/job/indexed-job.yaml new file mode 100644 index 0000000000..5b80d35264 --- /dev/null +++ b/content/ja/examples/application/job/indexed-job.yaml @@ -0,0 +1,35 @@ +apiVersion: batch/v1 +kind: Job +metadata: + name: 'indexed-job' +spec: + completions: 5 + parallelism: 3 + completionMode: Indexed + template: + spec: + restartPolicy: Never + initContainers: + - name: 'input' + image: 'docker.io/library/bash' + command: + - "bash" + - "-c" + - | + items=(foo bar baz qux xyz) + echo ${items[$JOB_COMPLETION_INDEX]} > /input/data.txt + volumeMounts: + - mountPath: /input + name: input + containers: + - name: 'worker' + image: 'docker.io/library/busybox' + command: + - "rev" + - "/input/data.txt" + volumeMounts: + - mountPath: /input + name: input + volumes: + - name: input + emptyDir: {} From 1e3a357f470f04293692fa503ce7f1cf84632be3 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Sat, 24 Apr 2021 13:46:00 +0000 Subject: [PATCH 013/128] Translate tasks/job/indexed-parallel-processing-static into Japanese --- .../job/indexed-parallel-processing-static.md | 103 +++++------------- 1 file changed, 30 insertions(+), 73 deletions(-) diff --git a/content/ja/docs/tasks/job/indexed-parallel-processing-static.md b/content/ja/docs/tasks/job/indexed-parallel-processing-static.md index b5492eed6e..3e92433476 100644 --- a/content/ja/docs/tasks/job/indexed-parallel-processing-static.md +++ b/content/ja/docs/tasks/job/indexed-parallel-processing-static.md @@ -1,5 +1,5 @@ --- -title: Indexed Job for Parallel Processing with Static Work Assignment +title: 静的な処理の割り当てを使用した並列処理のためのインデックス付きJob content_type: task min-kubernetes-server-version: v1.21 weight: 30 @@ -9,116 +9,75 @@ weight: 30 +この例では、複数の並列ワーカープロセスを使用するKubernetesのJobを実行します。各ワーカーは、それぞれが自分のPod内で実行される異なるコンテナです。Podはコントロールプレーンが自動的に設定する*インデックス値*を持ち、この値を利用することで、各Podは処理するタスク全体のどの部分を処理するのかを特定できます。 -In this example, you will run a Kubernetes Job that uses multiple parallel -worker processes. -Each worker is a different container running in its own Pod. The Pods have an -_index number_ that the control plane sets automatically, which allows each Pod -to identify which part of the overall task to work on. +Podのインデックスは、{{< glossary_tooltip text="アノテーション" term_id="annotation" >}}内の`batch.kubernetes.io/job-completion-index`を整数値の文字列表現としてで利用できます。コンテナ化されたタスクプロセスがこのインデックスを取得できるようにするために、このアノテーションの値は[downward API](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#the-downward-api)の仕組みを利用することで公開できます。利便性のために、コントロールプレーンは自動的にdownward APIを設定して、`JOB_COMPLETION_INDEX`環境変数内のインデックスを公開してくれます。 -The pod index is available in the {{< glossary_tooltip text="annotation" term_id="annotation" >}} -`batch.kubernetes.io/job-completion-index` as a string representing its -decimal value. In order for the containerized task process to obtain this index, -you can publish the value of the annotation using the [downward API](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#the-downward-api) -mechanism. -For convenience, the control plane automatically sets the downward API to -expose the index in the `JOB_COMPLETION_INDEX` environment variable. +以下に、この例で実行するステップの概要を示します。 -Here is an overview of the steps in this example: - -1. **Define a Job manifest using indexed completion**. - The downward API allows you to pass the pod index annotation as an - environment variable or file to the container. -2. **Start an `Indexed` Job based on that manifest**. +1. **completionのインデックスを使用してJobのマニフェストを定義する**。downward APIはPodのインデックスのアノテーションを環境変数またはファイルとしてコンテナに渡してくれます。 +2. **そのマニフェストに基づいてインデックス付き(Indexed)のJobを開始する**。 ## {{% heading "prerequisites" %}} -You should already be familiar with the basic, -non-parallel, use of [Job](/docs/concepts/workloads/controllers/job/). +あらかじめ基本的な非並列の[Job](/docs/concepts/workloads/controllers/job/)の使用に慣れている必要があります。 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -To be able to create Indexed Jobs, make sure to enable the `IndexedJob` -[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) -on the [API server](/docs/reference/command-line-tools-reference/kube-apiserver/) -and the [controller manager](/docs/reference/command-line-tools-reference/kube-controller-manager/). +インデックス付きJobを作成できるようにするには、[APIサーバー](/docs/reference/command-line-tools-reference/kube-apiserver/)と[コントローラーマネージャー](/docs/reference/command-line-tools-reference/kube-controller-manager/)上で`IndexedJob`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にしていることを確認してください。 -## Choose an approach +## アプローチを選択する -To access the work item from the worker program, you have a few options: +ワーカープログラムから処理アイテムにアクセスするには、いくつかの選択肢があります。 -1. Read the `JOB_COMPLETION_INDEX` environment variable. The Job - {{< glossary_tooltip text="controller" term_id="controller" >}} - automatically links this variable to the annotation containing the completion - index. -1. Read a file that contains the completion index. -1. Assuming that you can't modify the program, you can wrap it with a script - that reads the index using any of the methods above and converts it into - something that the program can use as input. +1. `JOB_COMPLETION_INDEX`環境変数を読み込む。Job{{< glossary_tooltip text="コントローラー" term_id="controller" >}}は、この変数をcompletion indexを含むアノテーションに自動的にリンクします。 +1. completion indexを含むファイルを読み込む。 +1. プログラムを修正できない場合、プログラムをスクリプトでラップし、上のいずれかの方法でインデックスを読み取り、プログラムが入力として使用できるものに変換する。 -For this example, imagine that you chose option 3 and you want to run the -[rev](https://man7.org/linux/man-pages/man1/rev.1.html) utility. This -program accepts a file as an argument and prints its content reversed. +この例では、3番目のオプションを選択肢して、[rev](https://man7.org/linux/man-pages/man1/rev.1.html)ユーティリティを実行したいと考えているとしましょう。このプログラムはファイルを引数として受け取り、内容を逆さまに表示します。 ```shell rev data.txt ``` -You'll use the `rev` tool from the -[`busybox`](https://hub.docker.com/_/busybox) container image. +`rev`ツールは[`busybox`](https://hub.docker.com/_/busybox)コンテナイメージから利用できます。 -As this is only an example, each Pod only does a tiny piece of work (reversing a short -string). In a real workload you might, for example, create a Job that represents - the -task of producing 60 seconds of video based on scene data. -Each work item in the video rendering Job would be to render a particular -frame of that video clip. Indexed completion would mean that each Pod in -the Job knows which frame to render and publish, by counting frames from -the start of the clip. +これは単なる例であるため、各Podはごく簡単な処理(短い文字列を逆にする)をするだけです。現実のワークロードでは、たとえば、シーンデータをもとに60秒の動画を生成するというようなタスクを記述したJobを作成するかもしれません。ビデオレンダリングJobの各処理アイテムは、ビデオクリップの特定のフレームのレンダリングを行うものになるでしょう。その場合、インデックス付きの完了が意味するのは、クリップの最初からフレームをカウントすることで、Job内の各Podがレンダリングと公開をするのがどのフレームであるかがわかるということです。 -## Define an Indexed Job +## インデックス付きJobを定義する -Here is a sample Job manifest that uses `Indexed` completion mode: +以下は、completion modeとして`Indexed`を使用するJobのマニフェストの例です。 {{< codenew language="yaml" file="application/job/indexed-job.yaml" >}} -In the example above, you use the builtin `JOB_COMPLETION_INDEX` environment -variable set by the Job controller for all containers. An [init container](/docs/concepts/workloads/pods/init-containers/) -maps the index to a static value and writes it to a file that is shared with the -container running the worker through an [emptyDir volume](/docs/concepts/storage/volumes/#emptydir). -Optionally, you can [define your own environment variable through the downward -API](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/) -to publish the index to containers. You can also choose to load a list of values -from a [ConfigMap as an environment variable or file](/docs/tasks/configure-pod-container/configure-pod-configmap/). +上記の例では、Jobコントローラーがすべてのコンテナに設定する組み込みの`JOB_COMPLETION_INDEX`環境変数を使っています。[initコンテナ](/ja/docs/concepts/workloads/pods/init-containers/)がインデックスを静的な値にマッピングし、その値をファイルに書き込み、ファイルを[emptyDir volume](/docs/concepts/storage/volumes/#emptydir)を介してワーカーを実行しているコンテナと共有します。オプションとして、インデックスとコンテナに公開するために[downward APIを使用して独自の環境変数を定義する](/ja/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)こともできます。[環境変数やファイルとして設定したConfigMap](/ja/docs/tasks/configure-pod-container/configure-pod-configmap/)から値のリストを読み込むという選択肢もあります。 -Alternatively, you can directly [use the downward API to pass the annotation -value as a volume file](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#store-pod-fields), -like shown in the following example: +他には、以下の例のように、直接[downward APIを使用してアノテーションの値をボリュームファイルとして渡す](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#store-pod-fields)こともできます。 {{< codenew language="yaml" file="application/job/indexed-job-vol.yaml" >}} -## Running the Job +## Jobを実行する -Now run the Job: +次のコマンドでJobを実行します。 ```shell -# This uses the first approach (relying on $JOB_COMPLETION_INDEX) +# このコマンドでは1番目のアプローチを使っています ($JOB_COMPLETION_INDEX に依存しています) kubectl apply -f https://kubernetes.io/examples/application/job/indexed-job.yaml ``` -When you create this Job, the control plane creates a series of Pods, one for each index you specified. The value of `.spec.parallelism` determines how many can run at once whereas `.spec.completions` determines how many Pods the Job creates in total. +このJobを作成したら、コントロールプレーンは指定した各インデックスごとに一連のPodを作成します。`.spec.parallelism`の値が同時に実行できるPodの数を決定し、`.spec.completions`の値がJobが作成するPodの合計数を決定します。 -Because `.spec.parallelism` is less than `.spec.completions`, the control plane waits for some of the first Pods to complete before starting more of them. +`.spec.parallelism`は`.spec.completions`より小さいため、コントロールプレーンは別のPodを開始する前に最初のPodの一部が完了するまで待機します。 -Once you have created the Job, wait a moment then check on progress: +Jobを作成したら、少し待ってから進行状況を確認します。 ```shell kubectl describe jobs/indexed-job ``` -The output is similar to: +出力は次のようになります。 ``` Name: indexed-job @@ -175,15 +134,13 @@ Events: Normal SuccessfulCreate 1s job-controller Created pod: indexed-job-ncslj ``` -In this example, you run the Job with custom values for each index. You can -inspect the output of one of the pods: +この例では、各インデックスごとにカスタムの値を使用してJobを実行します。次のコマンドでPodの1つの出力を確認できます。 ```shell -kubectl logs indexed-job-fdhq5 # Change this to match the name of a Pod from that Job +kubectl logs indexed-job-fdhq5 # これを対象のJobのPodの名前に一致するように変更してください。 ``` - -The output is similar to: +出力は次のようになります。 ``` xuq From fe2e63d8e86180d8e995eec43dad199d45ecb1ad Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Tue, 27 Apr 2021 11:17:35 +0000 Subject: [PATCH 014/128] Copy content/ja/docs/tasks/network/{_index,validate-dual-stack}.md --- content/ja/docs/tasks/network/_index.md | 6 + .../docs/tasks/network/validate-dual-stack.md | 237 ++++++++++++++++++ 2 files changed, 243 insertions(+) create mode 100755 content/ja/docs/tasks/network/_index.md create mode 100644 content/ja/docs/tasks/network/validate-dual-stack.md diff --git a/content/ja/docs/tasks/network/_index.md b/content/ja/docs/tasks/network/_index.md new file mode 100755 index 0000000000..0dad8191a0 --- /dev/null +++ b/content/ja/docs/tasks/network/_index.md @@ -0,0 +1,6 @@ +--- +title: "Networking" +description: Learn how to configure networking for your cluster. +weight: 160 +--- + diff --git a/content/ja/docs/tasks/network/validate-dual-stack.md b/content/ja/docs/tasks/network/validate-dual-stack.md new file mode 100644 index 0000000000..bc90dea4ea --- /dev/null +++ b/content/ja/docs/tasks/network/validate-dual-stack.md @@ -0,0 +1,237 @@ +--- +reviewers: +- lachie83 +- khenidak +- bridgetkromhout +min-kubernetes-server-version: v1.20 +title: Validate IPv4/IPv6 dual-stack +content_type: task +--- + + +This document shares how to validate IPv4/IPv6 dual-stack enabled Kubernetes clusters. + + +## {{% heading "prerequisites" %}} + + +* Provider support for dual-stack networking (Cloud provider or otherwise must be able to provide Kubernetes nodes with routable IPv4/IPv6 network interfaces) +* A [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) that supports dual-stack (such as Kubenet or Calico) +* [Dual-stack enabled](/docs/concepts/services-networking/dual-stack/) cluster + +{{< version-check >}} + + + + + +## Validate addressing + +### Validate node addressing + +Each dual-stack Node should have a single IPv4 block and a single IPv6 block allocated. Validate that IPv4/IPv6 Pod address ranges are configured by running the following command. Replace the sample node name with a valid dual-stack Node from your cluster. In this example, the Node's name is `k8s-linuxpool1-34450317-0`: + +```shell +kubectl get nodes k8s-linuxpool1-34450317-0 -o go-template --template='{{range .spec.podCIDRs}}{{printf "%s\n" .}}{{end}}' +``` +``` +10.244.1.0/24 +a00:100::/24 +``` +There should be one IPv4 block and one IPv6 block allocated. + +Validate that the node has an IPv4 and IPv6 interface detected. Replace node name with a valid node from the cluster. In this example the node name is `k8s-linuxpool1-34450317-0`: + +```shell +kubectl get nodes k8s-linuxpool1-34450317-0 -o go-template --template='{{range .status.addresses}}{{printf "%s: %s\n" .type .address}}{{end}}' +``` +``` +Hostname: k8s-linuxpool1-34450317-0 +InternalIP: 10.240.0.5 +InternalIP: 2001:1234:5678:9abc::5 +``` + +### Validate Pod addressing + +Validate that a Pod has an IPv4 and IPv6 address assigned. Replace the Pod name with a valid Pod in your cluster. In this example the Pod name is `pod01`: + +```shell +kubectl get pods pod01 -o go-template --template='{{range .status.podIPs}}{{printf "%s\n" .ip}}{{end}}' +``` +``` +10.244.1.4 +a00:100::4 +``` + +You can also validate Pod IPs using the Downward API via the `status.podIPs` fieldPath. The following snippet demonstrates how you can expose the Pod IPs via an environment variable called `MY_POD_IPS` within a container. + +``` + env: + - name: MY_POD_IPS + valueFrom: + fieldRef: + fieldPath: status.podIPs +``` + +The following command prints the value of the `MY_POD_IPS` environment variable from within a container. The value is a comma separated list that corresponds to the Pod's IPv4 and IPv6 addresses. + +```shell +kubectl exec -it pod01 -- set | grep MY_POD_IPS +``` +``` +MY_POD_IPS=10.244.1.4,a00:100::4 +``` + +The Pod's IP addresses will also be written to `/etc/hosts` within a container. The following command executes a cat on `/etc/hosts` on a dual stack Pod. From the output you can verify both the IPv4 and IPv6 IP address for the Pod. + +```shell +kubectl exec -it pod01 -- cat /etc/hosts +``` +``` +# Kubernetes-managed hosts file. +127.0.0.1 localhost +::1 localhost ip6-localhost ip6-loopback +fe00::0 ip6-localnet +fe00::0 ip6-mcastprefix +fe00::1 ip6-allnodes +fe00::2 ip6-allrouters +10.244.1.4 pod01 +a00:100::4 pod01 +``` + +## Validate Services + +Create the following Service that does not explicitly define `.spec.ipFamilyPolicy`. Kubernetes will assign a cluster IP for the Service from the first configured `service-cluster-ip-range` and set the `.spec.ipFamilyPolicy` to `SingleStack`. + +{{< codenew file="service/networking/dual-stack-default-svc.yaml" >}} + +Use `kubectl` to view the YAML for the Service. + +```shell +kubectl get svc my-service -o yaml +``` + +The Service has `.spec.ipFamilyPolicy` set to `SingleStack` and `.spec.clusterIP` set to an IPv4 address from the first configured range set via `--service-cluster-ip-range` flag on kube-controller-manager. + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: my-service + namespace: default +spec: + clusterIP: 10.0.217.164 + clusterIPs: + - 10.0.217.164 + ipFamilies: + - IPv4 + ipFamilyPolicy: SingleStack + ports: + - port: 80 + protocol: TCP + targetPort: 9376 + selector: + app: MyApp + sessionAffinity: None + type: ClusterIP +status: + loadBalancer: {} +``` + +Create the following Service that explicitly defines `IPv6` as the first array element in `.spec.ipFamilies`. Kubernetes will assign a cluster IP for the Service from the IPv6 range configured `service-cluster-ip-range` and set the `.spec.ipFamilyPolicy` to `SingleStack`. + +{{< codenew file="service/networking/dual-stack-ipfamilies-ipv6.yaml" >}} + +Use `kubectl` to view the YAML for the Service. + +```shell +kubectl get svc my-service -o yaml +``` + +The Service has `.spec.ipFamilyPolicy` set to `SingleStack` and `.spec.clusterIP` set to an IPv6 address from the IPv6 range set via `--service-cluster-ip-range` flag on kube-controller-manager. + +```yaml +apiVersion: v1 +kind: Service +metadata: + labels: + app: MyApp + name: my-service +spec: + clusterIP: fd00::5118 + clusterIPs: + - fd00::5118 + ipFamilies: + - IPv6 + ipFamilyPolicy: SingleStack + ports: + - port: 80 + protocol: TCP + targetPort: 80 + selector: + app: MyApp + sessionAffinity: None + type: ClusterIP +status: + loadBalancer: {} +``` + +Create the following Service that explicitly defines `PreferDualStack` in `.spec.ipFamilyPolicy`. Kubernetes will assign both IPv4 and IPv6 addresses (as this cluster has dual-stack enabled) and select the `.spec.ClusterIP` from the list of `.spec.ClusterIPs` based on the address family of the first element in the `.spec.ipFamilies` array. + +{{< codenew file="service/networking/dual-stack-preferred-svc.yaml" >}} + +{{< note >}} +The `kubectl get svc` command will only show the primary IP in the `CLUSTER-IP` field. + +```shell +kubectl get svc -l app=MyApp + +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +my-service ClusterIP 10.0.216.242 80/TCP 5s +``` +{{< /note >}} + +Validate that the Service gets cluster IPs from the IPv4 and IPv6 address blocks using `kubectl describe`. You may then validate access to the service via the IPs and ports. + +```shell +kubectl describe svc -l app=MyApp +``` + +``` +Name: my-service +Namespace: default +Labels: app=MyApp +Annotations: +Selector: app=MyApp +Type: ClusterIP +IP Family Policy: PreferDualStack +IP Families: IPv4,IPv6 +IP: 10.0.216.242 +IPs: 10.0.216.242,fd00::af55 +Port: 80/TCP +TargetPort: 9376/TCP +Endpoints: +Session Affinity: None +Events: +``` + +### Create a dual-stack load balanced Service + +If the cloud provider supports the provisioning of IPv6 enabled external load balancers, create the following Service with `PreferDualStack` in `.spec.ipFamilyPolicy`, `IPv6` as the first element of the `.spec.ipFamilies` array and the `type` field set to `LoadBalancer`. + +{{< codenew file="service/networking/dual-stack-prefer-ipv6-lb-svc.yaml" >}} + +Check the Service: + +```shell +kubectl get svc -l app=MyApp +``` + +Validate that the Service receives a `CLUSTER-IP` address from the IPv6 address block along with an `EXTERNAL-IP`. You may then validate access to the service via the IP and port. + +```shell +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +my-service LoadBalancer fd00::7ebc 2603:1030:805::5 80:30790/TCP 35s +``` + + From 074cc20ce3fbab51aef59f2de6bb853e4ac90651 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Tue, 27 Apr 2021 11:17:35 +0000 Subject: [PATCH 015/128] Update example YAML files --- .../networking/dual-stack-default-svc.yaml | 3 ++- .../networking/dual-stack-ipfamilies-ipv6.yaml | 14 ++++++++++++++ .../dual-stack-prefer-ipv6-lb-svc.yaml | 16 ++++++++++++++++ .../dual-stack-preferred-ipfamilies-svc.yaml | 16 ++++++++++++++++ .../networking/dual-stack-preferred-svc.yaml | 13 +++++++++++++ 5 files changed, 61 insertions(+), 1 deletion(-) create mode 100644 content/ja/examples/service/networking/dual-stack-ipfamilies-ipv6.yaml create mode 100644 content/ja/examples/service/networking/dual-stack-prefer-ipv6-lb-svc.yaml create mode 100644 content/ja/examples/service/networking/dual-stack-preferred-ipfamilies-svc.yaml create mode 100644 content/ja/examples/service/networking/dual-stack-preferred-svc.yaml diff --git a/content/ja/examples/service/networking/dual-stack-default-svc.yaml b/content/ja/examples/service/networking/dual-stack-default-svc.yaml index 00ed87ba19..86eadd5478 100644 --- a/content/ja/examples/service/networking/dual-stack-default-svc.yaml +++ b/content/ja/examples/service/networking/dual-stack-default-svc.yaml @@ -2,10 +2,11 @@ apiVersion: v1 kind: Service metadata: name: my-service + labels: + app: MyApp spec: selector: app: MyApp ports: - protocol: TCP port: 80 - targetPort: 9376 \ No newline at end of file diff --git a/content/ja/examples/service/networking/dual-stack-ipfamilies-ipv6.yaml b/content/ja/examples/service/networking/dual-stack-ipfamilies-ipv6.yaml new file mode 100644 index 0000000000..7c7239cae6 --- /dev/null +++ b/content/ja/examples/service/networking/dual-stack-ipfamilies-ipv6.yaml @@ -0,0 +1,14 @@ +apiVersion: v1 +kind: Service +metadata: + name: my-service + labels: + app: MyApp +spec: + ipFamilies: + - IPv6 + selector: + app: MyApp + ports: + - protocol: TCP + port: 80 diff --git a/content/ja/examples/service/networking/dual-stack-prefer-ipv6-lb-svc.yaml b/content/ja/examples/service/networking/dual-stack-prefer-ipv6-lb-svc.yaml new file mode 100644 index 0000000000..0949a75428 --- /dev/null +++ b/content/ja/examples/service/networking/dual-stack-prefer-ipv6-lb-svc.yaml @@ -0,0 +1,16 @@ +apiVersion: v1 +kind: Service +metadata: + name: my-service + labels: + app: MyApp +spec: + ipFamilyPolicy: PreferDualStack + ipFamilies: + - IPv6 + type: LoadBalancer + selector: + app: MyApp + ports: + - protocol: TCP + port: 80 diff --git a/content/ja/examples/service/networking/dual-stack-preferred-ipfamilies-svc.yaml b/content/ja/examples/service/networking/dual-stack-preferred-ipfamilies-svc.yaml new file mode 100644 index 0000000000..c31acfec58 --- /dev/null +++ b/content/ja/examples/service/networking/dual-stack-preferred-ipfamilies-svc.yaml @@ -0,0 +1,16 @@ +apiVersion: v1 +kind: Service +metadata: + name: my-service + labels: + app: MyApp +spec: + ipFamilyPolicy: PreferDualStack + ipFamilies: + - IPv6 + - IPv4 + selector: + app: MyApp + ports: + - protocol: TCP + port: 80 diff --git a/content/ja/examples/service/networking/dual-stack-preferred-svc.yaml b/content/ja/examples/service/networking/dual-stack-preferred-svc.yaml new file mode 100644 index 0000000000..8fb5bfa3d3 --- /dev/null +++ b/content/ja/examples/service/networking/dual-stack-preferred-svc.yaml @@ -0,0 +1,13 @@ +apiVersion: v1 +kind: Service +metadata: + name: my-service + labels: + app: MyApp +spec: + ipFamilyPolicy: PreferDualStack + selector: + app: MyApp + ports: + - protocol: TCP + port: 80 From 553e907708fb02d6102e4d61ef4b1b8f7506071e Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Tue, 27 Apr 2021 11:17:35 +0000 Subject: [PATCH 016/128] Translate _index.md --- content/ja/docs/tasks/network/_index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/tasks/network/_index.md b/content/ja/docs/tasks/network/_index.md index 0dad8191a0..1d5796f7b7 100755 --- a/content/ja/docs/tasks/network/_index.md +++ b/content/ja/docs/tasks/network/_index.md @@ -1,6 +1,6 @@ --- -title: "Networking" -description: Learn how to configure networking for your cluster. +title: "ネットワーク" +description: クラスターのネットワークの設定方法を学びます。 weight: 160 --- From 68033869bf33f42a304d61fd946d84332046ba5e Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Tue, 27 Apr 2021 11:17:35 +0000 Subject: [PATCH 017/128] Translate tasks/network/validate-dual-stack into japanese --- .../docs/tasks/network/validate-dual-stack.md | 65 +++++++++---------- 1 file changed, 30 insertions(+), 35 deletions(-) diff --git a/content/ja/docs/tasks/network/validate-dual-stack.md b/content/ja/docs/tasks/network/validate-dual-stack.md index bc90dea4ea..ef8aaadf01 100644 --- a/content/ja/docs/tasks/network/validate-dual-stack.md +++ b/content/ja/docs/tasks/network/validate-dual-stack.md @@ -1,23 +1,19 @@ --- -reviewers: -- lachie83 -- khenidak -- bridgetkromhout min-kubernetes-server-version: v1.20 -title: Validate IPv4/IPv6 dual-stack +title: IPv4/IPv6デュアルスタックの検証 content_type: task --- -This document shares how to validate IPv4/IPv6 dual-stack enabled Kubernetes clusters. +このドキュメントでは、IPv4/IPv6デュアルスタックが有効化されたKubernetesクラスターを検証する方法について共有します。 ## {{% heading "prerequisites" %}} -* Provider support for dual-stack networking (Cloud provider or otherwise must be able to provide Kubernetes nodes with routable IPv4/IPv6 network interfaces) -* A [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) that supports dual-stack (such as Kubenet or Calico) -* [Dual-stack enabled](/docs/concepts/services-networking/dual-stack/) cluster +* プロバイダーがデュアルスタックのネットワークをサポートしていること (クラウドプロバイダーか、ルーティングできるIPv4/IPv6ネットワークインターフェイスを持つKubernetesノードが提供できること) +* (KubenetやCalicoなど)デュアルスタックをサポートする[ネットワークプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) +* [デュアルスタックを有効化](/ja/docs/concepts/services-networking/dual-stack/)したクラスター {{< version-check >}} @@ -25,11 +21,11 @@ This document shares how to validate IPv4/IPv6 dual-stack enabled Kubernetes clu -## Validate addressing +## アドレスの検証 -### Validate node addressing +### ノードアドレスの検証 -Each dual-stack Node should have a single IPv4 block and a single IPv6 block allocated. Validate that IPv4/IPv6 Pod address ranges are configured by running the following command. Replace the sample node name with a valid dual-stack Node from your cluster. In this example, the Node's name is `k8s-linuxpool1-34450317-0`: +各デュアルスタックのノードは、1つのIPv4ブロックと1つのIPv6ブロックを割り当てる必要があります。IPv4/IPv6のPodアドレスの範囲が設定されていることを検証するには、次のコマンドを実行します。例の中のノード名は、自分のクラスターの有効なデュアルスタックのノードの名前に置換してください。この例では、ノードの名前は`k8s-linuxpool1-34450317-0`になっています。 ```shell kubectl get nodes k8s-linuxpool1-34450317-0 -o go-template --template='{{range .spec.podCIDRs}}{{printf "%s\n" .}}{{end}}' @@ -38,9 +34,10 @@ kubectl get nodes k8s-linuxpool1-34450317-0 -o go-template --template='{{range . 10.244.1.0/24 a00:100::/24 ``` -There should be one IPv4 block and one IPv6 block allocated. -Validate that the node has an IPv4 and IPv6 interface detected. Replace node name with a valid node from the cluster. In this example the node name is `k8s-linuxpool1-34450317-0`: +IPv4ブロックとIPv6ブロックがそれぞれ1つずつ割り当てられているはずです。 + +ノードが検出されたIPv4とIPv6のインターフェイスを持っていることを検証します。ノード名は自分のクラスター内の有効なノード名に置換してください。この例では、ノード名は`k8s-linuxpool1-34450317-0`になっています。 ```shell kubectl get nodes k8s-linuxpool1-34450317-0 -o go-template --template='{{range .status.addresses}}{{printf "%s: %s\n" .type .address}}{{end}}' @@ -51,9 +48,9 @@ InternalIP: 10.240.0.5 InternalIP: 2001:1234:5678:9abc::5 ``` -### Validate Pod addressing +### Podアドレスの検証 -Validate that a Pod has an IPv4 and IPv6 address assigned. Replace the Pod name with a valid Pod in your cluster. In this example the Pod name is `pod01`: +PodにIPv4とIPv6のアドレスが割り当てられていることを検証します。Podの名前は自分のクラスター内の有効なPodの名前と置換してください。この例では、Podの名前は`pod01`になっています。 ```shell kubectl get pods pod01 -o go-template --template='{{range .status.podIPs}}{{printf "%s\n" .ip}}{{end}}' @@ -63,7 +60,7 @@ kubectl get pods pod01 -o go-template --template='{{range .status.podIPs}}{{prin a00:100::4 ``` -You can also validate Pod IPs using the Downward API via the `status.podIPs` fieldPath. The following snippet demonstrates how you can expose the Pod IPs via an environment variable called `MY_POD_IPS` within a container. +Downward APIを使用して、`status.podIPs`のfieldPath経由でPod IPを検証することもできます。次のスニペットは、Pod IPを`MY_POD_IPS`という名前の環境変数経由でコンテナ内に公開する方法を示しています。 ``` env: @@ -73,7 +70,7 @@ You can also validate Pod IPs using the Downward API via the `status.podIPs` fie fieldPath: status.podIPs ``` -The following command prints the value of the `MY_POD_IPS` environment variable from within a container. The value is a comma separated list that corresponds to the Pod's IPv4 and IPv6 addresses. +次のコマンドを実行すると、`MY_POD_IPS`環境変数の値をコンテナ内から表示できます。値はカンマ区切りのリストであり、PodのIPv4とIPv6のアドレスに対応しています。 ```shell kubectl exec -it pod01 -- set | grep MY_POD_IPS @@ -82,7 +79,7 @@ kubectl exec -it pod01 -- set | grep MY_POD_IPS MY_POD_IPS=10.244.1.4,a00:100::4 ``` -The Pod's IP addresses will also be written to `/etc/hosts` within a container. The following command executes a cat on `/etc/hosts` on a dual stack Pod. From the output you can verify both the IPv4 and IPv6 IP address for the Pod. +PodのIPアドレスは、コンテナ内の`/etc/hosts`にも書き込まれます。次のコマンドは、デュアルスタックのPod上で`/etc/hosts`に対してcatコマンドを実行します。出力を見ると、Pod用のIPv4およびIPv6のIPアドレスの両方が確認できます。 ```shell kubectl exec -it pod01 -- cat /etc/hosts @@ -99,19 +96,19 @@ fe00::2 ip6-allrouters a00:100::4 pod01 ``` -## Validate Services +## Serviceの検証 -Create the following Service that does not explicitly define `.spec.ipFamilyPolicy`. Kubernetes will assign a cluster IP for the Service from the first configured `service-cluster-ip-range` and set the `.spec.ipFamilyPolicy` to `SingleStack`. +`.spec.isFamilyPolicy`を明示的に定義していない、以下のようなServiceを作成してみます。Kubernetesは最初に設定した`service-cluster-ip-range`の範囲からServiceにcluster IPを割り当てて、`.spec.ipFamilyPolicy`を`SingleStack`に設定します。 {{< codenew file="service/networking/dual-stack-default-svc.yaml" >}} -Use `kubectl` to view the YAML for the Service. +`kubectl`を使ってServiceのYAMLを表示します。 ```shell kubectl get svc my-service -o yaml ``` -The Service has `.spec.ipFamilyPolicy` set to `SingleStack` and `.spec.clusterIP` set to an IPv4 address from the first configured range set via `--service-cluster-ip-range` flag on kube-controller-manager. +Serviceの`.spec.ipFamilyPolicy`は`SingleStack`に設定され、`.spec.clusterIP`にはkube-controller-manager上の`--service-cluster-ip-range`フラグで最初に設定した範囲から1つのIPv4アドレスが設定されているのがわかります。 ```yaml apiVersion: v1 @@ -138,17 +135,17 @@ status: loadBalancer: {} ``` -Create the following Service that explicitly defines `IPv6` as the first array element in `.spec.ipFamilies`. Kubernetes will assign a cluster IP for the Service from the IPv6 range configured `service-cluster-ip-range` and set the `.spec.ipFamilyPolicy` to `SingleStack`. +`.spec.ipFamilies`内の配列の1番目の要素に`IPv6`を明示的に指定した、次のようなServiceを作成してみます。Kubernetesは`service-cluster-ip-range`で設定したIPv6の範囲からcluster IPを割り当てて、`.spec.ipFamilyPolicy`を`SingleStack`に設定します。 {{< codenew file="service/networking/dual-stack-ipfamilies-ipv6.yaml" >}} -Use `kubectl` to view the YAML for the Service. +`kubectl`を使ってServiceのYAMLを表示します。 ```shell kubectl get svc my-service -o yaml ``` -The Service has `.spec.ipFamilyPolicy` set to `SingleStack` and `.spec.clusterIP` set to an IPv6 address from the IPv6 range set via `--service-cluster-ip-range` flag on kube-controller-manager. +Serviceの`.spec.ipFamilyPolicy`は`SingleStack`に設定され、`.spec.clusterIP`には、kube-controller-manager上の`--service-cluster-ip-range`フラグで指定された最初の設定範囲から1つのIPv6アドレスが設定されているのがわかります。 ```yaml apiVersion: v1 @@ -176,12 +173,12 @@ status: loadBalancer: {} ``` -Create the following Service that explicitly defines `PreferDualStack` in `.spec.ipFamilyPolicy`. Kubernetes will assign both IPv4 and IPv6 addresses (as this cluster has dual-stack enabled) and select the `.spec.ClusterIP` from the list of `.spec.ClusterIPs` based on the address family of the first element in the `.spec.ipFamilies` array. +`.spec.ipFamiliePolicy`に`PreferDualStack`を明示的に指定した、次のようなServiceを作成してみます。Kubernetesは(クラスターでデュアルスタックを有効化しているため)IPv4およびIPv6のアドレスの両方を割り当て、`.spec.ClusterIPs`のリストから、`.spec.ipFamilies`配列の最初の要素のアドレスファミリーに基づいた`.spec.ClusterIP`を設定します。 {{< codenew file="service/networking/dual-stack-preferred-svc.yaml" >}} {{< note >}} -The `kubectl get svc` command will only show the primary IP in the `CLUSTER-IP` field. +`kubectl get svc`コマンドは、`CLUSTER-IP`フィールドにプライマリーのIPだけしか表示しません。 ```shell kubectl get svc -l app=MyApp @@ -191,7 +188,7 @@ my-service ClusterIP 10.0.216.242 80/TCP 5s ``` {{< /note >}} -Validate that the Service gets cluster IPs from the IPv4 and IPv6 address blocks using `kubectl describe`. You may then validate access to the service via the IPs and ports. +`kubectl describe`を使用して、ServiceがIPv4およびIPv6アドレスのブロックからcluster IPを割り当てられていることを検証します。その後、ServiceにIPアドレスとポートを使用してアクセスできることを検証することもできます。 ```shell kubectl describe svc -l app=MyApp @@ -215,23 +212,21 @@ Session Affinity: None Events: ``` -### Create a dual-stack load balanced Service +### デュアルスタックのLoadBalancer Serviceを作成する -If the cloud provider supports the provisioning of IPv6 enabled external load balancers, create the following Service with `PreferDualStack` in `.spec.ipFamilyPolicy`, `IPv6` as the first element of the `.spec.ipFamilies` array and the `type` field set to `LoadBalancer`. +クラウドプロバイダーがIPv6を有効化した外部ロードバランサーのプロビジョニングをサポートする場合、`.spec.ipFamilyPolicy`に`PreferDualStack`を指定し、`.spec.ipFamilies`の最初の要素を`IPv6`にして、`type`フィールドに`LoadBalancer`を指定したServiceを作成できます。 {{< codenew file="service/networking/dual-stack-prefer-ipv6-lb-svc.yaml" >}} -Check the Service: +Serviceを確認します。 ```shell kubectl get svc -l app=MyApp ``` -Validate that the Service receives a `CLUSTER-IP` address from the IPv6 address block along with an `EXTERNAL-IP`. You may then validate access to the service via the IP and port. +ServiceがIPv6アドレスブロックから`CLUSTER-IP`のアドレスと`EXTERNAL-IP`を割り当てられていることを検証します。その後、IPとポートを用いたServiceへのアクセスを検証することもできます。 ```shell NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE my-service LoadBalancer fd00::7ebc 2603:1030:805::5 80:30790/TCP 35s ``` - - From 5eeff70c00c734bb52a68f893af2e0a313973062 Mon Sep 17 00:00:00 2001 From: lmx-Hexagram <52130356+lmx-Hexagram@users.noreply.github.com> Date: Wed, 28 Apr 2021 23:49:01 +0800 Subject: [PATCH 018/128] fix: Dockedr -> Docker --- .../blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/zh/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md b/content/zh/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md index 788b28420d..e6a7cd2426 100644 --- a/content/zh/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md +++ b/content/zh/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md @@ -45,7 +45,7 @@ tool for building containers, and the images that result from running `docker build` can still run in your Kubernetes cluster. --> 如果你是 Kubernetes 的终端用户，这对你不会有太大影响。 -这事并不意味着 Dockder 已死、也不意味着你不能或不该继续把 Docker 用作开发工具。 +这事并不意味着 Docker 已死、也不意味着你不能或不该继续把 Docker 用作开发工具。 Docker 仍然是构建容器的利器，使用命令 `docker build` 构建的镜像在 Kubernetes 集群中仍然可以运行。 + +{{% thirdparty-content %}} + +Add-ons extend the functionality of Kubernetes. + +This page lists some of the available add-ons and links to their respective installation instructions. + + + +## Networking and Network Policy + +* [ACI](https://www.github.com/noironetworks/aci-containers) provides integrated container networking and network security with Cisco ACI. +* [Antrea](https://antrea.io/) operates at Layer 3/4 to provide networking and security services for Kubernetes, leveraging Open vSwitch as the networking data plane. +* [Calico](https://docs.projectcalico.org/latest/introduction/) is a networking and network policy provider. Calico supports a flexible set of networking options so you can choose the most efficient option for your situation, including non-overlay and overlay networks, with or without BGP. Calico uses the same engine to enforce network policy for hosts, pods, and (if using Istio & Envoy) applications at the service mesh layer. +* [Canal](https://github.com/tigera/canal/tree/master/k8s-install) unites Flannel and Calico, providing networking and network policy. +* [Cilium](https://github.com/cilium/cilium) is a L3 network and network policy plugin that can enforce HTTP/API/L7 policies transparently. Both routing and overlay/encapsulation mode are supported, and it can work on top of other CNI plugins. +* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) enables Kubernetes to seamlessly connect to a choice of CNI plugins, such as Calico, Canal, Flannel, Romana, or Weave. +* [Contiv](https://contiv.github.io) provides configurable networking (native L3 using BGP, overlay using vxlan, classic L2, and Cisco-SDN/ACI) for various use cases and a rich policy framework. Contiv project is fully [open sourced](https://github.com/contiv). The [installer](https://github.com/contiv/install) provides both kubeadm and non-kubeadm based installation options. +* [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), based on [Tungsten Fabric](https://tungsten.io), is an open source, multi-cloud network virtualization and policy management platform. Contrail and Tungsten Fabric are integrated with orchestration systems such as Kubernetes, OpenShift, OpenStack and Mesos, and provide isolation modes for virtual machines, containers/pods and bare metal workloads. +* [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kubernetes.md) is an overlay network provider that can be used with Kubernetes. +* [Knitter](https://github.com/ZTE/Knitter/) is a plugin to support multiple network interfaces in a Kubernetes pod. +* [Multus](https://github.com/Intel-Corp/multus-cni) is a Multi plugin for multiple network support in Kubernetes to support all CNI plugins (e.g. Calico, Cilium, Contiv, Flannel), in addition to SRIOV, DPDK, OVS-DPDK and VPP based workloads in Kubernetes. +* [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/) is a networking provider for Kubernetes based on [OVN (Open Virtual Network)](https://github.com/ovn-org/ovn/), a virtual networking implementation that came out of the Open vSwitch (OVS) project. OVN-Kubernetes provides an overlay based networking implementation for Kubernetes, including an OVS based implementation of load balancing and network policy. +* [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin) is OVN based CNI controller plugin to provide cloud native based Service function chaining(SFC), Multiple OVN overlay networking, dynamic subnet creation, dynamic creation of virtual networks, VLAN Provider network, Direct provider network and pluggable with other Multi-network plugins, ideal for edge based cloud native workloads in Multi-cluster networking +* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) provides integration between VMware NSX-T and container orchestrators such as Kubernetes, as well as integration between NSX-T and container-based CaaS/PaaS platforms such as Pivotal Container Service (PKS) and OpenShift. +* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) is an SDN platform that provides policy-based networking between Kubernetes Pods and non-Kubernetes environments with visibility and security monitoring. +* [Romana](https://romana.io) is a Layer 3 networking solution for pod networks that also supports the [NetworkPolicy API](/docs/concepts/services-networking/network-policies/). Kubeadm add-on installation details available [here](https://github.com/romana/romana/tree/master/containerize). +* [Weave Net](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/) provides networking and network policy, will carry on working on both sides of a network partition, and does not require an external database. + +## Service Discovery + +* [CoreDNS](https://coredns.io) is a flexible, extensible DNS server which can be [installed](https://github.com/coredns/deployment/tree/master/kubernetes) as the in-cluster DNS for pods. + +## Visualization & Control + +* [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard) is a dashboard web interface for Kubernetes. +* [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s) is a tool for graphically visualizing your containers, pods, services etc. Use it in conjunction with a [Weave Cloud account](https://cloud.weave.works/) or host the UI yourself. + +## Infrastructure + +* [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation) is an add-on to run virtual machines on Kubernetes. Usually run on bare-metal clusters. + +## Legacy Add-ons + +There are several other add-ons documented in the deprecated [cluster/addons](https://git.k8s.io/kubernetes/cluster/addons) directory. + +Well-maintained ones should be linked to here. PRs welcome! From e0d4e723426e97bbd2714ad27ceadb91c44b3851 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Fri, 30 Apr 2021 13:46:47 +0000 Subject: [PATCH 020/128] Translate concepts/cluster-administration/addons into Japanese --- .../concepts/cluster-administration/addons.md | 62 +++++++++---------- 1 file changed, 31 insertions(+), 31 deletions(-) diff --git a/content/ja/docs/concepts/cluster-administration/addons.md b/content/ja/docs/concepts/cluster-administration/addons.md index 726a714151..72e9ebc39f 100644 --- a/content/ja/docs/concepts/cluster-administration/addons.md +++ b/content/ja/docs/concepts/cluster-administration/addons.md @@ -1,5 +1,5 @@ --- -title: Installing Addons +title: アドオンのインストール content_type: concept --- @@ -7,47 +7,47 @@ content_type: concept {{% thirdparty-content %}} -Add-ons extend the functionality of Kubernetes. +アドオンはKubernetesの機能を拡張するものです。 -This page lists some of the available add-ons and links to their respective installation instructions. +このページでは、利用可能なアドオンの一部の一覧と、それぞれのアドオンのインストール方法へのリンクを提供します。 -## Networking and Network Policy +## ネットワークとネットワークポリシー -* [ACI](https://www.github.com/noironetworks/aci-containers) provides integrated container networking and network security with Cisco ACI. -* [Antrea](https://antrea.io/) operates at Layer 3/4 to provide networking and security services for Kubernetes, leveraging Open vSwitch as the networking data plane. -* [Calico](https://docs.projectcalico.org/latest/introduction/) is a networking and network policy provider. Calico supports a flexible set of networking options so you can choose the most efficient option for your situation, including non-overlay and overlay networks, with or without BGP. Calico uses the same engine to enforce network policy for hosts, pods, and (if using Istio & Envoy) applications at the service mesh layer. -* [Canal](https://github.com/tigera/canal/tree/master/k8s-install) unites Flannel and Calico, providing networking and network policy. -* [Cilium](https://github.com/cilium/cilium) is a L3 network and network policy plugin that can enforce HTTP/API/L7 policies transparently. Both routing and overlay/encapsulation mode are supported, and it can work on top of other CNI plugins. -* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) enables Kubernetes to seamlessly connect to a choice of CNI plugins, such as Calico, Canal, Flannel, Romana, or Weave. -* [Contiv](https://contiv.github.io) provides configurable networking (native L3 using BGP, overlay using vxlan, classic L2, and Cisco-SDN/ACI) for various use cases and a rich policy framework. Contiv project is fully [open sourced](https://github.com/contiv). The [installer](https://github.com/contiv/install) provides both kubeadm and non-kubeadm based installation options. -* [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), based on [Tungsten Fabric](https://tungsten.io), is an open source, multi-cloud network virtualization and policy management platform. Contrail and Tungsten Fabric are integrated with orchestration systems such as Kubernetes, OpenShift, OpenStack and Mesos, and provide isolation modes for virtual machines, containers/pods and bare metal workloads. -* [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kubernetes.md) is an overlay network provider that can be used with Kubernetes. -* [Knitter](https://github.com/ZTE/Knitter/) is a plugin to support multiple network interfaces in a Kubernetes pod. -* [Multus](https://github.com/Intel-Corp/multus-cni) is a Multi plugin for multiple network support in Kubernetes to support all CNI plugins (e.g. Calico, Cilium, Contiv, Flannel), in addition to SRIOV, DPDK, OVS-DPDK and VPP based workloads in Kubernetes. -* [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/) is a networking provider for Kubernetes based on [OVN (Open Virtual Network)](https://github.com/ovn-org/ovn/), a virtual networking implementation that came out of the Open vSwitch (OVS) project. OVN-Kubernetes provides an overlay based networking implementation for Kubernetes, including an OVS based implementation of load balancing and network policy. -* [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin) is OVN based CNI controller plugin to provide cloud native based Service function chaining(SFC), Multiple OVN overlay networking, dynamic subnet creation, dynamic creation of virtual networks, VLAN Provider network, Direct provider network and pluggable with other Multi-network plugins, ideal for edge based cloud native workloads in Multi-cluster networking -* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) provides integration between VMware NSX-T and container orchestrators such as Kubernetes, as well as integration between NSX-T and container-based CaaS/PaaS platforms such as Pivotal Container Service (PKS) and OpenShift. -* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) is an SDN platform that provides policy-based networking between Kubernetes Pods and non-Kubernetes environments with visibility and security monitoring. -* [Romana](https://romana.io) is a Layer 3 networking solution for pod networks that also supports the [NetworkPolicy API](/docs/concepts/services-networking/network-policies/). Kubeadm add-on installation details available [here](https://github.com/romana/romana/tree/master/containerize). -* [Weave Net](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/) provides networking and network policy, will carry on working on both sides of a network partition, and does not require an external database. +* [ACI](https://www.github.com/noironetworks/aci-containers)は、統合されたコンテナネットワークとネットワークセキュリティをCisco ACIを使用して提供します。 +* [Antrea](https://antrea.io/)は、L3またはL4で動作して、Open vSwitchをネットワークデータプレーンとして活用する、Kubernetes向けのネットワークとセキュリティサービスを提供します。 +* [Calico](https://docs.projectcalico.org/latest/introduction/)はネットワークとネットワークプリシーのプロバイダーです。Calicoは、BGPを使用または未使用の非オーバーレイおよびオーバーレイネットワークを含む、フレキシブルなさまざまなネットワークオプションサポートします。Calicoはホスト、Pod、そして(IstioとEnvoyを使用している場合には)サービスメッシュ上のアプリケーションに対してネットワークポリシーを強制するために、同一のエンジンを使用します。 +* [Canal](https://github.com/tigera/canal/tree/master/k8s-install)はFlannelとCalicoをあわせたもので、ネットワークとネットワークポリシーを提供します。 +* [Cilium](https://github.com/cilium/cilium)は、L3のネットワークとネットワークポリシーのプラグインで、HTTP/API/L7のポリシーを透過的に強制できます。ルーティングとoverlay/encapsulationモードの両方をサポートしており、他のCNIプラグイン上で機能できます。 +* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie)は、KubernetesをCalico、Canal、Flannel、Romana、Weaveなど選択したCNIプラグインをシームレスに接続できるようにするプラグインです。 +* [Contiv](https://contiv.github.io)は、さまざまなユースケースと豊富なポリシーフレームワーク向けに設定可能なネットワーク(BGPを使用したネイティブのL3、vxlanを使用したオーバーレイ、古典的なL2、Cisco-SDN/ACI)を提供します。Contivプロジェクトは完全に[オープンソース](https://github.com/contiv)です。[インストーラ](https://github.com/contiv/install)はkubeadmとkubeadm以外の両方をベースとしたインストールオプションがあります。 +* [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/)は、[Tungsten Fabric](https://tungsten.io)をベースにしている、オープンソースでマルチクラウドに対応したネットワーク仮想化およびポリシー管理プラットフォームです。ContrailおよびTungsten Fabricは、Kubernetes、OpenShift、OpenStack、Mesosなどのオーケストレーションシステムと統合されており、仮想マシン、コンテナ/Pod、ベアメタルのワークロードに隔離モードを提供します。 +* [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kubernetes.md)は、Kubernetesで使用できるオーバーレイネットワークプロバイダーです。 +* [Knitter](https://github.com/ZTE/Knitter/)は、1つのKubernetes Podで複数のネットワークインターフェイスをサポートするためのプラグインです。 +* [Multus](https://github.com/Intel-Corp/multus-cni)は、すべてのCNIプラグイン(たとえば、Calico、Cilium、Contiv、Flannel)に加えて、SRIOV、DPDK、OVS-DPDK、VPPをベースとするKubernetes上のワークロードをサポートする、複数のネットワークサポートのためのMultiプラグインです。 +* [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/)は、Open vSwitch(OVS)プロジェクトから生まれた仮想ネットワーク実装である[OVN(Open Virtual Network)](https://github.com/ovn-org/ovn/)をベースとする、Kubernetesのためのネットワークプロバイダです。OVN-Kubernetesは、OVSベースのロードバランサーおよびネットワークポリシーの実装を含む、Kubernetes向けのオーバーレイベースのネットワーク実装を提供します。 +* [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin)は、クラウドネイティブベースのService function chaining(SFC)、Multiple OVNオーバーレイネットワーク、動的なサブネットの作成、動的な仮想ネットワークの作成、VLANプロバイダーネットワーク、Directプロバイダーネットワークを提供し、他のMulti-networkプラグインと付け替え可能なOVNベースのCNIコントローラープラグインです。 +* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in(NCP)は、VMware NSX-TとKubernetesなどのコンテナオーケストレーター間のインテグレーションを提供します。また、NSX-Tと、Pivotal Container Service(PKS)とOpenShiftなどのコンテナベースのCaaS/PaaSプラットフォームとのインテグレーションも提供します。 +* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst)は、Kubernetes Podと非Kubernetes環境間で可視化とセキュリティモニタリングを使用してポリシーベースのネットワークを提供するSDNプラットフォームです。 +* [Romana](https://romana.io)は、[NetworkPolicy API](/docs/concepts/services-networking/network-policies/)もサポートするPodネットワーク向けのL3のネットワークソリューションです。Kubeadmアドオンのインストールの詳細は[こちら](https://github.com/romana/romana/tree/master/containerize)で確認できます。 +* [Weave Net](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/)は、ネットワークパーティションの両面で機能し、外部データベースを必要とせずに、ネットワークとネットワークポリシーを提供します。 -## Service Discovery +## サービスディスカバリ -* [CoreDNS](https://coredns.io) is a flexible, extensible DNS server which can be [installed](https://github.com/coredns/deployment/tree/master/kubernetes) as the in-cluster DNS for pods. +* [CoreDNS](https://coredns.io)は、フレキシブルで拡張可能なDNSサーバーです。Pod向けのクラスター内DNSとして[インストール](https://github.com/coredns/deployment/tree/master/kubernetes)できます。 -## Visualization & Control +## 可視化と制御 -* [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard) is a dashboard web interface for Kubernetes. -* [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s) is a tool for graphically visualizing your containers, pods, services etc. Use it in conjunction with a [Weave Cloud account](https://cloud.weave.works/) or host the UI yourself. +* [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard)はKubernetes向けのダッシュボードを提供するウェブインターフェイスです。 +* [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s)は、コンテナ、Pod、Serviceなどをグラフィカルに可視化するツールです。[Weave Cloud account](https://cloud.weave.works/)と組み合わせて使うか、UIを自分でホストして使います。 -## Infrastructure +## インフラストラクチャ -* [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation) is an add-on to run virtual machines on Kubernetes. Usually run on bare-metal clusters. +* [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation)は仮想マシンをKubernetes上で実行するためのアドオンです。通常、ベアメタルのクラスタで実行します。 -## Legacy Add-ons +## レガシーなアドオン -There are several other add-ons documented in the deprecated [cluster/addons](https://git.k8s.io/kubernetes/cluster/addons) directory. +いくつかのアドオンは、廃止された[cluster/addons](https://git.k8s.io/kubernetes/cluster/addons)ディレクトリに掲載されています。 -Well-maintained ones should be linked to here. PRs welcome! +よくメンテナンスされたアドオンはここにリンクしてください。PRを歓迎しています。 \ No newline at end of file From 390de57ebf80c2f5f7e39bad8c90beb08979f420 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Sat, 1 May 2021 06:24:13 +0000 Subject: [PATCH 021/128] Copy content/en/docs/concepts/cluster-administration/kubelet-garbage-collection.md for translation --- .../kubelet-garbage-collection.md | 86 +++++++++++++++++++ 1 file changed, 86 insertions(+) create mode 100644 content/ja/docs/concepts/cluster-administration/kubelet-garbage-collection.md diff --git a/content/ja/docs/concepts/cluster-administration/kubelet-garbage-collection.md b/content/ja/docs/concepts/cluster-administration/kubelet-garbage-collection.md new file mode 100644 index 0000000000..ea51a566ac --- /dev/null +++ b/content/ja/docs/concepts/cluster-administration/kubelet-garbage-collection.md @@ -0,0 +1,86 @@ +--- +reviewers: +title: Garbage collection for container images +content_type: concept +weight: 70 +--- + + + +Garbage collection is a helpful function of kubelet that will clean up unused [images](/docs/concepts/containers/#container-images) and unused [containers](/docs/concepts/containers/). Kubelet will perform garbage collection for containers every minute and garbage collection for images every five minutes. + +External garbage collection tools are not recommended as these tools can potentially break the behavior of kubelet by removing containers expected to exist. + + + + + + +## Image Collection + +Kubernetes manages lifecycle of all images through imageManager, with the cooperation +of cadvisor. + +The policy for garbage collecting images takes two factors into consideration: +`HighThresholdPercent` and `LowThresholdPercent`. Disk usage above the high threshold +will trigger garbage collection. The garbage collection will delete least recently used images until the low +threshold has been met. + +## Container Collection + +The policy for garbage collecting containers considers three user-defined variables. `MinAge` is the minimum age at which a container can be garbage collected. `MaxPerPodContainer` is the maximum number of dead containers every single +pod (UID, container name) pair is allowed to have. `MaxContainers` is the maximum number of total dead containers. These variables can be individually disabled by setting `MinAge` to zero and setting `MaxPerPodContainer` and `MaxContainers` respectively to less than zero. + +Kubelet will act on containers that are unidentified, deleted, or outside of the boundaries set by the previously mentioned flags. The oldest containers will generally be removed first. `MaxPerPodContainer` and `MaxContainer` may potentially conflict with each other in situations where retaining the maximum number of containers per pod (`MaxPerPodContainer`) would go outside the allowable range of global dead containers (`MaxContainers`). `MaxPerPodContainer` would be adjusted in this situation: A worst case scenario would be to downgrade `MaxPerPodContainer` to 1 and evict the oldest containers. Additionally, containers owned by pods that have been deleted are removed once they are older than `MinAge`. + +Containers that are not managed by kubelet are not subject to container garbage collection. + +## User Configuration + +You can adjust the following thresholds to tune image garbage collection with the following kubelet flags : + +1. `image-gc-high-threshold`, the percent of disk usage which triggers image garbage collection. +Default is 85%. +2. `image-gc-low-threshold`, the percent of disk usage to which image garbage collection attempts +to free. Default is 80%. + +You can customize the garbage collection policy through the following kubelet flags: + +1. `minimum-container-ttl-duration`, minimum age for a finished container before it is +garbage collected. Default is 0 minute, which means every finished container will be garbage collected. +2. `maximum-dead-containers-per-container`, maximum number of old instances to be retained +per container. Default is 1. +3. `maximum-dead-containers`, maximum number of old instances of containers to retain globally. +Default is -1, which means there is no global limit. + +Containers can potentially be garbage collected before their usefulness has expired. These containers +can contain logs and other data that can be useful for troubleshooting. A sufficiently large value for +`maximum-dead-containers-per-container` is highly recommended to allow at least 1 dead container to be +retained per expected container. A larger value for `maximum-dead-containers` is also recommended for a +similar reason. +See [this issue](https://github.com/kubernetes/kubernetes/issues/13287) for more details. + + +## Deprecation + +Some kubelet Garbage Collection features in this doc will be replaced by kubelet eviction in the future. + +Including: + +| Existing Flag | New Flag | Rationale | +| ------------- | -------- | --------- | +| `--image-gc-high-threshold` | `--eviction-hard` or `--eviction-soft` | existing eviction signals can trigger image garbage collection | +| `--image-gc-low-threshold` | `--eviction-minimum-reclaim` | eviction reclaims achieve the same behavior | +| `--maximum-dead-containers` | | deprecated once old logs are stored outside of container's context | +| `--maximum-dead-containers-per-container` | | deprecated once old logs are stored outside of container's context | +| `--minimum-container-ttl-duration` | | deprecated once old logs are stored outside of container's context | +| `--low-diskspace-threshold-mb` | `--eviction-hard` or `eviction-soft` | eviction generalizes disk thresholds to other resources | +| `--outofdisk-transition-frequency` | `--eviction-pressure-transition-period` | eviction generalizes disk pressure transition to other resources | + + + +## {{% heading "whatsnext" %}} + + +See [Configuring Out Of Resource Handling](/docs/tasks/administer-cluster/out-of-resource/) for more details. + From e654c368a7a2a82934bf4707d28a586fea441ce1 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Sat, 1 May 2021 07:57:30 +0000 Subject: [PATCH 022/128] Translate concepts/cluster-administration/kubelet-garbage-collection into Japanese --- .../kubelet-garbage-collection.md | 83 +++++++------------ 1 file changed, 32 insertions(+), 51 deletions(-) diff --git a/content/ja/docs/concepts/cluster-administration/kubelet-garbage-collection.md b/content/ja/docs/concepts/cluster-administration/kubelet-garbage-collection.md index ea51a566ac..ffa08d63bd 100644 --- a/content/ja/docs/concepts/cluster-administration/kubelet-garbage-collection.md +++ b/content/ja/docs/concepts/cluster-administration/kubelet-garbage-collection.md @@ -1,86 +1,67 @@ --- -reviewers: -title: Garbage collection for container images +title: コンテナイメージのガベージコレクション content_type: concept weight: 70 --- -Garbage collection is a helpful function of kubelet that will clean up unused [images](/docs/concepts/containers/#container-images) and unused [containers](/docs/concepts/containers/). Kubelet will perform garbage collection for containers every minute and garbage collection for images every five minutes. - -External garbage collection tools are not recommended as these tools can potentially break the behavior of kubelet by removing containers expected to exist. - - +ガベージコレクションは、未使用の[イメージ](/ja/docs/concepts/containers/#container-images)と未使用の[コンテナ](/ja/docs/concepts/containers/)をクリーンアップするkubeletの便利な機能です。kubeletコンテナのガベージコレクションを1分ごとに行い、イメージのガベージコレクションは5分ごとに行います。 +存在することが期待されているコンテナを削除してkubeletの動作を壊す可能性があるため、外部のガベージコレクションのツールは推奨されません。 -## Image Collection +## イメージのガベージコレクション -Kubernetes manages lifecycle of all images through imageManager, with the cooperation -of cadvisor. +Kubernetesでは、すべてのイメージのライフサイクルの管理はcadvisorと協調してimageManager経由で行います。 -The policy for garbage collecting images takes two factors into consideration: -`HighThresholdPercent` and `LowThresholdPercent`. Disk usage above the high threshold -will trigger garbage collection. The garbage collection will delete least recently used images until the low -threshold has been met. +イメージのガベージコレクションのポリシーについて考えるときは、`HighThresholdPercent`および`LowThresholdPercent`という2つの要因について考慮する必要があります。ディスク使用量がhigh thresholdを超えると、ガベージコレクションがトリガされます。ガベージコレクションは、low +thresholdが満たされるまで、最後に使われてから最も時間が経った(least recently used)イメージを削除します。 -## Container Collection +## コンテナのガベージコレクション -The policy for garbage collecting containers considers three user-defined variables. `MinAge` is the minimum age at which a container can be garbage collected. `MaxPerPodContainer` is the maximum number of dead containers every single -pod (UID, container name) pair is allowed to have. `MaxContainers` is the maximum number of total dead containers. These variables can be individually disabled by setting `MinAge` to zero and setting `MaxPerPodContainer` and `MaxContainers` respectively to less than zero. +コンテナのガベージコレクションのポリシーは、3つのユーザー定義の変数を考慮に入れます。`MinAge`は、ガベージコレクションできるコンテナの最小の年齢です。`MaxPerPodContainer`は、すべての単一のPod(UID、コンテナ名)が保持することを許されているdead状態のコンテナの最大値です。`MaxContainers`はdead状態のコンテナの合計の最大値です。これらの変数は、`MinAge`は0に、`MaxPerPodContainer`と`MaxContainers`は0未満にそれぞれ設定することで個別に無効にできます。 -Kubelet will act on containers that are unidentified, deleted, or outside of the boundaries set by the previously mentioned flags. The oldest containers will generally be removed first. `MaxPerPodContainer` and `MaxContainer` may potentially conflict with each other in situations where retaining the maximum number of containers per pod (`MaxPerPodContainer`) would go outside the allowable range of global dead containers (`MaxContainers`). `MaxPerPodContainer` would be adjusted in this situation: A worst case scenario would be to downgrade `MaxPerPodContainer` to 1 and evict the oldest containers. Additionally, containers owned by pods that have been deleted are removed once they are older than `MinAge`. +kubeletは、未指定のコンテナ、削除されたコンテナ、前述のフラグにより設定された境界の外にあるコンテナに対して動作します。一般に、最も古いコンテナが最初に削除されます。`MaxPerPodContainer`と`MaxContainer`は、Podごとの保持するコンテナの最大値(`MaxPerPodContainer`)がグローバルのdead状態のコンテナの許容範囲(`MaxContainers`)外である場合には、互いに競合する可能性があります。このような状況では、`MaxPerPodContainer`が調整されます。最悪のケースのシナリオでは、`MaxPerPodContainer`が1にダウングレードされ、最も古いコンテナが強制退去されます。さらに、`MinAge`より古くなると、削除済みのPodが所有するコンテナが削除されます。 -Containers that are not managed by kubelet are not subject to container garbage collection. +kubeletによって管理されないコンテナは、コンテナのガベージコレクションの対象にはなりません。 -## User Configuration +## ユーザー設定 -You can adjust the following thresholds to tune image garbage collection with the following kubelet flags : +イメージのガベージコレクションを調整するために、以下のkubeletのフラグを使用して次のようなしきい値を調整できます。 -1. `image-gc-high-threshold`, the percent of disk usage which triggers image garbage collection. -Default is 85%. -2. `image-gc-low-threshold`, the percent of disk usage to which image garbage collection attempts -to free. Default is 80%. +1. `image-gc-high-threshold`: イメージのガベージコレクションをトリガするディスク使用量の割合(%)。デフォルトは85%。 +2. `image-gc-low-threshold`: イメージのガベージコレクションが解放を試みるディスク使用量の割合(%)。デフォルトは80%。 -You can customize the garbage collection policy through the following kubelet flags: +ガベージコレクションのポリシーは、以下のkubeletのフラグを使用してカスタマイズできます。 -1. `minimum-container-ttl-duration`, minimum age for a finished container before it is -garbage collected. Default is 0 minute, which means every finished container will be garbage collected. -2. `maximum-dead-containers-per-container`, maximum number of old instances to be retained -per container. Default is 1. -3. `maximum-dead-containers`, maximum number of old instances of containers to retain globally. -Default is -1, which means there is no global limit. +1. `minimum-container-ttl-duration`: 完了したコンテナがガベージコレクションされる前に経過するべき最小期間。デフォルトは0分です。つまり、すべての完了したコンテナはガベージコレクションされます。 +2. `maximum-dead-containers-per-container`: コンテナごとに保持される古いインスタンスの最大値です。デフォルトは1です。 +3. `maximum-dead-containers`: グローバルに保持するべき古いコンテナのインスタンスの最大値です。デフォルトは-1です。つまり、グローバルなリミットは存在しません。 -Containers can potentially be garbage collected before their usefulness has expired. These containers -can contain logs and other data that can be useful for troubleshooting. A sufficiently large value for -`maximum-dead-containers-per-container` is highly recommended to allow at least 1 dead container to be -retained per expected container. A larger value for `maximum-dead-containers` is also recommended for a -similar reason. -See [this issue](https://github.com/kubernetes/kubernetes/issues/13287) for more details. +コンテナは役に立たなくなる前にガベージコレクションされる可能性があります。こうしたコンテナには、トラブルシューティングに役立つログや他のデータが含まれるかもしれません。そのため、期待されるコンテナごとに最低でも1つのdead状態のコンテナが許容されるようにするために、`maximum-dead-containers-per-container`には十分大きな値を設定することが強く推奨されます。同様の理由で、`maximum-dead-containers`にも、より大きな値を設定することが推奨されます。詳しくは、[こちらのissue](https://github.com/kubernetes/kubernetes/issues/13287)を読んでください。 +## 廃止 -## Deprecation +このドキュメントにあるkubeletの一部のガベージコレクションの機能は、将来kubelet evictionで置換される予定です。 -Some kubelet Garbage Collection features in this doc will be replaced by kubelet eviction in the future. +これには以下のものが含まれます。 -Including: - -| Existing Flag | New Flag | Rationale | +| 既存のフラグ | 新しいフラグ | 理由 | | ------------- | -------- | --------- | -| `--image-gc-high-threshold` | `--eviction-hard` or `--eviction-soft` | existing eviction signals can trigger image garbage collection | -| `--image-gc-low-threshold` | `--eviction-minimum-reclaim` | eviction reclaims achieve the same behavior | -| `--maximum-dead-containers` | | deprecated once old logs are stored outside of container's context | -| `--maximum-dead-containers-per-container` | | deprecated once old logs are stored outside of container's context | -| `--minimum-container-ttl-duration` | | deprecated once old logs are stored outside of container's context | -| `--low-diskspace-threshold-mb` | `--eviction-hard` or `eviction-soft` | eviction generalizes disk thresholds to other resources | -| `--outofdisk-transition-frequency` | `--eviction-pressure-transition-period` | eviction generalizes disk pressure transition to other resources | +| `--image-gc-high-threshold` | `--eviction-hard`または`--eviction-soft` | 既存のevictionのシグナルがイメージのガベージコレクションをトリガする可能性がある | +| `--image-gc-low-threshold` | `--eviction-minimum-reclaim` | eviction reclaimが同等の動作を実現する | +| `--maximum-dead-containers` | | 古いログがコンテナのコンテキストの外部に保存されるようになったら廃止 | +| `--maximum-dead-containers-per-container` | | 古いログがコンテナのコンテキストの外部に保存されるようになったら廃止 | +| `--minimum-container-ttl-duration` | | 古いログがコンテナのコンテキストの外部に保存されるようになったら廃止 | +| `--low-diskspace-threshold-mb` | `--eviction-hard` or `eviction-soft` | evictionはディスクのしきい値を他のリソースに一般化している | +| `--outofdisk-transition-frequency` | `--eviction-pressure-transition-period` | evictionはディスクのpressure transitionを他のリソースに一般化している | ## {{% heading "whatsnext" %}} -See [Configuring Out Of Resource Handling](/docs/tasks/administer-cluster/out-of-resource/) for more details. +詳細については、[リソース不足のハンドリング方法を設定する](/docs/tasks/administer-cluster/out-of-resource/)を参照してください。 From 919cafa2c0c7868bb810379711dc38f92904b25d Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Sat, 1 May 2021 08:00:27 +0000 Subject: [PATCH 023/128] Add an anchor link to concepts/containers/_index.md --- content/ja/docs/concepts/containers/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/containers/_index.md b/content/ja/docs/concepts/containers/_index.md index fd3506ea40..cb2b457e57 100755 --- a/content/ja/docs/concepts/containers/_index.md +++ b/content/ja/docs/concepts/containers/_index.md @@ -18,7 +18,7 @@ no_list: true -## コンテナイメージ +## コンテナイメージ {#container-images} [コンテナイメージ](/docs/concepts/containers/images/)はすぐに実行可能なソフトウェアパッケージで、アプリケーションの実行に必要なものをすべて含んています。コードと必要なランタイム、アプリケーションとシステムのライブラリ、そして必須な設定項目のデフォルト値を含みます。 設計上、コンテナは不変で、既に実行中のコンテナのコードを変更することはできません。コンテナ化されたアプリケーションがあり変更したい場合は、変更を含んだ新しいイメージをビルドし、コンテナを再作成して、更新されたイメージから起動する必要があります。 From 4201120ebd8f4652563d8ca549b9e2b1492aad23 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Sat, 1 May 2021 09:01:48 +0000 Subject: [PATCH 024/128] Copy content/en/docs/concepts/cluster-administration/system-logs.md for translation --- .../cluster-administration/system-logs.md | 142 ++++++++++++++++++ 1 file changed, 142 insertions(+) create mode 100644 content/ja/docs/concepts/cluster-administration/system-logs.md diff --git a/content/ja/docs/concepts/cluster-administration/system-logs.md b/content/ja/docs/concepts/cluster-administration/system-logs.md new file mode 100644 index 0000000000..0466837356 --- /dev/null +++ b/content/ja/docs/concepts/cluster-administration/system-logs.md @@ -0,0 +1,142 @@ +--- +reviewers: +- dims +- 44past4 +title: System Logs +content_type: concept +weight: 60 +--- + + + +System component logs record events happening in cluster, which can be very useful for debugging. +You can configure log verbosity to see more or less detail. +Logs can be as coarse-grained as showing errors within a component, or as fine-grained as showing step-by-step traces of events (like HTTP access logs, pod state changes, controller actions, or scheduler decisions). + + + +## Klog + +klog is the Kubernetes logging library. [klog](https://github.com/kubernetes/klog) +generates log messages for the Kubernetes system components. + +For more information about klog configuration, see the [Command line tool reference](/docs/reference/command-line-tools-reference/). + +An example of the klog native format: +``` +I1025 00:15:15.525108 1 httplog.go:79] GET /api/v1/namespaces/kube-system/pods/metrics-server-v0.3.1-57c75779f-9p8wg: (1.512ms) 200 [pod_nanny/v0.0.0 (linux/amd64) kubernetes/$Format 10.56.1.19:51756] +``` + +### Structured Logging + +{{< feature-state for_k8s_version="v1.19" state="alpha" >}} + +{{< warning >}} +Migration to structured log messages is an ongoing process. Not all log messages are structured in this version. When parsing log files, you must also handle unstructured log messages. + +Log formatting and value serialization are subject to change. +{{< /warning>}} + +Structured logging introduces a uniform structure in log messages allowing for programmatic extraction of information. You can store and process structured logs with less effort and cost. +New message format is backward compatible and enabled by default. + +Format of structured logs: + +```ini + "" ="" ="" ... +``` + +Example: + +```ini +I1025 00:15:15.525108 1 controller_utils.go:116] "Pod status updated" pod="kube-system/kubedns" status="ready" +``` + + +### JSON log format + +{{< feature-state for_k8s_version="v1.19" state="alpha" >}} + +{{}} +JSON output does not support many standard klog flags. For list of unsupported klog flags, see the [Command line tool reference](/docs/reference/command-line-tools-reference/). + +Not all logs are guaranteed to be written in JSON format (for example, during process start). If you intend to parse logs, make sure you can handle log lines that are not JSON as well. + +Field names and JSON serialization are subject to change. +{{< /warning >}} + +The `--logging-format=json` flag changes the format of logs from klog native format to JSON format. +Example of JSON log format (pretty printed): +```json +{ + "ts": 1580306777.04728, + "v": 4, + "msg": "Pod status updated", + "pod":{ + "name": "nginx-1", + "namespace": "default" + }, + "status": "ready" +} +``` + +Keys with special meaning: +* `ts` - timestamp as Unix time (required, float) +* `v` - verbosity (required, int, default 0) +* `err` - error string (optional, string) +* `msg` - message (required, string) + + +List of components currently supporting JSON format: +* {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}} +* {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} +* {{< glossary_tooltip term_id="kube-scheduler" text="kube-scheduler" >}} +* {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} + +### Log sanitization + +{{< feature-state for_k8s_version="v1.20" state="alpha" >}} + +{{}} +Log sanitization might incur significant computation overhead and therefore should not be enabled in production. +{{< /warning >}} + +The `--experimental-logging-sanitization` flag enables the klog sanitization filter. +If enabled all log arguments are inspected for fields tagged as sensitive data (e.g. passwords, keys, tokens) and logging of these fields will be prevented. + +List of components currently supporting log sanitization: +* kube-controller-manager +* kube-apiserver +* kube-scheduler +* kubelet + +{{< note >}} +The Log sanitization filter does not prevent user workload logs from leaking sensitive data. +{{< /note >}} + +### Log verbosity level + +The `-v` flag controls log verbosity. Increasing the value increases the number of logged events. Decreasing the value decreases the number of logged events. +Increasing verbosity settings logs increasingly less severe events. A verbosity setting of 0 logs only critical events. + +### Log location + +There are two types of system components: those that run in a container and those +that do not run in a container. For example: + +* The Kubernetes scheduler and kube-proxy run in a container. +* The kubelet and container runtime, for example Docker, do not run in containers. + +On machines with systemd, the kubelet and container runtime write to journald. +Otherwise, they write to `.log` files in the `/var/log` directory. +System components inside containers always write to `.log` files in the `/var/log` directory, +bypassing the default logging mechanism. +Similar to the container logs, you should rotate system component logs in the `/var/log` directory. +In Kubernetes clusters created by the `kube-up.sh` script, log rotation is configured by the `logrotate` tool. +The `logrotate` tool rotates logs daily, or once the log size is greater than 100MB. + +## {{% heading "whatsnext" %}} + +* Read about the [Kubernetes Logging Architecture](/docs/concepts/cluster-administration/logging/) +* Read about [Structured Logging](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1602-structured-logging) +* Read about the [Conventions for logging severity](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md) From 895d59124e53e380dc476f12d60f67f28f0855b7 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Sun, 2 May 2021 12:31:38 +0000 Subject: [PATCH 025/128] Translate concepts/cluster-administration/system-logs into Japanese --- .../cluster-administration/system-logs.md | 96 ++++++++----------- 1 file changed, 40 insertions(+), 56 deletions(-) diff --git a/content/ja/docs/concepts/cluster-administration/system-logs.md b/content/ja/docs/concepts/cluster-administration/system-logs.md index 0466837356..cae76d7e34 100644 --- a/content/ja/docs/concepts/cluster-administration/system-logs.md +++ b/content/ja/docs/concepts/cluster-administration/system-logs.md @@ -1,72 +1,66 @@ --- -reviewers: -- dims -- 44past4 -title: System Logs +title: システムログ content_type: concept weight: 60 --- -System component logs record events happening in cluster, which can be very useful for debugging. -You can configure log verbosity to see more or less detail. -Logs can be as coarse-grained as showing errors within a component, or as fine-grained as showing step-by-step traces of events (like HTTP access logs, pod state changes, controller actions, or scheduler decisions). +システムコンポーネントのログは、クラスター内で起こったイベントを記録します。このログはデバッグのために非常に役立ちます。ログのverbosityを設定すると、ログをどの程度詳細に見るのかを変更できます。ログはコンポーネント内のエラーを表示する程度の荒い粒度にすることも、イベントのステップバイステップのトレース(HTTPのアクセスログ、Podの状態の変更、コントローラーの動作、スケジューラーの決定など)を表示するような細かい粒度に設定することもできます。 -## Klog +## klog -klog is the Kubernetes logging library. [klog](https://github.com/kubernetes/klog) -generates log messages for the Kubernetes system components. +klogは、Kubernetesのログライブラリです。[klog](https://github.com/kubernetes/klog)は、Kubernetesのシステムコンポーネント向けのログメッセージを生成します。 -For more information about klog configuration, see the [Command line tool reference](/docs/reference/command-line-tools-reference/). +klogの設定に関する詳しい情報については、[コマンドラインツールのリファレンス](/docs/reference/command-line-tools-reference/)を参照してください。 + +klogネイティブ形式の例: -An example of the klog native format: ``` I1025 00:15:15.525108 1 httplog.go:79] GET /api/v1/namespaces/kube-system/pods/metrics-server-v0.3.1-57c75779f-9p8wg: (1.512ms) 200 [pod_nanny/v0.0.0 (linux/amd64) kubernetes/$Format 10.56.1.19:51756] ``` -### Structured Logging +### 構造化ログ {{< feature-state for_k8s_version="v1.19" state="alpha" >}} {{< warning >}} -Migration to structured log messages is an ongoing process. Not all log messages are structured in this version. When parsing log files, you must also handle unstructured log messages. +構造化ログへのマイグレーションは現在進行中の作業です。このバージョンでは、すべてのログメッセージが構造化されているわけではありません。ログファイルをパースする場合、JSONではないログの行にも対処しなければなりません。 -Log formatting and value serialization are subject to change. +ログの形式と値のシリアライズは変更される可能性があります。 {{< /warning>}} -Structured logging introduces a uniform structure in log messages allowing for programmatic extraction of information. You can store and process structured logs with less effort and cost. -New message format is backward compatible and enabled by default. +構造化ログは、ログメッセージに単一の構造を導入し、プログラムで情報の抽出ができるようにするものです。構造化ログは、僅かな労力とコストで保存・処理できます。新しいメッセージ形式は後方互換性があり、デフォルトで有効化されます。 -Format of structured logs: +構造化ログの形式: ```ini "" ="" ="" ... ``` -Example: +例: ```ini I1025 00:15:15.525108 1 controller_utils.go:116] "Pod status updated" pod="kube-system/kubedns" status="ready" ``` -### JSON log format +### JSONログ形式 {{< feature-state for_k8s_version="v1.19" state="alpha" >}} {{}} -JSON output does not support many standard klog flags. For list of unsupported klog flags, see the [Command line tool reference](/docs/reference/command-line-tools-reference/). +JSONの出力は多数の標準のklogフラグをサポートしていません。非対応のklogフラグの一覧については、[コマンドラインツールリファレンス](/docs/reference/command-line-tools-reference/)を参照してください。 -Not all logs are guaranteed to be written in JSON format (for example, during process start). If you intend to parse logs, make sure you can handle log lines that are not JSON as well. +すべてのログがJSON形式で書き込むことに対応しているわけではありません(たとえば、プロセスの開始時など)。ログのパースを行おうとしている場合、JSONではないログの行に対処できるようにしてください。 -Field names and JSON serialization are subject to change. +フィールド名とJSONのシリアライズは変更される可能性があります。 {{< /warning >}} -The `--logging-format=json` flag changes the format of logs from klog native format to JSON format. -Example of JSON log format (pretty printed): +`--logging-format=json`フラグは、ログの形式をネイティブ形式klogからJSON形式に変更します。以下は、JSONログ形式の例(pretty printしたもの)です。 + ```json { "ts": 1580306777.04728, @@ -80,63 +74,53 @@ Example of JSON log format (pretty printed): } ``` -Keys with special meaning: -* `ts` - timestamp as Unix time (required, float) -* `v` - verbosity (required, int, default 0) -* `err` - error string (optional, string) -* `msg` - message (required, string) +特別な意味を持つキー: +* `ts` - Unix時間のタイムスタンプ(必須、float) +* `v` - verbosity (必須、int、デフォルトは0) +* `err` - エラー文字列 (オプション、string) +* `msg` - メッセージ (必須、string) - -List of components currently supporting JSON format: +現在サポートされているJSONフォーマットの一覧: * {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}} * {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} * {{< glossary_tooltip term_id="kube-scheduler" text="kube-scheduler" >}} * {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} -### Log sanitization +### ログのサニタイズ {{< feature-state for_k8s_version="v1.20" state="alpha" >}} {{}} -Log sanitization might incur significant computation overhead and therefore should not be enabled in production. +ログのサニタイズ大きな計算のオーバーヘッドを引き起こす可能性があるため、本番環境では有効にするべきではありません。 {{< /warning >}} -The `--experimental-logging-sanitization` flag enables the klog sanitization filter. -If enabled all log arguments are inspected for fields tagged as sensitive data (e.g. passwords, keys, tokens) and logging of these fields will be prevented. +`--experimental-logging-sanitization`フラグはklogのサニタイズフィルタを有効にします。有効にすると、すべてのログの引数が機密データ(パスワード、キー、トークンなど)としてタグ付けされたフィールドについて検査され、これらのフィールドのログの記録は防止されます。 -List of components currently supporting log sanitization: +現在ログのサニタイズをサポートしているコンポーネント一覧: * kube-controller-manager * kube-apiserver * kube-scheduler * kubelet {{< note >}} -The Log sanitization filter does not prevent user workload logs from leaking sensitive data. +ログのサニタイズフィルターは、ユーザーのワークロードのログが機密データを漏洩するのを防げるわけではありません。 {{< /note >}} -### Log verbosity level +### ログのverbosityレベル -The `-v` flag controls log verbosity. Increasing the value increases the number of logged events. Decreasing the value decreases the number of logged events. -Increasing verbosity settings logs increasingly less severe events. A verbosity setting of 0 logs only critical events. +`-v`フラグはログのverbosityを制御します。値を増やすとログに記録されるイベントの数が増えます。値を減らすとログに記録されるイベントの数が減ります。verbosityの設定を増やすと、ますます多くの深刻度の低いイベントをログに記録するようになります。verbosityの設定を0にすると、クリティカルなイベントだけをログに記録します。 -### Log location +### ログの場所 -There are two types of system components: those that run in a container and those -that do not run in a container. For example: +システムコンポーネントには2種類あります。コンテナ内で実行されるコンポーネントと、コンテナ内で実行されないコンポーネントです。たとえば、次のようなコンポーネントがあります。 -* The Kubernetes scheduler and kube-proxy run in a container. -* The kubelet and container runtime, for example Docker, do not run in containers. +* Kubernetesのスケジューラーやkube-proxyはコンテナ内で実行されます。 +* kubeletやDockerのようなコンテナランタイムはコンテナ内で実行されません。 -On machines with systemd, the kubelet and container runtime write to journald. -Otherwise, they write to `.log` files in the `/var/log` directory. -System components inside containers always write to `.log` files in the `/var/log` directory, -bypassing the default logging mechanism. -Similar to the container logs, you should rotate system component logs in the `/var/log` directory. -In Kubernetes clusters created by the `kube-up.sh` script, log rotation is configured by the `logrotate` tool. -The `logrotate` tool rotates logs daily, or once the log size is greater than 100MB. +systemdを使用しているマシンでは、kubeletとコンテナランタイムはjournaldに書き込みを行います。それ以外のマシンでは、`/var/log`ディレクトリ内の`.log`ファイルに書き込みます。コンテナ内部のシステムコンポーネントは、デフォルトのログ機構をバイパスするため、常に`/var/log`ディレクトリ内の`.log`ファイルに書き込みます。コンテナのログと同様に、`/var/log`ディレクトリ内のシステムコンポーネントのログはローテートする必要があります。`kube-up.sh`スクリプトによって作成されたKubernetesクラスターでは、ログローテーションは`logrotate`ツールで設定されます。`logrotate`ツールはログを1日ごとまたはログのサイズが100MBを超えたときにローテートします。 ## {{% heading "whatsnext" %}} -* Read about the [Kubernetes Logging Architecture](/docs/concepts/cluster-administration/logging/) -* Read about [Structured Logging](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1602-structured-logging) -* Read about the [Conventions for logging severity](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md) +* [Kubernetesのログのアーキテクチャ](/docs/concepts/cluster-administration/logging/)について読む。 +* [構造化ログ](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1602-structured-logging)について読む。 +* [ログの深刻度の慣習](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md)について読む。 From d3fd7174c7f66d00dd0008b80c119088849fa9e6 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Mon, 3 May 2021 11:37:13 +0900 Subject: [PATCH 026/128] Apply suggestions from code review Co-authored-by: makocchi --- content/ja/docs/concepts/cluster-administration/addons.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/concepts/cluster-administration/addons.md b/content/ja/docs/concepts/cluster-administration/addons.md index 72e9ebc39f..b50beb85f5 100644 --- a/content/ja/docs/concepts/cluster-administration/addons.md +++ b/content/ja/docs/concepts/cluster-administration/addons.md @@ -17,7 +17,7 @@ content_type: concept * [ACI](https://www.github.com/noironetworks/aci-containers)は、統合されたコンテナネットワークとネットワークセキュリティをCisco ACIを使用して提供します。 * [Antrea](https://antrea.io/)は、L3またはL4で動作して、Open vSwitchをネットワークデータプレーンとして活用する、Kubernetes向けのネットワークとセキュリティサービスを提供します。 -* [Calico](https://docs.projectcalico.org/latest/introduction/)はネットワークとネットワークプリシーのプロバイダーです。Calicoは、BGPを使用または未使用の非オーバーレイおよびオーバーレイネットワークを含む、フレキシブルなさまざまなネットワークオプションサポートします。Calicoはホスト、Pod、そして(IstioとEnvoyを使用している場合には)サービスメッシュ上のアプリケーションに対してネットワークポリシーを強制するために、同一のエンジンを使用します。 +* [Calico](https://docs.projectcalico.org/latest/introduction/)はネットワークとネットワークプリシーのプロバイダーです。Calicoは、BGPを使用または未使用の非オーバーレイおよびオーバーレイネットワークを含む、フレキシブルなさまざまなネットワークオプションをサポートします。Calicoはホスト、Pod、そして(IstioとEnvoyを使用している場合には)サービスメッシュ上のアプリケーションに対してネットワークポリシーを強制するために、同一のエンジンを使用します。 * [Canal](https://github.com/tigera/canal/tree/master/k8s-install)はFlannelとCalicoをあわせたもので、ネットワークとネットワークポリシーを提供します。 * [Cilium](https://github.com/cilium/cilium)は、L3のネットワークとネットワークポリシーのプラグインで、HTTP/API/L7のポリシーを透過的に強制できます。ルーティングとoverlay/encapsulationモードの両方をサポートしており、他のCNIプラグイン上で機能できます。 * [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie)は、KubernetesをCalico、Canal、Flannel、Romana、Weaveなど選択したCNIプラグインをシームレスに接続できるようにするプラグインです。 @@ -25,7 +25,7 @@ content_type: concept * [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/)は、[Tungsten Fabric](https://tungsten.io)をベースにしている、オープンソースでマルチクラウドに対応したネットワーク仮想化およびポリシー管理プラットフォームです。ContrailおよびTungsten Fabricは、Kubernetes、OpenShift、OpenStack、Mesosなどのオーケストレーションシステムと統合されており、仮想マシン、コンテナ/Pod、ベアメタルのワークロードに隔離モードを提供します。 * [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kubernetes.md)は、Kubernetesで使用できるオーバーレイネットワークプロバイダーです。 * [Knitter](https://github.com/ZTE/Knitter/)は、1つのKubernetes Podで複数のネットワークインターフェイスをサポートするためのプラグインです。 -* [Multus](https://github.com/Intel-Corp/multus-cni)は、すべてのCNIプラグイン(たとえば、Calico、Cilium、Contiv、Flannel)に加えて、SRIOV、DPDK、OVS-DPDK、VPPをベースとするKubernetes上のワークロードをサポートする、複数のネットワークサポートのためのMultiプラグインです。 +* [Multus](https://github.com/Intel-Corp/multus-cni)は、すべてのCNIプラグイン(たとえば、Calico、Cilium、Contiv、Flannel)に加えて、SRIOV、DPDK、OVS-DPDK、VPPをベースとするKubernetes上のワークロードをサポートする、複数のネットワークサポートのためのマルチプラグインです。 * [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/)は、Open vSwitch(OVS)プロジェクトから生まれた仮想ネットワーク実装である[OVN(Open Virtual Network)](https://github.com/ovn-org/ovn/)をベースとする、Kubernetesのためのネットワークプロバイダです。OVN-Kubernetesは、OVSベースのロードバランサーおよびネットワークポリシーの実装を含む、Kubernetes向けのオーバーレイベースのネットワーク実装を提供します。 * [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin)は、クラウドネイティブベースのService function chaining(SFC)、Multiple OVNオーバーレイネットワーク、動的なサブネットの作成、動的な仮想ネットワークの作成、VLANプロバイダーネットワーク、Directプロバイダーネットワークを提供し、他のMulti-networkプラグインと付け替え可能なOVNベースのCNIコントローラープラグインです。 * [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in(NCP)は、VMware NSX-TとKubernetesなどのコンテナオーケストレーター間のインテグレーションを提供します。また、NSX-Tと、Pivotal Container Service(PKS)とOpenShiftなどのコンテナベースのCaaS/PaaSプラットフォームとのインテグレーションも提供します。 @@ -50,4 +50,4 @@ content_type: concept いくつかのアドオンは、廃止された[cluster/addons](https://git.k8s.io/kubernetes/cluster/addons)ディレクトリに掲載されています。 -よくメンテナンスされたアドオンはここにリンクしてください。PRを歓迎しています。 \ No newline at end of file +よくメンテナンスされたアドオンはここにリンクしてください。PRを歓迎しています。 From fdb56e4070a29147d38ec10b44381d135de2c7df Mon Sep 17 00:00:00 2001 From: Jai Govindani Date: Fri, 7 May 2021 18:54:57 +0700 Subject: [PATCH 027/128] chore(kubectl-cmds): add redirect to skip reundant page Signed-off-by: Jai Govindani --- static/_redirects | 1 + 1 file changed, 1 insertion(+) diff --git a/static/_redirects b/static/_redirects index 1f6e9f29bc..a95506d1e4 100644 --- a/static/_redirects +++ b/static/_redirects @@ -204,6 +204,7 @@ /docs/reference/glossary/maintainer/ /docs/reference/glossary/approver/ 301 +/docs/reference/kubectl/kubectl-cmds/ https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands/ 301 /docs/reference/kubectl/kubectl/kubectl_*.md /docs/reference/generated/kubectl/kubectl-commands#:splat 301 /docs/reference/scheduling/profiles/ /docs/reference/scheduling/config/#profiles 301 From b0f9d9f07414c3c58202d11d707ef8f007ac6825 Mon Sep 17 00:00:00 2001 From: Jai Govindani Date: Sat, 8 May 2021 12:40:01 +0700 Subject: [PATCH 028/128] fix(redirects): update broken /contribute/participating/ redirect Signed-off-by: Jai Govindani --- static/_redirects | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/static/_redirects b/static/_redirects index 1f6e9f29bc..1549d08169 100644 --- a/static/_redirects +++ b/static/_redirects @@ -183,7 +183,7 @@ /docs/home/contribute/generated-reference/kubernetes-components/ /docs/contribute/generate-ref-docs/kubernetes-components/ 301 /docs/home/contribute/localization/ /docs/contribute/localization/ 301 /docs/home/contribute/page-templates/ /docs/contribute/style/page-templates/ 301 -/docs/home/contribute/participating/ /docs/contribute/participating/ 301 +/docs/home/contribute/participating/ /docs/contribute/participate/ 301 /docs/home/contribute/review-issues/ /docs/contribute/intermediate/ 301 /docs/home/contribute/blog-post/ /docs/contribute/start/ 301 /docs/home/contribute/write-new-topic/ /docs/contribute/style/write-new-topic/ 301 From cb894d47f2809fc18f78b2edd75544f75e1dff87 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Sun, 9 May 2021 09:37:42 +0000 Subject: [PATCH 029/128] Copy content/en/docs/concepts/configuration/organize-cluster-access-kubeconfig.md for translation --- .../organize-cluster-access-kubeconfig.md | 157 ++++++++++++++++++ 1 file changed, 157 insertions(+) create mode 100644 content/ja/docs/concepts/configuration/organize-cluster-access-kubeconfig.md diff --git a/content/ja/docs/concepts/configuration/organize-cluster-access-kubeconfig.md b/content/ja/docs/concepts/configuration/organize-cluster-access-kubeconfig.md new file mode 100644 index 0000000000..df767bbc3e --- /dev/null +++ b/content/ja/docs/concepts/configuration/organize-cluster-access-kubeconfig.md @@ -0,0 +1,157 @@ +--- +title: Organizing Cluster Access Using kubeconfig Files +content_type: concept +weight: 60 +--- + + + +Use kubeconfig files to organize information about clusters, users, namespaces, and +authentication mechanisms. The `kubectl` command-line tool uses kubeconfig files to +find the information it needs to choose a cluster and communicate with the API server +of a cluster. + +{{< note >}} +A file that is used to configure access to clusters is called +a *kubeconfig file*. This is a generic way of referring to configuration files. +It does not mean that there is a file named `kubeconfig`. +{{< /note >}} + +By default, `kubectl` looks for a file named `config` in the `$HOME/.kube` directory. +You can specify other kubeconfig files by setting the `KUBECONFIG` environment +variable or by setting the +[`--kubeconfig`](/docs/reference/generated/kubectl/kubectl/) flag. + +For step-by-step instructions on creating and specifying kubeconfig files, see +[Configure Access to Multiple Clusters](/docs/tasks/access-application-cluster/configure-access-multiple-clusters). + + + + + + +## Supporting multiple clusters, users, and authentication mechanisms + +Suppose you have several clusters, and your users and components authenticate +in a variety of ways. For example: + +- A running kubelet might authenticate using certificates. +- A user might authenticate using tokens. +- Administrators might have sets of certificates that they provide to individual users. + +With kubeconfig files, you can organize your clusters, users, and namespaces. +You can also define contexts to quickly and easily switch between +clusters and namespaces. + +## Context + +A *context* element in a kubeconfig file is used to group access parameters +under a convenient name. Each context has three parameters: cluster, namespace, and user. +By default, the `kubectl` command-line tool uses parameters from +the *current context* to communicate with the cluster. + +To choose the current context: +``` +kubectl config use-context +``` + +## The KUBECONFIG environment variable + +The `KUBECONFIG` environment variable holds a list of kubeconfig files. +For Linux and Mac, the list is colon-delimited. For Windows, the list +is semicolon-delimited. The `KUBECONFIG` environment variable is not +required. If the `KUBECONFIG` environment variable doesn't exist, +`kubectl` uses the default kubeconfig file, `$HOME/.kube/config`. + +If the `KUBECONFIG` environment variable does exist, `kubectl` uses +an effective configuration that is the result of merging the files +listed in the `KUBECONFIG` environment variable. + +## Merging kubeconfig files + +To see your configuration, enter this command: + +```shell +kubectl config view +``` + +As described previously, the output might be from a single kubeconfig file, +or it might be the result of merging several kubeconfig files. + +Here are the rules that `kubectl` uses when it merges kubeconfig files: + +1. If the `--kubeconfig` flag is set, use only the specified file. Do not merge. + Only one instance of this flag is allowed. + + Otherwise, if the `KUBECONFIG` environment variable is set, use it as a + list of files that should be merged. + Merge the files listed in the `KUBECONFIG` environment variable + according to these rules: + + * Ignore empty filenames. + * Produce errors for files with content that cannot be deserialized. + * The first file to set a particular value or map key wins. + * Never change the value or map key. + Example: Preserve the context of the first file to set `current-context`. + Example: If two files specify a `red-user`, use only values from the first file's `red-user`. + Even if the second file has non-conflicting entries under `red-user`, discard them. + + For an example of setting the `KUBECONFIG` environment variable, see + [Setting the KUBECONFIG environment variable](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable). + + Otherwise, use the default kubeconfig file, `$HOME/.kube/config`, with no merging. + +1. Determine the context to use based on the first hit in this chain: + + 1. Use the `--context` command-line flag if it exists. + 1. Use the `current-context` from the merged kubeconfig files. + + An empty context is allowed at this point. + +1. Determine the cluster and user. At this point, there might or might not be a context. + Determine the cluster and user based on the first hit in this chain, + which is run twice: once for user and once for cluster: + + 1. Use a command-line flag if it exists: `--user` or `--cluster`. + 1. If the context is non-empty, take the user or cluster from the context. + + The user and cluster can be empty at this point. + +1. Determine the actual cluster information to use. At this point, there might or + might not be cluster information. + Build each piece of the cluster information based on this chain; the first hit wins: + + 1. Use command line flags if they exist: `--server`, `--certificate-authority`, `--insecure-skip-tls-verify`. + 1. If any cluster information attributes exist from the merged kubeconfig files, use them. + 1. If there is no server location, fail. + +1. Determine the actual user information to use. Build user information using the same + rules as cluster information, except allow only one authentication + technique per user: + + 1. Use command line flags if they exist: `--client-certificate`, `--client-key`, `--username`, `--password`, `--token`. + 1. Use the `user` fields from the merged kubeconfig files. + 1. If there are two conflicting techniques, fail. + +1. For any information still missing, use default values and potentially + prompt for authentication information. + +## File references + +File and path references in a kubeconfig file are relative to the location of the kubeconfig file. +File references on the command line are relative to the current working directory. +In `$HOME/.kube/config`, relative paths are stored relatively, and absolute paths +are stored absolutely. + + + + +## {{% heading "whatsnext" %}} + + +* [Configure Access to Multiple Clusters](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) +* [`kubectl config`](/docs/reference/generated/kubectl/kubectl-commands#config) + + + + From a359a219591a834f6320a5b0dd5c7c4dee966015 Mon Sep 17 00:00:00 2001 From: Simon Bauer Date: Mon, 10 May 2021 15:39:32 +0200 Subject: [PATCH 030/128] Updated Feature Gate "TTLAfterFinished" According to https://github.com/kubernetes/kubernetes/pull/98678 and the release notes for 1.21 the feature gate `TTLAfterFinished` is in beta now and enable by default. This change is not yet reflected in the Feature Gates documentation. --- .../reference/command-line-tools-reference/feature-gates.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates.md b/content/en/docs/reference/command-line-tools-reference/feature-gates.md index 849af9f00b..9e9aced3d0 100644 --- a/content/en/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/en/docs/reference/command-line-tools-reference/feature-gates.md @@ -173,7 +173,8 @@ different Kubernetes components. | `StorageVersionHash` | `false` | Alpha | 1.14 | 1.14 | | `StorageVersionHash` | `true` | Beta | 1.15 | | | `SuspendJob` | `false` | Alpha | 1.21 | | -| `TTLAfterFinished` | `false` | Alpha | 1.12 | | +| `TTLAfterFinished` | `false` | Alpha | 1.12 | 1.20 | +| `TTLAfterFinished` | `true` | Beta | 1.21 | | | `TopologyAwareHints` | `false` | Alpha | 1.21 | | | `TopologyManager` | `false` | Alpha | 1.16 | 1.17 | | `TopologyManager` | `true` | Beta | 1.18 | | From 939f0881abbf33cebdf8e51838fce9c0529781ce Mon Sep 17 00:00:00 2001 From: Jai Govindani Date: Tue, 11 May 2021 12:15:59 +0700 Subject: [PATCH 031/128] fix(redirects): spacing Signed-off-by: Jai Govindani --- static/_redirects | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/static/_redirects b/static/_redirects index a95506d1e4..0c04b14703 100644 --- a/static/_redirects +++ b/static/_redirects @@ -204,7 +204,7 @@ /docs/reference/glossary/maintainer/ /docs/reference/glossary/approver/ 301 -/docs/reference/kubectl/kubectl-cmds/ https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands/ 301 +/docs/reference/kubectl/kubectl-cmds/ /docs/reference/generated/kubectl/kubectl-commands/ 301 /docs/reference/kubectl/kubectl/kubectl_*.md /docs/reference/generated/kubectl/kubectl-commands#:splat 301 /docs/reference/scheduling/profiles/ /docs/reference/scheduling/config/#profiles 301 From 0e8b3e4aa818f764b6e90a30f1dd31cff044fa3f Mon Sep 17 00:00:00 2001 From: Arhell Date: Wed, 12 May 2021 00:43:17 +0300 Subject: [PATCH 032/128] [ja] Update HAProxy Protocol Link --- content/ja/docs/tutorials/services/source-ip.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tutorials/services/source-ip.md b/content/ja/docs/tutorials/services/source-ip.md index 505ba8ef45..6e52a1c9b3 100644 --- a/content/ja/docs/tutorials/services/source-ip.md +++ b/content/ja/docs/tutorials/services/source-ip.md @@ -392,7 +392,7 @@ client_address=198.51.100.79 2. クライアントからロードバランサーのVIPに送信されたリクエストが、中間のプロキシーではなく、クライアントの送信元IPとともにノードまで到達するようなパケット転送が使用される。 -1つめのカテゴリーのロードバランサーの場合、真のクライアントIPと通信するために、 HTTPの[Forwarded](https://tools.ietf.org/html/rfc7239#section-5.2)ヘッダーや[X-FORWARDED-FOR](https://ja.wikipedia.org/wiki/X-Forwarded-For)ヘッダー、[proxy protocol](https://www.haproxy.org/download/1.5/doc/proxy-protocol.txt)などの、ロードバランサーとバックエンドの間で合意されたプロトコルを使用する必要があります。2つ目のカテゴリーのロードバランサーの場合、Serviceの`service.spec.healthCheckNodePort`フィールドに保存されたポートを指すHTTPのヘルスチェックを作成することで、上記の機能を活用できます。 +1つめのカテゴリーのロードバランサーの場合、真のクライアントIPと通信するために、 HTTPの[Forwarded](https://tools.ietf.org/html/rfc7239#section-5.2)ヘッダーや[X-FORWARDED-FOR](https://ja.wikipedia.org/wiki/X-Forwarded-For)ヘッダー、[proxy protocol](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)などの、ロードバランサーとバックエンドの間で合意されたプロトコルを使用する必要があります。2つ目のカテゴリーのロードバランサーの場合、Serviceの`service.spec.healthCheckNodePort`フィールドに保存されたポートを指すHTTPのヘルスチェックを作成することで、上記の機能を活用できます。 ## {{% heading "cleanup" %}} From 4da06b09308459e3cbdf2dd6aaa0fe487660435e Mon Sep 17 00:00:00 2001 From: Kenaniah Cerny Date: Thu, 13 May 2021 16:15:26 -0700 Subject: [PATCH 033/128] Fixes a small typo --- .../docs/concepts/services-networking/topology-aware-hints.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/services-networking/topology-aware-hints.md b/content/en/docs/concepts/services-networking/topology-aware-hints.md index c2c15878ff..f471caff6b 100644 --- a/content/en/docs/concepts/services-networking/topology-aware-hints.md +++ b/content/en/docs/concepts/services-networking/topology-aware-hints.md @@ -13,7 +13,7 @@ weight: 45 _Topology Aware Hints_ enable topology aware routing by including suggestions for how clients should consume endpoints. This approach adds metadata to enable -consumers of EndpointSlice and / or and Endpoints objects, so that traffic to +consumers of EndpointSlice and / or Endpoints objects, so that traffic to those network endpoints can be routed closer to where it originated. For example, you can route traffic within a locality to reduce From c315df3c0f187e94979d7cc15b4d2dc8a7fdef98 Mon Sep 17 00:00:00 2001 From: Steven Pitts <25968054+makusu2@users.noreply.github.com> Date: Fri, 14 May 2021 12:12:48 -0400 Subject: [PATCH 034/128] Clarify what must be the same When reading these sentences, I thought that each pod must have the same values as each other pod. In other words, pod1's memory limit must equal pod2's memory limit. It looks like I misunderstood; "must be the same" means that the limit and request values on each individual pod must match. Clarify what "must be the same". --- .../docs/tasks/configure-pod-container/quality-service-pod.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/en/docs/tasks/configure-pod-container/quality-service-pod.md b/content/en/docs/tasks/configure-pod-container/quality-service-pod.md index 0e6a02af37..93204b86e0 100644 --- a/content/en/docs/tasks/configure-pod-container/quality-service-pod.md +++ b/content/en/docs/tasks/configure-pod-container/quality-service-pod.md @@ -45,8 +45,8 @@ kubectl create namespace qos-example For a Pod to be given a QoS class of Guaranteed: -* Every Container, including init containers, in the Pod must have a memory limit and a memory request, and they must be the same. -* Every Container, including init containers, in the Pod must have a CPU limit and a CPU request, and they must be the same. +* Every Container, including init containers, in the Pod must have a memory limit and a memory request, and the two values must be the same. +* Every Container, including init containers, in the Pod must have a CPU limit and a CPU request, and the two values must be the same. Here is the configuration file for a Pod that has one Container. The Container has a memory limit and a memory request, both equal to 200 MiB. The Container has a CPU limit and a CPU request, both equal to 700 milliCPU: From b8ab5835b9ebcf24f2781f2cc3bf885cb17c7670 Mon Sep 17 00:00:00 2001 From: Abigail McCarthy Date: Fri, 14 May 2021 17:12:27 -0400 Subject: [PATCH 035/128] Add page for analytics dashboard --- content/en/docs/contribute/analytics.md | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) create mode 100644 content/en/docs/contribute/analytics.md diff --git a/content/en/docs/contribute/analytics.md b/content/en/docs/contribute/analytics.md new file mode 100644 index 0000000000..5fc5adf837 --- /dev/null +++ b/content/en/docs/contribute/analytics.md @@ -0,0 +1,25 @@ +--- +title: Viewing site analytics +content_type: concept +weight: 100 +card: + name: contribute + weight: 100 +--- + + + +This page contains information about the kubernetes.io analytics dashboard. + + + + +[View the dashboard.](https://datastudio.google.com/u/0/reporting/fede2672-b2fd-402a-91d2-7473bdb10f04/page/567IC/edit) + +This dashboard is built using Google Data Studio and shows information collected on kubernetes.io using Google Analytics. + +### Using the dashboard + +By default, the dashboard will show all collected analytics for the past 30 days. Use the date selector to see data from a different date range. Other filtering options allow you to view data based on user location, the device used to access the site, the translation of the docs used, and more. + + If you notice an issue with this dashboard, or would like to request any improvements, please open an issue. From 3a8af16d5700049bb003a5dd2ca751f00d405981 Mon Sep 17 00:00:00 2001 From: Abigail McCarthy Date: Mon, 17 May 2021 08:39:39 -0400 Subject: [PATCH 036/128] Update with nits from reviews --- content/en/docs/contribute/analytics.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/en/docs/contribute/analytics.md b/content/en/docs/contribute/analytics.md index 5fc5adf837..6c8e56be43 100644 --- a/content/en/docs/contribute/analytics.md +++ b/content/en/docs/contribute/analytics.md @@ -14,7 +14,7 @@ This page contains information about the kubernetes.io analytics dashboard. -[View the dashboard.](https://datastudio.google.com/u/0/reporting/fede2672-b2fd-402a-91d2-7473bdb10f04/page/567IC/edit) +[View the dashboard](https://datastudio.google.com/reporting/fede2672-b2fd-402a-91d2-7473bdb10f04). This dashboard is built using Google Data Studio and shows information collected on kubernetes.io using Google Analytics. @@ -22,4 +22,4 @@ This dashboard is built using Google Data Studio and shows information collected By default, the dashboard will show all collected analytics for the past 30 days. Use the date selector to see data from a different date range. Other filtering options allow you to view data based on user location, the device used to access the site, the translation of the docs used, and more. - If you notice an issue with this dashboard, or would like to request any improvements, please open an issue. + If you notice an issue with this dashboard, or would like to request any improvements, please [open an issue](https://github.com/kubernetes/website/issues/new/choose). From 097292f485f920fcb18a797091bf6a672b4aca49 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Fran=C3=A7ois?= <32224751+AsterYujano@users.noreply.github.com> Date: Wed, 19 May 2021 23:05:01 +0200 Subject: [PATCH 037/128] Update kustomization.md Fix typo for the *volumeMount* field Running the previous snippets with `kubectl apply -k .` would generate this error: ``` error validating ".": error validating data: ValidationError(Deployment.spec.template.spec.containers[0]): unknown field "volumeMount" in io.k8s.api.core.v1.Container; ``` According to [this page](https://kubernetes.io/docs/concepts/storage/volumes/), the correct field is "volumeMounts". --- .../docs/tasks/manage-kubernetes-objects/kustomization.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/en/docs/tasks/manage-kubernetes-objects/kustomization.md b/content/en/docs/tasks/manage-kubernetes-objects/kustomization.md index 27f3762988..9b16c25167 100644 --- a/content/en/docs/tasks/manage-kubernetes-objects/kustomization.md +++ b/content/en/docs/tasks/manage-kubernetes-objects/kustomization.md @@ -180,7 +180,7 @@ spec: containers: - name: app image: my-app - volumeMount: + volumeMounts: - name: config mountPath: /config volumes: @@ -234,7 +234,7 @@ spec: containers: - image: my-app name: app - volumeMount: + volumeMounts: - mountPath: /config name: config volumes: @@ -327,7 +327,7 @@ spec: containers: - name: app image: my-app - volumeMount: + volumeMounts: - name: password mountPath: /secrets volumes: From 010374113893b178910f1599f3b76bccaa9fda33 Mon Sep 17 00:00:00 2001 From: Steven Pitts <25968054+makusu2@users.noreply.github.com> Date: Wed, 19 May 2021 17:23:05 -0400 Subject: [PATCH 038/128] Update content/en/docs/tasks/configure-pod-container/quality-service-pod.md Co-authored-by: Tim Bannister --- .../tasks/configure-pod-container/quality-service-pod.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/content/en/docs/tasks/configure-pod-container/quality-service-pod.md b/content/en/docs/tasks/configure-pod-container/quality-service-pod.md index 93204b86e0..ca74cf2a47 100644 --- a/content/en/docs/tasks/configure-pod-container/quality-service-pod.md +++ b/content/en/docs/tasks/configure-pod-container/quality-service-pod.md @@ -45,7 +45,12 @@ kubectl create namespace qos-example For a Pod to be given a QoS class of Guaranteed: -* Every Container, including init containers, in the Pod must have a memory limit and a memory request, and the two values must be the same. +* Every Container in the Pod must have a memory limit and a memory request. +* For every Container in the Pod, the memory limit must equal the memory request. +* Every Container in the Pod must have a CPU limit and a CPU request. +* For every Container in the Pod, the CPU limit must equal the CPU request. + +These restrictions apply to init containers and app containers equally. * Every Container, including init containers, in the Pod must have a CPU limit and a CPU request, and the two values must be the same. Here is the configuration file for a Pod that has one Container. The Container has a memory limit and a @@ -273,4 +278,3 @@ kubectl delete namespace qos-example - From e72b6ace24f7a8297e2c5e6560f632ac1001d79b Mon Sep 17 00:00:00 2001 From: Steven Pitts <25968054+makusu2@users.noreply.github.com> Date: Thu, 20 May 2021 09:03:46 -0400 Subject: [PATCH 039/128] Update content/en/docs/tasks/configure-pod-container/quality-service-pod.md --- .../docs/tasks/configure-pod-container/quality-service-pod.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/content/en/docs/tasks/configure-pod-container/quality-service-pod.md b/content/en/docs/tasks/configure-pod-container/quality-service-pod.md index ca74cf2a47..abe6320563 100644 --- a/content/en/docs/tasks/configure-pod-container/quality-service-pod.md +++ b/content/en/docs/tasks/configure-pod-container/quality-service-pod.md @@ -51,7 +51,6 @@ For a Pod to be given a QoS class of Guaranteed: * For every Container in the Pod, the CPU limit must equal the CPU request. These restrictions apply to init containers and app containers equally. -* Every Container, including init containers, in the Pod must have a CPU limit and a CPU request, and the two values must be the same. Here is the configuration file for a Pod that has one Container. The Container has a memory limit and a memory request, both equal to 200 MiB. The Container has a CPU limit and a CPU request, both equal to 700 milliCPU: @@ -277,4 +276,3 @@ kubectl delete namespace qos-example - From ccc61c87fc72b9f0f59012061f6da4d9894ed295 Mon Sep 17 00:00:00 2001 From: Vitaliy Date: Thu, 20 May 2021 18:49:59 -0400 Subject: [PATCH 040/128] Clarify that Docker registry secrets are using type kubernetes.io/dockerconfigjson --- .../configure-pod-container/pull-image-private-registry.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/tasks/configure-pod-container/pull-image-private-registry.md b/content/en/docs/tasks/configure-pod-container/pull-image-private-registry.md index 697a4c6e0e..57c5329b7a 100644 --- a/content/en/docs/tasks/configure-pod-container/pull-image-private-registry.md +++ b/content/en/docs/tasks/configure-pod-container/pull-image-private-registry.md @@ -54,7 +54,7 @@ If you use a Docker credentials store, you won't see that `auth` entry but a `cr ## Create a Secret based on existing Docker credentials {#registry-secret-existing-credentials} -A Kubernetes cluster uses the Secret of `docker-registry` type to authenticate with +A Kubernetes cluster uses the Secret of `kubernetes.io/dockerconfigjson` type to authenticate with a container registry to pull a private image. If you already ran `docker login`, you can copy that credential into Kubernetes: From e4550dc6204284703620dedd3da722e7f99c6a2a Mon Sep 17 00:00:00 2001 From: ms-choudhary Date: Fri, 21 May 2021 13:38:42 +0530 Subject: [PATCH 041/128] Fix: List all unique container images --- .../list-all-running-container-images.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/en/docs/tasks/access-application-cluster/list-all-running-container-images.md b/content/en/docs/tasks/access-application-cluster/list-all-running-container-images.md index 3a8983eec8..133eae902b 100644 --- a/content/en/docs/tasks/access-application-cluster/list-all-running-container-images.md +++ b/content/en/docs/tasks/access-application-cluster/list-all-running-container-images.md @@ -23,7 +23,7 @@ of Containers for each. - Fetch all Pods in all namespaces using `kubectl get pods --all-namespaces` - Format the output to include only the list of Container image names - using `-o jsonpath={..image}`. This will recursively parse out the + using `-o jsonpath={.items[*].spec.containers[*].image}`. This will recursively parse out the `image` field from the returned json. - See the [jsonpath reference](/docs/reference/kubectl/jsonpath/) for further information on how to use jsonpath. @@ -33,7 +33,7 @@ of Containers for each. - Use `uniq` to aggregate image counts ```shell -kubectl get pods --all-namespaces -o jsonpath="{..image}" |\ +kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" |\ tr -s '[[:space:]]' '\n' |\ sort |\ uniq -c @@ -80,7 +80,7 @@ To target only Pods matching a specific label, use the -l flag. The following matches only Pods with labels matching `app=nginx`. ```shell -kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx +kubectl get pods --all-namespaces -o=jsonpath="{.items[*].spec.containers[*].image}" -l app=nginx ``` ## List Container images filtering by Pod namespace @@ -89,7 +89,7 @@ To target only pods in a specific namespace, use the namespace flag. The following matches only Pods in the `kube-system` namespace. ```shell -kubectl get pods --namespace kube-system -o jsonpath="{..image}" +kubectl get pods --namespace kube-system -o jsonpath="{.items[*].spec.containers[*].image}" ``` ## List Container images using a go-template instead of jsonpath From 259bdd284869c34c133d75d59020ceaaccb78972 Mon Sep 17 00:00:00 2001 From: Martin Kanters Date: Sun, 23 May 2021 11:28:44 +0200 Subject: [PATCH 042/128] Deleted reference to removed file --- .../docs/contribute/generate-ref-docs/contribute-upstream.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/content/en/docs/contribute/generate-ref-docs/contribute-upstream.md b/content/en/docs/contribute/generate-ref-docs/contribute-upstream.md index 5f4edbcc77..656f8c971b 100644 --- a/content/en/docs/contribute/generate-ref-docs/contribute-upstream.md +++ b/content/en/docs/contribute/generate-ref-docs/contribute-upstream.md @@ -134,7 +134,6 @@ Go to `` and run these scripts: hack/update-generated-swagger-docs.sh hack/update-openapi-spec.sh hack/update-generated-protobuf.sh -hack/update-api-reference-docs.sh ``` Run `git status` to see what was generated. @@ -143,8 +142,6 @@ Run `git status` to see what was generated. On branch master ... modified: api/openapi-spec/swagger.json - modified: api/swagger-spec/apps_v1.json - modified: docs/api-reference/apps/v1/definitions.html modified: staging/src/k8s.io/api/apps/v1/generated.proto modified: staging/src/k8s.io/api/apps/v1/types.go modified: staging/src/k8s.io/api/apps/v1/types_swagger_doc_generated.go From 47a137594b2fb254986b4aefa83046b8e0726cb4 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Sun, 9 May 2021 10:05:59 +0000 Subject: [PATCH 043/128] Translate concepts/configuration/organize-cluster-access-kubeconfig into Japanese --- .../organize-cluster-access-kubeconfig.md | 145 ++++++------------ .../configure-access-multiple-clusters.md | 2 +- 2 files changed, 52 insertions(+), 95 deletions(-) diff --git a/content/ja/docs/concepts/configuration/organize-cluster-access-kubeconfig.md b/content/ja/docs/concepts/configuration/organize-cluster-access-kubeconfig.md index df767bbc3e..b3ed117931 100644 --- a/content/ja/docs/concepts/configuration/organize-cluster-access-kubeconfig.md +++ b/content/ja/docs/concepts/configuration/organize-cluster-access-kubeconfig.md @@ -1,155 +1,112 @@ --- -title: Organizing Cluster Access Using kubeconfig Files +title: kubeconfigファイルを使用してクラスターアクセスを組織する content_type: concept weight: 60 --- -Use kubeconfig files to organize information about clusters, users, namespaces, and -authentication mechanisms. The `kubectl` command-line tool uses kubeconfig files to -find the information it needs to choose a cluster and communicate with the API server -of a cluster. +kubeconfigを使用すると、クラスターに、ユーザー、名前空間、認証の仕組みに関する情報を組織できます。`kubectl`コマンドラインツールはkubeconfigファイルを使用してクラスターを選択するために必要な情報を見つけ、クラスターのAPIサーバーと通信します。 {{< note >}} -A file that is used to configure access to clusters is called -a *kubeconfig file*. This is a generic way of referring to configuration files. -It does not mean that there is a file named `kubeconfig`. +クラスターへのアクセスを設定するために使われるファイルは*kubeconfigファイル*と呼ばれます。これは設定ファイルを指すために使われる一般的な方法です。`kubeconfig`という名前を持つファイルが存在するという意味ではありません。 {{< /note >}} -By default, `kubectl` looks for a file named `config` in the `$HOME/.kube` directory. -You can specify other kubeconfig files by setting the `KUBECONFIG` environment -variable or by setting the -[`--kubeconfig`](/docs/reference/generated/kubectl/kubectl/) flag. - -For step-by-step instructions on creating and specifying kubeconfig files, see -[Configure Access to Multiple Clusters](/docs/tasks/access-application-cluster/configure-access-multiple-clusters). - - +デフォルトでは、`kubectl`は`$HOME/.kube`ディレクトリ内にある`config`という名前のファイルを探します。`KUBECONFIG`環境変数を設定するか、[`--kubeconfig`](/docs/reference/generated/kubectl/kubectl/)フラグで指定することで、別のkubeconfigファイルを指定することもできます。 +kubeconfigファイルの作成と指定に関するステップバイステップの手順を知りたいときは、[複数のクラスターへのアクセスを設定する](/docs/tasks/access-application-cluster/configure-access-multiple-clusters)を参照してください。 -## Supporting multiple clusters, users, and authentication mechanisms +## 複数のクラスター、ユーザ、認証の仕組みのサポート -Suppose you have several clusters, and your users and components authenticate -in a variety of ways. For example: +複数のクラスターを持っていて、ユーザーやコンポーネントがさまざまな方法で認証を行う次のような状況を考えてみます。 -- A running kubelet might authenticate using certificates. -- A user might authenticate using tokens. -- Administrators might have sets of certificates that they provide to individual users. +- 実行中のkubeletが証明書を使用して認証を行う可能性がある。 +- ユーザーがトークンを使用して認証を行う可能性がある。 +- 管理者が個別のユーザに提供する複数の証明書を持っている可能性がある。 -With kubeconfig files, you can organize your clusters, users, and namespaces. -You can also define contexts to quickly and easily switch between -clusters and namespaces. +kubeconfigファイルを使用すると、クラスター、ユーザー、名前空間を組織化することができます。また、contextを定義することで、複数のクラスターや名前空間を素早く簡単に切り替えられます。 ## Context -A *context* element in a kubeconfig file is used to group access parameters -under a convenient name. Each context has three parameters: cluster, namespace, and user. -By default, the `kubectl` command-line tool uses parameters from -the *current context* to communicate with the cluster. +kubeconfigファイルの*context*要素は、アクセスパラメーターを使いやすい名前でグループ化するために使われます。各contextは3つのパラメータ、cluster、namespace、userを持ちます。デフォルトでは、`kubectl`コマンドラインツールはクラスターとの通信に*current context*のパラメーターを使用します。 + +current contextを選択するには、以下のコマンドを使用します。 -To choose the current context: ``` kubectl config use-context ``` -## The KUBECONFIG environment variable +## KUBECONFIG環境変数 -The `KUBECONFIG` environment variable holds a list of kubeconfig files. -For Linux and Mac, the list is colon-delimited. For Windows, the list -is semicolon-delimited. The `KUBECONFIG` environment variable is not -required. If the `KUBECONFIG` environment variable doesn't exist, -`kubectl` uses the default kubeconfig file, `$HOME/.kube/config`. +`KUBECONFIG`環境変数には、kubeconfigファイルのリストを指定できます。LinuxとMacでは、リストはコロン区切りです。Windowsでは、セミコロン区切りです。`KUBECONFIG`環境変数は必須ではありません。`KUBECONFIG`環境変数が存在しない場合は、`kubectl`はデフォルトのkubeconfigファイルである`$HOME/.kube/config`を使用します。 -If the `KUBECONFIG` environment variable does exist, `kubectl` uses -an effective configuration that is the result of merging the files -listed in the `KUBECONFIG` environment variable. +`KUBECONFIG`環境変数が存在する場合は、`kubectl`は`KUBECONFIG`環境変数にリストされているファイルをマージした結果を有効な設定として使用します。 -## Merging kubeconfig files +## kubeconfigファイルのマージ -To see your configuration, enter this command: +設定ファイルを確認するには、以下のコマンドを実行します。 ```shell kubectl config view ``` -As described previously, the output might be from a single kubeconfig file, -or it might be the result of merging several kubeconfig files. +上で説明したように、出力は1つのkubeconfigファイルから作られる場合も、複数のkubeconfigファイルをマージした結果となる場合もあります。 -Here are the rules that `kubectl` uses when it merges kubeconfig files: +`kubectl`がkubeconfigファイルをマージするときに使用するルールを以下に示します。 -1. If the `--kubeconfig` flag is set, use only the specified file. Do not merge. - Only one instance of this flag is allowed. +1. もし`--kubeconfig`フラグが設定されていた場合、指定したファイルだけが使用されます。マージは行いません。このフラグに指定できるのは1つのファイルだけです。 - Otherwise, if the `KUBECONFIG` environment variable is set, use it as a - list of files that should be merged. - Merge the files listed in the `KUBECONFIG` environment variable - according to these rules: + そうでない場合、`KUBECONFIG`環境変数が設定されていた場合には、それをマージするべきファイルのリストとして使用します。`KUBECONFIG`環境変数にリストされたファイルのマージは、次のようなルールに従って行われます。 - * Ignore empty filenames. - * Produce errors for files with content that cannot be deserialized. - * The first file to set a particular value or map key wins. - * Never change the value or map key. - Example: Preserve the context of the first file to set `current-context`. - Example: If two files specify a `red-user`, use only values from the first file's `red-user`. - Even if the second file has non-conflicting entries under `red-user`, discard them. + * 空のファイルを無視する。 + * デシリアライズできない内容のファイルに対してエラーを出す。 + * 特定の値やmapのキーを設定する最初のファイルが勝つ。 + * 値やmapのキーは決して変更しない。 + 例: 最初のファイルが指定した`current-context`を保持する。 + 例: 2つのファイルが`red-user`を指定した場合、1つ目のファイルの`red-user`だけを使用する。もし2つ目のファイルの`red-user`以下に競合しないエントリーがあったとしても、それらは破棄する。 - For an example of setting the `KUBECONFIG` environment variable, see - [Setting the KUBECONFIG environment variable](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable). + `KUBECONFIG`環境変数を設定する例については、[KUBECONFIG環境変数を設定する](/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable)を参照してください。 - Otherwise, use the default kubeconfig file, `$HOME/.kube/config`, with no merging. + それ以外の場合は、デフォルトのkubeconfigファイル`$HOME/.kube/config`をマージせずに使用します。 -1. Determine the context to use based on the first hit in this chain: +1. 以下のチェーンで最初に見つかったものをもとにして、使用するcontextを決定する。 - 1. Use the `--context` command-line flag if it exists. - 1. Use the `current-context` from the merged kubeconfig files. + 1. `--context`コマンドラインフラグが存在すれば、それを使用する。 + 1. マージしたkubeconrfigファイルから`current-context`を使用する。 - An empty context is allowed at this point. + この時点では、空のcontextも許容されます。 -1. Determine the cluster and user. At this point, there might or might not be a context. - Determine the cluster and user based on the first hit in this chain, - which is run twice: once for user and once for cluster: +1. クラスターとユーザーを決定する。この時点では、contextである場合もそうでない場合もあります。以下のチェーンで最初に見つかったものをもとにして、クラスターとユーザーを決定します。この手順はユーザーとクラスターについてそれぞれ1回ずつ、合わせて2回実行されます。 - 1. Use a command-line flag if it exists: `--user` or `--cluster`. - 1. If the context is non-empty, take the user or cluster from the context. + 1. もし存在すれば、コマンドラインフラグ`--user`または`--cluster`を使用する。 + 1. もしcontextが空でなければ、contextからユーザーまたはクラスターを取得する。 - The user and cluster can be empty at this point. + この時点では、ユーザーとクラスターは空である可能性があります。 -1. Determine the actual cluster information to use. At this point, there might or - might not be cluster information. - Build each piece of the cluster information based on this chain; the first hit wins: +1. 使用する実際のクラスター情報を決定する。この時点では、クラスター情報は存在しない可能性があります。以下のチェーンで最初に見つかったものをもとにして、クラスター情報の各パーツをそれぞれを構築します。 - 1. Use command line flags if they exist: `--server`, `--certificate-authority`, `--insecure-skip-tls-verify`. - 1. If any cluster information attributes exist from the merged kubeconfig files, use them. - 1. If there is no server location, fail. + 1. もし存在すれば、`--server`、`--certificate-authority`、`--insecure-skip-tls-verify`コマンドラインフラグを使用する。 + 1. もしマージしたkubeconfigファイルにクラスター情報の属性が存在すれば、それを使用する。 + 1. もしサーバーの場所が存在しなければ、マージは失敗する。 -1. Determine the actual user information to use. Build user information using the same - rules as cluster information, except allow only one authentication - technique per user: +1. 使用する実際のユーザー情報を決定する。クラスター情報の場合と同じルールを使用して、ユーザー情報を構築します。ただし、ユーザーごとに許可される認証方法は1つだけです。 - 1. Use command line flags if they exist: `--client-certificate`, `--client-key`, `--username`, `--password`, `--token`. - 1. Use the `user` fields from the merged kubeconfig files. - 1. If there are two conflicting techniques, fail. - -1. For any information still missing, use default values and potentially - prompt for authentication information. - -## File references - -File and path references in a kubeconfig file are relative to the location of the kubeconfig file. -File references on the command line are relative to the current working directory. -In `$HOME/.kube/config`, relative paths are stored relatively, and absolute paths -are stored absolutely. + 1. もし存在すれば、`--client-certificate`、`--client-key`、`--username`、`--password`、`--token`コマンドラインフラグを使用する。 + 1. マージしたkubeconfigファイルの`user`フィールドを使用する。 + 1. もし2つの競合する方法が存在する場合、マージは失敗する。 +1. もし何らかの情報がまだ不足していれば、デフォルトの値を使用し、認証情報については場合によってはプロンプトを表示する。 +## ファイルリファレンス +kubeconfigファイル内のファイルとパスのリファレンスは、kubeconfigファイルの位置からの相対パスで指定します。コマンドライン上のファイルのリファレンスは、現在のワーキングディレクトリからの相対パスです。`$HOME/.kube/config`内では、相対パスは相対のまま、絶対パスは絶対のまま保存されます。 ## {{% heading "whatsnext" %}} -* [Configure Access to Multiple Clusters](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) +* [複数のクラスターへのアクセスを設定する](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) * [`kubectl config`](/docs/reference/generated/kubectl/kubectl-commands#config) diff --git a/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md index d5f6b72296..e250155f2d 100644 --- a/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md +++ b/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md @@ -232,7 +232,7 @@ contexts: 上記の設定ファイルは、`dev-ramp-up`というコンテキストを表します。 -## KUBECONFIG環境変数を設定する +## KUBECONFIG環境変数を設定する {#set-the-kubeconfig-environment-variable} `KUBECONFIG`という環境変数が存在するかを確認してください。もし存在する場合は、後で復元できるようにバックアップしてください。例えば: From dd05e6211d5e8d5a21600496492987267e47da51 Mon Sep 17 00:00:00 2001 From: Jesang Myung Date: Mon, 24 May 2021 21:46:28 +0900 Subject: [PATCH 044/128] no right parenthesis in three parts. --- .../tasks/configure-pod-container/configure-runasusername.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/en/docs/tasks/configure-pod-container/configure-runasusername.md b/content/en/docs/tasks/configure-pod-container/configure-runasusername.md index 12c10a9ddf..9ddcac270f 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-runasusername.md +++ b/content/en/docs/tasks/configure-pod-container/configure-runasusername.md @@ -23,7 +23,7 @@ You need to have a Kubernetes cluster and the kubectl command-line tool must be ## Set the Username for a Pod -To specify the username with which to execute the Pod's container processes, include the `securityContext` field ([PodSecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritycontext-v1-core) in the Pod specification, and within it, the `windowsOptions` ([WindowsSecurityContextOptions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#windowssecuritycontextoptions-v1-core) field containing the `runAsUserName` field. +To specify the username with which to execute the Pod's container processes, include the `securityContext` field ([PodSecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritycontext-v1-core)) in the Pod specification, and within it, the `windowsOptions` ([WindowsSecurityContextOptions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#windowssecuritycontextoptions-v1-core)) field containing the `runAsUserName` field. The Windows security context options that you specify for a Pod apply to all Containers and init Containers in the Pod. @@ -63,7 +63,7 @@ ContainerUser ## Set the Username for a Container -To specify the username with which to execute a Container's processes, include the `securityContext` field ([SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core)) in the Container manifest, and within it, the `windowsOptions` ([WindowsSecurityContextOptions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#windowssecuritycontextoptions-v1-core) field containing the `runAsUserName` field. +To specify the username with which to execute a Container's processes, include the `securityContext` field ([SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core)) in the Container manifest, and within it, the `windowsOptions` ([WindowsSecurityContextOptions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#windowssecuritycontextoptions-v1-core)) field containing the `runAsUserName` field. The Windows security context options that you specify for a Container apply only to that individual Container, and they override the settings made at the Pod level. From 6916aea2d5d1bedbd22db0967b1e45a3e6e13a52 Mon Sep 17 00:00:00 2001 From: Squidtoon99 <49101235+Squidtoon99@users.noreply.github.com> Date: Mon, 24 May 2021 22:53:28 -0500 Subject: [PATCH 045/128] Fix typo "form" > "from" In the code example given the flask server returns "Hello from Python!" but there are typos writing "form" instead of "from" in the post. --- .../2019-07-23-get-started-with-kubernetes-using-python.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/en/blog/_posts/2019-07-23-get-started-with-kubernetes-using-python.md b/content/en/blog/_posts/2019-07-23-get-started-with-kubernetes-using-python.md index 5f8d40618a..7d2e3d6ec2 100644 --- a/content/en/blog/_posts/2019-07-23-get-started-with-kubernetes-using-python.md +++ b/content/en/blog/_posts/2019-07-23-get-started-with-kubernetes-using-python.md @@ -120,7 +120,7 @@ Run the following command to have Docker run the application in a container and ``` docker run -p 5001:5000 hello-python ``` -Now navigate to http://localhost:5001, and you should see the “Hello form Python!” message. +Now navigate to http://localhost:5001, and you should see the “Hello from Python!” message. ### More info * [Get started with Docker](https://docs.docker.com/get-started/) @@ -201,7 +201,7 @@ kubectl get pods ``` Pod listing -Now navigate to http://localhost:6000, and you should see the “Hello form Python!” message. +Now navigate to http://localhost:6000, and you should see the “Hello from Python!” message. That’s it! The application is now running in Kubernetes! From 67c7ab0c4d42187a9c11b7bd53131e254449edc1 Mon Sep 17 00:00:00 2001 From: Albert Date: Wed, 19 May 2021 21:33:53 +0800 Subject: [PATCH 046/128] [zh]Update README-zh.md --- README-zh.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README-zh.md b/README-zh.md index 4dd4de269f..ef259ef2d0 100644 --- a/README-zh.md +++ b/README-zh.md @@ -174,7 +174,7 @@ Learn more about SIG Docs Kubernetes community and meetings on the [community pa You can also reach the maintainers of this project at: -- [Slack](https://kubernetes.slack.com/messages/sig-docs) +- [Slack](https://kubernetes.slack.com/messages/sig-docs) [Get an invite for this Slack](https://slack.k8s.io/) - [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) --> # 参与 SIG Docs 工作 @@ -184,7 +184,7 @@ You can also reach the maintainers of this project at: 你也可以通过以下渠道联系本项目的维护人员： -- [Slack](https://kubernetes.slack.com/messages/sig-docs) +- [Slack](https://kubernetes.slack.com/messages/sig-docs) [加入Slack](https://slack.k8s.io/) - [邮件列表](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) -윈도우 애플리케이션은 많은 조직에서 실행되는 서비스 및 애플리케이션의 상당 부분을 구성한다. [윈도우 컨테이너](https://aka.ms/windowscontainers)는 프로세스와 패키지 종속성을 캡슐화하는 현대적인 방법을 제공하여, 데브옵스(DevOps) 사례를 더욱 쉽게 ​​사용하고 윈도우 애플리케이션의 클라우드 네이티브 패턴을 따르도록 한다. 쿠버네티스는 사실상의 표준 컨테이너 오케스트레이터가 되었으며, 쿠버네티스 1.14 릴리스에는 쿠버네티스 클러스터의 윈도우 노드에서 윈도우 컨테이너 스케줄링을 위한 프로덕션 지원이 포함되어 있어, 광범위한 윈도우 애플리케이션 생태계가 쿠버네티스의 강력한 기능을 활용할 수 있다. 윈도우 기반 애플리케이션과 리눅스 기반 애플리케이션에 투자한 조직은 워크로드를 관리하기 위해 별도의 오케스트레이터를 찾을 필요가 없으므로, 운영 체제와 관계없이 배포 전반에 걸쳐 운영 효율성이 향상된다. +윈도우 애플리케이션은 많은 조직에서 실행되는 서비스 및 +애플리케이션의 상당 부분을 구성한다. +[윈도우 컨테이너](https://aka.ms/windowscontainers)는 프로세스와 패키지 종속성을 +캡슐화하는 현대적인 방법을 제공하여, 데브옵스(DevOps) +사례를 더욱 쉽게 사용하고 윈도우 애플리케이션의 클라우드 네이티브 패턴을 따르도록 한다. +쿠버네티스는 사실상의 표준 컨테이너 오케스트레이터가 되었으며, +쿠버네티스 1.14 릴리스에는 쿠버네티스 클러스터의 윈도우 노드에서 윈도우 +컨테이너 스케줄링을 위한 프로덕션 지원이 포함되어 있어, 광범위한 윈도우 애플리케이션 생태계가 +쿠버네티스의 강력한 기능을 활용할 수 있다. 윈도우 기반 애플리케이션과 +리눅스 기반 애플리케이션에 투자한 조직은 워크로드를 관리하기 위해 +별도의 오케스트레이터를 찾을 필요가 없으므로, +운영 체제와 관계없이 배포 전반에 걸쳐 +운영 효율성이 향상된다. ## 쿠버네티스의 윈도우 컨테이너 -쿠버네티스에서 윈도우 컨테이너 오케스트레이션을 활성화하려면, 기존 리눅스 클러스터에 윈도우 노드를 포함한다. 쿠버네티스의 {{< glossary_tooltip text="파드" term_id="pod" >}}에서 윈도우 컨테이너를 스케줄링하는 것은 리눅스 기반 컨테이너를 스케줄링하는 것과 유사하다. +쿠버네티스에서 윈도우 컨테이너 오케스트레이션을 활성화하려면, 기존 +리눅스 클러스터에 윈도우 노드를 포함한다. 쿠버네티스의 +{{< glossary_tooltip text="파드" term_id="pod" >}}에서 윈도우 컨테이너를 스케줄링하는 것은 +리눅스 기반 컨테이너를 스케줄링하는 것과 유사하다. -윈도우 컨테이너를 실행하려면, 쿠버네티스 클러스터에 리눅스를 실행하는 컨트롤 플레인 노드와 사용자의 워크로드 요구에 따라 윈도우 또는 리눅스를 실행하는 워커가 있는 여러 운영 체제가 포함되어 있어야 한다. 윈도우 서버 2019는 윈도우에서 [쿠버네티스 노드](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)를 활성화하는 유일한 윈도우 운영 체제이다(kubelet, [컨테이너 런타임](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/deploy-containers/containerd) 및 kube-proxy 포함). 윈도우 배포 채널에 대한 자세한 설명은 [Microsoft 문서](https://docs.microsoft.com/ko-kr/windows-server/get-started-19/servicing-channels-19)를 참고한다. +윈도우 컨테이너를 실행하려면, 쿠버네티스 클러스터에 리눅스를 +실행하는 컨트롤 플레인 노드와 사용자의 워크로드 요구에 따라 윈도우 또는 리눅스를 +실행하는 워커가 있는 여러 운영 체제가 포함되어 있어야 한다. 윈도우 +서버 2019는 윈도우에서 +[쿠버네티스 노드](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)를 +활성화하는 유일한 윈도우 운영 체제이다(kubelet, +[컨테이너 런타임](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/deploy-containers/containerd) +및 kube-proxy 포함). 윈도우 배포 채널에 대한 자세한 설명은 +[Microsoft 문서](https://docs.microsoft.com/ko-kr/windows-server/get-started-19/servicing-channels-19)를 참고한다. -{{< note >}} -[마스터 컴포넌트](/ko/docs/concepts/overview/components/)를 포함한 쿠버네티스 컨트롤 플레인은 리눅스에서 계속 실행된다. 윈도우 전용 쿠버네티스 클러스터는 계획이 없다. -{{< /note >}} +[마스터 컴포넌트](/ko/docs/concepts/overview/components/)를 포함한 +쿠버네티스 컨트롤 플레인은 +리눅스에서 계속 실행된다. +윈도우 전용 쿠버네티스 클러스터는 계획이 없다. -{{< note >}} -이 문서에서 윈도우 컨테이너에 대해 이야기할 때 프로세스 격리된 윈도우 컨테이너를 의미한다. [Hyper-V 격리](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/manage-containers/hyperv-container)가 있는 윈도우 컨테이너는 향후 릴리스로 계획되어 있다. -{{< /note >}} +이 문서에서 윈도우 컨테이너에 대해 이야기할 때 +프로세스 격리된 윈도우 컨테이너를 의미한다. +[Hyper-V 격리](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/manage-containers/hyperv-container)가 +있는 윈도우 컨테이너는 향후 릴리스로 계획되어 있다. ## 지원되는 기능 및 제한 @@ -30,41 +60,68 @@ weight: 65 #### 윈도우 OS 버전 지원 -쿠버네티스의 윈도우 운영 체제 지원은 다음 표를 참조한다. 단일 이기종 쿠버네티스 클러스터에는 윈도우 및 리눅스 워커 노드가 모두 있을 수 있다. 윈도우 컨테이너는 윈도우 노드에서, 리눅스 컨테이너는 리눅스 노드에서 스케줄되어야 한다. +쿠버네티스의 윈도우 운영 체제 지원은 다음 표를 +참조한다. 단일 이기종 쿠버네티스 클러스터에는 윈도우 및 +리눅스 워커 노드가 모두 있을 수 있다. 윈도우 컨테이너는 윈도우 노드에서, +리눅스 컨테이너는 리눅스 노드에서 스케줄되어야 한다. | 쿠버네티스 버전 | 윈도우 서버 LTSC 릴리스 | 윈도우 서버 SAC 릴리스 | -| --- | --- | --- | -| *Kubernetes v1.17* | Windows Server 2019 | Windows Server ver 1809 | -| *Kubernetes v1.18* | Windows Server 2019 | Windows Server ver 1809, Windows Server ver 1903, Windows Server ver 1909 | +| --- | --- | --- | --- | | *Kubernetes v1.19* | Windows Server 2019 | Windows Server ver 1909, Windows Server ver 2004 | | *Kubernetes v1.20* | Windows Server 2019 | Windows Server ver 1909, Windows Server ver 2004 | +| *Kubernetes v1.21* | Windows Server 2019 | Windows Server ver 2004, Windows Server ver 20H2 | -{{< note >}} -지원 모델을 포함한 다양한 윈도우 서버 서비스 채널에 대한 정보는 [윈도우 서버 서비스 채널](https://docs.microsoft.com/ko-kr/windows-server/get-started-19/servicing-channels-19)에서 확인할 수 있다. -{{< /note >}} -{{< note >}} -모든 윈도우 고객이 앱의 운영 체제를 자주 업데이트하는 것은 아니다. 애플리케이션 업그레이드를 위해서는 클러스터에 새 노드를 업그레이드하거나 도입하는 것이 필요하다. 이 문서에서 쿠버네티스에서 실행되는 컨테이너의 운영 체제를 업그레이드하기로 선택한 고객을 위해 새 운영 체제 버전에 대한 지원을 추가할 때의 가이드와 단계별 지침을 제공한다. 이 가이드에는 클러스터 노드와 함께 사용자 애플리케이션을 업그레이드하기 위한 권장 업그레이드 절차가 포함된다. 윈도우 노드는 현재 리눅스 노드와 동일한 방식으로 쿠버네티스 [버전-스큐(skew) 정책](/ko/docs/setup/release/version-skew-policy/)(노드 대 컨트롤 플레인 버전 관리)을 준수한다. -{{< /note >}} -{{< note >}} -윈도우 서버 호스트 운영 체제에는 [윈도우 서버](https://www.microsoft.com/ko-kr/cloud-platform/windows-server-pricing) 라이선스가 적용된다. 윈도우 컨테이너 이미지에는 [윈도우 컨테이너에 대한 추가 사용 조건](https://docs.microsoft.com/en-us/virtualization/windowscontainers/images-eula)이 적용된다. -{{< /note >}} -{{< note >}} -프로세스 격리가 포함된 윈도우 컨테이너에는 엄격한 호환성 규칙이 있으며, [여기서 호스트 OS 버전은 컨테이너 베이스 이미지 OS 버전과 일치해야 한다](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/deploy-containers/version-compatibility). 일단 쿠버네티스에서 Hyper-V 격리가 포함된 윈도우 컨테이너를 지원하면, 제한 및 호환성 규칙이 변경될 것이다. -{{< /note >}} + +지원 모델을 포함한 다양한 윈도우 서버 +서비스 채널에 대한 정보는 +[윈도우 서버 서비스 채널](https://docs.microsoft.com/ko-kr/windows-server/get-started-19/servicing-channels-19)에서 확인할 수 있다. + +모든 윈도우 고객이 앱의 운영 체제를 자주 업데이트하는 것은 +아니다. 애플리케이션 업그레이드를 위해서는 클러스터에 새 노드를 +업그레이드하거나 도입하는 것이 필요하다. 이 문서에서 +쿠버네티스에서 실행되는 컨테이너의 운영 체제를 업그레이드하기로 선택한 +고객을 위해 새 운영 체제 버전에 대한 지원을 추가할 때의 가이드와 +단계별 지침을 제공한다. 이 가이드에는 클러스터 노드와 함께 사용자 애플리케이션을 +업그레이드하기 위한 권장 업그레이드 절차가 포함된다. +윈도우 노드는 현재 리눅스 노드와 동일한 방식으로 쿠버네티스 +[버전-스큐(skew) 정책](/ko/docs/setup/release/version-skew-policy/)(노드 대 컨트롤 플레인 +버전 관리)을 준수한다. + + +윈도우 서버 호스트 운영 체제에는 +[윈도우 서버](https://www.microsoft.com/ko-kr/cloud-platform/windows-server-pricing) +라이선스가 적용된다. 윈도우 컨테이너 이미지에는 +[윈도우 컨테이너에 대한 추가 사용 조건](https://docs.microsoft.com/en-us/virtualization/windowscontainers/images-eula)이 적용된다. + +프로세스 격리가 포함된 윈도우 컨테이너에는 엄격한 호환성 규칙이 있으며, +[여기서 호스트 OS 버전은 컨테이너 베이스 이미지 OS 버전과 일치해야 한다](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/deploy-containers/version-compatibility). +일단 쿠버네티스에서 Hyper-V 격리가 포함된 윈도우 컨테이너를 지원하면, +제한 및 호환성 규칙이 변경될 것이다. #### 퍼즈(Pause) 이미지 -Microsoft는 `mcr.microsoft.com/oss/kubernetes/pause:1.4.1`에서 윈도우 퍼즈 인프라 컨테이너를 유지한다. +Microsoft는 `mcr.microsoft.com/oss/kubernetes/pause:3.4.1`에서 +윈도우 퍼즈 인프라 컨테이너를 유지한다. #### 컴퓨트 -API 및 kubectl의 관점에서, 윈도우 컨테이너는 리눅스 기반 컨테이너와 거의 같은 방식으로 작동한다. 그러나 [제한 섹션](#제한)에 요약된 주요 기능에는 몇 가지 눈에 띄는 차이점이 있다. +API 및 kubectl의 관점에서, 윈도우 컨테이너는 +리눅스 기반 컨테이너와 거의 같은 방식으로 작동한다. 그러나 +[제한 섹션](#제한)에 요약된 주요 기능에는 +몇 가지 눈에 띄는 차이점이 있다. -윈도우에서 주요 쿠버네티스 요소는 리눅스와 동일한 방식으로 작동한다. 이 섹션에서는, 주요 워크로드 인에이블러(enabler) 일부와 이들이 윈도우에 매핑되는 방법에 대해 설명한다. +윈도우에서 주요 쿠버네티스 요소는 리눅스와 동일한 방식으로 작동한다. 이 +섹션에서는, 주요 워크로드 인에이블러(enabler) 일부와 이들이 윈도우에 매핑되는 방법에 +대해 설명한다. * [파드](/ko/docs/concepts/workloads/pods/) - 파드는 쿠버네티스의 기본 빌딩 블록이다 - 쿠버네티스 오브젝트 모델에서 생성하고 배포하는 가장 작고 간단한 단위. 동일한 파드에 윈도우 및 리눅스 컨테이너를 배포할 수 없다. 파드의 모든 컨테이너는 단일 노드로 스케줄되며 각 노드는 특정 플랫폼 및 아키텍처를 나타낸다. 다음과 같은 파드 기능, 속성 및 이벤트가 윈도우 컨테이너에서 지원된다. + 파드는 쿠버네티스의 기본 빌딩 블록이다 - 쿠버네티스 오브젝트 모델에서 + 생성하고 배포하는 가장 작고 간단한 단위. 동일한 파드에 + 윈도우 및 리눅스 컨테이너를 배포할 수 없다. 파드의 모든 컨테이너는 + 단일 노드로 스케줄되며 각 노드는 특정 플랫폼 및 + 아키텍처를 나타낸다. 다음과 같은 파드 기능, 속성 및 + 이벤트가 윈도우 컨테이너에서 지원된다. * 프로세스 분리 및 볼륨 공유 기능을 갖춘 파드 당 하나 또는 여러 개의 컨테이너 * 파드 상태 필드 @@ -76,7 +133,8 @@ API 및 kubectl의 관점에서, 윈도우 컨테이너는 리눅스 기반 컨 * 리소스 제한 * [컨트롤러](/ko/docs/concepts/workloads/controllers/) - 쿠버네티스 컨트롤러는 파드의 의도한 상태(desired state)를 처리한다. 윈도우 컨테이너에서 지원되는 워크로드 컨트롤러는 다음과 같다. + 쿠버네티스 컨트롤러는 파드의 의도한 상태(desired state)를 처리한다. 윈도우 + 컨테이너에서 지원되는 워크로드 컨트롤러는 다음과 같다. * 레플리카셋(ReplicaSet) * 레플리케이션컨트롤러(ReplicationController) @@ -87,7 +145,10 @@ API 및 kubectl의 관점에서, 윈도우 컨테이너는 리눅스 기반 컨 * 크론잡(CronJob) * [서비스](/ko/docs/concepts/services-networking/service/) - 쿠버네티스 서비스는 논리적인 파드 집합과 그것에(마이크로 서비스라고도 함) 접근하는 정책을 정의하는 추상화 개념이다. 상호-운영 체제 연결을 위해 서비스를 사용할 수 있다. 윈도우에서 서비스는 다음의 유형, 속성 및 기능을 활용할 수 있다. + 쿠버네티스 서비스는 논리적인 파드 집합과 그것에(마이크로 서비스라고도 함) + 접근하는 정책을 정의하는 추상화 개념이다. 상호-운영 체제 + 연결을 위해 서비스를 사용할 수 있다. 윈도우에서 서비스는 + 다음의 유형, 속성 및 기능을 활용할 수 있다. * 서비스 환경 변수 * 노드포트(NodePort) @@ -96,7 +157,10 @@ API 및 kubectl의 관점에서, 윈도우 컨테이너는 리눅스 기반 컨 * ExternalName * 헤드리스 서비스(Headless services) -파드, 컨트롤러 및 서비스는 쿠버네티스에서 윈도우 워크로드를 관리하는데 중요한 요소이다. 그러나 그 자체로는 동적 클라우드 네이티브 환경에서 윈도우 워크로드의 적절한 수명 주기 관리를 수행하기에 충분하지 않다. 다음 기능에 대한 지원이 추가되었다. +파드, 컨트롤러 및 서비스는 쿠버네티스에서 윈도우 워크로드를 +관리하는데 중요한 요소이다. 그러나 그 자체로는 동적 클라우드 네이티브 환경에서 +윈도우 워크로드의 적절한 수명 주기 관리를 수행하기에 +충분하지 않다. 다음 기능에 대한 지원이 추가되었다. * 파드와 컨테이너 메트릭 * Horizontal Pod Autoscaler 지원 @@ -110,27 +174,42 @@ API 및 kubectl의 관점에서, 윈도우 컨테이너는 리눅스 기반 컨 {{< feature-state for_k8s_version="v1.14" state="stable" >}} -Docker EE-basic 19.03 이상은 모든 윈도우 서버 버전에 대해 권장되는 컨테이너 런타임이다. 이것은 kubelet에 포함된 dockershim 코드와 함께 작동한다. +Docker EE-basic 19.03 이상은 모든 윈도우 서버 버전에 대해 권장되는 +컨테이너 런타임이다. 이것은 kubelet에 포함된 dockershim 코드와 함께 작동한다. ##### CRI-ContainerD {{< feature-state for_k8s_version="v1.20" state="stable" >}} -{{< glossary_tooltip term_id="containerd" text="ContainerD" >}} 1.4.0+는 윈도우 쿠버네티스 노드의 컨테이너 런타임으로도 사용할 수 있다. +{{< glossary_tooltip term_id="containerd" text="ContainerD" >}} 1.4.0+는 +윈도우 쿠버네티스 노드의 컨테이너 런타임으로도 사용할 수 있다. -[윈도우에 ContainerD 설치](/ko/docs/setup/production-environment/container-runtimes/#containerd-설치) 방법을 확인한다. - -{{< caution >}} -ContainerD와 함께 GMSA를 사용하여 커널 패치가 필요한 윈도우 네트워크 공유에 액세스 할 때 [알려진 제한](/docs/tasks/configure-pod-container/configure-gmsa/#gmsa-limitations)이 있다. 이 제한을 해결하기위한 업데이트는 현재 Windows Server, 버전 2004에서 사용할 수 있으며 2021년 초에 Windows Server 2019에서 사용할 수 있다. [Microsoft 윈도우 컨테이너 이슈 트래커](https://github.com/microsoft/Windows-Containers/issues/44)에서 업데이트를 확인한다. -{{< /caution >}} +[윈도우에 ContainerD 설치](/ko/docs/setup/production-environment/container-runtimes/#containerd-설치) +방법을 확인한다. #### 퍼시스턴트 스토리지(Persistent Storage) -쿠버네티스 [볼륨](/ko/docs/concepts/storage/volumes/)을 사용하면 데이터 지속성(persistence) 및 파드 볼륨 공유 요구 사항이 있는 복잡한 애플리케이션을 쿠버네티스에 배포할 수 있다. 특정 스토리지 백엔드 또는 프로토콜과 관련된 퍼시스턴트 볼륨 관리에는 볼륨 프로비저닝/디-프로비저닝/크기 조정, 쿠버네티스 노드에 볼륨 연결/분리, 데이터를 유지해야 하는 파드의 개별 컨테이너에 볼륨 마운트/분리와 같은 작업이 포함된다. 특정 스토리지 백엔드 또는 프로토콜에 대해 이러한 볼륨 관리 작업을 구현하는 코드는 쿠버네티스 볼륨 [플러그인](/ko/docs/concepts/storage/volumes/#볼륨-유형들)의 형태로 제공된다. 다음과 같은 광범위한 쿠버네티스 볼륨 플러그인 클래스가 윈도우에서 지원된다. +쿠버네티스 [볼륨](/ko/docs/concepts/storage/volumes/)을 사용하면 +데이터 지속성(persistence) 및 파드 볼륨 공유 요구 사항이 있는 복잡한 애플리케이션을 +쿠버네티스에 배포할 수 있다. 특정 스토리지 백엔드 또는 +프로토콜과 관련된 퍼시스턴트 볼륨 관리에는 +볼륨 프로비저닝/디-프로비저닝/크기 조정, 쿠버네티스 노드에 볼륨 +연결/분리, 데이터를 유지해야 하는 파드의 개별 컨테이너에 볼륨 +마운트/분리와 같은 작업이 포함된다. 특정 스토리지 백엔드 또는 +프로토콜에 대해 이러한 볼륨 관리 작업을 +구현하는 코드는 쿠버네티스 볼륨 +[플러그인](/ko/docs/concepts/storage/volumes/#볼륨-유형들)의 형태로 제공된다. 다음과 같은 +광범위한 쿠버네티스 볼륨 플러그인 클래스가 윈도우에서 지원된다. ##### 인-트리(In-tree) 볼륨 플러그인 -인-트리 볼륨 플러그인과 관련된 코드는 핵심 쿠버네티스 코드 베이스의 일부로 제공된다. 인-트리 볼륨 플러그인 배포는 추가 스크립트를 설치하거나 별도의 컨테이너화된 플러그인 컴포넌트를 배포할 필요가 없다. 이러한 플러그인들은 볼륨 프로비저닝/디-프로비저닝, 스토리지 백엔드 볼륨 크기 조정, 쿠버네티스 노드에 볼륨 연결/분리, 파드의 개별 컨테이너에 볼륨 마운트/분리를 처리할 수 있다. 다음의 인-트리 플러그인은 윈도우 노드를 지원한다. +인-트리 볼륨 플러그인과 관련된 코드는 핵심 쿠버네티스 +코드 베이스의 일부로 제공된다. 인-트리 볼륨 플러그인 배포는 +추가 스크립트를 설치하거나 별도의 컨테이너화된 플러그인 컴포넌트를 +배포할 필요가 없다. 이러한 플러그인들은 +볼륨 프로비저닝/디-프로비저닝, 스토리지 백엔드 볼륨 크기 조정, 쿠버네티스 노드에 +볼륨 연결/분리, 파드의 개별 컨테이너에 볼륨 마운트/분리를 +처리할 수 있다. 다음의 인-트리 플러그인은 윈도우 노드를 지원한다. * [awsElasticBlockStore](/ko/docs/concepts/storage/volumes/#awselasticblockstore) * [azureDisk](/ko/docs/concepts/storage/volumes/#azuredisk) @@ -140,7 +219,16 @@ ContainerD와 함께 GMSA를 사용하여 커널 패치가 필요한 윈도우 ##### FlexVolume 플러그인 -[FlexVolume](/ko/docs/concepts/storage/volumes/#flexVolume) 플러그인과 관련된 코드는 아웃-오브-트리(out-of-tree) 스크립트 또는 호스트에 직접 배포해야 하는 바이너리로 제공된다. FlexVolume 플러그인은 쿠버네티스 노드에 볼륨 연결/분리 및 파드의 개별 컨테이너에 볼륨 마운트/분리를 처리한다. FlexVolume 플러그인과 관련된 퍼시스턴트 볼륨의 프로비저닝/디-프로비저닝은 일반적으로 FlexVolume 플러그인과는 별도의 외부 프로비저너를 통해 처리될 수 있다. 호스트에서 powershell 스크립트로 배포된 다음의 FlexVolume [플러그인](https://github.com/Microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows)은 윈도우 노드를 지원한다. +[FlexVolume](/ko/docs/concepts/storage/volumes/#flexVolume) +플러그인과 관련된 코드는 아웃-오브-트리(out-of-tree) 스크립트 또는 호스트에 직접 배포해야 하는 +바이너리로 제공된다. FlexVolume 플러그인은 쿠버네티스 노드에 볼륨 +연결/분리 및 파드의 개별 컨테이너에 볼륨 마운트/분리를 +처리한다. FlexVolume 플러그인과 관련된 퍼시스턴트 볼륨의 +프로비저닝/디-프로비저닝은 일반적으로 FlexVolume 플러그인과는 별도의 외부 +프로비저너를 통해 처리될 수 있다. 호스트에서 +powershell 스크립트로 배포된 다음의 FlexVolume +[플러그인](https://github.com/Microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows)은 +윈도우 노드를 지원한다. * [SMB](https://github.com/microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows/plugins/microsoft.com~smb.cmd) * [iSCSI](https://github.com/microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows/plugins/microsoft.com~iscsi.cmd) @@ -149,13 +237,40 @@ ContainerD와 함께 GMSA를 사용하여 커널 패치가 필요한 윈도우 {{< feature-state for_k8s_version="v1.19" state="beta" >}} -{{< glossary_tooltip text="CSI" term_id="csi" >}} 플러그인과 관련된 코드는 일반적으로 컨테이너 이미지로 배포되고 데몬셋(DaemonSets) 및 스테이트풀셋(StatefulSets)과 같은 표준 쿠버네티스 구성을 사용하여 배포되는 아웃-오브-트리 스크립트 및 바이너리로 제공된다. CSI 플러그인은 쿠버네티스에서 볼륨 프로비저닝/디-프로비저닝, 볼륨 크기 조정, 쿠버네티스 노드에 볼륨 연결/분리, 파드의 개별 컨테이너에 볼륨 마운트/분리, 스냅샷 및 복제를 사용하여 퍼시스턴트 데이터 백업/복원과 같은 다양한 볼륨 관리 작업을 처리한다. CSI 플러그인은 일반적으로 (각 노드에서 데몬셋으로 실행되는) 노드 플러그인과 컨트롤러 플러그인으로 구성된다. +{{< glossary_tooltip text="CSI" term_id="csi" >}} 플러그인과 +관련된 코드는 일반적으로 컨테이너 이미지로 배포되고 데몬셋(DaemonSets) +및 스테이트풀셋(StatefulSets)과 같은 +표준 쿠버네티스 구성을 사용하여 배포되는 아웃-오브-트리 스크립트 및 +바이너리로 제공된다. CSI 플러그인은 쿠버네티스에서 볼륨 프로비저닝/디-프로비저닝, 볼륨 +크기 조정, 쿠버네티스 노드에 볼륨 연결/분리, 파드의 개별 컨테이너에 볼륨 +마운트/분리, 스냅샷 및 복제를 사용하여 퍼시스턴트 데이터 백업/복원과 같은 +다양한 볼륨 관리 작업을 처리한다. CSI 플러그인은 +일반적으로 (각 노드에서 데몬셋으로 실행되는) 노드 플러그인과 컨트롤러 +플러그인으로 구성된다. -CSI 노드 플러그인(특히 블록 디바이스 또는 공유 파일시스템으로 노출된 퍼시스턴트 볼륨과 관련된 플러그인)은 디스크 장치 스캔, 파일 시스템 마운트 등과 같은 다양한 특권이 필요한(privileged) 작업을 수행해야 한다. 이러한 작업은 호스트 운영 체제마다 다르다. 리눅스 워커 노드의 경우 컨테이너화된 CSI 노드 플러그인은 일반적으로 특권을 가진 컨테이너로 배포된다. 윈도우 워커 노드의 경우 컨테이너화된 CSI 노드 플러그인에 대한 특권이 필요한 작업은 커뮤니티에서 관리되고, 각 윈도우 노드에 사전 설치되어야 하는 독립형(stand-alone) 바이너리인 [csi-proxy](https://github.com/kubernetes-csi/csi-proxy)를 사용하여 지원된다. 자세한 내용은 배포하려는 CSI 플러그인의 배포 가이드를 참조한다. +CSI 노드 플러그인(특히 블록 디바이스 또는 공유 파일시스템으로 노출된 +퍼시스턴트 볼륨과 관련된 플러그인)은 디스크 장치 스캔, 파일 시스템 마운트 등과 같은 +다양한 특권이 필요한(privileged) 작업을 수행해야 +한다. 이러한 작업은 호스트 운영 체제마다 다르다. 리눅스 워커 +노드의 경우 컨테이너화된 CSI 노드 플러그인은 일반적으로 특권을 가진 +컨테이너로 배포된다. 윈도우 워커 노드의 경우 컨테이너화된 +CSI 노드 플러그인에 대한 특권이 필요한 작업은 커뮤니티에서 관리되고, +각 윈도우 노드에 사전 설치되어야 하는 독립형(stand-alone) 바이너리인 +[csi-proxy](https://github.com/kubernetes-csi/csi-proxy)를 사용하여 지원된다. 자세한 +내용은 배포하려는 CSI 플러그인의 배포 가이드를 +참조한다. #### 네트워킹 -윈도우 컨테이너용 네트워킹은 [CNI 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)을 통해 노출된다. 윈도우 컨테이너는 네트워킹과 관련하여 가상 머신과 유사하게 작동한다. 각 컨테이너에는 Hyper-V 가상 스위치(vSwitch)에 연결된 가상 네트워크 어댑터(vNIC)가 있다. 호스트 네트워킹 서비스(HNS)와 호스트 컴퓨팅 서비스(HCS)는 함께 작동하여 컨테이너를 만들고 컨테이너 vNIC을 네트워크에 연결한다. HCS는 컨테이너 관리를 담당하는 반면 HNS는 다음과 같은 네트워킹 리소스 관리를 담당한다. +윈도우 컨테이너용 네트워킹은 +[CNI 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)을 통해 노출된다. +윈도우 컨테이너는 네트워킹과 관련하여 가상 머신과 유사하게 +작동한다. 각 컨테이너에는 Hyper-V 가상 스위치(vSwitch)에 연결된 +가상 네트워크 어댑터(vNIC)가 있다. 호스트 네트워킹 서비스(HNS)와 +호스트 컴퓨팅 서비스(HCS)는 함께 작동하여 컨테이너를 만들고 +컨테이너 vNIC을 네트워크에 연결한다. HCS는 컨테이너 관리를 +담당하는 반면 HNS는 다음과 같은 네트워킹 리소스 관리를 +담당한다. * 가상 네트워크(vSwitch 생성 포함) * 엔드포인트 / vNIC @@ -171,19 +286,155 @@ CSI 노드 플러그인(특히 블록 디바이스 또는 공유 파일시스템 ##### 네트워크 모드 -윈도우는 L2bridge, L2tunnel, Overlay, Transparent 및 NAT의 다섯 가지 네트워킹 드라이버/모드를 지원한다. 윈도우와 리눅스 워커 노드가 있는 이기종 클러스터에서는 윈도우와 리눅스 모두에서 호환되는 네트워킹 솔루션을 선택해야 한다. 윈도우에서 다음과 같은 out-of-tree 플러그인이 지원되며 각 CNI 사용 시 권장 사항이 있다. +윈도우는 L2bridge, L2tunnel, Overlay, Transparent 및 +NAT의 다섯 가지 네트워킹 드라이버/모드를 지원한다. 윈도우와 리눅스 워커 노드가 +있는 이기종 클러스터에서는 윈도우와 리눅스 모두에서 호환되는 네트워킹 +솔루션을 선택해야 한다. 윈도우에서 다음과 같은 out-of-tree 플러그인이 지원되며 +각 CNI 사용 시 권장 사항이 있다. -| 네트워크 드라이버 | 설명 | 컨테이너 패킷 수정 | 네트워크 플러그인 | 네트워크 플러그인 특성 | -| -------------- | ----------- | ------------------------------ | --------------- | ------------------------------ | -| L2bridge | 컨테이너는 외부 vSwitch에 연결된다. 컨테이너는 언더레이 네트워크에 연결된다. 하지만 인그레스/이그레스시에 재작성되기 때문에 물리적 네트워크가 컨테이너 MAC을 학습할 필요가 없다. | MAC은 호스트 MAC에 다시 쓰여지고, IP는 HNS OutboundNAT 정책을 사용하여 호스트 IP에 다시 쓰여질 수 있다. | [win-bridge](https://github.com/containernetworking/plugins/tree/master/plugins/main/windows/win-bridge), [Azure-CNI](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md), Flannel 호스트 게이트웨이는 win-bridge를 사용한다. | win-bridge는 L2bridge 네트워크 모드를 사용하고, 컨테이너를 호스트의 언더레이에 연결하여 최상의 성능을 제공한다. 노드 간 연결을 위해 사용자 정의 경로(user-defined routes, UDR)가 필요하다. | -| L2Tunnel | 이것은 l2bridge의 특별한 케이스이지만 Azure에서만 사용된다. 모든 패킷은 SDN 정책이 적용되는 가상화 호스트로 전송된다. | MAC 재작성되고, 언더레이 네트워크 상에서 IP가 보인다. | [Azure-CNI](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md) | Azure-CNI를 사용하면 컨테이너를 Azure vNET과 통합할 수 있으며, [Azure Virtual Network에서 제공하는](https://azure.microsoft.com/ko-kr/services/virtual-network/) 기능 집합을 활용할 수 있다. 예를 들어 Azure 서비스에 안전하게 연결하거나 Azure NSG를 사용한다. [azure-cni 예제](https://docs.microsoft.com/ko-kr/azure/aks/concepts-network#azure-cni-advanced-networking)를 참고한다. | -| 오버레이(쿠버네티스에서 윈도우용 오버레이 네트워킹은 *알파* 단계에 있음) | 컨테이너에는 외부 vSwitch에 연결된 vNIC이 제공된다. 각 오버레이 네트워크는 사용자 지정 IP 접두사로 정의된 자체 IP 서브넷을 가져온다. 오버레이 네트워크 드라이버는 VXLAN 캡슐화를 사용한다. | 외부 헤더로 캡슐화된다. | [Win-overlay](https://github.com/containernetworking/plugins/tree/master/plugins/main/windows/win-overlay), Flannel VXLAN(win-overlay 사용) | win-overlay는 가상 컨테이너 네트워크를 호스트의 언더레이에서 격리하려는 경우(예: 보안 상의 이유로) 사용해야 한다. 데이터 센터의 IP에 제한이 있는 경우, (다른 VNID 태그가 있는) 다른 오버레이 네트워크에 IP를 재사용할 수 있다. 이 옵션을 사용하려면 윈도우 서버 2019에서 [KB4489899](https://support.microsoft.com/help/4489899)가 필요하다. | -| Transparent([ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes)의 특수한 유스케이스) | 외부 vSwitch가 필요하다. 컨테이너는 논리적 네트워크(논리적 스위치 및 라우터)를 통해 파드 내 통신을 가능하게 하는 외부 vSwitch에 연결된다. | 패킷은 [GENEVE](https://datatracker.ietf.org/doc/draft-gross-geneve/) 또는 [STT](https://datatracker.ietf.org/doc/draft-davie-stt)를 통해 캡슐화되는데, 동일한 호스트에 있지 않은 파드에 도달하기 위한 터널링을 한다.
패킷은 ovn 네트워크 컨트롤러에서 제공하는 터널 메타데이터 정보를 통해 전달되거나 삭제된다.
NAT는 north-south 통신(데이터 센터와 클라이언트, 네트워크 상의 데이터 센터 외부와의 통신)을 위해 수행된다. | [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes) | [ansible을 통해 배포](https://github.com/openvswitch/ovn-kubernetes/tree/master/contrib)한다. 분산 ACL은 쿠버네티스 정책을 통해 적용할 수 있다. IPAM을 지원한다. kube-proxy 없이 로드 밸런싱을 수행할 수 있다. NAT를 수행할 때 iptables/netsh를 사용하지 않고 수행된다. | -| NAT(*쿠버네티스에서 사용되지 않음*) | 컨테이너에는 내부 vSwitch에 연결된 vNIC이 제공된다. DNS/DHCP는 [WinNAT](https://blogs.technet.microsoft.com/virtualization/2016/05/25/windows-nat-winnat-capabilities-and-limitations/)라는 내부 컴포넌트를 사용하여 제공된다. | MAC 및 IP는 호스트 MAC/IP에 다시 작성된다. | [nat](https://github.com/Microsoft/windows-container-networking/tree/master/plugins/nat) | 완전성을 위해 여기에 포함되었다. | + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
네트워크 드라이버설명컨테이너 패킷 수정네트워크 플러그인네트워크 플러그인 특성
L2bridge컨테이너는 외부 vSwitch에 연결된다. 컨테이너는 + 언더레이 네트워크에 연결된다. 하지만 인그레스/이그레스시에 재작성되기 + 때문에 물리적 네트워크가 컨테이너 MAC을 학습할 필요가 없다. + + MAC은 호스트 MAC에 다시 쓰여지고, IP는 HNS OutboundNAT 정책을 사용하여 + 호스트 IP에 다시 쓰여질 수 있다. + + win-bridge, + Azure-CNI, + Flannel 호스트 게이트웨이는 win-bridge를 사용한다. + + win-bridge는 L2bridge 네트워크 모드를 사용하고, + 컨테이너를 호스트의 언더레이에 연결하여 최상의 성능을 제공한다. + 노드 간 연결을 위해 사용자 정의 경로(user-defined routes, UDR)가 필요하다. +
L2Tunnel + 이것은 l2bridge의 특별한 케이스이지만 Azure에서만 사용된다. 모든 패킷은 + SDN 정책이 적용되는 가상화 호스트로 전송된다. + + MAC 재작성되고, 언더레이 네트워크 상에서 IP가 보인다. + + Azure-CNI + + Azure-CNI를 사용하면 컨테이너를 Azure vNET과 통합할 수 있으며, + Azure Virtual Network에서 + 제공하는 기능 집합을 활용할 수 있다. + 예를 들어, Azure 서비스에 안전하게 연결하거나 Azure NSG를 사용한다. + azure-cni + 예제를 참고한다. +
오버레이(쿠버네티스에서 윈도우용 오버레이 네트워킹은 알파 단계에 있음) + 컨테이너에는 외부 vSwitch에 연결된 vNIC이 제공된다. 각 오버레이 + 네트워크는 사용자 지정 IP 접두사로 정의된 자체 IP 서브넷을 가져온다. 오버레이 + 네트워크 드라이버는 VXLAN 캡슐화를 사용한다. + + 외부 헤더로 캡슐화된다. + + Win-overlay, + Flannel VXLAN (win-overlay 사용) + + win-overlay는 가상 컨테이너 네트워크를 호스트의 + 언더레이에서 격리하려는 경우(예: 보안 상의 이유로) 사용해야 한다. 데이터 센터의 IP에 + 제한이 있는 경우, (다른 VNID 태그가 있는) 다른 오버레이 + 네트워크에 IP를 재사용할 수 있다. 이 옵션을 사용하려면 + 윈도우 서버 2019에서 KB4489899가 + 필요하다. +
+ Transparent(ovn-kubernetes의 특수한 유스케이스) + + 외부 vSwitch가 필요하다. 컨테이너는 논리적 네트워크(논리적 스위치 및 라우터)를 + 통해 파드 내 통신을 가능하게 하는 외부 vSwitch에 + 연결된다. + + 패킷은 + GENEVE, + STT 터널링을 통해 + 캡슐화되는데, 동일한 호스트에 있지 않은 파드에 도달하기 위한 터널링을 한다.
패킷은 ovn 네트워크 + 컨트롤러에서 제공하는 터널 메타데이터 정보를 통해 전달되거나 삭제된다. +
+ NAT는 north-south 통신(데이터 센터와 클라이언트, 네트워크 상의 데이터 센터 외부와의 통신)을 위해 수행된다. + 		+ ovn-kubernetes + + Ansible을 통해 배포한다. + 분산 ACL은 쿠버네티스 정책을 통해 적용할 수 있다. IPAM을 지원한다. + kube-proxy 없이 로드 밸런싱을 수행할 수 있다. NAT를 수행할 때 + iptables/netsh를 사용하지 않고 수행된다. +
NAT (쿠버네티스에서 사용되지 않음) + 컨테이너에는 내부 vSwitch에 연결된 vNIC이 제공된다. DNS/DHCP는 + WinNAT라는 + 내부 컴포넌트를 사용하여 제공된다. + + MAC 및 IP는 호스트 MAC/IP에 다시 작성된다. + + nat + + 완전성을 위해 여기에 포함되었다. +
-위에서 설명한대로 [플란넬(Flannel)](https://github.com/coreos/flannel) CNI [메타 플러그인](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel)은 [VXLAN 네트워크 백엔드](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan)(**alpha 지원**, win-overlay에 위임) 및 [host-gateway network backend](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#host-gw) (안정적인 지원, win-bridge에 위임)를 통해 [윈도우](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel#windows-support-experimental)에서도 지원된다. 이 플러그인은 자동 노드 서브넷 임대 할당과 HNS 네트워크 생성을 위해 윈도우 (Flanneld)에서 Flannel 데몬과 함께 작동하도록 참조 CNI 플러그인 (win-overlay, win-bridge) 중 하나에 대한 위임을 지원한다. 이 플러그인은 자체 구성 파일 (cni.conf)을 읽고, 이를 FlannelD 생성하는 subnet.env 파일의 환경 변수와 함께 집계한다. 이후 네트워크 연결을 위한 참조 CNI 플러그인 중 하나에 위임하고 노드 할당 서브넷을 포함하는 올바른 구성을 IPAM 플러그인 (예: 호스트-로컬)으로 보낸다. +위에서 설명한대로 [플란넬(Flannel)](https://github.com/coreos/flannel) CNI +[메타 플러그인](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel)은 +[VXLAN 네트워크 백엔드](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan) +(**alpha 지원**, win-overlay에 위임) 및 +[host-gateway network backend](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#host-gw) +(안정적인 지원, win-bridge에 위임)를 통해 +[윈도우](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel#windows-support-experimental)에서도 +지원된다. 이 플러그인은 자동 노드 서브넷 +임대 할당과 HNS 네트워크 생성을 위해 윈도우 (Flanneld)에서 +Flannel 데몬과 함께 작동하도록 참조 CNI 플러그인 (win-overlay, win-bridge) +중 하나에 대한 위임을 지원한다. 이 플러그인은 자체 +구성 파일 (cni.conf)을 읽고, 이를 FlannelD 생성하는 subnet.env 파일의 환경 변수와 +함께 집계한다. 이후 네트워크 연결을 위한 +참조 CNI 플러그인 중 하나에 위임하고 노드 할당 서브넷을 포함하는 올바른 +구성을 IPAM 플러그인 (예: 호스트-로컬)으로 +보낸다. -노드, 파드, 서비스 오브젝트의 경우 TCP/UDP 트래픽에 대해 다음 네트워크 흐름이 지원된다. +노드, 파드, 서비스 오브젝트의 경우 TCP/UDP 트래픽에 대해 다음 +네트워크 흐름이 지원된다. * 파드 -> 파드(IP) * 파드 -> 파드(Name) @@ -205,84 +456,227 @@ CSI 노드 플러그인(특히 블록 디바이스 또는 공유 파일시스템 ##### 로드 밸런싱과 서비스 -윈도우에서는 다음 설정을 사용하여 서비스 및 로드 밸런싱 동작을 구성할 수 있다. +윈도우에서는 다음 설정을 사용하여 서비스 및 로드 밸런싱 동작을 +구성할 수 있다. {{< table caption="윈도우 서비스 구성" >}} -| 기능 | 설명 | 지원되는 쿠버네티스 버전 | 지원되는 윈도우 OS 빌드 | 활성화하는 방법 | -| ------- | ----------- | ----------------------------- | -------------------------- | ------------- | -| 세션 어피니티 | 특정 클라이언트의 연결이 매번 동일한 파드로 전달되도록 한다. | v1.20 이상 | [윈도우 서버 vNext Insider Preview Build 19551](https://blogs.windows.com/windowsexperience/2020/01/28/announcing-windows-server-vnext-insider-preview-build-19551/) 이상 | `service.spec.sessionAffinity`를 "ClientIP"로 설정 | -| 직접 서버 반환 (DSR) | IP 주소 수정 및 LBNAT가 컨테이너 vSwitch 포트에서 직접 발생하는 로드 밸런싱 모드. 서비스 트래픽은 소스 IP가 원래 파드 IP로 설정된 상태로 도착한다. | v1.20 이상 | 윈도우 서버 2019 | kube-proxy에서 다음 플래그를 설정한다. `--feature-gates="WinDSR=true" --enable-dsr=true` | -| 대상 보존(Preserve-Destination) | 서비스 트래픽의 DNAT를 스킵하여, 백엔드 파드에 도달하는 패킷에서 대상 서비스의 가상 IP를 보존한다. 또한 노드-노드 전달을 비활성화한다. | v1.20 이상 | 윈도우 서버, 버전 1903 (또는 그 이상) | 서비스 어노테이션에서 `"preserve-destination": "true"`를 설정하고 kube-proxy에서 DSR을 활성화한다. | -| IPv4/IPv6 이중 스택 네트워킹 | 클러스터 내/외부 기본 IPv4-to-IPv4 통신과 함께 IPv6-to-IPv6 통신 | v1.19 이상 | 윈도우 서버, 버전 2004 (또는 그 이상) | [IPv4/IPv6 이중 스택](#ipv4ipv6-이중-스택)을 참고한다. | -| 클라이언트 IP 보존 | 인그레스 트래픽의 소스 IP가 유지되도록 한다. 또한 노드-노드 전달을 비활성화한다. | v1.20 이상 | 윈도우 서버, 버전 2019 (또는 그 이상) | `service.spec.externalTrafficPolicy` 를 "Local"로 설정하고 kube-proxy에서 DSR을 활성화한다. | + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
기능설명지원되는 쿠버네티스 버전지원되는 윈도우 OS 빌드활성화하는 방법
세션 어피니티 + 특정 클라이언트의 연결이 매번 동일한 파드로 + 전달되도록 한다. + v1.20 이상 + 윈도우 서버 vNext Insider Preview Build 19551 (또는 그 이상) + + service.spec.sessionAffinity를 "ClientIP"로 설정 +
직접 서버 반환 (DSR) + IP 주소 수정 및 LBNAT가 컨테이너 vSwitch 포트에서 직접 + 발생하는 로드 밸런싱 모드. 서비스 트래픽은 소스 IP가 원래 파드 IP로 + 설정된 상태로 도착한다. + v1.20 이상 + 윈도우 서버 2019 + + kube-proxy에서 다음 플래그를 설정한다. + --feature-gates="WinDSR=true" --enable-dsr=true +
대상 보존(Preserve-Destination) + 서비스 트래픽의 DNAT를 스킵하여, 백엔드 파드에 도달하는 패킷에서 대상 + 서비스의 가상 IP를 보존한다. 또한 노드-노드 전달을 비활성화한다. + v1.20 이상윈도우 서버, 버전 1903 (또는 그 이상) + 서비스 어노테이션에서 "preserve-destination": "true"를 설정하고 + kube-proxy에서 DSR을 활성화한다. +
IPv4/IPv6 이중 스택 네트워킹 + 클러스터 내/외부 기본 IPv4-to-IPv4 통신과 함께 + IPv6-to-IPv6 통신 + v1.19 이상윈도우 서버, 버전 2004 (또는 그 이상) + IPv4/IPv6 이중 스택을 참고한다. +
클라이언트 IP 보존 + 인그레스 트래픽의 소스 IP가 유지되도록 한다. 또한 + 노드-노드 전달을 비활성화한다. + v1.20 이상윈도우 서버, 버전 2019 (또는 그 이상) + service.spec.externalTrafficPolicy를 "Local"로 설정하고 + kube-proxy에서 DSR을 활성화한다. +
+ {{< /table >}} #### IPv4/IPv6 이중 스택 -`IPv6DualStack` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 사용하여 `l2bridge` 네트워크에 IPv4/IPv6 이중 스택 네트워킹을 활성화할 수 있다. 자세한 내용은 [IPv4/IPv6 이중 스택 활성화](/ko/docs/concepts/services-networking/dual-stack/#ipv4-ipv6-이중-스택-활성화)를 참조한다. +`IPv6DualStack` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 +사용하여 `l2bridge` 네트워크에 IPv4/IPv6 이중 스택 네트워킹을 활성화할 수 있다. 자세한 내용은 +[IPv4/IPv6 이중 스택 활성화](/ko/docs/concepts/services-networking/dual-stack/#ipv4-ipv6-이중-스택-활성화)를 +참조한다. -{{< note >}} -윈도우에서 쿠버네티스와 함께 IPv6를 사용하려면 윈도우 서버 버전 2004 (커널 버전 10.0.19041.610) 이상이 필요하다. -{{< /note >}} +윈도우에서 쿠버네티스와 함께 IPv6를 사용하려면 윈도우 서버 버전 2004 +(커널 버전 10.0.19041.610) 이상이 필요하다. -{{< note >}} 윈도우의 오버레이(VXLAN) 네트워크는 현재 이중 스택 네트워킹을 지원하지 않는다. -{{< /note >}} ### 제한 -윈도우는 쿠버네티스 아키텍처 및 컴포넌트 매트릭스에서 워커 노드로만 지원된다. 즉, 쿠버네티스 클러스터에는 항상 리눅스 마스터 노드가 반드시 포함되어야 하고, 0개 이상의 리눅스 워커 노드 및 0개 이상의 윈도우 워커 노드가 포함된다. +윈도우는 쿠버네티스 아키텍처 및 컴포넌트 매트릭스에서 워커 +노드로만 지원된다. 즉, 쿠버네티스 클러스터에는 항상 리눅스 마스터 노드가 반드시 +포함되어야 하고, 0개 이상의 리눅스 워커 노드 및 0개 이상의 윈도우 +워커 노드가 포함된다. #### 자원 관리 - 리눅스 cgroup은 리눅스에서 리소스 제어를 위한 파드 경계로 사용된다. 컨테이너는 네트워크, 프로세스 및 파일시스템 격리를 위해 해당 경계 내에 생성된다. cgroups API는 cpu/io/memory 통계를 수집하는 데 사용할 수 있다. 반대로 윈도우는 시스템 네임스페이스 필터가 있는 컨테이너별로 잡(Job) 오브젝트를 사용하여 컨테이너의 모든 프로세스를 포함하고 호스트와의 논리적 격리를 제공한다. 네임스페이스 필터링 없이 윈도우 컨테이너를 실행할 수 있는 방법은 없다. 즉, 시스템 권한은 호스트 컨텍스트에서 삽입 될(assert) 수 없으므로 권한이 있는(privileged) 컨테이너는 윈도우에서 사용할 수 없다. 보안 계정 매니져(Security Account Manager, SAM)가 분리되어 있으므로 컨테이너는 호스트의 ID를 가정할 수 없다. +리눅스 cgroup은 리눅스에서 리소스 제어를 위한 파드 경계로 사용된다. +컨테이너는 네트워크, 프로세스 및 파일시스템 격리를 위해 해당 +경계 내에 생성된다. cgroups API는 cpu/io/memory 통계를 수집하는 데 사용할 수 있다. +반대로 윈도우는 시스템 네임스페이스 필터가 있는 컨테이너별로 잡(Job) +오브젝트를 사용하여 컨테이너의 모든 프로세스를 포함하고 호스트와의 +논리적 격리를 제공한다. 네임스페이스 필터링 없이 윈도우 컨테이너를 +실행할 수 있는 방법은 없다. 즉, 시스템 권한은 호스트 컨텍스트에서 삽입될(assert) 수 없으므로 +권한이 있는(privileged) 컨테이너는 윈도우에서 사용할 수 없다. 보안 계정 +매니져(Security Account Manager, SAM)가 분리되어 있으므로 +컨테이너는 호스트의 ID를 가정할 수 없다. #### 자원 예약 ##### 메모리 예약 -윈도우에는 리눅스에는 있는 메모리 부족 프로세스 킬러가 없다. 윈도우는 모든 사용자-모드 메모리 할당을 항상 가상 메모리처럼 처리하며, 페이지파일이 필수이다. 결과적으로 윈도우에서는 리눅스에서 발생할 수 있는 메모리 부족 상태에 도달하지 않으며, 프로세스는 메모리 부족 (out of memory, OOM) 종료를 겪는 대신 디스크로 페이징한다. 메모리가 오버프로비저닝되고 모든 물리 메모리가 고갈되면 페이징으로 인해 성능이 저하될 수 있다. -kubelet 파라미터 `--kubelet-reserve` 를 사용하여 메모리 사용량을 합리적인 범위 내로 유지할 수 있으며, `--system-reserve` 를 사용하여 노드 (컨테이너 외부) 의 메모리 사용량을 예약할 수 있다. 이들을 사용하면 그만큼 [노드 할당(NodeAllocatable)](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)은 줄어든다. +윈도우에는 리눅스에는 있는 메모리 부족 프로세스 킬러가 없다. 윈도우는 +모든 사용자-모드 메모리 할당을 항상 가상 메모리처럼 처리하며, 페이지파일이 +필수이다. 결과적으로 윈도우에서는 리눅스에서 발생할 수 있는 +메모리 부족 상태에 도달하지 않으며, 프로세스는 메모리 부족(out of memory, OOM) 종료를 +겪는 대신 디스크로 페이징한다. 메모리가 오버프로비저닝되고 +모든 물리 메모리가 고갈되면 페이징으로 인해 성능이 저하될 수 있다. -{{< note >}} -워크로드를 배포할 때, 컨테이너에 리소스 제한을 걸어라 (제한만 설정하거나, 제한이 요청과 같아야 함). 이 또한 NodeAllocatable 에서 차감되며, 메모리가 꽉 찬 노드에 스케줄러가 파드를 할당하지 않도록 제한한다. -{{< /note >}} +kubelet 파라미터 `--kubelet-reserve` 를 사용하여 메모리 사용량을 +합리적인 범위 내로 유지할 수 있으며, `--system-reserve` 를 사용하여 +노드(컨테이너 외부)의 메모리 사용량을 예약할 수 있다. 이들을 사용하면 그만큼 +[노드 할당(NodeAllocatable)](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)은 줄어든다. -오버프로비저닝을 방지하는 가장 좋은 방법은 윈도우, 도커, 그리고 쿠버네티스 프로세스를 위해 최소 2GB 이상의 시스템 예약 메모리로 kubelet을 설정하는 것이다. +워크로드를 배포할 때, 컨테이너에 리소스 제한을 +걸어라(제한만 설정하거나, 제한이 요청과 같아야 함). 이 또한 NodeAllocatable에서 차감되며, +메모리가 꽉 찬 노드에 스케줄러가 파드를 할당하지 않도록 제한한다. + +오버프로비저닝을 방지하는 가장 좋은 방법은 윈도우, 도커, 그리고 +쿠버네티스 프로세스를 위해 최소 2GB 이상의 시스템 예약 메모리로 +kubelet을 설정하는 것이다. ##### CPU 예약 -윈도우, 도커, 그리고 다른 쿠버네티스 호스트 프로세스가 이벤트에 잘 응답할 수 있도록, CPU의 일정 비율을 예약하는 것이 좋다. 이 값은 윈도우 노드에 있는 CPU 코어 수에 따라 조정해야 한다. 이 비율을 결정하려면, 각 노드의 최대 파드 밀도(density)를 관찰하고, 시스템 서비스의 CPU 사용량을 모니터링하여 워크로드 요구사항을 충족하는 값을 선택해야 한다. -kubelet 파라미터 `--kubelet-reserve` 를 사용하여 CPU 사용량을 합리적인 범위 내로 유지할 수 있으며, `--system-reserve` 를 사용하여 노드 (컨테이너 외부) 의 CPU 사용량을 예약할 수 있다. 이들을 사용하면 그만큼 [노드 할당(NodeAllocatable)](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)은 줄어든다. +윈도우, 도커, 그리고 다른 쿠버네티스 호스트 프로세스가 이벤트에 +잘 응답할 수 있도록, CPU의 일정 비율을 예약하는 것이 +좋다. 이 값은 윈도우 노드에 있는 CPU 코어 수에 +따라 조정해야 한다. 이 비율을 결정하려면, 각 노드의 +최대 파드 밀도(density)를 관찰하고, 시스템 서비스의 CPU +사용량을 모니터링하여 워크로드 요구사항을 충족하는 값을 선택해야 한다. + +kubelet 파라미터 `--kubelet-reserve` 를 사용하여 CPU 사용량을 +합리적인 범위 내로 유지할 수 있으며, `--system-reserve` 를 사용하여 +노드 (컨테이너 외부) 의 CPU 사용량을 예약할 수 있다. 이들을 사용하면 그만큼 +[노드 할당(NodeAllocatable)](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)은 줄어든다. #### 기능 제한 + * TerminationGracePeriod: 구현되지 않음 * 단일 파일 매핑: CRI-ContainerD로 구현 예정 * 종료 메시지: CRI-ContainerD로 구현 예정 * 특권을 가진(Privileged) 컨테이너: 현재 윈도우 컨테이너에서 지원되지 않음 * HugePages: 현재 윈도우 컨테이너에서 지원되지 않음 -* 기존 노드 문제 감지기는 리눅스 전용이며 특권을 가진 컨테이너가 필요하다. 윈도우에서 특권을 가진 컨테이너를 지원하지 않기 때문에 일반적으로 윈도우에서 이 기능이 사용될 것으로 예상하지 않는다. -* 공유 네임스페이스의 모든 기능이 지원되는 것은 아니다. (자세한 내용은 API 섹션 참조). +* 기존 노드 문제 감지기는 리눅스 전용이며 특권을 가진 + 컨테이너가 필요하다. 윈도우에서 특권을 가진 컨테이너를 지원하지 않기 때문에 + 일반적으로 윈도우에서 이 기능이 사용될 것으로 예상하지 않는다. +* 공유 네임스페이스의 모든 기능이 지원되는 것은 아니다. (자세한 내용은 + API 섹션 참조). #### 각 플래그의 리눅스와의 차이점 + 윈도우 노드에서의 kubelet 플래그의 동작은 아래에 설명된 대로 다르게 동작한다. -* `--kubelet-reserve`, `--system-reserve`, `--eviction-hard` 플래그는 Node Allocatable 업데이트 +* `--kubelet-reserve`, `--system-reserve`, `--eviction-hard` 플래그는 + Node Allocatable 업데이트 + * `--enforce-node-allocable`을 사용한 축출(Eviction)은 구현되지 않았다. + * `--eviction-hard`와 `--eviction-soft`를 사용한 축출은 구현되지 않았다. + * MemoryPressure 조건은 구현되지 않았다. + * kubelet이 취한 OOM 축출 조치가 없다. -* 윈도우 노드에서 실행되는 Kubelet에는 메모리 제한이 없다. `--kubelet-reserve`와 `--system-reserve`는 호스트에서 실행되는 kubelet 또는 프로세스에 제한을 설정하지 않는다. 이는 호스트의 kubelet 또는 프로세스가 node-allocatable 및 스케줄러 외부에서 메모리 리소스 부족을 유발할 수 있음을 의미한다. -* kubelet 프로세스의 우선 순위를 설정하는 추가 플래그는 `--windows-priorityclass`라는 윈도우 노드에서 사용할 수 있다. 이 플래그를 사용하면 kubelet 프로세스가 윈도우 호스트에서 실행중인 다른 프로세스와 비교할 때 더 많은 CPU 시간 슬라이스을 얻을 수 있다. 허용되는 값과 그 의미에 대한 자세한 내용은 [윈도우 우선순위 클래스](https://docs.microsoft.com/en-us/windows/win32/procthread/scheduling-priorities#priority-class)에서 확인할 수 있다. kubelet이 항상 충분한 CPU주기를 갖도록 하려면 이 플래그를 `ABOVE_NORMAL_PRIORITY_CLASS` 이상으로 설정하는 것이 좋다. + +* 윈도우 노드에서 실행되는 Kubelet에는 메모리 제한이 없다. + `--kubelet-reserve`와 `--system-reserve`는 호스트에서 실행되는 kubelet 또는 + 프로세스에 제한을 설정하지 않는다. 이는 호스트의 kubelet 또는 프로세스가 + node-allocatable 및 스케줄러 외부에서 메모리 리소스 부족을 유발할 수 있음을 + 의미한다. + +* kubelet 프로세스의 우선 순위를 설정하는 추가 플래그는 + `--windows-priorityclass`라는 윈도우 노드에서 사용할 수 있다. 이 플래그를 사용하면 + kubelet 프로세스가 윈도우 호스트에서 실행중인 다른 프로세스와 비교할 때 더 많은 CPU 시간 + 슬라이스을 얻을 수 있다. 허용되는 값과 그 의미에 대한 자세한 내용은 + [윈도우 우선순위 클래스](https://docs.microsoft.com/en-us/windows/win32/procthread/scheduling-priorities#priority-class)에서 + 확인할 수 있다. + kubelet이 항상 충분한 CPU주기를 갖도록 하려면 + 이 플래그를 `ABOVE_NORMAL_PRIORITY_CLASS` 이상으로 설정하는 것이 좋다. #### 스토리지 -윈도우에는 컨테이너 계층을 마운트하고 NTFS를 기반으로 하는 복제 파일시스템을 만드는 레이어드(layered) 파일시스템 드라이버가 있다. 컨테이너의 모든 파일 경로는 해당 컨테이너의 컨텍스트 내에서만 확인된다. +윈도우에는 컨테이너 계층을 마운트하고 NTFS를 기반으로 하는 복제 파일시스템을 +만드는 레이어드(layered) 파일시스템 드라이버가 있다. 컨테이너의 모든 파일 경로는 +해당 컨테이너의 컨텍스트 내에서만 확인된다. -* 도커 볼륨 마운트는 개별 파일이 아닌 컨테이너의 디렉토리 만 대상으로 할 수 있다. 이 제한은 CRI-containerD에는 존재하지 않는다. -* 볼륨 마운트는 파일이나 디렉터리를 호스트 파일시스템으로 다시 투영할 수 없다. -* 읽기 전용 파일시스템은 윈도우 레지스트리 및 SAM 데이터베이스에 항상 쓰기 접근이 필요하기 때문에 지원되지 않는다. 그러나 읽기 전용 볼륨은 지원된다. -* 볼륨 사용자 마스크(user-masks) 및 권한은 사용할 수 없다. SAM은 호스트와 컨테이너 간에 공유되지 않기 때문에 이들 간에 매핑이 없다. 모든 권한은 컨테이너 컨텍스트 내에서 해결된다. +* 도커 볼륨 마운트는 개별 파일이 아닌 컨테이너의 + 디렉터리만 대상으로 할 수 있다. 이 제한은 CRI-containerD에는 존재하지 않는다. + +* 볼륨 마운트는 파일이나 디렉터리를 호스트 파일시스템으로 다시 + 투영할 수 없다. + +* 읽기 전용 파일시스템은 윈도우 레지스트리 및 SAM 데이터베이스에 항상 + 쓰기 접근이 필요하기 때문에 지원되지 않는다. 그러나 읽기 전용 + 볼륨은 지원된다. + +* 볼륨 사용자 마스크(user-masks) 및 권한은 사용할 수 없다. SAM은 + 호스트와 컨테이너 간에 공유되지 않기 때문에 이들 간에 매핑이 없다. 모든 + 권한은 컨테이너 컨텍스트 내에서 해결된다. 결과적으로, 다음 스토리지 기능은 윈도우 노드에서 지원되지 않는다. @@ -299,24 +693,61 @@ kubelet 파라미터 `--kubelet-reserve` 를 사용하여 CPU 사용량을 합 #### 네트워킹 {#네트워킹-제한} -윈도우 컨테이너 네트워킹은 리눅스 네트워킹과 몇 가지 중요한 면에서 다르다. [윈도우 컨테이너 네트워킹에 대한 Microsoft 문서](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/container-networking/architecture)에는 추가 세부 정보와 배경이 포함되어 있다. +윈도우 컨테이너 네트워킹은 리눅스 네트워킹과 몇 가지 중요한 면에서 +다르다. [윈도우 컨테이너 네트워킹에 대한 Microsoft 문서](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/container-networking/architecture)에는 +추가 세부 정보와 배경이 포함되어 있다. -윈도우 호스트 네트워킹 서비스와 가상 스위치는 네임스페이스를 구현하고 파드 또는 컨테이너에 필요한 가상 NIC을 만들 수 있다. 그러나 DNS, 라우트, 메트릭과 같은 많은 구성은 리눅스에서와 같이 /etc/... 파일이 아닌 윈도우 레지스트리 데이터베이스에 저장된다. 컨테이너의 윈도우 레지스트리는 호스트 레지스트리와 별개이므로 호스트에서 컨테이너로 /etc/resolv.conf를 매핑하는 것과 같은 개념은 리눅스에서와 동일한 효과를 갖지 않는다. 해당 컨테이너의 컨텍스트에서 실행되는 윈도우 API를 사용하여 구성해야 한다. 따라서 CNI 구현에서는 파일 매핑에 의존하는 대신 HNS를 호출하여 네트워크 세부 정보를 파드 또는 컨테이너로 전달해야 한다. +윈도우 호스트 네트워킹 서비스와 가상 스위치는 네임스페이스를 +구현하고 파드 또는 컨테이너에 필요한 가상 NIC을 만들 수 있다. 그러나 +DNS, 라우트, 메트릭과 같은 많은 구성은 리눅스에서와 같이 /etc/... 파일이 +아닌 윈도우 레지스트리 데이터베이스에 저장된다. 컨테이너의 +윈도우 레지스트리는 호스트 레지스트리와 별개이므로 호스트에서 +컨테이너로 /etc/resolv.conf를 매핑하는 것과 같은 개념은 리눅스에서와 +동일한 효과를 갖지 않는다. 해당 컨테이너의 컨텍스트에서 실행되는 윈도우 API를 +사용하여 구성해야 한다. 따라서 CNI 구현에서는 파일 매핑에 의존하는 +대신 HNS를 호출하여 네트워크 세부 정보를 파드 또는 컨테이너로 +전달해야 한다. 다음 네트워킹 기능은 윈도우 노드에서 지원되지 않는다. * 윈도우 파드에서는 호스트 네트워킹 모드를 사용할 수 없다. -* 노드 자체에서 로컬 NodePort 접근은 실패한다. (다른 노드 또는 외부 클라이언트에서는 가능) -* 노드에서 서비스 VIP에 접근하는 것은 향후 윈도우 서버 릴리스에서 사용할 수 있다. + +* 노드 자체에서 로컬 NodePort 접근은 실패한다. (다른 노드 또는 + 외부 클라이언트에서는 가능) + +* 노드에서 서비스 VIP에 접근하는 것은 향후 윈도우 서버 릴리스에서 + 사용할 수 있다. + * 한 서비스는 최대 64개의 백엔드 파드 또는 고유한 목적지 IP를 지원할 수 있다. -* kube-proxy의 오버레이 네트워킹 지원은 베타 기능이다. 또한 윈도우 서버 2019에 [KB4482887](https://support.microsoft.com/ko-kr/help/4482887/windows-10-update-kb4482887)을 설치해야 한다. + +* kube-proxy의 오버레이 네트워킹 지원은 베타 기능이다. 또한 + 윈도우 서버 2019에 [KB4482887](https://support.microsoft.com/ko-kr/help/4482887/windows-10-update-kb4482887)을 + 설치해야 한다. + * 비-DSR 모드의 로컬 트래픽 정책 -* 오버레이 네트워크에 연결된 윈도우 컨테이너는 IPv6 스택을 통한 통신을 지원하지 않는다. 이 네트워크 드라이버가 IPv6 주소를 사용하고 kubelet, kube-proxy 및 CNI 플러그인에서 후속 쿠버네티스 작업을 사용할 수 있도록 하는데 필요한 뛰어난 윈도우 플랫폼 작업이 있다. -* win-overlay, win-bridge, Azure-CNI 플러그인을 통해 ICMP 프로토콜을 사용하는 아웃바운드 통신. 특히, 윈도우 데이터 플레인([VFP](https://www.microsoft.com/en-us/research/project/azure-virtual-filtering-platform/))은 ICMP 패킷 치환을 지원하지 않는다. 이것은 다음을 의미한다. - * 동일한 네트워크(예: ping을 통한 파드 간 통신) 내의 목적지로 전달되는 ICMP 패킷은 예상대로 제한 없이 작동한다. + +* 오버레이 네트워크에 연결된 윈도우 컨테이너는 + IPv6 스택을 통한 통신을 지원하지 않는다. 이 네트워크 드라이버가 IPv6 주소를 + 사용하고 kubelet, kube-proxy 및 CNI 플러그인에서 후속 쿠버네티스 작업을 + 사용할 수 있도록 하는데 필요한 뛰어난 윈도우 플랫폼 작업이 있다. + +* win-overlay, win-bridge, Azure-CNI 플러그인을 통해 + ICMP 프로토콜을 사용하는 아웃바운드 통신. 특히, 윈도우 데이터 플레인 + ([VFP](https://www.microsoft.com/en-us/research/project/azure-virtual-filtering-platform/))은 + ICMP 패킷 치환을 지원하지 않는다. 이것은 다음을 의미한다. + + * 동일한 네트워크(예: ping을 통한 파드 간 통신) 내의 목적지로 전달되는 + ICMP 패킷은 예상대로 제한 없이 작동한다. + * TCP/UDP 패킷은 예상대로 제한 없이 작동한다. - * 원격 네트워크를 통과하도록 지정된 ICMP 패킷(예: ping을 통한 파드에서 외부 인터넷으로의 통신)은 치환될 수 없으므로 소스로 다시 라우팅되지 않는다. - * TCP/UDP 패킷은 여전히 ​​치환될 수 있기 때문에 `ping `을 `curl `으로 대체하여 외부와의 연결을 디버깅할 수 있다. + + * 원격 네트워크를 통과하도록 지정된 ICMP 패킷(예: ping을 통한 + 파드에서 외부 인터넷으로의 통신)은 치환될 수 없으므로 + 소스로 다시 라우팅되지 않는다. + + * TCP/UDP 패킷은 여전히 ​​치환될 수 있기 때문에 + `ping `을 `curl `으로 대체하여 + 외부와의 연결을 디버깅할 수 있다. 해당 기능은 쿠버네티스 v1.15에 추가되었다. @@ -324,334 +755,583 @@ kubelet 파라미터 `--kubelet-reserve` 를 사용하여 CPU 사용량을 합 ##### CNI 플러그인 -* 윈도우 참조 네트워크 플러그인 win-bridge와 win-overlay는 현재 "CHECK" 구현 누락으로 인해 [CNI 사양](https://github.com/containernetworking/cni/blob/master/SPEC.md) v0.4.0을 구현하지 않는다. +* 윈도우 참조 네트워크 플러그인 win-bridge와 win-overlay는 + 현재 "CHECK" 구현 누락으로 인해 [CNI 사양](https://github.com/containernetworking/cni/blob/master/SPEC.md) + v0.4.0을 구현하지 않는다. + * Flannel VXLAN CNI는 윈도우에서 다음과 같은 제한이 있다. -1. 노드-파드 연결은 설계상 불가능하다. Flannel v0.12.0(또는 그 이상)이 있는 로컬 파드에서만 가능하다. -2. VNI 4096와 UDP 4789 포트 사용은 제한된다. VNI 제한은 작업 중이며 향후 릴리스(오픈 소스 flannel 변경)에서 구현될 것이다. 이러한 파라미터에 대한 자세한 내용은 공식 [Flannel VXLAN](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan) 백엔드 문서를 참고한다. + 1. 노드-파드 연결은 설계상 불가능하다. Flannel v0.12.0(또는 그 이상)이 + 있는 로컬 파드에서만 가능하다. + + 1. VNI 4096와 UDP 4789 포트 사용은 제한된다. VNI 제한은 + 작업 중이며 향후 릴리스(오픈 소스 flannel 변경)에서 + 구현될 것이다. 이러한 파라미터에 대한 자세한 내용은 공식 + [Flannel VXLAN](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan) + 백엔드 문서를 참고한다. ##### DNS {#dns-limitations} -* ClusterFirstWithHostNet은 DNS에서 지원되지 않는다. 윈도우는 '.'이 있는 모든 이름을 FQDN으로 처리하고 PQDN 확인을 건너뛴다. -* 리눅스에서는 PQDN을 확인하려고 할 때 사용되는 DNS 접미사 목록이 있다. 윈도우에서는 해당 파드의 네임스페이스(예: mydns.svc.cluster.local)와 연결된 DNS 접미사인 DNS 접미사 1개만 있다. 윈도우는 FQDN과 서비스 또는 해당 접미사만으로 확인할 수 있는 이름을 확인할 수 있다. 예를 들어, 디폴트 네임스페이스에서 생성된 파드에는 DNS 접미사 **default.svc.cluster.local**이 있다. 윈도우 파드에서는 **kubernetes.default.svc.cluster.local** 및 **kubernetes**를 모두 확인할 수 있지만 **kubernetes.default** 또는 **kubernetes.default.svc**와 같은 중간 항목은 확인할 수 없다. -* 윈도우에서는 사용할 수 있는 여러 가지의 DNS 리졸버(resolver)가 있다. 이들은 약간 다른 동작을 제공하므로, 이름 쿼리 확인을 위해 `Resolve-DNSName` 유틸리티를 사용하는 것이 좋다. +* ClusterFirstWithHostNet은 DNS에서 지원되지 않는다. 윈도우는 + '.'이 있는 모든 이름을 FQDN으로 처리하고 PQDN 확인을 건너뛴다. + +* 리눅스에서는 PQDN을 확인하려고 할 때 사용되는 DNS 접미사 목록이 + 있다. 윈도우에서는 해당 파드의 네임스페이스(예: mydns.svc.cluster.local)와 + 연결된 DNS 접미사인 DNS 접미사 1개만 있다. + 윈도우는 FQDN과 서비스 또는 해당 접미사만으로 확인할 수 있는 이름을 확인할 수 + 있다. 예를 들어, 디폴트 네임스페이스에서 생성된 파드에는 DNS + 접미사 `default.svc.cluster.local`이 있다. 윈도우 파드에서는 + `kubernetes.default.svc.cluster.local` 및 `kubernetes`를 모두 확인할 수 + 있지만 `kubernetes.default` 또는 `kubernetes.default.svc`와 같은 중간 항목은 확인할 수 없다. + +* 윈도우에서는 사용할 수 있는 여러 가지의 DNS 리졸버(resolver)가 있다. 이들은 + 약간 다른 동작을 제공하므로, 이름 쿼리 확인을 위해 `Resolve-DNSName` 유틸리티를 + 사용하는 것이 좋다. ##### IPv6 -윈도우의 쿠버네티스는 단일 스택 "IPv6 전용" 네트워킹을 지원하지 않는다. 그러나 단일 제품군 서비스를 사용하는 파드와 노드에 대한 이중 스택 IPv4/IPv6 네트워킹이 지원된다. 자세한 내용은 [IPv4/IPv6 이중 스택 네트워킹](#ipv4ipv6-이중-스택)을 참고한다. +윈도우의 쿠버네티스는 단일 스택 "IPv6 전용" 네트워킹을 지원하지 않는다. +그러나 단일 제품군 서비스를 사용하는 파드와 노드에 대한 이중 스택 IPv4/IPv6 네트워킹이 +지원된다. +자세한 내용은 [IPv4/IPv6 이중 스택 네트워킹](#ipv4ipv6-이중-스택)을 참고한다. ##### 세션 어피니티(affinity) -`service.spec.sessionAffinityConfig.clientIP.timeoutSeconds`를 사용하는 윈도우 서비스의 최대 세션 고정(sticky) 시간 설정은 지원되지 않는다. +`service.spec.sessionAffinityConfig.clientIP.timeoutSeconds`를 사용하는 +윈도우 서비스의 최대 세션 고정(sticky) 시간 설정은 지원되지 않는다. ##### 보안 -시크릿(Secret)은 노드의 볼륨(리눅스의 tmpfs/in-memory와 비교)에 일반 텍스트로 작성된다. 이는 고객이 두 가지 작업을 수행해야 함을 의미한다. +시크릿(Secret)은 노드의 볼륨(리눅스의 tmpfs/in-memory와 +비교)에 일반 텍스트로 작성된다. 이는 고객이 두 가지 작업을 수행해야 함을 의미한다. 1. 파일 ACL을 사용하여 시크릿 파일 위치를 보호한다. -2. [BitLocker](https://docs.microsoft.com/ko-kr/windows/security/information-protection/bitlocker/bitlocker-how-to-deploy-on-windows-server)를 사용한 볼륨-레벨 암호화를 사용한다. +1. [BitLocker](https://docs.microsoft.com/ko-kr/windows/security/information-protection/bitlocker/bitlocker-how-to-deploy-on-windows-server)를 + 사용한 볼륨-레벨 암호화를 사용한다. -[RunAsUsername](/ko/docs/tasks/configure-pod-container/configure-runasusername)은 컨테이너 프로세스를 노드 기본 사용자로 실행하기 위해 윈도우 파드 또는 컨테이너에 지정할 수 있다. 이것은 [RunAsUser](/ko/docs/concepts/policy/pod-security-policy/#사용자-및-그룹)와 거의 동일하다. +[RunAsUsername](/ko/docs/tasks/configure-pod-container/configure-runasusername)은 +컨테이너 프로세스를 노드 기본 사용자로 실행하기 위해 윈도우 파드 또는 +컨테이너에 지정할 수 있다. 이것은 +[RunAsUser](/ko/docs/concepts/policy/pod-security-policy/#사용자-및-그룹)와 거의 동일하다. -SELinux, AppArmor, Seccomp, 기능(POSIX 기능)과 같은 리눅스 특유의 파드 시큐리티 컨텍스트 권한은 지원하지 않는다. +SELinux, AppArmor, Seccomp, 기능(POSIX 기능)과 같은 +리눅스 특유의 파드 시큐리티 컨텍스트 권한은 지원하지 않는다. -또한 이미 언급했듯이 특권을 가진 컨테이너는 윈도우에서 지원되지 않는다. +또한 이미 언급했듯이 특권을 가진 컨테이너는 윈도우에서 지원되지 +않는다. #### API -대부분의 Kubernetes API가 윈도우에서 작동하는 방식은 차이가 없다. 중요한 차이점은 OS와 컨테이너 런타임의 차이로 귀결된다. 특정 상황에서 파드 또는 컨테이너와 같은 워크로드 API의 일부 속성은 리눅스에서 구현되고 윈도우에서 실행되지 않는다는 가정 하에 설계되었다. +대부분의 Kubernetes API가 윈도우에서 작동하는 방식은 차이가 없다. +중요한 차이점은 OS와 컨테이너 런타임의 차이로 +귀결된다. 특정 상황에서 파드 또는 컨테이너와 같은 워크로드 API의 +일부 속성은 리눅스에서 구현되고 윈도우에서 실행되지 않는다는 가정 하에 +설계되었다. 높은 수준에서 이러한 OS 개념은 다르다. -* ID - 리눅스는 정수형으로 표시되는 userID(UID) 및 groupID(GID)를 사용한다. 사용자와 그룹 이름은 정식 이름이 아니다. UID+GID에 대한 `/etc/groups` 또는 `/etc/passwd`의 별칭일 뿐이다. 윈도우는 윈도우 보안 계정 관리자(Security Account Manager, SAM) 데이터베이스에 저장된 더 큰 이진 보안 식별자(SID)를 사용한다. 이 데이터베이스는 호스트와 컨테이너 간에 또는 컨테이너들 간에 공유되지 않는다. -* 파일 퍼미션 - 윈도우는 권한 및 UUID+GID의 비트 마스크(bitmask) 대신 SID를 기반으로 하는 접근 제어 목록을 사용한다. -* 파일 경로 - 윈도우의 규칙은 `/` 대신 `\`를 사용하는 것이다. Go IO 라이브러리는 두 가지 파일 경로 분리자를 모두 허용한다. 하지만, 컨테이너 내부에서 해석되는 경로 또는 커맨드 라인을 설정할 때 `\`가 필요할 수 있다. -* 신호(Signals) - 윈도우 대화형(interactive) 앱은 종료를 다르게 처리하며, 다음 중 하나 이상을 구현할 수 있다. - * UI 스레드는 WM_CLOSE를 포함하여 잘 정의된(well-defined) 메시지를 처리한다. - * 콘솔 앱은 컨트롤 핸들러(Control Handler)를 사용하여 ctrl-c 또는 ctrl-break를 처리한다. - * 서비스는 SERVICE_CONTROL_STOP 제어 코드를 수용할 수 있는 Service Control Handler 함수를 등록한다. +* ID - 리눅스는 정수형으로 표시되는 userID(UID) 및 groupID(GID)를 + 사용한다. 사용자와 그룹 이름은 정식 이름이 아니다. UID+GID에 대한 + `/etc/groups` 또는 `/etc/passwd`의 별칭일 뿐이다. 윈도우는 윈도우 + 보안 계정 관리자(Security Account Manager, SAM) 데이터베이스에 + 저장된 더 큰 이진 보안 식별자(SID)를 사용한다. 이 데이터베이스는 호스트와 + 컨테이너 간에 또는 컨테이너들 간에 공유되지 않는다. -종료 코드는 0일 때 성공, 0이 아닌 경우 실패인 동일한 규칙을 따른다. 특정 오류 코드는 윈도우와 리눅스에서 다를 수 있다. 그러나 쿠버네티스 컴포넌트(kubelet, kube-proxy)에서 전달된 종료 코드는 변경되지 않는다. +* 파일 퍼미션 - 윈도우는 권한 및 UUID+GID의 비트 마스크(bitmask) 대신 + SID를 기반으로 하는 접근 제어 목록을 사용한다. + +* 파일 경로 - 윈도우의 규칙은 `/` 대신 `\`를 사용하는 것이다. Go IO + 라이브러리는 두 가지 파일 경로 분리자를 모두 허용한다. 하지만, 컨테이너 + 내부에서 해석되는 경로 또는 커맨드 라인을 설정할 때 `\`가 필요할 수 + 있다. + +* 신호(Signals) - 윈도우 대화형(interactive) 앱은 종료를 다르게 처리하며, 다음 중 + 하나 이상을 구현할 수 있다. + + * UI 스레드는 `WM_CLOSE`를 포함하여 잘 정의된(well-defined) 메시지를 처리한다. + + * 콘솔 앱은 컨트롤 핸들러(Control Handler)를 사용하여 ctrl-c 또는 ctrl-break를 처리한다. + + * 서비스는 `SERVICE_CONTROL_STOP` 제어 코드를 수용할 수 있는 + Service Control Handler 함수를 등록한다. + +종료 코드는 0일 때 성공, 0이 아닌 경우 실패인 동일한 규칙을 따른다. +특정 오류 코드는 윈도우와 리눅스에서 다를 수 있다. 그러나 +쿠버네티스 컴포넌트(kubelet, kube-proxy)에서 전달된 종료 코드는 +변경되지 않는다. ##### V1.Container -* V1.Container.ResourceRequirements.limits.cpu 및 V1.Container.ResourceRequirements.limits.memory - 윈도우는 CPU 할당에 하드 리밋(hard limit)을 사용하지 않는다. 대신 공유 시스템이 사용된다. 밀리코어를 기반으로 하는 기존 필드는 윈도우 스케줄러가 뒤따르는 상대적인 공유로 스케일된다. [참고: kuberuntime/helpers_windows.go](https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/kuberuntime/helpers_windows.go), [참고: Microsoft 문서 내 리소스 제어](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/manage-containers/resource-controls) - * Huge page는 윈도우 컨테이너 런타임에서 구현되지 않으며, 사용할 수 없다. 컨테이너에 대해 구성할 수 없는 [사용자 권한(privilege) 어설트](https://docs.microsoft.com/en-us/windows/desktop/Memory/large-page-support)가 필요하다. -* V1.Container.ResourceRequirements.requests.cpu 및 V1.Container.ResourceRequirements.requests.memory - 노드의 사용 가능한 리소스에서 요청(requests)을 빼서, 노드에 대한 오버 프로비저닝을 방지하는데 사용할 수 있다. 그러나 오버 프로비저닝된 노드에서 리소스를 보장하는 데는 사용할 수 없다. 운영자가 오버 프로비저닝을 완전히 피하려는 경우 모범 사례로 모든 컨테이너에 적용해야 한다. -* V1.Container.SecurityContext.allowPrivilegeEscalation - 윈도우에서는 불가능하며, 어떤 기능도 연결되지 않는다. -* V1.Container.SecurityContext.Capabilities - POSIX 기능은 윈도우에서 구현되지 않는다. -* V1.Container.SecurityContext.privileged - 윈도우는 특권을 가진 컨테이너를 지원하지 않는다. +* V1.Container.ResourceRequirements.limits.cpu 및 + V1.Container.ResourceRequirements.limits.memory - 윈도우는 CPU 할당에 하드 + 리밋(hard limit)을 사용하지 않는다. 대신 공유 시스템이 사용된다. 밀리코어를 + 기반으로 하는 기존 필드는 윈도우 스케줄러가 뒤따르는 상대적인 공유로 + 스케일된다. + [참고: kuberuntime/helpers_windows.go](https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/kuberuntime/helpers_windows.go), + [참고: Microsoft 문서 내 리소스 제어](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/manage-containers/resource-controls) + + * Huge page는 윈도우 컨테이너 런타임에서 구현되지 않으며, + 사용할 수 없다. 컨테이너에 대해 구성할 수 없는 + [사용자 권한(privilege) 어설트](https://docs.microsoft.com/en-us/windows/desktop/Memory/large-page-support)가 + 필요하다. + +* V1.Container.ResourceRequirements.requests.cpu 및 + V1.Container.ResourceRequirements.requests.memory - 노드의 사용 가능한 + 리소스에서 요청(requests)을 빼서, 노드에 대한 오버 프로비저닝을 방지하는데 사용할 수 + 있다. 그러나 오버 프로비저닝된 노드에서 리소스를 보장하는 데는 + 사용할 수 없다. 운영자가 오버 프로비저닝을 완전히 피하려는 경우 + 모범 사례로 모든 컨테이너에 적용해야 한다. + +* V1.Container.SecurityContext.allowPrivilegeEscalation - 윈도우에서는 + 불가능하며, 어떤 기능도 연결되지 않는다. + +* V1.Container.SecurityContext.Capabilities - POSIX 기능은 윈도우에서 + 구현되지 않는다. + +* V1.Container.SecurityContext.privileged - 윈도우는 특권을 가진 컨테이너를 + 지원하지 않는다. + * V1.Container.SecurityContext.procMount - 윈도우에는 /proc 파일시스템이 없다. -* V1.Container.SecurityContext.readOnlyRootFilesystem - 윈도우에서는 불가능하며, 레지스트리 및 시스템 프로세스가 컨테이너 내부에서 실행되려면 쓰기 권한이 필요하다. + +* V1.Container.SecurityContext.readOnlyRootFilesystem - 윈도우에서는 불가능하며, + 레지스트리 및 시스템 프로세스가 컨테이너 내부에서 실행되려면 쓰기 권한이 + 필요하다. + * V1.Container.SecurityContext.runAsGroup - 윈도우에서는 불가능하며, GID 지원이 없다. -* V1.Container.SecurityContext.runAsNonRoot - 윈도우에는 root 사용자가 없다. 가장 가까운 항목은 노드에 존재하지 않는 아이덴티티(identity)인 ContainerAdministrator이다. -* V1.Container.SecurityContext.runAsUser - 윈도우에서는 불가능하며, 정수값으로의 UID 지원이 없다. + +* V1.Container.SecurityContext.runAsNonRoot - 윈도우에는 root 사용자가 + 없다. 가장 가까운 항목은 노드에 존재하지 않는 아이덴티티(identity)인 + ContainerAdministrator이다. + +* V1.Container.SecurityContext.runAsUser - 윈도우에서는 불가능하며, 정수값으로의 UID + 지원이 없다. + * V1.Container.SecurityContext.seLinuxOptions - 윈도우에서는 불가능하며, SELinux가 없다. -* V1.Container.terminationMessagePath - 윈도우가 단일 파일 매핑을 지원하지 않는다는 점에서 몇 가지 제한이 있다. 기본값은 /dev/termination-log이며, 기본적으로 윈도우에 존재하지 않기 때문에 작동한다. + +* V1.Container.terminationMessagePath - 윈도우가 단일 파일 매핑을 지원하지 + 않는다는 점에서 몇 가지 제한이 있다. 기본값은 /dev/termination-log이며, 기본적으로 윈도우에 존재하지 않기 때문에 + 작동한다. ##### V1.Pod * V1.Pod.hostIPC, v1.pod.hostpid - 윈도우에서 호스트 네임스페이스 공유가 불가능하다. + * V1.Pod.hostNetwork - 호스트 네트워크를 공유하기 위한 윈도우 OS 지원이 없다. -* V1.Pod.dnsPolicy - ClusterFirstWithHostNet - 윈도우에서 호스트 네트워킹이 지원되지 않기 때문에 지원되지 않는다. + +* V1.Pod.dnsPolicy - ClusterFirstWithHostNet - 윈도우에서 호스트 네트워킹이 지원되지 않기 때문에 + 지원되지 않는다. + * V1.Pod.podSecurityContext - 아래 V1.PodSecurityContext 내용을 참고한다. -* V1.Pod.shareProcessNamespace - 이것은 베타 기능이며, 윈도우에서 구현되지 않은 리눅스 네임스페이스에 따라 다르다. 윈도우는 프로세스 네임스페이스 또는 컨테이너의 루트 파일시스템을 공유할 수 없다. 네트워크만 공유할 수 있다. -* V1.Pod.terminationGracePeriodSeconds - 이것은 윈도우의 도커에서 완전히 구현되지 않았다. [참조](https://github.com/moby/moby/issues/25982)의 내용을 참고한다. 현재 동작은 ENTRYPOINT 프로세스가 CTRL_SHUTDOWN_EVENT로 전송된 다음, 윈도우가 기본적으로 5초를 기다린 후, 마지막으로 정상적인 윈도우 종료 동작을 사용하여 모든 프로세스를 종료하는 것이다. 5초 기본값은 실제로 [컨테이너 내부](https://github.com/moby/moby/issues/25982#issuecomment-426441183) 윈도우 레지스트리에 있으므로 컨테이너를 빌드할 때 재정의 할 수 있다. -* V1.Pod.volumeDevices - 이것은 베타 기능이며, 윈도우에서 구현되지 않는다. 윈도우는 원시 블록 장치(raw block device)를 파드에 연결할 수 없다. -* V1.Pod.volumes - EmptyDir, 시크릿, 컨피그맵, HostPath - 모두 작동하며 TestGrid에 테스트가 있다. - * V1.emptyDirVolumeSource - 노드 기본 매체는 윈도우의 디스크이다. 윈도우에는 내장 RAM 디스크가 없기 때문에 메모리는 지원되지 않는다. + +* V1.Pod.shareProcessNamespace - 이것은 베타 기능이며, 윈도우에서 구현되지 않은 + 리눅스 네임스페이스에 따라 다르다. 윈도우는 프로세스 네임스페이스 또는 + 컨테이너의 루트 파일시스템을 공유할 수 없다. 네트워크만 공유할 수 + 있다. + +* V1.Pod.terminationGracePeriodSeconds - 이것은 윈도우의 도커에서 + 완전히 구현되지 않았다. + [참조](https://github.com/moby/moby/issues/25982)의 내용을 참고한다. 현재 동작은 + `ENTRYPOINT` 프로세스가 `CTRL_SHUTDOWN_EVENT`로 전송된 다음, 윈도우가 기본적으로 5초를 + 기다린 후, 마지막으로 정상적인 윈도우 종료 동작을 사용하여 모든 프로세스를 + 종료하는 것이다. 5초 기본값은 실제로 + [컨테이너 내부](https://github.com/moby/moby/issues/25982#issuecomment-426441183) + 윈도우 레지스트리에 있으므로 컨테이너를 빌드할 때 재정의 할 수 있다. + +* V1.Pod.volumeDevices - 이것은 베타 기능이며, 윈도우에서 구현되지 + 않는다. 윈도우는 원시 블록 장치(raw block device)를 파드에 연결할 수 없다. + +* V1.Pod.volumes - EmptyDir, 시크릿, 컨피그맵, HostPath - 모두 작동하며 + TestGrid에 테스트가 있다. + + * V1.emptyDirVolumeSource - 노드 기본 매체는 윈도우의 디스크이다. + 윈도우에는 내장 RAM 디스크가 없기 때문에 메모리는 지원되지 않는다. + * V1.VolumeMount.mountPropagation - 마운트 전파(propagation)는 윈도우에서 지원되지 않는다. ##### V1.PodSecurityContext -PodSecurityContext 필드는 윈도우에서 작동하지 않는다. 참조를 위해 여기에 나열한다. +PodSecurityContext 필드는 윈도우에서 작동하지 않는다. 참조를 위해 여기에 +나열한다. * V1.PodSecurityContext.SELinuxOptions - SELinux는 윈도우에서 사용할 수 없다. + * V1.PodSecurityContext.RunAsUser - 윈도우에서는 사용할 수 없는 UID를 제공한다. + * V1.PodSecurityContext.RunAsGroup - 윈도우에서는 사용할 수 없는 GID를 제공한다. -* V1.PodSecurityContext.RunAsNonRoot - 윈도우에는 root 사용자가 없다. 가장 가까운 항목은 노드에 존재하지 않는 아이덴티티인 ContainerAdministrator이다. + +* V1.PodSecurityContext.RunAsNonRoot - 윈도우에는 root 사용자가 없다. 가장 + 가까운 항목은 노드에 존재하지 않는 아이덴티티인 + ContainerAdministrator이다. + * V1.PodSecurityContext.SupplementalGroups - 윈도우에서는 사용할 수 없는 GID를 제공한다. -* V1.PodSecurityContext.Sysctls - 이것들은 리눅스 sysctl 인터페이스의 일부이다. 윈도우에는 이에 상응하는 것이 없다. + +* V1.PodSecurityContext.Sysctls - 이것들은 리눅스 sysctl 인터페이스의 + 일부이다. 윈도우에는 이에 상응하는 것이 없다. #### 운영 체제 버전 제한 -윈도우에는 호스트 OS 버전이 컨테이너 베이스 이미지 OS 버전과 일치해야 하는 엄격한 호환성 규칙이 있다. 윈도우 서버 2019의 컨테이너 운영 체제가 있는 윈도우 컨테이너만 지원된다. 윈도우 컨테이너 이미지 버전의 일부 이전 버전과의 호환성을 가능하게 하는 컨테이너의 Hyper-V 격리는 향후 릴리스로 계획되어 있다. +윈도우에는 호스트 OS 버전이 컨테이너 베이스 이미지 OS 버전과 일치해야 하는 +엄격한 호환성 규칙이 있다. 윈도우 서버 2019의 컨테이너 +운영 체제가 있는 윈도우 컨테이너만 지원된다. 윈도우 컨테이너 이미지 버전의 일부 +이전 버전과의 호환성을 가능하게 하는 컨테이너의 Hyper-V 격리는 +향후 릴리스로 계획되어 있다. ## 도움 받기 및 트러블슈팅 {#troubleshooting} -쿠버네티스 클러스터 트러블슈팅을 위한 기본 도움말은 이 [섹션](/docs/tasks/debug-application-cluster/troubleshooting/)에서 먼저 찾아야 한다. 이 섹션에는 몇 가지 추가 윈도우 관련 트러블슈팅 도움말이 포함되어 있다. 로그는 쿠버네티스에서 트러블슈팅하는데 중요한 요소이다. 다른 기여자로부터 트러블슈팅 지원을 구할 때마다 이를 포함해야 한다. SIG-Windows [로그 수집에 대한 기여 가이드](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs)의 지침을 따른다. +쿠버네티스 클러스터 트러블슈팅을 위한 기본 +도움말은 이 +[섹션](/docs/tasks/debug-application-cluster/troubleshooting/)에서 먼저 찾아야 한다. 이 +섹션에는 몇 가지 추가 윈도우 관련 트러블슈팅 도움말이 포함되어 있다. +로그는 쿠버네티스에서 트러블슈팅하는데 중요한 요소이다. 다른 +기여자로부터 트러블슈팅 지원을 구할 때마다 이를 포함해야 +한다. SIG-Windows +[로그 수집에 대한 기여 가이드](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs)의 지침을 따른다. -1. start.ps1이 성공적으로 완료되었는지 어떻게 알 수 있는가? +* start.ps1이 성공적으로 완료되었는지 어떻게 알 수 있는가? - kubelet, kube-proxy 및 (Flannel을 네트워킹 솔루션으로 선택한 경우) 노드에서 실행 중인 flanneld 호스트 에이전트 프로세스를 확인할 수 있어야 하는데, 별도의 PowerShell 윈도우에서 실행 중인 로그가 표시된다. 또한 윈도우 노드는 쿠버네티스 클러스터에서 "Ready"로 조회되어야 한다. + kubelet, kube-proxy 및 (Flannel을 네트워킹 솔루션으로 + 선택한 경우) 노드에서 실행 중인 flanneld 호스트 에이전트 프로세스를 + 확인할 수 있어야 하는데, 별도의 PowerShell 윈도우에서 실행 중인 로그가 표시된다. 또한 + 윈도우 노드는 쿠버네티스 클러스터에서 "Ready"로 조회되어야 + 한다. -1. 백그라운드에서 서비스로 실행되도록 쿠버네티스 노드 프로세스를 구성할 수 있는가? +* 백그라운드에서 서비스로 실행되도록 쿠버네티스 노드 프로세스를 구성할 수 있는가? - Kubelet 및 kube-proxy는 이미 기본 윈도우 서비스로 실행되도록 구성되어 있으며, 실패(예: 프로세스 충돌) 시 서비스를 자동으로 다시 시작하여 복원력(resiliency)을 제공한다. 이러한 노드 컴포넌트를 서비스로 구성하기 위한 두 가지 옵션이 있다. + Kubelet 및 kube-proxy는 이미 기본 윈도우 서비스로 실행되도록 + 구성되어 있으며, 실패(예: 프로세스 충돌) 시 서비스를 + 자동으로 다시 시작하여 복원력(resiliency)을 + 제공한다. 이러한 노드 컴포넌트를 서비스로 구성하기 위한 + 두 가지 옵션이 있다. - 1. 네이티브 윈도우 서비스 + * 네이티브 윈도우 서비스 - Kubelet와 kube-proxy는 `sc.exe`를 사용하여 네이티브 윈도우 서비스로 실행될 수 있다. - - ```powershell - # 두 개의 개별 명령으로 kubelet 및 kube-proxy에 대한 서비스 생성 - sc.exe create <컴포넌트_명> binPath= "<바이너리_경로> --service <다른_인자>" - - # 인자에 공백이 포함된 경우 이스케이프 되어야 한다. - sc.exe create kubelet binPath= "C:\kubelet.exe --service --hostname-override 'minion' <다른_인자>" - - # 서비스 시작 - Start-Service kubelet - Start-Service kube-proxy - - # 서비스 중지 - Stop-Service kubelet (-Force) - Stop-Service kube-proxy (-Force) - - # 서비스 상태 질의 - Get-Service kubelet - Get-Service kube-proxy - ``` - - 1. nssm.exe 사용 - - 또한 언제든지 [nssm.exe](https://nssm.cc/)와 같은 대체 서비스 관리자를 사용하여 백그라운드에서 이러한 프로세스(flanneld, kubelet, kube-proxy)를 실행할 수 있다. 이 [샘플 스크립트](https://github.com/Microsoft/SDN/tree/master/Kubernetes/flannel/register-svc.ps1)를 사용하여 백그라운드에서 윈도우 서비스로 실행하기 위해 nssm.exe를 활용하여 kubelet, kube-proxy, flanneld.exe를 등록할 수 있다. - - ```powershell - register-svc.ps1 -NetworkMode <네트워크 모드> -ManagementIP <윈도우 노드 IP> -ClusterCIDR <클러스터 서브넷> -KubeDnsServiceIP -LogDir <로그 위치 디렉터리> - - # NetworkMode = 네트워크 모드 l2bridge(flannel host-gw, 기본값이기도 함) 또는 네트워크 솔루션으로 선택한 오버레이(flannel vxlan) - # ManagementIP = 윈도우 노드에 할당된 IP 주소. ipconfig를 사용하여 찾을 수 있다. - # ClusterCIDR = 클러스터 서브넷 범위. (기본값 10.244.0.0/16) - # KubeDnsServiceIP = 쿠버네티스 DNS 서비스 IP (기본값 10.96.0.10) - # LogDir = kubelet 및 kube-proxy 로그가 각각의 출력 파일로 리다이렉션되는 디렉터리(기본값 C:\k) - ``` - - 위에 언급된 스크립트가 적합하지 않은 경우, 다음 예제를 사용하여 nssm.exe를 수동으로 구성할 수 있다. - ```powershell - # flanneld.exe 등록 - nssm install flanneld C:\flannel\flanneld.exe - nssm set flanneld AppParameters --kubeconfig-file=c:\k\config --iface= --ip-masq=1 --kube-subnet-mgr=1 - nssm set flanneld AppEnvironmentExtra NODE_NAME= - nssm set flanneld AppDirectory C:\flannel - nssm start flanneld - - # kubelet.exe 등록 - # Microsoft는 mcr.microsoft.com/oss/kubernetes/pause:1.4.1에서 pause 인프라 컨테이너를 릴리스했다. - nssm install kubelet C:\k\kubelet.exe - nssm set kubelet AppParameters --hostname-override= --v=6 --pod-infra-container-image=mcr.microsoft.com/oss/kubernetes/pause:1.4.1 --resolv-conf="" --allow-privileged=true --enable-debugging-handlers --cluster-dns= --cluster-domain=cluster.local --kubeconfig=c:\k\config --hairpin-mode=promiscuous-bridge --image-pull-progress-deadline=20m --cgroups-per-qos=false --log-dir= --logtostderr=false --enforce-node-allocatable="" --network-plugin=cni --cni-bin-dir=c:\k\cni --cni-conf-dir=c:\k\cni\config - nssm set kubelet AppDirectory C:\k - nssm start kubelet - - # kube-proxy.exe 등록 (l2bridge / host-gw) - nssm install kube-proxy C:\k\kube-proxy.exe - nssm set kube-proxy AppDirectory c:\k - nssm set kube-proxy AppParameters --v=4 --proxy-mode=kernelspace --hostname-override=--kubeconfig=c:\k\config --enable-dsr=false --log-dir= --logtostderr=false - nssm.exe set kube-proxy AppEnvironmentExtra KUBE_NETWORK=cbr0 - nssm set kube-proxy DependOnService kubelet - nssm start kube-proxy - - # kube-proxy.exe 등록 (overlay / vxlan) - nssm install kube-proxy C:\k\kube-proxy.exe - nssm set kube-proxy AppDirectory c:\k - nssm set kube-proxy AppParameters --v=4 --proxy-mode=kernelspace --feature-gates="WinOverlay=true" --hostname-override= --kubeconfig=c:\k\config --network-name=vxlan0 --source-vip= --enable-dsr=false --log-dir= --logtostderr=false - nssm set kube-proxy DependOnService kubelet - nssm start kube-proxy - ``` - - - 초기 트러블슈팅을 위해 [nssm.exe](https://nssm.cc/)에서 다음 플래그를 사용하여 stdout 및 stderr을 출력 파일로 리다이렉션할 수 있다. - - ```powershell - nssm set AppStdout C:\k\mysvc.log - nssm set AppStderr C:\k\mysvc.log - ``` - - 자세한 내용은 공식 [nssm 사용](https://nssm.cc/usage) 문서를 참고한다. - -1. 내 윈도우 파드에 네트워크 연결이 없다. - - 가상 머신을 사용하는 경우, 모든 VM 네트워크 어댑터에서 MAC 스푸핑이 활성화되어 있는지 확인한다. - -1. 내 윈도우 파드가 외부 리소스를 ping 할 수 없다. - - 윈도우 파드에는 현재 ICMP 프로토콜용으로 프로그래밍된 아웃바운드 규칙이 없다. 그러나 TCP/UDP는 지원된다. 클러스터 외부 리소스에 대한 연결을 시연하려는 경우, `ping `를 해당 `curl `명령으로 대체한다. - - 여전히 문제가 발생하는 경우, [cni.conf](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf)의 네트워크 구성에 특별히 추가 확인이 필요하다. 언제든지 이 정적 파일을 편집할 수 있다. 구성 업데이트는 새로 생성된 모든 쿠버네티스 리소스에 적용된다. - - 쿠버네티스 네트워킹 요구 사항 중 하나([쿠버네티스 모델](/ko/docs/concepts/cluster-administration/networking/))는 클러스터 통신이 내부적으로 NAT 없이 발생하는 것이다. 이 요구 사항을 준수하기 위해 아웃바운드 NAT가 발생하지 않도록 하는 모든 통신에 대한 [ExceptionList](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf#L20)가 있다. 그러나 이것은 쿼리하려는 외부 IP를 ExceptionList에서 제외해야 함도 의미한다. 그래야만 윈도우 파드에서 발생하는 트래픽이 제대로 SNAT 되어 외부에서 응답을 받는다. 이와 관련하여 `cni.conf`의 ExceptionList는 다음과 같아야 한다. - - ```conf - "ExceptionList": [ - "10.244.0.0/16", # 클러스터 서브넷 - "10.96.0.0/12", # 서비스 서브넷 - "10.127.130.0/24" # 관리(호스트) 서브넷 - ] - ``` - -1. 내 윈도우 노드가 NodePort 서비스에 접근할 수 없다. - - 노드 자체에서는 로컬 NodePort 접근이 실패한다. 이것은 알려진 제약사항이다. NodePort 접근은 다른 노드 또는 외부 클라이언트에서는 가능하다. - -1. 컨테이너의 vNIC 및 HNS 엔드포인트가 삭제되었다. - - 이 문제는 `hostname-override` 파라미터가 [kube-proxy](/ko/docs/reference/command-line-tools-reference/kube-proxy/)에 전달되지 않은 경우 발생할 수 있다. 이를 해결하려면 사용자는 다음과 같이 hostname을 kube-proxy에 전달해야 한다. + Kubelet와 kube-proxy는 `sc.exe`를 사용하여 네이티브 윈도우 서비스로 실행될 수 있다. ```powershell - C:\k\kube-proxy.exe --hostname-override=$(hostname) + # 두 개의 개별 명령으로 kubelet 및 kube-proxy에 대한 서비스 생성 + sc.exe create <컴포넌트_명> binPath= "<바이너리_경로> --service <다른_인자>" + + # 인자에 공백이 포함된 경우 이스케이프 되어야 한다. + sc.exe create kubelet binPath= "C:\kubelet.exe --service --hostname-override 'minion' <다른_인자>" + + # 서비스 시작 + Start-Service kubelet + Start-Service kube-proxy + + # 서비스 중지 + Stop-Service kubelet (-Force) + Stop-Service kube-proxy (-Force) + + # 서비스 상태 질의 + Get-Service kubelet + Get-Service kube-proxy ``` -1. 플란넬(flannel)을 사용하면 클러스터에 다시 조인(join)한 후 노드에 이슈가 발생한다. + * nssm.exe 사용 - 이전에 삭제된 노드가 클러스터에 다시 조인될 때마다, flannelD는 새 파드 서브넷을 노드에 할당하려고 한다. 사용자는 다음 경로에서 이전 파드 서브넷 구성 파일을 제거해야 한다. + 또한 언제든지 [nssm.exe](https://nssm.cc/)와 같은 + 대체 서비스 관리자를 사용하여 백그라운드에서 이러한 프로세스(flanneld, kubelet, + kube-proxy)를 실행할 수 있다. 이 + [샘플 스크립트](https://github.com/Microsoft/SDN/tree/master/Kubernetes/flannel/register-svc.ps1)를 사용하여 + 백그라운드에서 윈도우 서비스로 실행하기 위해 `nssm.exe`를 활용하여 kubelet, kube-proxy, + `flanneld.exe`를 등록할 수 있다. ```powershell - Remove-Item C:\k\SourceVip.json - Remove-Item C:\k\SourceVipRequest.json + register-svc.ps1 -NetworkMode <네트워크 모드> -ManagementIP <윈도우 노드 IP> -ClusterCIDR <클러스터 서브넷> -KubeDnsServiceIP -LogDir <로그 위치 디렉터리> ``` + 파라미터 설명은 아래와 같다. -1. `start.ps1`을 시작한 후, flanneld가 "Waiting for the Network to be created"에서 멈춘다. + - `NetworkMode`: 네트워크 모드 l2bridge(flannel host-gw, + 기본값이기도 함) 또는 네트워크 솔루션으로 선택한 오버레이(flannel vxlan) + - `ManagementIP`: 윈도우 노드에 할당된 IP 주소. `ipconfig`를 사용하여 + 찾을 수 있다. + - `ClusterCIDR`: 클러스터 서브넷 범위. (기본값 10.244.0.0/16) + - `KubeDnsServiceIP`: 쿠버네티스 DNS 서비스 IP (기본값 10.96.0.10) + - `LogDir`: kubelet 및 kube-proxy 로그가 각각의 출력 파일로 + 리다이렉션되는 디렉터리(기본값 C:\k) - 이 [이슈](https://github.com/coreos/flannel/issues/1066)에 대한 수많은 보고가 있다. 플란넬 네트워크의 관리 IP가 설정될 때의 타이밍 이슈일 가능성이 높다. 해결 방법은 start.ps1을 다시 시작하거나 다음과 같이 수동으로 다시 시작하는 것이다. + 위에 언급된 스크립트가 적합하지 않은 경우, 다음 예제를 사용하여 + `nssm.exe`를 수동으로 구성할 수 있다. + + flanneld.exe를 등록한다. ```powershell - PS C:> [Environment]::SetEnvironmentVariable("NODE_NAME", "") - PS C:> C:\flannel\flanneld.exe --kubeconfig-file=c:\k\config --iface= --ip-masq=1 --kube-subnet-mgr=1 + nssm install flanneld C:\flannel\flanneld.exe + nssm set flanneld AppParameters --kubeconfig-file=c:\k\config --iface= --ip-masq=1 --kube-subnet-mgr=1 + nssm set flanneld AppEnvironmentExtra NODE_NAME= + nssm set flanneld AppDirectory C:\flannel + nssm start flanneld ``` -1. `/run/flannel/subnet.env` 누락으로 인해 윈도우 파드를 시작할 수 없다. - - 이것은 플란넬이 제대로 실행되지 않았음을 나타낸다. flanneld.exe를 다시 시작하거나 쿠버네티스 마스터의 `/run/flannel/subnet.env`에서 윈도우 워커 노드의 `C:\run\flannel\subnet.env`로 파일을 수동으로 복사할 수 있고, `FLANNEL_SUBNET` 행을 다른 숫자로 수정한다. 예를 들어, 다음은 노드 서브넷 10.244.4.1/24가 필요한 경우이다. - - ```env - FLANNEL_NETWORK=10.244.0.0/16 - FLANNEL_SUBNET=10.244.4.1/24 - FLANNEL_MTU=1500 - FLANNEL_IPMASQ=true - ``` - -1. 내 윈도우 노드가 서비스 IP를 사용하여 내 서비스에 접근할 수 없다. - - 이는 윈도우에서 현재 네트워킹 스택의 알려진 제약 사항이다. 그러나 윈도우 파드는 서비스 IP에 접근할 수 있다. - -1. kubelet을 시작할 때 네트워크 어댑터를 찾을 수 없다. - - 윈도우 네트워킹 스택에는 쿠버네티스 네트워킹이 작동하기 위한 가상 어댑터가 필요하다. 다음 명령이 (어드민 셸에서) 결과를 반환하지 않으면, Kubelet이 작동하는데 필요한 필수 구성 요소인 가상 네트워크 생성이 실패한 것이다. + kubelet.exe를 등록한다. ```powershell - Get-HnsNetwork | ? Name -ieq "cbr0" - Get-NetAdapter | ? Name -Like "vEthernet (Ethernet*" + # Microsoft는 mcr.microsoft.com/oss/kubernetes/pause:1.4.1에서 pause 인프라 컨테이너를 릴리스했다. + nssm install kubelet C:\k\kubelet.exe + nssm set kubelet AppParameters --hostname-override= --v=6 --pod-infra-container-image=mcr.microsoft.com/oss/kubernetes/pause:1.4.1 --resolv-conf="" --allow-privileged=true --enable-debugging-handlers --cluster-dns= --cluster-domain=cluster.local --kubeconfig=c:\k\config --hairpin-mode=promiscuous-bridge --image-pull-progress-deadline=20m --cgroups-per-qos=false --log-dir= --logtostderr=false --enforce-node-allocatable="" --network-plugin=cni --cni-bin-dir=c:\k\cni --cni-conf-dir=c:\k\cni\config + nssm set kubelet AppDirectory C:\k + nssm start kubelet ``` - 호스트 네트워크 어댑터가 "Ethernet"이 아닌 경우, 종종 start.ps1 스크립트의 [InterfaceName](https://github.com/microsoft/SDN/blob/master/Kubernetes/flannel/start.ps1#L7) 파라미터를 수정하는 것이 좋다. 그렇지 않으면 `start-kubelet.ps1` 스크립트의 출력을 참조하여 가상 네트워크 생성 중에 오류가 있는지 확인한다. + kube-proxy.exe를 등록한다(l2bridge / host-gw). -1. 내 파드가 "Container Creating"에서 멈췄거나 계속해서 다시 시작된다. - - pause 이미지가 OS 버전과 호환되는지 확인한다. [지침](https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/deploying-resources)에서는 OS와 컨테이너가 모두 버전 1803이라고 가정한다. 이후 버전의 윈도우가 있는 경우, Insider 빌드와 같이 그에 따라 이미지를 조정해야 한다. 이미지는 Microsoft의 [도커 리포지터리](https://hub.docker.com/u/microsoft/)를 참조한다. 그럼에도 불구하고, pause 이미지 Dockerfile과 샘플 서비스는 이미지가 :latest로 태그될 것으로 예상한다. - -1. DNS 확인(resolution)이 제대로 작동하지 않는다. - - 이 [섹션](#dns-limitations)에서 윈도우에 대한 DNS 제한을 확인한다. - -1. `kubectl port-forward`가 "unable to do port forwarding: wincat not found"로 실패한다. - - 이는 쿠버네티스 1.15 및 pause 인프라 컨테이너 `mcr.microsoft.com/oss/kubernetes/pause:1.4.1`에서 구현되었다. 해당 버전 또는 최신 버전을 사용해야 한다. - 자체 pause 인프라 컨테이너를 빌드하려면 [wincat](https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat)을 포함해야 한다. - -1. 내 윈도우 서버 노드가 프록시 뒤에 있기 때문에 내 쿠버네티스 설치가 실패한다. - - 프록시 뒤에 있는 경우 다음 PowerShell 환경 변수를 정의해야 한다. - - ```PowerShell - [Environment]::SetEnvironmentVariable("HTTP_PROXY", "http://proxy.example.com:80/", [EnvironmentVariableTarget]::Machine) - [Environment]::SetEnvironmentVariable("HTTPS_PROXY", "http://proxy.example.com:443/", [EnvironmentVariableTarget]::Machine) + ```powershell + nssm install kube-proxy C:\k\kube-proxy.exe + nssm set kube-proxy AppDirectory c:\k + nssm set kube-proxy AppParameters --v=4 --proxy-mode=kernelspace --hostname-override=--kubeconfig=c:\k\config --enable-dsr=false --log-dir= --logtostderr=false + nssm.exe set kube-proxy AppEnvironmentExtra KUBE_NETWORK=cbr0 + nssm set kube-proxy DependOnService kubelet + nssm start kube-proxy ``` -1. `pause` 컨테이너란 무엇인가? + kube-proxy.exe를 등록한다(overlay / vxlan). - 쿠버네티스 파드에서는 컨테이너 엔드포인트를 호스팅하기 위해 먼저 인프라 또는 "pause" 컨테이너가 생성된다. 인프라 및 워커 컨테이너를 포함하여 동일한 파드에 속하는 컨테이너는 공통 네트워크 네임스페이스 및 엔드포인트(동일한 IP 및 포트 공간)를 공유한다. 네트워크 구성을 잃지 않고 워커 컨테이너가 충돌하거나 다시 시작되도록 하려면 pause 컨테이너가 필요하다. + ```powershell + nssm install kube-proxy C:\k\kube-proxy.exe + nssm set kube-proxy AppDirectory c:\k + nssm set kube-proxy AppParameters --v=4 --proxy-mode=kernelspace --feature-gates="WinOverlay=true" --hostname-override= --kubeconfig=c:\k\config --network-name=vxlan0 --source-vip= --enable-dsr=false --log-dir= --logtostderr=false + nssm set kube-proxy DependOnService kubelet + nssm start kube-proxy + ``` - "pause" (인프라) 이미지는 Microsoft Container Registry(MCR)에서 호스팅된다. `mcr.microsoft.com/oss/kubernetes/pause:1.4.1`을 사용하여 접근할 수 있다. 자세한 내용은 [DOCKERFILE](https://github.com/kubernetes-sigs/windows-testing/blob/master/images/pause/Dockerfile)을 참고한다. + + 초기 트러블슈팅을 위해 [nssm.exe](https://nssm.cc/)에서 + 다음 플래그를 사용하여 stdout 및 stderr을 출력 파일로 리다이렉션할 수 있다. + + ```powershell + nssm set AppStdout C:\k\mysvc.log + nssm set AppStderr C:\k\mysvc.log + ``` + + 자세한 내용은 공식 [nssm 사용](https://nssm.cc/usage) 문서를 참고한다. + +* 내 윈도우 파드에 네트워크 연결이 없다. + + 가상 머신을 사용하는 경우, 모든 VM 네트워크 어댑터에서 MAC 스푸핑이 + 활성화되어 있는지 확인한다. + +* 내 윈도우 파드가 외부 리소스를 ping 할 수 없다. + + 윈도우 파드에는 현재 ICMP 프로토콜용으로 프로그래밍된 아웃바운드 + 규칙이 없다. 그러나 TCP/UDP는 지원된다. 클러스터 외부 리소스에 대한 연결을 + 시연하려는 경우, `ping `를 해당 `curl `명령으로 + 대체한다. + + 여전히 문제가 발생하는 경우, + [cni.conf](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf)의 + 네트워크 구성에 특별히 추가 확인이 필요하다. 언제든지 이 정적 파일을 편집할 수 있다. 구성 + 업데이트는 새로 생성된 모든 쿠버네티스 리소스에 적용된다. + + 쿠버네티스 네트워킹 요구 사항 중 + 하나([쿠버네티스 모델](/ko/docs/concepts/cluster-administration/networking/))는 + 클러스터 통신이 내부적으로 NAT 없이 발생하는 것이다. 이 요구 사항을 + 준수하기 위해 아웃바운드 NAT가 발생하지 않도록 하는 모든 통신에 대한 + [ExceptionList](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf#L20)가 + 있다. 그러나 + 이것은 쿼리하려는 외부 IP를 ExceptionList에서 + 제외해야 함도 의미한다. 그래야만 윈도우 파드에서 발생하는 트래픽이 제대로 SNAT 되어 + 외부에서 응답을 받는다. 이와 관련하여 `cni.conf`의 ExceptionList는 다음과 + 같아야 한다. + + ```conf + "ExceptionList": [ + "10.244.0.0/16", # 클러스터 서브넷 + "10.96.0.0/12", # 서비스 서브넷 + "10.127.130.0/24" # 관리(호스트) 서브넷 + ] + ``` + +* 내 윈도우 노드가 NodePort 서비스에 접근할 수 없다. + + 노드 자체에서는 로컬 NodePort 접근이 실패한다. 이것은 알려진 + 제약사항이다. NodePort 접근은 다른 노드 또는 외부 클라이언트에서는 가능하다. + +* 컨테이너의 vNIC 및 HNS 엔드포인트가 삭제되었다. + + 이 문제는 `hostname-override` 파라미터가 + [kube-proxy](/ko/docs/reference/command-line-tools-reference/kube-proxy/)에 + 전달되지 않은 경우 발생할 수 있다. + 이를 해결하려면 사용자는 다음과 같이 hostname을 kube-proxy에 전달해야 한다. + + ```powershell + C:\k\kube-proxy.exe --hostname-override=$(hostname) + ``` + +* 플란넬(flannel)을 사용하면 클러스터에 다시 조인(join)한 후 노드에 이슈가 발생한다. + + 이전에 삭제된 노드가 클러스터에 다시 조인될 때마다, + flannelD는 새 파드 서브넷을 노드에 할당하려고 한다. 사용자는 다음 경로에서 + 이전 파드 서브넷 구성 파일을 제거해야 한다. + + ```powershell + Remove-Item C:\k\SourceVip.json + Remove-Item C:\k\SourceVipRequest.json + ``` + +* `start.ps1`을 시작한 후, flanneld가 "Waiting for the Network + to be created"에서 멈춘다. + + 이 [이슈](https://github.com/coreos/flannel/issues/1066)에 + 대한 수많은 보고가 있다. 플란넬 네트워크의 + 관리 IP가 설정될 때의 타이밍 이슈일 가능성이 높다. 해결 + 방법은 start.ps1을 다시 시작하거나 다음과 같이 수동으로 다시 시작하는 것이다. + + ```powershell + PS C:> [Environment]::SetEnvironmentVariable("NODE_NAME", "") + PS C:> C:\flannel\flanneld.exe --kubeconfig-file=c:\k\config --iface= --ip-masq=1 --kube-subnet-mgr=1 + ``` + +* `/run/flannel/subnet.env` 누락으로 인해 윈도우 파드를 시작할 수 없다. + + 이것은 플란넬이 제대로 실행되지 않았음을 나타낸다. flanneld.exe를 + 다시 시작하거나 쿠버네티스 마스터의 + `/run/flannel/subnet.env`에서 윈도우 워커 노드의 + `C:\run\flannel\subnet.env`로 파일을 수동으로 복사할 수 있고, + `FLANNEL_SUBNET` 행을 다른 숫자로 수정한다. 예를 들어, 다음은 노드 서브넷 + 10.244.4.1/24가 필요한 경우이다. + + ```none + FLANNEL_NETWORK=10.244.0.0/16 + FLANNEL_SUBNET=10.244.4.1/24 + FLANNEL_MTU=1500 + FLANNEL_IPMASQ=true + ``` + +* 내 윈도우 노드가 서비스 IP를 사용하여 내 서비스에 접근할 수 없다. + + 이는 윈도우에서 현재 네트워킹 스택의 알려진 제약 사항이다. + 그러나 윈도우 파드는 서비스 IP에 접근할 수 있다. + +* kubelet을 시작할 때 네트워크 어댑터를 찾을 수 없다. + + 윈도우 네트워킹 스택에는 쿠버네티스 네트워킹이 작동하기 위한 + 가상 어댑터가 필요하다. 다음 명령이 (어드민 셸에서) 결과를 반환하지 + 않으면, Kubelet이 작동하는데 필요한 필수 구성 요소인 가상 네트워크 생성이 + 실패한 것이다. + + ```powershell + Get-HnsNetwork | ? Name -ieq "cbr0" + Get-NetAdapter | ? Name -Like "vEthernet (Ethernet*" + ``` + + 호스트 네트워크 어댑터가 "Ethernet"이 아닌 경우, + 종종 start.ps1 스크립트의 + [InterfaceName](https://github.com/microsoft/SDN/blob/master/Kubernetes/flannel/start.ps1#L7) + 파라미터를 수정하는 것이 좋다. 그렇지 않으면 `start-kubelet.ps1` + 스크립트의 출력을 참조하여 가상 네트워크 생성 중에 오류가 있는지 확인한다. + +* 내 파드가 "Container Creating"에서 멈췄거나 계속해서 다시 시작된다. + + pause 이미지가 OS 버전과 호환되는지 확인한다. + [지침](https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/deploying-resources)에서는 + OS와 컨테이너가 모두 버전 1803이라고 가정한다. 이후 버전의 + 윈도우가 있는 경우, Insider 빌드와 같이 그에 따라 이미지를 + 조정해야 한다. 이미지는 Microsoft의 + [도커 리포지터리](https://hub.docker.com/u/microsoft/)를 참조한다. + 그럼에도 불구하고, pause 이미지 Dockerfile과 샘플 서비스는 이미지가 + :latest로 태그될 것으로 예상한다. + +* DNS 확인(resolution)이 제대로 작동하지 않는다. + + [윈도우에 대한 DNS 제한](#dns-limitations)을 확인한다. + +* `kubectl port-forward`가 "unable to do port forwarding: wincat not found"로 실패한다. + + 이는 쿠버네티스 1.15 및 pause 인프라 컨테이너 + `mcr.microsoft.com/oss/kubernetes/pause:1.4.1`에서 구현되었다. + 해당 버전 또는 최신 버전을 사용해야 한다. 자체 pause + 인프라 컨테이너를 빌드하려면 + [wincat](https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat)을 포함해야 한다. + +* 내 윈도우 서버 노드가 프록시 뒤에 있기 때문에 내 쿠버네티스 + 설치가 실패한다. + + 프록시 뒤에 있는 경우 다음 PowerShell 환경 변수를 + 정의해야 한다. + + ```PowerShell + [Environment]::SetEnvironmentVariable("HTTP_PROXY", "http://proxy.example.com:80/", [EnvironmentVariableTarget]::Machine) + [Environment]::SetEnvironmentVariable("HTTPS_PROXY", "http://proxy.example.com:443/", [EnvironmentVariableTarget]::Machine) + ``` + +* `pause` 컨테이너란 무엇인가? + + 쿠버네티스 파드에서는 컨테이너 엔드포인트를 호스팅하기 위해 + 먼저 인프라 또는 "pause" 컨테이너가 생성된다. 인프라 및 워커 컨테이너를 포함하여 + 동일한 파드에 속하는 컨테이너는 공통 네트워크 네임스페이스 및 + 엔드포인트(동일한 IP 및 포트 공간)를 공유한다. 네트워크 구성을 잃지 않고 + 워커 컨테이너가 충돌하거나 다시 시작되도록 하려면 pause 컨테이너가 + 필요하다. + + "pause" (인프라) 이미지는 Microsoft Container Registry(MCR)에서 + 호스팅된다. `mcr.microsoft.com/oss/kubernetes/pause:1.4.1`을 사용하여 접근할 수 있다. + 자세한 내용은 + [DOCKERFILE](https://github.com/kubernetes-sigs/windows-testing/blob/master/images/pause/Dockerfile)을 참고한다. ### 추가 조사 -이러한 단계로 문제가 해결되지 않으면, 다음을 통해 쿠버네티스의 윈도우 노드에서 윈도우 컨테이너를 실행하는데 도움을 받을 수 있다. +이러한 단계로 문제가 해결되지 않으면, 다음을 통해 쿠버네티스의 윈도우 노드에서 +윈도우 컨테이너를 실행하는데 도움을 받을 수 있다. * 스택오버플로우 [윈도우 서버 컨테이너](https://stackoverflow.com/questions/tagged/windows-server-container) 주제 + * 쿠버네티스 공식 포럼 [discuss.kubernetes.io](https://discuss.kubernetes.io/) + * 쿠버네티스 슬랙 [#SIG-Windows Channel](https://kubernetes.slack.com/messages/sig-windows) ## 이슈 리포팅 및 기능 요청 -버그처럼 보이는 부분이 있거나 기능 요청을 하고 싶다면, [GitHub 이슈 트래킹 시스템](https://github.com/kubernetes/kubernetes/issues)을 활용한다. [GitHub](https://github.com/kubernetes/kubernetes/issues/new/choose)에서 이슈를 열고 SIG-Windows에 할당할 수 있다. 먼저 이전에 보고된 이슈 목록을 검색하고 이슈에 대한 경험을 언급하고 추가 로그를 첨부해야 한다. SIG-Windows 슬랙은 티켓을 만들기 전에 초기 지원 및 트러블슈팅 아이디어를 얻을 수 있는 좋은 방법이기도 하다. +버그처럼 보이는 부분이 있거나 기능 +요청을 하고 싶다면, +[GitHub 이슈 트래킹 시스템](https://github.com/kubernetes/kubernetes/issues)을 +활용한다. +[GitHub](https://github.com/kubernetes/kubernetes/issues/new/choose)에서 이슈를 열고 +SIG-Windows에 할당할 수 있다. 먼저 이전에 보고된 이슈 목록을 검색하고 +이슈에 대한 경험을 언급하고 추가 로그를 +첨부해야 한다. SIG-Windows 슬랙은 티켓을 만들기 전에 초기 지원 및 +트러블슈팅 아이디어를 얻을 수 있는 좋은 방법이기도 하다. -버그를 제출하는 경우, 다음과 같이 문제를 재현하는 방법에 대한 자세한 정보를 포함한다. +버그를 제출하는 경우, 다음과 같이 문제를 재현하는 방법에 대한 자세한 정보를 +포함한다. * 쿠버네티스 버전: kubectl version -* 환경 세부사항: 클라우드 공급자, OS 배포판, 네트워킹 선택 및 구성, 도커 버전 +* 환경 세부사항: 클라우드 공급자, OS 배포판, 네트워킹 선택 및 + 구성, 도커 버전 * 문제를 재현하기 위한 세부 단계 * [관련 로그](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs) -* SIG-Windows 회원의 주의를 끌 수 있도록 `/sig windows`로 이슈에 대해 어노테이션을 달아 이슈에 sig/windows 태그를 지정한다. +* SIG-Windows 회원의 주의를 끌 수 있도록 `/sig windows`로 이슈에 대해 어노테이션을 달아 + 이슈에 sig/windows 태그를 지정한다. ## {{% heading "whatsnext" %}} -로드맵에는 많은 기능이 있다. 요약된 높은 수준의 목록이 아래에 포함되어 있지만, [로드맵 프로젝트](https://github.com/orgs/kubernetes/projects/8)를 보고 [기여](https://github.com/kubernetes/community/blob/master/sig-windows/)하여 윈도우 지원을 개선하는데 도움이 주는 것이 좋다. +로드맵에는 많은 기능이 있다. 요약된 높은 수준의 +목록이 아래에 포함되어 있지만, +[로드맵 프로젝트](https://github.com/orgs/kubernetes/projects/8)를 보고 +[기여](https://github.com/kubernetes/community/blob/master/sig-windows/)하여 +윈도우 지원을 개선하는데 도움이 주는 것이 좋다. ### Hyper-V 격리(isolation) -쿠버네티스에서 윈도우 컨테이너에 대해 다음 유스케이스를 사용하려면 Hyper-V 격리가 필요하다. +쿠버네티스에서 윈도우 컨테이너에 대해 다음 유스케이스를 사용하려면 +Hyper-V 격리가 필요하다. * 추가 보안을 위해 파드 간 하이퍼바이저 기반 격리 -* 하위 호환성을 통해 컨테이너를 다시 빌드할 필요 없이 노드에서 최신 윈도우 서버 버전을 실행할 수 있다. + +* 하위 호환성을 통해 컨테이너를 다시 빌드할 필요 없이 노드에서 + 최신 윈도우 서버 버전을 실행할 수 있다. + * 파드에 대한 특정 CPU/NUMA 설정 + * 메모리 격리 및 예약 -Hyper-V 격리 지원은 이후 릴리스에 추가되며 CRI-Containerd가 필요하다. +Hyper-V 격리 지원은 이후 릴리스에 추가되며 +CRI-Containerd가 필요하다. ### kubeadm 및 클러스터 API를 사용한 배포 Kubeadm은 사용자가 쿠버네티스 클러스터를 배포하기 위한 사실상의 표준이 되고 있다. kubeadm의 윈도우 노드 지원은 현재 작업 중이지만 -[여기](/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/)에서 가이드를 사용할 수 있다. +[여기](/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/)에서 +가이드를 사용할 수 있다. 또한 윈도우 노드가 적절하게 프로비저닝되도록 클러스터 API에 투자하고 있다. From 3564a5fd995db0de411645e2277d300b99815582 Mon Sep 17 00:00:00 2001 From: Jai Govindani Date: Fri, 28 May 2021 08:07:31 +0700 Subject: [PATCH 052/128] fix(redirects/kubectl-cmds): add ! to 301 Adding an "!" after the 301 to see if that fixes/makes the redirect work --- static/_redirects | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/static/_redirects b/static/_redirects index 0c04b14703..7798608979 100644 --- a/static/_redirects +++ b/static/_redirects @@ -204,7 +204,7 @@ /docs/reference/glossary/maintainer/ /docs/reference/glossary/approver/ 301 -/docs/reference/kubectl/kubectl-cmds/ /docs/reference/generated/kubectl/kubectl-commands/ 301 +/docs/reference/kubectl/kubectl-cmds/ /docs/reference/generated/kubectl/kubectl-commands/ 301! /docs/reference/kubectl/kubectl/kubectl_*.md /docs/reference/generated/kubectl/kubectl-commands#:splat 301 /docs/reference/scheduling/profiles/ /docs/reference/scheduling/config/#profiles 301 From 8c4a748db19a7284407ee693e4aacede21240fe4 Mon Sep 17 00:00:00 2001 From: John Kwiatkoski Date: Fri, 28 May 2021 09:10:47 -0400 Subject: [PATCH 053/128] Update default pod limits This update modifies the "pods-per-node" recommendation to align with the default Kubernetes setting of 110 pods per node. --- content/en/docs/setup/best-practices/cluster-large.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/setup/best-practices/cluster-large.md b/content/en/docs/setup/best-practices/cluster-large.md index 81b6404f37..13970266f9 100644 --- a/content/en/docs/setup/best-practices/cluster-large.md +++ b/content/en/docs/setup/best-practices/cluster-large.md @@ -12,7 +12,7 @@ or virtual machines) running Kubernetes agents, managed by the Kubernetes {{< param "version" >}} supports clusters with up to 5000 nodes. More specifically, Kubernetes is designed to accommodate configurations that meet *all* of the following criteria: -* No more than 100 pods per node +* No more than 110 pods per node * No more than 5000 nodes * No more than 150000 total pods * No more than 300000 total containers From 610835108f8f193ac99a032f45ca649e82fec417 Mon Sep 17 00:00:00 2001 From: Jeremy Cowan Date: Fri, 28 May 2021 21:47:14 -0500 Subject: [PATCH 054/128] Update resource-bin-packing.md The original documentation was using `Profile` instead of the `KubeSchedulerConfiguration`. Also clarified how you pass this configuration to the scheduler. --- .../resource-bin-packing.md | 51 ++++++++++--------- 1 file changed, 26 insertions(+), 25 deletions(-) diff --git a/content/en/docs/concepts/scheduling-eviction/resource-bin-packing.md b/content/en/docs/concepts/scheduling-eviction/resource-bin-packing.md index a7b3639366..e294537c4b 100644 --- a/content/en/docs/concepts/scheduling-eviction/resource-bin-packing.md +++ b/content/en/docs/concepts/scheduling-eviction/resource-bin-packing.md @@ -26,40 +26,41 @@ each resource to score nodes based on the request to capacity ratio. This allows users to bin pack extended resources by using appropriate parameters and improves the utilization of scarce resources in large clusters. The behavior of the `RequestedToCapacityRatioResourceAllocation` priority function -can be controlled by a configuration option called -`requestedToCapacityRatioArguments`. This argument consists of two parameters -`shape` and `resources`. The `shape` parameter allows the user to tune the -function as least requested or most requested based on `utilization` and -`score` values. The `resources` parameter consists of `name` of the resource -to be considered during scoring and `weight` specify the weight of each -resource. +can be controlled by a configuration option called `RequestedToCapacityRatioArgs`. +This argument consists of two parameters `shape` and `resources`. The `shape` +parameter allows the user to tune the function as least requested or most +requested based on `utilization` and `score` values. The `resources` parameter +consists of `name` of the resource to be considered during scoring and `weight` +specify the weight of each resource. Below is an example configuration that sets `requestedToCapacityRatioArguments` to bin packing behavior for extended resources `intel.com/foo` and `intel.com/bar`. ```yaml -apiVersion: v1 -kind: Policy +apiVersion: kubescheduler.config.k8s.io/v1beta1 +kind: KubeSchedulerConfiguration +profiles: # ... -priorities: - # ... - - name: RequestedToCapacityRatioPriority - weight: 2 - argument: - requestedToCapacityRatioArguments: - shape: - - utilization: 0 - score: 0 - - utilization: 100 - score: 10 - resources: - - name: intel.com/foo - weight: 3 - - name: intel.com/bar - weight: 5 + pluginConfig: + - name: RequestedToCapacityRatio + args: + shape: + - utilization: 0 + score: 10 + - utilization: 100 + score: 0 + resources: + - name: intel.com/foo + weight: 3 + - name: intel.com/bar + weight: 5 ``` +Referencing the `KubeSchedulerConfiguration` file with the kube-scheduler +flag `--config=/path/to/config/file` will pass the configuration to the +scheduler. + **This feature is disabled by default** ### Tuning the Priority Function From a9fb2d35d0da6a522656d3c3b96c5228c77e5a81 Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Fri, 28 May 2021 22:16:18 +0900 Subject: [PATCH 055/128] [ko] Update outdated files in dev-1.21-ko.3 (p2) --- content/ko/community/_index.html | 3 +- .../concepts/cluster-administration/addons.md | 2 +- .../concepts/extend-kubernetes/operator.md | 2 ++ .../concepts/overview/what-is-kubernetes.md | 2 +- .../working-with-objects/common-labels.md | 14 ++++---- .../working-with-objects/namespaces.md | 2 +- .../concepts/scheduling-eviction/_index.md | 36 +++++++++++++++++-- .../scheduling-eviction/kube-scheduler.md | 1 - .../scheduling-eviction/pod-overhead.md | 2 +- .../pod-priority-preemption.md | 0 .../resource-bin-packing.md | 2 +- .../scheduler-perf-tuning.md | 2 +- .../concepts/storage/persistent-volumes.md | 4 +-- .../docs/concepts/storage/storage-classes.md | 34 ++++++++++++++++-- .../concepts/workloads/pods/disruptions.md | 4 ++- .../workloads/pods/init-containers.md | 1 - .../pods/pod-topology-spread-constraints.md | 2 +- .../feature-gates.md | 14 +++++--- .../docs/reference/glossary/pod-disruption.md | 19 ++++++++++ 19 files changed, 118 insertions(+), 28 deletions(-) rename content/ko/docs/concepts/{configuration => scheduling-eviction}/pod-priority-preemption.md (100%) create mode 100644 content/ko/docs/reference/glossary/pod-disruption.md diff --git a/content/ko/community/_index.html b/content/ko/community/_index.html index 40bea7b523..0fa8d8658a 100644 --- a/content/ko/community/_index.html +++ b/content/ko/community/_index.html @@ -24,7 +24,8 @@ cid: community 비디오      토론      이벤트와 모임들      -새소식 +새소식      +릴리즈

diff --git a/content/ko/docs/concepts/cluster-administration/addons.md b/content/ko/docs/concepts/cluster-administration/addons.md index 7e67dd604f..270063a737 100644 --- a/content/ko/docs/concepts/cluster-administration/addons.md +++ b/content/ko/docs/concepts/cluster-administration/addons.md @@ -23,7 +23,7 @@ content_type: concept * [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie)를 사용하면 쿠버네티스는 Calico, Canal, Flannel, Romana 또는 Weave와 같은 CNI 플러그인을 완벽하게 연결할 수 있다. * [Contiv](https://contiv.github.io)는 다양한 유스케이스와 풍부한 폴리시 프레임워크를 위해 구성 가능한 네트워킹(BGP를 사용하는 네이티브 L3, vxlan을 사용하는 오버레이, 클래식 L2 그리고 Cisco-SDN/ACI)을 제공한다. Contiv 프로젝트는 완전히 [오픈소스](https://github.com/contiv)이다. [인스톨러](https://github.com/contiv/install)는 kubeadm을 이용하거나, 그렇지 않은 경우에 대해서도 설치 옵션을 모두 제공한다. * [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/)은 [Tungsten Fabric](https://tungsten.io)을 기반으로 하며, 오픈소스이고, 멀티 클라우드 네트워크 가상화 및 폴리시 관리 플랫폼이다. Contrail과 Tungsten Fabric은 쿠버네티스, OpenShift, OpenStack 및 Mesos와 같은 오케스트레이션 시스템과 통합되어 있으며, 가상 머신, 컨테이너/파드 및 베어 메탈 워크로드에 대한 격리 모드를 제공한다. -* [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kubernetes.md)은 쿠버네티스와 함께 사용할 수 있는 오버레이 네트워크 제공자이다. +* [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually)은 쿠버네티스와 함께 사용할 수 있는 오버레이 네트워크 제공자이다. * [Knitter](https://github.com/ZTE/Knitter/)는 쿠버네티스 파드에서 여러 네트워크 인터페이스를 지원하는 플러그인이다. * [Multus](https://github.com/Intel-Corp/multus-cni)는 쿠버네티스에서 SRIOV, DPDK, OVS-DPDK 및 VPP 기반 워크로드 외에 모든 CNI 플러그인(예: Calico, Cilium, Contiv, Flannel)을 지원하기 위해 쿠버네티스에서 다중 네트워크 지원을 위한 멀티 플러그인이다. * [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/)는 Open vSwitch(OVS) 프로젝트에서 나온 가상 네트워킹 구현인 [OVN(Open Virtual Network)](https://github.com/ovn-org/ovn/)을 기반으로 하는 쿠버네티스용 네트워킹 제공자이다. OVN-Kubernetes는 OVS 기반 로드 밸런싱과 네트워크 폴리시 구현을 포함하여 쿠버네티스용 오버레이 기반 네트워킹 구현을 제공한다. diff --git a/content/ko/docs/concepts/extend-kubernetes/operator.md b/content/ko/docs/concepts/extend-kubernetes/operator.md index 21b3183b99..a0959f83dc 100644 --- a/content/ko/docs/concepts/extend-kubernetes/operator.md +++ b/content/ko/docs/concepts/extend-kubernetes/operator.md @@ -113,11 +113,13 @@ kubectl edit SampleDB/example-database # 일부 설정을 수동으로 변경하 {{% thirdparty-content %}} +* [Charmed Operator Framework](https://juju.is/) * [kubebuilder](https://book.kubebuilder.io/) 사용하기 * [KUDO](https://kudo.dev/) (Kubernetes Universal Declarative Operator) * 웹훅(WebHook)과 함께 [Metacontroller](https://metacontroller.app/)를 사용하여 직접 구현하기 * [오퍼레이터 프레임워크](https://operatorframework.io) +* [shell-operator](https://github.com/flant/shell-operator) ## {{% heading "whatsnext" %}} diff --git a/content/ko/docs/concepts/overview/what-is-kubernetes.md b/content/ko/docs/concepts/overview/what-is-kubernetes.md index 344c266d1e..5d2ef83d76 100644 --- a/content/ko/docs/concepts/overview/what-is-kubernetes.md +++ b/content/ko/docs/concepts/overview/what-is-kubernetes.md @@ -21,7 +21,7 @@ sitemap: 쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고, 확장가능한 오픈소스 플랫폼이다. 쿠버네티스는 선언적 구성과 자동화를 모두 용이하게 해준다. 쿠버네티스는 크고, 빠르게 성장하는 생태계를 가지고 있다. 쿠버네티스 서비스, 기술 지원 및 도구는 어디서나 쉽게 이용할 수 있다. -쿠버네티스란 명칭은 키잡이(helmsman)나 파일럿을 뜻하는 그리스어에서 유래했다. 구글이 2014년에 쿠버네티스 프로젝트를 오픈소스화했다. 쿠버네티스는 프로덕션 워크로드를 대규모로 운영하는 [15년 이상의 구글 경험](/blog/2015/04/borg-predecessor-to-kubernetes/)과 커뮤니티의 최고의 아이디어와 적용 사례가 결합되어 있다. +쿠버네티스란 명칭은 키잡이(helmsman)나 파일럿을 뜻하는 그리스어에서 유래했다. K8s라는 표기는 "K"와 "s"와 그 사이에 있는 8글자를 나타내는 약식 표기이다. 구글이 2014년에 쿠버네티스 프로젝트를 오픈소스화했다. 쿠버네티스는 프로덕션 워크로드를 대규모로 운영하는 [15년 이상의 구글 경험](/blog/2015/04/borg-predecessor-to-kubernetes/)과 커뮤니티의 최고의 아이디어와 적용 사례가 결합되어 있다. ## 여정 돌아보기 diff --git a/content/ko/docs/concepts/overview/working-with-objects/common-labels.md b/content/ko/docs/concepts/overview/working-with-objects/common-labels.md index 09f70af30c..c19ec0b3a9 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/common-labels.md +++ b/content/ko/docs/concepts/overview/working-with-objects/common-labels.md @@ -32,14 +32,15 @@ kubectl과 대시보드와 같은 많은 도구들로 쿠버네티스 오브젝 레이블을 최대한 활용하려면 모든 리소스 오브젝트에 적용해야 한다. -| Key | Description | Example | Type | +| 키 | 설명 | 예시 | 타입 | | ----------------------------------- | --------------------- | -------- | ---- | | `app.kubernetes.io/name` | 애플리케이션 이름 | `mysql` | 문자열 | | `app.kubernetes.io/instance` | 애플리케이션의 인스턴스를 식별하는 고유한 이름 | `mysql-abcxzy` | 문자열 | | `app.kubernetes.io/version` | 애플리케이션의 현재 버전 (예: a semantic version, revision hash 등.) | `5.7.21` | 문자열 | | `app.kubernetes.io/component` | 아키텍처 내 구성요소 | `database` | 문자열 | | `app.kubernetes.io/part-of` | 이 애플리케이션의 전체 이름 | `wordpress` | 문자열 | -| `app.kubernetes.io/managed-by` | 애플리케이션의 작동을 관리하는데 사용되는 도구 | `helm` | 문자열 | +| `app.kubernetes.io/managed-by` | 애플리케이션의 작동을 관리하는 데 사용되는 도구 | `helm` | 문자열 | +| `app.kubernetes.io/created-by` | 이 리소스를 만든 컨트롤러/사용자 | `controller-manager` | 문자열 | 위 레이블의 실제 예시는 다음 스테이트풀셋 오브젝트를 고려한다. @@ -54,6 +55,7 @@ metadata: app.kubernetes.io/component: database app.kubernetes.io/part-of: wordpress app.kubernetes.io/managed-by: helm + app.kubernetes.io/created-by: controller-manager ``` ## 애플리케이션과 애플리케이션 인스턴스 @@ -76,7 +78,7 @@ WordPress가 여러 번 설치되어 각각 서로 다른 웹사이트를 서비 `Deployment` 와 `Service` 오브젝트를 통해 배포된 단순한 스테이트리스 서비스의 경우를 보자. 다음 두 식별자는 레이블을 가장 간단한 형태로 사용하는 방법을 나타낸다. -`Deployment` 는 애플리케이션을 실행하는 파드를 감시하는데 사용한다. +`Deployment` 는 애플리케이션을 실행하는 파드를 감시하는 데 사용한다. ```yaml apiVersion: apps/v1 kind: Deployment @@ -102,9 +104,9 @@ metadata: Helm을 이용해서 데이터베이스(MySQL)을 이용하는 웹 애플리케이션(WordPress)을 설치한 것과 같이 좀 더 복잡한 애플리케이션을 고려할 수 있다. -다음 식별자는 이 애플리케이션을 배포하는데 사용하는 오브젝트의 시작을 보여준다. +다음 식별자는 이 애플리케이션을 배포하는 데 사용하는 오브젝트의 시작을 보여준다. -WordPress를 배포하는데 다음과 같이 `Deployment` 로 시작한다. +WordPress를 배포하는 데 다음과 같이 `Deployment` 로 시작한다. ```yaml apiVersion: apps/v1 @@ -152,7 +154,7 @@ metadata: ... ``` -`Service` 는 WordPress의 일부로 MySQL을 노출하는데 이용한다. +`Service` 는 WordPress의 일부로 MySQL을 노출하는 데 이용한다. ```yaml apiVersion: v1 diff --git a/content/ko/docs/concepts/overview/working-with-objects/namespaces.md b/content/ko/docs/concepts/overview/working-with-objects/namespaces.md index ef75f4f081..049b30a1f7 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/ko/docs/concepts/overview/working-with-objects/namespaces.md @@ -35,7 +35,7 @@ weight: 30 [네임스페이스 관리자 가이드 문서](/docs/tasks/administer-cluster/namespaces/)에 기술되어 있다. {{< note >}} - 쿠버네티스 시스템 네임스페이스용으로 예약되어 있으므로, `kube-` 접두사로 네임스페이스를 생성하지 않는다. + `kube-` 접두사로 시작하는 네임스페이스는 쿠버네티스 시스템용으로 예약되어 있으므로, 사용자는 이러한 네임스페이스를 생성하지 않는다. {{< /note >}} ### 네임스페이스 조회 diff --git a/content/ko/docs/concepts/scheduling-eviction/_index.md b/content/ko/docs/concepts/scheduling-eviction/_index.md index 5cd57c3a29..5ae3f5822e 100644 --- a/content/ko/docs/concepts/scheduling-eviction/_index.md +++ b/content/ko/docs/concepts/scheduling-eviction/_index.md @@ -1,7 +1,37 @@ --- -title: "스케줄링과 축출(eviction)" +title: "스케줄링, 선점(Preemption), 축출(Eviction)" weight: 90 +content_type: concept description: > - 쿠버네티스에서, 스케줄링은 kubelet이 파드를 실행할 수 있도록 파드가 노드와 일치하는지 확인하는 것을 말한다. - 축출은 리소스가 부족한 노드에서 하나 이상의 파드를 사전에 장애로 처리하는 프로세스이다. + 쿠버네티스에서, 스케줄링은 kubelet이 파드를 실행할 수 있도록 + 파드를 노드에 할당하는 것을 말한다. + 선점은 우선순위가 높은 파드가 노드에 스케줄될 수 있도록 + 우선순위가 낮은 파드를 종료시키는 과정을 말한다. + 축출은 리소스가 부족한 노드에서 하나 이상의 파드를 사전에 종료시키는 프로세스이다. +no_list: true --- + +쿠버네티스에서, 스케줄링은 {{}}이 파드를 실행할 수 있도록 +{{}}를 +{{}}에 할당하는 것을 말한다. +선점은 {{}}가 높은 파드가 노드에 스케줄될 수 있도록 +우선순위가 낮은 파드를 종료시키는 과정을 말한다. +축출은 리소스가 부족한 노드에서 하나 이상의 파드를 사전에 종료시키는 프로세스이다. + +## 스케줄링 + +* [쿠버네티스 스케줄러](/ko/docs/concepts/scheduling-eviction/kube-scheduler/) +* [노드에 파드 할당하기](/ko/docs/concepts/scheduling-eviction/assign-pod-node/) +* [파드 오버헤드](/ko/docs/concepts/scheduling-eviction/pod-overhead/) +* [테인트(Taints)와 톨러레이션(Tolerations)](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/) +* [스케줄링 프레임워크](/docs/concepts/scheduling-eviction/scheduling-framework/) +* [스케줄러 성능 튜닝](/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning/) +* [확장된 리소스를 위한 리소스 빈 패킹(bin packing)](/ko/docs/concepts/scheduling-eviction/resource-bin-packing/) + +## 파드 중단(disruption) + +{{}} + +* [파드 우선순위와 선점](/docs/concepts/scheduling-eviction/pod-priority-preemption/) +* [노드-압박 축출](/docs/concepts/scheduling-eviction/node-pressure-eviction/) +* [API를 이용한 축출](/docs/concepts/scheduling-eviction/api-eviction/) diff --git a/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md index 86e67978c2..8c17269a64 100644 --- a/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md +++ b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md @@ -80,7 +80,6 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순 1. [스케줄링 정책](/ko/docs/reference/scheduling/config/#프로파일)을 사용하면 필터링을 위한 _단정(Predicates)_ 및 스코어링을 위한 _우선순위(Priorities)_ 를 구성할 수 있다. 1. [스케줄링 프로파일](/ko/docs/reference/scheduling/config/#프로파일)을 사용하면 `QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit` 등의 다른 스케줄링 단계를 구현하는 플러그인을 구성할 수 있다. 다른 프로파일을 실행하도록 kube-scheduler를 구성할 수도 있다. - ## {{% heading "whatsnext" %}} * [스케줄러 성능 튜닝](/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)에 대해 읽기 diff --git a/content/ko/docs/concepts/scheduling-eviction/pod-overhead.md b/content/ko/docs/concepts/scheduling-eviction/pod-overhead.md index 0f474338d9..b0da80ceae 100644 --- a/content/ko/docs/concepts/scheduling-eviction/pod-overhead.md +++ b/content/ko/docs/concepts/scheduling-eviction/pod-overhead.md @@ -1,7 +1,7 @@ --- title: 파드 오버헤드 content_type: concept -weight: 20 +weight: 30 --- diff --git a/content/ko/docs/concepts/configuration/pod-priority-preemption.md b/content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md similarity index 100% rename from content/ko/docs/concepts/configuration/pod-priority-preemption.md rename to content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md diff --git a/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md b/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md index d11b7fe2ae..34ff6f3108 100644 --- a/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md +++ b/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md @@ -5,7 +5,7 @@ title: 확장된 리소스를 위한 리소스 빈 패킹(bin packing) content_type: concept -weight: 30 +weight: 80 --- diff --git a/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md b/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md index 9e049cd348..6be3e204c8 100644 --- a/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md +++ b/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md @@ -3,7 +3,7 @@ title: 스케줄러 성능 튜닝 content_type: concept -weight: 80 +weight: 100 --- diff --git a/content/ko/docs/concepts/storage/persistent-volumes.md b/content/ko/docs/concepts/storage/persistent-volumes.md index 3a85139cd2..c70b7413ad 100644 --- a/content/ko/docs/concepts/storage/persistent-volumes.md +++ b/content/ko/docs/concepts/storage/persistent-volumes.md @@ -540,11 +540,11 @@ spec: ### 접근 모드 -클레임은 특정 접근 모드로 저장소를 요청할 때 볼륨과 동일한 규칙을 사용한다. +클레임은 특정 접근 모드로 저장소를 요청할 때 [볼륨과 동일한 규칙](#접근-모드)을 사용한다. ### 볼륨 모드 -클레임은 볼륨과 동일한 규칙을 사용하여 파일시스템 또는 블록 장치로 볼륨을 사용함을 나타낸다. +클레임은 [볼륨과 동일한 규칙](#볼륨-모드)을 사용하여 파일시스템 또는 블록 장치로 볼륨을 사용함을 나타낸다. ### 리소스 diff --git a/content/ko/docs/concepts/storage/storage-classes.md b/content/ko/docs/concepts/storage/storage-classes.md index 94577ca182..0bec67ef8a 100644 --- a/content/ko/docs/concepts/storage/storage-classes.md +++ b/content/ko/docs/concepts/storage/storage-classes.md @@ -149,9 +149,9 @@ CSI | 1.14 (alpha), 1.16 (beta) ### 볼륨 바인딩 모드 `volumeBindingMode` 필드는 [볼륨 바인딩과 동적 -프로비저닝](/ko/docs/concepts/storage/persistent-volumes/#프로비저닝)의 시작 시기를 제어한다. +프로비저닝](/ko/docs/concepts/storage/persistent-volumes/#프로비저닝)의 시작 시기를 제어한다. 설정되어 있지 않으면, `Immediate` 모드가 기본으로 사용된다. -기본적으로, `Immediate` 모드는 퍼시스턴트볼륨클레임이 생성되면 볼륨 +`Immediate` 모드는 퍼시스턴트볼륨클레임이 생성되면 볼륨 바인딩과 동적 프로비저닝이 즉시 발생하는 것을 나타낸다. 토폴로지 제약이 있고 클러스터의 모든 노드에서 전역적으로 접근할 수 없는 스토리지 백엔드의 경우, 파드의 스케줄링 요구 사항에 대한 지식 없이 퍼시스턴트볼륨이 @@ -183,6 +183,36 @@ CSI | 1.14 (alpha), 1.16 (beta) 사전에 생성된 PV에서도 지원되지만, 지원되는 토폴로지 키와 예시를 보려면 해당 CSI 드라이버에 대한 문서를 본다. +{{< note >}} + `waitForFirstConsumer`를 사용한다면, 노드 어피니티를 지정하기 위해서 파드 스펙에 `nodeName`을 사용하지는 않아야 한다. + 만약 `nodeName`을 사용한다면, 스케줄러가 바이패스되고 PVC가 `pending` 상태로 있을 것이다. + + 대신, 아래와 같이 호스트네임을 이용하는 노드셀렉터를 사용할 수 있다. +{{< /note >}} + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: task-pv-pod +spec: + nodeSelector: + kubernetes.io/hostname: kube-01 + volumes: + - name: task-pv-storage + persistentVolumeClaim: + claimName: task-pv-claim + containers: + - name: task-pv-container + image: nginx + ports: + - containerPort: 80 + name: "http-server" + volumeMounts: + - mountPath: "/usr/share/nginx/html" + name: task-pv-storage +``` + ### 허용된 토폴로지 클러스터 운영자가 `WaitForFirstConsumer` 볼륨 바인딩 모드를 지정하면, 대부분의 상황에서 diff --git a/content/ko/docs/concepts/workloads/pods/disruptions.md b/content/ko/docs/concepts/workloads/pods/disruptions.md index 56244fae26..02730d4306 100644 --- a/content/ko/docs/concepts/workloads/pods/disruptions.md +++ b/content/ko/docs/concepts/workloads/pods/disruptions.md @@ -79,13 +79,15 @@ weight: 60 ([다중 영역 클러스터](/docs/setup/multiple-zones)를 이용한다면)에 애플리케이션을 분산해야 한다. -자발적 중단의 빈도는 다양하다. 기본적인 쿠버네티스 클러스터에서는 자발적인 운영 중단이 전혀 없다. +자발적 중단의 빈도는 다양하다. 기본적인 쿠버네티스 클러스터에서는 자동화된 자발적 중단은 발생하지 않는다(사용자가 지시한 자발적 중단만 발생한다). 그러나 클러스터 관리자 또는 호스팅 공급자가 자발적 중단이 발생할 수 있는 일부 부가 서비스를 운영할 수 있다. 예를 들어 노드 소프트웨어의 업데이트를 출시하는 경우 자발적 중단이 발생할 수 있다. 또한 클러스터(노드) 오토스케일링의 일부 구현에서는 단편화를 제거하고 노드의 효율을 높이는 과정에서 자발적 중단을 야기할 수 있다. 클러스터 관리자 또는 호스팅 공급자는 예측 가능한 자발적 중단 수준에 대해 문서화해야 한다. +파드 스펙 안에 [프라이어리티클래스 사용하기](/ko/docs/concepts/configuration/pod-priority-preemption/)와 같은 특정 환경설정 옵션 +또한 자발적(+ 비자발적) 중단을 유발할 수 있다. ## 파드 disruption budgets diff --git a/content/ko/docs/concepts/workloads/pods/init-containers.md b/content/ko/docs/concepts/workloads/pods/init-containers.md index b7a1241fc2..c8c7055408 100644 --- a/content/ko/docs/concepts/workloads/pods/init-containers.md +++ b/content/ko/docs/concepts/workloads/pods/init-containers.md @@ -326,6 +326,5 @@ myapp-pod 1/1 Running 0 9m ## {{% heading "whatsnext" %}} - * [초기화 컨테이너를 가진 파드 생성하기](/ko/docs/tasks/configure-pod-container/configure-pod-initialization/#초기화-컨테이너를-갖는-파드-생성) * [초기화 컨테이너 디버깅](/ko/docs/tasks/debug-application-cluster/debug-init-containers/) 알아보기 diff --git a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md index 9bb8cfba78..2601f5c871 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md +++ b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md @@ -13,7 +13,7 @@ obsolete --> 사용자는 _토폴로지 분배 제약 조건_ 을 사용해서 지역, 영역, 노드 그리고 기타 사용자-정의 토폴로지 도메인과 같이 장애-도메인으로 설정된 클러스터에 걸쳐 파드가 분산되는 방식을 제어할 수 있다. 이를 통해 고가용성뿐만 아니라, 효율적인 리소스 활용의 목적을 이루는 데 도움이 된다. {{< note >}} -v1.19 이전 버전의 쿠버네티스에서는 파드 토폴로지 분배 제약조건을 사용하려면 +v1.18 이전 버전의 쿠버네티스에서는 파드 토폴로지 분배 제약조건을 사용하려면 [API 서버](/ko/docs/concepts/overview/components/#kube-apiserver)와 [스케줄러](/docs/reference/generated/kube-scheduler/)에서 `EvenPodsSpread`[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 diff --git a/content/ko/docs/reference/command-line-tools-reference/feature-gates.md b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md index 6040ba514b..a658d58497 100644 --- a/content/ko/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md @@ -132,7 +132,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `IPv6DualStack` | `true` | 베타 | 1.21 | | | `KubeletCredentialProviders` | `false` | 알파 | 1.20 | | | `LegacyNodeRoleBehavior` | `false` | 알파 | 1.16 | 1.18 | -| `LegacyNodeRoleBehavior` | `true` | 베타 | 1.19 | | +| `LegacyNodeRoleBehavior` | `true` | 베타 | 1.19 | 1.20 | | `LocalStorageCapacityIsolation` | `false` | 알파 | 1.7 | 1.9 | | `LocalStorageCapacityIsolation` | `true` | 베타 | 1.10 | | | `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | 알파 | 1.15 | | @@ -142,7 +142,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `NamespaceDefaultLabelName` | `true` | 베타 | 1.21 | | | `NetworkPolicyEndPort` | `false` | 알파 | 1.21 | | | `NodeDisruptionExclusion` | `false` | 알파 | 1.16 | 1.18 | -| `NodeDisruptionExclusion` | `true` | 베타 | 1.19 | | +| `NodeDisruptionExclusion` | `true` | 베타 | 1.19 | 1.20 | | `NonPreemptingPriority` | `false` | 알파 | 1.15 | 1.18 | | `NonPreemptingPriority` | `true` | 베타 | 1.19 | | | `PodDeletionCost` | `false` | 알파 | 1.21 | | @@ -164,7 +164,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `ServiceLBNodePortControl` | `false` | 알파 | 1.20 | | | `ServiceLoadBalancerClass` | `false` | 알파 | 1.21 | | | `ServiceNodeExclusion` | `false` | 알파 | 1.8 | 1.18 | -| `ServiceNodeExclusion` | `true` | 베타 | 1.19 | | +| `ServiceNodeExclusion` | `true` | 베타 | 1.19 | 1.20 | | `ServiceTopology` | `false` | 알파 | 1.17 | | | `SetHostnameAsFQDN` | `false` | 알파 | 1.19 | 1.19 | | `SetHostnameAsFQDN` | `true` | 베타 | 1.20 | | @@ -173,7 +173,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `StorageVersionHash` | `false` | 알파 | 1.14 | 1.14 | | `StorageVersionHash` | `true` | 베타 | 1.15 | | | `SuspendJob` | `false` | 알파 | 1.21 | | -| `TTLAfterFinished` | `false` | 알파 | 1.12 | | +| `TTLAfterFinished` | `false` | 알파 | 1.12 | 1.20 | +| `TTLAfterFinished` | `true` | 베타 | 1.21 | | | `TopologyAwareHints` | `false` | 알파 | 1.21 | | | `TopologyManager` | `false` | 알파 | 1.16 | 1.17 | | `TopologyManager` | `true` | 베타 | 1.18 | | @@ -266,6 +267,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `EvenPodsSpread` | `true` | 베타 | 1.18 | 1.18 | | `EvenPodsSpread` | `true` | GA | 1.19 | - | | `ExecProbeTimeout` | `true` | GA | 1.20 | - | +| `ExternalPolicyForExternalIP` | `true` | GA | 1.18 | - | | `GCERegionalPersistentDisk` | `true` | 베타 | 1.10 | 1.12 | | `GCERegionalPersistentDisk` | `true` | GA | 1.13 | - | | `HugePages` | `false` | 알파 | 1.8 | 1.9 | @@ -286,11 +288,13 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `KubeletPodResources` | `false` | 알파 | 1.13 | 1.14 | | `KubeletPodResources` | `true` | 베타 | 1.15 | | | `KubeletPodResources` | `true` | GA | 1.20 | | +| `LegacyNodeRoleBehavior` | `false` | GA | 1.21 | - | | `MountContainers` | `false` | 알파 | 1.9 | 1.16 | | `MountContainers` | `false` | 사용중단 | 1.17 | - | | `MountPropagation` | `false` | 알파 | 1.8 | 1.9 | | `MountPropagation` | `true` | 베타 | 1.10 | 1.11 | | `MountPropagation` | `true` | GA | 1.12 | - | +| `NodeDisruptionExclusion` | `true` | GA | 1.21 | - | | `NodeLease` | `false` | 알파 | 1.12 | 1.13 | | `NodeLease` | `true` | 베타 | 1.14 | 1.16 | | `NodeLease` | `true` | GA | 1.17 | - | @@ -341,6 +345,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `ServiceLoadBalancerFinalizer` | `false` | 알파 | 1.15 | 1.15 | | `ServiceLoadBalancerFinalizer` | `true` | 베타 | 1.16 | 1.16 | | `ServiceLoadBalancerFinalizer` | `true` | GA | 1.17 | - | +| `ServiceNodeExclusion` | `true` | GA | 1.21 | - | | `StartupProbe` | `false` | 알파 | 1.16 | 1.17 | | `StartupProbe` | `true` | 베타 | 1.18 | 1.19 | | `StartupProbe` | `true` | GA | 1.20 | - | @@ -636,6 +641,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 권한이 있는 컨테이너 또는 특정 비-네임스페이스(non-namespaced) 기능(예: `MKNODE`, `SYS_MODULE` 등)을 사용하는 컨테이너를 위한 것이다. 도커 데몬에서 사용자 네임스페이스 재 매핑이 활성화된 경우에만 활성화해야 한다. +- `ExternalPolicyForExternalIP`: ExternalTrafficPolicy가 서비스(Service) ExternalIP에 적용되지 않는 버그를 수정한다. - `GCERegionalPersistentDisk`: GCE에서 지역 PD 기능을 활성화한다. - `GenericEphemeralVolume`: 일반 볼륨의 모든 기능을 지원하는 임시, 인라인 볼륨을 활성화한다(타사 스토리지 공급 업체, 스토리지 용량 추적, 스냅샷으로부터 복원 diff --git a/content/ko/docs/reference/glossary/pod-disruption.md b/content/ko/docs/reference/glossary/pod-disruption.md new file mode 100644 index 0000000000..93a473035c --- /dev/null +++ b/content/ko/docs/reference/glossary/pod-disruption.md @@ -0,0 +1,19 @@ +--- +id: pod-disruption +title: 파드 중단(Disruption) +full_link: /ko/docs/concepts/workloads/pods/disruptions/ +date: 2021-05-12 +short_description: > + 노드에 있는 파드가 자발적 또는 비자발적으로 종료되는 절차 + +aka: +related: + - pod + - container +tags: + - operation +--- + +[파드 중단](/ko/docs/concepts/workloads/pods/disruptions/)은 노드에 있는 파드가 자발적 또는 비자발적으로 종료되는 절차이다. + +자발적 중단은 애플리케이션 소유자 또는 클러스터 관리자가 의도적으로 시작한다. 비자발적 중단은 의도하지 않은 것이며, 노드의 리소스 부족과 같은 피할 수 없는 문제 또는 우발적인 삭제로 인해 트리거될 수 있다. From 7af03687a0f4afb9b95c69f2157ec157493ec2ce Mon Sep 17 00:00:00 2001 From: Brendan Burns Date: Sat, 29 May 2021 08:36:19 -0700 Subject: [PATCH 056/128] Delete logging-stackdriver.md --- .../logging-stackdriver.md | 371 ------------------ 1 file changed, 371 deletions(-) delete mode 100644 content/en/docs/tasks/debug-application-cluster/logging-stackdriver.md diff --git a/content/en/docs/tasks/debug-application-cluster/logging-stackdriver.md b/content/en/docs/tasks/debug-application-cluster/logging-stackdriver.md deleted file mode 100644 index 29ace662f6..0000000000 --- a/content/en/docs/tasks/debug-application-cluster/logging-stackdriver.md +++ /dev/null @@ -1,371 +0,0 @@ ---- -reviewers: -- piosz -- x13n -title: Logging Using Stackdriver -content_type: concept ---- - - - -Before reading this page, it's highly recommended to familiarize yourself -with the [overview of logging in Kubernetes](/docs/concepts/cluster-administration/logging). - -{{< note >}} -By default, Stackdriver logging collects only your container's standard output and -standard error streams. To collect any logs your application writes to a file (for example), -see the [sidecar approach](/docs/concepts/cluster-administration/logging#sidecar-container-with-a-logging-agent) -in the Kubernetes logging overview. -{{< /note >}} - - - - - - -## Deploying - -To ingest logs, you must deploy the Stackdriver Logging agent to each node in your cluster. -The agent is a configured `fluentd` instance, where the configuration is stored in a `ConfigMap` -and the instances are managed using a Kubernetes `DaemonSet`. The actual deployment of the -`ConfigMap` and `DaemonSet` for your cluster depends on your individual cluster setup. - -### Deploying to a new cluster - -#### Google Kubernetes Engine - -Stackdriver is the default logging solution for clusters deployed on Google Kubernetes Engine. -Stackdriver Logging is deployed to a new cluster by default unless you explicitly opt-out. - -#### Other platforms - -To deploy Stackdriver Logging on a *new* cluster that you're -creating using `kube-up.sh`, do the following: - -1. Set the `KUBE_LOGGING_DESTINATION` environment variable to `gcp`. -1. **If not running on GCE**, include the `beta.kubernetes.io/fluentd-ds-ready=true` -in the `KUBE_NODE_LABELS` variable. - -Once your cluster has started, each node should be running the Stackdriver Logging agent. -The `DaemonSet` and `ConfigMap` are configured as addons. If you're not using `kube-up.sh`, -consider starting a cluster without a pre-configured logging solution and then deploying -Stackdriver Logging agents to the running cluster. - -{{< warning >}} -The Stackdriver logging daemon has known issues on platforms other -than Google Kubernetes Engine. Proceed at your own risk. -{{< /warning >}} - -### Deploying to an existing cluster - -1. Apply a label on each node, if not already present. - - The Stackdriver Logging agent deployment uses node labels to determine to which nodes - it should be allocated. These labels were introduced to distinguish nodes with the - Kubernetes version 1.6 or higher. If the cluster was created with Stackdriver Logging - configured and node has version 1.5.X or lower, it will have fluentd as static pod. Node - cannot have more than one instance of fluentd, therefore only apply labels to the nodes - that don't have fluentd pod allocated already. You can ensure that your node is labelled - properly by running `kubectl describe` as follows: - - ``` - kubectl describe node $NODE_NAME - ``` - - The output should be similar to this: - - ``` - Name: NODE_NAME - Role: - Labels: beta.kubernetes.io/fluentd-ds-ready=true - ... - ``` - - Ensure that the output contains the label `beta.kubernetes.io/fluentd-ds-ready=true`. If it - is not present, you can add it using the `kubectl label` command as follows: - - ``` - kubectl label node $NODE_NAME beta.kubernetes.io/fluentd-ds-ready=true - ``` - - {{< note >}} - If a node fails and has to be recreated, you must re-apply the label to - the recreated node. To make this easier, you can use Kubelet's command-line parameter - for applying node labels in your node startup script. - {{< /note >}} - -1. Deploy a `ConfigMap` with the logging agent configuration by running the following command: - - ``` - kubectl apply -f https://k8s.io/examples/debug/fluentd-gcp-configmap.yaml - ``` - - The command creates the `ConfigMap` in the `default` namespace. You can download the file - manually and change it before creating the `ConfigMap` object. - -1. Deploy the logging agent `DaemonSet` by running the following command: - - ``` - kubectl apply -f https://k8s.io/examples/debug/fluentd-gcp-ds.yaml - ``` - - You can download and edit this file before using it as well. - -## Verifying your Logging Agent Deployment - -After Stackdriver `DaemonSet` is deployed, you can discover logging agent deployment status -by running the following command: - -```shell -kubectl get ds --all-namespaces -``` - -If you have 3 nodes in the cluster, the output should looks similar to this: - -``` -NAMESPACE NAME DESIRED CURRENT READY NODE-SELECTOR AGE -... -default fluentd-gcp-v2.0 3 3 3 beta.kubernetes.io/fluentd-ds-ready=true 5m -... -``` - -To understand how logging with Stackdriver works, consider the following -synthetic log generator pod specification [counter-pod.yaml](/examples/debug/counter-pod.yaml): - -{{< codenew file="debug/counter-pod.yaml" >}} - -This pod specification has one container that runs a bash script -that writes out the value of a counter and the datetime once per -second, and runs indefinitely. Let's create this pod in the default namespace. - -```shell -kubectl apply -f https://k8s.io/examples/debug/counter-pod.yaml -``` - -You can observe the running pod: - -```shell -kubectl get pods -``` -``` -NAME READY STATUS RESTARTS AGE -counter 1/1 Running 0 5m -``` - -For a short period of time you can observe the 'Pending' pod status, because the kubelet -has to download the container image first. When the pod status changes to `Running` -you can use the `kubectl logs` command to view the output of this counter pod. - -```shell -kubectl logs counter -``` -``` -0: Mon Jan 1 00:00:00 UTC 2001 -1: Mon Jan 1 00:00:01 UTC 2001 -2: Mon Jan 1 00:00:02 UTC 2001 -... -``` - -As described in the logging overview, this command fetches log entries -from the container log file. If the container is killed and then restarted by -Kubernetes, you can still access logs from the previous container. However, -if the pod is evicted from the node, log files are lost. Let's demonstrate this -by deleting the currently running counter container: - -```shell -kubectl delete pod counter -``` -``` -pod "counter" deleted -``` - -and then recreating it: - -```shell -kubectl create -f https://k8s.io/examples/debug/counter-pod.yaml -``` -``` -pod/counter created -``` - -After some time, you can access logs from the counter pod again: - -```shell -kubectl logs counter -``` -``` -0: Mon Jan 1 00:01:00 UTC 2001 -1: Mon Jan 1 00:01:01 UTC 2001 -2: Mon Jan 1 00:01:02 UTC 2001 -... -``` - -As expected, only recent log lines are present. However, for a real-world -application you will likely want to be able to access logs from all containers, -especially for the debug purposes. This is exactly when the previously enabled -Stackdriver Logging can help. - -## Viewing logs - -Stackdriver Logging agent attaches metadata to each log entry, for you to use later -in queries to select only the messages you're interested in: for example, -the messages from a particular pod. - -The most important pieces of metadata are the resource type and log name. -The resource type of a container log is `container`, which is named -`GKE Containers` in the UI (even if the Kubernetes cluster is not on Google Kubernetes Engine). -The log name is the name of the container, so that if you have a pod with -two containers, named `container_1` and `container_2` in the spec, their logs -will have log names `container_1` and `container_2` respectively. - -System components have resource type `compute`, which is named -`GCE VM Instance` in the interface. Log names for system components are fixed. -For a Google Kubernetes Engine node, every log entry from a system component has one of the following -log names: - -* docker -* kubelet -* kube-proxy - -You can learn more about viewing logs on [the dedicated Stackdriver page](https://cloud.google.com/logging/docs/view/logs_viewer). - -One of the possible ways to view logs is using the -[`gcloud logging`](https://cloud.google.com/logging/docs/api/gcloud-logging) -command line interface from the [Google Cloud SDK](https://cloud.google.com/sdk/). -It uses Stackdriver Logging [filtering syntax](https://cloud.google.com/logging/docs/view/advanced_filters) -to query specific logs. For example, you can run the following command: - -```none -gcloud beta logging read 'logName="projects/$YOUR_PROJECT_ID/logs/count"' --format json | jq '.[].textPayload' -``` -``` -... -"2: Mon Jan 1 00:01:02 UTC 2001\n" -"1: Mon Jan 1 00:01:01 UTC 2001\n" -"0: Mon Jan 1 00:01:00 UTC 2001\n" -... -"2: Mon Jan 1 00:00:02 UTC 2001\n" -"1: Mon Jan 1 00:00:01 UTC 2001\n" -"0: Mon Jan 1 00:00:00 UTC 2001\n" -``` - -As you can see, it outputs messages for the count container from both -the first and second runs, despite the fact that the kubelet already deleted -the logs for the first container. - -### Exporting logs - -You can export logs to [Google Cloud Storage](https://cloud.google.com/storage/) -or to [BigQuery](https://cloud.google.com/bigquery/) to run further -analysis. Stackdriver Logging offers the concept of sinks, where you can -specify the destination of log entries. More information is available on -the Stackdriver [Exporting Logs page](https://cloud.google.com/logging/docs/export/configure_export_v2). - -## Configuring Stackdriver Logging Agents - -Sometimes the default installation of Stackdriver Logging may not suit your needs, for example: - -* You may want to add more resources because default performance doesn't suit your needs. -* You may want to introduce additional parsing to extract more metadata from your log messages, -like severity or source code reference. -* You may want to send logs not only to Stackdriver or send it to Stackdriver only partially. - -In this case you need to be able to change the parameters of `DaemonSet` and `ConfigMap`. - -### Prerequisites - -If you're using GKE and Stackdriver Logging is enabled in your cluster, you -cannot change its configuration, because it's managed and supported by GKE. -However, you can disable the default integration and deploy your own. - -{{< note >}} -You will have to support and maintain a newly deployed configuration -yourself: update the image and configuration, adjust the resources and so on. -{{< /note >}} - -To disable the default logging integration, use the following command: - -``` -gcloud beta container clusters update --logging-service=none CLUSTER -``` - -You can find notes on how to then install Stackdriver Logging agents into -a running cluster in the [Deploying section](#deploying). - -### Changing `DaemonSet` parameters - -When you have the Stackdriver Logging `DaemonSet` in your cluster, you can modify the -`template` field in its spec. The DaemonSet controller manages the pods for you. -For example, assume you've installed the Stackdriver Logging as described above. Now you want to -change the memory limit to give fluentd more memory to safely process more logs. - -Get the spec of `DaemonSet` running in your cluster: - -```shell -kubectl get ds fluentd-gcp-v2.0 --namespace kube-system -o yaml > fluentd-gcp-ds.yaml -``` - -Then edit resource requirements in the spec file and update the `DaemonSet` object -in the apiserver using the following command: - -```shell -kubectl replace -f fluentd-gcp-ds.yaml -``` - -After some time, Stackdriver Logging agent pods will be restarted with the new configuration. - -### Changing fluentd parameters - -Fluentd configuration is stored in the `ConfigMap` object. It is effectively a set of configuration -files that are merged together. You can learn about fluentd configuration on the -[official site](https://docs.fluentd.org). - -Imagine you want to add a new parsing logic to the configuration, so that fluentd can understand -default Python logging format. An appropriate fluentd filter looks similar to this: - -``` - - type parser - format /^(?\w):(?\w):(?.*)/ - reserve_data true - suppress_parse_error_log true - key_name log - -``` - -Now you have to put it in the configuration and make Stackdriver Logging agents pick it up. -Get the current version of the Stackdriver Logging `ConfigMap` in your cluster -by running the following command: - -```shell -kubectl get cm fluentd-gcp-config --namespace kube-system -o yaml > fluentd-gcp-configmap.yaml -``` - -Then in the value of the key `containers.input.conf` insert a new filter right after -the `source` section. - -{{< note >}} -Order is important. -{{< /note >}} - -Updating `ConfigMap` in the apiserver is more complicated than updating `DaemonSet`. It's better -to consider `ConfigMap` to be immutable. Then, in order to update the configuration, you should -create `ConfigMap` with a new name and then change `DaemonSet` to point to it -using [guide above](#changing-daemonset-parameters). - -### Adding fluentd plugins - -Fluentd is written in Ruby and allows to extend its capabilities using -[plugins](https://www.fluentd.org/plugins). If you want to use a plugin, which is not included -in the default Stackdriver Logging container image, you have to build a custom image. Imagine -you want to add Kafka sink for messages from a particular container for additional processing. -You can re-use the default [container image sources](https://git.k8s.io/contrib/fluentd/fluentd-gcp-image) -with minor changes: - -* Change Makefile to point to your container repository, for example `PREFIX=gcr.io/`. -* Add your dependency to the Gemfile, for example `gem 'fluent-plugin-kafka'`. - -Then run `make build push` from this directory. After updating `DaemonSet` to pick up the -new image, you can use the plugin you installed in the fluentd configuration. - - From 70d80a89e650f18341cc48ff4c27b9f11db8935d Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Sat, 29 May 2021 22:17:09 +0900 Subject: [PATCH 057/128] [ko] Update outdated files in dev-1.21-ko.3 (p3) --- .../kube-proxy.md | 137 +++++++++++++++++- .../ko/docs/reference/kubectl/cheatsheet.md | 4 + .../ko/docs/reference/scheduling/policies.md | 14 -- .../setup/best-practices/cluster-large.md | 6 +- 4 files changed, 144 insertions(+), 17 deletions(-) diff --git a/content/ko/docs/reference/command-line-tools-reference/kube-proxy.md b/content/ko/docs/reference/command-line-tools-reference/kube-proxy.md index bd930180cd..eab89638db 100644 --- a/content/ko/docs/reference/command-line-tools-reference/kube-proxy.md +++ b/content/ko/docs/reference/command-line-tools-reference/kube-proxy.md @@ -42,6 +42,20 @@ kube-proxy [flags] + +--add-dir-header + + +

true로 되어 있으면, 로그 메시지의 헤더에 파일 디렉터리를 기재한다.

+ + + +--alsologtostderr + + +

로그를 파일뿐만 아니라 표준 에러(standard error)로도 출력한다.

+ + --azure-container-registry-config string @@ -63,6 +77,13 @@ kube-proxy [flags]

true인 경우 kube-proxy는 포트 바인딩 실패를 치명적인 것으로 간주하고 종료한다.

+ +--boot-id-file string     기본값: "/proc/sys/kernel/random/boot_id" + + +

boot-id를 위해 확인할 파일 목록(쉼표로 분리). 가장 먼저 발견되는 항목을 사용한다.

+ + --cleanup @@ -70,6 +91,20 @@ kube-proxy [flags]

true인 경우 iptables 및 ipvs 규칙을 제거하고 종료한다.

+ +--cloud-provider-gce-l7lb-src-cidrs cidrs     기본값: 130.211.0.0/22,35.191.0.0/16 + + +

GCE 방화벽에서, L7 로드밸런싱 트래픽 프록시와 헬스 체크를 위해 개방할 CIDR 목록

+ + + +--cloud-provider-gce-lb-src-cidrs cidrs     기본값: 130.211.0.0/22,209.85.152.0/22,209.85.204.0/22,35.191.0.0/16 + + +

GCE 방화벽에서, L4 로드밸런싱 트래픽 프록시와 헬스 체크를 위해 개방할 CIDR 목록

+ + --cluster-cidr string @@ -119,6 +154,20 @@ kube-proxy [flags]

설정된 TCP 연결에 대한 유휴시간 초과(값이 0이면 그대로 유지)

+ +--default-not-ready-toleration-seconds int     기본값: 300 + + +

notReady:NoExecute 상태에 대한 톨러레이션(toleration) 시간이 지정되지 않은 모든 파드에 기본값으로 지정될 톨러레이션 시간(단위: 초)

+ + + +--default-unreachable-toleration-seconds int     기본값: 300 + + +

unreachable:NoExecute 상태에 대한 톨러레이션 시간이 지정되지 않은 모든 파드에 기본값으로 지정될 톨러레이션 시간(단위: 초)

+ + --detect-local-mode LocalMode @@ -259,6 +308,34 @@ kube-proxy [flags]

인증 정보가 있는 kubeconfig 파일의 경로(마스터 위치는 마스터 플래그로 설정됨).

+ +--log-backtrace-at <'file:N' 형태의 문자열>     기본값: :0 + + +

로깅 과정에서 file:N 번째 라인에 도달하면 스택 트레이스를 출력한다.

+ + + +--log-dir string + + +

로그 파일이 저장될 디렉터리

+ + + +--log-file string + + +

사용할 로그 파일

+ + + +--log-file-max-size uint     기본값: 1800 + + +

로그 파일의 최대 크기(단위: MB). 0으로 설정하면 무제한이다.

+ + --log-flush-frequency duration     기본값: 5s @@ -266,6 +343,20 @@ kube-proxy [flags]

로그 플러시 사이의 최대 시간

+ +--logtostderr     기본값: true + + +

로그를 파일에 기록하지 않고 표준 에러로만 출력

+ + + +--machine-id-file string     기본값: "/etc/machine-id,/var/lib/dbus/machine-id" + + +

machine-id를 위해 확인할 파일 목록(쉼표로 분리). 가장 먼저 발견되는 항목을 사용한다.

+ + --masquerade-all @@ -294,6 +385,13 @@ kube-proxy [flags]

NodePort에 사용할 주소를 지정하는 값의 문자열 조각. 값은 유효한 IP 블록(예: 1.2.3.0/24, 1.2.3.4/32). 기본값인 빈 문자열 조각값은([]) 모든 로컬 주소를 사용하는 것을 의미한다.

+ +--one-output + + +

true이면, 해당 로그가 속하는 심각성 레벨에만 각 로그를 기록한다(원래는 하위 심각성 레벨에도 기록한다).

+ + --oom-score-adj int32     기본값: -999 @@ -326,7 +424,28 @@ kube-proxy [flags] --show-hidden-metrics-for-version string -

숨겨진 메트릭을 표시할 이전 버전.

+

숨겨진 메트릭을 표시할 이전 버전. 이전 마이너 버전만 인식하며, 다른 값은 허용하지 않는다. '1.16' 형태로 사용한다. 이 옵션의 존재 목적은, 다음 릴리스에서 추가적인 메트릭을 숨기는지에 대한 여부를 사용자가 알게 하여, 그 이후 릴리스에서 메트릭이 영구적으로 삭제됐을 때 사용자가 놀라지 않도록 하기 위함이다.

+ + + +--skip-headers + + +

true이면, 로그 메시지에서 헤더 접두사를 붙이지 않는다.

+ + + +--skip-log-headers + + +

true이면, 로그 파일을 열 때 헤더를 붙이지 않는다.

+ + + +--stderrthreshold int     기본값: 2 + + +

이 값 이상의 로그는 표준 에러(stderr)로 출력되도록 한다.

@@ -336,11 +455,25 @@ kube-proxy [flags]

유휴 UDP 연결이 열린 상태로 유지되는 시간(예: '250ms', '2s'). 값은 0보다 커야 한다. 프록시 모드 userspace에만 적용 가능함.

+ +-v, --v int + + +

로그 상세 레벨(verbosity)

+ + --version version[=true] -

버전 정보를 인쇄하고 종료.

+

버전 정보를 출력하고 종료

+ + + +--vmodule <쉼표로 구분된 'pattern=N' 설정> + + +

파일-필터된 로깅을 위한 'pattern=N' 설정들(쉼표로 구분됨)

diff --git a/content/ko/docs/reference/kubectl/cheatsheet.md b/content/ko/docs/reference/kubectl/cheatsheet.md index 4ee9c5406e..71fc5a5f27 100644 --- a/content/ko/docs/reference/kubectl/cheatsheet.md +++ b/content/ko/docs/reference/kubectl/cheatsheet.md @@ -212,6 +212,10 @@ kubectl get nodes -o json | jq -c 'path(..)|[.[]|tostring]|join(".")' # 파드 등에 대해 반환된 모든 키의 마침표로 구분된 트리를 생성한다. kubectl get pods -o json | jq -c 'path(..)|[.[]|tostring]|join(".")' + +# 모든 파드에 대해 ENV를 생성한다(각 파드에 기본 컨테이너가 있고, 기본 네임스페이스가 있고, `env` 명령어가 동작한다고 가정). +# `env` 뿐만 아니라 다른 지원되는 명령어를 모든 파드에 실행할 때에도 참고할 수 있다. +for pod in $(kubectl get po --output=jsonpath={.items..metadata.name}); do echo $pod && kubectl exec -it $pod env; done ``` ## 리소스 업데이트 diff --git a/content/ko/docs/reference/scheduling/policies.md b/content/ko/docs/reference/scheduling/policies.md index 626e077784..c2b9cbbdff 100644 --- a/content/ko/docs/reference/scheduling/policies.md +++ b/content/ko/docs/reference/scheduling/policies.md @@ -37,20 +37,6 @@ weight: 10 - `MaxCSIVolumeCount`: 연결해야 하는 {{< glossary_tooltip text="CSI" term_id="csi" >}} 볼륨의 수와 구성된 제한을 초과하는지 여부를 결정한다. -- `CheckNodeMemoryPressure`: 노드가 메모리 압박을 보고하고 있고, 구성된 - 예외가 없는 경우, 파드가 해당 노드에 스케줄되지 않는다. - -- `CheckNodePIDPressure`: 노드가 프로세스 ID 부족을 보고하고 있고, 구성된 - 예외가 없는 경우, 파드가 해당 노드에 스케줄되지 않는다. - -- `CheckNodeDiskPressure`: 노드가 스토리지 압박(파일시스템이 가득차거나 - 거의 꽉 참)을 보고하고 있고, 구성된 예외가 없는 경우, 파드가 해당 노드에 스케줄되지 않는다. - -- `CheckNodeCondition`: 노드는 파일시스템이 완전히 가득찼거나, - 네트워킹을 사용할 수 없거나, kubelet이 파드를 실행할 준비가 되지 않았다고 보고할 수 있다. - 노드에 대해 이러한 조건이 설정되고, 구성된 예외가 없는 경우, 파드가 - 해당 노드에 스케줄되지 않는다. - - `PodToleratesNodeTaints`: 파드의 {{< glossary_tooltip text="톨러레이션" term_id="toleration" >}}이 노드의 {{< glossary_tooltip text="테인트" term_id="taint" >}}를 용인할 수 있는지 확인한다. diff --git a/content/ko/docs/setup/best-practices/cluster-large.md b/content/ko/docs/setup/best-practices/cluster-large.md index d67892e6dc..d0293e72f6 100644 --- a/content/ko/docs/setup/best-practices/cluster-large.md +++ b/content/ko/docs/setup/best-practices/cluster-large.md @@ -60,9 +60,13 @@ _A_ 영역에 있는 컨트롤 플레인 호스트로만 전달한다. 단일 클러스터 생성시의 부가 스트립트이다. 클러스터 생성 시에 (사용자 도구를 사용하여) 다음을 수행할 수 있다. -* 추가 ectd 인스턴스 시작 및 설정 +* 추가 etcd 인스턴스 시작 및 설정 * 이벤트를 저장하기 위한 {{< glossary_tooltip term_id="kube-apiserver" text="API server" >}} 설정 +[쿠버네티스를 위한 etcd 클러스터 운영하기](/docs/tasks/administer-cluster/configure-upgrade-etcd/)와 +[kubeadm을 이용하여 고가용성 etcd 생성하기](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)에서 +큰 클러스터를 위한 etcd를 설정하고 관리하는 방법에 대한 상세 사항을 확인한다. + ## 애드온 리소스 쿠버네티스 [리소스 제한](/ko/docs/concepts/configuration/manage-resources-containers/)은 From 1a3e0e3c139c03354ce049785ad5d540006049da Mon Sep 17 00:00:00 2001 From: seokho-son Date: Sun, 30 May 2021 19:22:07 +0900 Subject: [PATCH 058/128] Restruct release directory and docs for Korean --- content/ko/docs/setup/release/_index.md | 5 - content/ko/docs/setup/release/notes.md | 1626 ----------------- content/ko/releases/_index.md | 27 + content/ko/releases/notes.md | 13 + .../version-skew-policy.md | 4 +- 5 files changed, 42 insertions(+), 1633 deletions(-) delete mode 100755 content/ko/docs/setup/release/_index.md delete mode 100644 content/ko/docs/setup/release/notes.md create mode 100644 content/ko/releases/_index.md create mode 100644 content/ko/releases/notes.md rename content/ko/{docs/setup/release => releases}/version-skew-policy.md (97%) diff --git a/content/ko/docs/setup/release/_index.md b/content/ko/docs/setup/release/_index.md deleted file mode 100755 index fcef7a59ab..0000000000 --- a/content/ko/docs/setup/release/_index.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -title: "릴리스 노트와 버전 차이 지원(skew)" -weight: 10 ---- - diff --git a/content/ko/docs/setup/release/notes.md b/content/ko/docs/setup/release/notes.md deleted file mode 100644 index ada4903931..0000000000 --- a/content/ko/docs/setup/release/notes.md +++ /dev/null @@ -1,1626 +0,0 @@ ---- -title: v1.21 릴리스 노트 -weight: 10 -card: - name: release-notes - weight: 20 - anchors: - - anchor: "#" - title: 현재 릴리스 노트 - - anchor: "#긴급-업그레이드-노트" - title: 긴급 업그레이드 노트 ---- - - - -# v1.21.0 - -[문서](https://docs.k8s.io) - -## v1.21.0 다운로드 - -### 소스 코드 - -파일명 | sha512 해시 --------- | ----------- -[kubernetes.tar.gz](https://dl.k8s.io/v1.21.0/kubernetes.tar.gz) | `19bb76a3fa5ce4b9f043b2a3a77c32365ab1fcb902d8dd6678427fb8be8f49f64a5a03dc46aaef9c7dadee05501cf83412eda46f0edacbb8fc1ed0bf5fb79142` -[kubernetes-src.tar.gz](https://dl.k8s.io/v1.21.0/kubernetes-src.tar.gz) | `f942e6d6c10007a6e9ce21e94df597015ae646a7bc3e515caf1a3b79f1354efb9aff59c40f2553a8e3d43fe4a01742241f5af18b69666244906ed11a22e3bc49` - -### 클라이언트 바이너리 - -파일명 | sha512 해시 --------- | ----------- -[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.21.0/kubernetes-client-darwin-amd64.tar.gz) | `be9d1440e418e5253fb8a3d8aba705ca8160746a9bd17325ad626a986b6da9f733af864155a651a32b7bca94b533b8d596005ddbe5248bdeea85db47a1b957ed` -[kubernetes-client-darwin-arm64.tar.gz](https://dl.k8s.io/v1.21.0/kubernetes-client-darwin-arm64.tar.gz) | `eed0ddc81d104bb2d41ace13f737c490423d5df4ebddc7376e45c18ed66af35933c9376b912c1c3da105945b04056f6ca0870c156bee8a307cf4189ca5eb1dd1` -[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.21.0/kubernetes-client-linux-386.tar.gz) | `8a2f30c4434199762f2a96141dab4241c1cce2711bea9ea39cc63c2c5e7d31719ed7f076efac1931604e3a94578d3bbf0cfa454965708c96f3cfb91789868746` -[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.21.0/kubernetes-client-linux-amd64.tar.gz) | `cd3cfa645fa31de3716f1f63506e31b73d2aa8d37bb558bb3b3e8c151f35b3d74d44e03cbd05be67e380f9a5d015aba460222afdac6677815cd99a85c2325cf0` -[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.21.0/kubernetes-client-linux-arm.tar.gz) | `936042aa11cea0f6dfd2c30fc5dbe655420b34799bede036b1299a92d6831f589ca10290b73b9c9741560b603ae31e450ad024e273f2b4df5354bfac272691d8` -[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.21.0/kubernetes-client-linux-arm64.tar.gz) | `42beb75364d7bf4bf526804b8a35bd0ab3e124b712e9d1f45c1b914e6be0166619b30695feb24b3eecef134991dacb9ab3597e788bd9e45cf35addddf20dd7f6` -[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.21.0/kubernetes-client-linux-ppc64le.tar.gz) | `4baba2ed7046b28370eccc22e2378ae79e3ce58220d6f4f1b6791e8233bec8379e30200bb20b971456b83f2b791ea166fdfcf1ea56908bc1eea03590c0eda468` -[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.21.0/kubernetes-client-linux-s390x.tar.gz) | `37fa0c4d703aef09ce68c10ef3e7362b0313c8f251ce38eea579cd18fae4023d3d2b70e0f31577cabe6958ab9cfc30e98d25a7c64e69048b423057c3cf728339` -[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.21.0/kubernetes-client-windows-386.tar.gz) | `6900db36c1e3340edfd6dfd8d720575a904c932d39a8a7fa36401595e971a0235bd42111dbcc1cbb77e7374e47f1380a68c637997c18f96a0d9cdc9f3714c4c9` -[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.21.0/kubernetes-client-windows-amd64.tar.gz) | `90de67f6f79fc63bcfdf35066e3d84501cc85433265ffad36fd1a7a428a31b446249f0644a1e97495ea8b2a08e6944df6ef30363003750339edaa2aceffe937c` - -### 서버 바이너리 - -파일명 | sha512 해시 --------- | ----------- -[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.21.0/kubernetes-server-linux-amd64.tar.gz) | `3941dcc2309ac19ec185603a79f5a086d8a198f98c04efa23f15a177e5e1f34946ea9392ba9f5d24d0d727839438f067fef1001fc6e88b27b8b01e35bbd962ca` -[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.21.0/kubernetes-server-linux-arm.tar.gz) | `6507abf6c2ec2b336901dc23269f6c577ec0049b8bad3c9dd6ad63f21aa10f09bfbbfa6e064c2466d250411d3e10f8672791a9e10942e38de7bfbaf7a8bcc9da` -[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.21.0/kubernetes-server-linux-arm64.tar.gz) | `5abe76f867ca6865344e957bf166b81766c049ec4eb183a8a5580c22a7f8474db1edf90fd901a5833e56128b6825811653a1d27f72fd34ce5b1287a8c10da05c` -[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.21.0/kubernetes-server-linux-ppc64le.tar.gz) | `62507b182ca25396a285d91241536860e58f54fac937e97cbdf91948c83bb41be97d33277400489bf50e85164d560205540b76e94e5d519892312bdc63df1067` -[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.21.0/kubernetes-server-linux-s390x.tar.gz) | `04f2a1f7d1388e4a7d7d9f597f872a3da36f26839cfed16aad6df07021c03f4dca1df06b19cfda56df09d1c2d9a13ebd0af40ca1b9b6aecfaf427ab7712d88f3` - -### 노드 바이너리 - -파일명 | sha512 해시 --------- | ----------- -[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.21.0/kubernetes-node-linux-amd64.tar.gz) | `c1831c708109c31b3878e5a9327ea4b9e546504d0b6b00f3d43db78b5dd7d5114d32ac24a9a505f9cadbe61521f0419933348d2cd309ed8cfe3987d9ca8a7e2c` -[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.21.0/kubernetes-node-linux-arm.tar.gz) | `b68dd5bcfc7f9ce2781952df40c8c3a64c29701beff6ac22f042d6f31d4de220e9200b7e8272ddf608114327770acdaf3cb9a34a0a5206e784bda717ea080e0f` -[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.21.0/kubernetes-node-linux-arm64.tar.gz) | `7fa84fc500c28774ed25ca34b6f7b208a2bea29d6e8379f84b9f57bd024aa8fe574418cee7ee26edd55310716d43d65ae7b9cbe11e40c995fe2eac7f66bdb423` -[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.21.0/kubernetes-node-linux-ppc64le.tar.gz) | `a4278b3f8e458e9581e01f0c5ba8443303c987988ee136075a8f2f25515d70ca549fbd2e4d10eefca816c75c381d62d71494bd70c47034ab47f8315bbef4ae37` -[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.21.0/kubernetes-node-linux-s390x.tar.gz) | `8de2bc6f22f232ff534b45012986eac23893581ccb6c45bd637e40dbe808ce31d5a92375c00dc578bdbadec342b6e5b70c1b9f3d3a7bb26ccfde97d71f9bf84a` -[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.21.0/kubernetes-node-windows-amd64.tar.gz) | `b82e94663d330cff7a117f99a7544f27d0bc92b36b5a283b3c23725d5b33e6f15e0ebf784627638f22f2d58c58c0c2b618ddfd226a64ae779693a0861475d355` - -## v1.20.0 이후 변경로그 (Changelog) - -## 새로운 소식 (주요 테마) - -### Deprecation of PodSecurityPolicy - -PSP as an admission controller resource is being deprecated. Deployed PodSecurityPolicy's will keep working until version 1.25, their target removal from the codebase. A new feature, with a working title of "PSP replacement policy", is being developed in [KEP-2579](https://features.k8s.io/2579). To learn more, read [PodSecurityPolicy Deprecation: Past, Present, and Future](https://blog.k8s.io/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/). - -### Kubernetes API Reference Documentation - -The API reference is now generated with [`gen-resourcesdocs`](https://github.com/kubernetes-sigs/reference-docs/tree/c96658d89fb21037b7d00d27e6dbbe6b32375837/gen-resourcesdocs) and it is moving to [Kubernetes API](https://docs.k8s.io/reference/kubernetes-api/) - -### Kustomize Updates in Kubectl - -[Kustomize](https://github.com/kubernetes-sigs/kustomize) version in kubectl had a jump from v2.0.3 to [v4.0.5](https://github.com/kubernetes/kubernetes/pull/98946). Kustomize is now treated as a library and future updates will be less sporadic. - -### Default Container Labels - -Pod with multiple containers can use `kubectl.kubernetes.io/default-container` label to have a container preselected for kubectl commands. More can be read in [KEP-2227](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cli/2227-kubectl-default-container/README.md). - -### Immutable Secrets and ConfigMaps - -Immutable Secrets and ConfigMaps graduates to GA. This feature allows users to specify that the contents of a particular Secret or ConfigMap is immutable for its object lifetime. For such instances, Kubelet will not watch/poll for changes and therefore reducing apiserver load. - -### Structured Logging in Kubelet - -Kubelet has adopted structured logging, thanks to community effort in accomplishing this within the release timeline. Structured logging in the project remains an ongoing effort -- for folks interested in participating, [keep an eye / chime in to the mailing list discussion](https://groups.google.com/g/kubernetes-dev/c/y4WIw-ntUR8). - -### Storage Capacity Tracking - -Traditionally, the Kubernetes scheduler was based on the assumptions that additional persistent storage is available everywhere in the cluster and has infinite capacity. Topology constraints addressed the first point, but up to now pod scheduling was still done without considering that the remaining storage capacity may not be enough to start a new pod. [Storage capacity tracking](https://docs.k8s.io/concepts/storage/storage-capacity/) addresses that by adding an API for a CSI driver to report storage capacity and uses that information in the Kubernetes scheduler when choosing a node for a pod. This feature serves as a stepping stone for supporting dynamic provisioning for local volumes and other volume types that are more capacity constrained. - -### Generic Ephemeral Volumes - -[Generic ephermeral volumes](https://docs.k8s.io/concepts/storage/ephemeral-volumes/#generic-ephemeral-volumes) feature allows any existing storage driver that supports dynamic provisioning to be used as an ephemeral volume with the volume’s lifecycle bound to the Pod. It can be used to provide scratch storage that is different from the root disk, for example persistent memory, or a separate local disk on that node. All StorageClass parameters for volume provisioning are supported. All features supported with PersistentVolumeClaims are supported, such as storage capacity tracking, snapshots and restore, and volume resizing. - -### CSI Service Account Token - -CSI Service Account Token feature moves to Beta in 1.21. This feature improves the security posture and allows CSI drivers to receive pods' [bound service account tokens](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md). This feature also provides a knob to re-publish volumes so that short-lived volumes can be refreshed. - -### CSI Health Monitoring - -The CSI health monitoring feature is being released as a second Alpha in Kubernetes 1.21. This feature enables CSI Drivers to share abnormal volume conditions from the underlying storage systems with Kubernetes so that they can be reported as events on PVCs or Pods. This feature serves as a stepping stone towards programmatic detection and resolution of individual volume health issues by Kubernetes. - -## 알려진 이슈 - -### `TopologyAwareHints` feature falls back to default behavior - -The feature gate currently falls back to the default behavior in most cases. Enabling the feature gate will add hints to `EndpointSlices`, but functional differences are only observed in non-dual stack kube-proxy implementation. [The fix will be available in coming releases](https://github.com/kubernetes/kubernetes/pull/100804). - -## 긴급 업그레이드 노트 - -### (주의. 업그레이드 전에 반드시 읽어야 함) - -- Kube-proxy's IPVS proxy mode no longer sets the net.ipv4.conf.all.route_localnet sysctl parameter. Nodes upgrading will have net.ipv4.conf.all.route_localnet set to 1 but new nodes will inherit the system default (usually 0). If you relied on any behavior requiring net.ipv4.conf.all.route_localnet, you must set ensure it is enabled as kube-proxy will no longer set it automatically. This change helps to further mitigate CVE-2020-8558. ([#92938](https://github.com/kubernetes/kubernetes/pull/92938), [@lbernail](https://github.com/lbernail)) [SIG Network and Release] - - Kubeadm: during "init" an empty cgroupDriver value in the KubeletConfiguration is now always set to "systemd" unless the user is explicit about it. This requires existing machine setups to configure the container runtime to use the "systemd" driver. Documentation on this topic can be found here: https://kubernetes.io/docs/setup/production-environment/container-runtimes/. When upgrading existing clusters / nodes using "kubeadm upgrade" the old cgroupDriver value is preserved, but in 1.22 this change will also apply to "upgrade". For more information on migrating to the "systemd" driver or remaining on the "cgroupfs" driver see: https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/. ([#99471](https://github.com/kubernetes/kubernetes/pull/99471), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] - - Newly provisioned PVs by EBS plugin will no longer use the deprecated "failure-domain.beta.kubernetes.io/zone" and "failure-domain.beta.kubernetes.io/region" labels. It will use "topology.kubernetes.io/zone" and "topology.kubernetes.io/region" labels instead. ([#99130](https://github.com/kubernetes/kubernetes/pull/99130), [@ayberk](https://github.com/ayberk)) [SIG Cloud Provider, Storage and Testing] - - Newly provisioned PVs by OpenStack Cinder plugin will no longer use the deprecated "failure-domain.beta.kubernetes.io/zone" and "failure-domain.beta.kubernetes.io/region" labels. It will use "topology.kubernetes.io/zone" and "topology.kubernetes.io/region" labels instead. ([#99719](https://github.com/kubernetes/kubernetes/pull/99719), [@jsafrane](https://github.com/jsafrane)) [SIG Cloud Provider and Storage] - - Newly provisioned PVs by gce-pd will no longer have the beta FailureDomain label. gce-pd volume plugin will start to have GA topology label instead. ([#98700](https://github.com/kubernetes/kubernetes/pull/98700), [@Jiawei0227](https://github.com/Jiawei0227)) [SIG Cloud Provider, Storage and Testing] - - OpenStack Cinder CSI migration is on by default, Clinder CSI driver must be installed on clusters on OpenStack for Cinder volumes to work. ([#98538](https://github.com/kubernetes/kubernetes/pull/98538), [@dims](https://github.com/dims)) [SIG Storage] - - Remove alpha `CSIMigrationXXComplete` flag and add alpha `InTreePluginXXUnregister` flag. Deprecate `CSIMigrationvSphereComplete` flag and it will be removed in v1.22. ([#98243](https://github.com/kubernetes/kubernetes/pull/98243), [@Jiawei0227](https://github.com/Jiawei0227)) - - Remove storage metrics `storage_operation_errors_total`, since we already have `storage_operation_status_count`.And add new field `status` for `storage_operation_duration_seconds`, so that we can know about all status storage operation latency. ([#98332](https://github.com/kubernetes/kubernetes/pull/98332), [@JornShen](https://github.com/JornShen)) [SIG Instrumentation and Storage] - - The metric `storage_operation_errors_total` is not removed, but is marked deprecated, and the metric `storage_operation_status_count` is marked deprecated. In both cases the `storage_operation_duration_seconds` metric can be used to recover equivalent counts (using `status=fail-unknown` in the case of `storage_operations_errors_total`). ([#99045](https://github.com/kubernetes/kubernetes/pull/99045), [@mattcary](https://github.com/mattcary)) - - `ServiceNodeExclusion`, `NodeDisruptionExclusion` and `LegacyNodeRoleBehavior` features have been promoted to GA. `ServiceNodeExclusion` and `NodeDisruptionExclusion` are now unconditionally enabled, while `LegacyNodeRoleBehavior` is unconditionally disabled. To prevent control plane nodes from being added to load balancers automatically, upgrade users need to add "node.kubernetes.io/exclude-from-external-load-balancers" label to control plane nodes. ([#97543](https://github.com/kubernetes/kubernetes/pull/97543), [@pacoxu](https://github.com/pacoxu)) - -## 종류(Kind)별 변경 사항 - -### 사용 중단 - -- Aborting the drain command in a list of nodes will be deprecated. The new behavior will make the drain command go through all nodes even if one or more nodes failed during the drain. For now, users can try such experience by enabling --ignore-errors flag. ([#98203](https://github.com/kubernetes/kubernetes/pull/98203), [@yuzhiquan](https://github.com/yuzhiquan)) -- Delete deprecated `service.beta.kubernetes.io/azure-load-balancer-mixed-protocols` mixed procotol annotation in favor of the MixedProtocolLBService feature ([#97096](https://github.com/kubernetes/kubernetes/pull/97096), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider] -- Deprecate the `topologyKeys` field in Service. This capability will be replaced with upcoming work around Topology Aware Subsetting and Service Internal Traffic Policy. ([#96736](https://github.com/kubernetes/kubernetes/pull/96736), [@andrewsykim](https://github.com/andrewsykim)) [SIG Apps] -- Kube-proxy: remove deprecated --cleanup-ipvs flag of kube-proxy, and make --cleanup flag always to flush IPVS ([#97336](https://github.com/kubernetes/kubernetes/pull/97336), [@maaoBit](https://github.com/maaoBit)) [SIG Network] -- Kubeadm: deprecated command "alpha selfhosting pivot" is now removed. ([#97627](https://github.com/kubernetes/kubernetes/pull/97627), [@knight42](https://github.com/knight42)) -- Kubeadm: graduate the command `kubeadm alpha kubeconfig user` to `kubeadm kubeconfig user`. The `kubeadm alpha kubeconfig user` command is deprecated now. ([#97583](https://github.com/kubernetes/kubernetes/pull/97583), [@knight42](https://github.com/knight42)) [SIG Cluster Lifecycle] -- Kubeadm: the "kubeadm alpha certs" command is removed now, please use "kubeadm certs" instead. ([#97706](https://github.com/kubernetes/kubernetes/pull/97706), [@knight42](https://github.com/knight42)) [SIG Cluster Lifecycle] -- Kubeadm: the deprecated kube-dns is no longer supported as an option. If "ClusterConfiguration.dns.type" is set to "kube-dns" kubeadm will now throw an error. ([#99646](https://github.com/kubernetes/kubernetes/pull/99646), [@rajansandeep](https://github.com/rajansandeep)) [SIG Cluster Lifecycle] -- Kubectl: The deprecated `kubectl alpha debug` command is removed. Use `kubectl debug` instead. ([#98111](https://github.com/kubernetes/kubernetes/pull/98111), [@pandaamanda](https://github.com/pandaamanda)) [SIG CLI] -- Official support to build kubernetes with docker-machine / remote docker is removed. This change does not affect building kubernetes with docker locally. ([#97935](https://github.com/kubernetes/kubernetes/pull/97935), [@adeniyistephen](https://github.com/adeniyistephen)) [SIG Release and Testing] -- Remove deprecated `--generator, --replicas, --service-generator, --service-overrides, --schedule` from `kubectl run` - Deprecate `--serviceaccount, --hostport, --requests, --limits` in `kubectl run` ([#99732](https://github.com/kubernetes/kubernetes/pull/99732), [@soltysh](https://github.com/soltysh)) -- Remove the deprecated metrics "scheduling_algorithm_preemption_evaluation_seconds" and "binding_duration_seconds", suggest to use "scheduler_framework_extension_point_duration_seconds" instead. ([#96447](https://github.com/kubernetes/kubernetes/pull/96447), [@chendave](https://github.com/chendave)) [SIG Cluster Lifecycle, Instrumentation, Scheduling and Testing] -- Removing experimental windows container hyper-v support with Docker ([#97141](https://github.com/kubernetes/kubernetes/pull/97141), [@wawa0210](https://github.com/wawa0210)) [SIG Node and Windows] -- Rename metrics `etcd_object_counts` to `apiserver_storage_object_counts` and mark it as stable. The original `etcd_object_counts` metrics name is marked as "Deprecated" and will be removed in the future. ([#99785](https://github.com/kubernetes/kubernetes/pull/99785), [@erain](https://github.com/erain)) [SIG API Machinery, Instrumentation and Testing] -- The GA TokenRequest and TokenRequestProjection feature gates have been removed and are unconditionally enabled. Remove explicit use of those feature gates in CLI invocations. ([#97148](https://github.com/kubernetes/kubernetes/pull/97148), [@wawa0210](https://github.com/wawa0210)) [SIG Node] -- The PodSecurityPolicy API is deprecated in 1.21, and will no longer be served starting in 1.25. ([#97171](https://github.com/kubernetes/kubernetes/pull/97171), [@deads2k](https://github.com/deads2k)) [SIG Auth and CLI] -- The `batch/v2alpha1` CronJob type definitions and clients are deprecated and removed. ([#96987](https://github.com/kubernetes/kubernetes/pull/96987), [@soltysh](https://github.com/soltysh)) [SIG API Machinery, Apps, CLI and Testing] -- The `export` query parameter (inconsistently supported by API resources and deprecated in v1.14) is fully removed. Requests setting this query parameter will now receive a 400 status response. ([#98312](https://github.com/kubernetes/kubernetes/pull/98312), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, Auth and Testing] -- `audit.k8s.io/v1beta1` and `audit.k8s.io/v1alpha1` audit policy configuration and audit events are deprecated in favor of `audit.k8s.io/v1`, available since v1.13. kube-apiserver invocations that specify alpha or beta policy configurations with `--audit-policy-file`, or explicitly request alpha or beta audit events with `--audit-log-version` / `--audit-webhook-version` must update to use `audit.k8s.io/v1` and accept `audit.k8s.io/v1` events prior to v1.24. ([#98858](https://github.com/kubernetes/kubernetes/pull/98858), [@carlory](https://github.com/carlory)) [SIG Auth] -- `discovery.k8s.io/v1beta1` EndpointSlices are deprecated in favor of `discovery.k8s.io/v1`, and will no longer be served in Kubernetes v1.25. ([#100472](https://github.com/kubernetes/kubernetes/pull/100472), [@liggitt](https://github.com/liggitt)) -- `diskformat` storage class parameter for in-tree vSphere volume plugin is deprecated as of v1.21 release. Please consider updating storageclass and remove `diskformat` parameter. vSphere CSI Driver does not support diskformat storageclass parameter. - - vSphere releases less than 67u3 are deprecated as of v1.21. Please consider upgrading vSphere to 67u3 or above. vSphere CSI Driver requires minimum vSphere 67u3. - - VM Hardware version less than 15 is deprecated as of v1.21. Please consider upgrading the Node VM Hardware version to 15 or above. vSphere CSI Driver recommends Node VM's Hardware version set to at least vmx-15. - - Multi vCenter support is deprecated as of v1.21. If you have a Kubernetes cluster spanning across multiple vCenter servers, please consider moving all k8s nodes to a single vCenter Server. vSphere CSI Driver does not support Kubernetes deployment spanning across multiple vCenter servers. - - Support for these deprecations will be available till Kubernetes v1.24. ([#98546](https://github.com/kubernetes/kubernetes/pull/98546), [@divyenpatel](https://github.com/divyenpatel)) - -### API 변경 - -- 1. PodAffinityTerm includes a namespaceSelector field to allow selecting eligible namespaces based on their labels. - 2. A new CrossNamespacePodAffinity quota scope API that allows restricting which namespaces allowed to use PodAffinityTerm with corss-namespace reference via namespaceSelector or namespaces fields. ([#98582](https://github.com/kubernetes/kubernetes/pull/98582), [@ahg-g](https://github.com/ahg-g)) [SIG API Machinery, Apps, Auth and Testing] -- Add Probe-level terminationGracePeriodSeconds field ([#99375](https://github.com/kubernetes/kubernetes/pull/99375), [@ehashman](https://github.com/ehashman)) [SIG API Machinery, Apps, Node and Testing] -- Added `.spec.completionMode` field to Job, with accepted values `NonIndexed` (default) and `Indexed`. This is an alpha field and is only honored by servers with the `IndexedJob` feature gate enabled. ([#98441](https://github.com/kubernetes/kubernetes/pull/98441), [@alculquicondor](https://github.com/alculquicondor)) [SIG Apps and CLI] -- Adds support for endPort field in NetworkPolicy ([#97058](https://github.com/kubernetes/kubernetes/pull/97058), [@rikatz](https://github.com/rikatz)) [SIG Apps and Network] -- CSIServiceAccountToken graduates to Beta and enabled by default. ([#99298](https://github.com/kubernetes/kubernetes/pull/99298), [@zshihang](https://github.com/zshihang)) -- Cluster admins can now turn off `/debug/pprof` and `/debug/flags/v` endpoint in kubelet by setting `enableProfilingHandler` and `enableDebugFlagsHandler` to `false` in the Kubelet configuration file. Options `enableProfilingHandler` and `enableDebugFlagsHandler` can be set to `true` only when `enableDebuggingHandlers` is also set to `true`. ([#98458](https://github.com/kubernetes/kubernetes/pull/98458), [@SaranBalaji90](https://github.com/SaranBalaji90)) -- DaemonSets accept a MaxSurge integer or percent on their rolling update strategy that will launch the updated pod on nodes and wait for those pods to go ready before marking the old out-of-date pods as deleted. This allows workloads to avoid downtime during upgrades when deployed using DaemonSets. This feature is alpha and is behind the DaemonSetUpdateSurge feature gate. ([#96441](https://github.com/kubernetes/kubernetes/pull/96441), [@smarterclayton](https://github.com/smarterclayton)) [SIG Apps and Testing] -- Enable SPDY pings to keep connections alive, so that `kubectl exec` and `kubectl portforward` won't be interrupted. ([#97083](https://github.com/kubernetes/kubernetes/pull/97083), [@knight42](https://github.com/knight42)) [SIG API Machinery and CLI] -- FieldManager no longer owns fields that get reset before the object is persisted (e.g. "status wiping"). ([#99661](https://github.com/kubernetes/kubernetes/pull/99661), [@kevindelgado](https://github.com/kevindelgado)) [SIG API Machinery, Auth and Testing] -- Fixes server-side apply for APIService resources. ([#98576](https://github.com/kubernetes/kubernetes/pull/98576), [@kevindelgado](https://github.com/kevindelgado)) -- Generic ephemeral volumes are beta. ([#99643](https://github.com/kubernetes/kubernetes/pull/99643), [@pohly](https://github.com/pohly)) [SIG API Machinery, Apps, Auth, CLI, Node, Storage and Testing] -- Hugepages request values are limited to integer multiples of the page size. ([#98515](https://github.com/kubernetes/kubernetes/pull/98515), [@lala123912](https://github.com/lala123912)) [SIG Apps] -- Implement the GetAvailableResources in the podresources API. ([#95734](https://github.com/kubernetes/kubernetes/pull/95734), [@fromanirh](https://github.com/fromanirh)) [SIG Instrumentation, Node and Testing] -- IngressClass resource can now reference a resource in a specific namespace - for implementation-specific configuration (previously only Cluster-level resources were allowed). - This feature can be enabled using the IngressClassNamespacedParams feature gate. ([#99275](https://github.com/kubernetes/kubernetes/pull/99275), [@hbagdi](https://github.com/hbagdi)) -- Jobs API has a new `.spec.suspend` field that can be used to suspend and resume Jobs. This is an alpha field which is only honored by servers with the `SuspendJob` feature gate enabled. ([#98727](https://github.com/kubernetes/kubernetes/pull/98727), [@adtac](https://github.com/adtac)) -- Kubelet Graceful Node Shutdown feature graduates to Beta and enabled by default. ([#99735](https://github.com/kubernetes/kubernetes/pull/99735), [@bobbypage](https://github.com/bobbypage)) -- Kubernetes is now built using go1.15.7 ([#98363](https://github.com/kubernetes/kubernetes/pull/98363), [@cpanato](https://github.com/cpanato)) [SIG Cloud Provider, Instrumentation, Node, Release and Testing] -- Namespace API objects now have a `kubernetes.io/metadata.name` label matching their metadata.name field to allow selecting any namespace by its name using a label selector. ([#96968](https://github.com/kubernetes/kubernetes/pull/96968), [@jayunit100](https://github.com/jayunit100)) [SIG API Machinery, Apps, Cloud Provider, Storage and Testing] -- One new field "InternalTrafficPolicy" in Service is added. - It specifies if the cluster internal traffic should be routed to all endpoints or node-local endpoints only. - "Cluster" routes internal traffic to a Service to all endpoints. - "Local" routes traffic to node-local endpoints only, and traffic is dropped if no node-local endpoints are ready. - The default value is "Cluster". ([#96600](https://github.com/kubernetes/kubernetes/pull/96600), [@maplain](https://github.com/maplain)) [SIG API Machinery, Apps and Network] -- PodDisruptionBudget API objects can now contain conditions in status. ([#98127](https://github.com/kubernetes/kubernetes/pull/98127), [@mortent](https://github.com/mortent)) [SIG API Machinery, Apps, Auth, CLI, Cloud Provider, Cluster Lifecycle and Instrumentation] -- PodSecurityPolicy only stores "generic" as allowed volume type if the GenericEphemeralVolume feature gate is enabled ([#98918](https://github.com/kubernetes/kubernetes/pull/98918), [@pohly](https://github.com/pohly)) [SIG Auth and Security] -- Promote CronJobs to batch/v1 ([#99423](https://github.com/kubernetes/kubernetes/pull/99423), [@soltysh](https://github.com/soltysh)) [SIG API Machinery, Apps, CLI and Testing] -- Promote Immutable Secrets/ConfigMaps feature to Stable. This allows to set `immutable` field in Secret or ConfigMap object to mark their contents as immutable. ([#97615](https://github.com/kubernetes/kubernetes/pull/97615), [@wojtek-t](https://github.com/wojtek-t)) [SIG Apps, Architecture, Node and Testing] -- Remove support for building Kubernetes with bazel. ([#99561](https://github.com/kubernetes/kubernetes/pull/99561), [@BenTheElder](https://github.com/BenTheElder)) [SIG API Machinery, Apps, Architecture, Auth, Autoscaling, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation, Network, Node, Release, Scalability, Scheduling, Storage, Testing and Windows] -- Scheduler extender filter interface now can report unresolvable failed nodes in the new field `FailedAndUnresolvableNodes` of `ExtenderFilterResult` struct. Nodes in this map will be skipped in the preemption phase. ([#92866](https://github.com/kubernetes/kubernetes/pull/92866), [@cofyc](https://github.com/cofyc)) [SIG Scheduling] -- Services can specify loadBalancerClass to use a custom load balancer ([#98277](https://github.com/kubernetes/kubernetes/pull/98277), [@XudongLiuHarold](https://github.com/XudongLiuHarold)) -- Storage capacity tracking (= the CSIStorageCapacity feature) graduates to Beta and enabled by default, storage.k8s.io/v1alpha1/VolumeAttachment and storage.k8s.io/v1alpha1/CSIStorageCapacity objects are deprecated ([#99641](https://github.com/kubernetes/kubernetes/pull/99641), [@pohly](https://github.com/pohly)) -- Support for Indexed Job: a Job that is considered completed when Pods associated to indexes from 0 to (.spec.completions-1) have succeeded. ([#98812](https://github.com/kubernetes/kubernetes/pull/98812), [@alculquicondor](https://github.com/alculquicondor)) [SIG Apps and CLI] -- The BoundServiceAccountTokenVolume feature has been promoted to beta, and enabled by default. - - This changes the tokens provided to containers at `/var/run/secrets/kubernetes.io/serviceaccount/token` to be time-limited, auto-refreshed, and invalidated when the containing pod is deleted. - - Clients should reload the token from disk periodically (once per minute is recommended) to ensure they continue to use a valid token. `k8s.io/client-go` version v11.0.0+ and v0.15.0+ reload tokens automatically. - - By default, injected tokens are given an extended lifetime so they remain valid even after a new refreshed token is provided. The metric `serviceaccount_stale_tokens_total` can be used to monitor for workloads that are depending on the extended lifetime and are continuing to use tokens even after a refreshed token is provided to the container. If that metric indicates no existing workloads are depending on extended lifetimes, injected token lifetime can be shortened to 1 hour by starting `kube-apiserver` with `--service-account-extend-token-expiration=false`. ([#95667](https://github.com/kubernetes/kubernetes/pull/95667), [@zshihang](https://github.com/zshihang)) [SIG API Machinery, Auth, Cluster Lifecycle and Testing] -- The EndpointSlice Controllers are now GA. The `EndpointSliceController` will not populate the `deprecatedTopology` field and will only provide topology information through the `zone` and `nodeName` fields. ([#99870](https://github.com/kubernetes/kubernetes/pull/99870), [@swetharepakula](https://github.com/swetharepakula)) -- The Endpoints controller will now set the `endpoints.kubernetes.io/over-capacity` annotation to "warning" when an Endpoints resource contains more than 1000 addresses. In a future release, the controller will truncate Endpoints that exceed this limit. The EndpointSlice API can be used to support significantly larger number of addresses. ([#99975](https://github.com/kubernetes/kubernetes/pull/99975), [@robscott](https://github.com/robscott)) [SIG Apps and Network] -- The PodDisruptionBudget API has been promoted to policy/v1 with no schema changes. The only functional change is that an empty selector (`{}`) written to a policy/v1 PodDisruptionBudget now selects all pods in the namespace. The behavior of the policy/v1beta1 API remains unchanged. The policy/v1beta1 PodDisruptionBudget API is deprecated and will no longer be served in 1.25+. ([#99290](https://github.com/kubernetes/kubernetes/pull/99290), [@mortent](https://github.com/mortent)) [SIG API Machinery, Apps, Auth, Autoscaling, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation, Scheduling and Testing] -- The `EndpointSlice` API is now GA. The `EndpointSlice` topology field has been removed from the GA API and will be replaced by a new per Endpoint Zone field. If the topology field was previously used, it will be converted into an annotation in the v1 Resource. The `discovery.k8s.io/v1alpha1` API is removed. ([#99662](https://github.com/kubernetes/kubernetes/pull/99662), [@swetharepakula](https://github.com/swetharepakula)) -- The `controller.kubernetes.io/pod-deletion-cost` annotation can be set to offer a hint on the cost of deleting a `Pod` compared to other pods belonging to the same ReplicaSet. Pods with lower deletion cost are deleted first. This is an alpha feature. ([#99163](https://github.com/kubernetes/kubernetes/pull/99163), [@ahg-g](https://github.com/ahg-g)) -- The kube-apiserver now resets `managedFields` that got corrupted by a mutating admission controller. ([#98074](https://github.com/kubernetes/kubernetes/pull/98074), [@kwiesmueller](https://github.com/kwiesmueller)) -- Topology Aware Hints are now available in alpha and can be enabled with the `TopologyAwareHints` feature gate. ([#99522](https://github.com/kubernetes/kubernetes/pull/99522), [@robscott](https://github.com/robscott)) [SIG API Machinery, Apps, Auth, Instrumentation, Network and Testing] -- Users might specify the `kubectl.kubernetes.io/default-exec-container` annotation in a Pod to preselect container for kubectl commands. ([#97099](https://github.com/kubernetes/kubernetes/pull/97099), [@pacoxu](https://github.com/pacoxu)) [SIG CLI] - -### 기능 (Feature) - -- A client-go metric, rest_client_exec_plugin_call_total, has been added to track total calls to client-go credential plugins. ([#98892](https://github.com/kubernetes/kubernetes/pull/98892), [@ankeesler](https://github.com/ankeesler)) [SIG API Machinery, Auth, Cluster Lifecycle and Instrumentation] -- A new histogram metric to track the time it took to delete a job by the `TTLAfterFinished` controller ([#98676](https://github.com/kubernetes/kubernetes/pull/98676), [@ahg-g](https://github.com/ahg-g)) -- AWS cloud provider supports auto-discovering subnets without any `kubernetes.io/cluster/` tags. It also supports additional service annotation `service.beta.kubernetes.io/aws-load-balancer-subnets` to manually configure the subnets. ([#97431](https://github.com/kubernetes/kubernetes/pull/97431), [@kishorj](https://github.com/kishorj)) -- Aborting the drain command in a list of nodes will be deprecated. The new behavior will make the drain command go through all nodes even if one or more nodes failed during the drain. For now, users can try such experience by enabling --ignore-errors flag. ([#98203](https://github.com/kubernetes/kubernetes/pull/98203), [@yuzhiquan](https://github.com/yuzhiquan)) -- Add --permit-address-sharing flag to `kube-apiserver` to listen with `SO_REUSEADDR`. While allowing to listen on wildcard IPs like 0.0.0.0 and specific IPs in parallel, it avoids waiting for the kernel to release socket in `TIME_WAIT` state, and hence, considerably reducing `kube-apiserver` restart times under certain conditions. ([#93861](https://github.com/kubernetes/kubernetes/pull/93861), [@sttts](https://github.com/sttts)) -- Add `csi_operations_seconds` metric on kubelet that exposes CSI operations duration and status for node CSI operations. ([#98979](https://github.com/kubernetes/kubernetes/pull/98979), [@Jiawei0227](https://github.com/Jiawei0227)) [SIG Instrumentation and Storage] -- Add `migrated` field into `storage_operation_duration_seconds` metric ([#99050](https://github.com/kubernetes/kubernetes/pull/99050), [@Jiawei0227](https://github.com/Jiawei0227)) [SIG Apps, Instrumentation and Storage] -- Add flag --lease-reuse-duration-seconds for kube-apiserver to config etcd lease reuse duration. ([#97009](https://github.com/kubernetes/kubernetes/pull/97009), [@lingsamuel](https://github.com/lingsamuel)) [SIG API Machinery and Scalability] -- Add metric etcd_lease_object_counts for kube-apiserver to observe max objects attached to a single etcd lease. ([#97480](https://github.com/kubernetes/kubernetes/pull/97480), [@lingsamuel](https://github.com/lingsamuel)) [SIG API Machinery, Instrumentation and Scalability] -- Add support to generate client-side binaries for new darwin/arm64 platform ([#97743](https://github.com/kubernetes/kubernetes/pull/97743), [@dims](https://github.com/dims)) [SIG Release and Testing] -- Added `ephemeral_volume_controller_create[_failures]_total` counters to kube-controller-manager metrics ([#99115](https://github.com/kubernetes/kubernetes/pull/99115), [@pohly](https://github.com/pohly)) [SIG API Machinery, Apps, Cluster Lifecycle, Instrumentation and Storage] -- Added support for installing `arm64` node artifacts. ([#99242](https://github.com/kubernetes/kubernetes/pull/99242), [@liu-cong](https://github.com/liu-cong)) -- Adds alpha feature `VolumeCapacityPriority` which makes the scheduler prioritize nodes based on the best matching size of statically provisioned PVs across multiple topologies. ([#96347](https://github.com/kubernetes/kubernetes/pull/96347), [@cofyc](https://github.com/cofyc)) [SIG Apps, Network, Scheduling, Storage and Testing] -- Adds the ability to pass --strict-transport-security-directives to the kube-apiserver to set the HSTS header appropriately. Be sure you understand the consequences to browsers before setting this field. ([#96502](https://github.com/kubernetes/kubernetes/pull/96502), [@249043822](https://github.com/249043822)) [SIG Auth] -- Adds two new metrics to cronjobs, a histogram to track the time difference when a job is created and the expected time when it should be created, as well as a gauge for the missed schedules of a cronjob ([#99341](https://github.com/kubernetes/kubernetes/pull/99341), [@alaypatel07](https://github.com/alaypatel07)) -- Alpha implementation of Kubectl Command Headers: SIG CLI KEP 859 enabled when KUBECTL_COMMAND_HEADERS environment variable set on the client command line. ([#98952](https://github.com/kubernetes/kubernetes/pull/98952), [@seans3](https://github.com/seans3)) -- Base-images: Update to debian-iptables:buster-v1.4.0 - - Uses iptables 1.8.5 - - base-images: Update to debian-base:buster-v1.3.0 - - cluster/images/etcd: Build etcd:3.4.13-2 image - - Uses debian-base:buster-v1.3.0 ([#98401](https://github.com/kubernetes/kubernetes/pull/98401), [@pacoxu](https://github.com/pacoxu)) [SIG Testing] -- CRIContainerLogRotation graduates to GA and unconditionally enabled. ([#99651](https://github.com/kubernetes/kubernetes/pull/99651), [@umohnani8](https://github.com/umohnani8)) -- Component owner can configure the allowlist of metric label with flag '--allow-metric-labels'. ([#99385](https://github.com/kubernetes/kubernetes/pull/99385), [@YoyinZyc](https://github.com/YoyinZyc)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Release] -- Component owner can configure the allowlist of metric label with flag '--allow-metric-labels'. ([#99738](https://github.com/kubernetes/kubernetes/pull/99738), [@YoyinZyc](https://github.com/YoyinZyc)) [SIG API Machinery, Cluster Lifecycle and Instrumentation] -- EmptyDir memory backed volumes are sized as the the minimum of pod allocatable memory on a host and an optional explicit user provided value. ([#100319](https://github.com/kubernetes/kubernetes/pull/100319), [@derekwaynecarr](https://github.com/derekwaynecarr)) [SIG Node] -- Enables Kubelet to check volume condition and log events to corresponding pods. ([#99284](https://github.com/kubernetes/kubernetes/pull/99284), [@fengzixu](https://github.com/fengzixu)) [SIG Apps, Instrumentation, Node and Storage] -- EndpointSliceNodeName graduates to GA and thus will be unconditionally enabled -- NodeName will always be available in the v1beta1 API. ([#99746](https://github.com/kubernetes/kubernetes/pull/99746), [@swetharepakula](https://github.com/swetharepakula)) -- Export `NewDebuggingRoundTripper` function and `DebugLevel` options in the k8s.io/client-go/transport package. ([#98324](https://github.com/kubernetes/kubernetes/pull/98324), [@atosatto](https://github.com/atosatto)) -- Kube-proxy iptables: new metric sync_proxy_rules_iptables_total that exposes the number of rules programmed per table in each iteration ([#99653](https://github.com/kubernetes/kubernetes/pull/99653), [@aojea](https://github.com/aojea)) [SIG Instrumentation and Network] -- Kube-scheduler now logs plugin scoring summaries at --v=4 ([#99411](https://github.com/kubernetes/kubernetes/pull/99411), [@damemi](https://github.com/damemi)) [SIG Scheduling] -- Kubeadm now includes CoreDNS v1.8.0. ([#96429](https://github.com/kubernetes/kubernetes/pull/96429), [@rajansandeep](https://github.com/rajansandeep)) [SIG Cluster Lifecycle] -- Kubeadm: IPv6DualStack feature gate graduates to Beta and enabled by default ([#99294](https://github.com/kubernetes/kubernetes/pull/99294), [@pacoxu](https://github.com/pacoxu)) -- Kubeadm: a warning to user as ipv6 site-local is deprecated ([#99574](https://github.com/kubernetes/kubernetes/pull/99574), [@pacoxu](https://github.com/pacoxu)) [SIG Cluster Lifecycle and Network] -- Kubeadm: add support for certificate chain validation. When using kubeadm in external CA mode, this allows an intermediate CA to be used to sign the certificates. The intermediate CA certificate must be appended to each signed certificate for this to work correctly. ([#97266](https://github.com/kubernetes/kubernetes/pull/97266), [@robbiemcmichael](https://github.com/robbiemcmichael)) [SIG Cluster Lifecycle] -- Kubeadm: amend the node kernel validation to treat CGROUP_PIDS, FAIR_GROUP_SCHED as required and CFS_BANDWIDTH, CGROUP_HUGETLB as optional ([#96378](https://github.com/kubernetes/kubernetes/pull/96378), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle and Node] -- Kubeadm: apply the "node.kubernetes.io/exclude-from-external-load-balancers" label on control plane nodes during "init", "join" and "upgrade" to preserve backwards compatibility with the lagacy LB mode where nodes labeled as "master" where excluded. To opt-out you can remove the label from a node. See #97543 and the linked KEP for more details. ([#98269](https://github.com/kubernetes/kubernetes/pull/98269), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] -- Kubeadm: if the user has customized their image repository via the kubeadm configuration, pass the custom pause image repository and tag to the kubelet via --pod-infra-container-image not only for Docker but for all container runtimes. This flag tells the kubelet that it should not garbage collect the image. ([#99476](https://github.com/kubernetes/kubernetes/pull/99476), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] -- Kubeadm: perform pre-flight validation on host/node name upon `kubeadm init` and `kubeadm join`, showing warnings on non-compliant names ([#99194](https://github.com/kubernetes/kubernetes/pull/99194), [@pacoxu](https://github.com/pacoxu)) -- Kubectl version changed to write a warning message to stderr if the client and server version difference exceeds the supported version skew of +/-1 minor version. ([#98250](https://github.com/kubernetes/kubernetes/pull/98250), [@brianpursley](https://github.com/brianpursley)) [SIG CLI] -- Kubectl: Add `--use-protocol-buffers` flag to kubectl top pods and nodes. ([#96655](https://github.com/kubernetes/kubernetes/pull/96655), [@serathius](https://github.com/serathius)) -- Kubectl: `kubectl get` will omit managed fields by default now. Users could set `--show-managed-fields` to true to show managedFields when the output format is either `json` or `yaml`. ([#96878](https://github.com/kubernetes/kubernetes/pull/96878), [@knight42](https://github.com/knight42)) [SIG CLI and Testing] -- Kubectl: a Pod can be preselected as default container using `kubectl.kubernetes.io/default-container` annotation ([#99833](https://github.com/kubernetes/kubernetes/pull/99833), [@mengjiao-liu](https://github.com/mengjiao-liu)) -- Kubectl: add bash-completion for comma separated list on `kubectl get` ([#98301](https://github.com/kubernetes/kubernetes/pull/98301), [@phil9909](https://github.com/phil9909)) -- Kubernetes is now built using go1.15.8 ([#98834](https://github.com/kubernetes/kubernetes/pull/98834), [@cpanato](https://github.com/cpanato)) [SIG Cloud Provider, Instrumentation, Release and Testing] -- Kubernetes is now built with Golang 1.16 ([#98572](https://github.com/kubernetes/kubernetes/pull/98572), [@justaugustus](https://github.com/justaugustus)) [SIG API Machinery, Auth, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation, Node, Release and Testing] -- Kubernetes is now built with Golang 1.16.1 ([#100106](https://github.com/kubernetes/kubernetes/pull/100106), [@justaugustus](https://github.com/justaugustus)) [SIG Cloud Provider, Instrumentation, Release and Testing] -- Metrics can now be disabled explicitly via a command line flag (i.e. '--disabled-metrics=metric1,metric2') ([#99217](https://github.com/kubernetes/kubernetes/pull/99217), [@logicalhan](https://github.com/logicalhan)) -- New admission controller `DenyServiceExternalIPs` is available. Clusters which do not *need* the Service `externalIPs` feature should enable this controller and be more secure. ([#97395](https://github.com/kubernetes/kubernetes/pull/97395), [@thockin](https://github.com/thockin)) -- Overall, enable the feature of `PreferNominatedNode` will improve the performance of scheduling where preemption might frequently happen, but in theory, enable the feature of `PreferNominatedNode`, the pod might not be scheduled to the best candidate node in the cluster. ([#93179](https://github.com/kubernetes/kubernetes/pull/93179), [@chendave](https://github.com/chendave)) [SIG Scheduling and Testing] -- Persistent Volumes formatted with the btrfs filesystem will now automatically resize when expanded. ([#99361](https://github.com/kubernetes/kubernetes/pull/99361), [@Novex](https://github.com/Novex)) [SIG Storage] -- Port the devicemanager to Windows node to allow device plugins like directx ([#93285](https://github.com/kubernetes/kubernetes/pull/93285), [@aarnaud](https://github.com/aarnaud)) [SIG Node, Testing and Windows] -- Removes cAdvisor JSON metrics (/stats/container, /stats//, /stats////) from the kubelet. ([#99236](https://github.com/kubernetes/kubernetes/pull/99236), [@pacoxu](https://github.com/pacoxu)) -- Rename metrics `etcd_object_counts` to `apiserver_storage_object_counts` and mark it as stable. The original `etcd_object_counts` metrics name is marked as "Deprecated" and will be removed in the future. ([#99785](https://github.com/kubernetes/kubernetes/pull/99785), [@erain](https://github.com/erain)) [SIG API Machinery, Instrumentation and Testing] -- Sysctls graduates to General Availability and thus unconditionally enabled. ([#99158](https://github.com/kubernetes/kubernetes/pull/99158), [@wgahnagl](https://github.com/wgahnagl)) -- The Kubernetes pause image manifest list now contains an image for Windows Server 20H2. ([#97322](https://github.com/kubernetes/kubernetes/pull/97322), [@claudiubelu](https://github.com/claudiubelu)) [SIG Windows] -- The NodeAffinity plugin implements the PreFilter extension, offering enhanced performance for Filter. ([#99213](https://github.com/kubernetes/kubernetes/pull/99213), [@AliceZhang2016](https://github.com/AliceZhang2016)) [SIG Scheduling] -- The `CronJobControllerV2` feature flag graduates to Beta and set to be enabled by default. ([#98878](https://github.com/kubernetes/kubernetes/pull/98878), [@soltysh](https://github.com/soltysh)) -- The `EndpointSlice` mirroring controller mirrors endpoints annotations and labels to the generated endpoint slices, it also ensures that updates on any of these fields are mirrored. - The well-known annotation `endpoints.kubernetes.io/last-change-trigger-time` is skipped and not mirrored. ([#98116](https://github.com/kubernetes/kubernetes/pull/98116), [@aojea](https://github.com/aojea)) -- The `RunAsGroup` feature has been promoted to GA in this release. ([#94641](https://github.com/kubernetes/kubernetes/pull/94641), [@krmayankk](https://github.com/krmayankk)) [SIG Auth and Node] -- The `ServiceAccountIssuerDiscovery` feature has graduated to GA, and is unconditionally enabled. The `ServiceAccountIssuerDiscovery` feature-gate will be removed in 1.22. ([#98553](https://github.com/kubernetes/kubernetes/pull/98553), [@mtaufen](https://github.com/mtaufen)) [SIG API Machinery, Auth and Testing] -- The `TTLAfterFinished` feature flag is now beta and enabled by default ([#98678](https://github.com/kubernetes/kubernetes/pull/98678), [@ahg-g](https://github.com/ahg-g)) -- The apimachinery util/net function used to detect the bind address `ResolveBindAddress()` takes into consideration global IP addresses on loopback interfaces when 1) the host has default routes, or 2) there are no global IPs on those interfaces in order to support more complex network scenarios like BGP Unnumbered RFC 5549 ([#95790](https://github.com/kubernetes/kubernetes/pull/95790), [@aojea](https://github.com/aojea)) [SIG Network] -- The feature gate `RootCAConfigMap` graduated to GA in v1.21 and therefore will be unconditionally enabled. This flag will be removed in v1.22 release. ([#98033](https://github.com/kubernetes/kubernetes/pull/98033), [@zshihang](https://github.com/zshihang)) -- The pause image upgraded to `v3.4.1` in kubelet and kubeadm for both Linux and Windows. ([#98205](https://github.com/kubernetes/kubernetes/pull/98205), [@pacoxu](https://github.com/pacoxu)) -- Update pause container to run as pseudo user and group `65535:65535`. This implies the release of version 3.5 of the container images. ([#97963](https://github.com/kubernetes/kubernetes/pull/97963), [@saschagrunert](https://github.com/saschagrunert)) [SIG CLI, Cloud Provider, Cluster Lifecycle, Node, Release, Security and Testing] -- Update the latest validated version of Docker to 20.10 ([#98977](https://github.com/kubernetes/kubernetes/pull/98977), [@neolit123](https://github.com/neolit123)) [SIG CLI, Cluster Lifecycle and Node] -- Upgrade node local dns to 1.17.0 for better IPv6 support ([#99749](https://github.com/kubernetes/kubernetes/pull/99749), [@pacoxu](https://github.com/pacoxu)) [SIG Cloud Provider and Network] -- Upgrades `IPv6Dualstack` to `Beta` and turns it on by default. New clusters or existing clusters are not be affected until an actor starts adding secondary Pods and service CIDRS CLI flags as described here: [IPv4/IPv6 Dual-stack](https://github.com/kubernetes/enhancements/tree/master/keps/sig-network/563-dual-stack) ([#98969](https://github.com/kubernetes/kubernetes/pull/98969), [@khenidak](https://github.com/khenidak)) -- Users might specify the `kubectl.kubernetes.io/default-container` annotation in a Pod to preselect container for kubectl commands. ([#99581](https://github.com/kubernetes/kubernetes/pull/99581), [@mengjiao-liu](https://github.com/mengjiao-liu)) [SIG CLI] -- When downscaling ReplicaSets, ready and creation timestamps are compared in a logarithmic scale. ([#99212](https://github.com/kubernetes/kubernetes/pull/99212), [@damemi](https://github.com/damemi)) [SIG Apps and Testing] -- When the kubelet is watching a ConfigMap or Secret purely in the context of setting environment variables - for containers, only hold that watch for a defined duration before cancelling it. This change reduces the CPU - and memory usage of the kube-apiserver in large clusters. ([#99393](https://github.com/kubernetes/kubernetes/pull/99393), [@chenyw1990](https://github.com/chenyw1990)) [SIG API Machinery, Node and Testing] -- WindowsEndpointSliceProxying feature gate has graduated to beta and is enabled by default. This means kube-proxy will read from EndpointSlices instead of Endpoints on Windows by default. ([#99794](https://github.com/kubernetes/kubernetes/pull/99794), [@robscott](https://github.com/robscott)) [SIG Network] -- `kubectl wait` ensures that observedGeneration >= generation to prevent stale state reporting. An example scenario can be found on CRD updates. ([#97408](https://github.com/kubernetes/kubernetes/pull/97408), [@KnicKnic](https://github.com/KnicKnic)) - -### 문서 - -- Azure file migration graduates to beta, with CSIMigrationAzureFile flag off by default - as it requires installation of AzureFile CSI Driver. Users should enable CSIMigration and - CSIMigrationAzureFile features and install the [AzureFile CSI Driver](https://github.com/kubernetes-sigs/azurefile-csi-driver) - to avoid disruption to existing Pod and PVC objects at that time. Azure File CSI driver does not support using same persistent - volume with different fsgroups. When CSI migration is enabled for azurefile driver, such case is not supported. - (there is a case we support where volume is mounted with 0777 and then it readable/writable by everyone) ([#96293](https://github.com/kubernetes/kubernetes/pull/96293), [@andyzhangx](https://github.com/andyzhangx)) -- Official support to build kubernetes with docker-machine / remote docker is removed. This change does not affect building kubernetes with docker locally. ([#97935](https://github.com/kubernetes/kubernetes/pull/97935), [@adeniyistephen](https://github.com/adeniyistephen)) [SIG Release and Testing] -- Set kubelet option `--volume-stats-agg-period` to negative value to disable volume calculations. ([#96675](https://github.com/kubernetes/kubernetes/pull/96675), [@pacoxu](https://github.com/pacoxu)) [SIG Node] - -### 실패 테스트 - -- Escape the special characters like `[`, `]` and ` ` that exist in vsphere windows path ([#98830](https://github.com/kubernetes/kubernetes/pull/98830), [@liyanhui1228](https://github.com/liyanhui1228)) [SIG Storage and Windows] -- Kube-proxy: fix a bug on UDP `NodePort` Services where stale connection tracking entries may blackhole the traffic directed to the `NodePort` ([#98305](https://github.com/kubernetes/kubernetes/pull/98305), [@aojea](https://github.com/aojea)) -- Kubelet: fixes a bug in the HostPort dockershim implementation that caused the conformance test "HostPort validates that there is no conflict between pods with same hostPort but different hostIP and protocol" to fail. ([#98755](https://github.com/kubernetes/kubernetes/pull/98755), [@aojea](https://github.com/aojea)) [SIG Cloud Provider, Network and Node] - -### 버그 또는 회귀(regression) - -- AcceleratorStats will be available in the Summary API of kubelet when cri_stats_provider is used. ([#96873](https://github.com/kubernetes/kubernetes/pull/96873), [@ruiwen-zhao](https://github.com/ruiwen-zhao)) [SIG Node] -- All data is no longer automatically deleted when a failure is detected during creation of the volume data file on a CSI volume. Now only the data file and volume path is removed. ([#96021](https://github.com/kubernetes/kubernetes/pull/96021), [@huffmanca](https://github.com/huffmanca)) -- Clean ReplicaSet by revision instead of creation timestamp in deployment controller ([#97407](https://github.com/kubernetes/kubernetes/pull/97407), [@waynepeking348](https://github.com/waynepeking348)) [SIG Apps] -- Cleanup subnet in frontend IP configs to prevent huge subnet request bodies in some scenarios. ([#98133](https://github.com/kubernetes/kubernetes/pull/98133), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider] -- Client-go exec credential plugins will pass stdin only when interactive terminal is detected on stdin. This fixes a bug where previously it was checking if **stdout** is an interactive terminal. ([#99654](https://github.com/kubernetes/kubernetes/pull/99654), [@ankeesler](https://github.com/ankeesler)) -- Cloud-controller-manager: routes controller should not depend on --allocate-node-cidrs ([#97029](https://github.com/kubernetes/kubernetes/pull/97029), [@andrewsykim](https://github.com/andrewsykim)) [SIG Cloud Provider and Testing] -- Cluster Autoscaler version bump to v1.20.0 ([#97011](https://github.com/kubernetes/kubernetes/pull/97011), [@towca](https://github.com/towca)) -- Creating a PVC with DataSource should fail for non-CSI plugins. ([#97086](https://github.com/kubernetes/kubernetes/pull/97086), [@xing-yang](https://github.com/xing-yang)) [SIG Apps and Storage] -- EndpointSlice controller is now less likely to emit FailedToUpdateEndpointSlices events. ([#99345](https://github.com/kubernetes/kubernetes/pull/99345), [@robscott](https://github.com/robscott)) [SIG Apps and Network] -- EndpointSlice controllers are less likely to create duplicate EndpointSlices. ([#100103](https://github.com/kubernetes/kubernetes/pull/100103), [@robscott](https://github.com/robscott)) [SIG Apps and Network] -- EndpointSliceMirroring controller is now less likely to emit FailedToUpdateEndpointSlices events. ([#99756](https://github.com/kubernetes/kubernetes/pull/99756), [@robscott](https://github.com/robscott)) [SIG Apps and Network] -- Ensure all vSphere nodes are are tracked by volume attach-detach controller ([#96689](https://github.com/kubernetes/kubernetes/pull/96689), [@gnufied](https://github.com/gnufied)) -- Ensure empty string annotations are copied over in rollbacks. ([#94858](https://github.com/kubernetes/kubernetes/pull/94858), [@waynepeking348](https://github.com/waynepeking348)) -- Ensure only one LoadBalancer rule is created when HA mode is enabled ([#99825](https://github.com/kubernetes/kubernetes/pull/99825), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider] -- Ensure that client-go's EventBroadcaster is safe (non-racy) during shutdown. ([#95664](https://github.com/kubernetes/kubernetes/pull/95664), [@DirectXMan12](https://github.com/DirectXMan12)) [SIG API Machinery] -- Explicitly pass `KUBE_BUILD_CONFORMANCE=y` in `package-tarballs` to reenable building the conformance tarballs. ([#100571](https://github.com/kubernetes/kubernetes/pull/100571), [@puerco](https://github.com/puerco)) -- Fix Azure file migration e2e test failure when CSIMigration is turned on. ([#97877](https://github.com/kubernetes/kubernetes/pull/97877), [@andyzhangx](https://github.com/andyzhangx)) -- Fix CSI-migrated inline EBS volumes failing to mount if their volumeID is prefixed by aws:// ([#96821](https://github.com/kubernetes/kubernetes/pull/96821), [@wongma7](https://github.com/wongma7)) [SIG Storage] -- Fix CVE-2020-8555 for Gluster client connections. ([#97922](https://github.com/kubernetes/kubernetes/pull/97922), [@liggitt](https://github.com/liggitt)) [SIG Storage] -- Fix NPE in ephemeral storage eviction ([#98261](https://github.com/kubernetes/kubernetes/pull/98261), [@wzshiming](https://github.com/wzshiming)) [SIG Node] -- Fix PermissionDenied issue on SMB mount for Windows ([#99550](https://github.com/kubernetes/kubernetes/pull/99550), [@andyzhangx](https://github.com/andyzhangx)) -- Fix bug that would let the Horizontal Pod Autoscaler scale down despite at least one metric being unavailable/invalid ([#99514](https://github.com/kubernetes/kubernetes/pull/99514), [@mikkeloscar](https://github.com/mikkeloscar)) [SIG Apps and Autoscaling] -- Fix cgroup handling for systemd with cgroup v2 ([#98365](https://github.com/kubernetes/kubernetes/pull/98365), [@odinuge](https://github.com/odinuge)) [SIG Node] -- Fix counting error in service/nodeport/loadbalancer quota check ([#97451](https://github.com/kubernetes/kubernetes/pull/97451), [@pacoxu](https://github.com/pacoxu)) [SIG API Machinery, Network and Testing] -- Fix errors when accessing Windows container stats for Dockershim ([#98510](https://github.com/kubernetes/kubernetes/pull/98510), [@jsturtevant](https://github.com/jsturtevant)) [SIG Node and Windows] -- Fix kube-proxy container image architecture for non amd64 images. ([#98526](https://github.com/kubernetes/kubernetes/pull/98526), [@saschagrunert](https://github.com/saschagrunert)) -- Fix missing cadvisor machine metrics. ([#97006](https://github.com/kubernetes/kubernetes/pull/97006), [@lingsamuel](https://github.com/lingsamuel)) [SIG Node] -- Fix nil VMSS name when setting service to auto mode ([#97366](https://github.com/kubernetes/kubernetes/pull/97366), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider] -- Fix privileged config of Pod Sandbox which was previously ignored. ([#96877](https://github.com/kubernetes/kubernetes/pull/96877), [@xeniumlee](https://github.com/xeniumlee)) -- Fix the panic when kubelet registers if a node object already exists with no Status.Capacity or Status.Allocatable ([#95269](https://github.com/kubernetes/kubernetes/pull/95269), [@SataQiu](https://github.com/SataQiu)) [SIG Node] -- Fix the regression with the slow pods termination. Before this fix pods may take an additional time to terminate - up to one minute. Reversing the change that ensured that CNI resources cleaned up when the pod is removed on API server. ([#97980](https://github.com/kubernetes/kubernetes/pull/97980), [@SergeyKanzhelev](https://github.com/SergeyKanzhelev)) [SIG Node] -- Fix to recover CSI volumes from certain dangling attachments ([#96617](https://github.com/kubernetes/kubernetes/pull/96617), [@yuga711](https://github.com/yuga711)) [SIG Apps and Storage] -- Fix: azure file latency issue for metadata-heavy workloads ([#97082](https://github.com/kubernetes/kubernetes/pull/97082), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage] -- Fixed Cinder volume IDs on OpenStack Train ([#96673](https://github.com/kubernetes/kubernetes/pull/96673), [@jsafrane](https://github.com/jsafrane)) [SIG Cloud Provider] -- Fixed FibreChannel volume plugin corrupting filesystems on detach of multipath volumes. ([#97013](https://github.com/kubernetes/kubernetes/pull/97013), [@jsafrane](https://github.com/jsafrane)) [SIG Storage] -- Fixed a bug in kubelet that will saturate CPU utilization after containerd got restarted. ([#97174](https://github.com/kubernetes/kubernetes/pull/97174), [@hanlins](https://github.com/hanlins)) [SIG Node] -- Fixed a bug that causes smaller number of conntrack-max being used under CPU static policy. (#99225, @xh4n3) ([#99613](https://github.com/kubernetes/kubernetes/pull/99613), [@xh4n3](https://github.com/xh4n3)) [SIG Network] -- Fixed a bug that on k8s nodes, when the policy of INPUT chain in filter table is not ACCEPT, healthcheck nodeport would not work. - Added iptables rules to allow healthcheck nodeport traffic. ([#97824](https://github.com/kubernetes/kubernetes/pull/97824), [@hanlins](https://github.com/hanlins)) [SIG Network] -- Fixed a bug that the kubelet cannot start on BtrfS. ([#98042](https://github.com/kubernetes/kubernetes/pull/98042), [@gjkim42](https://github.com/gjkim42)) [SIG Node] -- Fixed a race condition on API server startup ensuring previously created webhook configurations are effective before the first write request is admitted. ([#95783](https://github.com/kubernetes/kubernetes/pull/95783), [@roycaihw](https://github.com/roycaihw)) [SIG API Machinery] -- Fixed an issue with garbage collection failing to clean up namespaced children of an object also referenced incorrectly by cluster-scoped children ([#98068](https://github.com/kubernetes/kubernetes/pull/98068), [@liggitt](https://github.com/liggitt)) [SIG API Machinery and Apps] -- Fixed authentication_duration_seconds metric scope. Previously, it included whole apiserver request duration which yields inaccurate results. ([#99944](https://github.com/kubernetes/kubernetes/pull/99944), [@marseel](https://github.com/marseel)) -- Fixed bug in CPUManager with race on container map access ([#97427](https://github.com/kubernetes/kubernetes/pull/97427), [@klueska](https://github.com/klueska)) [SIG Node] -- Fixed bug that caused cAdvisor to incorrectly detect single-socket multi-NUMA topology. ([#99315](https://github.com/kubernetes/kubernetes/pull/99315), [@iwankgb](https://github.com/iwankgb)) [SIG Node] -- Fixed cleanup of block devices when /var/lib/kubelet is a symlink. ([#96889](https://github.com/kubernetes/kubernetes/pull/96889), [@jsafrane](https://github.com/jsafrane)) [SIG Storage] -- Fixed no effect namespace when exposing deployment with --dry-run=client. ([#97492](https://github.com/kubernetes/kubernetes/pull/97492), [@masap](https://github.com/masap)) [SIG CLI] -- Fixed provisioning of Cinder volumes migrated to CSI when StorageClass with AllowedTopologies was used. ([#98311](https://github.com/kubernetes/kubernetes/pull/98311), [@jsafrane](https://github.com/jsafrane)) [SIG Storage] -- Fixes a bug of identifying the correct containerd process. ([#97888](https://github.com/kubernetes/kubernetes/pull/97888), [@pacoxu](https://github.com/pacoxu)) -- Fixes add-on manager leader election to use leases instead of endpoints, similar to what kube-controller-manager does in 1.20 ([#98968](https://github.com/kubernetes/kubernetes/pull/98968), [@liggitt](https://github.com/liggitt)) -- Fixes connection errors when using `--volume-host-cidr-denylist` or `--volume-host-allow-local-loopback` ([#98436](https://github.com/kubernetes/kubernetes/pull/98436), [@liggitt](https://github.com/liggitt)) [SIG Network and Storage] -- Fixes problem where invalid selector on `PodDisruptionBudget` leads to a nil pointer dereference that causes the Controller manager to crash loop. ([#98750](https://github.com/kubernetes/kubernetes/pull/98750), [@mortent](https://github.com/mortent)) -- Fixes spurious errors about IPv6 in `kube-proxy` logs on nodes with IPv6 disabled. ([#99127](https://github.com/kubernetes/kubernetes/pull/99127), [@danwinship](https://github.com/danwinship)) -- Fixing a bug where a failed node may not have the NoExecute taint set correctly ([#96876](https://github.com/kubernetes/kubernetes/pull/96876), [@howieyuen](https://github.com/howieyuen)) [SIG Apps and Node] -- GCE Internal LoadBalancer sync loop will now release the ILB IP address upon sync failure. An error in ILB forwarding rule creation will no longer leak IP addresses. ([#97740](https://github.com/kubernetes/kubernetes/pull/97740), [@prameshj](https://github.com/prameshj)) [SIG Cloud Provider and Network] -- Ignore update pod with no new images in alwaysPullImages admission controller ([#96668](https://github.com/kubernetes/kubernetes/pull/96668), [@pacoxu](https://github.com/pacoxu)) [SIG Apps, Auth and Node] -- Improve speed of vSphere PV provisioning and reduce number of API calls ([#100054](https://github.com/kubernetes/kubernetes/pull/100054), [@gnufied](https://github.com/gnufied)) [SIG Cloud Provider and Storage] -- KUBECTL_EXTERNAL_DIFF now accepts equal sign for additional parameters. ([#98158](https://github.com/kubernetes/kubernetes/pull/98158), [@dougsland](https://github.com/dougsland)) [SIG CLI] -- Kube-apiserver: an update of a pod with a generic ephemeral volume dropped that volume if the feature had been disabled since creating the pod with such a volume ([#99446](https://github.com/kubernetes/kubernetes/pull/99446), [@pohly](https://github.com/pohly)) [SIG Apps, Node and Storage] -- Kube-proxy: remove deprecated --cleanup-ipvs flag of kube-proxy, and make --cleanup flag always to flush IPVS ([#97336](https://github.com/kubernetes/kubernetes/pull/97336), [@maaoBit](https://github.com/maaoBit)) [SIG Network] -- Kubeadm installs etcd v3.4.13 when creating cluster v1.19 ([#97244](https://github.com/kubernetes/kubernetes/pull/97244), [@pacoxu](https://github.com/pacoxu)) -- Kubeadm: Fixes a kubeadm upgrade bug that could cause a custom CoreDNS configuration to be replaced with the default. ([#97016](https://github.com/kubernetes/kubernetes/pull/97016), [@rajansandeep](https://github.com/rajansandeep)) [SIG Cluster Lifecycle] -- Kubeadm: Some text in the `kubeadm upgrade plan` output has changed. If you have scripts or other automation that parses this output, please review these changes and update your scripts to account for the new output. ([#98728](https://github.com/kubernetes/kubernetes/pull/98728), [@stmcginnis](https://github.com/stmcginnis)) [SIG Cluster Lifecycle] -- Kubeadm: fix a bug in the host memory detection code on 32bit Linux platforms ([#97403](https://github.com/kubernetes/kubernetes/pull/97403), [@abelbarrera15](https://github.com/abelbarrera15)) [SIG Cluster Lifecycle] -- Kubeadm: fix a bug where "kubeadm join" would not properly handle missing names for existing etcd members. ([#97372](https://github.com/kubernetes/kubernetes/pull/97372), [@ihgann](https://github.com/ihgann)) [SIG Cluster Lifecycle] -- Kubeadm: fix a bug where "kubeadm upgrade" commands can fail if CoreDNS v1.8.0 is installed. ([#97919](https://github.com/kubernetes/kubernetes/pull/97919), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] -- Kubeadm: fix a bug where external credentials in an existing admin.conf prevented the CA certificate to be written in the cluster-info ConfigMap. ([#98882](https://github.com/kubernetes/kubernetes/pull/98882), [@kvaps](https://github.com/kvaps)) [SIG Cluster Lifecycle] -- Kubeadm: get k8s CI version markers from k8s infra bucket ([#98836](https://github.com/kubernetes/kubernetes/pull/98836), [@hasheddan](https://github.com/hasheddan)) [SIG Cluster Lifecycle and Release] -- Kubeadm: skip validating pod subnet against node-cidr-mask when allocate-node-cidrs is set to be false ([#98984](https://github.com/kubernetes/kubernetes/pull/98984), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle] -- Kubectl logs: `--ignore-errors` is now honored by all containers, maintaining consistency with parallelConsumeRequest behavior. ([#97686](https://github.com/kubernetes/kubernetes/pull/97686), [@wzshiming](https://github.com/wzshiming)) -- Kubectl-convert: Fix `no kind "Ingress" is registered for version` error ([#97754](https://github.com/kubernetes/kubernetes/pull/97754), [@wzshiming](https://github.com/wzshiming)) -- Kubectl: Fixed panic when describing an ingress backend without an API Group ([#100505](https://github.com/kubernetes/kubernetes/pull/100505), [@lauchokyip](https://github.com/lauchokyip)) [SIG CLI] -- Kubelet now cleans up orphaned volume directories automatically ([#95301](https://github.com/kubernetes/kubernetes/pull/95301), [@lorenz](https://github.com/lorenz)) [SIG Node and Storage] -- Kubelet.exe on Windows now checks that the process running as administrator and the executing user account is listed in the built-in administrators group. This is the equivalent to checking the process is running as uid 0. ([#96616](https://github.com/kubernetes/kubernetes/pull/96616), [@perithompson](https://github.com/perithompson)) [SIG Node and Windows] -- Kubelet: Fix kubelet from panic after getting the wrong signal ([#98200](https://github.com/kubernetes/kubernetes/pull/98200), [@wzshiming](https://github.com/wzshiming)) [SIG Node] -- Kubelet: Fix repeatedly acquiring the inhibit lock ([#98088](https://github.com/kubernetes/kubernetes/pull/98088), [@wzshiming](https://github.com/wzshiming)) [SIG Node] -- Kubelet: Fixed the bug of getting the number of cpu when the number of cpu logical processors is more than 64 in windows ([#97378](https://github.com/kubernetes/kubernetes/pull/97378), [@hwdef](https://github.com/hwdef)) [SIG Node and Windows] -- Limits lease to have 1000 maximum attached objects. ([#98257](https://github.com/kubernetes/kubernetes/pull/98257), [@lingsamuel](https://github.com/lingsamuel)) -- Mitigate CVE-2020-8555 for kube-up using GCE by preventing local loopback folume hosts. ([#97934](https://github.com/kubernetes/kubernetes/pull/97934), [@mattcary](https://github.com/mattcary)) [SIG Cloud Provider and Storage] -- On single-stack configured (IPv4 or IPv6, but not both) clusters, Services which are both headless (no clusterIP) and selectorless (empty or undefined selector) will report `ipFamilyPolicy RequireDualStack` and will have entries in `ipFamilies[]` for both IPv4 and IPv6. This is a change from alpha, but does not have any impact on the manually-specified Endpoints and EndpointSlices for the Service. ([#99555](https://github.com/kubernetes/kubernetes/pull/99555), [@thockin](https://github.com/thockin)) [SIG Apps and Network] -- Performance regression #97685 has been fixed. ([#97860](https://github.com/kubernetes/kubernetes/pull/97860), [@MikeSpreitzer](https://github.com/MikeSpreitzer)) [SIG API Machinery] -- Pod Log stats for windows now reports metrics ([#99221](https://github.com/kubernetes/kubernetes/pull/99221), [@jsturtevant](https://github.com/jsturtevant)) [SIG Node, Storage, Testing and Windows] -- Pod status updates faster when reacting on probe results. The first readiness probe will be called faster when startup probes succeeded, which will make Pod status as ready faster. ([#98376](https://github.com/kubernetes/kubernetes/pull/98376), [@matthyx](https://github.com/matthyx)) -- Readjust `kubelet_containers_per_pod_count` buckets to only show metrics greater than 1. ([#98169](https://github.com/kubernetes/kubernetes/pull/98169), [@wawa0210](https://github.com/wawa0210)) -- Remove CSI topology from migrated in-tree gcepd volume. ([#97823](https://github.com/kubernetes/kubernetes/pull/97823), [@Jiawei0227](https://github.com/Jiawei0227)) [SIG Cloud Provider and Storage] -- Requests with invalid timeout parameters in the request URL now appear in the audit log correctly. ([#96901](https://github.com/kubernetes/kubernetes/pull/96901), [@tkashem](https://github.com/tkashem)) [SIG API Machinery and Testing] -- Resolve a "concurrent map read and map write" crashing error in the kubelet ([#95111](https://github.com/kubernetes/kubernetes/pull/95111), [@choury](https://github.com/choury)) [SIG Node] -- Resolves spurious `Failed to list *v1.Secret` or `Failed to list *v1.ConfigMap` messages in kubelet logs. ([#99538](https://github.com/kubernetes/kubernetes/pull/99538), [@liggitt](https://github.com/liggitt)) [SIG Auth and Node] -- ResourceQuota of an entity now inclusively calculate Pod overhead ([#99600](https://github.com/kubernetes/kubernetes/pull/99600), [@gjkim42](https://github.com/gjkim42)) -- Return zero time (midnight on Jan. 1, 1970) instead of negative number when reporting startedAt and finishedAt of the not started or a running Pod when using `dockershim` as a runtime. ([#99585](https://github.com/kubernetes/kubernetes/pull/99585), [@Iceber](https://github.com/Iceber)) -- Reverts breaking change to inline AzureFile volumes; referenced secrets are now searched for in the same namespace as the pod as in previous releases. ([#100563](https://github.com/kubernetes/kubernetes/pull/100563), [@msau42](https://github.com/msau42)) -- Scores from InterPodAffinity have stronger differentiation. ([#98096](https://github.com/kubernetes/kubernetes/pull/98096), [@leileiwan](https://github.com/leileiwan)) [SIG Scheduling] -- Specifying the KUBE_TEST_REPO environment variable when e2e tests are executed will instruct the test infrastructure to load that image from a location within the specified repo, using a predefined pattern. ([#93510](https://github.com/kubernetes/kubernetes/pull/93510), [@smarterclayton](https://github.com/smarterclayton)) [SIG Testing] -- Static pods will be deleted gracefully. ([#98103](https://github.com/kubernetes/kubernetes/pull/98103), [@gjkim42](https://github.com/gjkim42)) [SIG Node] -- Sync node status during kubelet node shutdown. - Adds an pod admission handler that rejects new pods when the node is in progress of shutting down. ([#98005](https://github.com/kubernetes/kubernetes/pull/98005), [@wzshiming](https://github.com/wzshiming)) [SIG Node] -- The calculation of pod UIDs for static pods has changed to ensure each static pod gets a unique value - this will cause all static pod containers to be recreated/restarted if an in-place kubelet upgrade from 1.20 to 1.21 is performed. Note that draining pods before upgrading the kubelet across minor versions is the supported upgrade path. ([#87461](https://github.com/kubernetes/kubernetes/pull/87461), [@bboreham](https://github.com/bboreham)) [SIG Node] -- The maximum number of ports allowed in EndpointSlices has been increased from 100 to 20,000 ([#99795](https://github.com/kubernetes/kubernetes/pull/99795), [@robscott](https://github.com/robscott)) [SIG Network] -- Truncates a message if it hits the `NoteLengthLimit` when the scheduler records an event for the pod that indicates the pod has failed to schedule. ([#98715](https://github.com/kubernetes/kubernetes/pull/98715), [@carlory](https://github.com/carlory)) -- Updated k8s.gcr.io/ingress-gce-404-server-with-metrics-amd64 to a version that serves /metrics endpoint on a non-default port. ([#97621](https://github.com/kubernetes/kubernetes/pull/97621), [@vbannai](https://github.com/vbannai)) [SIG Cloud Provider] -- Updates the commands ` - - kubectl kustomize {arg} - - kubectl apply -k {arg} - `to use same code as kustomize CLI [v4.0.5](https://github.com/kubernetes-sigs/kustomize/releases/tag/kustomize%2Fv4.0.5) ([#98946](https://github.com/kubernetes/kubernetes/pull/98946), [@monopole](https://github.com/monopole)) -- Use force unmount for NFS volumes if regular mount fails after 1 minute timeout ([#96844](https://github.com/kubernetes/kubernetes/pull/96844), [@gnufied](https://github.com/gnufied)) [SIG Storage] -- Use network.Interface.VirtualMachine.ID to get the binded VM - Skip standalone VM when reconciling LoadBalancer ([#97635](https://github.com/kubernetes/kubernetes/pull/97635), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider] -- Using exec auth plugins with kubectl no longer results in warnings about constructing many client instances from the same exec auth config. ([#97857](https://github.com/kubernetes/kubernetes/pull/97857), [@liggitt](https://github.com/liggitt)) [SIG API Machinery and Auth] -- When a CNI plugin returns dual-stack pod IPs, kubelet will now try to respect the - "primary IP family" of the cluster by picking a primary pod IP of the same family - as the (primary) node IP, rather than assuming that the CNI plugin returned the IPs - in the order the administrator wanted (since some CNI plugins don't allow - configuring this). ([#97979](https://github.com/kubernetes/kubernetes/pull/97979), [@danwinship](https://github.com/danwinship)) [SIG Network and Node] -- When dynamically provisioning Azure File volumes for a premium account, the requested size will be set to 100GB if the request is initially lower than this value to accommodate Azure File requirements. ([#99122](https://github.com/kubernetes/kubernetes/pull/99122), [@huffmanca](https://github.com/huffmanca)) [SIG Cloud Provider and Storage] -- When using `Containerd` on Windows, the `C:\Windows\System32\drivers\etc\hosts` file will now be managed by kubelet. ([#83730](https://github.com/kubernetes/kubernetes/pull/83730), [@claudiubelu](https://github.com/claudiubelu)) -- `VolumeBindingArgs` now allow `BindTimeoutSeconds` to be set as zero, while the value zero indicates no waiting for the checking of volume binding operation. ([#99835](https://github.com/kubernetes/kubernetes/pull/99835), [@chendave](https://github.com/chendave)) [SIG Scheduling and Storage] -- `kubectl exec` and `kubectl attach` now honor the `--quiet` flag which suppresses output from the local binary that could be confused by a script with the remote command output (all non-failure output is hidden). In addition, print inline with exec and attach the list of alternate containers when we default to the first spec.container. ([#99004](https://github.com/kubernetes/kubernetes/pull/99004), [@smarterclayton](https://github.com/smarterclayton)) [SIG CLI] - -### 기타 (정리 또는 플레이크(flake)) - -- APIs for kubelet annotations and labels from `k8s.io/kubernetes/pkg/kubelet/apis` are now moved under `k8s.io/kubelet/pkg/apis/` ([#98931](https://github.com/kubernetes/kubernetes/pull/98931), [@michaelbeaumont](https://github.com/michaelbeaumont)) -- Apiserver_request_duration_seconds is promoted to stable status. ([#99925](https://github.com/kubernetes/kubernetes/pull/99925), [@logicalhan](https://github.com/logicalhan)) [SIG API Machinery, Instrumentation and Testing] -- Bump github.com/Azure/go-autorest/autorest to v0.11.12 ([#97033](https://github.com/kubernetes/kubernetes/pull/97033), [@patrickshan](https://github.com/patrickshan)) [SIG API Machinery, CLI, Cloud Provider and Cluster Lifecycle] -- Clients required to use go1.15.8+ or go1.16+ if kube-apiserver has the goaway feature enabled to avoid unexpected data race condition. ([#98809](https://github.com/kubernetes/kubernetes/pull/98809), [@answer1991](https://github.com/answer1991)) -- Delete deprecated `service.beta.kubernetes.io/azure-load-balancer-mixed-protocols` mixed procotol annotation in favor of the MixedProtocolLBService feature ([#97096](https://github.com/kubernetes/kubernetes/pull/97096), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider] -- EndpointSlice generation is now incremented when labels change. ([#99750](https://github.com/kubernetes/kubernetes/pull/99750), [@robscott](https://github.com/robscott)) [SIG Network] -- Featuregate AllowInsecureBackendProxy graduates to GA and unconditionally enabled. ([#99658](https://github.com/kubernetes/kubernetes/pull/99658), [@deads2k](https://github.com/deads2k)) -- Increase timeout for pod lifecycle test to reach pod status=ready ([#96691](https://github.com/kubernetes/kubernetes/pull/96691), [@hh](https://github.com/hh)) -- Increased `CSINodeIDMaxLength` from 128 bytes to 192 bytes. ([#98753](https://github.com/kubernetes/kubernetes/pull/98753), [@Jiawei0227](https://github.com/Jiawei0227)) -- Kube-apiserver: The OIDC authenticator no longer waits 10 seconds before attempting to fetch the metadata required to verify tokens. ([#97693](https://github.com/kubernetes/kubernetes/pull/97693), [@enj](https://github.com/enj)) [SIG API Machinery and Auth] -- Kube-proxy: Traffic from the cluster directed to ExternalIPs is always sent directly to the Service. ([#96296](https://github.com/kubernetes/kubernetes/pull/96296), [@aojea](https://github.com/aojea)) [SIG Network and Testing] -- Kubeadm: change the default image repository for CI images from 'gcr.io/kubernetes-ci-images' to 'gcr.io/k8s-staging-ci-images' ([#97087](https://github.com/kubernetes/kubernetes/pull/97087), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle] -- Kubectl: The deprecated `kubectl alpha debug` command is removed. Use `kubectl debug` instead. ([#98111](https://github.com/kubernetes/kubernetes/pull/98111), [@pandaamanda](https://github.com/pandaamanda)) [SIG CLI] -- Kubelet command line flags related to dockershim are now showing deprecation message as they will be removed along with dockershim in future release. ([#98730](https://github.com/kubernetes/kubernetes/pull/98730), [@dims](https://github.com/dims)) -- Official support to build kubernetes with docker-machine / remote docker is removed. This change does not affect building kubernetes with docker locally. ([#97618](https://github.com/kubernetes/kubernetes/pull/97618), [@jherrera123](https://github.com/jherrera123)) [SIG Release and Testing] -- Process start time on Windows now uses current process information ([#97491](https://github.com/kubernetes/kubernetes/pull/97491), [@jsturtevant](https://github.com/jsturtevant)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Windows] -- Resolves flakes in the Ingress conformance tests due to conflicts with controllers updating the Ingress object ([#98430](https://github.com/kubernetes/kubernetes/pull/98430), [@liggitt](https://github.com/liggitt)) [SIG Network and Testing] -- The `AttachVolumeLimit` feature gate (GA since v1.17) has been removed and now unconditionally enabled. ([#96539](https://github.com/kubernetes/kubernetes/pull/96539), [@ialidzhikov](https://github.com/ialidzhikov)) -- The `CSINodeInfo` feature gate that is GA since v1.17 is unconditionally enabled, and can no longer be specified via the `--feature-gates` argument. ([#96561](https://github.com/kubernetes/kubernetes/pull/96561), [@ialidzhikov](https://github.com/ialidzhikov)) [SIG Apps, Auth, Scheduling, Storage and Testing] -- The `apiserver_request_total` metric is promoted to stable status and no longer has a content-type dimensions, so any alerts/charts which presume the existence of this will fail. This is however, unlikely to be the case since it was effectively an unbounded dimension in the first place. ([#99788](https://github.com/kubernetes/kubernetes/pull/99788), [@logicalhan](https://github.com/logicalhan)) -- The default delegating authorization options now allow unauthenticated access to healthz, readyz, and livez. A system:masters user connecting to an authz delegator will not perform an authz check. ([#98325](https://github.com/kubernetes/kubernetes/pull/98325), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, Auth, Cloud Provider and Scheduling] -- The deprecated feature gates `CSIDriverRegistry`, `BlockVolume` and `CSIBlockVolume` are now unconditionally enabled and can no longer be specified in component invocations. ([#98021](https://github.com/kubernetes/kubernetes/pull/98021), [@gavinfish](https://github.com/gavinfish)) [SIG Storage] -- The deprecated feature gates `RotateKubeletClientCertificate`, `AttachVolumeLimit`, `VolumePVCDataSource` and `EvenPodsSpread` are now unconditionally enabled and can no longer be specified in component invocations. ([#97306](https://github.com/kubernetes/kubernetes/pull/97306), [@gavinfish](https://github.com/gavinfish)) [SIG Node, Scheduling and Storage] -- The e2e suite can be instructed not to wait for pods in kube-system to be ready or for all nodes to be ready by passing `--allowed-not-ready-nodes=-1` when invoking the e2e.test program. This allows callers to run subsets of the e2e suite in scenarios other than perfectly healthy clusters. ([#98781](https://github.com/kubernetes/kubernetes/pull/98781), [@smarterclayton](https://github.com/smarterclayton)) [SIG Testing] -- The feature gates `WindowsGMSA` and `WindowsRunAsUserName` that are GA since v1.18 are now removed. ([#96531](https://github.com/kubernetes/kubernetes/pull/96531), [@ialidzhikov](https://github.com/ialidzhikov)) [SIG Node and Windows] -- The new `-gce-zones` flag on the `e2e.test` binary instructs tests that check for information about how the cluster interacts with the cloud to limit their queries to the provided zone list. If not specified, the current behavior of asking the cloud provider for all available zones in multi zone clusters is preserved. ([#98787](https://github.com/kubernetes/kubernetes/pull/98787), [@smarterclayton](https://github.com/smarterclayton)) [SIG API Machinery, Cluster Lifecycle and Testing] -- Update cri-tools to [v1.20.0](https://github.com/kubernetes-sigs/cri-tools/releases/tag/v1.20.0) ([#97967](https://github.com/kubernetes/kubernetes/pull/97967), [@rajibmitra](https://github.com/rajibmitra)) [SIG Cloud Provider] -- Windows nodes on GCE will take longer to start due to dependencies installed at node creation time. ([#98284](https://github.com/kubernetes/kubernetes/pull/98284), [@pjh](https://github.com/pjh)) [SIG Cloud Provider] -- `apiserver_storage_objects` (a newer version of `etcd_object_counts`) is promoted and marked as stable. ([#100082](https://github.com/kubernetes/kubernetes/pull/100082), [@logicalhan](https://github.com/logicalhan)) - -### 분류되지 않음 - -- GCE L4 Loadbalancers now handle > 5 ports in service spec correctly. ([#99595](https://github.com/kubernetes/kubernetes/pull/99595), [@prameshj](https://github.com/prameshj)) [SIG Cloud Provider] -- The DownwardAPIHugePages feature is beta. Users may use the feature if all workers in their cluster are min 1.20 version. The feature will be enabled by default in all installations in 1.22. ([#99610](https://github.com/kubernetes/kubernetes/pull/99610), [@derekwaynecarr](https://github.com/derekwaynecarr)) [SIG Node] - -## 의존성 - -### 추가 -- github.com/go-errors/errors: [v1.0.1](https://github.com/go-errors/errors/tree/v1.0.1) -- github.com/gobuffalo/here: [v0.6.0](https://github.com/gobuffalo/here/tree/v0.6.0) -- github.com/google/shlex: [e7afc7f](https://github.com/google/shlex/tree/e7afc7f) -- github.com/markbates/pkger: [v0.17.1](https://github.com/markbates/pkger/tree/v0.17.1) -- github.com/moby/spdystream: [v0.2.0](https://github.com/moby/spdystream/tree/v0.2.0) -- github.com/monochromegane/go-gitignore: [205db1a](https://github.com/monochromegane/go-gitignore/tree/205db1a) -- github.com/niemeyer/pretty: [a10e7ca](https://github.com/niemeyer/pretty/tree/a10e7ca) -- github.com/xlab/treeprint: [a009c39](https://github.com/xlab/treeprint/tree/a009c39) -- go.starlark.net: 8dd3e2e -- golang.org/x/term: 6a3ed07 -- sigs.k8s.io/kustomize/api: v0.8.5 -- sigs.k8s.io/kustomize/cmd/config: v0.9.7 -- sigs.k8s.io/kustomize/kustomize/v4: v4.0.5 -- sigs.k8s.io/kustomize/kyaml: v0.10.15 - -### 변경 -- dmitri.shuralyov.com/gpu/mtl: 666a987 → 28db891 -- github.com/Azure/go-autorest/autorest: [v0.11.1 → v0.11.12](https://github.com/Azure/go-autorest/autorest/compare/v0.11.1...v0.11.12) -- github.com/NYTimes/gziphandler: [56545f4 → v1.1.1](https://github.com/NYTimes/gziphandler/compare/56545f4...v1.1.1) -- github.com/cilium/ebpf: [1c8d4c9 → v0.2.0](https://github.com/cilium/ebpf/compare/1c8d4c9...v0.2.0) -- github.com/container-storage-interface/spec: [v1.2.0 → v1.3.0](https://github.com/container-storage-interface/spec/compare/v1.2.0...v1.3.0) -- github.com/containerd/console: [v1.0.0 → v1.0.1](https://github.com/containerd/console/compare/v1.0.0...v1.0.1) -- github.com/containerd/containerd: [v1.4.1 → v1.4.4](https://github.com/containerd/containerd/compare/v1.4.1...v1.4.4) -- github.com/coredns/corefile-migration: [v1.0.10 → v1.0.11](https://github.com/coredns/corefile-migration/compare/v1.0.10...v1.0.11) -- github.com/creack/pty: [v1.1.7 → v1.1.11](https://github.com/creack/pty/compare/v1.1.7...v1.1.11) -- github.com/docker/docker: [bd33bbf → v20.10.2+incompatible](https://github.com/docker/docker/compare/bd33bbf...v20.10.2) -- github.com/go-logr/logr: [v0.2.0 → v0.4.0](https://github.com/go-logr/logr/compare/v0.2.0...v0.4.0) -- github.com/go-openapi/spec: [v0.19.3 → v0.19.5](https://github.com/go-openapi/spec/compare/v0.19.3...v0.19.5) -- github.com/go-openapi/strfmt: [v0.19.3 → v0.19.5](https://github.com/go-openapi/strfmt/compare/v0.19.3...v0.19.5) -- github.com/go-openapi/validate: [v0.19.5 → v0.19.8](https://github.com/go-openapi/validate/compare/v0.19.5...v0.19.8) -- github.com/gogo/protobuf: [v1.3.1 → v1.3.2](https://github.com/gogo/protobuf/compare/v1.3.1...v1.3.2) -- github.com/golang/mock: [v1.4.1 → v1.4.4](https://github.com/golang/mock/compare/v1.4.1...v1.4.4) -- github.com/google/cadvisor: [v0.38.5 → v0.39.0](https://github.com/google/cadvisor/compare/v0.38.5...v0.39.0) -- github.com/heketi/heketi: [c2e2a4a → v10.2.0+incompatible](https://github.com/heketi/heketi/compare/c2e2a4a...v10.2.0) -- github.com/kisielk/errcheck: [v1.2.0 → v1.5.0](https://github.com/kisielk/errcheck/compare/v1.2.0...v1.5.0) -- github.com/konsorten/go-windows-terminal-sequences: [v1.0.3 → v1.0.2](https://github.com/konsorten/go-windows-terminal-sequences/compare/v1.0.3...v1.0.2) -- github.com/kr/text: [v0.1.0 → v0.2.0](https://github.com/kr/text/compare/v0.1.0...v0.2.0) -- github.com/mattn/go-runewidth: [v0.0.2 → v0.0.7](https://github.com/mattn/go-runewidth/compare/v0.0.2...v0.0.7) -- github.com/miekg/dns: [v1.1.4 → v1.1.35](https://github.com/miekg/dns/compare/v1.1.4...v1.1.35) -- github.com/moby/sys/mountinfo: [v0.1.3 → v0.4.0](https://github.com/moby/sys/mountinfo/compare/v0.1.3...v0.4.0) -- github.com/moby/term: [672ec06 → df9cb8a](https://github.com/moby/term/compare/672ec06...df9cb8a) -- github.com/mrunalp/fileutils: [abd8a0e → v0.5.0](https://github.com/mrunalp/fileutils/compare/abd8a0e...v0.5.0) -- github.com/olekukonko/tablewriter: [a0225b3 → v0.0.4](https://github.com/olekukonko/tablewriter/compare/a0225b3...v0.0.4) -- github.com/opencontainers/runc: [v1.0.0-rc92 → v1.0.0-rc93](https://github.com/opencontainers/runc/compare/v1.0.0-rc92...v1.0.0-rc93) -- github.com/opencontainers/runtime-spec: [4d89ac9 → e6143ca](https://github.com/opencontainers/runtime-spec/compare/4d89ac9...e6143ca) -- github.com/opencontainers/selinux: [v1.6.0 → v1.8.0](https://github.com/opencontainers/selinux/compare/v1.6.0...v1.8.0) -- github.com/sergi/go-diff: [v1.0.0 → v1.1.0](https://github.com/sergi/go-diff/compare/v1.0.0...v1.1.0) -- github.com/sirupsen/logrus: [v1.6.0 → v1.7.0](https://github.com/sirupsen/logrus/compare/v1.6.0...v1.7.0) -- github.com/syndtr/gocapability: [d983527 → 42c35b4](https://github.com/syndtr/gocapability/compare/d983527...42c35b4) -- github.com/willf/bitset: [d5bec33 → v1.1.11](https://github.com/willf/bitset/compare/d5bec33...v1.1.11) -- github.com/yuin/goldmark: [v1.1.27 → v1.2.1](https://github.com/yuin/goldmark/compare/v1.1.27...v1.2.1) -- golang.org/x/crypto: 7f63de1 → 5ea612d -- golang.org/x/exp: 6cc2880 → 85be41e -- golang.org/x/mobile: d2bd2a2 → e6ae53a -- golang.org/x/mod: v0.3.0 → ce943fd -- golang.org/x/net: 69a7880 → 3d97a24 -- golang.org/x/sync: cd5d95a → 67f06af -- golang.org/x/sys: 5cba982 → a50acf3 -- golang.org/x/time: 3af7569 → f8bda1e -- golang.org/x/tools: c1934b7 → v0.1.0 -- gopkg.in/check.v1: 41f04d3 → 8fa4692 -- gopkg.in/yaml.v2: v2.2.8 → v2.4.0 -- gotest.tools/v3: v3.0.2 → v3.0.3 -- k8s.io/gengo: 83324d8 → b6c5ce2 -- k8s.io/klog/v2: v2.4.0 → v2.8.0 -- k8s.io/kube-openapi: d219536 → 591a79e -- k8s.io/system-validators: v1.2.0 → v1.4.0 -- sigs.k8s.io/apiserver-network-proxy/konnectivity-client: v0.0.14 → v0.0.15 -- sigs.k8s.io/structured-merge-diff/v4: v4.0.2 → v4.1.0 - -### 제거 -- github.com/codegangsta/negroni: [v1.0.0](https://github.com/codegangsta/negroni/tree/v1.0.0) -- github.com/docker/spdystream: [449fdfc](https://github.com/docker/spdystream/tree/449fdfc) -- github.com/golangplus/bytes: [45c989f](https://github.com/golangplus/bytes/tree/45c989f) -- github.com/golangplus/fmt: [2a5d6d7](https://github.com/golangplus/fmt/tree/2a5d6d7) -- github.com/gorilla/context: [v1.1.1](https://github.com/gorilla/context/tree/v1.1.1) -- github.com/kr/pty: [v1.1.5](https://github.com/kr/pty/tree/v1.1.5) -- rsc.io/quote/v3: v3.1.0 -- rsc.io/sampler: v1.3.0 -- sigs.k8s.io/kustomize: v2.0.3+incompatible - - - -# v1.21.0-rc.0 - - -## Downloads for v1.21.0-rc.0 - -### Source Code - -filename | sha512 hash --------- | ----------- -[kubernetes.tar.gz](https://dl.k8s.io/v1.21.0-rc.0/kubernetes.tar.gz) | ef53a41955d6f8a8d2a94636af98b55d633fb8a5081517559039e019b3dd65c9d10d4e7fa297ab88a7865d772f3eecf72e7b0eeba5e87accb4000c91da33e148 -[kubernetes-src.tar.gz](https://dl.k8s.io/v1.21.0-rc.0/kubernetes-src.tar.gz) | 9335a01b50d351776d3b8d00c07a5233844c51d307e361fa7e55a0620c1cb8b699e43eacf45ae9cafd8cbc44752e6987450c528a5bede8204706b7673000b5fc - -### Client binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.21.0-rc.0/kubernetes-client-darwin-amd64.tar.gz) | 964135e43234cee275c452f5f06fb6d2bcd3cff3211a0d50fa35fff1cc4446bc5a0ac5125405dadcfb6596cb152afe29fabf7aad5b35b100e1288db890b70f8e -[kubernetes-client-darwin-arm64.tar.gz](https://dl.k8s.io/v1.21.0-rc.0/kubernetes-client-darwin-arm64.tar.gz) | 50d782abaa4ded5e706b3192d87effa953ceabbd7d91e3d48b0c1fa2206a1963a909c14b923560f5d09cac2c7392edc5f38a13fbf1e9a40bc94e3afe8de10622 -[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.21.0-rc.0/kubernetes-client-linux-386.tar.gz) | 72af5562f24184a2d7c27f95fa260470da979fbdcacce39a372f8f3add2991d7af8bc78f4e1dbe7a0f97e3f559b149b72a51491d3b13008da81872ee50f02f37 -[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.21.0-rc.0/kubernetes-client-linux-amd64.tar.gz) | 1eddb8f6b51e005bc6f7b519d036cbe3d2f6d97dbf7d212dd933fb56354c29f222d050519115a9bcf94555aef095db7cf763469e47bb4ae3c6c07f97edf437cb -[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.21.0-rc.0/kubernetes-client-linux-arm.tar.gz) | 670f8ca60ea3cf0bb3262a772715e0ea735fccda6a92f3186299361dc455b304ae177d4017e0b67bbfa4a95e36f4cc3f7eb335e2a5130c93ac3fba2aff4519bf -[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.21.0-rc.0/kubernetes-client-linux-arm64.tar.gz) | a69a47907cff138ba393d8c87044fd95d97f3ca8f35d301b50742e2801ad7c229d99d6667971091f65825eb51854d585be0dd7421670110b1aa567e67e7ab4b3 -[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.21.0-rc.0/kubernetes-client-linux-ppc64le.tar.gz) | b929feade94b71c81908abdcd4343b1e1e20098fd65e10d4d02585ad649d292d06f52c7ddc349efa188ce5b093e703c7aa9582c6ae5a69699adb87bbf5350243 -[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.21.0-rc.0/kubernetes-client-linux-s390x.tar.gz) | 899d1470e412282cf289d8e24806d1a08c62ec0151f345ae3c9e497cc7bc0feab76498de4dd897d6adcdfa0c422e6b1a37e25d928669030f53457fd69d6e7df7 -[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.21.0-rc.0/kubernetes-client-windows-386.tar.gz) | 9f0bc90a269eabd06fe4f637b5172a3a6a7d3de26de0d66504c2e1f2093083c584ea39031db6075a7da7a86b98c48bed25aa88d4ac09060b38692c6a5b637078 -[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.21.0-rc.0/kubernetes-client-windows-amd64.tar.gz) | 05c8cc10188a1294b0d51d052942742a9b26411a08ec73494bf0e728a8a167e0a7863bdfc8864e76a371b584380098381805341e18b4b283b5d0cf298d5f7c7c - -### Server binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.21.0-rc.0/kubernetes-server-linux-amd64.tar.gz) | 355f278728ef7ac7eb2f5568c99c1429543c6302bbd0ed3bd0378c08116075e56ae850a49241313f078e2392702672ec6c9b70c8d97b4f2f5f4bee36828a63ba -[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.21.0-rc.0/kubernetes-server-linux-arm.tar.gz) | 9ac02c2825e2fd4e92f0c0f67180c67c24e32841ccbabc82284bf6293727ffecfae65e8a42b527c2a7ca482752384928eb65c2a1706144ae7819a6b3a1ab291c -[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.21.0-rc.0/kubernetes-server-linux-arm64.tar.gz) | eb412453da03c82a9248412c8ccf4d4baa1fbfa81edd8d4f81d28969b40a3727e18934accc68f643d253446c58ffd2623292402495480b3d4b2a837b5318b957 -[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.21.0-rc.0/kubernetes-server-linux-ppc64le.tar.gz) | 07da2812c35bbc427ee5b4a0b601c3ae271e0d50ab0dd4c5c25399f43506fa2a187642eb9d4d2085df7b90264d48ea2f31088af87d9efa7eb2e87f91e1fdbde4 -[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.21.0-rc.0/kubernetes-server-linux-s390x.tar.gz) | 3b79442a3d6e389c4ff105922a8e49994c0b6c088d2c501bd8c78d9f9e814902f5bb72c8f9c89380b750fda9b3a336759b9b68f11d70bef4f0e984564a95c29e - -### Node binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.21.0-rc.0/kubernetes-node-linux-amd64.tar.gz) | f12edf1faf5f07de1ebc5a8626601c12927902e10aca3f11e398637382fdf55365dbd9a0ef38858553fb7569495ae2cf68f155dd2e49b85b27d76fb599bb92e4 -[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.21.0-rc.0/kubernetes-node-linux-arm.tar.gz) | 4fba8fc4e2102f07fb778aab597ec7231ea65c35e1aa618fe98b707b64a931237bd842c173e9120326e4d9deb983bb3917176762bba2212612bbc09d6e2105c4 -[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.21.0-rc.0/kubernetes-node-linux-arm64.tar.gz) | a2e1be5459a8346839970faf4e7ebdb8ab9f3273e02babf1f3199b06bdb67434a2d18fcd1628cf1b989756e99d8dad6624a455b9db11d50f51f509f4df5c27da -[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.21.0-rc.0/kubernetes-node-linux-ppc64le.tar.gz) | 16d2c1cc295474fc49fe9a827ddd73e81bdd6b76af7074987b90250023f99b6d70bf474e204c7d556802111984fcb3a330740b150bdc7970d0e3634eb94a1665 -[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.21.0-rc.0/kubernetes-node-linux-s390x.tar.gz) | 9dc6faa6cd007b13dfce703f3e271f80adcc4e029c90a4a9b4f2f143b9756f2893f8af3d7c2cf813f2bd6731cffd87d15d4229456c1685939f65bf467820ec6e -[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.21.0-rc.0/kubernetes-node-windows-amd64.tar.gz) | f8bac2974c9142bfb80cd5eadeda79f79f27b78899a4e6e71809b795c708824ba442be83fdbadb98e01c3823dd8350776358258a205e851ed045572923cacba7 - -## Changelog since v1.21.0-beta.1 - -## Urgent Upgrade Notes - -### (No, really, you MUST read this before you upgrade) - - - Migrated pkg/kubelet/cm/cpuset/cpuset.go to structured logging. Exit code changed from 255 to 1. ([#100007](https://github.com/kubernetes/kubernetes/pull/100007), [@utsavoza](https://github.com/utsavoza)) [SIG Instrumentation and Node] - -## Changes by Kind - -### API Change - -- Add Probe-level terminationGracePeriodSeconds field ([#99375](https://github.com/kubernetes/kubernetes/pull/99375), [@ehashman](https://github.com/ehashman)) [SIG API Machinery, Apps, Node and Testing] -- CSIServiceAccountToken is Beta now ([#99298](https://github.com/kubernetes/kubernetes/pull/99298), [@zshihang](https://github.com/zshihang)) [SIG Auth, Storage and Testing] -- Discovery.k8s.io/v1beta1 EndpointSlices are deprecated in favor of discovery.k8s.io/v1, and will no longer be served in Kubernetes v1.25. ([#100472](https://github.com/kubernetes/kubernetes/pull/100472), [@liggitt](https://github.com/liggitt)) [SIG Network] -- FieldManager no longer owns fields that get reset before the object is persisted (e.g. "status wiping"). ([#99661](https://github.com/kubernetes/kubernetes/pull/99661), [@kevindelgado](https://github.com/kevindelgado)) [SIG API Machinery, Auth and Testing] -- Generic ephemeral volumes are beta. ([#99643](https://github.com/kubernetes/kubernetes/pull/99643), [@pohly](https://github.com/pohly)) [SIG API Machinery, Apps, Auth, CLI, Node, Storage and Testing] -- Implement the GetAvailableResources in the podresources API. ([#95734](https://github.com/kubernetes/kubernetes/pull/95734), [@fromanirh](https://github.com/fromanirh)) [SIG Instrumentation, Node and Testing] -- The Endpoints controller will now set the `endpoints.kubernetes.io/over-capacity` annotation to "warning" when an Endpoints resource contains more than 1000 addresses. In a future release, the controller will truncate Endpoints that exceed this limit. The EndpointSlice API can be used to support significantly larger number of addresses. ([#99975](https://github.com/kubernetes/kubernetes/pull/99975), [@robscott](https://github.com/robscott)) [SIG Apps and Network] -- The PodDisruptionBudget API has been promoted to policy/v1 with no schema changes. The only functional change is that an empty selector (`{}`) written to a policy/v1 PodDisruptionBudget now selects all pods in the namespace. The behavior of the policy/v1beta1 API remains unchanged. The policy/v1beta1 PodDisruptionBudget API is deprecated and will no longer be served in 1.25+. ([#99290](https://github.com/kubernetes/kubernetes/pull/99290), [@mortent](https://github.com/mortent)) [SIG API Machinery, Apps, Auth, Autoscaling, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation, Scheduling and Testing] -- Topology Aware Hints are now available in alpha and can be enabled with the `TopologyAwareHints` feature gate. ([#99522](https://github.com/kubernetes/kubernetes/pull/99522), [@robscott](https://github.com/robscott)) [SIG API Machinery, Apps, Auth, Instrumentation, Network and Testing] - -### Feature - -- Add e2e test to validate performance metrics of volume lifecycle operations ([#94334](https://github.com/kubernetes/kubernetes/pull/94334), [@RaunakShah](https://github.com/RaunakShah)) [SIG Storage and Testing] -- EmptyDir memory backed volumes are sized as the the minimum of pod allocatable memory on a host and an optional explicit user provided value. ([#100319](https://github.com/kubernetes/kubernetes/pull/100319), [@derekwaynecarr](https://github.com/derekwaynecarr)) [SIG Node] -- Enables Kubelet to check volume condition and log events to corresponding pods. ([#99284](https://github.com/kubernetes/kubernetes/pull/99284), [@fengzixu](https://github.com/fengzixu)) [SIG Apps, Instrumentation, Node and Storage] -- Introduce a churn operator to scheduler perf testing framework. ([#98900](https://github.com/kubernetes/kubernetes/pull/98900), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling and Testing] -- Kubernetes is now built with Golang 1.16.1 ([#100106](https://github.com/kubernetes/kubernetes/pull/100106), [@justaugustus](https://github.com/justaugustus)) [SIG Cloud Provider, Instrumentation, Release and Testing] -- Migrated pkg/kubelet/cm/devicemanager to structured logging ([#99976](https://github.com/kubernetes/kubernetes/pull/99976), [@knabben](https://github.com/knabben)) [SIG Instrumentation and Node] -- Migrated pkg/kubelet/cm/memorymanager to structured logging ([#99974](https://github.com/kubernetes/kubernetes/pull/99974), [@knabben](https://github.com/knabben)) [SIG Instrumentation and Node] -- Migrated pkg/kubelet/cm/topologymanager to structure logging ([#99969](https://github.com/kubernetes/kubernetes/pull/99969), [@knabben](https://github.com/knabben)) [SIG Instrumentation and Node] -- Rename metrics `etcd_object_counts` to `apiserver_storage_object_counts` and mark it as stable. The original `etcd_object_counts` metrics name is marked as "Deprecated" and will be removed in the future. ([#99785](https://github.com/kubernetes/kubernetes/pull/99785), [@erain](https://github.com/erain)) [SIG API Machinery, Instrumentation and Testing] -- Update pause container to run as pseudo user and group `65535:65535`. This implies the release of version 3.5 of the container images. ([#97963](https://github.com/kubernetes/kubernetes/pull/97963), [@saschagrunert](https://github.com/saschagrunert)) [SIG CLI, Cloud Provider, Cluster Lifecycle, Node, Release, Security and Testing] -- Users might specify the `kubectl.kubernetes.io/default-exec-container` annotation in a Pod to preselect container for kubectl commands. ([#99833](https://github.com/kubernetes/kubernetes/pull/99833), [@mengjiao-liu](https://github.com/mengjiao-liu)) [SIG CLI] - -### Bug or Regression - -- Add ability to skip OpenAPI handler installation to the GenericAPIServer ([#100341](https://github.com/kubernetes/kubernetes/pull/100341), [@kevindelgado](https://github.com/kevindelgado)) [SIG API Machinery] -- Count pod overhead against an entity's ResourceQuota ([#99600](https://github.com/kubernetes/kubernetes/pull/99600), [@gjkim42](https://github.com/gjkim42)) [SIG API Machinery and Node] -- EndpointSlice controllers are less likely to create duplicate EndpointSlices. ([#100103](https://github.com/kubernetes/kubernetes/pull/100103), [@robscott](https://github.com/robscott)) [SIG Apps and Network] -- Ensure only one LoadBalancer rule is created when HA mode is enabled ([#99825](https://github.com/kubernetes/kubernetes/pull/99825), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider] -- Fixed a race condition on API server startup ensuring previously created webhook configurations are effective before the first write request is admitted. ([#95783](https://github.com/kubernetes/kubernetes/pull/95783), [@roycaihw](https://github.com/roycaihw)) [SIG API Machinery] -- Fixed authentication_duration_seconds metric. Previously it included whole apiserver request duration. ([#99944](https://github.com/kubernetes/kubernetes/pull/99944), [@marseel](https://github.com/marseel)) [SIG API Machinery, Instrumentation and Scalability] -- Fixes issue where inline AzueFile secrets could not be accessed from the pod's namespace. ([#100563](https://github.com/kubernetes/kubernetes/pull/100563), [@msau42](https://github.com/msau42)) [SIG Storage] -- Improve speed of vSphere PV provisioning and reduce number of API calls ([#100054](https://github.com/kubernetes/kubernetes/pull/100054), [@gnufied](https://github.com/gnufied)) [SIG Cloud Provider and Storage] -- Kubectl: Fixed panic when describing an ingress backend without an API Group ([#100505](https://github.com/kubernetes/kubernetes/pull/100505), [@lauchokyip](https://github.com/lauchokyip)) [SIG CLI] -- Kubectl: fix case of age column in describe node (#96963, @bl-ue) ([#96963](https://github.com/kubernetes/kubernetes/pull/96963), [@bl-ue](https://github.com/bl-ue)) [SIG CLI] -- Kubelet.exe on Windows now checks that the process running as administrator and the executing user account is listed in the built-in administrators group. This is the equivalent to checking the process is running as uid 0. ([#96616](https://github.com/kubernetes/kubernetes/pull/96616), [@perithompson](https://github.com/perithompson)) [SIG Node and Windows] -- Kubelet: Fixed the bug of getting the number of cpu when the number of cpu logical processors is more than 64 in windows ([#97378](https://github.com/kubernetes/kubernetes/pull/97378), [@hwdef](https://github.com/hwdef)) [SIG Node and Windows] -- Pass `KUBE_BUILD_CONFORMANCE=y` to the package-tarballs to reenable building the conformance tarballs. ([#100571](https://github.com/kubernetes/kubernetes/pull/100571), [@puerco](https://github.com/puerco)) [SIG Release] -- Pod Log stats for windows now reports metrics ([#99221](https://github.com/kubernetes/kubernetes/pull/99221), [@jsturtevant](https://github.com/jsturtevant)) [SIG Node, Storage, Testing and Windows] - -### Other (Cleanup or Flake) - -- A new storage E2E testsuite covers CSIStorageCapacity publishing if a driver opts into the test. ([#100537](https://github.com/kubernetes/kubernetes/pull/100537), [@pohly](https://github.com/pohly)) [SIG Storage and Testing] -- Convert cmd/kubelet/app/server.go to structured logging ([#98334](https://github.com/kubernetes/kubernetes/pull/98334), [@wawa0210](https://github.com/wawa0210)) [SIG Node] -- If kube-apiserver enabled goaway feature, clients required golang 1.15.8 or 1.16+ version to avoid un-expected data race issue. ([#98809](https://github.com/kubernetes/kubernetes/pull/98809), [@answer1991](https://github.com/answer1991)) [SIG API Machinery] -- Increased CSINodeIDMaxLength from 128 bytes to 192 bytes. ([#98753](https://github.com/kubernetes/kubernetes/pull/98753), [@Jiawei0227](https://github.com/Jiawei0227)) [SIG Apps and Storage] -- Migrate `pkg/kubelet/pluginmanager` to structured logging ([#99885](https://github.com/kubernetes/kubernetes/pull/99885), [@qingwave](https://github.com/qingwave)) [SIG Node] -- Migrate `pkg/kubelet/preemption/preemption.go` and `pkg/kubelet/logs/container_log_manager.go` to structured logging ([#99848](https://github.com/kubernetes/kubernetes/pull/99848), [@qingwave](https://github.com/qingwave)) [SIG Node] -- Migrate `pkg/kubelet/(cri)` to structured logging ([#99006](https://github.com/kubernetes/kubernetes/pull/99006), [@yangjunmyfm192085](https://github.com/yangjunmyfm192085)) [SIG Node] -- Migrate `pkg/kubelet/(node, pod)` to structured logging ([#98847](https://github.com/kubernetes/kubernetes/pull/98847), [@yangjunmyfm192085](https://github.com/yangjunmyfm192085)) [SIG Node] -- Migrate `pkg/kubelet/(volume,container)` to structured logging ([#98850](https://github.com/kubernetes/kubernetes/pull/98850), [@yangjunmyfm192085](https://github.com/yangjunmyfm192085)) [SIG Node] -- Migrate `pkg/kubelet/kubelet_node_status.go` to structured logging ([#98154](https://github.com/kubernetes/kubernetes/pull/98154), [@yangjunmyfm192085](https://github.com/yangjunmyfm192085)) [SIG Node and Release] -- Migrate `pkg/kubelet/lifecycle,oom` to structured logging ([#99479](https://github.com/kubernetes/kubernetes/pull/99479), [@mengjiao-liu](https://github.com/mengjiao-liu)) [SIG Instrumentation and Node] -- Migrate cmd/kubelet/+ pkg/kubelet/cadvisor/cadvisor_linux.go + pkg/kubelet/cri/remote/util/util_unix.go + pkg/kubelet/images/image_manager.go to structured logging ([#99994](https://github.com/kubernetes/kubernetes/pull/99994), [@AfrouzMashayekhi](https://github.com/AfrouzMashayekhi)) [SIG Instrumentation and Node] -- Migrate pkg/kubelet/cm/container_manager_linux.go and pkg/kubelet/cm/container_manager_stub.go to structured logging ([#100001](https://github.com/kubernetes/kubernetes/pull/100001), [@shiyajuan123](https://github.com/shiyajuan123)) [SIG Instrumentation and Node] -- Migrate pkg/kubelet/cm/cpumanage/{topology/togit pology.go, policy_none.go, cpu_assignment.go} to structured logging ([#100163](https://github.com/kubernetes/kubernetes/pull/100163), [@lala123912](https://github.com/lala123912)) [SIG Instrumentation and Node] -- Migrate pkg/kubelet/cm/cpumanager/state to structured logging ([#99563](https://github.com/kubernetes/kubernetes/pull/99563), [@jmguzik](https://github.com/jmguzik)) [SIG Instrumentation and Node] -- Migrate pkg/kubelet/config to structured logging ([#100002](https://github.com/kubernetes/kubernetes/pull/100002), [@AfrouzMashayekhi](https://github.com/AfrouzMashayekhi)) [SIG Instrumentation and Node] -- Migrate pkg/kubelet/kubelet.go to structured logging ([#99861](https://github.com/kubernetes/kubernetes/pull/99861), [@navidshaikh](https://github.com/navidshaikh)) [SIG Instrumentation and Node] -- Migrate pkg/kubelet/kubeletconfig to structured logging ([#100265](https://github.com/kubernetes/kubernetes/pull/100265), [@ehashman](https://github.com/ehashman)) [SIG Node] -- Migrate pkg/kubelet/kuberuntime to structured logging ([#99970](https://github.com/kubernetes/kubernetes/pull/99970), [@krzysiekg](https://github.com/krzysiekg)) [SIG Instrumentation and Node] -- Migrate pkg/kubelet/prober to structured logging ([#99830](https://github.com/kubernetes/kubernetes/pull/99830), [@krzysiekg](https://github.com/krzysiekg)) [SIG Instrumentation and Node] -- Migrate pkg/kubelet/winstats to structured logging ([#99855](https://github.com/kubernetes/kubernetes/pull/99855), [@hexxdump](https://github.com/hexxdump)) [SIG Instrumentation and Node] -- Migrate probe log messages to structured logging ([#97093](https://github.com/kubernetes/kubernetes/pull/97093), [@aldudko](https://github.com/aldudko)) [SIG Instrumentation and Node] -- Migrate remaining kubelet files to structured logging ([#100196](https://github.com/kubernetes/kubernetes/pull/100196), [@ehashman](https://github.com/ehashman)) [SIG Instrumentation and Node] -- `apiserver_storage_objects` (a newer version of `etcd_object_counts) is promoted and marked as stable. ([#100082](https://github.com/kubernetes/kubernetes/pull/100082), [@logicalhan](https://github.com/logicalhan)) [SIG API Machinery, Instrumentation and Testing] - -## Dependencies - -### Added -_Nothing has changed._ - -### Changed -- github.com/cilium/ebpf: [1c8d4c9 → v0.2.0](https://github.com/cilium/ebpf/compare/1c8d4c9...v0.2.0) -- github.com/containerd/console: [v1.0.0 → v1.0.1](https://github.com/containerd/console/compare/v1.0.0...v1.0.1) -- github.com/containerd/containerd: [v1.4.1 → v1.4.4](https://github.com/containerd/containerd/compare/v1.4.1...v1.4.4) -- github.com/creack/pty: [v1.1.9 → v1.1.11](https://github.com/creack/pty/compare/v1.1.9...v1.1.11) -- github.com/docker/docker: [bd33bbf → v20.10.2+incompatible](https://github.com/docker/docker/compare/bd33bbf...v20.10.2) -- github.com/google/cadvisor: [v0.38.8 → v0.39.0](https://github.com/google/cadvisor/compare/v0.38.8...v0.39.0) -- github.com/konsorten/go-windows-terminal-sequences: [v1.0.3 → v1.0.2](https://github.com/konsorten/go-windows-terminal-sequences/compare/v1.0.3...v1.0.2) -- github.com/moby/sys/mountinfo: [v0.1.3 → v0.4.0](https://github.com/moby/sys/mountinfo/compare/v0.1.3...v0.4.0) -- github.com/moby/term: [672ec06 → df9cb8a](https://github.com/moby/term/compare/672ec06...df9cb8a) -- github.com/mrunalp/fileutils: [abd8a0e → v0.5.0](https://github.com/mrunalp/fileutils/compare/abd8a0e...v0.5.0) -- github.com/opencontainers/runc: [v1.0.0-rc92 → v1.0.0-rc93](https://github.com/opencontainers/runc/compare/v1.0.0-rc92...v1.0.0-rc93) -- github.com/opencontainers/runtime-spec: [4d89ac9 → e6143ca](https://github.com/opencontainers/runtime-spec/compare/4d89ac9...e6143ca) -- github.com/opencontainers/selinux: [v1.6.0 → v1.8.0](https://github.com/opencontainers/selinux/compare/v1.6.0...v1.8.0) -- github.com/sirupsen/logrus: [v1.6.0 → v1.7.0](https://github.com/sirupsen/logrus/compare/v1.6.0...v1.7.0) -- github.com/syndtr/gocapability: [d983527 → 42c35b4](https://github.com/syndtr/gocapability/compare/d983527...42c35b4) -- github.com/willf/bitset: [d5bec33 → v1.1.11](https://github.com/willf/bitset/compare/d5bec33...v1.1.11) -- gotest.tools/v3: v3.0.2 → v3.0.3 -- k8s.io/klog/v2: v2.5.0 → v2.8.0 -- sigs.k8s.io/structured-merge-diff/v4: v4.0.3 → v4.1.0 - -### Removed -_Nothing has changed._ - - - -# v1.21.0-beta.1 - - -## Downloads for v1.21.0-beta.1 - -### Source Code - -filename | sha512 hash --------- | ----------- -[kubernetes.tar.gz](https://dl.k8s.io/v1.21.0-beta.1/kubernetes.tar.gz) | c9f4f25242e319e5d90f49d26f239a930aad69677c0f3c2387c56bb13482648a26ed234be2bfe2352508f35010e3eb6d3b127c31a9f24fa1e53ac99c38520fe4 -[kubernetes-src.tar.gz](https://dl.k8s.io/v1.21.0-beta.1/kubernetes-src.tar.gz) | 255357db8fa160cab2187658906b674a8b0d9b9a5b5f688cc7b69dc124f5da00362c6cc18ae9b80f7ddb3da6f64c2ab2f12fb9b63a4e063c7366a5375b175cda - -### Client binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.21.0-beta.1/kubernetes-client-darwin-amd64.tar.gz) | 02efd389c8126456416fd2c7ea25c3cc30f612649ad91f631f068d6c0e5e539484d3763cb9a8645ad6b8077e4fcd1552a659d7516ebc4ce6828cf823b65c3016 -[kubernetes-client-darwin-arm64.tar.gz](https://dl.k8s.io/v1.21.0-beta.1/kubernetes-client-darwin-arm64.tar.gz) | ac90dcd1699d1d7ff9c8342d481f6d0d97ccdc3ec501a56dc7c9e1898a8f77f712bf66942d304bfe581b5494f13e3efa211865de88f89749780e9e26e673dbdb -[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.21.0-beta.1/kubernetes-client-linux-386.tar.gz) | cce5fb84cc7a1ee664f89d8ad3064307c51c044e9ddd2ae5a004939b69d3b3ef6f29acc5782e27d0c8f0d6d3d9c96e922f5d1b99d210ca3e754666d775df9f0c -[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.21.0-beta.1/kubernetes-client-linux-amd64.tar.gz) | 2e93bbd2e60ad7cd8fe495115e96c55b1dc8facd100a827ef9c197a732679b60cceb9ea7bf92a1f5e328c3b8adfa8d3922cbc5d8370e374f3381b83f5b877b4f -[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.21.0-beta.1/kubernetes-client-linux-arm.tar.gz) | 23f03b6a8fa9decce9b89a2c1bd3dae6d0b2f9e533e35a79e2c5a29326a165259677594ae83c877219a21bdb95557a284e55f4eec12954742794579c89a7d7e5 -[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.21.0-beta.1/kubernetes-client-linux-arm64.tar.gz) | 3acf3101b46568b0ded6b90f13df0e918870d6812dc1a584903ddb8ba146484a204b9e442f863df47c7d4dab043fd9f7294c5510d3eb09004993d6d3b1e9e13c -[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.21.0-beta.1/kubernetes-client-linux-ppc64le.tar.gz) | f749198df69577f62872d3096138a1b8969ec6b1636eb68eb56640bf33cf5f97a11df4363462749a1c0dc3ccbb8ae76c5d66864bf1c5cf7e52599caaf498e504 -[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.21.0-beta.1/kubernetes-client-linux-s390x.tar.gz) | 3f6c0189d59fca22cdded3a02c672ef703d17e6ab0831e173a870e14ccec436c142600e9fc35b403571b6906f2be8d18d38d33330f7caada971bbe1187b388f6 -[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.21.0-beta.1/kubernetes-client-windows-386.tar.gz) | 03d92371c425cf331c80807c0ac56f953be304fc6719057258a363d527d186d610e1d4b4d401b34128062983265c2e21f2d2389231aa66a6f5787eee78142cf6 -[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.21.0-beta.1/kubernetes-client-windows-amd64.tar.gz) | 489ece0c886a025ca3a25d28518637a5a824ea6544e7ef8778321036f13c8909a978ad4ceca966cec1e1cda99f25ca78bfd37460d1231c77436d216d43c872ad - -### Server binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.21.0-beta.1/kubernetes-server-linux-amd64.tar.gz) | 2e95cb31d5afcb6842c41d25b7d0c18dd7e65693b2d93c8aa44e5275f9c6201e1a67685c7a8ddefa334babb04cb559d26e39b6a18497695a07dc270568cae108 -[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.21.0-beta.1/kubernetes-server-linux-arm.tar.gz) | 2927e82b98404c077196ce3968f3afd51a7576aa56d516019bd3976771c0213ba01e78da5b77478528e770da0d334e9457995fafb98820ed68b2ee34beb68856 -[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.21.0-beta.1/kubernetes-server-linux-arm64.tar.gz) | e0f7aea3ea598214a9817bc04949389cb7e4e7b9503141a590ef48c0b681fe44a4243ebc6280752fa41aa1093149b3ee1bcef7664edb746097a342281825430b -[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.21.0-beta.1/kubernetes-server-linux-ppc64le.tar.gz) | c011f7eb01294e9ba5d5ced719068466f88ed595dcb8d554a36a4dd5118fb6b3d6bafe8bf89aa2d42988e69793ed777ba77b8876c6ec74f898a43cfce1f61bf4 -[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.21.0-beta.1/kubernetes-server-linux-s390x.tar.gz) | 15f6683e7f16caab7eebead2b7c15799460abbf035a43de0b75f96b0be19908f58add98a777a0cca916230d60cf6bfe3fee92b9dcff50274b1e37c243c157969 - -### Node binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.21.0-beta.1/kubernetes-node-linux-amd64.tar.gz) | ed58679561197110f366b9109f7afd62c227bfc271918ccf3eea203bb2ab6428eb5db4dd6c965f202a8a636f66da199470269b863815809b99d53d2fa47af2ea -[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.21.0-beta.1/kubernetes-node-linux-arm.tar.gz) | 7e6c7f1957fcdecec8fef689c5019edbc0d0c11d22dafbfef0a07121d10d8f6273644f73511bd06a9a88b04d81a940bd6645ffb5711422af64af547a45c76273 -[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.21.0-beta.1/kubernetes-node-linux-arm64.tar.gz) | a3618f29967e7a1574917a67f0296e65780321eda484b99aa32bfd4dc9b35acdefce33da952ac52dfb509fbac5bf700cf177431fad2ab4adcab0544538939faa -[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.21.0-beta.1/kubernetes-node-linux-ppc64le.tar.gz) | 326d3eb521b41bdf489912177f70b8cdd7cd828bb9b3d847ed3694eb27e457f24e0a88b8e51b726eee39800a3c5a40c1b30e3a8ec4a34d8041b3d8ef05d1b749 -[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.21.0-beta.1/kubernetes-node-linux-s390x.tar.gz) | 022d05ebaa66a0332c4fe18cdaf23d14c2c7e4d1f2af7f27baaf1eb042e6890dc3434b4ac8ba58c35d590717956f8c3458112685aff4938b94b18e263c3f4256 -[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.21.0-beta.1/kubernetes-node-windows-amd64.tar.gz) | fa691ed93f07af6bc1cf57e20a30580d6c528f88e5fea3c14f39c1820969dc5a0eb476c5b87b288593d0c086c4dd93aff6165082393283c3f46c210f9bb66d61 - -## Changelog since v1.21.0-beta.0 - -## Urgent Upgrade Notes - -### (No, really, you MUST read this before you upgrade) - - - Kubeadm: during "init" an empty cgroupDriver value in the KubeletConfiguration is now always set to "systemd" unless the user is explicit about it. This requires existing machine setups to configure the container runtime to use the "systemd" driver. Documentation on this topic can be found here: https://kubernetes.io/docs/setup/production-environment/container-runtimes/. When upgrading existing clusters / nodes using "kubeadm upgrade" the old cgroupDriver value is preserved, but in 1.22 this change will also apply to "upgrade". For more information on migrating to the "systemd" driver or remaining on the "cgroupfs" driver see: https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/. ([#99471](https://github.com/kubernetes/kubernetes/pull/99471), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] - - Migrate `pkg/kubelet/(dockershim, network)` to structured logging - Exit code changed from 255 to 1 ([#98939](https://github.com/kubernetes/kubernetes/pull/98939), [@yangjunmyfm192085](https://github.com/yangjunmyfm192085)) [SIG Network and Node] - - Migrate `pkg/kubelet/certificate` to structured logging - Exit code changed from 255 to 1 ([#98993](https://github.com/kubernetes/kubernetes/pull/98993), [@SataQiu](https://github.com/SataQiu)) [SIG Auth and Node] - - Newly provisioned PVs by EBS plugin will no longer use the deprecated "failure-domain.beta.kubernetes.io/zone" and "failure-domain.beta.kubernetes.io/region" labels. It will use "topology.kubernetes.io/zone" and "topology.kubernetes.io/region" labels instead. ([#99130](https://github.com/kubernetes/kubernetes/pull/99130), [@ayberk](https://github.com/ayberk)) [SIG Cloud Provider, Storage and Testing] - - Newly provisioned PVs by OpenStack Cinder plugin will no longer use the deprecated "failure-domain.beta.kubernetes.io/zone" and "failure-domain.beta.kubernetes.io/region" labels. It will use "topology.kubernetes.io/zone" and "topology.kubernetes.io/region" labels instead. ([#99719](https://github.com/kubernetes/kubernetes/pull/99719), [@jsafrane](https://github.com/jsafrane)) [SIG Cloud Provider and Storage] - - OpenStack Cinder CSI migration is on by default, Clinder CSI driver must be installed on clusters on OpenStack for Cinder volumes to work. ([#98538](https://github.com/kubernetes/kubernetes/pull/98538), [@dims](https://github.com/dims)) [SIG Storage] - - Package pkg/kubelet/server migrated to structured logging - Exit code changed from 255 to 1 ([#99838](https://github.com/kubernetes/kubernetes/pull/99838), [@adisky](https://github.com/adisky)) [SIG Node] - - Pkg/kubelet/kuberuntime/kuberuntime_manager.go migrated to structured logging - Exit code changed from 255 to 1 ([#99841](https://github.com/kubernetes/kubernetes/pull/99841), [@adisky](https://github.com/adisky)) [SIG Instrumentation and Node] - -## Changes by Kind - -### Deprecation - -- Kubeadm: the deprecated kube-dns is no longer supported as an option. If "ClusterConfiguration.dns.type" is set to "kube-dns" kubeadm will now throw an error. ([#99646](https://github.com/kubernetes/kubernetes/pull/99646), [@rajansandeep](https://github.com/rajansandeep)) [SIG Cluster Lifecycle] -- Remove deprecated --generator --replicas --service-generator --service-overrides --schedule from kubectl run - Deprecate --serviceaccount --hostport --requests --limits in kubectl run ([#99732](https://github.com/kubernetes/kubernetes/pull/99732), [@soltysh](https://github.com/soltysh)) [SIG CLI and Testing] -- `audit.k8s.io/v1beta1` and `audit.k8s.io/v1alpha1` audit policy configuration and audit events are deprecated in favor of `audit.k8s.io/v1`, available since v1.13. kube-apiserver invocations that specify alpha or beta policy configurations with `--audit-policy-file`, or explicitly request alpha or beta audit events with `--audit-log-version` / `--audit-webhook-version` must update to use `audit.k8s.io/v1` and accept `audit.k8s.io/v1` events prior to v1.24. ([#98858](https://github.com/kubernetes/kubernetes/pull/98858), [@carlory](https://github.com/carlory)) [SIG Auth] -- `diskformat` stroage class parameter for in-tree vSphere volume plugin is deprecated as of v1.21 release. Please consider updating storageclass and remove `diskformat` parameter. vSphere CSI Driver does not support diskformat storageclass parameter. - - vSphere releases less than 67u3 are deprecated as of v1.21. Please consider upgrading vSphere to 67u3 or above. vSphere CSI Driver requires minimum vSphere 67u3. - - VM Hardware version less than 15 is deprecated as of v1.21. Please consider upgrading the Node VM Hardware version to 15 or above. vSphere CSI Driver recommends Node VM's Hardware version set to at least vmx-15. - - Multi vCenter support is deprecated as of v1.21. If you have a Kubernetes cluster spanning across multiple vCenter servers, please consider moving all k8s nodes to a single vCenter Server. vSphere CSI Driver does not support Kubernetes deployment spanning across multiple vCenter servers. - - Support for these deprecations will be available till Kubernetes v1.24. ([#98546](https://github.com/kubernetes/kubernetes/pull/98546), [@divyenpatel](https://github.com/divyenpatel)) [SIG Cloud Provider and Storage] - -### API Change - -- 1. PodAffinityTerm includes a namespaceSelector field to allow selecting eligible namespaces based on their labels. - 2. A new CrossNamespacePodAffinity quota scope API that allows restricting which namespaces allowed to use PodAffinityTerm with corss-namespace reference via namespaceSelector or namespaces fields. ([#98582](https://github.com/kubernetes/kubernetes/pull/98582), [@ahg-g](https://github.com/ahg-g)) [SIG API Machinery, Apps, Auth and Testing] -- Add a default metadata name labels for selecting any namespace by its name. ([#96968](https://github.com/kubernetes/kubernetes/pull/96968), [@jayunit100](https://github.com/jayunit100)) [SIG API Machinery, Apps, Cloud Provider, Storage and Testing] -- Added `.spec.completionMode` field to Job, with accepted values `NonIndexed` (default) and `Indexed` ([#98441](https://github.com/kubernetes/kubernetes/pull/98441), [@alculquicondor](https://github.com/alculquicondor)) [SIG Apps and CLI] -- Clarified NetworkPolicy policyTypes documentation ([#97216](https://github.com/kubernetes/kubernetes/pull/97216), [@joejulian](https://github.com/joejulian)) [SIG Network] -- DaemonSets accept a MaxSurge integer or percent on their rolling update strategy that will launch the updated pod on nodes and wait for those pods to go ready before marking the old out-of-date pods as deleted. This allows workloads to avoid downtime during upgrades when deployed using DaemonSets. This feature is alpha and is behind the DaemonSetUpdateSurge feature gate. ([#96441](https://github.com/kubernetes/kubernetes/pull/96441), [@smarterclayton](https://github.com/smarterclayton)) [SIG Apps and Testing] -- EndpointSlice API is now GA. The EndpointSlice topology field has been removed from the GA API and will be replaced by a new per Endpoint Zone field. If the topology field was previously used, it will be converted into an annotation in the v1 Resource. The discovery.k8s.io/v1alpha1 API is removed. ([#99662](https://github.com/kubernetes/kubernetes/pull/99662), [@swetharepakula](https://github.com/swetharepakula)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation, Network and Testing] -- EndpointSlice Controllers are now GA. The EndpointSlice Controller will not populate the `deprecatedTopology` field and will only provide topology information through the `zone` and `nodeName` fields. ([#99870](https://github.com/kubernetes/kubernetes/pull/99870), [@swetharepakula](https://github.com/swetharepakula)) [SIG API Machinery, Apps, Auth, Network and Testing] -- IngressClass resource can now reference a resource in a specific namespace - for implementation-specific configuration(previously only Cluster-level resources were allowed). - This feature can be enabled using the IngressClassNamespacedParams feature gate. ([#99275](https://github.com/kubernetes/kubernetes/pull/99275), [@hbagdi](https://github.com/hbagdi)) [SIG API Machinery, CLI and Network] -- Introduce conditions for PodDisruptionBudget ([#98127](https://github.com/kubernetes/kubernetes/pull/98127), [@mortent](https://github.com/mortent)) [SIG API Machinery, Apps, Auth, CLI, Cloud Provider, Cluster Lifecycle and Instrumentation] -- Jobs API has a new .spec.suspend field that can be used to suspend and resume Jobs ([#98727](https://github.com/kubernetes/kubernetes/pull/98727), [@adtac](https://github.com/adtac)) [SIG API Machinery, Apps, Node, Scheduling and Testing] -- Kubelet Graceful Node Shutdown feature is now beta. ([#99735](https://github.com/kubernetes/kubernetes/pull/99735), [@bobbypage](https://github.com/bobbypage)) [SIG Node] -- Limit the quest value of hugepage to integer multiple of page size. ([#98515](https://github.com/kubernetes/kubernetes/pull/98515), [@lala123912](https://github.com/lala123912)) [SIG Apps] -- One new field "InternalTrafficPolicy" in Service is added. - It specifies if the cluster internal traffic should be routed to all endpoints or node-local endpoints only. - "Cluster" routes internal traffic to a Service to all endpoints. - "Local" routes traffic to node-local endpoints only, and traffic is dropped if no node-local endpoints are ready. - The default value is "Cluster". ([#96600](https://github.com/kubernetes/kubernetes/pull/96600), [@maplain](https://github.com/maplain)) [SIG API Machinery, Apps and Network] -- PodSecurityPolicy only stores "generic" as allowed volume type if the GenericEphemeralVolume feature gate is enabled ([#98918](https://github.com/kubernetes/kubernetes/pull/98918), [@pohly](https://github.com/pohly)) [SIG Auth and Security] -- Promote CronJobs to batch/v1 ([#99423](https://github.com/kubernetes/kubernetes/pull/99423), [@soltysh](https://github.com/soltysh)) [SIG API Machinery, Apps, CLI and Testing] -- Remove support for building Kubernetes with bazel. ([#99561](https://github.com/kubernetes/kubernetes/pull/99561), [@BenTheElder](https://github.com/BenTheElder)) [SIG API Machinery, Apps, Architecture, Auth, Autoscaling, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation, Network, Node, Release, Scalability, Scheduling, Storage, Testing and Windows] -- Setting loadBalancerClass in load balancer type of service is available with this PR. - Users who want to use a custom load balancer can specify loadBalancerClass to achieve it. ([#98277](https://github.com/kubernetes/kubernetes/pull/98277), [@XudongLiuHarold](https://github.com/XudongLiuHarold)) [SIG API Machinery, Apps, Cloud Provider and Network] -- Storage capacity tracking (= the CSIStorageCapacity feature) is beta, storage.k8s.io/v1alpha1/VolumeAttachment and storage.k8s.io/v1alpha1/CSIStorageCapacity objects are deprecated ([#99641](https://github.com/kubernetes/kubernetes/pull/99641), [@pohly](https://github.com/pohly)) [SIG API Machinery, Apps, Auth, Scheduling, Storage and Testing] -- Support for Indexed Job: a Job that is considered completed when Pods associated to indexes from 0 to (.spec.completions-1) have succeeded. ([#98812](https://github.com/kubernetes/kubernetes/pull/98812), [@alculquicondor](https://github.com/alculquicondor)) [SIG Apps and CLI] -- The apiserver now resets managedFields that got corrupted by a mutating admission controller. ([#98074](https://github.com/kubernetes/kubernetes/pull/98074), [@kwiesmueller](https://github.com/kwiesmueller)) [SIG API Machinery and Testing] -- `controller.kubernetes.io/pod-deletion-cost` annotation can be set to offer a hint on the cost of deleting a pod compared to other pods belonging to the same ReplicaSet. Pods with lower deletion cost are deleted first. This is an alpha feature. ([#99163](https://github.com/kubernetes/kubernetes/pull/99163), [@ahg-g](https://github.com/ahg-g)) [SIG Apps] - -### Feature - -- A client-go metric, rest_client_exec_plugin_call_total, has been added to track total calls to client-go credential plugins. ([#98892](https://github.com/kubernetes/kubernetes/pull/98892), [@ankeesler](https://github.com/ankeesler)) [SIG API Machinery, Auth, Cluster Lifecycle and Instrumentation] -- Add --use-protocol-buffers flag to kubectl top pods and nodes ([#96655](https://github.com/kubernetes/kubernetes/pull/96655), [@serathius](https://github.com/serathius)) [SIG CLI] -- Add support to generate client-side binaries for new darwin/arm64 platform ([#97743](https://github.com/kubernetes/kubernetes/pull/97743), [@dims](https://github.com/dims)) [SIG Release and Testing] -- Added `ephemeral_volume_controller_create[_failures]_total` counters to kube-controller-manager metrics ([#99115](https://github.com/kubernetes/kubernetes/pull/99115), [@pohly](https://github.com/pohly)) [SIG API Machinery, Apps, Cluster Lifecycle, Instrumentation and Storage] -- Adds alpha feature `VolumeCapacityPriority` which makes the scheduler prioritize nodes based on the best matching size of statically provisioned PVs across multiple topologies. ([#96347](https://github.com/kubernetes/kubernetes/pull/96347), [@cofyc](https://github.com/cofyc)) [SIG Apps, Network, Scheduling, Storage and Testing] -- Adds two new metrics to cronjobs, a histogram to track the time difference when a job is created and the expected time when it should be created, and a gauge for the missed schedules of a cronjob ([#99341](https://github.com/kubernetes/kubernetes/pull/99341), [@alaypatel07](https://github.com/alaypatel07)) [SIG Apps and Instrumentation] -- Alpha implementation of Kubectl Command Headers: SIG CLI KEP 859 enabled when KUBECTL_COMMAND_HEADERS environment variable set on the client command line. - - To enable: export KUBECTL_COMMAND_HEADERS=1; kubectl ... ([#98952](https://github.com/kubernetes/kubernetes/pull/98952), [@seans3](https://github.com/seans3)) [SIG API Machinery and CLI] -- Component owner can configure the allowlist of metric label with flag '--allow-metric-labels'. ([#99738](https://github.com/kubernetes/kubernetes/pull/99738), [@YoyinZyc](https://github.com/YoyinZyc)) [SIG API Machinery, Cluster Lifecycle and Instrumentation] -- Disruption controller only sends one event per PodDisruptionBudget if scale can't be computed ([#98128](https://github.com/kubernetes/kubernetes/pull/98128), [@mortent](https://github.com/mortent)) [SIG Apps] -- EndpointSliceNodeName will always be enabled, so NodeName will always be available in the v1beta1 API. ([#99746](https://github.com/kubernetes/kubernetes/pull/99746), [@swetharepakula](https://github.com/swetharepakula)) [SIG Apps and Network] -- Graduate CRIContainerLogRotation feature gate to GA. ([#99651](https://github.com/kubernetes/kubernetes/pull/99651), [@umohnani8](https://github.com/umohnani8)) [SIG Node and Testing] -- Kube-proxy iptables: new metric sync_proxy_rules_iptables_total that exposes the number of rules programmed per table in each iteration ([#99653](https://github.com/kubernetes/kubernetes/pull/99653), [@aojea](https://github.com/aojea)) [SIG Instrumentation and Network] -- Kube-scheduler now logs plugin scoring summaries at --v=4 ([#99411](https://github.com/kubernetes/kubernetes/pull/99411), [@damemi](https://github.com/damemi)) [SIG Scheduling] -- Kubeadm: a warning to user as ipv6 site-local is deprecated ([#99574](https://github.com/kubernetes/kubernetes/pull/99574), [@pacoxu](https://github.com/pacoxu)) [SIG Cluster Lifecycle and Network] -- Kubeadm: apply the "node.kubernetes.io/exclude-from-external-load-balancers" label on control plane nodes during "init", "join" and "upgrade" to preserve backwards compatibility with the lagacy LB mode where nodes labeled as "master" where excluded. To opt-out you can remove the label from a node. See #97543 and the linked KEP for more details. ([#98269](https://github.com/kubernetes/kubernetes/pull/98269), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] -- Kubeadm: if the user has customized their image repository via the kubeadm configuration, pass the custom pause image repository and tag to the kubelet via --pod-infra-container-image not only for Docker but for all container runtimes. This flag tells the kubelet that it should not garbage collect the image. ([#99476](https://github.com/kubernetes/kubernetes/pull/99476), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] -- Kubeadm: promote IPv6DualStack feature gate to Beta ([#99294](https://github.com/kubernetes/kubernetes/pull/99294), [@pacoxu](https://github.com/pacoxu)) [SIG Cluster Lifecycle] -- Kubectl version changed to write a warning message to stderr if the client and server version difference exceeds the supported version skew of +/-1 minor version. ([#98250](https://github.com/kubernetes/kubernetes/pull/98250), [@brianpursley](https://github.com/brianpursley)) [SIG CLI] -- Kubernetes is now built with Golang 1.16 ([#98572](https://github.com/kubernetes/kubernetes/pull/98572), [@justaugustus](https://github.com/justaugustus)) [SIG API Machinery, Auth, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation, Node, Release and Testing] -- Persistent Volumes formatted with the btrfs filesystem will now automatically resize when expanded. ([#99361](https://github.com/kubernetes/kubernetes/pull/99361), [@Novex](https://github.com/Novex)) [SIG Storage] -- Remove cAdvisor json metrics api collected by Kubelet ([#99236](https://github.com/kubernetes/kubernetes/pull/99236), [@pacoxu](https://github.com/pacoxu)) [SIG Node] -- Sysctls is now GA and locked to default ([#99158](https://github.com/kubernetes/kubernetes/pull/99158), [@wgahnagl](https://github.com/wgahnagl)) [SIG Node] -- The NodeAffinity plugin implements the PreFilter extension, offering enhanced performance for Filter. ([#99213](https://github.com/kubernetes/kubernetes/pull/99213), [@AliceZhang2016](https://github.com/AliceZhang2016)) [SIG Scheduling] -- The endpointslice mirroring controller mirrors endpoints annotations and labels to the generated endpoint slices, it also ensures that updates on any of these fields are mirrored. - The well-known annotation endpoints.kubernetes.io/last-change-trigger-time is skipped and not mirrored. ([#98116](https://github.com/kubernetes/kubernetes/pull/98116), [@aojea](https://github.com/aojea)) [SIG Apps, Network and Testing] -- Update the latest validated version of Docker to 20.10 ([#98977](https://github.com/kubernetes/kubernetes/pull/98977), [@neolit123](https://github.com/neolit123)) [SIG CLI, Cluster Lifecycle and Node] -- Upgrade node local dns to 1.17.0 for better IPv6 support ([#99749](https://github.com/kubernetes/kubernetes/pull/99749), [@pacoxu](https://github.com/pacoxu)) [SIG Cloud Provider and Network] -- Users might specify the `kubectl.kubernetes.io/default-exec-container` annotation in a Pod to preselect container for kubectl commands. ([#99581](https://github.com/kubernetes/kubernetes/pull/99581), [@mengjiao-liu](https://github.com/mengjiao-liu)) [SIG CLI] -- When downscaling ReplicaSets, ready and creation timestamps are compared in a logarithmic scale. ([#99212](https://github.com/kubernetes/kubernetes/pull/99212), [@damemi](https://github.com/damemi)) [SIG Apps and Testing] -- When the kubelet is watching a ConfigMap or Secret purely in the context of setting environment variables - for containers, only hold that watch for a defined duration before cancelling it. This change reduces the CPU - and memory usage of the kube-apiserver in large clusters. ([#99393](https://github.com/kubernetes/kubernetes/pull/99393), [@chenyw1990](https://github.com/chenyw1990)) [SIG API Machinery, Node and Testing] -- WindowsEndpointSliceProxying feature gate has graduated to beta and is enabled by default. This means kube-proxy will read from EndpointSlices instead of Endpoints on Windows by default. ([#99794](https://github.com/kubernetes/kubernetes/pull/99794), [@robscott](https://github.com/robscott)) [SIG Network] - -### Bug or Regression - -- Creating a PVC with DataSource should fail for non-CSI plugins. ([#97086](https://github.com/kubernetes/kubernetes/pull/97086), [@xing-yang](https://github.com/xing-yang)) [SIG Apps and Storage] -- EndpointSlice controller is now less likely to emit FailedToUpdateEndpointSlices events. ([#99345](https://github.com/kubernetes/kubernetes/pull/99345), [@robscott](https://github.com/robscott)) [SIG Apps and Network] -- EndpointSliceMirroring controller is now less likely to emit FailedToUpdateEndpointSlices events. ([#99756](https://github.com/kubernetes/kubernetes/pull/99756), [@robscott](https://github.com/robscott)) [SIG Apps and Network] -- Fix --ignore-errors does not take effect if multiple logs are printed and unfollowed ([#97686](https://github.com/kubernetes/kubernetes/pull/97686), [@wzshiming](https://github.com/wzshiming)) [SIG CLI] -- Fix bug that would let the Horizontal Pod Autoscaler scale down despite at least one metric being unavailable/invalid ([#99514](https://github.com/kubernetes/kubernetes/pull/99514), [@mikkeloscar](https://github.com/mikkeloscar)) [SIG Apps and Autoscaling] -- Fix cgroup handling for systemd with cgroup v2 ([#98365](https://github.com/kubernetes/kubernetes/pull/98365), [@odinuge](https://github.com/odinuge)) [SIG Node] -- Fix smb mount PermissionDenied issue on Windows ([#99550](https://github.com/kubernetes/kubernetes/pull/99550), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider, Storage and Windows] -- Fixed a bug that causes smaller number of conntrack-max being used under CPU static policy. (#99225, @xh4n3) ([#99613](https://github.com/kubernetes/kubernetes/pull/99613), [@xh4n3](https://github.com/xh4n3)) [SIG Network] -- Fixed bug that caused cAdvisor to incorrectly detect single-socket multi-NUMA topology. ([#99315](https://github.com/kubernetes/kubernetes/pull/99315), [@iwankgb](https://github.com/iwankgb)) [SIG Node] -- Fixes add-on manager leader election ([#98968](https://github.com/kubernetes/kubernetes/pull/98968), [@liggitt](https://github.com/liggitt)) [SIG Cloud Provider] -- Improved update time of pod statuses following new probe results. ([#98376](https://github.com/kubernetes/kubernetes/pull/98376), [@matthyx](https://github.com/matthyx)) [SIG Node and Testing] -- Kube-apiserver: an update of a pod with a generic ephemeral volume dropped that volume if the feature had been disabled since creating the pod with such a volume ([#99446](https://github.com/kubernetes/kubernetes/pull/99446), [@pohly](https://github.com/pohly)) [SIG Apps, Node and Storage] -- Kubeadm: skip validating pod subnet against node-cidr-mask when allocate-node-cidrs is set to be false ([#98984](https://github.com/kubernetes/kubernetes/pull/98984), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle] -- On single-stack configured (IPv4 or IPv6, but not both) clusters, Services which are both headless (no clusterIP) and selectorless (empty or undefined selector) will report `ipFamilyPolicy RequireDualStack` and will have entries in `ipFamilies[]` for both IPv4 and IPv6. This is a change from alpha, but does not have any impact on the manually-specified Endpoints and EndpointSlices for the Service. ([#99555](https://github.com/kubernetes/kubernetes/pull/99555), [@thockin](https://github.com/thockin)) [SIG Apps and Network] -- Resolves spurious `Failed to list *v1.Secret` or `Failed to list *v1.ConfigMap` messages in kubelet logs. ([#99538](https://github.com/kubernetes/kubernetes/pull/99538), [@liggitt](https://github.com/liggitt)) [SIG Auth and Node] -- Return zero time (midnight on Jan. 1, 1970) instead of negative number when reporting startedAt and finishedAt of the not started or a running Pod when using dockershim as a runtime. ([#99585](https://github.com/kubernetes/kubernetes/pull/99585), [@Iceber](https://github.com/Iceber)) [SIG Node] -- Stdin is now only passed to client-go exec credential plugins when it is detected to be an interactive terminal. Previously, it was passed to client-go exec plugins when **stdout*- was detected to be an interactive terminal. ([#99654](https://github.com/kubernetes/kubernetes/pull/99654), [@ankeesler](https://github.com/ankeesler)) [SIG API Machinery and Auth] -- The maximum number of ports allowed in EndpointSlices has been increased from 100 to 20,000 ([#99795](https://github.com/kubernetes/kubernetes/pull/99795), [@robscott](https://github.com/robscott)) [SIG Network] -- Updates the commands - - kubectl kustomize {arg} - - kubectl apply -k {arg} - to use same code as kustomize CLI v4.0.5 - - [v4.0.5]: https://github.com/kubernetes-sigs/kustomize/releases/tag/kustomize%2Fv4.0.5 ([#98946](https://github.com/kubernetes/kubernetes/pull/98946), [@monopole](https://github.com/monopole)) [SIG API Machinery, Architecture, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation, Node and Storage] -- When a CNI plugin returns dual-stack pod IPs, kubelet will now try to respect the - "primary IP family" of the cluster by picking a primary pod IP of the same family - as the (primary) node IP, rather than assuming that the CNI plugin returned the IPs - in the order the administrator wanted (since some CNI plugins don't allow - configuring this). ([#97979](https://github.com/kubernetes/kubernetes/pull/97979), [@danwinship](https://github.com/danwinship)) [SIG Network and Node] -- When using Containerd on Windows, the "C:\Windows\System32\drivers\etc\hosts" file will now be managed by kubelet. ([#83730](https://github.com/kubernetes/kubernetes/pull/83730), [@claudiubelu](https://github.com/claudiubelu)) [SIG Node and Windows] -- `VolumeBindingArgs` now allow `BindTimeoutSeconds` to be set as zero, while the value zero indicates no waiting for the checking of volume binding operation. ([#99835](https://github.com/kubernetes/kubernetes/pull/99835), [@chendave](https://github.com/chendave)) [SIG Scheduling and Storage] -- `kubectl exec` and `kubectl attach` now honor the `--quiet` flag which suppresses output from the local binary that could be confused by a script with the remote command output (all non-failure output is hidden). In addition, print inline with exec and attach the list of alternate containers when we default to the first spec.container. ([#99004](https://github.com/kubernetes/kubernetes/pull/99004), [@smarterclayton](https://github.com/smarterclayton)) [SIG CLI] - -### Other (Cleanup or Flake) - -- Apiserver_request_duration_seconds is promoted to stable status. ([#99925](https://github.com/kubernetes/kubernetes/pull/99925), [@logicalhan](https://github.com/logicalhan)) [SIG API Machinery, Instrumentation and Testing] -- Apiserver_request_total is promoted to stable status and no longer has a content-type dimensions, so any alerts/charts which presume the existence of this will fail. This is however, unlikely to be the case since it was effectively an unbounded dimension in the first place. ([#99788](https://github.com/kubernetes/kubernetes/pull/99788), [@logicalhan](https://github.com/logicalhan)) [SIG API Machinery, Instrumentation and Testing] -- EndpointSlice generation is now incremented when labels change. ([#99750](https://github.com/kubernetes/kubernetes/pull/99750), [@robscott](https://github.com/robscott)) [SIG Network] -- Featuregate AllowInsecureBackendProxy is promoted to GA ([#99658](https://github.com/kubernetes/kubernetes/pull/99658), [@deads2k](https://github.com/deads2k)) [SIG API Machinery] -- Migrate `pkg/kubelet/(eviction)` to structured logging ([#99032](https://github.com/kubernetes/kubernetes/pull/99032), [@yangjunmyfm192085](https://github.com/yangjunmyfm192085)) [SIG Node] -- Migrate deployment controller log messages to structured logging ([#97507](https://github.com/kubernetes/kubernetes/pull/97507), [@aldudko](https://github.com/aldudko)) [SIG Apps] -- Migrate pkg/kubelet/cloudresource to structured logging ([#98999](https://github.com/kubernetes/kubernetes/pull/98999), [@sladyn98](https://github.com/sladyn98)) [SIG Node] -- Migrate pkg/kubelet/cri/remote logs to structured logging ([#98589](https://github.com/kubernetes/kubernetes/pull/98589), [@chenyw1990](https://github.com/chenyw1990)) [SIG Node] -- Migrate pkg/kubelet/kuberuntime/kuberuntime_container.go logs to structured logging ([#96973](https://github.com/kubernetes/kubernetes/pull/96973), [@chenyw1990](https://github.com/chenyw1990)) [SIG Instrumentation and Node] -- Migrate pkg/kubelet/status to structured logging ([#99836](https://github.com/kubernetes/kubernetes/pull/99836), [@navidshaikh](https://github.com/navidshaikh)) [SIG Instrumentation and Node] -- Migrate pkg/kubelet/token to structured logging ([#99264](https://github.com/kubernetes/kubernetes/pull/99264), [@palnabarun](https://github.com/palnabarun)) [SIG Auth, Instrumentation and Node] -- Migrate pkg/kubelet/util to structured logging ([#99823](https://github.com/kubernetes/kubernetes/pull/99823), [@navidshaikh](https://github.com/navidshaikh)) [SIG Instrumentation and Node] -- Migrate proxy/userspace/proxier.go logs to structured logging ([#97837](https://github.com/kubernetes/kubernetes/pull/97837), [@JornShen](https://github.com/JornShen)) [SIG Network] -- Migrate some kubelet/metrics log messages to structured logging ([#98627](https://github.com/kubernetes/kubernetes/pull/98627), [@jialaijun](https://github.com/jialaijun)) [SIG Instrumentation and Node] -- Process start time on Windows now uses current process information ([#97491](https://github.com/kubernetes/kubernetes/pull/97491), [@jsturtevant](https://github.com/jsturtevant)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Windows] - -### Uncategorized - -- Migrate pkg/kubelet/stats to structured logging ([#99607](https://github.com/kubernetes/kubernetes/pull/99607), [@krzysiekg](https://github.com/krzysiekg)) [SIG Node] -- The DownwardAPIHugePages feature is beta. Users may use the feature if all workers in their cluster are min 1.20 version. The feature will be enabled by default in all installations in 1.22. ([#99610](https://github.com/kubernetes/kubernetes/pull/99610), [@derekwaynecarr](https://github.com/derekwaynecarr)) [SIG Node] - -## Dependencies - -### Added -- github.com/go-errors/errors: [v1.0.1](https://github.com/go-errors/errors/tree/v1.0.1) -- github.com/gobuffalo/here: [v0.6.0](https://github.com/gobuffalo/here/tree/v0.6.0) -- github.com/google/shlex: [e7afc7f](https://github.com/google/shlex/tree/e7afc7f) -- github.com/markbates/pkger: [v0.17.1](https://github.com/markbates/pkger/tree/v0.17.1) -- github.com/monochromegane/go-gitignore: [205db1a](https://github.com/monochromegane/go-gitignore/tree/205db1a) -- github.com/niemeyer/pretty: [a10e7ca](https://github.com/niemeyer/pretty/tree/a10e7ca) -- github.com/xlab/treeprint: [a009c39](https://github.com/xlab/treeprint/tree/a009c39) -- go.starlark.net: 8dd3e2e -- golang.org/x/term: 6a3ed07 -- sigs.k8s.io/kustomize/api: v0.8.5 -- sigs.k8s.io/kustomize/cmd/config: v0.9.7 -- sigs.k8s.io/kustomize/kustomize/v4: v4.0.5 -- sigs.k8s.io/kustomize/kyaml: v0.10.15 - -### Changed -- dmitri.shuralyov.com/gpu/mtl: 666a987 → 28db891 -- github.com/creack/pty: [v1.1.7 → v1.1.9](https://github.com/creack/pty/compare/v1.1.7...v1.1.9) -- github.com/go-openapi/spec: [v0.19.3 → v0.19.5](https://github.com/go-openapi/spec/compare/v0.19.3...v0.19.5) -- github.com/go-openapi/strfmt: [v0.19.3 → v0.19.5](https://github.com/go-openapi/strfmt/compare/v0.19.3...v0.19.5) -- github.com/go-openapi/validate: [v0.19.5 → v0.19.8](https://github.com/go-openapi/validate/compare/v0.19.5...v0.19.8) -- github.com/google/cadvisor: [v0.38.7 → v0.38.8](https://github.com/google/cadvisor/compare/v0.38.7...v0.38.8) -- github.com/kr/text: [v0.1.0 → v0.2.0](https://github.com/kr/text/compare/v0.1.0...v0.2.0) -- github.com/mattn/go-runewidth: [v0.0.2 → v0.0.7](https://github.com/mattn/go-runewidth/compare/v0.0.2...v0.0.7) -- github.com/olekukonko/tablewriter: [a0225b3 → v0.0.4](https://github.com/olekukonko/tablewriter/compare/a0225b3...v0.0.4) -- github.com/sergi/go-diff: [v1.0.0 → v1.1.0](https://github.com/sergi/go-diff/compare/v1.0.0...v1.1.0) -- golang.org/x/crypto: 7f63de1 → 5ea612d -- golang.org/x/exp: 6cc2880 → 85be41e -- golang.org/x/mobile: d2bd2a2 → e6ae53a -- golang.org/x/mod: v0.3.0 → ce943fd -- golang.org/x/net: 69a7880 → 3d97a24 -- golang.org/x/sys: 5cba982 → a50acf3 -- golang.org/x/time: 3af7569 → f8bda1e -- golang.org/x/tools: 113979e → v0.1.0 -- gopkg.in/check.v1: 41f04d3 → 8fa4692 -- gopkg.in/yaml.v2: v2.2.8 → v2.4.0 -- k8s.io/kube-openapi: d219536 → 591a79e -- k8s.io/system-validators: v1.3.0 → v1.4.0 - -### Removed -- github.com/codegangsta/negroni: [v1.0.0](https://github.com/codegangsta/negroni/tree/v1.0.0) -- github.com/golangplus/bytes: [45c989f](https://github.com/golangplus/bytes/tree/45c989f) -- github.com/golangplus/fmt: [2a5d6d7](https://github.com/golangplus/fmt/tree/2a5d6d7) -- github.com/gorilla/context: [v1.1.1](https://github.com/gorilla/context/tree/v1.1.1) -- github.com/kr/pty: [v1.1.5](https://github.com/kr/pty/tree/v1.1.5) -- sigs.k8s.io/kustomize: v2.0.3+incompatible - - - -# v1.21.0-beta.0 - - -## Downloads for v1.21.0-beta.0 - -### Source Code - -filename | sha512 hash --------- | ----------- -[kubernetes.tar.gz](https://dl.k8s.io/v1.21.0-beta.0/kubernetes.tar.gz) | 69b73a03b70b0ed006e9fef3f5b9bc68f0eb8dc40db6cc04777c03a2cb83a008c783012ca186b1c48357fb192403dbcf6960f120924785e2076e215b9012d546 -[kubernetes-src.tar.gz](https://dl.k8s.io/v1.21.0-beta.0/kubernetes-src.tar.gz) | 9620fb6d37634271bdd423c09f33f3bd29e74298aa82c47dffc8cb6bd2ff44fa8987a53c53bc529db4ca96ec41503aa81cc8d0c3ac106f3b06c4720de933a8e6 - -### Client binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.21.0-beta.0/kubernetes-client-darwin-amd64.tar.gz) | 2a6f3fcd6b571f5ccde56b91e6e179a01899244be496dae16a2a16e0405c9437b75c6dc853b56f9a4876a7c0a60ec624ccd28400bf8fb960258263172f6860ba -[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.21.0-beta.0/kubernetes-client-linux-386.tar.gz) | 78fe9ad9f9a9bc043293327223f0038a2c087ca65e87187a6dcae7a24aef9565fe498d295a4639b0b90524469a04930022fcecd815d0afc742eb87ddd8eb7ef5 -[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.21.0-beta.0/kubernetes-client-linux-amd64.tar.gz) | c025f5e5bd132355e7dd1296cf2ec752264e7f754c4d95fc34b076bd75bef2f571d30872bcb3d138ce95c592111353d275a80eb31f82c07000874b4c56282dbd -[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.21.0-beta.0/kubernetes-client-linux-arm.tar.gz) | 9975cd2f08fbc202575fb15ba6fc51dab23155ca4d294ebb48516a81efa51f58bab3a87d41c865103756189b554c020371d729ad42880ba788f25047ffc46910 -[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.21.0-beta.0/kubernetes-client-linux-arm64.tar.gz) | 56a6836e24471e42e9d9a8488453f2d55598d70c8aca0a307d5116139c930c25c469fd0d1ab5060fbe88dad75a9b5209a08dc11d644af5f3ebebfbcb6c16266c -[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.21.0-beta.0/kubernetes-client-linux-ppc64le.tar.gz) | b6a6cc9baad0ad85ed079ee80e6d6acc905095cfb440998bbc0f553b94fa80077bd58b8692754de477517663d51161705e6e89a1b6d04aa74819800db3517722 -[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.21.0-beta.0/kubernetes-client-linux-s390x.tar.gz) | 7b743481b340f510bf9ae28ea8ea91150aa1e8c37fe104b66d7b3aff62f5e6db3c590d2c13d14dbb5c928de31c7613372def2496075853611d10d6b5fa5b60bd -[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.21.0-beta.0/kubernetes-client-windows-386.tar.gz) | df06c7a524ce84c1f8d7836aa960c550c88dbca0ec4854df4dd0a85b3c84b8ecbc41b54e8c4669ce28ac670659ff0fad795deb1bc539f3c3b3aa885381265f5a -[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.21.0-beta.0/kubernetes-client-windows-amd64.tar.gz) | 4568497b684564f2a94fbea6cbfd778b891231470d9a6956c3b7a3268643d13b855c0fc5ebea5f769300cc0c7719c2c331c387f468816f182f63e515adeaa7a0 - -### Server binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.21.0-beta.0/kubernetes-server-linux-amd64.tar.gz) | 42883cca2d312153baf693fc6024a295359a421e74fd70eefc927413be4e0353debe634e7cca6b9a8f7d8a0cee3717e03ba5d29a306e93139b1c2f3027535a6d -[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.21.0-beta.0/kubernetes-server-linux-arm.tar.gz) | e0042215e84c769ba4fc4d159ccf67b2c4a26206bfffb0ec5152723dc813ff9c1426aa0e9b963d7bfa2efb266ca43561b596b459152882ebb42102ccf60bd8eb -[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.21.0-beta.0/kubernetes-server-linux-arm64.tar.gz) | bfad29d43e14152cb9bc7c4df6aa77929c6eca64a294bb832215bdba9fa0ee2195a2b709c0267dc7426bb371b547ee80bb8461a8c678c9bffa0819aa7db96289 -[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.21.0-beta.0/kubernetes-server-linux-ppc64le.tar.gz) | ca67674c01c6cebdc8160c85b449eab1a23bb0557418665246e0208543fa2eaaf97679685c7b49bee3a4300904c0399c3d762ae34dc3e279fd69ce792c4b07ff -[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.21.0-beta.0/kubernetes-server-linux-s390x.tar.gz) | 285352b628ec754b01b8ad4ef1427223a142d58ebcb46f6861df14d68643133b32330460b213b1ba5bc5362ff2b6dacd8e0c2d20cce6e760fa1954af8a60df8b - -### Node binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.21.0-beta.0/kubernetes-node-linux-amd64.tar.gz) | d92d9b30e7e44134a0cd9db4c01924d365991ea16b3131200b02a82cff89c8701f618cd90e7f1c65427bd4bb5f78b10d540b2262de2c143b401fa44e5b25627b -[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.21.0-beta.0/kubernetes-node-linux-arm.tar.gz) | 551092f23c27fdea4bb2d0547f6075892534892a96fc2be7786f82b58c93bffdb5e1c20f8f11beb8bed46c24f36d4c18ec5ac9755435489efa28e6ae775739bd -[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.21.0-beta.0/kubernetes-node-linux-arm64.tar.gz) | 26ae7f4163e527349b8818ee38b9ee062314ab417f307afa49c146df8f5a2bd689509b128bd4a1efd3896fd89571149a9955ada91f8ca0c2f599cd863d613c86 -[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.21.0-beta.0/kubernetes-node-linux-ppc64le.tar.gz) | 821fa953f6cebc69d2d481e489f3e90899813d20e2eefbabbcadd019d004108e7540f741fabe60e8e7c6adbb1053ac97898bbdddec3ca19f34a71aa3312e0d4e -[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.21.0-beta.0/kubernetes-node-linux-s390x.tar.gz) | 22197d4f66205d5aa9de83dfddcc4f2bb3195fd7067cdb5c21e61dbeae217bc112fb7ecff8a539579b60ad92298c2b4c87b9b7c7e6ec1ee1ffa0c6e4bc4412c1 -[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.21.0-beta.0/kubernetes-node-windows-amd64.tar.gz) | 7e22e0d9603562a04dee16a513579f06b1ff6354d97d669bd68f8777ec7f89f6ef027fb23ab0445d7bba0bb689352f0cc748ce90e3f597c6ebe495464a96b860 - -## Changelog since v1.21.0-alpha.3 - -## Urgent Upgrade Notes - -### (No, really, you MUST read this before you upgrade) - - - The metric `storage_operation_errors_total` is not removed, but is marked deprecated, and the metric `storage_operation_status_count` is marked deprecated. In both cases the storage_operation_duration_seconds metric can be used to recover equivalent counts (using `status=fail-unknown` in the case of `storage_operations_errors_total`). ([#99045](https://github.com/kubernetes/kubernetes/pull/99045), [@mattcary](https://github.com/mattcary)) [SIG Instrumentation and Storage] - -## Changes by Kind - -### Deprecation - -- The `batch/v2alpha1` CronJob type definitions and clients are deprecated and removed. ([#96987](https://github.com/kubernetes/kubernetes/pull/96987), [@soltysh](https://github.com/soltysh)) [SIG API Machinery, Apps, CLI and Testing] - -### API Change - -- Cluster admins can now turn off /debug/pprof and /debug/flags/v endpoint in kubelet by setting enableProfilingHandler and enableDebugFlagsHandler to false in their kubelet configuration file. enableProfilingHandler and enableDebugFlagsHandler can be set to true only when enableDebuggingHandlers is also set to true. ([#98458](https://github.com/kubernetes/kubernetes/pull/98458), [@SaranBalaji90](https://github.com/SaranBalaji90)) [SIG Node] -- The BoundServiceAccountTokenVolume feature has been promoted to beta, and enabled by default. - - This changes the tokens provided to containers at `/var/run/secrets/kubernetes.io/serviceaccount/token` to be time-limited, auto-refreshed, and invalidated when the containing pod is deleted. - - Clients should reload the token from disk periodically (once per minute is recommended) to ensure they continue to use a valid token. `k8s.io/client-go` version v11.0.0+ and v0.15.0+ reload tokens automatically. - - By default, injected tokens are given an extended lifetime so they remain valid even after a new refreshed token is provided. The metric `serviceaccount_stale_tokens_total` can be used to monitor for workloads that are depending on the extended lifetime and are continuing to use tokens even after a refreshed token is provided to the container. If that metric indicates no existing workloads are depending on extended lifetimes, injected token lifetime can be shortened to 1 hour by starting `kube-apiserver` with `--service-account-extend-token-expiration=false`. ([#95667](https://github.com/kubernetes/kubernetes/pull/95667), [@zshihang](https://github.com/zshihang)) [SIG API Machinery, Auth, Cluster Lifecycle and Testing] - -### Feature - -- A new histogram metric to track the time it took to delete a job by the ttl-after-finished controller ([#98676](https://github.com/kubernetes/kubernetes/pull/98676), [@ahg-g](https://github.com/ahg-g)) [SIG Apps and Instrumentation] -- AWS cloudprovider supports auto-discovering subnets without any kubernetes.io/cluster/ tags. It also supports additional service annotation service.beta.kubernetes.io/aws-load-balancer-subnets to manually configure the subnets. ([#97431](https://github.com/kubernetes/kubernetes/pull/97431), [@kishorj](https://github.com/kishorj)) [SIG Cloud Provider] -- Add --permit-address-sharing flag to kube-apiserver to listen with SO_REUSEADDR. While allowing to listen on wildcard IPs like 0.0.0.0 and specific IPs in parallel, it avoid waiting for the kernel to release socket in TIME_WAIT state, and hence, considably reducing kube-apiserver restart times under certain conditions. ([#93861](https://github.com/kubernetes/kubernetes/pull/93861), [@sttts](https://github.com/sttts)) [SIG API Machinery] -- Add `csi_operations_seconds` metric on kubelet that exposes CSI operations duration and status for node CSI operations. ([#98979](https://github.com/kubernetes/kubernetes/pull/98979), [@Jiawei0227](https://github.com/Jiawei0227)) [SIG Instrumentation and Storage] -- Add `migrated` field into `storage_operation_duration_seconds` metric ([#99050](https://github.com/kubernetes/kubernetes/pull/99050), [@Jiawei0227](https://github.com/Jiawei0227)) [SIG Apps, Instrumentation and Storage] -- Add bash-completion for comma separated list on `kubectl get` ([#98301](https://github.com/kubernetes/kubernetes/pull/98301), [@phil9909](https://github.com/phil9909)) [SIG CLI] -- Added support for installing arm64 node artifacts. ([#99242](https://github.com/kubernetes/kubernetes/pull/99242), [@liu-cong](https://github.com/liu-cong)) [SIG Cloud Provider] -- Feature gate RootCAConfigMap is graduated to GA in 1.21 and will be removed in 1.22. ([#98033](https://github.com/kubernetes/kubernetes/pull/98033), [@zshihang](https://github.com/zshihang)) [SIG API Machinery and Auth] -- Kubeadm: during "init" and "join" perform preflight validation on the host / node name and throw warnings if a name is not compliant ([#99194](https://github.com/kubernetes/kubernetes/pull/99194), [@pacoxu](https://github.com/pacoxu)) [SIG Cluster Lifecycle] -- Kubectl: `kubectl get` will omit managed fields by default now. Users could set `--show-managed-fields` to true to show managedFields when the output format is either `json` or `yaml`. ([#96878](https://github.com/kubernetes/kubernetes/pull/96878), [@knight42](https://github.com/knight42)) [SIG CLI and Testing] -- Metrics can now be disabled explicitly via a command line flag (i.e. '--disabled-metrics=bad_metric1,bad_metric2') ([#99217](https://github.com/kubernetes/kubernetes/pull/99217), [@logicalhan](https://github.com/logicalhan)) [SIG API Machinery, Cluster Lifecycle and Instrumentation] -- TTLAfterFinished is now beta and enabled by default ([#98678](https://github.com/kubernetes/kubernetes/pull/98678), [@ahg-g](https://github.com/ahg-g)) [SIG Apps and Auth] -- The `RunAsGroup` feature has been promoted to GA in this release. ([#94641](https://github.com/kubernetes/kubernetes/pull/94641), [@krmayankk](https://github.com/krmayankk)) [SIG Auth and Node] -- Turn CronJobControllerV2 on by default. ([#98878](https://github.com/kubernetes/kubernetes/pull/98878), [@soltysh](https://github.com/soltysh)) [SIG Apps] -- UDP protocol support for Agnhost connect subcommand ([#98639](https://github.com/kubernetes/kubernetes/pull/98639), [@knabben](https://github.com/knabben)) [SIG Testing] -- Upgrades `IPv6Dualstack` to `Beta` and turns it on by default. Clusters new and existing will not be affected until user starting adding secondary pod and service cidrs cli flags as described here: https://github.com/kubernetes/enhancements/tree/master/keps/sig-network/563-dual-stack ([#98969](https://github.com/kubernetes/kubernetes/pull/98969), [@khenidak](https://github.com/khenidak)) [SIG API Machinery, Apps, Cloud Provider, Network and Node] - -### Documentation - -- Fix ALPHA stability level reference link ([#98641](https://github.com/kubernetes/kubernetes/pull/98641), [@Jeffwan](https://github.com/Jeffwan)) [SIG Auth, Cloud Provider, Instrumentation and Storage] - -### Failing Test - -- Escape the special characters like `[`, `]` and ` ` that exist in vsphere windows path ([#98830](https://github.com/kubernetes/kubernetes/pull/98830), [@liyanhui1228](https://github.com/liyanhui1228)) [SIG Storage and Windows] -- Kube-proxy: fix a bug on UDP NodePort Services where stale conntrack entries may blackhole the traffic directed to the NodePort. ([#98305](https://github.com/kubernetes/kubernetes/pull/98305), [@aojea](https://github.com/aojea)) [SIG Network] - -### Bug or Regression - -- Add missing --kube-api-content-type in kubemark hollow template ([#98911](https://github.com/kubernetes/kubernetes/pull/98911), [@Jeffwan](https://github.com/Jeffwan)) [SIG Scalability and Testing] -- Avoid duplicate error messages when runing kubectl edit quota ([#98201](https://github.com/kubernetes/kubernetes/pull/98201), [@pacoxu](https://github.com/pacoxu)) [SIG API Machinery and Apps] -- Cleanup subnet in frontend IP configs to prevent huge subnet request bodies in some scenarios. ([#98133](https://github.com/kubernetes/kubernetes/pull/98133), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider] -- Fix errors when accessing Windows container stats for Dockershim ([#98510](https://github.com/kubernetes/kubernetes/pull/98510), [@jsturtevant](https://github.com/jsturtevant)) [SIG Node and Windows] -- Fixes spurious errors about IPv6 in kube-proxy logs on nodes with IPv6 disabled. ([#99127](https://github.com/kubernetes/kubernetes/pull/99127), [@danwinship](https://github.com/danwinship)) [SIG Network and Node] -- In the method that ensures that the docker and containerd are in the correct containers with the proper OOM score set up, fixed the bug of identifying containerd process. ([#97888](https://github.com/kubernetes/kubernetes/pull/97888), [@pacoxu](https://github.com/pacoxu)) [SIG Node] -- Kubelet now cleans up orphaned volume directories automatically ([#95301](https://github.com/kubernetes/kubernetes/pull/95301), [@lorenz](https://github.com/lorenz)) [SIG Node and Storage] -- When dynamically provisioning Azure File volumes for a premium account, the requested size will be set to 100GB if the request is initially lower than this value to accommodate Azure File requirements. ([#99122](https://github.com/kubernetes/kubernetes/pull/99122), [@huffmanca](https://github.com/huffmanca)) [SIG Cloud Provider and Storage] - -### Other (Cleanup or Flake) - -- APIs for kubelet annotations and labels from k8s.io/kubernetes/pkg/kubelet/apis are now available under k8s.io/kubelet/pkg/apis/ ([#98931](https://github.com/kubernetes/kubernetes/pull/98931), [@michaelbeaumont](https://github.com/michaelbeaumont)) [SIG Apps, Auth and Node] -- Migrate `pkg/kubelet/(pod, pleg)` to structured logging ([#98990](https://github.com/kubernetes/kubernetes/pull/98990), [@gjkim42](https://github.com/gjkim42)) [SIG Instrumentation and Node] -- Migrate pkg/kubelet/nodestatus to structured logging ([#99001](https://github.com/kubernetes/kubernetes/pull/99001), [@QiWang19](https://github.com/QiWang19)) [SIG Node] -- Migrate pkg/kubelet/server logs to structured logging ([#98643](https://github.com/kubernetes/kubernetes/pull/98643), [@chenyw1990](https://github.com/chenyw1990)) [SIG Node] -- Migrate proxy/winkernel/proxier.go logs to structured logging ([#98001](https://github.com/kubernetes/kubernetes/pull/98001), [@JornShen](https://github.com/JornShen)) [SIG Network and Windows] -- Migrate scheduling_queue.go to structured logging ([#98358](https://github.com/kubernetes/kubernetes/pull/98358), [@tanjing2020](https://github.com/tanjing2020)) [SIG Scheduling] -- Several flags related to the deprecated dockershim which are present in the kubelet command line are now deprecated. ([#98730](https://github.com/kubernetes/kubernetes/pull/98730), [@dims](https://github.com/dims)) [SIG Node] -- The deprecated feature gates `CSIDriverRegistry`, `BlockVolume` and `CSIBlockVolume` are now unconditionally enabled and can no longer be specified in component invocations. ([#98021](https://github.com/kubernetes/kubernetes/pull/98021), [@gavinfish](https://github.com/gavinfish)) [SIG Storage] - -## Dependencies - -### Added -_Nothing has changed._ - -### Changed -- sigs.k8s.io/structured-merge-diff/v4: v4.0.2 → v4.0.3 - -### Removed -_Nothing has changed._ - - - -# v1.21.0-alpha.3 - - -## Downloads for v1.21.0-alpha.3 - -### Source Code - -filename | sha512 hash --------- | ----------- -[kubernetes.tar.gz](https://dl.k8s.io/v1.21.0-alpha.3/kubernetes.tar.gz) | 704ec916a1dbd134c54184d2652671f80ae09274f9d23dbbed312944ebeccbc173e2e6b6949b38bdbbfdaf8aa032844deead5efeda1b3150f9751386d9184bc8 -[kubernetes-src.tar.gz](https://dl.k8s.io/v1.21.0-alpha.3/kubernetes-src.tar.gz) | 57db9e7560cfc9c10e7059cb5faf9c4bd5eb8f9b7964f44f000a417021cf80873184b774e7c66c80d4aba84c14080c6bc335618db3d2e5f276436ae065e25408 - -### Client binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.21.0-alpha.3/kubernetes-client-darwin-amd64.tar.gz) | e2706efda92d5cf4f8b69503bb2f7703a8754407eff7f199bb77847838070e720e5f572126c14daa4c0c03b59bb1a63c1dfdeb6e936a40eff1d5497e871e3409 -[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.21.0-alpha.3/kubernetes-client-linux-386.tar.gz) | 007bb23c576356ed0890bdfd25a0f98d552599e0ffec19fb982591183c7c1f216d8a3ffa3abf15216be12ae5c4b91fdcd48a7306a2d26b007b86a6abd553fc61 -[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.21.0-alpha.3/kubernetes-client-linux-amd64.tar.gz) | 39504b0c610348beba60e8866fff265bad58034f74504951cd894c151a248db718d10f77ebc83f2c38b2d517f8513a46325b38889eefa261ca6dbffeceba50ff -[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.21.0-alpha.3/kubernetes-client-linux-arm.tar.gz) | 30bc2c40d0c759365422ad1651a6fb35909be771f463c5b971caf401f9209525d05256ab70c807e88628dd357c2896745eecf13eda0b748464da97d0a5ef2066 -[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.21.0-alpha.3/kubernetes-client-linux-arm64.tar.gz) | 085cdf574dc8fd33ece667130b8c45830b522a07860e03a2384283b1adea73a9652ef3dfaa566e69ee00aea1a6461608814b3ce7a3f703e4a934304f7ae12f97 -[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.21.0-alpha.3/kubernetes-client-linux-ppc64le.tar.gz) | b34b845037d83ea7b3e2d80a9ede4f889b71b17b93b1445f0d936a36e98c13ed6ada125630a68d9243a5fcd311ee37cdcc0c05da484da8488ea5060bc529dbfc -[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.21.0-alpha.3/kubernetes-client-linux-s390x.tar.gz) | c4758adc7a404b776556efaa79655db2a70777c562145d6ea6887f3335988367a0c2fcd4383e469340f2a768b22e786951de212805ca1cb91104d41c21e0c9ce -[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.21.0-alpha.3/kubernetes-client-windows-386.tar.gz) | f51edc79702bbd1d9cb3a672852a405e11b20feeab64c5411a7e85c9af304960663eb6b23ef96e0f8c44a722fecf58cb6d700ea2c42c05b3269d8efd5ad803f2 -[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.21.0-alpha.3/kubernetes-client-windows-amd64.tar.gz) | 6a3507ce4ac40a0dc7e4720538863fa15f8faf025085a032f34b8fa0f6fa4e8c26849baf649b5b32829b9182e04f82721b13950d31cf218c35be6bf1c05d6abf - -### Server binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.21.0-alpha.3/kubernetes-server-linux-amd64.tar.gz) | 19181d162dfb0b30236e2bf1111000e037eece87c037ca2b24622ca94cb88db86aa4da4ca533522518b209bc9983bbfd6b880a7898e0da96b33f3f6c4690539b -[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.21.0-alpha.3/kubernetes-server-linux-arm.tar.gz) | 42a02f9e08a78ad5da6e5fa1ab12bf1e3c967c472fdbdadbd8746586da74dc8093682ba8513ff2a5301393c47ee9021b860e88ada56b13da386ef485708e46ca -[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.21.0-alpha.3/kubernetes-server-linux-arm64.tar.gz) | 3c8ba8eb02f70061689bd7fab7813542005efe2edc6cfc6b7aecd03ffedf0b81819ad91d69fff588e83023d595eefbfe636aa55e1856add8733bf42fff3c748f -[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.21.0-alpha.3/kubernetes-server-linux-ppc64le.tar.gz) | cd9e6537450411c39a06fd0b5819db3d16b668d403fb3627ec32c0e32dd1c4860e942934578ca0e1d1b8e6f21f450ff81e37e0cd46ff5c5faf7847ab074aefc5 -[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.21.0-alpha.3/kubernetes-server-linux-s390x.tar.gz) | ada3f65e53bc0e0c0229694dd48c425388089d6d77111a62476d1b08f6ad1d8ab3d60b9ed7d95ac1b42c2c6be8dc0618f40679717160769743c43583d8452362 - -### Node binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.21.0-alpha.3/kubernetes-node-linux-amd64.tar.gz) | ae0fec6aa59e49624b55d9a11c12fdf717ddfe04bdfd4f69965d03004a34e52ee4a3e83f7b61d0c6a86f43b72c99f3decb195b39ae529ef30526d18ec5f58f83 -[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.21.0-alpha.3/kubernetes-node-linux-arm.tar.gz) | 9a48c140ab53b7ed8ecec6903988a1a474efc16d2538e5974bc9a12f0c9190be78c4f9e326bf4e982d0b7045a80b99dd0fda7e9b650663be5b89bfd991596746 -[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.21.0-alpha.3/kubernetes-node-linux-arm64.tar.gz) | 6912adbc9300344bea470d6435f7b387bfce59767078c11728ce59faf47cd3f72b41b9604fcc5cda45e9816fe939fbe2fb33e52a773e6ff2dfa9a615b4df6141 -[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.21.0-alpha.3/kubernetes-node-linux-ppc64le.tar.gz) | d66dccfe3e6ed6d81567c70703f15375a53992b3a5e2814b98c32e581b861ad95912e03ed2562415d087624c008038bb4a816611fa255442ae752968ea15856b -[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.21.0-alpha.3/kubernetes-node-linux-s390x.tar.gz) | ad8c69a28f1fbafa3f1cb54909bfd3fc22b104bed63d7ca2b296208c9d43eb5f2943a0ff267da4c185186cdd9f7f77b315cd7f5f1bf9858c0bf42eceb9ac3c58 -[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.21.0-alpha.3/kubernetes-node-windows-amd64.tar.gz) | 91d723aa848a9cb028f5bcb41090ca346fb973961521d025c4399164de2c8029b57ca2c4daca560d3c782c05265d2eb0edb0abcce6f23d3efbecf2316a54d650 - -## Changelog since v1.21.0-alpha.2 - -## Urgent Upgrade Notes - -### (No, really, you MUST read this before you upgrade) - - - Newly provisioned PVs by gce-pd will no longer have the beta FailureDomain label. gce-pd volume plugin will start to have GA topology label instead. ([#98700](https://github.com/kubernetes/kubernetes/pull/98700), [@Jiawei0227](https://github.com/Jiawei0227)) [SIG Cloud Provider, Storage and Testing] - - Remove alpha CSIMigrationXXComplete flag and add alpha InTreePluginXXUnregister flag. Deprecate CSIMigrationvSphereComplete flag and it will be removed in 1.22. ([#98243](https://github.com/kubernetes/kubernetes/pull/98243), [@Jiawei0227](https://github.com/Jiawei0227)) [SIG Node and Storage] - -## Changes by Kind - -### API Change - -- Adds support for portRange / EndPort in Network Policy ([#97058](https://github.com/kubernetes/kubernetes/pull/97058), [@rikatz](https://github.com/rikatz)) [SIG Apps and Network] -- Fixes using server-side apply with APIService resources ([#98576](https://github.com/kubernetes/kubernetes/pull/98576), [@kevindelgado](https://github.com/kevindelgado)) [SIG API Machinery, Apps and Testing] -- Kubernetes is now built using go1.15.7 ([#98363](https://github.com/kubernetes/kubernetes/pull/98363), [@cpanato](https://github.com/cpanato)) [SIG Cloud Provider, Instrumentation, Node, Release and Testing] -- Scheduler extender filter interface now can report unresolvable failed nodes in the new field `FailedAndUnresolvableNodes` of `ExtenderFilterResult` struct. Nodes in this map will be skipped in the preemption phase. ([#92866](https://github.com/kubernetes/kubernetes/pull/92866), [@cofyc](https://github.com/cofyc)) [SIG Scheduling] - -### Feature - -- A lease can only attach up to 10k objects. ([#98257](https://github.com/kubernetes/kubernetes/pull/98257), [@lingsamuel](https://github.com/lingsamuel)) [SIG API Machinery] -- Add ignore-errors flag for drain, support none-break drain in group ([#98203](https://github.com/kubernetes/kubernetes/pull/98203), [@yuzhiquan](https://github.com/yuzhiquan)) [SIG CLI] -- Base-images: Update to debian-iptables:buster-v1.4.0 - - Uses iptables 1.8.5 - - base-images: Update to debian-base:buster-v1.3.0 - - cluster/images/etcd: Build etcd:3.4.13-2 image - - Uses debian-base:buster-v1.3.0 ([#98401](https://github.com/kubernetes/kubernetes/pull/98401), [@pacoxu](https://github.com/pacoxu)) [SIG Testing] -- Export NewDebuggingRoundTripper function and DebugLevel options in the k8s.io/client-go/transport package. ([#98324](https://github.com/kubernetes/kubernetes/pull/98324), [@atosatto](https://github.com/atosatto)) [SIG API Machinery] -- Kubectl wait ensures that observedGeneration >= generation if applicable ([#97408](https://github.com/kubernetes/kubernetes/pull/97408), [@KnicKnic](https://github.com/KnicKnic)) [SIG CLI] -- Kubernetes is now built using go1.15.8 ([#98834](https://github.com/kubernetes/kubernetes/pull/98834), [@cpanato](https://github.com/cpanato)) [SIG Cloud Provider, Instrumentation, Release and Testing] -- New admission controller "denyserviceexternalips" is available. Clusters which do not *need- the Service "externalIPs" feature should enable this controller and be more secure. ([#97395](https://github.com/kubernetes/kubernetes/pull/97395), [@thockin](https://github.com/thockin)) [SIG API Machinery] -- Overall, enable the feature of `PreferNominatedNode` will improve the performance of scheduling where preemption might frequently happen, but in theory, enable the feature of `PreferNominatedNode`, the pod might not be scheduled to the best candidate node in the cluster. ([#93179](https://github.com/kubernetes/kubernetes/pull/93179), [@chendave](https://github.com/chendave)) [SIG Scheduling and Testing] -- Pause image upgraded to 3.4.1 in kubelet and kubeadm for both Linux and Windows. ([#98205](https://github.com/kubernetes/kubernetes/pull/98205), [@pacoxu](https://github.com/pacoxu)) [SIG CLI, Cloud Provider, Cluster Lifecycle, Node, Testing and Windows] -- The `ServiceAccountIssuerDiscovery` feature has graduated to GA, and is unconditionally enabled. The `ServiceAccountIssuerDiscovery` feature-gate will be removed in 1.22. ([#98553](https://github.com/kubernetes/kubernetes/pull/98553), [@mtaufen](https://github.com/mtaufen)) [SIG API Machinery, Auth and Testing] - -### Documentation - -- Feat: azure file migration go beta in 1.21. Feature gates CSIMigration to Beta (on by default) and CSIMigrationAzureFile to Beta (off by default since it requires installation of the AzureFile CSI Driver) - The in-tree AzureFile plugin "kubernetes.io/azure-file" is now deprecated and will be removed in 1.23. Users should enable CSIMigration + CSIMigrationAzureFile features and install the AzureFile CSI Driver (https://github.com/kubernetes-sigs/azurefile-csi-driver) to avoid disruption to existing Pod and PVC objects at that time. - Users should start using the AzureFile CSI Driver directly for any new volumes. ([#96293](https://github.com/kubernetes/kubernetes/pull/96293), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] - -### Failing Test - -- Kubelet: the HostPort implementation in dockershim was not taking into consideration the HostIP field, causing that the same HostPort can not be used with different IP addresses. - This bug causes the conformance test "HostPort validates that there is no conflict between pods with same hostPort but different hostIP and protocol" to fail. ([#98755](https://github.com/kubernetes/kubernetes/pull/98755), [@aojea](https://github.com/aojea)) [SIG Cloud Provider, Network and Node] - -### Bug or Regression - -- Fix NPE in ephemeral storage eviction ([#98261](https://github.com/kubernetes/kubernetes/pull/98261), [@wzshiming](https://github.com/wzshiming)) [SIG Node] -- Fixed a bug that on k8s nodes, when the policy of INPUT chain in filter table is not ACCEPT, healthcheck nodeport would not work. - Added iptables rules to allow healthcheck nodeport traffic. ([#97824](https://github.com/kubernetes/kubernetes/pull/97824), [@hanlins](https://github.com/hanlins)) [SIG Network] -- Fixed kube-proxy container image architecture for non amd64 images. ([#98526](https://github.com/kubernetes/kubernetes/pull/98526), [@saschagrunert](https://github.com/saschagrunert)) [SIG API Machinery, Release and Testing] -- Fixed provisioning of Cinder volumes migrated to CSI when StorageClass with AllowedTopologies was used. ([#98311](https://github.com/kubernetes/kubernetes/pull/98311), [@jsafrane](https://github.com/jsafrane)) [SIG Storage] -- Fixes a panic in the disruption budget controller for PDB objects with invalid selectors ([#98750](https://github.com/kubernetes/kubernetes/pull/98750), [@mortent](https://github.com/mortent)) [SIG Apps] -- Fixes connection errors when using `--volume-host-cidr-denylist` or `--volume-host-allow-local-loopback` ([#98436](https://github.com/kubernetes/kubernetes/pull/98436), [@liggitt](https://github.com/liggitt)) [SIG Network and Storage] -- If the user specifies an invalid timeout in the request URL, the request will be aborted with an HTTP 400. - - in cases where the client specifies a timeout in the request URL, the overall request deadline is shortened now since the deadline is setup as soon as the request is received by the apiserver. ([#96901](https://github.com/kubernetes/kubernetes/pull/96901), [@tkashem](https://github.com/tkashem)) [SIG API Machinery and Testing] -- Kubeadm: Some text in the `kubeadm upgrade plan` output has changed. If you have scripts or other automation that parses this output, please review these changes and update your scripts to account for the new output. ([#98728](https://github.com/kubernetes/kubernetes/pull/98728), [@stmcginnis](https://github.com/stmcginnis)) [SIG Cluster Lifecycle] -- Kubeadm: fix a bug where external credentials in an existing admin.conf prevented the CA certificate to be written in the cluster-info ConfigMap. ([#98882](https://github.com/kubernetes/kubernetes/pull/98882), [@kvaps](https://github.com/kvaps)) [SIG Cluster Lifecycle] -- Kubeadm: fix bad token placeholder text in "config print *-defaults --help" ([#98839](https://github.com/kubernetes/kubernetes/pull/98839), [@Mattias-](https://github.com/Mattias-)) [SIG Cluster Lifecycle] -- Kubeadm: get k8s CI version markers from k8s infra bucket ([#98836](https://github.com/kubernetes/kubernetes/pull/98836), [@hasheddan](https://github.com/hasheddan)) [SIG Cluster Lifecycle and Release] -- Mitigate CVE-2020-8555 for kube-up using GCE by preventing local loopback folume hosts. ([#97934](https://github.com/kubernetes/kubernetes/pull/97934), [@mattcary](https://github.com/mattcary)) [SIG Cloud Provider and Storage] -- Remove CSI topology from migrated in-tree gcepd volume. ([#97823](https://github.com/kubernetes/kubernetes/pull/97823), [@Jiawei0227](https://github.com/Jiawei0227)) [SIG Cloud Provider and Storage] -- Sync node status during kubelet node shutdown. - Adds an pod admission handler that rejects new pods when the node is in progress of shutting down. ([#98005](https://github.com/kubernetes/kubernetes/pull/98005), [@wzshiming](https://github.com/wzshiming)) [SIG Node] -- Truncates a message if it hits the NoteLengthLimit when the scheduler records an event for the pod that indicates the pod has failed to schedule. ([#98715](https://github.com/kubernetes/kubernetes/pull/98715), [@carlory](https://github.com/carlory)) [SIG Scheduling] -- We will no longer automatically delete all data when a failure is detected during creation of the volume data file on a CSI volume. Now we will only remove the data file and volume path. ([#96021](https://github.com/kubernetes/kubernetes/pull/96021), [@huffmanca](https://github.com/huffmanca)) [SIG Storage] - -### Other (Cleanup or Flake) - -- Fix the description of command line flags that can override --config ([#98254](https://github.com/kubernetes/kubernetes/pull/98254), [@changshuchao](https://github.com/changshuchao)) [SIG Scheduling] -- Migrate scheduler/taint_manager.go structured logging ([#98259](https://github.com/kubernetes/kubernetes/pull/98259), [@tanjing2020](https://github.com/tanjing2020)) [SIG Apps] -- Migrate staging/src/k8s.io/apiserver/pkg/admission logs to structured logging ([#98138](https://github.com/kubernetes/kubernetes/pull/98138), [@lala123912](https://github.com/lala123912)) [SIG API Machinery] -- Resolves flakes in the Ingress conformance tests due to conflicts with controllers updating the Ingress object ([#98430](https://github.com/kubernetes/kubernetes/pull/98430), [@liggitt](https://github.com/liggitt)) [SIG Network and Testing] -- The default delegating authorization options now allow unauthenticated access to healthz, readyz, and livez. A system:masters user connecting to an authz delegator will not perform an authz check. ([#98325](https://github.com/kubernetes/kubernetes/pull/98325), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, Auth, Cloud Provider and Scheduling] -- The e2e suite can be instructed not to wait for pods in kube-system to be ready or for all nodes to be ready by passing `--allowed-not-ready-nodes=-1` when invoking the e2e.test program. This allows callers to run subsets of the e2e suite in scenarios other than perfectly healthy clusters. ([#98781](https://github.com/kubernetes/kubernetes/pull/98781), [@smarterclayton](https://github.com/smarterclayton)) [SIG Testing] -- The feature gates `WindowsGMSA` and `WindowsRunAsUserName` that are GA since v1.18 are now removed. ([#96531](https://github.com/kubernetes/kubernetes/pull/96531), [@ialidzhikov](https://github.com/ialidzhikov)) [SIG Node and Windows] -- The new `-gce-zones` flag on the `e2e.test` binary instructs tests that check for information about how the cluster interacts with the cloud to limit their queries to the provided zone list. If not specified, the current behavior of asking the cloud provider for all available zones in multi zone clusters is preserved. ([#98787](https://github.com/kubernetes/kubernetes/pull/98787), [@smarterclayton](https://github.com/smarterclayton)) [SIG API Machinery, Cluster Lifecycle and Testing] - -## Dependencies - -### Added -- github.com/moby/spdystream: [v0.2.0](https://github.com/moby/spdystream/tree/v0.2.0) - -### Changed -- github.com/NYTimes/gziphandler: [56545f4 → v1.1.1](https://github.com/NYTimes/gziphandler/compare/56545f4...v1.1.1) -- github.com/container-storage-interface/spec: [v1.2.0 → v1.3.0](https://github.com/container-storage-interface/spec/compare/v1.2.0...v1.3.0) -- github.com/go-logr/logr: [v0.2.0 → v0.4.0](https://github.com/go-logr/logr/compare/v0.2.0...v0.4.0) -- github.com/gogo/protobuf: [v1.3.1 → v1.3.2](https://github.com/gogo/protobuf/compare/v1.3.1...v1.3.2) -- github.com/kisielk/errcheck: [v1.2.0 → v1.5.0](https://github.com/kisielk/errcheck/compare/v1.2.0...v1.5.0) -- github.com/yuin/goldmark: [v1.1.27 → v1.2.1](https://github.com/yuin/goldmark/compare/v1.1.27...v1.2.1) -- golang.org/x/sync: cd5d95a → 67f06af -- golang.org/x/tools: c1934b7 → 113979e -- k8s.io/klog/v2: v2.4.0 → v2.5.0 -- sigs.k8s.io/apiserver-network-proxy/konnectivity-client: v0.0.14 → v0.0.15 - -### Removed -- github.com/docker/spdystream: [449fdfc](https://github.com/docker/spdystream/tree/449fdfc) - - - -# v1.21.0-alpha.2 - - -## Downloads for v1.21.0-alpha.2 - -### Source Code - -filename | sha512 hash --------- | ----------- -[kubernetes.tar.gz](https://dl.k8s.io/v1.21.0-alpha.2/kubernetes.tar.gz) | 6836f6c8514253fe0831fd171fc4ed92eb6d9a773491c8dc82b90d171a1b10076bd6bfaea56ec1e199c5f46c273265bdb9f174f0b2d99c5af1de4c99b862329e -[kubernetes-src.tar.gz](https://dl.k8s.io/v1.21.0-alpha.2/kubernetes-src.tar.gz) | d137694804741a05ab09e5f9a418448b66aba0146c028eafce61bcd9d7c276521e345ce9223ffbc703e8172041d58dfc56a3242a4df3686f24905a4541fcd306 - -### Client binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.21.0-alpha.2/kubernetes-client-darwin-amd64.tar.gz) | 9478b047a97717953f365c13a098feb7e3cb30a3df22e1b82aa945f2208dcc5cb90afc441ba059a3ae7aafb4ee000ec3a52dc65a8c043a5ac7255a391c875330 -[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.21.0-alpha.2/kubernetes-client-linux-386.tar.gz) | 44c8dd4b1ddfc256d35786c8abf45b0eb5f0794f5e310d2efc865748adddc50e8bf38aa71295ae8a82884cb65f2e0b9b0737b000f96fd8f2d5c19971d7c4d8e8 -[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.21.0-alpha.2/kubernetes-client-linux-amd64.tar.gz) | e1291989892769de6b978c17b8612b94da6f3b735a4d895100af622ca9ebb968c75548afea7ab00445869625dd0da3afec979e333afbb445805f5d31c1c13cc7 -[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.21.0-alpha.2/kubernetes-client-linux-arm.tar.gz) | 3c4bcb8cbe73822d68a2f62553a364e20bec56b638c71d0f58679b4f4b277d809142346f18506914e694f6122a3e0f767eab20b7b1c4dbb79e4c5089981ae0f1 -[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.21.0-alpha.2/kubernetes-client-linux-arm64.tar.gz) | 9389974a790268522e187f5ba5237f3ee4684118c7db76bc3d4164de71d8208702747ec333b204c7a78073ab42553cbbce13a1883fab4fec617e093b05fab332 -[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.21.0-alpha.2/kubernetes-client-linux-ppc64le.tar.gz) | 63399e53a083b5af3816c28ff162c9de6b64c75da4647f0d6bbaf97afdf896823cb1e556f2abac75c6516072293026d3ff9f30676fd75143ac6ca3f4d21f4327 -[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.21.0-alpha.2/kubernetes-client-linux-s390x.tar.gz) | 50898f197a9d923971ff9046c9f02779b57f7b3cea7da02f3ea9bab8c08d65a9c4a7531a2470fa14783460f52111a52b96ebf916c0a1d8215b4070e4e861c1b0 -[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.21.0-alpha.2/kubernetes-client-windows-386.tar.gz) | a7743e839e1aa19f5ee20b6ee5000ac8ef9e624ac5be63bb574fad6992e4b9167193ed07e03c9bc524e88bfeed66c95341a38a03bff1b10bc9910345f33019f0 -[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.21.0-alpha.2/kubernetes-client-windows-amd64.tar.gz) | 5f1d19c230bd3542866d16051808d184e9dd3e2f8c001ed4cee7b5df91f872380c2bf56a3add8c9413ead9d8c369efce2bcab4412174df9b823d3592677bf74e - -### Server binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.21.0-alpha.2/kubernetes-server-linux-amd64.tar.gz) | ef2cac10febde231aeb6f131e589450c560eeaab8046b49504127a091cddc17bc518c2ad56894a6a033033ab6fc6e121b1cc23691683bc36f45fe6b1dd8e0510 -[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.21.0-alpha.2/kubernetes-server-linux-arm.tar.gz) | d11c9730307f08e80b2b8a7c64c3e9a9e43c622002e377dfe3a386f4541e24adc79a199a6f280f40298bb36793194fd44ed45defe8a3ee54a9cb1386bc26e905 -[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.21.0-alpha.2/kubernetes-server-linux-arm64.tar.gz) | 28f8c32bf98ee1add7edf5d341c3bac1afc0085f90dcbbfb8b27a92087f13e2b53c327c8935ee29bf1dc3160655b32bbe3e29d5741a8124a3848a777e7d42933 -[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.21.0-alpha.2/kubernetes-server-linux-ppc64le.tar.gz) | 99ae8d44b0de3518c27fa8bbddd2ecf053dfb789fb9d65f8a4ecf4c8331cf63d2f09a41c2bcd5573247d5f66a1b2e51944379df1715017d920d521b98589508a -[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.21.0-alpha.2/kubernetes-server-linux-s390x.tar.gz) | f8c0e954a2dfc6845614488dadeed069cc7f3f08e33c351d7a77c6ef97867af590932e8576d12998a820a0e4d35d2eee797c764e2810f09ab1e90a5acaeaad33 - -### Node binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.21.0-alpha.2/kubernetes-node-linux-amd64.tar.gz) | c5456d50bfbe0d75fb150b3662ed7468a0abd3970792c447824f326894382c47bbd3a2cc5a290f691c8c09585ff6fe505ab86b4aff2b7e5ccee11b5e6354ae6c -[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.21.0-alpha.2/kubernetes-node-linux-arm.tar.gz) | 335b5cd8672e053302fd94d932fb2fa2e48eeeb1799650b3f93acdfa635e03a8453637569ab710c46885c8317759f4c60aaaf24dca9817d9fa47500fe4a3ca53 -[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.21.0-alpha.2/kubernetes-node-linux-arm64.tar.gz) | 3ee87dbeed8ace9351ac89bdaf7274dd10b4faec3ceba0825f690ec7a2bb7eb7c634274a1065a0939eec8ff3e43f72385f058f4ec141841550109e775bc5eff9 -[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.21.0-alpha.2/kubernetes-node-linux-ppc64le.tar.gz) | 6956f965b8d719b164214ec9195fdb2c776b907fe6d2c524082f00c27872a73475927fd7d2a994045ce78f6ad2aa5aeaf1eb5514df1810d2cfe342fd4e5ce4a1 -[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.21.0-alpha.2/kubernetes-node-linux-s390x.tar.gz) | 3b643aa905c709c57083c28dd9e8ffd88cb64466cda1499da7fc54176b775003e08b9c7a07b0964064df67c8142f6f1e6c13bfc261bd65fb064049920bfa57d0 -[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.21.0-alpha.2/kubernetes-node-windows-amd64.tar.gz) | b2e6d6fb0091f2541f9925018c2bdbb0138a95bab06b4c6b38abf4b7144b2575422263b78fb3c6fd09e76d90a25a8d35a6d4720dc169794d42c95aa22ecc6d5f - -## Changelog since v1.21.0-alpha.1 - -## Urgent Upgrade Notes - -### (No, really, you MUST read this before you upgrade) - - - Remove storage metrics `storage_operation_errors_total`, since we already have `storage_operation_status_count`.And add new field `status` for `storage_operation_duration_seconds`, so that we can know about all status storage operation latency. ([#98332](https://github.com/kubernetes/kubernetes/pull/98332), [@JornShen](https://github.com/JornShen)) [SIG Instrumentation and Storage] - -## Changes by Kind - -### Deprecation - -- Remove the TokenRequest and TokenRequestProjection feature gates ([#97148](https://github.com/kubernetes/kubernetes/pull/97148), [@wawa0210](https://github.com/wawa0210)) [SIG Node] -- Removing experimental windows container hyper-v support with Docker ([#97141](https://github.com/kubernetes/kubernetes/pull/97141), [@wawa0210](https://github.com/wawa0210)) [SIG Node and Windows] -- The `export` query parameter (inconsistently supported by API resources and deprecated in v1.14) is fully removed. Requests setting this query parameter will now receive a 400 status response. ([#98312](https://github.com/kubernetes/kubernetes/pull/98312), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, Auth and Testing] - -### API Change - -- Enable SPDY pings to keep connections alive, so that `kubectl exec` and `kubectl port-forward` won't be interrupted. ([#97083](https://github.com/kubernetes/kubernetes/pull/97083), [@knight42](https://github.com/knight42)) [SIG API Machinery and CLI] - -### Documentation - -- Official support to build kubernetes with docker-machine / remote docker is removed. This change does not affect building kubernetes with docker locally. ([#97935](https://github.com/kubernetes/kubernetes/pull/97935), [@adeniyistephen](https://github.com/adeniyistephen)) [SIG Release and Testing] -- Set kubelet option `--volume-stats-agg-period` to negative value to disable volume calculations. ([#96675](https://github.com/kubernetes/kubernetes/pull/96675), [@pacoxu](https://github.com/pacoxu)) [SIG Node] - -### Bug or Regression - -- Clean ReplicaSet by revision instead of creation timestamp in deployment controller ([#97407](https://github.com/kubernetes/kubernetes/pull/97407), [@waynepeking348](https://github.com/waynepeking348)) [SIG Apps] -- Ensure that client-go's EventBroadcaster is safe (non-racy) during shutdown. ([#95664](https://github.com/kubernetes/kubernetes/pull/95664), [@DirectXMan12](https://github.com/DirectXMan12)) [SIG API Machinery] -- Fix azure file migration issue ([#97877](https://github.com/kubernetes/kubernetes/pull/97877), [@andyzhangx](https://github.com/andyzhangx)) [SIG Auth, Cloud Provider and Storage] -- Fix kubelet from panic after getting the wrong signal ([#98200](https://github.com/kubernetes/kubernetes/pull/98200), [@wzshiming](https://github.com/wzshiming)) [SIG Node] -- Fix repeatedly acquire the inhibit lock ([#98088](https://github.com/kubernetes/kubernetes/pull/98088), [@wzshiming](https://github.com/wzshiming)) [SIG Node] -- Fixed a bug that the kubelet cannot start on BtrfS. ([#98042](https://github.com/kubernetes/kubernetes/pull/98042), [@gjkim42](https://github.com/gjkim42)) [SIG Node] -- Fixed an issue with garbage collection failing to clean up namespaced children of an object also referenced incorrectly by cluster-scoped children ([#98068](https://github.com/kubernetes/kubernetes/pull/98068), [@liggitt](https://github.com/liggitt)) [SIG API Machinery and Apps] -- Fixed no effect namespace when exposing deployment with --dry-run=client. ([#97492](https://github.com/kubernetes/kubernetes/pull/97492), [@masap](https://github.com/masap)) [SIG CLI] -- Fixing a bug where a failed node may not have the NoExecute taint set correctly ([#96876](https://github.com/kubernetes/kubernetes/pull/96876), [@howieyuen](https://github.com/howieyuen)) [SIG Apps and Node] -- Indentation of `Resource Quota` block in kubectl describe namespaces output gets correct. ([#97946](https://github.com/kubernetes/kubernetes/pull/97946), [@dty1er](https://github.com/dty1er)) [SIG CLI] -- KUBECTL_EXTERNAL_DIFF now accepts equal sign for additional parameters. ([#98158](https://github.com/kubernetes/kubernetes/pull/98158), [@dougsland](https://github.com/dougsland)) [SIG CLI] -- Kubeadm: fix a bug where "kubeadm join" would not properly handle missing names for existing etcd members. ([#97372](https://github.com/kubernetes/kubernetes/pull/97372), [@ihgann](https://github.com/ihgann)) [SIG Cluster Lifecycle] -- Kubelet should ignore cgroup driver check on Windows node. ([#97764](https://github.com/kubernetes/kubernetes/pull/97764), [@pacoxu](https://github.com/pacoxu)) [SIG Node and Windows] -- Make podTopologyHints protected by lock ([#95111](https://github.com/kubernetes/kubernetes/pull/95111), [@choury](https://github.com/choury)) [SIG Node] -- Readjust kubelet_containers_per_pod_count bucket ([#98169](https://github.com/kubernetes/kubernetes/pull/98169), [@wawa0210](https://github.com/wawa0210)) [SIG Instrumentation and Node] -- Scores from InterPodAffinity have stronger differentiation. ([#98096](https://github.com/kubernetes/kubernetes/pull/98096), [@leileiwan](https://github.com/leileiwan)) [SIG Scheduling] -- Specifying the KUBE_TEST_REPO environment variable when e2e tests are executed will instruct the test infrastructure to load that image from a location within the specified repo, using a predefined pattern. ([#93510](https://github.com/kubernetes/kubernetes/pull/93510), [@smarterclayton](https://github.com/smarterclayton)) [SIG Testing] -- Static pods will be deleted gracefully. ([#98103](https://github.com/kubernetes/kubernetes/pull/98103), [@gjkim42](https://github.com/gjkim42)) [SIG Node] -- Use network.Interface.VirtualMachine.ID to get the binded VM - Skip standalone VM when reconciling LoadBalancer ([#97635](https://github.com/kubernetes/kubernetes/pull/97635), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider] - -### Other (Cleanup or Flake) - -- Kubeadm: change the default image repository for CI images from 'gcr.io/kubernetes-ci-images' to 'gcr.io/k8s-staging-ci-images' ([#97087](https://github.com/kubernetes/kubernetes/pull/97087), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle] -- Migrate generic_scheduler.go and types.go to structured logging. ([#98134](https://github.com/kubernetes/kubernetes/pull/98134), [@tanjing2020](https://github.com/tanjing2020)) [SIG Scheduling] -- Migrate proxy/winuserspace/proxier.go logs to structured logging ([#97941](https://github.com/kubernetes/kubernetes/pull/97941), [@JornShen](https://github.com/JornShen)) [SIG Network] -- Migrate staging/src/k8s.io/apiserver/pkg/audit/policy/reader.go logs to structured logging. ([#98252](https://github.com/kubernetes/kubernetes/pull/98252), [@lala123912](https://github.com/lala123912)) [SIG API Machinery and Auth] -- Migrate staging\src\k8s.io\apiserver\pkg\endpoints logs to structured logging ([#98093](https://github.com/kubernetes/kubernetes/pull/98093), [@lala123912](https://github.com/lala123912)) [SIG API Machinery] -- Node ([#96552](https://github.com/kubernetes/kubernetes/pull/96552), [@pandaamanda](https://github.com/pandaamanda)) [SIG Apps, Cloud Provider, Node and Scheduling] -- The kubectl alpha debug command was scheduled to be removed in v1.21. ([#98111](https://github.com/kubernetes/kubernetes/pull/98111), [@pandaamanda](https://github.com/pandaamanda)) [SIG CLI] -- Update cri-tools to [v1.20.0](https://github.com/kubernetes-sigs/cri-tools/releases/tag/v1.20.0) ([#97967](https://github.com/kubernetes/kubernetes/pull/97967), [@rajibmitra](https://github.com/rajibmitra)) [SIG Cloud Provider] -- Windows nodes on GCE will take longer to start due to dependencies installed at node creation time. ([#98284](https://github.com/kubernetes/kubernetes/pull/98284), [@pjh](https://github.com/pjh)) [SIG Cloud Provider] - -## Dependencies - -### Added -_Nothing has changed._ - -### Changed -- github.com/google/cadvisor: [v0.38.6 → v0.38.7](https://github.com/google/cadvisor/compare/v0.38.6...v0.38.7) -- k8s.io/gengo: 83324d8 → b6c5ce2 - -### Removed -_Nothing has changed._ - - - -# v1.21.0-alpha.1 - - -## Downloads for v1.21.0-alpha.1 - -### Source Code - -filename | sha512 hash --------- | ----------- -[kubernetes.tar.gz](https://dl.k8s.io/v1.21.0-alpha.1/kubernetes.tar.gz) | b2bacd5c3fc9f829e6269b7d2006b0c6e464ff848bb0a2a8f2fe52ad2d7c4438f099bd8be847d8d49ac6e4087f4d74d5c3a967acd798e0b0cb4d7a2bdb122997 -[kubernetes-src.tar.gz](https://dl.k8s.io/v1.21.0-alpha.1/kubernetes-src.tar.gz) | 518ac5acbcf23902fb1b902b69dbf3e86deca5d8a9b5f57488a15f185176d5a109558f3e4df062366af874eca1bcd61751ee8098b0beb9bcdc025d9a1c9be693 - -### Client binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.21.0-alpha.1/kubernetes-client-darwin-amd64.tar.gz) | eaa7aea84a5ed954df5ec710cbeb6ec88b46465f43cb3d09aabe2f714b84a050a50bf5736089f09dbf1090f2e19b44823d656c917e3c8c877630756c3026f2b6 -[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.21.0-alpha.1/kubernetes-client-linux-386.tar.gz) | 47f74b8d46ad1779c5b0b5f15aa15d5513a504eeb6f53db4201fbe9ff8956cb986b7c1b0e9d50a99f78e9e2a7f304f3fc1cc2fa239296d9a0dd408eb6069e975 -[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.21.0-alpha.1/kubernetes-client-linux-amd64.tar.gz) | 1a148e282628b008c8abd03dd12ec177ced17584b5115d92cd33dd251e607097d42e9da8c7089bd947134b900f85eb75a4740b6a5dd580c105455b843559df39 -[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.21.0-alpha.1/kubernetes-client-linux-arm.tar.gz) | d13d2feb73bd032dc01f7e2955b98d8215a39fe1107d037a73fa1f7d06c3b93ebaa53ed4952d845c64454ef3cca533edb97132d234d50b6fb3bcbd8a8ad990eb -[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.21.0-alpha.1/kubernetes-client-linux-arm64.tar.gz) | 8252105a17b09a78e9ad2c024e4e401a69764ac869708a071aaa06f81714c17b9e7c5b2eb8efde33f24d0b59f75c5da607d5e1e72bdf12adfbb8c829205cd1c1 -[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.21.0-alpha.1/kubernetes-client-linux-ppc64le.tar.gz) | 297a9082df4988389dc4be30eb636dff49f36f5d87047bab44745884e610f46a17ae3a08401e2cab155b7c439f38057bfd8288418215f7dd3bf6a49dbe61ea0e -[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.21.0-alpha.1/kubernetes-client-linux-s390x.tar.gz) | 04c06490dd17cd5dccfd92bafa14acf64280ceaea370d9635f23aeb6984d1beae6d0d1d1506edc6f30f927deeb149b989d3e482b47fbe74008b371f629656e79 -[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.21.0-alpha.1/kubernetes-client-windows-386.tar.gz) | ec6e9e87a7d685f8751d7e58f24f417753cff5554a7229218cb3a08195d461b2e12409344950228e9fbbc92a8a06d35dd86242da6ff1e6652ec1fae0365a88c1 -[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.21.0-alpha.1/kubernetes-client-windows-amd64.tar.gz) | 51039e6221d3126b5d15e797002ae01d4f0b10789c5d2056532f27ef13f35c5a2e51be27764fda68e8303219963126559023aed9421313bec275c0827fbcaf8a - -### Server binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.21.0-alpha.1/kubernetes-server-linux-amd64.tar.gz) | 4edf820930c88716263560275e3bd7fadb8dc3700b9f8e1d266562e356e0abeb1a913f536377dab91218e3940b447d6bf1da343b85da25c2256dc4dcde5798dd -[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.21.0-alpha.1/kubernetes-server-linux-arm.tar.gz) | b15213e53a8ab4ba512ce6ef9ad42dd197d419c61615cd23de344227fd846c90448d8f3d98e555b63ba5b565afa627cca6b7e3990ebbbba359c96f2391302df1 -[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.21.0-alpha.1/kubernetes-server-linux-arm64.tar.gz) | 5be29cca9a9358fc68351ee63e99d57dc2ffce6e42fc3345753dbbf7542ff2d770c4852424158540435fa6e097ce3afa9b13affc40c8b3b69fe8406798f8068f -[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.21.0-alpha.1/kubernetes-server-linux-ppc64le.tar.gz) | 89fd99ab9ce85db0b94b86709932105efc883cc93959cf7ea9a39e79a4acea23064d7010eeb577450cccabe521c04b7ba47bbec212ed37edeed7cb04bad34518 -[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.21.0-alpha.1/kubernetes-server-linux-s390x.tar.gz) | 2fbc30862c77d247aa8d96ab9d1a144599505287b0033a3a2d0988958e7bb2f2e8b67f52c1fec74b4ec47d74ba22cd0f6cb5c4228acbaa72b1678d5fece0254d - -### Node binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.21.0-alpha.1/kubernetes-node-linux-amd64.tar.gz) | 95658d321a0a371c0900b401d1469d96915310afbc4e4b9b11f031438bb188513b57d5a60b5316c3b0c18f541cda6f0ac42f59a76495f8abc743a067115da23a -[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.21.0-alpha.1/kubernetes-node-linux-arm.tar.gz) | f375acfb42aad6c65b833c270e7e3acfe9cd1d6b2441c33874e77faae263957f7acfe86f1b71f14298118595e4cc6952c7dea0c832f7f2e72428336f13034362 -[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.21.0-alpha.1/kubernetes-node-linux-arm64.tar.gz) | 43b4baccd58d74e7f48d096ab92f2bbbcdf47e30e7a3d2b56c6cc9f90002cfd4fefaac894f69bd5f9f4dbdb09a4749a77eb76b1b97d91746bd96fe94457879ab -[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.21.0-alpha.1/kubernetes-node-linux-ppc64le.tar.gz) | e7962b522c6c7c14b9ee4c1d254d8bdd9846b2b33b0443fc9c4a41be6c40e5e6981798b720f0148f36263d5cc45d5a2bb1dd2f9ab2838e3d002e45b9bddeb7bf -[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.21.0-alpha.1/kubernetes-node-linux-s390x.tar.gz) | 49ebc97f01829e65f7de15be00b882513c44782eaadd1b1825a227e3bd3c73cc6aca8345af05b303d8c43aa2cb944a069755b2709effb8cc22eae621d25d4ba5 -[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.21.0-alpha.1/kubernetes-node-windows-amd64.tar.gz) | 6e0fd7724b09e6befbcb53b33574e97f2db089f2eee4bbf391abb7f043103a5e6e32e3014c0531b88f9a3ca88887bbc68625752c44326f98dd53adb3a6d1bed8 - -## Changelog since v1.20.0 - -## Urgent Upgrade Notes - -### (No, really, you MUST read this before you upgrade) - - - Kube-proxy's IPVS proxy mode no longer sets the net.ipv4.conf.all.route_localnet sysctl parameter. Nodes upgrading will have net.ipv4.conf.all.route_localnet set to 1 but new nodes will inherit the system default (usually 0). If you relied on any behavior requiring net.ipv4.conf.all.route_localnet, you must set ensure it is enabled as kube-proxy will no longer set it automatically. This change helps to further mitigate CVE-2020-8558. ([#92938](https://github.com/kubernetes/kubernetes/pull/92938), [@lbernail](https://github.com/lbernail)) [SIG Network and Release] - -## Changes by Kind - -### Deprecation - -- Deprecate the `topologyKeys` field in Service. This capability will be replaced with upcoming work around Topology Aware Subsetting and Service Internal Traffic Policy. ([#96736](https://github.com/kubernetes/kubernetes/pull/96736), [@andrewsykim](https://github.com/andrewsykim)) [SIG Apps] -- Kubeadm: deprecated command "alpha selfhosting pivot" is removed now. ([#97627](https://github.com/kubernetes/kubernetes/pull/97627), [@knight42](https://github.com/knight42)) [SIG Cluster Lifecycle] -- Kubeadm: graduate the command `kubeadm alpha kubeconfig user` to `kubeadm kubeconfig user`. The `kubeadm alpha kubeconfig user` command is deprecated now. ([#97583](https://github.com/kubernetes/kubernetes/pull/97583), [@knight42](https://github.com/knight42)) [SIG Cluster Lifecycle] -- Kubeadm: the "kubeadm alpha certs" command is removed now, please use "kubeadm certs" instead. ([#97706](https://github.com/kubernetes/kubernetes/pull/97706), [@knight42](https://github.com/knight42)) [SIG Cluster Lifecycle] -- Remove the deprecated metrics "scheduling_algorithm_preemption_evaluation_seconds" and "binding_duration_seconds", suggest to use "scheduler_framework_extension_point_duration_seconds" instead. ([#96447](https://github.com/kubernetes/kubernetes/pull/96447), [@chendave](https://github.com/chendave)) [SIG Cluster Lifecycle, Instrumentation, Scheduling and Testing] -- The PodSecurityPolicy API is deprecated in 1.21, and will no longer be served starting in 1.25. ([#97171](https://github.com/kubernetes/kubernetes/pull/97171), [@deads2k](https://github.com/deads2k)) [SIG Auth and CLI] - -### API Change - -- Change the APIVersion proto name of BoundObjectRef from aPIVersion to apiVersion. ([#97379](https://github.com/kubernetes/kubernetes/pull/97379), [@kebe7jun](https://github.com/kebe7jun)) [SIG Auth] -- Promote Immutable Secrets/ConfigMaps feature to Stable. - This allows to set `Immutable` field in Secrets or ConfigMap object to mark their contents as immutable. ([#97615](https://github.com/kubernetes/kubernetes/pull/97615), [@wojtek-t](https://github.com/wojtek-t)) [SIG Apps, Architecture, Node and Testing] - -### Feature - -- Add flag --lease-max-object-size and metric etcd_lease_object_counts for kube-apiserver to config and observe max objects attached to a single etcd lease. ([#97480](https://github.com/kubernetes/kubernetes/pull/97480), [@lingsamuel](https://github.com/lingsamuel)) [SIG API Machinery, Instrumentation and Scalability] -- Add flag --lease-reuse-duration-seconds for kube-apiserver to config etcd lease reuse duration. ([#97009](https://github.com/kubernetes/kubernetes/pull/97009), [@lingsamuel](https://github.com/lingsamuel)) [SIG API Machinery and Scalability] -- Adds the ability to pass --strict-transport-security-directives to the kube-apiserver to set the HSTS header appropriately. Be sure you understand the consequences to browsers before setting this field. ([#96502](https://github.com/kubernetes/kubernetes/pull/96502), [@249043822](https://github.com/249043822)) [SIG Auth] -- Kubeadm now includes CoreDNS v1.8.0. ([#96429](https://github.com/kubernetes/kubernetes/pull/96429), [@rajansandeep](https://github.com/rajansandeep)) [SIG Cluster Lifecycle] -- Kubeadm: add support for certificate chain validation. When using kubeadm in external CA mode, this allows an intermediate CA to be used to sign the certificates. The intermediate CA certificate must be appended to each signed certificate for this to work correctly. ([#97266](https://github.com/kubernetes/kubernetes/pull/97266), [@robbiemcmichael](https://github.com/robbiemcmichael)) [SIG Cluster Lifecycle] -- Kubeadm: amend the node kernel validation to treat CGROUP_PIDS, FAIR_GROUP_SCHED as required and CFS_BANDWIDTH, CGROUP_HUGETLB as optional ([#96378](https://github.com/kubernetes/kubernetes/pull/96378), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle and Node] -- The Kubernetes pause image manifest list now contains an image for Windows Server 20H2. ([#97322](https://github.com/kubernetes/kubernetes/pull/97322), [@claudiubelu](https://github.com/claudiubelu)) [SIG Windows] -- The apimachinery util/net function used to detect the bind address `ResolveBindAddress()` - takes into consideration global ip addresses on loopback interfaces when: - - the host has default routes - - there are no global IPs on those interfaces. - in order to support more complex network scenarios like BGP Unnumbered RFC 5549 ([#95790](https://github.com/kubernetes/kubernetes/pull/95790), [@aojea](https://github.com/aojea)) [SIG Network] - -### Bug or Regression - -- ## Changelog - - ### General - - Fix priority expander falling back to a random choice even though there is a higher priority option to choose - - Clone `kubernetes/kubernetes` in `update-vendor.sh` shallowly, instead of fetching all revisions - - Speed up binpacking by reducing the number of PreFilter calls (call once per pod instead of #pods*#nodes times) - - Speed up finding unneeded nodes by 5x+ in very large clusters by reducing the number of PreFilter calls - - Expose `--max-nodes-total` as a metric - - Errors in `IncreaseSize` changed from type `apiError` to `cloudProviderError` - - Make `build-in-docker` and `test-in-docker` work on Linux systems with SELinux enabled - - Fix an error where existing nodes were not considered as destinations while finding place for pods in scale-down simulations - - Remove redundant log lines and reduce severity around parsing kubeEnv - - Don't treat nodes created by virtual kubelet as nodes from non-autoscaled node groups - - Remove redundant logging around calculating node utilization - - Add configurable `--network` and `--rm` flags for docker in `Makefile` - - Subtract DaemonSet pods' requests from node allocatable in the denominator while computing node utilization - - Include taints by condition when determining if a node is unready/still starting - - Fix `update-vendor.sh` to work on OSX and zsh - - Add best-effort eviction for DaemonSet pods while scaling down non-empty nodes - - Add build support for ARM64 - - ### AliCloud - - Add missing daemonsets and replicasets to ALI example cluster role - - ### Apache CloudStack - - Add support for Apache CloudStack - - ### AWS - - Regenerate list of EC2 instances - - Fix pricing endpoint in AWS China Region - - ### Azure - - Add optional jitter on initial VMSS VM cache refresh, keep the refreshes spread over time - - Serve from cache for the whole period of ongoing throttling - - Fix unwanted VMSS VMs cache invalidations - - Enforce setting the number of retries if cloud provider backoff is enabled - - Don't update capacity if VMSS provisioning state is updating - - Support allocatable resources overrides via VMSS tags - - Add missing stable labels in template nodes - - Proactively set instance status to deleting on node deletions - - ### Cluster API - - Migrate interaction with the API from using internal types to using Unstructured - - Improve tests to work better with constrained resources - - Add support for node autodiscovery - - Add support for `--cloud-config` - - Update group identifier to use for Cluster API annotations - - ### Exoscale - - Add support for Exoscale - - ### GCE - - Decrease the number of GCE Read Requests made while deleting nodes - - Base pricing of custom instances on their instance family type - - Add pricing information for missing machine types - - Add pricing information for different GPU types - - Ignore the new `topology.gke.io/zone` label when comparing groups - - Add missing stable labels to template nodes - - ### HuaweiCloud - - Add auto scaling group support - - Implement node group by AS - - Implement getting desired instance number of node group - - Implement increasing node group size - - Implement TemplateNodeInfo - - Implement caching instances - - ### IONOS - - Add support for IONOS - - ### Kubemark - - Skip non-kubemark nodes while computing node infos for node groups. - - ### Magnum - - Add Magnum support in the Cluster Autoscaler helm chart - - ### Packet - - Allow empty nodepools - - Add support for multiple nodepools - - Add pricing support - - ## Image - Image: `k8s.gcr.io/autoscaling/cluster-autoscaler:v1.20.0` ([#97011](https://github.com/kubernetes/kubernetes/pull/97011), [@towca](https://github.com/towca)) [SIG Cloud Provider] -- AcceleratorStats will be available in the Summary API of kubelet when cri_stats_provider is used. ([#96873](https://github.com/kubernetes/kubernetes/pull/96873), [@ruiwen-zhao](https://github.com/ruiwen-zhao)) [SIG Node] -- Add limited lines to log when having tail option ([#93920](https://github.com/kubernetes/kubernetes/pull/93920), [@zhouya0](https://github.com/zhouya0)) [SIG Node] -- Avoid systemd-logind loading configuration warning ([#97950](https://github.com/kubernetes/kubernetes/pull/97950), [@wzshiming](https://github.com/wzshiming)) [SIG Node] -- Cloud-controller-manager: routes controller should not depend on --allocate-node-cidrs ([#97029](https://github.com/kubernetes/kubernetes/pull/97029), [@andrewsykim](https://github.com/andrewsykim)) [SIG Cloud Provider and Testing] -- Copy annotations with empty value when deployment rolls back ([#94858](https://github.com/kubernetes/kubernetes/pull/94858), [@waynepeking348](https://github.com/waynepeking348)) [SIG Apps] -- Detach volumes from vSphere nodes not tracked by attach-detach controller ([#96689](https://github.com/kubernetes/kubernetes/pull/96689), [@gnufied](https://github.com/gnufied)) [SIG Cloud Provider and Storage] -- Fix kubectl label error when local=true is set. ([#97440](https://github.com/kubernetes/kubernetes/pull/97440), [@pandaamanda](https://github.com/pandaamanda)) [SIG CLI] -- Fix Azure file share not deleted issue when the namespace is deleted ([#97417](https://github.com/kubernetes/kubernetes/pull/97417), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage] -- Fix CVE-2020-8555 for Gluster client connections. ([#97922](https://github.com/kubernetes/kubernetes/pull/97922), [@liggitt](https://github.com/liggitt)) [SIG Storage] -- Fix counting error in service/nodeport/loadbalancer quota check ([#97451](https://github.com/kubernetes/kubernetes/pull/97451), [@pacoxu](https://github.com/pacoxu)) [SIG API Machinery, Network and Testing] -- Fix kubectl-convert import known versions ([#97754](https://github.com/kubernetes/kubernetes/pull/97754), [@wzshiming](https://github.com/wzshiming)) [SIG CLI and Testing] -- Fix missing cadvisor machine metrics. ([#97006](https://github.com/kubernetes/kubernetes/pull/97006), [@lingsamuel](https://github.com/lingsamuel)) [SIG Node] -- Fix nil VMSS name when setting service to auto mode ([#97366](https://github.com/kubernetes/kubernetes/pull/97366), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider] -- Fix the panic when kubelet registers if a node object already exists with no Status.Capacity or Status.Allocatable ([#95269](https://github.com/kubernetes/kubernetes/pull/95269), [@SataQiu](https://github.com/SataQiu)) [SIG Node] -- Fix the regression with the slow pods termination. Before this fix pods may take an additional time to terminate - up to one minute. Reversing the change that ensured that CNI resources cleaned up when the pod is removed on API server. ([#97980](https://github.com/kubernetes/kubernetes/pull/97980), [@SergeyKanzhelev](https://github.com/SergeyKanzhelev)) [SIG Node] -- Fix to recover CSI volumes from certain dangling attachments ([#96617](https://github.com/kubernetes/kubernetes/pull/96617), [@yuga711](https://github.com/yuga711)) [SIG Apps and Storage] -- Fix: azure file latency issue for metadata-heavy workloads ([#97082](https://github.com/kubernetes/kubernetes/pull/97082), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage] -- Fixed Cinder volume IDs on OpenStack Train ([#96673](https://github.com/kubernetes/kubernetes/pull/96673), [@jsafrane](https://github.com/jsafrane)) [SIG Cloud Provider] -- Fixed FibreChannel volume plugin corrupting filesystems on detach of multipath volumes. ([#97013](https://github.com/kubernetes/kubernetes/pull/97013), [@jsafrane](https://github.com/jsafrane)) [SIG Storage] -- Fixed a bug in kubelet that will saturate CPU utilization after containerd got restarted. ([#97174](https://github.com/kubernetes/kubernetes/pull/97174), [@hanlins](https://github.com/hanlins)) [SIG Node] -- Fixed bug in CPUManager with race on container map access ([#97427](https://github.com/kubernetes/kubernetes/pull/97427), [@klueska](https://github.com/klueska)) [SIG Node] -- Fixed cleanup of block devices when /var/lib/kubelet is a symlink. ([#96889](https://github.com/kubernetes/kubernetes/pull/96889), [@jsafrane](https://github.com/jsafrane)) [SIG Storage] -- GCE Internal LoadBalancer sync loop will now release the ILB IP address upon sync failure. An error in ILB forwarding rule creation will no longer leak IP addresses. ([#97740](https://github.com/kubernetes/kubernetes/pull/97740), [@prameshj](https://github.com/prameshj)) [SIG Cloud Provider and Network] -- Ignore update pod with no new images in alwaysPullImages admission controller ([#96668](https://github.com/kubernetes/kubernetes/pull/96668), [@pacoxu](https://github.com/pacoxu)) [SIG Apps, Auth and Node] -- Kubeadm now installs version 3.4.13 of etcd when creating a cluster with v1.19 ([#97244](https://github.com/kubernetes/kubernetes/pull/97244), [@pacoxu](https://github.com/pacoxu)) [SIG Cluster Lifecycle] -- Kubeadm: avoid detection of the container runtime for commands that do not need it ([#97625](https://github.com/kubernetes/kubernetes/pull/97625), [@pacoxu](https://github.com/pacoxu)) [SIG Cluster Lifecycle] -- Kubeadm: fix a bug in the host memory detection code on 32bit Linux platforms ([#97403](https://github.com/kubernetes/kubernetes/pull/97403), [@abelbarrera15](https://github.com/abelbarrera15)) [SIG Cluster Lifecycle] -- Kubeadm: fix a bug where "kubeadm upgrade" commands can fail if CoreDNS v1.8.0 is installed. ([#97919](https://github.com/kubernetes/kubernetes/pull/97919), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] -- Performance regression [#97685](https://github.com/kubernetes/kubernetes/issues/97685) has been fixed. ([#97860](https://github.com/kubernetes/kubernetes/pull/97860), [@MikeSpreitzer](https://github.com/MikeSpreitzer)) [SIG API Machinery] -- Remove deprecated --cleanup-ipvs flag of kube-proxy, and make --cleanup flag always to flush IPVS ([#97336](https://github.com/kubernetes/kubernetes/pull/97336), [@maaoBit](https://github.com/maaoBit)) [SIG Network] -- The current version of the container image publicly exposed IP serving a /metrics endpoint to the Internet. The new version of the container image serves /metrics endpoint on a different port. ([#97621](https://github.com/kubernetes/kubernetes/pull/97621), [@vbannai](https://github.com/vbannai)) [SIG Cloud Provider] -- Use force unmount for NFS volumes if regular mount fails after 1 minute timeout ([#96844](https://github.com/kubernetes/kubernetes/pull/96844), [@gnufied](https://github.com/gnufied)) [SIG Storage] -- Users will see increase in time for deletion of pods and also guarantee that removal of pod from api server would mean deletion of all the resources from container runtime. ([#92817](https://github.com/kubernetes/kubernetes/pull/92817), [@kmala](https://github.com/kmala)) [SIG Node] -- Using exec auth plugins with kubectl no longer results in warnings about constructing many client instances from the same exec auth config. ([#97857](https://github.com/kubernetes/kubernetes/pull/97857), [@liggitt](https://github.com/liggitt)) [SIG API Machinery and Auth] -- Warning about using a deprecated volume plugin is logged only once. ([#96751](https://github.com/kubernetes/kubernetes/pull/96751), [@jsafrane](https://github.com/jsafrane)) [SIG Storage] - -### Other (Cleanup or Flake) - -- Bump github.com/Azure/go-autorest/autorest to v0.11.12 ([#97033](https://github.com/kubernetes/kubernetes/pull/97033), [@patrickshan](https://github.com/patrickshan)) [SIG API Machinery, CLI, Cloud Provider and Cluster Lifecycle] -- Delete deprecated mixed protocol annotation ([#97096](https://github.com/kubernetes/kubernetes/pull/97096), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider] -- Kube-proxy: Traffic from the cluster directed to ExternalIPs is always sent directly to the Service. ([#96296](https://github.com/kubernetes/kubernetes/pull/96296), [@aojea](https://github.com/aojea)) [SIG Network and Testing] -- Kubeadm: fix a whitespace issue in the output of the "kubeadm join" command shown as the output of "kubeadm init" and "kubeadm token create --print-join-command" ([#97413](https://github.com/kubernetes/kubernetes/pull/97413), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle] -- Kubeadm: improve the error messaging when the user provides an invalid discovery token CA certificate hash. ([#97290](https://github.com/kubernetes/kubernetes/pull/97290), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] -- Migrate log messages in pkg/scheduler/{scheduler.go,factory.go} to structured logging ([#97509](https://github.com/kubernetes/kubernetes/pull/97509), [@aldudko](https://github.com/aldudko)) [SIG Scheduling] -- Migrate proxy/iptables/proxier.go logs to structured logging ([#97678](https://github.com/kubernetes/kubernetes/pull/97678), [@JornShen](https://github.com/JornShen)) [SIG Network] -- Migrate some scheduler log messages to structured logging ([#97349](https://github.com/kubernetes/kubernetes/pull/97349), [@aldudko](https://github.com/aldudko)) [SIG Scheduling] -- NONE ([#97167](https://github.com/kubernetes/kubernetes/pull/97167), [@geegeea](https://github.com/geegeea)) [SIG Node] -- NetworkPolicy validation framework optimizations for rapidly verifying CNI's work correctly across several pods and namespaces ([#91592](https://github.com/kubernetes/kubernetes/pull/91592), [@jayunit100](https://github.com/jayunit100)) [SIG Network, Storage and Testing] -- Official support to build kubernetes with docker-machine / remote docker is removed. This change does not affect building kubernetes with docker locally. ([#97618](https://github.com/kubernetes/kubernetes/pull/97618), [@jherrera123](https://github.com/jherrera123)) [SIG Release and Testing] -- Scheduler plugin validation now provides all errors detected instead of the first one. ([#96745](https://github.com/kubernetes/kubernetes/pull/96745), [@lingsamuel](https://github.com/lingsamuel)) [SIG Node, Scheduling and Testing] -- Storage related e2e testsuite redesign & cleanup ([#96573](https://github.com/kubernetes/kubernetes/pull/96573), [@Jiawei0227](https://github.com/Jiawei0227)) [SIG Storage and Testing] -- The OIDC authenticator no longer waits 10 seconds before attempting to fetch the metadata required to verify tokens. ([#97693](https://github.com/kubernetes/kubernetes/pull/97693), [@enj](https://github.com/enj)) [SIG API Machinery and Auth] -- The `AttachVolumeLimit` feature gate that is GA since v1.17 is now removed. ([#96539](https://github.com/kubernetes/kubernetes/pull/96539), [@ialidzhikov](https://github.com/ialidzhikov)) [SIG Storage] -- The `CSINodeInfo` feature gate that is GA since v1.17 is unconditionally enabled, and can no longer be specified via the `--feature-gates` argument. ([#96561](https://github.com/kubernetes/kubernetes/pull/96561), [@ialidzhikov](https://github.com/ialidzhikov)) [SIG Apps, Auth, Scheduling, Storage and Testing] -- The deprecated feature gates `RotateKubeletClientCertificate`, `AttachVolumeLimit`, `VolumePVCDataSource` and `EvenPodsSpread` are now unconditionally enabled and can no longer be specified in component invocations. ([#97306](https://github.com/kubernetes/kubernetes/pull/97306), [@gavinfish](https://github.com/gavinfish)) [SIG Node, Scheduling and Storage] -- `ServiceNodeExclusion`, `NodeDisruptionExclusion` and `LegacyNodeRoleBehavior`(locked to false) features have been promoted to GA. - To prevent control plane nodes being added to load balancers automatically, upgrade users need to add "node.kubernetes.io/exclude-from-external-load-balancers" label to control plane nodes. ([#97543](https://github.com/kubernetes/kubernetes/pull/97543), [@pacoxu](https://github.com/pacoxu)) [SIG API Machinery, Apps, Cloud Provider and Network] - -### Uncategorized - -- Adding Brazilian Portuguese translation for kubectl ([#61595](https://github.com/kubernetes/kubernetes/pull/61595), [@cpanato](https://github.com/cpanato)) [SIG CLI] - -## Dependencies - -### Added -_Nothing has changed._ - -### Changed -- github.com/Azure/go-autorest/autorest: [v0.11.1 → v0.11.12](https://github.com/Azure/go-autorest/autorest/compare/v0.11.1...v0.11.12) -- github.com/coredns/corefile-migration: [v1.0.10 → v1.0.11](https://github.com/coredns/corefile-migration/compare/v1.0.10...v1.0.11) -- github.com/golang/mock: [v1.4.1 → v1.4.4](https://github.com/golang/mock/compare/v1.4.1...v1.4.4) -- github.com/google/cadvisor: [v0.38.5 → v0.38.6](https://github.com/google/cadvisor/compare/v0.38.5...v0.38.6) -- github.com/heketi/heketi: [c2e2a4a → v10.2.0+incompatible](https://github.com/heketi/heketi/compare/c2e2a4a...v10.2.0) -- github.com/miekg/dns: [v1.1.4 → v1.1.35](https://github.com/miekg/dns/compare/v1.1.4...v1.1.35) -- k8s.io/system-validators: v1.2.0 → v1.3.0 - -### Removed -- rsc.io/quote/v3: v3.1.0 -- rsc.io/sampler: v1.3.0 diff --git a/content/ko/releases/_index.md b/content/ko/releases/_index.md new file mode 100644 index 0000000000..aa6a306f8a --- /dev/null +++ b/content/ko/releases/_index.md @@ -0,0 +1,27 @@ +--- +linktitle: 릴리스 히스토리 +title: 릴리스 +type: docs +--- + + + + +쿠버네티스 프로젝트는 가장 최신의 3개 마이너(minor) 릴리스({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}})에 대해서 릴리스 브랜치를 관리한다. 쿠버네티스 1.19 및 이후 신규 버전은 약 1년간 패치 지원을 받을 수 있다. 쿠버네티스 1.18 및 이전 버전은 약 9개월간의 패치 지원을 받을 수 있다. + +쿠버네티스 버전은 **x.y.z** 의 형태로 표현되는데, +**x** 는 메이저(major) 버전, **y** 는 마이너(minor), **z** 는 패치(patch) 버전을 의미하며, 이는 [시맨틱 버전](https://semver.org/)의 용어를 따른 것이다. + +저 자세한 정보는 [버전 차이(skew) 정책](/releases/version-skew-policy/) 문서에서 확인하길 바란다. + + + +## 릴리스 히스토리 + +{{< release-data >}} + +## 차기 릴리스 + +차기 쿠버네티스 릴리스 **{{< skew nextMinorVersion >}}** 일정은 [스케줄](https://github.com/kubernetes/sig-release/tree/master/releases/release-{{< skew nextMinorVersion >}})에서 확인할 수 있다. + +## 유용한 자원 diff --git a/content/ko/releases/notes.md b/content/ko/releases/notes.md new file mode 100644 index 0000000000..b509ae0d65 --- /dev/null +++ b/content/ko/releases/notes.md @@ -0,0 +1,13 @@ +--- +linktitle: 릴리스 노트 +title: 노트 +type: docs +description: > + 쿠버네티스 릴리스 노트. +sitemap: + priority: 0.5 +--- + +릴리스 노트는 사용자의 쿠버네티스 버전에 해당하는 [변경로그(Changelog)](https://github.com/kubernetes/kubernetes/tree/master/CHANGELOG)를 통해서 확인할 수 있다. {{< skew latestVersion >}} 의 변경로그는 [깃허브](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-{{< skew latestVersion >}}.md)에 있다. + +대안으로, 릴리스 노트는 [relnotes.k8s.io](https://relnotes.k8s.io)에서 온라인으로 검색 및 필터링이 가능하다. {{< skew latestVersion >}}로 필터링된 릴리스 노트는 [relnotes.k8s.io](https://relnotes.k8s.io/?releaseVersions={{< skew latestVersion >}}.0)에서 확인한다. diff --git a/content/ko/docs/setup/release/version-skew-policy.md b/content/ko/releases/version-skew-policy.md similarity index 97% rename from content/ko/docs/setup/release/version-skew-policy.md rename to content/ko/releases/version-skew-policy.md index 76ff7504fd..38052aa18d 100644 --- a/content/ko/docs/setup/release/version-skew-policy.md +++ b/content/ko/releases/version-skew-policy.md @@ -20,8 +20,8 @@ weight: 30 ## 지원되는 버전 -쿠버네티스 버전은 **x.y.z**로 표현되는데, -여기서 **x**는 메이저 버전, **y**는 마이너 버전, **z**는 [시맨틱 버전](https://semver.org/) 용어에 따른 패치 버전이다. +쿠버네티스 버전은 **x.y.z** 로 표현되는데, +여기서 **x** 는 메이저 버전, **y** 는 마이너 버전, **z** 는 패치 버전을 의미하며, 이는 [시맨틱 버전](https://semver.org/) 용어에 따른 것이다. 자세한 내용은 [쿠버네티스 릴리스 버전](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md#kubernetes-release-versioning)을 참조한다. 쿠버네티스 프로젝트는 최근 세 개의 마이너 릴리스 ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}) 에 대한 릴리스 분기를 유지한다. 쿠버네티스 1.19 이상은 약 1년간의 패치 지원을 받는다. 쿠버네티스 1.18 이상은 약 9개월의 패치 지원을 받는다. From 11bc6b4efcc60c1ba61a8721549ece224aaf7ae4 Mon Sep 17 00:00:00 2001 From: luzg Date: Fri, 28 May 2021 23:52:22 +0800 Subject: [PATCH 059/128] [zh] translate tasks/Enabling Topology Aware Hints --- .../enabling-topology-aware-hints.md | 72 +++++++++++++++++++ 1 file changed, 72 insertions(+) create mode 100644 content/zh/docs/tasks/administer-cluster/enabling-topology-aware-hints.md diff --git a/content/zh/docs/tasks/administer-cluster/enabling-topology-aware-hints.md b/content/zh/docs/tasks/administer-cluster/enabling-topology-aware-hints.md new file mode 100644 index 0000000000..14b5bea3a5 --- /dev/null +++ b/content/zh/docs/tasks/administer-cluster/enabling-topology-aware-hints.md @@ -0,0 +1,72 @@ +--- +title: 启用拓扑感知提示 +content_type: task +min-kubernetes-server-version: 1.21 +--- + + + +{{< feature-state for_k8s_version="v1.21" state="alpha" >}} + + +_拓扑感知提示_ 启用具有拓扑感知能力的路由，其中拓扑感知信息包含在 +{{< glossary_tooltip text="EndpointSlices" term_id="endpoint-slice" >}} 中。 +此功能尽量将流量限制在它的发起区域附近； +可以降低成本，或者提高网络性能。 + +## {{% heading "prerequisites" %}} + + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + +为了启用拓扑感知提示，先要满足以下先决条件： + +* 配置 {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}} + 以 iptables 或 IPVS 模式运行 +* 确保未禁用 EndpointSlices + + +## 启动拓扑感知提示 {#enable-topology-aware-hints} + + +要启用服务拓扑感知，请启用 kube-apiserver、kube-controller-manager、和 kube-proxy 的 +[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) +`TopologyAwareHints`。 + +``` +--feature-gates="TopologyAwareHints=true" +``` + +## {{% heading "whatsnext" %}} + + +* 参阅面向服务的[拓扑感知提示](/zh/docs/concepts/services-networking/topology-aware-hints) +* 参阅[用服务连通应用](/zh/docs/concepts/services-networking/connect-applications-service/) From 9c1a5245b0151172985dc8220c552a4645d9ff7a Mon Sep 17 00:00:00 2001 From: liuwei10 Date: Mon, 31 May 2021 10:35:25 +0800 Subject: [PATCH 060/128] modify error of labels-annotations-taints.md --- .../manage-resources/memory-constraint-namespace.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/zh/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md b/content/zh/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md index 0bb4c5d8d8..372ca6c854 100644 --- a/content/zh/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md +++ b/content/zh/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md @@ -339,7 +339,7 @@ For example: you want development workloads to be limited to 512 MB. You create separate namespaces for production and development, and you apply memory constraints to each namespace. --> -做为集群管理员，你可能想规定 Pod 可以使用的内存总量限制。例如： +作为集群管理员，你可能想规定 Pod 可以使用的内存总量限制。例如： * 集群的每个节点有 2 GB 内存。你不想接受任何请求超过 2 GB 的 Pod，因为集群中没有节点可以满足。 * 集群由生产部门和开发部门共享。你希望允许产品部门的负载最多耗用 8 GB 内存， From 590d07f92215ccfa52bac3fe944f6825a3d3558b Mon Sep 17 00:00:00 2001 From: Rui Chen Date: Sun, 30 May 2021 12:40:17 -0400 Subject: [PATCH 061/128] zh: sync concepts/storage/persistent-volumes Signed-off-by: Rui Chen sync zh translation Co-authored-by: Qiming Teng add hyperlink refs Signed-off-by: Rui Chen --- .../docs/concepts/storage/persistent-volumes.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/content/zh/docs/concepts/storage/persistent-volumes.md b/content/zh/docs/concepts/storage/persistent-volumes.md index 739540c002..53647be555 100644 --- a/content/zh/docs/concepts/storage/persistent-volumes.md +++ b/content/zh/docs/concepts/storage/persistent-volumes.md @@ -746,10 +746,10 @@ Kubernetes supports two `volumeModes` of PersistentVolumes: `Filesystem` and `Bl `Filesystem` is the default mode used when `volumeMode` parameter is omitted. A volume with `volumeMode: Filesystem` is *mounted* into Pods into a directory. If the volume -is backed by a block device and the device is empty, Kuberneretes creates a filesystem +is backed by a block device and the device is empty, Kubernetes creates a filesystem on the device before mounting it for the first time. --> -针对 PV 持久卷，Kuberneretes +针对 PV 持久卷，Kubernetes 支持两种卷模式（`volumeModes`）：`Filesystem（文件系统）` 和 `Block（块）`。 `volumeMode` 是一个可选的 API 参数。 如果该参数被省略，默认的卷模式是 `Filesystem`。 @@ -1032,20 +1032,20 @@ spec: -### 访问模式 {#access-modes} +### 访问模式 {#access-modes} -申领在请求具有特定访问模式的存储时，使用与卷相同的访问模式约定。 +申领在请求具有特定访问模式的存储时，使用与卷相同的[访问模式约定](#access-modes)。 -### 卷模式 {#volume-modes} +### 卷模式 {#volume-modes} -申领使用与卷相同的约定来表明是将卷作为文件系统还是块设备来使用。 +申领使用[与卷相同的约定](#access-modes)来表明是将卷作为文件系统还是块设备来使用。 -自愿干扰的频率各不相同。在一个基本的 Kubernetes 集群中，根本没有自愿干扰。然而，集群管理 -或托管提供商可能运行一些可能导致自愿干扰的额外服务。例如，节点软 +自愿干扰的频率各不相同。在一个基本的 Kubernetes 集群中，没有自愿干扰（只有用户触发的干扰）。 +然而，集群管理员或托管提供商可能运行一些可能导致自愿干扰的额外服务。例如，节点软 更新可能导致自愿干扰。另外，集群（节点）自动缩放的某些 实现可能导致碎片整理和紧缩节点的自愿干扰。集群 管理员或托管提供商应该已经记录了各级别的自愿干扰（如果有的话）。 +有些配置选项，例如在 pod spec 中 +[使用 PriorityClasses]（https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/） +也会产生自愿（和非自愿）的干扰。 当使用驱逐 API 驱逐 Pod 时，Pod 会被体面地 @@ -504,4 +509,3 @@ the nodes in your cluster, such as a node or system software upgrade, here are s * 进一步了解[排空节点](/zh/docs/tasks/administer-cluster/safely-drain-node/)的信息。 * 了解[更新 Deployment](/zh/docs/concepts/workloads/controllers/deployment/#updating-a-deployment) 的过程，包括如何在其进程中维持应用的可用性 - diff --git a/content/zh/docs/concepts/workloads/pods/init-containers.md b/content/zh/docs/concepts/workloads/pods/init-containers.md index 283b9f3759..bbfdebc581 100644 --- a/content/zh/docs/concepts/workloads/pods/init-containers.md +++ b/content/zh/docs/concepts/workloads/pods/init-containers.md @@ -54,7 +54,7 @@ Init 容器与普通的容器非常像，除了如下两点： * 每个都必须在下一个启动之前成功完成。 如果 Pod 的 Init 容器失败，kubelet 会不断地重启该 Init 容器直到该容器成功为止。 @@ -391,10 +391,10 @@ myapp-pod 1/1 Running 0 9m 这个简单例子应该能为你创建自己的 Init 容器提供一些启发。 -[接下来](#whats-next)节提供了更详细例子的链接。 +[接下来](#what-s-next)节提供了更详细例子的链接。 * 阅读[创建包含 Init 容器的 Pod](/zh/docs/tasks/configure-pod-container/configure-pod-initialization/#create-a-pod-that-has-an-init-container) * 学习如何[调试 Init 容器](/zh/docs/tasks/debug-application-cluster/debug-init-containers/) - diff --git a/content/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints.md index 2ddc5a4d9d..747087b059 100644 --- a/content/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints.md +++ b/content/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints.md @@ -27,7 +27,7 @@ You can use _topology spread constraints_ to control how {{< glossary_tooltip te {{< note >}} -在 v1.19 之前的 Kubernetes 版本中，如果要使用 Pod 拓扑扩展约束，你必须在 [API 服务器](/zh/docs/concepts/overview/components/#kube-apiserver) +在 v1.18 之前的 Kubernetes 版本中，如果要使用 Pod 拓扑扩展约束，你必须在 +[API 服务器](/zh/docs/concepts/overview/components/#kube-apiserver) 和[调度器](/zh/docs/reference/command-line-tools-reference/kube-scheduler/) 中启用 `EvenPodsSpread` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。 {{< /note >}} @@ -218,7 +219,7 @@ If we want an incoming Pod to be evenly spread with existing Pods across zones, 则让它保持悬决状态。 如果调度器将新的 Pod 放入 "zoneA"，Pods 分布将变为 [3, 1]，因此实际的偏差 @@ -645,4 +646,3 @@ See [Motivation](https://github.com/kubernetes/enhancements/blob/master/keps/sig --> - [博客: PodTopologySpread介绍](https://kubernetes.io/blog/2020/05/introducing-podtopologyspread/) 详细解释了 `maxSkew`，并给出了一些高级的使用示例。 - From 7f4281ebb3f17d87f3d1d05d982f4f1b748d81a2 Mon Sep 17 00:00:00 2001 From: Rui Chen Date: Sun, 30 May 2021 12:27:23 -0400 Subject: [PATCH 063/128] zh: resync concepts/security files zh: resync content/zh/docs/concepts/security/controlling-access zh: resync content/zh/docs/concepts/security/pod-security-standards sync zh translation Update content/zh/docs/concepts/security/pod-security-standards.md Co-authored-by: Qiming Teng Update content/zh/docs/concepts/security/pod-security-standards.md Co-authored-by: Qiming Teng Update content/zh/docs/concepts/security/pod-security-standards.md Co-authored-by: Qiming Teng Update content/zh/docs/concepts/security/pod-security-standards.md Co-authored-by: Qiming Teng Update content/zh/docs/concepts/security/pod-security-standards.md Co-authored-by: Qiming Teng Update content/zh/docs/concepts/security/pod-security-standards.md Co-authored-by: Qiming Teng --- .../concepts/security/controlling-access.md | 62 +++++++-------- .../security/pod-security-standards.md | 78 ++++++++++++------- 2 files changed, 83 insertions(+), 57 deletions(-) diff --git a/content/zh/docs/concepts/security/controlling-access.md b/content/zh/docs/concepts/security/controlling-access.md index d17e6744bb..b45dee64dd 100644 --- a/content/zh/docs/concepts/security/controlling-access.md +++ b/content/zh/docs/concepts/security/controlling-access.md @@ -2,7 +2,7 @@ title: Kubernetes API 访问控制 content_type: concept --- - - 本页面概述了对 Kubernetes API 的访问控制。 - ## 传输安全 {#transport-security} - ## 认证 {#authentication} - 如果请求认证不通过，服务器将以 HTTP 状态码 401 拒绝该请求。 反之，该用户被认证为特定的 `username`，并且该用户名可用于后续步骤以在其决策中使用。 @@ -108,7 +108,7 @@ users in its API. ## 鉴权 {#authorization} - 如果 Bob 执行以下请求，那么请求会被鉴权，因为允许他读取 `projectCaribou` 名称空间中的对象。 @@ -153,27 +153,27 @@ If Bob makes the following request, the request is authorized because he is allo } } ``` - 如果 Bob 在 `projectCaribou` 名字空间中请求写（`create` 或 `update`）对象，其鉴权请求将被拒绝。 如果 Bob 在诸如 `projectFish` 这类其它名字空间中请求读取（`get`）对象，其鉴权也会被拒绝。 -Kubernetes 鉴权要求使用公共 REST 属性与现有的组织范围或云提供商范围的访问控制系统进行交互。 +Kubernetes 鉴权要求使用公共 REST 属性与现有的组织范围或云提供商范围的访问控制系统进行交互。 使用 REST 格式很重要，因为这些控制系统可能会与 Kubernetes API 之外的 API 交互。 - Kubernetes 支持多种鉴权模块，例如 ABAC 模式、RBAC 模式和 Webhook 模式等。 @@ -187,7 +187,7 @@ Kubernetes 支持多种鉴权模块，例如 ABAC 模式、RBAC 模式和 Webhoo ## 准入控制 {#admission-control} - ## API 服务器端口和 IP {#api-server-ports-and-ips} - 前面的讨论适用于发送到 API 服务器的安全端口的请求（典型情况）。 API 服务器实际上可以在 2 个端口上提供服务： @@ -250,7 +250,7 @@ By default the Kubernetes API server serves HTTP on 2 ports: - default IP is localhost, change with `--insecure-bind-address` flag. - request **bypasses** authentication and authorization modules. - request handled by admission control module(s). - - protected by need to have host access + - protected by need to have host access 2. “Secure port”: @@ -281,11 +281,11 @@ By default the Kubernetes API server serves HTTP on 2 ports: - 请求须经身份认证和鉴权组件处理 - 请求须经准入控制模块处理 - 身份认证和鉴权模块运行 - + ## {{% heading "whatsnext" %}} - @@ -60,7 +60,7 @@ should range from highly restricted to highly flexible: - **_Privileged_** - 不受限制的策略，提供最大可能范围的权限许可。这些策略 允许已知的特权提升。 -- **_Baseline/Default_** - 限制性最弱的策略，禁止已知的策略提升。 +- **_Baseline_** - 限制性最弱的策略，禁止已知的策略提升。 允许使用默认的（规定最少）Pod 配置。 - **_Restricted_** - 限制性非常强的策略，遵循当前的保护 Pod 的最佳实践。 @@ -90,15 +90,15 @@ Privileged 框架可能意味着不应用任何约束而不是实施某策略实 与此不同，对于默认拒绝（Deny-by-default）实施机制（如 Pod 安全策略）而言， Privileged 策略应该默认允许所有控制（即，禁止所有限制）。 -### Baseline/Default +### Baseline -Baseline/Default 策略的目标是便于常见的容器化应用采用，同时禁止已知的特权提升。 +Baseline 策略的目标是便于常见的容器化应用采用，同时禁止已知的特权提升。 此策略针对的是应用运维人员和非关键性应用的开发人员。 下面列举的控制应该被实施（禁止）： @@ -201,39 +201,66 @@ Baseline/Default 策略的目标是便于常见的容器化应用采用，同时 - - AppArmor （可选） + + AppArmor - 在受支持的宿主上，默认应用 'runtime/default' AppArmor Profile。默认策略应禁止重载或者禁用该策略，或将重载限定未所允许的 profile 集合。
+ 在被支持的主机上，默认使用 'runtime/default' AppArmor Profile。 + 基线策略应避免覆盖或者禁用默认策略，以及限制覆盖一些 profile 集合的权限。

限制的字段：
metadata.annotations['container.apparmor.security.beta.kubernetes.io/*']

允许的值： 'runtime/default'、未定义
- - SELinux （可选） + + SELinux - 应禁止设置定制的 SELinux 选项。
+ 设置 SELinux 类型的操作是被限制的，设置自定义的 SELinux 用户或角色选项是被禁止的。

限制的字段：
- spec.securityContext.seLinuxOptions
- spec.containers[*].securityContext.seLinuxOptions
- spec.initContainers[*].securityContext.seLinuxOptions
-
允许的值： undefined/nil
+ spec.securityContext.seLinuxOptions.type
+ spec.containers[*].securityContext.seLinuxOptions.type
+ spec.initContainers[*].securityContext.seLinuxOptions.type
+
允许的值：
+ 未定义/空
+ container_t
+ container_init_t
+ container_kvm_t
+
被限制的字段：
+ spec.securityContext.seLinuxOptions.user
+ spec.containers[*].securityContext.seLinuxOptions.user
+ spec.initContainers[*].securityContext.seLinuxOptions.user
+ spec.securityContext.seLinuxOptions.role
+ spec.containers[*].securityContext.seLinuxOptions.role
+ spec.initContainers[*].securityContext.seLinuxOptions.role
+
允许的值： 未定义或空
@@ -306,8 +333,8 @@ Restricted 策略旨在实施当前保护 Pod 的最佳实践，尽管这样作 策略（Policy） - - Default 策略的所有要求。 + + 基线策略的所有要求。 @@ -425,11 +452,11 @@ of individual policies are not defined here. ## 常见问题 {#faq} -### 为什么策略类型定义在 Privileged 和 Default 之间 +### 为什么不存在介于 Privileged 和 Baseline 之间的策略类型 + + + + + +## 调度 + +* [Kubernetes 调度器](/zh/docs/concepts/scheduling-eviction/kube-scheduler/) +* [将 Pods 指派到节点](/zh/docs/concepts/scheduling-eviction/assign-pod-node/) +* [Pod 开销](/zh/docs/concepts/scheduling-eviction/pod-overhead/) +* [污点和容忍](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/) +* [调度框架](/zh/docs/concepts/scheduling-eviction/scheduling-framework) +* [调度器的性能调试](/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning/) +* [扩展资源的资源装箱](/zh/docs/concepts/scheduling-eviction/resource-bin-packing/) + + + +## Pod 干扰 + +* [Pod 优先级和抢占](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/) +* [节点压力驱逐](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/) +* [API发起的驱逐](/zh/docs/concepts/scheduling-eviction/api-eviction/) diff --git a/content/zh/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/zh/docs/concepts/scheduling-eviction/assign-pod-node.md index c237281776..7f93a31186 100644 --- a/content/zh/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/zh/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -75,9 +75,9 @@ Run `kubectl get nodes` to get the names of your cluster's nodes. Pick out the o 执行 `kubectl get nodes` 命令获取集群的节点名称。 选择一个你要增加标签的节点，然后执行 -`kubectl label nodes =` +`kubectl label nodes =` 命令将标签添加到你所选择的节点上。 -例如，如果你的节点名称为 'kubernetes-foo-node-1.c.a-robinson.internal' +例如，如果你的节点名称为 'kubernetes-foo-node-1.c.a-robinson.internal' 并且想要的标签是 'disktype=ssd'，则可以执行 `kubectl label nodes kubernetes-foo-node-1.c.a-robinson.internal disktype=ssd` 命令。 @@ -136,8 +136,18 @@ with a standard set of labels. See [Well-Known Labels, Annotations and Taints](/ --> ## 插曲：内置的节点标签 {#built-in-node-labels} -除了你[添加](#attach-labels-to-node)的标签外，节点还预先填充了一组标准标签。 -参见[常用标签、注解和污点](/zh/docs/reference/labels-annotations-taints/)。 +除了你[添加](#step-one-attach-label-to-the-node)的标签外，节点还预制了一组标准标签。 +参见这些[常用的标签，注解以及污点](/zh/docs/reference/labels-annotations-taints/)： + +* [`kubernetes.io/hostname`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-hostname) +* [`failure-domain.beta.kubernetes.io/zone`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domainbetakubernetesiozone) +* [`failure-domain.beta.kubernetes.io/region`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domainbetakubernetesioregion) +* [`topology.kubernetes.io/zone`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone) +* [`topology.kubernetes.io/region`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone) +* [`beta.kubernetes.io/instance-type`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#beta-kubernetes-io-instance-type) +* [`node.kubernetes.io/instance-type`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#nodekubernetesioinstance-type) +* [`kubernetes.io/os`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-os) +* [`kubernetes.io/arch`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-arch) {{< note >}} 1. 检查是否在使用 Kubernetes v1.11+，以便 NodeRestriction 功能可用。 -2. 确保你在使用[节点授权](/zh/docs/reference/access-authn-authz/node/)并且已经_启用_ +2. 确保你在使用[节点授权](/zh/docs/reference/access-authn-authz/node/)并且已经_启用_ [NodeRestriction 准入插件](/zh/docs/reference/access-authn-authz/admission-controllers/#noderestriction)。 3. 将 `node-restriction.kubernetes.io/` 前缀下的标签添加到 Node 对象， 然后在节点选择器中使用这些标签。 @@ -574,7 +584,7 @@ must be satisfied for the pod to be scheduled onto a node. 用户也可以使用 `namespaceSelector` 选择匹配的名字空间，`namespaceSelector` @@ -828,4 +838,3 @@ resource allocation decisions. 一旦 Pod 分配给 节点，kubelet 应用将运行该 pod 并且分配节点本地资源。 [拓扑管理器](/zh/docs/tasks/administer-cluster/topology-manager/) 可以参与到节点级别的资源分配决定中。 - diff --git a/content/zh/docs/concepts/scheduling-eviction/pod-overhead.md b/content/zh/docs/concepts/scheduling-eviction/pod-overhead.md index 40684ff11c..998a2c3327 100644 --- a/content/zh/docs/concepts/scheduling-eviction/pod-overhead.md +++ b/content/zh/docs/concepts/scheduling-eviction/pod-overhead.md @@ -1,9 +1,21 @@ --- title: Pod 开销 content_type: concept -weight: 20 +weight: 30 --- + + {{< feature-state for_k8s_version="v1.18" state="beta" >}} @@ -58,7 +70,7 @@ across your cluster, and a `RuntimeClass` is utilized which defines the `overhea 您需要确保在集群中启用了 `PodOverhead` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) （在 1.18 默认是开启的），以及一个用于定义 `overhead` 字段的 `RuntimeClass`。 - ## 使用示例 @@ -85,7 +97,7 @@ overhead: cpu: "250m" ``` - 在 RuntimeClass 准入控制器之后，可以检验一下已更新的 PodSpec: @@ -138,7 +150,7 @@ After the RuntimeClass admission controller, you can check the updated PodSpec: kubectl get pod test-pod -o jsonpath='{.spec.overhead}' ``` - 输出： @@ -146,25 +158,25 @@ The output is: map[cpu:250m memory:120Mi] ``` - 如果定义了 ResourceQuata, 则容器请求的总量以及 `overhead` 字段都将计算在内。 - 当 kube-scheduler 决定在哪一个节点调度运行新的 Pod 时，调度器会兼顾该 Pod 的 `overhead` 以及该 Pod 的容器请求总量。在这个示例中，调度器将资源请求和开销相加，然后寻找具备 2.25 CPU 和 320 MiB 内存可用的节点。 - 一旦 Pod 调度到了某个节点， 该节点上的 kubelet 将为该 Pod 新建一个 {{< glossary_tooltip text="cgroup" term_id="cgroup" >}}. 底层容器运行时将在这个 pod 中创建容器。 - 对于 CPU, 如果 Pod 的 QoS 是 Guaranteed 或者 Burstable, kubelet 会基于容器请求总量与 PodSpec 中定义的 `overhead` 之和设置 `cpu.shares`. - 请看这个例子，验证工作负载的容器请求： @@ -187,7 +199,7 @@ Looking at our example, verify the container requests for the workload: kubectl get pod test-pod -o jsonpath='{.spec.containers[*].resources.limits}' ``` - 容器请求总计 2000m CPU 和 200MiB 内存： @@ -195,7 +207,7 @@ The total container requests are 2000m CPU and 200MiB of memory: map[cpu: 500m memory:100Mi] map[cpu:1500m memory:100Mi] ``` - 对照从节点观察到的情况来检查一下： @@ -203,7 +215,7 @@ Check this against what is observed by the node: kubectl describe node | grep test-pod -B2 ``` - 该输出显示请求了 2250m CPU 以及 320MiB 内存，包含了 PodOverhead 在内： @@ -226,8 +238,9 @@ cgroups directly on the node. First, on the particular node, determine the Pod identifier: --> -在工作负载所运行的节点上检查 Pod 的内存 cgroups. 在接下来的例子中，将在该节点上使用具备 CRI 兼容的容器运行时命令行工具 [`crictl`](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md). -这是一个展示 PodOverhead 行为的进阶示例，用户并不需要直接在该节点上检查 cgroups. +在工作负载所运行的节点上检查 Pod 的内存 cgroups. 在接下来的例子中， +将在该节点上使用具备 CRI 兼容的容器运行时命令行工具 +[`crictl`](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md)。 首先在特定的节点上确定该 Pod 的标识符： @@ -240,7 +253,7 @@ First, on the particular node, determine the Pod identifier: POD_ID="$(sudo crictl pods --name test-pod -q)" ``` - 可以依此判断该 Pod 的 cgroup 路径： @@ -254,7 +267,7 @@ From this, you can determine the cgroup path for the Pod: sudo crictl inspectp -o=json $POD_ID | grep cgroupsPath ``` - 执行结果的 cgroup 路径中包含了该 Pod 的 `pause` 容器。Pod 级别的 cgroup 即上面的一个目录。 @@ -262,7 +275,7 @@ The resulting cgroup path includes the Pod's `pause` container. The Pod level cg "cgroupsPath": "/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/7ccf55aee35dd16aca4189c952d83487297f3cd760f1bbf09620e206e7d0c27a" ``` - 在这个例子中，该 pod 的 cgroup 路径是 `kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2`。验证内存的 Pod 级别 cgroup 设置： @@ -278,7 +291,7 @@ In this specific case, the pod cgroup path is `kubepods/podd7f4b509-cf94-4951-94 cat /sys/fs/cgroup/memory/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/memory.limit_in_bytes ``` - 和预期的一样是 320 MiB @@ -286,7 +299,7 @@ This is 320 MiB, as expected: 335544320 ``` - ### 可观察性 @@ -298,8 +311,11 @@ running with a defined Overhead. This functionality is not available in the 1.9 kube-state-metrics, but is expected in a following release. Users will need to build kube-state-metrics from source in the meantime. --> -在 [kube-state-metrics](https://github.com/kubernetes/kube-state-metrics) 中可以通过 `kube_pod_overhead` 指标来协助确定何时使用 PodOverhead 以及协助观察以一个既定开销运行的工作负载的稳定性。 -该特性在 kube-state-metrics 的 1.9 发行版本中不可用，不过预计将在后续版本中发布。在此之前，用户需要从源代码构建 kube-state-metrics. +在 [kube-state-metrics](https://github.com/kubernetes/kube-state-metrics) 中可以通过 +`kube_pod_overhead` 指标来协助确定何时使用 PodOverhead 以及协助观察以一个既定 +开销运行的工作负载的稳定性。 +该特性在 kube-state-metrics 的 1.9 发行版本中不可用，不过预计将在后续版本中发布。 +在此之前，用户需要从源代码构建 kube-state-metrics。 ## {{% heading "whatsnext" %}} @@ -310,4 +326,3 @@ from source in the meantime. * [RuntimeClass](/zh/docs/concepts/containers/runtime-class/) * [PodOverhead 设计](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead) - diff --git a/content/zh/docs/concepts/scheduling-eviction/resource-bin-packing.md b/content/zh/docs/concepts/scheduling-eviction/resource-bin-packing.md index a08539b1a0..b8c097e5df 100644 --- a/content/zh/docs/concepts/scheduling-eviction/resource-bin-packing.md +++ b/content/zh/docs/concepts/scheduling-eviction/resource-bin-packing.md @@ -1,16 +1,18 @@ --- title: 扩展资源的资源装箱 content_type: concept -weight: 30 +weight: 80 --- @@ -18,7 +20,7 @@ weight: 30 {{< feature-state for_k8s_version="1.16" state="alpha" >}} 使用 `RequestedToCapacityRatioResourceAllocation` 优先级函数，可以将 kube-scheduler @@ -48,7 +50,7 @@ Kubernetes 1.16 在优先级函数中添加了一个新参数，该参数允许 （least requested）或 最多请求（most requested）计算。 `resources` 包含由 `name` 和 `weight` 组成，`name` 指定评分时要考虑的资源， -`weight` 指定每种资源的权重。 +`weight` 指定每种资源的权重。 它可以用来添加扩展资源，如下所示： @@ -249,4 +251,3 @@ CPU = resourceScoringFunction((2+6),8) NodeScore = (5 * 5) + (7 * 1) + (10 * 3) / (5 + 1 + 3) = 7 ``` - diff --git a/content/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md b/content/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md index 42894aca1e..8a43385d13 100644 --- a/content/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md +++ b/content/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md @@ -1,14 +1,16 @@ --- title: 调度器性能调优 content_type: concept -weight: 80 +weight: 100 --- @@ -45,7 +47,7 @@ large Kubernetes clusters. - ### 设置阈值 - -要修改这个值，编辑 [kube-scheduler 的配置文件](/zh/docs/reference/config-api/kube-scheduler-config.v1beta1/)， -之后重启调度器。 -在很多场合下，配置文件位于 `/etc/kubernetes/config/kube-scheduler.yaml`。 +In many cases, the configuration file can be found at `/etc/kubernetes/config/kube-scheduler.yaml` + --> +要修改这个值，先编辑 [kube-scheduler 的配置文件](/zh/docs/reference/config-api/kube-scheduler-config.v1beta1/) +然后重启调度器。 +大多数情况下，这个配置文件是 `/etc/kubernetes/config/kube-scheduler.yaml`。 - 修改完成后，你可以执行 @@ -96,17 +98,17 @@ After you have made this change, you can run kubectl get pods -n kube-system | grep kube-scheduler ``` - 来检查该 kube-scheduler 组件是否健康。 - ## 节点打分阈值 {#percentage-of-nodes-to-score} - -你可以使用整个集群节点总数的百分比作为阈值来指定需要多少节点就足够。 +你可以使用整个集群节点总数的百分比作为阈值来指定需要多少节点就足够。 kube-scheduler 会将它转换为节点数的整数值。在调度期间，如果 kube-scheduler 已确认的可调度节点数足以超过了配置的百分比数量， kube-scheduler 将停止继续查找可调度节点并继续进行 [打分阶段](/zh/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler-implementation)。 - [调度器如何遍历节点](#how-the-scheduler-iterates-over-nodes) 详细介绍了这个过程。 - ### 默认阈值 - 这意味着，调度器至少会对集群中 5% 的节点进行打分，除非用户将该参数设置的低于 5。 - 如果你想让调度器对集群内所有节点进行打分，则将 `percentageOfNodesToScore` 设置为 100。 - ## 示例 @@ -189,15 +191,15 @@ percentageOfNodesToScore: 50 `percentageOfNodesToScore` 的值必须在 1 到 100 之间，而且其默认值是通过集群的规模计算得来的。 另外，还有一个 50 个 Node 的最小值是硬编码在程序中。 在评估完所有 Node 后，将会返回到 Node 1，从头开始。 - ## {{% heading "whatsnext" %}} -* 查阅 [kube-scheduler 配置参考 (v1beta1)](/zh/docs/reference/config-api/kube-scheduler-config.v1beta1/) + +* 参见 [kube-scheduler 配置参考 (v1beta1)](/zh/docs/reference/config-api/kube-scheduler-config.v1beta1/) diff --git a/content/zh/docs/concepts/scheduling-eviction/scheduling-framework.md b/content/zh/docs/concepts/scheduling-eviction/scheduling-framework.md index 5927a4c8f3..1107c19565 100644 --- a/content/zh/docs/concepts/scheduling-eviction/scheduling-framework.md +++ b/content/zh/docs/concepts/scheduling-eviction/scheduling-framework.md @@ -1,15 +1,17 @@ --- title: 调度框架 content_type: concept -weight: 70 +weight: 90 --- @@ -17,17 +19,15 @@ weight: 70 {{< feature-state for_k8s_version="1.15" state="alpha" >}} -调度框架是 Kubernetes 调度器的一种可插入架构。 -调度框架向现有的调度器增加了一组新的“插件（Plugin）” API。 -插件被编译到调度器程序中。 + +调度框架是面向 Kubernetes 调度器的一种插件架构， +它为现有的调度器添加了一组新的“插件” API。插件会被编译到调度器之中。 这些 API 允许大多数调度功能以插件的形式实现，同时使调度“核心”保持简单且可维护。 请参考[调度框架的设计提案](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/624-scheduling-framework/README.md) 获取框架设计的更多技术信息。 @@ -98,7 +98,7 @@ stateful tasks. --> 一个插件可以在多个扩展点处注册，以执行更复杂或有状态的任务。 - {{< figure src="/images/docs/scheduling-framework-extensions.png" title="调度框架扩展点" >}} @@ -163,12 +163,12 @@ tries to make the pod schedulable by preempting other Pods. 则其余的插件不会调用。典型的后筛选实现是抢占，试图通过抢占其他 Pod 的资源使该 Pod 可以调度。 - ### 前置评分 {#pre-score} - ### 评分 {#scoring} @@ -325,17 +325,17 @@ _Permit_ 插件在每个 Pod 调度周期的最后调用，用于防止或延迟 将返回调度队列，从而触发 [Unreserve](#unreserve) 插件。 - {{< note >}} -尽管任何插件可以访问 “等待中” 状态的 Pod 列表并批准它们 -（参阅 [`FrameworkHandle`](https://git.k8s.io/enhancements/keps/sig-scheduling/624-scheduling-framework#frameworkhandle)）。 -我们希望只有被允许的插件可以批准处于“等待中”状态的预留 Pod 的绑定。 -一旦 Pod 被批准了，它将进入到[预绑定](#pre-bind) 阶段。 +尽管任何插件可以访问 “等待中” 状态的 Pod 列表并批准它们 +(查看 [`FrameworkHandle`](https://git.k8s.io/enhancements/keps/sig-scheduling/624-scheduling-framework#frameworkhandle))。 +我们期望只有允许插件可以批准处于 “等待中” 状态的预留 Pod 的绑定。 +一旦 Pod 被批准了，它将发送到[预绑定](#pre-bind) 阶段。 {{< /note >}} # 插件配置 - @@ -498,7 +498,7 @@ DaemonSet 控制器自动为所有守护进程添加如下 `NoSchedule` 容忍 * `node.kubernetes.io/memory-pressure` * `node.kubernetes.io/disk-pressure` - * `node.kubernetes.io/out-of-disk` (*只适合关键 Pod*) + * `node.kubernetes.io/pid-pressure` (1.14 或更高版本) * `node.kubernetes.io/unschedulable` (1.10 或更高版本) * `node.kubernetes.io/network-unavailable` (*只适合主机网络配置*) From 23dbe3823b2e2222d13750e7764be99ded490c4c Mon Sep 17 00:00:00 2001 From: liuwei10 Date: Mon, 31 May 2021 15:42:55 +0800 Subject: [PATCH 065/128] modify error of zh md --- .../zh/docs/tasks/run-application/horizontal-pod-autoscale.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/zh/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/zh/docs/tasks/run-application/horizontal-pod-autoscale.md index 4d4c8416c2..bc9702e8f0 100644 --- a/content/zh/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/zh/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -634,7 +634,7 @@ APIs, cluster administrators must ensure that: * 相应的 API 已注册： * 对于资源指标，将使用 `metrics.k8s.io` API，一般由 [metrics-server](https://github.com/kubernetes-incubator/metrics-server) 提供。 - 它可以做为集群插件启动。 + 它可以作为集群插件启动。 * 对于自定义指标，将使用 `custom.metrics.k8s.io` API。 它由其他度量指标方案厂商的“适配器（Adapter）” API 服务器提供。 From 9f09fe0e943dbc8ec48539e84dc2d2e3060e34a1 Mon Sep 17 00:00:00 2001 From: yaohaoyun Date: Mon, 31 May 2021 15:59:18 +0800 Subject: [PATCH 066/128] replace http link to https --- content/en/blog/_posts/2018-01-00-Core-Workloads-Api-Ga.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/blog/_posts/2018-01-00-Core-Workloads-Api-Ga.md b/content/en/blog/_posts/2018-01-00-Core-Workloads-Api-Ga.md index 385e6a814a..cf7cc12c92 100644 --- a/content/en/blog/_posts/2018-01-00-Core-Workloads-Api-Ga.md +++ b/content/en/blog/_posts/2018-01-00-Core-Workloads-Api-Ga.md @@ -95,7 +95,7 @@ The core workloads API surface is stable, but it’s still software, and softwar --Kenneth Owens, Software Engineer, Google -- [Download](http://get.k8s.io/) Kubernetes +- [Download](https://get.k8s.io/) Kubernetes - Get involved with the Kubernetes project on [GitHub](https://github.com/kubernetes/kubernetes) - Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes) - Connect with the community on [Slack](http://slack.k8s.io/) From 428e30e5211acd6add9f4b218bde1bbf3c6bd236 Mon Sep 17 00:00:00 2001 From: yaohaoyun Date: Mon, 31 May 2021 17:18:47 +0800 Subject: [PATCH 067/128] optimize zh doc translation --- .../_posts/2019-05-14-expanding-our-contributor-workshops.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/zh/blog/_posts/2019-05-14-expanding-our-contributor-workshops.md b/content/zh/blog/_posts/2019-05-14-expanding-our-contributor-workshops.md index 9fed26b2c7..8fb0f2b32f 100644 --- a/content/zh/blog/_posts/2019-05-14-expanding-our-contributor-workshops.md +++ b/content/zh/blog/_posts/2019-05-14-expanding-our-contributor-workshops.md @@ -71,7 +71,7 @@ In the 201 track, we will have a codebase walkthrough and local development and For both tracks, you will have a chance to get your hands dirty and have some fun. Because not every contributor works with code, and not every contribution is technical, we will spend the beginning of the workshop learning how our project is structured and organized, where to find the right people, and where to get help when stuck. --> -对于这两门课程，你将有机会亲自动手并体会到其中的乐趣。因为不是每个贡献者都使用代码，也不是每项贡献都包含技术性的，所以我们将在研讨会开始时学习如何构建和组织项目，以及如何进行找到合适的人，以及遇到困难时在哪里寻求帮助。 +对于这两门课程，你将有机会亲自动手并体会到其中的乐趣。因为不是每个贡献者都使用代码，也不是每项贡献都是技术性的，所以我们将在研讨会开始时学习如何构建和组织项目，以及如何进行找到合适的人，以及遇到困难时在哪里寻求帮助。 t92&$qGcZ*_dEoBRHM8a**@=_w8I|+v=!c>qK1{2`p;x%UH;^X6H=Y^W` zvKw;=aNiY>iyO{uVgfdSL;tq(pYS|T0VxQ#gg6hk3MTY^wV8iV%*LH`~VpLJz@Tvu>PTc z!7(u~?xc6mKZ5^uaQg{Bj0f-ne8IvX24E6nU=d^7b^-G5&JL{Kw*P&s;N8c^y@!MS zn}_vV_KySu6ASMi?tN?=A^_kXCI%KJ7WTb+fBY8TNw9J50dVn%AKjkdbZMGO!HEXiPDcz=4sMfu>~|KWj8`}4QC>uIu1 z8o!odi-OiqEH|tj*B(s@hh@qll^=gB7Lt9fD4G-+RzGPJuRw75{rE$HZv37hX)bF= zk8*VIeQzP<`2}^bRNkW@C6$<#shF2u}53Jqf(+FpM=WEW>2nC+K`tmH^B2% z9?0_URs#5eM{In75|m=tZh&9Qj%WN#a~>2-I-6|#Aww@?gM(6*=8H*$7)+J(oVIn6 zf|ACW`kQ2Hp(Fb{E*Jbv7CCcOR!cCQT(;H;;+&D$kS;5#xv`QiD=>A619?t#?$bpx z-4Ka4SmksFISFsxVt0gehYNT=+#;sS*cw$kTv})%_R@PoBdbfa=LI{fpLiT4>tK28J z=u=L|Q!|U+1>tl9%00nX&r)^Duc20@&(QOo<)kiMg7;h%y9~{?QAImN9(lI_*YxmW zjcu~o6lCon_ev?q>ZEAbAsEq6$RvBk{-sBzS{<$;S}B3IvRt9p{%yUR-unT~(nJe3 zK(c6BBSM_8H5cOYK>gBBFhE)N-1!&Qx8-giuF-x=zNp5j`jbfvLt+|BSLa{P(g!z0 zsgI{id>7}9T&&og3rnAao)*mvdNhLYF-NA`sZzV1{G3ntp)P!xWRZ(8h^8WgPstVz zh%@8)!-#nVrI0U&-z_k$(Y4T@TQ1Z^#A*?;q;-2~|0t|Kqo1m)S&6W1i&oknivxZ#fbdRtn615BuKSNwNx^F6fm&F9ov^@Hk+N0ILCMu@qPky`+#IsZp?V#nHXlo9iwpQ#{< z@R0+AnVG2f-Y|)-J-w7z8bFp!Nou6;<CD9yzPNNYZ(X{^VtiKlG|+l5FU08e zy{SF9>g4`6d-8gjQE47u{6^Dg#o!0`6FW4~;N-cc<*G=7(KRp9&(?JeP=dnai+%lT z1GLEa1~Dx>&T2~HT1i^1jJ$F%Ya!}gOO>?ZWHzl^z#}#*8-MruGkh0+Ti#gU;i_-1 zwg$s_iidjBw7*=>7VW?Qg}w*$5pzW0wcHcB77@GAfwp!ls!;pyE$8Jsm#-9!zRwF8 z%;^`b-CI>ju!7)U5ozr$0txj}msQT+<&1>J5BST5|^}b&ATTDyC?ISlOL> z*d+0#$Oep|lKEm7L_DSJ`IJc!r|EOew)iE*0Lf?uQy;RAhwYGc3O_=d{mf zS9*u0W$ie`FmuTs)C)Z|Ajb4$ z2$r0=Z>iU`D)O`I_lt(eJY^cz@#*ur*qYYYulYul05?E7ONkZA%`@_OdyD7jOzO-J z(IWkr?KGa~;PE5}v*sIt;`bG|fRY=VoYT&+;z_r1?M*XCD-9*flK_3w>RZ6Z6ANwA zjkeP^_iIj{*44|Kt92EJqW!raBPpMq-J7<{pbc*Yq`Y_L+HG-O7 z2UNhr9Ucn(0SclFP>)T8b*rlZ#M}u*uyJPu(B9*f6xY?hTYx=`ug~pREISWb*0QVA`^RhWNX!(|0qG_MN5H4-T;XEbGVN<4@}*P zI~JdOQ|*&n)LlP|h`ZsoV~98e1Pm{6fsZyT7FHJI$oNSH1!@!&eP4$AxxgdyB@%Oa zDA!6s=X5LRMQBS?2;wzTaDMglC(3_a1?4_$= z-%TASYMiC7(0V#)L1ArlP-B%=TkV4^;LUi6|HP`ZpxEq32rARe!q*J^Na@RgxyRe` z6t|a$xL0${jyF1mUIA(T5#-=YlG6i(QQ894nyLU~LxUpWCu2;OrM^bWH0WNrzTPPh3}PQdFt4mFndzD)bfdFlgG`g&D|`e^KCJ3s%MRgWX8i-%;`)TvDixudSUCrpBR&y*y@R$wuzqXdBzan*r0A?b%qP~M zkLPqo)Xizptf^Z@nTTkeT5apz&1laMvz09Czj(Q}f7t`SrovC!KcZA#1AdH*?|hQGH2QMV>E_ z+cVqF6c2N@M>zPihewBAB!`iW+47Lcm4d@V{6Y*!L#>C6nd<;H6B`MPc~N9#-QDMb z2f6FF0Ha?U8)lQ4cDDctH9oqQsT~!~(rR|EhjNL2@iJzQvpF^FwG@D~NxTM>LNu8D zl(<s={mSHht)yHwc+B;%+j$+R%aSbc6OE;)Q&mHb^V$*GRCjGl^yv zkzVygnUQ)+4U*+8v)ArgvxV!czuxH;!D>pdOd&g?i=A>;HMEVO^aFUw*n2e-I;VZ*a=P)GqgdgM$%pW>uRQ$-8xX6Gk zG`B(djQQF*pj;`gjI0n& zh%jXA_Aw>+Vpp0)euCoPCyXFhD~dUj_b!~fnHHhj;oYHZQQ4X7A4FdX?9-$RNll;c z#mDzrPf$POk`dBlDe){Vr6})L&DdOSE`Qxfa6xV>*JS(bg>B*H;Ct7rxYbr+((dR6 zD_{0n(fZWboMq+uLh{^J_aTh~hc+YbFT;oKL&J+3o3TSzvcI-sdG@5Kd2RvK?&I|4 zY?_Rbr33uzex~N@LSq~$GZB4B+FBvhzlu7TA!hh_GQKw+qhku)Y`w@^!1swdTmjA8 zU%0&?UbNM*uloFafcp$s;?7YnRwuCR>+PN%e{Crdo zPRVdkc?LwmQ}AQoPAYas4CS}*0fsHH!4LQQT@TdxLdW&;-!JV5TubNFToHbpt_jiV zi2II&7wxWo25f7zc1pdrX zJ09pjEw5(>{Hn@#4DdbE(yw`zocU>o7O9@EOI$Ku%x=Kr7p$Ne^idOqUum=L%o=l~ zi(p)0`F!nL^z9Lb0#GeHMsRi7`4+%0vw90SFKO_(DyAo?fom<@wR>+RPt@<$xmM29EQz%2#!3wUadwve>e zr#_|2wYL;$--hz|Lu_n)6kvFWga9Ju`+oR}*!M?lyfH;`Sfr#pKM^+Q9rV-%AXw1B z#l6*@bFn0FI%x5(d{fo*R^)e9u9`BPN@szUTzVyus4-dX@w_Jzpx~hwJ~8ceI!8Cl z_q;t?65RGCx&p}_`NUYB4};VDb99q4D=h{5KX&a|6;Jf^l1S#8S&rg=C{bv<#KQ@Pk6f-Cfp6h6+jsa73s`*Gsq0BE5HM+;7V zIztt*$$Vc^{X5VmZ8chV^`g!9%7t1ZDf6dofR-Y)G;Ei*jQLYF*ew-`2dYlB|tiRxP17sV!B zty!(%UN0HyvR6j->SPp6hV)KuEnC0HKW!~lf zNpLKRY%Mz(8dF3s?|xL;hC)+gdvz{H3Z*CufO9Asr3*G3@}Uqz*)qPJ~8mO-_8ekHseoS5>QML{Cgk3~*` z6kmcAkjtV#i?0zYh@qfH=#BAnq#!7y>t#hQ3@tD+T~o?eJv3*oo3zZmDfHgAb$U`? z^A+S{OF_e|;L?FO(kfhOM{b&;ewvZ3;EN6@rWT*|luVuo6{XPl3_K3N!4nN)A<6mP zH=T3Zf!Y-Je|Pczu*!TQu$GA?E=&1!c`X5f6+Rdrs>gCapUh*Cv^vFQBb^nksiPt_ zk`<!<6w182}gDw8Fpjj2;Xb(=>lOSeu1Ss1k2rbrA z!sc396F!hx=;C@5RkU;9Hm~FAC!bzZRwY4Izod0ZIv%Bl#3PvHdb1?MG5HN#OrFa^ zWF4EC;?D&iCqdhFHtYKn+Lw^Yh@Bh#-+SNTY@G%bdm};#T zKt^#yLNcw-o<3&xb~-zItVBair^ifsxmeB^w2lq7&A9t~np`whB&4qDq0Ln~dMAUs6j~uJgtr3wn9Di@_FS$@xHjwQjM# z#CaxCyDkJ_UEY;U-}el5_x%3srm2zznMvP@-pWbrOj^G%p?P-CT+9_igP!s2s&CIR z8?y_q>L<0;wCR=T=U{Xs9*Fkrt;I~jfGbUzA>}WZ+UQb7v94TEL{ ztt9U%`bB3Oa|MUz8eBxq`N}B11n<_xaN4$|eKe7xtPV@&Jqp;amK|#XDudOf@!=7A z-;Vg!4%9j`Y*jg3nmp=mxRB?z(PZ^H}d+L#H-BI68$pS>()Wsg zBwN*(ye5}KrpS^YIgdd4?AG|c*VW6!QAD9w~CXCo+_g$hE4G4WXhAOgVJ R?Uet&{~zE#M<{wb`#*xsh{XT^ From c0d1bef1b1f2c0ca4b0c03d0b3d392705bacfc1e Mon Sep 17 00:00:00 2001 From: liuwei10 Date: Mon, 31 May 2021 17:39:31 +0800 Subject: [PATCH 069/128] modify error of zh docs --- content/zh/docs/tasks/job/automated-tasks-with-cron-jobs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/zh/docs/tasks/job/automated-tasks-with-cron-jobs.md b/content/zh/docs/tasks/job/automated-tasks-with-cron-jobs.md index 6de803ec91..b4039ee281 100644 --- a/content/zh/docs/tasks/job/automated-tasks-with-cron-jobs.md +++ b/content/zh/docs/tasks/job/automated-tasks-with-cron-jobs.md @@ -227,7 +227,7 @@ It takes a [Cron](https://en.wikipedia.org/wiki/Cron) format string, such as `0 ### 时间安排 `.spec.schedule` 是 `.spec` 需要的域。它使用了 [Cron](https://en.wikipedia.org/wiki/Cron) -格式串，例如 `0 * * * *` or `@hourly` ，做为它的任务被创建和执行的调度时间。 +格式串，例如 `0 * * * *` or `@hourly` ，作为它的任务被创建和执行的调度时间。 +### 你的服务在正确的命名空间中吗？ + +未指定命名空间的 DNS 查询仅作用于 pod 所在的命名空间。 + +如果 pod 和服务的命名空间不相同，则 DNS 查询必须指定服务所在的命名空间。 + +该查询仅限于 pod 所在的名称空间： +```shell +kubectl exec -i -t dnsutils -- nslookup +``` + + +指定命名空间的查询： +```shell +kubectl exec -i -t dnsutils -- nslookup . +``` + + +要进一步了解名字解析，请查看 +[服务和 Pod 的 DNS](/zh/docs/concepts/services-networking/dns-pod-service/#what-things-get-dns-names)。 + + +{{< feature-state for_k8s_version="v1.18" state="stable" >}} + +이 페이지에서는 윈도우 노드에서 실행될 파드 및 컨테이너에 `runAsUserName` 설정을 사용하는 방법을 소개한다. 이는 리눅스 관련 `runAsUser` 설정과 거의 동일하여, 컨테이너의 기본값과 다른 username으로 애플리케이션을 실행할 수 있다. + + + +## {{% heading "prerequisites" %}} + + +쿠버네티스 클러스터가 있어야 하며 클러스터와 통신하도록 kubectl 명령줄 도구를 구성해야 한다. 클러스터에는 윈도우 워커 노드가 있어야 하고, 해당 노드에서 윈도우 워크로드를 실행하는 컨테이너의 파드가 스케쥴 된다. + + + + + +## 파드의 username 설정 + +파드의 컨테이너 프로세스를 실행할 username을 지정하려면 파드 명세에 `securityContext` 필드 ([PodSecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritycontext-v1-core)) 를 포함시키고, 그 안에 `runAsUserName` 필드를 포함하는 `windowsOptions` ([WindowsSecurityContextOptions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#windowssecuritycontextoptions-v1-core)) 필드를 추가한다. + +파드에 지정하는 윈도우 보안 컨텍스트 옵션은 파드의 모든 컨테이너 및 초기화 컨테이너에 적용된다. + +다음은 `runAsUserName` 필드가 설정된 윈도우 파드의 구성 파일이다. + +{{< codenew file="windows/run-as-username-pod.yaml" >}} + +파드를 생성한다. + +```shell +kubectl apply -f https://k8s.io/examples/windows/run-as-username-pod.yaml +``` + +파드의 컨테이너가 실행 중인지 확인한다. + +```shell +kubectl get pod run-as-username-pod-demo +``` + +실행 중인 컨테이너의 셸에 접근한다. + +```shell +kubectl exec -it run-as-username-pod-demo -- powershell +``` + +셸이 올바른 username인 사용자로 실행 중인지 확인한다. + +```powershell +echo $env:USERNAME +``` + +결과는 다음과 같다. + +```shell +ContainerUser +``` + +## 컨테이너의 username 설정 + +컨테이너의 프로세스를 실행할 username을 지정하려면, 컨테이너 매니페스트에 `securityContext` 필드 ([SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core)) 를 포함시키고 그 안에 `runAsUserName` 필드를 포함하는 `windowsOptions` ([WindowsSecurityContextOptions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#windowssecuritycontextoptions-v1-core)) 필드를 추가한다. + +컨테이너에 지정하는 윈도우 보안 컨텍스트 옵션은 해당 개별 컨테이너에만 적용되며 파드 수준에서 지정한 설정을 재정의한다. + +다음은 한 개의 컨테이너에 `runAsUserName` 필드가 파드 수준 및 컨테이너 수준에서 설정되는 파드의 구성 파일이다. + +{{< codenew file="windows/run-as-username-container.yaml" >}} + +파드를 생성한다. + +```shell +kubectl apply -f https://k8s.io/examples/windows/run-as-username-container.yaml +``` + +파드의 컨테이너가 실행 중인지 확인한다. + +```shell +kubectl get pod run-as-username-container-demo +``` + +실행 중인 컨테이너의 셸에 접근한다. + +```shell +kubectl exec -it run-as-username-container-demo -- powershell +``` + +셸이 사용자에게 올바른 username(컨테이너 수준에서 설정된 사용자)을 실행 중인지 확인한다. + +```powershell +echo $env:USERNAME +``` + +결과는 다음과 같다. + +```shell +ContainerAdministrator +``` + +## 윈도우 username 제약사항 + +이 기능을 사용하려면 `runAsUserName` 필드에 설정된 값이 유효한 username이어야 한다. 형식은 `DOMAIN\USER` 여야하고, 여기서 `DOMAIN\`은 선택 사항이다. 윈도우 username은 대소문자를 구분하지 않는다. 또한 `DOMAIN` 및 `USER` 와 관련된 몇 가지 제약사항이 있다. + +- `runAsUserName` 필드는 비워 둘 수 없으며 제어 문자를 포함할 수 없다. (ASCII 값: `0x00-0x1F`, `0x7F`) +- `DOMAIN`은 NetBios 이름 또는 DNS 이름이어야 하며 각각 고유한 제한이 있다. + - NetBios 이름: 최대 15 자, `.`(마침표)으로 시작할 수 없으며 다음 문자를 포함할 수 없다. `\ / : * ? " < > |` + - DNS 이름: 최대 255 자로 영숫자, 마침표(`.`), 대시(`-`)로만 구성되며, 마침표 또는 대시로 시작하거나 끝날 수 없다. +- `USER`는 최대 20자이며, *오직* 마침표나 공백들로는 구성할 수 없고, 다음 문자는 포함할 수 없다. `" / \ [ ] : ; | = , + * ? < > @`. + +`runAsUserName` 필드에 허용되는 값의 예 : `ContainerAdministrator`,`ContainerUser`, `NT AUTHORITY\NETWORK SERVICE`, `NT AUTHORITY\LOCAL SERVICE`. + +이러한 제약사항에 대한 자세한 내용은 [여기](https://support.microsoft.com/en-us/help/909264/naming-conventions-in-active-directory-for-computers-domains-sites-and) 와 [여기](https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.localaccounts/new-localuser?view=powershell-5.1)를 확인한다. + + + +## {{% heading "whatsnext" %}} + + +* [쿠버네티스에서 윈도우 컨테이너 스케줄링을 위한 가이드](/ko/docs/setup/production-environment/windows/user-guide-windows-containers/) +* [그룹 매니지드 서비스 어카운트를 이용하여 워크로드 신원 관리하기](/ko/docs/setup/production-environment/windows/user-guide-windows-containers/#그룹-매니지드-서비스-어카운트를-이용하여-워크로드-신원-관리하기) +* [윈도우 파드와 컨테이너의 GMSA 구성](/docs/tasks/configure-pod-container/configure-gmsa/) + diff --git a/content/ko/examples/windows/configmap-pod.yaml b/content/ko/examples/windows/configmap-pod.yaml new file mode 100644 index 0000000000..661cb73dee --- /dev/null +++ b/content/ko/examples/windows/configmap-pod.yaml @@ -0,0 +1,31 @@ +kind: ConfigMap +apiVersion: v1 +metadata: + name: example-config +data: + example.property.1: hello + example.property.2: world + +--- + +apiVersion: v1 +kind: Pod +metadata: + name: configmap-pod +spec: + containers: + - name: configmap-redis + image: redis:3.0-nanoserver + env: + - name: EXAMPLE_PROPERTY_1 + valueFrom: + configMapKeyRef: + name: example-config + key: example.property.1 + - name: EXAMPLE_PROPERTY_2 + valueFrom: + configMapKeyRef: + name: example-config + key: example.property.2 + nodeSelector: + kubernetes.io/os: windows \ No newline at end of file diff --git a/content/ko/examples/windows/daemonset.yaml b/content/ko/examples/windows/daemonset.yaml new file mode 100644 index 0000000000..7483708fc7 --- /dev/null +++ b/content/ko/examples/windows/daemonset.yaml @@ -0,0 +1,21 @@ +apiVersion: apps/v1 +kind: DaemonSet +metadata: + name: my-daemonset + labels: + app: foo +spec: + selector: + matchLabels: + app: foo + template: + metadata: + labels: + app: foo + spec: + containers: + - name: foo + image: microsoft/windowsservercore:1709 + nodeSelector: + kubernetes.io/os: windows + diff --git a/content/ko/examples/windows/deploy-hyperv.yaml b/content/ko/examples/windows/deploy-hyperv.yaml new file mode 100644 index 0000000000..c8b71ce8cb --- /dev/null +++ b/content/ko/examples/windows/deploy-hyperv.yaml @@ -0,0 +1,22 @@ +apiVersion: apps/v1 +kind: Deployment +metadata: + name: iis +spec: + selector: + matchLabels: + app: iis + replicas: 3 + template: + metadata: + labels: + app: iis + annotations: + experimental.windows.kubernetes.io/isolation-type: hyperv + spec: + containers: + - name: iis + image: microsoft/iis + ports: + - containerPort: 80 + diff --git a/content/ko/examples/windows/deploy-resource.yaml b/content/ko/examples/windows/deploy-resource.yaml new file mode 100644 index 0000000000..81207a3804 --- /dev/null +++ b/content/ko/examples/windows/deploy-resource.yaml @@ -0,0 +1,24 @@ +apiVersion: apps/v1 +kind: Deployment +metadata: + name: iis +spec: + replicas: 3 + selector: + matchLabels: + app: iis + template: + metadata: + labels: + app: iis + spec: + containers: + - name: iis + image: microsoft/iis + resources: + limits: + memory: "128Mi" + cpu: 2 + ports: + - containerPort: 80 + diff --git a/content/ko/examples/windows/emptydir-pod.yaml b/content/ko/examples/windows/emptydir-pod.yaml new file mode 100644 index 0000000000..08d8091391 --- /dev/null +++ b/content/ko/examples/windows/emptydir-pod.yaml @@ -0,0 +1,20 @@ +apiVersion: v1 +kind: Pod +metadata: + name: my-empty-dir-pod +spec: + containers: + - image: microsoft/windowsservercore:1709 + name: my-empty-dir-pod + volumeMounts: + - mountPath: /cache + name: cache-volume + - mountPath: C:/scratch + name: scratch-volume + volumes: + - name: cache-volume + emptyDir: {} + - name: scratch-volume + emptyDir: {} + nodeSelector: + kubernetes.io/os: windows diff --git a/content/ko/examples/windows/hostpath-volume-pod.yaml b/content/ko/examples/windows/hostpath-volume-pod.yaml new file mode 100644 index 0000000000..d95e345b6c --- /dev/null +++ b/content/ko/examples/windows/hostpath-volume-pod.yaml @@ -0,0 +1,18 @@ +apiVersion: v1 +kind: Pod +metadata: + name: hostpath-volume-pod +spec: + containers: + - name: my-hostpath-volume-pod + image: microsoft/windowsservercore:1709 + volumeMounts: + - name: foo + mountPath: "C:\\etc\\foo" + readOnly: true + nodeSelector: + kubernetes.io/os: windows + volumes: + - name: foo + hostPath: + path: "C:\\etc\\foo" diff --git a/content/ko/examples/windows/run-as-username-container.yaml b/content/ko/examples/windows/run-as-username-container.yaml new file mode 100644 index 0000000000..77b7b2d188 --- /dev/null +++ b/content/ko/examples/windows/run-as-username-container.yaml @@ -0,0 +1,17 @@ +apiVersion: v1 +kind: Pod +metadata: + name: run-as-username-container-demo +spec: + securityContext: + windowsOptions: + runAsUserName: "ContainerUser" + containers: + - name: run-as-username-demo + image: mcr.microsoft.com/windows/servercore:ltsc2019 + command: ["ping", "-t", "localhost"] + securityContext: + windowsOptions: + runAsUserName: "ContainerAdministrator" + nodeSelector: + kubernetes.io/os: windows diff --git a/content/ko/examples/windows/run-as-username-pod.yaml b/content/ko/examples/windows/run-as-username-pod.yaml new file mode 100644 index 0000000000..281bbda597 --- /dev/null +++ b/content/ko/examples/windows/run-as-username-pod.yaml @@ -0,0 +1,14 @@ +apiVersion: v1 +kind: Pod +metadata: + name: run-as-username-pod-demo +spec: + securityContext: + windowsOptions: + runAsUserName: "ContainerUser" + containers: + - name: run-as-username-demo + image: mcr.microsoft.com/windows/servercore:ltsc2019 + command: ["ping", "-t", "localhost"] + nodeSelector: + kubernetes.io/os: windows diff --git a/content/ko/examples/windows/secret-pod.yaml b/content/ko/examples/windows/secret-pod.yaml new file mode 100644 index 0000000000..69ee9b1f1e --- /dev/null +++ b/content/ko/examples/windows/secret-pod.yaml @@ -0,0 +1,32 @@ +apiVersion: v1 +kind: Secret +metadata: + name: mysecret +type: Opaque +data: + username: YWRtaW4= + password: MWYyZDFlMmU2N2Rm + +--- + +apiVersion: v1 +kind: Pod +metadata: + name: my-secret-pod +spec: + containers: + - name: my-secret-pod + image: microsoft/windowsservercore:1709 + env: + - name: USERNAME + valueFrom: + secretKeyRef: + name: mysecret + key: username + - name: PASSWORD + valueFrom: + secretKeyRef: + name: mysecret + key: password + nodeSelector: + kubernetes.io/os: windows diff --git a/content/ko/examples/windows/simple-pod.yaml b/content/ko/examples/windows/simple-pod.yaml new file mode 100644 index 0000000000..0b1f0ed5c5 --- /dev/null +++ b/content/ko/examples/windows/simple-pod.yaml @@ -0,0 +1,14 @@ +apiVersion: v1 +kind: Pod +metadata: + name: iis + labels: + name: iis +spec: + containers: + - name: iis + image: microsoft/iis:windowsservercore-1709 + ports: + - containerPort: 80 + nodeSelector: + "kubernetes.io/os": windows From 5e27d2ee604410b0a4bec5827acfbf80b537ded0 Mon Sep 17 00:00:00 2001 From: Arhell Date: Wed, 2 Jun 2021 00:12:56 +0300 Subject: [PATCH 075/128] [uk] Add configuration java microservice & translate --- content/uk/docs/tutorials/_index.md | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/content/uk/docs/tutorials/_index.md b/content/uk/docs/tutorials/_index.md index 09c8b1e7a8..c87a5155a0 100644 --- a/content/uk/docs/tutorials/_index.md +++ b/content/uk/docs/tutorials/_index.md @@ -29,9 +29,9 @@ Before walking through each tutorial, you may want to bookmark the --> * [Основи Kubernetes](/docs/tutorials/kubernetes-basics/) - детальний навчальний матеріал з інтерактивними уроками, що допоможе вам зрозуміти Kubernetes і спробувати його базову функціональність. -* [Scalable Microservices with Kubernetes (Udacity)](https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615) +* [Масштабовані мікросервіси з Kubernetes (Udacity)](https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615) -* [Introduction to Kubernetes (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x#) +* [Вступ до Kubernetes (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x#) * [Привіт Minikube](/docs/tutorials/hello-minikube/) @@ -39,23 +39,25 @@ Before walking through each tutorial, you may want to bookmark the --> ## Конфігурація -* [Configuring Redis Using a ConfigMap](/docs/tutorials/configuration/configure-redis-using-configmap/) +* [Приклад: Конфігурування Java мікросервісу](/docs/tutorials/configuration/configure-java-microservice/) + +* [Конфігурування Redis використовуючи ConfigMap](/docs/tutorials/configuration/configure-redis-using-configmap/) ## Застосунки без стану (Stateless Applications) {#застосунки-без-стану} -* [Exposing an External IP Address to Access an Application in a Cluster](/docs/tutorials/stateless-application/expose-external-ip-address/) +* [Відкриття зовнішньої IP-адреси для доступу до програми в кластері](/docs/tutorials/stateless-application/expose-external-ip-address/) -* [Example: Deploying PHP Guestbook application with Redis](/docs/tutorials/stateless-application/guestbook/) +* [Приклад: Розгортання застосунку PHP Guestbook з Redis](/docs/tutorials/stateless-application/guestbook/) ## Застосунки зі станом (Stateful Applications) {#застосунки-зі-станом} -* [StatefulSet Basics](/docs/tutorials/stateful-application/basic-stateful-set/) +* [Основи StatefulSet](/docs/tutorials/stateful-application/basic-stateful-set/) -* [Example: WordPress and MySQL with Persistent Volumes](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/) +* [Приклад: WordPress та MySQL із постійними томами](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/) -* [Example: Deploying Cassandra with Stateful Sets](/docs/tutorials/stateful-application/cassandra/) +* [Приклад: Розгортання Cassandra зі Stateful Sets](/docs/tutorials/stateful-application/cassandra/) -* [Running ZooKeeper, A CP Distributed System](/docs/tutorials/stateful-application/zookeeper/) +* [Запуск ZooKeeper, координатора розподіленої системи](/docs/tutorials/stateful-application/zookeeper/) ## Кластери @@ -63,7 +65,7 @@ Before walking through each tutorial, you may want to bookmark the ## Сервіси -* [Using Source IP](/docs/tutorials/services/source-ip/) +* [Використання Source IP](/docs/tutorials/services/source-ip/) From e10fada0073a6cb3ef8d94aadf5eeb85bcd3b1e0 Mon Sep 17 00:00:00 2001 From: Christoph Petrausch <263448+hikhvar@users.noreply.github.com> Date: Wed, 2 Jun 2021 03:42:33 +0200 Subject: [PATCH 076/128] [de] Add missing git submodules init to german README. (#24308) * Add missing git submodules init to german README. * Add links and comments to docsy theme installation * Adjust the JavaScript dependency managment from the english Readme --- README-de.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/README-de.md b/README-de.md index b6f4491e70..c901fdde65 100644 --- a/README-de.md +++ b/README-de.md @@ -37,6 +37,13 @@ Um die Kubernetes-Website lokal laufen zu lassen, empfiehlt es sich, ein speziel > Wenn Sie die Website lieber lokal ohne Docker ausführen möchten, finden Sie weitere Informationen unter [Website lokal mit Hugo ausführen](#Die-Site-lokal-mit-Hugo-ausführen). +Das benötigte [Docsy Hugo theme](https://github.com/google/docsy#readme) muss als git submodule installiert werden: + +``` +#Füge das Docsy submodule hinzu +git submodule update --init --recursive --depth 1 +``` + Wenn Sie Docker [installiert](https://www.docker.com/get-started) haben, erstellen Sie das Docker-Image `kubernetes-hugo` lokal: ```bash @@ -55,9 +62,18 @@ make container-serve Hugo-Installationsanweisungen finden Sie in der [offiziellen Hugo-Dokumentation](https://gohugo.io/getting-started/installing/). Stellen Sie sicher, dass Sie die Hugo-Version installieren, die in der Umgebungsvariablen `HUGO_VERSION` in der Datei [`netlify.toml`](netlify.toml#L9) angegeben ist. +Das benötigte [Docsy Hugo theme](https://github.com/google/docsy#readme) muss als git submodule installiert werden: + +``` +#Füge das Docsy submodule hinzu +git submodule update --init --recursive --depth 1 +``` + So führen Sie die Site lokal aus, wenn Sie Hugo installiert haben: ```bash +# Installieren der JavaScript Abhängigkeiten +npm ci make serve ``` From 88018a88f28e1bfd3151d0f300606721bb8a80d5 Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Mon, 31 May 2021 10:51:29 +0900 Subject: [PATCH 077/128] Update 'Attend KubeCon' buttons --- content/en/_index.html | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/en/_index.html b/content/en/_index.html index 13a3c069be..2abc22985c 100644 --- a/content/en/_index.html +++ b/content/en/_index.html @@ -43,12 +43,12 @@ Kubernetes is open source giving you the freedom to take advantage of on-premise

- Attend KubeCon NA virtually on November 17-20, 2020 + Attend KubeCon North America on October 11-15, 2021



- Attend KubeCon EU virtually on May 4 – 7, 2021 + Revisit KubeCon EU 2021
@@ -58,4 +58,4 @@ Kubernetes is open source giving you the freedom to take advantage of on-premise {{< blocks/kubernetes-features >}} -{{< blocks/case-studies >}} \ No newline at end of file +{{< blocks/case-studies >}} From 85965ec8d047dc849716b85caa7c88058f4ef2ee Mon Sep 17 00:00:00 2001 From: luzg Date: Mon, 31 May 2021 18:11:28 +0800 Subject: [PATCH 078/128] [zh] translate concepts/API-initiated Eviction --- .../scheduling-eviction/api-eviction.md | 38 +++++++++++++++ .../docs/reference/glossary/api-eviction.md | 47 +++++++++++++++++++ 2 files changed, 85 insertions(+) create mode 100644 content/zh/docs/concepts/scheduling-eviction/api-eviction.md create mode 100644 content/zh/docs/reference/glossary/api-eviction.md diff --git a/content/zh/docs/concepts/scheduling-eviction/api-eviction.md b/content/zh/docs/concepts/scheduling-eviction/api-eviction.md new file mode 100644 index 0000000000..ee90cf9dd6 --- /dev/null +++ b/content/zh/docs/concepts/scheduling-eviction/api-eviction.md @@ -0,0 +1,38 @@ +--- +title: API 发起的驱逐 +content_type: concept +weight: 70 +--- + +{{< glossary_definition term_id="api-eviction" length="short" >}}
+ + +你可以通过 kube-apiserver 的客户端，比如 `kubectl drain` 这样的命令，直接调用 Eviction API 发起驱逐。 +此操作创建一个 `Eviction` 对象，该对象再驱动 API 服务器终止选定的 Pod。 + +API 发起的驱逐将遵从你的 +[`PodDisruptionBudgets`](/zh/docs/tasks/run-application/configure-pdb/) +和 [`terminationGracePeriodSeconds`](/zh/docs/concepts/workloads/pods/pod-lifecycle#pod-termination) +配置。 + +## {{% heading "whatsnext" %}} + + +* 了解[节点压力引发的驱逐](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/) +* 了解 [Pod 优先级和抢占](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/) diff --git a/content/zh/docs/reference/glossary/api-eviction.md b/content/zh/docs/reference/glossary/api-eviction.md new file mode 100644 index 0000000000..9ce3069879 --- /dev/null +++ b/content/zh/docs/reference/glossary/api-eviction.md @@ -0,0 +1,47 @@ +--- +title: API 发起的驱逐 +id: api-eviction +date: 2021-04-27 +full_link: /zh/docs/concepts/scheduling-eviction/pod-eviction/#api-eviction +short_description: > + API 发起的驱逐是一个先调用 Eviction API 创建驱逐对象，再由该对象体面地中止 Pod 的过程。 +aka: +tags: +- operation +--- + + + +API 发起的驱逐是一个先调用 +[Eviction API](/docs/reference/generated/kubernetes-api/{{}}/create-eviction-pod-v1-core) +创建驱逐对象，再由该对象体面地中止 Pod 的过程。 + + + + +你可以通过 kube-apiserver 的客户端，比如 `kubectl drain` 这样的命令，直接调用 Eviction API 发起驱逐。 +当 `Eviction` 对象创建出来之后，该对象将驱动 API 服务器终止选定的Pod。 + +API 发起的驱逐不同于 +[节点压力引发的驱逐](/zh/docs/concepts/scheduling-eviction/eviction/#kubelet-eviction)。 From dbca4e41b7869fe68af086c82008a052f7d1ac61 Mon Sep 17 00:00:00 2001 From: Abigail McCarthy Date: Wed, 2 Jun 2021 14:05:40 -0400 Subject: [PATCH 079/128] Fix page title --- content/en/docs/contribute/analytics.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/en/docs/contribute/analytics.md b/content/en/docs/contribute/analytics.md index 6c8e56be43..ccffc79fdd 100644 --- a/content/en/docs/contribute/analytics.md +++ b/content/en/docs/contribute/analytics.md @@ -1,5 +1,5 @@ --- -title: Viewing site analytics +title: Viewing Site Analytics content_type: concept weight: 100 card: @@ -20,6 +20,6 @@ This dashboard is built using Google Data Studio and shows information collected ### Using the dashboard -By default, the dashboard will show all collected analytics for the past 30 days. Use the date selector to see data from a different date range. Other filtering options allow you to view data based on user location, the device used to access the site, the translation of the docs used, and more. +By default, the dashboard shows all collected analytics for the past 30 days. Use the date selector to see data from a different date range. Other filtering options allow you to view data based on user location, the device used to access the site, the translation of the docs used, and more. If you notice an issue with this dashboard, or would like to request any improvements, please [open an issue](https://github.com/kubernetes/website/issues/new/choose). From f0be2cf9a5a168ee2a7beb66d456d4c6585a0e92 Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Mon, 31 May 2021 18:11:27 +0900 Subject: [PATCH 080/128] [ko] Update outdated files in dev-1.21-ko.3 (p6) --- .../setup/production-environment/_index.md | 291 +++++++++++++++++- .../tools/kubeadm/control-plane-flags.md | 10 +- 2 files changed, 297 insertions(+), 4 deletions(-) diff --git a/content/ko/docs/setup/production-environment/_index.md b/content/ko/docs/setup/production-environment/_index.md index 5296cfcaf2..3471214564 100644 --- a/content/ko/docs/setup/production-environment/_index.md +++ b/content/ko/docs/setup/production-environment/_index.md @@ -1,4 +1,293 @@ --- -title: 운영 환경 +title: "프로덕션 환경" +description: 프로덕션 수준의 쿠버네티스 클러스터 생성 weight: 30 +no_list: true --- + + +프로덕션 수준의 쿠버네티스 클러스터에는 계획과 준비가 필요하다. +쿠버네티스 클러스터에 중요한 워크로드를 실행하려면 클러스터를 탄력적이도록 구성해야 한다. +이 페이지에서는 프로덕션용 클러스터를 설정하거나 기존 클러스터를 프로덕션용으로 업그레이드하기 위해 +수행할 수 있는 단계를 설명한다. +이미 프로덕션 구성 내용에 익숙하여 단지 링크를 찾고 있다면, +[다음 내용](#다음-내용)을 참고한다. + + + +## 프로덕션 고려 사항 + +일반적으로 프로덕션 쿠버네티스 클러스터 환경에는 +개인 학습용, 개발용 또는 테스트 환경용 클러스터보다 더 많은 요구 사항이 있다. +프로덕션 환경에는 많은 사용자의 보안 액세스, 일관된 가용성 및 +변화하는 요구를 충족하기 위한 리소스가 필요할 수 있다. + +프로덕션 쿠버네티스 환경이 상주할 위치(온 프레미스 또는 클라우드)와 +직접 처리하거나 다른 사람에게 맡길 관리의 양을 결정할 때, +쿠버네티스 클러스터에 대한 요구 사항이 +다음 이슈에 의해 어떻게 영향을 받는지 고려해야 한다. + +- *가용성*: 단일 머신 쿠버네티스 [학습 환경](/ko/docs/setup/#학습-환경)은 SPOF(Single Point of Failure, 단일 장애 지점) 이슈를 갖고 있다. +고가용성 클러스터를 만드는 것에는 다음과 같은 고려 사항이 있다. + - 컨트롤 플레인과 워크 노드를 분리 + - 컨트롤 플레인 구성요소를 여러 노드에 복제 + - 클러스터의 {{< glossary_tooltip term_id="kube-apiserver" text="API 서버" >}}로 가는 트래픽을 로드밸런싱 + - 워커 노드를 충분히 운영하거나, 워크로드 변경에 따라 빠르게 제공할 수 있도록 보장 + +- *스케일링*: 프로덕션 쿠버네티스 환경에 들어오는 요청의 양의 +일정할 것으로 예상된다면, 필요한 만큼의 용량(capacity)을 증설하고 +마무리할 수도 있다. 하지만, 요청의 양이 시간에 따라 점점 증가하거나 +계절, 이벤트 등에 의해 극적으로 변동할 것으로 예상된다면, +컨트롤 플레인과 워커 노드로의 요청 증가로 인한 압박을 해소하기 위해 스케일 업 하거나 +잉여 자원을 줄이기 위해 스케일 다운 하는 것에 대해 고려해야 한다. + +- *보안 및 접근 관리*: 학습을 위한 쿠버네티스 클러스터에는 +완전한 관리 권한을 가질 수 있다. 하지만 중요한 워크로드를 실행하며 +두 명 이상의 사용자가 있는 공유 클러스터에는 누가, 그리고 무엇이 클러스터 자원에 +접근할 수 있는지에 대해서 보다 정교한 접근 방식이 필요하다. +역할 기반 접근 제어([RBAC](/docs/reference/access-authn-authz/rbac/)) 및 +기타 보안 메커니즘을 사용하여, 사용자와 워크로드가 필요한 자원에 +액세스할 수 있게 하면서도 워크로드와 클러스터를 안전하게 유지할 수 있다. +[정책](/ko/docs/concepts/policy/)과 +[컨테이너 리소스](/ko/docs/concepts/configuration/manage-resources-containers/)를 +관리하여, 사용자 및 워크로드가 접근할 수 있는 자원에 대한 제한을 설정할 수 있다. + +쿠버네티스 프로덕션 환경을 직접 구축하기 전에, 이 작업의 일부 또는 전체를 +[턴키 클라우드 솔루션](/docs/setup/production-environment/turnkey-solutions/) +제공 업체 또는 기타 [쿠버네티스 파트너](/ko/partners/)에게 +넘기는 것을 고려할 수 있다. +다음과 같은 옵션이 있다. + +- *서버리스*: 클러스터를 전혀 관리하지 않고 +타사 장비에서 워크로드를 실행하기만 하면 된다. +CPU 사용량, 메모리 및 디스크 요청과 같은 항목에 대한 요금이 부과된다. +- *관리형 컨트롤 플레인*: 쿠버네티스 서비스 공급자가 +클러스터 컨트롤 플레인의 확장 및 가용성을 관리하고 패치 및 업그레이드를 처리하도록 한다. +- *관리형 워커 노드*: 필요에 맞는 노드 풀을 정의하면, +쿠버네티스 서비스 공급자는 해당 노드의 가용성 및 +필요 시 업그레이드 제공을 보장한다. +- *통합*: 쿠버네티스를 스토리지, 컨테이너 레지스트리, +인증 방법 및 개발 도구와 같이 +사용자가 필요로 하는 여러 서비스를 통합 제공하는 업체도 있다. + +프로덕션 쿠버네티스 클러스터를 직접 구축하든 파트너와 협력하든, +요구 사항이 *컨트롤 플레인*, *워커 노드*, +*사용자 접근*, *워크로드 자원*과 관련되기 때문에, +다음 섹션들을 검토하는 것이 바람직하다. + +## 프로덕션 클러스터 구성 + +프로덕션 수준 쿠버네티스 클러스터에서, +컨트롤 플레인은 다양한 방식으로 여러 컴퓨터에 분산될 수 있는 서비스들을 통해 +클러스터를 관리한다. +반면, 각 워커 노드는 쿠버네티스 파드를 실행하도록 구성된 단일 엔티티를 나타낸다. + +### 프로덕션 컨트롤 플레인 + +가장 간단한 쿠버네티스 클러스터는 모든 컨트롤 플레인 및 워커 노드 서비스가 +하나의 머신에 실행되는 클러스터이다. +[쿠버네티스 컴포넌트](/ko/docs/concepts/overview/components/) +그림에 명시된 대로, 워커 노드를 추가하여 해당 환경을 확장할 수 있다. +클러스터를 단기간만 사용하거나, +심각한 문제가 발생한 경우 폐기하는 것이 가능하다면, 이 방식을 선택할 수 있다. + +그러나 더 영구적이고 가용성이 높은 클러스터가 필요한 경우 +컨트롤 플레인 확장을 고려해야 한다. +설계 상, 단일 시스템에서 실행되는 단일 시스템 컨트롤 플레인 서비스는 +가용성이 높지 않다. +클러스터를 계속 유지하면서 문제가 발생한 경우 복구할 수 있는지 여부가 중요한 경우, +다음 사항들을 고려한다. + +- *배포 도구 선택*: kubeadm, kops, kubespray와 같은 도구를 이용해 +컨트롤 플레인을 배포할 수 있다. +[배포 도구로 쿠버네티스 설치하기](/ko/docs/setup/production-environment/tools/)에서 +여러 배포 도구를 이용한 프로덕션 수준 배포에 대한 팁을 확인한다. +배포 시, 다양한 +[컨테이너 런타임](/ko/docs/setup/production-environment/container-runtimes/)을 사용할 수 있다. +- *인증서 관리*: 컨트롤 플레인 서비스 간의 보안 통신은 인증서를 사용하여 구현된다. +인증서는 배포 중에 자동으로 생성되거나, 또는 자체 인증 기관을 사용하여 생성할 수 있다. +[PKI 인증서 및 요구 조건](/ko/docs/setup/best-practices/certificates/)에서 +상세 사항을 확인한다. +- *apiserver를 위한 로드밸런서 구성*: 여러 노드에서 실행되는 apiserver 서비스 인스턴스에 +외부 API 호출을 분산할 수 있도록 로드밸런서를 구성한다. +[외부 로드밸런서 생성하기](/docs/tasks/access-application-cluster/create-external-load-balancer/)에서 +상세 사항을 확인한다. +- *etcd 서비스 분리 및 백업*: etcd 서비스는 +다른 컨트롤 플레인 서비스와 동일한 시스템에서 실행되거나, +또는 추가 보안 및 가용성을 위해 별도의 시스템에서 실행될 수 있다. +etcd는 클러스터 구성 데이터를 저장하므로 +필요한 경우 해당 데이터베이스를 복구할 수 있도록 etcd 데이터베이스를 정기적으로 백업해야 한다. +[etcd FAQ](https://etcd.io/docs/v3.4/faq/)에서 etcd 구성 및 사용 상세를 확인한다. +[쿠버네티스를 위한 etcd 클러스터 운영하기](/docs/tasks/administer-cluster/configure-upgrade-etcd/)와 +[kubeadm을 이용하여 고가용성 etcd 생성하기](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)에서 +상세 사항을 확인한다. +- *다중 컨트롤 플레인 시스템 구성*: 고가용성을 위해, +컨트롤 플레인은 단일 머신으로 제한되지 않아야 한다. +컨트롤 플레인 서비스가 init 서비스(예: systemd)에 의해 실행되는 경우, +각 서비스는 최소 3대의 머신에서 실행되어야 한다. +그러나, 컨트롤 플레인 서비스를 쿠버네티스 상의 파드 형태로 실행하면 +각 서비스 복제본 요청이 보장된다. +스케줄러는 내결함성이 있어야 하고, 고가용성은 필요하지 않다. +일부 배포 도구는 쿠버네티스 서비스의 리더 선출을 수행하기 위해 +[Raft](https://raft.github.io/) 합의 알고리즘을 설정한다. +리더를 맡은 서비스가 사라지면 다른 서비스가 스스로 리더가 되어 인계를 받는다. +- *다중 영역(zone)으로 확장*: 클러스터를 항상 사용 가능한 상태로 유지하는 것이 중요하다면 +여러 데이터 센터(클라우드 환경에서는 '영역'이라고 함)에서 실행되는 +클러스터를 만드는 것이 좋다. +영역의 그룹을 지역(region)이라고 한다. +동일한 지역의 여러 영역에 클러스터를 분산하면 +하나의 영역을 사용할 수 없게 된 경우에도 클러스터가 계속 작동할 가능성을 높일 수 있다. +[여러 영역에서 실행](/ko/docs/setup/best-practices/multiple-zones/)에서 상세 사항을 확인한다. +- *구동 중인 기능 관리*: 클러스터를 계속 유지하려면, +상태 및 보안을 유지하기 위해 수행해야 하는 작업이 있다. +예를 들어 kubeadm으로 클러스터를 생성한 경우, +[인증서 관리](/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/)와 +[kubeadm 클러스터 업그레이드하기](/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)에 대해 도움이 되는 가이드가 있다. +[클러스터 운영하기](/ko/docs/tasks/administer-cluster/)에서 +더 많은 쿠버네티스 관리 작업을 볼 수 있다. + +컨트롤 플레인 서비스를 실행할 때 사용 가능한 옵션에 대해 보려면, +[kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/), +[kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/), +[kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/)를 참조한다. +고가용성 컨트롤 플레인 예제는 +[고가용성 토폴로지를 위한 옵션](/docs/setup/production-environment/tools/kubeadm/ha-topology/), +[kubeadm을 이용하여 고가용성 클러스터 생성하기](/docs/setup/production-environment/tools/kubeadm/high-availability/), +[쿠버네티스를 위한 etcd 클러스터 운영하기](/docs/tasks/administer-cluster/configure-upgrade-etcd/)를 참조한다. +etcd 백업 계획을 세우려면 +[etcd 클러스터 백업하기](/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster)를 참고한다. + +### 프로덕션 워커 노드 + +프로덕션 수준 워크로드는 복원력이 있어야 하고, +이들이 의존하는 모든 것들(예: CoreDNS)도 복원력이 있어야 한다. +컨트롤 플레인을 자체적으로 관리하든 +클라우드 공급자가 대신 수행하도록 하든 상관없이, +워커 노드(간단히 *노드*라고도 함)를 어떤 방법으로 관리할지 고려해야 한다. + +- *노드 구성하기*: 노드는 물리적 또는 가상 머신일 수 있다. +직접 노드를 만들고 관리하려면 지원되는 운영 체제를 설치한 다음 +적절한 [노드 서비스](/ko/docs/concepts/overview/components/#노드-컴포넌트)를 추가하고 실행한다. +다음을 고려해야 한다. + - 워크로드의 요구 사항 (노드가 적절한 메모리, CPU, 디스크 속도, 저장 용량을 갖도록 구성) + - 일반적인 컴퓨터 시스템이면 되는지, 아니면 GPU, 윈도우 노드, 또는 VM 격리를 필요로 하는 워크로드가 있는지 +- *노드 검증하기*: [노드 구성 검증하기](/ko/docs/setup/best-practices/node-conformance/)에서 +노드가 쿠버네티스 클러스터에 조인(join)에 필요한 요구 사항을 +만족하는지 확인하는 방법을 알아본다. +- *클러스터에 노드 추가하기*: 클러스터를 자체적으로 관리하는 경우, +머신을 준비하고, 클러스터의 apiserver에 이를 수동으로 추가하거나 +또는 머신이 스스로 등록하도록 하여 노드를 추가할 수 있다. +이러한 방식으로 노드를 추가하는 방법을 보려면 [노드](/ko/docs/concepts/architecture/nodes/) 섹션을 확인한다. +- *클러스터에 윈도우 노드 추가하기*: 윈도우 컨테이너로 구현된 워크로드를 +실행할 수 있도록, 쿠버네티스는 윈도우 워커 노드를 지원한다. +[쿠버네티스에서의 윈도우](/ko/docs/setup/production-environment/windows/)에서 상세 사항을 확인한다. +- *노드 스케일링*: 클러스터가 최종적으로 필요로 하게 될 용량만큼 +확장하는 것에 대한 계획이 있어야 한다. +실행해야 하는 파드 및 컨테이너 수에 따라 필요한 노드 수를 판별하려면 +[대형 클러스터에 대한 고려 사항](/ko/docs/setup/best-practices/cluster-large/)을 확인한다. +만약 노드를 직접 관리한다면, 직접 물리적 장비를 구입하고 설치해야 할 수도 있음을 의미한다. +- *노드 자동 스케일링*: 대부분의 클라우드 공급자는 +비정상 노드를 교체하거나 수요에 따라 노드 수를 늘리거나 줄일 수 있도록 +[클러스터 오토스케일러](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#readme)를 지원한다. +[자주 묻는 질문](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md)에서 +오토스케일러가 어떻게 동작하는지, +[배치](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#deployment) 섹션에서 +각 클라우드 공급자별로 어떻게 구현했는지를 확인한다. +온프레미스의 경우, 필요에 따라 새 노드를 가동하도록 +스크립트를 구성할 수 있는 가상화 플랫폼이 있다. +- *노드 헬스 체크 구성*: 중요한 워크로드의 경우, +해당 노드에서 실행 중인 노드와 파드의 상태가 정상인지 확인하고 싶을 것이다. +[Node Problem Detector](/docs/tasks/debug-application-cluster/monitor-node-health/) +데몬을 사용하면 노드가 정상인지 확인할 수 있다. + +## 프로덕션 사용자 관리 + +프로덕션에서는, 클러스터를 한 명 또는 여러 명이 사용하던 모델에서 +수십에서 수백 명이 사용하는 모델로 바꿔야 하는 경우가 발생할 수 있다. +학습 환경 또는 플랫폼 프로토타입에서는 모든 작업에 대한 단일 관리 계정으로도 +충분할 수 있다. 프로덕션에서는 여러 네임스페이스에 대한, 액세스 수준이 +각각 다른 더 많은 계정이 필요하다. + +프로덕션 수준의 클러스터를 사용한다는 것은 +다른 사용자의 액세스를 선택적으로 허용할 방법을 결정하는 것을 의미한다. +특히 클러스터에 액세스를 시도하는 사용자의 신원을 확인(인증, authentication)하고 +요청한 작업을 수행할 권한이 있는지 결정(인가, authorization)하기 위한 +다음과 같은 전략을 선택해야 한다. + +- *인증*: apiserver는 클라이언트 인증서, 전달자 토큰, 인증 프록시 또는 +HTTP 기본 인증을 사용하여 사용자를 인증할 수 있다. +사용자는 인증 방법을 선택하여 사용할 수 있다. +apiserver는 또한 플러그인을 사용하여 +LDAP 또는 Kerberos와 같은 조직의 기존 인증 방법을 활용할 수 있다. +쿠버네티스 사용자를 인증하는 다양한 방법에 대한 설명은 +[인증](/docs/reference/access-authn-authz/authentication/)을 참조한다. +- *인가*: 일반 사용자 인가를 위해, RBAC 와 ABAC 중 하나를 선택하여 사용할 수 있다. [인가 개요](/ko/docs/reference/access-authn-authz/authorization/)에서 사용자 계정과 서비스 어카운트 인가를 위한 여러 가지 모드를 확인할 수 있다. + - *역할 기반 접근 제어* ([RBAC](/docs/reference/access-authn-authz/rbac/)): 인증된 사용자에게 특정 권한 집합을 허용하여 클러스터에 대한 액세스를 할당할 수 있다. 특정 네임스페이스(Role) 또는 전체 클러스터(ClusterRole)에 권한을 할당할 수 있다. 그 뒤에 RoleBindings 및 ClusterRoleBindings를 사용하여 해당 권한을 특정 사용자에게 연결할 수 있다. + - *속성 기반 접근 제어* ([ABAC](/docs/reference/access-authn-authz/abac/)): 클러스터의 리소스 속성을 기반으로 정책을 생성하고 이러한 속성을 기반으로 액세스를 허용하거나 거부할 수 있다. 정책 파일의 각 줄은 버전 관리 속성(apiVersion 및 종류), 그리고 '대상(사용자 또는 그룹)', '리소스 속성', '비 리소스 속성(`/version` 또는 `/apis`)' 및 '읽기 전용'과 일치하는 사양 속성 맵을 식별한다. 자세한 내용은 [예시](/docs/reference/access-authn-authz/abac/#examples)를 참조한다. + +프로덕션 쿠버네티스 클러스터에 인증과 인가를 설정할 때, 다음의 사항을 고려해야 한다. + +- *인가 모드 설정*: 쿠버네티스 API 서버([kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/))를 실행할 때, +*`--authorization-mode`* 플래그를 사용하여 인증 모드를 설정해야 한다. +예를 들어, (*`/etc/kubernetes/manifests`*에 있는) +*`kube-adminserver.yaml`* 파일 안의 플래그를 `Node,RBAC`으로 설정할 수 있다. +이렇게 하여 인증된 요청이 Node 인가와 RBAC 인가를 사용할 수 있게 된다. +- *사용자 인증서와 롤 바인딩 생성(RBAC을 사용하는 경우)*: RBAC 인증을 사용하는 경우, +사용자는 클러스터 CA가 서명한 CSR(CertificateSigningRequest)을 만들 수 있다. +그 뒤에 각 사용자에게 역할 및 ClusterRoles를 바인딩할 수 있다. +자세한 내용은 +[인증서 서명 요청](/docs/reference/access-authn-authz/certificate-signing-requests/)을 참조한다. +- *속성을 포함하는 정책 생성(ABAC을 사용하는 경우)*: ABAC 인증을 사용하는 경우, +속성의 집합으로 정책을 생성하여, 인증된 사용자 또는 그룹이 +특정 리소스(예: 파드), 네임스페이스, 또는 apiGroup에 접근할 수 있도록 한다. +[예시](/docs/reference/access-authn-authz/abac/#examples)에서 +더 많은 정보를 확인한다. +- *어드미션 컨트롤러 도입 고려*: +[웹훅 토큰 인증](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)은 +API 서버를 통해 들어오는 요청의 인가에 사용할 수 있는 추가적인 방법이다. +웹훅 및 다른 인가 형식을 사용하려면 API 서버에 +[어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/)를 +추가해야 한다. + +## 워크로드에 자원 제한 걸기 + +프로덕션 워크로드의 요구 사항이 +쿠버네티스 컨트롤 플레인 안팎의 압박을 초래할 수 있다. +워크로드의 요구 사항을 충족하도록 클러스터를 구성할 때 다음 항목을 고려한다. + +- *네임스페이스 제한 설정*: 메모리, CPU와 같은 자원의 네임스페이스 별 쿼터를 설정한다. +[메모리, CPU 와 API 리소스 관리](/ko/docs/tasks/administer-cluster/manage-resources/)에서 +상세 사항을 확인한다. +[계층적 네임스페이스](/blog/2020/08/14/introducing-hierarchical-namespaces/)를 설정하여 +제한을 상속할 수도 있다. +- *DNS 요청에 대한 대비*: 워크로드가 대규모로 확장될 것으로 예상된다면, +DNS 서비스도 확장할 준비가 되어 있어야 한다. +[클러스터의 DNS 서비스 오토스케일링](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/)을 확인한다. +- *추가적인 서비스 어카운트 생성*: 사용자 계정은 *클러스터*에서 사용자가 무엇을 할 수 있는지 결정하는 반면에, +서비스 어카운트는 특정 네임스페이스 내의 파드 접근 권한을 결정한다. +기본적으로, 파드는 자신의 네임스페이스의 기본 서비스 어카운트을 이용한다. +[서비스 어카운트 관리하기](/ko/docs/reference/access-authn-authz/service-accounts-admin/)에서 +새로운 서비스 어카운트을 생성하는 방법을 확인한다. 예를 들어, 다음의 작업을 할 수 있다. + - 파드가 특정 컨테이너 레지스트리에서 이미지를 가져 오는 데 사용할 수 있는 시크릿을 추가한다. [파드를 위한 서비스 어카운트 구성하기](/docs/tasks/configure-pod-container/configure-service-account/)에서 예시를 확인한다. + - 서비스 어카운트에 RBAC 권한을 할당한다. [서비스어카운트 권한](/docs/reference/access-authn-authz/rbac/#service-account-permissions)에서 상세 사항을 확인한다. + +## {{% heading "whatsnext" %}} + +- 프로덕션 쿠버네티스를 직접 구축할지, +아니면 [턴키 클라우드 솔루션](/docs/setup/production-environment/turnkey-solutions/) 또는 +[쿠버네티스 파트너](/partners/)가 제공하는 서비스를 이용할지 결정한다. +- 클러스터를 직접 구축한다면, +[인증서](/ko/docs/setup/best-practices/certificates/)를 어떻게 관리할지, +[etcd](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)와 +[API 서버](/ko/docs/setup/production-environment/tools/kubeadm/ha-topology/) +등의 기능에 대한 고가용성을 +어떻게 보장할지를 계획한다. +- 배포 도구로 [kubeadm](/ko/docs/setup/production-environment/tools/kubeadm/), [kops](/ko/docs/setup/production-environment/tools/kops/), [Kubespray](/ko/docs/setup/production-environment/tools/kubespray/) 중 +하나를 선택한다. +- [인증](/docs/reference/access-authn-authz/authentication/) 및 +[인가](/ko/docs/reference/access-authn-authz/authorization/) 방식을 선택하여 +사용자 관리 방법을 구성한다. +- [자원 제한](/ko/docs/tasks/administer-cluster/manage-resources/), +[DNS 오토스케일링](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/), +[서비스 어카운트](/ko/docs/reference/access-authn-authz/service-accounts-admin/)를 설정하여 +애플리케이션 워크로드의 실행에 대비한다. diff --git a/content/ko/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md b/content/ko/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md index 358274d143..d978e7d59f 100644 --- a/content/ko/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md +++ b/content/ko/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md @@ -76,7 +76,11 @@ kind: ClusterConfiguration kubernetesVersion: v1.16.0 scheduler: extraArgs: - bind-address: 0.0.0.0 - config: /home/johndoe/schedconfig.yaml - kubeconfig: /home/johndoe/kubeconfig.yaml + config: /etc/kubernetes/scheduler-config.yaml + extraVolumes: + - name: schedulerconfig + hostPath: /home/johndoe/schedconfig.yaml + mountPath: /etc/kubernetes/scheduler-config.yaml + readOnly: true + pathType: "File" ``` From dfaefa54aab81cd868c38bcfdf5a3831319a6b39 Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Thu, 3 Jun 2021 06:20:26 +0900 Subject: [PATCH 081/128] Nit: Fix hrefs of some links --- .../extend-kubernetes/compute-storage-net/device-plugins.md | 2 +- content/en/docs/concepts/workloads/pods/disruptions.md | 2 +- .../command-line-tools-reference/kube-scheduler.md | 2 +- content/en/docs/reference/scheduling/config.md | 2 +- .../kubeadm/generated/kubeadm_certs_generate-csr.md | 2 +- content/en/docs/reference/using-api/deprecation-guide.md | 2 +- content/en/docs/setup/best-practices/cluster-large.md | 4 ++-- content/en/docs/setup/production-environment/_index.md | 6 +++--- .../docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md | 2 +- 9 files changed, 12 insertions(+), 12 deletions(-) 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 8f39284a96..ae96bb7551 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 @@ -253,7 +253,7 @@ message AllocatableResourcesResponse { `ContainerDevices` do expose the topology information declaring to which NUMA cells the device is affine. The NUMA cells are identified using a opaque integer ID, which value is consistent to what device -plugins report [when they register themselves to the kubelet](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-integration-with-the-topology-manager). +plugins report [when they register themselves to the kubelet](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-integration-with-the-topology-manager). The gRPC service is served over a unix socket at `/var/lib/kubelet/pod-resources/kubelet.sock`. diff --git a/content/en/docs/concepts/workloads/pods/disruptions.md b/content/en/docs/concepts/workloads/pods/disruptions.md index 288502e0d7..6d51edd803 100644 --- a/content/en/docs/concepts/workloads/pods/disruptions.md +++ b/content/en/docs/concepts/workloads/pods/disruptions.md @@ -86,7 +86,7 @@ rolling out node software updates can cause voluntary disruptions. Also, some im of cluster (node) autoscaling may cause voluntary disruptions to defragment and compact nodes. Your cluster administrator or hosting provider should have documented what level of voluntary disruptions, if any, to expect. Certain configuration options, such as -[using PriorityClasses](https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/) +[using PriorityClasses](/docs/concepts/configuration/pod-priority-preemption/) in your pod spec can also cause voluntary (and involuntary) disruptions. diff --git a/content/en/docs/reference/command-line-tools-reference/kube-scheduler.md b/content/en/docs/reference/command-line-tools-reference/kube-scheduler.md index ce8b9b3b67..45d8cae73a 100644 --- a/content/en/docs/reference/command-line-tools-reference/kube-scheduler.md +++ b/content/en/docs/reference/command-line-tools-reference/kube-scheduler.md @@ -27,7 +27,7 @@ each Pod in the scheduling queue according to constraints and available resources. The scheduler then ranks each valid Node and binds the Pod to a suitable Node. Multiple different schedulers may be used within a cluster; kube-scheduler is the reference implementation. -See [scheduling](https://kubernetes.io/docs/concepts/scheduling-eviction/) +See [scheduling](/docs/concepts/scheduling-eviction/) for more information about scheduling and the kube-scheduler component. ``` diff --git a/content/en/docs/reference/scheduling/config.md b/content/en/docs/reference/scheduling/config.md index 02a6e8e505..1e140e6300 100644 --- a/content/en/docs/reference/scheduling/config.md +++ b/content/en/docs/reference/scheduling/config.md @@ -250,7 +250,7 @@ only has one pending pods queue. ## {{% heading "whatsnext" %}} -* Read the [kube-scheduler reference](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/) +* Read the [kube-scheduler reference](/docs/reference/command-line-tools-reference/kube-scheduler/) * Learn about [scheduling](/docs/concepts/scheduling-eviction/kube-scheduler/) * Read the [kube-scheduler configuration (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) reference diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_generate-csr.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_generate-csr.md index 52d21a2cff..2a41f2e58f 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_generate-csr.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_generate-csr.md @@ -17,7 +17,7 @@ Generate keys and certificate signing requests Generates keys and certificate signing requests (CSRs) for all the certificates required to run the control plane. This command also generates partial kubeconfig files with private key data in the "users > user > client-key-data" field, and for each kubeconfig file an accompanying ".csr" file is created. -This command is designed for use in [Kubeadm External CA Mode](https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/#external-ca-mode). It generates CSRs which you can then submit to your external certificate authority for signing. +This command is designed for use in [Kubeadm External CA Mode](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/#external-ca-mode). It generates CSRs which you can then submit to your external certificate authority for signing. The PEM encoded signed certificates should then be saved alongside the key files, using ".crt" as the file extension, or in the case of kubeconfig files, the PEM encoded signed certificate should be base64 encoded and added to the kubeconfig file in the "users > user > client-certificate-data" field. diff --git a/content/en/docs/reference/using-api/deprecation-guide.md b/content/en/docs/reference/using-api/deprecation-guide.md index 9f518143b3..73a4ae2a18 100755 --- a/content/en/docs/reference/using-api/deprecation-guide.md +++ b/content/en/docs/reference/using-api/deprecation-guide.md @@ -74,7 +74,7 @@ The **policy/v1beta1** API version of PodDisruptionBudget will no longer be serv PodSecurityPolicy in the **policy/v1beta1** API version will no longer be served in v1.25, and the PodSecurityPolicy admission controller will be removed. PodSecurityPolicy replacements are still under discussion, but current use can be migrated to -[3rd-party admission webhooks](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) now. +[3rd-party admission webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/) now. #### RuntimeClass {#runtimeclass-v125} diff --git a/content/en/docs/setup/best-practices/cluster-large.md b/content/en/docs/setup/best-practices/cluster-large.md index 81b6404f37..30e8128a19 100644 --- a/content/en/docs/setup/best-practices/cluster-large.md +++ b/content/en/docs/setup/best-practices/cluster-large.md @@ -66,8 +66,8 @@ When creating a cluster, you can (using custom tooling): * start and configure additional etcd instance * configure the {{< glossary_tooltip term_id="kube-apiserver" text="API server" >}} to use it for storing events -See [Operating etcd clusters for Kubernetes](https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/) and -[Set up a High Availability etcd cluster with kubeadm](docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) +See [Operating etcd clusters for Kubernetes](/docs/tasks/administer-cluster/configure-upgrade-etcd/) and +[Set up a High Availability etcd cluster with kubeadm](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) for details on configuring and managing etcd for a large cluster. ## Addon resources diff --git a/content/en/docs/setup/production-environment/_index.md b/content/en/docs/setup/production-environment/_index.md index 7b8eba7d6e..fc99c31a7d 100644 --- a/content/en/docs/setup/production-environment/_index.md +++ b/content/en/docs/setup/production-environment/_index.md @@ -49,7 +49,7 @@ access cluster resources. You can use role-based access control security mechanisms to make sure that users and workloads can get access to the resources they need, while keeping workloads, and the cluster itself, secure. You can set limits on the resources that users and workloads can access -by managing [policies](https://kubernetes.io/docs/concepts/policy/) and +by managing [policies](/docs/concepts/policy/) and [container resources](/docs/concepts/configuration/manage-resources-containers/). Before building a Kubernetes production environment on your own, consider @@ -286,8 +286,8 @@ and the deployment methods. - Configure user management by determining your [Authentication](/docs/reference/access-authn-authz/authentication/) and -[Authorization](docs/reference/access-authn-authz/authorization/) methods. +[Authorization](/docs/reference/access-authn-authz/authorization/) methods. - Prepare for application workloads by setting up -[resource limits](docs/tasks/administer-cluster/manage-resources/), +[resource limits](/docs/tasks/administer-cluster/manage-resources/), [DNS autoscaling](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/) and [service accounts](/docs/reference/access-authn-authz/service-accounts-admin/). diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md index 57aac35a7a..e706bf0267 100644 --- a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md +++ b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md @@ -239,7 +239,7 @@ The field `serverTLSBootstrap: true` will enable the bootstrap of kubelet servin certificates by requesting them from the `certificates.k8s.io` API. One known limitation is that the CSRs (Certificate Signing Requests) for these certificates cannot be automatically approved by the default signer in the kube-controller-manager - -[`kubernetes.io/kubelet-serving`](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers). +[`kubernetes.io/kubelet-serving`](/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers). This will require action from the user or a third party controller. These CSRs can be viewed using: From edb849a7253aa5538b2a57fba883bcefe385f29d Mon Sep 17 00:00:00 2001 From: redcometlpb Date: Thu, 3 Jun 2021 10:52:10 +0900 Subject: [PATCH 082/128] Translate concepts/storage/volume-health-monitoring in Korean --- .../storage/volume-health-monitoring.md | 30 +++++++++++++++++++ 1 file changed, 30 insertions(+) create mode 100644 content/ko/docs/concepts/storage/volume-health-monitoring.md diff --git a/content/ko/docs/concepts/storage/volume-health-monitoring.md b/content/ko/docs/concepts/storage/volume-health-monitoring.md new file mode 100644 index 0000000000..ce149165da --- /dev/null +++ b/content/ko/docs/concepts/storage/volume-health-monitoring.md @@ -0,0 +1,30 @@ +--- +title: 볼륨 헬스 모니터링 +content_type: concept +--- + + + +{{< feature-state for_k8s_version="v1.21" state="alpha" >}} + +{{< glossary_tooltip text="CSI" term_id="csi" >}} 볼륨 헬스 모니터링을 통해 CSI 드라이버는 기본 스토리지 시스템에서 비정상적인 볼륨 상태를 감지하고 이를 {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}} 또는 {{< glossary_tooltip text="파드" term_id="pod" >}}의 이벤트로 보고한다. + + + +## 볼륨 헬스 모니터링 + +쿠버네티스 _볼륨 헬스 모니터링_ 은 쿠버네티스가 CSI(Container Storage Interface)를 구현하는 방법의 일부다. 볼륨 헬스 모니터링 기능은 외부 헬스 모니터 컨트롤러와 {{< glossary_tooltip term_id="kubelet" text="kubelet" >}}, 2가지 컴포넌트로 구현된다. + +CSI 드라이버가 컨트롤러 측의 볼륨 헬스 모니터링 기능을 지원하는 경우, CSI 볼륨에서 비정상적인 볼륨 상태가 감지될 때 관련 {{< glossary_tooltip text="퍼시스턴트볼륨클레임" term_id="persistent-volume-claim" >}}(PersistentVolumeClaim, PVC) 이벤트가 보고된다. + +외부 헬스 모니터 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}는 노드 장애 이벤트도 감시한다. `enable-node-watcher` 플래그를 true로 설정하여 노드 장애 모니터링을 활성화할 수 있다. 외부 헬스 모니터가 노드 장애 이벤트를 감지하면, 컨트롤러는 이 PVC를 사용하는 파드가 장애 상태인 노드에 있음을 나타내는 이벤트가 PVC에 보고된다고 알린다. + +CSI 드라이버가 노드 측에서 볼륨 헬스 모니터링 기능을 지원하는 경우, CSI 볼륨에서 비정상적인 볼륨 상태가 감지되면 PVC를 사용하는 모든 파드에서 이벤트가 보고된다. + +{{< note >}} +노드 측에서 이 기능을 사용하려면 `CSIVolumeHealth` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다. +{{< /note >}} + +## {{% heading "whatsnext" %}} + +이 기능을 구현한 CSI 드라이버를 확인하려면 [CSI 드라이버 문서](https://kubernetes-csi.github.io/docs/drivers.html)를 참고한다. From 316667729c38d12b468ceff5df45ee49660dfec4 Mon Sep 17 00:00:00 2001 From: Bridget Kromhout Date: Wed, 2 Jun 2021 22:16:05 -0500 Subject: [PATCH 083/128] SCTP is stable as of 1.20 Signed-off-by: Bridget Kromhout --- .../en/docs/concepts/services-networking/network-policies.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/en/docs/concepts/services-networking/network-policies.md b/content/en/docs/concepts/services-networking/network-policies.md index 764fedbcc7..2c9ed4a90e 100644 --- a/content/en/docs/concepts/services-networking/network-policies.md +++ b/content/en/docs/concepts/services-networking/network-policies.md @@ -212,9 +212,9 @@ This ensures that even pods that aren't selected by any other NetworkPolicy will ## SCTP support -{{< feature-state for_k8s_version="v1.19" state="beta" >}} +{{< feature-state for_k8s_version="v1.20" state="stable" >}} -As a beta feature, this is enabled by default. To disable SCTP at a cluster level, you (or your cluster administrator) will need to disable the `SCTPSupport` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the API server with `--feature-gates=SCTPSupport=false,…`. +As a stable feature, this is enabled by default. To disable SCTP at a cluster level, you (or your cluster administrator) will need to disable the `SCTPSupport` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the API server with `--feature-gates=SCTPSupport=false,…`. When the feature gate is enabled, you can set the `protocol` field of a NetworkPolicy to `SCTP`. {{< note >}} From 77c019e97bdf1d8b8891c24fcafbb420f040b5c2 Mon Sep 17 00:00:00 2001 From: Ulrich VACHON Date: Thu, 3 Jun 2021 08:48:56 +0200 Subject: [PATCH 084/128] Update configure-liveness-readiness-startup-probes.md Kept coherence. Using "vous" instead of "tu". --- .../configure-liveness-readiness-startup-probes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/fr/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/fr/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index 4b8b736336..5902ca926d 100644 --- a/content/fr/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/fr/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -225,7 +225,7 @@ Si la startup probe ne réussit jamais, le conteneur est tué après 300s puis s Parfois, les applications sont temporairement incapables de servir le trafic. Par exemple, une application peut avoir besoin de charger des larges données ou des fichiers de configuration pendant le démarrage, ou elle peut dépendre de services externes après le démarrage. -Dans ces cas, vous ne voulez pas tuer l'application, mais tu ne veux pas non plus lui envoyer de requêtes. Kubernetes fournit des readiness probes pour détecter et atténuer ces situations. Un pod avec des conteneurs qui signale qu'elle n'est pas prête ne reçoit pas de trafic par les services de Kubernetes. +Dans ces cas, vous ne voulez pas tuer l'application, mais vous ne voulez pas non plus lui envoyer de requêtes. Kubernetes fournit des readiness probes pour détecter et atténuer ces situations. Un pod avec des conteneurs qui signale qu'elle n'est pas prête ne reçoit pas de trafic par les services de Kubernetes. {{< note >}} Readiness probes fonctionnent sur le conteneur pendant tout son cycle de vie. From 05c1eb0030968241425805bf1482ca90f9169fdc Mon Sep 17 00:00:00 2001 From: Albert Date: Thu, 3 Jun 2021 16:30:14 +0800 Subject: [PATCH 085/128] [zh]: fix names.md --- content/zh/docs/concepts/overview/working-with-objects/names.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/zh/docs/concepts/overview/working-with-objects/names.md b/content/zh/docs/concepts/overview/working-with-objects/names.md index 5e0c59ae6d..09e767ea9c 100644 --- a/content/zh/docs/concepts/overview/working-with-objects/names.md +++ b/content/zh/docs/concepts/overview/working-with-objects/names.md @@ -41,7 +41,7 @@ For non-unique user-provided attributes, Kubernetes provides [labels](/docs/user In cases when objects represent a physical entity, like a Node representing a physical host, when the host is re-created under the same name without deleting and re-creating the Node, Kubernetes treats the new host as the old one, which may lead to inconsistencies. --> 当对象所代表的是一个物理实体（例如代表一台物理主机的 Node）时， -如果在 Node 对象未被删除并重建的条件下，创新创建了同名的物理主机， +如果在 Node 对象未被删除并重建的条件下，重新创建了同名的物理主机， 则 Kubernetes 会将新的主机看作是老的主机，这可能会带来某种不一致性。 {{< /note >}} From a64a4fd2f50b4acab7bac3b7eeab6e984a816d13 Mon Sep 17 00:00:00 2001 From: Albert Date: Thu, 3 Jun 2021 16:16:38 +0800 Subject: [PATCH 086/128] [zh]Update init-containers.md --- content/zh/docs/concepts/workloads/pods/init-containers.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/content/zh/docs/concepts/workloads/pods/init-containers.md b/content/zh/docs/concepts/workloads/pods/init-containers.md index bbfdebc581..d15fcfebce 100644 --- a/content/zh/docs/concepts/workloads/pods/init-containers.md +++ b/content/zh/docs/concepts/workloads/pods/init-containers.md @@ -58,7 +58,8 @@ If a Pod's init container fails, the kubelet repeatedly restarts that init conta However, if the Pod has a `restartPolicy` of Never, and an init container fails during startup of that Pod, Kubernetes treats the overall Pod as failed. --> 如果 Pod 的 Init 容器失败，kubelet 会不断地重启该 Init 容器直到该容器成功为止。 -然而，如果 Pod 对应的 `restartPolicy` 值为 "Never"，Kubernetes 不会重新启动 Pod。 +然而，如果 Pod 对应的 `restartPolicy` 值为 "Never"，并且 Pod 的 Init 容器失败， +则 Kubernetes 会将整个 Pod 状态设置为失败。 + +# Ценности сообщества Kubernetes + +Культура сообщества Kubernetes часто упоминается как существенный вклад в стремительный рост этого проекта с открытым исходным кодом. Ниже приведены дистиллированные ценности, которые развивались в течение последних многих лет в нашем сообществе, подталкивая наш проект и коллег к постоянному совершенствованию. + +## Распределение лучше, чем централизация + +Масштаб проекта Kubernetes жизнеспособен только благодаря высокому доверию и четкому распределению работ, которое включает делегирование полномочий, принятие решений, техническое проектирование, владение кодом и документацию. Распределенное асинхронное владение, сотрудничество, коммуникация и принятие решений являются краеугольным камнем нашего мирового сообщества. + +## Сообщество над товаром или компанией + +Мы здесь в первую очередь как сообщество, наша преданность заключается в преднамеренном управлении проектом Kubernetes на благо всех его членов и пользователей во всем мире. Мы поддерживаем совместную публичную работу для достижения общей цели создания динамичной взаимодействующей экосистемы, обеспечивающей отличный опыт для наших пользователей. Отдельные лица получают статус благодаря работе, компании получают статус благодаря своим обязательствам поддерживать это сообщество и финансировать ресурсы, необходимые для функционирования проекта. + +## Автоматизация процесса + +У крупных проектов есть много менее захватывающей, но все же тяжелой работы. Мы ценим время, потраченное на автоматизацию повторяющейся работы, больше, чем тяжелый труд. Там, где эта работа не может быть автоматизирована, наша культура заключается в признании и вознаграждении всех видов вклада. Однако героизм не является устойчивым. + +## Inclusive is better than exclusive + +В целом успешная и полезная технология требует различных перспектив и навыков, которые могут быть услышаны только в гостеприимной и уважительной обстановке. Членство в сообществе-это привилегия, а не право. Лидерство в сообществе достигается за счет усилий, объема, качества, количества и продолжительности взносов. Наше сообщество проявляет уважение к времени и усилиям, затраченным на обсуждение, независимо от того, где участник находится на пути своего роста. + +## Эволюция лучше, чем застой + +Открытость новым идеям и изученная технологическая эволюция делают Kubernetes более сильным проектом. Постоянное совершенствование, лидерство слуг, наставничество и уважение-вот основы культуры проекта Kubernetes. Лидеры сообщества Kubernetes обязаны находить, спонсировать и продвигать новых членов сообщества. Лидеры должны ожидать, что они отойдут в сторону. Члены сообщества должны ожидать, что они сделают шаг вперед. + +**"Culture eats strategy for breakfast." --Peter Drucker** diff --git a/content/ru/community/values.md b/content/ru/community/values.md new file mode 100644 index 0000000000..4ae1fe30b6 --- /dev/null +++ b/content/ru/community/values.md @@ -0,0 +1,13 @@ +--- +title: Community +layout: basic +cid: community +css: /css/community.css +--- + +
+ +
+{{< include "/static/community-values.md" >}} +
+
diff --git a/content/ru/docs/_index.md b/content/ru/docs/_index.md index 09f6d57a37..3ccdee88bb 100644 --- a/content/ru/docs/_index.md +++ b/content/ru/docs/_index.md @@ -1,3 +1,6 @@ --- +linktitle: Документация по Kubernetes title: Документация +sitemap: + priority: 1.0 --- diff --git a/content/ru/docs/concepts/architecture/_index.md b/content/ru/docs/concepts/architecture/_index.md index eb68a67e53..05b3535491 100755 --- a/content/ru/docs/concepts/architecture/_index.md +++ b/content/ru/docs/concepts/architecture/_index.md @@ -1,5 +1,7 @@ --- title: "Кластерная Архитектура" weight: 30 +description: > + The architectural concepts behind Kubernetes. --- diff --git a/content/ru/docs/concepts/architecture/cloud-controller.md b/content/ru/docs/concepts/architecture/cloud-controller.md new file mode 100644 index 0000000000..287afad287 --- /dev/null +++ b/content/ru/docs/concepts/architecture/cloud-controller.md @@ -0,0 +1,192 @@ +--- +title: Диспетчер облочных контроллеров +content_type: concept +weight: 40 +--- + + + +{{< feature-state state="beta" for_k8s_version="v1.11" >}} + +Технологии облочной инфраструктуры позволяет запускать Kubernetes в общедоступных, частных и гибритных облоках. Kubernetes верит в автоматизированную,управляемую API инфраструктуру без жесткой связи между компонентами. + +{{< glossary_definition term_id="cloud-controller-manager" length="all" prepend="Диспетчер облочных контроллеров">}} + +Диспетчер облочных контроллеров структурирован с использованием механизма плагинов, которые позволяют различным облочным провайдерам интегрировать свои платформы с Kubernetes. + + + + + +## Дизайн + +![Kubernetes components](/images/docs/components-of-kubernetes.svg) + +Диспетчер облочных контроллеров работает в панели управления как реплицированный набот процессов (обычно это контейнер в Pod-ах). Каждый диспетчер облочных контроллеров реализует многоразовые {{< glossary_tooltip text="контроллеры" term_id="controller" >}} в единственном процессе. + + +{{< note >}} +Вы так же можете запустить диспетчер облочных контроллеров как {{< glossary_tooltip text="дополнение" term_id="addons" >}} Kubernetes, а некак часть панели управления. +{{< /note >}} + +## Функции диспетчера облочных контроллеров {#functions-of-the-ccm} + +Контроллеры внутри диспетчера облочных контроллеров включают в себя: + +### Контролер узла + +Контроллер узла отвечает за создание объектов {{< glossary_tooltip text="узла" term_id="node" >}} при создании новых серверов в вашей облочной инфраструктуре. Контроллер узла получает информацию +о работающих хостах внутри вашего арендуемого облочного провайдера. +Контроллер узла выполняет следующие функции: + +1. Инициализация объектов узла для каждого сервера, контроллер которого через API облочного провайдера. +2. Аннотирование и маркировка объеко узла специфичной для облока информацией, такой как регион, в котором развернут узел и доступные ему ресурсы (процессор, память и т.д.). +3. Получение имени хоста и сетевых адресов. +4. Проверка работоспособности ущла. В случае, если узел перестает отвечать на запросы, этот контроллер проверяется с помощью API вашего облочного провайдера, был ли сервер деактевирован / удален / прекращен. + Если узел был удален из облока, контроллер удлаяет объект узла из вашего Kubernetes кластера.. + +Некоторые облочные провайдеры реализуют его разделение на контроллер узла и отдельный контроллер жизненного цикла узла. + +### Контролер маршрута + +Контролер маршрута отвечае за соответствующую настройку маршрутов облоке, чтобы контейнеры на разных узлах кластера Kubernetes могли взаимодействовать друг с другом. + +В зависимости от облочного провайдера, контроллер маршрута способен также выделять блоки IP адресов для сети Pod. + +### Сервисный контроллер + +{{< glossary_tooltip text="Службы" term_id="service" >}} интегрируются с компонентами облочной инфраструктуры, такими как управляемые балансировщики нагрузки, IP адреса, фильтрация сетевых пакетов и проверка работоспособности целевых объектов. Сервисный контроллер взаимодействует с API вашего облочного провайдера для настройки балансировщиков нагрузки и других компонентов инфраструктуры, когда вы объявляете ресурсные службы которые он требует. + +## Авторизация + +В этом разделе разбирается доступ, который нужен для управления облочным контроллером к различным объектам API для выполнения своих операций. + +### Контроллер узла {#authorization-node-controller} + +Контроллер узла работает только с объектом узла. Он требует полного доступа для и изменения объектов узла. + +`v1/Node`: + +- Get +- List +- Create +- Update +- Patch +- Watch +- Delete + +### Контролер маршрута {#authorization-route-controller} + +Контролер маршрута прослушивает создание объектов узла и соответствующим образом настраивает маршруты. Для этого требуется получить доступ к объектам узла. + +`v1/Node`: + +- Get + +### Сервисный контроллер {#authorization-service-controller} + +Сервисный контроллер прослушивает события Create, Update и Delete объектов службы, а затем соответствующим образом настраивает конечные точки для этих соответствующих сервисов. + +Для доступа к сервисам, требуется доступ к событиям List и Watch. Для обновления сервисов, требуется доступ к событиям Patch и Update. + +Чтобы настроить ресурсы конечных точек для сервисов, требуется доступ к событиям Create, List, Get, Watch, и Update. + +`v1/Service`: + +- List +- Get +- Watch +- Patch +- Update + +### Другие {#authorization-miscellaneous} + +Реализация ядра диспетчера облочных контроллеров требует доступ для создания создания объектов события, а для обеспечения безопасной работы требуется доступ для создания учетных записей сервисов (ServiceAccounts). + +`v1/Event`: + +- Create +- Patch +- Update + +`v1/ServiceAccount`: + +- Create + +The {{< glossary_tooltip term_id="rbac" text="RBAC" >}} ClusterRole для диспетчера облочных контроллеров выглядить так: + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: cloud-controller-manager +rules: +- apiGroups: + - "" + resources: + - events + verbs: + - create + - patch + - update +- apiGroups: + - "" + resources: + - nodes + verbs: + - '*' +- apiGroups: + - "" + resources: + - nodes/status + verbs: + - patch +- apiGroups: + - "" + resources: + - services + verbs: + - list + - patch + - update + - watch +- apiGroups: + - "" + resources: + - serviceaccounts + verbs: + - create +- apiGroups: + - "" + resources: + - persistentvolumes + verbs: + - get + - list + - update + - watch +- apiGroups: + - "" + resources: + - endpoints + verbs: + - create + - get + - list + - watch + - update +``` + + +## {{% heading "whatsnext" %}} + +[Администрирование диспетчера облочных контроллеров](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager) +содержить инструкции по запуску и управлению диспетером облочных контроллеров. + +Хотите знать как реализовать свой собственный диспетчер облочных контроллеров или расширить проект? + +Диспетчер облочных контроллеров использует интерфейс Go, который позволяет реализовать подключение из любого облока. В частности, он использует `CloudProvider` интерфейс, который определен в [`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.17/cloud.go#L42-L62) из [kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider). + +Реализация общих контроллеров выделенных в этом документе (Node, Route, и Service),а так же некоторые возведения вместе с общим облочным провайдерским интерфейсом являются частью ядра Kubernetes. особые реализации, для облочных провайдеров находятся вне ядра Kubernetes и реализуют интерфейс `CloudProvider`. + +Дополнительные сведения о разработке плагинов см. в разделе [Разработка диспетчера облочных контроллеров](/docs/tasks/administer-cluster/developing-cloud-controller-manager/). diff --git a/content/ru/docs/concepts/architecture/control-plane-node-communication.md b/content/ru/docs/concepts/architecture/control-plane-node-communication.md new file mode 100644 index 0000000000..ea5cc33921 --- /dev/null +++ b/content/ru/docs/concepts/architecture/control-plane-node-communication.md @@ -0,0 +1,70 @@ +--- +reviewers: +- dchen1107 +- liggitt +title: Связь между плоскостью управления и узлом +content_type: concept +weight: 20 +aliases: +- master-node-communication +--- + + + +Этот документ каталог связь между плоскостью управления (apiserver) и кластером Kubernetes. Цель состоит в том, чтобы позволить пользователям настраивать свою установку для усиления сетевой конфигурации, чтобы кластер мог работать в ненадежной сети (или на полностью общедоступных IP-адресах облачного провайдера). + + + + + +## Связь между плоскостью управления и узлом +В Kubernetes имеется API шаблон "hub-and-spoke". Все используемые API из узлов (или которые запускают pod-ы) завершает apiserver. Ни один из других компонентов плоскости управления не предназначен для предоставления удаленных сервисов. Apiserver настроен на прослушивание удаленных подключений через безопасный порт HTTPS. (обычно 443) с одной или несколькими включенными формами [идентификации](/docs/reference/access-authn-authz/authentication/) клиена. + +Должна быть включена одна или несколько форм [идентификации](/docs/reference/access-authn-authz/authorization/), особенно если разрешены [анонимные запросы](/docs/reference/access-authn-authz/authentication/#anonymous-requests) или [service account tokens](/docs/reference/access-authn-authz/authentication/#service-account-tokens). + +Узлы должны быть снабжены общедоступным корневым сертификатом для кластера, чтобы они могли безопасно подключаться к apiserver-у вместе с действительными учетными данными клиента. Хороший подход заключается в том, что учетные данные клиента, предоставляемые kubelet, имеют форму клиентского сертификата. См. Информацию о загрузке Kubelet TLS [kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) для автоматической подготовки клиентских сертификатов kubelet. + +pod-ы, которые хотят подключиться к apiserver, могут сделать это безопасно, используя учетную запись службы, чтобы Kubernetes автоматически вводил общедоступный корневой сертификат и действительный токен-носитель в pod при его создании. +Служба `kubernetes` (в пространстве имен `default`) is настроен с виртуальным IP-адресом, который перенаправляет (через kube-proxy) к endpoint HTTPS apiserver-а. + +Компоненты уровня управления также взаимодействуют с кластером apiserver-а через защищенный порт. + +В результате режим работы по умолчанию для соединений от узлов и модулей, работающих на узлах, к плоскости управления по умолчанию защищен и может работать в ненадежных и/или общедоступных сетях. + +## Узел к плоскости управления + +Существуют две пути взаимодействия от плоскости управления (apiserver) к узлам. Первый - от apiserver-а до kubelet процесса, который выполняется на каждом узле кластера. Второй - от apiserver к любому узлу, pod-у или службе через промежуточную функциональность apiserver-а. + +### apiserver в kubelet + +Соединение из apiserver-а к kubelet используются для: + +* Извлечения логов с pod-ов. +* Прикрепление (через kubectl) к запущенным pod-ам. +* Обеспечение функциональности переадресации портов kubelet. + +Эти соединения заверщаются в kubelet в endpoint HTTPS. По умолчанию apiserver не проверяет сертификат обслуживания kubelet-ов, что делает соединение подверженным к атаке человек по середине (man-in-the-middle) и **unsafe** запущенных в ненадежных или общедоступных сетях. + +Для проверки этого соединения, используется флаг `--kubelet-certificate-authority` чтобы предоставить apiserver-у набор корневых (root) сертификатов для проверки сертификата обслуживания kubelet-ов. + +Если это не возможно, используйте [SSH-тунелирование](#ssh-tunnels) между apiserver-ом и kubelet, если это необходимо во избежании подключения по ненадежной или общедоступной сети. + +Наконец, Должны быть включены [пудентификация или авторизация Kubelet](/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/) для защиты kubelet API. + +### apiserver для узлов, pod-ов, и служб + +Соединение с apiserver-ом к узлу, pod-у или службе по умолчанию осушествяляется по обычному HTTP-соединению и поэтому не проходят проверку подлиности и не шифрование. Они могут быть запущены по защищенному HTTPS-соединению, добавив префикс `https:` к имени узла, pod-а или службы в URL-адресе API, но они не будут проверять сертификат предоставленный HTTPS endpoint, также не будут предоставлять учетные данные клиента. Таким образом, хотя соединение будет зашифровано, оно не обеспечит никаких гарантий целостности. Эти соединения **are not currently safe** запущенных в ненадежных или общедоступных сетях. + +### SSH-тунели + +Kubernetes поддерживает SSH-туннели для защиты плоскости управления узлов от путей связи. В этой конфигурации apiserver инициирует SSH-туннель для каждого узла в кластере (подключается к ssh-серверу, прослушивая порт 22) и передает весь трафикпредназначенный для kubelet, узлу, pod-у или службе через тунель. Этот тунель гарантирует, что трафик не выводиться за пределы сети, в которой работает узел. + +SSH-туннели в настоящее время устарели, поэтому вы не должны использовать их, если не знаете, что делаете. Служба подключения является заменой этого канала связи. + +### Служба подключения + +{{< feature-state for_k8s_version="v1.18" state="beta" >}} + +В качестве замены SSH-туннелям, служба подключения обеспечивает уровень полномочие TCP для плоскости управления кластерной связи. Служба подключения состоит из двух частей: сервер подключения в сети плоскости управления и агентов подключения в сети узлов. Агенты службы подключения инициируют подключения к серверу подключения и поддерживают сетевое подключение. После включения службы подключения, весь трафик с плоскости управления на узлы проходит через эти соединения. + +Следуйте инструкциям [Задача службы подключения](/docs/tasks/extend-kubernetes/setup-konnectivity/) чтобы настроить службу подключения в кластере. diff --git a/content/ru/docs/concepts/architecture/controller.md b/content/ru/docs/concepts/architecture/controller.md new file mode 100644 index 0000000000..c47fcaed95 --- /dev/null +++ b/content/ru/docs/concepts/architecture/controller.md @@ -0,0 +1,116 @@ +--- +title: Контроллеры +content_type: concept +weight: 30 +--- + + + +В робототехнике и автоматизации, _цикл управления_ - это непрерывный цикл, который регулирует состояние системы. + +Вот один из примеров контура управления: термостат в помещении. + +Когда вы устанавливаете температуру, это говорит термостату о вашем *желаемом состоянии*. Фактическая температура в помещении - это +*текущее состояние*. Термостат действует так, чтобы приблизить текущее состояние к елаемому состоянию, путем включения или выключения оборудования. + +{{< glossary_definition term_id="controller" length="short">}} + + + + + + +## Шаблон контроллера + +Контроллер отслеживает по крайней мере один тип ресурса Kubernetes. +Эти [объекты](/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects) +имеют поле спецификации, которое представляет желаемое состояние. Контроллер (ы) для этого ресурса несут ответственность за приближение текущего состояния к желаемому состоянию + +Контроллер может выполнить это действие сам; чаще всего в Kubernetes, +контроллер будет отправляет сообщения на +{{< glossary_tooltip text="сервер API" term_id="kube-apiserver" >}} которые имеют +полезные побочные эффекты. Пример этого вы можете увидеть ниже. + +{{< comment >}} +Некоторые встроенные контроллеры, такие как контроллер пространства имен, действуют на объекты, не имеющие спецификации. Для простоты эта страница опускает объяснение этих деталей. +{{< /comment >}} + +### Управление с помощью сервера API + +Контроллер {{< glossary_tooltip term_id="job" >}} является примером встроенного контроллера Kubernetes. Встроенные контроллеры управляют состоянием, взаимодействуя с кластером сервера API. + +Задание - это ресурс Kubernetes, который запускает +{{< glossary_tooltip term_id="pod" >}}, или возможно несколько Pod-ов, которые выполняют задание и затем останавливаются. + +(После [планирования](/docs/concepts/scheduling-eviction/), Pod объекты становятся частью желаемого состояния для kubelet). + +Когда контроллер задания видить новую задачу, он убеждается что где-то в вашем кластере kubelet-ы на множестве узлов запускают нужное количество Pod-ов для выполнения работы. +Контроллер задания сам по себе не запускает никакие Pod-ы или контейнеры. Вместо этого контроллер задания Iсообщает серверу API о создании или удалении Pod-ов. +Другие компоненты в +{{< glossary_tooltip text="плоскости управления" term_id="control-plane" >}} +действуют на основе информации (имеются ли новые заплонированные Pod-ы для запуска), и в итоге работка заверщается. + +После того, как вы создадите новое задание, желаемое состояние для этого задания будет завершено. Контроллер задания приближает текущее состояние этого задания к желаемому состоянию: создает Pod-ы, которые выполняют работу, которую вы хотели для этого задания, чтобы задание было ближе к завершению. + +Контроллеры также обровляют объекты которые их настраивают. +Например: как только работа выполнена для задания, контроллер задания обновляет этот объект задание, чтобы пометить его как `Завершенный`. + +(Это немного похоже на то, как некоторые термостаты выключают свет, чтобы указать, что теперь ваша комната имеет установленную вами температуру). + +### Прямое управление + +В отличие от Задания, некоторым контроллерам нужно вносить изменения в вещи за пределами вашего кластера. + +Например, если вы используете контур управления, чтобы убедиться, что в вашем кластере достаточно {{< glossary_tooltip text="Узлов" term_id="node" >}}, +тогда этому контроллеру нужно что-то вне текущего кластера, чтобы при необъодимости установить новые узлы. + +Контроллеры, которые взаимодействуют с внешним состоянием, находят свое желаемое состояние с сервера API, а затем напрямую взаимодействуют с внешней системой, чтобы приблизить текущее состояние. + +(На самом деле существует [контроллер](https://github.com/kubernetes/autoscaler/) +, который горизонтально маштабирует узла в вашем кластере.) + +Важным моментом здесь является то, что контроллер вносит некоторые изменения, чтобы вызвать желаемое состояние, а затем сообщает текущее состояние обратно на сервер API вашего кластера. Другие контуры управления могут наблюдать за этими отчетными данными и предпринимать собственные действия. + +В примере с термостатом, если в помещении очень холодно, тогда другой контроллер может также включить обогреватель для защиты от замерзания. В кластерах Kubernetes, плоскость управления косвенно работает с инструментами управления IP-адресами,службами хранения данных, API облочных провайдеров и другими службами для релизации +[расширения Kubernetes](/docs/concepts/extend-kubernetes/). + +## Желаемое против текущего состояния {#desired-vs-current} + +Kubernetes использует систему вида cloud-native и способен справлятся с постоянными изменениями. + +Ваш кластер может изменяться в любой по мере выполнения работы и контуры управления автоматически устранают сбой. Это означает, что потенциально Ваш кластер никогда не достигнет стабильного состояния. + +Пока контроллеры вашего кластера работают и могут вносить полезные изменения, не имеет значения, является ли общее состояние стабильным или нет. + +## Дизайн + +В качестве принципа своей конструкции Kubernetes использует множество контроллеров, каждый из которых управляет определенным аспектом состояния кластера. Чаще всего конкретный контур управления (контроллер) использует один вид ресурса в качестве своего желаемого состояния и имеет другой вид ресурса, которым он управляет, чтобы это случилось. Например, контроллер для заданий отслеживает объекты заданий (для обнаружения новой работы) и объекты модулей (для выполнения заданий, а затем для того, чтобы видеть, когда работа завершена). В этом случае что-то еще создает задания, тогда как контроллер заданий создает Pod-ы. + +Полезно иметь простые контроллеры, а не один монолитный набор взаимосвязанных контуров управления. Контроллеры могут выйти из строя, поэтому Kubernetes предназначен для этого. + +{{< note >}} +Существует несколько контроллеров, которые создают или обновляют один и тот же тип объекта. За кулисами контроллеры Kubernetes следят за тем, чтобы обращать внимание только на ресурсы, связанные с их контролирующим ресурсом. + +Например, у вас могут быть развертывания и задания; они оба создают Pod-ы. Контроллер заданий не удаляет Pod-ы созданные вашим развертиыванием, потому что имеется информационные ({{< glossary_tooltip term_id="label" text="метки" >}}) +которые могут быть использованы контроллерами тем самым показывая отличие Pod-ов. +{{< /note >}} + +## Способы запуска контроллеров {#running-controllers} + +Kubernetes поставляется с набором встроенных контроллеров, которые работают внутри {{< glossary_tooltip term_id="kube-controller-manager" >}}. Эти встроенные контроллеры обеспечивают важные основные функции. + +Контроллер развертывания и контроллер заданий - это примеры контроллеров, которые входят в состав самого Kubernetes («встроенные» контроллеры). +Kubernetes позволяет вам запускать устойчивую плоскость управления, так что в случае отказа одного из встроенных контроллеров работу берет на себя другая часть плоскости управления. + +Вы можете найти контроллеры, которые работают вне плоскости управления, чтобы расширить Kubernetes. +Или, если вы хотите, можете написать новый контроллер самостоятельно. Вы можете запустить свой собственный контроллер виде наборов Pod-ов, +или внешнее в Kubernetes. Что подойдет лучше всего, будет зависеть от того, что делает этот конкретный контроллер. + + + +## {{% heading "whatsnext" %}} + +* Прочтите о [плоскости управления Kubernetes ](/docs/concepts/overview/components/#control-plane-components) +* Откройте для себя некоторые из основных [объектов Kubernetes ](/docs/concepts/overview/working-with-objects/kubernetes-objects/) +* Узнайте больше о [Kubernetes API](/docs/concepts/overview/kubernetes-api/) +* Если вы хотите написать собственный контроллер, см [Шаблоны расширения](/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns) в расширении Kubernetes. diff --git a/content/ru/docs/reference/glossary/cloud-controller-manager.md b/content/ru/docs/reference/glossary/cloud-controller-manager.md new file mode 100644 index 0000000000..d8f0615778 --- /dev/null +++ b/content/ru/docs/reference/glossary/cloud-controller-manager.md @@ -0,0 +1,19 @@ +--- +title: Диспетчер облачных контроллеров +id: cloud-controller-manager +date: 2018-04-12 +full_link: /docs/concepts/architecture/cloud-controller/ +short_description: > + Компонент плоскости управления, который интегрирует Kubernetes со сторонними облачными провайдерами. +aka: +tags: +- core-object +- architecture +- operation +--- +Компонент {{< glossary_tooltip text="панель управления" term_id="control-plane" >}} Kubernetes - это встраиваемый в логику управления облочная спецификация. Диспетчер облачных контроллеров позволяет связать кластер с API поставщика облачных услуг и отделить компоненты, взаимодействующие с этой облачной платформой, от компонентов, взаимодействующих только с вашим кластером. + + + +Отделяя логику взаимодействия между Kubernetes и базовой облачной инфраструктурой, компонент cloud-controller-manager позволяет поставщикам облачных услуг выпускать функции в другом темпе по сравнению с основным проектом Kubernetes. + From 612ebcc5594ec4043f65f2a1f7a5bd15075a19c5 Mon Sep 17 00:00:00 2001 From: himanshu007-creator Date: Thu, 3 Jun 2021 17:29:05 +0530 Subject: [PATCH 089/128] links corrected --- content/en/releases/patch-releases.md | 110 +++++++++++++------------- content/en/releases/release.md | 25 +++--- 2 files changed, 68 insertions(+), 67 deletions(-) diff --git a/content/en/releases/patch-releases.md b/content/en/releases/patch-releases.md index 85951742ab..adc51c5ac2 100644 --- a/content/en/releases/patch-releases.md +++ b/content/en/releases/patch-releases.md @@ -10,10 +10,10 @@ For general information about Kubernetes release cycle, see the ## Cadence -Our typical patch release cadence is monthly. It is +Our typical patch release cadence is monthly. It is commonly a bit faster (1 to 2 weeks) for the earliest patch releases -after a 1.X minor release. Critical bug fixes may cause a more -immediate release outside of the normal cadence. We also aim to not make +after a 1.X minor release. Critical bug fixes may cause a more +immediate release outside of the normal cadence. We also aim to not make releases during major holiday periods. ## Contact @@ -23,7 +23,7 @@ See the [Release Managers page][release-managers] for full contact details on th Please give us a business day to respond - we may be in a different timezone! In between releases the team is looking at incoming cherry pick -requests on a weekly basis. The team will get in touch with +requests on a weekly basis. The team will get in touch with submitters via GitHub PR, SIG channels in Slack, and direct messages in Slack and [email](mailto:release-managers-private@kubernetes.io) if there are questions on the PR. @@ -34,8 +34,8 @@ Please follow the [cherry pick process][cherry-picks]. Cherry picks must be merge-ready in GitHub with proper labels (e.g., `approved`, `lgtm`, `release-note`) and passing CI tests ahead of the -cherry pick deadline. This is typically two days before the target -release, but may be more. Earlier PR readiness is better, as we +cherry pick deadline. This is typically two days before the target +release, but may be more. Earlier PR readiness is better, as we need time to get CI signal after merging your cherry picks ahead of the actual release. @@ -73,15 +73,15 @@ dates for simplicity (every month has it). ## Upcoming Monthly Releases Timelines may vary with the severity of bug fixes, but for easier planning we -will target the following monthly release points. Unplanned, critical +will target the following monthly release points. Unplanned, critical releases may also occur in between these. | Monthly Patch Release | Target date | -| --- | --- | -| June 2021 | 2021-06-16 | -| July 2021 | 2021-07-14 | -| August 2021 | 2021-08-11 | -| September 2021 | 2021-09-15 | +| --------------------- | ----------- | +| June 2021 | 2021-06-16 | +| July 2021 | 2021-07-14 | +| August 2021 | 2021-08-11 | +| September 2021 | 2021-09-15 | ## Detailed Release History for Active Branches @@ -92,7 +92,7 @@ releases may also occur in between these. End of Life for **1.21** is **2022-06-28** | PATCH RELEASE | CHERRY PICK DEADLINE | TARGET DATE | -|--- |--- |--- | +| ------------- | -------------------- | ----------- | | 1.21.2 | 2021-06-12 | 2021-06-16 | | 1.21.1 | 2021-05-07 | 2021-05-12 | @@ -102,16 +102,16 @@ End of Life for **1.21** is **2022-06-28** End of Life for **1.20** is **2022-02-28** -| PATCH RELEASE | CHERRY PICK DEADLINE | TARGET DATE | -|--- |--- |--- | -| 1.20.8 | 2021-06-12 | 2021-06-16 | -| 1.20.7 | 2021-05-07 | 2021-05-12 | -| 1.20.6 | 2021-04-09 | 2021-04-14 | -| 1.20.5 | 2021-03-12 | 2021-03-17 | -| 1.20.4 | 2021-02-12 | 2021-02-18 | +| PATCH RELEASE | CHERRY PICK DEADLINE | TARGET DATE | +| ------------- | ----------------------------------------------------------------------------------- | ----------- | +| 1.20.8 | 2021-06-12 | 2021-06-16 | +| 1.20.7 | 2021-05-07 | 2021-05-12 | +| 1.20.6 | 2021-04-09 | 2021-04-14 | +| 1.20.5 | 2021-03-12 | 2021-03-17 | +| 1.20.4 | 2021-02-12 | 2021-02-18 | | 1.20.3 | [Conformance Tests Issue](https://groups.google.com/g/kubernetes-dev/c/oUpY9vWgzJo) | 2021-02-17 | -| 1.20.2 | 2021-01-08 | 2021-01-13 | -| 1.20.1 | [Tagging Issue](https://groups.google.com/g/kubernetes-dev/c/dNH2yknlCBA) | 2020-12-18 | +| 1.20.2 | 2021-01-08 | 2021-01-13 | +| 1.20.1 | [Tagging Issue](https://groups.google.com/g/kubernetes-dev/c/dNH2yknlCBA) | 2020-12-18 | ### 1.19 @@ -119,46 +119,46 @@ End of Life for **1.20** is **2022-02-28** End of Life for **1.19** is **2021-10-28** -| PATCH RELEASE | CHERRY PICK DEADLINE | TARGET DATE | -|--- |--- |--- | -| 1.19.12 | 2021-06-12 | 2021-06-16 | -| 1.19.11 | 2021-05-07 | 2021-05-12 | -| 1.19.10 | 2021-04-09 | 2021-04-14 | -| 1.19.9 | 2021-03-12 | 2021-03-17 | -| 1.19.8 | 2021-02-12 | 2021-02-17 | -| 1.19.7 | 2021-01-08 | 2021-01-13 | +| PATCH RELEASE | CHERRY PICK DEADLINE | TARGET DATE | +| ------------- | ------------------------------------------------------------------------- | ----------- | +| 1.19.12 | 2021-06-12 | 2021-06-16 | +| 1.19.11 | 2021-05-07 | 2021-05-12 | +| 1.19.10 | 2021-04-09 | 2021-04-14 | +| 1.19.9 | 2021-03-12 | 2021-03-17 | +| 1.19.8 | 2021-02-12 | 2021-02-17 | +| 1.19.7 | 2021-01-08 | 2021-01-13 | | 1.19.6 | [Tagging Issue](https://groups.google.com/g/kubernetes-dev/c/dNH2yknlCBA) | 2020-12-18 | -| 1.19.5 | 2020-12-04 | 2020-12-09 | -| 1.19.4 | 2020-11-06 | 2020-11-11 | -| 1.19.3 | 2020-10-09 | 2020-10-14 | -| 1.19.2 | 2020-09-11 | 2020-09-16 | -| 1.19.1 | 2020-09-04 | 2020-09-09 | +| 1.19.5 | 2020-12-04 | 2020-12-09 | +| 1.19.4 | 2020-11-06 | 2020-11-11 | +| 1.19.3 | 2020-10-09 | 2020-10-14 | +| 1.19.2 | 2020-09-11 | 2020-09-16 | +| 1.19.1 | 2020-09-04 | 2020-09-09 | ## Non-Active Branch History These releases are no longer supported. -| Minor Version | Final Patch Release | EOL date | -| --- | --- | --- | -| 1.18 | 1.18.19 | 2021-05-12 | -| 1.17 | 1.17.17 | 2021-01-13 | -| 1.16 | 1.16.15 | 2020-09-02 | -| 1.15 | 1.15.12 | 2020-05-06 | -| 1.14 | 1.14.10 | 2019-12-11 | -| 1.13 | 1.13.12 | 2019-10-15 | -| 1.12 | 1.12.10 | 2019-07-08 | -| 1.11 | 1.11.10 | 2019-05-01 | -| 1.10 | 1.10.13 | 2019-02-13 | -| 1.9 | 1.9.11 | 2018-09-29 | -| 1.8 | 1.8.15 | 2018-07-12 | -| 1.7 | 1.7.16 | 2018-04-04 | -| 1.6 | 1.6.13 | 2017-11-23 | -| 1.5 | 1.5.8 | 2017-10-01 | -| 1.4 | 1.4.12 | 2017-04-21 | -| 1.3 | 1.3.10 | 2016-11-01 | -| 1.2 | 1.2.7 | 2016-10-23 | +| Minor Version | Final Patch Release | EOL date | +| ------------- | ------------------- | ---------- | +| 1.18 | 1.18.19 | 2021-05-12 | +| 1.17 | 1.17.17 | 2021-01-13 | +| 1.16 | 1.16.15 | 2020-09-02 | +| 1.15 | 1.15.12 | 2020-05-06 | +| 1.14 | 1.14.10 | 2019-12-11 | +| 1.13 | 1.13.12 | 2019-10-15 | +| 1.12 | 1.12.10 | 2019-07-08 | +| 1.11 | 1.11.10 | 2019-05-01 | +| 1.10 | 1.10.13 | 2019-02-13 | +| 1.9 | 1.9.11 | 2018-09-29 | +| 1.8 | 1.8.15 | 2018-07-12 | +| 1.7 | 1.7.16 | 2018-04-04 | +| 1.6 | 1.6.13 | 2017-11-23 | +| 1.5 | 1.5.8 | 2017-10-01 | +| 1.4 | 1.4.12 | 2017-04-21 | +| 1.3 | 1.3.10 | 2016-11-01 | +| 1.2 | 1.2.7 | 2016-10-23 | -[cherry-picks]: https://git.k8s.io/community/contributors/devel/sig-release/cherry-picks.md +[cherry-picks]: https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/cherry-picks.md [release-managers]: /release-managers.md [release process description]: /release.md [yearly-support]: https://git.k8s.io/enhancements/keps/sig-release/1498-kubernetes-yearly-support-period/README.md diff --git a/content/en/releases/release.md b/content/en/releases/release.md index fa0f5e0b21..5542b41202 100644 --- a/content/en/releases/release.md +++ b/content/en/releases/release.md @@ -3,6 +3,7 @@ title: Kubernetes Release Cycle type: docs auto_generated: true --- + {{< warning >}} @@ -89,43 +90,43 @@ The general labeling process should be consistent across artifact types. ## Definitions -- *issue owners*: Creator, assignees, and user who moved the issue into a +- _issue owners_: Creator, assignees, and user who moved the issue into a release milestone -- *Release Team*: Each Kubernetes release has a team doing project management +- _Release Team_: Each Kubernetes release has a team doing project management tasks described [here][release-team]. The contact info for the team associated with any given release can be found [here](https://git.k8s.io/sig-release/releases/). -- *Y days*: Refers to business days +- _Y days_: Refers to business days -- *enhancement*: see "[Is My Thing an Enhancement?](https://git.k8s.io/enhancements/README.md#is-my-thing-an-enhancement)" +- _enhancement_: see "[Is My Thing an Enhancement?](https://git.k8s.io/enhancements/README.md#is-my-thing-an-enhancement)" -- *[Enhancements Freeze][enhancements-freeze]*: +- _[Enhancements Freeze][enhancements-freeze]_: the deadline by which [KEPs][keps] have to be completed in order for enhancements to be part of the current release -- *[Exception Request][exceptions]*: +- _[Exception Request][exceptions]_: The process of requesting an extension on the deadline for a particular Enhancement -- *[Code Freeze][code-freeze]*: +- _[Code Freeze][code-freeze]_: The period of ~4 weeks before the final release date, during which only critical bug fixes are merged into the release. -- *[Pruning](https://git.k8s.io/sig-release/releases/release_phases.md#pruning)*: +- _[Pruning](https://git.k8s.io/sig-release/releases/release_phases.md#pruning)_: The process of removing an Enhancement from a release milestone if it is not fully implemented or is otherwise considered not stable. -- *release milestone*: semantic version string or +- _release milestone_: semantic version string or [GitHub milestone](https://help.github.com/en/github/managing-your-work-on-github/associating-milestones-with-issues-and-pull-requests) referring to a release MAJOR.MINOR `vX.Y` version. See also [release versioning](/contributors/design-proposals/release/versioning.md). -- *release branch*: Git branch `release-X.Y` created for the `vX.Y` milestone. +- _release branch_: Git branch `release-X.Y` created for the `vX.Y` milestone. Created at the time of the `vX.Y-rc.0` release and maintained after the release for approximately 12 months with `vX.Y.Z` patch releases. @@ -160,7 +161,7 @@ conjunction with the Release Team's [Enhancements Lead](https://git.k8s.io/sig-r After Enhancements Freeze, tracking milestones on PRs and issues is important. Items within the milestone are used as a punchdown list to complete the -release. *On issues*, milestones must be applied correctly, via triage by the +release. _On issues_, milestones must be applied correctly, via triage by the SIG, so that [Release Team][release-team] can track bugs and enhancements (any enhancement-related issue needs a milestone). @@ -354,7 +355,7 @@ issue kind labels must be set: - `kind/feature`: New functionality. - `kind/flake`: CI test case is showing intermittent failures. -[cherry-picks]: /contributors/devel/sig-release/cherry-picks.md +[cherry-picks]: /community/blob/master/contributors/devel/sig-release/cherry-picks.md [code-freeze]: https://git.k8s.io/sig-release/releases/release_phases.md#code-freeze [enhancements-freeze]: https://git.k8s.io/sig-release/releases/release_phases.md#enhancements-freeze [exceptions]: https://git.k8s.io/sig-release/releases/release_phases.md#exceptions From 104ec652828bedc29097f18774f454ca559f965e Mon Sep 17 00:00:00 2001 From: jmkim Date: Wed, 26 May 2021 14:04:35 +0900 Subject: [PATCH 090/128] Translate /concepts/cluster-administration/system-logs.md into Korean --- .../cluster-administration/system-logs.md | 148 ++++++++++++++++++ 1 file changed, 148 insertions(+) create mode 100644 content/ko/docs/concepts/cluster-administration/system-logs.md diff --git a/content/ko/docs/concepts/cluster-administration/system-logs.md b/content/ko/docs/concepts/cluster-administration/system-logs.md new file mode 100644 index 0000000000..13008ebbd8 --- /dev/null +++ b/content/ko/docs/concepts/cluster-administration/system-logs.md @@ -0,0 +1,148 @@ +--- + + + +title: 시스템 로그 +content_type: concept +weight: 60 +--- + + + +시스템 컴포넌트 로그는 클러스터에서 발생하는 이벤트를 기록하며, 이는 디버깅에 아주 유용하다. +더 많거나 적은 세부 정보를 표시하도록 다양하게 로그를 설정할 수 있다. +로그는 컴포넌트 내에서 오류를 표시하는 것 처럼 간단하거나, 이벤트의 단계적 추적(예: HTTP 엑세스 로그, 파드의 상태 변경, 컨트롤러 작업 또는 스케줄러의 결정)을 표시하는 것처럼 세밀할 수 있다. + + + +## Klog + +klog는 쿠버네티스의 로깅 라이브러리다. [klog](https://github.com/kubernetes/klog) +는 쿠버네티스 시스템 컴포넌트의 로그 메시지를 생성한다. + +klog 설정에 대한 더 많은 정보는, [커맨드라인 툴](/docs/reference/command-line-tools-reference/)을 참고한다. + +klog 네이티브 형식 예 : +``` +I1025 00:15:15.525108 1 httplog.go:79] GET /api/v1/namespaces/kube-system/pods/metrics-server-v0.3.1-57c75779f-9p8wg: (1.512ms) 200 [pod_nanny/v0.0.0 (linux/amd64) kubernetes/$Format 10.56.1.19:51756] +``` + +### 구조화된 로깅 + +{{< feature-state for_k8s_version="v1.19" state="alpha" >}} + +{{}} +구조화된 로그메시지로 마이그레이션은 진행중인 작업이다. 이 버전에서는 모든 로그 메시지가 구조화되지 않는다. 로그 파일을 +파싱할 때, 구조화되지 않은 로그 메시지도 처리해야 한다. + +로그 형식 및 값 직렬화는 변경될 수 있다. +{{< /warning>}} + +구조화된 로깅은 로그 메시지에 통일된 구조를 적용하여 정보를 쉽게 추출하고, +로그를 보다 쉽고 저렴하게 저장하고 처리하는 작업이다. +새로운 메시지 형식은 이전 버전과 호환되며 기본적으로 활성화 된다. + +구조화된 로그 형식: + +```ini + "" ="" ="" ... +``` + +예시: + +```ini +I1025 00:15:15.525108 1 controller_utils.go:116] "Pod status updated" pod="kube-system/kubedns" status="ready" +``` + + +### JSON 로그 형식 + +{{< feature-state for_k8s_version="v1.19" state="alpha" >}} + +{{}} + +JSON 출력은 많은 표준 klog 플래그를 지원하지 않는다. 지원하지 않는 klog 플래그 목록은, [커맨드라인 툴](/docs/reference/command-line-tools-reference/)을 참고한다. + +모든 로그가 JSON 형식으로 작성되는 것은 아니다(예: 프로세스 시작 중). 로그를 파싱하려는 경우 +JSON 형식이 아닌 로그 행을 처리할 수 있는지 확인해야 한다. + +필드 이름과 JSON 직렬화는 변경될 수 있다. +{{< /warning >}} + +`--logging-format=json` 플래그는 로그 형식을 klog 기본 형식에서 JSON 형식으로 변경한다. +JSON 로그 형식 예시(보기좋게 출력된 형태): + +```json +{ + "ts": 1580306777.04728, + "v": 4, + "msg": "Pod status updated", + "pod":{ + "name": "nginx-1", + "namespace": "default" + }, + "status": "ready" +} +``` + +특별한 의미가 있는 키: +* `ts` - Unix 시간의 타임스탬프 (필수, 부동 소수점) +* `v` - 자세한 정도 (필수, 정수, 기본 값 0) +* `err` - 오류 문자열 (선택 사항, 문자열) +* `msg` - 메시지 (필수, 문자열) + + +현재 JSON 형식을 지원하는 컴포넌트 목록: +* {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}} +* {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} +* {{< glossary_tooltip term_id="kube-scheduler" text="kube-scheduler" >}} +* {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} + +### 로그 정리(sanitization) + +{{< feature-state for_k8s_version="v1.20" state="alpha" >}} + +{{}} +로그 정리(sanitization)는 상당한 오버 헤드를 발생시킬 수 있으므로 프로덕션 환경에서는 사용하지 않아야한다. +{{< /warning >}} + + `--experimental-logging-sanitization` 플래그는 klog 정리(sanitization) 필터를 활성화 한다. +활성화된 경우 모든 로그 인자에서 민감한 데이터(예: 비밀번호, 키, 토큰)가 표시된 필드를 검사하고 +이러한 필드의 로깅이 방지된다. + +현재 로그 정리(sanitization)를 지원하는 컴포넌트 목록: +* kube-controller-manager +* kube-apiserver +* kube-scheduler +* kubelet + +{{< note >}} +로그 정리(sanitization) 필터는 사용자 작업 로그로부터 민감한 데이터가 유출되는 것을 방지할 수 없다. +{{< /note >}} + +### 로그 상세 레벨(verbosity) + +`-v` 플래그로 로그 상세 레벨(verbosity)을 제어한다. 값을 늘리면 기록된 이벤트 수가 증가한다. 값을 줄이면 +기록된 이벤트 수가 줄어든다. +로그 상세 레벨(verbosity)를 높이면 점점 덜 심각한 이벤트가 기록된다. 로그 상세 레벨(verbosity)을 0으로 설정하면 중요한 이벤트만 기록된다. + +### 로그 위치 + +시스템 컴포넌트에는 컨테이너에서 실행되는 것과 컨테이너에서 실행되지 않는 두 가지 유형이 있다. 예를 들면 다음과 같다. + +* 쿠버네티스 스케줄러와 kube-proxy는 컨테이너에서 실행된다. +* kubelet과 컨테이너 런타임(예: 도커)은 컨테이너에서 실행되지 않는다. + +systemd를 사용하는 시스템에서는, kubelet과 컨테이너 런타임은 jounald에 기록한다. +그 외 시스템에서는, `/var/log` 디렉터리의 `.log` 파일에 기록한다. +컨테이너 내부의 시스템 컴포넌트들은 기본 로깅 메커니즘을 무시하고, +항상 `/var/log` 디렉터리의 `.log` 파일에 기록한다. +컨테이너 로그와 마찬가지로, `/var/log` 디렉터리의 시스템 컴포넌트 로그들은 로테이트해야 한다. +`kube-up.sh` 스크립트로 생성된 쿠버네티스 클러스터에서는, `logrotate` 도구로 로그가 로테이트되도록 설정된다. +`logrotate` 도구는 로그가 매일 또는 크기가 100MB 보다 클 때 로테이트된다. + +## {{% heading "whatsnext" %}} + +* [쿠버네티스 로깅 아키텍처](/docs/concepts/cluster-administration/logging/) 알아보기 +* [구조화된 로깅](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1602-structured-logging) 알아보기 +* [로깅 심각도(serverity) 규칙](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md) 알아보기 From 8d50647fdbed6d679667f148367b846d98c71e5f Mon Sep 17 00:00:00 2001 From: Shubham Kuchhal Date: Thu, 3 Jun 2021 16:30:09 +0530 Subject: [PATCH 091/128] Improve Configure Service Accounts Improvement in Configure Service Accounts for Pods Task Signed-off-by: Shubham Kuchhal Remove annotations field from metadata. --- .../configure-pod-container/configure-service-account.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) 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 23a76f3752..505ec7d755 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 @@ -167,8 +167,8 @@ The output is similar to this: Name: build-robot-secret Namespace: default Labels: -Annotations: kubernetes.io/service-account.name=build-robot - kubernetes.io/service-account.uid=da68f9c6-9d26-11e7-b84e-002dc52800da +Annotations: kubernetes.io/service-account.name: build-robot + kubernetes.io/service-account.uid: da68f9c6-9d26-11e7-b84e-002dc52800da Type: kubernetes.io/service-account-token From 905619a79bf6ca7ce93374be777b7367b29e311b Mon Sep 17 00:00:00 2001 From: Albert Date: Fri, 4 Jun 2021 00:08:06 +0800 Subject: [PATCH 092/128] [en]: fix client libraries --- content/en/docs/reference/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/reference/_index.md b/content/en/docs/reference/_index.md index a9d7ee3a9b..376fb69ba4 100644 --- a/content/en/docs/reference/_index.md +++ b/content/en/docs/reference/_index.md @@ -38,7 +38,7 @@ client libraries: - [Kubernetes Python client library](https://github.com/kubernetes-client/python) - [Kubernetes Java client library](https://github.com/kubernetes-client/java) - [Kubernetes JavaScript client library](https://github.com/kubernetes-client/javascript) -- [Kubernetes Dotnet client library](https://github.com/kubernetes-client/csharp) +- [Kubernetes C# client library](https://github.com/kubernetes-client/csharp) - [Kubernetes Haskell Client library](https://github.com/kubernetes-client/haskell) ## CLI From beabc4a7e10d7597ef94554e11e7d7d65db91316 Mon Sep 17 00:00:00 2001 From: Arhell Date: Fri, 4 Jun 2021 01:42:02 +0300 Subject: [PATCH 093/128] [ru] Fixed errors in instructions for generating ref docs --- .../contribute/generate-ref-docs/kubernetes-api.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/content/ru/docs/contribute/generate-ref-docs/kubernetes-api.md b/content/ru/docs/contribute/generate-ref-docs/kubernetes-api.md index 90011b3dd2..883fc8d16c 100644 --- a/content/ru/docs/contribute/generate-ref-docs/kubernetes-api.md +++ b/content/ru/docs/contribute/generate-ref-docs/kubernetes-api.md @@ -75,16 +75,16 @@ git clone https://github.com/kubernetes/kubernetes $GOPATH/src/k8s.io/kubernetes ### Настройка переменных для сборки * `K8S_ROOT` со значением ``. -* `WEB_ROOT` со значением ``. +* `K8S_WEBROOT` со значением ``. * `K8S_RELEASE` со значением нужной версии документации. - Например, если вы хотите собрать документацию для Kubernetes версии 1.17, определите переменную окружения `K8S_RELEASE` со значением 1.17. + Например, если вы хотите собрать документацию для Kubernetes версии 1.17.0, определите переменную окружения `K8S_RELEASE` со значением 1.17.0. Примеры: ```shell -export WEB_ROOT=$(GOPATH)/src/github.com//website +export K8S_WEBROOT=$(GOPATH)/src/github.com//website export K8S_ROOT=$(GOPATH)/src/k8s.io/kubernetes -export K8S_RELEASE=1.17 +export K8S_RELEASE=1.17.0 ``` ### Создание версионированной директории и получение Open API spec @@ -113,8 +113,8 @@ make copyapi Убедитесь в том, что перечисленные ниже два файлы были сгенерированы: ```shell -[ -e "/gen-apidocs/generators/build/index.html" ] && echo "index.html built" || echo "no index.html" -[ -e "/gen-apidocs/generators/build/navData.js" ] && echo "navData.js built" || echo "no navData.js" +[ -e "/gen-apidocs/build/index.html" ] && echo "index.html built" || echo "no index.html" +[ -e "/gen-apidocs/build/navData.js" ] && echo "navData.js built" || echo "no navData.js" ``` Перейдите в корень директории `` и посмотрите, какие файлы были изменены: From 0893e5b1cc0be46703d2388fe59932360aaa6f09 Mon Sep 17 00:00:00 2001 From: Toshiaki Inukai Date: Thu, 3 Jun 2021 23:56:59 +0000 Subject: [PATCH 094/128] Fix emphasis tags --- content/ja/docs/concepts/services-networking/service.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/services-networking/service.md b/content/ja/docs/concepts/services-networking/service.md index a91da37567..f7273d45f1 100644 --- a/content/ja/docs/concepts/services-networking/service.md +++ b/content/ja/docs/concepts/services-networking/service.md @@ -95,7 +95,7 @@ Serviceは多くの場合、KubernetesのPodに対するアクセスを抽象化 * Serviceを、異なる{{< glossary_tooltip term_id="namespace" >}}のServiceや他のクラスターのServiceに向ける場合 * ワークロードをKubernetesに移行するとき、アプリケーションに対する処理をしながら、バックエンドの一部をKubernetesで実行する場合 -このような場合において、ユーザーはPodセレクター_なしで_ Serviceを定義できます。 +このような場合において、ユーザーはPodセレクター*なしで*Serviceを定義できます。 ```yaml apiVersion: v1 @@ -882,7 +882,7 @@ Kubernetesは各Serviceに、それ自身のIPアドレスを割り当てるこ ### ServiceのIPアドレス {#ips-and-vips} 実際に固定された向き先であるPodのIPアドレスとは異なり、ServiceのIPは実際には単一のホストによって応答されません。 -その代わり、kube-proxyは必要な時に透過的にリダイレクトされる_仮想_ IPアドレスを定義するため、iptables(Linuxのパケット処理ロジック)を使用します。 +その代わり、kube-proxyは必要な時に透過的にリダイレクトされる*仮想*IPアドレスを定義するため、iptables(Linuxのパケット処理ロジック)を使用します。 クライアントがVIPに接続する時、そのトラフィックは自動的に適切なEndpointsに転送されます。 Service用の環境変数とDNSは、Serviceの仮想IPアドレス(とポート)の面において、自動的に生成されます。 From df5ece0a1d2c7b594bb975299b40a592efa9c777 Mon Sep 17 00:00:00 2001 From: Albert Date: Thu, 3 Jun 2021 16:25:39 +0800 Subject: [PATCH 095/128] [zh]: fix common lables.md --- .../concepts/overview/working-with-objects/common-labels.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/content/zh/docs/concepts/overview/working-with-objects/common-labels.md b/content/zh/docs/concepts/overview/working-with-objects/common-labels.md index 664c9ed096..a64d648ac3 100644 --- a/content/zh/docs/concepts/overview/working-with-objects/common-labels.md +++ b/content/zh/docs/concepts/overview/working-with-objects/common-labels.md @@ -116,7 +116,10 @@ to be identifiable. Every instance of an application must have a unique name. 应用可以在 Kubernetes 集群中安装一次或多次。在某些情况下，可以安装在同一命名空间中。例如，可以不止一次地为不同的站点安装不同的 WordPress。 -应用的名称和实例的名称是分别记录的。例如，某 WordPress 实例的 `app.kubernetes.io/name` 为 `wordpress`，而其实例名称表现为 `app.kubernetes.io/instance` 的属性值 `wordpress-abcxzy`。这使应用程序和应用程序的实例成为可能是可识别的。应用程序的每个实例都必须具有唯一的名称。 +应用的名称和实例的名称是分别记录的。例如，WordPress 应用的 +`app.kubernetes.io/name` 为 `wordpress`，而其实例名称 +`app.kubernetes.io/instance` 为 `wordpress-abcxzy`。 +这使得应用和应用的实例均可被识别，应用的每个实例都必须具有唯一的名称。 -欢迎来到新的 Kubernetes 博客。关注此博客，了解 Kubernetes 开源项目。我们计划不时发布发布说明，操作方法文章，活动，甚至一些非常有趣的话题。 +欢迎来到新的 Kubernetes 博客。关注此博客，了解 Kubernetes 开源项目。我们计划时不时的发布发布说明，操作方法文章，活动，甚至一些非常有趣的话题。 -另一方面， CNI 在哲学上与 Kubernetes 更加一致。它比 CNM 简单得多，不需要守护进程，并且至少是合理的跨平台（ CoreOS 的 [rkt](https://coreos.com/rkt/docs/) 容器运行时支持它）。跨平台意味着有机会启用跨运行时（例如 Docker ， Rocket ， Hyper ）运行相同的网络配置。 它遵循 UNIX 的理念，即做好一件事。 +另一方面， CNI 在哲学上与 Kubernetes 更加一致。它比 CNM 简单得多，不需要守护进程，并且至少有合理的跨平台（ CoreOS 的 [rkt](https://coreos.com/rkt/docs/) 容器运行时支持它）。跨平台意味着有机会启用跨运行时（例如 Docker ， Rocket ， Hyper ）运行相同的网络配置。 它遵循 UNIX 的理念，即做好一件事。 diff --git a/content/zh/blog/_posts/2020-12-02-dockershim-faq.md b/content/zh/blog/_posts/2020-12-02-dockershim-faq.md index b910cfdfd2..65292d90ac 100644 --- a/content/zh/blog/_posts/2020-12-02-dockershim-faq.md +++ b/content/zh/blog/_posts/2020-12-02-dockershim-faq.md @@ -83,7 +83,7 @@ and other ecosystem groups to ensure a smooth transition and will evaluate thing as the situation evolves. --> 考虑到此改变带来的影响，我们使用了一个加长的废弃时间表。 -在 Kubernetes 1.22 版之前，它不会被彻底移除；换句话说，dockershim 被移除的最早版本会是 2021 年底发布 1.23 版。 +在 Kubernetes 1.22 版之前，它不会被彻底移除；换句话说，dockershim 被移除的最早版本会是 2021 年底发布的 1.23 版。 我们将与供应商以及其他生态团队紧密合作，确保顺利过渡，并将依据事态的发展评估后续事项。 -弃用 Docker 这个底层运行时，转而支持符合为 Kubernetes 创建的 +弃用 Docker 这个底层运行时，转而支持符合为 Kubernetes 创建的容器运行接口 [Container Runtime Interface (CRI)](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/) 的运行时。 Docker 构建的镜像，将在你的集群的所有运行时中继续工作，一如既往。 diff --git a/content/zh/docs/concepts/architecture/cloud-controller.md b/content/zh/docs/concepts/architecture/cloud-controller.md index c962b5f5f0..f97922ec17 100644 --- a/content/zh/docs/concepts/architecture/cloud-controller.md +++ b/content/zh/docs/concepts/architecture/cloud-controller.md @@ -56,7 +56,7 @@ You can also run the cloud controller manager as a Kubernetes of the control plane. --> {{< note >}} -你也可以以 Kubernetes {{< glossary_tooltip text="插件" term_id="addons" >}} +你也可以用 Kubernetes {{< glossary_tooltip text="插件" term_id="addons" >}} 的形式而不是控制面中的一部分来运行云控制器管理器。 {{< /note >}} From cd04c8a1f6a0bc5f30749ab1182d4bfd4c4ac4f8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Y=C4=B1lmaz=20=C5=9EEN?= Date: Fri, 4 Jun 2021 11:19:25 +0300 Subject: [PATCH 097/128] Adding one line code for installation of kubectl Hi There, When I follow these instructions, I could not install correctly kubectl. After kubectl file downloading, That file needs to be given execution permission. I want to contribute for that. Best regards. --- content/en/docs/tasks/tools/install-kubectl-macos.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/en/docs/tasks/tools/install-kubectl-macos.md b/content/en/docs/tasks/tools/install-kubectl-macos.md index b748a38c6f..d952359407 100644 --- a/content/en/docs/tasks/tools/install-kubectl-macos.md +++ b/content/en/docs/tasks/tools/install-kubectl-macos.md @@ -31,6 +31,7 @@ The following methods exist for installing kubectl on macOS: {{< tabs name="download_binary_macos" >}} {{< tab name="Intel" codelang="bash" >}} curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl" + chmod +x kubectl {{< /tab >}} {{< tab name="Apple Silicon" codelang="bash" >}} curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl" From 56dbcd673119f26e5420f562f56a5367e7c92fff Mon Sep 17 00:00:00 2001 From: Marian Steinbach Date: Sat, 5 Jun 2021 06:08:38 +0200 Subject: [PATCH 098/128] Terminology: high-availability masters -> high-availability control plane (#28225) * Change terminology: high availability masters -> high availability control plane * Fix typo * Add alias for old URI * Rename file --- ...r.md => highly-available-control-plane.md} | 100 ++++++++++-------- 1 file changed, 54 insertions(+), 46 deletions(-) rename content/en/docs/tasks/administer-cluster/{highly-available-master.md => highly-available-control-plane.md} (57%) diff --git a/content/en/docs/tasks/administer-cluster/highly-available-master.md b/content/en/docs/tasks/administer-cluster/highly-available-control-plane.md similarity index 57% rename from content/en/docs/tasks/administer-cluster/highly-available-master.md rename to content/en/docs/tasks/administer-cluster/highly-available-control-plane.md index 141b4ee9cd..339f48e41a 100644 --- a/content/en/docs/tasks/administer-cluster/highly-available-master.md +++ b/content/en/docs/tasks/administer-cluster/highly-available-control-plane.md @@ -1,16 +1,17 @@ --- reviewers: - jszczepkowski -title: Set up High-Availability Kubernetes Masters +title: Set up a High-Availability Control Plane content_type: task +aliases: [ '/docs/tasks/administer-cluster/highly-available-master/' ] --- {{< feature-state for_k8s_version="v1.5" state="alpha" >}} -You can replicate Kubernetes masters in `kube-up` or `kube-down` scripts for Google Compute Engine. -This document describes how to use kube-up/down scripts to manage highly available (HA) masters and how HA masters are implemented for use with GCE. +You can replicate Kubernetes control plane nodes in `kube-up` or `kube-down` scripts for Google Compute Engine. +This document describes how to use kube-up/down scripts to manage a highly available (HA) control plane and how HA control planes are implemented for use with GCE. @@ -28,17 +29,17 @@ This document describes how to use kube-up/down scripts to manage highly availab To create a new HA-compatible cluster, you must set the following flags in your `kube-up` script: -* `MULTIZONE=true` - to prevent removal of master replicas kubelets from zones different than server's default zone. -Required if you want to run master replicas in different zones, which is recommended. +* `MULTIZONE=true` - to prevent removal of control plane kubelets from zones different than server's default zone. +Required if you want to run control plane nodes in different zones, which is recommended. * `ENABLE_ETCD_QUORUM_READ=true` - to ensure that reads from all API servers will return most up-to-date data. If true, reads will be directed to leader etcd replica. Setting this value to true is optional: reads will be more reliable but will also be slower. -Optionally, you can specify a GCE zone where the first master replica is to be created. +Optionally, you can specify a GCE zone where the first control plane node is to be created. Set the following flag: -* `KUBE_GCE_ZONE=zone` - zone where the first master replica will run. +* `KUBE_GCE_ZONE=zone` - zone where the first control plane node will run. The following sample command sets up a HA-compatible cluster in the GCE zone europe-west1-b: @@ -46,50 +47,52 @@ The following sample command sets up a HA-compatible cluster in the GCE zone eur MULTIZONE=true KUBE_GCE_ZONE=europe-west1-b ENABLE_ETCD_QUORUM_READS=true ./cluster/kube-up.sh ``` -Note that the commands above create a cluster with one master; -however, you can add new master replicas to the cluster with subsequent commands. +Note that the commands above create a cluster with one control plane node; +however, you can add new control plane nodes to the cluster with subsequent commands. -## Adding a new master replica +## Adding a new control plane node -After you have created an HA-compatible cluster, you can add master replicas to it. -You add master replicas by using a `kube-up` script with the following flags: +After you have created an HA-compatible cluster, you can add control plane nodes to it. +You add control plane nodes by using a `kube-up` script with the following flags: -* `KUBE_REPLICATE_EXISTING_MASTER=true` - to create a replica of an existing -master. +* `KUBE_REPLICATE_EXISTING_MASTER=true` - to create a replica of an existing control plane +node. -* `KUBE_GCE_ZONE=zone` - zone where the master replica will run. -Must be in the same region as other replicas' zones. +* `KUBE_GCE_ZONE=zone` - zone where the control plane node will run. +Must be in the same region as other control plane nodes' zones. You don't need to set the `MULTIZONE` or `ENABLE_ETCD_QUORUM_READS` flags, as those are inherited from when you started your HA-compatible cluster. -The following sample command replicates the master on an existing HA-compatible cluster: +The following sample command replicates the control plane node on an existing +HA-compatible cluster: ```shell KUBE_GCE_ZONE=europe-west1-c KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh ``` -## Removing a master replica +## Removing a control plane node -You can remove a master replica from an HA cluster by using a `kube-down` script with the following flags: +You can remove a control plane node from an HA cluster by using a `kube-down` script with the following flags: * `KUBE_DELETE_NODES=false` - to restrain deletion of kubelets. -* `KUBE_GCE_ZONE=zone` - the zone from where master replica will be removed. +* `KUBE_GCE_ZONE=zone` - the zone from where the control plane node will be removed. -* `KUBE_REPLICA_NAME=replica_name` - (optional) the name of master replica to remove. -If empty: any replica from the given zone will be removed. +* `KUBE_REPLICA_NAME=replica_name` - (optional) the name of control plane node to +remove. If empty: any replica from the given zone will be removed. -The following sample command removes a master replica from an existing HA cluster: +The following sample command removes a control plane node from an existing HA cluster: ```shell KUBE_DELETE_NODES=false KUBE_GCE_ZONE=europe-west1-c ./cluster/kube-down.sh ``` -## Handling master replica failures +## Handling control plane node failures -If one of the master replicas in your HA cluster fails, -the best practice is to remove the replica from your cluster and add a new replica in the same zone. +If one of the control plane nodes in your HA cluster fails, +the best practice is to remove the node from your cluster and add a new control plane +node in the same zone. The following sample commands demonstrate this process: 1. Remove the broken replica: @@ -98,26 +101,31 @@ The following sample commands demonstrate this process: KUBE_DELETE_NODES=false KUBE_GCE_ZONE=replica_zone KUBE_REPLICA_NAME=replica_name ./cluster/kube-down.sh ``` -
  1. Add a new replica in place of the old one:
+
  1. Add a new node in place of the old one:
```shell KUBE_GCE_ZONE=replica-zone KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh ``` -## Best practices for replicating masters for HA clusters +## Best practices for replicating control plane nodes for HA clusters -* Try to place master replicas in different zones. During a zone failure, all masters placed inside the zone will fail. +* Try to place control plane nodes in different zones. During a zone failure, all +control plane nodes placed inside the zone will fail. To survive zone failure, also place nodes in multiple zones (see [multiple-zones](/docs/setup/best-practices/multiple-zones/) for details). -* Do not use a cluster with two master replicas. Consensus on a two-replica cluster requires both replicas running when changing persistent state. -As a result, both replicas are needed and a failure of any replica turns cluster into majority failure state. -A two-replica cluster is thus inferior, in terms of HA, to a single replica cluster. +* Do not use a cluster with two control plane nodes. Consensus on a two-node +control plane requires both nodes running when changing persistent state. +As a result, both nodes are needed and a failure of any node turns the cluster +into majority failure state. +A two-node control plane is thus inferior, in terms of HA, to a cluster with +one control plane node. -* When you add a master replica, cluster state (etcd) is copied to a new instance. +* When you add a control plane node, cluster state (etcd) is copied to a new instance. If the cluster is large, it may take a long time to duplicate its state. -This operation may be sped up by migrating etcd data directory, as described [here](https://coreos.com/etcd/docs/latest/admin_guide.html#member-migration) -(we are considering adding support for etcd data dir migration in future). +This operation may be sped up by migrating the etcd data directory, as described in +the [etcd administration guide](https://etcd.io/docs/v2.3/admin_guide/#member-migration) +(we are considering adding support for etcd data dir migration in the future). @@ -129,7 +137,7 @@ This operation may be sped up by migrating etcd data directory, as described [he ### Overview -Each of master replicas will run the following components in the following mode: +Each of the control plane nodes will run the following components in the following mode: * etcd instance: all instances will be clustered together using consensus; @@ -143,9 +151,9 @@ In addition, there will be a load balancer in front of API servers that will rou ### Load balancing -When starting the second master replica, a load balancer containing the two replicas will be created +When starting the second control plane node, a load balancer containing the two replicas will be created and the IP address of the first replica will be promoted to IP address of load balancer. -Similarly, after removal of the penultimate master replica, the load balancer will be removed and its IP address will be assigned to the last remaining replica. +Similarly, after removal of the penultimate control plane node, the load balancer will be removed and its IP address will be assigned to the last remaining replica. Please note that creation and removal of load balancer are complex operations and it may take some time (~20 minutes) for them to propagate. ### Master service & kubelets @@ -153,17 +161,17 @@ Please note that creation and removal of load balancer are complex operations an Instead of trying to keep an up-to-date list of Kubernetes apiserver in the Kubernetes service, the system directs all traffic to the external IP: -* in one master cluster the IP points to the single master, +* in case of a single node control plane, the IP points to the control plane node, -* in multi-master cluster the IP points to the load balancer in-front of the masters. +* in case of an HA control plane, the IP points to the load balancer in-front of the masters. -Similarly, the external IP will be used by kubelets to communicate with master. +Similarly, the external IP will be used by kubelets to communicate with the control plane. -### Master certificates +### Control plane node certificates -Kubernetes generates Master TLS certificates for the external public IP and local IP for each replica. -There are no certificates for the ephemeral public IP for replicas; -to access a replica via its ephemeral public IP, you must skip TLS verification. +Kubernetes generates TLS certificates for the external public IP and local IP for each control plane node. +There are no certificates for the ephemeral public IP for control plane nodes; +to access a control plane node via its ephemeral public IP, you must skip TLS verification. ### Clustering etcd @@ -172,7 +180,7 @@ To make such deployment secure, communication between etcd instances is authoriz ### API server identity -{{< feature-state state="alpha" for_k8s_version="v1.20" >}} +{{< feature-state state="alpha" for_k8s_version="v1.20" >}} The API Server Identity feature is controlled by a [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) From d0689c9937c588e5287155307e44af0890a69cc7 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Sat, 5 Jun 2021 17:24:22 +0800 Subject: [PATCH 099/128] Fix Windows sample command The script mentioned actually accepts simply the version string without the 'v' character. --- .../tasks/administer-cluster/kubeadm/adding-windows-nodes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md b/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md index aad5f13909..9d8c672dfe 100644 --- a/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md +++ b/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md @@ -188,7 +188,7 @@ To install a specific version of containerD specify the version with -ContainerD ```powershell # Example -.\Install-Containerd.ps1 -ContainerDVersion v1.4.1 +.\Install-Containerd.ps1 -ContainerDVersion 1.4.1 ``` {{< /note >}} From 7b4b91831ed1b7d3cf2eef440762cb49ce2781ba Mon Sep 17 00:00:00 2001 From: bells17 Date: Sun, 6 Jun 2021 18:33:14 +0900 Subject: [PATCH 100/128] Fix em tags: content/ja/docs/concepts/configuration/manage-resources-containers.md --- .../docs/concepts/configuration/manage-resources-containers.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/configuration/manage-resources-containers.md b/content/ja/docs/concepts/configuration/manage-resources-containers.md index bb2ccb7c20..0d59ecd319 100644 --- a/content/ja/docs/concepts/configuration/manage-resources-containers.md +++ b/content/ja/docs/concepts/configuration/manage-resources-containers.md @@ -237,7 +237,7 @@ kubeletは、`tmpfs`のemptyDirボリュームをローカルのエフェメラ ### ローカルのエフェメラルストレージの要求と制限設定 -ローカルのエフェメラルストレージを管理するためには_ephemeral-storage_パラメーターを利用することができます。 +ローカルのエフェメラルストレージを管理するためには _ephemeral-storage_ パラメーターを利用することができます。 Podの各コンテナは、次の1つ以上を指定できます。 * `spec.containers[].resources.limits.ephemeral-storage` * `spec.containers[].resources.requests.ephemeral-storage` From 20c11beb32172ffe9e5169d938585d0d9ad65e90 Mon Sep 17 00:00:00 2001 From: bells17 Date: Sun, 6 Jun 2021 18:35:43 +0900 Subject: [PATCH 101/128] Fix em tags: content/ja/docs/concepts/configuration/overview.md --- content/ja/docs/concepts/configuration/overview.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/configuration/overview.md b/content/ja/docs/concepts/configuration/overview.md index 5f2fd15120..ee63e066d8 100644 --- a/content/ja/docs/concepts/configuration/overview.md +++ b/content/ja/docs/concepts/configuration/overview.md @@ -58,11 +58,11 @@ weight: 10 ## ラベルの使用 -- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`のように、アプリケーションまたはデプロイメントの__セマンティック属性__を識別する[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)を定義して使いましょう。これらのラベルを使用して、他のリソースに適切なポッドを選択できます。例えば、すべての`tier：frontend`を持つPodを選択するServiceや、`app：myapp`に属するすべての`phase：test`コンポーネント、などです。このアプローチの例を知るには、[ゲストブック](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/)アプリも合わせてご覧ください。 +- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`のように、アプリケーションまたはデプロイメントの __セマンティック属性__ を識別する[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)を定義して使いましょう。これらのラベルを使用して、他のリソースに適切なポッドを選択できます。例えば、すべての`tier：frontend`を持つPodを選択するServiceや、`app：myapp`に属するすべての`phase：test`コンポーネント、などです。このアプローチの例を知るには、[ゲストブック](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/)アプリも合わせてご覧ください。 セレクターからリリース固有のラベルを省略することで、Serviceを複数のDeploymentにまたがるように作成できます。 [Deployment](/ja/docs/concepts/workloads/controllers/deployment/)により、ダウンタイムなしで実行中のサービスを簡単に更新できます。 -オブジェクトの望ましい状態はDeploymentによって記述され、その仕様への変更が_適用_されると、Deploymentコントローラは制御された速度で実際の状態を望ましい状態に変更します。 +オブジェクトの望ましい状態はDeploymentによって記述され、その仕様への変更が _適用_ されると、Deploymentコントローラは制御された速度で実際の状態を望ましい状態に変更します。 - デバッグ用にラベルを操作できます。Kubernetesコントローラー（ReplicaSetなど）とServiceはセレクターラベルを使用してPodとマッチするため、Podから関連ラベルを削除すると、コントローラーによって考慮されたり、Serviceによってトラフィックを処理されたりすることがなくなります。既存のPodのラベルを削除すると、そのコントローラーはその代わりに新しいPodを作成します。これは、「隔離」環境で以前の「ライブ」Podをデバッグするのに便利な方法です。対話的にラベルを削除または追加するには、[`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands#label)を使います。 From 1a337324553fd60b64d88bb3cd27f6c046e9ac5b Mon Sep 17 00:00:00 2001 From: bells17 Date: Sun, 6 Jun 2021 18:36:59 +0900 Subject: [PATCH 102/128] Fix em tags: content/ja/docs/concepts/containers/runtime-class.md --- content/ja/docs/concepts/containers/runtime-class.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/containers/runtime-class.md b/content/ja/docs/concepts/containers/runtime-class.md index 67334995eb..bc4e285c66 100644 --- a/content/ja/docs/concepts/containers/runtime-class.md +++ b/content/ja/docs/concepts/containers/runtime-class.md @@ -140,7 +140,7 @@ RuntimeClassのnodeSelectorはアドミッション機能によりPodのnodeSele {{< feature-state for_k8s_version="v1.18" state="beta" >}} -Podが稼働する時に関連する_オーバーヘッド_リソースを指定できます。オーバーヘッドを宣言すると、クラスター(スケジューラーを含む)がPodとリソースに関する決定を行うときにオーバーヘッドを考慮することができます。 +Podが稼働する時に関連する _オーバーヘッド_ リソースを指定できます。オーバーヘッドを宣言すると、クラスター(スケジューラーを含む)がPodとリソースに関する決定を行うときにオーバーヘッドを考慮することができます。 Podオーバーヘッドを使うためには、PodOverhead[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にしなければなりません。(デフォルトではonです) PodのオーバーヘッドはRuntimeClass内の`overhead`フィールドによって定義されます。 From 8c4b1d3e86256611cc636e6d21809a6c613f56cb Mon Sep 17 00:00:00 2001 From: bells17 Date: Sun, 6 Jun 2021 18:38:15 +0900 Subject: [PATCH 103/128] Fix em tags: content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md --- content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md index c1c0c95b6d..6bc7af0dab 100644 --- a/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -83,7 +83,7 @@ Nodeにラベルを付与することで、Podは特定のNodeやNodeグルー `NodeRestriction`プラグインは、kubeletが`node-restriction.kubernetes.io/`プレフィックスを有するラベルの設定や上書きを防ぎます。 Nodeの隔離にラベルのプレフィックスを使用するためには、以下のようにします。 -1. [Node authorizer](/docs/reference/access-authn-authz/node/)を使用していることと、[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)が_有効_になっていること。 +1. [Node authorizer](/docs/reference/access-authn-authz/node/)を使用していることと、[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)が _有効_ になっていること。 2. Nodeに`node-restriction.kubernetes.io/` プレフィックスのラベルを付与し、そのラベルがnode selectorに指定されていること。 例えば、`example.com.node-restriction.kubernetes.io/fips=true` または `example.com.node-restriction.kubernetes.io/pci-dss=true`のようなラベルです。 From f0c13220f181f71adc290f7116b6a46798664e7b Mon Sep 17 00:00:00 2001 From: bells17 Date: Sun, 6 Jun 2021 18:40:13 +0900 Subject: [PATCH 104/128] Fix em tags: content/ja/docs/concepts/scheduling-eviction/kube-scheduler.md --- .../ja/docs/concepts/scheduling-eviction/kube-scheduler.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/ja/docs/concepts/scheduling-eviction/kube-scheduler.md index 9f2b86a425..cbd833ba3d 100644 --- a/content/ja/docs/concepts/scheduling-eviction/kube-scheduler.md +++ b/content/ja/docs/concepts/scheduling-eviction/kube-scheduler.md @@ -26,11 +26,11 @@ kube-schedulerは、もし希望するのであれば自分自身でスケジュ kube-schedulerは、新規に作成された各Podや他のスケジューリングされていないPodを稼働させるために最適なNodeを選択します。 しかし、Pod内の各コンテナにはそれぞれ異なるリソースの要件があり、各Pod自体にもそれぞれ異なる要件があります。そのため、既存のNodeは特定のスケジューリング要求によってフィルターされる必要があります。 -クラスター内でPodに対する割り当て要求を満たしたNodeは_割り当て可能_ なNodeと呼ばれます。 +クラスター内でPodに対する割り当て要求を満たしたNodeは _割り当て可能_ なNodeと呼ばれます。 もし適切なNodeが一つもない場合、スケジューラーがNodeを割り当てることができるまで、そのPodはスケジュールされずに残ります。 スケジューラーはPodに対する割り当て可能なNodeをみつけ、それらの割り当て可能なNodeにスコアをつけます。その中から最も高いスコアのNodeを選択し、Podに割り当てるためのいくつかの関数を実行します。 -スケジューラーは_binding_ と呼ばれる処理中において、APIサーバーに対して割り当てが決まったNodeの情報を通知します。 +スケジューラーは _binding_ と呼ばれる処理中において、APIサーバーに対して割り当てが決まったNodeの情報を通知します。 スケジューリングを決定する上で考慮が必要な要素としては、個別または複数のリソース要求や、ハードウェア/ソフトウェアのポリシー制約、affinityやanti-affinityの設定、データの局所性や、ワークロード間での干渉などが挙げられます。 @@ -52,7 +52,7 @@ _スコアリング_ ステップでは、Podを割り当てるのに最も適 スケジューラーのフィルタリングとスコアリングの動作に関する設定には2つのサポートされた手法があります。 -1. [スケジューリングポリシー](/docs/reference/scheduling/policies) は、フィルタリングのための_Predicates_とスコアリングのための_Priorities_の設定することができます。 +1. [スケジューリングポリシー](/docs/reference/scheduling/policies) は、フィルタリングのための _Predicates_ とスコアリングのための _Priorities_ の設定することができます。 1. [スケジューリングプロファイル](/docs/reference/scheduling/config/#profiles)は、`QueueSort`、 `Filter`、 `Score`、 `Bind`、 `Reserve`、 `Permit`やその他を含む異なるスケジューリングの段階を実装するプラグインを設定することができます。kube-schedulerを異なるプロファイルを実行するように設定することもできます。 From edac091e452d7df998cedb3f8956f326f38bca24 Mon Sep 17 00:00:00 2001 From: bells17 Date: Sun, 6 Jun 2021 18:42:20 +0900 Subject: [PATCH 105/128] Fix em tags: content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md --- .../docs/tasks/access-application-cluster/web-ui-dashboard.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md index 8235e113ae..ba78ba15fa 100644 --- a/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md +++ b/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md @@ -55,7 +55,7 @@ kubectl proxy kubectlは、ダッシュボードを http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/ で利用できるようにします。 -UIはコマンドを実行しているマシンから_のみ_ アクセスできます。オプションについては`kubectl proxy --help`を参照してください。 +UIはコマンドを実行しているマシンから _のみ_ アクセスできます。オプションについては`kubectl proxy --help`を参照してください。 {{< note >}} Kubeconfigの認証方法は、外部IDプロバイダーやx509証明書ベースの認証には対応していません。 From 454ebcfd48037c1716c265f04fb11682657c2525 Mon Sep 17 00:00:00 2001 From: Albert Date: Sun, 6 Jun 2021 15:12:00 +0800 Subject: [PATCH 106/128] [zh]: resync kube-scheduler references files. --- .../kube-scheduler.md | 354 +++++++++++------- 1 file changed, 223 insertions(+), 131 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 5cca4b8355..dbb9eb3cfa 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 @@ -2,11 +2,13 @@ title: kube-scheduler content_type: tool-reference weight: 30 +auto_generated: true --- ## {{% heading "synopsis" %}} @@ -18,14 +20,14 @@ each Pod in the scheduling queue according to constraints and available resources. The scheduler then ranks each valid Node and binds the Pod to a suitable Node. Multiple different schedulers may be used within a cluster; kube-scheduler is the reference implementation. -See [scheduling](https://kubernetes.io/docs/concepts/scheduling-eviction/) +See [scheduling](/docs/concepts/scheduling-eviction/) for more information about scheduling and the kube-scheduler component. --> Kubernetes 调度器是一个控制面进程，负责将 Pods 指派到节点上。 调度器基于约束和可用资源为调度队列中每个 Pod 确定其可合法放置的节点。 调度器之后对所有合法的节点进行排序，将 Pod 绑定到一个合适的节点。 在同一个集群中可以使用多个不同的调度器；kube-scheduler 是其参考实现。 -参阅[调度](https://kubernetes.io/zh/docs/concepts/scheduling-eviction/) +参阅[调度](/zh/docs/concepts/scheduling-eviction/) 以获得关于调度和 kube-scheduler 组件的更多信息。 ``` @@ -58,10 +60,11 @@ If true, adds the file directory to the header of the log messages -已弃用: 要监听 --port 端口的 IP 地址（对于所有 IPv4 接口设置为 0.0.0.0，对于所有 IPv6 接口设置为 ::）。 +已弃用： 要监听 --port 端口的 IP 地址（将其设置为 0.0.0.0 或者 :: 用于监听所有接口和 IP族）。 请参阅 --bind-address。 +如果在 --config 中指定了一个配置文件，这个参数将被忽略。 @@ -73,19 +76,36 @@ DEPRECATED: the IP address on which to listen for the --port port (set to 0.0.0. -已弃用: 要使用的调度算法驱动，此标志设置组件配置框架的默认插件。 +已弃用： 要使用的调度算法驱动，此标志设置组件配置框架的默认插件。 可选值：ClusterAutoscalerProvider | DefaultProvider + +--allow-metric-labels stringToString      +默认值： [] + + + + +这个键值映射表设置 度量标签 所允许设置的值。 +其中键的格式是 <MetricName>,<LabelName>。 +值的格式是 <allowed_value>,<allowed_value>。 +例如：metric1,label1='v1,v2,v3', metric1,label2='v1,v2,v3' metric2,label1='v1,v2,v3'。 + + + --alsologtostderr +日志记录到标准错误以及文件 @@ -141,7 +161,7 @@ If true, failures to look up missing authentication configuration from the clust ---authorization-always-allow-paths stringSlice     默认值：[/healthz] +--authorization-always-allow-paths strings     默认值："/healthz,/readyz,/livez" @@ -203,16 +223,17 @@ Path to the file containing Azure container registry configuration information. ---bind-address ip     默认值：0.0.0.0 +--bind-address string     默认值：0.0.0.0 监听 --secure-port 端口的 IP 地址。 集群的其余部分以及 CLI/ Web 客户端必须可以访问关联的接口。 如果为空，将使用所有接口（0.0.0.0 表示使用所有 IPv4 接口，"::" 表示使用所有 IPv6 接口）。 +如果为空或未指定地址 (0.0.0.0 或 ::)，所有接口将被使用。 @@ -248,27 +269,43 @@ If set, any request presenting a client certificate signed by one of the authori 配置文件的路径。以下标志会覆盖此文件中的值：
---address
---port
---use-legacy-policy-config
---policy-configmap
+--algorithm-provider
--policy-config-file
---algorithm-provider +--policy-configmap
+--policy-configmap-namespace ---contention-profiling +--contention-profiling     默认值: true -已弃用: 如果启用了性能分析，则启用锁竞争分析 +已弃用: 如果启用了性能分析，则启用锁竞争分析。 +如果 --config 指定了一个配置文件，那么这个参数将被忽略。 + + + + +--disabled-metrics strings + + + + +这个标志提供了一个规避不良指标的选项。你必须提供完整的指标名称才能禁用它。 +免责声明：禁用指标的优先级比显示隐藏的指标更高。 @@ -287,7 +324,7 @@ DEPRECATED: enable lock contention profiling, if profiling is enabled ---feature-gates mapStringBool +--feature-gates <逗号分隔的 'key=True|False' 对> @@ -299,41 +336,35 @@ APIResponseCompression=true|false (BETA - default=true)
APIServerIdentity=true|false (ALPHA - default=false)
AllAlpha=true|false (ALPHA - default=false)
AllBeta=true|false (BETA - default=false)
-AllowInsecureBackendProxy=true|false (BETA - default=true)
AnyVolumeDataSource=true|false (ALPHA - default=false)
AppArmor=true|false (BETA - default=true)
BalanceAttachedNodeVolumes=true|false (ALPHA - default=false)
-BoundServiceAccountTokenVolume=true|false (ALPHA - default=false)
+BoundServiceAccountTokenVolume=true|false (BETA - default=true)
CPUManager=true|false (BETA - default=true)
-CRIContainerLogRotation=true|false (BETA - default=true)
CSIInlineVolume=true|false (BETA - default=true)
CSIMigration=true|false (BETA - default=true)
CSIMigrationAWS=true|false (BETA - default=false)
-CSIMigrationAWSComplete=true|false (ALPHA - default=false)
CSIMigrationAzureDisk=true|false (BETA - default=false)
-CSIMigrationAzureDiskComplete=true|false (ALPHA - default=false)
-CSIMigrationAzureFile=true|false (ALPHA - default=false)
-CSIMigrationAzureFileComplete=true|false (ALPHA - default=false)
+CSIMigrationAzureFile=true|false (BETA - default=false)
CSIMigrationGCE=true|false (BETA - default=false)
-CSIMigrationGCEComplete=true|false (ALPHA - default=false)
-CSIMigrationOpenStack=true|false (BETA - default=false)
-CSIMigrationOpenStackComplete=true|false (ALPHA - default=false)
+CSIMigrationOpenStack=true|false (BETA - default=true)
CSIMigrationvSphere=true|false (BETA - default=false)
CSIMigrationvSphereComplete=true|false (BETA - default=false)
-CSIServiceAccountToken=true|false (ALPHA - default=false)
-CSIStorageCapacity=true|false (ALPHA - default=false)
+CSIServiceAccountToken=true|false (BETA - default=true)
+CSIStorageCapacity=true|false (BETA - default=true)
CSIVolumeFSGroupPolicy=true|false (BETA - default=true)
+CSIVolumeHealth=true|false (ALPHA - default=false)
ConfigurableFSGroupPolicy=true|false (BETA - default=true)
-CronJobControllerV2=true|false (ALPHA - default=false)
+ControllerManagerLeaderMigration=true|false (ALPHA - default=false)
+CronJobControllerV2=true|false (BETA - default=true)
CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)
+DaemonSetUpdateSurge=true|false (ALPHA - default=false)
DefaultPodTopologySpread=true|false (BETA - default=true)
DevicePlugins=true|false (BETA - default=true)
DisableAcceleratorUsageMetrics=true|false (BETA - default=true)
-DownwardAPIHugePages=true|false (ALPHA - default=false)
+DownwardAPIHugePages=true|false (BETA - default=false)
DynamicKubeletConfig=true|false (BETA - default=true)
-EfficientWatchResumption=true|false (ALPHA - default=false)
-EndpointSlice=true|false (BETA - default=true)
-EndpointSliceNodeName=true|false (ALPHA - default=false)
+EfficientWatchResumption=true|false (BETA - default=true)
EndpointSliceProxying=true|false (BETA - default=true)
EndpointSliceTerminatingCondition=true|false (ALPHA - default=false)
EphemeralContainers=true|false (ALPHA - default=false)
@@ -341,90 +372,98 @@ ExpandCSIVolumes=true|false (BETA - default=true)
ExpandInUsePersistentVolumes=true|false (BETA - default=true)
ExpandPersistentVolumes=true|false (BETA - default=true)
ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)
-GenericEphemeralVolume=true|false (ALPHA - default=false)
-GracefulNodeShutdown=true|false (ALPHA - default=false)
+GenericEphemeralVolume=true|false (BETA - default=true)
+GracefulNodeShutdown=true|false (BETA - default=true)
HPAContainerMetrics=true|false (ALPHA - default=false)
HPAScaleToZero=true|false (ALPHA - default=false)
HugePageStorageMediumSize=true|false (BETA - default=true)
-IPv6DualStack=true|false (ALPHA - default=false)
-ImmutableEphemeralVolumes=true|false (BETA - default=true)
+IPv6DualStack=true|false (BETA - default=true)
+InTreePluginAWSUnregister=true|false (ALPHA - default=false)
+InTreePluginAzureDiskUnregister=true|false (ALPHA - default=false)
+InTreePluginAzureFileUnregister=true|false (ALPHA - default=false)
+InTreePluginGCEUnregister=true|false (ALPHA - default=false)
+InTreePluginOpenStackUnregister=true|false (ALPHA - default=false)
+InTreePluginvSphereUnregister=true|false (ALPHA - default=false)
+IndexedJob=true|false (ALPHA - default=false)
+IngressClassNamespacedParams=true|false (ALPHA - default=false)
KubeletCredentialProviders=true|false (ALPHA - default=false)
KubeletPodResources=true|false (BETA - default=true)
-LegacyNodeRoleBehavior=true|false (BETA - default=true)
+KubeletPodResourcesGetAllocatable=true|false (ALPHA - default=false)
LocalStorageCapacityIsolation=true|false (BETA - default=true)
LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - default=false)
+LogarithmicScaleDown=true|false (ALPHA - default=false)
+MemoryManager=true|false (ALPHA - default=false)
MixedProtocolLBService=true|false (ALPHA - default=false)
-NodeDisruptionExclusion=true|false (BETA - default=true)
+NamespaceDefaultLabelName=true|false (BETA - default=true)
+NetworkPolicyEndPort=true|false (ALPHA - default=false)
NonPreemptingPriority=true|false (BETA - default=true)
-PodDisruptionBudget=true|false (BETA - default=true)
+PodAffinityNamespaceSelector=true|false (ALPHA - default=false)
+PodDeletionCost=true|false (ALPHA - default=false)
PodOverhead=true|false (BETA - default=true)
+PreferNominatedNode=true|false (ALPHA - default=false)
+ProbeTerminationGracePeriod=true|false (ALPHA - default=false)
ProcMountType=true|false (ALPHA - default=false)
QOSReserved=true|false (ALPHA - default=false)
RemainingItemCount=true|false (BETA - default=true)
RemoveSelfLink=true|false (BETA - default=true)
-RootCAConfigMap=true|false (BETA - default=true)
RotateKubeletServerCertificate=true|false (BETA - default=true)
-RunAsGroup=true|false (BETA - default=true)
ServerSideApply=true|false (BETA - default=true)
-ServiceAccountIssuerDiscovery=true|false (BETA - default=true)
+ServiceInternalTrafficPolicy=true|false (ALPHA - default=false)
ServiceLBNodePortControl=true|false (ALPHA - default=false)
-ServiceNodeExclusion=true|false (BETA - default=true)
+ServiceLoadBalancerClass=true|false (ALPHA - default=false)
ServiceTopology=true|false (ALPHA - default=false)
SetHostnameAsFQDN=true|false (BETA - default=true)
SizeMemoryBackedVolumes=true|false (ALPHA - default=false)
StorageVersionAPI=true|false (ALPHA - default=false)
StorageVersionHash=true|false (BETA - default=true)
-Sysctls=true|false (BETA - default=true)
-TTLAfterFinished=true|false (ALPHA - default=false)
+SuspendJob=true|false (ALPHA - default=false)
+TTLAfterFinished=true|false (BETA - default=true)
+TopologyAwareHints=true|false (ALPHA - default=false)
TopologyManager=true|false (BETA - default=true)
ValidateProxyRedirects=true|false (BETA - default=true)
+VolumeCapacityPriority=true|false (ALPHA - default=false)
WarningHeaders=true|false (BETA - default=true)
WinDSR=true|false (ALPHA - default=false)
WinOverlay=true|false (BETA - default=true)
-WindowsEndpointSliceProxying=true|false (ALPHA - default=false) +WindowsEndpointSliceProxying=true|false (BETA - default=true) --> 一组 key=value 对，描述了 alpha/experimental 特征开关。选项包括：
+A set of key=value pairs that describe feature gates for alpha/experimental features. Options are:
APIListChunking=true|false (BETA - 默认值=true)
APIPriorityAndFairness=true|false (BETA - 默认值=true)
APIResponseCompression=true|false (BETA - 默认值=true)
APIServerIdentity=true|false (ALPHA - 默认值=false)
AllAlpha=true|false (ALPHA - 默认值=false)
AllBeta=true|false (BETA - 默认值=false)
-AllowInsecureBackendProxy=true|false (BETA - 默认值=true)
AnyVolumeDataSource=true|false (ALPHA - 默认值=false)
AppArmor=true|false (BETA - 默认值=true)
BalanceAttachedNodeVolumes=true|false (ALPHA - 默认值=false)
-BoundServiceAccountTokenVolume=true|false (ALPHA - 默认值=false)
+BoundServiceAccountTokenVolume=true|false (BETA - 默认值=true)
CPUManager=true|false (BETA - 默认值=true)
-CRIContainerLogRotation=true|false (BETA - 默认值=true)
CSIInlineVolume=true|false (BETA - 默认值=true)
CSIMigration=true|false (BETA - 默认值=true)
-CSIMigrationAWS=true|false (BETA - 默认值=true)
-CSIMigrationAWSComplete=true|false (ALPHA - 默认值=false)
-CSIMigrationAzureDisk=true|false (BETA - 默认值=true)
-CSIMigrationAzureDiskComplete=true|false (ALPHA - 默认值=false)
-CSIMigrationAzureFile=true|false (ALPHA - 默认值=false)
-CSIMigrationAzureFileComplete=true|false (ALPHA - 默认值=false)
-CSIMigrationGCE=true|false (BETA - 默认值=true)
-CSIMigrationGCEComplete=true|false (ALPHA - 默认值=false)
+CSIMigrationAWS=true|false (BETA - 默认值=false)
+CSIMigrationAzureDisk=true|false (BETA - 默认值=false)
+CSIMigrationAzureFile=true|false (BETA - 默认值=false)
+CSIMigrationGCE=true|false (BETA - 默认值=false)
CSIMigrationOpenStack=true|false (BETA - 默认值=true)
-CSIMigrationOpenStackComplete=true|false (ALPHA - 默认值=false)
CSIMigrationvSphere=true|false (BETA - 默认值=false)
-CSIMigrationvSphereComplete=true|false (BETA - default=false)
-CSIServiceAccountToken=true|false (ALPHA - 默认值=false)
-CSIStorageCapacity=true|false (ALPHA - 默认值=false)
+CSIMigrationvSphereComplete=true|false (BETA - 默认值=false)
+CSIServiceAccountToken=true|false (BETA - 默认值=true)
+CSIStorageCapacity=true|false (BETA - 默认值=true)
CSIVolumeFSGroupPolicy=true|false (BETA - 默认值=true)
+CSIVolumeHealth=true|false (ALPHA - 默认值=false)
ConfigurableFSGroupPolicy=true|false (BETA - 默认值=true)
-CronJobControllerV2=true|false (ALPHA - 默认值=false)
+ControllerManagerLeaderMigration=true|false (ALPHA - 默认值=false)
+CronJobControllerV2=true|false (BETA - 默认值=true)
CustomCPUCFSQuotaPeriod=true|false (ALPHA - 默认值=false)
+DaemonSetUpdateSurge=true|false (ALPHA - 默认值=false)
DefaultPodTopologySpread=true|false (BETA - 默认值=true)
DevicePlugins=true|false (BETA - 默认值=true)
DisableAcceleratorUsageMetrics=true|false (BETA - 默认值=true)
-DownwardAPIHugePages=true|false (ALPHA - 默认值=false)
+DownwardAPIHugePages=true|false (BETA - 默认值=false)
DynamicKubeletConfig=true|false (BETA - 默认值=true)
-EfficientWatchResumption=true|false (ALPHA - 默认值=false)
-EndpointSlice=true|false (ALPHA - 默认值=false)
-EndpointSliceNodeName=true|false (ALPHA - 默认值=false)
+EfficientWatchResumption=true|false (BETA - 默认值=true)
EndpointSliceProxying=true|false (BETA - 默认值=true)
EndpointSliceTerminatingCondition=true|false (ALPHA - 默认值=false)
EphemeralContainers=true|false (ALPHA - 默认值=false)
@@ -432,47 +471,60 @@ ExpandCSIVolumes=true|false (BETA - 默认值=true)
ExpandInUsePersistentVolumes=true|false (BETA - 默认值=true)
ExpandPersistentVolumes=true|false (BETA - 默认值=true)
ExperimentalHostUserNamespaceDefaulting=true|false (BETA - 默认值=false)
-GenericEphemeralVolume=true|false (ALPHA - 默认值=false)
-GracefulNodeShutdown=true|false (ALPHA - 默认值=false)
+GenericEphemeralVolume=true|false (BETA - 默认值=true)
+GracefulNodeShutdown=true|false (BETA - 默认值=true)
HPAContainerMetrics=true|false (ALPHA - 默认值=false)
HPAScaleToZero=true|false (ALPHA - 默认值=false)
HugePageStorageMediumSize=true|false (BETA - 默认值=true)
-IPv6DualStack=true|false (ALPHA - 默认值=false)
-ImmutableEphemeralVolumes=true|false (BETA - 默认值=true)
+IPv6DualStack=true|false (BETA - 默认值=true)
+InTreePluginAWSUnregister=true|false (ALPHA - 默认值=false)
+InTreePluginAzureDiskUnregister=true|false (ALPHA - 默认值=false)
+InTreePluginAzureFileUnregister=true|false (ALPHA - 默认值=false)
+InTreePluginGCEUnregister=true|false (ALPHA - 默认值=false)
+InTreePluginOpenStackUnregister=true|false (ALPHA - 默认值=false)
+InTreePluginvSphereUnregister=true|false (ALPHA - 默认值=false)
+IndexedJob=true|false (ALPHA - 默认值=false)
+IngressClassNamespacedParams=true|false (ALPHA - 默认值=false)
KubeletCredentialProviders=true|false (ALPHA - 默认值=false)
KubeletPodResources=true|false (BETA - 默认值=true)
-LegacyNodeRoleBehavior=true|false (BETA - 默认值=true)
+KubeletPodResourcesGetAllocatable=true|false (ALPHA - 默认值=false)
LocalStorageCapacityIsolation=true|false (BETA - 默认值=true)
LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - 默认值=false)
+LogarithmicScaleDown=true|false (ALPHA - 默认值=false)
+MemoryManager=true|false (ALPHA - 默认值=false)
MixedProtocolLBService=true|false (ALPHA - 默认值=false)
-NodeDisruptionExclusion=true|false (BETA - 默认值=false)
+NamespaceDefaultLabelName=true|false (BETA - 默认值=true)
+NetworkPolicyEndPort=true|false (ALPHA - 默认值=false)
NonPreemptingPriority=true|false (BETA - 默认值=true)
-PodDisruptionBudget=true|false (BETA - 默认值=true)
+PodAffinityNamespaceSelector=true|false (ALPHA - 默认值=false)
+PodDeletionCost=true|false (ALPHA - 默认值=false)
PodOverhead=true|false (BETA - 默认值=true)
+PreferNominatedNode=true|false (ALPHA - 默认值=false)
+ProbeTerminationGracePeriod=true|false (ALPHA - 默认值=false)
ProcMountType=true|false (ALPHA - 默认值=false)
QOSReserved=true|false (ALPHA - 默认值=false)
RemainingItemCount=true|false (BETA - 默认值=true)
RemoveSelfLink=true|false (BETA - 默认值=true)
-RootCAConfigMap=true|false (BETA - 默认值=true)
RotateKubeletServerCertificate=true|false (BETA - 默认值=true)
-RunAsGroup=true|false (BETA - 默认值=true)
ServerSideApply=true|false (BETA - 默认值=true)
-ServiceAccountIssuerDiscovery=true|false (BETA - 默认值=true)
+ServiceInternalTrafficPolicy=true|false (ALPHA - 默认值=false)
ServiceLBNodePortControl=true|false (ALPHA - 默认值=false)
-ServiceNodeExclusion=true|false (BETA - 默认值=true)
+ServiceLoadBalancerClass=true|false (ALPHA - 默认值=false)
ServiceTopology=true|false (ALPHA - 默认值=false)
SetHostnameAsFQDN=true|false (BETA - 默认值=true)
SizeMemoryBackedVolumes=true|false (ALPHA - 默认值=false)
StorageVersionAPI=true|false (ALPHA - 默认值=false)
StorageVersionHash=true|false (BETA - 默认值=true)
-Sysctls=true|false (BETA - 默认值=true)
-TTLAfterFinished=true|false (ALPHA - 默认值=false)
+SuspendJob=true|false (ALPHA - 默认值=false)
+TTLAfterFinished=true|false (BETA - 默认值=true)
+TopologyAwareHints=true|false (ALPHA - 默认值=false)
TopologyManager=true|false (BETA - 默认值=true)
ValidateProxyRedirects=true|false (BETA - 默认值=true)
+VolumeCapacityPriority=true|false (ALPHA - 默认值=false)
WarningHeaders=true|false (BETA - 默认值=true)
WinDSR=true|false (ALPHA - 默认值=false)
WinOverlay=true|false (BETA - 默认值=true)
-WindowsEndpointSliceProxying=true|false (ALPHA - 默认值=false) +WindowsEndpointSliceProxying=true|false (BETA - 默认值=true) @@ -482,12 +534,13 @@ WindowsEndpointSliceProxying=true|false (ALPHA - 默认值=false) 已弃用: RequiredDuringScheduling 亲和性是不对称的，但是存在与每个 RequiredDuringScheduling 关联性规则相对应的隐式 PreferredDuringScheduling 关联性规则。 --hard-pod-affinity-symmetric-weight 代表隐式 PreferredDuringScheduling -关联性规则的权重。权重必须在 0-100 范围内。此选项已移至策略配置文件。 +关联性规则的权重。权重必须在 0-100 范围内。 +如果 --config 指定了一个配置文件，那么这个参数将被忽略。 @@ -521,9 +574,10 @@ The limit that the server gives to clients for the maximum number of streams in 已弃用: 与 kubernetes API 通信时使用的突发请求个数限值。 +如果 --config 指定了一个配置文件，那么这个参数将被忽略。 @@ -533,9 +587,10 @@ DEPRECATED: burst to use while talking with kubernetes apiserver 已弃用: 发送到 API 服务器的请求的内容类型。 +如果 --config 指定了一个配置文件，那么这个参数将被忽略。 @@ -545,9 +600,10 @@ DEPRECATED: content type of requests sent to apiserver. 已弃用: 与 kubernetes apiserver 通信时要使用的 QPS +如果 --config 指定了一个配置文件，那么这个参数将被忽略。 @@ -557,9 +613,10 @@ DEPRECATED: QPS to use while talking with kubernetes apiserver 已弃用: 包含鉴权和主节点位置信息的 kubeconfig 文件的路径。 +如果 --config 指定了一个配置文件，那么这个参数将被忽略。 @@ -604,7 +661,7 @@ The interval between attempts by the acting master to renew a leadership slot be ---leader-elect-resource-lock endpoints     默认值："leases" +--leader-elect-resource-lock string     默认值："leases" @@ -659,9 +716,10 @@ The duration the clients should wait between attempting acquisition and renewal 已弃用: 定义锁对象的名称。将被删除以便使用 --leader-elect-resource-name。 +如果 --config 指定了一个配置文件，那么这个参数将被忽略。 @@ -671,14 +729,16 @@ DEPRECATED: define the name of the lock object. Will be removed in favor of lead 已弃用: 定义锁对象的命名空间。将被删除以便使用 leader-elect-resource-namespace。 +如果 --config 指定了一个配置文件，那么这个参数将被忽略。 ---log-backtrace-at traceLocation     默认值：:0 +--log-backtrace-at <a string in the form 'file:N'>      +默认值: 0 @@ -739,19 +799,24 @@ Maximum number of seconds between log flushes ---logging-format string     默认值："text" +--logging-format string     默认值：“text” -设置日志格式。可选格式："json"、"text"。
-非默认格式不会在意以下标志设置： ---add_dir_header、--alsologtostderr、--log_backtrace_at、--log_dir、 ---log_file、--log_file_max_size、--logtostderr、--one_output、 ---skip_headers、--skip_log_headers、--stderrthreshold、--vmodule、 ---log-flush-frequency.
+设置日志格式。可选格式：“json”，“text”。
+采用非默认格式时，以下标识不会生效： +--add-dir-header, --alsologtostderr, --log-backtrace-at, +--log-dir, --log-file, --log-file-max-size, +--logtostderr, --one-output, --skip-headers, --skip-log-headers, +--stderrthreshold, --vmodule, --log-flush-frequency.
非默认选项目前处于 Alpha 阶段，有可能会出现变更且无事先警告。 @@ -786,22 +851,38 @@ Kubernetes API 服务器的地址（覆盖 kubeconfig 中的任何值）。 若此标志为 true，则日志仅写入其自身的严重性级别，而不会写入所有较低严重性级别。 + +--permit-address-sharing + + + + +如果为 true，在绑定端口时将使用 SO_REUSEADDR。 +这将允许同时绑定诸如 0.0.0.0 这类通配符 IP和特定 IP， +并且它避免等待内核释放处于 TIME_WAIT 状态的套接字。 +默认值： false + + + --permit-port-sharing 如果此标志为 true，在绑定端口时会使用 SO_REUSEPORT，从而允许不止一个 实例绑定到同一地址和端口。 +默认值：false @@ -853,22 +934,25 @@ DEPRECATED: the namespace where policy ConfigMap is located. The kube-system nam -已弃用: 在没有身份验证和授权的情况下不安全地为 HTTP 服务的端口。 -如果为0，则根本不提供 HTTP。请参见--secure-port。 +已弃用： 在没有身份验证和鉴权的情况下不安全地为 HTTP 服务的端口。 +如果为 0，则根本不提供 HTTP。请参见 --secure-port。 +如果 --config 指定了一个配置文件，这个参数将被忽略。 ---profiling +--profiling     默认值： true 已弃用: 通过 Web 界面主机启用配置文件：host:port/debug/pprof/。 +如果 --config 指定了一个配置文件，这个参数将被忽略。 @@ -901,7 +985,8 @@ Root certificate bundle to use to verify client certificates on incoming request - --requestheader-extra-headers-prefix stringSlice     默认值：[x-remote-extra-] +--requestheader-extra-headers-prefix strings      +默认值: "x-remote-extra-" @@ -913,7 +998,8 @@ List of request header prefixes to inspect. X-Remote-Extra- is suggested. ---requestheader-group-headers stringSlice     默认值：[x-remote-group] +--requestheader-group-headers strings      +默认值: "x-remote-group" @@ -925,7 +1011,8 @@ List of request headers to inspect for groups. X-Remote-Group is suggested. ---requestheader-username-headers stringSlice     默认值：[x-remote-user] +--requestheader-username-headers strings      +默认值: "x-remote-user" @@ -937,15 +1024,17 @@ List of request headers to inspect for usernames. X-Remote-User is common. ---scheduler-name string     默认值："default-scheduler" +--scheduler-name string      +默认值："default-scheduler" -已弃用: 调度器名称，用于根据 Pod 的 "spec.schedulerName" 选择此 +已弃用: 调度器名称，用于根据 Pod 的 “spec.schedulerName” 选择此 调度器将处理的 Pod。 +如果 --config 指定了一个配置文件，那么这个参数将被忽略 @@ -955,7 +1044,7 @@ DEPRECATED: name of the scheduler, used to select which pods will be processed b 通过身份验证和授权为 HTTPS 服务的端口。如果为 0，则根本不提供 HTTPS。 @@ -1001,7 +1090,7 @@ If true, avoid headers when opening log files ---stderrthreshold severity     默认值：2 +--stderrthreshold int     默认值：2 @@ -1028,15 +1117,16 @@ File containing the default x509 Certificate for HTTPS. (CA cert, if any, concat ---tls-cipher-suites stringSlice +--tls-cipher-suites strings 服务器的密码套件列表，以逗号分隔。如果省略，将使用默认的 Go 密码套件。 优先考虑的值： @@ -1071,18 +1161,20 @@ File containing the default x509 private key matching --tls-cert-file. ---tls-sni-cert-key namedCertKey     默认值：[] +--tls-sni-cert-key string -一对 x509 证书和私钥文件路径，可选地后缀为完全限定域名的域模式列表， -并可能带有前缀的通配符段。如果未提供域名模式，则提取证书名称。 -非通配符匹配优先于通配符匹配，显式域名模式优先于提取而来的名称。 +一对 x509 证书和私钥文件路径，也可以包含由全限定域名构成的域名模式列表作为后缀， +并可能带有前缀的通配符段。域名匹配还允许是 IP 地址， +但是只有当 apiserver 对客户端请求的 IP 地址可见时，才能使用 IP。 +如果未提供域名匹配模式，则提取证书名称。 +非通配符匹配优先于通配符匹配，显式域名匹配优先于提取而来的名称。 若有多个密钥/证书对，可多次使用 --tls-sni-cert-key。 -例如: "example.crt,example.key" 或者 "foo.crt,foo.key:*.foo.com,foo.com"。 +例子: "example.crt,example.key" 或者 "foo.crt,foo.key:*.foo.com,foo.com"。 @@ -1100,7 +1192,7 @@ DEPRECATED: when set to true, scheduler will ignore policy ConfigMap and uses po --v, --v Level +-v, --v int @@ -1124,14 +1216,14 @@ Print version information and quit ---vmodule moduleSpec +--vmodule <逗号分隔的 ‘模式=N’ 配置列表> -以逗号分隔的 pattern=N 设置列表，用于文件过滤的日志记录。 +以逗号分隔的 ‘模式=N’ 设置列表，用于文件过滤的日志记录。 From baf379436b8b1598fc3a65b100f75148b88ae4d3 Mon Sep 17 00:00:00 2001 From: Shubham Kuchhal Date: Mon, 7 Jun 2021 17:33:58 +0530 Subject: [PATCH 107/128] Improvement: Managing Service Accounts --- .../access-authn-authz/service-accounts-admin.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/en/docs/reference/access-authn-authz/service-accounts-admin.md b/content/en/docs/reference/access-authn-authz/service-accounts-admin.md index ea04f462b1..867c9d0445 100644 --- a/content/en/docs/reference/access-authn-authz/service-accounts-admin.md +++ b/content/en/docs/reference/access-authn-authz/service-accounts-admin.md @@ -58,7 +58,7 @@ It acts synchronously to modify pods as they are created or updated. When this p 1. It ensures that the `ServiceAccount` referenced by the pod exists, and otherwise rejects it. 1. It adds a `volume` to the pod which contains a token for API access if neither the ServiceAccount `automountServiceAccountToken` nor the Pod's `automountServiceAccountToken` is set to `false`. 1. It adds a `volumeSource` to each container of the pod mounted at `/var/run/secrets/kubernetes.io/serviceaccount`, if the previous step has created a volume for ServiceAccount token. -1. If the pod does not contain any `ImagePullSecrets`, then `ImagePullSecrets` of the `ServiceAccount` are added to the pod. +1. If the pod does not contain any `imagePullSecrets`, then `imagePullSecrets` of the `ServiceAccount` are added to the pod. #### Bound Service Account Token Volume @@ -91,14 +91,14 @@ add the following projected volume instead of a Secret-based volume for the non- This projected volume consists of three sources: 1. A ServiceAccountToken acquired from kube-apiserver via TokenRequest API. It will expire after 1 hour by default or when the pod is deleted. It is bound to the pod and has kube-apiserver as the audience. -1. A ConfigMap containing a CA bundle used for verifying connections to the kube-apiserver. This feature depends on the `RootCAConfigMap` feature gate being enabled, which publishes a "kube-root-ca.crt" ConfigMap to every namespace. `RootCAConfigMap` is enabled by default in 1.20, and always enabled in 1.21+. +1. A ConfigMap containing a CA bundle used for verifying connections to the kube-apiserver. This feature depends on the `RootCAConfigMap` feature gate, which publishes a "kube-root-ca.crt" ConfigMap to every namespace. `RootCAConfigMap` feature gate is graduated to GA in 1.21 and default to true.(This flag will be removed from --feature-gate arg in 1.22) 1. A DownwardAPI that references the namespace of the pod. See more details about [projected volumes](/docs/tasks/configure-pod-container/configure-projected-volume-storage/). -You can manually migrate a secret-based service account volume to a projected volume when +You can manually migrate a Secret-based service account volume to a projected volume when the `BoundServiceAccountTokenVolume` feature gate is not enabled by adding the above -projected volume to the pod spec. However, `RootCAConfigMap` needs to be enabled. +projected volume to the pod spec. ### Token Controller From e4dde86ce2986feaa0c976de2b1962bed5c907e7 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Tue, 8 Jun 2021 13:32:38 +0800 Subject: [PATCH 108/128] Fix a typo on labels-annotations-taints page --- content/en/docs/reference/labels-annotations-taints.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/content/en/docs/reference/labels-annotations-taints.md b/content/en/docs/reference/labels-annotations-taints.md index 2d74362913..29f3a63a8c 100644 --- a/content/en/docs/reference/labels-annotations-taints.md +++ b/content/en/docs/reference/labels-annotations-taints.md @@ -222,7 +222,9 @@ When a single IngressClass resource has this annotation set to `"true"`, new Ing ## kubernetes.io/ingress.class (deprecated) -{{< note >}} Starting in v1.18, this annotation is deprecated in favor of `spec.ingressClassName`. {{< /note >}} +{{< note >}} +Starting in v1.18, this annotation is deprecated in favor of `spec.ingressClassName`. +{{< /note >}} ## storageclass.kubernetes.io/is-default-class @@ -230,7 +232,8 @@ Example: `storageclass.kubernetes.io/is-default-class=true` Used on: StorageClass -When a single StorageClass resource has this annotation set to `"true"`, new Physical Volume Claim resource without a class specified will be assigned this default class. +When a single StorageClass resource has this annotation set to `"true"`, new PersistentVolumeClaim +resource without a class specified will be assigned this default class. ## alpha.kubernetes.io/provided-node-ip From 5cf02fde985df30e84beae6d580bd3434bd90af6 Mon Sep 17 00:00:00 2001 From: Shubham Kuchhal Date: Tue, 8 Jun 2021 11:08:11 +0530 Subject: [PATCH 109/128] Add Spaces. --- .../docs/reference/access-authn-authz/service-accounts-admin.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/reference/access-authn-authz/service-accounts-admin.md b/content/en/docs/reference/access-authn-authz/service-accounts-admin.md index 867c9d0445..0d4ecff08c 100644 --- a/content/en/docs/reference/access-authn-authz/service-accounts-admin.md +++ b/content/en/docs/reference/access-authn-authz/service-accounts-admin.md @@ -91,7 +91,7 @@ add the following projected volume instead of a Secret-based volume for the non- This projected volume consists of three sources: 1. A ServiceAccountToken acquired from kube-apiserver via TokenRequest API. It will expire after 1 hour by default or when the pod is deleted. It is bound to the pod and has kube-apiserver as the audience. -1. A ConfigMap containing a CA bundle used for verifying connections to the kube-apiserver. This feature depends on the `RootCAConfigMap` feature gate, which publishes a "kube-root-ca.crt" ConfigMap to every namespace. `RootCAConfigMap` feature gate is graduated to GA in 1.21 and default to true.(This flag will be removed from --feature-gate arg in 1.22) +1. A ConfigMap containing a CA bundle used for verifying connections to the kube-apiserver. This feature depends on the `RootCAConfigMap` feature gate, which publishes a "kube-root-ca.crt" ConfigMap to every namespace. `RootCAConfigMap` feature gate is graduated to GA in 1.21 and default to true. (This flag will be removed from --feature-gate arg in 1.22) 1. A DownwardAPI that references the namespace of the pod. See more details about [projected volumes](/docs/tasks/configure-pod-container/configure-projected-volume-storage/). From c73d0510b93ae6741edfbcf167069fa09d2e8489 Mon Sep 17 00:00:00 2001 From: caodonghui Date: Thu, 3 Jun 2021 11:15:27 +0800 Subject: [PATCH 110/128] [zh]Resync Reference files[11] --- content/zh/docs/reference/_index.md | 108 ++++++++++++++---- .../reference/labels-annotations-taints.md | 100 +++++++++++++++- 2 files changed, 182 insertions(+), 26 deletions(-) diff --git a/content/zh/docs/reference/_index.md b/content/zh/docs/reference/_index.md index d1c1c93035..f28e5b1e5d 100644 --- a/content/zh/docs/reference/_index.md +++ b/content/zh/docs/reference/_index.md @@ -15,6 +15,7 @@ linkTitle: "Reference" main_menu: true weight: 70 content_type: concept +no_list: true --> @@ -29,16 +30,26 @@ This section of the Kubernetes documentation contains references. ## API 参考 +* [术语表](/zh/docs/reference/glossary/) - 一个全面的标准化的 Kubernetes 术语表 + +* [Kubernetes API 单页参考](/zh/docs/reference/kubernetes-api/) * [Kubernetes API 参考 {{< param "version" >}}](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)。 * [使用 Kubernetes API ](/zh/docs/reference/using-api/) - Kubernetes 的 API 概述 +* [API 的访问控制](/zh/docs/reference/access-authn-authz/) - 关于 Kubernetes 如何控制 API 访问的详细信息 +* [常见的标签、注解和污点](/zh/docs/reference/labels-annotations-taints/) -## API 客户端库 +## 官方支持的客户端库 如果您需要通过编程语言调用 Kubernetes API，您可以使用 [客户端库](/zh/docs/reference/using-api/client-libraries/)。以下是官方支持的客户端库： @@ -58,16 +71,17 @@ client libraries: - [Kubernetes Python 语言客户端库](https://github.com/kubernetes-client/python) - [Kubernetes Java 语言客户端库](https://github.com/kubernetes-client/java) - [Kubernetes JavaScript 语言客户端库](https://github.com/kubernetes-client/javascript) +- [Kubernetes Dotnet 语言客户端库](https://github.com/kubernetes-client/csharp) +- [Kubernetes Haskell 语言客户端库](https://github.com/kubernetes-client/haskell) -## CLI 参考 +## CLI * [kubectl](/zh/docs/reference/kubectl/overview/) - 主要的 CLI 工具，用于运行命令和管理 Kubernetes 集群。 * [JSONPath](/zh/docs/reference/kubectl/jsonpath/) - 通过 kubectl 使用 @@ -75,29 +89,75 @@ client libraries: * [kubeadm](/zh/docs/reference/setup-tools/kubeadm/) - 此 CLI 工具可轻松配置安全的 Kubernetes 集群。 -## 组件参考 +## 组件 + +* [kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) - + 在每个节点上运行的主代理。kubelet 接收一组 PodSpecs 并确保其所描述的容器健康地运行。 +* [kube-apiserver](/zh/docs/reference/command-line-tools-reference/kube-apiserver/) - + REST API，用于验证和配置 API 对象（如 Pod、服务或副本控制器等）的数据。 +* [kube-controller-manager](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/) - + 一个守护进程，其中包含 Kubernetes 所附带的核心控制回路。 +* [kube-proxy](/zh/docs/reference/command-line-tools-reference/kube-proxy/) - + 可进行简单的 TCP/UDP 流转发或针对一组后端执行轮流 TCP/UDP 转发。 +* [kube-scheduler](/zh/docs/reference/command-line-tools-reference/kube-scheduler/) - + 一个调度程序，用于管理可用性、性能和容量。 + + * [调度策略](/zh/docs/reference/scheduling/policies) + * [调度配置](/zh/docs/reference/scheduling/config#profiles) + + +## 配置 API + +本节包含用于配置 kubernetes 组件或工具的 "未发布" API 的文档。 +尽管这些 API 对于用户或操作者使用或管理集群来说是必不可少的， +它们大都没有以 RESTful 的方式在 API 服务器上公开。 + +* [kubelet 配置 (v1beta1)](/zh/docs/reference/config-api/kubelet-config.v1beta1/) +* [kube-scheduler 配置 (v1beta1)](/zh/docs/reference/config-api/kube-scheduler-config.v1beta1/) +* [kube-scheduler 策略参考 (v1)](/zh/docs/reference/config-api/kube-scheduler-policy-config.v1/) +* [kube-proxy 配置 (v1alpha1)](/zh/docs/reference/config-api/kube-proxy-config.v1alpha1/) +* [`audit.k8s.io/v1` API](/zh/docs/reference/config-api/apiserver-audit.v1/) +* [客户端认证 API (v1beta1)](/zh/docs/reference/config-api/client-authentication.v1beta1/) +* [WebhookAdmission 配置 (v1)](/zh/docs/reference/config-api/apiserver-webhookadmission.v1/) -* [kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) - 在每个节点上运行的主 *节点代理* 。kubelet 采用一组 PodSpecs 并确保所描述的容器健康地运行。 -* [kube-apiserver](/zh/docs/reference/command-line-tools-reference/kube-apiserver/) - REST API，用于验证和配置 API 对象（如 Pod、服务或副本控制器等）的数据。 -* [kube-controller-manager](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/) - 一个守护进程，它嵌入到了 Kubernetes 的附带的核心控制循环。 -* [kube-proxy](/zh/docs/reference/command-line-tools-reference/kube-proxy/) - 可进行简单的 TCP/UDP 流转发或针对一组后端执行轮流 TCP/UDP 转发。 -* [kube-scheduler](/zh/docs/reference/command-line-tools-reference/kube-scheduler/) - 一个调度程序，用于管理可用性、性能和容量。 - * [kube-scheduler 策略](/zh/docs/reference/scheduling/policies) - * [kube-scheduler 配置](/zh/docs/reference/scheduling/config#profiles) ## 设计文档 diff --git a/content/zh/docs/reference/labels-annotations-taints.md b/content/zh/docs/reference/labels-annotations-taints.md index 1c163cc056..e4b1fdfe70 100644 --- a/content/zh/docs/reference/labels-annotations-taints.md +++ b/content/zh/docs/reference/labels-annotations-taints.md @@ -46,6 +46,26 @@ The Kubelet populates this with `runtime.GOOS` as defined by Go. This can be han --> Kubelet 用 Go 定义的 `runtime.GOOS` 生成该标签的键值。在混合使用异构操作系统场景下（例如：混合使用 Linux 和 Windows 节点），此键值可以带来极大便利。 +## kubernetes.io/metadata.name + +示例：`kubernetes.io/metadata.name=mynamespace` + +用于：Namespaces + + +当 `NamespaceDefaultLabelName` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) +被启用时，Kubernetes API 服务器会在所有命名空间上设置此标签。标签值被设置为命名空间的名称。 + +如果你想使用标签 {{< glossary_tooltip text="选择器" term_id="selector" >}} 来指向特定的命名空间，这很有用。 + ## beta.kubernetes.io/arch (deprecated) +该注解用于设置 [Pod 删除开销](/zh/docs/concepts/workloads/controllers/replicaset/#pod-deletion-cost)， +允许用户影响 ReplicaSet 的缩减顺序。该注解解析为 `int32` 类型。 + ## beta.kubernetes.io/instance-type (deprecated) {{< note >}} @@ -124,6 +157,22 @@ Starting in v1.17, this label is deprecated in favor of [topology.kubernetes.io/ 从 v1.17 开始，此标签被弃用，取而代之的是 [topology.kubernetes.io/zone](#topologykubernetesiozone). {{< /note >}} +## statefulset.kubernetes.io/pod-name {#statefulsetkubernetesiopod-name} + +示例：`statefulset.kubernetes.io/pod-name=mystatefulset-7` + + +当 StatefulSet 控制器为 StatefulSet 创建 Pod 时，控制平面会在该 Pod 上设置此标签。 +标签的值是正在创建的 Pod 的名称。 + +更多细节请参见 StatefulSet 文章中的 [Pod 名称标签](/zh/docs/concepts/workloads/controllers/statefulset/#pod-name-label)。 + ## topology.kubernetes.io/region {#topologykubernetesioregion} 示例 @@ -316,6 +365,17 @@ Starting in v1.18, this annotation is deprecated in favor of `spec.ingressClassN 从 v1.18 开始，此注解被弃用，取而代之的是 `spec.ingressClassName`。 {{< /note >}} +## storageclass.kubernetes.io/is-default-class + +示例：`storageclass.kubernetes.io/is-default-class=true` + +用于：StorageClass + + +当单个的 StorageClass 资源将这个注解设置为 `"true"` 时，新的持久卷申领（PVC） +资源若未指定类别，将被设定为此默认类别。 ## alpha.kubernetes.io/provided-node-ip @@ -327,14 +387,50 @@ Starting in v1.18, this annotation is deprecated in favor of `spec.ingressClassN The kubelet can set this annotation on a Node to denote its configured IPv4 address. When kubelet is started with the "external" cloud provider, it sets this annotation on the Node to denote an IP address set from the command line flag (`--node-ip`). This IP is verified with the cloud provider as valid by the cloud-controller-manager. - -**The taints listed below are always used on Nodes** --> kubectl 在 Node 上设置此注解，表示它的 IPv4 地址。 当 kubectl 由外部的云供应商启动时，在 Node 上设置此注解，表示由命令行标记(`--node-ip`)设置的 IP 地址。 cloud-controller-manager 向云供应商验证此 IP 是否有效。 +## batch.kubernetes.io/job-completion-index + +示例：`batch.kubernetes.io/job-completion-index: "3"` + +用于：Pod + + +kube-controller-manager 中的 Job 控制器给创建使用索引 +[完成模式](/zh/docs/concepts/workloads/controllers/job/#completion-mode) +的 Pod 设置此注解。 + +## kubectl.kubernetes.io/default-container + +示例：`kubectl.kubernetes.io/default-container: "front-end-app"` + + +注解的值是此 Pod 的默认容器名称。 +例如，`kubectl logs` 或 `kubectl exec` 没有 `-c` 或 `--container` 参数时，将使用这个默认的容器。 + +## endpoints.kubernetes.io/over-capacity + +示例：`endpoints.kubernetes.io/over-capacity:warning` + +用于：Endpoints + + +在 Kubernetes 集群 v1.21（或更高版本）中，如果 Endpoint 超过 1000 个，Endpoint 控制器 +就会向其添加这个注解。该注解表示 Endpoint 资源已超过容量。 + **以下列出的污点只能用于 Node** ## node.kubernetes.io/not-ready From 745e62c4d65c5ca4d56e825e373b0bf08f693e77 Mon Sep 17 00:00:00 2001 From: Albert Date: Wed, 9 Jun 2021 02:34:55 +0800 Subject: [PATCH 111/128] [es]: fix container-runtime full_link 404 --- content/es/docs/reference/glossary/container-runtime.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/reference/glossary/container-runtime.md b/content/es/docs/reference/glossary/container-runtime.md index 597ceaf25c..fd3328e799 100644 --- a/content/es/docs/reference/glossary/container-runtime.md +++ b/content/es/docs/reference/glossary/container-runtime.md @@ -2,7 +2,7 @@ title: Container Runtime id: container-runtime date: 2019-06-05 -full_link: /es/docs/reference/generated/container-runtime +full_link: /docs/setup/production-environment/container-runtimes short_description: > El _Container Runtime_, entorno de ejecución de un contenedor, es el software responsable de ejecutar contenedores. From 8d40a8560ca2913d1dfbde2d20c2dd1c30aaba07 Mon Sep 17 00:00:00 2001 From: Albert Date: Wed, 9 Jun 2021 02:38:55 +0800 Subject: [PATCH 112/128] [fr]: fix container-runtime full_link 404 --- content/fr/docs/reference/glossary/container-runtime.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/fr/docs/reference/glossary/container-runtime.md b/content/fr/docs/reference/glossary/container-runtime.md index ccd95157b9..1d2c8b105f 100644 --- a/content/fr/docs/reference/glossary/container-runtime.md +++ b/content/fr/docs/reference/glossary/container-runtime.md @@ -2,7 +2,7 @@ title: Container Runtime id: container-runtime date: 2019-06-05 -full_link: /docs/reference/generated/container-runtime +full_link: /docs/setup/production-environment/container-runtimes short_description: > L'environnement d'exécution de conteneurs est le logiciel responsable de l'exécution des conteneurs. From fc82534c5b4e845bf25ec93ca1463f2a92c3baa1 Mon Sep 17 00:00:00 2001 From: Albert Date: Wed, 9 Jun 2021 02:42:06 +0800 Subject: [PATCH 113/128] [ru]: fix container-runtime full_link 404 --- content/ru/docs/reference/glossary/container-runtime.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ru/docs/reference/glossary/container-runtime.md b/content/ru/docs/reference/glossary/container-runtime.md index cea63dfa94..25916582e5 100644 --- a/content/ru/docs/reference/glossary/container-runtime.md +++ b/content/ru/docs/reference/glossary/container-runtime.md @@ -2,7 +2,7 @@ title: Среда выполнения контейнера id: container-runtime date: 2019-06-05 -full_link: /docs/reference/generated/container-runtime +full_link: /docs/setup/production-environment/container-runtimes short_description: > Среда выполнения контейнера — это программа, предназначенная для выполнения контейнеров. From ddc67b811442170610137ebf7f00d191c97174d4 Mon Sep 17 00:00:00 2001 From: Squidtoon99 <49101235+Squidtoon99@users.noreply.github.com> Date: Tue, 8 Jun 2021 21:11:47 -0500 Subject: [PATCH 114/128] Fix a few grammar issues and typos (#28332) * Fix few grammar issues and typos in the blog page > see the API documentation more information Should be corrected to "documentation for more information" as the sentence is incorrect. > may only compare two resource version for equality Everywhere else in the paragraph "resource versions" are used, I believe this is just a typo. > The get, list and watch Missing comma after list to separate the elements * Fix typos in blog post > On rare occurences, a "occurrences" is misspelled > whole list, map or struct 3 elements are missing a comma seperator after map > there are no way are is a plural form while "no way" is a singular subject > `MergePatch`, `StrategicMergePatch`, `JSONPatch` or `Update` Missing comma after JSONPatch --- content/en/docs/reference/using-api/api-concepts.md | 6 +++--- content/en/docs/reference/using-api/server-side-apply.md | 8 ++++---- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/content/en/docs/reference/using-api/api-concepts.md b/content/en/docs/reference/using-api/api-concepts.md index e517a13d52..da41e7c4c9 100644 --- a/content/en/docs/reference/using-api/api-concepts.md +++ b/content/en/docs/reference/using-api/api-concepts.md @@ -49,7 +49,7 @@ Some resource types will have one or more sub-resources, represented as sub path * Cluster-scoped subresource: `GET /apis/GROUP/VERSION/RESOURCETYPE/NAME/SUBRESOURCE` * Namespace-scoped subresource: `GET /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE/NAME/SUBRESOURCE` -The verbs supported for each subresource will differ depending on the object - see the API documentation more information. It is not possible to access sub-resources across multiple resources - generally a new virtual resource type would be used if that becomes necessary. +The verbs supported for each subresource will differ depending on the object - see the API documentation for more information. It is not possible to access sub-resources across multiple resources - generally a new virtual resource type would be used if that becomes necessary. ## Efficient detection of changes @@ -442,7 +442,7 @@ feature, see the section on ## Resource Versions -Resource versions are strings that identify the server's internal version of an object. Resource versions can be used by clients to determine when objects have changed, or to express data consistency requirements when getting, listing and watching resources. Resource versions must be treated as opaque by clients and passed unmodified back to the server. For example, clients must not assume resource versions are numeric, and may only compare two resource version for equality (i.e. must not compare resource versions for greater-than or less-than relationships). +Resource versions are strings that identify the server's internal version of an object. Resource versions can be used by clients to determine when objects have changed, or to express data consistency requirements when getting, listing and watching resources. Resource versions must be treated as opaque by clients and passed unmodified back to the server. For example, clients must not assume resource versions are numeric, and may only compare two resource versions for equality (i.e. must not compare resource versions for greater-than or less-than relationships). ### ResourceVersion in metadata @@ -454,7 +454,7 @@ Clients find resource versions in resources, including the resources in watch ev ### The ResourceVersion Parameter -The get, list and watch operations support the `resourceVersion` parameter. +The get, list, and watch operations support the `resourceVersion` parameter. The exact meaning of this parameter differs depending on the operation and the value of `resourceVersion`. diff --git a/content/en/docs/reference/using-api/server-side-apply.md b/content/en/docs/reference/using-api/server-side-apply.md index 1502684325..3d88413b50 100644 --- a/content/en/docs/reference/using-api/server-side-apply.md +++ b/content/en/docs/reference/using-api/server-side-apply.md @@ -245,7 +245,7 @@ field tags. ### Compatibility across topology changes -On rare occurences, a CRD or built-in type author may want to change the +On rare occurrences, a CRD or built-in type author may want to change the specific topology of a field in their resource without incrementing its version. Changing the topology of types, by upgrading the cluster or updating the CRD, has different consequences when updating existing @@ -253,7 +253,7 @@ objects. There are two categories of changes: when a field goes from `map`/`set`/`granular` to `atomic` and the other way around. When the `listType`, `mapType`, or `structType` changes from -`map`/`set`/`granular` to `atomic`, the whole list, map or struct of +`map`/`set`/`granular` to `atomic`, the whole list, map, or struct of existing objects will end-up being owned by actors who owned an element of these types. This means that any further change to these objects would cause a conflict. @@ -310,7 +310,7 @@ simplify the update logic of your controller. The main differences with a read-modify-write and/or patch are the following: * the applied object must contain all the fields that the controller cares about. -* there are no way to remove fields that haven't been applied by the controller +* there is no way to remove fields that haven't been applied by the controller before (controller can still send a PATCH/UPDATE for these use-cases). * the object doesn't have to be read beforehand, `resourceVersion` doesn't have to be specified. @@ -473,7 +473,7 @@ have an opinion about. ## Clearing ManagedFields It is possible to strip all managedFields from an object by overwriting them -using `MergePatch`, `StrategicMergePatch`, `JSONPatch` or `Update`, so every +using `MergePatch`, `StrategicMergePatch`, `JSONPatch`, or `Update`, so every non-apply operation. This can be done by overwriting the managedFields field with an empty entry. Two examples are: From cbc503206a47217570b1d50e90c7c337be4cee1b Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Wed, 9 Jun 2021 10:37:08 +0800 Subject: [PATCH 115/128] [zh] Resync service account admin page --- .../service-accounts-admin.md | 99 +++++++++++++++---- 1 file changed, 78 insertions(+), 21 deletions(-) diff --git a/content/zh/docs/reference/access-authn-authz/service-accounts-admin.md b/content/zh/docs/reference/access-authn-authz/service-accounts-admin.md index 82b37c9043..071329096c 100644 --- a/content/zh/docs/reference/access-authn-authz/service-accounts-admin.md +++ b/content/zh/docs/reference/access-authn-authz/service-accounts-admin.md @@ -1,5 +1,5 @@ --- -title: 管理 Service Accounts +title: 管理服务账号 content_type: concept weight: 50 --- @@ -20,7 +20,7 @@ weight: 50 This is a Cluster Administrator guide to service accounts. You should be familiar with [configuring Kubernetes service accounts](/docs/tasks/configure-pod-container/configure-service-account/). -Support for authorization and user accounts is planned but incomplete. Sometimes +Support for authorization and user accounts is planned but incomplete. Sometimes incomplete features are referred to in order to better describe service accounts. --> 这是一篇针对服务账号的集群管理员指南。你应该熟悉 @@ -102,41 +102,98 @@ It acts synchronously to modify pods as they are created or updated. When this p 或更新时它会进行以下操作： -1. 如果该 Pod 没有设置 `serviceAccountName`，将其 `serviceAccountName` 设为 - `default`。 -1. 保证 Pod 所引用的 `serviceAccountName` 确实存在，否则拒绝该 Pod。 -1. 如果 Pod 不包含 `imagePullSecrets` 设置，将 `serviceAccountName` 所引用 - 的服务账号中的 `imagePullSecrets` 信息添加到 Pod 中。 +1. 如果该 Pod 没有设置 `ServiceAccount`，将其 `ServiceAccount` 设为 `default`。 +1. 保证 Pod 所引用的 `ServiceAccount` 确实存在，否则拒绝该 Pod。 1. 如果服务账号的 `automountServiceAccountToken` 或 Pod 的 `automountServiceAccountToken` 都为设置为 `false`，则为 Pod 创建一个 `volume`，在其中包含用来访问 API 的令牌。 1. 如果前一步中为服务账号令牌创建了卷，则为 Pod 中的每个容器添加一个 `volumeSource`，挂载在其 `/var/run/secrets/kubernetes.io/serviceaccount` 目录下。 +1. 如果 Pod 不包含 `imagePullSecrets` 设置，将 `ServiceAccount` 所引用 + 的服务账号中的 `imagePullSecrets` 信息添加到 Pod 中。 -当 `BoundServiceAccountTokenVolume` 特性门控被启用时，你可以将服务账号卷迁移到投射卷。 -服务账号令牌会在 1 小时后或者 Pod 被删除之后过期。 -更多信息可参阅[投射卷](/zh/docs/tasks/configure-pod-container/configure-projected-volume-storage/)。 +#### 绑定的服务账号令牌卷 {#bound-service-account-token-volume} + + +{{< feature-state for_k8s_version="v1.21" state="beta" >}} + + +当 `BoundServiceAccountTokenVolume` +[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) +被启用时，服务账号准入控制器将添加如下投射卷，而不是为令牌控制器 +所生成的不过期的服务账号令牌而创建的基于 Secret 的卷。 + +```yaml +- name: kube-api-access-<随机后缀> + projected: + defaultMode: 420 # 0644 + sources: + - serviceAccountToken: + expirationSeconds: 3600 + path: token + - configMap: + items: + - key: ca.crt + path: ca.crt + name: kube-root-ca.crt + - downwardAPI: + items: + - fieldRef: + apiVersion: v1 + fieldPath: metadata.namespace + path: namespace +``` + + +此投射卷有三个数据源： + +1. 通过 TokenRequest API 从 kube-apiserver 处获得的 ServiceAccountToken。 + 这一令牌默认会在一个小时之后或者 Pod 被删除时过期。 + 该令牌绑定到 Pod 实例上，并将 kube-apiserver 作为其受众（audience）。 +1. 包含用来验证与 kube-apiserver 连接的 CA 证书包的 ConfigMap 对象。 + 这一特性依赖于 `RootCAConfigMap` 特性门控被启用。该特性被启用时， + 控制面会公开一个名为 `kube-root-ca.crt` 的 ConfigMap 给所有名字空间。 + `RootCAConfigMap` 在 1.20 版本中是默认被启用的，在 1.21 及之后版本中 + 总是被启用。 +1. 引用 Pod 名字空间的一个 DownwardAPI。 + + +参阅[投射卷](/zh/docs/tasks/configure-pod-container/configure-projected-volume-storage/) +了解进一步的细节。 + +如果 `BoundServiceAccountTokenVolume` 特性门控未被启用， +你可以手动地将一个基于 Secret 的服务账号卷升级为一个投射卷， +方法是将上述投射卷添加到 Pod 规约中。 +不过，这时仍需要启用 `RootCAConfigMap` 特性门控。 -[_Node affinity_](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity), +[_Node affinity_](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity) is a property of {{< glossary_tooltip text="Pods" term_id="pod" >}} that *attracts* them to a set of {{< glossary_tooltip text="nodes" term_id="node" >}} (either as a preference or a hard requirement). _Taints_ are the opposite -- they allow a node to repel a set of pods. From c3624aba963375d090d7692a3cac4cae3a4a2032 Mon Sep 17 00:00:00 2001 From: Jai Govindani Date: Wed, 9 Jun 2021 19:29:47 +0700 Subject: [PATCH 117/128] fix(/contribute/page-templates): broken redirect (#28107) * fix(/contribute/page-templates): broken redirect Signed-off-by: Jai Govindani * fix(redirects): page-templates > page-content-types * fix(static/_redirects): remove erroneous redirect --- static/_redirects | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/static/_redirects b/static/_redirects index c6716f2084..0d95cef56f 100644 --- a/static/_redirects +++ b/static/_redirects @@ -184,11 +184,12 @@ /docs/home/contribute/generated-reference/kubernetes-api/ /docs/contribute/generate-ref-docs/kubernetes-api/ 301 /docs/home/contribute/generated-reference/kubernetes-components/ /docs/contribute/generate-ref-docs/kubernetes-components/ 301 /docs/home/contribute/localization/ /docs/contribute/localization/ 301 -/docs/home/contribute/page-templates/ /docs/contribute/style/page-templates/ 301 +/docs/home/contribute/page-templates/ /docs/contribute/style/page-content-types/ 301 /docs/home/contribute/participating/ /docs/contribute/participate/ 301 /docs/home/contribute/review-issues/ /docs/contribute/intermediate/ 301 /docs/home/contribute/blog-post/ /docs/contribute/start/ 301 /docs/home/contribute/write-new-topic/ /docs/contribute/style/write-new-topic/ 301 +/docs/contribute/style/page-templates/ /docs/contribute/style/page-content-types/ 301 /docs/reference/command-line-tools-reference/labels-annotations-taints/ /docs/reference/labels-annotations-taints/ 301 From 03d885ebc0230db34f4730a930cff34193c883fc Mon Sep 17 00:00:00 2001 From: Bas Kok Date: Wed, 9 Jun 2021 21:30:01 +0200 Subject: [PATCH 118/128] Update the expected output for `minikube addons enable` The output from `minikube addons enable` in the documentation should match the output from the current version of minikube (which is also in katakoda) --- content/en/docs/tutorials/hello-minikube.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/tutorials/hello-minikube.md b/content/en/docs/tutorials/hello-minikube.md index d8ad753958..5193372920 100644 --- a/content/en/docs/tutorials/hello-minikube.md +++ b/content/en/docs/tutorials/hello-minikube.md @@ -224,7 +224,7 @@ The minikube tool includes a set of built-in {{< glossary_tooltip text="addons" The output is similar to: ``` - metrics-server was successfully enabled + The 'metrics-server' addon is enabled ``` 3. View the Pod and Service you created: From 0295ca4f9e06df1b22c89d2b324bb218070bc798 Mon Sep 17 00:00:00 2001 From: Bruno Gabriel da Silva <38823062+bgsilvait@users.noreply.github.com> Date: Thu, 10 Jun 2021 02:37:26 +0100 Subject: [PATCH 119/128] Adjust yaml indentation on allowedHostPaths example (#27731) * Adjust yaml indentation on allowedHostPaths allowedHostPaths is an attribute inside spec: of PSP, so the sample needs to be shifted to match the YAML. * Adjusted the PSP example allowedHostPaths coments Adjusted the whole example (including the #coments) --- .../en/docs/concepts/policy/pod-security-policy.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/content/en/docs/concepts/policy/pod-security-policy.md b/content/en/docs/concepts/policy/pod-security-policy.md index f0884c3dea..fac2b1205e 100644 --- a/content/en/docs/concepts/policy/pod-security-policy.md +++ b/content/en/docs/concepts/policy/pod-security-policy.md @@ -464,12 +464,12 @@ allowed prefix, and a `readOnly` field indicating it must be mounted read-only. For example: ```yaml -allowedHostPaths: - # This allows "/foo", "/foo/", "/foo/bar" etc., but - # disallows "/fool", "/etc/foo" etc. - # "/foo/../" is never valid. - - pathPrefix: "/foo" - readOnly: true # only allow read-only mounts + allowedHostPaths: + # This allows "/foo", "/foo/", "/foo/bar" etc., but + # disallows "/fool", "/etc/foo" etc. + # "/foo/../" is never valid. + - pathPrefix: "/foo" + readOnly: true # only allow read-only mounts ``` {{< warning >}}There are many ways a container with unrestricted access to the host From 038b2b99a7a812ad5cb342b41eb209bd2f9dca0b Mon Sep 17 00:00:00 2001 From: howieyuen Date: Thu, 10 Jun 2021 23:22:43 +0800 Subject: [PATCH 120/128] fix two broken links and a word localization --- content/zh/docs/concepts/containers/runtime-class.md | 4 +--- content/zh/docs/concepts/workloads/pods/_index.md | 2 +- content/zh/docs/concepts/workloads/pods/disruptions.md | 2 +- .../zh/docs/concepts/workloads/pods/ephemeral-containers.md | 2 +- content/zh/docs/contribute/localization_zh.md | 2 +- content/zh/docs/reference/glossary/pod.md | 2 +- 6 files changed, 6 insertions(+), 8 deletions(-) diff --git a/content/zh/docs/concepts/containers/runtime-class.md b/content/zh/docs/concepts/containers/runtime-class.md index c45df4e62b..d1ed733804 100644 --- a/content/zh/docs/concepts/containers/runtime-class.md +++ b/content/zh/docs/concepts/containers/runtime-class.md @@ -313,6 +313,4 @@ Pod 开销通过 RuntimeClass 的 `overhead` 字段定义。 - [RuntimeClass 设计](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md) - [RuntimeClass 调度设计](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md#runtimeclass-scheduling) - 阅读关于 [Pod 开销](/zh/docs/concepts/scheduling-eviction/pod-overhead/) 的概念 -- [PodOverhead 特性设计](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md) - - +- [PodOverhead 特性设计](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead) diff --git a/content/zh/docs/concepts/workloads/pods/_index.md b/content/zh/docs/concepts/workloads/pods/_index.md index 422ee139c2..4dde0a45db 100644 --- a/content/zh/docs/concepts/workloads/pods/_index.md +++ b/content/zh/docs/concepts/workloads/pods/_index.md @@ -135,7 +135,7 @@ Kubernetes 集群中的 Pod 主要有两种用法： * **运行多个协同工作的容器的 Pod**。 Pod 可能封装由多个紧密耦合且需要共享资源的共处容器组成的应用程序。 这些位于同一位置的容器可能形成单个内聚的服务单元 —— 一个容器将文件从共享卷提供给公众， - 而另一个单独的“挂斗”（sidecar）容器则刷新或更新这些文件。 + 而另一个单独的“边车”（sidecar）容器则刷新或更新这些文件。 Pod 将这些容器和存储资源打包为一个可管理的实体。 {{< note >}} diff --git a/content/zh/docs/concepts/workloads/pods/disruptions.md b/content/zh/docs/concepts/workloads/pods/disruptions.md index c200a51757..e146d66bc5 100644 --- a/content/zh/docs/concepts/workloads/pods/disruptions.md +++ b/content/zh/docs/concepts/workloads/pods/disruptions.md @@ -170,7 +170,7 @@ in your pod spec can also cause voluntary (and involuntary) disruptions. 实现可能导致碎片整理和紧缩节点的自愿干扰。集群 管理员或托管提供商应该已经记录了各级别的自愿干扰（如果有的话）。 有些配置选项，例如在 pod spec 中 -[使用 PriorityClasses]（https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/） +[使用 PriorityClasses](https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/) 也会产生自愿（和非自愿）的干扰。 -### 临时容器 API {#ephemeral-containers-api}」 +### 临时容器 API {#ephemeral-containers-api} {{< note >}} -通常创建 Pod 是为了运行单个主容器。Pod 还可以运行可选的挂斗（sidecar）容器，以添加诸如日志记录之类的补充特性。通常用 {{< glossary_tooltip term_id="deployment" >}} 来管理 Pod。 +通常创建 Pod 是为了运行单个主容器。Pod 还可以运行可选的边车（sidecar）容器，以添加诸如日志记录之类的补充特性。通常用 {{< glossary_tooltip term_id="deployment" >}} 来管理 Pod。 From c18c0acb3887abae858f328033acf8144ee1c715 Mon Sep 17 00:00:00 2001 From: Carlos Panato Date: Fri, 11 Jun 2021 11:13:03 +0200 Subject: [PATCH 121/128] release-managers: add adolfo/carlos as tech leads Signed-off-by: Carlos Panato --- content/en/releases/release-managers.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/content/en/releases/release-managers.md b/content/en/releases/release-managers.md index e8b895def6..1554f3df9a 100644 --- a/content/en/releases/release-managers.md +++ b/content/en/releases/release-managers.md @@ -192,6 +192,8 @@ GitHub team: [@kubernetes/sig-release-leads](https://github.com/orgs/kubernetes/ ### Technical Leads +- Adolfo García Veytia ([@puerco](https://github.com/puerco)) +- Carlos Panato ([@cpanato](https://github.com/cpanato)) - Daniel Mangum ([@hasheddan](https://github.com/hasheddan)) - Jeremy Rickard ([@jeremyrickard](https://github.com/jeremyrickard)) From 2a03ddea27b9a78d918ad96539b0a571401bf6ab Mon Sep 17 00:00:00 2001 From: Brendan Burns Date: Fri, 11 Jun 2021 18:23:00 -0700 Subject: [PATCH 122/128] Remove Google SDK instructions. (#28165) * Remove Google SDK instructions. Ref: https://github.com/kubernetes/website/issues/20232 * Remove Google SDK instructions for MacOS * Remove Google SDK instructions for Windows * Delete install-kubectl-gcloud.md --- .../tools/included/install-kubectl-gcloud.md | 21 ------------------- .../docs/tasks/tools/install-kubectl-linux.md | 5 ----- .../docs/tasks/tools/install-kubectl-macos.md | 6 ------ .../tasks/tools/install-kubectl-windows.md | 7 +------ 4 files changed, 1 insertion(+), 38 deletions(-) delete mode 100644 content/en/docs/tasks/tools/included/install-kubectl-gcloud.md diff --git a/content/en/docs/tasks/tools/included/install-kubectl-gcloud.md b/content/en/docs/tasks/tools/included/install-kubectl-gcloud.md deleted file mode 100644 index dcf8572618..0000000000 --- a/content/en/docs/tasks/tools/included/install-kubectl-gcloud.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: "gcloud kubectl install" -description: "How to install kubectl with gcloud snippet for inclusion in each OS-specific tab." -headless: true ---- - -You can install kubectl as part of the Google Cloud SDK. - -1. Install the [Google Cloud SDK](https://cloud.google.com/sdk/). - -1. Run the `kubectl` installation command: - - ```shell - gcloud components install kubectl - ``` - -1. Test to ensure the version you installed is up-to-date: - - ```shell - kubectl version --client - ``` \ No newline at end of file diff --git a/content/en/docs/tasks/tools/install-kubectl-linux.md b/content/en/docs/tasks/tools/install-kubectl-linux.md index d64ef99b13..cd04442614 100644 --- a/content/en/docs/tasks/tools/install-kubectl-linux.md +++ b/content/en/docs/tasks/tools/install-kubectl-linux.md @@ -22,7 +22,6 @@ The following methods exist for installing kubectl on Linux: - [Install kubectl binary with curl on Linux](#install-kubectl-binary-with-curl-on-linux) - [Install using native package management](#install-using-native-package-management) - [Install using other package management](#install-using-other-package-management) -- [Install on Linux as part of the Google Cloud SDK](#install-on-linux-as-part-of-the-google-cloud-sdk) ### Install kubectl binary with curl on Linux @@ -168,10 +167,6 @@ kubectl version --client {{< /tabs >}} -### Install on Linux as part of the Google Cloud SDK - -{{< include "included/install-kubectl-gcloud.md" >}} - ## Verify kubectl configuration {{< include "included/verify-kubectl.md" >}} diff --git a/content/en/docs/tasks/tools/install-kubectl-macos.md b/content/en/docs/tasks/tools/install-kubectl-macos.md index d952359407..3087d83517 100644 --- a/content/en/docs/tasks/tools/install-kubectl-macos.md +++ b/content/en/docs/tasks/tools/install-kubectl-macos.md @@ -22,7 +22,6 @@ The following methods exist for installing kubectl on macOS: - [Install kubectl binary with curl on macOS](#install-kubectl-binary-with-curl-on-macos) - [Install with Homebrew on macOS](#install-with-homebrew-on-macos) - [Install with Macports on macOS](#install-with-macports-on-macos) -- [Install on macOS as part of the Google Cloud SDK](#install-on-macos-as-part-of-the-google-cloud-sdk) ### Install kubectl binary with curl on macOS @@ -149,11 +148,6 @@ If you are on macOS and using [Macports](https://macports.org/) package manager, kubectl version --client ``` - -### Install on macOS as part of the Google Cloud SDK - -{{< include "included/install-kubectl-gcloud.md" >}} - ## Verify kubectl configuration {{< include "included/verify-kubectl.md" >}} diff --git a/content/en/docs/tasks/tools/install-kubectl-windows.md b/content/en/docs/tasks/tools/install-kubectl-windows.md index 11f79b6d94..45f7759df9 100644 --- a/content/en/docs/tasks/tools/install-kubectl-windows.md +++ b/content/en/docs/tasks/tools/install-kubectl-windows.md @@ -21,7 +21,6 @@ The following methods exist for installing kubectl on Windows: - [Install kubectl binary with curl on Windows](#install-kubectl-binary-with-curl-on-windows) - [Install on Windows using Chocolatey or Scoop](#install-on-windows-using-chocolatey-or-scoop) -- [Install on Windows as part of the Google Cloud SDK](#install-on-windows-as-part-of-the-google-cloud-sdk) ### Install kubectl binary with curl on Windows @@ -127,10 +126,6 @@ If you have installed Docker Desktop before, you may need to place your `PATH` e Edit the config file with a text editor of your choice, such as Notepad. {{< /note >}} -### Install on Windows as part of the Google Cloud SDK - -{{< include "included/install-kubectl-gcloud.md" >}} - ## Verify kubectl configuration {{< include "included/verify-kubectl.md" >}} @@ -147,4 +142,4 @@ Below are the procedures to set up autocompletion for Zsh, if you are running th ## {{% heading "whatsnext" %}} -{{< include "included/kubectl-whats-next.md" >}} \ No newline at end of file +{{< include "included/kubectl-whats-next.md" >}} From 97a453a505455f92a211e0dff490a70c99152c9a Mon Sep 17 00:00:00 2001 From: chenxuc Date: Wed, 26 May 2021 19:17:10 +0800 Subject: [PATCH 123/128] Update feature availability for dns-pod-service Removed the outdated availability section and add feature state shortcode. --- .../services-networking/dns-pod-service.md | 15 +++------------ 1 file changed, 3 insertions(+), 12 deletions(-) diff --git a/content/en/docs/concepts/services-networking/dns-pod-service.md b/content/en/docs/concepts/services-networking/dns-pod-service.md index 2888064c2e..bd5fdf99a6 100644 --- a/content/en/docs/concepts/services-networking/dns-pod-service.md +++ b/content/en/docs/concepts/services-networking/dns-pod-service.md @@ -7,6 +7,7 @@ content_type: concept weight: 20 --- + Kubernetes creates DNS records for services and pods. You can contact services with consistent DNS names instead of IP addresses. @@ -261,6 +262,8 @@ spec: ### Pod's DNS Config {#pod-dns-config} +{{< feature-state for_k8s_version="v1.14" state="stable" >}} + Pod's DNS Config allows users more control on the DNS settings for a Pod. The `dnsConfig` field is optional and it can work with any `dnsPolicy` settings. @@ -310,18 +313,6 @@ search default.svc.cluster-domain.example svc.cluster-domain.example cluster-dom options ndots:5 ``` -### Feature availability - -The availability of Pod DNS Config and DNS Policy "`None`" is shown as below. - -| k8s version | Feature support | -| :---------: |:-----------:| -| 1.14 | Stable | -| 1.10 | Beta (on by default)| -| 1.9 | Alpha | - - - ## {{% heading "whatsnext" %}} From 7bdab6f12113c3c07a10cab8fff8178fa10bc5a4 Mon Sep 17 00:00:00 2001 From: Tim Bannister Date: Sat, 12 Jun 2021 17:11:00 +0100 Subject: [PATCH 124/128] Improve getting started page (#28356) * Link to downloads from Getting Started * Improve Getting Started page --- content/en/docs/setup/_index.md | 34 ++++++++++++++++++++++++++++----- 1 file changed, 29 insertions(+), 5 deletions(-) diff --git a/content/en/docs/setup/_index.md b/content/en/docs/setup/_index.md index 59db384258..bb73375553 100644 --- a/content/en/docs/setup/_index.md +++ b/content/en/docs/setup/_index.md @@ -3,11 +3,11 @@ reviewers: - brendandburns - erictune - mikedanese -no_issue: true title: Getting started main_menu: true weight: 20 content_type: concept +no_list: true card: name: setup weight: 20 @@ -24,16 +24,40 @@ This section lists the different ways to set up and run Kubernetes. When you install Kubernetes, choose an installation type based on: ease of maintenance, security, control, available resources, and expertise required to operate and manage a cluster. -You can deploy a Kubernetes cluster on a local machine, cloud, on-prem datacenter, or choose a managed Kubernetes cluster. There are also custom solutions across a wide range of cloud providers, or bare metal environments. +You can [download Kubernetes](/releases/download/) to deploy a Kubernetes cluster +on a local machine, into the cloud, or for your own datacenter. + +If you don't want to manage a Kubernetes cluster yourself, you could pick a managed service, including +[certified platforms](/docs/setup/production-environment/turnkey-solutions/). +There are also other standardized and custom solutions across a wide range of cloud and +bare metal environments. ## Learning environment -If you're learning Kubernetes, use the tools supported by the Kubernetes community, or tools in the ecosystem to set up a Kubernetes cluster on a local machine. +If you're learning Kubernetes, use the tools supported by the Kubernetes community, +or tools in the ecosystem to set up a Kubernetes cluster on a local machine. +See [Install tools](/docs/tasks/tools/). ## Production environment -When evaluating a solution for a production environment, consider which aspects of operating a Kubernetes cluster (or _abstractions_) you want to manage yourself or offload to a provider. +When evaluating a solution for a +[production environment](/docs/setup/production-environment/), consider which aspects of +operating a Kubernetes cluster (or _abstractions_) you want to manage yourself and which you +prefer to hand off to a provider. -[Kubernetes Partners](https://kubernetes.io/partners/#conformance) includes a list of [Certified Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes) providers. +For a cluster you're managing yourself, the officially supported tool +for deploying Kubernetes is [kubeadm](/docs/setup/production-environment/tools/kubeadm/). + +## {{% heading "whatsnext" %}} + +- [Download Kubernetes](/releases/download/) +- Download and [install tools](/docs/tasks/tools/) including `kubectl` +- Select a [container runtime](/docs/setup/production-environment/container-runtimes/) for your new cluster +- Learn about [best practices](/docs/setup/best-practices/) for cluster setup + +Kubernetes is designed for its {{< glossary_tooltip term_id="control-plane" text="control plane" >}} to +run on Linux. Within your cluster you can run applications on Linux or other operating systems, including +Windows. +- Learn to [set up clusters with Windows nodes](/docs/setup/production-environment/windows/) From c03963607aaff9c2ae25b6c5a31d80606ef5b965 Mon Sep 17 00:00:00 2001 From: Emanuel Haine Date: Sat, 12 Jun 2021 17:31:35 -0300 Subject: [PATCH 125/128] [spelling corrections] content/pt/docs/concepts/storage/persistent-volumes.md #26806 --- content/pt/docs/concepts/storage/persistent-volumes.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/pt/docs/concepts/storage/persistent-volumes.md b/content/pt/docs/concepts/storage/persistent-volumes.md index 8e952c607a..65396a3c37 100644 --- a/content/pt/docs/concepts/storage/persistent-volumes.md +++ b/content/pt/docs/concepts/storage/persistent-volumes.md @@ -24,7 +24,7 @@ Esse documento descreve o estado atual dos _volumes persistentes_ no Kubernetes. ## Introdução -O gerenciamento de armazenamento é uma questão bem diferente do gerenciamento de instâncias computacionais. O subsistema PersistentVolume provê uma API para usuários e administradores que mostra de forma detalhada de como o armazenamento é provido e como ele é consumido. Para isso, nós introduzidmos duas novas APIs: PersistentVolume e PersistentVolumeClaim. +O gerenciamento de armazenamento é uma questão bem diferente do gerenciamento de instâncias computacionais. O subsistema PersistentVolume provê uma API para usuários e administradores que mostra de forma detalhada de como o armazenamento é provido e como ele é consumido. Para isso, nós introduzimos duas novas APIs: PersistentVolume e PersistentVolumeClaim. Um _PersistentVolume_ (PV) é uma parte do armazenamento dentro do cluster que tenha sido provisionada por um administrador, ou dinamicamente utilizando [Classes de Armazenamento](/docs/concepts/storage/storage-classes/). Isso é um recurso dentro do cluster da mesma forma que um nó também é. PVs são plugins de volume da mesma forma que Volumes, porém eles têm um ciclo de vida independente de qualquer Pod que utilize um PV. Essa API tem por objetivo mostrar os detalhes da implementação do armazenamento, seja ele NFS, iSCSI, ou um armazenamento específico de um provedor de cloud pública. @@ -44,7 +44,7 @@ Existem duas formas de provisionar um PV: estaticamente ou dinamicamente. #### Estático -O administrador do cluster cria uma determinada quantidade de PVs. Eles possuem todos os detalhes do armazenamento a qual estão atrelados, que neste caso fica disponível para utilização por um usuário dentro do cluster. Eles estão presentes na API do Kubernetes e disponíveis para utilização. +O administrador do cluster cria uma determinada quantidade de PVs. Eles possuem todos os detalhes do armazenamento os quais estão atrelados, que neste caso fica disponível para utilização por um usuário dentro do cluster. Eles estão presentes na API do Kubernetes e disponíveis para utilização. #### Dinâmico @@ -118,7 +118,7 @@ Quando um usuário não precisar mais utilizar um volume, ele pode deletar a PVC #### Retenção -A política `Retain` permite a recuperação de forma manual do recurso. Quando a PersistentVolumeClaim é deletada, ela continua existindo e o volume é considerado "livre". Mas ele ainda não está disponível para outra requisição porque os dados da requisição anterior ainda permanecem no volume. Um administrador pode manuamente recuperar o volume executando os seguintes passos: +A política `Retain` permite a recuperação de forma manual do recurso. Quando a PersistentVolumeClaim é deletada, ela continua existindo e o volume é considerado "livre". Mas ele ainda não está disponível para outra requisição porque os dados da requisição anterior ainda permanecem no volume. Um administrador pode manualmente recuperar o volume executando os seguintes passos: 1. Deletar o PersistentVolume. O armazenamento associado à infraestrutura externa (AWS EBS, GCE PD, Azure Disk ou Cinder volume) ainda continuará existindo após o PV ser deletado. @@ -456,7 +456,7 @@ Um PV pode especificar uma [afinidade de nó](/docs/reference/generated/kubernet ### Estado -Um volume sempre estará em dos seguintes estados: +Um volume sempre estará em um dos seguintes estados: * Available -- um recurso que está livre e ainda não foi atrelado a nenhuma requisição * Bound -- um volume atrelado a uma requisição From 733218709196ddced2c06b66d6cda1edd106a346 Mon Sep 17 00:00:00 2001 From: Arhell Date: Sun, 13 Jun 2021 12:06:12 +0300 Subject: [PATCH 126/128] [zh] fix typo node-resource-managers.md --- content/zh/docs/concepts/policy/node-resource-managers.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/zh/docs/concepts/policy/node-resource-managers.md b/content/zh/docs/concepts/policy/node-resource-managers.md index 0651a66f73..73f28da383 100644 --- a/content/zh/docs/concepts/policy/node-resource-managers.md +++ b/content/zh/docs/concepts/policy/node-resource-managers.md @@ -38,7 +38,7 @@ The configuration of individual managers is elaborated in dedicated documents: - [CPU 管理器策略](/zh/docs/tasks/administer-cluster/cpu-management-policies/) - [设备管理器](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-integration-with-the-topology-manager) From ea83fa8ec4727786e6c1bff59967afc920cd6211 Mon Sep 17 00:00:00 2001 From: Arhell Date: Mon, 14 Jun 2021 00:34:22 +0300 Subject: [PATCH 127/128] [zh] update release status --- .../docs/reference/access-authn-authz/admission-controllers.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/zh/docs/reference/access-authn-authz/admission-controllers.md b/content/zh/docs/reference/access-authn-authz/admission-controllers.md index 80d1256504..d7d612af16 100644 --- a/content/zh/docs/reference/access-authn-authz/admission-controllers.md +++ b/content/zh/docs/reference/access-authn-authz/admission-controllers.md @@ -1351,7 +1351,7 @@ PVC/PV 不会被删除。 ### TaintNodesByCondition {#taintnodesbycondition} -{{< feature-state for_k8s_version="v1.12" state="beta" >}} +{{< feature-state for_k8s_version="v1.17" state="stable" >}} -## 容器的特权模式 {#rivileged-mode-for-containers} +## 容器的特权模式 {#privileged-mode-for-containers} Pod 中的任何容器都可以使用容器规约中的 [安全性上下文](/zh/docs/tasks/configure-pod-container/security-context/)中的