Merge remote-tracking branch 'upstream/master' into merged-master-dev-1.16
This commit is contained in:
simplytunde
+1
-1
@@ -418,7 +418,7 @@ zk-budget 2 1 2h
|
||||
|
||||
|
||||
|
||||
zk-budget indicates that at least two members of the ensemble must be available at all times for the ensemble to be healthy. If you attempt to drain a node prior taking it offline, and if draining it would terminate a Pod that violates the budget, the drain operation will fail. If you use [kubectl drain](/docs/user-guide/kubectl/kubectl_drain/), in conjunction with PodDisruptionBudgets, to cordon your nodes and to evict all Pods prior to maintenance or decommissioning, you can ensure that the procedure won’t be disruptive to your stateful applications.
|
||||
zk-budget indicates that at least two members of the ensemble must be available at all times for the ensemble to be healthy. If you attempt to drain a node prior taking it offline, and if draining it would terminate a Pod that violates the budget, the drain operation will fail. If you use [kubectl drain](/docs/reference/generated/kubectl/kubectl-commands#drain), in conjunction with PodDisruptionBudgets, to cordon your nodes and to evict all Pods prior to maintenance or decommissioning, you can ensure that the procedure won’t be disruptive to your stateful applications.
|
||||
|
||||
|
||||
|
||||
|
||||
+1
-1
@@ -87,5 +87,5 @@ With today’s [announcement from CNCF](https://www.cncf.io/announcement/2018/08
|
||||
|
||||
Want to find out more? Come check out these resources:
|
||||
|
||||
* [Prow: Testing the way to Kubernetes Next](https://bentheelder.io/posts/prow)
|
||||
* [Prow: Testing the way to Kubernetes Next](https://elder.dev/posts/prow)
|
||||
* [Automation and the Kubernetes Contributor Experience](https://www.youtube.com/watch?v=BsIC7gPkH5M)
|
||||
|
||||
@@ -0,0 +1,65 @@
|
||||
|
||||
---
|
||||
layout: blog
|
||||
title: "Announcing etcd 3.4"
|
||||
date: 2019-08-30
|
||||
slug: announcing-etcd-3-4
|
||||
---
|
||||
|
||||
**Authors:** Gyuho Lee (Amazon Web Services, @[gyuho](https://github.com/gyuho)), Jingyi Hu (Google, @[jingyih](https://github.com/jingyih))
|
||||
|
||||
etcd 3.4 focuses on stability, performance and ease of operation, with features like pre-vote and non-voting member and improvements to storage backend and client balancer.
|
||||
|
||||
Please see [CHANGELOG](https://github.com/etcd-io/etcd/blob/master/CHANGELOG-3.4.md) for full lists of changes.
|
||||
|
||||
## Better Storage Backend
|
||||
|
||||
etcd v3.4 includes a number of performance improvements for large scale Kubernetes workloads.
|
||||
|
||||
In particular, etcd experienced performance issues with a large number of concurrent read transactions even when there is no write (e.g. `“read-only range request ... took too long to execute”`). Previously, the storage backend commit operation on pending writes blocks incoming read transactions, even when there was no pending write. Now, the commit [does not block reads](https://github.com/etcd-io/etcd/pull/9296) which improve long-running read transaction performance.
|
||||
|
||||
We further made [backend read transactions fully concurrent](https://github.com/etcd-io/etcd/pull/10523). Previously, ongoing long-running read transactions block writes and upcoming reads. With this change, write throughput is increased by 70% and P99 write latency is reduced by 90% in the presence of long-running reads. We also ran [Kubernetes 5000-node scalability test on GCE](https://prow.k8s.io/view/gcs/kubernetes-jenkins/logs/ci-kubernetes-e2e-gce-scale-performance/1130745634945503235) with this change and observed similar improvements. For example, in the very beginning of the test where there are a lot of long-running “LIST pods”, the P99 latency of “POST clusterrolebindings” is [reduced by 97.4%](https://github.com/etcd-io/etcd/pull/10523#issuecomment-499262001). This non-blocking read transaction is now [used for compaction](https://github.com/etcd-io/etcd/pull/11034), which, combined with the reduced compaction batch size, reduces the P99 server request latency during compaction.
|
||||
|
||||
More improvements have been made to lease storage. We enhanced [lease expire/revoke performance](https://github.com/etcd-io/etcd/pull/9418) by storing lease objects more efficiently, and made [lease look-up operation non-blocking](https://github.com/etcd-io/etcd/pull/9229) with current lease grant/revoke operation. And etcd v3.4 introduces [lease checkpoint](https://github.com/etcd-io/etcd/pull/9924) as an experimental feature to persist remaining time-to-live values through consensus. This ensures short-lived lease objects are not auto-renewed after leadership election. This also prevents lease object pile-up when the time-to-live value is relatively large (e.g. [1-hour TTL never expired in Kubernetes use case](https://github.com/kubernetes/kubernetes/issues/65497)).
|
||||
|
||||
## Improved Raft Voting Process
|
||||
|
||||
etcd server implements [Raft consensus algorithm](https://raft.github.io) for data replication. Raft is a leader-based protocol. Data is replicated from leader to follower; a follower forwards proposals to a leader, and the leader decides what to commit or not. Leader persists and replicates an entry, once it has been agreed by the quorum of cluster. The cluster members elect a single leader, and all other members become followers. The elected leader periodically sends heartbeats to its followers to maintain its leadership, and expects responses from each follower to keep track of its progress.
|
||||
|
||||
In its simplest form, a Raft leader steps down to a follower when it receives a message with higher terms without any further cluster-wide health checks. This behavior can affect the overall cluster availability.
|
||||
|
||||
For instance, a flaky (or rejoining) member drops in and out, and starts campaign. This member ends up with higher terms, ignores all incoming messages with lower terms, and sends out messages with higher terms. When the leader receives this message of a higher term, it reverts back to follower.
|
||||
|
||||
This becomes more disruptive when there’s a network partition. Whenever the partitioned node regains its connectivity, it can possibly trigger the leader re-election. To address this issue, etcd Raft introduces a new node state pre-candidate with the [pre-vote feature](https://github.com/etcd-io/etcd/pull/9352). The pre-candidate first asks other servers whether it's up-to-date enough to get votes. Only if it can get votes from the majority, it increments its term and starts an election. This extra phase improves the robustness of leader election in general. And helps the leader remain stable as long as it maintains its connectivity with the quorum of its peers.
|
||||
|
||||
Similarly, etcd availability can be affected when a restarting node has not received the leader heartbeats in time (e.g. due to slow network), which triggers the leader election. Previously, etcd fast-forwards election ticks on server start, with only one tick left for leader election. For example, when the election timeout is 1-second, the follower only waits 100ms for leader contacts before starting an election. This speeds up initial server start, by not having to wait for the election timeouts (e.g. election is triggered in 100ms instead of 1-second). Advancing election ticks is also useful for cross datacenter deployments with larger election timeouts. However, in many cases, the availability is more critical than the speed of initial leader election. To ensure better availability with rejoining nodes, etcd now [adjusts election ticks](https://github.com/etcd-io/etcd/pull/9415) with more than one tick left, thus more time for the leader to prevent a disruptive restart.
|
||||
|
||||
## Raft Non-Voting Member, Learner
|
||||
|
||||
The challenge with membership reconfiguration is that it often leads to quorum size changes, which are prone to cluster unavailabilities. Even if it does not alter the quorum, clusters with membership change are more likely to experience other underlying problems. To improve the reliability and confidence of reconfiguration, a new role - learner is introduced in etcd 3.4 release.
|
||||
|
||||
A new etcd member joins the cluster with no initial data, requesting all historical updates from the leader until it catches up to the leader’s logs. This means the leader’s network is more likely to be overloaded, blocking or dropping leader heartbeats to followers. In such cases, a follower may experience election-timeout and start a new leader election. That is, a cluster with a new member is more vulnerable to leader election. Both leader election and the subsequent update propagation to the new member are prone to causing periods of cluster unavailability (see *Figure 1*).
|
||||
|
||||
|
||||
|
||||
The worst case is a misconfigured membership add. Membership reconfiguration in etcd is a two-step process: `etcdctl member add` with peer URLs, and starting a new etcd to join the cluster. That is, `member add` command is applied whether the peer URL value is invalid or not. If the first step is to apply the invalid URLs and change the quorum size, it is possible that the cluster already loses the quorum until the new node connects. Since the node with invalid URLs will never become online and there’s no leader, it is impossible to revert the membership change (see *Figure 2*).
|
||||
|
||||
|
||||
|
||||
This becomes more complicated when there are partitioned nodes (see the [design document](https://github.com/etcd-io/etcd/blob/master/Documentation/learning/design-learner.md) for more).
|
||||
|
||||
In order to address such failure modes, etcd introduces a [new node state “Learner”](https://github.com/etcd-io/etcd/issues/10537), which joins the cluster as a non-voting member until it catches up to leader’s logs. This means the learner still receives all updates from leader, while it does not count towards the quorum, which is used by the leader to evaluate peer activeness. The learner only serves as a standby node until promoted. This relaxed requirements for quorum provides the better availability during membership reconfiguration and operational safety (see *Figure 3*).
|
||||
|
||||
|
||||
|
||||
We will further improve learner robustness, and explore auto-promote mechanisms for easier and more reliable operation. Please read our [learner design documentation](https://github.com/etcd-io/etcd/blob/master/Documentation/learning/design-learner.md) and [runtime-configuration document](https://github.com/etcd-io/etcd/blob/master/Documentation/op-guide/runtime-configuration.md#add-a-new-member-as-learner) for user guides.
|
||||
|
||||
## New Client Balancer
|
||||
|
||||
etcd is designed to tolerate various system and network faults. By design, even if one node goes down, the cluster “appears” to be working normally, by providing one logical cluster view of multiple servers. But, this does not guarantee the liveness of the client. Thus, etcd client has implemented a different set of intricate protocols to guarantee its correctness and high availability under faulty conditions.
|
||||
|
||||
Historically, etcd client balancer heavily relied on old gRPC interface: every gRPC dependency upgrade broke client behavior. A majority of development and debugging efforts were devoted to fixing those client behavior changes. As a result, its implementation has become overly complicated with bad assumptions on server connectivity. The primary goal was to [simplify balancer failover logic in etcd v3.4 client](https://github.com/etcd-io/etcd/pull/9860); instead of maintaining a list of unhealthy endpoints, which may be stale, simply roundrobin to the next endpoint whenever client gets disconnected from the current endpoint. It does not assume endpoint status. Thus, no more complicated status tracking is needed.
|
||||
|
||||
Furthermore, the new client now creates its own credential bundle to [fix balancer failover against secure endpoints](https://github.com/etcd-io/etcd/pull/10911). This resolves the [year-long bug](https://github.com/kubernetes/kubernetes/issues/72102), where kube-apiserver loses its connectivity to etcd cluster when the first etcd server becomes unavailable.
|
||||
|
||||
Please see [client balancer design documentation](https://github.com/etcd-io/etcd/blob/master/Documentation/learning/design-client.md) for more.
|
||||
@@ -224,13 +224,14 @@ rules:
|
||||
|
||||
The following cloud providers have implemented CCMs:
|
||||
|
||||
* [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
|
||||
* [Oracle](https://github.com/oracle/oci-cloud-controller-manager)
|
||||
* [Azure](https://github.com/kubernetes/cloud-provider-azure)
|
||||
* [GCP](https://github.com/kubernetes/cloud-provider-gcp)
|
||||
* [AWS](https://github.com/kubernetes/cloud-provider-aws)
|
||||
* [Azure](https://github.com/kubernetes/cloud-provider-azure)
|
||||
* [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud)
|
||||
* [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
|
||||
* [GCP](https://github.com/kubernetes/cloud-provider-gcp)
|
||||
* [Linode](https://github.com/linode/linode-cloud-controller-manager)
|
||||
* [OpenStack](https://github.com/kubernetes/cloud-provider-openstack)
|
||||
* [Oracle](https://github.com/oracle/oci-cloud-controller-manager)
|
||||
|
||||
## Cluster Administration
|
||||
|
||||
|
||||
@@ -120,9 +120,6 @@ Node affinity is like the existing `nodeSelector` (but with the first two benefi
|
||||
while inter-pod affinity/anti-affinity constrains against pod labels rather than node labels, as
|
||||
described in the third item listed above, in addition to having the first and second properties listed above.
|
||||
|
||||
`nodeSelector` continues to work as usual, but will eventually be deprecated, as node affinity can express
|
||||
everything that `nodeSelector` can express.
|
||||
|
||||
### Node affinity
|
||||
|
||||
Node affinity is conceptually similar to `nodeSelector` -- it allows you to constrain which nodes your
|
||||
|
||||
@@ -142,7 +142,7 @@ When using Docker:
|
||||
- The `spec.containers[].resources.requests.cpu` is converted to its core value,
|
||||
which is potentially fractional, and multiplied by 1024. The greater of this number
|
||||
or 2 is used as the value of the
|
||||
[`--cpu-shares`](https://docs.docker.com/engine/reference/run/#/cpu-share-constraint)
|
||||
[`--cpu-shares`](https://docs.docker.com/engine/reference/run/#cpu-share-constraint)
|
||||
flag in the `docker run` command.
|
||||
|
||||
- The `spec.containers[].resources.limits.cpu` is converted to its millicore value and
|
||||
|
||||
@@ -81,7 +81,7 @@ Kubernetes:
|
||||
* Does not dictate logging, monitoring, or alerting solutions. It provides some integrations as proof of concept, and mechanisms to collect and export metrics.
|
||||
* Does not provide nor mandate a configuration language/system (for example, jsonnet). It provides a declarative API that may be targeted by arbitrary forms of declarative specifications.
|
||||
* Does not provide nor adopt any comprehensive machine configuration, maintenance, management, or self-healing systems.
|
||||
* Additionally, Kubernetes is not a mere orchestration system. In fact, it eliminates the need for orchestration. The technical definition of orchestration is execution of a defined workflow: first do A, then B, then C. In contrast, Kubernetes is comprised of a set of independent, composable control processes that continuously drive the current state towards the provided desired state. It shouldn’t matter how you get from A to C. Centralized control is also not required. This results in a system that is easier to use and more powerful, robust, resilient, and extensible.
|
||||
* Additionally, Kubernetes is not a mere orchestration system. In fact, it eliminates the need for orchestration. The technical definition of orchestration is execution of a defined workflow: first do A, then B, then C. In contrast, Kubernetes comprises a set of independent, composable control processes that continuously drive the current state towards the provided desired state. It shouldn’t matter how you get from A to C. Centralized control is also not required. This results in a system that is easier to use and more powerful, robust, resilient, and extensible.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -1,382 +1,382 @@
|
||||
---
|
||||
reviewers:
|
||||
- nelvadas
|
||||
title: Limit Ranges
|
||||
content_template: templates/concept
|
||||
weight: 10
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
By default, containers run with unbounded [compute resources](/docs/user-guide/compute-resources) on a Kubernetes cluster.
|
||||
With Resource quotas, cluster administrators can restrict the resource consumption and creation on a namespace basis.
|
||||
Within a namespace, a Pod or Container can consume as much CPU and memory as defined by the namespace's resource quota. There is a concern that one Pod or Container could monopolize all of the resources. Limit Range is a policy to constrain resource by Pod or Container in a namespace.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
A limit range, defined by a `LimitRange` object, provides constraints that can:
|
||||
|
||||
- Enforce minimum and maximum compute resources usage per Pod or Container in a namespace.
|
||||
- Enforce minimum and maximum storage request per PersistentVolumeClaim in a namespace.
|
||||
- Enforce a ratio between request and limit for a resource in a namespace.
|
||||
- Set default request/limit for compute resources in a namespace and automatically inject them to Containers at runtime.
|
||||
|
||||
## Enabling Limit Range
|
||||
|
||||
Limit Range support is enabled by default for many Kubernetes distributions. It is
|
||||
enabled when the apiserver `--enable-admission-plugins=` flag has `LimitRanger` admission controller as
|
||||
one of its arguments.
|
||||
|
||||
A limit range is enforced in a particular namespace when there is a
|
||||
`LimitRange` object in that namespace.
|
||||
|
||||
### Overview of Limit Range:
|
||||
|
||||
- The administrator creates one `LimitRange` in one namespace.
|
||||
- Users create resources like Pods, Containers, and PersistentVolumeClaims in the namespace.
|
||||
- The `LimitRanger` admission controller enforces defaults limits for all Pods and Container that do not set compute resource requirements and tracks usage to ensure it does not exceed resource minimum , maximum and ratio defined in any `LimitRange` present in the namespace.
|
||||
- If creating or updating a resource (Pod, Container, PersistentVolumeClaim) violates a limit range constraint, the request to the API server will fail with HTTP status code `403 FORBIDDEN` and a message explaining the constraint that would have been violated.
|
||||
- If limit range is activated in a namespace for compute resources like `cpu` and `memory`, users must specify
|
||||
requests or limits for those values; otherwise, the system may reject pod creation.
|
||||
- LimitRange validations occurs only at Pod Admission stage, not on Running pods.
|
||||
|
||||
|
||||
Examples of policies that could be created using limit range are:
|
||||
|
||||
- In a 2 node cluster with a capacity of 8 GiB RAM, and 16 cores, constrain Pods in a namespace to request 100m and not exceeds 500m for CPU , request 200Mi and not exceed 600Mi
|
||||
- Define default CPU limits and request to 150m and Memory default request to 300Mi for containers started with no cpu and memory requests in their spec.
|
||||
|
||||
In the case where the total limits of the namespace is less than the sum of the limits of the Pods/Containers,
|
||||
there may be contention for resources; The Containers or Pods will not be created.
|
||||
|
||||
Neither contention nor changes to limitrange will affect already created resources.
|
||||
|
||||
## Limiting Container compute resources
|
||||
|
||||
The following section discusses the creation of a LimitRange acting at Container Level.
|
||||
A Pod with 04 containers is first created; each container within the Pod has a specific `spec.resource` configuration
|
||||
each containerwithin the pod is handled differently by the LimitRanger admission controller.
|
||||
|
||||
Create a namespace `limitrange-demo` using the following kubectl command
|
||||
|
||||
```shell
|
||||
kubectl create namespace limitrange-demo
|
||||
```
|
||||
|
||||
To avoid passing the target limitrange-demo in your kubectl commands, change your context with the following command
|
||||
|
||||
```shell
|
||||
kubectl config set-context --current --namespace=limitrange-demo
|
||||
```
|
||||
|
||||
Here is the configuration file for a LimitRange object:
|
||||
{{< codenew file="admin/resource/limit-mem-cpu-container.yaml" >}}
|
||||
|
||||
This object defines minimum and maximum Memory/CPU limits, default cpu/Memory requests and default limits for CPU/Memory resources to be apply to containers.
|
||||
|
||||
Create the `limit-mem-cpu-per-container` LimitRange in the `limitrange-demo` namespace with the following kubectl command.
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/examples/admin/resource/limit-mem-cpu-container.yaml -n limitrange-demo
|
||||
```
|
||||
|
||||
|
||||
```shell
|
||||
kubectl describe limitrange/limit-mem-cpu-per-container -n limitrange-demo
|
||||
```
|
||||
|
||||
|
||||
```shell
|
||||
Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio
|
||||
---- -------- --- --- --------------- ------------- -----------------------
|
||||
Container cpu 100m 800m 110m 700m -
|
||||
Container memory 99Mi 1Gi 111Mi 900Mi -
|
||||
```
|
||||
|
||||
|
||||
|
||||
Here is the configuration file for a Pod with 04 containers to demonstrate LimitRange features :
|
||||
{{< codenew file="admin/resource/limit-range-pod-1.yaml" >}}
|
||||
|
||||
Create the `busybox1` Pod :
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/admin/resource/limit-range-pod-1.yaml -n limitrange-demo
|
||||
```
|
||||
|
||||
### Container spec with valid CPU/Memory requests and limits
|
||||
View the the `busybox-cnt01` resource configuration
|
||||
|
||||
```shell
|
||||
kubectl get po/busybox1 -n limitrange-demo -o json | jq ".spec.containers[0].resources"
|
||||
```
|
||||
|
||||
```json
|
||||
{
|
||||
"limits": {
|
||||
"cpu": "500m",
|
||||
"memory": "200Mi"
|
||||
},
|
||||
"requests": {
|
||||
"cpu": "100m",
|
||||
"memory": "100Mi"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
- The `busybox-cnt01` Container inside `busybox` Pod defined `requests.cpu=100m` and `requests.memory=100Mi`.
|
||||
- `100m <= 500m <= 800m` , The container cpu limit (500m) falls inside the authorized CPU limit range.
|
||||
- `99Mi <= 200Mi <= 1Gi` , The container memory limit (200Mi) falls inside the authorized Memory limit range.
|
||||
- No request/limits ratio validation for CPU/Memory , thus the container is valid and created.
|
||||
|
||||
|
||||
### Container spec with a valid CPU/Memory requests but no limits
|
||||
|
||||
View the `busybox-cnt02` resource configuration
|
||||
|
||||
```shell
|
||||
kubectl get po/busybox1 -n limitrange-demo -o json | jq ".spec.containers[1].resources"
|
||||
```
|
||||
|
||||
```json
|
||||
{
|
||||
"limits": {
|
||||
"cpu": "700m",
|
||||
"memory": "900Mi"
|
||||
},
|
||||
"requests": {
|
||||
"cpu": "100m",
|
||||
"memory": "100Mi"
|
||||
}
|
||||
}
|
||||
```
|
||||
- The `busybox-cnt02` Container inside `busybox1` Pod defined `requests.cpu=100m` and `requests.memory=100Mi` but not limits for cpu and memory.
|
||||
- The container do not have a limits section, the default limits defined in the limit-mem-cpu-per-container LimitRange object are injected to this container `limits.cpu=700mi` and `limits.memory=900Mi`.
|
||||
- `100m <= 700m <= 800m` , The container cpu limit (700m) falls inside the authorized CPU limit range.
|
||||
- `99Mi <= 900Mi <= 1Gi` , The container memory limit (900Mi) falls inside the authorized Memory limit range.
|
||||
- No request/limits ratio set , thus the container is valid and created.
|
||||
|
||||
|
||||
### Container spec with a valid CPU/Memory limits but no requests
|
||||
View the `busybox-cnt03` resource configuration
|
||||
|
||||
```shell
|
||||
kubectl get po/busybox1 -n limitrange-demo -o json | jq ".spec.containers[2].resources"
|
||||
```
|
||||
```json
|
||||
{
|
||||
"limits": {
|
||||
"cpu": "500m",
|
||||
"memory": "200Mi"
|
||||
},
|
||||
"requests": {
|
||||
"cpu": "500m",
|
||||
"memory": "200Mi"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
- The `busybox-cnt03` Container inside `busybox1` Pod defined `limits.cpu=500m` and `limits.memory=200Mi` but no `requests` for cpu and memory.
|
||||
- The container do not define a request section, the defaultRequest defined in the limit-mem-cpu-per-container LimitRange is not used to fill its limits section but the limits defined by the container are set as requests `limits.cpu=500m` and `limits.memory=200Mi`.
|
||||
- `100m <= 500m <= 800m` , The container cpu limit (500m) falls inside the authorized CPU limit range.
|
||||
- `99Mi <= 200Mi <= 1Gi` , The container memory limit (200Mi) falls inside the authorized Memory limit range.
|
||||
- No request/limits ratio set , thus the container is valid and created.
|
||||
|
||||
|
||||
|
||||
### Container spec with no CPU/Memory requests/limits
|
||||
View the `busybox-cnt04` resource configuration
|
||||
```shell
|
||||
kubectl get po/busybox1 -n limitrange-demo -o json | jq ".spec.containers[3].resources"
|
||||
```
|
||||
```json
|
||||
{
|
||||
"limits": {
|
||||
"cpu": "700m",
|
||||
"memory": "900Mi"
|
||||
},
|
||||
"requests": {
|
||||
"cpu": "110m",
|
||||
"memory": "111Mi"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
- The `busybox-cnt04` Container inside `busybox1` define neither `limits` nor `requests`.
|
||||
- The container do not define a limit section, the default limit defined in the limit-mem-cpu-per-container LimitRange is used to fill its request
|
||||
`limits.cpu=700m and` `limits.memory=900Mi` .
|
||||
- The container do not define a request section, the defaultRequest defined in the limit-mem-cpu-per-container LimitRange is used to fill its request section requests.cpu=110m and requests.memory=111Mi
|
||||
- `100m <= 700m <= 800m` , The container cpu limit (700m) falls inside the authorized CPU limit range.
|
||||
- `99Mi <= 900Mi <= 1Gi` , The container memory limit (900Mi) falls inside the authorized Memory limitrange .
|
||||
- No request/limits ratio set , thus the container is valid and created.
|
||||
|
||||
All containers defined in the `busybox` Pod passed LimitRange validations, this the Pod is valid and create in the namespace.
|
||||
|
||||
## Limiting Pod compute resources
|
||||
The following section discusses how to constrain resources at Pod level.
|
||||
|
||||
{{< codenew file="admin/resource/limit-mem-cpu-pod.yaml" >}}
|
||||
|
||||
Without having to delete `busybox1` Pod, create the `limit-mem-cpu-pod` LimitRange in the `limitrange-demo` namespace
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/admin/resource/limit-mem-cpu-pod.yaml -n limitrange-demo
|
||||
```
|
||||
The limitrange is created and limits CPU to 2 Core and Memory to 2Gi per Pod.
|
||||
```shell
|
||||
limitrange/limit-mem-cpu-per-pod created
|
||||
```
|
||||
Describe the `limit-mem-cpu-per-pod` limit object using the following kubectl command
|
||||
```shell
|
||||
kubectl describe limitrange/limit-mem-cpu-per-pod
|
||||
```
|
||||
|
||||
```shell
|
||||
Name: limit-mem-cpu-per-pod
|
||||
Namespace: limitrange-demo
|
||||
Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio
|
||||
---- -------- --- --- --------------- ------------- -----------------------
|
||||
Pod cpu - 2 - - -
|
||||
Pod memory - 2Gi - - -
|
||||
```
|
||||
Now create the `busybox2` Pod.
|
||||
|
||||
{{< codenew file="admin/resource/limit-range-pod-2.yaml" >}}
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/admin/resource/limit-range-pod-2.yaml -n limitrange-demo
|
||||
```
|
||||
The `busybox2` Pod definition is identical to `busybox1` but an error is reported since Pod's resources are now limited
|
||||
```shell
|
||||
Error from server (Forbidden): error when creating "limit-range-pod-2.yaml": pods "busybox2" is forbidden: [maximum cpu usage per Pod is 2, but limit is 2400m., maximum memory usage per Pod is 2Gi, but limit is 2306867200.]
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl get po/busybox1 -n limitrange-demo -o json | jq ".spec.containers[].resources.limits.memory"
|
||||
"200Mi"
|
||||
"900Mi"
|
||||
"200Mi"
|
||||
"900Mi"
|
||||
```
|
||||
`busybox2` Pod will not be admitted on the cluster since the total memory limit of its container is greater than the limit defined in the LimitRange.
|
||||
`busybox1` will not be evicted since it was created and admitted on the cluster before the LimitRange creation.
|
||||
|
||||
|
||||
## Limiting Storage resources
|
||||
|
||||
You can enforce minimum and maximum size of [storage resources](/docs/concepts/storage/persistent-volumes/) that can be requested by each PersistentVolumeClaim in a namespace using a LimitRange.
|
||||
|
||||
{{< codenew file="admin/resource/storagelimits.yaml" >}}
|
||||
|
||||
Apply the YAML using `kubectl create`.
|
||||
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/examples/admin/resource/storagelimits.yaml -n limitrange-demo
|
||||
```
|
||||
|
||||
```shell
|
||||
limitrange/storagelimits created
|
||||
```
|
||||
Describe the created object,
|
||||
|
||||
```shell
|
||||
kubectl describe limits/storagelimits
|
||||
```
|
||||
the output should look like
|
||||
|
||||
```shell
|
||||
Name: storagelimits
|
||||
Namespace: limitrange-demo
|
||||
Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio
|
||||
---- -------- --- --- --------------- ------------- -----------------------
|
||||
PersistentVolumeClaim storage 1Gi 2Gi - - -
|
||||
```
|
||||
|
||||
{{< codenew file="admin/resource/pvc-limit-lower.yaml" >}}
|
||||
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/examples/admin/resource//pvc-limit-lower.yaml -n limitrange-demo
|
||||
```
|
||||
|
||||
While creating a PVC with `requests.storage` lower than the Min value in the LimitRange, an Error thrown by the server
|
||||
|
||||
```shell
|
||||
Error from server (Forbidden): error when creating "pvc-limit-lower.yaml": persistentvolumeclaims "pvc-limit-lower" is forbidden: minimum storage usage per PersistentVolumeClaim is 1Gi, but request is 500Mi.
|
||||
```
|
||||
|
||||
Same behaviour is noted if the `requests.storage` is greater than the Max value in the LimitRange
|
||||
|
||||
{{< codenew file="admin/resource/pvc-limit-greater.yaml" >}}
|
||||
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/examples/admin/resource/pvc-limit-greater.yaml -n limitrange-demo
|
||||
```
|
||||
|
||||
```shell
|
||||
Error from server (Forbidden): error when creating "pvc-limit-greater.yaml": persistentvolumeclaims "pvc-limit-greater" is forbidden: maximum storage usage per PersistentVolumeClaim is 2Gi, but request is 5Gi.
|
||||
```
|
||||
|
||||
## Limits/Requests Ratio
|
||||
|
||||
If `LimitRangeItem.maxLimitRequestRatio` if specified in th `LimitRangeSpec`, the named resource must have a request and limit that are both non-zero where limit divided by request is less than or equal to the enumerated value
|
||||
|
||||
the following `LimitRange` enforces memory limit to be at most twice the amount of the memory request for any pod in the namespace.
|
||||
|
||||
{{< codenew file="admin/resource/limit-memory-ratio-pod.yaml" >}}
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/admin/resource/limit-memory-ratio-pod.yaml
|
||||
```
|
||||
|
||||
Describe the <limit-memory-ratio-pod> LimitRange with the following kubectl command:
|
||||
|
||||
```shell
|
||||
$ kubectl describe limitrange/limit-memory-ratio-pod
|
||||
```
|
||||
|
||||
```shell
|
||||
Name: limit-memory-ratio-pod
|
||||
Namespace: limitrange-demo
|
||||
Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio
|
||||
---- -------- --- --- --------------- ------------- -----------------------
|
||||
Pod memory - - - - 2
|
||||
```
|
||||
|
||||
|
||||
Let's create a pod with `requests.memory=100Mi` and `limits.memory=300Mi`
|
||||
{{< codenew file="admin/resource/limit-range-pod-3.yaml" >}}
|
||||
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/admin/resource/limit-range-pod-3.yaml
|
||||
```
|
||||
|
||||
The pod creation failed as the ratio here (`3`) is greater than the enforced limit (`2`) in `limit-memory-ratio-pod` LimitRange
|
||||
|
||||
|
||||
```shell
|
||||
Error from server (Forbidden): error when creating "limit-range-pod-3.yaml": pods "busybox3" is forbidden: memory max limit to request ratio per Pod is 2, but provided ratio is 3.000000.
|
||||
```
|
||||
|
||||
|
||||
### Clean up
|
||||
Delete the `limitrange-demo` namespace to free all resources
|
||||
```shell
|
||||
kubectl delete ns limitrange-demo
|
||||
```
|
||||
|
||||
|
||||
## Examples
|
||||
|
||||
- See [a tutorial on how to limit compute resources per namespace](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/) .
|
||||
- Check [how to limit storage consumption](/docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage).
|
||||
- See a [detailed example on quota per namespace](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
See [LimitRanger design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) for more information.
|
||||
|
||||
{{% /capture %}}
|
||||
---
|
||||
reviewers:
|
||||
- nelvadas
|
||||
title: Limit Ranges
|
||||
content_template: templates/concept
|
||||
weight: 10
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
By default, containers run with unbounded [compute resources](/docs/user-guide/compute-resources) on a Kubernetes cluster.
|
||||
With Resource quotas, cluster administrators can restrict the resource consumption and creation on a namespace basis.
|
||||
Within a namespace, a Pod or Container can consume as much CPU and memory as defined by the namespace's resource quota. There is a concern that one Pod or Container could monopolize all of the resources. Limit Range is a policy to constrain resource by Pod or Container in a namespace.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
A limit range, defined by a `LimitRange` object, provides constraints that can:
|
||||
|
||||
- Enforce minimum and maximum compute resources usage per Pod or Container in a namespace.
|
||||
- Enforce minimum and maximum storage request per PersistentVolumeClaim in a namespace.
|
||||
- Enforce a ratio between request and limit for a resource in a namespace.
|
||||
- Set default request/limit for compute resources in a namespace and automatically inject them to Containers at runtime.
|
||||
|
||||
## Enabling Limit Range
|
||||
|
||||
Limit Range support is enabled by default for many Kubernetes distributions. It is
|
||||
enabled when the apiserver `--enable-admission-plugins=` flag has `LimitRanger` admission controller as
|
||||
one of its arguments.
|
||||
|
||||
A limit range is enforced in a particular namespace when there is a
|
||||
`LimitRange` object in that namespace.
|
||||
|
||||
### Overview of Limit Range:
|
||||
|
||||
- The administrator creates one `LimitRange` in one namespace.
|
||||
- Users create resources like Pods, Containers, and PersistentVolumeClaims in the namespace.
|
||||
- The `LimitRanger` admission controller enforces defaults limits for all Pods and Container that do not set compute resource requirements and tracks usage to ensure it does not exceed resource minimum , maximum and ratio defined in any `LimitRange` present in the namespace.
|
||||
- If creating or updating a resource (Pod, Container, PersistentVolumeClaim) violates a limit range constraint, the request to the API server will fail with HTTP status code `403 FORBIDDEN` and a message explaining the constraint that would have been violated.
|
||||
- If limit range is activated in a namespace for compute resources like `cpu` and `memory`, users must specify
|
||||
requests or limits for those values; otherwise, the system may reject pod creation.
|
||||
- LimitRange validations occurs only at Pod Admission stage, not on Running pods.
|
||||
|
||||
|
||||
Examples of policies that could be created using limit range are:
|
||||
|
||||
- In a 2 node cluster with a capacity of 8 GiB RAM, and 16 cores, constrain Pods in a namespace to request 100m and not exceeds 500m for CPU , request 200Mi and not exceed 600Mi
|
||||
- Define default CPU limits and request to 150m and Memory default request to 300Mi for containers started with no cpu and memory requests in their spec.
|
||||
|
||||
In the case where the total limits of the namespace is less than the sum of the limits of the Pods/Containers,
|
||||
there may be contention for resources; The Containers or Pods will not be created.
|
||||
|
||||
Neither contention nor changes to limitrange will affect already created resources.
|
||||
|
||||
## Limiting Container compute resources
|
||||
|
||||
The following section discusses the creation of a LimitRange acting at Container Level.
|
||||
A Pod with 04 containers is first created; each container within the Pod has a specific `spec.resource` configuration
|
||||
each containerwithin the pod is handled differently by the LimitRanger admission controller.
|
||||
|
||||
Create a namespace `limitrange-demo` using the following kubectl command
|
||||
|
||||
```shell
|
||||
kubectl create namespace limitrange-demo
|
||||
```
|
||||
|
||||
To avoid passing the target limitrange-demo in your kubectl commands, change your context with the following command
|
||||
|
||||
```shell
|
||||
kubectl config set-context --current --namespace=limitrange-demo
|
||||
```
|
||||
|
||||
Here is the configuration file for a LimitRange object:
|
||||
{{< codenew file="admin/resource/limit-mem-cpu-container.yaml" >}}
|
||||
|
||||
This object defines minimum and maximum Memory/CPU limits, default cpu/Memory requests and default limits for CPU/Memory resources to be apply to containers.
|
||||
|
||||
Create the `limit-mem-cpu-per-container` LimitRange in the `limitrange-demo` namespace with the following kubectl command.
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/examples/admin/resource/limit-mem-cpu-container.yaml -n limitrange-demo
|
||||
```
|
||||
|
||||
|
||||
```shell
|
||||
kubectl describe limitrange/limit-mem-cpu-per-container -n limitrange-demo
|
||||
```
|
||||
|
||||
|
||||
```shell
|
||||
Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio
|
||||
---- -------- --- --- --------------- ------------- -----------------------
|
||||
Container cpu 100m 800m 110m 700m -
|
||||
Container memory 99Mi 1Gi 111Mi 900Mi -
|
||||
```
|
||||
|
||||
|
||||
|
||||
Here is the configuration file for a Pod with 04 containers to demonstrate LimitRange features :
|
||||
{{< codenew file="admin/resource/limit-range-pod-1.yaml" >}}
|
||||
|
||||
Create the `busybox1` Pod :
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/admin/resource/limit-range-pod-1.yaml -n limitrange-demo
|
||||
```
|
||||
|
||||
### Container spec with valid CPU/Memory requests and limits
|
||||
View the the `busybox-cnt01` resource configuration
|
||||
|
||||
```shell
|
||||
kubectl get po/busybox1 -n limitrange-demo -o json | jq ".spec.containers[0].resources"
|
||||
```
|
||||
|
||||
```json
|
||||
{
|
||||
"limits": {
|
||||
"cpu": "500m",
|
||||
"memory": "200Mi"
|
||||
},
|
||||
"requests": {
|
||||
"cpu": "100m",
|
||||
"memory": "100Mi"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
- The `busybox-cnt01` Container inside `busybox` Pod defined `requests.cpu=100m` and `requests.memory=100Mi`.
|
||||
- `100m <= 500m <= 800m` , The container cpu limit (500m) falls inside the authorized CPU limit range.
|
||||
- `99Mi <= 200Mi <= 1Gi` , The container memory limit (200Mi) falls inside the authorized Memory limit range.
|
||||
- No request/limits ratio validation for CPU/Memory , thus the container is valid and created.
|
||||
|
||||
|
||||
### Container spec with a valid CPU/Memory requests but no limits
|
||||
|
||||
View the `busybox-cnt02` resource configuration
|
||||
|
||||
```shell
|
||||
kubectl get po/busybox1 -n limitrange-demo -o json | jq ".spec.containers[1].resources"
|
||||
```
|
||||
|
||||
```json
|
||||
{
|
||||
"limits": {
|
||||
"cpu": "700m",
|
||||
"memory": "900Mi"
|
||||
},
|
||||
"requests": {
|
||||
"cpu": "100m",
|
||||
"memory": "100Mi"
|
||||
}
|
||||
}
|
||||
```
|
||||
- The `busybox-cnt02` Container inside `busybox1` Pod defined `requests.cpu=100m` and `requests.memory=100Mi` but not limits for cpu and memory.
|
||||
- The container do not have a limits section, the default limits defined in the limit-mem-cpu-per-container LimitRange object are injected to this container `limits.cpu=700mi` and `limits.memory=900Mi`.
|
||||
- `100m <= 700m <= 800m` , The container cpu limit (700m) falls inside the authorized CPU limit range.
|
||||
- `99Mi <= 900Mi <= 1Gi` , The container memory limit (900Mi) falls inside the authorized Memory limit range.
|
||||
- No request/limits ratio set , thus the container is valid and created.
|
||||
|
||||
|
||||
### Container spec with a valid CPU/Memory limits but no requests
|
||||
View the `busybox-cnt03` resource configuration
|
||||
|
||||
```shell
|
||||
kubectl get po/busybox1 -n limitrange-demo -o json | jq ".spec.containers[2].resources"
|
||||
```
|
||||
```json
|
||||
{
|
||||
"limits": {
|
||||
"cpu": "500m",
|
||||
"memory": "200Mi"
|
||||
},
|
||||
"requests": {
|
||||
"cpu": "500m",
|
||||
"memory": "200Mi"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
- The `busybox-cnt03` Container inside `busybox1` Pod defined `limits.cpu=500m` and `limits.memory=200Mi` but no `requests` for cpu and memory.
|
||||
- The container do not define a request section, the defaultRequest defined in the limit-mem-cpu-per-container LimitRange is not used to fill its limits section but the limits defined by the container are set as requests `limits.cpu=500m` and `limits.memory=200Mi`.
|
||||
- `100m <= 500m <= 800m` , The container cpu limit (500m) falls inside the authorized CPU limit range.
|
||||
- `99Mi <= 200Mi <= 1Gi` , The container memory limit (200Mi) falls inside the authorized Memory limit range.
|
||||
- No request/limits ratio set , thus the container is valid and created.
|
||||
|
||||
|
||||
|
||||
### Container spec with no CPU/Memory requests/limits
|
||||
View the `busybox-cnt04` resource configuration
|
||||
```shell
|
||||
kubectl get po/busybox1 -n limitrange-demo -o json | jq ".spec.containers[3].resources"
|
||||
```
|
||||
```json
|
||||
{
|
||||
"limits": {
|
||||
"cpu": "700m",
|
||||
"memory": "900Mi"
|
||||
},
|
||||
"requests": {
|
||||
"cpu": "110m",
|
||||
"memory": "111Mi"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
- The `busybox-cnt04` Container inside `busybox1` define neither `limits` nor `requests`.
|
||||
- The container do not define a limit section, the default limit defined in the limit-mem-cpu-per-container LimitRange is used to fill its request
|
||||
`limits.cpu=700m and` `limits.memory=900Mi` .
|
||||
- The container do not define a request section, the defaultRequest defined in the limit-mem-cpu-per-container LimitRange is used to fill its request section requests.cpu=110m and requests.memory=111Mi
|
||||
- `100m <= 700m <= 800m` , The container cpu limit (700m) falls inside the authorized CPU limit range.
|
||||
- `99Mi <= 900Mi <= 1Gi` , The container memory limit (900Mi) falls inside the authorized Memory limitrange .
|
||||
- No request/limits ratio set , thus the container is valid and created.
|
||||
|
||||
All containers defined in the `busybox` Pod passed LimitRange validations, this the Pod is valid and create in the namespace.
|
||||
|
||||
## Limiting Pod compute resources
|
||||
The following section discusses how to constrain resources at Pod level.
|
||||
|
||||
{{< codenew file="admin/resource/limit-mem-cpu-pod.yaml" >}}
|
||||
|
||||
Without having to delete `busybox1` Pod, create the `limit-mem-cpu-pod` LimitRange in the `limitrange-demo` namespace
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/admin/resource/limit-mem-cpu-pod.yaml -n limitrange-demo
|
||||
```
|
||||
The limitrange is created and limits CPU to 2 Core and Memory to 2Gi per Pod.
|
||||
```shell
|
||||
limitrange/limit-mem-cpu-per-pod created
|
||||
```
|
||||
Describe the `limit-mem-cpu-per-pod` limit object using the following kubectl command
|
||||
```shell
|
||||
kubectl describe limitrange/limit-mem-cpu-per-pod
|
||||
```
|
||||
|
||||
```shell
|
||||
Name: limit-mem-cpu-per-pod
|
||||
Namespace: limitrange-demo
|
||||
Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio
|
||||
---- -------- --- --- --------------- ------------- -----------------------
|
||||
Pod cpu - 2 - - -
|
||||
Pod memory - 2Gi - - -
|
||||
```
|
||||
Now create the `busybox2` Pod.
|
||||
|
||||
{{< codenew file="admin/resource/limit-range-pod-2.yaml" >}}
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/admin/resource/limit-range-pod-2.yaml -n limitrange-demo
|
||||
```
|
||||
The `busybox2` Pod definition is identical to `busybox1` but an error is reported since Pod's resources are now limited
|
||||
```shell
|
||||
Error from server (Forbidden): error when creating "limit-range-pod-2.yaml": pods "busybox2" is forbidden: [maximum cpu usage per Pod is 2, but limit is 2400m., maximum memory usage per Pod is 2Gi, but limit is 2306867200.]
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl get po/busybox1 -n limitrange-demo -o json | jq ".spec.containers[].resources.limits.memory"
|
||||
"200Mi"
|
||||
"900Mi"
|
||||
"200Mi"
|
||||
"900Mi"
|
||||
```
|
||||
`busybox2` Pod will not be admitted on the cluster since the total memory limit of its container is greater than the limit defined in the LimitRange.
|
||||
`busybox1` will not be evicted since it was created and admitted on the cluster before the LimitRange creation.
|
||||
|
||||
|
||||
## Limiting Storage resources
|
||||
|
||||
You can enforce minimum and maximum size of [storage resources](/docs/concepts/storage/persistent-volumes/) that can be requested by each PersistentVolumeClaim in a namespace using a LimitRange.
|
||||
|
||||
{{< codenew file="admin/resource/storagelimits.yaml" >}}
|
||||
|
||||
Apply the YAML using `kubectl create`.
|
||||
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/examples/admin/resource/storagelimits.yaml -n limitrange-demo
|
||||
```
|
||||
|
||||
```shell
|
||||
limitrange/storagelimits created
|
||||
```
|
||||
Describe the created object,
|
||||
|
||||
```shell
|
||||
kubectl describe limits/storagelimits
|
||||
```
|
||||
the output should look like
|
||||
|
||||
```shell
|
||||
Name: storagelimits
|
||||
Namespace: limitrange-demo
|
||||
Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio
|
||||
---- -------- --- --- --------------- ------------- -----------------------
|
||||
PersistentVolumeClaim storage 1Gi 2Gi - - -
|
||||
```
|
||||
|
||||
{{< codenew file="admin/resource/pvc-limit-lower.yaml" >}}
|
||||
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/examples/admin/resource//pvc-limit-lower.yaml -n limitrange-demo
|
||||
```
|
||||
|
||||
While creating a PVC with `requests.storage` lower than the Min value in the LimitRange, an Error thrown by the server
|
||||
|
||||
```shell
|
||||
Error from server (Forbidden): error when creating "pvc-limit-lower.yaml": persistentvolumeclaims "pvc-limit-lower" is forbidden: minimum storage usage per PersistentVolumeClaim is 1Gi, but request is 500Mi.
|
||||
```
|
||||
|
||||
Same behaviour is noted if the `requests.storage` is greater than the Max value in the LimitRange
|
||||
|
||||
{{< codenew file="admin/resource/pvc-limit-greater.yaml" >}}
|
||||
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/examples/admin/resource/pvc-limit-greater.yaml -n limitrange-demo
|
||||
```
|
||||
|
||||
```shell
|
||||
Error from server (Forbidden): error when creating "pvc-limit-greater.yaml": persistentvolumeclaims "pvc-limit-greater" is forbidden: maximum storage usage per PersistentVolumeClaim is 2Gi, but request is 5Gi.
|
||||
```
|
||||
|
||||
## Limits/Requests Ratio
|
||||
|
||||
If `LimitRangeItem.maxLimitRequestRatio` if specified in th `LimitRangeSpec`, the named resource must have a request and limit that are both non-zero where limit divided by request is less than or equal to the enumerated value
|
||||
|
||||
the following `LimitRange` enforces memory limit to be at most twice the amount of the memory request for any pod in the namespace.
|
||||
|
||||
{{< codenew file="admin/resource/limit-memory-ratio-pod.yaml" >}}
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/admin/resource/limit-memory-ratio-pod.yaml
|
||||
```
|
||||
|
||||
Describe the <limit-memory-ratio-pod> LimitRange with the following kubectl command:
|
||||
|
||||
```shell
|
||||
$ kubectl describe limitrange/limit-memory-ratio-pod
|
||||
```
|
||||
|
||||
```shell
|
||||
Name: limit-memory-ratio-pod
|
||||
Namespace: limitrange-demo
|
||||
Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio
|
||||
---- -------- --- --- --------------- ------------- -----------------------
|
||||
Pod memory - - - - 2
|
||||
```
|
||||
|
||||
|
||||
Let's create a pod with `requests.memory=100Mi` and `limits.memory=300Mi`
|
||||
{{< codenew file="admin/resource/limit-range-pod-3.yaml" >}}
|
||||
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/admin/resource/limit-range-pod-3.yaml
|
||||
```
|
||||
|
||||
The pod creation failed as the ratio here (`3`) is greater than the enforced limit (`2`) in `limit-memory-ratio-pod` LimitRange
|
||||
|
||||
|
||||
```shell
|
||||
Error from server (Forbidden): error when creating "limit-range-pod-3.yaml": pods "busybox3" is forbidden: memory max limit to request ratio per Pod is 2, but provided ratio is 3.000000.
|
||||
```
|
||||
|
||||
|
||||
### Clean up
|
||||
Delete the `limitrange-demo` namespace to free all resources
|
||||
```shell
|
||||
kubectl delete ns limitrange-demo
|
||||
```
|
||||
|
||||
|
||||
## Examples
|
||||
|
||||
- See [a tutorial on how to limit compute resources per namespace](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/) .
|
||||
- Check [how to limit storage consumption](/docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage).
|
||||
- See a [detailed example on quota per namespace](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
See [LimitRanger design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) for more information.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -268,7 +268,7 @@ Expanding EBS volumes is a time consuming operation. Also, there is a per-volume
|
||||
* AzureDisk
|
||||
* CSI
|
||||
* FC (Fibre Channel)
|
||||
* Flexvolume
|
||||
* FlexVolume
|
||||
* Flocker
|
||||
* NFS
|
||||
* iSCSI
|
||||
|
||||
@@ -53,6 +53,7 @@ provisioner: kubernetes.io/aws-ebs
|
||||
parameters:
|
||||
type: gp2
|
||||
reclaimPolicy: Retain
|
||||
allowVolumeExpansion: true
|
||||
mountOptions:
|
||||
- debug
|
||||
volumeBindingMode: Immediate
|
||||
@@ -110,6 +111,31 @@ either `Delete` or `Retain`. If no `reclaimPolicy` is specified when a
|
||||
Persistent Volumes that are created manually and managed via a storage class will have
|
||||
whatever reclaim policy they were assigned at creation.
|
||||
|
||||
### Allow Volume Expansion
|
||||
|
||||
{{< feature-state for_k8s_version="v1.11" state="beta" >}}
|
||||
|
||||
Persistent Volumes can be configured to be expandable. This feature when set to `true`,
|
||||
allows the users to resize the volume by editing the corresponding PVC object.
|
||||
|
||||
The following types of volumes support volume expansion, when the underlying
|
||||
Storage Class has the field `allowVolumeExpansion` set to true.
|
||||
|
||||
* gcePersistentDisk
|
||||
* awsElasticBlockStore
|
||||
* Cinder
|
||||
* glusterfs
|
||||
* rbd
|
||||
* Azure File
|
||||
* Azure Disk
|
||||
* Portworx
|
||||
* FlexVolumes
|
||||
* CSI {{< feature-state for_k8s_version="v1.14" state="alpha" >}}
|
||||
|
||||
{{< note >}}
|
||||
This feature cannot be used to shrink volumes.
|
||||
{{< /note >}}
|
||||
|
||||
### Mount Options
|
||||
|
||||
Persistent Volumes that are dynamically created by a storage class will have the
|
||||
|
||||
@@ -62,7 +62,8 @@ yourself, but the project is better in the long term when we have a diversity of
|
||||
active participants.
|
||||
|
||||
Before you start reviewing PRs, make sure you are familiar with the
|
||||
[Documentation Style Guide](/docs/contribute/style/style-guide/)
|
||||
[Documentation Content Guide](/docs/contribute/style/content-guide/), the
|
||||
[Documentation Style Guide](/docs/contribute/style/style-guide/),
|
||||
and the [code of conduct](/community/code-of-conduct/).
|
||||
|
||||
### Find a PR to review
|
||||
|
||||
@@ -44,6 +44,15 @@ called SIG Docs. We [communicate](#participate-in-sig-docs-discussions) using a
|
||||
weekly video meetings. New participants are welcome. For more information, see
|
||||
[Participating in SIG Docs](/docs/contribute/participating/).
|
||||
|
||||
### Content guildelines
|
||||
|
||||
The SIG Docs community created guidelines about what kind of content is allowed
|
||||
in the Kubernetes documentation. Look over the [Documentation Content
|
||||
Guide](/docs/contribute/style/content-guide/) to determine if the content
|
||||
contribution you want to make is allowed. You can ask questions about allowed
|
||||
content in the [#sig-docs]((#participate-in-sig-docs-discussions)) Slack
|
||||
channel.
|
||||
|
||||
### Style guidelines
|
||||
|
||||
We maintain a [style guide](/docs/contribute/style/style-guide/) with information
|
||||
@@ -330,7 +339,7 @@ commercial in nature and should consist of content that will apply broadly to
|
||||
the Kubernetes community.
|
||||
|
||||
To submit a blog post, you can either submit it using the
|
||||
[Kubernetes blog submission form](https://docs.google.com/forms/d/e/1FAIpQLSch_phFYMTYlrTDuYziURP6nLMijoXx_f7sLABEU5gWBtxJHQ/viewform),
|
||||
[Kubernetes blog submission form](https://docs.google.com/forms/d/e/1FAIpQLSdMpMoSIrhte5omZbTE7nB84qcGBy8XnnXhDFoW0h7p2zwXrw/viewform),
|
||||
or follow the steps below.
|
||||
|
||||
1. [Sign the CLA](#sign-the-cla) if you have not yet done so.
|
||||
|
||||
@@ -0,0 +1,116 @@
|
||||
---
|
||||
title: Documentation Content Guide
|
||||
linktitle: Content guide
|
||||
content_template: templates/concept
|
||||
weight: 10
|
||||
card:
|
||||
name: contribute
|
||||
weight: 20
|
||||
title: Documentation Content Guide
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
This page contains guidelines for adding content to the Kubernetes documentation.
|
||||
If you have questions about allowed content, join the [Kubernetes Slack](http://slack.k8s.io/) #sig-docs channel and ask! Use your best judgment, and feel free to
|
||||
propose changes to this document in a pull request.
|
||||
|
||||
For additional information on creating new content for the Kubernetes
|
||||
docs, follow the instructions in the [Style guide](/docs/contribute/style/style-guide).
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
## Contributing content
|
||||
|
||||
The Kubernetes documentation comprises the content of the
|
||||
[kubernetes/website](https://github.com/kubernetes/website) source repository.
|
||||
Located in the `kubernetes/website/content/<language_code>/docs` folder, the
|
||||
majority of the Kubernetes documentation is specific to the [Kubernetes
|
||||
project](https://github.com/kubernetes/kubernetes). The Kubernetes
|
||||
documentation may also include content from projects in the
|
||||
[kubernetes](https://github.com/kubernetes) and
|
||||
[kubernetes-sigs](https://github.com/kubernetes-sigs) GitHub organizations if
|
||||
those projects do not have their own documentation. Linking to active kubernetes,
|
||||
kubernetes-sigs, and ({{< glossary_tooltip text="CNCF" term_id="cncf" >}}) projects from the Kubernetes documentation is always
|
||||
allowed, but linking to vendor-specific products is not. Check the CNCF project lists
|
||||
([Graduated/Incubating](https://www.cncf.io/projects/),
|
||||
[Sandbox](https://www.cncf.io/sandbox-projects/),
|
||||
[Archived](https://www.cncf.io/archived-projects/)) if you are unsure of a
|
||||
project's CNCF status.
|
||||
|
||||
### Dual-sourced content
|
||||
|
||||
Kubernetes documentation does not include duplicate content sourced from multiple
|
||||
locations (*dual-sourced* content). Dual-sourced content requires duplicated
|
||||
effort from project maintainers and tends to become outdated more quickly.
|
||||
Before adding content, ask yourself this:
|
||||
|
||||
- Is the content about an active CNCF project OR a project in the kubernetes or kubernetes-sigs GitHub organizations?
|
||||
- If yes, then:
|
||||
- Does the project have its own documentation?
|
||||
- if yes, link to the project's documention from the Kubernetes documentation
|
||||
- if no, add the content to the project's repository if possible and then link to it from the Kubernetes documentation
|
||||
- If no, then:
|
||||
- Stop!
|
||||
- Adding content about vendor-specific products is not allowed
|
||||
- Linking to vendor-specific documentation and websites is not allowed
|
||||
|
||||
### What is and isn't allowed
|
||||
|
||||
There are some scenarios in which the Kubernetes documentation includes content from non-Kubernetes projects.
|
||||
Below are general categories of non-Kubernetes project content along with guidelines of what is and is not allowed:
|
||||
|
||||
1. Instructional content involving non-Kubernetes projects during setup or operation of Kubernetes
|
||||
- Allowed:
|
||||
- Referring to or linking to existing documentation about a CNCF project or a project in the kubernetes or kubernetes-sigs GitHub organizations
|
||||
- Example: for installating Kubernetes in a learning environment, including a prerequisite stating that successful installation and configuration of minikube is required and linking to the relevant minikube documentation
|
||||
- Adding content for kubernetes or kubernetes-sigs projects that don't have their own instructional content
|
||||
- Example: including [kubadm](https://github.com/kubernetes/kubeadm) installation and troubleshooting instructions
|
||||
- Not Allowed:
|
||||
- Adding content that duplicates documentation in another repository
|
||||
- Examples:
|
||||
- Including minikube installation and configuration instructions; minikube has its own [documentation](https://minikube.sigs.k8s.io/docs/) that provides those instructions
|
||||
- Including instructions for installing Docker, CRI-O, containerd, and other container runtimes on various operating systems
|
||||
- Including instructions for installing Kubernetes on production environments using various projects:
|
||||
- Kubernetes Rebar Integrated Bootstrap (KRIB) is a vendor-specific project and content belongs in the vendor's documentation
|
||||
- [Kubernetes Operations (kops)](https://github.com/kubernetes/kops) has installation instructions and tutorials in its GitHub repository
|
||||
- [Kubespray](https://kubespray.io) has its own documenation
|
||||
- Adding a tutorial that explains how to perform a task using a vendor-specific product or an open source project that is not a CNCF project or a project in the kubernetes or kubnetes-sigs GitHub organizations
|
||||
- Adding a tutorial on how to use a CNCF project or a project in the kubernetes or kubnetes-sigs GitHub organizations if the project has its own documentation
|
||||
1. Detailed technical content about how to use a non-Kubernetes project or how that project is designed
|
||||
|
||||
Adding this type of content to the Kubernetes documentation is not allowed.
|
||||
1. Content that describes a non-Kubernetes project
|
||||
- Allowed:
|
||||
- Adding a brief introductory paragraph about a CNCF project or a project in the kubernetes or kubernetes-sigs GitHub organizations; the paragraph may contain links to the project
|
||||
- Not Allowed:
|
||||
- Adding content describing a vendor-specific product
|
||||
- Adding content describing an open source project that is not a CNCF project or a project in the kubernetes or kubnetes-sigs GitHub organizations
|
||||
- Adding content that duplicates documentation from another project, regardless of source repository
|
||||
- Example: adding [Kubernetes in Docker (KinD)](https://kind.sigs.k8s.io) documentation to the Kubernetes documentation
|
||||
1. Content that simply links to information about a non-Kubernetes project
|
||||
- Allowed:
|
||||
- Linking to projects in the kubernetes and kubernetes-sigs GitHub organizations
|
||||
- Example: linking to Kubernetes in Docker (KinD) [documentation](https://kind.sigs.k8s.io/docs/user/quick-start), which resides in the kubernetes-sigs GitHub organization
|
||||
- Linking to active CNCF projects
|
||||
- Example: linking to the Prometheus [documentation](https://prometheus.io/docs/introduction/overview/); Prometheus is an active CNCF project
|
||||
- Not Allowed:
|
||||
- Linking to vendor-specific products
|
||||
- Linking to archived CNCF projects
|
||||
- Linking to inactive projects in the kubernetes and kubernetes-sigs GitHub organizations
|
||||
- Linking to open source projects that are not CNCF projects or do not reside in the kubernetes or kubernetes-sigs GitHub organizations
|
||||
1. Content about training courses
|
||||
- Allowed:
|
||||
- Linking to vendor-neutral Kubernetes training courses offered by the [CNCF](https://www.cncf.io/), the [Linux Foundation](https://www.linuxfoundation.org/), and the [Linux Academy](https://linuxacademy.com/), which is a partner of the Linux Foundation
|
||||
- Example: linking to Linux Academy courses such as [Kubernetes Quick Start](https://linuxacademy.com/course/kubernetes-quick-start/) and [Kubernetes Security](https://linuxacademy.com/course/kubernetes-security/)
|
||||
- Not Allowed:
|
||||
- Linking to online training outside of the CNCF, the Linux Foundation, or the Linux Academy; the Kubernetes documentation does not link to third-party content
|
||||
- Example: linking to Kubernetes tutorials or courses on Medium, KodeKloud, Udacity, Coursera, learnk8s, and similar websites
|
||||
- Linking to vendor-specific tutorials regardless of the training provider
|
||||
- Example: linking to Linux Academy courses such as [Google Kubernetes Engine Deep Dive](https://linuxacademy.com/google-cloud-platform/training/course/name/google-kubernetes-engine-deep-dive) and [Amazon EKS Deep Dive](https://linuxacademy.com/course/amazon-eks-deep-dive/)
|
||||
|
||||
If you have questions about allowed content, join the [Kubernetes Slack](http://slack.k8s.io/) #sig-docs channel and ask!
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
* Read the [Style guide](/docs/contribute/style/style-guide).
|
||||
{{% /capture %}}
|
||||
@@ -14,10 +14,12 @@ This page gives writing style guidelines for the Kubernetes documentation.
|
||||
These are guidelines, not rules. Use your best judgment, and feel free to
|
||||
propose changes to this document in a pull request.
|
||||
|
||||
For additional information on creating new content for the Kubernetes
|
||||
docs, follow the instructions on
|
||||
[using page templates](/docs/contribute/style/page-templates/) and
|
||||
[creating a documentation pull request](/docs/contribute/start/#improve-existing-content).
|
||||
For additional information on creating new content for the Kubernetes
|
||||
documentation, read the [Documentation Content
|
||||
Guide](/docs/contribute/style/content-guide/) and follow the instructions on
|
||||
[using page templates](/docs/contribute/style/page-templates/) and [creating a
|
||||
documentation pull request](/docs/contribute/start/#improve-existing-content).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
@@ -1,5 +0,0 @@
|
||||
# See the OWNERS docs at https://go.k8s.io/owners
|
||||
|
||||
reviewers:
|
||||
- errordeveloper
|
||||
|
||||
@@ -1,5 +0,0 @@
|
||||
---
|
||||
title: "Independent Solutions"
|
||||
weight: 50
|
||||
---
|
||||
|
||||
@@ -1,10 +0,0 @@
|
||||
---
|
||||
reviewers:
|
||||
- pwittrock
|
||||
title: Deprecated Alternatives
|
||||
---
|
||||
|
||||
# *Stop. These guides are superseded by [Minikube](../minikube/). They are only listed here for completeness.*
|
||||
|
||||
* [Using Vagrant](https://git.k8s.io/community/contributors/devel/vagrant.md)
|
||||
* *Advanced:* [Directly using Kubernetes raw binaries (Linux Only)](https://git.k8s.io/community/contributors/devel/running-locally.md)
|
||||
@@ -1,7 +0,0 @@
|
||||
# See the OWNERS docs at https://go.k8s.io/owners
|
||||
|
||||
reviewers:
|
||||
- aveshagarwal
|
||||
- eparis
|
||||
- thockin
|
||||
|
||||
@@ -1,5 +0,0 @@
|
||||
---
|
||||
title: "Bare Metal"
|
||||
weight: 60
|
||||
---
|
||||
|
||||
@@ -1,177 +0,0 @@
|
||||
---
|
||||
reviewers:
|
||||
- aveshagarwal
|
||||
- eparis
|
||||
- thockin
|
||||
title: Fedora (Single Node)
|
||||
---
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
## Prerequisites
|
||||
|
||||
1. You need 2 or more machines with Fedora installed. These can be either bare metal machines or virtual machines.
|
||||
|
||||
## Instructions
|
||||
|
||||
This is a getting started guide for Fedora. It is a manual configuration so you understand all the underlying packages / services / ports, etc...
|
||||
|
||||
This guide will only get ONE node (previously minion) working. Multiple nodes require a functional [networking configuration](/docs/concepts/cluster-administration/networking/) done outside of Kubernetes. Although the additional Kubernetes configuration requirements should be obvious.
|
||||
|
||||
The Kubernetes package provides a few services: kube-apiserver, kube-scheduler, kube-controller-manager, kubelet, kube-proxy. These services are managed by systemd and the configuration resides in a central location: `/etc/kubernetes`. We will break the services up between the hosts. The first host, fed-master, will be the Kubernetes master. This host will run the kube-apiserver, kube-controller-manager, and kube-scheduler. In addition, the master will also run _etcd_ (not needed if _etcd_ runs on a different host but this guide assumes that _etcd_ and Kubernetes master run on the same host). The remaining host, fed-node will be the node and run kubelet, proxy and docker.
|
||||
|
||||
**System Information:**
|
||||
|
||||
Hosts:
|
||||
|
||||
```conf
|
||||
fed-master = 192.168.121.9
|
||||
fed-node = 192.168.121.65
|
||||
```
|
||||
|
||||
**Prepare the hosts:**
|
||||
|
||||
* Install Kubernetes on all hosts - fed-{master,node}. This will also pull in docker. Also install etcd on fed-master. This guide has been tested with Kubernetes-0.18 and beyond.
|
||||
* Running on AWS EC2 with RHEL 7.2, you need to enable "extras" repository for yum by editing `/etc/yum.repos.d/redhat-rhui.repo` and changing the `enable=0` to `enable=1` for extras.
|
||||
|
||||
```shell
|
||||
dnf -y install kubernetes
|
||||
```
|
||||
|
||||
* Install etcd
|
||||
|
||||
```shell
|
||||
dnf -y install etcd
|
||||
```
|
||||
|
||||
* Add master and node to `/etc/hosts` on all machines (not needed if hostnames already in DNS). Make sure that communication works between fed-master and fed-node by using a utility such as ping.
|
||||
|
||||
```shell
|
||||
echo "192.168.121.9 fed-master
|
||||
192.168.121.65 fed-node" >> /etc/hosts
|
||||
```
|
||||
|
||||
* Edit `/etc/kubernetes/config` (which should be the same on all hosts) to set
|
||||
the name of the master server:
|
||||
|
||||
```shell
|
||||
# Comma separated list of nodes in the etcd cluster
|
||||
KUBE_MASTER="--master=http://fed-master:8080"
|
||||
```
|
||||
|
||||
* Disable the firewall on both the master and node, as Docker does not play well with other firewall rule managers. Please note that iptables.service does not exist on the default Fedora Server install.
|
||||
|
||||
```shell
|
||||
systemctl mask firewalld.service
|
||||
systemctl stop firewalld.service
|
||||
|
||||
systemctl disable --now iptables.service
|
||||
```
|
||||
|
||||
**Configure the Kubernetes services on the master.**
|
||||
|
||||
* Edit `/etc/kubernetes/apiserver` to appear as such. The service-cluster-ip-range IP addresses must be an unused block of addresses, not used anywhere else. They do not need to be routed or assigned to anything.
|
||||
|
||||
```shell
|
||||
# The address on the local server to listen to.
|
||||
KUBE_API_ADDRESS="--address=0.0.0.0"
|
||||
|
||||
# Comma separated list of nodes in the etcd cluster
|
||||
KUBE_ETCD_SERVERS="--etcd-servers=http://127.0.0.1:2379"
|
||||
|
||||
# Address range to use for services
|
||||
KUBE_SERVICE_ADDRESSES="--service-cluster-ip-range=10.254.0.0/16"
|
||||
|
||||
# Add your own!
|
||||
KUBE_API_ARGS=""
|
||||
```
|
||||
|
||||
* Edit `/etc/etcd/etcd.conf` to let etcd listen on all available IPs instead of 127.0.0.1. If you have not done this, you might see an error such as "connection refused".
|
||||
|
||||
```shell
|
||||
ETCD_LISTEN_CLIENT_URLS="http://0.0.0.0:2379"
|
||||
```
|
||||
|
||||
* Start the appropriate services on master:
|
||||
|
||||
```shell
|
||||
for SERVICES in etcd kube-apiserver kube-controller-manager kube-scheduler; do
|
||||
systemctl enable --now $SERVICES
|
||||
systemctl status $SERVICES
|
||||
done
|
||||
```
|
||||
|
||||
**Configure the Kubernetes services on the node.**
|
||||
|
||||
***We need to configure the kubelet on the node.***
|
||||
|
||||
* Edit `/etc/kubernetes/kubelet` to appear as such:
|
||||
|
||||
```shell
|
||||
###
|
||||
# Kubernetes kubelet (node) config
|
||||
|
||||
# The address for the info server to serve on (set to 0.0.0.0 or "" for all interfaces)
|
||||
KUBELET_ADDRESS="--address=0.0.0.0"
|
||||
|
||||
# You may leave this blank to use the actual hostname
|
||||
KUBELET_HOSTNAME="--hostname-override=fed-node"
|
||||
|
||||
# location of the api-server
|
||||
KUBELET_ARGS="--cgroup-driver=systemd --kubeconfig=/etc/kubernetes/master-kubeconfig.yaml"
|
||||
|
||||
```
|
||||
|
||||
* Edit `/etc/kubernetes/master-kubeconfig.yaml` to contain the following information:
|
||||
|
||||
```yaml
|
||||
kind: Config
|
||||
clusters:
|
||||
- name: local
|
||||
cluster:
|
||||
server: http://fed-master:8080
|
||||
users:
|
||||
- name: kubelet
|
||||
contexts:
|
||||
- context:
|
||||
cluster: local
|
||||
user: kubelet
|
||||
name: kubelet-context
|
||||
current-context: kubelet-context
|
||||
```
|
||||
|
||||
* Start the appropriate services on the node (fed-node).
|
||||
|
||||
```shell
|
||||
for SERVICES in kube-proxy kubelet docker; do
|
||||
systemctl enable --now $SERVICES
|
||||
systemctl status $SERVICES
|
||||
done
|
||||
```
|
||||
|
||||
* Check to make sure now the cluster can see the fed-node on fed-master, and its status changes to _Ready_.
|
||||
|
||||
```shell
|
||||
kubectl get nodes
|
||||
NAME STATUS AGE VERSION
|
||||
fed-node Ready 4h
|
||||
```
|
||||
|
||||
* Deletion of nodes:
|
||||
|
||||
To delete _fed-node_ from your Kubernetes cluster, one should run the following on fed-master (Please do not do it, it is just for information):
|
||||
|
||||
```shell
|
||||
kubectl delete -f ./node.json
|
||||
```
|
||||
|
||||
*You should be finished!*
|
||||
|
||||
**The cluster should be running! Launch a test pod.**
|
||||
|
||||
## Support Level
|
||||
|
||||
|
||||
IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level
|
||||
-------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ----------------------------
|
||||
Bare-metal | custom | Fedora | _none_ | [docs](/docs/getting-started-guides/fedora/fedora_manual_config) | | Project
|
||||
@@ -1,196 +0,0 @@
|
||||
---
|
||||
reviewers:
|
||||
- dchen1107
|
||||
- erictune
|
||||
- thockin
|
||||
title: Fedora (Multi Node)
|
||||
---
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
This document describes how to deploy Kubernetes on multiple hosts to set up a multi-node cluster and networking with flannel. Follow fedora [getting started guide](/docs/getting-started-guides/fedora/fedora_manual_config/) to setup 1 master (fed-master) and 2 or more nodes. Make sure that all nodes have different names (fed-node1, fed-node2 and so on) and labels (fed-node1-label, fed-node2-label, and so on) to avoid any conflict. Also make sure that the Kubernetes master host is running etcd, kube-controller-manager, kube-scheduler, and kube-apiserver services, and the nodes are running docker, kube-proxy and kubelet services. Now install flannel on Kubernetes nodes. Flannel on each node configures an overlay network that docker uses. Flannel runs on each node to setup a unique class-C container network.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
You need 2 or more machines with Fedora installed.
|
||||
|
||||
## Master Setup
|
||||
|
||||
**Perform following commands on the Kubernetes master**
|
||||
|
||||
* Configure flannel by creating a `flannel-config.json` in your current directory on fed-master. Flannel provides udp and vxlan among other overlay networking backend options. In this guide, we choose kernel based vxlan backend. The contents of the json are:
|
||||
|
||||
```json
|
||||
{
|
||||
"Network": "18.16.0.0/16",
|
||||
"SubnetLen": 24,
|
||||
"Backend": {
|
||||
"Type": "vxlan",
|
||||
"VNI": 1
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
Choose an IP range that is *NOT* part of the public IP address range.
|
||||
{{< /note >}}
|
||||
|
||||
Add the configuration to the etcd server on fed-master.
|
||||
|
||||
```shell
|
||||
etcdctl set /coreos.com/network/config < flannel-config.json
|
||||
```
|
||||
|
||||
* Verify that the key exists in the etcd server on fed-master.
|
||||
|
||||
```shell
|
||||
etcdctl get /coreos.com/network/config
|
||||
```
|
||||
|
||||
## Node Setup
|
||||
|
||||
**Perform following commands on all Kubernetes nodes**
|
||||
|
||||
Install the flannel package
|
||||
|
||||
```shell
|
||||
# dnf -y install flannel
|
||||
```
|
||||
|
||||
Edit the flannel configuration file /etc/sysconfig/flanneld as follows:
|
||||
|
||||
```shell
|
||||
# Flanneld configuration options
|
||||
|
||||
# etcd url location. Point this to the server where etcd runs
|
||||
FLANNEL_ETCD="http://fed-master:2379"
|
||||
|
||||
# etcd config key. This is the configuration key that flannel queries
|
||||
# For address range assignment
|
||||
FLANNEL_ETCD_KEY="/coreos.com/network"
|
||||
|
||||
# Any additional options that you want to pass
|
||||
FLANNEL_OPTIONS=""
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
By default, flannel uses the interface for the default route. If you have multiple interfaces and would like to use an interface other than the default route one, you could add "-iface=" to FLANNEL_OPTIONS. For additional options, run `flanneld --help` on command line.
|
||||
{{< /note >}}
|
||||
|
||||
Enable the flannel service.
|
||||
|
||||
```shell
|
||||
systemctl enable flanneld
|
||||
```
|
||||
|
||||
If docker is not running, then starting flannel service is enough and skip the next step.
|
||||
|
||||
```shell
|
||||
systemctl start flanneld
|
||||
```
|
||||
|
||||
If docker is already running, then stop docker, delete docker bridge (docker0), start flanneld and restart docker as follows. Another alternative is to just reboot the system (`systemctl reboot`).
|
||||
|
||||
```shell
|
||||
systemctl stop docker
|
||||
ip link delete docker0
|
||||
systemctl start flanneld
|
||||
systemctl start docker
|
||||
```
|
||||
|
||||
|
||||
## Test the cluster and flannel configuration
|
||||
|
||||
Now check the interfaces on the nodes. Notice there is now a flannel.1 interface, and the ip addresses of docker0 and flannel.1 interfaces are in the same network. You will notice that docker0 is assigned a subnet (18.16.29.0/24 as shown below) on each Kubernetes node out of the IP range configured above. A working output should look like this:
|
||||
|
||||
```shell
|
||||
# ip -4 a|grep inet
|
||||
inet 127.0.0.1/8 scope host lo
|
||||
inet 192.168.122.77/24 brd 192.168.122.255 scope global dynamic eth0
|
||||
inet 18.16.29.0/16 scope global flannel.1
|
||||
inet 18.16.29.1/24 scope global docker0
|
||||
```
|
||||
|
||||
From any node in the cluster, check the cluster members by issuing a query to etcd server via curl (only partial output is shown using `grep -E "\{|\}|key|value"`). If you set up a 1 master and 3 nodes cluster, you should see one block for each node showing the subnets they have been assigned. You can associate those subnets to each node by the MAC address (VtepMAC) and IP address (Public IP) that is listed in the output.
|
||||
|
||||
```shell
|
||||
curl -s http://fed-master:2379/v2/keys/coreos.com/network/subnets | python -mjson.tool
|
||||
```
|
||||
|
||||
```json
|
||||
{
|
||||
"node": {
|
||||
"key": "/coreos.com/network/subnets",
|
||||
{
|
||||
"key": "/coreos.com/network/subnets/18.16.29.0-24",
|
||||
"value": "{\"PublicIP\":\"192.168.122.77\",\"BackendType\":\"vxlan\",\"BackendData\":{\"VtepMAC\":\"46:f1:d0:18:d0:65\"}}"
|
||||
},
|
||||
{
|
||||
"key": "/coreos.com/network/subnets/18.16.83.0-24",
|
||||
"value": "{\"PublicIP\":\"192.168.122.36\",\"BackendType\":\"vxlan\",\"BackendData\":{\"VtepMAC\":\"ca:38:78:fc:72:29\"}}"
|
||||
},
|
||||
{
|
||||
"key": "/coreos.com/network/subnets/18.16.90.0-24",
|
||||
"value": "{\"PublicIP\":\"192.168.122.127\",\"BackendType\":\"vxlan\",\"BackendData\":{\"VtepMAC\":\"92:e2:80:ba:2d:4d\"}}"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
From all nodes, review the `/run/flannel/subnet.env` file. This file was generated automatically by flannel.
|
||||
|
||||
```shell
|
||||
# cat /run/flannel/subnet.env
|
||||
FLANNEL_SUBNET=18.16.29.1/24
|
||||
FLANNEL_MTU=1450
|
||||
FLANNEL_IPMASQ=false
|
||||
```
|
||||
|
||||
At this point, we have etcd running on the Kubernetes master, and flannel / docker running on Kubernetes nodes. Next steps are for testing cross-host container communication which will confirm that docker and flannel are configured properly.
|
||||
|
||||
Issue the following commands on any 2 nodes:
|
||||
|
||||
```shell
|
||||
# docker run -it fedora:latest bash
|
||||
bash-4.3#
|
||||
```
|
||||
|
||||
This will place you inside the container. Install iproute and iputils packages to install ip and ping utilities. Due to a [bug](https://bugzilla.redhat.com/show_bug.cgi?id=1142311), it is required to modify capabilities of ping binary to work around "Operation not permitted" error.
|
||||
|
||||
```shell
|
||||
bash-4.3# dnf -y install iproute iputils
|
||||
bash-4.3# setcap cap_net_raw-ep /usr/bin/ping
|
||||
```
|
||||
|
||||
Now note the IP address on the first node:
|
||||
|
||||
```shell
|
||||
bash-4.3# ip -4 a l eth0 | grep inet
|
||||
inet 18.16.29.4/24 scope global eth0
|
||||
```
|
||||
|
||||
And also note the IP address on the other node:
|
||||
|
||||
```shell
|
||||
bash-4.3# ip a l eth0 | grep inet
|
||||
inet 18.16.90.4/24 scope global eth0
|
||||
```
|
||||
Now ping from the first node to the other node:
|
||||
|
||||
```shell
|
||||
bash-4.3# ping 18.16.90.4
|
||||
PING 18.16.90.4 (18.16.90.4) 56(84) bytes of data.
|
||||
64 bytes from 18.16.90.4: icmp_seq=1 ttl=62 time=0.275 ms
|
||||
64 bytes from 18.16.90.4: icmp_seq=2 ttl=62 time=0.372 ms
|
||||
```
|
||||
|
||||
Now Kubernetes multi-node cluster is set up with overlay networking set up by flannel.
|
||||
|
||||
## Support Level
|
||||
|
||||
|
||||
IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level
|
||||
-------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ----------------------------
|
||||
Bare-metal | custom | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) | | Community ([@aveshagarwal](https://github.com/aveshagarwal))
|
||||
libvirt | custom | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) | | Community ([@aveshagarwal](https://github.com/aveshagarwal))
|
||||
KVM | custom | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) | | Community ([@aveshagarwal](https://github.com/aveshagarwal))
|
||||
@@ -1,41 +0,0 @@
|
||||
---
|
||||
title: Kubernetes on Ubuntu
|
||||
content_template: templates/concept
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
There are multiple ways to run a Kubernetes cluster with Ubuntu on public and
|
||||
private clouds, as well as bare metal.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
## The Charmed Distribution of Kubernetes(CDK)
|
||||
|
||||
[CDK](https://www.ubuntu.com/cloud/kubernetes) is a distribution of Kubernetes
|
||||
packaged as a bundle of *charms* for Juju, the open source application modeller.
|
||||
|
||||
CDK is the latest version of Kubernetes with upstream binaries, packaged in a format
|
||||
which makes it fast and easy to deploy. It supports various public
|
||||
and private clouds including AWS, GCE, Azure, Joyent, OpenStack, VMware, Bare Metal
|
||||
and localhost deployments.
|
||||
|
||||
See the [Official documentation](https://www.ubuntu.com/kubernetes/docs) for
|
||||
more information.
|
||||
|
||||
## MicroK8s
|
||||
|
||||
[MicroK8s](https://microk8s.io) is a minimal install of Kubernetes designed to run locally.
|
||||
It can be installed on Ubuntu (or any snap enabled operating system) with the command:
|
||||
|
||||
```shell
|
||||
snap install microk8s --classic
|
||||
```
|
||||
|
||||
Full documentation is available on the [MicroK8s website](https://microk8s.io/docs)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -74,6 +74,7 @@ different Kubernetes components.
|
||||
| `CustomPodDNS` | `false` | Alpha | 1.9 | 1.9 |
|
||||
| `CustomPodDNS` | `true` | Beta| 1.10 | 1.13 |
|
||||
| `CustomPodDNS` | `true` | GA | 1.14 | - |
|
||||
| `CustomResourceDefaulting` | `false` | Alpha| 1.15 | |
|
||||
| `CustomResourcePublishOpenAPI` | `false` | Alpha| 1.14 | 1.14 |
|
||||
| `CustomResourcePublishOpenAPI` | `true` | Beta| 1.15 | |
|
||||
| `CustomResourceSubresources` | `false` | Alpha | 1.10 | 1.11 |
|
||||
@@ -114,6 +115,7 @@ different Kubernetes components.
|
||||
| `KubeletPluginsWatcher` | `true` | GA | 1.13 | - |
|
||||
| `KubeletPodResources` | `false` | Alpha | 1.13 | 1.14 |
|
||||
| `KubeletPodResources` | `true` | Beta | 1.15 | |
|
||||
| `LegacyNodeRoleBehavior` | `true` | Alpha | 1.16 | |
|
||||
| `LocalStorageCapacityIsolation` | `false` | Alpha | 1.7 | 1.9 |
|
||||
| `LocalStorageCapacityIsolation` | `true` | Beta| 1.10 | |
|
||||
| `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | Alpha| 1.15 | |
|
||||
@@ -121,6 +123,7 @@ different Kubernetes components.
|
||||
| `MountPropagation` | `false` | Alpha | 1.8 | 1.9 |
|
||||
| `MountPropagation` | `true` | Beta | 1.10 | 1.11 |
|
||||
| `MountPropagation` | `true` | GA | 1.12 | |
|
||||
| `NodeDisruptionExclusion` | `false` | Alpha | 1.16 | |
|
||||
| `NodeLease` | `false` | Alpha | 1.12 | 1.13 |
|
||||
| `NodeLease` | `true` | Beta | 1.14 | |
|
||||
| `NonPreemptingPriority` | `false` | Alpha | 1.15 | |
|
||||
@@ -267,6 +270,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
|
||||
- `CustomPodDNS`: Enable customizing the DNS settings for a Pod using its `dnsConfig` property.
|
||||
Check [Pod's DNS Config](/docs/concepts/services-networking/dns-pod-service/#pods-dns-config)
|
||||
for more details.
|
||||
- `CustomResourceDefaulting`: Enable CRD support for default values in OpenAPI v3 validation schemas.
|
||||
- `CustomResourcePublishOpenAPI`: Enables publishing of CRD OpenAPI specs.
|
||||
- `CustomResourceSubresources`: Enable `/status` and `/scale` subresources
|
||||
on resources created from [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/).
|
||||
@@ -302,11 +306,13 @@ Each feature gate is designed for enabling/disabling a specific feature:
|
||||
to discover plugins such as [CSI volume drivers](/docs/concepts/storage/volumes/#csi).
|
||||
- `KubeletPodResources`: Enable the kubelet's pod resources grpc endpoint.
|
||||
See [Support Device Monitoring](https://git.k8s.io/community/keps/sig-node/compute-device-assignment.md) for more details.
|
||||
- `LegacyNodeRoleBehavior`: When disabled, legacy behavior in service load balancers and node disruption will ignore the `node-role.kubernetes.io/master` label in favor of the feature-specific labels.
|
||||
- `LocalStorageCapacityIsolation`: Enable the consumption of [local ephemeral storage](/docs/concepts/configuration/manage-compute-resources-container/) and also the `sizeLimit` property of an [emptyDir volume](/docs/concepts/storage/volumes/#emptydir).
|
||||
- `LocalStorageCapacityIsolationFSQuotaMonitoring`: When `LocalStorageCapacityIsolation` is enabled for [local ephemeral storage](/docs/concepts/configuration/manage-compute-resources-container/) and the backing filesystem for [emptyDir volumes](/docs/concepts/storage/volumes/#emptydir) supports project quotas and they are enabled, use project quotas to monitor [emptyDir volume](/docs/concepts/storage/volumes/#emptydir) storage consumption rather than filesystem walk for better performance and accuracy.
|
||||
- `MountContainers`: Enable using utility containers on host as the volume mounter.
|
||||
- `MountPropagation`: Enable sharing volume mounted by one container to other containers or pods.
|
||||
For more details, please see [mount propagation](/docs/concepts/storage/volumes/#mount-propagation).
|
||||
- `NodeDisruptionExclusion`: Enable use of the node label `node.kubernetes.io/exclude-disruption` which prevents nodes from being evacuated during zone failures.
|
||||
- `NodeLease`: Enable the new Lease API to report node heartbeats, which could be used as a node health signal.
|
||||
- `NonPreemptingPriority`: Enable NonPreempting option for PriorityClass and Pod.
|
||||
- `PersistentLocalVolumes`: Enable the usage of `local` volume type in Pods.
|
||||
@@ -336,7 +342,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
|
||||
- `ServerSideApply`: Enables the [Sever Side Apply (SSA)](/docs/reference/using-api/api-concepts/#server-side-apply) path at the API Server.
|
||||
- `ServiceLoadBalancerFinalizer`: Enable finalizer protection for Service load balancers.
|
||||
- `ServiceNodeExclusion`: Enable the exclusion of nodes from load balancers created by a cloud provider.
|
||||
A node is eligible for exclusion if annotated with "`alpha.service-controller.kubernetes.io/exclude-balancer`" key.
|
||||
A node is eligible for exclusion if labelled with "`alpha.service-controller.kubernetes.io/exclude-balancer`" key (when `LegacyNodeRoleBehavior` is on) or `node.kubernetes.io/exclude-from-external-load-balancers`.
|
||||
- `StorageObjectInUseProtection`: Postpone the deletion of PersistentVolume or
|
||||
PersistentVolumeClaim objects if they are still being used.
|
||||
- `StorageVersionHash`: Allow apiservers to expose the storage version hash in the discovery.
|
||||
|
||||
@@ -2,13 +2,17 @@
|
||||
title: Static Pod
|
||||
id: static-pod
|
||||
date: 2019-02-12
|
||||
full_link: /docs/tasks/administer-cluster/static-pod/
|
||||
full_link: /docs/tasks/configure-pod-container/static-pod/
|
||||
short_description: >
|
||||
A pod managed directly by kubelet daemon on a specific node
|
||||
A pod managed directly by the kubelet daemon on a specific node.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
---
|
||||
A {{< glossary_tooltip text="pod" term_id="pod" >}} managed directly by the kubelet
|
||||
daemon on a specific node, without the API server observing it.
|
||||
|
||||
A {{< glossary_tooltip text="pod" term_id="pod" >}} managed directly by the kubelet
|
||||
daemon on a specific node,
|
||||
<!--more-->
|
||||
|
||||
without the API server observing it.
|
||||
@@ -1,28 +1,22 @@
|
||||
---
|
||||
title: Workloads
|
||||
title: Workload
|
||||
id: workloads
|
||||
date: 2019-02-13
|
||||
full_link: /docs/concepts/workloads/
|
||||
short_description: >
|
||||
Workloads are objects you use to manage and run your containers on the cluster.
|
||||
A workload is an application running on Kubernetes.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- core-object
|
||||
- workload
|
||||
---
|
||||
Workloads are objects you use to manage and run your containers on the cluster.
|
||||
A workload is an application running on Kubernetes.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Kubernetes performs the
|
||||
deployment and updates the workload with the current state of the application.
|
||||
Workloads include the DaemonSet, Deployments, Jobs, Pods, ReplicaSet, ReplicationController, and StatefulSet objects.
|
||||
|
||||
For example, a workload that has a web element and a database element might run the
|
||||
database in one {{< glossary_tooltip term_id="StatefulSet" >}} of
|
||||
{{< glossary_tooltip text="pods" term_id="pod" >}} and the webserver via
|
||||
a {{< glossary_tooltip term_id="Deployment" >}} that consists of many web app
|
||||
{{< glossary_tooltip text="pods" term_id="pod" >}}, all alike.
|
||||
Various core objects that represent different types or parts of a workload
|
||||
include the DaemonSet, Deployment, Job, ReplicaSet, and StatefulSet objects.
|
||||
|
||||
For example, a workload that has a web server and a database might run the
|
||||
database in one {{< glossary_tooltip term_id="StatefulSet" >}} and the web server
|
||||
in a {{< glossary_tooltip term_id="Deployment" >}}.
|
||||
|
||||
@@ -109,5 +109,6 @@ The following production environment solutions table lists the providers and the
|
||||
| [Tencent Cloud](https://intl.cloud.tencent.com/) | [Tencent Kubernetes Engine](https://intl.cloud.tencent.com/product/tke) | ✔ | ✔ | | | ✔ |
|
||||
| [VEXXHOST](https://vexxhost.com/) | ✔ | ✔ | | | |
|
||||
| [VMware](https://cloud.vmware.com/) | [VMware Cloud PKS](https://cloud.vmware.com/vmware-cloud-pks) |[VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks) | [VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks) | [VMware Essential PKS](https://cloud.vmware.com/vmware-essential-pks) | |[VMware Essential PKS](https://cloud.vmware.com/vmware-essential-pks)
|
||||
| [Z.A.R.V.I.S.](https://zarvis.ai/) | ✔ | | | | | |
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -28,8 +28,8 @@ The Kubernetes project maintains release branches for the most recent three mino
|
||||
|
||||
Applicable fixes, including security fixes, may be backported to those three release branches, depending on severity and feasibility.
|
||||
Patch releases are cut from those branches at a regular cadence, or as needed.
|
||||
This decision is owned by the [patch release manager](https://github.com/kubernetes/sig-release/blob/master/release-team/role-handbooks/patch-release-manager/README.md#release-timing).
|
||||
The patch release manager is a member of the [release team for each release](https://github.com/kubernetes/sig-release/tree/master/releases/).
|
||||
This decision is owned by the [patch release manager](https://github.com/kubernetes/sig-release/blob/master/release-engineering/role-handbooks/patch-release-manager.md#release-timing).
|
||||
The patch release manager is a member of the [release team for each release](https://github.com/kubernetes/sig-release/tree/master/release-team).
|
||||
|
||||
Minor releases occur approximately every 3 months, so each minor release branch is maintained for approximately 9 months.
|
||||
|
||||
@@ -37,7 +37,7 @@ Minor releases occur approximately every 3 months, so each minor release branch
|
||||
|
||||
### kube-apiserver
|
||||
|
||||
In [highly-available (HA) clusters](/docs/setup/production-environment/tools/independent/high-availability/), the newest and oldest `kube-apiserver` instances must be within one minor version.
|
||||
In [highly-available (HA) clusters](/docs/setup/production-environment/tools/kubeadm/high-availability/), the newest and oldest `kube-apiserver` instances must be within one minor version.
|
||||
|
||||
Example:
|
||||
|
||||
@@ -120,7 +120,7 @@ Upgrade `kube-apiserver` to **1.(n+1)**
|
||||
|
||||
{{< note >}}
|
||||
Project policies for [API deprecation](/docs/reference/using-api/deprecation-policy/) and
|
||||
[API change guidelines](https://github.com/kubernetes/community/blob/master/contributors/devel/api_changes.md)
|
||||
[API change guidelines](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md)
|
||||
require `kube-apiserver` to not skip minor versions when upgrading, even in single-instance clusters.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
@@ -30,7 +30,7 @@ Dashboard also provides information on the state of Kubernetes resources in your
|
||||
The Dashboard UI is not deployed by default. To deploy it, run the following command:
|
||||
|
||||
```
|
||||
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-beta1/aio/deploy/recommended.yaml
|
||||
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-beta4/aio/deploy/recommended.yaml
|
||||
```
|
||||
|
||||
## Accessing the Dashboard UI
|
||||
|
||||
+4
@@ -217,6 +217,8 @@ metadata:
|
||||
spec:
|
||||
# group name to use for REST API: /apis/<group>/<version>
|
||||
group: example.com
|
||||
# prunes object fields that are not specified in OpenAPI schemas below.
|
||||
preserveUnknownFields: false
|
||||
# list of versions supported by this CustomResourceDefinition
|
||||
versions:
|
||||
- name: v1beta1
|
||||
@@ -228,6 +230,7 @@ spec:
|
||||
# schema is defined.
|
||||
schema:
|
||||
openAPIV3Schema:
|
||||
type: object
|
||||
properties:
|
||||
hostPort:
|
||||
type: string
|
||||
@@ -236,6 +239,7 @@ spec:
|
||||
storage: false
|
||||
schema:
|
||||
openAPIV3Schema:
|
||||
type: object
|
||||
properties:
|
||||
host:
|
||||
type: string
|
||||
|
||||
@@ -36,7 +36,7 @@ may be disabled by setting `--feature-gates=PodShareProcessNamespace=false`.
|
||||
|
||||
## Configure a Pod
|
||||
|
||||
Process Namespace Sharing is enabled using the `ShareProcessNamespace` field of
|
||||
Process Namespace Sharing is enabled using the `shareProcessNamespace` field of
|
||||
`v1.PodSpec`. For example:
|
||||
|
||||
{{< codenew file="pods/share-process-namespace.yaml" >}}
|
||||
|
||||
@@ -490,6 +490,18 @@ let users route data where they want. For example, users can emit audit events t
|
||||
plugin which supports full-text search and analytics.
|
||||
|
||||
|
||||
[kube-apiserver]: /docs/admin/kube-apiserver
|
||||
[auditing-proposal]: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/auditing.md
|
||||
[auditing-api]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/pkg/apis/audit/v1/types.go
|
||||
[gce-audit-profile]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh#L735
|
||||
[kubeconfig]: /docs/tasks/access-application-cluster/configure-access-multiple-clusters/
|
||||
[fluentd]: http://www.fluentd.org/
|
||||
[fluentd_install_doc]: https://docs.fluentd.org/v1.0/articles/quickstart#step-1:-installing-fluentd
|
||||
[fluentd_plugin_management_doc]: https://docs.fluentd.org/v1.0/articles/plugin-management
|
||||
[logstash]: https://www.elastic.co/products/logstash
|
||||
[logstash_install_doc]: https://www.elastic.co/guide/en/logstash/current/installing-logstash.html
|
||||
[kube-aggregator]: /docs/concepts/api-extension/apiserver-aggregation
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
FROM nginx:1.9.14
|
||||
FROM nginx:1.17.3
|
||||
|
||||
RUN rm /etc/nginx/conf.d/default.conf
|
||||
COPY frontend.conf /etc/nginx/conf.d
|
||||
|
||||
Reference in New Issue
Block a user