Merge remote-tracking branch 'upstream/master' into HEAD
This commit is contained in:
simplytunde
@@ -111,9 +111,8 @@ on a Node.
|
||||
|
||||
### Info
|
||||
|
||||
General information about the node, such as kernel version, Kubernetes version
|
||||
(kubelet and kube-proxy version), Docker version (if used), OS name.
|
||||
The information is gathered by Kubelet from the node.
|
||||
Describes general information about the node, such as kernel version, Kubernetes version (kubelet and kube-proxy version), Docker version (if used), and OS name.
|
||||
This information is gathered by Kubelet from the node.
|
||||
|
||||
## Management
|
||||
|
||||
|
||||
@@ -70,7 +70,7 @@ Credentials can be provided in several ways:
|
||||
- Configuring Nodes to Authenticate to a Private Registry
|
||||
- all pods can read any configured private registries
|
||||
- requires node configuration by cluster administrator
|
||||
- Pre-pulling Images
|
||||
- Pre-pulled Images
|
||||
- all pods can use any images cached on a node
|
||||
- requires root access to all nodes to setup
|
||||
- Specifying ImagePullSecrets on a Pod
|
||||
@@ -243,7 +243,7 @@ template needs to include the `.docker/config.json` or mount a drive that contai
|
||||
All pods will have read access to images in any private registry once private
|
||||
registry keys are added to the `.docker/config.json`.
|
||||
|
||||
### Pre-pulling Images
|
||||
### Pre-pulled Images
|
||||
|
||||
{{< note >}}
|
||||
If you are running on Google Kubernetes Engine, there will already be a `.dockercfg` on each node with credentials for Google Container Registry. You cannot use this approach.
|
||||
|
||||
@@ -6,31 +6,33 @@ content_template: templates/concept
|
||||
weight: 20
|
||||
---
|
||||
|
||||
{{< feature-state state="beta" >}}
|
||||
|
||||
{{% capture overview %}}
|
||||
Starting in version 1.8, Kubernetes provides a
|
||||
[device plugin framework](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/resource-management/device-plugin.md)
|
||||
for vendors to advertise their resources to the kubelet without changing Kubernetes core code.
|
||||
Instead of writing custom Kubernetes code, vendors can implement a device plugin that can
|
||||
be deployed manually or as a DaemonSet. The targeted devices include GPUs,
|
||||
High-performance NICs, FPGAs, InfiniBand, and other similar computing resources
|
||||
that may require vendor specific initialization and setup.
|
||||
{{< feature-state for_k8s_version="v1.10" state="beta" >}}
|
||||
|
||||
Kubernetes provides a [device plugin framework](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/resource-management/device-plugin.md)
|
||||
that you can use to advertise system hardware resources to the
|
||||
{{< glossary_tooltip term_id="kubelet" >}}.
|
||||
|
||||
Instead of customising the code for Kubernetes itself, vendors can implement a
|
||||
device plugin that you deploy either manually or as a {{< glossary_tooltip term_id="daemonset" >}}.
|
||||
The targeted devices include GPUs, high-performance NICs, FPGAs, InfiniBand adapters,
|
||||
and other similar computing resources that may require vendor specific initialization
|
||||
and setup.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Device plugin registration
|
||||
|
||||
The device plugins feature is gated by the `DevicePlugins` feature gate which
|
||||
is disabled by default before 1.10. When the device plugins feature is enabled,
|
||||
the kubelet exports a `Registration` gRPC service:
|
||||
The kubelet exports a `Registration` gRPC service:
|
||||
|
||||
```gRPC
|
||||
service Registration {
|
||||
rpc Register(RegisterRequest) returns (Empty) {}
|
||||
}
|
||||
```
|
||||
|
||||
A device plugin can register itself with the kubelet through this gRPC service.
|
||||
During the registration, the device plugin needs to send:
|
||||
|
||||
@@ -38,15 +40,15 @@ During the registration, the device plugin needs to send:
|
||||
* The Device Plugin API version against which it was built.
|
||||
* The `ResourceName` it wants to advertise. Here `ResourceName` needs to follow the
|
||||
[extended resource naming scheme](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)
|
||||
as `vendor-domain/resource`.
|
||||
For example, an Nvidia GPU is advertised as `nvidia.com/gpu`.
|
||||
as `vendor-domain/resourcetype`.
|
||||
(For example, an NVIDIA GPU is advertised as `nvidia.com/gpu`.)
|
||||
|
||||
Following a successful registration, the device plugin sends the kubelet the
|
||||
list of devices it manages, and the kubelet is then in charge of advertising those
|
||||
resources to the API server as part of the kubelet node status update.
|
||||
For example, after a device plugin registers `vendor-domain/foo` with the kubelet
|
||||
For example, after a device plugin registers `hardware-vendor.example/foo` with the kubelet
|
||||
and reports two healthy devices on a node, the node status is updated
|
||||
to advertise 2 `vendor-domain/foo`.
|
||||
to advertise that the node has 2 “Foo” devices installed and available.
|
||||
|
||||
Then, users can request devices in a
|
||||
[Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
|
||||
@@ -55,10 +57,11 @@ specification as they request other types of resources, with the following limit
|
||||
* Extended resources are only supported as integer resources and cannot be overcommitted.
|
||||
* Devices cannot be shared among Containers.
|
||||
|
||||
Suppose a Kubernetes cluster is running a device plugin that advertises resource `vendor-domain/resource`
|
||||
on certain nodes, here is an example user pod requesting this resource:
|
||||
Suppose a Kubernetes cluster is running a device plugin that advertises resource `hardware-vendor.example/foo`
|
||||
on certain nodes. Here is an example of a pod requesting this resource to run a demo workload:
|
||||
|
||||
```yaml
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
@@ -69,7 +72,14 @@ spec:
|
||||
image: k8s.gcr.io/pause:2.0
|
||||
resources:
|
||||
limits:
|
||||
vendor-domain/resource: 2 # requesting 2 vendor-domain/resource
|
||||
hardware-vendor.example/foo: 2
|
||||
#
|
||||
# This Pod needs 2 of the hardware-vendor.example/foo devices
|
||||
# and can only schedule onto a Node that's able to satisfy
|
||||
# that need.
|
||||
#
|
||||
# If the Node has more than 2 of those devices available, the
|
||||
# remainder would be available for other Pods to use.
|
||||
```
|
||||
|
||||
## Device plugin implementation
|
||||
@@ -107,6 +117,8 @@ If the operations succeed, the device plugin returns an `AllocateResponse` that
|
||||
runtime configurations for accessing the allocated devices. The kubelet passes this information
|
||||
to the container runtime.
|
||||
|
||||
### Handling kubelet restarts
|
||||
|
||||
A device plugin is expected to detect kubelet restarts and re-register itself with the new
|
||||
kubelet instance. In the current implementation, a new kubelet instance deletes all the existing Unix sockets
|
||||
under `/var/lib/kubelet/device-plugins` when it starts. A device plugin can monitor the deletion
|
||||
@@ -114,37 +126,44 @@ of its Unix socket and re-register itself upon such an event.
|
||||
|
||||
## Device plugin deployment
|
||||
|
||||
A device plugin can be deployed manually or as a DaemonSet. Being deployed as a DaemonSet has
|
||||
the benefit that Kubernetes can restart the device plugin if it fails.
|
||||
Otherwise, an extra mechanism is needed to recover from device plugin failures.
|
||||
You can deploy a device plugin as a DaemonSet, as a package for your node's operating system,
|
||||
or manually.
|
||||
|
||||
The canonical directory `/var/lib/kubelet/device-plugins` requires privileged access,
|
||||
so a device plugin must run in a privileged security context.
|
||||
If a device plugin is running as a DaemonSet, `/var/lib/kubelet/device-plugins`
|
||||
must be mounted as a
|
||||
[Volume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core)
|
||||
If you're deploying a device plugin as a DaemonSet, `/var/lib/kubelet/device-plugins`
|
||||
must be mounted as a {{< glossary_tooltip term_id="volume" >}}
|
||||
in the plugin's
|
||||
[PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).
|
||||
|
||||
Kubernetes device plugin support is in beta. As development continues, its API version can
|
||||
change. We recommend that device plugin developers do the following:
|
||||
If you choose the DaemonSet approach you can rely on Kubernetes to: place the device plugin's
|
||||
Pod onto Nodes, to restart the daemon Pod after failure, and to help automate upgrades.
|
||||
|
||||
## API compatibility
|
||||
|
||||
Kubernetes device plugin support is in beta. The API may change before stabilization,
|
||||
in incompatible ways. As a project, Kubernetes recommends that device plugin developers:
|
||||
|
||||
* Watch for changes in future releases.
|
||||
* Support multiple versions of the device plugin API for backward/forward compatibility.
|
||||
|
||||
If you enable the DevicePlugins feature and run device plugins on nodes that need to be upgraded to
|
||||
a Kubernetes release with a newer device plugin API version, upgrade your device plugins
|
||||
to support both versions before upgrading these nodes to
|
||||
to support both versions before upgrading these nodes. Taking that approach will
|
||||
ensure the continuous functioning of the device allocations during the upgrade.
|
||||
|
||||
## Monitoring Device Plugin Resources
|
||||
|
||||
In order to monitor resources provided by device plugins, monitoring agents need to be able to
|
||||
discover the set of devices that are in-use on the node and obtain metadata to describe which
|
||||
container the metric should be associated with. Prometheus metrics exposed by device monitoring
|
||||
agents should follow the
|
||||
[Kubernetes Instrumentation Guidelines](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/instrumentation.md),
|
||||
which requires identifying containers using `pod`, `namespace`, and `container` prometheus labels.
|
||||
The kubelet provides a gRPC service to enable discovery of in-use devices, and to provide metadata
|
||||
{{< feature-state for_k8s_version="v1.13" state="alpha" >}}
|
||||
|
||||
In order to monitor resources provided by device plugins, monitoring agents need to be able to
|
||||
discover the set of devices that are in-use on the node and obtain metadata to describe which
|
||||
container the metric should be associated with. [Prometheus](https://prometheus.io/) metrics
|
||||
exposed by device monitoring agents should follow the
|
||||
[Kubernetes Instrumentation Guidelines](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/instrumentation.md),
|
||||
identifying containers using `pod`, `namespace`, and `container` prometheus labels.
|
||||
|
||||
The kubelet provides a gRPC service to enable discovery of in-use devices, and to provide metadata
|
||||
for these devices:
|
||||
|
||||
```gRPC
|
||||
@@ -155,31 +174,36 @@ service PodResourcesLister {
|
||||
}
|
||||
```
|
||||
|
||||
The gRPC service is served over a unix socket at `/var/lib/kubelet/pod-resources/kubelet.sock`.
|
||||
Monitoring agents for device plugin resources can be deployed as a daemon, or as a DaemonSet.
|
||||
The canonical directory `/var/lib/kubelet/pod-resources` requires privileged access, so monitoring
|
||||
agents must run in a privileged security context. If a device monitoring agent is running as a
|
||||
DaemonSet, `/var/lib/kubelet/pod-resources` must be mounted as a
|
||||
[Volume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core)
|
||||
in the plugin's
|
||||
The gRPC service is served over a unix socket at `/var/lib/kubelet/pod-resources/kubelet.sock`.
|
||||
Monitoring agents for device plugin resources can be deployed as a daemon, or as a DaemonSet.
|
||||
The canonical directory `/var/lib/kubelet/pod-resources` requires privileged access, so monitoring
|
||||
agents must run in a privileged security context. If a device monitoring agent is running as a
|
||||
DaemonSet, `/var/lib/kubelet/pod-resources` must be mounted as a
|
||||
{{< glossary_tooltip term_id="volume" >}} in the plugin's
|
||||
[PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).
|
||||
|
||||
Support for the "PodResources service" is in beta, and is enabled by default.
|
||||
|
||||
## Examples
|
||||
## Device plugin examples {#examples}
|
||||
|
||||
For examples of device plugin implementations, see:
|
||||
Here are some examples of device plugin implementations:
|
||||
|
||||
* The official [NVIDIA GPU device plugin](https://github.com/NVIDIA/k8s-device-plugin)
|
||||
* Requires [nvidia-docker 2.0](https://github.com/NVIDIA/nvidia-docker) which allows you to run GPU enabled docker containers.
|
||||
* A detailed guide on how to [schedule NVIDIA GPUs](/docs/tasks/manage-gpus/scheduling-gpus) on k8s.
|
||||
* The [NVIDIA GPU device plugin for COS base OS](https://github.com/GoogleCloudPlatform/container-engine-accelerators/tree/master/cmd/nvidia_gpu)
|
||||
* The [AMD GPU device plugin](https://github.com/RadeonOpenCompute/k8s-device-plugin)
|
||||
* The [Intel device plugins](https://github.com/intel/intel-device-plugins-for-kubernetes) for Intel GPU, FPGA and QuickAssist devices
|
||||
* The [KubeVirt device plugins](https://github.com/kubevirt/kubernetes-device-plugins) for hardware-assisted virtualization
|
||||
* The [NVIDIA GPU device plugin](https://github.com/NVIDIA/k8s-device-plugin)
|
||||
* Requires [nvidia-docker](https://github.com/NVIDIA/nvidia-docker) 2.0, which allows you to run GPU-enabled Docker containers.
|
||||
* The [NVIDIA GPU device plugin for Container-Optimized OS](https://github.com/GoogleCloudPlatform/container-engine-accelerators/tree/master/cmd/nvidia_gpu)
|
||||
* The [RDMA device plugin](https://github.com/hustcat/k8s-rdma-device-plugin)
|
||||
* The [Solarflare device plugin](https://github.com/vikaschoudhary16/sfc-device-plugin)
|
||||
* The [AMD GPU device plugin](https://github.com/RadeonOpenCompute/k8s-device-plugin)
|
||||
* The [SRIOV Network device plugin](https://github.com/intel/sriov-network-device-plugin)
|
||||
* The [Intel device plugins](https://github.com/intel/intel-device-plugins-for-kubernetes) for GPU, FPGA and QuickAssist devices
|
||||
* The [SR-IOV Network device plugin](https://github.com/intel/sriov-network-device-plugin)
|
||||
* The [Xilinx FPGA device plugins](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin/trunk) for Xilinx FPGA devices
|
||||
|
||||
{{% /capture %}}
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* Learn about [scheduling GPU resources](/docs/tasks/manage-gpus/scheduling-gpus/) using device plugins
|
||||
* Learn about [advertising extended resources](/docs/tasks/administer-cluster/extended-resource-node/) on a node
|
||||
* Read about using [hardware acceleration for TLS ingress](https://kubernetes.io/blog/2019/04/24/hardware-accelerated-ssl-tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) with Kubernetes
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -420,6 +420,11 @@ The **recommended minimum set** of allowed volumes for new PSPs are:
|
||||
- secret
|
||||
- projected
|
||||
|
||||
{{< warning >}}
|
||||
PodSecurityPolicy does not limit the types of `PersistentVolume` objects that may be referenced by a `PersistentVolumeClaim`.
|
||||
Only trusted users should be granted permission to create `PersistentVolume` objects.
|
||||
{{< /warning >}}
|
||||
|
||||
**FSGroup** - Controls the supplemental group applied to some volumes.
|
||||
|
||||
- *MustRunAs* - Requires at least one `range` to be specified. Uses the
|
||||
|
||||
@@ -134,6 +134,12 @@ about the [service proxy](/docs/concepts/services-networking/service/#virtual-ip
|
||||
Kubernetes supports 2 primary modes of finding a Service - environment variables
|
||||
and DNS. The former works out of the box while the latter requires the
|
||||
[CoreDNS cluster addon](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns).
|
||||
{{< note >}}
|
||||
If the service environment variables are not desired (because possible clashing with expected program ones,
|
||||
too many variables to process, only using DNS, etc) you can disable this mode by setting the `enableServiceLinks`
|
||||
flag to `false` on the [pod spec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core).
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
### Environment Variables
|
||||
|
||||
|
||||
@@ -215,7 +215,7 @@ Events:
|
||||
```
|
||||
|
||||
The Ingress controller provisions an implementation-specific load balancer
|
||||
that satisfies the Ingress, as long as the Services (`s1`, `s2`) exist.
|
||||
that satisfies the Ingress, as long as the Services (`service1`, `service2`) exist.
|
||||
When it has done so, you can see the address of the load balancer at the
|
||||
Address field.
|
||||
|
||||
@@ -230,9 +230,9 @@ you are using, you may need to create a default-http-backend
|
||||
Name-based virtual hosts support routing HTTP traffic to multiple host names at the same IP address.
|
||||
|
||||
```none
|
||||
foo.bar.com --| |-> foo.bar.com s1:80
|
||||
foo.bar.com --| |-> foo.bar.com service1:80
|
||||
| 178.91.123.132 |
|
||||
bar.foo.com --| |-> bar.foo.com s2:80
|
||||
bar.foo.com --| |-> bar.foo.com service2:80
|
||||
```
|
||||
|
||||
The following Ingress tells the backing load balancer to route requests based on
|
||||
@@ -384,7 +384,7 @@ Rules:
|
||||
Host Path Backends
|
||||
---- ---- --------
|
||||
foo.bar.com
|
||||
/foo s1:80 (10.8.0.90:80)
|
||||
/foo service1:80 (10.8.0.90:80)
|
||||
Annotations:
|
||||
nginx.ingress.kubernetes.io/rewrite-target: /
|
||||
Events:
|
||||
@@ -407,14 +407,14 @@ spec:
|
||||
http:
|
||||
paths:
|
||||
- backend:
|
||||
serviceName: s1
|
||||
serviceName: service1
|
||||
servicePort: 80
|
||||
path: /foo
|
||||
- host: bar.baz.com
|
||||
http:
|
||||
paths:
|
||||
- backend:
|
||||
serviceName: s2
|
||||
serviceName: service2
|
||||
servicePort: 80
|
||||
path: /foo
|
||||
..
|
||||
@@ -438,9 +438,9 @@ Rules:
|
||||
Host Path Backends
|
||||
---- ---- --------
|
||||
foo.bar.com
|
||||
/foo s1:80 (10.8.0.90:80)
|
||||
/foo service1:80 (10.8.0.90:80)
|
||||
bar.baz.com
|
||||
/foo s2:80 (10.8.0.91:80)
|
||||
/foo service2:80 (10.8.0.91:80)
|
||||
Annotations:
|
||||
nginx.ingress.kubernetes.io/rewrite-target: /
|
||||
Events:
|
||||
|
||||
@@ -149,7 +149,7 @@ spec:
|
||||
fsType: ext4
|
||||
```
|
||||
|
||||
#### CSI Migration
|
||||
#### CSI Migration
|
||||
|
||||
{{< feature-state for_k8s_version="v1.14" state="alpha" >}}
|
||||
|
||||
@@ -241,7 +241,7 @@ spec:
|
||||
fsType: ext4
|
||||
```
|
||||
|
||||
#### CSI Migration
|
||||
#### CSI Migration
|
||||
|
||||
{{< feature-state for_k8s_version="v1.14" state="alpha" >}}
|
||||
|
||||
@@ -1359,16 +1359,16 @@ documentation](https://kubernetes-csi.github.io/docs/)
|
||||
{{< feature-state for_k8s_version="v1.14" state="alpha" >}}
|
||||
|
||||
The CSI Migration feature, when enabled, directs operations against existing in-tree
|
||||
plugins to corresponding CSI plugins (which are expected to be installed and configured).
|
||||
The feature implements the necessary translation logic and shims to re-route the
|
||||
operations in a seamless fashion. As a result, operators do not have to make any
|
||||
configuration changes to existing Storage Classes, PVs or PVCs (referring to
|
||||
plugins to corresponding CSI plugins (which are expected to be installed and configured).
|
||||
The feature implements the necessary translation logic and shims to re-route the
|
||||
operations in a seamless fashion. As a result, operators do not have to make any
|
||||
configuration changes to existing Storage Classes, PVs or PVCs (referring to
|
||||
in-tree plugins) when transitioning to a CSI driver that supersedes an in-tree plugin.
|
||||
|
||||
In the alpha state, the operations and features that are supported include
|
||||
In the alpha state, the operations and features that are supported include
|
||||
provisioning/delete, attach/detach, mount/unmount and resizing of volumes.
|
||||
|
||||
In-tree plugins that support CSI Migration and have a corresponding CSI driver implemented
|
||||
In-tree plugins that support CSI Migration and have a corresponding CSI driver implemented
|
||||
are listed in the "Types of Volumes" section above.
|
||||
|
||||
### Flexvolume {#flexVolume}
|
||||
|
||||
@@ -169,8 +169,8 @@ The deployment notices that one of the pods is terminating, so it creates a repl
|
||||
called `pod-d`. Since `node-1` is cordoned, it lands on another node. Something has
|
||||
also created `pod-y` as a replacement for `pod-x`.
|
||||
|
||||
(Note: for a StatefulSet, `pod-a`, which would be called something like `pod-1`, would need
|
||||
to terminate completely before its replacement, which is also called `pod-1` but has a
|
||||
(Note: for a StatefulSet, `pod-a`, which would be called something like `pod-0`, would need
|
||||
to terminate completely before its replacement, which is also called `pod-0` but has a
|
||||
different UID, could be created. Otherwise, the example applies to a StatefulSet as well.)
|
||||
|
||||
Now the cluster is in this state:
|
||||
|
||||
@@ -154,7 +154,7 @@ and rollout management.
|
||||
Controllers like [StatefulSet](/docs/concepts/workloads/controllers/statefulset.md)
|
||||
can also provide support to stateful Pods.
|
||||
|
||||
The use of collective APIs as the primary user-facing primitive is relatively common among cluster scheduling systems, including [Borg](https://research.google.com/pubs/pub43438.html), [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html), [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema), and [Tupperware](http://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997).
|
||||
The use of collective APIs as the primary user-facing primitive is relatively common among cluster scheduling systems, including [Borg](https://research.google.com/pubs/pub43438.html), [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html), [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema), and [Tupperware](https://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997).
|
||||
|
||||
Pod is exposed as a primitive in order to facilitate:
|
||||
|
||||
|
||||
@@ -40,7 +40,7 @@ Not all tasks can be done in the GitHub UI, but these are discussed in the
|
||||
|
||||
The Kubernetes documentation is maintained by a
|
||||
{{< glossary_tooltip text="Special Interest Group" term_id="sig" >}} (SIG)
|
||||
called SIG Docs. We communicate using a Slack channel, a mailing list, and
|
||||
called SIG Docs. We [communicate](#participate-in-sig-docs-discussions) using a Slack channel, a mailing list, and
|
||||
weekly video meetings. New participants are welcome. For more information, see
|
||||
[Participating in SIG Docs](/docs/contribute/participating/).
|
||||
|
||||
@@ -52,7 +52,7 @@ formatting, and typographic conventions. Look over the style guide before you
|
||||
make your first contribution, and use it when you have questions.
|
||||
|
||||
Changes to the style guide are made by SIG Docs as a group. To propose a change
|
||||
or addition, [add it to the agenda](https://docs.google.com/document/d/1Ds87eRiNZeXwRBEbFr6Z7ukjbTow5RQcNZLaSvWWQsE/edit#) for an upcoming SIG Docs meeting, and attend the meeting to participate in the
|
||||
or addition, [add it to the agenda](https://docs.google.com/document/d/1zg6By77SGg90EVUrhDIhopjZlSDg2jCebU-Ks9cYx0w/edit#) for an upcoming SIG Docs meeting, and attend the meeting to participate in the
|
||||
discussion. See the [advanced contribution](/docs/contribute/advanced/) topic for more
|
||||
information.
|
||||
|
||||
@@ -247,8 +247,10 @@ pull request if it detects that you pushed a new branch to your fork.
|
||||
is the same as the commit summary, but you can change it if needed. The
|
||||
body is populated by your extended commit message (if present) and some
|
||||
template text. Read the template text and fill out the details it asks for,
|
||||
then delete the extra template text. Leave the
|
||||
**Allow edits from maintainers** checkbox selected. Click
|
||||
then delete the extra template text. If you add to the description `fixes #<000000>`
|
||||
or `closes #<000000>`, where `#<000000>` is the number of an associated issue,
|
||||
GitHub will automatically close the issue when the PR merges.
|
||||
Leave the **Allow edits from maintainers** checkbox selected. Click
|
||||
**Create pull request**.
|
||||
|
||||
Congratulations! Your pull request is available in
|
||||
|
||||
@@ -71,7 +71,7 @@ can be accomplished using an [authenticating proxy](#authenticating-proxy) or th
|
||||
### X509 Client Certs
|
||||
|
||||
Client certificate authentication is enabled by passing the `--client-ca-file=SOMEFILE`
|
||||
option to API server. The referenced file must contain one or more certificates authorities
|
||||
option to API server. The referenced file must contain one or more certificate authorities
|
||||
to use to validate client certificates presented to the API server. If a client certificate
|
||||
is presented and verified, the common name of the subject is used as the user name for the
|
||||
request. As of Kubernetes 1.4, client certificates can also indicate a user's group memberships
|
||||
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
title: Admission Controller
|
||||
id: admission-controller
|
||||
date: 2019-06-28
|
||||
full_link: /docs/reference/access-authn-authz/admission-controllers/
|
||||
short_description: >
|
||||
A piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- extension
|
||||
- security
|
||||
---
|
||||
A piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Admission controllers are configurable for the Kubernetes API server and may be “validating”, “mutating”, or
|
||||
both. Any admission controller may reject the request. Mutating controllers may modify the objects they admit;
|
||||
validating controllers may not.
|
||||
|
||||
* [Admission controllers in the Kubernetes documentation](/docs/reference/access-authn-authz/admission-controllers/)
|
||||
@@ -4,7 +4,7 @@ id: device-plugin
|
||||
date: 2019-02-02
|
||||
full_link: /docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/
|
||||
short_description: >
|
||||
Device Plugins are containers running in Kubernetes that provide access to a vendor specific resource.
|
||||
Containers running in Kubernetes that provide access to a vendor specific resource.
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
@@ -14,4 +14,4 @@ tags:
|
||||
|
||||
<!--more-->
|
||||
|
||||
[Device Plugin](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) are containers running in Kubernetes that provide access to a vendor specific resource. Device Plugins advertise these resources to kubelet and can be deployed manually or as a DeamonSet, rather than writing custom Kubernetes code.
|
||||
[Device Plugins](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) are containers running in Kubernetes that provide access to a vendor-specific resource. Device Plugins advertise these resources to {{< glossary_tooltip term_id="kubelet" >}}. They can be deployed manually or as a {{< glossary_tooltip term_id="daemonset" >}}, rather than writing custom Kubernetes code.
|
||||
|
||||
@@ -1,8 +1,7 @@
|
||||
---
|
||||
title: Mirror Pod
|
||||
id: mirror-pod
|
||||
date: 2091-02-12
|
||||
full_link:
|
||||
date: 2019-08-06
|
||||
short_description: >
|
||||
An object in the API server that tracks a static pod on a kubelet.
|
||||
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: Static Pod
|
||||
id: static-pod
|
||||
date: 2091-02-12
|
||||
date: 2019-02-12
|
||||
full_link: /docs/tasks/administer-cluster/static-pod/
|
||||
short_description: >
|
||||
A pod managed directly by kubelet daemon on a specific node
|
||||
|
||||
@@ -158,6 +158,10 @@ kubectl get services --sort-by=.metadata.name # List Services Sorted by Name
|
||||
# List pods Sorted by Restart Count
|
||||
kubectl get pods --sort-by='.status.containerStatuses[0].restartCount'
|
||||
|
||||
# List pods in test namespace sorted by capacity
|
||||
|
||||
kubectl get pods -n test --sort-by=.spec.capacity.storage
|
||||
|
||||
# Get the version label of all pods with label app=cassandra
|
||||
kubectl get pods --selector=app=cassandra -o \
|
||||
jsonpath='{.items[*].metadata.labels.version}'
|
||||
@@ -344,7 +348,7 @@ Output format | Description
|
||||
|
||||
### Kubectl output verbosity and debugging
|
||||
|
||||
Kubectl verbosity is controlled with the `-v` or `--v` flags followed by an integer representing the log level. General Kubernetes logging conventions and the associated log levels are described [here](https://github.com/kubernetes/community/blob/master/contributors/devel/logging.md).
|
||||
Kubectl verbosity is controlled with the `-v` or `--v` flags followed by an integer representing the log level. General Kubernetes logging conventions and the associated log levels are described [here](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md).
|
||||
|
||||
Verbosity | Description
|
||||
--------------| -----------
|
||||
|
||||
@@ -65,18 +65,18 @@ Given the JSON input:
|
||||
}
|
||||
```
|
||||
|
||||
Function | Description | Example | Result
|
||||
------------------|---------------------------|---------------------------------------------------------------|------------------
|
||||
text | the plain text | kind is {.kind} | kind is List
|
||||
@ | the current object | {@} | the same as input
|
||||
. or [] | child operator | {.kind} or {['kind']} | List
|
||||
.. | recursive descent | {..name} | 127.0.0.1 127.0.0.2 myself e2e
|
||||
\* | wildcard. Get all objects | {.items[*].metadata.name} | [127.0.0.1 127.0.0.2]
|
||||
[start:end :step] | subscript operator | {.users[0].name} | myself
|
||||
[,] | union operator | {.items[*]['metadata.name', 'status.capacity']} | 127.0.0.1 127.0.0.2 map[cpu:4] map[cpu:8]
|
||||
?() | filter | {.users[?(@.name=="e2e")].user.password} | secret
|
||||
range, end | iterate list | {range .items[*]}[{.metadata.name}, {.status.capacity}] {end} | [127.0.0.1, map[cpu:4]] [127.0.0.2, map[cpu:8]]
|
||||
'' | quote interpreted string | {range .items[*]}{.metadata.name}{'\t'}{end} | 127.0.0.1 127.0.0.2
|
||||
Function | Description | Example | Result
|
||||
--------------------|---------------------------|-----------------------------------------------------------------|------------------
|
||||
`text` | the plain text | `kind is {.kind}` | `kind is List`
|
||||
`@` | the current object | `{@}` | the same as input
|
||||
`.` or `[]` | child operator | `{.kind}` or `{['kind']}` | `List`
|
||||
`..` | recursive descent | `{..name}` | `127.0.0.1 127.0.0.2 myself e2e`
|
||||
`*` | wildcard. Get all objects | `{.items[*].metadata.name}` | `[127.0.0.1 127.0.0.2]`
|
||||
`[start:end :step]` | subscript operator | `{.users[0].name}` | `myself`
|
||||
`[,]` | union operator | `{.items[*]['metadata.name', 'status.capacity']}` | `127.0.0.1 127.0.0.2 map[cpu:4] map[cpu:8]`
|
||||
`?()` | filter | `{.users[?(@.name=="e2e")].user.password}` | `secret`
|
||||
`range`, `end` | iterate list | `{range .items[*]}[{.metadata.name}, {.status.capacity}] {end}` | `[127.0.0.1, map[cpu:4]] [127.0.0.2, map[cpu:8]]`
|
||||
`''` | quote interpreted string | `{range .items[*]}{.metadata.name}{'\t'}{end}` | `127.0.0.1 127.0.0.2`
|
||||
|
||||
Examples using `kubectl` and JSONPath expressions:
|
||||
|
||||
@@ -95,4 +95,4 @@ C:\> kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{'\t'}{.stat
|
||||
C:\> kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{\"\t\"}{.status.startTime}{\"\n\"}{end}"
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -14,7 +14,7 @@ weight: 90
|
||||
## kubeadm alpha certs renew {#cmd-certs-renew}
|
||||
|
||||
You can renew all Kubernetes certificates using the `all` subcommand or renew them selectively.
|
||||
For more details about certificate expiration and renewal see the [certificate management documentation](docs/tasks/administer-cluster/kubeadm/kubeadm-certs).
|
||||
For more details about certificate expiration and renewal see the [certificate management documentation](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/).
|
||||
|
||||
{{< tabs name="tab-certs-renew" >}}
|
||||
{{< tab name="renew" include="generated/kubeadm_alpha_certs_renew.md" />}}
|
||||
@@ -44,7 +44,7 @@ to enable the automatic copy of certificates when joining additional control-pla
|
||||
## kubeadm alpha certs check-expiration {#cmd-certs-check-expiration}
|
||||
|
||||
This command checks expiration for the certificates in the local PKI managed by kubeadm.
|
||||
For more details about certificate expiration and renewal see the [certificate management documentation](docs/tasks/administer-cluster/kubeadm/kubeadm-certs).
|
||||
For more details about certificate expiration and renewal see the [certificate management documentation](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/).
|
||||
|
||||
{{< tabs name="tab-certs-check-expiration" >}}
|
||||
{{< tab name="check-expiration" include="generated/kubeadm_alpha_certs_check-expiration.md" />}}
|
||||
@@ -75,7 +75,7 @@ to enable the DynamicKubeletConfiguration feature.
|
||||
|
||||
The subcommand `pivot` can be used to convert a static Pod-hosted control plane into a self-hosted one.
|
||||
|
||||
[Documentation](/docs/setup/independent/self-hosting)
|
||||
[Documentation](/docs/setup/production-environment/tools/kubeadm/self-hosting/)
|
||||
|
||||
{{< tabs name="selfhosting" >}}
|
||||
{{< tab name="selfhosting" include="generated/kubeadm_alpha_selfhosting.md" />}}
|
||||
|
||||
@@ -16,10 +16,9 @@ You can execute `kubeadm config view` to view the ConfigMap. If you initialized
|
||||
kubeadm v1.7.x or lower, you must use `kubeadm config upload` to create the ConfigMap before you
|
||||
may use `kubeadm upgrade`.
|
||||
|
||||
In Kubernetes v1.11.0, some new commands were added. You can use `kubeadm config print-default`
|
||||
to print the default configuration and `kubeadm config migrate` to convert your old configuration
|
||||
files to a newer version. `kubeadm config images list` and `kubeadm config images pull` can be used
|
||||
to list and pull the images that kubeadm requires.
|
||||
You can use `kubeadm config print` to print the default configuration and `kubeadm config migrate` to
|
||||
convert your old configuration files to a newer version. `kubeadm config images list` and
|
||||
`kubeadm config images pull` can be used to list and pull the images that kubeadm requires.
|
||||
|
||||
In Kubernetes v1.13.0 and later to list/pull kube-dns images instead of the CoreDNS image
|
||||
the `--config` method described [here](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-addon)
|
||||
|
||||
@@ -75,7 +75,7 @@ The following production environment solutions table lists the providers and the
|
||||
| [Cisco Container Platform](https://cisco.com/go/containers) | | | ✔ | | |
|
||||
| [Cloud Foundry Container Runtime (CFCR)](https://docs-cfcr.cfapps.io/) | | | | ✔ |✔ |
|
||||
| [CloudStack](https://cloudstack.apache.org/) | | | | | ✔|
|
||||
| [Canonical](https://www.ubuntu.com/kubernetes/docs/quickstart) | | ✔ | | ✔ |✔ | ✔
|
||||
| [Canonical](https://ubuntu.com/kubernetes) | ✔ | ✔ | ✔ | ✔ |✔ | ✔
|
||||
| [Containership](https://containership.io/containership-platform) | ✔ |✔ | | | |
|
||||
| [Digital Rebar](https://provision.readthedocs.io/en/tip/README.html) | | | | | | ✔
|
||||
| [DigitalOcean](https://www.digitalocean.com/products/kubernetes/) | ✔ | | | | |
|
||||
|
||||
@@ -189,7 +189,7 @@ apt-get install cri-o-1.13
|
||||
{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}}
|
||||
|
||||
# Install prerequisites
|
||||
yum-config-manager --add-repo=https://cbs.centos.org/repos/paas7-crio-311-candidate/x86_64/os/
|
||||
yum-config-manager --add-repo=https://cbs.centos.org/repos/paas7-crio-115-release/x86_64/os/
|
||||
|
||||
# Install CRI-O
|
||||
yum install --nogpgcheck cri-o
|
||||
|
||||
@@ -157,15 +157,19 @@ has finished performing the TLS Bootstrap.
|
||||
|
||||
## The kubelet drop-in file for systemd
|
||||
|
||||
The configuration file installed by the kubeadm DEB or RPM package is written to
|
||||
kubeadm ships with configuration for how systemd should run the kubelet.
|
||||
Note that the kubeadm CLI command never touches this drop-in file.
|
||||
|
||||
This configuration file installed by the `kubeadm` [DEB](https://github.com/kubernetes/kubernetes/blob/master/build/debs/10-kubeadm.conf) or [RPM package](https://github.com/kubernetes/kubernetes/blob/master/build/rpms/10-kubeadm.conf) is written to
|
||||
`/etc/systemd/system/kubelet.service.d/10-kubeadm.conf` and is used by systemd.
|
||||
It augments the basic [`kubelet.service` for RPM](https://github.com/kubernetes/kubernetes/blob/master/build/rpms/kubelet.service) (resp. [`kubelet.service` for DEB](https://github.com/kubernetes/kubernetes/blob/master/build/debs/kubelet.service))):
|
||||
|
||||
```none
|
||||
[Service]
|
||||
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf
|
||||
--kubeconfig=/etc/kubernetes/kubelet.conf"
|
||||
Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
|
||||
# This is a file that "kubeadm init" and "kubeadm join" generates at runtime, populating
|
||||
# This is a file that "kubeadm init" and "kubeadm join" generate at runtime, populating
|
||||
the KUBELET_KUBEADM_ARGS variable dynamically
|
||||
EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
|
||||
# This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably,
|
||||
|
||||
@@ -170,6 +170,7 @@ Unable to connect to the server: x509: certificate signed by unknown authority (
|
||||
|
||||
```sh
|
||||
mv $HOME/.kube $HOME/.kube.bak
|
||||
mkdir $HOME/.kube
|
||||
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
|
||||
sudo chown $(id -u):$(id -g) $HOME/.kube/config
|
||||
```
|
||||
|
||||
@@ -279,14 +279,12 @@ Configure each cluster with a different cluster name using `kube-controller-mana
|
||||
|
||||
### Stable
|
||||
|
||||
- You can now create a non-preempting Pod priority. If set on a class, the pod will continue to be prioritized above queued pods of a lesser class, but will not preempt running pods. ([#74614](https://github.com/kubernetes/kubernetes/pull/74614), [@denkensk](https://github.com/denkensk))
|
||||
|
||||
- Third party device monitoring is now enabled by default (KubeletPodResources). ([#77274](https://github.com/kubernetes/kubernetes/pull/77274), [@RenaudWasTaken](https://github.com/RenaudWasTaken))
|
||||
- The kube-apiserver’s `watch` can now be enabled for events using the `--watch-cache-sizes` flag. ([#74321](https://github.com/kubernetes/kubernetes/pull/74321), [@yastij](https://github.com/yastij))
|
||||
|
||||
### Beta
|
||||
|
||||
- Admission webhooks can now register for a single version of a resource (for example, `apps/v1 deployments`) and be called when any other version of that resource is modified (for example `extensions/v1beta1 deployments`). This allows new versions of a resource to be handled by admission webhooks without needing to update every webhook to understand the new version. See the API documentation for the `matchPolicy: Equivalent` option in MutatingWebhookConfiguration and ValidatingWebhookConfiguration types. ([#78135](https://github.com/kubernetes/kubernetes/pull/78135), [@liggitt](https://github.com/liggitt))
|
||||
- Third party device monitoring is now enabled by default (KubeletPodResources). ([#77274](https://github.com/kubernetes/kubernetes/pull/77274), [@RenaudWasTaken](https://github.com/RenaudWasTaken))
|
||||
- The CustomResourcePublishOpenAPI feature is now beta and enabled by default. CustomResourceDefinitions with [structural schemas](https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/20190425-structural-openapi.md) now publish schemas in the OpenAPI document served at `/openapi/v2`. CustomResourceDefinitions with non-structural schemas have a `NonStructuralSchema` condition added with details about what needs to be corrected in the validation schema. ([#77825](https://github.com/kubernetes/kubernetes/pull/77825), [@roycaihw](https://github.com/roycaihw))
|
||||
- Online volume expansion (ExpandInUsePersistentVolumes) is now a beta feature. As such, it is enabled by default. ([#77755](https://github.com/kubernetes/kubernetes/pull/77755), [@gnufied](https://github.com/gnufied))
|
||||
- The `SupportNodePidsLimit` feature is now beta, and enabled by default. It is no longer necessary to set the feature gate `SupportNodePidsLimit=true`. ([#76221](https://github.com/kubernetes/kubernetes/pull/76221), [@RobertKrawitz](https://github.com/RobertKrawitz))
|
||||
@@ -301,6 +299,7 @@ Configure each cluster with a different cluster name using `kube-controller-mana
|
||||
|
||||
### Alpha
|
||||
|
||||
- You can now create a non-preempting Pod priority. If set on a class, the pod will continue to be prioritized above queued pods of a lesser class, but will not preempt running pods. ([#74614](https://github.com/kubernetes/kubernetes/pull/74614), [@denkensk](https://github.com/denkensk))
|
||||
- kubelet now allows the use of XFS quotas (on XFS and suitably configured ext4fs filesystems) to monitor storage consumption for ephemeral storage. This method of monitoring consumption, which is currently available only for `emptyDir` volumes, is faster and more accurate than the old method of walking the filesystem tree. Note that it does not enforce limits, it only monitors consumption. To utilize this functionality, set the feature gate `LocalStorageCapacityIsolationFSQuotaMonitoring=true`. For ext4fs filesystems, create the filesystem with `mkfs.ext4 -O project <block_device>` and run `tune2fs -Q prjquota `block device`; XFS filesystems need no additional preparation. The filesystem must be mounted with option `project` in `/etc/fstab`. If the primary partition is the root filesystem, add `rootflags=pquota` to the GRUB config file. ([#66928](https://github.com/kubernetes/kubernetes/pull/66928), [@RobertKrawitz](https://github.com/RobertKrawitz))
|
||||
- Finalizer Protection for Service LoadBalancers (ServiceLoadBalancerFinalizer) has been added as an Alpha feature, which is disabled by default. This feature ensures the Service resource is not fully deleted until the correlating load balancer resources are deleted. ([#78262](https://github.com/kubernetes/kubernetes/pull/78262), [@MrHohn](https://github.com/MrHohn))
|
||||
- Inline CSI ephemeral volumes can now be controlled with PodSecurityPolicy when the CSIInlineVolume alpha feature is enabled. ([#76915](https://github.com/kubernetes/kubernetes/pull/76915), [@vladimirvivien](https://github.com/vladimirvivien))
|
||||
|
||||
@@ -10,8 +10,6 @@ This page shows how to specify extended resources for a Node.
|
||||
Extended resources allow cluster administrators to advertise node-level
|
||||
resources that would otherwise be unknown to Kubernetes.
|
||||
|
||||
{{< feature-state state="stable" >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -60,7 +58,7 @@ you call dongles.
|
||||
|
||||
Start a proxy, so that you can easily send requests to the Kubernetes API server:
|
||||
|
||||
```
|
||||
```shell
|
||||
kubectl proxy
|
||||
```
|
||||
|
||||
@@ -153,7 +151,7 @@ Then a Container could request any number of bytes of special storage, up to 800
|
||||
|
||||
Here is a PATCH request that removes the dongle advertisement from a Node.
|
||||
|
||||
```shell
|
||||
```
|
||||
PATCH /api/v1/nodes/<your-node-name>/status HTTP/1.1
|
||||
Accept: application/json
|
||||
Content-Type: application/json-patch+json
|
||||
@@ -169,7 +167,7 @@ Host: k8s-master:8080
|
||||
|
||||
Start a proxy, so that you can easily send requests to the Kubernetes API server:
|
||||
|
||||
```
|
||||
```shell
|
||||
kubectl proxy
|
||||
```
|
||||
|
||||
@@ -189,6 +187,8 @@ Verify that the dongle advertisement has been removed:
|
||||
kubectl describe node <your-node-name> | grep dongle
|
||||
```
|
||||
|
||||
(you should not see any output)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
@@ -28,7 +28,7 @@ and provides recommendations on overall security.
|
||||
As Kubernetes is entirely API driven, controlling and limiting who can access the cluster and what actions
|
||||
they are allowed to perform is the first line of defense.
|
||||
|
||||
### Use Transport Level Security (TLS) for all API traffic
|
||||
### Use Transport Layer Security (TLS) for all API traffic
|
||||
|
||||
Kubernetes expects that all API communication in the cluster is encrypted by default with TLS, and the
|
||||
majority of installation methods will allow the necessary certificates to be created and distributed to
|
||||
|
||||
@@ -1,143 +0,0 @@
|
||||
---
|
||||
reviewers:
|
||||
- jsafrane
|
||||
title: Static Pods
|
||||
content_template: templates/concept
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
**If you are running clustered Kubernetes and are using static pods to run a pod on every node, you should probably be using a [DaemonSet](/docs/concepts/workloads/controllers/daemonset/)!**
|
||||
|
||||
*Static pods* are managed directly by kubelet daemon on a specific node, without the API server observing it. It does not have an associated replication controller, and kubelet daemon itself watches it and restarts it when it crashes. There is no health check. Static pods are always bound to one kubelet daemon and always run on the same node with it.
|
||||
|
||||
Kubelet automatically tries to create a *mirror pod* on the Kubernetes API server for each static pod.
|
||||
This means that the pods are visible on the API server but cannot be controlled from there.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Static pod creation
|
||||
|
||||
Static pod can be created in two ways: either by using configuration file(s) or by HTTP.
|
||||
|
||||
### Configuration files
|
||||
|
||||
The configuration files are just standard pod definitions in json or yaml format in a specific directory. Use `kubelet --pod-manifest-path=<the directory>` to start kubelet daemon or add the `staticPodPath: <the directory>` field in the [KubeletConfiguration file](/docs/tasks/administer-cluster/kubelet-config-file), which periodically scans the directory and creates/deletes static pods as yaml/json files appear/disappear there.
|
||||
Note that kubelet will ignore files starting with dots when scanning the specified directory.
|
||||
|
||||
For example, this is how to start a simple web server as a static pod:
|
||||
|
||||
1. Choose a node where we want to run the static pod. In this example, it's `my-node1`.
|
||||
|
||||
```
|
||||
[joe@host ~] $ ssh my-node1
|
||||
```
|
||||
|
||||
2. Choose a directory, say `/etc/kubelet.d` and place a web server pod definition there, e.g. `/etc/kubelet.d/static-web.yaml`:
|
||||
|
||||
```shell
|
||||
[root@my-node1 ~] $ mkdir /etc/kubelet.d/
|
||||
[root@my-node1 ~] $ cat <<EOF >/etc/kubelet.d/static-web.yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: static-web
|
||||
labels:
|
||||
role: myrole
|
||||
spec:
|
||||
containers:
|
||||
- name: web
|
||||
image: nginx
|
||||
ports:
|
||||
- name: web
|
||||
containerPort: 80
|
||||
protocol: TCP
|
||||
EOF
|
||||
```
|
||||
|
||||
3. Configure your kubelet daemon on the node to use this directory by running it with `--pod-manifest-path=/etc/kubelet.d/` argument or add the `staticPodPath: <the directory>` field in the [KubeletConfiguration file](/docs/tasks/administer-cluster/kubelet-config-file).
|
||||
On Fedora edit `/etc/kubernetes/kubelet` to include this line:
|
||||
|
||||
```
|
||||
KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --pod-manifest-path=/etc/kubelet.d/"
|
||||
```
|
||||
|
||||
Instructions for other distributions or Kubernetes installations may vary.
|
||||
|
||||
4. Restart kubelet. On Fedora, this is:
|
||||
|
||||
```
|
||||
[root@my-node1 ~] $ systemctl restart kubelet
|
||||
```
|
||||
|
||||
### Pods created via HTTP
|
||||
|
||||
Kubelet periodically downloads a file specified by `--manifest-url=<URL>` argument and interprets it as a json/yaml file with a pod definition. It works the same as `--pod-manifest-path=<directory>`, i.e. it's reloaded every now and then and changes are applied to running static pods (see below).
|
||||
|
||||
## Behavior of static pods
|
||||
|
||||
When kubelet starts, it automatically starts all pods defined in directory specified in `--pod-manifest-path=` or `--manifest-url=` arguments or add the `staticPodPath: <the directory>` field in the [KubeletConfiguration file](/docs/tasks/administer-cluster/kubelet-config-file), i.e. our static-web. (It may take some time to pull nginx image, be patient…):
|
||||
|
||||
```shell
|
||||
[joe@my-node1 ~] $ docker ps
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||||
f6d05272b57e nginx:latest "nginx" 8 minutes ago Up 8 minutes k8s_web.6f802af4_static-web-fk-node1_default_67e24ed9466ba55986d120c867395f3c_378e5f3c
|
||||
```
|
||||
|
||||
If we look at our Kubernetes API server (running on host `my-master`), we see that a new mirror-pod was created there too:
|
||||
|
||||
```shell
|
||||
[joe@host ~] $ ssh my-master
|
||||
[joe@my-master ~] $ kubectl get pods
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
static-web-my-node1 1/1 Running 0 2m
|
||||
```
|
||||
|
||||
Labels from the static pod are propagated into the mirror-pod and can be used as usual for filtering.
|
||||
|
||||
Notice we cannot delete the pod with the API server (e.g. via [`kubectl`](/docs/user-guide/kubectl/) command), kubelet simply won't remove it.
|
||||
|
||||
{{< note >}}
|
||||
Make sure the kubelet has permission to create the mirror pod in the API server. If not, the creation request is rejected by the API server. See
|
||||
[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/).
|
||||
{{< /note >}}
|
||||
|
||||
```shell
|
||||
[joe@my-master ~] $ kubectl delete pod static-web-my-node1
|
||||
pod "static-web-my-node1" deleted
|
||||
[joe@my-master ~] $ kubectl get pods
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
static-web-my-node1 1/1 Running 0 12s
|
||||
```
|
||||
|
||||
Back to our `my-node1` host, we can try to stop the container manually and see, that kubelet automatically restarts it in a while:
|
||||
|
||||
```none
|
||||
[joe@host ~] $ ssh my-node1
|
||||
[joe@my-node1 ~] $ docker stop f6d05272b57e
|
||||
[joe@my-node1 ~] $ sleep 20
|
||||
[joe@my-node1 ~] $ docker ps
|
||||
CONTAINER ID IMAGE COMMAND CREATED ...
|
||||
5b920cbaf8b1 nginx:latest "nginx -g 'daemon of 2 seconds ago ...
|
||||
```
|
||||
|
||||
## Dynamic addition and removal of static pods
|
||||
|
||||
Running kubelet periodically scans the configured directory (`/etc/kubelet.d` in our example) for changes and adds/removes pods as files appear/disappear in this directory.
|
||||
|
||||
```shell
|
||||
[joe@my-node1 ~] $ mv /etc/kubelet.d/static-web.yaml /tmp
|
||||
[joe@my-node1 ~] $ sleep 20
|
||||
[joe@my-node1 ~] $ docker ps
|
||||
// no nginx container is running
|
||||
[joe@my-node1 ~] $ mv /tmp/static-web.yaml /etc/kubelet.d/
|
||||
[joe@my-node1 ~] $ sleep 20
|
||||
[joe@my-node1 ~] $ docker ps
|
||||
CONTAINER ID IMAGE COMMAND CREATED ...
|
||||
e7a62e3427f1 nginx:latest "nginx -g 'daemon of 27 seconds ago
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -6,10 +6,10 @@ weight: 40
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
This page shows how to assign extended resources to a Container.
|
||||
|
||||
{{< feature-state state="stable" >}}
|
||||
|
||||
This page shows how to assign extended resources to a Container.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -141,9 +141,3 @@ kubectl delete pod extended-resource-demo-2
|
||||
* [Advertise Extended Resources for a Node](/docs/tasks/administer-cluster/extended-resource-node/)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,244 @@
|
||||
---
|
||||
reviewers:
|
||||
- jsafrane
|
||||
title: Create static Pods
|
||||
weight: 170
|
||||
content_template: templates/task
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
|
||||
*Static Pods* are managed directly by the kubelet daemon on a specific node,
|
||||
without the {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}}
|
||||
observing them.
|
||||
Unlike Pods that are managed by the control plane (eg, a
|
||||
{{< glossary_tooltip text="Deployment" term_id="deployment" >}};
|
||||
instead, the kubelet watches each static Pod (and restarts it if it crashes).
|
||||
There are no health checks for the containers in a static Pod.
|
||||
|
||||
Static Pods are always bound to one {{< glossary_tooltip term_id="kubelet" >}} on a specific node.
|
||||
|
||||
Kubelet automatically tries to create a {{< glossary_tooltip text="mirror Pod" term_id="mirror-pod" >}}
|
||||
on the Kubernetes API server for each static Pod.
|
||||
This means that the Pods running on a node are visible on the API server,
|
||||
but cannot be controlled from there.
|
||||
|
||||
{{< note >}}
|
||||
If you are running clustered Kubernetes and are using static
|
||||
Pods to run a Pod on every node, you should probably be using a
|
||||
{{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}
|
||||
instead.
|
||||
{{< /note >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
This page assumes you're using {{< glossary_tooltip term_id="docker" >}} to run Pods,
|
||||
and that your nodes are running the Fedora operating system.
|
||||
Instructions for other distributions or Kubernetes installations may vary.
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## Create a static pod {#static-pod-creation}
|
||||
|
||||
You can configure a static Pod two different ways: either by using configuration file(s) or by HTTP.
|
||||
|
||||
### Filesystem-hosted static Pod manifest {#configuration-files}
|
||||
|
||||
The configuration files are just standard Pod definitions in JSON or YAML format in a specific directory. Use `kubelet --pod-manifest-path=<the directory>` to start the kubelet or add the `staticPodPath: <the directory>` field in the [KubeletConfiguration file](/docs/tasks/administer-cluster/kubelet-config-file), which periodically scans the directory and creates/deletes static Pods as YAML/JSON files appear/disappear there.
|
||||
Note that the kubelet will ignore files starting with dots when scanning the specified directory.
|
||||
|
||||
For example, this is how to start a simple web server as a static Pod:
|
||||
|
||||
1. Choose a node where you want to run the static Pod. In this example, it's `my-node1`.
|
||||
|
||||
```shell
|
||||
ssh my-node1
|
||||
```
|
||||
|
||||
2. Choose a directory, say `/etc/kubelet.d` and place a web server Pod definition there, e.g. `/etc/kubelet.d/static-web.yaml`:
|
||||
|
||||
```shell
|
||||
# Run this command on the node where kubelet is running
|
||||
mkdir /etc/kubelet.d/
|
||||
cat <<EOF >/etc/kubelet.d/static-web.yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: static-web
|
||||
labels:
|
||||
role: myrole
|
||||
spec:
|
||||
containers:
|
||||
- name: web
|
||||
image: nginx
|
||||
ports:
|
||||
- name: web
|
||||
containerPort: 80
|
||||
protocol: TCP
|
||||
EOF
|
||||
```
|
||||
|
||||
3. Configure your kubelet on the node to use this directory by running it with `--pod-manifest-path=/etc/kubelet.d/` argument or add the `staticPodPath: <the directory>` field in the [KubeletConfiguration file](/docs/tasks/administer-cluster/kubelet-config-file).
|
||||
On Fedora edit `/etc/kubernetes/kubelet` to include this line:
|
||||
|
||||
```
|
||||
KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --pod-manifest-path=/etc/kubelet.d/"
|
||||
```
|
||||
|
||||
4. Restart the kubelet. On Fedora, you would run:
|
||||
|
||||
```shell
|
||||
# Run this command on the node where the kubelet is running
|
||||
systemctl restart kubelet
|
||||
```
|
||||
|
||||
### Web-hosted static pod manifest {#pods-created-via-http}
|
||||
|
||||
Kubelet periodically downloads a file specified by `--manifest-url=<URL>` argument
|
||||
and interprets it as a JSON/YAML file that contains Pod definitions.
|
||||
Similar to how [filesystem-hosted manifests](#configuration-files) work, the kubelet
|
||||
refetches the manifest on a schedule. If there are changes to the list of static
|
||||
Pods, the kubelet applies them.
|
||||
|
||||
If you want to use this approach, create a YAML file:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: static-web
|
||||
labels:
|
||||
role: myrole
|
||||
spec:
|
||||
containers:
|
||||
- name: web
|
||||
image: nginx
|
||||
ports:
|
||||
- name: web
|
||||
containerPort: 80
|
||||
protocol: TCP
|
||||
```
|
||||
|
||||
and store it on a web server so that you can pass the URL of that file to the kubelet.
|
||||
|
||||
Configure the kubelet on your selected node to use this web manifest by running it with `--manifest-url=<manifest-url>`
|
||||
|
||||
On Fedora, edit `/etc/kubernetes/kubelet` to include this line:
|
||||
|
||||
```
|
||||
KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --manifest-url=<manifest-url>`
|
||||
```
|
||||
|
||||
Now, restart the kubelet. On Fedora, you would run:
|
||||
|
||||
```shell
|
||||
# Run this command on the node where the kubelet is running
|
||||
systemctl restart kubelet
|
||||
```
|
||||
|
||||
|
||||
|
||||
## Observe static pod behavior {#behavior-of-static-pods}
|
||||
|
||||
When the kubelet starts, it automatically starts all defined static Pods. As you have
|
||||
defined a static Pod and restarted the kubelet, the new static Pod should
|
||||
already be running.
|
||||
|
||||
You can view running containers (including static Pods) by running (on the node):
|
||||
```shell
|
||||
# Run this command on the node where kubelet is running
|
||||
docker ps
|
||||
```
|
||||
|
||||
The output might be something like:
|
||||
|
||||
```
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||||
f6d05272b57e nginx:latest "nginx" 8 minutes ago Up 8 minutes k8s_web.6f802af4_static-web-fk-node1_default_67e24ed9466ba55986d120c867395f3c_378e5f3c
|
||||
```
|
||||
|
||||
You can see the mirror Pod on the API server:
|
||||
|
||||
```shell
|
||||
kubectl get pods
|
||||
```
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
static-web-my-node1 1/1 Running 0 2m
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
Make sure the kubelet has permission to create the mirror Pod in the API server. If not, the creation request is rejected by the API server. See
|
||||
[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/).
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
{{< glossary_tooltip term_id="label" text="Labels" >}} from the static Pod are
|
||||
propagated into the mirror Pod. You can use those labels as normal via
|
||||
{{< glossary_tooltip term_id="selector" text="selectors" >}}, etc.
|
||||
|
||||
If you try to use `kubectl` to delete the mirror Pod from the API server,
|
||||
the kubelet _doesn't_ remove the static Pod:
|
||||
|
||||
```shell
|
||||
kubectl delete pod static-web-my-node1
|
||||
```
|
||||
```
|
||||
pod "static-web-my-node1" deleted
|
||||
```
|
||||
You can see that the Pod is still running:
|
||||
```shell
|
||||
kubectl get pods
|
||||
```
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
static-web-my-node1 1/1 Running 0 12s
|
||||
```
|
||||
|
||||
Back on your node where the kubelet is running, you can try to stop the Docker
|
||||
container manually.
|
||||
You'll see that, after a time, the kubelet will notice and will restart the Pod
|
||||
automatically:
|
||||
|
||||
```shell
|
||||
# Run these commands on the node where the kubelet is running
|
||||
docker stop f6d05272b57e # replace with the ID of your container
|
||||
sleep 20
|
||||
docker ps
|
||||
```
|
||||
```
|
||||
CONTAINER ID IMAGE COMMAND CREATED ...
|
||||
5b920cbaf8b1 nginx:latest "nginx -g 'daemon of 2 seconds ago ...
|
||||
```
|
||||
|
||||
## Dynamic addition and removal of static pods
|
||||
|
||||
The running kubelet periodically scans the configured directory (`/etc/kubelet.d` in our example) for changes and adds/removes Pods as files appear/disappear in this directory.
|
||||
|
||||
```shell
|
||||
# This assumes you are using filesystem-hosted static Pod configuration
|
||||
# Run these commands on the node where the kubelet is running
|
||||
#
|
||||
mv /etc/kubelet.d/static-web.yaml /tmp
|
||||
sleep 20
|
||||
docker ps
|
||||
# You see that no nginx container is running
|
||||
mv /tmp/static-web.yaml /etc/kubelet.d/
|
||||
sleep 20
|
||||
docker ps
|
||||
```
|
||||
```
|
||||
CONTAINER ID IMAGE COMMAND CREATED ...
|
||||
e7a62e3427f1 nginx:latest "nginx -g 'daemon of 27 seconds ago
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -3,7 +3,7 @@ reviewers:
|
||||
- cdrage
|
||||
title: Translate a Docker Compose File to Kubernetes Resources
|
||||
content_template: templates/task
|
||||
weight: 170
|
||||
weight: 200
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
@@ -295,7 +295,7 @@ deleted by the Kubelet.
|
||||
"command": [
|
||||
"top"
|
||||
],
|
||||
"log_path":"busybox/0.log",
|
||||
"log_path":"busybox.log",
|
||||
"linux": {
|
||||
}
|
||||
}
|
||||
|
||||
@@ -7,10 +7,10 @@ title: Schedule GPUs
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
Kubernetes includes **experimental** support for managing AMD and NVIDIA GPUs spread
|
||||
across nodes. The support for NVIDIA GPUs was added in v1.6 and has gone through
|
||||
multiple backwards incompatible iterations. The support for AMD GPUs was added in
|
||||
v1.9 via [device plugin](#deploying-amd-gpu-device-plugin).
|
||||
{{< feature-state state="beta" for_k8s_version="1.10" >}}
|
||||
|
||||
Kubernetes includes **experimental** support for managing AMD and NVIDIA GPUs
|
||||
(graphical processing units) across several nodes.
|
||||
|
||||
This page describes how users can consume GPUs across different Kubernetes versions
|
||||
and the current limitations.
|
||||
@@ -20,22 +20,20 @@ and the current limitations.
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## v1.8 onwards
|
||||
## Using device plugins
|
||||
|
||||
**From 1.8 onwards, the recommended way to consume GPUs is to use [device
|
||||
plugins](/docs/concepts/cluster-administration/device-plugins).**
|
||||
Kubernetes implements {{< glossary_tooltip text="Device Plugins" term_id="device-plugin" >}}
|
||||
to let Pods access specialized hardware features such as GPUs.
|
||||
|
||||
To enable GPU support through device plugins before 1.10, the `DevicePlugins`
|
||||
feature gate has to be explicitly set to true across the system:
|
||||
`--feature-gates="DevicePlugins=true"`. This is no longer required starting
|
||||
from 1.10.
|
||||
As an administrator, you have to install GPU drivers from the corresponding
|
||||
hardware vendor on the nodes and run the corresponding device plugin from the
|
||||
GPU vendor:
|
||||
|
||||
Then you have to install GPU drivers from the corresponding vendor on the nodes
|
||||
and run the corresponding device plugin from the GPU vendor
|
||||
([AMD](#deploying-amd-gpu-device-plugin), [NVIDIA](#deploying-nvidia-gpu-device-plugin)).
|
||||
* [AMD](#deploying-amd-gpu-device-plugin)
|
||||
* [NVIDIA](#deploying-nvidia-gpu-device-plugin)
|
||||
|
||||
When the above conditions are true, Kubernetes will expose `nvidia.com/gpu` or
|
||||
`amd.com/gpu` as a schedulable resource.
|
||||
When the above conditions are true, Kubernetes will expose `amd.com/gpu` or
|
||||
`nvidia.com/gpu` as a schedulable resource.
|
||||
|
||||
You can consume these GPUs from your containers by requesting
|
||||
`<vendor>.com/gpu` just like you request `cpu` or `memory`.
|
||||
@@ -48,7 +46,7 @@ when using GPUs:
|
||||
* You can specify GPU in both `limits` and `requests` but these two values
|
||||
must be equal.
|
||||
* You cannot specify GPU `requests` without specifying `limits`.
|
||||
- Containers (and pods) do not share GPUs. There's no overcommitting of GPUs.
|
||||
- Containers (and Pods) do not share GPUs. There's no overcommitting of GPUs.
|
||||
- Each container can request one or more GPUs. It is not possible to request a
|
||||
fraction of a GPU.
|
||||
|
||||
@@ -79,14 +77,12 @@ has the following requirements:
|
||||
|
||||
To deploy the AMD device plugin once your cluster is running and the above
|
||||
requirements are satisfied:
|
||||
```shell
|
||||
kubectl create -f https://raw.githubusercontent.com/RadeonOpenCompute/k8s-device-plugin/v1.10/k8s-ds-amdgpu-dp.yaml
|
||||
```
|
||||
# For Kubernetes v1.9
|
||||
kubectl create -f https://raw.githubusercontent.com/RadeonOpenCompute/k8s-device-plugin/r1.9/k8s-ds-amdgpu-dp.yaml
|
||||
|
||||
# For Kubernetes v1.10
|
||||
kubectl create -f https://raw.githubusercontent.com/RadeonOpenCompute/k8s-device-plugin/r1.10/k8s-ds-amdgpu-dp.yaml
|
||||
```
|
||||
Report issues with this device plugin to [RadeonOpenCompute/k8s-device-plugin](https://github.com/RadeonOpenCompute/k8s-device-plugin).
|
||||
You can report issues with this third-party device plugin by logging an issue in
|
||||
[RadeonOpenCompute/k8s-device-plugin](https://github.com/RadeonOpenCompute/k8s-device-plugin).
|
||||
|
||||
### Deploying NVIDIA GPU device plugin
|
||||
|
||||
@@ -99,22 +95,20 @@ has the following requirements:
|
||||
|
||||
- Kubernetes nodes have to be pre-installed with NVIDIA drivers.
|
||||
- Kubernetes nodes have to be pre-installed with [nvidia-docker 2.0](https://github.com/NVIDIA/nvidia-docker)
|
||||
- nvidia-container-runtime must be configured as the [default runtime](https://github.com/NVIDIA/k8s-device-plugin#preparing-your-gpu-nodes)
|
||||
for docker instead of runc.
|
||||
- NVIDIA drivers ~= 361.93
|
||||
- Kubelet must use Docker as its container runtime
|
||||
- `nvidia-container-runtime` must be configured as the [default runtime](https://github.com/NVIDIA/k8s-device-plugin#preparing-your-gpu-nodes)
|
||||
for Docker, instead of runc.
|
||||
- The version of the NVIDIA drivers must match the constraint ~= 361.93
|
||||
|
||||
To deploy the NVIDIA device plugin once your cluster is running and the above
|
||||
requirements are satisfied:
|
||||
|
||||
```
|
||||
# For Kubernetes v1.8
|
||||
kubectl create -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v1.8/nvidia-device-plugin.yml
|
||||
|
||||
# For Kubernetes v1.9
|
||||
kubectl create -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v1.9/nvidia-device-plugin.yml
|
||||
```shell
|
||||
kubectl create -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/1.0.0-beta/nvidia-device-plugin.yml
|
||||
```
|
||||
|
||||
Report issues with this device plugin to [NVIDIA/k8s-device-plugin](https://github.com/NVIDIA/k8s-device-plugin).
|
||||
You can report issues with this third-party device plugin by logging an issue in
|
||||
[NVIDIA/k8s-device-plugin](https://github.com/NVIDIA/k8s-device-plugin).
|
||||
|
||||
#### NVIDIA GPU device plugin used by GCE
|
||||
|
||||
@@ -124,9 +118,9 @@ that is compatible with the Kubernetes Container Runtime Interface (CRI). It's t
|
||||
on [Container-Optimized OS](https://cloud.google.com/container-optimized-os/)
|
||||
and has experimental code for Ubuntu from 1.9 onwards.
|
||||
|
||||
On your 1.12 cluster, you can use the following commands to install the NVIDIA drivers and device plugin:
|
||||
You can use the following commands to install the NVIDIA drivers and device plugin:
|
||||
|
||||
```
|
||||
```shell
|
||||
# Install NVIDIA drivers on Container-Optimized OS:
|
||||
kubectl create -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/stable/daemonset.yaml
|
||||
|
||||
@@ -134,13 +128,13 @@ kubectl create -f https://raw.githubusercontent.com/GoogleCloudPlatform/containe
|
||||
kubectl create -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/stable/nvidia-driver-installer/ubuntu/daemonset.yaml
|
||||
|
||||
# Install the device plugin:
|
||||
kubectl create -f https://raw.githubusercontent.com/kubernetes/kubernetes/release-1.12/cluster/addons/device-plugins/nvidia-gpu/daemonset.yaml
|
||||
kubectl create -f https://raw.githubusercontent.com/kubernetes/kubernetes/release-1.14/cluster/addons/device-plugins/nvidia-gpu/daemonset.yaml
|
||||
```
|
||||
|
||||
Report issues with this device plugin and installation method to [GoogleCloudPlatform/container-engine-accelerators](https://github.com/GoogleCloudPlatform/container-engine-accelerators).
|
||||
You can report issues with using or deploying this third-party device plugin by logging an issue in
|
||||
[GoogleCloudPlatform/container-engine-accelerators](https://github.com/GoogleCloudPlatform/container-engine-accelerators).
|
||||
|
||||
Instructions for using NVIDIA GPUs on GKE are
|
||||
[here](https://cloud.google.com/kubernetes-engine/docs/how-to/gpus)
|
||||
Google publishes its own [instructions](https://cloud.google.com/kubernetes-engine/docs/how-to/gpus) for using NVIDIA GPUs on GKE .
|
||||
|
||||
## Clusters containing different types of GPUs
|
||||
|
||||
@@ -156,7 +150,14 @@ kubectl label nodes <node-with-k80> accelerator=nvidia-tesla-k80
|
||||
kubectl label nodes <node-with-p100> accelerator=nvidia-tesla-p100
|
||||
```
|
||||
|
||||
For AMD GPUs, you can deploy [Node Labeller](https://github.com/RadeonOpenCompute/k8s-device-plugin/tree/master/cmd/k8s-node-labeller), which automatically labels your nodes with GPU properties. Currently supported properties:
|
||||
## Automatic node labelling {#node-labeller}
|
||||
|
||||
If you're using AMD GPU devices, you can deploy
|
||||
[Node Labeller](https://github.com/RadeonOpenCompute/k8s-device-plugin/tree/master/cmd/k8s-node-labeller).
|
||||
Node Labeller is a {{< glossary_tooltip text="controller" term_id="controller" >}} that automatically
|
||||
labels your nodes with GPU device properties.
|
||||
|
||||
At the moment, that controller can add labels for:
|
||||
|
||||
* Device ID (-device-id)
|
||||
* VRAM Size (-vram)
|
||||
@@ -172,13 +173,11 @@ For AMD GPUs, you can deploy [Node Labeller](https://github.com/RadeonOpenComput
|
||||
* AI - Arctic Islands
|
||||
* RV - Raven
|
||||
|
||||
Example result:
|
||||
|
||||
```console
|
||||
```shell
|
||||
kubectl describe node cluster-node-23
|
||||
```
|
||||
The output is similar to:
|
||||
|
||||
```
|
||||
Name: cluster-node-23
|
||||
Roles: <none>
|
||||
Labels: beta.amd.com/gpu.cu-count.64=1
|
||||
@@ -191,9 +190,10 @@ The output is similar to:
|
||||
kubernetes.io/hostname=cluster-node-23
|
||||
Annotations: kubeadm.alpha.kubernetes.io/cri-socket: /var/run/dockershim.sock
|
||||
node.alpha.kubernetes.io/ttl: 0
|
||||
......
|
||||
…
|
||||
```
|
||||
|
||||
Specify the GPU type in the pod spec:
|
||||
With the Node Labeller in use, you can specify the GPU type in the Pod spec:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
@@ -213,5 +213,7 @@ spec:
|
||||
accelerator: nvidia-tesla-p100 # or nvidia-tesla-k80 etc.
|
||||
```
|
||||
|
||||
This will ensure that the pod will be scheduled to a node that has the GPU type
|
||||
This will ensure that the Pod will be scheduled to a node that has the GPU type
|
||||
you specified.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -65,7 +65,7 @@ It defines an index.php page which performs some CPU intensive computations:
|
||||
First, we will start a deployment running the image and expose it as a service:
|
||||
|
||||
```shell
|
||||
kubectl run php-apache --image=k8s.gcr.io/hpa-example --requests=cpu=200m --expose --port=80
|
||||
kubectl run php-apache --image=k8s.gcr.io/hpa-example --requests=cpu=200m --limits=cpu=500m --expose --port=80
|
||||
```
|
||||
```
|
||||
service/php-apache created
|
||||
|
||||
@@ -69,9 +69,14 @@ spec:
|
||||
|
||||
Patch your Deployment:
|
||||
|
||||
```shell
|
||||
{{< tabs name="kubectl_patch_example" >}}
|
||||
{{{< tab name="Bash" codelang="bash" >}}
|
||||
kubectl patch deployment patch-demo --patch "$(cat patch-file-containers.yaml)"
|
||||
```
|
||||
{{< /tab >}}
|
||||
{{< tab name="PowerShell" codelang="posh" >}}
|
||||
kubectl patch deployment patch-demo --patch $(cat patch-file-containers.yaml)
|
||||
{{< /tab >}}}
|
||||
{{< /tabs >}}
|
||||
|
||||
View the patched Deployment:
|
||||
|
||||
|
||||
@@ -18,17 +18,19 @@ This page shows you how to install [Minikube](/docs/tutorials/hello-minikube), a
|
||||
{{< tabs name="minikube_before_you_begin" >}}
|
||||
{{% tab name="Linux" %}}
|
||||
To check if virtualization is supported on Linux, run the following command and verify that the output is non-empty:
|
||||
```shell
|
||||
egrep --color 'vmx|svm' /proc/cpuinfo
|
||||
```
|
||||
grep -E --color 'vmx|svm' /proc/cpuinfo
|
||||
```
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="macOS" %}}
|
||||
To check if virtualization is supported on macOS, run the following command on your terminal.
|
||||
```
|
||||
sysctl -a | grep machdep.cpu.features
|
||||
sysctl -a | grep -E --color 'machdep.cpu.features|VMX'
|
||||
```
|
||||
If you see `VMX` in the output, the VT-x feature is supported on your OS.
|
||||
If you see `VMX` in the output (should be colored), the VT-x feature is enabled in your machine.
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="Windows" %}}
|
||||
To check if virtualization is supported on Windows 8 and above, run the following command on your Windows terminal or command prompt.
|
||||
```
|
||||
@@ -73,7 +75,7 @@ If you do not already have a hypervisor installed, install one of these now:
|
||||
• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
|
||||
|
||||
{{< note >}}
|
||||
Minikube also supports a `--vm-driver=none` option that runs the Kubernetes components on the host and not in a VM. Using this driver requires [Docker](https://www.docker.com/products/docker-desktop) and a Linux environment but not a hypervisor.
|
||||
Minikube also supports a `--vm-driver=none` option that runs the Kubernetes components on the host and not in a VM. Using this driver requires [Docker](https://www.docker.com/products/docker-desktop) and a Linux environment but not a hypervisor. It is recommended to use the apt installation of docker from ([Docker](https://www.docker.com/products/docker-desktop), when using the none driver. The snap installation of docker does not work with minikube.
|
||||
{{< /note >}}
|
||||
|
||||
### Install Minikube using a package
|
||||
@@ -158,7 +160,7 @@ Hyper-V can run on three versions of Windows 10: Windows 10 Enterprise, Windows
|
||||
The easiest way to install Minikube on Windows is using [Chocolatey](https://chocolatey.org/) (run as an administrator):
|
||||
|
||||
```shell
|
||||
choco install minikube kubernetes-cli
|
||||
choco install minikube
|
||||
```
|
||||
|
||||
After Minikube has finished installing, close the current CLI session and restart. Minikube should have been added to your path automatically.
|
||||
|
||||
@@ -99,6 +99,11 @@ kubectl exec -it redis redis-cli
|
||||
2) "allkeys-lru"
|
||||
```
|
||||
|
||||
Delete the created pod:
|
||||
```shell
|
||||
kubectl delete pod redis
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
@@ -92,7 +92,7 @@ weight: 10
|
||||
<div class="col-md-8">
|
||||
<p>
|
||||
For your first Deployment, you'll use a Node.js application packaged in a Docker container. (If you didn't already try creating a
|
||||
Node.js application and deploying a Node.js application and deploying it using a container, you can do that first by following the
|
||||
Node.js application and deploying it using a container, you can do that first by following the
|
||||
instructions from the <a href="/docs/tutorials/hello-minikube/">Hello Minikube tutorial</a>).
|
||||
<p>
|
||||
|
||||
|
||||
Reference in New Issue
Block a user