add en pages
This commit is contained in:
Karen Bradshaw
@@ -1,20 +1,21 @@
|
||||
---
|
||||
title: Assign CPU Resources to Containers and Pods
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
weight: 20
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
This page shows how to assign a CPU *request* and a CPU *limit* to
|
||||
a container. Containers cannot use more CPU than the configured limit.
|
||||
Provided the system has CPU time free, a container is guaranteed to be
|
||||
allocated as much CPU as it requests.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
@@ -48,10 +49,10 @@ NAME
|
||||
v1beta1.metrics.k8s.io
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Create a namespace
|
||||
|
||||
@@ -239,9 +240,10 @@ Delete your namespace:
|
||||
kubectl delete namespace cpu-example
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
|
||||
### For app developers
|
||||
@@ -266,4 +268,4 @@ kubectl delete namespace cpu-example
|
||||
|
||||
* [Configure Quotas for API Objects](/docs/tasks/administer-cluster/quota-api-object/)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -1,19 +1,20 @@
|
||||
---
|
||||
title: Assign Memory Resources to Containers and Pods
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
weight: 10
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
This page shows how to assign a memory *request* and a memory *limit* to a
|
||||
Container. A Container is guaranteed to have as much memory as it requests,
|
||||
but is not allowed to use more memory than its limit.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
@@ -46,9 +47,9 @@ NAME
|
||||
v1beta1.metrics.k8s.io
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Create a namespace
|
||||
|
||||
@@ -330,9 +331,10 @@ Delete your namespace. This deletes all the Pods that you created for this task:
|
||||
kubectl delete namespace mem-example
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
### For app developers
|
||||
|
||||
@@ -356,7 +358,7 @@ kubectl delete namespace mem-example
|
||||
|
||||
* [Configure Quotas for API Objects](/docs/tasks/administer-cluster/quota-api-object/)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
+11
-9
@@ -1,22 +1,23 @@
|
||||
---
|
||||
title: Assign Pods to Nodes using Node Affinity
|
||||
min-kubernetes-server-version: v1.10
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
weight: 120
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
This page shows how to assign a Kubernetes Pod to a particular node using Node Affinity in a
|
||||
Kubernetes cluster.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Add a label to a node
|
||||
|
||||
@@ -112,9 +113,10 @@ This means that the pod will prefer a node that has a `disktype=ssd` label.
|
||||
nginx 1/1 Running 0 13s 10.200.0.4 worker0
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
Learn more about
|
||||
[Node Affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity).
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -1,21 +1,22 @@
|
||||
---
|
||||
title: Assign Pods to Nodes
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
weight: 120
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
This page shows how to assign a Kubernetes Pod to a particular node in a
|
||||
Kubernetes cluster.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Add a label to a node
|
||||
|
||||
@@ -94,10 +95,11 @@ You can also schedule a pod to one specific node via setting `nodeName`.
|
||||
|
||||
Use the configuration file to create a pod that will get scheduled on `foo-node` only.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* Learn more about [labels and selectors](/docs/concepts/overview/working-with-objects/labels/).
|
||||
* Learn more about [nodes](/docs/concepts/architecture/nodes/).
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
@@ -1,27 +1,28 @@
|
||||
---
|
||||
title: Attach Handlers to Container Lifecycle Events
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
weight: 140
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
This page shows how to attach handlers to Container lifecycle events. Kubernetes supports
|
||||
the postStart and preStop events. Kubernetes sends the postStart event immediately
|
||||
after a Container is started, and it sends the preStop event immediately before the
|
||||
Container is terminated.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Define postStart and preStop handlers
|
||||
|
||||
@@ -56,11 +57,11 @@ The output shows the text written by the postStart handler:
|
||||
|
||||
Hello from the postStart handler
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
{{% capture discussion %}}
|
||||
|
||||
<!-- discussion -->
|
||||
|
||||
## Discussion
|
||||
|
||||
@@ -82,10 +83,11 @@ This means that the preStop hook is not invoked when the Pod is *completed*.
|
||||
This limitation is tracked in [issue #55087](https://github.com/kubernetes/kubernetes/issues/55807).
|
||||
{{< /note >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* Learn more about [Container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/).
|
||||
* Learn more about the [lifecycle of a Pod](/docs/concepts/workloads/pods/pod-lifecycle/).
|
||||
@@ -97,6 +99,6 @@ This limitation is tracked in [issue #55087](https://github.com/kubernetes/kuber
|
||||
* [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
|
||||
* See `terminationGracePeriodSeconds` in [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
---
|
||||
title: Configure GMSA for Windows Pods and containers
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
weight: 20
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state for_k8s_version="v1.18" state="stable" >}}
|
||||
|
||||
@@ -12,9 +12,10 @@ This page shows how to configure [Group Managed Service Accounts](https://docs.m
|
||||
|
||||
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.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
## {{% 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:
|
||||
|
||||
@@ -43,9 +44,9 @@ A [script](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission
|
||||
|
||||
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 %}}
|
||||
|
||||
<!-- 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)
|
||||
@@ -252,4 +253,4 @@ If the above command corrects the error, you can automate the step by adding the
|
||||
|
||||
If you add the `lifecycle` section show above to your Pod spec, the Pod will execute the commands listed to restart the `netlogon` service until the `nltest.exe /query` command exits without error.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
+11
-9
@@ -1,10 +1,10 @@
|
||||
---
|
||||
title: Configure Liveness, Readiness and Startup Probes
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
weight: 110
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
This page shows how to configure liveness, readiness and startup probes for containers.
|
||||
|
||||
@@ -25,15 +25,16 @@ it succeeds, making sure those probes don't interfere with the application start
|
||||
This can be used to adopt liveness checks on slow starting containers, avoiding them
|
||||
getting killed by the kubelet before they are up and running.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Define a liveness command
|
||||
|
||||
@@ -360,9 +361,10 @@ For a TCP probe, the kubelet makes the probe connection at the node, not in the
|
||||
means that you can not use a service name in the `host` parameter since the kubelet is unable
|
||||
to resolve it.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* Learn more about
|
||||
[Container Probes](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes).
|
||||
@@ -373,6 +375,6 @@ You can also read the API references for:
|
||||
* [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
|
||||
* [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
|
||||
+13
-11
@@ -1,10 +1,10 @@
|
||||
---
|
||||
title: Configure a Pod to Use a PersistentVolume for Storage
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
weight: 60
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
This page shows you how to configure a Pod to use a
|
||||
{{< glossary_tooltip text="PersistentVolumeClaim" term_id="persistent-volume-claim" >}}
|
||||
@@ -20,9 +20,10 @@ PersistentVolume.
|
||||
|
||||
1. You create a Pod that uses the above PersistentVolumeClaim for storage.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
* You need to have a Kubernetes cluster that has only one Node, and the
|
||||
{{< glossary_tooltip text="kubectl" term_id="kubectl" >}}
|
||||
@@ -33,9 +34,9 @@ do not already have a single-node cluster, you can create one by using
|
||||
* Familiarize yourself with the material in
|
||||
[Persistent Volumes](/docs/concepts/storage/persistent-volumes/).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Create an index.html file on your Node
|
||||
|
||||
@@ -237,10 +238,10 @@ sudo rmdir /mnt/data
|
||||
|
||||
You can now close the shell to your Node.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture discussion %}}
|
||||
|
||||
<!-- discussion -->
|
||||
|
||||
## Access control
|
||||
|
||||
@@ -270,10 +271,11 @@ When a Pod consumes a PersistentVolume, the GIDs associated with the
|
||||
PersistentVolume are not present on the Pod resource itself.
|
||||
{{< /note >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* Learn more about [PersistentVolumes](/docs/concepts/storage/persistent-volumes/).
|
||||
* Read the [Persistent Storage design document](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md).
|
||||
@@ -285,6 +287,6 @@ PersistentVolume are not present on the Pod resource itself.
|
||||
* [PersistentVolumeClaim](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core)
|
||||
* [PersistentVolumeClaimSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaimspec-v1-core)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,24 +1,25 @@
|
||||
---
|
||||
title: Configure a Pod to Use a ConfigMap
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
weight: 150
|
||||
card:
|
||||
name: tasks
|
||||
weight: 50
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
ConfigMaps allow you to decouple configuration artifacts from image content to keep containerized applications portable. This page provides a series of usage examples demonstrating how to create ConfigMaps and configure Pods using data stored in ConfigMaps.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
|
||||
## Create a ConfigMap
|
||||
@@ -628,9 +629,9 @@ When a ConfigMap already being consumed in a volume is updated, projected keys a
|
||||
A container using a ConfigMap as a [subPath](/docs/concepts/storage/volumes/#using-subpath) volume will not receive ConfigMap updates.
|
||||
{{< /note >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture discussion %}}
|
||||
|
||||
<!-- discussion -->
|
||||
|
||||
## Understanding ConfigMaps and Pods
|
||||
|
||||
@@ -680,9 +681,10 @@ data:
|
||||
|
||||
- You can't use ConfigMaps for {{< glossary_tooltip text="static pods" term_id="static-pod" >}}, because the Kubelet does not support this.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* Follow a real world example of [Configuring Redis using a ConfigMap](/docs/tutorials/configuration/configure-redis-using-configmap/).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -1,22 +1,23 @@
|
||||
---
|
||||
title: Configure Pod Initialization
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
weight: 130
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
This page shows how to use an Init Container to initialize a Pod before an
|
||||
application Container runs.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Create a Pod that has an Init Container
|
||||
|
||||
@@ -78,9 +79,10 @@ The output shows that nginx is serving the web page that was written by the init
|
||||
<p>Kubernetes is open source giving you the freedom to take advantage ...</p>
|
||||
...
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* Learn more about
|
||||
[communicating between Containers running in the same Pod](/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/).
|
||||
@@ -88,6 +90,6 @@ The output shows that nginx is serving the web page that was written by the init
|
||||
* Learn more about [Volumes](/docs/concepts/storage/volumes/).
|
||||
* Learn more about [Debugging Init Containers](/docs/tasks/debug-application-cluster/debug-init-containers/)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
|
||||
+11
-9
@@ -3,11 +3,11 @@ reviewers:
|
||||
- jpeeler
|
||||
- pmorie
|
||||
title: Configure a Pod to Use a Projected Volume for Storage
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
weight: 70
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
This page shows how to use a [`projected`](/docs/concepts/storage/volumes/#projected) Volume to mount
|
||||
several existing volume sources into the same directory. Currently, `secret`, `configMap`, `downwardAPI`,
|
||||
and `serviceAccountToken` volumes can be projected.
|
||||
@@ -15,13 +15,14 @@ and `serviceAccountToken` volumes can be projected.
|
||||
{{< note >}}
|
||||
`serviceAccountToken` is not a volume type.
|
||||
{{< /note >}}
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
<!-- steps -->
|
||||
## Configure a projected volume for a pod
|
||||
|
||||
In this exercise, you create username and password {{< glossary_tooltip text="Secrets" term_id="secret" >}} from local files. You then create a Pod that runs one container, using a [`projected`](/docs/concepts/storage/volumes/#projected) Volume to mount the Secrets into the same shared directory.
|
||||
@@ -77,9 +78,10 @@ kubectl delete pod test-projected-volume
|
||||
kubectl delete secret user pass
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* Learn more about [`projected`](/docs/concepts/storage/volumes/#projected) volumes.
|
||||
* Read the [all-in-one volume](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/node/all-in-one-volume.md) design document.
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -1,24 +1,25 @@
|
||||
---
|
||||
title: Configure RunAsUserName for Windows pods and containers
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
weight: 20
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state for_k8s_version="v1.18" state="stable" >}}
|
||||
|
||||
This page shows how to use the `runAsUserName` setting for Pods and containers that will run on Windows nodes. This is roughly equivalent of the Linux-specific `runAsUser` setting, allowing you to run applications in a container as a different username than the default.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
## {{% 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 where pods with containers running Windows workloads will get scheduled.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Set the Username for a Pod
|
||||
|
||||
@@ -114,12 +115,12 @@ Examples of acceptable values for the `runAsUserName` field: `ContainerAdministr
|
||||
|
||||
For more information about these limtations, check [here](https://support.microsoft.com/en-us/help/909264/naming-conventions-in-active-directory-for-computers-domains-sites-and) and [here](https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.localaccounts/new-localuser?view=powershell-5.1).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* [Guide for scheduling Windows containers in Kubernetes](/docs/setup/production-environment/windows/user-guide-windows-containers/)
|
||||
* [Managing Workload Identity with Group Managed Service Accounts (GMSA)](/docs/setup/production-environment/windows/user-guide-windows-containers/#managing-workload-identity-with-group-managed-service-accounts)
|
||||
* [Configure GMSA for Windows pods and containers](/docs/tasks/configure-pod-container/configure-gmsa/)
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -4,11 +4,11 @@ reviewers:
|
||||
- liggitt
|
||||
- thockin
|
||||
title: Configure Service Accounts for Pods
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
weight: 90
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
A service account provides an identity for processes that run in a Pod.
|
||||
|
||||
{{< note >}}
|
||||
@@ -23,16 +23,17 @@ authenticated by the apiserver as a particular User Account (currently this is
|
||||
usually `admin`, unless your cluster administrator has customized your cluster). Processes in containers inside pods can also contact the apiserver.
|
||||
When they do, they are authenticated as a particular Service Account (for example, `default`).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Use the Default Service Account to access the API server.
|
||||
|
||||
@@ -370,9 +371,10 @@ override the `jwks_uri` in the OpenID Provider Configuration so that it points
|
||||
to the public endpoint, rather than the API server's address, by passing the
|
||||
`--service-account-jwks-uri` flag to the API server. Like the issuer URL, the
|
||||
JWKS URI is required to use the `https` scheme.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
See also:
|
||||
|
||||
@@ -380,4 +382,4 @@ See also:
|
||||
- [Service Account Signing Key Retrieval KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/20190730-oidc-discovery.md)
|
||||
- [OIDC Discovery Spec](https://openid.net/specs/openid-connect-discovery-1_0.html)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
---
|
||||
title: Configure a Pod to Use a Volume for Storage
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
weight: 50
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
This page shows how to configure a Pod to use a Volume for storage.
|
||||
|
||||
@@ -14,15 +14,16 @@ consistent storage that is independent of the Container, you can use a
|
||||
[Volume](/docs/concepts/storage/volumes/). This is especially important for stateful
|
||||
applications, such as key-value stores (such as Redis) and databases.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Configure a volume for a Pod
|
||||
|
||||
@@ -126,9 +127,10 @@ of `Always`.
|
||||
kubectl delete pod redis
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* See [Volume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core).
|
||||
|
||||
@@ -140,6 +142,6 @@ GCE and EBS on EC2, which are preferred for critical data and will handle
|
||||
details such as mounting and unmounting the devices on the nodes. See
|
||||
[Volumes](/docs/concepts/storage/volumes/) for more details.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,19 +1,20 @@
|
||||
---
|
||||
title: Assign Extended Resources to a Container
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
weight: 40
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state state="stable" >}}
|
||||
|
||||
This page shows how to assign extended resources to a Container.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
@@ -21,10 +22,10 @@ Before you do this exercise, do the exercise in
|
||||
[Advertise Extended Resources for a Node](/docs/tasks/administer-cluster/extended-resource-node/).
|
||||
That will configure one of your Nodes to advertise a dongle resource.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Assign an extended resource to a Pod
|
||||
|
||||
@@ -127,9 +128,10 @@ kubectl delete pod extended-resource-demo
|
||||
kubectl delete pod extended-resource-demo-2
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
### For application developers
|
||||
|
||||
@@ -140,4 +142,4 @@ kubectl delete pod extended-resource-demo-2
|
||||
|
||||
* [Advertise Extended Resources for a Node](/docs/tasks/administer-cluster/extended-resource-node/)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -1,26 +1,27 @@
|
||||
---
|
||||
title: Pull an Image from a Private Registry
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
weight: 100
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
This page shows how to create a Pod that uses a Secret to pull an image from a
|
||||
private Docker registry or repository.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
* To do this exercise, you need a
|
||||
[Docker ID](https://docs.docker.com/docker-id/) and password.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Log in to Docker
|
||||
|
||||
@@ -200,9 +201,10 @@ kubectl apply -f my-private-reg-pod.yaml
|
||||
kubectl get pod private-reg
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* Learn more about [Secrets](/docs/concepts/configuration/secret/).
|
||||
* Learn more about [using a private registry](/docs/concepts/containers/images/#using-a-private-registry).
|
||||
@@ -211,5 +213,5 @@ kubectl get pod private-reg
|
||||
* See [Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core).
|
||||
* See the `imagePullSecrets` field of [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
@@ -1,27 +1,28 @@
|
||||
---
|
||||
title: Configure Quality of Service for Pods
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
weight: 30
|
||||
---
|
||||
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
This page shows how to configure Pods so that they will be assigned particular
|
||||
Quality of Service (QoS) classes. Kubernetes uses QoS classes to make decisions about
|
||||
scheduling and evicting Pods.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## QoS classes
|
||||
|
||||
@@ -235,9 +236,10 @@ Delete your namespace:
|
||||
kubectl delete namespace qos-example
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
|
||||
### For app developers
|
||||
@@ -263,7 +265,7 @@ kubectl delete namespace qos-example
|
||||
* [Configure Quotas for API Objects](/docs/tasks/administer-cluster/quota-api-object/)
|
||||
|
||||
* [Control Topology Management policies on a node](/docs/tasks/administer-cluster/topology-manager/)
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -4,11 +4,11 @@ reviewers:
|
||||
- mikedanese
|
||||
- thockin
|
||||
title: Configure a Security Context for a Pod or Container
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
weight: 80
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
A security context defines privilege and access control settings for
|
||||
a Pod or Container. Security context settings include, but are not limited to:
|
||||
@@ -37,15 +37,16 @@ for a comprehensive list.
|
||||
For more information about security mechanisms in Linux, see
|
||||
[Overview of Linux Kernel Security Features](https://www.linux.com/learn/overview-linux-kernel-security-features)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Set the security context for a Pod
|
||||
|
||||
@@ -409,9 +410,10 @@ kubectl delete pod security-context-demo-3
|
||||
kubectl delete pod security-context-demo-4
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* [PodSecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritycontext-v1-core)
|
||||
* [SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core)
|
||||
@@ -423,4 +425,4 @@ kubectl delete pod security-context-demo-4
|
||||
document](https://git.k8s.io/community/contributors/design-proposals/auth/no-new-privs.md)
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -5,11 +5,11 @@ reviewers:
|
||||
- verb
|
||||
- yujuhong
|
||||
- dchen1107
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
weight: 160
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state state="stable" for_k8s_version="v1.17" >}}
|
||||
|
||||
@@ -21,15 +21,16 @@ You can use this feature to configure cooperating containers, such as a log
|
||||
handler sidecar container, or to troubleshoot container images that don't
|
||||
include debugging utilities like a shell.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Configure a Pod
|
||||
|
||||
@@ -93,9 +94,9 @@ events {
|
||||
worker_connections 1024;
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture discussion %}}
|
||||
|
||||
<!-- discussion -->
|
||||
|
||||
## Understanding Process Namespace Sharing
|
||||
|
||||
@@ -117,6 +118,6 @@ containers, though, so it's important to understand these differences:
|
||||
`/proc/$pid/root` link.** This makes debugging easier, but it also means
|
||||
that filesystem secrets are protected only by filesystem permissions.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -3,10 +3,10 @@ reviewers:
|
||||
- jsafrane
|
||||
title: Create static Pods
|
||||
weight: 170
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
|
||||
*Static Pods* are managed directly by the kubelet daemon on a specific node,
|
||||
@@ -30,9 +30,10 @@ Pods to run a Pod on every node, you should probably be using a
|
||||
instead.
|
||||
{{< /note >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
@@ -41,10 +42,10 @@ and that your nodes are running the Fedora operating system.
|
||||
Instructions for other distributions or Kubernetes installations may vary.
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Create a static pod {#static-pod-creation}
|
||||
|
||||
@@ -236,4 +237,4 @@ CONTAINER ID IMAGE COMMAND CREATED ...
|
||||
e7a62e3427f1 nginx:latest "nginx -g 'daemon of 27 seconds ago
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -2,26 +2,27 @@
|
||||
reviewers:
|
||||
- cdrage
|
||||
title: Translate a Docker Compose File to Kubernetes Resources
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
weight: 200
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
What's Kompose? It's a conversion tool for all things compose (namely Docker Compose) to container orchestrators (Kubernetes or OpenShift).
|
||||
|
||||
More information can be found on the Kompose website at [http://kompose.io](http://kompose.io).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Install Kompose
|
||||
|
||||
@@ -200,9 +201,9 @@ you need is an existing `docker-compose.yml` file.
|
||||
$ curl http://192.0.2.89
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture discussion %}}
|
||||
|
||||
<!-- discussion -->
|
||||
|
||||
## User Guide
|
||||
|
||||
@@ -606,4 +607,4 @@ Kompose supports Docker Compose versions: 1, 2 and 3. We have limited support on
|
||||
|
||||
A full list on compatibility between all three versions is listed in our [conversion document](https://github.com/kubernetes/kompose/blob/master/docs/conversion.md) including a list of all incompatible Docker Compose keys.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
Reference in New Issue
Block a user