From 5d7141f9034a846f83fb4a1af1244460ebd410dc Mon Sep 17 00:00:00 2001 From: ixodie Date: Mon, 6 Dec 2021 06:53:02 -0500 Subject: [PATCH 01/32] Kind cleanup - Remove Contiv This domain/URL has no relevant content, is a squatter. Video link on youtube is 5 years old. Product seems to be abandonware. --- content/en/docs/concepts/cluster-administration/networking.md | 4 ---- 1 file changed, 4 deletions(-) diff --git a/content/en/docs/concepts/cluster-administration/networking.md b/content/en/docs/concepts/cluster-administration/networking.md index 2b5c398a46..f3cf77507d 100644 --- a/content/en/docs/concepts/cluster-administration/networking.md +++ b/content/en/docs/concepts/cluster-administration/networking.md @@ -143,10 +143,6 @@ network complexity required to deploy Kubernetes at scale within AWS. [Coil](https://github.com/cybozu-go/coil) is a CNI plugin designed for ease of integration, providing flexible egress networking. Coil operates with a low overhead compared to bare metal, and allows you to define arbitrary egress NAT gateways for external networks. -### Contiv - -[Contiv](https://github.com/contiv/netplugin) provides configurable networking (native l3 using BGP, overlay using vxlan, classic l2, or Cisco-SDN/ACI) for various use cases. - ### Contrail / Tungsten Fabric [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), based on [Tungsten Fabric](https://tungsten.io), is a truly open, multi-cloud network virtualization and policy management platform. Contrail and Tungsten Fabric are integrated with various orchestration systems such as Kubernetes, OpenShift, OpenStack and Mesos, and provide different isolation modes for virtual machines, containers/pods and bare metal workloads. From a599614861188b7dd91d39aba362e1f91979eb25 Mon Sep 17 00:00:00 2001 From: Tim Bannister Date: Wed, 8 Dec 2021 00:42:18 +0000 Subject: [PATCH 02/32] Add sftim as a blog editor --- OWNERS_ALIASES | 1 + 1 file changed, 1 insertion(+) diff --git a/OWNERS_ALIASES b/OWNERS_ALIASES index 9763b65c88..cf898838de 100644 --- a/OWNERS_ALIASES +++ b/OWNERS_ALIASES @@ -2,6 +2,7 @@ aliases: sig-docs-blog-owners: # Approvers for blog content - onlydole - mrbobbytables + - sftim sig-docs-blog-reviewers: # Reviewers for blog content - mrbobbytables - onlydole From 5fee22b57496fa58ca16f978d12a4a76ab30fa7e Mon Sep 17 00:00:00 2001 From: Shivam Singhal Date: Sat, 18 Dec 2021 12:25:34 +0200 Subject: [PATCH 03/32] Fix the link to access cluster service in docs --- .../en/docs/tasks/access-application-cluster/access-cluster.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/tasks/access-application-cluster/access-cluster.md b/content/en/docs/tasks/access-application-cluster/access-cluster.md index 9f56a409f4..aad72d9dae 100644 --- a/content/en/docs/tasks/access-application-cluster/access-cluster.md +++ b/content/en/docs/tasks/access-application-cluster/access-cluster.md @@ -214,7 +214,7 @@ In each case, the credentials of the pod are used to communicate securely with t ## Accessing services running on the cluster -The previous section describes how to connect to the Kubernetes API server. For information about connecting to other services running on a Kubernetes cluster, see [Access Cluster Services.](/docs/tasks/access-application-cluster/access-cluster/) +The previous section describes how to connect to the Kubernetes API server. For information about connecting to other services running on a Kubernetes cluster, see [Access Cluster Services.](/docs/tasks/administer-cluster/access-cluster-services/) ## Requesting redirects From 7a2863b99ad1c3a081d468f3e3d23e771a6ef6d9 Mon Sep 17 00:00:00 2001 From: Shivam Singhal Date: Wed, 22 Dec 2021 00:47:22 +0200 Subject: [PATCH 04/32] Cleanup notes in Define a Command and Arguments docs --- .../define-command-argument-container.md | 44 +------------------ 1 file changed, 1 insertion(+), 43 deletions(-) diff --git a/content/en/docs/tasks/inject-data-application/define-command-argument-container.md b/content/en/docs/tasks/inject-data-application/define-command-argument-container.md index faaffc52a2..0de57b864f 100644 --- a/content/en/docs/tasks/inject-data-application/define-command-argument-container.md +++ b/content/en/docs/tasks/inject-data-application/define-command-argument-container.md @@ -36,8 +36,7 @@ If you define args, but do not define a command, the default command is used with your new arguments. {{< note >}} -The `command` field corresponds to `entrypoint` in some container -runtimes. Refer to the [Notes](#notes) below. +The `command` field corresponds to `entrypoint` in some container runtimes. {{< /note >}} In this exercise, you create a Pod that runs one container. The configuration @@ -111,50 +110,9 @@ command: ["/bin/sh"] args: ["-c", "while true; do echo hello; sleep 10;done"] ``` -## Notes - -This table summarizes the field names used by Docker and Kubernetes. - -| Description | Docker field name | Kubernetes field name | -|----------------------------------------|------------------------|-----------------------| -| The command run by the container | Entrypoint | command | -| The arguments passed to the command | Cmd | args | - -When you override the default Entrypoint and Cmd, these rules apply: - -* If you do not supply `command` or `args` for a Container, the defaults defined -in the Docker image are used. - -* If you supply a `command` but no `args` for a Container, only the supplied -`command` is used. The default EntryPoint and the default Cmd defined in the Docker -image are ignored. - -* If you supply only `args` for a Container, the default Entrypoint defined in -the Docker image is run with the `args` that you supplied. - -* If you supply a `command` and `args`, the default Entrypoint and the default -Cmd defined in the Docker image are ignored. Your `command` is run with your -`args`. - -Here are some examples: - -| Image Entrypoint | Image Cmd | Container command | Container args | Command run | -|--------------------|------------------|---------------------|--------------------|------------------| -| `[/ep-1]` | `[foo bar]` | <not set> | <not set> | `[ep-1 foo bar]` | -| `[/ep-1]` | `[foo bar]` | `[/ep-2]` | <not set> | `[ep-2]` | -| `[/ep-1]` | `[foo bar]` | <not set> | `[zoo boo]` | `[ep-1 zoo boo]` | -| `[/ep-1]` | `[foo bar]` | `[/ep-2]` | `[zoo boo]` | `[ep-2 zoo boo]` | - - - - ## {{% heading "whatsnext" %}} * Learn more about [configuring pods and containers](/docs/tasks/). * Learn more about [running commands in a container](/docs/tasks/debug-application-cluster/get-shell-running-container/). * See [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core). - - - - From c7b9b20083aa24c2140fa00e0a8068ab7b782634 Mon Sep 17 00:00:00 2001 From: kartik494 Date: Wed, 10 Nov 2021 18:22:25 +0530 Subject: [PATCH 05/32] Added a note for CRD improvement in Docs --- content/en/docs/concepts/storage/volume-snapshot-classes.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/content/en/docs/concepts/storage/volume-snapshot-classes.md b/content/en/docs/concepts/storage/volume-snapshot-classes.md index ee781d665f..d81b895194 100644 --- a/content/en/docs/concepts/storage/volume-snapshot-classes.md +++ b/content/en/docs/concepts/storage/volume-snapshot-classes.md @@ -39,6 +39,10 @@ request a particular class. Administrators set the name and other parameters of a class when first creating VolumeSnapshotClass objects, and the objects cannot be updated once they are created. +{{< note >}} +Installation of the CRDs is the responsibility of the Kubernetes distribution. Without the required CRDs present, the creation of a VolumeSnapshotClass fails. +{{< /note >}} + ```yaml apiVersion: snapshot.storage.k8s.io/v1 kind: VolumeSnapshotClass From f424739d9c18d6eba4f8cd2a0c15a76a598e211b Mon Sep 17 00:00:00 2001 From: Alex McCarthy <19922103+CodingCanuck@users.noreply.github.com> Date: Fri, 31 Dec 2021 07:06:04 -1000 Subject: [PATCH 06/32] Fix grammar in kubernetes dashboard docs Start a new sentence after a period. --- .../docs/tasks/access-application-cluster/web-ui-dashboard.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md index e13b6e075a..79015b0209 100644 --- a/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md +++ b/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md @@ -219,7 +219,7 @@ allocated resources, events and pods running on the node. Shows all applications running in the selected namespace. The view lists applications by workload kind (for example: Deployments, ReplicaSets, StatefulSets). -and each workload kind can be viewed separately. +Each workload kind can be viewed separately. The lists summarize actionable information about the workloads, such as the number of ready pods for a ReplicaSet or current memory usage for a Pod. From b9da040a08373cf764f4e93df32df182bbd8a835 Mon Sep 17 00:00:00 2001 From: afirth Date: Wed, 3 Nov 2021 16:14:32 +0100 Subject: [PATCH 07/32] Document the environment variable substitution feature of configMapGenerator --- .../manage-kubernetes-objects/kustomization.md | 15 ++++++++++++--- 1 file changed, 12 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 6ef2a87f07..f391b37e09 100644 --- a/content/en/docs/tasks/manage-kubernetes-objects/kustomization.md +++ b/content/en/docs/tasks/manage-kubernetes-objects/kustomization.md @@ -86,12 +86,20 @@ metadata: name: example-configmap-1-8mbdf7882g ``` -To generate a ConfigMap from an env file, add an entry to the `envs` list in `configMapGenerator`. Here is an example of generating a ConfigMap with a data item from a `.env` file: +To generate a ConfigMap from an env file, add an entry to the `envs` list in `configMapGenerator`. This can also be used to set values from local environment variables by omitting the `=` and the value. + +{{< note >}} +It's recommended to use the local environment variable population functionality sparingly - an overlay with a patch is often more maintainable. Setting values from the environment may be useful when they cannot easily be predicted, such as a git SHA. +{{< /note >}} + +Here is an example of generating a ConfigMap with a data item from a `.env` file: ```shell # Create a .env file +# BAZ will be populated from the local environment variable $BAZ cat <.env FOO=Bar +BAZ EOF cat <./kustomization.yaml @@ -105,7 +113,7 @@ EOF The generated ConfigMap can be examined with the following command: ```shell -kubectl kustomize ./ +BAZ=Qux kubectl kustomize ./ ``` The generated ConfigMap is: @@ -113,10 +121,11 @@ The generated ConfigMap is: ```yaml apiVersion: v1 data: + BAZ: Qux FOO: Bar kind: ConfigMap metadata: - name: example-configmap-1-42cfbf598f + name: example-configmap-1-892ghb99c8 ``` {{< note >}} From 4c0612d6055736ec49f28b4be237e4ef5581b138 Mon Sep 17 00:00:00 2001 From: Tim Bannister Date: Mon, 3 Jan 2022 15:44:06 +0000 Subject: [PATCH 08/32] Fix case for tables in patch releases list (aside: if we did want these all-uppercase, I'd be tempted to apply that style using CSS / Sass) --- content/en/releases/patch-releases.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/content/en/releases/patch-releases.md b/content/en/releases/patch-releases.md index 3b058deb48..f241692009 100644 --- a/content/en/releases/patch-releases.md +++ b/content/en/releases/patch-releases.md @@ -90,7 +90,7 @@ releases may also occur in between these. End of Life for **1.23** is **2023-02-28**. -| PATCH RELEASE | CHERRY PICK DEADLINE | TARGET DATE | NOTE | +| Patch Release | Cherry Pick Deadline | Target Date | Note | |---------------|----------------------|-------------|------| | 1.23.2 | 2022-01-14 | 2022-01-19 | | | 1.23.1 | 2021-12-14 | 2021-12-16 | | @@ -101,7 +101,7 @@ End of Life for **1.23** is **2023-02-28**. End of Life for **1.22** is **2022-10-28** -| PATCH RELEASE | CHERRY PICK DEADLINE | TARGET DATE | NOTE | +| Patch Release | Cherry Pick Deadline | Target Date | Note | |---------------|----------------------|-------------|------| | 1.22.6 | 2022-01-14 | 2022-01-19 | | | 1.22.5 | 2021-12-10 | 2021-12-15 | | @@ -116,7 +116,7 @@ End of Life for **1.22** is **2022-10-28** End of Life for **1.21** is **2022-06-28** -| PATCH RELEASE | CHERRY PICK DEADLINE | TARGET DATE | NOTE | +| Patch Release | Cherry Pick Deadline | Target Date | Note | | ------------- | -------------------- | ----------- | ---------------------------------------------------------------------- | | 1.21.9 | 2022-01-14 | 2022-01-19 | | | 1.21.8 | 2021-12-10 | 2021-12-15 | | @@ -134,7 +134,7 @@ 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 | NOTE | +| Patch Release | Cherry Pick Deadline | Target Date | Note | | ------------- | -------------------- | ----------- | ----------------------------------------------------------------------------------- | | 1.20.15 | 2022-01-14 | 2022-01-19 | | | 1.20.14 | 2021-12-10 | 2021-12-15 | | @@ -157,7 +157,7 @@ End of Life for **1.20** is **2022-02-28** These releases are no longer supported. -| MINOR VERSION | FINAL PATCH RELEASE | EOL DATE | NOTE | +| Minor Version | Final Patch Release | EOL Date | Note | | ------------- | ------------------- | ---------- | ---------------------------------------------------------------------- | | 1.19 | 1.19.16 | 2021-10-28 | | | 1.18 | 1.18.20 | 2021-06-18 | Created to resolve regression introduced in 1.18.19 | From 90970b7b73b7d2cd07105f1687f815d4081218de Mon Sep 17 00:00:00 2001 From: Alex McCarthy <19922103+CodingCanuck@users.noreply.github.com> Date: Mon, 3 Jan 2022 07:17:52 -1000 Subject: [PATCH 09/32] Fix kind delete cluster commands The name flag requires two leading dashes, not one. --- content/en/docs/tutorials/security/cluster-level-pss.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/en/docs/tutorials/security/cluster-level-pss.md b/content/en/docs/tutorials/security/cluster-level-pss.md index e2d37b765a..42244750ca 100644 --- a/content/en/docs/tutorials/security/cluster-level-pss.md +++ b/content/en/docs/tutorials/security/cluster-level-pss.md @@ -304,8 +304,8 @@ following: ## Clean up -Run `kind delete cluster -name psa-with-cluster-pss` and -`kind delete cluster -name psa-wo-cluster-pss` to delete the clusters you +Run `kind delete cluster --name psa-with-cluster-pss` and +`kind delete cluster --name psa-wo-cluster-pss` to delete the clusters you created. ## {{% heading "whatsnext" %}} From b2dadde6bf61d47e9da75dff92f50d37e068d547 Mon Sep 17 00:00:00 2001 From: Arhell Date: Tue, 4 Jan 2022 00:21:52 +0200 Subject: [PATCH 10/32] [it] remove Open vSwitch --- .../it/docs/concepts/cluster-administration/networking.md | 6 ------ 1 file changed, 6 deletions(-) diff --git a/content/it/docs/concepts/cluster-administration/networking.md b/content/it/docs/concepts/cluster-administration/networking.md index 4c83d201e0..af99f91735 100644 --- a/content/it/docs/concepts/cluster-administration/networking.md +++ b/content/it/docs/concepts/cluster-administration/networking.md @@ -292,12 +292,6 @@ Nuage è stato progettato pensando alle applicazioni e semplifica la dichiarazio applicazioni. Il motore di analisi in tempo reale della piattaforma consente la visibilità e il monitoraggio della sicurezza per le applicazioni Kubernetes. -### OpenVSwitch - -[OpenVSwitch](https://www.openvswitch.org/) è un po 'più maturo ma anche -modo complicato per costruire una rete di sovrapposizione. Questo è approvato da molti dei -"Grandi negozi" per il networking. - ### OVN (Apri rete virtuale) OVN è una soluzione di virtualizzazione della rete opensource sviluppata da From 60824acdd276d396bffa064fa253c365079ffada Mon Sep 17 00:00:00 2001 From: Peri Thompson Date: Tue, 4 Jan 2022 09:40:47 +0000 Subject: [PATCH 11/32] Update windows pause image Signed-off-by: Peri Thompson --- .../docs/reference/command-line-tools-reference/kubelet.md | 2 +- .../windows/intro-windows-in-kubernetes.md | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/content/en/docs/reference/command-line-tools-reference/kubelet.md b/content/en/docs/reference/command-line-tools-reference/kubelet.md index 75698b3966..ac54718b01 100644 --- a/content/en/docs/reference/command-line-tools-reference/kubelet.md +++ b/content/en/docs/reference/command-line-tools-reference/kubelet.md @@ -916,7 +916,7 @@ WindowsHostProcessContainers=true|false (ALPHA - default=false)
---pod-infra-container-image string     Default: k8s.gcr.io/pause:3.5 +--pod-infra-container-image string     Default: k8s.gcr.io/pause:3.6 Specified image will not be pruned by the image garbage collector. When container-runtime is set to docker, all containers in each pod will use the network/IPC namespaces from this image. Other CRI implementations have their own configuration to set this image. diff --git a/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md b/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md index 89546dc58d..659aa95af8 100644 --- a/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md +++ b/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md @@ -775,9 +775,9 @@ SIG Windows [contributing guide on gathering logs](https://github.com/kubernetes nssm start flanneld # Register kubelet.exe - # Microsoft releases the pause infrastructure container at mcr.microsoft.com/oss/kubernetes/pause:1.4.1 + # Microsoft releases the pause infrastructure container at mcr.microsoft.com/oss/kubernetes/pause:3.6 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 AppParameters --hostname-override= --v=6 --pod-infra-container-image=mcr.microsoft.com/oss/kubernetes/pause:3.6 --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 @@ -923,7 +923,7 @@ SIG Windows [contributing guide on gathering logs](https://github.com/kubernetes 1. `kubectl port-forward` fails with "unable to do port forwarding: wincat not found" - This was implemented in Kubernetes 1.15 by including `wincat.exe` in the pause infrastructure container `mcr.microsoft.com/oss/kubernetes/pause:1.4.1`. Be sure to use a supported version of Kubernetes. + This was implemented in Kubernetes 1.15 by including `wincat.exe` in the pause infrastructure container `mcr.microsoft.com/oss/kubernetes/pause:3.6`. Be sure to use a supported version of Kubernetes. If you would like to build your own pause infrastructure container be sure to include [wincat](https://github.com/kubernetes/kubernetes/tree/master/build/pause/windows/wincat). 1. My Kubernetes installation is failing because my Windows Server node is behind a proxy From 02d19b7fa924735d85570f807cd0d2ab7661f5b2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E5=B8=85=E8=BF=9B=E8=B6=85?= Date: Wed, 5 Jan 2022 00:09:31 +0800 Subject: [PATCH 12/32] [zh] synchronize translate system-traces.md --- .../docs/concepts/cluster-administration/system-traces.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/content/zh/docs/concepts/cluster-administration/system-traces.md b/content/zh/docs/concepts/cluster-administration/system-traces.md index c829341afd..9916b403b0 100644 --- a/content/zh/docs/concepts/cluster-administration/system-traces.md +++ b/content/zh/docs/concepts/cluster-administration/system-traces.md @@ -119,7 +119,7 @@ spans for 1 in 10000 requests, and uses the default OpenTelemetry endpoint: 下面是一个示例配置，它为万分之一的请求记录 spans，并使用了默认的 OpenTelemetry 端口。 ```yaml -apiVersion: apiserver.config.k8s.io/v1alpha1 +apiVersion: apiserver.config.k8s.io/v1beta1 kind: TracingConfiguration # default value #endpoint: localhost:4317 @@ -128,10 +128,11 @@ samplingRatePerMillion: 100 + 有关 TracingConfiguration 结构体的更多信息，请参阅 -[API 服务器配置 API (v1alpha1)](/docs/reference/config-api/apiserver-config.v1alpha1/#apiserver-k8s-io-v1alpha1-TracingConfiguration)。 +[API 服务器配置 API (v1beta1)](/docs/reference/config-api/apiserver-config.v1beta1/#apiserver-k8s-io-v1beta1-TracingConfiguration)。 @@ -66,10 +66,8 @@ It is implemented as an extension API server and a controller, using etcd for st 与服务代理进行通信，并作为 Kubernetes API 服务器的中介，以便协商启动部署和获取 应用程序使用托管服务时必须的凭据。 -服务目录实现为一个扩展 API 服务器和一个控制器，使用 Etcd 提供存储。 -它还使用了 Kubernetes 1.7 之后版本中提供的 -[聚合层](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) -来呈现其 API。 +它是[基于 CRDs](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/#custom-resources) +架构实现的。 ![服务目录架构](/images/docs/service-catalog-architecture.svg) From 6be193b4de480686175aabbc1f643f2cf52cbac4 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Wed, 5 Jan 2022 13:42:32 +0800 Subject: [PATCH 19/32] Tune config API links We favor links to generated docs targetting non-developer audiences over golang specifics. --- .../tools/kubeadm/dual-stack-support.md | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/dual-stack-support.md b/content/en/docs/setup/production-environment/tools/kubeadm/dual-stack-support.md index ffd5839c23..9a448caed5 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/dual-stack-support.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/dual-stack-support.md @@ -43,7 +43,9 @@ similar to the following example: kubeadm init --pod-network-cidr=10.244.0.0/16,2001:db8:42:0::/56 --service-cidr=10.96.0.0/16,2001:db8:42:1::/112 ``` -To make things clearer, here is an example kubeadm [configuration file](https://pkg.go.dev/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3) `kubeadm-config.yaml` for the primary dual-stack control plane node. +To make things clearer, here is an example kubeadm +[configuration file](/docs/reference/config-api/kubeadm-config.v1beta3/) +`kubeadm-config.yaml` for the primary dual-stack control plane node. ```yaml --- @@ -81,7 +83,8 @@ The `--apiserver-advertise-address` flag does not support dual-stack. Before joining a node, make sure that the node has IPv6 routable network interface and allows IPv6 forwarding. -Here is an example kubeadm [configuration file](https://pkg.go.dev/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3) `kubeadm-config.yaml` for joining a worker node to the cluster. +Here is an example kubeadm [configuration file](/docs/reference/config-api/kubeadm-config.v1beta3/) +`kubeadm-config.yaml` for joining a worker node to the cluster. ```yaml apiVersion: kubeadm.k8s.io/v1beta3 @@ -98,7 +101,9 @@ nodeRegistration: node-ip: 10.100.0.3,fd00:1:2:3::3 ``` -Also, here is an example kubeadm [configuration file](https://pkg.go.dev/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3) `kubeadm-config.yaml` for joining another control plane node to the cluster. +Also, here is an example kubeadm [configuration file](/docs/reference/config-api/kubeadm-config.v1beta3/) +`kubeadm-config.yaml` for joining another control plane node to the cluster. + ```yaml apiVersion: kubeadm.k8s.io/v1beta3 kind: JoinConfiguration @@ -132,7 +137,9 @@ Dual-stack support doesn't mean that you need to use dual-stack addressing. You can deploy a single-stack cluster that has the dual-stack networking feature enabled. {{< /note >}} -To make things more clear, here is an example kubeadm [configuration file](https://pkg.go.dev/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3) `kubeadm-config.yaml` for the single-stack control plane node. +To make things more clear, here is an example kubeadm +[configuration file](/docs/reference/config-api/kubeadm-config.v1beta3/) +`kubeadm-config.yaml` for the single-stack control plane node. ```yaml apiVersion: kubeadm.k8s.io/v1beta3 From d2816748221ef5b2e15cd2fadaaafdd494965084 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E5=B8=85=E8=BF=9B=E8=B6=85?= Date: Tue, 4 Jan 2022 23:38:52 +0800 Subject: [PATCH 20/32] [zh] synchronize translate operator.md --- .../zh/docs/concepts/extend-kubernetes/operator.md | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/content/zh/docs/concepts/extend-kubernetes/operator.md b/content/zh/docs/concepts/extend-kubernetes/operator.md index e2153ea594..4812a272bd 100644 --- a/content/zh/docs/concepts/extend-kubernetes/operator.md +++ b/content/zh/docs/concepts/extend-kubernetes/operator.md @@ -54,9 +54,7 @@ built-in automation from the core of Kubernetes. You can use Kubernetes to automate deploying and running workloads, *and* you can automate how Kubernetes does that. -Kubernetes' {{< glossary_tooltip text="controllers" term_id="controller" >}} -concept lets you extend the cluster's behaviour without modifying the code -of Kubernetes itself. +Kubernetes' {{< glossary_tooltip text="operator pattern" term_id="operator-pattern" >}} concept lets you extend the cluster's behaviour without modifying the code of Kubernetes itself by linking {{< glossary_tooltip text="controllers" term_id="controller" >}} to one or more custom resources. Operators are clients of the Kubernetes API that act as controllers for a [Custom Resource](/docs/concepts/extend-kubernetes/api-extension/custom-resources/). --> @@ -65,10 +63,11 @@ a [Custom Resource](/docs/concepts/extend-kubernetes/api-extension/custom-resour Kubernetes 为自动化而生。无需任何修改，你即可以从 Kubernetes 核心中获得许多内置的自动化功能。 你可以使用 Kubernetes 自动化部署和运行工作负载， *甚至* 可以自动化 Kubernetes 自身。 -Kubernetes 的 {{< glossary_tooltip text="Operator 模式" term_id="operator-pattern" >}}概念 -使你无需修改 Kubernetes 自身的代码，通过把定制控制器关联到一个以上的定制资源上，即可以扩展集群的行为。 +Kubernetes 的 {{< glossary_tooltip text="Operator 模式" term_id="operator-pattern" >}}概念允许你在不修改 +Kubernetes 自身代码的情况下，通过为一个或多个自定义资源关联{{< glossary_tooltip text="控制器" term_id="controller" >}} +来扩展集群的能力。 Operator 是 Kubernetes API 的客户端，充当 -[定制资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/) +[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/) 的控制器。 ## 访问集群上运行的服务 {#accessing-services-running-on-the-cluster} From 24ee2527d0ddc9c91782b9487bf5904e470f1287 Mon Sep 17 00:00:00 2001 From: Neha Viswanathan <12013126+neha-viswanathan@users.noreply.github.com> Date: Wed, 5 Jan 2022 08:08:41 -0800 Subject: [PATCH 22/32] migrate the K8s networking model section (#28617) --- .../cluster-administration/networking.md | 50 +------------------ .../concepts/services-networking/_index.md | 48 ++++++++++++++++-- 2 files changed, 46 insertions(+), 52 deletions(-) diff --git a/content/en/docs/concepts/cluster-administration/networking.md b/content/en/docs/concepts/cluster-administration/networking.md index fb34a82d50..ee7793d004 100644 --- a/content/en/docs/concepts/cluster-administration/networking.md +++ b/content/en/docs/concepts/cluster-administration/networking.md @@ -30,55 +30,7 @@ insert dynamic port numbers into configuration blocks, services have to know how to find each other, etc. Rather than deal with this, Kubernetes takes a different approach. -## The Kubernetes network model - -Every `Pod` gets its own IP address, maximum one per IP family. This means you -do not need need to deal with mapping container ports to host ports in order to -expose the `Pods` services on the network. This creates a clean, -backwards-compatible model where `Pods` can be treated much like VMs or physical -hosts from the perspectives of port allocation, naming, service discovery, load -balancing, application configuration, and migration. - -Kubernetes IP addresses exist at the `Pod` scope, in the `status.PodIPs` field -- containers within a `Pod` share their network namespaces - including their IP -address. This means that containers within a `Pod` can all reach each other's -ports on `localhost`. This also means that containers within a `Pod` must -coordinate port usage, but this is no different from processes in a VM. This is -called the _IP-per-pod_ model. - -In every cluster, there exists an abstract pod-network to which pods -are connected by default, unless explicitly configured to use the -host-network (on platforms that support it). Even if a host has -multiple IPs, host-network pods only have one Kubernetes IP address at -the `Pod` scope, that is, the `status.PodIPs` field contains one -IP per address family (for now), so the "IP-per-pod" model is guaranteed. - -Kubernetes imposes the following fundamental requirements on any networking -implementation (barring any intentional network segmentation policies): - - * any pod-network pod on any node can communicate with all other pod-network - pods on all nodes without NAT. - * non-pod processes on a node (the kubelet, and also for example any other system daemon) can - communicate with all pods on that node. - -In addition, for platforms and runtimes that support running pods in the host OS network: - - * host-network pods of a node can connect directly with all pods IPs on all - nodes, however, unlike pod-network pods, the source IP address might not be - present in the `Pod` `status.PodIPs` field. - -This model is principally compatible with the desire for Kubernetes to enable -low-friction porting of apps from VMs to containers. If your workload previously ran -in a VM, your VM typically had a single IP address; everything in that VM could talk to -other VMs on your network. -This is the same basic model but less complex overall. - -How this is implemented is a detail of the particular container runtime in use. Likewise, the networking option you choose may support [dual-stack IPv4/IPv6 networking](/docs/concepts/services-networking/dual-stack/); implementations vary. - -It is possible to request ports on the `Node` itself which forward to your `Pod` -(called host ports), but this is a very niche operation. How that forwarding is -implemented is also a detail of the container runtime. The `Pod` itself is -blind to the existence or non-existence of host ports. +To learn about the Kubernetes networking model, see [here](/docs/concepts/services-networking/). ## How to implement the Kubernetes networking model diff --git a/content/en/docs/concepts/services-networking/_index.md b/content/en/docs/concepts/services-networking/_index.md index 2e7d91427e..ab1b784658 100644 --- a/content/en/docs/concepts/services-networking/_index.md +++ b/content/en/docs/concepts/services-networking/_index.md @@ -5,8 +5,50 @@ description: > Concepts and resources behind networking in Kubernetes. --- +## The Kubernetes network model + +Every [`Pod`](/docs/concepts/workloads/pods/) gets its own IP address. +This means you do not need to explicitly create links between `Pods` and you +almost never need to deal with mapping container ports to host ports. +This creates a clean, backwards-compatible model where `Pods` can be treated +much like VMs or physical hosts from the perspectives of port allocation, +naming, service discovery, [load balancing](/docs/concepts/services-networking/ingress/#load-balancing), application configuration, +and migration. + +Kubernetes imposes the following fundamental requirements on any networking +implementation (barring any intentional network segmentation policies): + + * pods on a [node](/docs/concepts/architecture/nodes/) can communicate with all pods on all nodes without NAT + * agents on a node (e.g. system daemons, kubelet) can communicate with all + pods on that node + +Note: For those platforms that support `Pods` running in the host network (e.g. +Linux): + + * pods in the host network of a node can communicate with all pods on all + nodes without NAT + +This model is not only less complex overall, but it is principally compatible +with the desire for Kubernetes to enable low-friction porting of apps from VMs +to containers. If your job previously ran in a VM, your VM had an IP and could +talk to other VMs in your project. This is the same basic model. + +Kubernetes IP addresses exist at the `Pod` scope - containers within a `Pod` +share their network namespaces - including their IP address and MAC address. +This means that containers within a `Pod` can all reach each other's ports on +`localhost`. This also means that containers within a `Pod` must coordinate port +usage, but this is no different from processes in a VM. This is called the +"IP-per-pod" model. + +How this is implemented is a detail of the particular container runtime in use. + +It is possible to request ports on the `Node` itself which forward to your `Pod` +(called host ports), but this is a very niche operation. How that forwarding is +implemented is also a detail of the container runtime. The `Pod` itself is +blind to the existence or non-existence of host ports. + Kubernetes networking addresses four concerns: -- Containers within a Pod use networking to communicate via loopback. +- Containers within a Pod [use networking to communicate](/docs/concepts/services-networking/dns-pod-service/) via loopback. - Cluster networking provides communication between different Pods. -- The Service resource lets you expose an application running in Pods to be reachable from outside your cluster. -- You can also use Services to publish services only for consumption inside your cluster. +- The [Service resource](/docs/concepts/services-networking/service/) lets you [expose an application running in Pods](/docs/concepts/services-networking/connect-applications-service/) to be reachable from outside your cluster. +- You can also use Services to [publish services only for consumption inside your cluster](/docs/concepts/services-networking/service-traffic-policy/). From 4207597a91ced2f5fa4950a7efc11f4a27d117b5 Mon Sep 17 00:00:00 2001 From: Sergey Kanzhelev Date: Thu, 6 Jan 2022 01:37:16 +0000 Subject: [PATCH 23/32] blog post draft: https://docs.google.com/document/d/160edAf2q3-FY8SFNCfEoSWcQ0Y7OUUy4hD7nc-b11n8/edit# --- .../index.md | 6 +- ...kubernetes-is-moving-on-from-dockershim.md | 99 +++++++++++++++++++ 2 files changed, 104 insertions(+), 1 deletion(-) create mode 100644 content/en/blog/_posts/2022-01-07-kubernetes-is-moving-on-from-dockershim.md diff --git a/content/en/blog/_posts/2021-11-12-are-you-ready-for-dockershim-removal/index.md b/content/en/blog/_posts/2021-11-12-are-you-ready-for-dockershim-removal/index.md index b372e7e7b4..6d0f1e9f83 100644 --- a/content/en/blog/_posts/2021-11-12-are-you-ready-for-dockershim-removal/index.md +++ b/content/en/blog/_posts/2021-11-12-are-you-ready-for-dockershim-removal/index.md @@ -5,6 +5,10 @@ date: 2021-11-12 slug: are-you-ready-for-dockershim-removal --- +{{< note >}} +This poll will close on January 7, 2022. +{{}} + **Author:** Sergey Kanzhelev, Google. With reviews from Davanum Srinivas, Elana Hashman, Noah Kantrowitz, Rey Lejano. Last year we announced that Dockershim is being deprecated: [Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/). @@ -25,7 +29,7 @@ are still not ready: [migrating telemetry and security agents](/docs/tasks/admin At this point, we believe that there is feature parity between Docker and the other runtimes. Many end-users have used our [migration guide](/docs/tasks/administer-cluster/migrating-from-dockershim/) and are running production workload using these different runtimes. The plan of -record today is that dockershim will be removed in version 1.24, slated for +record today is that dockershim will be removed in version 1.24, slated for release around April of next year. For those developing or running alpha and beta versions, dockershim will be removed in December at the beginning of the 1.24 release development cycle. diff --git a/content/en/blog/_posts/2022-01-07-kubernetes-is-moving-on-from-dockershim.md b/content/en/blog/_posts/2022-01-07-kubernetes-is-moving-on-from-dockershim.md new file mode 100644 index 0000000000..11fc82f947 --- /dev/null +++ b/content/en/blog/_posts/2022-01-07-kubernetes-is-moving-on-from-dockershim.md @@ -0,0 +1,99 @@ +--- +layout: blog +title: "Kubernetes is moving on from Dockershim: commitments and next steps" +date: 2022-01-07 +slug: kubernetes-is-moving-on-from-dockershim +--- + +**Authors:** Sergey Kanzhelev (Google), Jim Angel (Google), Davanum Srinivas (VMware), Shannon Kularathna (Google), Chris Short (AWS), Dawn Chen (Google) + +Kubernetes is removing dockershim in the upcoming v1.24 release. We're excited +to reaffirm our community values by supporting open source container runtimes, +enable a smaller kubelet, and increase engineering velocity for teams using +Kubernetes. If you [use Docker Engine as a Container Runtime](/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use/) +for your Kubernetes cluster, get ready to migrate to 1.24! To check if you're +affected, refer to [Check whether dockershim deprecation affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/). + +## Why we’re moving away from dockershim + +Docker was the first container runtime used by Kubernetes. This is one of the +reasons why Docker is so familiar to many Kubernetes users and enthusiasts. +As containerization became an industry standard, the Kubernetes project added support +for additional runtimes. This culminated with the implementation of the +container runtime interface (CRI), letting system components (like the kubelet) +talk to container runtimes in a standardized way. As a result, the hardcoded support for Docker – +a component the project refers to as dockershim – became an anomaly in the Kubernetes project. +Dependencies on Docker and dockershim have crept into various tools +and projects in the CNCF ecosystem ecosystem, resulting in fragile code. + +By removing the +dockershim CRI, we're embracing the first value of CNCF: "[Fast is better than +slow](https://github.com/cncf/foundation/blob/master/charter.md#3-values)". +Stay tuned for future communications on the topic! + +## Deprecation timeline + +We [formally announced](/blog/2020/12/08/kubernetes-1-20-release-announcement/) the dockershim deprecation in December 2020.  Full removal is targeted +in Kubernetes 1.24, in April 2022. This timeline +aligns with our [deprecation policy](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior), +which states that deprecated behaviors must function for at least 1 year +after their announced deprecation. + +We'll support Kubernetes version 1.23, which includes +dockershim, for another year in the Kubernetes project. Managed +Kubernetes providers, vendor support is likely to last even longer, but this is +dependent on the companies themselves. Regardless, we're confident all cluster operations will have +time to migrate. If you have more questions about the dockershim removal, refer +to the [Dockershim Deprecation FAQ](/dockershim). + +We asked you whether you feel prepared for the migration from dockershim in this +survey: [Are you ready for Dockershim removal](/blog/2021/11/12/are-you-ready-for-dockershim-removal/). +We had over 600 responses. To everybody who took time filling out the survey, +thank you. + +The results show that we still have a lot of ground to cover to help you to +migrate smoothly. Other container runtimes exist, and have been promoted +extensively. However, many users told us they still rely on dockershim, +and sometimes have dependencies that need to be re-worked. Some of these +dependencies are outside of your control. Based on the feedback received from +you, here are some of the steps we are taking to help. + +## Our next steps + +Based on the feedback you provided: + +- CNCF and the 1.24 release team are committed to delivering documentation in + time for the 1.24 release. This includes more informative blog posts like this + one, updating existing code samples, tutorials, and tasks, and producing a + migration guide for cluster operators. +- We are reaching out to the rest of the CNCF community to help prepare them for + this change. + +If you're part of a project with dependencies on dockershim, or if you're +interested in helping with the migration effort, please join us! There's always +room for more contributors, whether to our transition tools or to our +documentation. To get started, say hello in +[#sig-node](https://kubernetes.slack.com/archives/C0BP8PW9G) +channel on [Kuberentes Slack](https://slack.kubernetes.io/)! + +## Final thoughts + +As a project, we've already seen cluster operators increasingly adopt of other container runtimes through 2021. +We believe there are no major blockers to migration. The steps we're taking to +improve the migration experience will light the path more clearly for you. + +We understand that migration from dockershim is yet another action you may need to +do to keep your Kubernetes infrastructure up to date. For most of you, this step +will be straightforward and transparent. In some cases, you will encounter +hiccups or issues. The community has discussed at length whether postponing the +dockershim removal would be helpful. For example, we recently talked about it in +the [SIG Node discussion on November 11th](https://docs.google.com/document/d/1Ne57gvidMEWXR70OxxnRkYquAoMpt56o75oZtg-OeBg/edit#bookmark=id.r77y11bgzid) +and in the [Kubernetes Steering committee meeting held on December 6th](https://docs.google.com/document/d/1qazwMIHGeF3iUh5xMJIJ6PDr-S3bNkT8tNLRkSiOkOU/edit#bookmark=id.m0ir406av7jx). +We already [postponed](https://github.com/kubernetes/enhancements/pull/2481/) it once last year because the adoption rate of other +runtimes was lower than we wanted, which also gave us more time to identify +potential blocking issues. + +At this point, we believe that the value that you (and Kubernetes) gain from +dockershim removal makes up for the migration effort you'll have. Start planning +now to avoid surprises. We'll have more updates and guides before Kubernetes +1.24 is released. From 4030f7fab9fc3a81aeb69314421a7aba4ab0b0fc Mon Sep 17 00:00:00 2001 From: DanStough Date: Thu, 6 Jan 2022 14:50:38 -0500 Subject: [PATCH 24/32] kubeadm: remove ClusterStatus references --- content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md | 2 -- content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset.md | 3 +-- 2 files changed, 1 insertion(+), 4 deletions(-) diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md index b5756e5cc2..5693274a59 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md +++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md @@ -41,8 +41,6 @@ For control-plane nodes additional steps are performed: 1. Adding new local etcd member. -1. Adding this node to the ClusterStatus of the kubeadm cluster. - ### Using join phases with kubeadm {#join-phases} Kubeadm allows you join a node to the cluster in phases using `kubeadm join phase`. diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset.md index 93d5ce0cbb..9a5f9b29fd 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset.md +++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset.md @@ -16,8 +16,7 @@ Performs a best effort revert of changes made by `kubeadm init` or `kubeadm join `kubeadm reset` is responsible for cleaning up a node local file system from files that were created using the `kubeadm init` or `kubeadm join` commands. For control-plane nodes `reset` also removes the local stacked -etcd member of this node from the etcd cluster and also removes this node's information from the kubeadm -`ClusterStatus` object. `ClusterStatus` is a kubeadm managed Kubernetes API object that holds a list of kube-apiserver endpoints. +etcd member of this node from the etcd cluster. `kubeadm reset phase` can be used to execute the separate phases of the above workflow. To skip a list of phases you can use the `--skip-phases` flag, which works in a similar way to From 9617e67e51290b50edc5c9f30175f8d4403d0fd6 Mon Sep 17 00:00:00 2001 From: Sergey Kanzhelev Date: Thu, 6 Jan 2022 12:40:58 -0800 Subject: [PATCH 25/32] Update content/en/blog/_posts/2022-01-07-kubernetes-is-moving-on-from-dockershim.md Co-authored-by: Rey Lejano --- .../2022-01-07-kubernetes-is-moving-on-from-dockershim.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/blog/_posts/2022-01-07-kubernetes-is-moving-on-from-dockershim.md b/content/en/blog/_posts/2022-01-07-kubernetes-is-moving-on-from-dockershim.md index 11fc82f947..17a38caa5f 100644 --- a/content/en/blog/_posts/2022-01-07-kubernetes-is-moving-on-from-dockershim.md +++ b/content/en/blog/_posts/2022-01-07-kubernetes-is-moving-on-from-dockershim.md @@ -1,6 +1,6 @@ --- layout: blog -title: "Kubernetes is moving on from Dockershim: commitments and next steps" +title: "Kubernetes is Moving on From Dockershim: Commitments and Next Steps" date: 2022-01-07 slug: kubernetes-is-moving-on-from-dockershim --- From 2a0fb0690f3dfa80a56fe6d35d968d1ea5dcbcf2 Mon Sep 17 00:00:00 2001 From: Tim Bannister Date: Thu, 6 Jan 2022 21:04:13 +0000 Subject: [PATCH 26/32] Mark dockershim survey closed --- .../index.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/content/en/blog/_posts/2021-11-12-are-you-ready-for-dockershim-removal/index.md b/content/en/blog/_posts/2021-11-12-are-you-ready-for-dockershim-removal/index.md index 6d0f1e9f83..a896d0f8c9 100644 --- a/content/en/blog/_posts/2021-11-12-are-you-ready-for-dockershim-removal/index.md +++ b/content/en/blog/_posts/2021-11-12-are-you-ready-for-dockershim-removal/index.md @@ -5,17 +5,18 @@ date: 2021-11-12 slug: are-you-ready-for-dockershim-removal --- -{{< note >}} -This poll will close on January 7, 2022. -{{}} - **Author:** Sergey Kanzhelev, Google. With reviews from Davanum Srinivas, Elana Hashman, Noah Kantrowitz, Rey Lejano. +{{% alert color="info" title="Poll closed" %}} +This poll closed on January 7, 2022. +{{% /alert %}} + Last year we announced that Dockershim is being deprecated: [Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/). Our current plan is to remove dockershim from the Kubernetes codebase soon. We are looking for feedback from you whether you are ready for dockershim removal and to ensure that you are ready when the time comes. -**Please fill out this survey: https://forms.gle/svCJmhvTv78jGdSx8**. + +Please fill out this survey: https://forms.gle/svCJmhvTv78jGdSx8 The dockershim component that enables Docker as a Kubernetes container runtime is being deprecated in favor of runtimes that directly use the [Container Runtime Interface](/blog/2016/12/container-runtime-interface-cri-in-kubernetes/) @@ -37,7 +38,7 @@ beta versions, dockershim will be removed in December at the beginning of the There is only one month left to give us feedback. We want you to tell us how ready you are. -**We are collecting opinions through this survey: [https://forms.gle/svCJmhvTv78jGdSx8](https://forms.gle/svCJmhvTv78jGdSx8)** +We are collecting opinions through this survey: https://forms.gle/svCJmhvTv78jGdSx8 To better understand preparedness for the dockershim removal, our survey is asking the version of Kubernetes you are currently using, and an estimate of when you think you will adopt Kubernetes 1.24. All the aggregated information From 34036af32149fd9ed94222e8c8f97e29be8b191f Mon Sep 17 00:00:00 2001 From: Mauren Berti Date: Mon, 25 Oct 2021 18:29:03 -0400 Subject: [PATCH 27/32] Add pt-br/docs/concepts/configuration/secret.md. Create the Brazilian Portuguese translation for the Secrets page. --- .../docs/concepts/configuration/secret.md | 2141 +++++++++++++++++ .../docs/reference/glossary/configmap.md | 2 +- .../glossary/container-env-variables.md | 17 + .../docs/reference/glossary/container.md | 19 + .../pt-br/docs/reference/glossary/secret.md | 2 +- 5 files changed, 2179 insertions(+), 2 deletions(-) create mode 100644 content/pt-br/docs/concepts/configuration/secret.md create mode 100644 content/pt-br/docs/reference/glossary/container-env-variables.md create mode 100644 content/pt-br/docs/reference/glossary/container.md diff --git a/content/pt-br/docs/concepts/configuration/secret.md b/content/pt-br/docs/concepts/configuration/secret.md new file mode 100644 index 0000000000..013075c852 --- /dev/null +++ b/content/pt-br/docs/concepts/configuration/secret.md @@ -0,0 +1,2141 @@ +--- +title: Secrets +content_type: concept +feature: + title: Secrets e gerenciamento de configuração + description: > + Crie e atualize Secrets e configurações da aplicação sem reconstruir sua imagem + de contêiner e sem expor credenciais na configuração da sua aplicação. +weight: 30 +--- + + + + + + + +Um Secret é um objeto que contém uma pequena quantidade de informação sensível, +como senhas, tokens ou chaves. Este tipo de informação poderia, em outras +circunstâncias, ser colocada diretamente em uma configuração de +{{< glossary_tooltip term_id="pod" >}} ou em uma +{{< glossary_tooltip text="imagem de contêiner" term_id="image" >}}. O uso de +Secrets evita que você tenha de incluir dados confidenciais no seu código. + + + +Secrets podem ser criados de forma independente dos Pods que os consomem. Isto +reduz o risco de que o Secret e seus dados sejam expostos durante o processo de +criação, visualização e edição ou atualização de Pods. O Kubernetes e as +aplicações que rodam no seu cluster podem também tomar outras precauções com +Secrets, como por exemplo evitar a escrita de dados confidenciais em local de +armazenamento persistente (não-volátil). + + + +Secrets são semelhantes a +{{< glossary_tooltip text="ConfigMaps" term_id="configmap" >}}, mas foram +especificamente projetados para conter dados confidenciais. + + + +{{< caution >}} +Os Secrets do Kubernetes são, por padrão, gravados não-encriptados no sistema +de armazenamento de dados utilizado pelo servidor da API (etcd). Qualquer pessoa +com acesso à API ou ao etcd consegue obter ou modificar um Secret. +Além disso, qualquer pessoa que possui autorização para criar Pods em um namespace +consegue utilizar este privilégio para ler qualquer Secret naquele namespace. Isso +inclui acesso indireto, como por exemplo a permissão para criar Deployments. + +Para utilizar Secrets de forma segura, siga pelo menos as instruções abaixo: +1. [Habilite encriptação em disco](/docs/tasks/administer-cluster/encrypt-data/) para Secrets. +1. Habilite ou configure [regras de RBAC](/docs/reference/access-authn-authz/authorization/) +que restrinjam o acesso de leitura a Secrets (incluindo acesso indireto). +1. Quando apropriado, utilize mecanismos como RBAC para limitar quais perfis e +usuários possuem permissão para criar novos Secrets ou substituir Secrets +existentes. + +{{< /caution >}} + + + +## Visão Geral de Secrets + + + +Para utilizar um Secret, um Pod precisa referenciar o Secret. +Um Secret pode ser utilizado em um Pod de três maneiras diferentes: +- Como um [arquivo](#using-secrets-as-files-from-a-pod) em um +{{< glossary_tooltip text="volume" term_id="volume" >}} montado em um ou mais de +seus contêineres. +- Como uma [variável de ambiente](#using-secrets-as-environment-variables) em um +contêiner. +- Pelo [kubelet ao baixar imagens de contêiner](#using-imagepullsecrets) para o +Pod. + + + +A camada de gerenciamento do Kubernetes também utiliza Secrets. Por exemplo, +os [Secrets de tokens de autoinicialização](#bootstrap-token-secrets) são um +mecanismo que auxilia a automação do registro de nós. + + + +O nome de um Secret deve ser um [subdomínio DNS válido](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). +Você pode especificar o campo `data` e/ou o campo `stringData` na criação de um +arquivo de configuração de um Secret. Ambos os campos `data` e `stringData` são +opcionais. Os valores das chaves no campo `data` devem ser strings codificadas +no formato base64. Se a conversão para base64 não for desejável, você pode +optar por informar os dados no campo `stringData`, que aceita strings arbitrárias +como valores. + + + +As chaves dos campos `data` e `stringData` devem consistir de caracteres +alfanuméricos, `-`, `_`, ou `.`. Todos os pares chave-valor no campo `stringData` +são internamente combinados com os dados do campo `data`. Se uma chave aparece +em ambos os campos, o valor informado no campo `stringData` toma a precedência. + +## Tipos de Secrets {#secret-types} + + + +Ao criar um Secret, você pode especificar o seu tipo utilizando o campo `type` +do objeto Secret, ou algumas opções de linha de comando equivalentes no comando +`kubectl`, quando disponíveis. O campo `type` de um Secret é utilizado para +facilitar a manipulação programática de diferentes tipos de dados confidenciais. + + + +O Kubernetes oferece vários tipos embutidos de Secret para casos de uso comuns. +Estes tipos variam em termos de validações efetuadas e limitações que o +Kubernetes impõe neles. + + + +| Tipo embutido | Caso de uso | +|----------------------------------------|----------------------------------------------------| +| `Opaque` | dados arbitrários definidos pelo usuário | +| `kubernetes.io/service-account-token` | token de service account (conta de serviço) | +| `kubernetes.io/dockercfg` | arquivo `~/.dockercfg` serializado | +| `kubernetes.io/dockerconfigjson` | arquivo `~/.docker/config.json` serializado | +| `kubernetes.io/basic-auth` | credenciais para autenticação básica (basic auth) | +| `kubernetes.io/ssh-auth` | credenciais para autenticação SSH | +| `kubernetes.io/tls` | dados para um cliente ou servidor TLS | +| `bootstrap.kubernetes.io/token` | dados de token de autoinicialização | + + + +Você pode definir e utilizar seu próprio tipo de Secret definindo o valor do +campo `type` como uma string não-nula em um objeto Secret. Uma string em branco +é tratada como o tipo `Opaque`. O Kubernetes não restringe nomes de tipos. No +entanto, quando tipos embutidos são utilizados, você precisa atender a todos os +requisitos daquele tipo. + +### Secrets tipo Opaque + + + +`Opaque` é o tipo predefinido de Secret quando o campo `type` não é informado +em um arquivo de configuração. Quando um Secret é criado usando o comando +`kubectl`, você deve usar o subcomando `generic` para indicar que um Secret é +do tipo `Opaque`. Por exemplo, o comando a seguir cria um Secret vazio do tipo +`Opaque`: +```shell +kubectl create secret generic empty-secret +kubectl get secret empty-secret +``` + +O resultado será semelhante ao abaixo: + +``` +NAME TYPE DATA AGE +empty-secret Opaque 0 2m6s +``` + + + +A coluna `DATA` demonstra a quantidade de dados armazenados no Secret. Neste +caso, `0` significa que este objeto Secret está vazio. + +### Secrets de token de service account (conta de serviço) + + + +Secrets do tipo `kubernetes.io/service-account-token` são utilizados para +armazenar um token que identifica uma service account (conta de serviço). Ao +utilizar este tipo de Secret, você deve garantir que a anotação +`kubernetes.io/service-account.name` contém um nome de uma service account +existente. Um controlador do Kubernetes preenche outros campos, como por exemplo +a anotação `kubernetes.io/service-account.uid` e a chave `token` no campo `data` +com o conteúdo do token. + + +O exemplo de configuração abaixo declara um Secret de token de service account: + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: secret-sa-sample + annotations: + kubernetes.io/service-account-name: "sa-name" +type: kubernetes.io/service-account-token +data: + # Você pode incluir pares chave-valor adicionais, da mesma forma que faria com + # Secrets do tipo Opaque + extra: YmFyCg== +``` + + + +Ao criar um {{< glossary_tooltip text="Pod" term_id="pod" >}}, o Kubernetes +automaticamente cria um Secret de service account e automaticamente atualiza o +seu Pod para utilizar este Secret. O Secret de token de service account contém +credenciais para acessar a API. + + + +A criação automática e o uso de credenciais de API podem ser desativados se +desejado. Porém, se tudo que você necessita é poder acessar o servidor da API +de forma segura, este é o processo recomendado. + + + +Veja a documentação de +[ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/) +para mais informações sobre o funcionamento de service accounts. Você pode +verificar também os campos `automountServiceAccountToken` e `serviceAccountName` +do [`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) +para mais informações sobre como referenciar service accounts em Pods. + +### Secrets de configuração do Docker + + + +Você pode utilizar um dos tipos abaixo para criar um Secret que armazena +credenciais para accesso a um registro de contêineres compatível com Docker +para busca de imagens: +- `kubernetes.io/dockercfg` +- `kubernetes.io/dockerconfigjson` + + +O tipo `kubernetes.io/dockercfg` é reservado para armazenamento de um arquivo +`~/.dockercfg` serializado. Este arquivo é o formato legado para configuração +do utilitário de linha de comando do Docker. Ao utilizar este tipo de Secret, +é preciso garantir que o campo `data` contém uma chave `.dockercfg` cujo valor +é o conteúdo do arquivo `~/.dockercfg` codificado no formato base64. + + + +O tipo `kubernetes.io/dockerconfigjson` foi projetado para armazenamento de um +conteúdo JSON serializado que obedece às mesmas regras de formato que o arquivo +`~/.docker/config.json`. Este arquivo é um formato mais moderno para o conteúdo +do arquivo `~/.dockercfg`. Ao utilizar este tipo de Secret, o conteúdo do campo +`data` deve conter uma chave `.dockerconfigjson` em que o conteúdo do arquivo +`~/.docker/config.json` é fornecido codificado no formato base64. + + + +Um exemplo de um Secret do tipo `kubernetes.io/dockercfg`: +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: secret-dockercfg +type: kubernetes.io/dockercfg +data: + .dockercfg: | + "" +``` + + + +{{< note >}} +Se você não desejar fazer a codificação em formato base64, você pode utilizar o +campo `stringData` como alternativa. +{{< /note >}} + + + +Ao criar estes tipos de Secret utilizando um manifesto (arquivo YAML), o servidor +da API verifica se a chave esperada existe no campo `data` e se o valor fornecido +pode ser interpretado como um conteúdo JSON válido. O servidor da API não verifica +se o conteúdo informado é realmente um arquivo de configuração do Docker. + + + +Quando você não tem um arquivo de configuração do Docker, ou quer utilizar o +comando `kubectl` para criar um Secret de registro de contêineres compatível +com o Docker, você pode executar: +```shell +kubectl create secret docker-registry secret-tiger-docker \ + --docker-username=tiger \ + --docker-password=pass113 \ + --docker-email=tiger@acme.com \ + --docker-server=my-registry.example:5000 +``` + + + +Esse comando cria um secret do tipo `kubernetes.io/dockerconfigjson`, cujo +conteúdo é semelhante ao exemplo abaixo: + +```json +{ + "apiVersion": "v1", + "data": { + ".dockerconfigjson": "eyJhdXRocyI6eyJteS1yZWdpc3RyeTo1MDAwIjp7InVzZXJuYW1lIjoidGlnZXIiLCJwYXNzd29yZCI6InBhc3MxMTMiLCJlbWFpbCI6InRpZ2VyQGFjbWUuY29tIiwiYXV0aCI6ImRHbG5aWEk2Y0dGemN6RXhNdz09In19fQ==" + }, + "kind": "Secret", + "metadata": { + "creationTimestamp": "2021-07-01T07:30:59Z", + "name": "secret-tiger-docker", + "namespace": "default", + "resourceVersion": "566718", + "uid": "e15c1d7b-9071-4100-8681-f3a7a2ce89ca" + }, + "type": "kubernetes.io/dockerconfigjson" +} +``` + +Se você extrair o conteúdo da chave `.dockerconfigjson`, presente no campo +`data`, e decodificá-lo do formato base64, você irá obter o objeto JSON abaixo, +que é uma configuração válida do Docker criada automaticamente: + +```json +{ + "auths":{ + "my-registry:5000":{ + "username":"tiger", + "password":"pass113", + "email":"tiger@acme.com", + "auth":"dGlnZXI6cGFzczExMw==" + } + } +} +``` + +### Secret de autenticação básica + + + +O tipo `kubernetes.io/basic-auth` é fornecido para armazenar credenciais +necessárias para autenticação básica. Ao utilizar este tipo de Secret, o campo +`data` do Secret deve conter as duas chaves abaixo: +- `username`: o usuário utilizado para autenticação; +- `password`: a senha ou token para autenticação. + + + +Ambos os valores para estas duas chaves são textos codificados em formato base64. +Você pode fornecer os valores como texto simples utilizando o campo `stringData` +na criação do Secret. + +O arquivo YAML abaixo é um exemplo de configuração para um Secret de autenticação +básica: +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: secret-basic-auth +type: kubernetes.io/basic-auth +stringData: + username: admin + password: t0p-Secret +``` + + + +O tipo de autenticação básica é fornecido unicamente por conveniência. Você pode +criar um Secret do tipo `Opaque` utilizado para autenticação básica. No entanto, +utilizar o tipo embutido de Secret auxilia a unificação dos formatos das suas +credenciais. O tipo embutido também fornece verificação de presença das chaves +requeridas pelo servidor da API. + +### Secret de autenticação SSH + + + +O tipo embutido `kubernetes.io/ssh-auth` é fornecido para armazenamento de dados +utilizados em autenticação SSH. Ao utilizar este tipo de Secret, você deve +especificar um par de chave-valor `ssh-privatekey` no campo `data` ou no campo +`stringData` com a credencial SSH a ser utilizada. + +O YAML abaixo é um exemplo de configuração para um Secret de autenticação SSH: + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: secret-ssh-auth +type: kubernetes.io/ssh-auth +data: + # os dados estão abreviados neste exemplo + ssh-privatekey: | + MIIEpQIBAAKCAQEAulqb/Y ... +``` + + + +O Secret de autenticação SSH é fornecido apenas para a conveniência do usuário. +Você pode criar um Secret do tipo `Opaque` para credentials utilizadas para +autenticação SSH. No entanto, a utilização do tipo embutido auxilia na +unificação dos formatos das suas credenciais e o servidor da API fornece +verificação dos campos requeridos em uma configuração de Secret. + + + +{{< caution >}} +Chaves privadas SSH não estabelecem, por si só, uma comunicação confiável +entre um cliente SSH e um servidor. Uma forma secundária de estabelecer +confiança é necessária para mitigar ataques "machine-in-the-middle", como +por exemplo um arquivo `known_hosts` adicionado a um ConfigMap. +{{< /caution >}} + +### Secrets TLS + + + +O Kubernetes fornece o tipo embutido de Secret `kubernetes.io/tls` para +armazenamento de um certificado e sua chave associada que são tipicamente +utilizados para TLS. Estes dados são utilizados primariamente para a +finalização TLS do recurso Ingress, mas podem ser utilizados com outros +recursos ou diretamente por uma carga de trabalho. Ao utilizar este tipo de +Secret, as chaves `tls.key` e `tls.crt` devem ser informadas no campo `data` +(ou `stringData`) da configuração do Secret, embora o servidor da API não +valide o conteúdo de cada uma destas chaves. + +O YAML a seguir tem um exemplo de configuração para um Secret TLS: +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: secret-tls +type: kubernetes.io/tls +data: + # os dados estão abreviados neste exemplo + tls.crt: | + MIIC2DCCAcCgAwIBAgIBATANBgkqh ... + tls.key: | + MIIEpgIBAAKCAQEA7yn3bRHQ5FHMQ ... +``` + + + +O tipo TLS é fornecido para a conveniência do usuário. Você pode criar um +Secret do tipo `Opaque` para credenciais utilizadas para o servidor e/ou +cliente TLS. No entanto, a utilização do tipo embutido auxilia a manter a +consistência dos formatos de Secret no seu projeto; o servidor da API +valida se os campos requeridos estão presentes na configuração do Secret. + +Ao criar um Secret TLS utilizando a ferramenta de linha de comando `kubectl`, +você pode utilizar o subcomando `tls` conforme demonstrado no exemplo abaixo: +```shell +kubectl create secret tls my-tls-secret \ + --cert=path/to/cert/file \ + --key=path/to/key/file +``` + + + +O par de chaves pública/privada deve ser criado separadamente. O certificado +de chave pública a ser utilizado no argumento `--cert` deve ser codificado em +formato .PEM (formato DER codificado em texto base64) e deve corresponder à +chave privada fornecida no argumento `--key`. +A chave privada deve estar no formato de chave privada PEM não-encriptado. Em +ambos os casos, as linhas inicial e final do formato PEM (por exemplo, +`--------BEGIN CERTIFICATE-----` e `-------END CERTIFICATE----` para um +certificado) *não* são incluídas. + +### Secret de token de autoinicialização {#bootstrap-token-secrets} + + + +Um Secret de token de autoinicialização pode ser criado especificando o tipo de +um Secret explicitamente com o valor `bootstrap.kubernetes.io/token`. Este tipo +de Secret é projetado para tokens utilizados durante o processo de inicialização +de nós. Este tipo de Secret armazena tokens utilizados para assinar ConfigMaps +conhecidos. + +Um Secret de token de autoinicialização é normalmente criado no namespace +`kube-system` e nomeado na forma `bootstrap-token-`, onde +`` é um texto com 6 caracteres contendo a identificação do token. + +No formato de manifesto do Kubernetes, um Secret de token de autoinicialização +se assemelha ao exemplo abaixo: +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: bootstrap-token-5emitj + namespace: kube-system +type: bootstrap.kubernetes.io/token +data: + auth-extra-groups: c3lzdGVtOmJvb3RzdHJhcHBlcnM6a3ViZWFkbTpkZWZhdWx0LW5vZGUtdG9rZW4= + expiration: MjAyMC0wOS0xM1QwNDozOToxMFo= + token-id: NWVtaXRq + token-secret: a3E0Z2lodnN6emduMXAwcg== + usage-bootstrap-authentication: dHJ1ZQ== + usage-bootstrap-signing: dHJ1ZQ== +``` + + + +Um Secret do tipo token de autoinicialização possui as seguintes chaves no campo +`data`: +- `token-id`: Uma string com 6 caracteres aleatórios como identificador do + token. Requerido. +- `token-secret`: Uma string de 16 caracteres aleatórios como o conteúdo do + token. Requerido. +- `description`: Uma string contendo uma descrição do propósito para o qual este + token é utilizado. Opcional. +- `expiration`: Um horário absoluto UTC no formato RFC3339 especificando quando + o token deve expirar. Opcional. +- `usage-bootstrap-`: Um conjunto de flags booleanas indicando outros + usos para este token de autoinicialização. +- `auth-extra-groups`: Uma lista separada por vírgulas de nomes de grupos que + serão autenticados adicionalmente, além do grupo `system:bootstrappers`. + +O YAML acima pode parecer confuso, já que os valores estão todos codificados em +formato base64. Você pode criar o mesmo Secret utilizando este YAML: +```yaml +apiVersion: v1 +kind: Secret +metadata: + # Observe como o Secret é nomeado + name: bootstrap-token-5emitj + # Um Secret de token de inicialização geralmente fica armazenado no namespace + # kube-system + namespace: kube-system +type: bootstrap.kubernetes.io/token +stringData: + auth-extra-groups: "system:bootstrappers:kubeadm:default-node-token" + expiration: "2020-09-13T04:39:10Z" + # Esta identificação de token é utilizada no nome + token-id: "5emitj" + token-secret: "kq4gihvszzgn1p0r" + # Este token pode ser utilizado para autenticação. + usage-bootstrap-authentication: "true" + # e pode ser utilizado para assinaturas + usage-bootstrap-signing: "true" +``` + +## Criando um Secret + + + +Há várias formas diferentes de criar um Secret: +- [criar um Secret utilizando o comando `kubectl`](/pt-br/docs/tasks/configmap-secret/managing-secret-using-kubectl/) +- [criar um Secret a partir de um arquivo de configuração](/pt-br/docs/tasks/configmap-secret/managing-secret-using-config-file/) +- [criar um Secret utilizando a ferramenta kustomize](/pt-br/docs/tasks/configmap-secret/managing-secret-using-kustomize/) + +## Editando um Secret + + +Um Secret existente no cluster pode ser editado com o seguinte comando: +```shell +kubectl edit secrets mysecret +``` + + + +Este comando abrirá o editor padrão configurado e permitirá a modificação dos +valores codificados em base64 no campo `data`: +```yaml +# Please edit the object below. Lines beginning with a '#' will be ignored, +# and an empty file will abort the edit. If an error occurs while saving this file will be +# reopened with the relevant failures. +# +apiVersion: v1 +data: + username: YWRtaW4= + password: MWYyZDFlMmU2N2Rm +kind: Secret +metadata: + annotations: + kubectl.kubernetes.io/last-applied-configuration: { ... } + creationTimestamp: 2016-01-22T18:41:56Z + name: mysecret + namespace: default + resourceVersion: "164619" + uid: cfee02d6-c137-11e5-8d73-42010af00002 +type: Opaque +``` + +## Utilizando Secrets + + + +Secrets podem ser montados como volumes de dados ou expostos como +{{< glossary_tooltip text="variáveis de ambiente" term_id="container-env-variables" >}} +para serem utilizados num container de um Pod. Secrets também podem ser +utilizados por outras partes do sistema, sem serem diretamente expostos ao Pod. +Por exemplo, Secrets podem conter credenciais que outras partes do sistema devem +utilizar para interagir com sistemas externos no lugar do usuário. + +### Utilizando Secrets como arquivos em um Pod {#using-secrets-as-files-from-a-pod} + + + +Para consumir um Secret em um volume em um Pod: +1. Crie um Secret ou utilize um previamente existente. Múltiplos Pods podem +referenciar o mesmo secret. +1. Modifique sua definição de Pod para adicionar um volume na lista +`.spec.volumes[]`. Escolha um nome qualquer para o seu volume e adicione um +campo `.spec.volumes[].secret.secretName` com o mesmo valor do seu objeto +Secret. +1. Adicione um ponto de montagem de volume à lista +`.spec.containers[].volumeMounts[]` de cada contêiner que requer o Secret. +Especifique `.spec.containers[].volumeMounts[].readOnly = true` e especifique o +valor do campo `.spec.containers[].volumeMounts[].mountPath` com o nome de um +diretório não utilizado onde você deseja que os Secrets apareçam. +1. Modifique sua imagem ou linha de comando de modo que o programa procure por +arquivos naquele diretório. Cada chave no campo `data` se torna um nome de +arquivo no diretório especificado em `mountPath`. + +Este é um exemplo de Pod que monta um Secret em um volume: +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + containers: + - name: mypod + image: redis + volumeMounts: + - name: foo + mountPath: "/etc/foo" + readOnly: true + volumes: + - name: foo + secret: + secretName: mysecret +``` + + + +Cada Secret que você deseja utilizar deve ser referenciado na lista +`.spec.volumes`. + +Se existirem múltiplos contêineres em um Pod, cada um dos contêineres necessitará +seu próprio bloco `volumeMounts`, mas somente um volume na lista `.spec.volumes` +é necessário por Secret. + +Você pode armazenar vários arquivos em um Secret ou utilizar vários Secrets +distintos, o que for mais conveniente. + +#### Projeção de chaves de Secrets a caminhos específicos + + +Você pode também controlar os caminhos dentro do volume onde as chaves do Secret +são projetadas. Você pode utilizar o campo `.spec.volumes[].secret.items` para +mudar o caminho de destino de cada chave: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + containers: + - name: mypod + image: redis + volumeMounts: + - name: foo + mountPath: "/etc/foo" + readOnly: true + volumes: + - name: foo + secret: + secretName: mysecret + items: + - key: username + path: my-group/my-username +``` + + + +Neste caso: +* O valor da chave `username` é armazenado no arquivo +`/etc/foo/my-group/my-username` ao invés de `/etc/foo/username`. +* O valor da chave `password` não é projetado no sistema de arquivos. + +Se `.spec.volumes[].secret.items` for utilizado, somente chaves especificadas +na lista `items` são projetadas. Para consumir todas as chaves do Secret, deve +haver um item para cada chave no campo `items`. Todas as chaves listadas precisam +existir no Secret correspondente. Caso contrário, o volume não é criado. + +#### Permissões de arquivos de Secret + + + +Você pode trocar os bits de permissão de uma chave avulsa de Secret. +Se nenhuma permissão for especificada, `0644` é utilizado por padrão. +Você pode também especificar uma permissão padrão para o volume inteiro de +Secret e sobrescrever esta permissão por chave, se necessário. + +Por exemplo, você pode especificar uma permissão padrão da seguinte maneira: +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + containers: + - name: mypod + image: redis + volumeMounts: + - name: foo + mountPath: "/etc/foo" + volumes: + - name: foo + secret: + secretName: mysecret + defaultMode: 0400 +``` + + + +Dessa forma, o Secret será montado em `/etc/foo` e todos os arquivos criados +no volume terão a permissão `0400`. + +Note que a especificação JSON não suporta notação octal. Neste caso, utilize o +valor 256 para permissões equivalentes a 0400. Se você utilizar YAML ao invés +de JSON para o Pod, você pode utilizar notação octal para especificar permissões +de uma forma mais natural. + +Perceba que se você acessar o Pod com `kubectl exec`, você precisará seguir o +vínculo simbólico para encontrar a permissão esperada. Por exemplo, + +Verifique as permissões do arquivo de Secret no pod. +``` +kubectl exec mypod -it sh + +cd /etc/foo +ls -l +``` + + +O resultado é semelhante ao abaixo: +``` +total 0 +lrwxrwxrwx 1 root root 15 May 18 00:18 password -> ..data/password +lrwxrwxrwx 1 root root 15 May 18 00:18 username -> ..data/username +``` + + +Siga o vínculo simbólico para encontrar a permissão correta do arquivo. +``` +cd /etc/foo/..data +ls -l +``` + + +O resultado é semelhante ao abaixo: +``` +total 8 +-r-------- 1 root root 12 May 18 00:18 password +-r-------- 1 root root 5 May 18 00:18 username +``` + + + +Você pode também utilizar mapeamento, como no exemplo anterior, e especificar +permissões diferentes para arquivos diferentes conforme abaixo: +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + containers: + - name: mypod + image: redis + volumeMounts: + - name: foo + mountPath: "/etc/foo" + volumes: + - name: foo + secret: + secretName: mysecret + items: + - key: username + path: my-group/my-username + mode: 0777 +``` + + + +Neste caso, o arquivo resultante em `/etc/foo/my-group/my-username` terá as +permissões `0777`. Se você utilizar JSON, devido às limitações do formato, +você precisará informar as permissões em base decimal, ou o valor `511` neste +exemplo. + +Note que os valores de permissões podem ser exibidos em formato decimal se você +ler essa informação posteriormente. + +#### Consumindo valores de Secrets em volumes + + + +Dentro do contêiner que monta um volume de Secret, as chaves deste Secret +aparecem como arquivos e os valores dos Secrets são decodificados do formato +base64 e armazenados dentro destes arquivos. Ao executar comandos dentro do +contêiner do exemplo anterior, obteremos os seguintes resultados: + +```shell +ls /etc/foo +``` + + +O resultado é semelhante a: +``` +username +password +``` + +```shell +cat /etc/foo/username +``` + + +O resultado é semelhante a: +``` +admin +``` + +```shell +cat /etc/foo/password +``` + + +O resultado é semelhante a: +``` +1f2d1e2e67df +``` + + + +A aplicação rodando dentro do contêiner é responsável pela leitura dos Secrets +dentro dos arquivos. + +#### Secrets montados são atualizados automaticamente + + + +Quando um Secret que está sendo consumido a partir de um volume é atualizado, as +chaves projetadas são atualizadas após algum tempo também. O kubelet verifica +se o Secret montado está atualizado a cada sincronização periódica. No entanto, +o kubelet utiliza seu cache local para buscar o valor corrente de um Secret. O +tipo do cache é configurável utilizando o campo `ConfigMapAndSecretChangeDetectionStrategy` +na estrutura [KubeletConfiguration](/docs/reference/config-api/kubelet-config.v1beta1/). +Um Secret pode ser propagado através de um _watch_ (comportamento padrão), que +é o sistema de propagação de mudanças incrementais em objetos do Kubernetes; +baseado em TTL (_time to live_, ou tempo de expiração); ou redirecionando todas +as requisições diretamente para o servidor da API. + +Como resultado, o tempo decorrido total entre o momento em que o Secret foi +atualizado até o momento em que as novas chaves são projetadas nos Pods pode +ser tão longo quanto o tempo de sincronização do kubelet somado ao tempo de +propagação do cache, onde o tempo de propagação do cache depende do tipo de +cache escolhido: o tempo de propagação pode ser igual ao tempo de propagação +do _watch_, TTL do cache, ou zero, de acordo com cada um dos tipos de cache. + + + +{{< note >}} +Um contêiner que utiliza Secrets através de um ponto de montagem com a +propriedade +[subPath](/docs/concepts/storage/volumes#using-subpath) não recebe atualizações +deste Secret. +{{< /note >}} + +### Utilizando Secrets como variáveis de ambiente {#using-secrets-as-environment-variables} + + + +Para utilizar um secret em uma {{< glossary_tooltip text="variável de ambiente" term_id="container-env-variables" >}} +em um Pod: + +1. Crie um Secret ou utilize um já existente. Múltiplos Pods podem referenciar o +mesmo Secret. +1. Modifique a definição de cada contêiner do Pod em que desejar consumir o +Secret, adicionando uma variável de ambiente para cada uma das chaves que deseja +consumir. +A variável de ambiente que consumir o valor da chave em questão deverá popular o +nome do Secret e a sua chave correspondente no campo +`env[].valueFrom.secretKeyRef`. +1. Modifique sua imagem de contêiner ou linha de comando de forma que o programa +busque os valores nas variáveis de ambiente especificadas. + +Este é um exemplo de um Pod que utiliza Secrets em variáveis de ambiente: +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: secret-env-pod +spec: + containers: + - name: mycontainer + image: redis + env: + - name: SECRET_USERNAME + valueFrom: + secretKeyRef: + name: mysecret + key: username + - name: SECRET_PASSWORD + valueFrom: + secretKeyRef: + name: mysecret + key: password + restartPolicy: Never +``` + +#### Consumindo valores de Secret em variáveis de ambiente + + + +Dentro de um contêiner que consome um Secret em variáveis de ambiente, a chave +do Secret aparece como uma variável de ambiente comum, contendo os dados do +Secret decodificados do formato base64. Ao executar comandos no contêiner do +exemplo anterior, obteremos os resultados abaixo: + +```shell +echo $SECRET_USERNAME +``` + + +O resultado é semelhante a: + +``` +admin +``` + +```shell +echo $SECRET_PASSWORD +``` + +O resultado é semelhante a: + +``` +1f2d1e2e67df +``` + +#### Variáveis de ambiente não são atualizadas após uma atualização no Secret + + + +Se um contêiner já consome um Secret em uma variável de ambiente, uma atualização +dos valores do Secret não será refletida no contêiner a menos que o contêiner +seja reiniciado. +Existem ferramentas de terceiros que oferecem reinicializações automáticas +quando Secrets são atualizados. + +## Secrets imutáveis {#secret-immutable} + +{{< feature-state for_k8s_version="v1.21" state="stable" >}} + + + +A funcionalidade do Kubernetes _Secrets e ConfigMaps imutáveis_ fornece uma +opção para marcar Secrets e ConfigMaps individuais como imutáveis. Em clusters +que fazem uso extensivo de Secrets (pelo menos dezenas de milhares de montagens +únicas de Secrets em Pods), prevenir alterações aos dados dos Secrets traz as +seguintes vantagens: +- protege você de alterações acidentais ou indesejadas que poderiam provocar +disrupções na execução de aplicações; +- melhora a performance do seu cluster através da redução significativa de carga +no kube-apiserver, devido ao fechamento de _watches_ de Secrets marcados como +imutáveis. + + + +Esta funcionalidade é controlada pelo +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) +`ImmutableEphemeralVolumes`, que está habilitado por padrão desde a versão +v1.19. Você pode criar um Secret imutável adicionando o campo `immutable` com +o valor `true`. Por exemplo: +```yaml +apiVersion: v1 +kind: Secret +metadata: + ... +data: + ... +immutable: true +``` + + + +{{< note >}} +Uma vez que um Secret ou ConfigMap seja marcado como imutável, _não_ é mais +possível reverter esta mudança, nem alterar os conteúdos do campo `data`. Você +pode somente apagar e recriar o Secret. Pods existentes mantém um ponto de +montagem referenciando o Secret removido - é recomendado recriar tais Pods. +{{< /note >}} + +### Usando `imagePullSecrets` {#using-imagepullsecrets} + + + +O campo `imagePullSecrets` é uma lista de referências para Secrets no mesmo +namespace. Você pode utilizar a lista `imagePullSecrets` para enviar Secrets +que contém uma senha para acesso a um registro de contêineres do Docker (ou +outros registros de contêineres) ao kubelet. O kubelet utiliza essa informação +para baixar uma imagem privada no lugar do seu Pod. +Veja a [API PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) +para maiores detalhes sobre o campo `imagePullSecrets`. + +#### Especificando `imagePullSecrets` manualmente + + + +Você pode ler sobre como especificar `imagePullSecrets` em um Pod na +[documentação de imagens de contêiner](/pt-br/docs/concepts/containers/images/#especificando-imagepullsecrets-em-um-pod). + +### Configurando `imagePullSecrets` para serem vinculados automaticamente + + + +Você pode criar manualmente `imagePullSecrets` e referenciá-los em uma +ServiceAccount. Quaisquer Pods criados com esta ServiceAccount, especificada +explicitamente ou por padrão, têm o campo `imagePullSecrets` populado com os +mesmos valores existentes na service account. +Veja [adicionando `imagePullSecrets` a uma service account](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) +para uma explicação detalhada do processo. + +## Detalhes + +### Restrições + + + +Referências a Secrets em volumes são validadas para garantir que o objeto +especificado realmente existe e é um objeto do tipo Secret. Portanto, um Secret +precisa ser criado antes de quaisquer Pods que dependam deste. + + + +Objetos Secret residem em um {{< glossary_tooltip text="namespace" term_id="namespace" >}}. +Secrets podem ser referenciados somente por Pods no mesmo namespace. + + + +Secrets individuais são limitados ao tamanho de 1MiB. Esta limitação ter por +objetivo desencorajar a criação de Secrets muito grandes que poderiam exaurir +a memória do servidor da API e do kubelet. No entanto, a criação de muitos +Secrets pequenos também pode exaurir a memória. Limites mais completos de uso +de memória em função de Secrets é uma funcionalidade prevista para o futuro. + + + +O kubelet suporta apenas o uso de Secrets em Pods onde os Secrets são obtidos +do servidor da API. Isso inclui quaisquer Pods criados usando o comando +`kubectl`, ou indiretamente através de um controlador de replicação, mas não +inclui Pods criados como resultado das flags `--manifest-url` e `--config` do +kubelet, ou a sua API REST (estas são formas incomuns de criar um Pod). +A `spec` de um {{< glossary_tooltip text="Pod estático" term_id="static-pod" >}} +não pode se referir a um Secret ou a qualquer outro objeto da API. + + + +Secrets precisam ser criados antes de serem consumidos em Pods como variáveis de +ambiente, exceto quando são marcados como opcionais. Referências a Secrets que +não existem provocam falhas na inicialização do Pod. + + + +Referências (campo `secretKeyRef`) a chaves que não existem em um Secret nomeado +provocam falhas na inicialização do Pod. + + + +Secrets utilizados para popular variáveis de ambiente através do campo `envFrom` +que contém chaves inválidas para utilização como nome de uma variável de ambiente +terão tais chaves ignoradas. O Pod inicializará normalmente. Porém, um evento +será gerado com a razão `InvalidVariableNames` e a mensagem gerada conterá a lista +de chaves inválidas que foram ignoradas. O exemplo abaixo demonstra um Pod que se +refere ao Secret default/mysecret, contendo duas chaves inválidas: `1badkey` e +`2alsobad`. + +```shell +kubectl get events +``` + + +O resultado é semelhante a: + +``` +LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT TYPE REASON +0s 0s 1 dapi-test-pod Pod Warning InvalidEnvironmentVariableNames kubelet, 127.0.0.1 Keys [1badkey, 2alsobad] from the EnvFrom secret default/mysecret were skipped since they are considered invalid environment variable names. +``` + +### Interações do ciclo de vida entre Secrets e Pods + + + +Quando um Pod é criado através de chamadas à API do Kubernetes, não há validação +da existência de um Secret referenciado. Uma vez que um Pod seja agendado, o +kubelet tentará buscar o valor do Secret. Se o Secret não puder ser encontrado +porque não existe ou porque houve uma falha de comunicação temporária entre o +kubelet e o servidor da API, o kubelet fará novas tentativas periodicamente. +O kubelet irá gerar um evento sobre o Pod, explicando a razão pela qual o Pod +ainda não foi inicializado. Uma vez que o Secret tenha sido encontrado, o +kubelet irá criar e montar um volume contendo este Secret. Nenhum dos contêineres +do Pod irá iniciar até que todos os volumes estejam montados. + +## Casos de uso + +### Caso de uso: Como variáveis de ambiente em um contêiner + + +Crie um manifesto de Secret + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: mysecret +type: Opaque +data: + USER_NAME: YWRtaW4= + PASSWORD: MWYyZDFlMmU2N2Rm +``` + + +Crie o Secret no seu cluster: + +```shell +kubectl apply -f mysecret.yaml +``` + + +Utilize `envFrom` para definir todos os dados do Secret como variáveis de +ambiente do contêiner. Cada chave do Secret se torna o nome de uma variável de +ambiente no Pod. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: secret-test-pod +spec: + containers: + - name: test-container + image: k8s.gcr.io/busybox + command: [ "/bin/sh", "-c", "env" ] + envFrom: + - secretRef: + name: mysecret + restartPolicy: Never +``` + +### Caso de uso: Pod com chaves SSH + + +Crie um Secret contendo chaves SSH: + +```shell +kubectl create secret generic ssh-key-secret --from-file=ssh-privatekey=/path/to/.ssh/id_rsa --from-file=ssh-publickey=/path/to/.ssh/id_rsa.pub +``` + + +O resultado é semelhante a: + +``` +secret "ssh-key-secret" created +``` + + + +Você também pode criar um manifesto `kustomization.yaml` com um campo +`secretGenerator` contendo chaves SSH. + +{{< caution >}} +Analise cuidadosamente antes de enviar suas próprias chaves SSH: outros usuários +do cluster podem ter acesso a este Secret. Utilize uma service account que você +deseje que seja acessível a todos os usuários com os quais você compartilha o +cluster do Kubernetes em questão. Desse modo, você pode revogar esta service +account caso os usuários sejam comprometidos. +{{< /caution >}} + +Agora você pode criar um Pod que referencia o Secret com a chave SSH e consome-o +em um volume: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: secret-test-pod + labels: + name: secret-test +spec: + volumes: + - name: secret-volume + secret: + secretName: ssh-key-secret + containers: + - name: ssh-test-container + image: mySshImage + volumeMounts: + - name: secret-volume + readOnly: true + mountPath: "/etc/secret-volume" +``` + + +Ao rodar o comando do contêiner, as partes da chave estarão disponíveis em: + +``` +/etc/secret-volume/ssh-publickey +/etc/secret-volume/ssh-privatekey +``` + + + +O contêiner então pode utilizar os dados do secret para estabelecer uma conexão +SSH. + +### Caso de uso: Pods com credenciais de ambientes de produção ou testes + + + +Este exemplo ilustra um Pod que consome um Secret contendo credenciais de um +ambiente de produção e outro Pod que consome um Secret contendo credenciais de +um ambiente de testes. + +Você pode criar um manifesto `kustomization.yaml` com um `secretGenerator` ou +rodar `kubectl create secret`. + +```shell +kubectl create secret generic prod-db-secret --from-literal=username=produser --from-literal=password=Y4nys7f11 +``` + + +O resultado é semelhante a: + +``` +secret "prod-db-secret" created +``` + + +Você pode também criar um Secret com credenciais para o ambiente de testes. + +```shell +kubectl create secret generic test-db-secret --from-literal=username=testuser --from-literal=password=iluvtests +``` + + +O resultado é semelhante a: + +``` +secret "test-db-secret" created +``` + + + +{{< note >}} +Caracteres especiais como `$`, `\`, `*`, `+` e `!` serão interpretados pelo seu +[shell](https://pt.wikipedia.org/wiki/Shell_(computa%C3%A7%C3%A3o)) e precisam de +sequências de escape. Na maioria dos shells, a forma mais fácil de gerar sequências +de escape para suas senhas é escrevê-las entre aspas simples (`'`). Por exemplo, +se a sua senha for `S!B\*d$zDsb=`, você deve executar o comando da seguinte +forma: + +```shell +kubectl create secret generic dev-db-secret --from-literal=username=devuser --from-literal=password='S!B\*d$zDsb=' +``` + +Não é necessário gerar sequências de escape para caracteres especiais em arquivos +(utilizados com a opção `--from-file`). +{{< /note >}} + +Agora, crie os Pods: + +```shell +cat < pod.yaml +apiVersion: v1 +kind: List +items: +- kind: Pod + apiVersion: v1 + metadata: + name: prod-db-client-pod + labels: + name: prod-db-client + spec: + volumes: + - name: secret-volume + secret: + secretName: prod-db-secret + containers: + - name: db-client-container + image: myClientImage + volumeMounts: + - name: secret-volume + readOnly: true + mountPath: "/etc/secret-volume" +- kind: Pod + apiVersion: v1 + metadata: + name: test-db-client-pod + labels: + name: test-db-client + spec: + volumes: + - name: secret-volume + secret: + secretName: test-db-secret + containers: + - name: db-client-container + image: myClientImage + volumeMounts: + - name: secret-volume + readOnly: true + mountPath: "/etc/secret-volume" +EOF +``` + + +Adicione os Pods a um manifesto `kustomization.yaml`: + +```shell +cat <> kustomization.yaml +resources: +- pod.yaml +EOF +``` + + +Crie todos estes objetos no servidor da API rodando o comando: + +```shell +kubectl apply -k . +``` + + + +Ambos os contêineres terão os seguintes arquivos presentes nos seus sistemas de +arquivos, com valores para cada um dos ambientes dos contêineres: + +``` +/etc/secret-volume/username +/etc/secret-volume/password +``` + + + +Observe como as `spec`s para cada um dos Pods diverge somente em um campo. Isso +facilita a criação de Pods com capacidades diferentes a partir de um template +mais genérico. + +Você pode simplificar ainda mais a definição básica do Pod através da utilização +de duas service accounts diferentes: + +1. `prod-user` com o Secret `prod-db-secret` +1. `test-user` com o Secret `test-db-secret` + +A especificação do Pod é reduzida para: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: prod-db-client-pod + labels: + name: prod-db-client +spec: + serviceAccount: prod-db-client + containers: + - name: db-client-container + image: myClientImage +``` + +### Caso de uso: _dotfiles_ em um volume de Secret + + + +Você pode fazer com que seus dados fiquem "ocultos" definindo uma chave que se +inicia com um ponto (`.`). Este tipo de chave representa um _dotfile_, ou +arquivo "oculto". Por exemplo, quando o Secret abaixo é montado em um volume, +`secret-volume`: + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: dotfile-secret +data: + .secret-file: dmFsdWUtMg0KDQo= +--- +apiVersion: v1 +kind: Pod +metadata: + name: secret-dotfiles-pod +spec: + volumes: + - name: secret-volume + secret: + secretName: dotfile-secret + containers: + - name: dotfile-test-container + image: k8s.gcr.io/busybox + command: + - ls + - "-l" + - "/etc/secret-volume" + volumeMounts: + - name: secret-volume + readOnly: true + mountPath: "/etc/secret-volume" +``` + + + +Este volume irá conter um único arquivo, chamado `.secret-file`, e o contêiner +`dotfile-test-container` terá este arquivo presente no caminho +`/etc/secret-volume/.secret-file`. + +{{< note >}} +Arquivos com nomes iniciados por um caractere de ponto são ocultos do resultado +do comando `ls -l`. Você precisa utilizar `ls -la` para vê-los ao listar o +conteúdo de um diretório. +{{< /note >}} + +### Caso de uso: Secret visível somente em um dos contêineres de um pod {#use-case-secret-visible-to-one-container-in-a-pod} + + + +Suponha que um programa necessita manipular requisições HTTP, executar regras +de negócio complexas e então assinar mensagens com HMAC. Devido à natureza +complexa da aplicação, pode haver um _exploit_ despercebido que lê arquivos +remotos no servidor e que poderia expor a chave privada para um invasor. + +Esta aplicação poderia ser dividida em dois processos, separados em dois +contêineres distintos: um contêiner de _front-end_, que manipula as interações +com o usuário e a lógica de negócio, mas não consegue ver a chave privada; e +um contêiner assinador, que vê a chave privada e responde a requisições simples +de assinatura do _front-end_ (por exemplo, através de rede local). + +Com essa abordagem particionada, um invasor agora precisa forçar o servidor de +aplicação a rodar comandos arbitrários, o que é mais difícil de ser feito do que +apenas ler um arquivo presente no disco. + + + +## Melhores práticas + +### Clientes que utilizam a API de Secrets + + + +Ao instalar aplicações que interajam com a API de Secrets, você deve limitar o +acesso utilizando [políticas de autorização](/docs/reference/access-authn-authz/authorization/) +como [RBAC](/docs/reference/access-authn-authz/rbac/). + + + +Secrets frequentemente contém valores com um espectro de importância, muitos dos +quais podem causar escalações dentro do Kubernetes (por exemplo, tokens de service +account) e de sistemas externos. Mesmo que um aplicativo individual possa +avaliar o poder do Secret com o qual espera interagir, outras aplicações dentro +do mesmo namespace podem tornar estas suposições inválidas. + + + +Por estas razões, as requisições `watch` (observar) e `list` (listar) de +Secrets dentro de um namespace são permissões extremamente poderosas e devem +ser evitadas, pois a listagem de Secrets permite a clientes inspecionar os +valores de todos os Secrets presentes naquele namespace. A habilidade de listar +e observar todos os Secrets em um cluster deve ser reservada somente para os +componentes mais privilegiados, que fazem parte do nível de aplicações de sistema. + + + +Aplicações que necessitam acessar a API de Secret devem realizar uma requisição +`get` nos Secrets que precisam. Isto permite que administradores restrinjam o +acesso a todos os Secrets, enquanto +[utilizam uma lista de autorização a instâncias individuais](/docs/reference/access-authn-authz/rbac/#referring-to-resources) +que a aplicação precise. + + + +Para melhor desempenho em uma requisição `get` repetitiva, clientes podem criar +objetos que referenciam o Secret e então utilizar a requisição `watch` neste +novo objeto, requisitanto o Secret novamente quando a referência mudar. +Além disso, uma [API de "observação em lotes"](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/bulk_watch.md) +para permitir a clientes observar recursos individuais também foi proposta e +provavelmente estará disponível em versões futuras do Kubernetes. + +## Propriedades de segurança + +### Proteções + + + +Como Secrets podem ser criados de forma independente de Pods que os utilizam, +há menos risco de um Secret ser exposto durante o fluxo de trabalho de criação, +visualização, e edição de Pods. O sistema pode também tomar precauções adicionais +com Secrets, como por exemplo evitar que sejam escritos em disco quando possível. + + + +Um Secret só é enviado para um nó se um Pod naquele nó requerê-lo. O kubelet +armazena o Secret num sistema de arquivos `tmpfs`, de forma a evitar que o Secret +seja escrito em armazenamento persistente. Uma vez que o Pod que depende do +Secret é removido, o kubelet apaga sua cópia local do Secret também. + + + +Secrets de vários Pods diferentes podem existir no mesmo nó. No entanto, somente +os Secrets que um Pod requerer estão potencialmente visíveis em seus contêineres. +Portanto, um Pod não tem acesso aos Secrets de outro Pod. + + + +Um Pod pode conter vários contêineres. Porém, cada contêiner em um Pod precisa +requerer o volume de Secret nos seus `volumeMounts` para que este fique visível +dentro do contêiner. Esta característica pode ser utilizada para construir +[partições de segurança ao nível do Pod](#use-case-secret-visible-to-one-container-in-a-pod). + + + +Na maioria das distribuições do Kubernetes, a comunicação entre usuários e o +servidor da API e entre servidor da API e os kubelets é protegida por SSL/TLS. +Secrets são protegidos quando transmitidos através destes canais. + +{{< feature-state for_k8s_version="v1.13" state="beta" >}} + + + +Você pode habilitar [encriptação em disco](/docs/tasks/administer-cluster/encrypt-data/) +em dados de Secret para evitar que estes sejam armazenados em texto plano no +{{< glossary_tooltip term_id="etcd" >}}. + +### Riscos + + + +- No servidor da API, os dados de Secret são armazenados no + {{< glossary_tooltip term_id="etcd" >}}; portanto: + - Administradores devem habilitar encriptação em disco para dados do cluster + (requer Kubernetes v1.13 ou posterior). + - Administradores devem limitar o acesso ao etcd somente para usuários + administradores. + - Administradores podem desejar apagar definitivamente ou destruir discos + previamente utilizados pelo etcd que não estiverem mais em uso. + - Ao executar o etcd em um cluster, administradores devem garantir o uso de + SSL/TLS para conexões ponto-a-ponto do etcd. +- Se você configurar um Secret utilizando um arquivo de manifesto (JSON ou + YAML) que contém os dados do Secret codificados como base64, compartilhar + este arquivo ou salvá-lo num sistema de controle de versão de código-fonte + compromete este Secret. Codificação base64 _não_ é um método de encriptação + e deve ser considerada idêntica a texto plano. +- Aplicações ainda precisam proteger o valor do Secret após lê-lo de um volume, + como por exemplo não escrever seu valor em logs ou enviá-lo para um sistema + não-confiável. +- Um usuário que consegue criar um Pod que utiliza um Secret também consegue + ler o valor daquele Secret. Mesmo que o servidor da API possua políticas para + impedir que aquele usuário leia o valor do Secret, o usuário poderia criar um + Pod que expõe o Secret. + +## {{% heading "whatsnext" %}} + + + +- Aprenda a [gerenciar Secrets utilizando `kubectl`](/pt-br/docs/tasks/configmap-secret/managing-secret-using-kubectl/) +- Aprenda a [gerenciar Secrets utilizando arquivos de configuração](/pt-br/docs/tasks/configmap-secret/managing-secret-using-config-file/) +- Aprenda a [gerenciar Secrets utilizando kustomize](/pt-br/docs/tasks/configmap-secret/managing-secret-using-kustomize/) +- Leia a [documentação de referência da API](/docs/reference/kubernetes-api/config-and-storage-resources/secret-v1/) de `Secrets` diff --git a/content/pt-br/docs/reference/glossary/configmap.md b/content/pt-br/docs/reference/glossary/configmap.md index a1ccdea668..4840cdb4ac 100644 --- a/content/pt-br/docs/reference/glossary/configmap.md +++ b/content/pt-br/docs/reference/glossary/configmap.md @@ -2,7 +2,7 @@ title: ConfigMap id: configmap date: 2021-08-24 -full_link: /docs/concepts/configuration/configmap +full_link: /pt-br/docs/concepts/configuration/configmap short_description: > Um objeto da API usado para armazenar dados não-confidenciais em pares chave-valor. Pode ser consumido como variáveis de ambiente, argumentos de linha de comando, ou arquivos de configuração em um volume. diff --git a/content/pt-br/docs/reference/glossary/container-env-variables.md b/content/pt-br/docs/reference/glossary/container-env-variables.md new file mode 100644 index 0000000000..620dee723c --- /dev/null +++ b/content/pt-br/docs/reference/glossary/container-env-variables.md @@ -0,0 +1,17 @@ +--- +title: Variáveis de Ambiente de Contêineres +id: container-env-variables +date: 2021-11-20 +full_link: /pt-br/docs/concepts/containers/container-environment/ +short_description: > + Variáveis de ambiente de contêineres são pares nome=valor que trazem informações úteis para os contêineres rodando dentro de um Pod. + +aka: +tags: +- fundamental +--- + Variáveis de ambiente de contêineres são pares nome=valor que trazem informações úteis para os contêineres rodando dentro de um {{< glossary_tooltip text="pod" term_id="Pod" >}} + + + +Variáveis de ambiente de contêineres fornecem informações requeridas pela aplicação conteinerizada, junto com informações sobre recursos importantes para o {{< glossary_tooltip text="contêiner" term_id="container" >}}. Por exemplo, detalhes do sistema de arquivos, informações sobre o contêiner, e outros recursos do cluster, como endpoints de serviços. diff --git a/content/pt-br/docs/reference/glossary/container.md b/content/pt-br/docs/reference/glossary/container.md new file mode 100644 index 0000000000..7e24fa5ad7 --- /dev/null +++ b/content/pt-br/docs/reference/glossary/container.md @@ -0,0 +1,19 @@ +--- +title: Contêiner +id: container +date: 2018-04-12 +full_link: /docs/concepts/containers/ +short_description: > + Uma imagem executável leve e portável que contém software e todas as suas dependências. + +aka: +tags: +- fundamental +- workload +--- + Uma imagem executável leve e portável que contém software e todas as suas dependências. + + + +Contêineres desacoplam aplicações da infraestrutura da máquina em que estas rodam para tornar a instalação mais fácil em diferentes ambientes de nuvem e de +sistemas operacionais, e para facilitar o escalonamento das aplicações. diff --git a/content/pt-br/docs/reference/glossary/secret.md b/content/pt-br/docs/reference/glossary/secret.md index abcd1bb421..b293f7acc4 100644 --- a/content/pt-br/docs/reference/glossary/secret.md +++ b/content/pt-br/docs/reference/glossary/secret.md @@ -2,7 +2,7 @@ title: Secret id: secret date: 2021-08-24 -full_link: /docs/concepts/configuration/secret/ +full_link: /pt-br/docs/concepts/configuration/secret/ short_description: > Armazena dados sensíveis, como senhas, tokens OAuth e chaves SSH. From 9cf1da909660d9de51c1bf723be781f07ce6efa1 Mon Sep 17 00:00:00 2001 From: Mauren Berti Date: Mon, 29 Nov 2021 20:58:39 -0500 Subject: [PATCH 28/32] Fix typo on translation. --- content/pt-br/docs/concepts/configuration/secret.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/pt-br/docs/concepts/configuration/secret.md b/content/pt-br/docs/concepts/configuration/secret.md index 013075c852..a15a93cd70 100644 --- a/content/pt-br/docs/concepts/configuration/secret.md +++ b/content/pt-br/docs/concepts/configuration/secret.md @@ -2005,7 +2005,7 @@ be available in future releases of Kubernetes. Para melhor desempenho em uma requisição `get` repetitiva, clientes podem criar objetos que referenciam o Secret e então utilizar a requisição `watch` neste -novo objeto, requisitanto o Secret novamente quando a referência mudar. +novo objeto, requisitando o Secret novamente quando a referência mudar. Além disso, uma [API de "observação em lotes"](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/bulk_watch.md) para permitir a clientes observar recursos individuais também foi proposta e provavelmente estará disponível em versões futuras do Kubernetes. From 735c85364bb254d92a280f2914544abe1b026169 Mon Sep 17 00:00:00 2001 From: Mauren Berti Date: Thu, 6 Jan 2022 19:28:08 -0500 Subject: [PATCH 29/32] Remove comment blocks with original content. --- .../docs/concepts/configuration/secret.md | 775 +----------------- 1 file changed, 2 insertions(+), 773 deletions(-) diff --git a/content/pt-br/docs/concepts/configuration/secret.md b/content/pt-br/docs/concepts/configuration/secret.md index a15a93cd70..1638aa4faf 100644 --- a/content/pt-br/docs/concepts/configuration/secret.md +++ b/content/pt-br/docs/concepts/configuration/secret.md @@ -39,14 +39,6 @@ circunstâncias, ser colocada diretamente em uma configuração de {{< glossary_tooltip text="imagem de contêiner" term_id="image" >}}. O uso de Secrets evita que você tenha de incluir dados confidenciais no seu código. - - Secrets podem ser criados de forma independente dos Pods que os consomem. Isto reduz o risco de que o Secret e seus dados sejam expostos durante o processo de criação, visualização e edição ou atualização de Pods. O Kubernetes e as @@ -54,30 +46,10 @@ aplicações que rodam no seu cluster podem também tomar outras precauções co Secrets, como por exemplo evitar a escrita de dados confidenciais em local de armazenamento persistente (não-volátil). - - Secrets são semelhantes a {{< glossary_tooltip text="ConfigMaps" term_id="configmap" >}}, mas foram especificamente projetados para conter dados confidenciais. - - {{< caution >}} Os Secrets do Kubernetes são, por padrão, gravados não-encriptados no sistema de armazenamento de dados utilizado pelo servidor da API (etcd). Qualquer pessoa @@ -100,17 +72,6 @@ existentes. ## Visão Geral de Secrets - - Para utilizar um Secret, um Pod precisa referenciar o Secret. Um Secret pode ser utilizado em um Pod de três maneiras diferentes: - Como um [arquivo](#using-secrets-as-files-from-a-pod) em um @@ -121,26 +82,10 @@ contêiner. - Pelo [kubelet ao baixar imagens de contêiner](#using-imagepullsecrets) para o Pod. - - A camada de gerenciamento do Kubernetes também utiliza Secrets. Por exemplo, os [Secrets de tokens de autoinicialização](#bootstrap-token-secrets) são um mecanismo que auxilia a automação do registro de nós. - - O nome de um Secret deve ser um [subdomínio DNS válido](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). Você pode especificar o campo `data` e/ou o campo `stringData` na criação de um arquivo de configuração de um Secret. Ambos os campos `data` e `stringData` são @@ -149,14 +94,6 @@ no formato base64. Se a conversão para base64 não for desejável, você pode optar por informar os dados no campo `stringData`, que aceita strings arbitrárias como valores. - - As chaves dos campos `data` e `stringData` devem consistir de caracteres alfanuméricos, `-`, `_`, ou `.`. Todos os pares chave-valor no campo `stringData` são internamente combinados com os dados do campo `data`. Se uma chave aparece @@ -164,41 +101,15 @@ em ambos os campos, o valor informado no campo `stringData` toma a precedência. ## Tipos de Secrets {#secret-types} - - Ao criar um Secret, você pode especificar o seu tipo utilizando o campo `type` do objeto Secret, ou algumas opções de linha de comando equivalentes no comando `kubectl`, quando disponíveis. O campo `type` de um Secret é utilizado para facilitar a manipulação programática de diferentes tipos de dados confidenciais. - - O Kubernetes oferece vários tipos embutidos de Secret para casos de uso comuns. Estes tipos variam em termos de validações efetuadas e limitações que o Kubernetes impõe neles. - - | Tipo embutido | Caso de uso | |----------------------------------------|----------------------------------------------------| | `Opaque` | dados arbitrários definidos pelo usuário | @@ -210,14 +121,6 @@ Kubernetes impõe neles. | `kubernetes.io/tls` | dados para um cliente ou servidor TLS | | `bootstrap.kubernetes.io/token` | dados de token de autoinicialização | - - Você pode definir e utilizar seu próprio tipo de Secret definindo o valor do campo `type` como uma string não-nula em um objeto Secret. Uma string em branco é tratada como o tipo `Opaque`. O Kubernetes não restringe nomes de tipos. No @@ -226,13 +129,6 @@ requisitos daquele tipo. ### Secrets tipo Opaque - - `Opaque` é o tipo predefinido de Secret quando o campo `type` não é informado em um arquivo de configuração. Quando um Secret é criado usando o comando `kubectl`, você deve usar o subcomando `generic` para indicar que um Secret é @@ -242,7 +138,7 @@ do tipo `Opaque`. Por exemplo, o comando a seguir cria um Secret vazio do tipo kubectl create secret generic empty-secret kubectl get secret empty-secret ``` - + O resultado será semelhante ao abaixo: ``` @@ -250,25 +146,11 @@ NAME TYPE DATA AGE empty-secret Opaque 0 2m6s ``` - - A coluna `DATA` demonstra a quantidade de dados armazenados no Secret. Neste caso, `0` significa que este objeto Secret está vazio. ### Secrets de token de service account (conta de serviço) - - Secrets do tipo `kubernetes.io/service-account-token` são utilizados para armazenar um token que identifica uma service account (conta de serviço). Ao utilizar este tipo de Secret, você deve garantir que a anotação @@ -277,7 +159,6 @@ existente. Um controlador do Kubernetes preenche outros campos, como por exemplo a anotação `kubernetes.io/service-account.uid` e a chave `token` no campo `data` com o conteúdo do token. - O exemplo de configuração abaixo declara um Secret de token de service account: ```yaml @@ -294,36 +175,15 @@ data: extra: YmFyCg== ``` - - Ao criar um {{< glossary_tooltip text="Pod" term_id="pod" >}}, o Kubernetes automaticamente cria um Secret de service account e automaticamente atualiza o seu Pod para utilizar este Secret. O Secret de token de service account contém credenciais para acessar a API. - - A criação automática e o uso de credenciais de API podem ser desativados se desejado. Porém, se tudo que você necessita é poder acessar o servidor da API de forma segura, este é o processo recomendado. - - Veja a documentação de [ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/) para mais informações sobre o funcionamento de service accounts. Você pode @@ -333,39 +193,18 @@ para mais informações sobre como referenciar service accounts em Pods. ### Secrets de configuração do Docker - - Você pode utilizar um dos tipos abaixo para criar um Secret que armazena credenciais para accesso a um registro de contêineres compatível com Docker para busca de imagens: - `kubernetes.io/dockercfg` - `kubernetes.io/dockerconfigjson` - O tipo `kubernetes.io/dockercfg` é reservado para armazenamento de um arquivo `~/.dockercfg` serializado. Este arquivo é o formato legado para configuração do utilitário de linha de comando do Docker. Ao utilizar este tipo de Secret, é preciso garantir que o campo `data` contém uma chave `.dockercfg` cujo valor é o conteúdo do arquivo `~/.dockercfg` codificado no formato base64. - - O tipo `kubernetes.io/dockerconfigjson` foi projetado para armazenamento de um conteúdo JSON serializado que obedece às mesmas regras de formato que o arquivo `~/.docker/config.json`. Este arquivo é um formato mais moderno para o conteúdo @@ -373,8 +212,6 @@ do arquivo `~/.dockercfg`. Ao utilizar este tipo de Secret, o conteúdo do campo `data` deve conter uma chave `.dockerconfigjson` em que o conteúdo do arquivo `~/.docker/config.json` é fornecido codificado no formato base64. - - Um exemplo de um Secret do tipo `kubernetes.io/dockercfg`: ```yaml apiVersion: v1 @@ -387,35 +224,16 @@ data: "" ``` - - {{< note >}} Se você não desejar fazer a codificação em formato base64, você pode utilizar o campo `stringData` como alternativa. {{< /note >}} - - Ao criar estes tipos de Secret utilizando um manifesto (arquivo YAML), o servidor da API verifica se a chave esperada existe no campo `data` e se o valor fornecido pode ser interpretado como um conteúdo JSON válido. O servidor da API não verifica se o conteúdo informado é realmente um arquivo de configuração do Docker. - - Quando você não tem um arquivo de configuração do Docker, ou quer utilizar o comando `kubectl` para criar um Secret de registro de contêineres compatível com o Docker, você pode executar: @@ -427,13 +245,6 @@ kubectl create secret docker-registry secret-tiger-docker \ --docker-server=my-registry.example:5000 ``` - - Esse comando cria um secret do tipo `kubernetes.io/dockerconfigjson`, cujo conteúdo é semelhante ao exemplo abaixo: @@ -474,29 +285,12 @@ que é uma configuração válida do Docker criada automaticamente: ### Secret de autenticação básica - - O tipo `kubernetes.io/basic-auth` é fornecido para armazenar credenciais necessárias para autenticação básica. Ao utilizar este tipo de Secret, o campo `data` do Secret deve conter as duas chaves abaixo: - `username`: o usuário utilizado para autenticação; - `password`: a senha ou token para autenticação. - - Ambos os valores para estas duas chaves são textos codificados em formato base64. Você pode fornecer os valores como texto simples utilizando o campo `stringData` na criação do Secret. @@ -514,14 +308,6 @@ stringData: password: t0p-Secret ``` - - O tipo de autenticação básica é fornecido unicamente por conveniência. Você pode criar um Secret do tipo `Opaque` utilizado para autenticação básica. No entanto, utilizar o tipo embutido de Secret auxilia a unificação dos formatos das suas @@ -530,15 +316,6 @@ requeridas pelo servidor da API. ### Secret de autenticação SSH - - O tipo embutido `kubernetes.io/ssh-auth` é fornecido para armazenamento de dados utilizados em autenticação SSH. Ao utilizar este tipo de Secret, você deve especificar um par de chave-valor `ssh-privatekey` no campo `data` ou no campo @@ -558,29 +335,12 @@ data: MIIEpQIBAAKCAQEAulqb/Y ... ``` - - O Secret de autenticação SSH é fornecido apenas para a conveniência do usuário. Você pode criar um Secret do tipo `Opaque` para credentials utilizadas para autenticação SSH. No entanto, a utilização do tipo embutido auxilia na unificação dos formatos das suas credenciais e o servidor da API fornece verificação dos campos requeridos em uma configuração de Secret. - - {{< caution >}} Chaves privadas SSH não estabelecem, por si só, uma comunicação confiável entre um cliente SSH e um servidor. Uma forma secundária de estabelecer @@ -590,18 +350,6 @@ por exemplo um arquivo `known_hosts` adicionado a um ConfigMap. ### Secrets TLS - - O Kubernetes fornece o tipo embutido de Secret `kubernetes.io/tls` para armazenamento de um certificado e sua chave associada que são tipicamente utilizados para TLS. Estes dados são utilizados primariamente para a @@ -626,16 +374,6 @@ data: MIIEpgIBAAKCAQEA7yn3bRHQ5FHMQ ... ``` - - O tipo TLS é fornecido para a conveniência do usuário. Você pode criar um Secret do tipo `Opaque` para credenciais utilizadas para o servidor e/ou cliente TLS. No entanto, a utilização do tipo embutido auxilia a manter a @@ -650,16 +388,6 @@ kubectl create secret tls my-tls-secret \ --key=path/to/key/file ``` - - O par de chaves pública/privada deve ser criado separadamente. O certificado de chave pública a ser utilizado no argumento `--cert` deve ser codificado em formato .PEM (formato DER codificado em texto base64) e deve corresponder à @@ -671,20 +399,6 @@ certificado) *não* são incluídas. ### Secret de token de autoinicialização {#bootstrap-token-secrets} - - Um Secret de token de autoinicialização pode ser criado especificando o tipo de um Secret explicitamente com o valor `bootstrap.kubernetes.io/token`. Este tipo de Secret é projetado para tokens utilizados durante o processo de inicialização @@ -713,24 +427,6 @@ data: usage-bootstrap-signing: dHJ1ZQ== ``` - - Um Secret do tipo token de autoinicialização possui as seguintes chaves no campo `data`: - `token-id`: Uma string com 6 caracteres aleatórios como identificador do @@ -772,14 +468,6 @@ stringData: ## Criando um Secret - - Há várias formas diferentes de criar um Secret: - [criar um Secret utilizando o comando `kubectl`](/pt-br/docs/tasks/configmap-secret/managing-secret-using-kubectl/) - [criar um Secret a partir de um arquivo de configuração](/pt-br/docs/tasks/configmap-secret/managing-secret-using-config-file/) @@ -787,16 +475,11 @@ Há várias formas diferentes de criar um Secret: ## Editando um Secret - Um Secret existente no cluster pode ser editado com o seguinte comando: ```shell kubectl edit secrets mysecret ``` - - Este comando abrirá o editor padrão configurado e permitirá a modificação dos valores codificados em base64 no campo `data`: ```yaml @@ -822,15 +505,6 @@ type: Opaque ## Utilizando Secrets - - Secrets podem ser montados como volumes de dados ou expostos como {{< glossary_tooltip text="variáveis de ambiente" term_id="container-env-variables" >}} para serem utilizados num container de um Pod. Secrets também podem ser @@ -840,17 +514,6 @@ utilizar para interagir com sistemas externos no lugar do usuário. ### Utilizando Secrets como arquivos em um Pod {#using-secrets-as-files-from-a-pod} - - Para consumir um Secret em um volume em um Pod: 1. Crie um Secret ou utilize um previamente existente. Múltiplos Pods podem referenciar o mesmo secret. @@ -887,15 +550,6 @@ spec: secretName: mysecret ``` - - Cada Secret que você deseja utilizar deve ser referenciado na lista `.spec.volumes`. @@ -908,10 +562,6 @@ distintos, o que for mais conveniente. #### Projeção de chaves de Secrets a caminhos específicos - Você pode também controlar os caminhos dentro do volume onde as chaves do Secret são projetadas. Você pode utilizar o campo `.spec.volumes[].secret.items` para mudar o caminho de destino de cada chave: @@ -938,17 +588,6 @@ spec: path: my-group/my-username ``` - - Neste caso: * O valor da chave `username` é armazenado no arquivo `/etc/foo/my-group/my-username` ao invés de `/etc/foo/username`. @@ -961,14 +600,6 @@ existir no Secret correspondente. Caso contrário, o volume não é criado. #### Permissões de arquivos de Secret - - Você pode trocar os bits de permissão de uma chave avulsa de Secret. Se nenhuma permissão for especificada, `0644` é utilizado por padrão. Você pode também especificar uma permissão padrão para o volume inteiro de @@ -994,20 +625,6 @@ spec: defaultMode: 0400 ``` - - Dessa forma, o Secret será montado em `/etc/foo` e todos os arquivos criados no volume terão a permissão `0400`. @@ -1027,7 +644,6 @@ cd /etc/foo ls -l ``` - O resultado é semelhante ao abaixo: ``` total 0 @@ -1035,14 +651,12 @@ lrwxrwxrwx 1 root root 15 May 18 00:18 password -> ..data/password lrwxrwxrwx 1 root root 15 May 18 00:18 username -> ..data/username ``` - Siga o vínculo simbólico para encontrar a permissão correta do arquivo. ``` cd /etc/foo/..data ls -l ``` - O resultado é semelhante ao abaixo: ``` total 8 @@ -1050,11 +664,6 @@ total 8 -r-------- 1 root root 5 May 18 00:18 username ``` - - Você pode também utilizar mapeamento, como no exemplo anterior, e especificar permissões diferentes para arquivos diferentes conforme abaixo: ```yaml @@ -1079,15 +688,6 @@ spec: mode: 0777 ``` - - Neste caso, o arquivo resultante em `/etc/foo/my-group/my-username` terá as permissões `0777`. Se você utilizar JSON, devido às limitações do formato, você precisará informar as permissões em base decimal, ou o valor `511` neste @@ -1098,12 +698,6 @@ ler essa informação posteriormente. #### Consumindo valores de Secrets em volumes - - Dentro do contêiner que monta um volume de Secret, as chaves deste Secret aparecem como arquivos e os valores dos Secrets são decodificados do formato base64 e armazenados dentro destes arquivos. Ao executar comandos dentro do @@ -1113,7 +707,6 @@ contêiner do exemplo anterior, obteremos os seguintes resultados: ls /etc/foo ``` - O resultado é semelhante a: ``` username @@ -1124,7 +717,6 @@ password cat /etc/foo/username ``` - O resultado é semelhante a: ``` admin @@ -1134,36 +726,16 @@ admin cat /etc/foo/password ``` - O resultado é semelhante a: ``` 1f2d1e2e67df ``` - - A aplicação rodando dentro do contêiner é responsável pela leitura dos Secrets dentro dos arquivos. #### Secrets montados são atualizados automaticamente - - Quando um Secret que está sendo consumido a partir de um volume é atualizado, as chaves projetadas são atualizadas após algum tempo também. O kubelet verifica se o Secret montado está atualizado a cada sincronização periódica. No entanto, @@ -1182,14 +754,6 @@ propagação do cache, onde o tempo de propagação do cache depende do tipo de cache escolhido: o tempo de propagação pode ser igual ao tempo de propagação do _watch_, TTL do cache, ou zero, de acordo com cada um dos tipos de cache. - - {{< note >}} Um contêiner que utiliza Secrets através de um ponto de montagem com a propriedade @@ -1199,17 +763,6 @@ deste Secret. ### Utilizando Secrets como variáveis de ambiente {#using-secrets-as-environment-variables} - - Para utilizar um secret em uma {{< glossary_tooltip text="variável de ambiente" term_id="container-env-variables" >}} em um Pod: @@ -1250,12 +803,6 @@ spec: #### Consumindo valores de Secret em variáveis de ambiente - - Dentro de um contêiner que consome um Secret em variáveis de ambiente, a chave do Secret aparece como uma variável de ambiente comum, contendo os dados do Secret decodificados do formato base64. Ao executar comandos no contêiner do @@ -1265,7 +812,6 @@ exemplo anterior, obteremos os resultados abaixo: echo $SECRET_USERNAME ``` - O resultado é semelhante a: ``` @@ -1275,7 +821,7 @@ admin ```shell echo $SECRET_PASSWORD ``` - + O resultado é semelhante a: ``` @@ -1284,11 +830,6 @@ O resultado é semelhante a: #### Variáveis de ambiente não são atualizadas após uma atualização no Secret - - Se um contêiner já consome um Secret em uma variável de ambiente, uma atualização dos valores do Secret não será refletida no contêiner a menos que o contêiner seja reiniciado. @@ -1299,16 +840,6 @@ quando Secrets são atualizados. {{< feature-state for_k8s_version="v1.21" state="stable" >}} - - A funcionalidade do Kubernetes _Secrets e ConfigMaps imutáveis_ fornece uma opção para marcar Secrets e ConfigMaps individuais como imutáveis. Em clusters que fazem uso extensivo de Secrets (pelo menos dezenas de milhares de montagens @@ -1320,13 +851,6 @@ disrupções na execução de aplicações; no kube-apiserver, devido ao fechamento de _watches_ de Secrets marcados como imutáveis. - - Esta funcionalidade é controlada pelo [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `ImmutableEphemeralVolumes`, que está habilitado por padrão desde a versão @@ -1342,15 +866,6 @@ data: immutable: true ``` - - {{< note >}} Uma vez que um Secret ou ConfigMap seja marcado como imutável, _não_ é mais possível reverter esta mudança, nem alterar os conteúdos do campo `data`. Você @@ -1360,13 +875,6 @@ montagem referenciando o Secret removido - é recomendado recriar tais Pods. ### Usando `imagePullSecrets` {#using-imagepullsecrets} - - O campo `imagePullSecrets` é uma lista de referências para Secrets no mesmo namespace. Você pode utilizar a lista `imagePullSecrets` para enviar Secrets que contém uma senha para acesso a um registro de contêineres do Docker (ou @@ -1377,24 +885,11 @@ para maiores detalhes sobre o campo `imagePullSecrets`. #### Especificando `imagePullSecrets` manualmente - - Você pode ler sobre como especificar `imagePullSecrets` em um Pod na [documentação de imagens de contêiner](/pt-br/docs/concepts/containers/images/#especificando-imagepullsecrets-em-um-pod). ### Configurando `imagePullSecrets` para serem vinculados automaticamente - - Você pode criar manualmente `imagePullSecrets` e referenciá-los em uma ServiceAccount. Quaisquer Pods criados com esta ServiceAccount, especificada explicitamente ou por padrão, têm o campo `imagePullSecrets` populado com os @@ -1406,48 +901,19 @@ para uma explicação detalhada do processo. ### Restrições - - Referências a Secrets em volumes são validadas para garantir que o objeto especificado realmente existe e é um objeto do tipo Secret. Portanto, um Secret precisa ser criado antes de quaisquer Pods que dependam deste. - - Objetos Secret residem em um {{< glossary_tooltip text="namespace" term_id="namespace" >}}. Secrets podem ser referenciados somente por Pods no mesmo namespace. - - Secrets individuais são limitados ao tamanho de 1MiB. Esta limitação ter por objetivo desencorajar a criação de Secrets muito grandes que poderiam exaurir a memória do servidor da API e do kubelet. No entanto, a criação de muitos Secrets pequenos também pode exaurir a memória. Limites mais completos de uso de memória em função de Secrets é uma funcionalidade prevista para o futuro. - - O kubelet suporta apenas o uso de Secrets em Pods onde os Secrets são obtidos do servidor da API. Isso inclui quaisquer Pods criados usando o comando `kubectl`, ou indiretamente através de um controlador de replicação, mas não @@ -1456,33 +922,13 @@ kubelet, ou a sua API REST (estas são formas incomuns de criar um Pod). A `spec` de um {{< glossary_tooltip text="Pod estático" term_id="static-pod" >}} não pode se referir a um Secret ou a qualquer outro objeto da API. - - Secrets precisam ser criados antes de serem consumidos em Pods como variáveis de ambiente, exceto quando são marcados como opcionais. Referências a Secrets que não existem provocam falhas na inicialização do Pod. - - Referências (campo `secretKeyRef`) a chaves que não existem em um Secret nomeado provocam falhas na inicialização do Pod. - - Secrets utilizados para popular variáveis de ambiente através do campo `envFrom` que contém chaves inválidas para utilização como nome de uma variável de ambiente terão tais chaves ignoradas. O Pod inicializará normalmente. Porém, um evento @@ -1495,7 +941,6 @@ refere ao Secret default/mysecret, contendo duas chaves inválidas: `1badkey` e kubectl get events ``` - O resultado é semelhante a: ``` @@ -1505,17 +950,6 @@ LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT ### Interações do ciclo de vida entre Secrets e Pods - - Quando um Pod é criado através de chamadas à API do Kubernetes, não há validação da existência de um Secret referenciado. Uma vez que um Pod seja agendado, o kubelet tentará buscar o valor do Secret. Se o Secret não puder ser encontrado @@ -1530,7 +964,6 @@ do Pod irá iniciar até que todos os volumes estejam montados. ### Caso de uso: Como variáveis de ambiente em um contêiner - Crie um manifesto de Secret ```yaml @@ -1544,16 +977,12 @@ data: PASSWORD: MWYyZDFlMmU2N2Rm ``` - Crie o Secret no seu cluster: ```shell kubectl apply -f mysecret.yaml ``` - Utilize `envFrom` para definir todos os dados do Secret como variáveis de ambiente do contêiner. Cada chave do Secret se torna o nome de uma variável de ambiente no Pod. @@ -1576,31 +1005,18 @@ spec: ### Caso de uso: Pod com chaves SSH - Crie um Secret contendo chaves SSH: ```shell kubectl create secret generic ssh-key-secret --from-file=ssh-privatekey=/path/to/.ssh/id_rsa --from-file=ssh-publickey=/path/to/.ssh/id_rsa.pub ``` - O resultado é semelhante a: ``` secret "ssh-key-secret" created ``` - - Você também pode criar um manifesto `kustomization.yaml` com um campo `secretGenerator` contendo chaves SSH. @@ -1636,7 +1052,6 @@ spec: mountPath: "/etc/secret-volume" ``` - Ao rodar o comando do contêiner, as partes da chave estarão disponíveis em: ``` @@ -1644,24 +1059,11 @@ Ao rodar o comando do contêiner, as partes da chave estarão disponíveis em: /etc/secret-volume/ssh-privatekey ``` - - O contêiner então pode utilizar os dados do secret para estabelecer uma conexão SSH. ### Caso de uso: Pods com credenciais de ambientes de produção ou testes - - Este exemplo ilustra um Pod que consome um Secret contendo credenciais de um ambiente de produção e outro Pod que consome um Secret contendo credenciais de um ambiente de testes. @@ -1673,43 +1075,24 @@ rodar `kubectl create secret`. kubectl create secret generic prod-db-secret --from-literal=username=produser --from-literal=password=Y4nys7f11 ``` - O resultado é semelhante a: ``` secret "prod-db-secret" created ``` - Você pode também criar um Secret com credenciais para o ambiente de testes. ```shell kubectl create secret generic test-db-secret --from-literal=username=testuser --from-literal=password=iluvtests ``` - O resultado é semelhante a: ``` secret "test-db-secret" created ``` - - {{< note >}} Caracteres especiais como `$`, `\`, `*`, `+` e `!` serão interpretados pelo seu [shell](https://pt.wikipedia.org/wiki/Shell_(computa%C3%A7%C3%A3o)) e precisam de @@ -1772,7 +1155,6 @@ items: EOF ``` - Adicione os Pods a um manifesto `kustomization.yaml`: ```shell @@ -1782,17 +1164,12 @@ resources: EOF ``` - Crie todos estes objetos no servidor da API rodando o comando: ```shell kubectl apply -k . ``` - - Ambos os contêineres terão os seguintes arquivos presentes nos seus sistemas de arquivos, com valores para cada um dos ambientes dos contêineres: @@ -1801,18 +1178,6 @@ arquivos, com valores para cada um dos ambientes dos contêineres: /etc/secret-volume/password ``` - - Observe como as `spec`s para cada um dos Pods diverge somente em um campo. Isso facilita a criação de Pods com capacidades diferentes a partir de um template mais genérico. @@ -1841,12 +1206,6 @@ spec: ### Caso de uso: _dotfiles_ em um volume de Secret - - Você pode fazer com que seus dados fiquem "ocultos" definindo uma chave que se inicia com um ponto (`.`). Este tipo de chave representa um _dotfile_, ou arquivo "oculto". Por exemplo, quando o Secret abaixo é montado em um volume, @@ -1882,17 +1241,6 @@ spec: mountPath: "/etc/secret-volume" ``` - - Este volume irá conter um único arquivo, chamado `.secret-file`, e o contêiner `dotfile-test-container` terá este arquivo presente no caminho `/etc/secret-volume/.secret-file`. @@ -1905,22 +1253,6 @@ conteúdo de um diretório. ### Caso de uso: Secret visível somente em um dos contêineres de um pod {#use-case-secret-visible-to-one-container-in-a-pod} - - Suponha que um programa necessita manipular requisições HTTP, executar regras de negócio complexas e então assinar mensagens com HMAC. Devido à natureza complexa da aplicação, pode haver um _exploit_ despercebido que lê arquivos @@ -1942,39 +1274,16 @@ apenas ler um arquivo presente no disco. ### Clientes que utilizam a API de Secrets - - Ao instalar aplicações que interajam com a API de Secrets, você deve limitar o acesso utilizando [políticas de autorização](/docs/reference/access-authn-authz/authorization/) como [RBAC](/docs/reference/access-authn-authz/rbac/). - - Secrets frequentemente contém valores com um espectro de importância, muitos dos quais podem causar escalações dentro do Kubernetes (por exemplo, tokens de service account) e de sistemas externos. Mesmo que um aplicativo individual possa avaliar o poder do Secret com o qual espera interagir, outras aplicações dentro do mesmo namespace podem tornar estas suposições inválidas. - - Por estas razões, as requisições `watch` (observar) e `list` (listar) de Secrets dentro de um namespace são permissões extremamente poderosas e devem ser evitadas, pois a listagem de Secrets permite a clientes inspecionar os @@ -1982,27 +1291,12 @@ valores de todos os Secrets presentes naquele namespace. A habilidade de listar e observar todos os Secrets em um cluster deve ser reservada somente para os componentes mais privilegiados, que fazem parte do nível de aplicações de sistema. - - Aplicações que necessitam acessar a API de Secret devem realizar uma requisição `get` nos Secrets que precisam. Isto permite que administradores restrinjam o acesso a todos os Secrets, enquanto [utilizam uma lista de autorização a instâncias individuais](/docs/reference/access-authn-authz/rbac/#referring-to-resources) que a aplicação precise. - - Para melhor desempenho em uma requisição `get` repetitiva, clientes podem criar objetos que referenciam o Secret e então utilizar a requisição `watch` neste novo objeto, requisitando o Secret novamente quando a referência mudar. @@ -2014,95 +1308,37 @@ provavelmente estará disponível em versões futuras do Kubernetes. ### Proteções - - Como Secrets podem ser criados de forma independente de Pods que os utilizam, há menos risco de um Secret ser exposto durante o fluxo de trabalho de criação, visualização, e edição de Pods. O sistema pode também tomar precauções adicionais com Secrets, como por exemplo evitar que sejam escritos em disco quando possível. - - Um Secret só é enviado para um nó se um Pod naquele nó requerê-lo. O kubelet armazena o Secret num sistema de arquivos `tmpfs`, de forma a evitar que o Secret seja escrito em armazenamento persistente. Uma vez que o Pod que depende do Secret é removido, o kubelet apaga sua cópia local do Secret também. - - Secrets de vários Pods diferentes podem existir no mesmo nó. No entanto, somente os Secrets que um Pod requerer estão potencialmente visíveis em seus contêineres. Portanto, um Pod não tem acesso aos Secrets de outro Pod. - - Um Pod pode conter vários contêineres. Porém, cada contêiner em um Pod precisa requerer o volume de Secret nos seus `volumeMounts` para que este fique visível dentro do contêiner. Esta característica pode ser utilizada para construir [partições de segurança ao nível do Pod](#use-case-secret-visible-to-one-container-in-a-pod). - - Na maioria das distribuições do Kubernetes, a comunicação entre usuários e o servidor da API e entre servidor da API e os kubelets é protegida por SSL/TLS. Secrets são protegidos quando transmitidos através destes canais. {{< feature-state for_k8s_version="v1.13" state="beta" >}} - - Você pode habilitar [encriptação em disco](/docs/tasks/administer-cluster/encrypt-data/) em dados de Secret para evitar que estes sejam armazenados em texto plano no {{< glossary_tooltip term_id="etcd" >}}. ### Riscos - - - No servidor da API, os dados de Secret são armazenados no {{< glossary_tooltip term_id="etcd" >}}; portanto: - Administradores devem habilitar encriptação em disco para dados do cluster @@ -2128,13 +1364,6 @@ em dados de Secret para evitar que estes sejam armazenados em texto plano no ## {{% heading "whatsnext" %}} - - - Aprenda a [gerenciar Secrets utilizando `kubectl`](/pt-br/docs/tasks/configmap-secret/managing-secret-using-kubectl/) - Aprenda a [gerenciar Secrets utilizando arquivos de configuração](/pt-br/docs/tasks/configmap-secret/managing-secret-using-config-file/) - Aprenda a [gerenciar Secrets utilizando kustomize](/pt-br/docs/tasks/configmap-secret/managing-secret-using-kustomize/) From 6708e86c6e574f3c867debf9d58d1fc072d2f0a7 Mon Sep 17 00:00:00 2001 From: Mauren Berti Date: Thu, 6 Jan 2022 19:33:47 -0500 Subject: [PATCH 30/32] Remove comment blocks with original content. --- .../docs/concepts/configuration/secret.md | 21 ------------------- 1 file changed, 21 deletions(-) diff --git a/content/pt-br/docs/concepts/configuration/secret.md b/content/pt-br/docs/concepts/configuration/secret.md index 1638aa4faf..bd0cd7315d 100644 --- a/content/pt-br/docs/concepts/configuration/secret.md +++ b/content/pt-br/docs/concepts/configuration/secret.md @@ -9,29 +9,8 @@ feature: weight: 30 --- - - - - Um Secret é um objeto que contém uma pequena quantidade de informação sensível, como senhas, tokens ou chaves. Este tipo de informação poderia, em outras circunstâncias, ser colocada diretamente em uma configuração de From 2546d6439738cd6df3dfd9d30612ee3d5e3fad48 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E5=B8=85=E8=BF=9B=E8=B6=85?= Date: Wed, 5 Jan 2022 22:42:59 +0800 Subject: [PATCH 31/32] [zh] synchronize translate check-if-dockershim-deprecation-affects-you.md --- ...k-if-dockershim-deprecation-affects-you.md | 35 ++++++++++++------- 1 file changed, 22 insertions(+), 13 deletions(-) diff --git a/content/zh/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you.md b/content/zh/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you.md index c1cf73c96e..bb77882ad1 100644 --- a/content/zh/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you.md +++ b/content/zh/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you.md @@ -52,35 +52,44 @@ dependency on Docker: 当用了替代的容器运行时之后，Docker 命令可能不工作，甚至产生意外的输出。 这才是判定你是否依赖于 Docker 的方法。 - -1. 确认没有特权 Pod 执行 docker 命令。 -2. 检查 Kubernetes 基础架构外部节点上的脚本和应用，确认它们没有执行 Docker 命令。可能的命令有： +--> +1. 确认没有特权 Pod 执行 Docker 命令（如 `docker ps`）、重新启动 Docker + 服务（如 `systemctl restart docker.service`）或修改 + Docker 配置文件 `/etc/docker/daemon.json`。 +2. 检查 Docker 配置文件（如 `/etc/docker/daemon.json`）中容器镜像仓库的镜像（mirror）站点设置。 + 这些配置通常需要针对不同容器运行时来重新设置。 +3. 检查确保在 Kubernetes 基础设施之外的节点上运行的脚本和应用程序没有执行Docker命令。 + 可能的情况如： - SSH 到节点排查故障； - 节点启动脚本； - - 直接安装在节点上的监视和安全代理。 -3. 检查执行了上述特权操作的第三方工具。详细操作请参考: - [从 dockershim 迁移遥测和安全代理](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents/) -4. 确认没有对 dockershim 行为的间接依赖。这是一种极端情况，不太可能影响你的应用。 + - 直接安装在节点上的监控和安全代理。 +4. 检查执行上述特权操作的第三方工具。详细操作请参考： + [从 dockershim 迁移遥测和安全代理](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents) +5. 确认没有对 dockershim 行为的间接依赖。这是一种极端情况，不太可能影响你的应用。 一些工具很可能被配置为使用了 Docker 特性，比如，基于特定指标发警报，或者在故障排查指令的一个环节中搜索特定的日志信息。 如果你有此类配置的工具，需要在迁移之前，在测试集群上完成功能验证。 - From 4bb3f367a261293e7044ff169a93f3a91d1bec82 Mon Sep 17 00:00:00 2001 From: Priyanka Saggu Date: Wed, 5 Jan 2022 13:46:16 +0530 Subject: [PATCH 32/32] blog: meet our contributors APAC India region --- ...t-our-contributors-APAC-India-region-01.md | 106 ++++++++++++++++++ 1 file changed, 106 insertions(+) create mode 100644 content/en/blog/_posts/2022-01-10-meet-our-contributors-APAC-India-region-01.md diff --git a/content/en/blog/_posts/2022-01-10-meet-our-contributors-APAC-India-region-01.md b/content/en/blog/_posts/2022-01-10-meet-our-contributors-APAC-India-region-01.md new file mode 100644 index 0000000000..4c969ff50c --- /dev/null +++ b/content/en/blog/_posts/2022-01-10-meet-our-contributors-APAC-India-region-01.md @@ -0,0 +1,106 @@ +--- +layout: blog +title: "Meet Our Contributors - APAC (India region)" +date: 2022-01-10T12:00:00+0000 +slug: meet-our-contributors-india-ep-01 +canonicalUrl: https://kubernetes.dev/blog/2022/01/10/meet-our-contributors-india-ep-01/ +--- + +**Authors & Interviewers:** [Anubhav Vardhan](https://github.com/anubha-v-ardhan), [Atharva Shinde](https://github.com/Atharva-Shinde), [Avinesh Tripathi](https://github.com/AvineshTripathi), [Debabrata Panigrahi](https://github.com/Debanitrkl), [Kunal Verma](https://github.com/verma-kunal), [Pranshu Srivastava](https://github.com/PranshuSrivastava), [Pritish Samal](https://github.com/CIPHERTron), [Purneswar Prasad](https://github.com/PurneswarPrasad), [Vedant Kakde](https://github.com/vedant-kakde) + +**Editor:** [Priyanka Saggu](https://psaggu.com) + +--- + +Good day, everyone 👋 + +Welcome to the first episode of the APAC edition of the "Meet Our Contributors" blog post series. + + +In this post, we'll introduce you to five amazing folks from the India region who have been actively contributing to the upstream Kubernetes projects in a variety of ways, as well as being the leaders or maintainers of numerous community initiatives. + +💫 *Let's get started, so without further ado…* + + +## [Arsh Sharma](https://github.com/RinkiyaKeDad) + +Arsh is currently employed with Okteto as a Developer Experience engineer. As a new contributor, he realised that 1:1 mentorship opportunities were quite beneficial in getting him started with the upstream project. + +He is presently a CI Signal shadow on the Kubernetes 1.23 release team. He is also contributing to the SIG Testing and SIG Docs projects, as well as to the [cert-manager](https://github.com/cert-manager/infrastructure) tools development work that is being done under the aegis of SIG Architecture. + +To the newcomers, Arsh helps plan their early contributions sustainably. + +> _I would encourage folks to contribute in a way that's sustainable. What I mean by that +> is that it's easy to be very enthusiastic early on and take up more stuff than one can +> actually handle. This can often lead to burnout in later stages. It's much more sustainable +> to work on things iteratively._ + +## [Kunal Kushwaha](https://github.com/kunal-kushwaha) + +Kunal Kushwaha is a core member of the Kubernetes marketing council. He is also a CNCF ambassador and one of the founders of the [CNCF Students Program](https://community.cncf.io/cloud-native-students/).. He also served as a Communications role shadow during the 1.22 release cycle. + +At the end of his first year, Kunal began contributing to the [fabric8io kubernetes-client](https://github.com/fabric8io/kubernetes-client) project. He was then selected to work on the same project as part of Google Summer of Code. Kunal mentored people on the same project, first through Google Summer of Code then through Google Code-in. + +As an open-source enthusiast, he believes that diverse participation in the community is beneficial since it introduces new perspectives and opinions and respect for one's peers. He has worked on various open-source projects, and his participation in communities has considerably assisted his development as a developer. + + +> _I believe if you find yourself in a place where you do not know much about the +> project, that's a good thing because now you can learn while contributing and the +> community is there to help you. It has helped me a lot in gaining skills, meeting +> people from around the world and also helping them. You can learn on the go, +> you don't have to be an expert. Make sure to also check out no code contributions +> because being a beginner is a skill and you can bring new perspectives to the +> organisation._ + +## [Madhav Jivarajani](https://github.com/MadhavJivrajani) + + +Madhav Jivarajani works on the VMware Upstream Kubernetes stability team. He began contributing to the Kubernetes project in January 2021 and has since made significant contributions to several areas of work under SIG Architecture, SIG API Machinery, and SIG ContribEx (contributor experience). + +Among several significant contributions are his recent efforts toward the Archival of [design proposals](https://github.com/kubernetes/community/issues/6055), refactoring the ["groups" codebase](https://github.com/kubernetes/k8s.io/pull/2713) under k8s-infra repository to make it mockable and testable, and improving the functionality of the [GitHub k8s bot](https://github.com/kubernetes/test-infra/issues/23129). + +In addition to his technical efforts, Madhav oversees many projects aimed at assisting new contributors. He organises bi-weekly "KEP reading club" sessions to help newcomers understand the process of adding new features, deprecating old ones, and making other key changes to the upstream project. He has also worked on developing [Katacoda scenarios](https://github.com/kubernetes-sigs/contributor-katacoda) to assist new contributors to become acquainted with the process of contributing to k/k. In addition to his current efforts to meet with community members every week, he has organised several [new contributors workshops (NCW)](https://www.youtube.com/watch?v=FgsXbHBRYIc). + +> _I initially did not know much about Kubernetes. I joined because the community was +> super friendly. But what made me stay was not just the people, but the project itself. +> My solution to not feeling overwhelmed in the community was to gain as much context +> and knowledge into the topics that I was interested in and were being discussed. And +> as a result I continued to dig deeper into Kubernetes and the design of it. +> I am a systems nut & thus Kubernetes was an absolute goldmine for me._ + + +## [Rajas Kakodkar](https://github.com/rajaskakodkar) + +Rajas Kakodkar currently works at VMware as a Member of Technical Staff. He has been engaged in many aspects of the upstream Kubernetes project since 2019. + +He is now a key contributor to the Testing special interest group. He is also active in the SIG Network community. Lately, Rajas has contributed significantly to the [NetworkPolicy++](https://docs.google.com/document/d/1AtWQy2fNa4qXRag9cCp5_HsefD7bxKe3ea2RPn8jnSs/) and [`kpng`](https://github.com/kubernetes-sigs/kpng) sub-projects. + +One of the first challenges he ran across was that he was in a different time zone than the upstream project's regular meeting hours. However, async interactions on community forums progressively corrected that problem. + +> _I enjoy contributing to Kubernetes not just because I get to work on +> cutting edge tech but more importantly because I get to work with +> awesome people and help in solving real world problems._ + +## [Rajula Vineet Reddy](https://github.com/rajula96reddy) + +Rajula Vineet Reddy, a Junior Engineer at CERN, is a member of the Marketing Council team under SIG ContribEx . He also served as a release shadow for SIG Release during the 1.22 and 1.23 Kubernetes release cycles. + +He started looking at the Kubernetes project as part of a university project with the help of one of his professors. Over time, he spent a significant amount of time reading the project's documentation, Slack discussions, GitHub issues, and blogs, which helped him better grasp the Kubernetes project and piqued his interest in contributing upstream. One of his key contributions was his assistance with automation in the SIG ContribEx Upstream Marketing subproject. + +According to Rajula, attending project meetings and shadowing various project roles are vital for learning about the community. + +> _I find the community very helpful and it's always_ +> “you get back as much as you contribute”. +> _The more involved you are, the more you will understand, get to learn and +> contribute new things._ +> +> _The first step to_ “come forward and start” _is hard. But it's all gonna be +> smooth after that. Just take that jump._ + +--- + +If you have any recommendations/suggestions for who we should interview next, please let us know in #sig-contribex. We're thrilled to have other folks assisting us in reaching out to even more wonderful individuals of the community. Your suggestions would be much appreciated. + + +We'll see you all in the next one. Everyone, till then, have a happy contributing! 👋 +