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

Official 1.14 Release Docs (#13174)

Browse Source 
* Official documentation on Poseidon/Firmament, a new multi-scheduler support for K8S. (#11752)

* Added documentation about Poseidon-Firmament scheduler

* Fixed some style issues.

* Udpated the document as per the review comments.

* Fixed some typos and updated the document

* Updated the document as per the review comments.

* Document timeout attribute for kms-plugin. (#12158)

See 72540.

* Official documentation on Poseidon/Firmament, a new multi-scheduler  (#12343)

* Removed the old version of the Poseidon documentation. Incorrect location.

* Official documentation on Poseidon/Firmament, a new multi-scheduler support for K8S (#12069)

* Official documentation on Poseidon/Firmament, a new multi-scheduler support for K8S. (#11752)

* Added documentation about Poseidon-Firmament scheduler

* Fixed some style issues.

* Udpated the document as per the review comments.

* Fixed some typos and updated the document

* Updated the document as per the review comments.

* Updated the document as per review comments. Added config details.

* Updated the document as per the latest review comments. Fixed nits

* Made changes as per latest suggestions.

* Some more changes added.

* Updated as per suggestions.

* Changed the release process section.

* SIG Docs edits

Small edits to match style guidelines.

* add plus to feature state

* capitalization

* revert feature state shortcode

since this is a Kubernetes extension, not a direct feature, it shouldn't use the regular feature state tagging.

(cherry picked from commit 7730c1540b)

* Remove initializers from doc. It will be removed in 1.14 (#12331)

* kubeadm: Document CRI auto detection functionality (#12462)

Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>

* Minor doc change for GAing Pod DNS Config (#12514)

* Graduate ExpandInUsePersistentVolumes feature to beta (#10574)

* Rename 2018-11-07-grpc-load-balancing-with-linkerd.md.md file (#12594)

* Add dynamic percentage of node scoring to user docs (#12235)

* Add dynamic percentage of node scoring to user docs

* addressed review comments

* delete special symbol (#12445)

* Update documentation for VolumeSubpathEnvExpansion (#11843)

* Update documentation for VolumeSubpathEnvExpansion

* Address comments - improve descriptions

* Graduate Pod Priority and Preemption to GA (#12428)

* Added Instana links to the documentation (#12977)

* Added link to the Instana Kubernetes integration

* Added Instana link for services section

Added Instana and a link to the Kubernetes integration to the analytics services section and broadened the scope to APM, monitoring and analytics.

* Oxford comma /flex

* More Oxford commas, because they matter

* Update kubectl plugins to stable (#12847)

* documentation for CSI topology beta (#12889)

* Document changes to default RBAC discovery ClusterRole(Binding)s (#12888)

* Document changes to default RBAC discovery ClusterRole(Binding)s

Documentation for https://github.com/kubernetes/enhancements/issues/789 and https://github.com/kubernetes/kubernetes/pull/73807

* documentation review feedback

* CSI raw block to beta (#12931)

* Change incorrect string raw to block (#12926)

Fixes #12925

* Update documentation on node OS/arch labels (#12976)

These labels have been promoted to GA:
https://github.com/kubernetes/enhancements/issues/793

* local pv GA doc updates (#12915)

* Publish CRD OpenAPI Documentation (#12910)

* add documentation for CustomResourcePublishOpenAPI

* address comments

fix links, ordered lists, style and typo

* kubeadm: add document for upgrading from 1.13 to 1.14 (single CP and HA) (#13189)

* kubeadm: add document for upgrading from 1.13 to 1.14

- remove doc for upgrading 1.10 -> 1.11

* kubeadm: apply amends to upgrade-1.14 doc

* kubeadm: apply amends to upgrade-1.14 doc (part2)

* kubeadm: apply amends to upgrade-1.14 doc (part3)

* kubeadm: add note about "upgrade node experimental-control-plane"

+ add comment about `upgrade plan`

* kubeadm: add missing "You should see output similar to this"

* fix bullet indentation (#13214)

* mark PodReadinessGate GA (#12800)

* Update RuntimeClass documentation for beta (#13043)

* Update RuntimeClass documentation for beta

* Update feature gate & add upgrade section

* formatting fixes

* Highlight upgrade action required

* Address feedback

* CSI ephemeral volume alpha documentation (#10934)

* update kubectl documentation (#12867)

* update kubectl documentation

* add document for Secret/ConfigMap generators

* replace `kubectl create -f` by `kubectl apply -f`

* Add page for kustomization support in kubectl

* fix spelling errors and address comments

* Documentation for Windows GMSA feature (#12936)

* Documentation for Windows GMSA feature

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* Enhancements to GMSA docs

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* Fix links

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* Fix GMSA link

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* Add GMSA feature flag in feature flag list

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* Relocate GMSA to container configuration

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* Add example for container spec

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* Remove changes in Windows index

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* Update configure-gmsa.md

* Update configure-gmsa.md

* Update configure-gmsa.md

* Update configure-gmsa.md

* Rearrange the steps into two sections and other edits

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* Fix links

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* Add reference to script to generate GMSA YAMLs

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* Some more clarifications for GMSA

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* HugePages graduated to GA (#13004)

* HugePages graduated to GA

* fixing nit for build

* Docs for node PID limiting (https://github.com/kubernetes/kubernetes/pull/73651) (#12932)

* kubeadm: update the reference documentation for 1.14 (#12911)

* kubeadm: update list of generated files for 1.14

NOTE: PLACEHOLDERS! these files are generated by SIG Docs each
release, but we need them to pass the k/website PR CI.

- add join_phase* (new sub phases of join)
- add init_phase_upload-certs.md (new upload certs phase for init)
- remove alpha-preflight (now both init and join have this)

* kubeadm: update reference docs includes for 1.14

- remove includes from alpha.md
- add upload-certs to init-phase.md
- add join-phase.md and it's phases

* kubeadm: update the editorial content of join and init

- cleanup master->control-plane node
- add some notes about phases and join
- remove table about pre-pulling images
- remove outdated info about self-hosting

* kubeadm: update target release for v1alpha3 removal

1.14 -> 1.15

* kubeadm: copy edits for 1.14 reference docs (part1)

* kubeadm: use "shell" for code blocks

* kubeadm: update the 1.14 HA guide (#13191)

* kubeadm: update the 1.14 HA guide

* kubeadm: try to fix note/caution indent in HA page

* kubeadm: fix missing sudo and minor amends in HA doc

* kubeadm: apply latest amends to the HA doc for 1.14

* fixed a few missed merge conflicts

* Admission Webhook new features doc (#12938)

- kubernetes/kubernetes#74998
- kubernetes/kubernetes#74477
- kubernetes/kubernetes#74562

* Clarifications and fixes in GMSA doc (#13226)

* Clarifications and fixes in GMSA doc

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* Update configure-gmsa.md

* Reformat to align headings and pre-reqs better

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* Reformat to align headings and pre-reqs better

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* Reformat to fix bullets

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* Reword application of sample gmsa

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* Update configure-gmsa.md

* Address feedback to use active voice

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* Address feedback to use active voice

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* RunAsGroup documentation for Progressing this to Beta (#12297)

* start serverside-apply documentation (#13077)

* start serverside-apply documentation

* add more concept info on server side apply

* Update api concepts

* Update api-concepts.md

* fix style issues

* Document CSI update (#12928)

* Document CSI update

* Finish CSI documentation

Also fix mistake with  ExpandInUsePersistentVolumes documented as beta

* Overall docs for CSI Migration feature (#12935)

* Placeholder docs for CSI Migration feature

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* Address CR comments and update feature gates

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* Add mappings for CSI plugins

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* Add sections for AWS and GCE PD migration

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* Add docs for Cinder and CSI Migration info

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* Clarify scope to volumes with file system

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* Change the format of EBS and Cinder CSI Migration sections to follow the GCE template

Signed-off-by: Deep Debroy <ddebroy@docker.com>

* Windows documentation updates for 1.14 (#12929)

* Updated the note to indicate doc work for 1.14

* first attempt at md export from gdoc

* simplifyig

* big attempt

* moving DRAFT windows content to PR for review

* moving content to PR in markdown for review

* updated note tags

* Delete windows-contributing.md

deleting this file as it is already ported to the github contributor guide

* fixed formatting in intro and cluster setup guide

* updating formatting for running containers guide

* rejiggered end of troubleshooting

* fixed minor typos

* Clarified the windows binary download step

* Update _index.md

making updates based on feedback

* Update _index.md

updating ovn-kubernetes docs

* Update _index.md

* Update _index.md

* updating relative docs links

updating all the links to be relative links to /docs

* Update _index.md

* Update _index.md

updates for windows services and ovn-kubernetes

* formatted for correct step numbering

* fix typos

* Update _index.md

updates for flannel PR in troubleshooting

* Update _index.md

* Update _index.md

updating a few sections like roadmap, services, troubleshooting/filing tickets

* Update _index.md

* Update _index.md

* Update _index.md

* Fixed a few whitespace issues

* Update _index.md

* Update _index.md

* Update _index.md

* add section on upgrading CoreDNS (#12909)

* documentation for kubelet resource metrics endpoint (#12934)

* windows docs updates for 1.14 (#13279)

* Delete sample-l2bridge-wincni-config.json

this file is not used anywhere

* Update _index.md

* Update _index.md

* Update _index.md

* Update _index.md

* Update _index.md

* Rename content/en/docs/getting-started-guides/windows/_index.md to content/en/docs/setup/windows/_index.md

moving to new location

* Delete flannel-master-kubectl-get-ds.png

* Delete flannel-master-kubeclt-get-pods.png

* Delete windows-docker-error.png

* Add files via upload

* Rename _index.md to add-windows-nodes.md

* Create _index.md

* Update _index.md

* Update add-windows-nodes.md

* Update add-windows-nodes.md

* Create user-guide-windows-nodes.md

* Create user-guide-windows-containers.md

* Update and rename add-windows-nodes.md to intro-windows-nodes.md

* Update user-guide-windows-containers.md

* Rename intro-windows-nodes.md to intro-windows-in-kubernetes.md

* Update user-guide-windows-nodes.md

* Update user-guide-windows-containers.md

* Update user-guide-windows-containers.md

* Update user-guide-windows-nodes.md

* Update user-guide-windows-containers.md

* Update _index.md

* Update intro-windows-in-kubernetes.md

* Update intro-windows-in-kubernetes.md

fixing the pause image

* Update intro-windows-in-kubernetes.md

changing tables from html to MD

* Update user-guide-windows-nodes.md

converting tables from HTML to MD

* Update intro-windows-in-kubernetes.md

* Update user-guide-windows-nodes.md

* Update user-guide-windows-nodes.md

* Update user-guide-windows-nodes.md

updating the numbering , even though it messes up the notes a little bit. Jim will file a ticket to follow up

* Update user-guide-windows-nodes.md

* update to windows docs for 1.14 (#13322)

* Update intro-windows-in-kubernetes.md

* Update intro-windows-in-kubernetes.md

* Update intro-windows-in-kubernetes.md

* Update intro-windows-in-kubernetes.md

* Update intro-windows-in-kubernetes.md

* Update user-guide-windows-containers.md

* Update user-guide-windows-nodes.md

* Update intro-windows-in-kubernetes.md (#13344)

* server side apply followup (#13321)

* change some parts of serverside apply docs in response to comments

* fix typos and wording

* Update config.toml (#13365)
This commit is contained in:
Jim Angel
2019-03-25 17:06:16 -05:00
committed by Kubernetes Prow Robot
parent 28dd4d5154
commit 851ef58fa8
160 changed files with 4319 additions and 1812 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/tasks/configure-pod-container/assign-cpu-resource.md
+2 -2
View File
@@ -77,7 +77,7 @@ The `-cpus "2"` argument tells the Container to attempt to use 2 CPUs.
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/resource/cpu-request-limit.yaml --namespace=cpu-example
kubectl apply -f https://k8s.io/examples/pods/resource/cpu-request-limit.yaml --namespace=cpu-example
```
Verify that the Pod Container is running:
@@ -168,7 +168,7 @@ capacity of any Node in your cluster.
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/resource/cpu-request-limit-2.yaml --namespace=cpu-example
kubectl apply -f https://k8s.io/examples/pods/resource/cpu-request-limit-2.yaml --namespace=cpu-example
```
View the Pod status:
content/en/docs/tasks/configure-pod-container/assign-memory-resource.md
+3 -3
View File
@@ -76,7 +76,7 @@ The `"--vm-bytes", "150M"` arguments tell the Container to attempt to allocate 1
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/resource/memory-request-limit.yaml --namespace=mem-example
kubectl apply -f https://k8s.io/examples/pods/resource/memory-request-limit.yaml --namespace=mem-example
```
Verify that the Pod Container is running:
@@ -146,7 +146,7 @@ will attempt to allocate 250 MiB of memory, which is well above the 100 MiB limi
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/resource/memory-request-limit-2.yaml --namespace=mem-example
kubectl apply -f https://k8s.io/examples/pods/resource/memory-request-limit-2.yaml --namespace=mem-example
```
View detailed information about the Pod:
@@ -252,7 +252,7 @@ of any Node in your cluster.
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/resource/memory-request-limit-3.yaml --namespace=mem-example
kubectl apply -f https://k8s.io/examples/pods/resource/memory-request-limit-3.yaml --namespace=mem-example
```
View the Pod status:
content/en/docs/tasks/configure-pod-container/assign-pods-nodes.md
+1 -1
View File
@@ -71,7 +71,7 @@ a `disktype=ssd` label.
chosen node:
```shell
kubectl create -f https://k8s.io/examples/pods/pod-nginx.yaml
kubectl apply -f https://k8s.io/examples/pods/pod-nginx.yaml
```
1. Verify that the pod is running on your chosen node:
content/en/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md
+1 -1
View File
@@ -38,7 +38,7 @@ nginx gracefully. This is helpful if the Container is being terminated because o
Create the Pod:
kubectl create -f https://k8s.io/examples/pods/lifecycle-events.yaml
kubectl apply -f https://k8s.io/examples/pods/lifecycle-events.yaml
Verify that the Container in the Pod is running:
content/en/docs/tasks/configure-pod-container/configure-gmsa.md
+204
View File
@@ -0,0 +1,204 @@
---
title: Configure GMSA for Windows pods and containers
content_template: templates/task
weight: 20
---
{{% capture overview %}}
{{< feature-state for_k8s_version="v1.14" state="alpha" >}}
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.14, the only container runtime interface that supports GMSA for Windows workloads is Dockershim. Implementation of GMSA through CRI and other runtimes is planned for the future.
{{< note >}}
Currently this feature is in alpha state. While the overall goals and functionality will not change, the way in which the GMSA credspec references are specified in pod specs may change from annotations to API fields. Please take this into consideration when testing or adopting this feature.
{{< /note >}}
{{% /capture %}}
{{% capture 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 where pods with containers running Windows workloads requiring GMSA credentials will get scheduled. This section covers a set of initial steps required once for each cluster:
### Enable the WindowsGMSA feature gate
In the alpha state, the `WindowsGMSA` feature gate needs to be enabled on kubelet on Windows nodes. This is required to pass down the GMSA credential specs from the cluster scoped configurations to the container runtime. See [Feature Gates](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) for an explanation of enabling feature gates. Please make sure `--feature-gates=WindowsGMSA=true` parameter exists in the kubelet.exe command line.
### Install the GMSACredentialSpec CRD
A [CustomResourceDefinition](https://kubernetes.io/docs/tasks/access-kubernetes-api/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.
1. A validating webhook ensures all references to GMSAs are authorized to be used by the pod service account.
Installing the above webhooks and associated objects require the steps below:
1. Create a certificate key pair (that will be used to allow the webhook container to communicate to the cluster)
1. Install a secret with the certificate from above.
1. Create a deployment for the core webhook logic.
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``` 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)
{{% /capture %}}
{{% capture 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 [here](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 [here](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).
Following are the steps for generating a GMSA credential spec YAML manually in JSON format and then converting it:
1. Import the CredentialSpec [module](https://github.com/MicrosoftDocs/Virtualization-Documentation/blob/live/windows-server-container-tools/ServiceAccounts/CredentialSpec.psm1): `ipmo CredentialSpec.psm1`
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. 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`:
```
apiVersion: windows.k8s.io/v1alpha1
kind: GMSACredentialSpec
metadata:
name: gmsa-WebApp1 #This is an arbitrary name but it will be used as a reference
credspec:
ActiveDirectoryConfig:
GroupManagedServiceAccounts:
- Name: WebApp1 #Username of the GMSA account
Scope: CONTOSO #NETBIOS Domain Name
- Name: WebApp1 #Username of the GMSA account
Scope: contoso.com #DNS Domain Name
CmsPlugins:
- ActiveDirectory
DomainJoinConfig:
DnsName: contoso.com #DNS Domain Name
DnsTreeName: contoso.com #DNS Domain Name Root
Guid: 244818ae-87ac-4fcd-92ec-e79e5252348a #GUID
MachineAccountName: WebApp1 #Username of the GMSA account
NetBiosName: CONTOSO #NETBIOS Domain Name
Sid: S-1-5-21-2126449477-2524075714-3094792973 #SID of GMSA
```
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`
```
#Create the Role to read the credspec
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: webapp1-role
rules:
- apiGroups: ["windows.k8s.io"]
resources: ["gmsacredentialspecs"]
verbs: ["use"]
resourceNames: ["gmsa-WebApp1"]
```
## 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.
```
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: allow-default-svc-account-read-on-gmsa-WebApp1
namespace: default
subjects:
- kind: ServiceAccount
name: default
namespace: default
roleRef:
kind: ClusterRole
name: webapp1-role
apiGroup: rbac.authorization.k8s.io
```
## Configure GMSA credential spec reference in pod spec
In the alpha stage of the feature, the annotation `pod.alpha.windows.kubernetes.io/gmsa-credential-spec-name` 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`:
```
apiVersion: apps/v1beta1
kind: Deployment
metadata:
labels:
run: with-creds
name: with-creds
namespace: default
spec:
replicas: 1
selector:
matchLabels:
run: with-creds
template:
metadata:
labels:
run: with-creds
annotations:
pod.alpha.windows.kubernetes.io/gmsa-credential-spec-name: gmsa-WebApp1 # This must be the name of the cred spec you created
spec:
containers:
- image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
imagePullPolicy: Always
name: iis
nodeSelector:
beta.kubernetes.io/os: windows
```
Individual containers in a pod spec can also specify the desired GMSA credspec using annotation `<containerName>.container.alpha.windows.kubernetes.io/gmsa-credential-spec`. For example:
```
apiVersion: apps/v1beta1
kind: Deployment
metadata:
labels:
run: with-creds
name: with-creds
namespace: default
spec:
replicas: 1
selector:
matchLabels:
run: with-creds
template:
metadata:
labels:
run: with-creds
annotations:
iis.container.alpha.windows.kubernetes.io/gmsa-credential-spec-name: gmsa-WebApp1 # This must be the name of the cred spec you created
spec:
containers:
- image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
imagePullPolicy: Always
name: iis
nodeSelector:
beta.kubernetes.io/os: windows
```
As pod specs with GMSA annotations (as described above) are applied in a cluster configured for GMSA, the following sequence of events take place:
1. The mutating webhook resolves and expands all references to GMSA credential spec resources to the contents of the GMSA credential spec.
1. The validating webhook ensures the service account associated with the pod is authorized for the "use" verb on the specified GMSA credential spec.
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.
{{% /capture %}}
content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-probes.md
+3 -3
View File
@@ -62,7 +62,7 @@ code. After 30 seconds, `cat /tmp/healthy` returns a failure code.
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/probe/exec-liveness.yaml
kubectl apply -f https://k8s.io/examples/pods/probe/exec-liveness.yaml
```
Within 30 seconds, view the Pod events:
@@ -163,7 +163,7 @@ checks will fail, and the kubelet will kill and restart the Container.
To try the HTTP liveness check, create a Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/probe/http-liveness.yaml
kubectl apply -f https://k8s.io/examples/pods/probe/http-liveness.yaml
```
After 10 seconds, view Pod events to verify that liveness probes have failed and
@@ -204,7 +204,7 @@ will be restarted.
To try the TCP liveness check, create a Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/probe/tcp-liveness-readiness.yaml
kubectl apply -f https://k8s.io/examples/pods/probe/tcp-liveness-readiness.yaml
```
After 15 seconds, view Pod events to verify that liveness probes:
content/en/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md
+3 -3
View File
@@ -73,7 +73,7 @@ PersistentVolumeClaim requests to this PersistentVolume.
Create the PersistentVolume:
kubectl create -f https://k8s.io/examples/pods/storage/pv-volume.yaml
kubectl apply -f https://k8s.io/examples/pods/storage/pv-volume.yaml
View information about the PersistentVolume:
@@ -98,7 +98,7 @@ Here is the configuration file for the PersistentVolumeClaim:
Create the PersistentVolumeClaim:
kubectl create -f https://k8s.io/examples/pods/storage/pv-claim.yaml
kubectl apply -f https://k8s.io/examples/pods/storage/pv-claim.yaml
After you create the PersistentVolumeClaim, the Kubernetes control plane looks
for a PersistentVolume that satisfies the claim's requirements. If the control
@@ -138,7 +138,7 @@ is a volume.
Create the Pod:
kubectl create -f https://k8s.io/examples/pods/storage/pv-pod.yaml
kubectl apply -f https://k8s.io/examples/pods/storage/pv-pod.yaml
Verify that the Container in the Pod is running;
content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md
+102 -4
View File
@@ -21,7 +21,10 @@ ConfigMaps allow you to decouple configuration artifacts from image content to k
{{% capture steps %}}
## Create a ConfigMap
## Create a ConfigMap
You can use either `kubectl create configmap` or a ConfigMap generator in `kustomization.yaml` to create a ConfigMap. Note that `kubectl` starts to support `kustomization.yaml` since 1.14.
### Create a ConfigMap Using kubectl create configmap
Use the `kubectl create configmap` command to create configmaps from [directories](#create-configmaps-from-directories), [files](#create-configmaps-from-files), or [literal values](#create-configmaps-from-literal-values):
@@ -40,7 +43,7 @@ You can use [`kubectl describe`](/docs/reference/generated/kubectl/kubectl-comma
[`kubectl get`](/docs/reference/generated/kubectl/kubectl-commands/#get) to retrieve information
about a ConfigMap.
### Create ConfigMaps from directories
#### Create ConfigMaps from directories
You can use `kubectl create configmap` to create a ConfigMap from multiple files in the same directory.
@@ -117,7 +120,7 @@ metadata:
uid: b4952dc3-d670-11e5-8cd0-68f728db1985
```
### Create ConfigMaps from files
#### Create ConfigMaps from files
You can use `kubectl create configmap` to create a ConfigMap from an individual file, or from multiple files.
@@ -300,7 +303,7 @@ metadata:
uid: 05f8da22-d671-11e5-8cd0-68f728db1985
```
### Create ConfigMaps from literal values
#### Create ConfigMaps from literal values
You can use `kubectl create configmap` with the `--from-literal` argument to define a literal value from the command line:
@@ -330,6 +333,101 @@ metadata:
uid: dadce046-d673-11e5-8cd0-68f728db1985
```
### Create a ConfigMap from generator
`kubectl` supports `kustomization.yaml` since 1.14.
You can also create a ConfigMap from generators and then apply it to create the object on
the Apiserver. The generators
should be specified in a `kustomization.yaml` inside a directory.
#### Generate ConfigMaps from files
For example, to generate a ConfigMap from files `configure-pod-container/configmap/kubectl/game.properties`
```shell
# Create a kustomization.yaml file with ConfigMapGenerator
cat <<EOF >./kustomization.yaml
configMapGenerator:
- name: game-config-4
files:
- configure-pod-container/configmap/kubectl/game.properties
EOF
```
Apply the kustomization directory to create the ConfigMap object.
```shell
kubectl apply -k .
configmap/game-config-4-m9dm2f92bt created
```
You can check that the ConfigMap was created like this:
```shell
kubectl get configmap
NAME DATA AGE
game-config-4-m9dm2f92bt 1 37s
kubectl describe configmaps/game-config-4-m9dm2f92bt
Name: game-config-4-m9dm2f92bt
Namespace: default
Labels: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"v1","data":{"game.properties":"enemies=aliens\nlives=3\nenemies.cheat=true\nenemies.cheat.level=noGoodRotten\nsecret.code.p...
Data
====
game.properties:
----
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
Events: <none>
```
Note that the generated ConfigMap name has a suffix appended by hashing the contents. This ensures that a
new ConfigMap is generated each time the content is modified.
#### Define the key to use when generating a ConfigMap from a file
You can define a key other than the file name to use in the ConfigMap generator.
For example, to generate a ConfigMap from files `configure-pod-container/configmap/kubectl/game.properties`
with the key `game-special-key`
```shell
# Create a kustomization.yaml file with ConfigMapGenerator
cat <<EOF >./kustomization.yaml
configMapGenerator:
- name: game-config-5
files:
- game-special-key=configure-pod-container/configmap/kubectl/game.properties
EOF
```
Apply the kustomization directory to create the ConfigMap object.
```shell
kubectl apply -k .
configmap/game-config-5-m67dt67794 created
```
#### Generate ConfigMaps from Literals
To generate a ConfigMap from literals `special.type=charm` and `special.how=very`,
you can specify the ConfigMap generator in `kusotmization.yaml` as
```shell
# Create a kustomization.yaml file with ConfigMapGenerator
cat <<EOF >./kustomization.yaml
configMapGenerator:
- name: special-config-2
literals:
- special.how=very
- special.type=charm
EOF
```
Apply the kustomization directory to create the ConfigMap object.
```shell
kubectl apply -k .
configmap/special-config-2-c92b5mmcf2 created
```
## Define container environment variables using ConfigMap data
content/en/docs/tasks/configure-pod-container/configure-pod-initialization.md
+1 -1
View File
@@ -43,7 +43,7 @@ of the nginx server.
Create the Pod:
kubectl create -f https://k8s.io/examples/pods/init-containers.yaml
kubectl apply -f https://k8s.io/examples/pods/init-containers.yaml
Verify that the nginx container is running:
content/en/docs/tasks/configure-pod-container/configure-projected-volume-storage.md
+1 -1
View File
@@ -42,7 +42,7 @@ Here is the configuration file for the Pod:
```
1. Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/storage/projected.yaml
kubectl apply -f https://k8s.io/examples/pods/storage/projected.yaml
```
1. Verify that the Pod's Container is running, and then watch for changes to
the Pod:
content/en/docs/tasks/configure-pod-container/configure-service-account.md
+2 -2
View File
@@ -90,7 +90,7 @@ default 1 1d
You can create additional ServiceAccount objects like this:
```shell
kubectl create -f - <<EOF
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
@@ -142,7 +142,7 @@ Suppose we have an existing service account named "build-robot" as mentioned abo
a new secret manually.
```shell
kubectl create -f - <<EOF
kubectl apply -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
content/en/docs/tasks/configure-pod-container/configure-volume-storage.md
+1 -1
View File
@@ -37,7 +37,7 @@ restarts. Here is the configuration file for the Pod:
1. Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/storage/redis.yaml
kubectl apply -f https://k8s.io/examples/pods/storage/redis.yaml
```
1. Verify that the Pod's Container is running, and then watch for changes to
content/en/docs/tasks/configure-pod-container/extended-resource.md
+2 -2
View File
@@ -43,7 +43,7 @@ In the configuration file, you can see that the Container requests 3 dongles.
Create a Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/resource/extended-resource-pod.yaml
kubectl apply -f https://k8s.io/examples/pods/resource/extended-resource-pod.yaml
```
Verify that the Pod is running:
@@ -80,7 +80,7 @@ used three of the four available dongles.
Attempt to create a Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/resource/extended-resource-pod-2.yaml
kubectl apply -f https://k8s.io/examples/pods/resource/extended-resource-pod-2.yaml
```
Describe the Pod
content/en/docs/tasks/configure-pod-container/pull-image-private-registry.md
+1 -1
View File
@@ -196,7 +196,7 @@ The `imagePullSecrets` field in the configuration file specifies that Kubernetes
Create a Pod that uses your Secret, and verify that the Pod is running:
```shell
kubectl create -f my-private-reg-pod.yaml
kubectl apply -f my-private-reg-pod.yaml
kubectl get pod private-reg
```
content/en/docs/tasks/configure-pod-container/quality-service-pod.md
+4 -4
View File
@@ -55,7 +55,7 @@ memory request, both equal to 200 MiB. The Container has a CPU limit and a CPU r
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/qos/qos-pod.yaml --namespace=qos-example
kubectl apply -f https://k8s.io/examples/pods/qos/qos-pod.yaml --namespace=qos-example
```
View detailed information about the Pod:
@@ -111,7 +111,7 @@ and a memory request of 100 MiB.
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/qos/qos-pod-2.yaml --namespace=qos-example
kubectl apply -f https://k8s.io/examples/pods/qos/qos-pod-2.yaml --namespace=qos-example
```
View detailed information about the Pod:
@@ -156,7 +156,7 @@ limits or requests:
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/qos/qos-pod-3.yaml --namespace=qos-example
kubectl apply -f https://k8s.io/examples/pods/qos/qos-pod-3.yaml --namespace=qos-example
```
View detailed information about the Pod:
@@ -195,7 +195,7 @@ criteria for QoS class Guaranteed, and one of its Containers has a memory reques
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/qos/qos-pod-4.yaml --namespace=qos-example
kubectl apply -f https://k8s.io/examples/pods/qos/qos-pod-4.yaml --namespace=qos-example
```
View detailed information about the Pod:
content/en/docs/tasks/configure-pod-container/security-context.md
+19 -10
View File
@@ -52,15 +52,16 @@ Here is a configuration file for a Pod that has a `securityContext` and an `empt
{{< codenew file="pods/security/security-context.yaml" >}}
In the configuration file, the `runAsUser` field specifies that for any Containers in
the Pod, the first process runs with user ID 1000. The `fsGroup` field specifies that
group ID 2000 is associated with all Containers in the Pod. Group ID 2000 is also
associated with the volume mounted at `/data/demo` and with any files created in that
volume.
the Pod, all processes run with user ID 1000. The `runAsGroup` field specifies the primary group ID of 3000 for
all processes within any containers of the Pod. If this field is ommitted, the primary group ID of the containers
will be root(0). Any files created will also be owned by user 1000 and group 3000 when `runAsGroup` is specified.
Since `fsGroup` field is specified, all processes of the container are also part of the supplementary group ID 2000.
The owner for volume `/data/demo` and any files created in that volume will be Group ID 2000.
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/security/security-context.yaml
kubectl apply -f https://k8s.io/examples/pods/security/security-context.yaml
```
Verify that the Pod's Container is running:
@@ -123,6 +124,16 @@ The output shows that `testfile` has group ID 2000, which is the value of `fsGro
-rw-r--r-- 1 1000 2000 6 Jun 6 20:08 testfile
```
Run the following command:
```shell
$ id
uid=1000 gid=3000 groups=2000
```
You will see that gid is 3000 which is same as `runAsGroup` field. If the `runAsGroup` was ommitted the gid would
remain as 0(root) and the process will be able to interact with files that are owned by root(0) group and that have
the required group permissions for root(0) group.
Exit your shell:
```shell
@@ -146,7 +157,7 @@ and the Container have a `securityContext` field:
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/security/security-context-2.yaml
kubectl apply -f https://k8s.io/examples/pods/security/security-context-2.yaml
```
Verify that the Pod's Container is running:
@@ -199,7 +210,7 @@ Here is configuration file that does not add or remove any Container capabilitie
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/security/security-context-3.yaml
kubectl apply -f https://k8s.io/examples/pods/security/security-context-3.yaml
```
Verify that the Pod's Container is running:
@@ -261,7 +272,7 @@ adds the `CAP_NET_ADMIN` and `CAP_SYS_TIME` capabilities:
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/security/security-context-4.yaml
kubectl apply -f https://k8s.io/examples/pods/security/security-context-4.yaml
```
Get a shell into the running Container:
@@ -357,5 +368,3 @@ After you specify an MCS label for a Pod, all Pods with the same label can acces
{{% /capture %}}
content/en/docs/tasks/configure-pod-container/share-process-namespace.md
+1 -1
View File
@@ -43,7 +43,7 @@ Process Namespace Sharing is enabled using the `ShareProcessNamespace` field of
1. Create the pod `nginx` on your cluster:
kubectl create -f https://k8s.io/examples/pods/share-process-namespace.yaml
kubectl apply -f https://k8s.io/examples/pods/share-process-namespace.yaml
1. Attach to the `shell` container and run `ps`:
content/en/docs/tasks/configure-pod-container/translate-compose-kubernetes.md
+6 -6
View File
@@ -124,7 +124,7 @@ you need is an existing `docker-compose.yml` file.
```bash
$ kompose up
We are going to create Kubernetes Deployments, Services and PersistentVolumeClaims for your Dockerized application.
If you need different kind of resources, use the 'kompose convert' and 'kubectl create -f' commands instead.
If you need different kind of resources, use the 'kompose convert' and 'kubectl apply -f' commands instead.
INFO Successfully created Service: redis
INFO Successfully created Service: web
@@ -135,7 +135,7 @@ you need is an existing `docker-compose.yml` file.
```
3. To convert the `docker-compose.yml` file to files that you can use with
`kubectl`, run `kompose convert` and then `kubectl create -f <output file>`.
`kubectl`, run `kompose convert` and then `kubectl apply -f <output file>`.
```bash
$ kompose convert
@@ -148,7 +148,7 @@ you need is an existing `docker-compose.yml` file.
```
```bash
$ kubectl create -f frontend-service.yaml,redis-master-service.yaml,redis-slave-service.yaml,frontend-deployment.yaml,redis-master-deployment.yaml,redis-slave-deployment.yaml
$ kubectl apply -f frontend-service.yaml,redis-master-service.yaml,redis-slave-service.yaml,frontend-deployment.yaml,redis-master-deployment.yaml,redis-slave-deployment.yaml
service/frontend created
service/redis-master created
service/redis-slave created
@@ -309,7 +309,7 @@ Kompose supports a straightforward way to deploy your "composed" application to
```sh
$ kompose --file ./examples/docker-guestbook.yml up
We are going to create Kubernetes deployments and services for your Dockerized application.
If you need different kind of resources, use the 'kompose convert' and 'kubectl create -f' commands instead.
If you need different kind of resources, use the 'kompose convert' and 'kubectl apply -f' commands instead.
INFO Successfully created service: redis-master
INFO Successfully created service: redis-slave
@@ -341,7 +341,7 @@ pod/redis-slave-2504961300-nve7b 1/1 Running 0 4m
**Note**:
- You must have a running Kubernetes cluster with a pre-configured kubectl context.
- Only deployments and services are generated and deployed to Kubernetes. If you need different kind of resources, use the `kompose convert` and `kubectl create -f` commands instead.
- Only deployments and services are generated and deployed to Kubernetes. If you need different kind of resources, use the `kompose convert` and `kubectl apply -f` commands instead.
### OpenShift
```sh
@@ -426,7 +426,7 @@ INFO Image 'docker.io/foo/bar' from directory 'build' built successfully
INFO Pushing image 'foo/bar:latest' to registry 'docker.io'
INFO Attempting authentication credentials 'https://index.docker.io/v1/
INFO Successfully pushed image 'foo/bar:latest' to registry 'docker.io'
INFO We are going to create Kubernetes Deployments, Services and PersistentVolumeClaims for your Dockerized application. If you need different kind of resources, use the 'kompose convert' and 'kubectl create -f' commands instead.
INFO We are going to create Kubernetes Deployments, Services and PersistentVolumeClaims for your Dockerized application. If you need different kind of resources, use the 'kompose convert' and 'kubectl apply -f' commands instead.
INFO Deploying application in "default" namespace
INFO Successfully created Service: foo