Merge remote-tracking branch 'upstream/main' into dev-1.23
This commit is contained in:
Jesse Butler
@@ -402,7 +402,7 @@ Graceful node shutdown is controlled with the `GracefulNodeShutdown`
|
||||
enabled by default in 1.21.
|
||||
|
||||
Note that by default, both configuration options described below,
|
||||
`ShutdownGracePeriod` and `ShutdownGracePeriodCriticalPods` are set to zero,
|
||||
`shutdownGracePeriod` and `shutdownGracePeriodCriticalPods` are set to zero,
|
||||
thus not activating Graceful node shutdown functionality.
|
||||
To activate the feature, the two kubelet config settings should be configured appropriately and set to non-zero values.
|
||||
|
||||
@@ -412,13 +412,13 @@ During a graceful shutdown, kubelet terminates pods in two phases:
|
||||
2. Terminate [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical) running on the node.
|
||||
|
||||
Graceful node shutdown feature is configured with two [`KubeletConfiguration`](/docs/tasks/administer-cluster/kubelet-config-file/) options:
|
||||
* `ShutdownGracePeriod`:
|
||||
* `shutdownGracePeriod`:
|
||||
* Specifies the total duration that the node should delay the shutdown by. This is the total grace period for pod termination for both regular and [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical).
|
||||
* `ShutdownGracePeriodCriticalPods`:
|
||||
* Specifies the duration used to terminate [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical) during a node shutdown. This value should be less than `ShutdownGracePeriod`.
|
||||
* `shutdownGracePeriodCriticalPods`:
|
||||
* Specifies the duration used to terminate [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical) during a node shutdown. This value should be less than `shutdownGracePeriod`.
|
||||
|
||||
For example, if `ShutdownGracePeriod=30s`, and
|
||||
`ShutdownGracePeriodCriticalPods=10s`, kubelet will delay the node shutdown by
|
||||
For example, if `shutdownGracePeriod=30s`, and
|
||||
`shutdownGracePeriodCriticalPods=10s`, kubelet will delay the node shutdown by
|
||||
30 seconds. During the shutdown, the first 20 (30-10) seconds would be reserved
|
||||
for gracefully terminating normal pods, and the last 10 seconds would be
|
||||
reserved for terminating [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical).
|
||||
@@ -535,6 +535,11 @@ the kubelet, and the `--fail-swap-on` command line flag or `failSwapOn`
|
||||
[configuration setting](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)
|
||||
must be set to false.
|
||||
|
||||
{{< warning >}}
|
||||
When the memory swap feature is turned on, Kubernetes data such as the content
|
||||
of Secret objects that were written to tmpfs now could be swapped to disk.
|
||||
{{< /warning >}}
|
||||
|
||||
A user can also optionally configure `memorySwap.swapBehavior` in order to
|
||||
specify how a node will use swap memory. For example,
|
||||
|
||||
|
||||
@@ -45,6 +45,11 @@ This page lists some of the available add-ons and links to their respective inst
|
||||
## Infrastructure
|
||||
|
||||
* [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation) is an add-on to run virtual machines on Kubernetes. Usually run on bare-metal clusters.
|
||||
* The
|
||||
[node problem detector](https://github.com/kubernetes/node-problem-detector)
|
||||
runs on Linux nodes and reports system issues as either
|
||||
[Events](/docs/reference/kubernetes-api/cluster-resources/event-v1/) or
|
||||
[Node conditions](/docs/concepts/architecture/nodes/#condition).
|
||||
|
||||
## Legacy Add-ons
|
||||
|
||||
|
||||
@@ -26,6 +26,10 @@ fair queuing technique so that, for example, a poorly-behaved
|
||||
{{< glossary_tooltip text="controller" term_id="controller" >}} need not
|
||||
starve others (even at the same priority level).
|
||||
|
||||
This feature is designed to work well with standard controllers, which
|
||||
use informers and react to failures of API requests with exponential
|
||||
back-off, and other clients that also work this way.
|
||||
|
||||
{{< caution >}}
|
||||
Requests classified as "long-running" — primarily watches — are not
|
||||
subject to the API Priority and Fairness filter. This is also true for
|
||||
@@ -102,6 +106,8 @@ name of the matching FlowSchema plus a _flow distinguisher_ — which
|
||||
is either the requesting user, the target resource's namespace, or nothing — and the
|
||||
system attempts to give approximately equal weight to requests in different
|
||||
flows of the same priority level.
|
||||
To enable distinct handling of distinct instances, controllers that have
|
||||
many instances should authenticate with distinct usernames
|
||||
|
||||
After classifying a request into a flow, the API Priority and Fairness
|
||||
feature then may assign the request to a queue. This assignment uses
|
||||
|
||||
@@ -169,49 +169,6 @@ With this toolset DANM is able to provide multiple separated network interfaces,
|
||||
network that satisfies the Kubernetes requirements. Many
|
||||
people have reported success with Flannel and Kubernetes.
|
||||
|
||||
### Google Compute Engine (GCE)
|
||||
|
||||
For the Google Compute Engine cluster configuration scripts, [advanced
|
||||
routing](https://cloud.google.com/vpc/docs/routes) is used to
|
||||
assign each VM a subnet (default is `/24` - 254 IPs). Any traffic bound for that
|
||||
subnet will be routed directly to the VM by the GCE network fabric. This is in
|
||||
addition to the "main" IP address assigned to the VM, which is NAT'ed for
|
||||
outbound internet access. A linux bridge (called `cbr0`) is configured to exist
|
||||
on that subnet, and is passed to docker's `--bridge` flag.
|
||||
|
||||
Docker is started with:
|
||||
|
||||
```shell
|
||||
DOCKER_OPTS="--bridge=cbr0 --iptables=false --ip-masq=false"
|
||||
```
|
||||
|
||||
This bridge is created by Kubelet (controlled by the `--network-plugin=kubenet`
|
||||
flag) according to the `Node`'s `.spec.podCIDR`.
|
||||
|
||||
Docker will now allocate IPs from the `cbr-cidr` block. Containers can reach
|
||||
each other and `Nodes` over the `cbr0` bridge. Those IPs are all routable
|
||||
within the GCE project network.
|
||||
|
||||
GCE itself does not know anything about these IPs, though, so it will not NAT
|
||||
them for outbound internet traffic. To achieve that an iptables rule is used
|
||||
to masquerade (aka SNAT - to make it seem as if packets came from the `Node`
|
||||
itself) traffic that is bound for IPs outside the GCE project network
|
||||
(10.0.0.0/8).
|
||||
|
||||
```shell
|
||||
iptables -t nat -A POSTROUTING ! -d 10.0.0.0/8 -o eth0 -j MASQUERADE
|
||||
```
|
||||
|
||||
Lastly IP forwarding is enabled in the kernel (so the kernel will process
|
||||
packets for bridged containers):
|
||||
|
||||
```shell
|
||||
sysctl net.ipv4.ip_forward=1
|
||||
```
|
||||
|
||||
The result of all this is that all `Pods` can reach each other and can egress
|
||||
traffic to the internet.
|
||||
|
||||
### Jaguar
|
||||
|
||||
[Jaguar](https://gitlab.com/sdnlab/jaguar) is an open source solution for Kubernetes's network based on OpenDaylight. Jaguar provides overlay network using vxlan and Jaguar CNIPlugin provides one IP address per pod.
|
||||
|
||||
@@ -116,11 +116,11 @@ CPU is always requested as an absolute quantity, never as a relative quantity;
|
||||
|
||||
Limits and requests for `memory` are measured in bytes. You can express memory as
|
||||
a plain integer or as a fixed-point number using one of these suffixes:
|
||||
E, P, T, G, M, k. You can also use the power-of-two equivalents: Ei, Pi, Ti, Gi,
|
||||
E, P, T, G, M, k, m (millis). You can also use the power-of-two equivalents: Ei, Pi, Ti, Gi,
|
||||
Mi, Ki. For example, the following represent roughly the same value:
|
||||
|
||||
```shell
|
||||
128974848, 129e6, 129M, 123Mi
|
||||
128974848, 129e6, 129M, 128974848000m, 123Mi
|
||||
```
|
||||
|
||||
Here's an example.
|
||||
|
||||
@@ -57,12 +57,11 @@ Kubernetes as a project supports and maintains [AWS](https://github.com/kubernet
|
||||
|
||||
## Using multiple Ingress controllers
|
||||
|
||||
You may deploy [any number of ingress controllers](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers)
|
||||
within a cluster. When you create an ingress, you should annotate each ingress with the appropriate
|
||||
[`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster)
|
||||
to indicate which ingress controller should be used if more than one exists within your cluster.
|
||||
You may deploy any number of ingress controllers using [ingress class](/docs/concepts/services-networking/ingress/#ingress-class)
|
||||
within a cluster. Note the `.metadata.name` of your ingress class resource. When you create an ingress you would need that name to specify the `ingressClassName` field on your Ingress object (refer to [IngressSpec v1 reference](/docs/reference/kubernetes-api/service-resources/ingress-v1/#IngressSpec). `ingressClassName` is a replacement of the older [annotation method](/docs/concepts/services-networking/ingress/#deprecated-annotation).
|
||||
|
||||
If you do not define a class, your cloud provider may use a default ingress controller.
|
||||
If you do not specify an IngressClass for an Ingress, and your cluster has exactly one IngressClass marked as default, then Kubernetes [applies](/docs/concepts/services-networking/ingress/#default-ingress-class) the cluster's default IngressClass to the Ingress.
|
||||
You mark an IngressClass as default by setting the [`ingressclass.kubernetes.io/is-default-class` annotation](/docs/reference/labels-annotations-taints/#ingressclass-kubernetes-io-is-default-class) on that IngressClass, with the string value `"true"`.
|
||||
|
||||
Ideally, all ingress controllers should fulfill this specification, but the various ingress
|
||||
controllers operate slightly differently.
|
||||
|
||||
@@ -7,7 +7,7 @@ reviewers:
|
||||
- pohly
|
||||
title: Ephemeral Volumes
|
||||
content_type: concept
|
||||
weight: 50
|
||||
weight: 30
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
@@ -10,14 +10,13 @@ feature:
|
||||
title: Storage orchestration
|
||||
description: >
|
||||
Automatically mount the storage system of your choice, whether from local storage, a public cloud provider such as <a href="https://cloud.google.com/storage/">GCP</a> or <a href="https://aws.amazon.com/products/storage/">AWS</a>, or a network storage system such as NFS, iSCSI, Gluster, Ceph, Cinder, or Flocker.
|
||||
|
||||
content_type: concept
|
||||
weight: 20
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
This document describes the current state of _persistent volumes_ in Kubernetes. Familiarity with [volumes](/docs/concepts/storage/volumes/) is suggested.
|
||||
This document describes _persistent volumes_ in Kubernetes. Familiarity with [volumes](/docs/concepts/storage/volumes/) is suggested.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
|
||||
@@ -1,16 +1,16 @@
|
||||
---
|
||||
reviewers:
|
||||
- sftim
|
||||
- marosset
|
||||
- jsturtevant
|
||||
- zshihang
|
||||
title: Projected Volumes
|
||||
content_type: concept
|
||||
weight: 21 # just after persistent volumes
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
This document describes the current state of _projected volumes_ in Kubernetes. Familiarity with [volumes](/docs/concepts/storage/volumes/) is suggested.
|
||||
This document describes _projected volumes_ in Kubernetes. Familiarity with [volumes](/docs/concepts/storage/volumes/) is suggested.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@ reviewers:
|
||||
- pohly
|
||||
title: Storage Capacity
|
||||
content_type: concept
|
||||
weight: 45
|
||||
weight: 70
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
@@ -16,7 +16,6 @@ Storage capacity is limited and may vary depending on the node on
|
||||
which a pod runs: network-attached storage might not be accessible by
|
||||
all nodes, or storage is local to a node to begin with.
|
||||
|
||||
{{< feature-state for_k8s_version="v1.19" state="alpha" >}}
|
||||
{{< feature-state for_k8s_version="v1.21" state="beta" >}}
|
||||
|
||||
This page describes how Kubernetes keeps track of storage capacity and
|
||||
|
||||
@@ -6,7 +6,7 @@ reviewers:
|
||||
- msau42
|
||||
title: CSI Volume Cloning
|
||||
content_type: concept
|
||||
weight: 30
|
||||
weight: 60
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
@@ -8,7 +8,7 @@ reviewers:
|
||||
- yuxiangqian
|
||||
title: Volume Snapshot Classes
|
||||
content_type: concept
|
||||
weight: 30
|
||||
weight: 41 # just after volume snapshots
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
@@ -8,7 +8,7 @@ reviewers:
|
||||
- yuxiangqian
|
||||
title: Volume Snapshots
|
||||
content_type: concept
|
||||
weight: 20
|
||||
weight: 40
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
@@ -32,7 +32,7 @@ The following are typical use cases for Deployments:
|
||||
* [Declare the new state of the Pods](#updating-a-deployment) by updating the PodTemplateSpec of the Deployment. A new ReplicaSet is created and the Deployment manages moving the Pods from the old ReplicaSet to the new one at a controlled rate. Each new ReplicaSet updates the revision of the Deployment.
|
||||
* [Rollback to an earlier Deployment revision](#rolling-back-a-deployment) if the current state of the Deployment is not stable. Each rollback updates the revision of the Deployment.
|
||||
* [Scale up the Deployment to facilitate more load](#scaling-a-deployment).
|
||||
* [Pause the Deployment](#pausing-and-resuming-a-deployment) to apply multiple fixes to its PodTemplateSpec and then resume it to start a new rollout.
|
||||
* [Pause the rollout of a Deployment](#pausing-and-resuming-a-deployment) to apply multiple fixes to its PodTemplateSpec and then resume it to start a new rollout.
|
||||
* [Use the status of the Deployment](#deployment-status) as an indicator that a rollout has stuck.
|
||||
* [Clean up older ReplicaSets](#clean-up-policy) that you don't need anymore.
|
||||
|
||||
@@ -697,9 +697,12 @@ nginx-deployment-1989198191 7 7 0 7m
|
||||
nginx-deployment-618515232 11 11 11 7m
|
||||
```
|
||||
|
||||
## Pausing and Resuming a Deployment
|
||||
## Pausing and Resuming a rollout of a Deployment {#pausing-and-resuming-a-deployment}
|
||||
|
||||
You can pause a Deployment before triggering one or more updates and then resume it. This allows you to
|
||||
When you update a Deployment, or plan to, you can pause rollouts
|
||||
for that Deployment before you trigger one or more updates. When
|
||||
you're ready to apply those changes, you resume rollouts for the
|
||||
Deployment. This approach allows you to
|
||||
apply multiple fixes in between pausing and resuming without triggering unnecessary rollouts.
|
||||
|
||||
* For example, with a Deployment that was created:
|
||||
@@ -775,10 +778,10 @@ apply multiple fixes in between pausing and resuming without triggering unnecess
|
||||
deployment.apps/nginx-deployment resource requirements updated
|
||||
```
|
||||
|
||||
The initial state of the Deployment prior to pausing it will continue its function, but new updates to
|
||||
the Deployment will not have any effect as long as the Deployment is paused.
|
||||
The initial state of the Deployment prior to pausing its rollout will continue its function, but new updates to
|
||||
the Deployment will not have any effect as long as the Deployment rollout is paused.
|
||||
|
||||
* Eventually, resume the Deployment and observe a new ReplicaSet coming up with all the new updates:
|
||||
* Eventually, resume the Deployment rollout and observe a new ReplicaSet coming up with all the new updates:
|
||||
```shell
|
||||
kubectl rollout resume deployment/nginx-deployment
|
||||
```
|
||||
@@ -912,8 +915,8 @@ example, rollback the Deployment to its previous version.
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
If you pause a Deployment, Kubernetes does not check progress against your specified deadline.
|
||||
You can safely pause a Deployment in the middle of a rollout and resume without triggering
|
||||
If you pause a Deployment rollout, Kubernetes does not check progress against your specified deadline.
|
||||
You can safely pause a Deployment rollout in the middle of a rollout and resume without triggering
|
||||
the condition for exceeding the deadline.
|
||||
{{< /note >}}
|
||||
|
||||
@@ -1065,6 +1068,18 @@ allowed, which is the default if not specified.
|
||||
|
||||
`.spec.replicas` is an optional field that specifies the number of desired Pods. It defaults to 1.
|
||||
|
||||
Should you manually scale a Deployment, example via `kubectl scale deployment
|
||||
deployment --replicas=X`, and then you update that Deployment based on a manifest
|
||||
(for example: by running `kubectl apply -f deployment.yaml`),
|
||||
then applying that manifest overwrites the manual scaling that you previously did.
|
||||
|
||||
If a [HorizontalPodAutoscaler](/docs/tasks/run-application/horizontal-pod-autoscale/) (or any
|
||||
similar API for horizontal scaling) is managing scaling for a Deployment, don't set `.spec.replicas`.
|
||||
|
||||
Instead, allow the Kubernetes
|
||||
{{< glossary_tooltip text="control plane" term_id="control-plane" >}} to manage the
|
||||
`.spec.replicas` field automatically.
|
||||
|
||||
### Selector
|
||||
|
||||
`.spec.selector` is a required field that specifies a [label selector](/docs/concepts/overview/working-with-objects/labels/)
|
||||
|
||||
@@ -379,6 +379,22 @@ which will verify owner references before terminating Pods. If that is not possi
|
||||
operator should verify the owner references on PVCs to ensure the expected objects are
|
||||
deleted when Pods are force-deleted.
|
||||
|
||||
### Replicas
|
||||
|
||||
`.spec.replicas` is an optional field that specifies the number of desired Pods. It defaults to 1.
|
||||
|
||||
Should you manually scale a deployment, example via `kubectl scale
|
||||
statefulset statefulset --replicas=X`, and then you update that StatefulSet
|
||||
based on a manifest (for example: by running `kubectl apply -f
|
||||
statefulset.yaml`), then applying that manifest overwrites the manual scaling
|
||||
that you previously did.
|
||||
|
||||
If a [HorizontalPodAutoscaler](/docs/tasks/run-application/horizontal-pod-autoscale/)
|
||||
(or any similar API for horizontal scaling) is managing scaling for a
|
||||
Statefulset, don't set `.spec.replicas`. Instead, allow the Kubernetes
|
||||
{{<glossary_tooltip text="control plane" term_id="control-plane" >}} to manage
|
||||
the `.spec.replicas` field automatically.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* Learn about [Pods](/docs/concepts/workloads/pods).
|
||||
|
||||
@@ -159,7 +159,7 @@ through which the Pod has or has not passed:
|
||||
* `PodScheduled`: the Pod has been scheduled to a node.
|
||||
* `ContainersReady`: all containers in the Pod are ready.
|
||||
* `Initialized`: all [init containers](/docs/concepts/workloads/pods/init-containers/)
|
||||
have started successfully.
|
||||
have completed successfully.
|
||||
* `Ready`: the Pod is able to serve requests and should be added to the load
|
||||
balancing pools of all matching Services.
|
||||
|
||||
|
||||
@@ -85,7 +85,7 @@ You can define one or multiple `topologySpreadConstraint` to instruct the kube-s
|
||||
It must be greater than zero. Its semantics differs according to the value of `whenUnsatisfiable`:
|
||||
- when `whenUnsatisfiable` equals to "DoNotSchedule", `maxSkew` is the maximum
|
||||
permitted difference between the number of matching pods in the target
|
||||
topology and the global minimum
|
||||
topology and the global minimum
|
||||
(the minimum number of pods that match the label selector in a topology domain. For example, if you have 3 zones with 0, 2 and 3 matching pods respectively, The global minimum is 0).
|
||||
- when `whenUnsatisfiable` equals to "ScheduleAnyway", scheduler gives higher
|
||||
precedence to topologies that would help reduce the skew.
|
||||
@@ -234,6 +234,8 @@ To overcome this situation, you can either increase the `maxSkew` or modify one
|
||||
|
||||
The scheduler will skip the non-matching nodes from the skew calculations if the incoming Pod has `spec.nodeSelector` or `spec.affinity.nodeAffinity` defined.
|
||||
|
||||
### Example: TopologySpreadConstraints with NodeAffinity
|
||||
|
||||
Suppose you have a 5-node cluster ranging from zoneA to zoneC:
|
||||
|
||||
{{<mermaid>}}
|
||||
@@ -349,12 +351,14 @@ Also, the legacy `SelectorSpread` plugin, which provides an equivalent behavior,
|
||||
is disabled.
|
||||
|
||||
{{< note >}}
|
||||
The `PodTopologySpread` plugin does not score the nodes that don't have
|
||||
the topology keys specified in the spreading constraints. This might result
|
||||
in a different default behavior compared to the legacy `SelectorSpread` plugin when
|
||||
using the default topology constraints.
|
||||
|
||||
If your nodes are not expected to have **both** `kubernetes.io/hostname` and
|
||||
`topology.kubernetes.io/zone` labels set, define your own constraints
|
||||
instead of using the Kubernetes defaults.
|
||||
|
||||
The `PodTopologySpread` plugin does not score the nodes that don't have
|
||||
the topology keys specified in the spreading constraints.
|
||||
{{< /note >}}
|
||||
|
||||
If you don't want to use the default Pod spreading constraints for your cluster,
|
||||
@@ -392,7 +396,7 @@ for more details.
|
||||
|
||||
## Known Limitations
|
||||
|
||||
- There's no guarantee that the constraints remain satisfied when Pods are removed. For example, scaling down a Deployment may result in imbalanced Pods distribution.
|
||||
- There's no guarantee that the constraints remain satisfied when Pods are removed. For example, scaling down a Deployment may result in imbalanced Pods distribution.
|
||||
You can use [Descheduler](https://github.com/kubernetes-sigs/descheduler) to rebalance the Pods distribution.
|
||||
- Pods matched on tainted nodes are respected. See [Issue 80921](https://github.com/kubernetes/kubernetes/issues/80921)
|
||||
|
||||
|
||||
@@ -27,7 +27,7 @@ the documentation, the website style, the processes for reviewing and merging
|
||||
pull requests, or other aspects of the documentation. For maximum transparency,
|
||||
these types of proposals need to be discussed in a SIG Docs meeting or on the
|
||||
[kubernetes-sig-docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
|
||||
In addition, it can really help to have some context about the way things
|
||||
In addition, it can help to have some context about the way things
|
||||
currently work and why past decisions have been made before proposing sweeping
|
||||
changes. The quickest way to get answers to questions about how the documentation
|
||||
currently works is to ask in the `#sig-docs` Slack channel on
|
||||
@@ -54,7 +54,7 @@ refer to
|
||||
The SIG Docs representative for a given release coordinates the following tasks:
|
||||
|
||||
- Monitor the feature-tracking spreadsheet for new or changed features with an
|
||||
impact on documentation. If documentation for a given feature won't be ready
|
||||
impact on documentation. If the documentation for a given feature won't be ready
|
||||
for the release, the feature may not be allowed to go into the release.
|
||||
- Attend sig-release meetings regularly and give updates on the status of the
|
||||
docs for the release.
|
||||
@@ -82,12 +82,12 @@ few PR submissions.
|
||||
Responsibilities for New Contributor Ambassadors include:
|
||||
|
||||
- Monitoring the [#sig-docs Slack channel](https://kubernetes.slack.com) for questions from new contributors.
|
||||
- Working with PR wranglers to identify good first issues for new contributors.
|
||||
- Working with PR wranglers to identify [good first issues](https://kubernetes.dev/docs/guide/help-wanted/#good-first-issue) for new contributors.
|
||||
- Mentoring new contributors through their first few PRs to the docs repo.
|
||||
- Helping new contributors create the more complex PRs they need to become Kubernetes members.
|
||||
- [Sponsoring contributors](/docs/contribute/advanced/#sponsor-a-new-contributor) on their path to becoming Kubernetes members.
|
||||
|
||||
Current New Contributor Ambassadors are announced at each SIG-Docs meeting, and in the [Kubernetes #sig-docs channel](https://kubernetes.slack.com).
|
||||
Current New Contributor Ambassadors are announced at each SIG-Docs meeting and in the [Kubernetes #sig-docs channel](https://kubernetes.slack.com).
|
||||
|
||||
## Sponsor a new contributor
|
||||
|
||||
@@ -122,7 +122,7 @@ Approvers must meet the following requirements to be a co-chair:
|
||||
- Understand SIG Docs workflows and tooling: git, Hugo, localization, blog subproject
|
||||
- Understand how other Kubernetes SIGs and repositories affect the SIG Docs
|
||||
workflow, including:
|
||||
[teams in k/org](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml),
|
||||
[teams in k/org](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml), the
|
||||
[process in k/community](https://github.com/kubernetes/community/tree/master/sig-docs),
|
||||
plugins in [k/test-infra](https://github.com/kubernetes/test-infra/), and the role of
|
||||
[SIG Architecture](https://github.com/kubernetes/community/tree/master/sig-architecture).
|
||||
|
||||
@@ -38,6 +38,7 @@ Anyone can write a blog post and submit it for review.
|
||||
- The components of Kubernetes are purposely modular, so tools that use existing integration points like CNI and CSI are on topic.
|
||||
- Posts about other CNCF projects may or may not be on topic. We recommend asking the blog team before submitting a draft.
|
||||
- Many CNCF projects have their own blog. These are often a better choice for posts. There are times of major feature or milestone for a CNCF project that users would be interested in reading on the Kubernetes blog.
|
||||
- Blog posts about contributing to the Kubernetes project should be in the [Kubernetes Contributors site](https://kubernetes.dev)
|
||||
- Blog posts should be original content
|
||||
- The official blog is not for repurposing existing content from a third party as new content.
|
||||
- The [license](https://github.com/kubernetes/website/blob/main/LICENSE) for the blog allows commercial use of the content for commercial purposes, but not the other way around.
|
||||
|
||||
@@ -29,7 +29,13 @@ Each day in a week-long shift as PR Wrangler:
|
||||
- You can also tag a [SIG](https://github.com/kubernetes/community/blob/master/sig-list.md) for a review by commenting `@kubernetes/<sig>-pr-reviews` on the PR.
|
||||
- Use the `/approve` comment to approve a PR for merging. Merge the PR when ready.
|
||||
- PRs should have a `/lgtm` comment from another member before merging.
|
||||
- Consider accepting technically accurate content that doesn't meet the [style guidelines](/docs/contribute/style/style-guide/). Open a new issue with the label `good first issue` to address style concerns.
|
||||
- Consider accepting technically accurate content that doesn't meet the
|
||||
[style guidelines](/docs/contribute/style/style-guide/). As you approve the change,
|
||||
open a new issue to address the style concern. You can usually write these style fix
|
||||
issues as [good first issues](https://kubernetes.dev/docs/guide/help-wanted/#good-first-issue).
|
||||
- Using style fixups as good first issues is a good way to ensure a supply of easier tasks
|
||||
to help onboard new contributors.
|
||||
|
||||
|
||||
### Helpful GitHub queries for wranglers
|
||||
|
||||
|
||||
@@ -121,7 +121,7 @@ finds issues that might need triage.
|
||||
`priority/important-longterm` | Do this within 6 months.
|
||||
`priority/backlog` | Deferrable indefinitely. Do when resources are available.
|
||||
`priority/awaiting-more-evidence` | Placeholder for a potentially good issue so it doesn't get lost.
|
||||
`help` or `good first issue` | Suitable for someone with very little Kubernetes or SIG Docs experience. See [Help Wanted and Good First Issue Labels](https://github.com/kubernetes/community/blob/master/contributors/guide/help-wanted.md) for more information.
|
||||
`help` or `good first issue` | Suitable for someone with very little Kubernetes or SIG Docs experience. See [Help Wanted and Good First Issue Labels](https://kubernetes.dev/docs/guide/help-wanted/) for more information.
|
||||
|
||||
{{< /table >}}
|
||||
|
||||
|
||||
@@ -30,9 +30,9 @@ mutating and validating (respectively)
|
||||
which are configured in the API.
|
||||
|
||||
Admission controllers may be "validating", "mutating", or both. Mutating
|
||||
controllers may modify the objects they admit; validating controllers may not.
|
||||
controllers may modify related objects to the requests they admit; validating controllers may not.
|
||||
|
||||
Admission controllers limit requests to create, delete, modify or connect to (proxy). They do not support read requests.
|
||||
Admission controllers limit requests to create, delete, modify objects or connect to proxy. They do not limit requests to read objects.
|
||||
|
||||
The admission control process proceeds in two phases. In the first phase,
|
||||
mutating admission controllers are run. In the second phase, validating
|
||||
|
||||
@@ -104,7 +104,7 @@ See [Managing Certificates](/docs/tasks/administer-cluster/certificates/) for ho
|
||||
### Static Token File
|
||||
|
||||
The API server reads bearer tokens from a file when given the `--token-auth-file=SOMEFILE` option on the command line. Currently, tokens last indefinitely, and the token list cannot be
|
||||
changed without restarting API server.
|
||||
changed without restarting the API server.
|
||||
|
||||
The token file is a csv file with a minimum of 3 columns: token, user name, user uid,
|
||||
followed by optional group names.
|
||||
|
||||
@@ -134,7 +134,7 @@ The output is similar to this:
|
||||
no
|
||||
```
|
||||
|
||||
Similarly, to check whether a Service Account named `dev-sa` in Namespace `dev`
|
||||
Similarly, to check whether a ServiceAccount named `dev-sa` in Namespace `dev`
|
||||
can list Pods in the Namespace `target`:
|
||||
|
||||
```bash
|
||||
|
||||
@@ -15,4 +15,4 @@ tags:
|
||||
|
||||
<!--more-->
|
||||
|
||||
Allows for more control over how sensitive information is used and reduces the risk of accidental exposure, including [encryption](/docs/tasks/administer-cluster/encrypt-data/#ensure-all-secrets-are-encrypted) at rest. A {{< glossary_tooltip text="Pod" term_id="pod" >}} references the secret as a file in a volume mount or by the kubelet pulling images for a pod. Secrets are great for confidential data and [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/) for non-confidential data.
|
||||
Allows for more control over how sensitive information is used and reduces the risk of accidental exposure. Secret values are encoded as base64 strings and stored unencrypted by default, but can be configured to be [encrypted at rest](/docs/tasks/administer-cluster/encrypt-data/#ensure-all-secrets-are-encrypted). A {{< glossary_tooltip text="Pod" term_id="pod" >}} references the secret as a file in a volume mount or by the kubelet pulling images for a pod. Secrets are great for confidential data and [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/) for non-confidential data.
|
||||
|
||||
@@ -311,8 +311,7 @@ kubectl logs -f my-pod # stream pod logs (stdout)
|
||||
kubectl logs -f my-pod -c my-container # stream pod container logs (stdout, multi-container case)
|
||||
kubectl logs -f -l name=myLabel --all-containers # stream all pods logs with label name=myLabel (stdout)
|
||||
kubectl run -i --tty busybox --image=busybox -- sh # Run pod as interactive shell
|
||||
kubectl run nginx --image=nginx -n
|
||||
mynamespace # Run pod nginx in a specific namespace
|
||||
kubectl run nginx --image=nginx -n mynamespace # Start a single instance of nginx pod in the namespace of mynamespace
|
||||
kubectl run nginx --image=nginx # Run pod nginx and write its spec into a file called pod.yaml
|
||||
--dry-run=client -o yaml > pod.yaml
|
||||
|
||||
|
||||
@@ -62,6 +62,16 @@ The Kubelet populates this label with the hostname. Note that the hostname can b
|
||||
This label is also used as part of the topology hierarchy. See [topology.kubernetes.io/zone](#topologykubernetesiozone) for more information.
|
||||
|
||||
|
||||
## kubernetes.io/change-cause {#change-cause}
|
||||
|
||||
Example: `kubernetes.io/change-cause=kubectl edit --record deployment foo`
|
||||
|
||||
Used on: All Objects
|
||||
|
||||
This annotation is a best guess at why something was changed.
|
||||
|
||||
It is populated when adding `--record` to a `kubectl` command that may change an object.
|
||||
|
||||
## controller.kubernetes.io/pod-deletion-cost {#pod-deletion-cost}
|
||||
|
||||
Example: `controller.kubernetes.io/pod-deletion-cost=10`
|
||||
|
||||
@@ -214,115 +214,7 @@ In each case, the credentials of the pod are used to communicate securely with t
|
||||
|
||||
## Accessing services running on the cluster
|
||||
|
||||
The previous section was about connecting the Kubernetes API server. This section is about
|
||||
connecting to other services running on Kubernetes cluster. In Kubernetes, the
|
||||
[nodes](/docs/concepts/architecture/nodes/),
|
||||
[pods](/docs/concepts/workloads/pods/) and
|
||||
[services](/docs/concepts/services-networking/service/) all have
|
||||
their own IPs. In many cases, the node IPs, pod IPs, and some service IPs on a cluster will not be
|
||||
routable, so they will not be reachable from a machine outside the cluster,
|
||||
such as your desktop machine.
|
||||
|
||||
### Ways to connect
|
||||
|
||||
You have several options for connecting to nodes, pods and services from outside the cluster:
|
||||
|
||||
- Access services through public IPs.
|
||||
- Use a service with type `NodePort` or `LoadBalancer` to make the service reachable outside
|
||||
the cluster. See the [services](/docs/concepts/services-networking/service/) and
|
||||
[kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) documentation.
|
||||
- Depending on your cluster environment, this may only expose the service to your corporate network,
|
||||
or it may expose it to the internet. Think about whether the service being exposed is secure.
|
||||
Does it do its own authentication?
|
||||
- Place pods behind services. To access one specific pod from a set of replicas, such as for debugging,
|
||||
place a unique label on the pod and create a new service which selects this label.
|
||||
- In most cases, it should not be necessary for application developer to directly access
|
||||
nodes via their nodeIPs.
|
||||
- Access services, nodes, or pods using the Proxy Verb.
|
||||
- Does apiserver authentication and authorization prior to accessing the remote service.
|
||||
Use this if the services are not secure enough to expose to the internet, or to gain
|
||||
access to ports on the node IP, or for debugging.
|
||||
- Proxies may cause problems for some web applications.
|
||||
- Only works for HTTP/HTTPS.
|
||||
- Described [here](#manually-constructing-apiserver-proxy-urls).
|
||||
- Access from a node or pod in the cluster.
|
||||
- Run a pod, and then connect to a shell in it using [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec).
|
||||
Connect to other nodes, pods, and services from that shell.
|
||||
- Some clusters may allow you to ssh to a node in the cluster. From there you may be able to
|
||||
access cluster services. This is a non-standard method, and will work on some clusters but
|
||||
not others. Browsers and other tools may or may not be installed. Cluster DNS may not work.
|
||||
|
||||
### Discovering builtin services
|
||||
|
||||
Typically, there are several services which are started on a cluster by kube-system. Get a list of these
|
||||
with the `kubectl cluster-info` command:
|
||||
|
||||
```shell
|
||||
kubectl cluster-info
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```
|
||||
Kubernetes master is running at https://104.197.5.247
|
||||
elasticsearch-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy
|
||||
kibana-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kibana-logging/proxy
|
||||
kube-dns is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kube-dns/proxy
|
||||
grafana is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy
|
||||
heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy
|
||||
```
|
||||
|
||||
This shows the proxy-verb URL for accessing each service.
|
||||
For example, this cluster has cluster-level logging enabled (using Elasticsearch), which can be reached
|
||||
at `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/` if suitable credentials are passed. Logging can also be reached through a kubectl proxy, for example at:
|
||||
`http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`.
|
||||
(See [Access Clusters Using the Kubernetes API](/docs/tasks/administer-cluster/access-cluster-api/) for how to pass credentials or use kubectl proxy.)
|
||||
|
||||
#### Manually constructing apiserver proxy URLs
|
||||
|
||||
As mentioned above, you use the `kubectl cluster-info` command to retrieve the service's proxy URL. To create proxy URLs that include service endpoints, suffixes, and parameters, you append to the service's proxy URL:
|
||||
`http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`service_name[:port_name]`*`/proxy`
|
||||
|
||||
If you haven't specified a name for your port, you don't have to specify *port_name* in the URL. You can also use the port number in place of the *port_name* for both named and unnamed ports.
|
||||
|
||||
By default, the API server proxies to your service using http. To use https, prefix the service name with `https:`:
|
||||
`http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`https:service_name:[port_name]`*`/proxy`
|
||||
|
||||
The supported formats for the name segment of the URL are:
|
||||
|
||||
* `<service_name>` - proxies to the default or unnamed port using http
|
||||
* `<service_name>:<port_name>` - proxies to the specified port name or port number using http
|
||||
* `https:<service_name>:` - proxies to the default or unnamed port using https (note the trailing colon)
|
||||
* `https:<service_name>:<port_name>` - proxies to the specified port name or port number using https
|
||||
|
||||
##### Examples
|
||||
|
||||
* To access the Elasticsearch service endpoint `_search?q=user:kimchy`, you would use: `http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy`
|
||||
* To access the Elasticsearch cluster health information `_cluster/health?pretty=true`, you would use: `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true`
|
||||
|
||||
```json
|
||||
{
|
||||
"cluster_name" : "kubernetes_logging",
|
||||
"status" : "yellow",
|
||||
"timed_out" : false,
|
||||
"number_of_nodes" : 1,
|
||||
"number_of_data_nodes" : 1,
|
||||
"active_primary_shards" : 5,
|
||||
"active_shards" : 5,
|
||||
"relocating_shards" : 0,
|
||||
"initializing_shards" : 0,
|
||||
"unassigned_shards" : 5
|
||||
}
|
||||
```
|
||||
|
||||
### Using web browsers to access services running on the cluster
|
||||
|
||||
You may be able to put an apiserver proxy url into the address bar of a browser. However:
|
||||
|
||||
- Web browsers cannot usually pass tokens, so you may need to use basic (password) auth. Apiserver can be configured to accept basic auth,
|
||||
but your cluster may not be configured to accept basic auth.
|
||||
- Some web apps may not work, particularly those with client side javascript that construct urls in a
|
||||
way that is unaware of the proxy path prefix.
|
||||
The previous section describes how to connect to the Kubernetes API server. For information about connecting to other services running on a Kubernetes cluster, see [Access Cluster Services.](/docs/tasks/access-application-cluster/access-cluster/)
|
||||
|
||||
## Requesting redirects
|
||||
|
||||
|
||||
+2
-2
@@ -70,7 +70,7 @@ The formatting can be controlled further by using the `range` operation to
|
||||
iterate over elements individually.
|
||||
|
||||
```shell
|
||||
kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\
|
||||
kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\
|
||||
sort
|
||||
```
|
||||
|
||||
@@ -80,7 +80,7 @@ To target only Pods matching a specific label, use the -l flag. The
|
||||
following matches only Pods with labels matching `app=nginx`.
|
||||
|
||||
```shell
|
||||
kubectl get pods --all-namespaces -o=jsonpath="{.items[*].spec.containers[*].image}" -l app=nginx
|
||||
kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" -l app=nginx
|
||||
```
|
||||
|
||||
## List Container images filtering by Pod namespace
|
||||
|
||||
@@ -86,7 +86,18 @@ See [Access Clusters Using the Kubernetes API](/docs/tasks/administer-cluster/ac
|
||||
As mentioned above, you use the `kubectl cluster-info` command to retrieve the service's proxy URL. To create proxy URLs that include service endpoints, suffixes, and parameters, you append to the service's proxy URL:
|
||||
`http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`[https:]service_name[:port_name]`*`/proxy`
|
||||
|
||||
If you haven't specified a name for your port, you don't have to specify *port_name* in the URL.
|
||||
If you haven't specified a name for your port, you don't have to specify *port_name* in the URL. You can also use the port number in place of the *port_name* for both named and unnamed ports.
|
||||
|
||||
By default, the API server proxies to your service using HTTP. To use HTTPS, prefix the service name with `https:`:
|
||||
`http://<kubernetes_master_address>/api/v1/namespaces/<namespace_name>/services/<service_name>/proxy`
|
||||
|
||||
The supported formats for the `<service_name>` segment of the URL are:
|
||||
|
||||
* `<service_name>` - proxies to the default or unnamed port using http
|
||||
* `<service_name>:<port_name>` - proxies to the specified port name or port number using http
|
||||
* `https:<service_name>:` - proxies to the default or unnamed port using https (note the trailing colon)
|
||||
* `https:<service_name>:<port_name>` - proxies to the specified port name or port number using https
|
||||
|
||||
|
||||
##### Examples
|
||||
|
||||
|
||||
@@ -78,10 +78,6 @@ Pick a control plane node that you wish to upgrade first. It must have the `/etc
|
||||
apt-mark unhold kubeadm && \
|
||||
apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 && \
|
||||
apt-mark hold kubeadm
|
||||
-
|
||||
# since apt-get version 1.1 you can also use the following method
|
||||
apt-get update && \
|
||||
apt-get install -y --allow-change-held-packages kubeadm={{< skew currentVersion >}}.x-00
|
||||
{{% /tab %}}
|
||||
{{% tab name="CentOS, RHEL or Fedora" %}}
|
||||
# replace x in {{< skew currentVersion >}}.x-0 with the latest patch version
|
||||
@@ -175,10 +171,6 @@ Also calling `kubeadm upgrade plan` and upgrading the CNI provider plugin is no
|
||||
apt-mark unhold kubelet kubectl && \
|
||||
apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \
|
||||
apt-mark hold kubelet kubectl
|
||||
-
|
||||
# since apt-get version 1.1 you can also use the following method
|
||||
apt-get update && \
|
||||
apt-get install -y --allow-change-held-packages kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00
|
||||
{{% /tab %}}
|
||||
{{% tab name="CentOS, RHEL or Fedora" %}}
|
||||
# replace x in {{< skew currentVersion >}}.x-0 with the latest patch version
|
||||
@@ -218,10 +210,6 @@ without compromising the minimum required capacity for running your workloads.
|
||||
apt-mark unhold kubeadm && \
|
||||
apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 && \
|
||||
apt-mark hold kubeadm
|
||||
-
|
||||
# since apt-get version 1.1 you can also use the following method
|
||||
apt-get update && \
|
||||
apt-get install -y --allow-change-held-packages kubeadm={{< skew currentVersion >}}.x-00
|
||||
{{% /tab %}}
|
||||
{{% tab name="CentOS, RHEL or Fedora" %}}
|
||||
# replace x in {{< skew currentVersion >}}.x-0 with the latest patch version
|
||||
@@ -256,10 +244,6 @@ without compromising the minimum required capacity for running your workloads.
|
||||
apt-mark unhold kubelet kubectl && \
|
||||
apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \
|
||||
apt-mark hold kubelet kubectl
|
||||
-
|
||||
# since apt-get version 1.1 you can also use the following method
|
||||
apt-get update && \
|
||||
apt-get install -y --allow-change-held-packages kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00
|
||||
{{% /tab %}}
|
||||
{{% tab name="CentOS, RHEL or Fedora" %}}
|
||||
# replace x in {{< skew currentVersion >}}.x-0 with the latest patch version
|
||||
|
||||
@@ -91,4 +91,13 @@ If you are using the sample manifest from the previous point, this will require
|
||||
Once enabled, node-local-dns Pods will run in the kube-system namespace on each of the cluster nodes. This Pod runs [CoreDNS](https://github.com/coredns/coredns) in cache mode, so all CoreDNS metrics exposed by the different plugins will be available on a per-node basis.
|
||||
|
||||
You can disable this feature by removing the DaemonSet, using `kubectl delete -f <manifest>` . You should also revert any changes you made to the kubelet configuration.
|
||||
|
||||
## StubDomains and Upstream server Configuration
|
||||
|
||||
StubDomains and upstream servers specified in the `kube-dns` ConfigMap in the `kube-system` namespace
|
||||
are automatically picked up by `node-local-dns` pods. The ConfigMap contents need to follow the format
|
||||
shown in [the example](/docs/tasks/administer-cluster/dns-custom-nameservers/#example-1).
|
||||
The `node-local-dns` ConfigMap can also be modified directly with the stubDomain configuration
|
||||
in the Corefile format. Some cloud providers might not allow modifying `node-local-dns` ConfigMap directly.
|
||||
In those cases, the `kube-dns` ConfigMap can be updated.
|
||||
|
||||
|
||||
@@ -11,7 +11,7 @@ min-kubernetes-server-version: v1.11
|
||||
{{< feature-state for_k8s_version="v1.22" state="deprecated" >}}
|
||||
|
||||
{{< caution >}}
|
||||
[Dynamic Kubelet Configuration](https://github.com/kubernetes/enhancements/issues/281)
|
||||
The [Dynamic Kubelet Configuration](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/281-dynamic-kubelet-configuration)
|
||||
feature is deprecated and should not be used.
|
||||
Please switch to alternative means distributing configuration to the Nodes of your cluster.
|
||||
{{< /caution >}}
|
||||
@@ -37,13 +37,10 @@ fields is available in the inline
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
You need to have a Kubernetes cluster.
|
||||
You also need kubectl v1.11 or higher, configured to communicate with your cluster.
|
||||
You also need `kubectl`, [installed](/docs/tasks/tools/#kubectl) and configured to communicate with your cluster.
|
||||
Make sure that you are using a version of `kubectl` that is
|
||||
[compatible](/releases/version-skew-policy/) with your cluster.
|
||||
{{< version-check >}}
|
||||
Your cluster API server version (eg v1.12) must be no more than one minor
|
||||
version away from the version of kubectl that you are using. For example,
|
||||
if your cluster is running v1.16 then you can use kubectl v1.15, v1.16
|
||||
or v1.17; other combinations
|
||||
[aren't supported](/docs/setup/release/version-skew-policy/#kubectl).
|
||||
|
||||
Some of the examples use the command line tool
|
||||
[jq](https://stedolan.github.io/jq/). You do not need `jq` to complete the task,
|
||||
@@ -383,9 +380,10 @@ internal failure, see Kubelet log for details | The kubelet encountered some int
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
- For more information on configuring the kubelet via a configuration file, see
|
||||
[Set kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file).
|
||||
- See the reference documentation for [`NodeConfigSource`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#nodeconfigsource-v1-core)
|
||||
- [Set kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file)
|
||||
explains the supported way to configure a kubelet.
|
||||
- See the reference documentation for Node, including the `configSource` field within
|
||||
the Node's [.spec](/docs/reference/kubernetes-api/cluster-resources/node-v1/#NodeSpec)
|
||||
- Learn more about kubelet configuration by checking the
|
||||
[`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/)
|
||||
reference.
|
||||
|
||||
@@ -71,6 +71,7 @@ The following sysctls are supported in the _safe_ set:
|
||||
- `net.ipv4.ip_local_port_range`,
|
||||
- `net.ipv4.tcp_syncookies`,
|
||||
- `net.ipv4.ping_group_range` (since Kubernetes 1.18).
|
||||
- `net.ipv4.ip_unprivileged_port_start` (since Kubernetes 1.22).
|
||||
|
||||
{{< note >}}
|
||||
The example `net.ipv4.tcp_syncookies` is not namespaced on Linux kernel version 4.4 or lower.
|
||||
|
||||
@@ -236,8 +236,14 @@ sudo rmdir /mnt/data
|
||||
|
||||
You can now close the shell to your Node.
|
||||
|
||||
## Mounting the same persistentVolume in two places
|
||||
|
||||
{{< codenew file="pods/storage/pv-duplicate.yaml" >}}
|
||||
|
||||
You can perform 2 volume mounts on your nginx container:
|
||||
|
||||
`/usr/share/nginx/html` for the static website
|
||||
`/etc/nginx/nginx.conf` for the default config
|
||||
|
||||
<!-- discussion -->
|
||||
|
||||
|
||||
@@ -73,6 +73,7 @@ isolation other than resource constraints imposed on the HostProcess user accoun
|
||||
filesystem or Hyper-V isolation are supported for HostProcess containers.
|
||||
- Volume mounts are supported and are mounted under the container volume. See [Volume Mounts](#volume-mounts)
|
||||
- As of 1.23, a limited set of host user accounts are available for HostProcess containers by default.
|
||||
- A limited set of host user accounts are available for HostProcess containers by default.
|
||||
See [Choosing a User Account](#choosing-a-user-account).
|
||||
- Resource limits (disk, memory, cpu count) are supported in the same fashion as processes
|
||||
on the host.
|
||||
|
||||
@@ -29,13 +29,13 @@ Kompose is released via GitHub on a three-week cycle, you can see all current re
|
||||
|
||||
```sh
|
||||
# Linux
|
||||
curl -L https://github.com/kubernetes/kompose/releases/download/v1.24.0/kompose-linux-amd64 -o kompose
|
||||
curl -L https://github.com/kubernetes/kompose/releases/download/v1.26.0/kompose-linux-amd64 -o kompose
|
||||
|
||||
# macOS
|
||||
curl -L https://github.com/kubernetes/kompose/releases/download/v1.24.0/kompose-darwin-amd64 -o kompose
|
||||
curl -L https://github.com/kubernetes/kompose/releases/download/v1.26.0/kompose-darwin-amd64 -o kompose
|
||||
|
||||
# Windows
|
||||
curl -L https://github.com/kubernetes/kompose/releases/download/v1.24.0/kompose-windows-amd64.exe -o kompose.exe
|
||||
curl -L https://github.com/kubernetes/kompose/releases/download/v1.26.0/kompose-windows-amd64.exe -o kompose.exe
|
||||
|
||||
chmod +x kompose
|
||||
sudo mv ./kompose /usr/local/bin/kompose
|
||||
@@ -207,8 +207,6 @@ you need is an existing `docker-compose.yml` file.
|
||||
|
||||
- CLI
|
||||
- [`kompose convert`](#kompose-convert)
|
||||
- [`kompose up`](#kompose-up)
|
||||
- [`kompose down`](#kompose-down)
|
||||
- Documentation
|
||||
- [Build and Push Docker Images](#build-and-push-docker-images)
|
||||
- [Alternative Conversions](#alternative-conversions)
|
||||
@@ -328,121 +326,7 @@ INFO OpenShift file "foo-buildconfig.yaml" created
|
||||
If you are manually pushing the OpenShift artifacts using ``oc create -f``, you need to ensure that you push the imagestream artifact before the buildconfig artifact, to workaround this OpenShift issue: https://github.com/openshift/origin/issues/4518 .
|
||||
{{< /note >}}
|
||||
|
||||
## `kompose up`
|
||||
|
||||
Kompose supports a straightforward way to deploy your "composed" application to Kubernetes or OpenShift via `kompose up`.
|
||||
|
||||
### Kubernetes `kompose up` example
|
||||
|
||||
```shell
|
||||
kompose --file ./examples/docker-guestbook.yml up
|
||||
```
|
||||
|
||||
```none
|
||||
We are going to create Kubernetes deployments and services for your Dockerized application.
|
||||
If you need different kind of resources, use the 'kompose convert' and 'kubectl apply -f' commands instead.
|
||||
|
||||
INFO Successfully created service: redis-master
|
||||
INFO Successfully created service: redis-slave
|
||||
INFO Successfully created service: frontend
|
||||
INFO Successfully created deployment: redis-master
|
||||
INFO Successfully created deployment: redis-slave
|
||||
INFO Successfully created deployment: frontend
|
||||
|
||||
Your application has been deployed to Kubernetes. You can run 'kubectl get deployment,svc,pods' for details.
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl get deployment,svc,pods
|
||||
```
|
||||
|
||||
```none
|
||||
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
|
||||
deployment.extensions/frontend 1 1 1 1 4m
|
||||
deployment.extensions/redis-master 1 1 1 1 4m
|
||||
deployment.extensions/redis-slave 1 1 1 1 4m
|
||||
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
service/frontend ClusterIP 10.0.174.12 <none> 80/TCP 4m
|
||||
service/kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 13d
|
||||
service/redis-master ClusterIP 10.0.202.43 <none> 6379/TCP 4m
|
||||
service/redis-slave ClusterIP 10.0.1.85 <none> 6379/TCP 4m
|
||||
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
pod/frontend-2768218532-cs5t5 1/1 Running 0 4m
|
||||
pod/redis-master-1432129712-63jn8 1/1 Running 0 4m
|
||||
pod/redis-slave-2504961300-nve7b 1/1 Running 0 4m
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
|
||||
- You must have a running Kubernetes cluster with a pre-configured kubectl context.
|
||||
- Only deployments and services are generated and deployed to Kubernetes. If you need different kind of resources, use the `kompose convert` and `kubectl apply -f` commands instead.
|
||||
{{< /note >}}
|
||||
|
||||
### OpenShift `kompose up` example
|
||||
|
||||
```shell
|
||||
kompose --file ./examples/docker-guestbook.yml --provider openshift up
|
||||
```
|
||||
|
||||
```none
|
||||
We are going to create OpenShift DeploymentConfigs and Services for your Dockerized application.
|
||||
If you need different kind of resources, use the 'kompose convert' and 'oc create -f' commands instead.
|
||||
|
||||
INFO Successfully created service: redis-slave
|
||||
INFO Successfully created service: frontend
|
||||
INFO Successfully created service: redis-master
|
||||
INFO Successfully created deployment: redis-slave
|
||||
INFO Successfully created ImageStream: redis-slave
|
||||
INFO Successfully created deployment: frontend
|
||||
INFO Successfully created ImageStream: frontend
|
||||
INFO Successfully created deployment: redis-master
|
||||
INFO Successfully created ImageStream: redis-master
|
||||
|
||||
Your application has been deployed to OpenShift. You can run 'oc get dc,svc,is' for details.
|
||||
```
|
||||
|
||||
```shell
|
||||
oc get dc,svc,is
|
||||
```
|
||||
|
||||
```none
|
||||
NAME REVISION DESIRED CURRENT TRIGGERED BY
|
||||
dc/frontend 0 1 0 config,image(frontend:v4)
|
||||
dc/redis-master 0 1 0 config,image(redis-master:e2e)
|
||||
dc/redis-slave 0 1 0 config,image(redis-slave:v1)
|
||||
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
svc/frontend 172.30.46.64 <none> 80/TCP 8s
|
||||
svc/redis-master 172.30.144.56 <none> 6379/TCP 8s
|
||||
svc/redis-slave 172.30.75.245 <none> 6379/TCP 8s
|
||||
NAME DOCKER REPO TAGS UPDATED
|
||||
is/frontend 172.30.12.200:5000/fff/frontend
|
||||
is/redis-master 172.30.12.200:5000/fff/redis-master
|
||||
is/redis-slave 172.30.12.200:5000/fff/redis-slave v1
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
You must have a running OpenShift cluster with a pre-configured `oc` context (`oc login`).
|
||||
{{< /note >}}
|
||||
|
||||
## `kompose down`
|
||||
|
||||
Once you have deployed "composed" application to Kubernetes, `kompose down` will help you to take the application out by deleting its deployments and services. If you need to remove other resources, use the 'kubectl' command.
|
||||
|
||||
```shell
|
||||
kompose --file docker-guestbook.yml down
|
||||
INFO Successfully deleted service: redis-master
|
||||
INFO Successfully deleted deployment: redis-master
|
||||
INFO Successfully deleted service: redis-slave
|
||||
INFO Successfully deleted deployment: redis-slave
|
||||
INFO Successfully deleted service: frontend
|
||||
INFO Successfully deleted deployment: frontend
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
You must have a running Kubernetes cluster with a pre-configured `kubectl` context.
|
||||
{{< /note >}}
|
||||
|
||||
## Build and Push Docker Images
|
||||
|
||||
|
||||
+13
-3
@@ -1038,8 +1038,8 @@ procedure.
|
||||
|
||||
*Option 1:* Use the Storage Version Migrator
|
||||
|
||||
1. Run the [storage Version migrator](https://github.com/kubernetes-sigs/kube-storage-version-migrator)
|
||||
2. Remove the old version from the CustomResourceDefinition `status.storedVersions` field.
|
||||
1. Run the [storage Version migrator](https://github.com/kubernetes-sigs/kube-storage-version-migrator)
|
||||
2. Remove the old version from the CustomResourceDefinition `status.storedVersions` field.
|
||||
|
||||
*Option 2:* Manually upgrade the existing objects to a new stored version
|
||||
|
||||
@@ -1050,6 +1050,16 @@ The following is an example procedure to upgrade from `v1beta1` to `v1`.
|
||||
2. Write an upgrade procedure to list all existing objects and write them with
|
||||
the same content. This forces the backend to write objects in the current
|
||||
storage version, which is `v1`.
|
||||
2. Remove `v1beta1` from the CustomResourceDefinition `status.storedVersions` field.
|
||||
3. Remove `v1beta1` from the CustomResourceDefinition `status.storedVersions` field.
|
||||
|
||||
{{< note >}}
|
||||
The `kubectl` tool currently cannot be used to edit or patch the `status` subresource on a CRD: see the [Kubectl Subresource Support KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-cli/2590-kubectl-subresource) for more details.
|
||||
|
||||
The easier way to patch the status subresource from the CLI is directly interacting with the API server using the `curl` tool, in this example:
|
||||
```bash
|
||||
kubectl proxy &
|
||||
curl --header "Content-Type: application/json-patch+json" \
|
||||
--request PATCH http://localhost:8001/apis/apiextensions.k8s.io/v1/customresourcedefinitions/<your CRD name here>/status \
|
||||
--data '[{"op": "replace", "path": "/status/storedVersions", "value":["v1"]}]'
|
||||
```
|
||||
{{< /note >}}
|
||||
|
||||
@@ -178,13 +178,13 @@ First, copy and paste the following template of a Job object, into a file called
|
||||
|
||||
|
||||
```liquid
|
||||
{%- set params = [{ "name": "apple", "url": "http://dbpedia.org/resource/Apple", },
|
||||
{% set params = [{ "name": "apple", "url": "http://dbpedia.org/resource/Apple", },
|
||||
{ "name": "banana", "url": "http://dbpedia.org/resource/Banana", },
|
||||
{ "name": "cherry", "url": "http://dbpedia.org/resource/Cherry" }]
|
||||
%}
|
||||
{%- for p in params %}
|
||||
{%- set name = p["name"] %}
|
||||
{%- set url = p["url"] %}
|
||||
{% for p in params %}
|
||||
{% set name = p["name"] %}
|
||||
{% set url = p["url"] %}
|
||||
---
|
||||
apiVersion: batch/v1
|
||||
kind: Job
|
||||
@@ -204,7 +204,7 @@ spec:
|
||||
image: busybox
|
||||
command: ["sh", "-c", "echo Processing URL {{ url }} && sleep 5"]
|
||||
restartPolicy: Never
|
||||
{%- endfor %}
|
||||
{% endfor %}
|
||||
```
|
||||
|
||||
The above template defines two parameters for each Job object using a list of
|
||||
|
||||
@@ -525,6 +525,45 @@ stops adjusting the target (and sets the `ScalingActive` Condition on itself
|
||||
to `false`) until you reactivate it by manually adjusting the target's desired
|
||||
replica count or HPA's minimum replica count.
|
||||
|
||||
### Migrating Deployments and StatefulSets to horizontal autoscaling
|
||||
|
||||
When an HPA is enabled, it is recommended that the value of `spec.replicas` of
|
||||
the Deployment and / or StatefulSet be removed from their
|
||||
{{< glossary_tooltip text="manifest(s)" term_id="manifest" >}}. If this isn't done, any time
|
||||
a change to that object is applied, for example via `kubectl apply -f
|
||||
deployment.yaml`, this will instruct Kubernetes to scale the current number of Pods
|
||||
to the value of the `spec.replicas` key. This may not be
|
||||
desired and could be troublesome when an HPA is active.
|
||||
|
||||
Keep in mind that the removal of `spec.replicas` may incur a one-time
|
||||
degradation of Pod counts as the default value of this key is 1 (reference
|
||||
[Deployment Replicas](/docs/concepts/workloads/controllers/deployment#replicas).
|
||||
Upon the update, all Pods except 1 will begin their termination procedures. Any
|
||||
deployment application afterwards will behave as normal and respect a rolling
|
||||
update configuration as desired. You can avoid this degradation by choosing one of the following two
|
||||
methods based on how you are modifying your deployments:
|
||||
|
||||
{{< tabs name="fix_replicas_instructions" >}}
|
||||
{{% tab name="Client Side Apply (this is the default)" %}}
|
||||
|
||||
1. `kubectl apply edit-last-applied deployment/<deployment_name>`
|
||||
2. In the editor, remove `spec.replicas`. When you save and exit the editor, `kubectl`
|
||||
applies the update. No changes to Pod counts happen at this step.
|
||||
3. You can now remove `spec.replicas` from the manifest. If you use source code management,
|
||||
also commit your changes or take whatever other steps for revising the source code
|
||||
are appropriate for how you track updates.
|
||||
4. From here on out you can run `kubectl apply -f deployment.yaml`
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="Server Side Apply" %}}
|
||||
|
||||
When using the [Server-Side Apply](/docs/reference/using-api/server-side-apply/)
|
||||
you can follow the [transferring ownership](/docs/reference/using-api/server-side-apply/#transferring-ownership)
|
||||
guidelines, which cover this exact use case.
|
||||
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
If you configure autoscaling in your cluster, you may also want to consider running a
|
||||
|
||||
Reference in New Issue
Block a user