Merge remote-tracking branch 'upstream/master' into dev-1.19
This commit is contained in:
Savitha Raghunathan
@@ -101,12 +101,12 @@ If needed, you can expand the **Advanced options** section where you can specify
|
||||
|
||||
Example:
|
||||
|
||||
```conf
|
||||
release=1.0
|
||||
tier=frontend
|
||||
environment=pod
|
||||
track=stable
|
||||
```
|
||||
```conf
|
||||
release=1.0
|
||||
tier=frontend
|
||||
environment=pod
|
||||
track=stable
|
||||
```
|
||||
|
||||
- **Namespace**: Kubernetes supports multiple virtual clusters backed by the same physical cluster. These virtual clusters are called [namespaces](/docs/tasks/administer-cluster/namespaces/). They let you partition resources into logically named groups.
|
||||
|
||||
|
||||
@@ -24,7 +24,7 @@ Depending on the installation method, your Kubernetes cluster may be deployed wi
|
||||
an existing StorageClass that is marked as default. This default StorageClass
|
||||
is then used to dynamically provision storage for PersistentVolumeClaims
|
||||
that do not require any specific storage class. See
|
||||
[PersistentVolumeClaim documentation](/docs/concepts/storage/persistent-volumes/#class-1)
|
||||
[PersistentVolumeClaim documentation](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)
|
||||
for details.
|
||||
|
||||
The pre-installed default StorageClass may not fit well with your expected workload;
|
||||
|
||||
@@ -36,7 +36,7 @@ By default, the kubelet uses [CFS quota](https://en.wikipedia.org/wiki/Completel
|
||||
to enforce pod CPU limits. When the node runs many CPU-bound pods,
|
||||
the workload can move to different CPU cores depending on
|
||||
whether the pod is throttled and which CPU cores are available at
|
||||
scheduling time. Many workloads are not sensitive to this migration and thus
|
||||
scheduling time. Many workloads are not sensitive to this migration and thus
|
||||
work fine without any intervention.
|
||||
|
||||
However, in workloads where CPU cache affinity and scheduling latency
|
||||
|
||||
@@ -82,6 +82,10 @@ See the [design doc](https://git.k8s.io/community/contributors/design-proposals/
|
||||
|
||||
## Creating a new namespace
|
||||
|
||||
{{< note >}}
|
||||
Avoid creating namespace with prefix `kube-`, since it is reserved for Kubernetes system namespaces.
|
||||
{{< /note >}}
|
||||
|
||||
1. Create a new YAML file called `my-namespace.yaml` with the contents:
|
||||
|
||||
```yaml
|
||||
|
||||
@@ -57,7 +57,8 @@ The following sysctls are supported in the _safe_ set:
|
||||
|
||||
- `kernel.shm_rmid_forced`,
|
||||
- `net.ipv4.ip_local_port_range`,
|
||||
- `net.ipv4.tcp_syncookies`.
|
||||
- `net.ipv4.tcp_syncookies`,
|
||||
- `net.ipv4.ping_group_range` (since Kubernetes 1.18).
|
||||
|
||||
{{< note >}}
|
||||
The example `net.ipv4.tcp_syncookies` is not namespaced on Linux kernel version 4.4 or lower.
|
||||
|
||||
+1
-1
@@ -332,7 +332,7 @@ to 1 second. Minimum value is 1.
|
||||
* `successThreshold`: Minimum consecutive successes for the probe to be
|
||||
considered successful after having failed. Defaults to 1. Must be 1 for
|
||||
liveness. Minimum value is 1.
|
||||
* `failureThreshold`: When a Pod starts and the probe fails, Kubernetes will
|
||||
* `failureThreshold`: When a probe fails, Kubernetes will
|
||||
try `failureThreshold` times before giving up. Giving up in case of liveness probe means restarting the container. In case of readiness probe the Pod will be marked Unready.
|
||||
Defaults to 3. Minimum value is 1.
|
||||
|
||||
|
||||
@@ -323,7 +323,7 @@ The application is responsible for reloading the token when it rotates. Periodic
|
||||
{{< feature-state for_k8s_version="v1.18" state="alpha" >}}
|
||||
|
||||
The Service Account Issuer Discovery feature is enabled by enabling the
|
||||
`ServiceAccountIssuerDiscovery` [feature gate](/docs/reference/command-line-tools-reference/feature)
|
||||
`ServiceAccountIssuerDiscovery` [feature gate](/docs/reference/command-line-tools-reference/feature-gates)
|
||||
and then enabling the Service Account Token Projection feature as described
|
||||
[above](#service-account-token-volume-projection).
|
||||
|
||||
|
||||
@@ -116,6 +116,6 @@ For further details, see [Kubernetes Audit Events][falco_ka_docs] in the Falco d
|
||||
[falco_k8s_audit_rules]: https://github.com/falcosecurity/falco/blob/master/rules/k8s_audit_rules.yaml
|
||||
[falco_ka_docs]: https://falco.org/docs/event-sources/kubernetes-audit
|
||||
[falco_installation]: https://falco.org/docs/installation
|
||||
[falco_helm_chart]: https://github.com/helm/charts/tree/master/stable/falco
|
||||
[falco_helm_chart]: https://github.com/falcosecurity/charts/tree/master/falco
|
||||
|
||||
|
||||
|
||||
+1
@@ -4,6 +4,7 @@ reviewers:
|
||||
- madhusudancs
|
||||
title: Configure Multiple Schedulers
|
||||
content_type: task
|
||||
weight: 20
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
@@ -181,7 +181,8 @@ are preserved as annotations when working with `autoscaling/v1`.
|
||||
When you create a HorizontalPodAutoscaler API object, make sure the name specified is a valid
|
||||
[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
|
||||
More details about the API object can be found at
|
||||
[HorizontalPodAutoscaler Object](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object).
|
||||
[HorizontalPodAutoscaler Object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#horizontalpodautoscaler-v1-autoscaling).
|
||||
|
||||
|
||||
## Support for Horizontal Pod Autoscaler in kubectl
|
||||
|
||||
|
||||
Reference in New Issue
Block a user