Merge master into dev-1.21 to keep in sync
This commit is contained in:
Rey Lejano
@@ -242,7 +242,7 @@ checks the state of each node every `--node-monitor-period` seconds.
|
||||
Heartbeats, sent by Kubernetes nodes, help determine the availability of a node.
|
||||
|
||||
There are two forms of heartbeats: updates of `NodeStatus` and the
|
||||
[Lease object](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#lease-v1-coordination-k8s-io).
|
||||
[Lease object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#lease-v1-coordination-k8s-io).
|
||||
Each Node has an associated Lease object in the `kube-node-lease`
|
||||
{{< glossary_tooltip term_id="namespace" text="namespace">}}.
|
||||
Lease is a lightweight resource, which improves the performance
|
||||
|
||||
@@ -527,5 +527,5 @@ When you enable the API Priority and Fairness feature, the kube-apiserver serves
|
||||
|
||||
For background information on design details for API priority and fairness, see
|
||||
the [enhancement proposal](https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/20190228-priority-and-fairness.md).
|
||||
You can make suggestions and feature requests via [SIG API
|
||||
Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery).
|
||||
You can make suggestions and feature requests via [SIG API Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery)
|
||||
or the feature's [slack channel](http://kubernetes.slack.com/messages/api-priority-and-fairness).
|
||||
|
||||
@@ -69,6 +69,8 @@ A Service can be made to span multiple Deployments by omitting release-specific
|
||||
|
||||
A desired state of an object is described by a Deployment, and if changes to that spec are _applied_, the deployment controller changes the actual state to the desired state at a controlled rate.
|
||||
|
||||
- Use the [Kubernetes common labels](/docs/concepts/overview/working-with-objects/common-labels/) for common use cases. These standardized labels enrich the metadata in a way that allows tools, including `kubectl` and [dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard), to work in an interoperable way.
|
||||
|
||||
- You can manipulate labels for debugging. Because Kubernetes controllers (such as ReplicaSet) and Services match to Pods using selector labels, removing the relevant labels from a Pod will stop it from being considered by a controller or from being served traffic by a Service. If you remove the labels of an existing Pod, its controller will create a new Pod to take its place. This is a useful way to debug a previously "live" Pod in a "quarantine" environment. To interactively remove or add labels, use [`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands#label).
|
||||
|
||||
## Container Images
|
||||
|
||||
@@ -776,7 +776,7 @@ these pods.
|
||||
The `imagePullSecrets` field is a list of references to secrets in the same namespace.
|
||||
You can use an `imagePullSecrets` to pass a secret that contains a Docker (or other) image registry
|
||||
password to the kubelet. The kubelet uses this information to pull a private image on behalf of your Pod.
|
||||
See the [PodSpec API](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#podspec-v1-core) for more information about the `imagePullSecrets` field.
|
||||
See the [PodSpec API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) for more information about the `imagePullSecrets` field.
|
||||
|
||||
#### Manually specifying an imagePullSecret
|
||||
|
||||
|
||||
@@ -37,10 +37,10 @@ but with different settings.
|
||||
|
||||
Ensure the RuntimeClass feature gate is enabled (it is by default). See [Feature
|
||||
Gates](/docs/reference/command-line-tools-reference/feature-gates/) for an explanation of enabling
|
||||
feature gates. The `RuntimeClass` feature gate must be enabled on apiservers _and_ kubelets.
|
||||
feature gates. The `RuntimeClass` feature gate must be enabled on API server _and_ kubelets.
|
||||
|
||||
1. Configure the CRI implementation on nodes (runtime dependent)
|
||||
2. Create the corresponding RuntimeClass resources
|
||||
1. Configure the CRI implementation on nodes (runtime dependent).
|
||||
2. Create the corresponding RuntimeClass resources.
|
||||
|
||||
### 1. Configure the CRI implementation on nodes
|
||||
|
||||
@@ -51,7 +51,7 @@ CRI implementation for how to configure.
|
||||
{{< note >}}
|
||||
RuntimeClass assumes a homogeneous node configuration across the cluster by default (which means
|
||||
that all nodes are configured the same way with respect to container runtimes). To support
|
||||
heterogenous node configurations, see [Scheduling](#scheduling) below.
|
||||
heterogeneous node configurations, see [Scheduling](#scheduling) below.
|
||||
{{< /note >}}
|
||||
|
||||
The configurations have a corresponding `handler` name, referenced by the RuntimeClass. The
|
||||
@@ -98,7 +98,7 @@ spec:
|
||||
# ...
|
||||
```
|
||||
|
||||
This will instruct the Kubelet to use the named RuntimeClass to run this pod. If the named
|
||||
This will instruct the kubelet to use the named RuntimeClass to run this pod. If the named
|
||||
RuntimeClass does not exist, or the CRI cannot run the corresponding handler, the pod will enter the
|
||||
`Failed` terminal [phase](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase). Look for a
|
||||
corresponding [event](/docs/tasks/debug-application-cluster/debug-application-introspection/) for an
|
||||
@@ -144,7 +144,7 @@ See CRI-O's [config documentation](https://raw.githubusercontent.com/cri-o/cri-o
|
||||
|
||||
{{< feature-state for_k8s_version="v1.16" state="beta" >}}
|
||||
|
||||
As of Kubernetes v1.16, RuntimeClass includes support for heterogenous clusters through its
|
||||
As of Kubernetes v1.16, RuntimeClass includes support for heterogeneous clusters through its
|
||||
`scheduling` fields. Through the use of these fields, you can ensure that pods running with this
|
||||
RuntimeClass are scheduled to nodes that support it. To use the scheduling support, you must have
|
||||
the [RuntimeClass admission controller](/docs/reference/access-authn-authz/admission-controllers/#runtimeclass)
|
||||
|
||||
@@ -201,7 +201,7 @@ Monitoring agents for device plugin resources can be deployed as a daemon, or as
|
||||
The canonical directory `/var/lib/kubelet/pod-resources` requires privileged access, so monitoring
|
||||
agents must run in a privileged security context. If a device monitoring agent is running as a
|
||||
DaemonSet, `/var/lib/kubelet/pod-resources` must be mounted as a
|
||||
{{< glossary_tooltip term_id="volume" >}} in the plugin's
|
||||
{{< glossary_tooltip term_id="volume" >}} in the device monitoring agent's
|
||||
[PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).
|
||||
|
||||
Support for the "PodResources service" requires `KubeletPodResources` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) to be enabled.
|
||||
|
||||
@@ -159,7 +159,7 @@ This option is provided to the network-plugin; currently **only kubenet supports
|
||||
## Usage Summary
|
||||
|
||||
* `--network-plugin=cni` specifies that we use the `cni` network plugin with actual CNI plugin binaries located in `--cni-bin-dir` (default `/opt/cni/bin`) and CNI plugin configuration located in `--cni-conf-dir` (default `/etc/cni/net.d`).
|
||||
* `--network-plugin=kubenet` specifies that we use the `kubenet` network plugin with CNI `bridge` and `host-local` plugins placed in `/opt/cni/bin` or `cni-bin-dir`.
|
||||
* `--network-plugin=kubenet` specifies that we use the `kubenet` network plugin with CNI `bridge`, `lo` and `host-local` plugins placed in `/opt/cni/bin` or `cni-bin-dir`.
|
||||
* `--network-plugin-mtu=9001` specifies the MTU to use, currently only used by the `kubenet` network plugin.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
@@ -246,7 +246,7 @@ as at least one already-running pod that has a label with key "security" and val
|
||||
on node N if node N has a label with key `topology.kubernetes.io/zone` and some value V
|
||||
such that there is at least one node in the cluster with key `topology.kubernetes.io/zone` and
|
||||
value V that is running a pod that has a label with key "security" and value "S1".) The pod anti-affinity
|
||||
rule says that the pod cannot be scheduled onto a node if that node is in the same zone as a pod with
|
||||
rule says that the pod should not be scheduled onto a node if that node is in the same zone as a pod with
|
||||
label having key "security" and value "S2". See the
|
||||
[design doc](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)
|
||||
for many more examples of pod affinity and anti-affinity, both the `requiredDuringSchedulingIgnoredDuringExecution`
|
||||
|
||||
@@ -194,4 +194,4 @@ from source in the meantime.
|
||||
|
||||
|
||||
* [RuntimeClass](/docs/concepts/containers/runtime-class/)
|
||||
* [PodOverhead Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)
|
||||
* [PodOverhead Design](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead)
|
||||
|
||||
@@ -82,7 +82,7 @@ requested the score value must be reversed as follows.
|
||||
```yaml
|
||||
shape:
|
||||
- utilization: 0
|
||||
score: 100
|
||||
score: 10
|
||||
- utilization: 100
|
||||
score: 0
|
||||
```
|
||||
|
||||
@@ -26,6 +26,7 @@ Kubernetes as a project supports and maintains [AWS](https://github.com/kubernet
|
||||
* [AKS Application Gateway Ingress Controller](https://azure.github.io/application-gateway-kubernetes-ingress/) is an ingress controller that configures the [Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview).
|
||||
* [Ambassador](https://www.getambassador.io/) API Gateway is an [Envoy](https://www.envoyproxy.io)-based ingress
|
||||
controller.
|
||||
* [Avi Kubernetes Operator](https://github.com/vmware/load-balancer-and-ingress-services-for-kubernetes) provides L4-L7 load-balancing using [VMware NSX Advanced Load Balancer](https://avinetworks.com/).
|
||||
* The [Citrix ingress controller](https://github.com/citrix/citrix-k8s-ingress-controller#readme) works with
|
||||
Citrix Application Delivery Controller.
|
||||
* [Contour](https://projectcontour.io/) is an [Envoy](https://www.envoyproxy.io/) based ingress controller.
|
||||
|
||||
@@ -35,6 +35,8 @@ Pods become isolated by having a NetworkPolicy that selects them. Once there is
|
||||
|
||||
Network policies do not conflict; they are additive. If any policy or policies select a pod, the pod is restricted to what is allowed by the union of those policies' ingress/egress rules. Thus, order of evaluation does not affect the policy result.
|
||||
|
||||
For a network flow between two pods to be allowed, both the egress policy on the source pod and the ingress policy on the destination pod need to allow the traffic. If either the egress policy on the source, or the ingress policy on the destination denies the traffic, the traffic will be denied.
|
||||
|
||||
## The NetworkPolicy resource {#networkpolicy-resource}
|
||||
|
||||
See the [NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) reference for a full definition of the resource.
|
||||
|
||||
@@ -311,7 +311,7 @@ If expanding underlying storage fails, the cluster administrator can manually re
|
||||
PersistentVolume types are implemented as plugins. Kubernetes currently supports the following plugins:
|
||||
|
||||
* [`awsElasticBlockStore`](/docs/concepts/storage/volumes/#awselasticblockstore) - AWS Elastic Block Store (EBS)
|
||||
* [`azureDisk`](/docs/concepts/sotrage/volumes/#azuredisk) - Azure Disk
|
||||
* [`azureDisk`](/docs/concepts/storage/volumes/#azuredisk) - Azure Disk
|
||||
* [`azureFile`](/docs/concepts/storage/volumes/#azurefile) - Azure File
|
||||
* [`cephfs`](/docs/concepts/storage/volumes/#cephfs) - CephFS volume
|
||||
* [`cinder`](/docs/concepts/storage/volumes/#cinder) - Cinder (OpenStack block storage)
|
||||
|
||||
@@ -72,7 +72,7 @@ used for provisioning VolumeSnapshots. This field must be specified.
|
||||
|
||||
### DeletionPolicy
|
||||
|
||||
Volume snapshot classes have a deletionPolicy. It enables you to configure what happens to a VolumeSnapshotContent when the VolumeSnapshot object it is bound to is to be deleted. The deletionPolicy of a volume snapshot can either be `Retain` or `Delete`. This field must be specified.
|
||||
Volume snapshot classes have a deletionPolicy. It enables you to configure what happens to a VolumeSnapshotContent when the VolumeSnapshot object it is bound to is to be deleted. The deletionPolicy of a volume snapshot class can either be `Retain` or `Delete`. This field must be specified.
|
||||
|
||||
If the deletionPolicy is `Delete`, then the underlying storage snapshot will be deleted along with the VolumeSnapshotContent object. If the deletionPolicy is `Retain`, then both the underlying snapshot and VolumeSnapshotContent remain.
|
||||
|
||||
|
||||
@@ -150,14 +150,17 @@ curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-rep
|
||||
```
|
||||
|
||||
kubectl also supports cascading deletion.
|
||||
To delete dependents automatically using kubectl, set `--cascade` to true. To
|
||||
orphan dependents, set `--cascade` to false. The default value for `--cascade`
|
||||
is true.
|
||||
|
||||
To delete dependents in the foreground using kubectl, set `--cascade=foreground`. To
|
||||
orphan dependents, set `--cascade=orphan`.
|
||||
|
||||
The default behavior is to delete the dependents in the background which is the
|
||||
behavior when `--cascade` is omitted or explicitly set to `background`.
|
||||
|
||||
Here's an example that orphans the dependents of a ReplicaSet:
|
||||
|
||||
```shell
|
||||
kubectl delete replicaset my-repset --cascade=false
|
||||
kubectl delete replicaset my-repset --cascade=orphan
|
||||
```
|
||||
|
||||
### Additional note on Deployments
|
||||
|
||||
@@ -283,7 +283,7 @@ curl -X DELETE 'localhost:8080/apis/apps/v1/namespaces/default/replicasets/fron
|
||||
|
||||
### Deleting just a ReplicaSet
|
||||
|
||||
You can delete a ReplicaSet without affecting any of its Pods using [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) with the `--cascade=false` option.
|
||||
You can delete a ReplicaSet without affecting any of its Pods using [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) with the `--cascade=orphan` option.
|
||||
When using the REST API or the `client-go` library, you must set `propagationPolicy` to `Orphan`.
|
||||
For example:
|
||||
```shell
|
||||
|
||||
@@ -15,8 +15,7 @@ card:
|
||||
_Pods_ are the smallest deployable units of computing that you can create and manage in Kubernetes.
|
||||
|
||||
A _Pod_ (as in a pod of whales or pea pod) is a group of one or more
|
||||
{{< glossary_tooltip text="containers" term_id="container" >}}, with shared storage/network resources, and a specification
|
||||
for how to run the containers. A Pod's contents are always co-located and
|
||||
{{< glossary_tooltip text="containers" term_id="container" >}}, with shared storage and network resources, and a specification for how to run the containers. A Pod's contents are always co-located and
|
||||
co-scheduled, and run in a shared context. A Pod models an
|
||||
application-specific "logical host": it contains one or more application
|
||||
containers which are relatively tightly coupled.
|
||||
@@ -295,9 +294,10 @@ but cannot be controlled from there.
|
||||
object definition describes the object in detail.
|
||||
* [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) explains common layouts for Pods with more than one container.
|
||||
|
||||
To understand the context for why Kubernetes wraps a common Pod API in other resources (such as {{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}} or {{< glossary_tooltip text="Deployments" term_id="deployment" >}}, you can read about the prior art, including:
|
||||
* [Aurora](https://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)
|
||||
* [Borg](https://research.google.com/pubs/pub43438.html)
|
||||
* [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html)
|
||||
* [Omega](https://research.google/pubs/pub41684/)
|
||||
* [Tupperware](https://engineering.fb.com/data-center-engineering/tupperware/).
|
||||
To understand the context for why Kubernetes wraps a common Pod API in other resources (such as {{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}} or {{< glossary_tooltip text="Deployments" term_id="deployment" >}}), you can read about the prior art, including:
|
||||
|
||||
* [Aurora](https://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)
|
||||
* [Borg](https://research.google.com/pubs/pub43438.html)
|
||||
* [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html)
|
||||
* [Omega](https://research.google/pubs/pub41684/)
|
||||
* [Tupperware](https://engineering.fb.com/data-center-engineering/tupperware/).
|
||||
|
||||
@@ -49,7 +49,7 @@ Cluster administrator actions include:
|
||||
|
||||
- [Draining a node](/docs/tasks/administer-cluster/safely-drain-node/) for repair or upgrade.
|
||||
- Draining a node from a cluster to scale the cluster down (learn about
|
||||
[Cluster Autoscaling](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaler)
|
||||
[Cluster Autoscaling](https://github.com/kubernetes/autoscaler/#readme)
|
||||
).
|
||||
- Removing a pod from a node to permit something else to fit on that node.
|
||||
|
||||
|
||||
@@ -133,6 +133,7 @@ You can start this Pod by running:
|
||||
```shell
|
||||
kubectl apply -f myapp.yaml
|
||||
```
|
||||
The output is similar to this:
|
||||
```
|
||||
pod/myapp-pod created
|
||||
```
|
||||
@@ -141,6 +142,7 @@ And check on its status with:
|
||||
```shell
|
||||
kubectl get -f myapp.yaml
|
||||
```
|
||||
The output is similar to this:
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
myapp-pod 0/1 Init:0/2 0 6m
|
||||
@@ -150,6 +152,7 @@ or for more details:
|
||||
```shell
|
||||
kubectl describe -f myapp.yaml
|
||||
```
|
||||
The output is similar to this:
|
||||
```
|
||||
Name: myapp-pod
|
||||
Namespace: default
|
||||
@@ -224,6 +227,7 @@ To create the `mydb` and `myservice` services:
|
||||
```shell
|
||||
kubectl apply -f services.yaml
|
||||
```
|
||||
The output is similar to this:
|
||||
```
|
||||
service/myservice created
|
||||
service/mydb created
|
||||
@@ -235,6 +239,7 @@ Pod moves into the Running state:
|
||||
```shell
|
||||
kubectl get -f myapp.yaml
|
||||
```
|
||||
The output is similar to this:
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
myapp-pod 1/1 Running 0 9m
|
||||
@@ -319,11 +324,9 @@ reasons:
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* Read about [creating a Pod that has an init container](/docs/tasks/configure-pod-container/configure-pod-initialization/#create-a-pod-that-has-an-init-container)
|
||||
* Learn how to [debug init containers](/docs/tasks/debug-application-cluster/debug-init-containers/)
|
||||
|
||||
|
||||
|
||||
@@ -85,6 +85,13 @@ Value | Description
|
||||
`Failed` | All containers in the Pod have terminated, and at least one container has terminated in failure. That is, the container either exited with non-zero status or was terminated by the system.
|
||||
`Unknown` | For some reason the state of the Pod could not be obtained. This phase typically occurs due to an error in communicating with the node where the Pod should be running.
|
||||
|
||||
{{< note >}}
|
||||
When a Pod is being deleted, it is shown as `Terminating` by some kubectl commands.
|
||||
This `Terminating` status is not one of the Pod phases.
|
||||
A Pod is granted a term to terminate gracefully, which defaults to 30 seconds.
|
||||
You can use the flag `--force` to [terminate a Pod by force](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination-forced).
|
||||
{{< /note >}}
|
||||
|
||||
If a node dies or is disconnected from the rest of the cluster, Kubernetes
|
||||
applies a policy for setting the `phase` of all Pods on the lost node to Failed.
|
||||
|
||||
@@ -325,7 +332,7 @@ a time longer than the liveness interval would allow.
|
||||
If your container usually starts in more than
|
||||
`initialDelaySeconds + failureThreshold × periodSeconds`, you should specify a
|
||||
startup probe that checks the same endpoint as the liveness probe. The default for
|
||||
`periodSeconds` is 30s. You should then set its `failureThreshold` high enough to
|
||||
`periodSeconds` is 10s. You should then set its `failureThreshold` high enough to
|
||||
allow the container to start, without changing the default values of the liveness
|
||||
probe. This helps to protect against deadlocks.
|
||||
|
||||
|
||||
@@ -6,4 +6,4 @@ This is an **example** content file inside the **includes** leaf bundle.
|
||||
|
||||
{{< note >}}
|
||||
Included content files can also contain shortcodes.
|
||||
{{< /note >}}
|
||||
{{< /note >}}
|
||||
|
||||
@@ -1,33 +1,30 @@
|
||||
---
|
||||
approvers:
|
||||
- chenopis
|
||||
title: Custom Hugo Shortcodes
|
||||
content_type: concept
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
This page explains the custom Hugo shortcodes that can be used in Kubernetes markdown documentation.
|
||||
This page explains the custom Hugo shortcodes that can be used in Kubernetes Markdown documentation.
|
||||
|
||||
Read more about shortcodes in the [Hugo documentation](https://gohugo.io/content-management/shortcodes).
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Feature state
|
||||
|
||||
In a markdown page (`.md` file) on this site, you can add a shortcode to display version and state of the documented feature.
|
||||
In a Markdown page (`.md` file) on this site, you can add a shortcode to display version and state of the documented feature.
|
||||
|
||||
### Feature state demo
|
||||
|
||||
Below is a demo of the feature state snippet, which displays the feature as stable in Kubernetes version 1.10.
|
||||
Below is a demo of the feature state snippet, which displays the feature as stable in the latest Kubernetes version.
|
||||
|
||||
```
|
||||
{{</* feature-state for_k8s_version="v1.10" state="stable" */>}}
|
||||
{{</* feature-state state="stable" */>}}
|
||||
```
|
||||
|
||||
Renders to:
|
||||
|
||||
{{< feature-state for_k8s_version="v1.10" state="stable" >}}
|
||||
{{< feature-state state="stable" >}}
|
||||
|
||||
The valid values for `state` are:
|
||||
|
||||
@@ -38,62 +35,22 @@ The valid values for `state` are:
|
||||
|
||||
### Feature state code
|
||||
|
||||
The displayed Kubernetes version defaults to that of the page or the site. This can be changed by passing the <code>for_k8s_version</code> shortcode parameter.
|
||||
The displayed Kubernetes version defaults to that of the page or the site. You can change the
|
||||
feature state version by passing the `for_k8s_version` shortcode parameter. For example:
|
||||
|
||||
```
|
||||
{{</* feature-state for_k8s_version="v1.10" state="stable" */>}}
|
||||
{{</* feature-state for_k8s_version="v1.10" state="beta" */>}}
|
||||
```
|
||||
|
||||
Renders to:
|
||||
|
||||
{{< feature-state for_k8s_version="v1.10" state="stable" >}}
|
||||
|
||||
#### Alpha feature
|
||||
|
||||
```
|
||||
{{</* feature-state state="alpha" */>}}
|
||||
```
|
||||
|
||||
Renders to:
|
||||
|
||||
{{< feature-state state="alpha" >}}
|
||||
|
||||
#### Beta feature
|
||||
|
||||
```
|
||||
{{</* feature-state state="beta" */>}}
|
||||
```
|
||||
|
||||
Renders to:
|
||||
|
||||
{{< feature-state state="beta" >}}
|
||||
|
||||
#### Stable feature
|
||||
|
||||
```
|
||||
{{</* feature-state state="stable" */>}}
|
||||
```
|
||||
|
||||
Renders to:
|
||||
|
||||
{{< feature-state state="stable" >}}
|
||||
|
||||
#### Deprecated feature
|
||||
|
||||
```
|
||||
{{</* feature-state state="deprecated" */>}}
|
||||
```
|
||||
|
||||
Renders to:
|
||||
|
||||
{{< feature-state state="deprecated" >}}
|
||||
{{< feature-state for_k8s_version="v1.10" state="beta" >}}
|
||||
|
||||
## Glossary
|
||||
|
||||
There are two glossary tooltips.
|
||||
There are two glossary shortcodes: `glossary_tooltip` and `glossary_definition`.
|
||||
|
||||
You can reference glossary terms with an inclusion that automatically updates and replaces content with the relevant links from [our glossary](/docs/reference/glossary/). When the term is moused-over by someone
|
||||
using the online documentation, the glossary entry displays a tooltip.
|
||||
You can reference glossary terms with an inclusion that automatically updates and replaces content with the relevant links from [our glossary](/docs/reference/glossary/). When the glossary term is moused-over, the glossary entry displays a tooltip. The glossary term also displays as a link.
|
||||
|
||||
As well as inclusions with tooltips, you can reuse the definitions from the glossary in
|
||||
page content.
|
||||
@@ -102,7 +59,7 @@ The raw data for glossary terms is stored at [https://github.com/kubernetes/webs
|
||||
|
||||
### Glossary demo
|
||||
|
||||
For example, the following include within the markdown renders to {{< glossary_tooltip text="cluster" term_id="cluster" >}} with a tooltip:
|
||||
For example, the following include within the Markdown renders to {{< glossary_tooltip text="cluster" term_id="cluster" >}} with a tooltip:
|
||||
|
||||
```
|
||||
{{</* glossary_tooltip text="cluster" term_id="cluster" */>}}
|
||||
@@ -113,13 +70,16 @@ Here's a short glossary definition:
|
||||
```
|
||||
{{</* glossary_definition prepend="A cluster is" term_id="cluster" length="short" */>}}
|
||||
```
|
||||
|
||||
which renders as:
|
||||
{{< glossary_definition prepend="A cluster is" term_id="cluster" length="short" >}}
|
||||
|
||||
You can also include a full definition:
|
||||
|
||||
```
|
||||
{{</* glossary_definition term_id="cluster" length="all" */>}}
|
||||
```
|
||||
|
||||
which renders as:
|
||||
{{< glossary_definition term_id="cluster" length="all" >}}
|
||||
|
||||
@@ -255,7 +215,63 @@ Renders to:
|
||||
{{< tab name="JSON File" include="podtemplate.json" />}}
|
||||
{{< /tabs >}}
|
||||
|
||||
## Version strings
|
||||
|
||||
To generate a version string for inclusion in the documentation, you can choose from
|
||||
several version shortcodes. Each version shortcode displays a version string derived from
|
||||
the value of a version parameter found in the site configuration file, `config.toml`.
|
||||
The two most commonly used version parameters are `latest` and `version`.
|
||||
|
||||
### `{{</* param "version" */>}}`
|
||||
|
||||
The `{{</* param "version" */>}}` shortcode generates the value of the current version of
|
||||
the Kubernetes documentation from the `version` site parameter. The `param` shortcode accepts the name of one site parameter, in this case: `version`.
|
||||
|
||||
{{< note >}}
|
||||
In previously released documentation, `latest` and `version` parameter values are not equivalent.
|
||||
After a new version is released, `latest` is incremented and the value of `version` for the documentation set remains unchanged. For example, a previously released version of the documentation displays `version` as
|
||||
`v1.19` and `latest` as `v1.20`.
|
||||
{{< /note >}}
|
||||
|
||||
Renders to:
|
||||
|
||||
{{< param "version" >}}
|
||||
|
||||
### `{{</* latest-version */>}}`
|
||||
|
||||
The `{{</* latest-version */>}}` shortcode returns the value of the `latest` site parameter.
|
||||
The `latest` site parameter is updated when a new version of the documentation is released.
|
||||
This parameter does not always match the value of `version` in a documentation set.
|
||||
|
||||
Renders to:
|
||||
|
||||
{{< latest-version >}}
|
||||
|
||||
### `{{</* latest-semver */>}}`
|
||||
|
||||
The `{{</* latest-semver */>}}` shortcode generates the value of `latest` without the "v" prefix.
|
||||
|
||||
Renders to:
|
||||
|
||||
{{< latest-semver >}}
|
||||
|
||||
### `{{</* version-check */>}}`
|
||||
|
||||
The `{{</* version-check */>}}` shortcode checks if the `min-kubernetes-server-version`
|
||||
page parameter is present and then uses this value to compare to `version`.
|
||||
|
||||
Renders to:
|
||||
|
||||
{{< version-check >}}
|
||||
|
||||
### `{{</* latest-release-notes */>}}`
|
||||
|
||||
The `{{</* latest-release-notes */>}}` shortcode generates a version string from `latest` and removes
|
||||
the "v" prefix. The shortcode prints a new URL for the release note CHANGELOG page with the modified version string.
|
||||
|
||||
Renders to:
|
||||
|
||||
{{< latest-release-notes >}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
@@ -264,4 +280,3 @@ Renders to:
|
||||
* Learn about [page content types](/docs/contribute/style/page-content-types/).
|
||||
* Learn about [opening a pull request](/docs/contribute/new-content/open-a-pr/).
|
||||
* Learn about [advanced contributing](/docs/contribute/advanced/).
|
||||
|
||||
|
||||
@@ -792,25 +792,8 @@ versions 1.9 and later).
|
||||
|
||||
## Is there a recommended set of admission controllers to use?
|
||||
|
||||
Yes. For Kubernetes version 1.10 and later, the recommended admission controllers are enabled by default (shown [here](/docs/reference/command-line-tools-reference/kube-apiserver/#options)), so you do not need to explicitly specify them. You can enable additional admission controllers beyond the default set using the `--enable-admission-plugins` flag (**order doesn't matter**).
|
||||
Yes. The recommended admission controllers are enabled by default (shown [here](/docs/reference/command-line-tools-reference/kube-apiserver/#options)), so you do not need to explicitly specify them. You can enable additional admission controllers beyond the default set using the `--enable-admission-plugins` flag (**order doesn't matter**).
|
||||
|
||||
{{< note >}}
|
||||
`--admission-control` was deprecated in 1.10 and replaced with `--enable-admission-plugins`.
|
||||
{{< /note >}}
|
||||
|
||||
For Kubernetes 1.9 and earlier, we recommend running the following set of admission controllers using the `--admission-control` flag (**order matters**).
|
||||
|
||||
* v1.9
|
||||
|
||||
```shell
|
||||
--admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota
|
||||
```
|
||||
|
||||
* It's worth reiterating that in 1.9, these happen in a mutating phase
|
||||
and a validating phase, and that for example `ResourceQuota` runs in the validating
|
||||
phase, and therefore is the last admission controller to run.
|
||||
`MutatingAdmissionWebhook` appears before it in this list, because it runs
|
||||
in the mutating phase.
|
||||
|
||||
For earlier versions, there was no concept of validating versus mutating and the
|
||||
admission controllers ran in the exact order specified.
|
||||
|
||||
@@ -87,7 +87,7 @@ Because ClusterRoles are cluster-scoped, you can also use them to grant access t
|
||||
* non-resource endpoints (like `/healthz`)
|
||||
* namespaced resources (like Pods), across all namespaces
|
||||
For example: you can use a ClusterRole to allow a particular user to run
|
||||
`kubectl get pods --all-namespaces`.
|
||||
`kubectl get pods --all-namespaces`
|
||||
|
||||
Here is an example of a ClusterRole that can be used to grant read access to
|
||||
{{< glossary_tooltip text="secrets" term_id="secret" >}} in any particular namespace,
|
||||
|
||||
@@ -166,7 +166,8 @@ different Kubernetes components.
|
||||
| `StorageVersionHash` | `true` | Beta | 1.15 | |
|
||||
| `Sysctls` | `true` | Beta | 1.11 | |
|
||||
| `TTLAfterFinished` | `false` | Alpha | 1.12 | |
|
||||
| `TopologyManager` | `false` | Alpha | 1.16 | |
|
||||
| `TopologyManager` | `false` | Alpha | 1.16 | 1.17 |
|
||||
| `TopologyManager` | `true` | Beta | 1.18 | |
|
||||
| `ValidateProxyRedirects` | `false` | Alpha | 1.12 | 1.13 |
|
||||
| `ValidateProxyRedirects` | `true` | Beta | 1.14 | |
|
||||
| `WindowsEndpointSliceProxying` | `false` | Alpha | 1.19 | |
|
||||
|
||||
@@ -351,7 +351,7 @@ kubelet [flags]
|
||||
<td colspan="2">--eviction-hard mapStringString Default: `imagefs.available<15%,memory.available<100Mi,nodefs.available<10%`</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">A set of eviction thresholds (e.g. `memory.available<1Gi`) that if met would trigger a pod eviction. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">A set of eviction thresholds (e.g. `memory.available<1Gi`) that if met would trigger a pod eviction. On a Linux node, the default value also includes `nodefs.inodesFree<5%`. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
|
||||
@@ -194,6 +194,9 @@ kubectl get pods --show-labels
|
||||
JSONPATH='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status};{end}{end}' \
|
||||
&& kubectl get nodes -o jsonpath="$JSONPATH" | grep "Ready=True"
|
||||
|
||||
# Output decoded secrets without external tools
|
||||
kubectl get secret ${secret_name} -o go-template='{{range $k,$v := .data}}{{$k}}={{$v|base64decode}}{{"\n"}}{{end}}'
|
||||
|
||||
# List all Secrets currently in use by a pod
|
||||
kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq
|
||||
|
||||
@@ -314,6 +317,7 @@ kubectl exec my-pod -- ls / # Run command in existing po
|
||||
kubectl exec --stdin --tty my-pod -- /bin/sh # Interactive shell access to a running pod (1 container case)
|
||||
kubectl exec my-pod -c my-container -- ls / # Run command in existing pod (multi-container case)
|
||||
kubectl top pod POD_NAME --containers # Show metrics for a given pod and its containers
|
||||
kubectl top pod POD_NAME --sort-by=cpu # Show metrics for a given pod and sort it by 'cpu' or 'memory'
|
||||
```
|
||||
|
||||
## Interacting with Nodes and cluster
|
||||
|
||||
@@ -37,23 +37,22 @@ All `kubectl run` generators are deprecated. See the Kubernetes v1.17 documentat
|
||||
|
||||
#### Generators
|
||||
You can generate the following resources with a kubectl command, `kubectl create --dry-run=client -o yaml`:
|
||||
```
|
||||
clusterrole Create a ClusterRole.
|
||||
clusterrolebinding Create a ClusterRoleBinding for a particular ClusterRole.
|
||||
configmap Create a configmap from a local file, directory or literal value.
|
||||
cronjob Create a cronjob with the specified name.
|
||||
deployment Create a deployment with the specified name.
|
||||
job Create a job with the specified name.
|
||||
namespace Create a namespace with the specified name.
|
||||
poddisruptionbudget Create a pod disruption budget with the specified name.
|
||||
priorityclass Create a priorityclass with the specified name.
|
||||
quota Create a quota with the specified name.
|
||||
role Create a role with single rule.
|
||||
rolebinding Create a RoleBinding for a particular Role or ClusterRole.
|
||||
secret Create a secret using specified subcommand.
|
||||
service Create a service using specified subcommand.
|
||||
serviceaccount Create a service account with the specified name.
|
||||
```
|
||||
|
||||
* `clusterrole`: Create a ClusterRole.
|
||||
* `clusterrolebinding`: Create a ClusterRoleBinding for a particular ClusterRole.
|
||||
* `configmap`: Create a ConfigMap from a local file, directory or literal value.
|
||||
* `cronjob`: Create a CronJob with the specified name.
|
||||
* `deployment`: Create a Deployment with the specified name.
|
||||
* `job`: Create a Job with the specified name.
|
||||
* `namespace`: Create a Namespace with the specified name.
|
||||
* `poddisruptionbudget`: Create a PodDisruptionBudget with the specified name.
|
||||
* `priorityclass`: Create a PriorityClass with the specified name.
|
||||
* `quota`: Create a Quota with the specified name.
|
||||
* `role`: Create a Role with single rule.
|
||||
* `rolebinding`: Create a RoleBinding for a particular Role or ClusterRole.
|
||||
* `secret`: Create a Secret using specified subcommand.
|
||||
* `service`: Create a Service using specified subcommand.
|
||||
* `serviceaccount`: Create a ServiceAccount with the specified name.
|
||||
|
||||
### `kubectl apply`
|
||||
|
||||
|
||||
@@ -37,16 +37,11 @@ kubectl:
|
||||
# start the pod running nginx
|
||||
kubectl create deployment --image=nginx nginx-app
|
||||
```
|
||||
|
||||
```shell
|
||||
# add env to nginx-app
|
||||
kubectl set env deployment/nginx-app DOMAIN=cluster
|
||||
```
|
||||
```
|
||||
deployment.apps/nginx-app created
|
||||
```
|
||||
|
||||
```
|
||||
```shell
|
||||
# add env to nginx-app
|
||||
kubectl set env deployment/nginx-app DOMAIN=cluster
|
||||
```
|
||||
|
||||
@@ -108,7 +108,7 @@ extension points:
|
||||
- `SelectorSpread`: Favors spreading across nodes for Pods that belong to
|
||||
{{< glossary_tooltip text="Services" term_id="service" >}},
|
||||
{{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}} and
|
||||
{{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}}
|
||||
{{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}}.
|
||||
Extension points: `PreScore`, `Score`.
|
||||
- `ImageLocality`: Favors nodes that already have the container images that the
|
||||
Pod runs.
|
||||
|
||||
@@ -71,7 +71,7 @@ the appliers, results in a conflict. Shared field owners may give up ownership
|
||||
of a field by removing it from their configuration.
|
||||
|
||||
Field management is stored in a`managedFields` field that is part of an object's
|
||||
[`metadata`](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#objectmeta-v1-meta).
|
||||
[`metadata`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#objectmeta-v1-meta).
|
||||
|
||||
A simple example of an object created by Server Side Apply could look like this:
|
||||
|
||||
|
||||
@@ -143,6 +143,44 @@ sudo mkdir -p /etc/containerd
|
||||
sudo containerd config default | sudo tee /etc/containerd/config.toml
|
||||
```
|
||||
|
||||
```shell
|
||||
# Restart containerd
|
||||
sudo systemctl restart containerd
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="Debian 9+" %}}
|
||||
|
||||
```shell
|
||||
# (Install containerd)
|
||||
## Set up the repository
|
||||
### Install packages to allow apt to use a repository over HTTPS
|
||||
sudo apt-get update && sudo apt-get install -y apt-transport-https ca-certificates curl software-properties-common
|
||||
```
|
||||
|
||||
```shell
|
||||
## Add Docker's official GPG key
|
||||
curl -fsSL https://download.docker.com/linux/debian/gpg | sudo apt-key --keyring /etc/apt/trusted.gpg.d/docker.gpg add -
|
||||
```
|
||||
|
||||
```shell
|
||||
## Add Docker apt repository.
|
||||
sudo add-apt-repository \
|
||||
"deb [arch=amd64] https://download.docker.com/linux/debian \
|
||||
$(lsb_release -cs) \
|
||||
stable"
|
||||
```
|
||||
|
||||
```shell
|
||||
## Install containerd
|
||||
sudo apt-get update && sudo apt-get install -y containerd.io
|
||||
```
|
||||
|
||||
```shell
|
||||
# Set default containerd configuration
|
||||
sudo mkdir -p /etc/containerd
|
||||
containerd config default | sudo tee /etc/containerd/config.toml
|
||||
```
|
||||
|
||||
```shell
|
||||
# Restart containerd
|
||||
sudo systemctl restart containerd
|
||||
@@ -432,6 +470,11 @@ sudo apt-get update && sudo apt-get install -y \
|
||||
docker-ce-cli=5:19.03.11~3-0~ubuntu-$(lsb_release -cs)
|
||||
```
|
||||
|
||||
```shell
|
||||
## Create /etc/docker
|
||||
sudo mkdir /etc/docker
|
||||
```
|
||||
|
||||
```shell
|
||||
# Set up the Docker daemon
|
||||
cat <<EOF | sudo tee /etc/docker/daemon.json
|
||||
@@ -523,4 +566,3 @@ sudo systemctl enable docker
|
||||
|
||||
Refer to the [official Docker installation guides](https://docs.docker.com/engine/installation/)
|
||||
for more information.
|
||||
|
||||
|
||||
+1
-2
@@ -102,8 +102,7 @@ This may be caused by a number of problems. The most common are:
|
||||
1. Install Docker again following instructions
|
||||
[here](/docs/setup/production-environment/container-runtimes/#docker).
|
||||
|
||||
1. Change the kubelet config to match the Docker cgroup driver manually, you can refer to
|
||||
[Configure cgroup driver used by kubelet on Master Node](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-master-node)
|
||||
1. Change the kubelet config to match the Docker cgroup driver manually, you can refer to [Configure cgroup driver used by kubelet on control-plane node](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-control-plane-node)
|
||||
|
||||
- control plane Docker containers are crashlooping or hanging. You can check this by running `docker ps` and investigating each container by running `docker logs`.
|
||||
|
||||
|
||||
+1
-1
@@ -160,7 +160,7 @@ for the pathnames of the certificate files. You need to change these to the actu
|
||||
of certificate files in your environment.
|
||||
|
||||
Sometimes you may want to use Base64-encoded data embedded here instead of separate
|
||||
certificate files; in that case you need add the suffix `-data` to the keys, for example,
|
||||
certificate files; in that case you need to add the suffix `-data` to the keys, for example,
|
||||
`certificate-authority-data`, `client-certificate-data`, `client-key-data`.
|
||||
|
||||
Each context is a triple (cluster, user, namespace). For example, the
|
||||
|
||||
@@ -49,12 +49,14 @@ This is the path followed by DNS Queries after NodeLocal DNSCache is enabled:
|
||||
{{< figure src="/images/docs/nodelocaldns.svg" alt="NodeLocal DNSCache flow" title="Nodelocal DNSCache flow" caption="This image shows how NodeLocal DNSCache handles DNS queries." >}}
|
||||
|
||||
## Configuration
|
||||
{{< note >}} The local listen IP address for NodeLocal DNSCache can be any IP in the 169.254.20.0/16 space or any other IP address that can be guaranteed to not collide with any existing IP. This document uses 169.254.20.10 as an example.
|
||||
{{< note >}} The local listen IP address for NodeLocal DNSCache can be any address that can be guaranteed to not collide with any existing IP in your cluster. It's recommended to use an address with a local scope, per example, from the link-local range 169.254.0.0/16 for IPv4 or from the Unique Local Address range in IPv6 fd00::/8.
|
||||
{{< /note >}}
|
||||
|
||||
This feature can be enabled using the following steps:
|
||||
|
||||
* Prepare a manifest similar to the sample [`nodelocaldns.yaml`](https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/dns/nodelocaldns/nodelocaldns.yaml) and save it as `nodelocaldns.yaml.`
|
||||
* If using IPv6, the CoreDNS configuration file need to enclose all the IPv6 addresses into square brackets if used in IP:Port format.
|
||||
If you are using the sample manifest from the previous point, this will require to modify [the configuration line L70](https://github.com/kubernetes/kubernetes/blob/b2ecd1b3a3192fbbe2b9e348e095326f51dc43dd/cluster/addons/dns/nodelocaldns/nodelocaldns.yaml#L70) like this `health [__PILLAR__LOCAL__DNS__]:8080`
|
||||
* Substitute the variables in the manifest with the right values:
|
||||
|
||||
* kubedns=`kubectl get svc kube-dns -n kube-system -o jsonpath={.spec.clusterIP}`
|
||||
|
||||
@@ -82,6 +82,7 @@ You can list this and any other serviceAccount resources in the namespace with t
|
||||
```shell
|
||||
kubectl get serviceaccounts
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```
|
||||
@@ -108,9 +109,10 @@ If you get a complete dump of the service account object, like this:
|
||||
```shell
|
||||
kubectl get serviceaccounts/build-robot -o yaml
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ServiceAccount
|
||||
metadata:
|
||||
@@ -164,6 +166,7 @@ Any tokens for non-existent service accounts will be cleaned up by the token con
|
||||
```shell
|
||||
kubectl describe secrets/build-robot-secret
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```
|
||||
@@ -227,7 +230,7 @@ kubectl get serviceaccounts default -o yaml > ./sa.yaml
|
||||
|
||||
The output of the `sa.yaml` file is similar to this:
|
||||
|
||||
```shell
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ServiceAccount
|
||||
metadata:
|
||||
@@ -244,7 +247,7 @@ Using your editor of choice (for example `vi`), open the `sa.yaml` file, delete
|
||||
|
||||
The output of the `sa.yaml` file is similar to this:
|
||||
|
||||
```shell
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ServiceAccount
|
||||
metadata:
|
||||
@@ -319,7 +322,8 @@ kubectl create -f https://k8s.io/examples/pods/pod-projected-svc-token.yaml
|
||||
```
|
||||
|
||||
The kubelet will request and store the token on behalf of the pod, make the
|
||||
token available to the pod at a configurable file path, and refresh the token as it approaches expiration. Kubelet proactively rotates the token if it is older than 80% of its total TTL, or if the token is older than 24 hours.
|
||||
token available to the pod at a configurable file path, and refresh the token as it approaches expiration.
|
||||
The kubelet proactively rotates the token if it is older than 80% of its total TTL, or if the token is older than 24 hours.
|
||||
|
||||
The application is responsible for reloading the token when it rotates. Periodic reloading (e.g. once every 5 minutes) is sufficient for most use cases.
|
||||
|
||||
@@ -380,7 +384,6 @@ JWKS URI is required to use the `https` scheme.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
See also:
|
||||
|
||||
- [Cluster Admin Guide to Service Accounts](/docs/reference/access-authn-authz/service-accounts-admin/)
|
||||
|
||||
@@ -192,7 +192,7 @@ this scenario using `kubectl run`:
|
||||
kubectl run myapp --image=busybox --restart=Never -- sleep 1d
|
||||
```
|
||||
|
||||
Run this command to create a copy of `myapp` named `myapp-copy` that adds a
|
||||
Run this command to create a copy of `myapp` named `myapp-debug` that adds a
|
||||
new Ubuntu container for debugging:
|
||||
|
||||
```shell
|
||||
|
||||
@@ -445,6 +445,9 @@ and
|
||||
[kubectl apply](/docs/reference/generated/kubectl/kubectl-commands/#apply).
|
||||
|
||||
|
||||
{{< note >}}
|
||||
Strategic merge patch is not supported for custom resources.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
@@ -337,7 +337,7 @@ sequenceDiagram
|
||||
Alice->John: Yes... John, how are you?
|
||||
{{</ mermaid >}}
|
||||
|
||||
<br>More [examples](https://mermaid-js.github.io/mermaid/#/examples) from the offical docs.
|
||||
<br>More [examples](https://mermaid-js.github.io/mermaid/#/examples) from the official docs.
|
||||
|
||||
## Sidebars and Admonitions
|
||||
|
||||
|
||||
@@ -92,9 +92,7 @@ weight: 10
|
||||
<div class="row">
|
||||
<div class="col-md-8">
|
||||
<p>
|
||||
For your first Deployment, you'll use a Node.js application packaged in a Docker container. (If you didn't already try creating a
|
||||
Node.js application and deploying it using a container, you can do that first by following the
|
||||
instructions from the <a href="/docs/tutorials/hello-minikube/">Hello Minikube tutorial</a>).
|
||||
For your first Deployment, you'll use a hello-node application packaged in a Docker container that uses NGINX to echo back all the requests. (If you didn't already try creating a hello-node application and deploying it using a container, you can do that first by following the instructions from the <a href="/docs/tutorials/hello-minikube/">Hello Minikube tutorial</a>).
|
||||
<p>
|
||||
|
||||
<p>Now that you know what Deployments are, let's go to the online tutorial and deploy our first app!</p>
|
||||
|
||||
Reference in New Issue
Block a user