whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'upstream/main' into dev-1.24

Browse Source
This commit is contained in:
Nate W
2022-01-24 09:07:23 -08:00
parent dd1f2f1155 f89e0ba1c9
commit 6fb319b29c
97 changed files with 414 additions and 325 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/concepts/architecture/cloud-controller.md
+1 -1
View File
@@ -78,7 +78,7 @@ when you declare a Service resource that requires them.
## Authorization
This section breaks down the access that the cloud controller managers requires
This section breaks down the access that the cloud controller manager requires
on various API objects, in order to perform its operations.
### Node controller {#authorization-node-controller}
content/en/docs/concepts/cluster-administration/networking.md
+10 -5
View File
@@ -67,7 +67,7 @@ Azure CNI is available natively in the [Azure Kubernetes Service (AKS)](https://
### Calico
[Calico](https://docs.projectcalico.org/) is an open source networking and network security solution for containers, virtual machines, and native host-based workloads. Calico supports multiple data planes including: a pure Linux eBPF dataplane, a standard Linux networking dataplane, and a Windows HNS dataplane. Calico provides a full networking stack but can also be used in conjunction with [cloud provider CNIs](https://docs.projectcalico.org/networking/determine-best-networking#calico-compatible-cni-plugins-and-cloud-provider-integrations) to provide network policy enforcement.
[Calico](https://projectcalico.docs.tigera.io/about/about-calico/) is an open source networking and network security solution for containers, virtual machines, and native host-based workloads. Calico supports multiple data planes including: a pure Linux eBPF dataplane, a standard Linux networking dataplane, and a Windows HNS dataplane. Calico provides a full networking stack but can also be used in conjunction with [cloud provider CNIs](https://projectcalico.docs.tigera.io/networking/determine-best-networking#calico-compatible-cni-plugins-and-cloud-provider-integrations) to provide network policy enforcement.
### Cilium
@@ -79,9 +79,9 @@ addressing, and it can be used in combination with other CNI plugins.
### CNI-Genie from Huawei
[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) is a CNI plugin that enables Kubernetes to [simultaneously have access to different implementations](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) of the [Kubernetes network model](/docs/concepts/cluster-administration/networking/#the-kubernetes-network-model) in runtime. This includes any implementation that runs as a [CNI plugin](https://github.com/containernetworking/cni#3rd-party-plugins), such as [Flannel](https://github.com/coreos/flannel#flannel), [Calico](https://docs.projectcalico.org/), [Weave-net](https://www.weave.works/products/weave-net/).
[CNI-Genie](https://github.com/cni-genie/CNI-Genie) is a CNI plugin that enables Kubernetes to [simultaneously have access to different implementations](https://github.com/cni-genie/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) of the [Kubernetes network model](/docs/concepts/cluster-administration/networking/#the-kubernetes-network-model) in runtime. This includes any implementation that runs as a [CNI plugin](https://github.com/containernetworking/cni#3rd-party-plugins), such as [Flannel](https://github.com/flannel-io/flannel#flannel), [Calico](https://projectcalico.docs.tigera.io/about/about-calico/), [Weave-net](https://www.weave.works/oss/net/).
CNI-Genie also supports [assigning multiple IP addresses to a pod](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multiple-ip-addresses-per-pod), each from a different CNI plugin.
CNI-Genie also supports [assigning multiple IP addresses to a pod](https://github.com/cni-genie/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multiple-ip-addresses-per-pod), each from a different CNI plugin.
### cni-ipvlan-vpc-k8s
[cni-ipvlan-vpc-k8s](https://github.com/lyft/cni-ipvlan-vpc-k8s) contains a set
@@ -104,6 +104,11 @@ 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-VPP
[Contiv-VPP](https://contivpp.io/) is a user-space, performance-oriented network plugin for
Kubernetes, using the [fd.io](https://fd.io/) data plane.
### 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.
@@ -122,7 +127,7 @@ With this toolset DANM is able to provide multiple separated network interfaces,
### Flannel
[Flannel](https://github.com/coreos/flannel#flannel) is a very simple overlay
[Flannel](https://github.com/flannel-io/flannel#flannel) is a very simple overlay
network that satisfies the Kubernetes requirements. Many
people have reported success with Flannel and Kubernetes.
@@ -188,7 +193,7 @@ at [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes).
### Weave Net from Weaveworks
[Weave Net](https://www.weave.works/products/weave-net/) is a
[Weave Net](https://www.weave.works/oss/net/) is a
resilient and simple to use network for Kubernetes and its hosted applications.
Weave Net runs as a [CNI plug-in](https://www.weave.works/docs/net/latest/cni-plugin/)
or stand-alone. In either version, it doesn't require any configuration or extra code
content/en/docs/concepts/cluster-administration/system-logs.md
+2 -1
View File
@@ -182,7 +182,8 @@ There are two types of system components: those that run in a container and thos
that do not run in a container. For example:
* The Kubernetes scheduler and kube-proxy run in a container.
* The kubelet and container runtime, for example Docker, do not run in containers.
* The kubelet and {{<glossary_tooltip term_id="container-runtime" text="container runtime">}}
do not run in containers.
On machines with systemd, the kubelet and container runtime write to journald.
Otherwise, they write to `.log` files in the `/var/log` directory.
content/en/docs/concepts/storage/volumes.md
+2 -1
View File
@@ -858,7 +858,7 @@ operations from the existing in-tree plugin to the `rbd.csi.ceph.com` {{<
glossary_tooltip text="CSI" term_id="csi" >}} driver. In order to use this
feature, the
[Ceph CSI driver](https://github.com/ceph/ceph-csi)
must be installed on the cluster and the `CSIMigration` and `CSIMigrationRBD`
must be installed on the cluster and the `CSIMigration` and `csiMigrationRBD`
[feature gates](/docs/reference/command-line-tools-reference/feature-gates/)
must be enabled.
@@ -1133,6 +1133,7 @@ spec:
volumeMounts:
- name: workdir1
mountPath: /logs
# The variable expansion uses round brackets (not curly brackets).
subPathExpr: $(POD_NAME)
restartPolicy: Never
volumes:
content/en/docs/reference/command-line-tools-reference/feature-gates.md
+4 -3
View File
@@ -88,7 +88,7 @@ different Kubernetes components.
| `CSIMigrationOpenStack` | `true` | Beta | 1.18 | |
| `CSIMigrationvSphere` | `false` | Beta | 1.19 | |
| `CSIMigrationPortworx` | `false` | Alpha | 1.23 | |
| `CSIMigrationRBD` | `false` | Alpha | 1.23 | |
| `csiMigrationRBD` | `false` | Alpha | 1.23 | |
| `CSIStorageCapacity` | `false` | Alpha | 1.19 | 1.20 |
| `CSIStorageCapacity` | `true` | Beta | 1.21 | |
| `CSIVolumeHealth` | `false` | Alpha | 1.21 | |
@@ -653,9 +653,9 @@ Each feature gate is designed for enabling/disabling a specific feature:
operations from the GCE-PD in-tree plugin to PD CSI plugin. Supports falling
back to in-tree GCE plugin if a node does not have PD CSI plugin installed and
configured. Requires CSIMigration feature flag enabled.
- `CSIMigrationRBD`: Enables shims and translation logic to route volume
- `csiMigrationRBD`: Enables shims and translation logic to route volume
operations from the RBD in-tree plugin to Ceph RBD CSI plugin. Requires
CSIMigration and CSIMigrationRBD feature flags enabled and Ceph CSI plugin
CSIMigration and csiMigrationRBD feature flags enabled and Ceph CSI plugin
installed and configured in the cluster. This flag has been deprecated in
favor of the
`InTreePluginRBDUnregister` feature flag which prevents the registration of
@@ -731,6 +731,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
on resources created from [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
- `DaemonSetUpdateSurge`: Enables the DaemonSet workloads to maintain
availability during update per node.
See [Perform a Rolling Update on a DaemonSet](/docs/tasks/manage-daemon/update-daemon-set/).
- `DefaultPodTopologySpread`: Enables the use of `PodTopologySpread` scheduling plugin to do
[default spreading](/docs/concepts/workloads/pods/pod-topology-spread-constraints/#internal-default-constraints).
- `DelegateFSGroupToCSIDriver`: If supported by the CSI driver, delegates the
content/en/docs/reference/glossary/container-runtime.md
+2 -2
View File
@@ -15,7 +15,7 @@ tags:
<!--more-->
Kubernetes supports several container runtimes: {{< glossary_tooltip term_id="docker">}},
Kubernetes supports container runtimes such as
{{< glossary_tooltip term_id="containerd" >}}, {{< glossary_tooltip term_id="cri-o" >}},
and any implementation of the [Kubernetes CRI (Container Runtime
and any other implementation of the [Kubernetes CRI (Container Runtime
Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md).
content/en/docs/reference/kubectl/conventions.md
-23
View File
@@ -31,29 +31,6 @@ For `kubectl run` to satisfy infrastructure as code:
You can use the `--dry-run=client` flag to preview the object that would be sent to your cluster, without really submitting it.
{{< note >}}
All `kubectl run` generators are deprecated. See the Kubernetes v1.17 documentation for a [list](https://v1-17.docs.kubernetes.io/docs/reference/kubectl/conventions/#generators) of generators and how they were used.
{{< /note >}}
#### Generators
You can generate the following resources with a kubectl command, `kubectl create --dry-run=client -o yaml`:
* `clusterrole`: Create a ClusterRole.
* `clusterrolebinding`: Create a ClusterRoleBinding for a particular ClusterRole.
* `configmap`: Create a ConfigMap from a local file, directory or literal value.
* `cronjob`: Create a CronJob with the specified name.
* `deployment`: Create a Deployment with the specified name.
* `job`: Create a Job with the specified name.
* `namespace`: Create a Namespace with the specified name.
* `poddisruptionbudget`: Create a PodDisruptionBudget with the specified name.
* `priorityclass`: Create a PriorityClass with the specified name.
* `quota`: Create a Quota with the specified name.
* `role`: Create a Role with single rule.
* `rolebinding`: Create a RoleBinding for a particular Role or ClusterRole.
* `secret`: Create a Secret using specified subcommand.
* `service`: Create a Service using specified subcommand.
* `serviceaccount`: Create a ServiceAccount with the specified name.
### `kubectl apply`
* You can use `kubectl apply` to create or update resources. For more information about using kubectl apply to update resources, see [Kubectl Book](https://kubectl.docs.kubernetes.io).
content/en/docs/setup/best-practices/enforcing-pod-security-standards.md
+1 -1
View File
@@ -15,7 +15,7 @@ This page provides an overview of best practices when it comes to enforcing
## Using the built-in Pod Security Admission Controller
{{< feature-state for_k8s_version="v1.22" state="alpha" >}}
{{< feature-state for_k8s_version="v1.23" state="beta" >}}
The [Pod Security Admission Controller](/docs/reference/access-authn-authz/admission-controllers/#podsecurity)
intends to replace the deprecated PodSecurityPolicies.
content/en/docs/setup/production-environment/container-runtimes.md
+35 -35
View File
@@ -15,12 +15,19 @@ what is involved and describes related tasks for setting up nodes.
<!-- body -->
Kubernetes {{< skew currentVersion >}} requires that you use a runtime that
conforms with the
{{< glossary_tooltip term_id="cri" text="Container Runtime Interface">}} (CRI).
See [CRI version support](#cri-versions) for more information.
This page lists details for using several common container runtimes with
Kubernetes, on Linux:
- [containerd](#containerd)
- [CRI-O](#cri-o)
- [Docker](#docker)
- [Docker Engine](#docker)
- [Mirantis Container Runtime](#mcr)
{{< note >}}
For other operating systems, look for documentation specific to your platform.
@@ -94,10 +101,19 @@ In order to use it, cgroup v2 must be supported by the CRI runtime as well.
Follow this [Migration guide](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/)
if you wish to migrate to the `systemd` cgroup driver in existing kubeadm managed clusters.
## CRI version support {#cri-versions}
Your container runtime must support at least v1alpha2 of the container runtime interface.
Kubernetes {{< skew currentVersion >}} defaults to using v1 of the CRI API.
If a container runtime does not support the v1 API, the kubelet falls back to
using the (deprecated) v1alpha2 API instead.
## Container runtimes
{{% thirdparty-content %}}
### containerd
This section contains the necessary steps to use containerd as CRI runtime.
@@ -394,44 +410,28 @@ Please also note the changed `conmon_cgroup`, which has to be set to the value
cgroup driver configuration of the kubelet (usually done via kubeadm) and CRI-O
in sync.
### Docker
### Docker Engine {#docker}
1. On each of your nodes, install the Docker for your Linux distribution as per
[Install Docker Engine](https://docs.docker.com/engine/install/#server).
You can find the latest validated version of Docker in this
[dependencies](https://git.k8s.io/kubernetes/build/dependencies.yaml) file.
Docker Engine is the container runtime that started it all. Formerly known just as Docker,
this container runtime is available in various forms.
[Install Docker Engine](https://docs.docker.com/engine/install/) explains your options
for installing this runtime.
2. Configure the Docker daemon, in particular to use systemd for the management of the container’s cgroups.
Docker Engine is directly compatible with Kubernetes {{< skew currentVersion >}}, using the deprecated `dockershim` component. For more information
and context, see the [Dockershim deprecation FAQ](/dockershim).
```shell
sudo mkdir /etc/docker
cat <<EOF | sudo tee /etc/docker/daemon.json
{
"exec-opts": ["native.cgroupdriver=systemd"],
"log-driver": "json-file",
"log-opts": {
"max-size": "100m"
},
"storage-driver": "overlay2"
}
EOF
```
You can also find third-party adapters that let you use Docker Engine with Kubernetes
through the supported {{< glossary_tooltip term_id="cri" text="Container Runtime Interface">}}
(CRI).
{{< note >}}
`overlay2` is the preferred storage driver for systems running Linux kernel version 4.0 or higher,
or RHEL or CentOS using version 3.10.0-514 and above.
{{< /note >}}
The following CRI adaptors are designed to work with Docker Engine:
3. Restart Docker and enable on boot:
- [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd) from Mirantis
```shell
sudo systemctl enable docker
sudo systemctl daemon-reload
sudo systemctl restart docker
```
### Mirantis Container Runtime {#mcr}
{{< note >}}
For more information refer to
- [Configure the Docker daemon](https://docs.docker.com/config/daemon/)
- [Control Docker with systemd](https://docs.docker.com/config/daemon/systemd/)
{{< /note >}}
[Mirantis Container Runtime](https://docs.mirantis.com/mcr/20.10/overview.html) (MCR) is a commercially
available container runtime that was formerly known as Docker Enterprise Edition.
You can use Mirantis Container Runtime with Kubernetes using the open source
[`cri-dockerd`](https://github.com/Mirantis/cri-dockerd) component, included with MCR.
content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md
+6 -7
View File
@@ -167,14 +167,13 @@ option. Your cluster requirements may need a different configuration.
{{< /caution >}}
1. Apply the CNI plugin of your choice:
[Follow these instructions](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network)
[Follow these instructions](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network)
to install the CNI provider. Make sure the configuration corresponds to the Pod CIDR specified in the kubeadm configuration file if applicable.
In this example we are using Weave Net:
```sh
kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
```
{{< note >}}
You must pick a network plugin that suits your use case and deploy it before you move on to next step.
If you don't do this, you will not be able to launch your cluster properly.
{{< /note >}}
1. Type the following and watch the pods of the control plane components get started:
content/en/docs/tasks/configure-pod-container/configure-gmsa.md
+28 -60
View File
@@ -10,20 +10,19 @@ weight: 20
This page shows how to configure [Group Managed Service Accounts](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview) (GMSA) for Pods and containers that will run on Windows nodes. Group Managed Service Accounts are a specific type of Active Directory account that provides automatic password management, simplified service principal name (SPN) management, and the ability to delegate the management to other administrators across multiple servers.
In Kubernetes, GMSA credential specs are configured at a Kubernetes cluster-wide scope as Custom Resources. Windows Pods, as well as individual containers within a Pod, can be configured to use a GMSA for domain based functions (e.g. Kerberos authentication) when interacting with other Windows services. As of v1.16, the Docker runtime supports GMSA for Windows workloads.
In Kubernetes, GMSA credential specs are configured at a Kubernetes cluster-wide scope as Custom Resources. Windows Pods, as well as individual containers within a Pod, can be configured to use a GMSA for domain based functions (e.g. Kerberos authentication) when interacting with other Windows services.
## {{% heading "prerequisites" %}}
You need to have a Kubernetes cluster and the `kubectl` command-line tool must be configured to communicate with your cluster. The cluster is expected to have Windows worker nodes. This section covers a set of initial steps required once for each cluster:
### Install the GMSACredentialSpec CRD
A [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)(CRD) for GMSA credential spec resources needs to be configured on the cluster to define the custom resource type `GMSACredentialSpec`. Download the GMSA CRD [YAML](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-crd.yml) and save it as gmsa-crd.yaml.
Next, install the CRD with `kubectl apply -f gmsa-crd.yaml`
### Install webhooks to validate GMSA users
Two webhooks need to be configured on the Kubernetes cluster to populate and validate GMSA credential spec references at the Pod or container level:
1. A mutating webhook that expands references to GMSAs (by name from a Pod specification) into the full credential spec in JSON form within the Pod spec.
@@ -36,23 +35,23 @@ Installing the above webhooks and associated objects require the steps below:
1. Install a secret with the certificate from above.
1. Create a deployment for the core webhook logic.
1. Create a deployment for the core webhook logic.
1. Create the validating and mutating webhook configurations referring to the deployment.
1. Create the validating and mutating webhook configurations referring to the deployment.
A [script](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/deploy-gmsa-webhook.sh) can be used to deploy and configure the GMSA webhooks and associated objects mentioned above. The script can be run with a ```--dry-run=server``` option to allow you to review the changes that would be made to your cluster.
The [YAML template](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-webhook.yml.tpl) used by the script may also be used to deploy the webhooks and associated objects manually (with appropriate substitutions for the parameters)
<!-- steps -->
## Configure GMSAs and Windows nodes in Active Directory
Before Pods in Kubernetes can be configured to use GMSAs, the desired GMSAs need to be provisioned in Active Directory as described in the [Windows GMSA documentation](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#BKMK_Step1). Windows worker nodes (that are part of the Kubernetes cluster) need to be configured in Active Directory to access the secret credentials associated with the desired GMSA as described in the [Windows GMSA documentation](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#to-add-member-hosts-using-the-set-adserviceaccount-cmdlet)
## Create GMSA credential spec resources
With the GMSACredentialSpec CRD installed (as described earlier), custom resources containing GMSA credential specs can be configured. The GMSA credential spec does not contain secret or sensitive data. It is information that a container runtime can use to describe the desired GMSA of a container to Windows. GMSA credential specs can be generated in YAML format with a utility [PowerShell script](https://github.com/kubernetes-sigs/windows-gmsa/tree/master/scripts/GenerateCredentialSpecResource.ps1).
With the GMSACredentialSpec CRD installed (as described earlier), custom resources containing GMSA credential specs can be configured. The GMSA credential spec does not contain secret or sensitive data. It is information that a container runtime can use to describe the desired GMSA of a container to Windows. GMSA credential specs can be generated in YAML format with a utility [PowerShell script](https://github.com/kubernetes-sigs/windows-gmsa/tree/master/scripts/GenerateCredentialSpecResource.ps1).
Following are the steps for generating a GMSA credential spec YAML manually in JSON format and then converting it:
@@ -60,14 +59,14 @@ Following are the steps for generating a GMSA credential spec YAML manually in J
1. Create a credential spec in JSON format using `New-CredentialSpec`. To create a GMSA credential spec named WebApp1, invoke `New-CredentialSpec -Name WebApp1 -AccountName WebApp1 -Domain $(Get-ADDomain -Current LocalComputer)`
1. Use `Get-CredentialSpec` to show the path of the JSON file.
1. Use `Get-CredentialSpec` to show the path of the JSON file.
1. Convert the credspec file from JSON to YAML format and apply the necessary header fields `apiVersion`, `kind`, `metadata` and `credspec` to make it a GMSACredentialSpec custom resource that can be configured in Kubernetes.
1. Convert the credspec file from JSON to YAML format and apply the necessary header fields `apiVersion`, `kind`, `metadata` and `credspec` to make it a GMSACredentialSpec custom resource that can be configured in Kubernetes.
The following YAML configuration describes a GMSA credential spec named `gmsa-WebApp1`:
```yaml
apiVersion: windows.k8s.io/v1alpha1
apiVersion: windows.k8s.io/v1
kind: GMSACredentialSpec
metadata:
name: gmsa-WebApp1 #This is an arbitrary name but it will be used as a reference
@@ -92,6 +91,7 @@ credspec:
The above credential spec resource may be saved as `gmsa-Webapp1-credspec.yaml` and applied to the cluster using: `kubectl apply -f gmsa-Webapp1-credspec.yml`
## Configure cluster role to enable RBAC on specific GMSA credential specs
A cluster role needs to be defined for each GMSA credential spec resource. This authorizes the `use` verb on a specific GMSA resource by a subject which is typically a service account. The following example shows a cluster role that authorizes usage of the `gmsa-WebApp1` credential spec from above. Save the file as gmsa-webapp1-role.yaml and apply using `kubectl apply -f gmsa-webapp1-role.yaml`
```yaml
@@ -108,6 +108,7 @@ rules:
```
## Assign role to service accounts to use specific GMSA credspecs
A service account (that Pods will be configured with) needs to be bound to the cluster role create above. This authorizes the service account to use the desired GMSA credential spec resource. The following shows the default service account being bound to a cluster role `webapp1-role` to use `gmsa-WebApp1` credential spec resource created above.
```yaml
@@ -127,6 +128,7 @@ roleRef:
```
## Configure GMSA credential spec reference in Pod spec
The Pod spec field `securityContext.windowsOptions.gmsaCredentialSpecName` is used to specify references to desired GMSA credential spec custom resources in Pod specs. This configures all containers in the Pod spec to use the specified GMSA. A sample Pod spec with the annotation populated to refer to `gmsa-WebApp1`:
```yaml
@@ -197,55 +199,17 @@ As Pod specs with GMSA fields populated (as described above) are applied in a cl
1. The container runtime configures each Windows container with the specified GMSA credential spec so that the container can assume the identity of the GMSA in Active Directory and access services in the domain using that identity.
## Containerd
## Authenticating to network shares usinig hostname of FQDN
On Windows Server 2019, in order to use GMSA with containerd, you must be running OS Build 17763.1817 (or later) which can be installed using the patch [KB5000822](https://support.microsoft.com/en-us/topic/march-9-2021-kb5000822-os-build-17763-1817-2eb6197f-e3b1-4f42-ab51-84345e063564).
If you are experiencing issues connecting to SMB shares from Pods using hostname or FQDN, but are able to access the shares via their IPv4 address then make sure the following registry key is set on the Windows nodes.
There is also a known issue with containerd that occurs when trying to connect to SMB shares from Pods. Once you have configured GMSA, the pod will be unable to connect to the share using the hostname or FQDN, but connecting to the share using an IP address works as expected.
```PowerShell
ping adserver.ad.local
```
and correctly resolves the hostname to an IPv4 address. The output is similar to:
```
Pinging adserver.ad.local [192.168.111.18] with 32 bytes of data:
Reply from 192.168.111.18: bytes=32 time=6ms TTL=124
Reply from 192.168.111.18: bytes=32 time=5ms TTL=124
Reply from 192.168.111.18: bytes=32 time=5ms TTL=124
Reply from 192.168.111.18: bytes=32 time=5ms TTL=124
```cmd
reg add "HKLM\SYSTEM\CurrentControlSet\Services\hns\State" /v EnableCompartmentNamespace /t REG_DWORD /d 1
```
However, when attempting to browse the directory using the hostname
```PowerShell
cd \\adserver.ad.local\test
```
you see an error that implies the target share doesn't exist:
```
cd : Cannot find path '\\adserver.ad.local\test' because it does not exist.
At line:1 char:1
+ cd \\adserver.ad.local\test
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (\\adserver.ad.local\test:String) [Set-Location], ItemNotFoundException
+ FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.SetLocationCommand
```
but you notice that the error disappears if you browse to the share using its IPv4 address instead; for example:
```PowerShell
cd \\192.168.111.18\test
```
After you change into a directory within the share, you see a prompt similar to:
```
Microsoft.PowerShell.Core\FileSystem::\\192.168.111.18\test>
```
To correct the behaviour you must run the following on the node `reg add "HKLM\SYSTEM\CurrentControlSet\Services\hns\State" /v EnableCompartmentNamespace /t REG_DWORD /d 1` to add the required registry key. This node change will only take effect in newly created pods, meaning you must now recreate any running pods which require access to SMB shares.
Running Pods will then need to be recreated to pick up the behavior changes.
More information on how this registry key is used can be found [here](
https://github.com/microsoft/hcsshim/blob/885f896c5a8548ca36c88c4b87fd2208c8d16543/internal/uvm/create.go#L74-L83)
## Troubleshooting
@@ -258,8 +222,10 @@ In the example below the Pod did not get the credspec correctly:
```PowerShell
kubectl exec -it iis-auth-7776966999-n5nzr powershell.exe
```
`nltest.exe /parentdomain` results in the following error:
```
```PowerShell
Getting parent domain failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE
```
@@ -278,7 +244,8 @@ nltest.exe /query
```
Results in the following output:
```
```PowerShell
I_NetLogonControl failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE
```
@@ -289,7 +256,8 @@ nltest /sc_reset:domain.example
```
If the command is successful you will see and output similar to this:
```
```PowerShell
Flags: 30 HAS_IP HAS_TIMESERV
Trusted DC Name \\dc10.domain.example
Trusted DC Connection Status Status = 0 0x0 NERR_Success
content/en/docs/tasks/configure-pod-container/security-context.md
+1 -1
View File
@@ -469,7 +469,7 @@ kubectl delete pod security-context-demo-4
* [PodSecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritycontext-v1-core)
* [SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core)
* [Tuning Docker with the newest security enhancements](https://opensource.com/business/15/3/docker-security-tuning)
* [Tuning Docker with the newest security enhancements](https://github.com/containerd/containerd/blob/main/docs/cri/config.md)
* [Security Contexts design document](https://git.k8s.io/community/contributors/design-proposals/auth/security_context.md)
* [Ownership Management design document](https://git.k8s.io/community/contributors/design-proposals/storage/volume-ownership-management.md)
* [Pod Security Policies](/docs/concepts/policy/pod-security-policy/)
content/en/docs/tasks/manage-daemon/update-daemon-set.md
+1 -1
View File
@@ -40,7 +40,7 @@ You may want to set
[`.spec.minReadySeconds`](/docs/concepts/workloads/controllers/deployment/#min-ready-seconds)
(default to 0) and
[`.spec.maxSurge`](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#max-surge)
(a beta feature and defaults to 25%) as well.
(a beta feature and defaults to 0) as well.
### Creating a DaemonSet with `RollingUpdate` update strategy
content/en/docs/tasks/network/customize-hosts-file-for-pods.md
+9 -4
View File
@@ -117,10 +117,15 @@ with the additional entries specified at the bottom.
## Why does the kubelet manage the hosts file? {#why-does-kubelet-manage-the-hosts-file}
The kubelet [manages](https://github.com/kubernetes/kubernetes/issues/14633) the
`hosts` file for each container of the Pod to prevent Docker from
[modifying](https://github.com/moby/moby/issues/17190) the file after the
containers have already been started.
The kubelet manages the
`hosts` file for each container of the Pod to prevent the container runtime from
modifying the file after the containers have already been started.
Historically, Kubernetes always used Docker Engine as its container runtime, and Docker Engine would
then modify the `/etc/hosts` file after each container had started.
Current Kubernetes can use a variety of container runtimes; even so, the kubelet manages the
hosts file within each container so that the outcome is as intended regardless of which
container runtime you use.
{{< caution >}}
Avoid making manual changes to the hosts file inside a container.
content/en/docs/tasks/tools/included/optional-kubectl-configs-fish.md
+15
View File
@@ -0,0 +1,15 @@
---
title: "fish auto-completion"
description: "Optional configuration to enable fish shell auto-completion."
headless: true
---
The kubectl completion script for Fish can be generated with the command `kubectl completion fish`. Sourcing the completion script in your shell enables kubectl autocompletion.
To do so in all your shell sessions, add the following line to your `~/.config/fish/config.fish` file:
```shell
kubectl completion fish | source
```
After reloading your shell, kubectl autocompletion should be working.
content/en/docs/tasks/tools/install-kubectl-linux.md
+3 -2
View File
@@ -178,10 +178,11 @@ kubectl version --client
kubectl provides autocompletion support for Bash, Zsh, Fish, and PowerShell, which can save you a lot of typing.
Below are the procedures to set up autocompletion for Bash and Zsh.
Below are the procedures to set up autocompletion for Bash, Fish, and Zsh.
{{< tabs name="kubectl_autocompletion" >}}
{{< tab name="Bash" include="included/optional-kubectl-configs-bash-linux.md" />}}
{{< tab name="Fish" include="included/optional-kubectl-configs-fish.md" />}}
{{< tab name="Zsh" include="included/optional-kubectl-configs-zsh.md" />}}
{{< /tabs >}}
@@ -192,7 +193,7 @@ Below are the procedures to set up autocompletion for Bash and Zsh.
1. Download the latest release with the command:
```bash
curl -LO https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl-convert
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl-convert"
```
1. Validate the binary (optional)
content/en/docs/tasks/tools/install-kubectl-macos.md
+2 -1
View File
@@ -161,10 +161,11 @@ If you are on macOS and using [Macports](https://macports.org/) package manager,
kubectl provides autocompletion support for Bash, Zsh, Fish, and PowerShell which can save you a lot of typing.
Below are the procedures to set up autocompletion for Bash and Zsh.
Below are the procedures to set up autocompletion for Bash, Fish, and Zsh.
{{< tabs name="kubectl_autocompletion" >}}
{{< tab name="Bash" include="included/optional-kubectl-configs-bash-mac.md" />}}
{{< tab name="Fish" include="included/optional-kubectl-configs-fish.md" />}}
{{< tab name="Zsh" include="included/optional-kubectl-configs-zsh.md" />}}
{{< /tabs >}}