Merge remote-tracking branch 'upstream/main' into dev-1.23
This commit is contained in:
Jesse Butler
@@ -43,11 +43,11 @@ The controllers inside the cloud controller manager include:
|
||||
|
||||
### Node controller
|
||||
|
||||
The node controller is responsible for creating {{< glossary_tooltip text="Node" term_id="node" >}} objects
|
||||
The node controller is responsible for updating {{< glossary_tooltip text="Node" term_id="node" >}} objects
|
||||
when new servers are created in your cloud infrastructure. The node controller obtains information about the
|
||||
hosts running inside your tenancy with the cloud provider. The node controller performs the following functions:
|
||||
|
||||
1. Initialize a Node object for each server that the controller discovers through the cloud provider API.
|
||||
1. Update a Node object with the corresponding server's unique identifier obtained from the cloud provider API.
|
||||
2. Annotating and labelling the Node object with cloud-specific information, such as the region the node
|
||||
is deployed into and the resources (CPU, memory, etc) that it has available.
|
||||
3. Obtain the node's hostname and network addresses.
|
||||
|
||||
@@ -72,7 +72,8 @@ The name of a Node object must be a valid
|
||||
The [name](/docs/concepts/overview/working-with-objects/names#names) identifies a Node. Two Nodes
|
||||
cannot have the same name at the same time. Kubernetes also assumes that a resource with the same
|
||||
name is the same object. In case of a Node, it is implicitly assumed that an instance using the
|
||||
same name will have the same state (e.g. network settings, root disk contents). This may lead to
|
||||
same name will have the same state (e.g. network settings, root disk contents)
|
||||
and attributes like node labels. This may lead to
|
||||
inconsistencies if an instance was modified without changing its name. If the Node needs to be
|
||||
replaced or updated significantly, the existing Node object needs to be removed from API server
|
||||
first and re-added after the update.
|
||||
@@ -98,6 +99,21 @@ When the [Node authorization mode](/docs/reference/access-authn-authz/node/) and
|
||||
[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) are enabled,
|
||||
kubelets are only authorized to create/modify their own Node resource.
|
||||
|
||||
{{< note >}}
|
||||
As mentioned in the [Node name uniqueness](#node-name-uniqueness) section,
|
||||
when Node configuration needs to be updated, it is a good practice to re-register
|
||||
the node with the API server. For example, if the kubelet being restarted with
|
||||
the new set of `--node-labels`, but the same Node name is used, the change will
|
||||
not take an effect, as labels are being set on the Node registration.
|
||||
|
||||
Pods already scheduled on the Node may misbehave or cause issues if the Node
|
||||
configuration will be changed on kubelet restart. For example, already running
|
||||
Pod may be tainted against the new labels assigned to the Node, while other
|
||||
Pods, that are incompatible with that Pod will be scheduled based on this new
|
||||
label. Node re-registration ensures all Pods will be drained and properly
|
||||
re-scheduled.
|
||||
{{< /note >}}
|
||||
|
||||
### Manual Node administration
|
||||
|
||||
You can create and modify Node objects using
|
||||
|
||||
@@ -25,7 +25,7 @@ This page lists some of the available add-ons and links to their respective inst
|
||||
* [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), based on [Tungsten Fabric](https://tungsten.io), is an open source, multi-cloud network virtualization and policy management platform. Contrail and Tungsten Fabric are integrated with orchestration systems such as Kubernetes, OpenShift, OpenStack and Mesos, and provide isolation modes for virtual machines, containers/pods and bare metal workloads.
|
||||
* [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually) is an overlay network provider that can be used with Kubernetes.
|
||||
* [Knitter](https://github.com/ZTE/Knitter/) is a plugin to support multiple network interfaces in a Kubernetes pod.
|
||||
* [Multus](https://github.com/Intel-Corp/multus-cni) is a Multi plugin for multiple network support in Kubernetes to support all CNI plugins (e.g. Calico, Cilium, Contiv, Flannel), in addition to SRIOV, DPDK, OVS-DPDK and VPP based workloads in Kubernetes.
|
||||
* Multus is a Multi plugin for multiple network support in Kubernetes to support all CNI plugins (e.g. Calico, Cilium, Contiv, Flannel), in addition to SRIOV, DPDK, OVS-DPDK and VPP based workloads in Kubernetes.
|
||||
* [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/) is a networking provider for Kubernetes based on [OVN (Open Virtual Network)](https://github.com/ovn-org/ovn/), a virtual networking implementation that came out of the Open vSwitch (OVS) project. OVN-Kubernetes provides an overlay based networking implementation for Kubernetes, including an OVS based implementation of load balancing and network policy.
|
||||
* [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin) is OVN based CNI controller plugin to provide cloud native based Service function chaining(SFC), Multiple OVN overlay networking, dynamic subnet creation, dynamic creation of virtual networks, VLAN Provider network, Direct provider network and pluggable with other Multi-network plugins, ideal for edge based cloud native workloads in Multi-cluster networking
|
||||
* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) provides integration between VMware NSX-T and container orchestrators such as Kubernetes, as well as integration between NSX-T and container-based CaaS/PaaS platforms such as Pivotal Container Service (PKS) and OpenShift.
|
||||
|
||||
@@ -246,7 +246,7 @@ Lars Kellogg-Stedman.
|
||||
|
||||
### Multus (a Multi Network plugin)
|
||||
|
||||
[Multus](https://github.com/Intel-Corp/multus-cni) is a Multi CNI plugin to support the Multi Networking feature in Kubernetes using CRD based network objects in Kubernetes.
|
||||
Multus is a Multi CNI plugin to support the Multi Networking feature in Kubernetes using CRD based network objects in Kubernetes.
|
||||
|
||||
Multus supports all [reference plugins](https://github.com/containernetworking/plugins) (eg. [Flannel](https://github.com/containernetworking/cni.dev/blob/main/content/plugins/v0.9/meta/flannel.md), [DHCP](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/dhcp), [Macvlan](https://github.com/containernetworking/plugins/tree/master/plugins/main/macvlan)) that implement the CNI specification and 3rd party plugins (eg. [Calico](https://github.com/projectcalico/cni-plugin), [Weave](https://github.com/weaveworks/weave), [Cilium](https://github.com/cilium/cilium), [Contiv](https://github.com/contiv/netplugin)). In addition to it, Multus supports [SRIOV](https://github.com/hustcat/sriov-cni), [DPDK](https://github.com/Intel-Corp/sriov-cni), [OVS-DPDK & VPP](https://github.com/intel/vhost-user-net-plugin) workloads in Kubernetes with both cloud native and NFV based applications in Kubernetes.
|
||||
|
||||
|
||||
@@ -99,9 +99,10 @@ resource requests/limits of that type for each Container in the Pod.
|
||||
Limits and requests for CPU resources are measured in *cpu* units.
|
||||
One cpu, in Kubernetes, is equivalent to **1 vCPU/Core** for cloud providers and **1 hyperthread** on bare-metal Intel processors.
|
||||
|
||||
Fractional requests are allowed. A Container with
|
||||
`spec.containers[].resources.requests.cpu` of `0.5` is guaranteed half as much
|
||||
CPU as one that asks for 1 CPU. The expression `0.1` is equivalent to the
|
||||
Fractional requests are allowed. When you define a container with
|
||||
`spec.containers[].resources.requests.cpu` set to `0.5`, you are requesting half
|
||||
as much CPU time compared to if you asked for `1.0` CPU.
|
||||
For CPU resource units, the expression `0.1` is equivalent to the
|
||||
expression `100m`, which can be read as "one hundred millicpu". Some people say
|
||||
"one hundred millicores", and this is understood to mean the same thing. A
|
||||
request with a decimal point, like `0.1`, is converted to `100m` by the API, and
|
||||
@@ -236,7 +237,7 @@ The kubelet also uses this kind of storage to hold
|
||||
container images, and the writable layers of running containers.
|
||||
|
||||
{{< caution >}}
|
||||
If a node fails, the data in its ephemeral storage can be lost.
|
||||
If a node fails, the data in its ephemeral storage can be lost.
|
||||
Your applications cannot expect any performance SLAs (disk IOPS for example)
|
||||
from local ephemeral storage.
|
||||
{{< /caution >}}
|
||||
@@ -440,7 +441,7 @@ Kubernetes does not use them.
|
||||
Quotas are faster and more accurate than directory scanning. When a
|
||||
directory is assigned to a project, all files created under a
|
||||
directory are created in that project, and the kernel merely has to
|
||||
keep track of how many blocks are in use by files in that project.
|
||||
keep track of how many blocks are in use by files in that project.
|
||||
If a file is created and deleted, but has an open file descriptor,
|
||||
it continues to consume space. Quota tracking records that space accurately
|
||||
whereas directory scans overlook the storage used by deleted files.
|
||||
|
||||
@@ -55,7 +55,7 @@ DNS server watches the Kubernetes API for new `Services` and creates a set of DN
|
||||
|
||||
If you only need access to the port for debugging purposes, you can use the [apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls) or [`kubectl port-forward`](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/).
|
||||
|
||||
If you explicitly need to expose a Pod's port on the node, consider using a [NodePort](/docs/concepts/services-networking/service/#nodeport) Service before resorting to `hostPort`.
|
||||
If you explicitly need to expose a Pod's port on the node, consider using a [NodePort](/docs/concepts/services-networking/service/#type-nodeport) Service before resorting to `hostPort`.
|
||||
|
||||
- Avoid using `hostNetwork`, for the same reasons as `hostPort`.
|
||||
|
||||
|
||||
@@ -244,7 +244,7 @@ on the fly:
|
||||
|
||||
The `kubernetes.io/basic-auth` type is provided for storing credentials needed
|
||||
for basic authentication. When using this Secret type, the `data` field of the
|
||||
Secret must contain the following two keys:
|
||||
Secret must contain one of the following two keys:
|
||||
|
||||
- `username`: the user name for authentication;
|
||||
- `password`: the password or token for authentication.
|
||||
|
||||
@@ -59,7 +59,7 @@ Resources consumed by the command are counted against the Container.
|
||||
### Hook handler execution
|
||||
|
||||
When a Container lifecycle management hook is called,
|
||||
the Kubernetes management system execute the handler according to the hook action,
|
||||
the Kubernetes management system executes the handler according to the hook action,
|
||||
`httpGet` and `tcpSocket` are executed by the kubelet process, and `exec` is executed in the container.
|
||||
|
||||
Hook handler calls are synchronous within the context of the Pod containing the Container.
|
||||
|
||||
@@ -265,6 +265,73 @@ 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`.
|
||||
|
||||
### Interpretation of config.json {#config-json}
|
||||
|
||||
The interpretation of `config.json` varies between the original Docker
|
||||
implementation and the Kubernetes interpretation. In Docker, the `auths` keys
|
||||
can only specify root URLs, whereas Kubernetes allows glob URLs as well as
|
||||
prefix-matched paths. This means that a `config.json` like this is valid:
|
||||
|
||||
```json
|
||||
{
|
||||
"auths": {
|
||||
"*my-registry.io/images": {
|
||||
"auth": "…"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
The root URL (`*my-registry.io`) is matched by using the following syntax:
|
||||
|
||||
```
|
||||
pattern:
|
||||
{ term }
|
||||
|
||||
term:
|
||||
'*' matches any sequence of non-Separator characters
|
||||
'?' matches any single non-Separator character
|
||||
'[' [ '^' ] { character-range } ']'
|
||||
character class (must be non-empty)
|
||||
c matches character c (c != '*', '?', '\\', '[')
|
||||
'\\' c matches character c
|
||||
|
||||
character-range:
|
||||
c matches character c (c != '\\', '-', ']')
|
||||
'\\' c matches character c
|
||||
lo '-' hi matches character c for lo <= c <= hi
|
||||
```
|
||||
|
||||
Image pull operations would now pass the credentials to the CRI container
|
||||
runtime for every valid pattern. For example the following container image names
|
||||
would match successfully:
|
||||
|
||||
- `my-registry.io/images`
|
||||
- `my-registry.io/images/my-image`
|
||||
- `my-registry.io/images/another-image`
|
||||
- `sub.my-registry.io/images/my-image`
|
||||
- `a.sub.my-registry.io/images/my-image`
|
||||
|
||||
The kubelet performs image pulls sequentially for every found credential. This
|
||||
means, that multiple entries in `config.json` are possible, too:
|
||||
|
||||
```json
|
||||
{
|
||||
"auths": {
|
||||
"my-registry.io/images": {
|
||||
"auth": "…"
|
||||
},
|
||||
"my-registry.io/images/subpath": {
|
||||
"auth": "…"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
If now a container specifies an image `my-registry.io/images/subpath/my-image`
|
||||
to be pulled, then the kubelet will try to download them from both
|
||||
authentication sources if one of them fails.
|
||||
|
||||
### Pre-pulled images
|
||||
|
||||
{{< note >}}
|
||||
@@ -390,3 +457,4 @@ Kubelet will merge any `imagePullSecrets` into a single virtual `.docker/config.
|
||||
|
||||
* Read the [OCI Image Manifest Specification](https://github.com/opencontainers/image-spec/blob/master/manifest.md).
|
||||
* Learn about [container image garbage collection](/docs/concepts/architecture/garbage-collection/#container-image-garbage-collection).
|
||||
* Learn more about [pulling an Image from a Private Registry](/docs/tasks/configure-pod-container/pull-image-private-registry).
|
||||
|
||||
@@ -52,9 +52,9 @@ Flags and configuration files may not always be changeable in a hosted Kubernete
|
||||
Extensions are software components that extend and deeply integrate with Kubernetes.
|
||||
They adapt it to support new types and new kinds of hardware.
|
||||
|
||||
Most cluster administrators will use a hosted or distribution
|
||||
instance of Kubernetes. As a result, most Kubernetes users will not need to
|
||||
install extensions and fewer will need to author new ones.
|
||||
Many cluster administrators use a hosted or distribution instance of Kubernetes.
|
||||
These clusters come with extensions pre-installed. As a result, most Kubernetes
|
||||
users will not need to install extensions and even fewer users will need to author new ones.
|
||||
|
||||
## Extension Patterns
|
||||
|
||||
|
||||
@@ -148,8 +148,8 @@ and use a controller to handle events.
|
||||
Usually, each resource in the Kubernetes API requires code that handles REST requests and manages persistent storage of objects. The main Kubernetes API server handles built-in resources like *pods* and *services*, and can also generically handle custom resources through [CRDs](#customresourcedefinitions).
|
||||
|
||||
The [aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) allows you to provide specialized
|
||||
implementations for your custom resources by writing and deploying your own standalone API server.
|
||||
The main API server delegates requests to you for the custom resources that you handle,
|
||||
implementations for your custom resources by writing and deploying your own API server.
|
||||
The main API server delegates requests to your API server for the custom resources that you handle,
|
||||
making them available to all of its clients.
|
||||
|
||||
## Choosing a method for adding custom resources
|
||||
|
||||
@@ -31,9 +31,7 @@ built-in automation from the core of Kubernetes. You can use Kubernetes
|
||||
to automate deploying and running workloads, *and* you can automate how
|
||||
Kubernetes does that.
|
||||
|
||||
Kubernetes' {{< glossary_tooltip text="controllers" term_id="controller" >}}
|
||||
concept lets you extend the cluster's behaviour without modifying the code
|
||||
of Kubernetes itself.
|
||||
Kubernetes' {{< glossary_tooltip text="operator pattern" term_id="operator-pattern" >}} concept lets you extend the cluster's behaviour without modifying the code of Kubernetes itself by linking {{< glossary_tooltip text="controllers" term_id="controller" >}} to one or more custom resources.
|
||||
Operators are clients of the Kubernetes API that act as controllers for
|
||||
a [Custom Resource](/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
|
||||
|
||||
|
||||
@@ -74,10 +74,10 @@ Suggestions for securing your infrastructure in a Kubernetes cluster:
|
||||
Area of Concern for Kubernetes Infrastructure | Recommendation |
|
||||
--------------------------------------------- | -------------- |
|
||||
Network access to API Server (Control plane) | All access to the Kubernetes control plane is not allowed publicly on the internet and is controlled by network access control lists restricted to the set of IP addresses needed to administer the cluster.|
|
||||
Network access to Nodes (nodes) | Nodes should be configured to _only_ accept connections (via network access control lists)from the control plane on the specified ports, and accept connections for services in Kubernetes of type NodePort and LoadBalancer. If possible, these nodes should not be exposed on the public internet entirely.
|
||||
Network access to Nodes (nodes) | Nodes should be configured to _only_ accept connections (via network access control lists) from the control plane on the specified ports, and accept connections for services in Kubernetes of type NodePort and LoadBalancer. If possible, these nodes should not be exposed on the public internet entirely.
|
||||
Kubernetes access to Cloud Provider API | Each cloud provider needs to grant a different set of permissions to the Kubernetes control plane and nodes. It is best to provide the cluster with cloud provider access that follows the [principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege) for the resources it needs to administer. The [Kops documentation](https://github.com/kubernetes/kops/blob/master/docs/iam_roles.md#iam-roles) provides information about IAM policies and roles.
|
||||
Access to etcd | Access to etcd (the datastore of Kubernetes) should be limited to the control plane only. Depending on your configuration, you should attempt to use etcd over TLS. More information can be found in the [etcd documentation](https://github.com/etcd-io/etcd/tree/master/Documentation).
|
||||
etcd Encryption | Wherever possible it's a good practice to encrypt all drives at rest, but since etcd holds the state of the entire cluster (including Secrets) its disk should especially be encrypted at rest.
|
||||
etcd Encryption | Wherever possible it's a good practice to encrypt all storage at rest, and since etcd holds the state of the entire cluster (including Secrets) its disk should especially be encrypted at rest.
|
||||
|
||||
{{< /table >}}
|
||||
|
||||
@@ -99,7 +99,7 @@ good information practices, read and follow the advice about
|
||||
Depending on the attack surface of your application, you may want to focus on specific
|
||||
aspects of security. For example: If you are running a service (Service A) that is critical
|
||||
in a chain of other resources and a separate workload (Service B) which is
|
||||
vulnerable to a resource exhaustion attack then the risk of compromising Service A
|
||||
vulnerable to a resource exhaustion attack, then the risk of compromising Service A
|
||||
is high if you do not limit the resources of Service B. The following table lists
|
||||
areas of security concerns and recommendations for securing workloads running in Kubernetes:
|
||||
|
||||
@@ -108,10 +108,10 @@ Area of Concern for Workload Security | Recommendation |
|
||||
RBAC Authorization (Access to the Kubernetes API) | https://kubernetes.io/docs/reference/access-authn-authz/rbac/
|
||||
Authentication | https://kubernetes.io/docs/concepts/security/controlling-access/
|
||||
Application secrets management (and encrypting them in etcd at rest) | https://kubernetes.io/docs/concepts/configuration/secret/ <br> https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/
|
||||
Pod Security Policies | https://kubernetes.io/docs/concepts/policy/pod-security-policy/
|
||||
Ensuring that pods meet defined Pod Security Standards | https://kubernetes.io/docs/concepts/security/pod-security-standards/#policy-instantiation
|
||||
Quality of Service (and Cluster resource management) | https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/
|
||||
Network Policies | https://kubernetes.io/docs/concepts/services-networking/network-policies/
|
||||
TLS For Kubernetes Ingress | https://kubernetes.io/docs/concepts/services-networking/ingress/#tls
|
||||
TLS for Kubernetes Ingress | https://kubernetes.io/docs/concepts/services-networking/ingress/#tls
|
||||
|
||||
## Container
|
||||
|
||||
@@ -137,7 +137,7 @@ are recommendations to protect application code:
|
||||
|
||||
Area of Concern for Code | Recommendation |
|
||||
-------------------------| -------------- |
|
||||
Access over TLS only | If your code needs to communicate by TCP, perform a TLS handshake with the client ahead of time. With the exception of a few cases, encrypt everything in transit. Going one step further, it's a good idea to encrypt network traffic between services. This can be done through a process known as mutual or [mTLS](https://en.wikipedia.org/wiki/Mutual_authentication) which performs a two sided verification of communication between two certificate holding services. |
|
||||
Access over TLS only | If your code needs to communicate by TCP, perform a TLS handshake with the client ahead of time. With the exception of a few cases, encrypt everything in transit. Going one step further, it's a good idea to encrypt network traffic between services. This can be done through a process known as mutual TLS authentication or [mTLS](https://en.wikipedia.org/wiki/Mutual_authentication) which performs a two sided verification of communication between two certificate holding services. |
|
||||
Limiting port ranges of communication | This recommendation may be a bit self-explanatory, but wherever possible you should only expose the ports on your service that are absolutely essential for communication or metric gathering. |
|
||||
3rd Party Dependency Security | It is a good practice to regularly scan your application's third party libraries for known security vulnerabilities. Each programming language has a tool for performing this check automatically. |
|
||||
Static Code Analysis | Most languages provide a way for a snippet of code to be analyzed for any potentially unsafe coding practices. Whenever possible you should perform checks using automated tooling that can scan codebases for common security errors. Some of the tools can be found at: https://owasp.org/www-community/Source_Code_Analysis_Tools |
|
||||
|
||||
@@ -484,7 +484,7 @@ of individual policies are not defined here.
|
||||
- {{< example file="security/podsecurity-baseline.yaml" >}}Baseline namespace{{< /example >}}
|
||||
- {{< example file="security/podsecurity-restricted.yaml" >}}Restricted namespace{{< /example >}}
|
||||
|
||||
[**PodSecurityPolicy**](/docs/concepts/profile/pod-security-profile/) (Deprecated)
|
||||
[**PodSecurityPolicy**](/docs/concepts/policy/pod-security-policy/) (Deprecated)
|
||||
|
||||
- {{< example file="policy/privileged-psp.yaml" >}}Privileged{{< /example >}}
|
||||
- {{< example file="policy/baseline-psp.yaml" >}}Baseline{{< /example >}}
|
||||
|
||||
@@ -54,7 +54,7 @@ kubectl get pods -l run=my-nginx -o yaml | grep podIP
|
||||
|
||||
You should be able to ssh into any node in your cluster and curl both IPs. Note that the containers are *not* using port 80 on the node, nor are there any special NAT rules to route traffic to the pod. This means you can run multiple nginx pods on the same node all using the same containerPort and access them from any other pod or node in your cluster using IP. Like Docker, ports can still be published to the host node's interfaces, but the need for this is radically diminished because of the networking model.
|
||||
|
||||
You can read more about [how we achieve this](/docs/concepts/cluster-administration/networking/#how-to-achieve-this) if you're curious.
|
||||
You can read more about the [Kubernetes Networking Model](/docs/concepts/cluster-administration/networking/#the-kubernetes-network-model) if you're curious.
|
||||
|
||||
## Creating a Service
|
||||
|
||||
|
||||
@@ -28,6 +28,7 @@ Kubernetes as a project supports and maintains [AWS](https://github.com/kubernet
|
||||
controller.
|
||||
* [Apache APISIX ingress controller](https://github.com/apache/apisix-ingress-controller) is an [Apache APISIX](https://github.com/apache/apisix)-based ingress controller.
|
||||
* [Avi Kubernetes Operator](https://github.com/vmware/load-balancer-and-ingress-services-for-kubernetes) provides L4-L7 load-balancing using [VMware NSX Advanced Load Balancer](https://avinetworks.com/).
|
||||
* [BFE Ingress Controller](https://github.com/bfenetworks/ingress-bfe) is a [BFE](https://www.bfe-networks.net)-based ingress controller.
|
||||
* The [Citrix ingress controller](https://github.com/citrix/citrix-k8s-ingress-controller#readme) works with
|
||||
Citrix Application Delivery Controller.
|
||||
* [Contour](https://projectcontour.io/) is an [Envoy](https://www.envoyproxy.io/) based ingress controller.
|
||||
|
||||
@@ -51,7 +51,7 @@ graph LR;
|
||||
An Ingress may be configured to give Services externally-reachable URLs, load balance traffic, terminate SSL / TLS, and offer name-based virtual hosting. An [Ingress controller](/docs/concepts/services-networking/ingress-controllers) is responsible for fulfilling the Ingress, usually with a load balancer, though it may also configure your edge router or additional frontends to help handle the traffic.
|
||||
|
||||
An Ingress does not expose arbitrary ports or protocols. Exposing services other than HTTP and HTTPS to the internet typically
|
||||
uses a service of type [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport) or
|
||||
uses a service of type [Service.Type=NodePort](/docs/concepts/services-networking/service/#type-nodeport) or
|
||||
[Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer).
|
||||
|
||||
## Prerequisites
|
||||
|
||||
@@ -568,7 +568,7 @@ The default is `ClusterIP`.
|
||||
You can also use [Ingress](/docs/concepts/services-networking/ingress/) to expose your Service. Ingress is not a Service type, but it acts as the entry point for your cluster. It lets you consolidate your routing rules
|
||||
into a single resource as it can expose multiple services under the same IP address.
|
||||
|
||||
### Type NodePort {#nodeport}
|
||||
### Type NodePort {#type-nodeport}
|
||||
|
||||
If you set the `type` field to `NodePort`, the Kubernetes control plane
|
||||
allocates a port from a range specified by `--service-node-port-range` flag (default: 30000-32767).
|
||||
|
||||
@@ -0,0 +1,123 @@
|
||||
---
|
||||
reviewers:
|
||||
- sftim
|
||||
- marosset
|
||||
- jsturtevant
|
||||
- zshihang
|
||||
title: Projected Volumes
|
||||
content_type: concept
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
This document describes the current state of _projected volumes_ in Kubernetes. Familiarity with [volumes](/docs/concepts/storage/volumes/) is suggested.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Introduction
|
||||
|
||||
A `projected` volume maps several existing volume sources into the same directory.
|
||||
|
||||
Currently, the following types of volume sources can be projected:
|
||||
|
||||
* [`secret`](/docs/concepts/storage/volumes/#secret)
|
||||
* [`downwardAPI`](/docs/concepts/storage/volumes/#downwardapi)
|
||||
* [`configMap`](/docs/concepts/storage/volumes/#configmap)
|
||||
* `serviceAccountToken`
|
||||
|
||||
All sources are required to be in the same namespace as the Pod. For more details,
|
||||
see the [all-in-one volume design document](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/all-in-one-volume.md).
|
||||
|
||||
### Example configuration with a secret, a downwardAPI, and a configMap {#example-configuration-secret-downwardapi-configmap}
|
||||
|
||||
{{< codenew file="pods/storage/projected-secret-downwardapi-configmap.yaml" >}}
|
||||
|
||||
### Example configuration: secrets with a non-default permission mode set {#example-configuration-secrets-nondefault-permission-mode}
|
||||
|
||||
{{< codenew file="pods/storage/projected-secrets-nondefault-permission-mode.yaml" >}}
|
||||
|
||||
Each projected volume source is listed in the spec under `sources`. The
|
||||
parameters are nearly the same with two exceptions:
|
||||
|
||||
* For secrets, the `secretName` field has been changed to `name` to be consistent
|
||||
with ConfigMap naming.
|
||||
* The `defaultMode` can only be specified at the projected level and not for each
|
||||
volume source. However, as illustrated above, you can explicitly set the `mode`
|
||||
for each individual projection.
|
||||
|
||||
When the `TokenRequestProjection` feature is enabled, you can inject the token
|
||||
for the current [service account](/docs/reference/access-authn-authz/authentication/#service-account-tokens)
|
||||
into a Pod at a specified path. For example:
|
||||
|
||||
{{< codenew file="pods/storage/projected-service-account-token.yaml" >}}
|
||||
|
||||
The example Pod has a projected volume containing the injected service account
|
||||
token. This token can be used by a Pod's containers to access the Kubernetes API
|
||||
server. The `audience` field contains the intended audience of the
|
||||
token. A recipient of the token must identify itself with an identifier specified
|
||||
in the audience of the token, and otherwise should reject the token. This field
|
||||
is optional and it defaults to the identifier of the API server.
|
||||
|
||||
The `expirationSeconds` is the expected duration of validity of the service account
|
||||
token. It defaults to 1 hour and must be at least 10 minutes (600 seconds). An administrator
|
||||
can also limit its maximum value by specifying the `--service-account-max-token-expiration`
|
||||
option for the API server. The `path` field specifies a relative path to the mount point
|
||||
of the projected volume.
|
||||
|
||||
{{< note >}}
|
||||
A container using a projected volume source as a [`subPath`](/docs/concepts/storage/volumes/#using-subpath)
|
||||
volume mount will not receive updates for those volume sources.
|
||||
{{< /note >}}
|
||||
|
||||
## SecurityContext interactions
|
||||
|
||||
The [proposal for file permission handling in projected service account volume](https://github.com/kubernetes/enhancements/pull/1598)
|
||||
enhancement introduced the projected files having the the correct owner
|
||||
permissions set.
|
||||
|
||||
### Linux
|
||||
|
||||
In Linux pods that have a projected volume and `RunAsUser` set in the Pod
|
||||
[`SecurityContext`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context),
|
||||
the projected files have the correct ownership set including container user
|
||||
ownership.
|
||||
|
||||
### Windows
|
||||
|
||||
In Windows pods that have a projected volume and `RunAsUsername` set in the
|
||||
Pod `SecurityContext`, the ownership is not enforced due to the way user
|
||||
accounts are managed in Windows. Windows stores and manages local user and group
|
||||
accounts in a database file called Security Account Manager (SAM). Each
|
||||
container maintains its own instance of the SAM database, to which the host has
|
||||
no visibility into while the container is running. Windows containers are
|
||||
designed to run the user mode portion of the OS in isolation from the host,
|
||||
hence the maintenance of a virtual SAM database. As a result, the kubelet running
|
||||
on the host does not have the ability to dynamically configure host file
|
||||
ownership for virtualized container accounts. It is recommended that if files on
|
||||
the host machine are to be shared with the container then they should be placed
|
||||
into their own volume mount outside of `C:\`.
|
||||
|
||||
By default, the projected files will have the following ownership as shown for
|
||||
an example projected volume file:
|
||||
```powershell
|
||||
Path : Microsoft.PowerShell.Core\FileSystem::C:\var\run\secrets\kubernetes.io\serviceaccount\..2021_08_31_22_22_18.318230061\ca.crt
|
||||
Owner : BUILTIN\Administrators
|
||||
Group : NT AUTHORITY\SYSTEM
|
||||
Access : NT AUTHORITY\SYSTEM Allow FullControl
|
||||
BUILTIN\Administrators Allow FullControl
|
||||
BUILTIN\Users Allow ReadAndExecute, Synchronize
|
||||
Audit :
|
||||
Sddl : O:BAG:SYD:AI(A;ID;FA;;;SY)(A;ID;FA;;;BA)(A;ID;0x1200a9;;;BU)
|
||||
```
|
||||
This implies all administrator users like `ContainerAdministrator` will have
|
||||
read, write and execute access while, non-administrator users will have read and
|
||||
execute access.
|
||||
|
||||
{{< note >}}
|
||||
In general, granting the container access to the host is discouraged as it can
|
||||
open the door for potential security exploits.
|
||||
|
||||
Creating a Windows Pod with `RunAsUser` in it's `SecurityContext` will result in
|
||||
the Pod being stuck at `ContainerCreating` forever. So it is advised to not use
|
||||
the Linux only `RunAsUser` option with Windows Pods.
|
||||
{{< /note >}}
|
||||
@@ -33,8 +33,8 @@ drivers, but the functionality is somewhat limited.
|
||||
Kubernetes supports many types of volumes. A {{< glossary_tooltip term_id="pod" text="Pod" >}}
|
||||
can use any number of volume types simultaneously.
|
||||
Ephemeral volume types have a lifetime of a pod, but persistent volumes exist beyond
|
||||
the lifetime of a pod. When a pod ceases to exist, Kubernetes destroys ephemeral volumes;
|
||||
however, Kubernetes does not destroy persistent volumes.
|
||||
the lifetime of a pod. When a pod ceases to exist, Kubernetes destroys ephemeral volumes;
|
||||
however, Kubernetes does not destroy persistent volumes.
|
||||
For any kind of volume in a given pod, data is preserved across container restarts.
|
||||
|
||||
At its core, a volume is a directory, possibly with some data in it, which
|
||||
@@ -44,12 +44,21 @@ volume type used.
|
||||
|
||||
To use a volume, specify the volumes to provide for the Pod in `.spec.volumes`
|
||||
and declare where to mount those volumes into containers in `.spec.containers[*].volumeMounts`.
|
||||
A process in a container sees a filesystem view composed from their Docker
|
||||
image and volumes. The [Docker image](https://docs.docker.com/userguide/dockerimages/)
|
||||
is at the root of the filesystem hierarchy. Volumes mount at the specified paths within
|
||||
the image. Volumes can not mount onto other volumes or have hard links to
|
||||
other volumes. Each Container in the Pod's configuration must independently specify where to
|
||||
mount each volume.
|
||||
A process in a container sees a filesystem view composed from the initial contents of
|
||||
the {{< glossary_tooltip text="container image" term_id="image" >}}, plus volumes
|
||||
(if defined) mounted inside the container.
|
||||
The process sees a root filesystem that initially matches the contents of the container
|
||||
image.
|
||||
Any writes to within that filesystem hierarchy, if allowed, affect what that process views
|
||||
when it performs a subsequent filesystem access.
|
||||
Volumes mount at the [specified paths](#using-subpath) within
|
||||
the image.
|
||||
For each container defined within a Pod, you must independently specify where
|
||||
to mount each volume that the container uses.
|
||||
|
||||
Volumes cannot mount within other volumes (but see [Using subPath](#using-subpath)
|
||||
for a related mechanism). Also, a volume cannot contain a hard link to anything in
|
||||
a different volume.
|
||||
|
||||
## Types of Volumes {#volume-types}
|
||||
|
||||
@@ -217,7 +226,7 @@ It redirects all plugin operations from the existing in-tree plugin to the
|
||||
`cinder.csi.openstack.org` Container Storage Interface (CSI) Driver.
|
||||
[OpenStack Cinder CSI Driver](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/cinder-csi-plugin/using-cinder-csi-plugin.md)
|
||||
must be installed on the cluster.
|
||||
You can disable Cinder CSI migration for your cluster by setting the `CSIMigrationOpenStack`
|
||||
You can disable Cinder CSI migration for your cluster by setting the `CSIMigrationOpenStack`
|
||||
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) to `false`.
|
||||
If you disable the `CSIMigrationOpenStack` feature, the in-tree Cinder volume plugin takes responsibility
|
||||
for all aspects of Cinder volume storage management.
|
||||
@@ -801,143 +810,8 @@ For more details, see the [Portworx volume](https://github.com/kubernetes/exampl
|
||||
|
||||
### projected
|
||||
|
||||
A `projected` volume maps several existing volume sources into the same directory.
|
||||
|
||||
Currently, the following types of volume sources can be projected:
|
||||
|
||||
* [`secret`](#secret)
|
||||
* [`downwardAPI`](#downwardapi)
|
||||
* [`configMap`](#configmap)
|
||||
* `serviceAccountToken`
|
||||
|
||||
All sources are required to be in the same namespace as the Pod. For more details,
|
||||
see the [all-in-one volume design document](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/all-in-one-volume.md).
|
||||
|
||||
#### Example configuration with a secret, a downwardAPI, and a configMap {#example-configuration-secret-downwardapi-configmap}
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: volume-test
|
||||
spec:
|
||||
containers:
|
||||
- name: container-test
|
||||
image: busybox
|
||||
volumeMounts:
|
||||
- name: all-in-one
|
||||
mountPath: "/projected-volume"
|
||||
readOnly: true
|
||||
volumes:
|
||||
- name: all-in-one
|
||||
projected:
|
||||
sources:
|
||||
- secret:
|
||||
name: mysecret
|
||||
items:
|
||||
- key: username
|
||||
path: my-group/my-username
|
||||
- downwardAPI:
|
||||
items:
|
||||
- path: "labels"
|
||||
fieldRef:
|
||||
fieldPath: metadata.labels
|
||||
- path: "cpu_limit"
|
||||
resourceFieldRef:
|
||||
containerName: container-test
|
||||
resource: limits.cpu
|
||||
- configMap:
|
||||
name: myconfigmap
|
||||
items:
|
||||
- key: config
|
||||
path: my-group/my-config
|
||||
```
|
||||
|
||||
#### Example configuration: secrets with a non-default permission mode set {#example-configuration-secrets-nondefault-permission-mode}
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: volume-test
|
||||
spec:
|
||||
containers:
|
||||
- name: container-test
|
||||
image: busybox
|
||||
volumeMounts:
|
||||
- name: all-in-one
|
||||
mountPath: "/projected-volume"
|
||||
readOnly: true
|
||||
volumes:
|
||||
- name: all-in-one
|
||||
projected:
|
||||
sources:
|
||||
- secret:
|
||||
name: mysecret
|
||||
items:
|
||||
- key: username
|
||||
path: my-group/my-username
|
||||
- secret:
|
||||
name: mysecret2
|
||||
items:
|
||||
- key: password
|
||||
path: my-group/my-password
|
||||
mode: 511
|
||||
```
|
||||
|
||||
Each projected volume source is listed in the spec under `sources`. The
|
||||
parameters are nearly the same with two exceptions:
|
||||
|
||||
* For secrets, the `secretName` field has been changed to `name` to be consistent
|
||||
with ConfigMap naming.
|
||||
* The `defaultMode` can only be specified at the projected level and not for each
|
||||
volume source. However, as illustrated above, you can explicitly set the `mode`
|
||||
for each individual projection.
|
||||
|
||||
When the `TokenRequestProjection` feature is enabled, you can inject the token
|
||||
for the current [service account](/docs/reference/access-authn-authz/authentication/#service-account-tokens)
|
||||
into a Pod at a specified path. For example:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: sa-token-test
|
||||
spec:
|
||||
containers:
|
||||
- name: container-test
|
||||
image: busybox
|
||||
volumeMounts:
|
||||
- name: token-vol
|
||||
mountPath: "/service-account"
|
||||
readOnly: true
|
||||
volumes:
|
||||
- name: token-vol
|
||||
projected:
|
||||
sources:
|
||||
- serviceAccountToken:
|
||||
audience: api
|
||||
expirationSeconds: 3600
|
||||
path: token
|
||||
```
|
||||
|
||||
The example Pod has a projected volume containing the injected service account
|
||||
token. This token can be used by a Pod's containers to access the Kubernetes API
|
||||
server. The `audience` field contains the intended audience of the
|
||||
token. A recipient of the token must identify itself with an identifier specified
|
||||
in the audience of the token, and otherwise should reject the token. This field
|
||||
is optional and it defaults to the identifier of the API server.
|
||||
|
||||
The `expirationSeconds` is the expected duration of validity of the service account
|
||||
token. It defaults to 1 hour and must be at least 10 minutes (600 seconds). An administrator
|
||||
can also limit its maximum value by specifying the `--service-account-max-token-expiration`
|
||||
option for the API server. The `path` field specifies a relative path to the mount point
|
||||
of the projected volume.
|
||||
|
||||
{{< note >}}
|
||||
A container using a projected volume source as a [`subPath`](#using-subpath) volume mount will not
|
||||
receive updates for those volume sources.
|
||||
{{< /note >}}
|
||||
A projected volume maps several existing volume sources into the same
|
||||
directory. For more details, see [projected volumes](/docs/concepts/storage/projected-volumes/)
|
||||
|
||||
### quobyte (deprecated) {#quobyte}
|
||||
|
||||
|
||||
@@ -17,8 +17,6 @@ A _CronJob_ creates {{< glossary_tooltip term_id="job" text="Jobs" >}} on a repe
|
||||
One CronJob object is like one line of a _crontab_ (cron table) file. It runs a job periodically
|
||||
on a given schedule, written in [Cron](https://en.wikipedia.org/wiki/Cron) format.
|
||||
|
||||
In addition, the CronJob schedule supports timezone handling, you can specify the timezone by adding "CRON_TZ=<time zone>" at the beginning of the CronJob schedule, and it is recommended to always set `CRON_TZ`.
|
||||
|
||||
{{< caution >}}
|
||||
All **CronJob** `schedule:` times are based on the timezone of the
|
||||
{{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}.
|
||||
@@ -28,6 +26,16 @@ containers, the timezone set for the kube-controller-manager container determine
|
||||
that the cron job controller uses.
|
||||
{{< /caution >}}
|
||||
|
||||
{{< caution >}}
|
||||
The [v1 CronJob API](/docs/reference/kubernetes-api/workload-resources/cron-job-v1/)
|
||||
does not officially support setting timezone as explained above.
|
||||
|
||||
Setting variables such as `CRON_TZ` or `TZ` is not officially supported by the Kubernetes project.
|
||||
`CRON_TZ` or `TZ` is an implementation detail of the internal library being used
|
||||
for parsing and calculating the next Job creation time. Any usage of it is not
|
||||
recommended in a production cluster.
|
||||
{{< /caution >}}
|
||||
|
||||
When creating the manifest for a CronJob resource, make sure the name you provide
|
||||
is a valid [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
|
||||
The name must be no longer than 52 characters. This is because the CronJob controller will automatically
|
||||
@@ -55,16 +63,15 @@ takes you through this example in more detail).
|
||||
### Cron schedule syntax
|
||||
|
||||
```
|
||||
# ┌────────────────── timezone (optional)
|
||||
# | ┌───────────── minute (0 - 59)
|
||||
# | │ ┌───────────── hour (0 - 23)
|
||||
# | │ │ ┌───────────── day of the month (1 - 31)
|
||||
# | │ │ │ ┌───────────── month (1 - 12)
|
||||
# | │ │ │ │ ┌───────────── day of the week (0 - 6) (Sunday to Saturday;
|
||||
# | │ │ │ │ │ 7 is also Sunday on some systems)
|
||||
# | │ │ │ │ │
|
||||
# | │ │ │ │ │
|
||||
# CRON_TZ=UTC * * * * *
|
||||
# ┌───────────── minute (0 - 59)
|
||||
# │ ┌───────────── hour (0 - 23)
|
||||
# │ │ ┌───────────── day of the month (1 - 31)
|
||||
# │ │ │ ┌───────────── month (1 - 12)
|
||||
# │ │ │ │ ┌───────────── day of the week (0 - 6) (Sunday to Saturday;
|
||||
# │ │ │ │ │ 7 is also Sunday on some systems)
|
||||
# │ │ │ │ │
|
||||
# │ │ │ │ │
|
||||
# * * * * *
|
||||
```
|
||||
|
||||
|
||||
@@ -78,9 +85,9 @@ takes you through this example in more detail).
|
||||
|
||||
|
||||
|
||||
For example, the line below states that the task must be started every Friday at midnight, as well as on the 13th of each month at midnight(in UTC):
|
||||
For example, the line below states that the task must be started every Friday at midnight, as well as on the 13th of each month at midnight:
|
||||
|
||||
`CRON_TZ=UTC 0 0 13 * 5`
|
||||
`0 0 13 * 5`
|
||||
|
||||
To generate CronJob schedule expressions, you can also use web tools like [crontab.guru](https://crontab.guru/).
|
||||
|
||||
|
||||
@@ -703,6 +703,7 @@ You can pause a Deployment before triggering one or more updates and then resume
|
||||
apply multiple fixes in between pausing and resuming without triggering unnecessary rollouts.
|
||||
|
||||
* For example, with a Deployment that was created:
|
||||
|
||||
Get the Deployment details:
|
||||
```shell
|
||||
kubectl get deploy
|
||||
@@ -753,7 +754,7 @@ apply multiple fixes in between pausing and resuming without triggering unnecess
|
||||
REVISION CHANGE-CAUSE
|
||||
1 <none>
|
||||
```
|
||||
* Get the rollout status to ensure that the Deployment is updated successfully:
|
||||
* Get the rollout status to verify that the existing ReplicaSet has not changed:
|
||||
```shell
|
||||
kubectl get rs
|
||||
```
|
||||
|
||||
@@ -282,7 +282,7 @@ define readiness distinct from completion. This is enforced during validation.
|
||||
|
||||
Use `activeDeadlineSeconds` on the Pod to prevent init containers from failing forever.
|
||||
The active deadline includes init containers.
|
||||
However it is recommended to use `activeDeadlineSeconds` if user deploy their application
|
||||
However it is recommended to use `activeDeadlineSeconds` only if teams deploy their application
|
||||
as a Job, because `activeDeadlineSeconds` has an effect even after initContainer finished.
|
||||
The Pod which is already running correctly would be killed by `activeDeadlineSeconds` if you set.
|
||||
|
||||
|
||||
@@ -236,41 +236,41 @@ The scheduler will skip the non-matching nodes from the skew calculations if the
|
||||
|
||||
Suppose you have a 5-node cluster ranging from zoneA to zoneC:
|
||||
|
||||
{{<mermaid>}}
|
||||
graph BT
|
||||
subgraph "zoneB"
|
||||
p3(Pod) --> n3(Node3)
|
||||
n4(Node4)
|
||||
end
|
||||
subgraph "zoneA"
|
||||
p1(Pod) --> n1(Node1)
|
||||
p2(Pod) --> n2(Node2)
|
||||
end
|
||||
{{<mermaid>}}
|
||||
graph BT
|
||||
subgraph "zoneB"
|
||||
p3(Pod) --> n3(Node3)
|
||||
n4(Node4)
|
||||
end
|
||||
subgraph "zoneA"
|
||||
p1(Pod) --> n1(Node1)
|
||||
p2(Pod) --> n2(Node2)
|
||||
end
|
||||
|
||||
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
|
||||
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
|
||||
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
|
||||
class n1,n2,n3,n4,p1,p2,p3 k8s;
|
||||
class p4 plain;
|
||||
class zoneA,zoneB cluster;
|
||||
{{< /mermaid >}}
|
||||
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
|
||||
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
|
||||
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
|
||||
class n1,n2,n3,n4,p1,p2,p3 k8s;
|
||||
class p4 plain;
|
||||
class zoneA,zoneB cluster;
|
||||
{{< /mermaid >}}
|
||||
|
||||
{{<mermaid>}}
|
||||
graph BT
|
||||
subgraph "zoneC"
|
||||
n5(Node5)
|
||||
end
|
||||
{{<mermaid>}}
|
||||
graph BT
|
||||
subgraph "zoneC"
|
||||
n5(Node5)
|
||||
end
|
||||
|
||||
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
|
||||
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
|
||||
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
|
||||
class n5 k8s;
|
||||
class zoneC cluster;
|
||||
{{< /mermaid >}}
|
||||
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
|
||||
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
|
||||
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
|
||||
class n5 k8s;
|
||||
class zoneC cluster;
|
||||
{{< /mermaid >}}
|
||||
|
||||
and you know that "zoneC" must be excluded. In this case, you can compose the yaml as below, so that "mypod" will be placed onto "zoneB" instead of "zoneC". Similarly `spec.nodeSelector` is also respected.
|
||||
|
||||
{{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}}
|
||||
{{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}}
|
||||
|
||||
The scheduler doesn't have prior knowledge of all the zones or other topology domains that a cluster has. They are determined from the existing nodes in the cluster. This could lead to a problem in autoscaled clusters, when a node pool (or node group) is scaled to zero nodes and the user is expecting them to scale up, because, in this case, those topology domains won't be considered until there is at least one node in them.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user