Merge branch 'master' into patch-1
This commit is contained in:
Vinicius Barbosa
@@ -7,8 +7,8 @@ approvers:
|
||||
- sig-docs-en-owners # Defined in OWNERS_ALIASES
|
||||
|
||||
emeritus_approvers:
|
||||
- chenopis
|
||||
- jaredbhatti
|
||||
# chenopis, you're welcome to return when you're ready to resume PR wrangling
|
||||
# jaredbhatti, you're welcome to return when you're ready to resume PR wrangling
|
||||
# stewart-yu, you're welcome to return when you're ready to resume PR wrangling
|
||||
- stewart-yu
|
||||
|
||||
|
||||
@@ -48,6 +48,7 @@ aliases:
|
||||
- makoscafee
|
||||
- onlydole
|
||||
- Rajakavitha1
|
||||
- savitharaghunathan
|
||||
- sftim
|
||||
- steveperry-53
|
||||
- tengqm
|
||||
|
||||
@@ -19,6 +19,19 @@
|
||||
* [Керівництво зі стилю оформлення документації](http://kubernetes.io/docs/contribute/style/style-guide/)
|
||||
* [Переклад документації Kubernetes іншими мовами](https://kubernetes.io/docs/contribute/localization/)
|
||||
|
||||
## Файл `README.md` іншими мовами
|
||||
|
||||
| | |
|
||||
|-------------------------------|-------------------------------|
|
||||
| [Англійська](README.md) | [Французька](README-fr.md) |
|
||||
| [Корейська](README-ko.md) | [Німецька](README-de.md) |
|
||||
| [Португальська](README-pt.md) | [Хінді](README-hi.md) |
|
||||
| [Іспанська](README-es.md) | [Індонезійська](README-id.md) |
|
||||
| [Китайська](README-zh.md) | [Японська](README-ja.md) |
|
||||
| [В'єтнамська](README-vi.md) | [Російська](README-ru.md) |
|
||||
| [Італійська](README-it.md) | [Польська](README-pl.md) |
|
||||
| | |
|
||||
|
||||
## Запуск сайту локально за допомогою Docker
|
||||
|
||||
Для локального запуску сайту Kubernetes рекомендовано запустити спеціальний [Docker](https://docker.com)-образ, що містить генератор статичних сайтів [Hugo](https://gohugo.io).
|
||||
|
||||
@@ -2,7 +2,7 @@ $main-max-width: 1200px
|
||||
$vendor-strip-height: 44px
|
||||
$video-section-height: 550px
|
||||
|
||||
@media screen and (min-width: 1025px)
|
||||
@media screen and (min-width: 1100px)
|
||||
#hamburger
|
||||
display: none
|
||||
|
||||
|
||||
@@ -1,12 +0,0 @@
|
||||
|
||||
|
||||
<table style="background-color:#eeeeee">
|
||||
<tr>
|
||||
<td>
|
||||
<p><b>ACHTUNG</b></p>
|
||||
<p>Seit dem 14. März 2017 hat die Gruppe Kubernetes SIG-Docs-Maintainers mit der Migration des Benutzerhandbuch-Inhalts begonnen, wie bereits zuvor in der <a href="https://git.k8s.io/community/sig-docs">SIG Docs community</a> angekündigt. Dies wurde in der <a href="https://groups.google.com/forum/#!forum/kubernetes-sig-docs">kubernetes-sig-docs</a> Gruppe und im <a href="https://kubernetes.slack.com/messages/sig-docs/">kubernetes.slack.com #sig-docs</a> Kanal bekanntgegeben.</p>
|
||||
<p>Die Benutzerhandbücher in diesem Abschnitt werden in den Themen Tutorials, Aufgaben und Konzepte umgestaltet. Alles, was verschoben wurde, wird an seinem vorherigen Standort mit einer Benachrichtigung sowie einem Link zu seinem neuen Standort versehen. Die Reorganisation implementiert ein neues Inhaltsverzeichnis und sollte die Auffindbarkeit und Lesbarkeit der Dokumentation für ein breiteres Publikum verbessern.</p>
|
||||
<p>Bei Fragen wenden Sie sich bitte an: <a href="mailto:kubernetes-sig-docs@googlegroups.com">kubernetes-sig-docs@googlegroups.com</a></p>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
+17
-17
@@ -24,17 +24,17 @@ The new concept of a path type allows you to specify how a path should be matche
|
||||
The Ingress resource was designed with simplicity in mind, providing a simple set of fields that would be applicable in all use cases. Over time, as use cases evolved, implementations began to rely on a long list of custom annotations for further configuration. The new `IngressClass` resource provides a way to replace some of those annotations.
|
||||
|
||||
Each `IngressClass` specifies which controller should implement Ingresses of the class and can reference a custom resource with additional parameters.
|
||||
```
|
||||
apiVersion: networking.k8s.io/v1beta1
|
||||
kind: IngressClass
|
||||
```yaml
|
||||
apiVersion: "networking.k8s.io/v1beta1"
|
||||
kind: "IngressClass"
|
||||
metadata:
|
||||
name: external-lb
|
||||
name: "external-lb"
|
||||
spec:
|
||||
controller: example.com/ingress-controller
|
||||
controller: "example.com/ingress-controller"
|
||||
parameters:
|
||||
apiGroup: k8s.example.com/v1alpha
|
||||
kind: IngressParameters
|
||||
name: external-lb
|
||||
apiGroup: "k8s.example.com/v1alpha"
|
||||
kind: "IngressParameters"
|
||||
name: "external-lb"
|
||||
```
|
||||
|
||||
### Specifying the Class of an Ingress
|
||||
@@ -60,21 +60,21 @@ Many Ingress providers have supported wildcard hostname matching like `*.foo.com
|
||||
### Putting it All Together
|
||||
These new Ingress features allow for much more configurability. Here’s an example of an Ingress that makes use of pathType, `ingressClassName`, and a hostname wildcard:
|
||||
|
||||
```
|
||||
apiVersion: networking.k8s.io/v1beta1
|
||||
kind: Ingress
|
||||
```yaml
|
||||
apiVersion: "networking.k8s.io/v1beta1"
|
||||
kind: "Ingress"
|
||||
metadata:
|
||||
name: example-ingress
|
||||
name: "example-ingress"
|
||||
spec:
|
||||
ingressClassName: external-lb
|
||||
ingressClassName: "external-lb"
|
||||
rules:
|
||||
- host: *.example.com
|
||||
- host: "*.example.com"
|
||||
http:
|
||||
paths:
|
||||
- path: /example
|
||||
pathType: Prefix
|
||||
- path: "/example"
|
||||
pathType: "Prefix"
|
||||
backend:
|
||||
serviceName: example-service
|
||||
serviceName: "example-service"
|
||||
servicePort: 80
|
||||
```
|
||||
|
||||
|
||||
@@ -231,6 +231,7 @@ The following cloud providers have implemented CCMs:
|
||||
* [DigitalOcean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
|
||||
* [GCP](https://github.com/kubernetes/cloud-provider-gcp)
|
||||
* [Hetzner](https://github.com/hetznercloud/hcloud-cloud-controller-manager)
|
||||
* [HUAWEI CLOUD](https://github.com/kubernetes-sigs/cloud-provider-huaweicloud)
|
||||
* [Linode](https://github.com/linode/linode-cloud-controller-manager)
|
||||
* [OpenStack](https://github.com/kubernetes/cloud-provider-openstack)
|
||||
* [Oracle](https://github.com/oracle/oci-cloud-controller-manager)
|
||||
|
||||
@@ -52,7 +52,7 @@ Job is a Kubernetes resource that runs a
|
||||
{{< glossary_tooltip term_id="pod" >}}, or perhaps several Pods, to carry out
|
||||
a task and then stop.
|
||||
|
||||
(Once [scheduled](/docs/concepts/scheduling/), Pod objects become part of the
|
||||
(Once [scheduled](/docs/concepts/scheduling-eviction/), Pod objects become part of the
|
||||
desired state for a kubelet).
|
||||
|
||||
When the Job controller sees a new task it makes sure that, somewhere
|
||||
|
||||
@@ -140,7 +140,7 @@ deployment.apps/my-deployment created
|
||||
persistentvolumeclaim/my-pvc created
|
||||
```
|
||||
|
||||
The `--recursive` flag works with any operation that accepts the `--filename,-f` flag such as: `kubectl {create,get,delete,describe,rollout} etc.`
|
||||
The `--recursive` flag works with any operation that accepts the `--filename,-f` flag such as: `kubectl {create,get,delete,describe,rollout}` etc.
|
||||
|
||||
The `--recursive` flag also works when multiple `-f` arguments are provided:
|
||||
|
||||
@@ -453,7 +453,7 @@ That's it! The Deployment will declaratively update the deployed nginx applicati
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
- [Learn about how to use `kubectl` for application introspection and debugging.](/docs/tasks/debug-application-cluster/debug-application-introspection/)
|
||||
- [Configuration Best Practices and Tips](/docs/concepts/configuration/overview/)
|
||||
- Learn about [how to use `kubectl` for application introspection and debugging](/docs/tasks/debug-application-cluster/debug-application-introspection/).
|
||||
- See [Configuration Best Practices and Tips](/docs/concepts/configuration/overview/).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
+360
-214
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Managing Compute Resources for Containers
|
||||
title: Managing Resources for Containers
|
||||
content_template: templates/concept
|
||||
weight: 20
|
||||
feature:
|
||||
@@ -10,23 +10,48 @@ feature:
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
When you specify a [Pod](/docs/concepts/workloads/pods/pod/), you can optionally specify how
|
||||
much CPU and memory (RAM) each Container needs. When Containers have resource
|
||||
requests specified, the scheduler can make better decisions about which nodes to
|
||||
place Pods on. And when Containers have their limits specified, contention for
|
||||
resources on a node can be handled in a specified manner. For more details about
|
||||
the difference between requests and limits, see
|
||||
[Resource QoS](https://git.k8s.io/community/contributors/design-proposals/node/resource-qos.md).
|
||||
When you specify a {{< glossary_tooltip term_id="pod" >}}, you can optionally specify how
|
||||
much of each resource a {{< glossary_tooltip text="Container" term_id="container" >}} needs.
|
||||
The most common resources to specify are CPU and memory (RAM); there are others.
|
||||
|
||||
When you specify the resource _request_ for Containers in a Pod, the scheduler uses this
|
||||
information to decide which node to place the Pod on. When you specify a resource _limit_
|
||||
for a Container, the kubelet enforces those limits so that the running container is not
|
||||
allowed to use more of that resource than the limit you set. The kubelet also reserves
|
||||
at least the _request_ amount of that system resource specifically for that container
|
||||
to use.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Requests and limits
|
||||
|
||||
If the node where a Pod is running has enough of a resource available, it's possible (and
|
||||
allowed) for a container to use more resource than its `request` for that resource specifies.
|
||||
However, a container is not allowed to use more than its resource `limit`.
|
||||
|
||||
For example, if you set a `memory` request of 256 MiB for a container, and that container is in
|
||||
a Pod scheduled to a Node with 8GiB of memory and no other Pods, then the container can try to use
|
||||
more RAM.
|
||||
|
||||
If you set a `memory` limit of 4GiB for that Container, the kubelet (and
|
||||
{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}) enforce the limit.
|
||||
The runtime prevents the container from using more than the configured resource limit. For example:
|
||||
when a process in the container tries to consume more than the allowed amount of memory,
|
||||
the system kernel terminates the process that attempted the allocation, with an out of memory
|
||||
(OOM) error.
|
||||
|
||||
Limits can be implemented either reactively (the system intervenes once it sees a violation)
|
||||
or by enforcement (the system prevents the container from ever exceeding the limit). Different
|
||||
runtimes can have different ways to implement the same restrictions.
|
||||
|
||||
## Resource types
|
||||
|
||||
*CPU* and *memory* are each a *resource type*. A resource type has a base unit.
|
||||
CPU is specified in units of cores, and memory is specified in units of bytes.
|
||||
CPU represents compute processing and is specified in units of [Kubernetes CPUs](#meaning-of-cpu).
|
||||
Memory is specified in units of bytes.
|
||||
If you're using Kubernetes v1.14 or newer, you can specify _huge page_ resources.
|
||||
Huge pages are a Linux-specific feature where the node kernel allocates blocks of memory
|
||||
that are much larger than the default page size.
|
||||
@@ -64,8 +89,9 @@ is convenient to talk about Pod resource requests and limits. A
|
||||
*Pod resource request/limit* for a particular resource type is the sum of the
|
||||
resource requests/limits of that type for each Container in the Pod.
|
||||
|
||||
## Resource units in Kubernetes
|
||||
|
||||
## Meaning of CPU
|
||||
### Meaning of CPU
|
||||
|
||||
Limits and requests for CPU resources are measured in *cpu* units.
|
||||
One cpu, in Kubernetes, is equivalent to **1 vCPU/Core** for cloud providers and **1 hyperthread** on bare-metal Intel processors.
|
||||
@@ -82,7 +108,7 @@ be preferred.
|
||||
CPU is always requested as an absolute quantity, never as a relative quantity;
|
||||
0.1 is the same amount of CPU on a single-core, dual-core, or 48-core machine.
|
||||
|
||||
## Meaning of memory
|
||||
### Meaning of memory
|
||||
|
||||
Limits and requests for `memory` are measured in bytes. You can express memory as
|
||||
a plain integer or as a fixed-point integer using one of these suffixes:
|
||||
@@ -181,7 +207,7 @@ To determine whether a Container cannot be scheduled or is being killed due to
|
||||
resource limits, see the
|
||||
[Troubleshooting](#troubleshooting) section.
|
||||
|
||||
## Monitoring compute resource usage
|
||||
### Monitoring compute & memory resource usage
|
||||
|
||||
The resource usage of a Pod is reported as part of the Pod status.
|
||||
|
||||
@@ -190,158 +216,98 @@ are available in your cluster, then Pod resource usage can be retrieved either
|
||||
from the [Metrics API](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#the-metrics-api)
|
||||
directly or from your monitoring tools.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### My Pods are pending with event message failedScheduling
|
||||
|
||||
If the scheduler cannot find any node where a Pod can fit, the Pod remains
|
||||
unscheduled until a place can be found. An event is produced each time the
|
||||
scheduler fails to find a place for the Pod, like this:
|
||||
|
||||
```shell
|
||||
kubectl describe pod frontend | grep -A 3 Events
|
||||
```
|
||||
```
|
||||
Events:
|
||||
FirstSeen LastSeen Count From Subobject PathReason Message
|
||||
36s 5s 6 {scheduler } FailedScheduling Failed for reason PodExceedsFreeCPU and possibly others
|
||||
```
|
||||
|
||||
In the preceding example, the Pod named "frontend" fails to be scheduled due to
|
||||
insufficient CPU resource on the node. Similar error messages can also suggest
|
||||
failure due to insufficient memory (PodExceedsFreeMemory). In general, if a Pod
|
||||
is pending with a message of this type, there are several things to try:
|
||||
|
||||
- Add more nodes to the cluster.
|
||||
- Terminate unneeded Pods to make room for pending Pods.
|
||||
- Check that the Pod is not larger than all the nodes. For example, if all the
|
||||
nodes have a capacity of `cpu: 1`, then a Pod with a request of `cpu: 1.1` will
|
||||
never be scheduled.
|
||||
|
||||
You can check node capacities and amounts allocated with the
|
||||
`kubectl describe nodes` command. For example:
|
||||
|
||||
```shell
|
||||
kubectl describe nodes e2e-test-node-pool-4lw4
|
||||
```
|
||||
```
|
||||
Name: e2e-test-node-pool-4lw4
|
||||
[ ... lines removed for clarity ...]
|
||||
Capacity:
|
||||
cpu: 2
|
||||
memory: 7679792Ki
|
||||
pods: 110
|
||||
Allocatable:
|
||||
cpu: 1800m
|
||||
memory: 7474992Ki
|
||||
pods: 110
|
||||
[ ... lines removed for clarity ...]
|
||||
Non-terminated Pods: (5 in total)
|
||||
Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits
|
||||
--------- ---- ------------ ---------- --------------- -------------
|
||||
kube-system fluentd-gcp-v1.38-28bv1 100m (5%) 0 (0%) 200Mi (2%) 200Mi (2%)
|
||||
kube-system kube-dns-3297075139-61lj3 260m (13%) 0 (0%) 100Mi (1%) 170Mi (2%)
|
||||
kube-system kube-proxy-e2e-test-... 100m (5%) 0 (0%) 0 (0%) 0 (0%)
|
||||
kube-system monitoring-influxdb-grafana-v4-z1m12 200m (10%) 200m (10%) 600Mi (8%) 600Mi (8%)
|
||||
kube-system node-problem-detector-v0.1-fj7m3 20m (1%) 200m (10%) 20Mi (0%) 100Mi (1%)
|
||||
Allocated resources:
|
||||
(Total limits may be over 100 percent, i.e., overcommitted.)
|
||||
CPU Requests CPU Limits Memory Requests Memory Limits
|
||||
------------ ---------- --------------- -------------
|
||||
680m (34%) 400m (20%) 920Mi (12%) 1070Mi (14%)
|
||||
```
|
||||
|
||||
In the preceding output, you can see that if a Pod requests more than 1120m
|
||||
CPUs or 6.23Gi of memory, it will not fit on the node.
|
||||
|
||||
By looking at the `Pods` section, you can see which Pods are taking up space on
|
||||
the node.
|
||||
|
||||
The amount of resources available to Pods is less than the node capacity, because
|
||||
system daemons use a portion of the available resources. The `allocatable` field
|
||||
[NodeStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#nodestatus-v1-core)
|
||||
gives the amount of resources that are available to Pods. For more information, see
|
||||
[Node Allocatable Resources](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md).
|
||||
|
||||
The [resource quota](/docs/concepts/policy/resource-quotas/) feature can be configured
|
||||
to limit the total amount of resources that can be consumed. If used in conjunction
|
||||
with namespaces, it can prevent one team from hogging all the resources.
|
||||
|
||||
### My Container is terminated
|
||||
|
||||
Your Container might get terminated because it is resource-starved. To check
|
||||
whether a Container is being killed because it is hitting a resource limit, call
|
||||
`kubectl describe pod` on the Pod of interest:
|
||||
|
||||
```shell
|
||||
kubectl describe pod simmemleak-hra99
|
||||
```
|
||||
```
|
||||
Name: simmemleak-hra99
|
||||
Namespace: default
|
||||
Image(s): saadali/simmemleak
|
||||
Node: kubernetes-node-tf0f/10.240.216.66
|
||||
Labels: name=simmemleak
|
||||
Status: Running
|
||||
Reason:
|
||||
Message:
|
||||
IP: 10.244.2.75
|
||||
Replication Controllers: simmemleak (1/1 replicas created)
|
||||
Containers:
|
||||
simmemleak:
|
||||
Image: saadali/simmemleak
|
||||
Limits:
|
||||
cpu: 100m
|
||||
memory: 50Mi
|
||||
State: Running
|
||||
Started: Tue, 07 Jul 2015 12:54:41 -0700
|
||||
Last Termination State: Terminated
|
||||
Exit Code: 1
|
||||
Started: Fri, 07 Jul 2015 12:54:30 -0700
|
||||
Finished: Fri, 07 Jul 2015 12:54:33 -0700
|
||||
Ready: False
|
||||
Restart Count: 5
|
||||
Conditions:
|
||||
Type Status
|
||||
Ready False
|
||||
Events:
|
||||
FirstSeen LastSeen Count From SubobjectPath Reason Message
|
||||
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {scheduler } scheduled Successfully assigned simmemleak-hra99 to kubernetes-node-tf0f
|
||||
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD pulled Pod container image "k8s.gcr.io/pause:0.8.0" already present on machine
|
||||
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD created Created with docker id 6a41280f516d
|
||||
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD started Started with docker id 6a41280f516d
|
||||
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} spec.containers{simmemleak} created Created with docker id 87348f12526a
|
||||
```
|
||||
|
||||
In the preceding example, the `Restart Count: 5` indicates that the `simmemleak`
|
||||
Container in the Pod was terminated and restarted five times.
|
||||
|
||||
You can call `kubectl get pod` with the `-o go-template=...` option to fetch the status
|
||||
of previously terminated Containers:
|
||||
|
||||
```shell
|
||||
kubectl get pod -o go-template='{{range.status.containerStatuses}}{{"Container Name: "}}{{.name}}{{"\r\nLastState: "}}{{.lastState}}{{end}}' simmemleak-hra99
|
||||
```
|
||||
```
|
||||
Container Name: simmemleak
|
||||
LastState: map[terminated:map[exitCode:137 reason:OOM Killed startedAt:2015-07-07T20:58:43Z finishedAt:2015-07-07T20:58:43Z containerID:docker://0e4095bba1feccdfe7ef9fb6ebffe972b4b14285d5acdec6f0d3ae8a22fad8b2]]
|
||||
```
|
||||
|
||||
You can see that the Container was terminated because of `reason:OOM Killed`, where `OOM` stands for Out Of Memory.
|
||||
|
||||
## Local ephemeral storage
|
||||
{{< feature-state state="beta" >}}
|
||||
|
||||
Kubernetes version 1.8 introduces a new resource, _ephemeral-storage_ for managing local ephemeral storage. In each Kubernetes node, kubelet's root directory (/var/lib/kubelet by default) and log directory (/var/log) are stored on the root partition of the node. This partition is also shared and consumed by Pods via emptyDir volumes, container logs, image layers and container writable layers.
|
||||
<!-- feature gate LocalStorageCapacityIsolation -->
|
||||
{{< feature-state for_k8s_version="v1.10" state="beta" >}}
|
||||
|
||||
This partition is “ephemeral” and applications cannot expect any performance SLAs (Disk IOPS for example) from this partition. Local ephemeral storage management only applies for the root partition; the optional partition for image layer and writable layer is out of scope.
|
||||
Nodes have local ephemeral storage, backed by
|
||||
locally-attached writeable devices or, sometimes, by RAM.
|
||||
"Ephemeral" means that there is no long-term guarantee about durability.
|
||||
|
||||
Pods use ephemeral local storage for scratch space, caching, and for logs.
|
||||
The kubelet can provide scratch space to Pods using local ephemeral storage to
|
||||
mount [`emptyDir`](https://kubernetes.io/docs/concepts/storage/volumes/#emptydir)
|
||||
{{< glossary_tooltip term_id="volume" text="volumes" >}} into containers.
|
||||
|
||||
The kubelet also uses this kind of storage to hold
|
||||
[node-level container logs](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level),
|
||||
container images, and the writable layers of running containers.
|
||||
|
||||
{{< caution >}}
|
||||
If a node fails, the data in its ephemeral storage can be lost.
|
||||
Your applications cannot expect any performance SLAs (disk IOPS for example)
|
||||
from local ephemeral storage.
|
||||
{{< /caution >}}
|
||||
|
||||
As a beta feature, Kubernetes lets you track, reserve and limit the amount
|
||||
of ephemeral local storage a Pod can consume.
|
||||
|
||||
### Configurations for local ephemeral storage
|
||||
|
||||
Kubernetes supports two ways to configure local ephemeral storage on a node:
|
||||
{{< tabs name="local_storage_configurations" >}}
|
||||
{{% tab name="Single filesystem" %}}
|
||||
In this configuration, you place all different kinds of ephemeral local data
|
||||
(`emptyDir` volumes, writeable layers, container images, logs) into one filesystem.
|
||||
The most effective way to configure the kubelet means dedicating this filesystem
|
||||
to Kubernetes (kubelet) data.
|
||||
|
||||
The kubelet also writes
|
||||
[node-level container logs](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)
|
||||
and treats these similarly to ephemeral local storage.
|
||||
|
||||
The kubelet writes logs to files inside its configured log directory (`/var/log`
|
||||
by default); and has a base directory for other locally stored data
|
||||
(`/var/lib/kubelet` by default).
|
||||
|
||||
Typically, both `/var/lib/kubelet` and `/var/log` are on the system root filesystem,
|
||||
and the kubelet is designed with that layout in mind.
|
||||
|
||||
Your node can have as many other filesystems, not used for Kubernetes,
|
||||
as you like.
|
||||
{{% /tab %}}
|
||||
{{% tab name="Two filesystems" %}}
|
||||
You have a filesystem on the node that you're using for ephemeral data that
|
||||
comes from running Pods: logs, and `emptyDir` volumes. You can use this filesystem
|
||||
for other data (for example: system logs not related to Kubernetes); it can even
|
||||
be the root filesystem.
|
||||
|
||||
The kubelet also writes
|
||||
[node-level container logs](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)
|
||||
into the first filesystem, and treats these similarly to ephemeral local storage.
|
||||
|
||||
You also use a separate filesystem, backed by a different logical storage device.
|
||||
In this configuration, the directory where you tell the kubelet to place
|
||||
container image layers and writeable layers is on this second filesystem.
|
||||
|
||||
The first filesystem does not hold any image layers or writeable layers.
|
||||
|
||||
Your node can have as many other filesystems, not used for Kubernetes,
|
||||
as you like.
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
The kubelet can measure how much local storage it is using. It does this provided
|
||||
that:
|
||||
|
||||
- the `LocalStorageCapacityIsolation`
|
||||
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
is enabled (the feature is on by default), and
|
||||
- you have set up the node using one of the supported configurations
|
||||
for local ephemeral storage.
|
||||
|
||||
If you have a different configuration, then the kubelet does not apply resource
|
||||
limits for ephemeral local storage.
|
||||
|
||||
{{< note >}}
|
||||
If an optional runtime partition is used, root partition will not hold any image layer or writable layers.
|
||||
The kubelet tracks `tmpfs` emptyDir volumes as container memory use, rather
|
||||
than as local ephemeral storage.
|
||||
{{< /note >}}
|
||||
|
||||
### Requests and limits setting for local ephemeral storage
|
||||
Each Container of a Pod can specify one or more of the following:
|
||||
### Setting requests and limits for local ephemeral storage
|
||||
|
||||
You can use _ephemeral-storage_ for managing local ephemeral storage. Each Container of a Pod can specify one or more of the following:
|
||||
|
||||
* `spec.containers[].resources.limits.ephemeral-storage`
|
||||
* `spec.containers[].resources.requests.ephemeral-storage`
|
||||
@@ -355,7 +321,7 @@ Mi, Ki. For example, the following represent roughly the same value:
|
||||
128974848, 129e6, 129M, 123Mi
|
||||
```
|
||||
|
||||
For example, the following Pod has two Containers. Each Container has a request of 2GiB of local ephemeral storage. Each Container has a limit of 4GiB of local ephemeral storage. Therefore, the Pod has a request of 4GiB of local ephemeral storage, and a limit of 8GiB of storage.
|
||||
In the following example, the Pod has two Containers. Each Container has a request of 2GiB of local ephemeral storage. Each Container has a limit of 4GiB of local ephemeral storage. Therefore, the Pod has a request of 4GiB of local ephemeral storage, and a limit of 8GiB of storage.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
@@ -386,77 +352,113 @@ spec:
|
||||
### How Pods with ephemeral-storage requests are scheduled
|
||||
|
||||
When you create a Pod, the Kubernetes scheduler selects a node for the Pod to
|
||||
run on. Each node has a maximum amount of local ephemeral storage it can provide for Pods. For more information, see ["Node Allocatable"](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable).
|
||||
run on. Each node has a maximum amount of local ephemeral storage it can provide for Pods. For more information, see [Node Allocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable).
|
||||
|
||||
The scheduler ensures that the sum of the resource requests of the scheduled Containers is less than the capacity of the node.
|
||||
|
||||
### How Pods with ephemeral-storage limits run
|
||||
### Ephemeral storage consumption management {#resource-emphemeralstorage-consumption}
|
||||
|
||||
For container-level isolation, if a Container's writable layer and logs usage exceeds its storage limit, the Pod will be evicted. For pod-level isolation, if the sum of the local ephemeral storage usage from all containers and also the Pod's emptyDir volumes exceeds the limit, the Pod will be evicted.
|
||||
If the kubelet is managing local ephemeral storage as a resource, then the
|
||||
kubelet measures storage use in:
|
||||
|
||||
### Monitoring ephemeral-storage consumption
|
||||
- `emptyDir` volumes, except _tmpfs_ `emptyDir` volumes
|
||||
- directories holding node-level logs
|
||||
- writeable container layers
|
||||
|
||||
When local ephemeral storage is used, it is monitored on an ongoing
|
||||
basis by the kubelet. The monitoring is performed by scanning each
|
||||
emptyDir volume, log directories, and writable layers on a periodic
|
||||
basis. Starting with Kubernetes 1.15, emptyDir volumes (but not log
|
||||
directories or writable layers) may, at the cluster operator's option,
|
||||
be managed by use of [project
|
||||
quotas](http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html).
|
||||
Project quotas were originally implemented in XFS, and have more
|
||||
recently been ported to ext4fs. Project quotas can be used for both
|
||||
monitoring and enforcement; as of Kubernetes 1.16, they are available
|
||||
as alpha functionality for monitoring only.
|
||||
If a Pod is using more ephemeral storage than you allow it to, the kubelet
|
||||
sets an eviction signal that triggers Pod eviction.
|
||||
|
||||
For container-level isolation, if a Container's writable layer and log
|
||||
usage exceeds its storage limit, the kubelet marks the Pod for eviction.
|
||||
|
||||
For pod-level isolation the kubelet works out an overall Pod storage limit by
|
||||
summing the limits for the containers in that Pod. In this case, if the sum of
|
||||
the local ephemeral storage usage from all containers and also the Pod's `emptyDir`
|
||||
volumes exceeds the overall Pod storage limit, then the kubelet also marks the Pod
|
||||
for eviction.
|
||||
|
||||
{{< caution >}}
|
||||
If the kubelet is not measuring local ephemeral storage, then a Pod
|
||||
that exceeds its local storage limit will not be evicted for breaching
|
||||
local storage resource limits.
|
||||
|
||||
However, if the filesystem space for writeable container layers, node-level logs,
|
||||
or `emptyDir` volumes falls low, the node
|
||||
{{< glossary_tooltip text="taints" term_id="taint" >}} itself as short on local storage
|
||||
and this taint triggers eviction for any Pods that don't specifically tolerate the taint.
|
||||
|
||||
See the supported [configurations](#configurations-for-local-ephemeral-storage)
|
||||
for ephemeral local storage.
|
||||
{{< /caution >}}
|
||||
|
||||
The kubelet supports different ways to measure Pod storage use:
|
||||
|
||||
{{< tabs name="resource-emphemeralstorage-measurement" >}}
|
||||
{{% tab name="Periodic scanning" %}}
|
||||
The kubelet performs regular, schedules checks that scan each
|
||||
`emptyDir` volume, container log directory, and writeable container layer.
|
||||
|
||||
The scan measures how much space is used.
|
||||
|
||||
{{< note >}}
|
||||
In this mode, the kubelet does not track open file descriptors
|
||||
for deleted files.
|
||||
|
||||
If you (or a container) create a file inside an `emptyDir` volume,
|
||||
something then opens that file, and you delete the file while it is
|
||||
still open, then the inode for the deleted file stays until you close
|
||||
that file but the kubelet does not categorize the space as in use.
|
||||
{{< /note >}}
|
||||
{{% /tab %}}
|
||||
{{% tab name="Filesystem project quota" %}}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.15" state="alpha" >}}
|
||||
|
||||
Project quotas are an operating-system level feature for managing
|
||||
storage use on filesystems. With Kubernetes, you can enable project
|
||||
quotas for monitoring storage use. Make sure that the filesystem
|
||||
backing the `emptyDir` volumes, on the node, provides project quota support.
|
||||
For example, XFS and ext4fs offer project quotas.
|
||||
|
||||
{{< note >}}
|
||||
Project quotas let you monitor storage use; they do not enforce limits.
|
||||
{{< /note >}}
|
||||
|
||||
Kubernetes uses project IDs starting from `1048576`. The IDs in use are
|
||||
registered in `/etc/projects` and `/etc/projid`. If project IDs in
|
||||
this range are used for other purposes on the system, those project
|
||||
IDs must be registered in `/etc/projects` and `/etc/projid` so that
|
||||
Kubernetes does not use them.
|
||||
|
||||
Quotas are faster and more accurate than directory scanning. When a
|
||||
directory is assigned to a project, all files created under a
|
||||
directory are created in that project, and the kernel merely has to
|
||||
keep track of how many blocks are in use by files in that project. If
|
||||
a file is created and deleted, but with an open file descriptor, it
|
||||
continues to consume space. This space will be tracked by the quota,
|
||||
but will not be seen by a directory scan.
|
||||
keep track of how many blocks are in use by files in that project.
|
||||
If a file is created and deleted, but has an open file descriptor,
|
||||
it continues to consume space. Quota tracking records that space accurately
|
||||
whereas directory scans overlook the storage used by deleted files.
|
||||
|
||||
Kubernetes uses project IDs starting from 1048576. The IDs in use are
|
||||
registered in `/etc/projects` and `/etc/projid`. If project IDs in
|
||||
this range are used for other purposes on the system, those project
|
||||
IDs must be registered in `/etc/projects` and `/etc/projid` to prevent
|
||||
Kubernetes from using them.
|
||||
|
||||
To enable use of project quotas, the cluster operator must do the
|
||||
following:
|
||||
If you want to use project quotas, you should:
|
||||
|
||||
* Enable the `LocalStorageCapacityIsolationFSQuotaMonitoring=true`
|
||||
feature gate in the kubelet configuration. This defaults to `false`
|
||||
in Kubernetes 1.16, so must be explicitly set to `true`.
|
||||
|
||||
* Ensure that the root partition (or optional runtime partition) is
|
||||
built with project quotas enabled. All XFS filesystems support
|
||||
project quotas, but ext4 filesystems must be built specially.
|
||||
|
||||
* Ensure that the root partition (or optional runtime partition) is
|
||||
mounted with project quotas enabled.
|
||||
|
||||
#### Building and mounting filesystems with project quotas enabled
|
||||
|
||||
XFS filesystems require no special action when building; they are
|
||||
automatically built with project quotas enabled.
|
||||
|
||||
Ext4fs filesystems must be built with quotas enabled, then they must
|
||||
be enabled in the filesystem:
|
||||
|
||||
```
|
||||
% sudo mkfs.ext4 other_ext4fs_args... -E quotatype=prjquota /dev/block_device
|
||||
% sudo tune2fs -O project -Q prjquota /dev/block_device
|
||||
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
in the kubelet configuration.
|
||||
|
||||
* Ensure that the the root fileystem (or optional runtime filesystem)
|
||||
has project quotas enabled. All XFS filesystems support project quotas.
|
||||
For ext4 filesystems, you need to enable the project quota tracking feature
|
||||
while the filesystem is not mounted.
|
||||
```bash
|
||||
# For ext4, with /dev/block-device not mounted
|
||||
sudo tune2fs -O project -Q prjquota /dev/block-device
|
||||
```
|
||||
|
||||
To mount the filesystem, both ext4fs and XFS require the `prjquota`
|
||||
option set in `/etc/fstab`:
|
||||
|
||||
```
|
||||
/dev/block_device /var/kubernetes_data defaults,prjquota 0 0
|
||||
```
|
||||
* Ensure that the root filesystem (or optional runtime filesystem is
|
||||
mounted with project quotas enabled. For both XFS and ext4fs, the
|
||||
mount option is named `prjquota`.
|
||||
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
## Extended resources
|
||||
|
||||
@@ -597,6 +599,145 @@ spec:
|
||||
example.com/foo: 1
|
||||
```
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### My Pods are pending with event message failedScheduling
|
||||
|
||||
If the scheduler cannot find any node where a Pod can fit, the Pod remains
|
||||
unscheduled until a place can be found. An event is produced each time the
|
||||
scheduler fails to find a place for the Pod, like this:
|
||||
|
||||
```shell
|
||||
kubectl describe pod frontend | grep -A 3 Events
|
||||
```
|
||||
```
|
||||
Events:
|
||||
FirstSeen LastSeen Count From Subobject PathReason Message
|
||||
36s 5s 6 {scheduler } FailedScheduling Failed for reason PodExceedsFreeCPU and possibly others
|
||||
```
|
||||
|
||||
In the preceding example, the Pod named "frontend" fails to be scheduled due to
|
||||
insufficient CPU resource on the node. Similar error messages can also suggest
|
||||
failure due to insufficient memory (PodExceedsFreeMemory). In general, if a Pod
|
||||
is pending with a message of this type, there are several things to try:
|
||||
|
||||
- Add more nodes to the cluster.
|
||||
- Terminate unneeded Pods to make room for pending Pods.
|
||||
- Check that the Pod is not larger than all the nodes. For example, if all the
|
||||
nodes have a capacity of `cpu: 1`, then a Pod with a request of `cpu: 1.1` will
|
||||
never be scheduled.
|
||||
|
||||
You can check node capacities and amounts allocated with the
|
||||
`kubectl describe nodes` command. For example:
|
||||
|
||||
```shell
|
||||
kubectl describe nodes e2e-test-node-pool-4lw4
|
||||
```
|
||||
```
|
||||
Name: e2e-test-node-pool-4lw4
|
||||
[ ... lines removed for clarity ...]
|
||||
Capacity:
|
||||
cpu: 2
|
||||
memory: 7679792Ki
|
||||
pods: 110
|
||||
Allocatable:
|
||||
cpu: 1800m
|
||||
memory: 7474992Ki
|
||||
pods: 110
|
||||
[ ... lines removed for clarity ...]
|
||||
Non-terminated Pods: (5 in total)
|
||||
Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits
|
||||
--------- ---- ------------ ---------- --------------- -------------
|
||||
kube-system fluentd-gcp-v1.38-28bv1 100m (5%) 0 (0%) 200Mi (2%) 200Mi (2%)
|
||||
kube-system kube-dns-3297075139-61lj3 260m (13%) 0 (0%) 100Mi (1%) 170Mi (2%)
|
||||
kube-system kube-proxy-e2e-test-... 100m (5%) 0 (0%) 0 (0%) 0 (0%)
|
||||
kube-system monitoring-influxdb-grafana-v4-z1m12 200m (10%) 200m (10%) 600Mi (8%) 600Mi (8%)
|
||||
kube-system node-problem-detector-v0.1-fj7m3 20m (1%) 200m (10%) 20Mi (0%) 100Mi (1%)
|
||||
Allocated resources:
|
||||
(Total limits may be over 100 percent, i.e., overcommitted.)
|
||||
CPU Requests CPU Limits Memory Requests Memory Limits
|
||||
------------ ---------- --------------- -------------
|
||||
680m (34%) 400m (20%) 920Mi (12%) 1070Mi (14%)
|
||||
```
|
||||
|
||||
In the preceding output, you can see that if a Pod requests more than 1120m
|
||||
CPUs or 6.23Gi of memory, it will not fit on the node.
|
||||
|
||||
By looking at the `Pods` section, you can see which Pods are taking up space on
|
||||
the node.
|
||||
|
||||
The amount of resources available to Pods is less than the node capacity, because
|
||||
system daemons use a portion of the available resources. The `allocatable` field
|
||||
[NodeStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#nodestatus-v1-core)
|
||||
gives the amount of resources that are available to Pods. For more information, see
|
||||
[Node Allocatable Resources](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md).
|
||||
|
||||
The [resource quota](/docs/concepts/policy/resource-quotas/) feature can be configured
|
||||
to limit the total amount of resources that can be consumed. If used in conjunction
|
||||
with namespaces, it can prevent one team from hogging all the resources.
|
||||
|
||||
### My Container is terminated
|
||||
|
||||
Your Container might get terminated because it is resource-starved. To check
|
||||
whether a Container is being killed because it is hitting a resource limit, call
|
||||
`kubectl describe pod` on the Pod of interest:
|
||||
|
||||
```shell
|
||||
kubectl describe pod simmemleak-hra99
|
||||
```
|
||||
```
|
||||
Name: simmemleak-hra99
|
||||
Namespace: default
|
||||
Image(s): saadali/simmemleak
|
||||
Node: kubernetes-node-tf0f/10.240.216.66
|
||||
Labels: name=simmemleak
|
||||
Status: Running
|
||||
Reason:
|
||||
Message:
|
||||
IP: 10.244.2.75
|
||||
Replication Controllers: simmemleak (1/1 replicas created)
|
||||
Containers:
|
||||
simmemleak:
|
||||
Image: saadali/simmemleak
|
||||
Limits:
|
||||
cpu: 100m
|
||||
memory: 50Mi
|
||||
State: Running
|
||||
Started: Tue, 07 Jul 2015 12:54:41 -0700
|
||||
Last Termination State: Terminated
|
||||
Exit Code: 1
|
||||
Started: Fri, 07 Jul 2015 12:54:30 -0700
|
||||
Finished: Fri, 07 Jul 2015 12:54:33 -0700
|
||||
Ready: False
|
||||
Restart Count: 5
|
||||
Conditions:
|
||||
Type Status
|
||||
Ready False
|
||||
Events:
|
||||
FirstSeen LastSeen Count From SubobjectPath Reason Message
|
||||
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {scheduler } scheduled Successfully assigned simmemleak-hra99 to kubernetes-node-tf0f
|
||||
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD pulled Pod container image "k8s.gcr.io/pause:0.8.0" already present on machine
|
||||
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD created Created with docker id 6a41280f516d
|
||||
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD started Started with docker id 6a41280f516d
|
||||
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} spec.containers{simmemleak} created Created with docker id 87348f12526a
|
||||
```
|
||||
|
||||
In the preceding example, the `Restart Count: 5` indicates that the `simmemleak`
|
||||
Container in the Pod was terminated and restarted five times.
|
||||
|
||||
You can call `kubectl get pod` with the `-o go-template=...` option to fetch the status
|
||||
of previously terminated Containers:
|
||||
|
||||
```shell
|
||||
kubectl get pod -o go-template='{{range.status.containerStatuses}}{{"Container Name: "}}{{.name}}{{"\r\nLastState: "}}{{.lastState}}{{end}}' simmemleak-hra99
|
||||
```
|
||||
```
|
||||
Container Name: simmemleak
|
||||
LastState: map[terminated:map[exitCode:137 reason:OOM Killed startedAt:2015-07-07T20:58:43Z finishedAt:2015-07-07T20:58:43Z containerID:docker://0e4095bba1feccdfe7ef9fb6ebffe972b4b14285d5acdec6f0d3ae8a22fad8b2]]
|
||||
```
|
||||
|
||||
You can see that the Container was terminated because of `reason:OOM Killed`, where `OOM` stands for Out Of Memory.
|
||||
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -608,8 +749,13 @@ spec:
|
||||
|
||||
* Get hands-on experience [assigning CPU resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-cpu-resource/).
|
||||
|
||||
* [Container API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
|
||||
* For more details about the difference between requests and limits, see
|
||||
[Resource QoS](https://git.k8s.io/community/contributors/design-proposals/node/resource-qos.md).
|
||||
|
||||
* [ResourceRequirements](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcerequirements-v1-core)
|
||||
* Read the [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) API reference
|
||||
|
||||
* Read the [ResourceRequirements](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcerequirements-v1-core) API reference
|
||||
|
||||
* Read about [project quotas](http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html) in XFS
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -854,6 +854,43 @@ start until all the Pod's volumes are mounted.
|
||||
|
||||
## Use cases
|
||||
|
||||
### Use-Case: As container environment variables
|
||||
|
||||
Create a secret
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: mysecret
|
||||
type: Opaque
|
||||
data:
|
||||
USER_NAME: YWRtaW4=
|
||||
PASSWORD: MWYyZDFlMmU2N2Rm
|
||||
```
|
||||
|
||||
Create the Secret:
|
||||
```shell
|
||||
kubectl apply -f mysecret.yaml
|
||||
```
|
||||
|
||||
Use `envFrom` to define all of the Secret’s data as container environment variables. The key from the Secret becomes the environment variable name in the Pod.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: secret-test-pod
|
||||
spec:
|
||||
containers:
|
||||
- name: test-container
|
||||
image: k8s.gcr.io/busybox
|
||||
command: [ "/bin/sh", "-c", "env" ]
|
||||
envFrom:
|
||||
- secretRef:
|
||||
name: mysecret
|
||||
restartPolicy: Never
|
||||
```
|
||||
|
||||
### Use-Case: Pod with ssh keys
|
||||
|
||||
Create a secret containing some ssh keys:
|
||||
|
||||
@@ -10,7 +10,7 @@ weight: 40
|
||||
|
||||
|
||||
{{% capture overview %}}
|
||||
Node affinity, described [here](/docs/concepts/configuration/assign-pod-node/#node-affinity-beta-feature),
|
||||
Node affinity, described [here](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity),
|
||||
is a property of *pods* that *attracts* them to a set of nodes (either as a
|
||||
preference or a hard requirement). Taints are the opposite -- they allow a
|
||||
*node* to *repel* a set of pods.
|
||||
|
||||
@@ -19,7 +19,7 @@ methods for adding custom resources and how to choose between them.
|
||||
## Custom resources
|
||||
|
||||
A *resource* is an endpoint in the [Kubernetes API](/docs/reference/using-api/api-overview/) that stores a collection of
|
||||
[API objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/) of a certain kind. For example, the built-in *pods* resource contains a collection of Pod objects.
|
||||
[API objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/) of a certain kind; for example, the built-in *pods* resource contains a collection of Pod objects.
|
||||
|
||||
A *custom resource* is an extension of the Kubernetes API that is not necessarily available in a default
|
||||
Kubernetes installation. It represents a customization of a particular Kubernetes installation. However,
|
||||
@@ -81,7 +81,7 @@ Signs that your API might not be declarative include:
|
||||
- The client says "do this", and then gets a synchronous response back when it is done.
|
||||
- The client says "do this", and then gets an operation ID back, and has to check a separate Operation object to determine completion of the request.
|
||||
- You talk about Remote Procedure Calls (RPCs).
|
||||
- Directly storing large amounts of data (e.g. > a few kB per object, or >1000s of objects).
|
||||
- Directly storing large amounts of data; for example, > a few kB per object, or > 1000s of objects.
|
||||
- High bandwidth access (10s of requests per second sustained) needed.
|
||||
- Store end-user data (such as images, PII, etc.) or other large-scale data processed by applications.
|
||||
- The natural operations on the objects are not CRUD-y.
|
||||
@@ -105,7 +105,7 @@ Use a [secret](/docs/concepts/configuration/secret/) for sensitive data, which i
|
||||
Use a custom resource (CRD or Aggregated API) if most of the following apply:
|
||||
|
||||
* You want to use Kubernetes client libraries and CLIs to create and update the new resource.
|
||||
* You want top-level support from kubectl (for example: `kubectl get my-object object-name`).
|
||||
* You want top-level support from `kubectl`; for example, `kubectl get my-object object-name`.
|
||||
* You want to build new automation that watches for updates on the new object, and then CRUD other objects, or vice versa.
|
||||
* You want to write automation that handles updates to the object.
|
||||
* You want to use Kubernetes API conventions like `.spec`, `.status`, and `.metadata`.
|
||||
@@ -120,7 +120,7 @@ Kubernetes provides two ways to add custom resources to your cluster:
|
||||
|
||||
Kubernetes provides these two options to meet the needs of different users, so that neither ease of use nor flexibility is compromised.
|
||||
|
||||
Aggregated APIs are subordinate APIServers that sit behind the primary API server, which acts as a proxy. This arrangement is called [API Aggregation](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) (AA). To users, it simply appears that the Kubernetes API is extended.
|
||||
Aggregated APIs are subordinate API servers that sit behind the primary API server, which acts as a proxy. This arrangement is called [API Aggregation](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) (AA). To users, it simply appears that the Kubernetes API is extended.
|
||||
|
||||
CRDs allow users to create new types of resources without adding another API server. You do not need to understand API Aggregation to use CRDs.
|
||||
|
||||
@@ -168,18 +168,18 @@ CRDs are easier to create than Aggregated APIs.
|
||||
| CRDs | Aggregated API |
|
||||
| --------------------------- | -------------- |
|
||||
| Do not require programming. Users can choose any language for a CRD controller. | Requires programming in Go and building binary and image. |
|
||||
| No additional service to run; CRs are handled by API Server. | An additional service to create and that could fail. |
|
||||
| No additional service to run; CRDs are handled by API server. | An additional service to create and that could fail. |
|
||||
| No ongoing support once the CRD is created. Any bug fixes are picked up as part of normal Kubernetes Master upgrades. | May need to periodically pickup bug fixes from upstream and rebuild and update the Aggregated API server. |
|
||||
| No need to handle multiple versions of your API. For example: when you control the client for this resource, you can upgrade it in sync with the API. | You need to handle multiple versions of your API, for example: when developing an extension to share with the world. |
|
||||
| No need to handle multiple versions of your API; for example, when you control the client for this resource, you can upgrade it in sync with the API. | You need to handle multiple versions of your API; for example, when developing an extension to share with the world. |
|
||||
|
||||
### Advanced features and flexibility
|
||||
|
||||
Aggregated APIs offer more advanced API features and customization of other features, for example: the storage layer.
|
||||
Aggregated APIs offer more advanced API features and customization of other features; for example, the storage layer.
|
||||
|
||||
| Feature | Description | CRDs | Aggregated API |
|
||||
| ------- | ----------- | ---- | -------------- |
|
||||
| Validation | Help users prevent errors and allow you to evolve your API independently of your clients. These features are most useful when there are many clients who can't all update at the same time. | Yes. Most validation can be specified in the CRD using [OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation). Any other validations supported by addition of a [Validating Webhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9). | Yes, arbitrary validation checks |
|
||||
| Defaulting | See above | Yes, either via [OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#defaulting) `default` keyword (GA in 1.17), or via a [Mutating Webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook) (though this will not be run when reading from etcd for old objects) | Yes |
|
||||
| Defaulting | See above | Yes, either via [OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#defaulting) `default` keyword (GA in 1.17), or via a [Mutating Webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook) (though this will not be run when reading from etcd for old objects). | Yes |
|
||||
| Multi-versioning | Allows serving the same object through two API versions. Can help ease API changes like renaming fields. Less important if you control your client versions. | [Yes](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning) | Yes |
|
||||
| Custom Storage | If you need storage with a different performance mode (e.g. a time-series database instead of key-value store) or isolation for security (e.g. encryption of sensitive information, etc.) | No | Yes |
|
||||
| Custom Business Logic | Perform arbitrary checks or actions when creating, reading, updating or deleting an object | Yes, using [Webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks). | Yes |
|
||||
@@ -188,22 +188,22 @@ Aggregated APIs offer more advanced API features and customization of other feat
|
||||
| Other Subresources | Add operations other than CRUD, such as "logs" or "exec". | No | Yes |
|
||||
| strategic-merge-patch | The new endpoints support PATCH with `Content-Type: application/strategic-merge-patch+json`. Useful for updating objects that may be modified both locally, and by the server. For more information, see ["Update API Objects in Place Using kubectl patch"](/docs/tasks/run-application/update-api-object-kubectl-patch/) | No | Yes |
|
||||
| Protocol Buffers | The new resource supports clients that want to use Protocol Buffers | No | Yes |
|
||||
| OpenAPI Schema | Is there an OpenAPI (swagger) schema for the types that can be dynamically fetched from the server? Is the user protected from misspelling field names by ensuring only allowed fields are set? Are types enforced (in other words, don't put an `int` in a `string` field?) | Yes, based on the [OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation) schema (GA in 1.16) | Yes |
|
||||
| OpenAPI Schema | Is there an OpenAPI (swagger) schema for the types that can be dynamically fetched from the server? Is the user protected from misspelling field names by ensuring only allowed fields are set? Are types enforced (in other words, don't put an `int` in a `string` field?) | Yes, based on the [OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation) schema (GA in 1.16). | Yes |
|
||||
|
||||
### Common Features
|
||||
|
||||
When you create a custom resource, either via a CRDs or an AA, you get many features for your API, compared to implementing it outside the Kubernetes platform:
|
||||
When you create a custom resource, either via a CRD or an AA, you get many features for your API, compared to implementing it outside the Kubernetes platform:
|
||||
|
||||
| Feature | What it does |
|
||||
| ------- | ------------ |
|
||||
| CRUD | The new endpoints support CRUD basic operations via HTTP and `kubectl` |
|
||||
| Watch | The new endpoints support Kubernetes Watch operations via HTTP |
|
||||
| Discovery | Clients like kubectl and dashboard automatically offer list, display, and field edit operations on your resources |
|
||||
| Discovery | Clients like `kubectl` and dashboard automatically offer list, display, and field edit operations on your resources |
|
||||
| json-patch | The new endpoints support PATCH with `Content-Type: application/json-patch+json` |
|
||||
| merge-patch | The new endpoints support PATCH with `Content-Type: application/merge-patch+json` |
|
||||
| HTTPS | The new endpoints uses HTTPS |
|
||||
| Built-in Authentication | Access to the extension uses the core apiserver (aggregation layer) for authentication |
|
||||
| Built-in Authorization | Access to the extension can reuse the authorization used by the core apiserver (e.g. RBAC) |
|
||||
| Built-in Authentication | Access to the extension uses the core API server (aggregation layer) for authentication |
|
||||
| Built-in Authorization | Access to the extension can reuse the authorization used by the core API server; for example, RBAC. |
|
||||
| Finalizers | Block deletion of extension resources until external cleanup happens. |
|
||||
| Admission Webhooks | Set default values and validate extension resources during any create/update/delete operation. |
|
||||
| UI/CLI Display | Kubectl, dashboard can display extension resources. |
|
||||
@@ -229,7 +229,7 @@ Aggregated API servers may use the same storage as the main API server, in which
|
||||
|
||||
### Authentication, authorization, and auditing
|
||||
|
||||
CRDs always use the same authentication, authorization, and audit logging as the built-in resources of your API Server.
|
||||
CRDs always use the same authentication, authorization, and audit logging as the built-in resources of your API server.
|
||||
|
||||
If you use RBAC for authorization, most RBAC roles will not grant access to the new resources (except the cluster-admin role or any role created with wildcard rules). You'll need to explicitly grant access to the new resources. CRDs and Aggregated APIs often come bundled with new role definitions for the types they add.
|
||||
|
||||
@@ -237,11 +237,11 @@ Aggregated API servers may or may not use the same authentication, authorization
|
||||
|
||||
## Accessing a custom resource
|
||||
|
||||
Kubernetes [client libraries](/docs/reference/using-api/client-libraries/) can be used to access custom resources. Not all client libraries support custom resources. The go and python client libraries do.
|
||||
Kubernetes [client libraries](/docs/reference/using-api/client-libraries/) can be used to access custom resources. Not all client libraries support custom resources. The _Go_ and _Python_ client libraries do.
|
||||
|
||||
When you add a custom resource, you can access it using:
|
||||
|
||||
- kubectl
|
||||
- `kubectl`
|
||||
- The kubernetes dynamic client.
|
||||
- A REST client that you write.
|
||||
- A client generated using [Kubernetes client generation tools](https://github.com/kubernetes/code-generator) (generating one is an advanced undertaking, but some projects may provide a client along with the CRD or AA).
|
||||
|
||||
@@ -25,10 +25,10 @@ Here's the diagram of a Kubernetes cluster with all the components tied together
|
||||
{{% capture body %}}
|
||||
## Control Plane Components
|
||||
|
||||
The Control Plane's components make global decisions about the cluster (for example, scheduling), as well as detecting and responding to cluster events (for example, starting up a new {{< glossary_tooltip text="pod" term_id="pod">}} when a deployment's `replicas` field is unsatisfied).
|
||||
The control plane's components make global decisions about the cluster (for example, scheduling), as well as detecting and responding to cluster events (for example, starting up a new {{< glossary_tooltip text="pod" term_id="pod">}} when a deployment's `replicas` field is unsatisfied).
|
||||
|
||||
Control Plane components can be run on any machine in the cluster. However,
|
||||
for simplicity, set up scripts typically start all Control Plane components on
|
||||
Control plane components can be run on any machine in the cluster. However,
|
||||
for simplicity, set up scripts typically start all control plane components on
|
||||
the same machine, and do not run user containers on this machine. See
|
||||
[Building High-Availability Clusters](/docs/admin/high-availability/) for an example multi-master-VM setup.
|
||||
|
||||
@@ -123,6 +123,6 @@ saving container logs to a central log store with search/browsing interface.
|
||||
{{% capture whatsnext %}}
|
||||
* Learn about [Nodes](/docs/concepts/architecture/nodes/)
|
||||
* Learn about [Controllers](/docs/concepts/architecture/controller/)
|
||||
* Learn about [kube-scheduler](/docs/concepts/scheduling/kube-scheduler/)
|
||||
* Learn about [kube-scheduler](/docs/concepts/scheduling-eviction/kube-scheduler/)
|
||||
* Read etcd's official [documentation](https://etcd.io/docs/)
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -33,7 +33,7 @@ providing a description of the characteristics you want the resource to have:
|
||||
its _desired state_.
|
||||
|
||||
The `status` describes the _current state_ of the object, supplied and updated
|
||||
by the Kubernetes and its components. The Kubernetes
|
||||
by the Kubernetes system and its components. The Kubernetes
|
||||
{{< glossary_tooltip text="control plane" term_id="control-plane" >}} continually
|
||||
and actively manages every object's actual state to match the desired state you
|
||||
supplied.
|
||||
|
||||
@@ -9,7 +9,7 @@ weight: 10
|
||||
{{% capture overview %}}
|
||||
|
||||
By default, containers run with unbounded [compute resources](/docs/user-guide/compute-resources) on a Kubernetes cluster.
|
||||
With resource quotas, cluster administrators can restrict resource consumption and creation on a namespace basis.
|
||||
With resource quotas, cluster administrators can restrict resource consumption and creation on a {{< glossary_tooltip text="namespace" term_id="namespace" >}} basis.
|
||||
Within a namespace, a Pod or Container can consume as much CPU and memory as defined by the namespace's resource quota. There is a concern that one Pod or Container could monopolize all available resources. A LimitRange is a policy to constrain resource allocations (to Pods or Containers) in a namespace.
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -38,7 +38,7 @@ The name of a LimitRange object must be a valid
|
||||
|
||||
### Overview of Limit Range
|
||||
|
||||
- The administrator creates one `LimitRange` in one namespace.
|
||||
- The administrator creates one LimitRange in one namespace.
|
||||
- Users create resources like Pods, Containers, and PersistentVolumeClaims in the namespace.
|
||||
- The `LimitRanger` admission controller enforces defaults and limits for all Pods and Containers that do not set compute resource requirements and tracks usage to ensure it does not exceed resource minimum, maximum and ratio defined in any LimitRange present in the namespace.
|
||||
- If creating or updating a resource (Pod, Container, PersistentVolumeClaim) that violates a LimitRange constraint, the request to the API server will fail with an HTTP status code `403 FORBIDDEN` and a message explaining the constraint that have been violated.
|
||||
@@ -56,19 +56,20 @@ there may be contention for resources. In this case, the Containers or Pods will
|
||||
|
||||
Neither contention nor changes to a LimitRange will affect already created resources.
|
||||
|
||||
## Examples
|
||||
|
||||
- See [how to configure minimum and maximum CPU constraints per namespace](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/).
|
||||
- See [how to configure minimum and maximum Memory constraints per namespace](https://kubernetes.io/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/).
|
||||
- See [how to configure default CPU Requests and Limits per namespace](https://kubernetes.io/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/).
|
||||
- See [how to configure default Memory Requests and Limits per namespace](https://kubernetes.io/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/).
|
||||
- Check [how to configure minimum and maximum Storage consumption per namespace](/docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage).
|
||||
- See a [detailed example on configuring quota per namespace](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
See [LimitRanger design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) for more information.
|
||||
Refer to the [LimitRanger design document](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) for more information.
|
||||
|
||||
For examples on using limits, see:
|
||||
|
||||
- [how to configure minimum and maximum CPU constraints per namespace](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/).
|
||||
- [how to configure minimum and maximum Memory constraints per namespace](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/).
|
||||
- [how to configure default CPU Requests and Limits per namespace](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/).
|
||||
- [how to configure default Memory Requests and Limits per namespace](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/).
|
||||
- [how to configure minimum and maximum Storage consumption per namespace](/docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage).
|
||||
- a [detailed example on configuring quota per namespace](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/).
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
title: "Scheduling and Eviction"
|
||||
weight: 90
|
||||
---
|
||||
|
||||
+1
-1
@@ -88,7 +88,7 @@ of the scheduler:
|
||||
|
||||
{{% /capture %}}
|
||||
{{% capture whatsnext %}}
|
||||
* Read about [scheduler performance tuning](/docs/concepts/scheduling/scheduler-perf-tuning/)
|
||||
* Read about [scheduler performance tuning](/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)
|
||||
* Read about [Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
|
||||
* Read the [reference documentation](/docs/reference/command-line-tools-reference/kube-scheduler/) for kube-scheduler
|
||||
* Learn about [configuring multiple schedulers](/docs/tasks/administer-cluster/configure-multiple-schedulers/)
|
||||
+2
-2
@@ -10,7 +10,7 @@ weight: 70
|
||||
|
||||
{{< feature-state for_k8s_version="v1.14" state="beta" >}}
|
||||
|
||||
[kube-scheduler](/docs/concepts/scheduling/kube-scheduler/#kube-scheduler)
|
||||
[kube-scheduler](/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler)
|
||||
is the Kubernetes default scheduler. It is responsible for placement of Pods
|
||||
on Nodes in a cluster.
|
||||
|
||||
@@ -70,7 +70,7 @@ of all the nodes in your cluster. The kube-scheduler converts this into an
|
||||
integer number of nodes. During scheduling, if the kube-scheduler has identified
|
||||
enough feasible nodes to exceed the configured percentage, the kube-scheduler
|
||||
stops searching for more feasible nodes and moves on to the
|
||||
[scoring phase](/docs/concepts/scheduling/kube-scheduler/#kube-scheduler-implementation).
|
||||
[scoring phase](/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler-implementation).
|
||||
|
||||
[How the scheduler iterates over Nodes](#how-the-scheduler-iterates-over-nodes)
|
||||
describes the process in detail.
|
||||
@@ -1,5 +0,0 @@
|
||||
---
|
||||
title: "Scheduling"
|
||||
weight: 90
|
||||
---
|
||||
|
||||
@@ -143,8 +143,8 @@ Area of Concern for Code | Recommendation |
|
||||
Access over TLS only | If your code needs to communicate via TCP, ideally it would be performing a TLS handshake with the client ahead of time. With the exception of a few cases, the default behavior should be to encrypt everything in transit. Going one step further, even "behind the firewall" in our VPC's it's still a good idea to encrypt network traffic between services. This can be done through a process known as mutual or [mTLS](https://en.wikipedia.org/wiki/Mutual_authentication) which performs a two sided verification of communication between two certificate holding services. There are numerous tools that can be used to accomplish this in Kubernetes such as [Linkerd](https://linkerd.io/) and [Istio](https://istio.io/). |
|
||||
Limiting port ranges of communication | This recommendation may be a bit self-explanatory, but wherever possible you should only expose the ports on your service that are absolutely essential for communication or metric gathering. |
|
||||
3rd Party Dependency Security | Since our applications tend to have dependencies outside of our own codebases, it is a good practice to regularly scan the code's dependencies to ensure that they are still secure with no vulnerabilities currently filed against them. Each language has a tool for performing this check automatically. |
|
||||
Static Code Analysis | Most languages provide a way for a snippet of code to be analyzed for any potentially unsafe coding practices. Whenever possible you should perform checks using automated tooling that can scan codebases for common security errors. Some of the tools can be found here: https://www.owasp.org/index.php/Source_Code_Analysis_Tools |
|
||||
Dynamic probing attacks | There are a few automated tools that are able to be run against your service to try some of the well known attacks that commonly befall services. These include SQL injection, CSRF, and XSS. One of the most popular dynamic analysis tools is the OWASP Zed Attack proxy https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project |
|
||||
Static Code Analysis | Most languages provide a way for a snippet of code to be analyzed for any potentially unsafe coding practices. Whenever possible you should perform checks using automated tooling that can scan codebases for common security errors. Some of the tools can be found here: https://owasp.org/www-community/Source_Code_Analysis_Tools |
|
||||
Dynamic probing attacks | There are a few automated tools that are able to be run against your service to try some of the well known attacks that commonly befall services. These include SQL injection, CSRF, and XSS. One of the most popular dynamic analysis tools is the OWASP Zed Attack proxy https://owasp.org/www-project-zap/ |
|
||||
|
||||
|
||||
## Robust automation
|
||||
|
||||
@@ -164,7 +164,7 @@ following pod-specific DNS policies. These policies are specified in the
|
||||
domain suffix, such as "`www.kubernetes.io`", is forwarded to the upstream
|
||||
nameserver inherited from the node. Cluster administrators may have extra
|
||||
stub-domain and upstream DNS servers configured.
|
||||
See [related discussion](/docs/tasks/administer-cluster/dns-custom-nameservers/#impacts-on-pods)
|
||||
See [related discussion](/docs/tasks/administer-cluster/dns-custom-nameservers/#effects-on-pods)
|
||||
for details on how DNS queries are handled in those cases.
|
||||
- "`ClusterFirstWithHostNet`": For Pods running with hostNetwork, you should
|
||||
explicitly set its DNS policy "`ClusterFirstWithHostNet`".
|
||||
|
||||
@@ -653,6 +653,16 @@ metadata:
|
||||
[...]
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="IBM Cloud" %}}
|
||||
```yaml
|
||||
[...]
|
||||
metadata:
|
||||
name: my-service
|
||||
annotations:
|
||||
service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"
|
||||
[...]
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="OpenStack" %}}
|
||||
```yaml
|
||||
[...]
|
||||
@@ -1069,7 +1079,7 @@ fail with a message indicating an IP address could not be allocated.
|
||||
|
||||
In the control plane, a background controller is responsible for creating that
|
||||
map (needed to support migrating from older versions of Kubernetes that used
|
||||
in-memory locking). Kubernetes also uses controllers to checking for invalid
|
||||
in-memory locking). Kubernetes also uses controllers to check for invalid
|
||||
assignments (eg due to administrator intervention) and for cleaning up allocated
|
||||
IP addresses that are no longer used by any Services.
|
||||
|
||||
|
||||
@@ -301,12 +301,13 @@ If `replication-type` is set to `none`, a regular (zonal) PD will be provisioned
|
||||
|
||||
If `replication-type` is set to `regional-pd`, a
|
||||
[Regional Persistent Disk](https://cloud.google.com/compute/docs/disks/#repds)
|
||||
will be provisioned. In this case, users must use `zones` instead of `zone` to
|
||||
specify the desired replication zones. If exactly two zones are specified, the
|
||||
Regional PD will be provisioned in those zones. If more than two zones are
|
||||
specified, Kubernetes will arbitrarily choose among the specified zones. If the
|
||||
`zones` parameter is omitted, Kubernetes will arbitrarily choose among zones
|
||||
managed by the cluster.
|
||||
will be provisioned. It's highly recommended to have
|
||||
`volumeBindingMode: WaitForFirstConsumer` set, in which case when you create
|
||||
a Pod that consumes a PersistentVolumeClaim which uses this StorageClass, a
|
||||
Regional Persistent Disk is provisioned with two zones. One zone is the same
|
||||
as the zone that the Pod is scheduled in. The other zone is randomly picked
|
||||
from the zones available to the cluster. Disk zones can be further constrained
|
||||
using `allowedTopologies`.
|
||||
|
||||
{{< note >}}
|
||||
`zone` and `zones` parameters are deprecated and replaced with
|
||||
|
||||
@@ -61,7 +61,9 @@ In the case of pre-provisioned binding, the VolumeSnapshot will remain unbound u
|
||||
|
||||
### Persistent Volume Claim as Snapshot Source Protection
|
||||
|
||||
The purpose of this protection is to ensure that in-use PersistentVolumeClaim API objects are not removed from the system while a snapshot is being taken from it (as this may result in data loss).
|
||||
The purpose of this protection is to ensure that in-use
|
||||
{{< glossary_tooltip text="PersistentVolumeClaim" term_id="persistent-volume-claim" >}}
|
||||
API objects are not removed from the system while a snapshot is being taken from it (as this may result in data loss).
|
||||
|
||||
While a snapshot is being taken of a PersistentVolumeClaim, that PersistentVolumeClaim is in-use. If you delete a PersistentVolumeClaim API object in active use as a snapshot source, the PersistentVolumeClaim object is not removed immediately. Instead, removal of the PersistentVolumeClaim object is postponed until the snapshot is readyToUse or aborted.
|
||||
|
||||
|
||||
@@ -12,14 +12,19 @@ weight: 80
|
||||
|
||||
{{< feature-state for_k8s_version="v1.8" state="beta" >}}
|
||||
|
||||
A _Cron Job_ creates [Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/) on a time-based schedule.
|
||||
A _CronJob_ creates {{< glossary_tooltip term_id="job" text="Jobs" >}} on a repeating schedule.
|
||||
|
||||
One CronJob object is like one line of a _crontab_ (cron table) file. It runs a job periodically
|
||||
on a given schedule, written in [Cron](https://en.wikipedia.org/wiki/Cron) format.
|
||||
|
||||
{{< note >}}
|
||||
All **CronJob** `schedule:` times are denoted in UTC.
|
||||
{{< /note >}}
|
||||
{{< caution >}}
|
||||
All **CronJob** `schedule:` times are based on the timezone of the
|
||||
{{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}.
|
||||
|
||||
If your control plane runs the kube-controller-manager in Pods or bare
|
||||
containers, the timezone set for the kube-controller-manager container determines the timezone
|
||||
that the cron job controller uses.
|
||||
{{< /caution >}}
|
||||
|
||||
When creating the manifest for a CronJob resource, make sure the name you provide
|
||||
is a valid [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
|
||||
@@ -27,14 +32,26 @@ The name must be no longer than 52 characters. This is because the CronJob contr
|
||||
append 11 characters to the job name provided and there is a constraint that the
|
||||
maximum length of a Job name is no more than 63 characters.
|
||||
|
||||
For instructions on creating and working with cron jobs, and for an example of a spec file for a cron job, see [Running automated tasks with cron jobs](/docs/tasks/job/automated-tasks-with-cron-jobs).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Cron Job Limitations
|
||||
## CronJob
|
||||
|
||||
CronJobs are useful for creating periodic and recurring tasks, like running backups or
|
||||
sending emails. CronJobs can also schedule individual tasks for a specific time, such as
|
||||
scheduling a Job for when your cluster is likely to be idle.
|
||||
|
||||
### Example
|
||||
|
||||
This example CronJob manifest prints the current time and a hello message every minute:
|
||||
|
||||
{{< codenew file="application/job/cronjob.yaml" >}}
|
||||
|
||||
([Running Automated Tasks with a CronJob](/docs/tasks/job/automated-tasks-with-cron-jobs/)
|
||||
takes you through this example in more detail).
|
||||
|
||||
## CronJob limitations {#cron-job-limitations}
|
||||
|
||||
A cron job creates a job object _about_ once per execution time of its schedule. We say "about" because there
|
||||
are certain circumstances where two jobs might be created, or no job might be created. We attempt to make these rare,
|
||||
@@ -66,3 +83,11 @@ The CronJob is only responsible for creating Jobs that match its schedule, and
|
||||
the Job in turn is responsible for the management of the Pods it represents.
|
||||
|
||||
{{% /capture %}}
|
||||
{{% capture whatsnext %}}
|
||||
[Cron expression format](https://pkg.go.dev/github.com/robfig/cron?tab=doc#hdr-CRON_Expression_Format)
|
||||
documents the format of CronJob `schedule` fields.
|
||||
|
||||
For instructions on creating and working with cron jobs, and for an example of CronJob
|
||||
manifest, see [Running automated tasks with cron jobs](/docs/tasks/job/automated-tasks-with-cron-jobs).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -48,24 +48,24 @@ The following is an example of a Deployment. It creates a ReplicaSet to bring up
|
||||
In this example:
|
||||
|
||||
* A Deployment named `nginx-deployment` is created, indicated by the `.metadata.name` field.
|
||||
* The Deployment creates three replicated Pods, indicated by the `replicas` field.
|
||||
* The `selector` field defines how the Deployment finds which Pods to manage.
|
||||
* The Deployment creates three replicated Pods, indicated by the `.spec.replicas` field.
|
||||
* The `.spec.selector` field defines how the Deployment finds which Pods to manage.
|
||||
In this case, you simply select a label that is defined in the Pod template (`app: nginx`).
|
||||
However, more sophisticated selection rules are possible,
|
||||
as long as the Pod template itself satisfies the rule.
|
||||
{{< note >}}
|
||||
The `matchLabels` field is a map of {key,value} pairs. A single {key,value} in the `matchLabels` map
|
||||
The `.spec.selector.matchLabels` field is a map of {key,value} pairs. A single {key,value} in the `matchLabels` map
|
||||
is equivalent to an element of `matchExpressions`, whose key field is "key" the operator is "In",
|
||||
and the values array contains only "value".
|
||||
All of the requirements, from both `matchLabels` and `matchExpressions`, must be satisfied in order to match.
|
||||
{{< /note >}}
|
||||
|
||||
* The `template` field contains the following sub-fields:
|
||||
* The Pods are labeled `app: nginx`using the `labels` field.
|
||||
* The Pods are labeled `app: nginx`using the `.metadata.labels` field.
|
||||
* The Pod template's specification, or `.template.spec` field, indicates that
|
||||
the Pods run one container, `nginx`, which runs the `nginx`
|
||||
[Docker Hub](https://hub.docker.com/) image at version 1.14.2.
|
||||
* Create one container and name it `nginx` using the `name` field.
|
||||
* Create one container and name it `nginx` using the `.spec.template.spec.containers[0].name` field.
|
||||
|
||||
Follow the steps given below to create the above Deployment:
|
||||
|
||||
@@ -89,9 +89,8 @@ In this example:
|
||||
```
|
||||
When you inspect the Deployments in your cluster, the following fields are displayed:
|
||||
|
||||
* `NAME` lists the names of the Deployments in the cluster.
|
||||
* `DESIRED` displays the desired number of _replicas_ of the application, which you define when you create the Deployment. This is the _desired state_.
|
||||
* `CURRENT` displays how many replicas are currently running.
|
||||
* `NAME` lists the names of the Deployments in the namespace.
|
||||
* `READY` displays how many replicas of the application are available to your users. It follows the pattern ready/desired.
|
||||
* `UP-TO-DATE` displays the number of replicas that have been updated to achieve the desired state.
|
||||
* `AVAILABLE` displays how many replicas of the application are available to your users.
|
||||
* `AGE` displays the amount of time that the application has been running.
|
||||
@@ -116,8 +115,16 @@ In this example:
|
||||
NAME DESIRED CURRENT READY AGE
|
||||
nginx-deployment-75675f5897 3 3 3 18s
|
||||
```
|
||||
ReplicaSet output shows the following fields:
|
||||
|
||||
* `NAME` lists the names of the ReplicaSets in the namespace.
|
||||
* `DESIRED` displays the desired number of _replicas_ of the application, which you define when you create the Deployment. This is the _desired state_.
|
||||
* `CURRENT` displays how many replicas are currently running.
|
||||
* `READY` displays how many replicas of the application are available to your users.
|
||||
* `AGE` displays the amount of time that the application has been running.
|
||||
|
||||
Notice that the name of the ReplicaSet is always formatted as `[DEPLOYMENT-NAME]-[RANDOM-STRING]`. The random string is
|
||||
randomly generated and uses the pod-template-hash as a seed.
|
||||
randomly generated and uses the `pod-template-hash` as a seed.
|
||||
|
||||
6. To see the labels automatically generated for each Pod, run `kubectl get pods --show-labels`. The following output is returned:
|
||||
```shell
|
||||
@@ -510,7 +517,7 @@ Follow the steps given below to rollback the Deployment from the current version
|
||||
|
||||
The output is similar to this:
|
||||
```
|
||||
deployment.apps/nginx-deployment
|
||||
deployment.apps/nginx-deployment rolled back
|
||||
```
|
||||
Alternatively, you can rollback to a specific revision by specifying it with `--to-revision`:
|
||||
|
||||
@@ -520,7 +527,7 @@ Follow the steps given below to rollback the Deployment from the current version
|
||||
|
||||
The output is similar to this:
|
||||
```
|
||||
deployment.apps/nginx-deployment
|
||||
deployment.apps/nginx-deployment rolled back
|
||||
```
|
||||
|
||||
For more details about rollout related commands, read [`kubectl rollout`](/docs/reference/generated/kubectl/kubectl-commands#rollout).
|
||||
@@ -1017,7 +1024,7 @@ can create multiple Deployments, one for each release, following the canary patt
|
||||
|
||||
## Writing a Deployment Spec
|
||||
|
||||
As with all other Kubernetes configs, a Deployment needs `apiVersion`, `kind`, and `metadata` fields.
|
||||
As with all other Kubernetes configs, a Deployment needs `.apiVersion`, `.kind`, and `.metadata` fields.
|
||||
For general information about working with config files, see [deploying applications](/docs/tutorials/stateless-application/run-stateless-application-deployment/),
|
||||
configuring containers, and [using kubectl to manage resources](/docs/concepts/overview/working-with-objects/object-management/) documents.
|
||||
The name of a Deployment object must be a valid
|
||||
|
||||
@@ -205,27 +205,30 @@ Once Pod is assigned to a node by scheduler, kubelet starts creating containers
|
||||
...
|
||||
```
|
||||
|
||||
## Pod readiness gate
|
||||
## Pod readiness {#pod-readiness-gate}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.14" state="stable" >}}
|
||||
|
||||
In order to add extensibility to Pod readiness by enabling the injection of
|
||||
extra feedback or signals into `PodStatus`, Kubernetes 1.11 introduced a
|
||||
feature named [Pod ready++](https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/0007-pod-ready%2B%2B.md).
|
||||
You can use the new field `ReadinessGate` in the `PodSpec` to specify additional
|
||||
conditions to be evaluated for Pod readiness. If Kubernetes cannot find such a
|
||||
Your application can inject extra feedback or signals into PodStatus:
|
||||
_Pod readiness_. To use this, set `readinessGates` in the PodSpec to specify
|
||||
a list of additional conditions that the kubelet evaluates for Pod readiness.
|
||||
|
||||
Readiness gates are determined by the current state of `status.condition`
|
||||
fields for the Pod. If Kubernetes cannot find such a
|
||||
condition in the `status.conditions` field of a Pod, the status of the condition
|
||||
is default to "`False`". Below is an example:
|
||||
is defaulted to "`False`". Below is an example:
|
||||
|
||||
Here is an example:
|
||||
|
||||
```yaml
|
||||
Kind: Pod
|
||||
kind: Pod
|
||||
...
|
||||
spec:
|
||||
readinessGates:
|
||||
- conditionType: "www.example.com/feature-1"
|
||||
status:
|
||||
conditions:
|
||||
- type: Ready # this is a builtin PodCondition
|
||||
- type: Ready # a built in PodCondition
|
||||
status: "False"
|
||||
lastProbeTime: null
|
||||
lastTransitionTime: 2018-01-01T00:00:00Z
|
||||
@@ -239,19 +242,26 @@ status:
|
||||
...
|
||||
```
|
||||
|
||||
The new Pod conditions must comply with Kubernetes [label key format](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set).
|
||||
Since the `kubectl patch` command still doesn't support patching object status,
|
||||
the new Pod conditions have to be injected through the `PATCH` action using
|
||||
one of the [KubeClient libraries](/docs/reference/using-api/client-libraries/).
|
||||
The Pod conditions you add must have names that meet the Kubernetes [label key format](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set).
|
||||
|
||||
With the introduction of new Pod conditions, a Pod is evaluated to be ready **only**
|
||||
when both the following statements are true:
|
||||
|
||||
### Status for Pod readiness {#pod-readiness-status}
|
||||
|
||||
The `kubectl patch` command does not support patching object status.
|
||||
To set these `status.conditions` for the pod, applications and
|
||||
{{< glossary_tooltip term_id="operator-pattern" text="operators">}} should use
|
||||
the `PATCH` action.
|
||||
You can use a [Kubernetes client library](/docs/reference/using-api/client-libraries/) to
|
||||
write code that sets custom Pod conditions for Pod readiness.
|
||||
|
||||
For a Pod that uses custom conditions, that Pod is evaluated to be ready **only**
|
||||
when both the following statements apply:
|
||||
|
||||
* All containers in the Pod are ready.
|
||||
* All conditions specified in `ReadinessGates` are "`True`".
|
||||
* All conditions specified in `ReadinessGates` are `True`.
|
||||
|
||||
To facilitate this change to Pod readiness evaluation, a new Pod condition
|
||||
`ContainersReady` is introduced to capture the old Pod `Ready` condition.
|
||||
When a Pod's containers are Ready but at least one custom condition is missing or
|
||||
`False`, the kubelet sets the Pod's condition to `ContainersReady`.
|
||||
|
||||
## Restart policy
|
||||
|
||||
@@ -268,32 +278,31 @@ once bound to a node, a Pod will never be rebound to another node.
|
||||
|
||||
## Pod lifetime
|
||||
|
||||
In general, Pods remain until a human or controller process explicitly removes them.
|
||||
In general, Pods remain until a human or
|
||||
{{< glossary_tooltip term_id="controller" text="controller" >}} process
|
||||
explicitly removes them.
|
||||
The control plane cleans up terminated Pods (with a phase of `Succeeded` or
|
||||
`Failed`), when the number of Pods exceeds the configured threshold
|
||||
(determined by `terminated-pod-gc-threshold` in the kube-controller-manager).
|
||||
This avoids a resource leak as Pods are created and terminated over time.
|
||||
|
||||
Three types of controllers are available:
|
||||
There are different kinds of resources for creating Pods:
|
||||
|
||||
- Use a [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/) for Pods that are expected to terminate,
|
||||
- Use a {{< glossary_tooltip term_id="deployment" >}},
|
||||
{{< glossary_tooltip term_id="replica-set" >}} or {{< glossary_tooltip term_id="statefulset" >}}
|
||||
for Pods that are not expected to terminate, for example, web servers.
|
||||
|
||||
- Use a {{< glossary_tooltip term_id="job" >}}
|
||||
for Pods that are expected to terminate once their work is complete;
|
||||
for example, batch computations. Jobs are appropriate only for Pods with
|
||||
`restartPolicy` equal to OnFailure or Never.
|
||||
|
||||
- Use a [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/),
|
||||
[ReplicaSet](/docs/concepts/workloads/controllers/replicaset/), or
|
||||
[Deployment](/docs/concepts/workloads/controllers/deployment/)
|
||||
for Pods that are not expected to terminate, for example, web servers.
|
||||
ReplicationControllers are appropriate only for Pods with a `restartPolicy` of
|
||||
Always.
|
||||
- Use a {{< glossary_tooltip term_id="daemonset" >}}
|
||||
for Pods that need to run one per eligible node.
|
||||
|
||||
- Use a [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) for Pods that need to run one per
|
||||
machine, because they provide a machine-specific system service.
|
||||
|
||||
All three types of controllers contain a PodTemplate. It
|
||||
is recommended to create the appropriate controller and let
|
||||
it create Pods, rather than directly create Pods yourself. That is because Pods
|
||||
alone are not resilient to machine failures, but controllers are.
|
||||
All workload resources contain a PodSpec. It is recommended to create the
|
||||
appropriate workload resource and let the resource's controller create Pods
|
||||
for you, rather than directly create Pods yourself.
|
||||
|
||||
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.
|
||||
|
||||
@@ -17,9 +17,9 @@ This page provides an overview of `Pod`, the smallest deployable object in the K
|
||||
{{% capture body %}}
|
||||
## Understanding Pods
|
||||
|
||||
A *Pod* is the basic execution unit of a Kubernetes application--the smallest and simplest unit in the Kubernetes object model that you create or deploy. A Pod represents processes running on your {{< glossary_tooltip term_id="cluster" >}}.
|
||||
A *Pod* is the basic execution unit of a Kubernetes application--the smallest and simplest unit in the Kubernetes object model that you create or deploy. A Pod represents processes running on your {{< glossary_tooltip term_id="cluster" text="cluster" >}}.
|
||||
|
||||
A Pod encapsulates an application's container (or, in some cases, multiple containers), storage resources, a unique network IP, and options that govern how the container(s) should run. A Pod represents a unit of deployment: *a single instance of an application in Kubernetes*, which might consist of either a single {{< glossary_tooltip text="container" term_id="container" >}} or a small number of containers that are tightly coupled and that share resources.
|
||||
A Pod encapsulates an application's container (or, in some cases, multiple containers), storage resources, a unique network identity (IP address), as well as options that govern how the container(s) should run. A Pod represents a unit of deployment: *a single instance of an application in Kubernetes*, which might consist of either a single {{< glossary_tooltip text="container" term_id="container" >}} or a small number of containers that are tightly coupled and that share resources.
|
||||
|
||||
[Docker](https://www.docker.com) is the most common container runtime used in a Kubernetes Pod, but Pods support other [container runtimes](/docs/setup/production-environment/container-runtimes/) as well.
|
||||
|
||||
@@ -28,14 +28,12 @@ Pods in a Kubernetes cluster can be used in two main ways:
|
||||
|
||||
* **Pods that run a single container**. The "one-container-per-Pod" model is the most common Kubernetes use case; in this case, you can think of a Pod as a wrapper around a single container, and Kubernetes manages the Pods rather than the containers directly.
|
||||
* **Pods that run multiple containers that need to work together**. A Pod might encapsulate an application composed of multiple co-located containers that are tightly coupled and need to share resources. These co-located containers might form a single cohesive unit of service--one container serving files from a shared volume to the public, while a separate "sidecar" container refreshes or updates those files. The Pod wraps these containers and storage resources together as a single manageable entity.
|
||||
The [Kubernetes Blog](https://kubernetes.io/blog) has some additional information on Pod use cases. For more information, see:
|
||||
|
||||
* [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)
|
||||
* [Container Design Patterns](https://kubernetes.io/blog/2016/06/container-design-patterns)
|
||||
Each Pod is meant to run a single instance of a given application. If you want to scale your application horizontally (to provide more overall resources by running more instances), you should use multiple Pods, one for each instance. In Kubernetes, this is typically referred to as _replication_.
|
||||
Replicated Pods are usually created and managed as a group by a workload resource and its {{< glossary_tooltip text="_controller_" term_id="controller" >}}.
|
||||
See [Pods and controllers](#pods-and-controllers) for more information on how Kubernetes uses controllers to implement workload scaling and healing.
|
||||
|
||||
Each Pod is meant to run a single instance of a given application. If you want to scale your application horizontally (e.g., run multiple instances), you should use multiple Pods, one for each instance. In Kubernetes, this is generally referred to as _replication_. Replicated Pods are usually created and managed as a group by an abstraction called a Controller. See [Pods and Controllers](#pods-and-controllers) for more information.
|
||||
|
||||
### How Pods manage multiple Containers
|
||||
### How Pods manage multiple containers
|
||||
|
||||
Pods are designed to support multiple cooperating processes (as containers) that form a cohesive unit of service. The containers in a Pod are automatically co-located and co-scheduled on the same physical or virtual machine in the cluster. The containers can share resources and dependencies, communicate with one another, and coordinate when and how they are terminated.
|
||||
|
||||
@@ -49,62 +47,75 @@ Pods provide two kinds of shared resources for their constituent containers: *ne
|
||||
|
||||
#### Networking
|
||||
|
||||
Each Pod is assigned a unique IP address. Every container in a Pod shares the network namespace, including the IP address and network ports. Containers *inside a Pod* can communicate with one another using `localhost`. When containers in a Pod communicate with entities *outside the Pod*, they must coordinate how they use the shared network resources (such as ports).
|
||||
Each Pod is assigned a unique IP address for each address family. Every container in a Pod shares the network namespace, including the IP address and network ports. Containers *inside a Pod* can communicate with one another using `localhost`. When containers in a Pod communicate with entities *outside the Pod*, they must coordinate how they use the shared network resources (such as ports).
|
||||
|
||||
#### Storage
|
||||
|
||||
A Pod can specify a set of shared storage {{< glossary_tooltip text="Volumes" term_id="volume" >}}. All containers in the Pod can access the shared volumes, allowing those containers to share data. Volumes also allow persistent data in a Pod to survive in case one of the containers within needs to be restarted. See [Volumes](/docs/concepts/storage/volumes/) for more information on how Kubernetes implements shared storage in a Pod.
|
||||
A Pod can specify a set of shared storage {{< glossary_tooltip text="volumes" term_id="volume" >}}. All containers in the Pod can access the shared volumes, allowing those containers to share data. Volumes also allow persistent data in a Pod to survive in case one of the containers within needs to be restarted. See [Volumes](/docs/concepts/storage/volumes/) for more information on how Kubernetes implements shared storage in a Pod.
|
||||
|
||||
## Working with Pods
|
||||
|
||||
You'll rarely create individual Pods directly in Kubernetes--even singleton Pods. This is because Pods are designed as relatively ephemeral, disposable entities. When a Pod gets created (directly by you, or indirectly by a Controller), it is scheduled to run on a {{< glossary_tooltip term_id="node" >}} in your cluster. The Pod remains on that Node until the process is terminated, the pod object is deleted, the Pod is *evicted* for lack of resources, or the Node fails.
|
||||
You'll rarely create individual Pods directly in Kubernetes--even singleton Pods. This is because Pods are designed as relatively ephemeral, disposable entities. When a Pod gets created (directly by you, or indirectly by a {{< glossary_tooltip text="_controller_" term_id="controller" >}}), it is scheduled to run on a {{< glossary_tooltip term_id="node" >}} in your cluster. The Pod remains on that node until the process is terminated, the pod object is deleted, the Pod is *evicted* for lack of resources, or the node fails.
|
||||
|
||||
{{< note >}}
|
||||
Restarting a container in a Pod should not be confused with restarting the Pod. The Pod itself does not run, but is an environment the containers run in and persists until it is deleted.
|
||||
Restarting a container in a Pod should not be confused with restarting a Pod. A Pod is not a process, but an environment for running a container. A Pod persists until it is deleted.
|
||||
{{< /note >}}
|
||||
|
||||
Pods do not, by themselves, self-heal. If a Pod is scheduled to a Node that fails, or if the scheduling operation itself fails, the Pod is deleted; likewise, a Pod won't survive an eviction due to a lack of resources or Node maintenance. Kubernetes uses a higher-level abstraction, called a *Controller*, that handles the work of managing the relatively disposable Pod instances. Thus, while it is possible to use Pod directly, it's far more common in Kubernetes to manage your pods using a Controller. See [Pods and Controllers](#pods-and-controllers) for more information on how Kubernetes uses Controllers to implement Pod scaling and healing.
|
||||
Pods do not, by themselves, self-heal. If a Pod is scheduled to a Node that fails, or if the scheduling operation itself fails, the Pod is deleted; likewise, a Pod won't survive an eviction due to a lack of resources or Node maintenance. Kubernetes uses a higher-level abstraction, called a controller, that handles the work of managing the relatively disposable Pod instances. Thus, while it is possible to use Pod directly, it's far more common in Kubernetes to manage your pods using a controller.
|
||||
|
||||
### Pods and Controllers
|
||||
### Pods and controllers
|
||||
|
||||
A Controller can create and manage multiple Pods for you, handling replication and rollout and providing self-healing capabilities at cluster scope. For example, if a Node fails, the Controller might automatically replace the Pod by scheduling an identical replacement on a different Node.
|
||||
You can use workload resources to create and manage multiple Pods for you. A controller for the resource handles replication and rollout and automatic healing in case of Pod failure. For example, if a Node fails, a controller notices that Pods on that Node have stopped working and creates a replacement Pod. The scheduler places the replacement Pod onto a healthy Node.
|
||||
|
||||
Some examples of Controllers that contain one or more pods include:
|
||||
Here are some examples of workload resources that manage one or more Pods:
|
||||
|
||||
* [Deployment](/docs/concepts/workloads/controllers/deployment/)
|
||||
* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/)
|
||||
* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/)
|
||||
* {{< glossary_tooltip text="Deployment" term_id="deployment" >}}
|
||||
* {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}
|
||||
* {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}
|
||||
|
||||
In general, Controllers use a Pod Template that you provide to create the Pods for which it is responsible.
|
||||
|
||||
## Pod Templates
|
||||
## Pod templates
|
||||
|
||||
Pod templates are pod specifications which are included in other objects, such as
|
||||
[Replication Controllers](/docs/concepts/workloads/controllers/replicationcontroller/), [Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/), and
|
||||
[DaemonSets](/docs/concepts/workloads/controllers/daemonset/). Controllers use Pod Templates to make actual pods.
|
||||
The sample below is a simple manifest for a Pod which contains a container that prints
|
||||
a message.
|
||||
Controllers for {{< glossary_tooltip text="workload" term_id="workload" >}} resources create Pods
|
||||
from a pod template and manage those Pods on your behalf.
|
||||
|
||||
PodTemplates are specifications for creating Pods, and are included in workload resources such as
|
||||
[Deployments](/docs/concepts/workloads/controllers/deployment/),
|
||||
[Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/), and
|
||||
[DaemonSets](/docs/concepts/workloads/controllers/daemonset/).
|
||||
|
||||
Each controller for a workload resource uses the PodTemplate inside the workload object to make actual Pods. The PodTemplate is part of the desired state of whatever workload resource you used to run your app.
|
||||
|
||||
The sample below is a manifest for a simple Job with a `template` that starts one container. The container in that Pod prints a message then pauses.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
apiVersion: batch/v1
|
||||
kind: Job
|
||||
metadata:
|
||||
name: myapp-pod
|
||||
labels:
|
||||
app: myapp
|
||||
name: hello
|
||||
spec:
|
||||
template:
|
||||
# This is the pod template
|
||||
spec:
|
||||
containers:
|
||||
- name: myapp-container
|
||||
- name: hello
|
||||
image: busybox
|
||||
command: ['sh', '-c', 'echo Hello Kubernetes! && sleep 3600']
|
||||
command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']
|
||||
restartPolicy: OnFailure
|
||||
# The pod template ends here
|
||||
```
|
||||
|
||||
Rather than specifying the current desired state of all replicas, pod templates are like cookie cutters. Once a cookie has been cut, the cookie has no relationship to the cutter. There is no "quantum entanglement". Subsequent changes to the template or even switching to a new template has no direct effect on the pods already created. Similarly, pods created by a replication controller may subsequently be updated directly. This is in deliberate contrast to pods, which do specify the current desired state of all containers belonging to the pod. This approach radically simplifies system semantics and increases the flexibility of the primitive.
|
||||
Modifying the pod template or switching to a new pod template has no effect on the Pods that already exist. Pods do not receive template updates directly; instead, a new Pod is created to match the revised pod template.
|
||||
|
||||
For example, a Deployment controller ensures that the running Pods match the current pod template. If the template is updated, the controller has to remove the existing Pods and create new Pods based on the updated template. Each workload controller implements its own rules for handling changes to the Pod template.
|
||||
|
||||
On Nodes, the {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} does not directly observe or manage any of the details around pod templates and updates; those details are abstracted away. That abstraction and separation of concerts simplifies system semantics, and makes it feasible to extend the cluster's behavior without changing existing code.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
* Learn more about [Pods](/docs/concepts/workloads/pods/pod/)
|
||||
* [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
|
||||
* Learn more about Pod behavior:
|
||||
* [Pod Termination](/docs/concepts/workloads/pods/pod/#termination-of-pods)
|
||||
* [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/)
|
||||
|
||||
@@ -160,6 +160,7 @@ There are some implicit conventions worth noting here:
|
||||
- Only the Pods holding the same namespace as the incoming Pod can be matching candidates.
|
||||
|
||||
- Nodes without `topologySpreadConstraints[*].topologyKey` present will be bypassed. It implies that:
|
||||
|
||||
1. the Pods located on those nodes do not impact `maxSkew` calculation - in the above example, suppose "node1" does not have label "zone", then the 2 Pods will be disregarded, hence the incomingPod will be scheduled into "zoneA".
|
||||
2. the incoming Pod has no chances to be scheduled onto this kind of nodes - in the above example, suppose a "node5" carrying label `{zone-typo: zoneC}` joins the cluster, it will be bypassed due to the absence of label key "zone".
|
||||
|
||||
@@ -236,7 +237,7 @@ single topology domain.
|
||||
The "EvenPodsSpread" feature provides flexible options to distribute Pods evenly across different
|
||||
topology domains - to achieve high availability or cost-saving. This can also help on rolling update
|
||||
workloads and scaling out replicas smoothly.
|
||||
See [Motivation](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20190221-even-pods-spreading.md#motivation) for more details.
|
||||
See [Motivation](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20190221-pod-topology-spread.md#motivation) for more details.
|
||||
|
||||
## Known Limitations
|
||||
|
||||
|
||||
@@ -35,7 +35,7 @@ To get involved with documentation:
|
||||
|
||||
1. Sign the CNCF [Contributor License Agreement](https://github.com/kubernetes/community/blob/master/CLA.md).
|
||||
2. Familiarize yourself with the [documentation repository](https://github.com/kubernetes/website) and the website's [static site generator](https://gohugo.io).
|
||||
3. Make sure you understand the basic processes for [opening a pull request](/docs/contribute/new-content/open-a-pr/) and [reviewing changes](/docs/contribute/review/reviewing-prs/).
|
||||
3. Make sure you understand the basic processes for [opening a pull request](/docs/contribute/new-content/new-content/) and [reviewing changes](/docs/contribute/review/reviewing-prs/).
|
||||
|
||||
Some tasks require more trust and more access in the Kubernetes organization.
|
||||
See [Participating in SIG Docs](/docs/contribute/participating/) for more details about
|
||||
@@ -44,6 +44,7 @@ roles and permissions.
|
||||
## Your first contribution
|
||||
|
||||
- Read the [Contribution overview](/docs/contribute/new-content/overview/) to learn about the different ways you can contribute.
|
||||
- See [Contribute to kubernetes/website](https://github.com/kubernetes/website/contribute) to find issues that make good entry points.
|
||||
- [Open a pull request using GitHub](/docs/contribute/new-content/new-content/#changes-using-github) to existing documentation and learn more about filing issues in GitHub.
|
||||
- [Review pull requests](/docs/contribute/review/reviewing-prs/) from other Kubernetes community members for accuracy and language.
|
||||
- Read the Kubernetes [content](/docs/contribute/style/content-guide/) and [style guides](/docs/contribute/style/style-guide/) so you can leave informed comments.
|
||||
|
||||
@@ -277,7 +277,7 @@ SIG Docs welcomes upstream contributions and corrections to the English source.
|
||||
|
||||
## Help an existing localization
|
||||
|
||||
You can also help add or improve content to an existing localization. Join the [Slack channel](https://kubernetes.slack.com/messages/C1J0BPD2M/) for the localization, and start opening PRs to help.
|
||||
You can also help add or improve content to an existing localization. Join the [Slack channel](https://kubernetes.slack.com/messages/C1J0BPD2M/) for the localization, and start opening PRs to help. Please limit pull requests to a single localization since pull requests that change content in multiple localizations could be difficult to review.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -50,8 +50,7 @@ real-world problems. The Kubernetes marketing team and members of the {{< glossa
|
||||
Have a look at the source for the
|
||||
[existing case studies](https://github.com/kubernetes/website/tree/master/content/en/case-studies).
|
||||
|
||||
Use the [Kubernetes case study submission form](https://www.cncf.io/people/end-user-community/)
|
||||
to submit your proposal.
|
||||
Refer to the [case study guidelines](https://github.com/cncf/foundation/blob/master/case-study-guidelines.md) and submit your request as outlined in the guidelines.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -14,7 +14,7 @@ card:
|
||||
Each major Kubernetes release introduces new features that require documentation. New releases also bring updates to existing features and documentation (such as upgrading a feature from alpha to beta).
|
||||
|
||||
Generally, the SIG responsible for a feature submits draft documentation of the
|
||||
feature as a pull request to the appropriate release branch of the
|
||||
feature as a pull request to the appropriate development branch of the
|
||||
`kubernetes/website` repository, and someone on the SIG Docs team provides
|
||||
editorial feedback or edits the draft directly. This section covers the branching
|
||||
conventions and process used during a release by both groups.
|
||||
@@ -96,9 +96,9 @@ deadlines.
|
||||
### Open a placeholder PR
|
||||
|
||||
1. Open a pull request against the
|
||||
`release-X.Y` branch in the `kubernetes/website` repository, with a small
|
||||
`dev-{{< skew nextMinorVersion >}}` branch in the `kubernetes/website` repository, with a small
|
||||
commit that you will amend later.
|
||||
2. Use the Prow command `/milestone X.Y` to
|
||||
2. Use the Prow command `/milestone {{< skew nextMinorVersion >}}` to
|
||||
assign the PR to the relevant milestone. This alerts the docs person managing
|
||||
this release that the feature docs are coming.
|
||||
|
||||
@@ -121,7 +121,7 @@ content is not received, the feature may be removed from the milestone.
|
||||
|
||||
### All PRs reviewed and ready to merge
|
||||
|
||||
If your PR has not yet been merged into the `release-X.Y` branch by the release deadline, work with the
|
||||
If your PR has not yet been merged into the `dev-{{< skew nextMinorVersion >}}` branch by the release deadline, work with the
|
||||
docs person managing the release to get it in by the deadline. If your feature needs
|
||||
documentation and the docs are not ready, the feature may be removed from the
|
||||
milestone.
|
||||
|
||||
@@ -16,7 +16,7 @@ upcoming Kubernetes release, see
|
||||
[Document a new feature](/docs/contribute/new-content/new-features/).
|
||||
{{< /note >}}
|
||||
|
||||
To contribute new content pages or improve existing content pages, open a pull request (PR). Make sure you follow all the requirements in the [Before you begin](#before-you-begin) section.
|
||||
To contribute new content pages or improve existing content pages, open a pull request (PR). Make sure you follow all the requirements in the [Before you begin](/docs/contribute/new-content/overview/#before-you-begin) section.
|
||||
|
||||
If your change is small, or you're unfamiliar with git, read [Changes using GitHub](#changes-using-github) to learn how to edit a page.
|
||||
|
||||
|
||||
@@ -30,22 +30,7 @@ This section contains information you should know before contributing new conten
|
||||
|
||||
All Kubernetes contributors **must** read the [Contributor guide](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md) and [sign the Contributor License Agreement (CLA)](https://github.com/kubernetes/community/blob/master/CLA.md).
|
||||
|
||||
Pull requests from contributors who haven't signed the CLA fail the automated tests.
|
||||
|
||||
### Configure commit signoffs
|
||||
|
||||
All commits to Kubernetes repositories must be _signed off_ using the Git `--signoff` or `-s` flag.
|
||||
The signoff acknowledges that you have the rights to submit contributions under the same
|
||||
license and [Developer Certificate of Origin](https://developercertificate.org/).
|
||||
|
||||
If you're using a Git UI app, you can use the app's commit template functionality if it
|
||||
exists, or add the following to your commit message body:
|
||||
|
||||
```
|
||||
Signed-off-by: Your Name <youremail@domain.com>
|
||||
```
|
||||
|
||||
In both cases, the name and email you provide must match those found in your `git config`, and your git name and email must match those used for the CNCF CLA.
|
||||
Pull requests from contributors who haven't signed the CLA fail the automated tests. The name and email you provide must match those found in your `git config`, and your git name and email must match those used for the CNCF CLA.
|
||||
|
||||
### Choose which Git branch to use
|
||||
|
||||
|
||||
@@ -292,10 +292,10 @@ status:
|
||||
type: Denied
|
||||
```
|
||||
|
||||
It's usual to set `status.condtions.reason` to a machine-friendly reason
|
||||
It's usual to set `status.conditions.reason` to a machine-friendly reason
|
||||
code using TitleCase; this is a convention but you can set it to anything
|
||||
you like. If you want to add a note just for human consumption, use the
|
||||
`status.condtions.message` field.
|
||||
`status.conditions.message` field.
|
||||
|
||||
## Signing
|
||||
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: cloud-controller-manager
|
||||
content_template: templates/tool-reference
|
||||
weight: 28
|
||||
weight: 30
|
||||
---
|
||||
|
||||
{{% capture synopsis %}}
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: kube-apiserver
|
||||
content_template: templates/tool-reference
|
||||
weight: 28
|
||||
weight: 30
|
||||
---
|
||||
|
||||
{{% capture synopsis %}}
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: kube-controller-manager
|
||||
content_template: templates/tool-reference
|
||||
weight: 28
|
||||
weight: 30
|
||||
---
|
||||
|
||||
{{% capture synopsis %}}
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: kube-proxy
|
||||
content_template: templates/tool-reference
|
||||
weight: 28
|
||||
weight: 30
|
||||
---
|
||||
|
||||
{{% capture synopsis %}}
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: kube-scheduler
|
||||
content_template: templates/tool-reference
|
||||
weight: 28
|
||||
weight: 30
|
||||
---
|
||||
|
||||
{{% capture synopsis %}}
|
||||
@@ -13,7 +13,7 @@ and capacity. The scheduler needs to take into account individual and collective
|
||||
resource requirements, quality of service requirements, hardware/software/policy
|
||||
constraints, affinity and anti-affinity specifications, data locality, inter-workload
|
||||
interference, deadlines, and so on. Workload-specific requirements will be exposed
|
||||
through the API as necessary. See [scheduling](https://kubernetes.io/docs/concepts/scheduling/)
|
||||
through the API as necessary. See [scheduling](https://kubernetes.io/docs/concepts/scheduling-eviction/)
|
||||
for more information about scheduling and the kube-scheduler component.
|
||||
|
||||
```
|
||||
|
||||
@@ -12,7 +12,7 @@ node. It can register the node with the apiserver using one of: the hostname; a
|
||||
The kubelet works in terms of a PodSpec. A PodSpec is a YAML or JSON object
|
||||
that describes a pod. The kubelet takes a set of PodSpecs that are provided through various mechanisms (primarily through the apiserver) and ensures that the containers described in those PodSpecs are running and healthy. The kubelet doesn't manage containers which were not created by Kubernetes.
|
||||
|
||||
Other than from an PodSpec from the apiserver, there are three ways that a container manifest can be provided to the Kubelet.
|
||||
Other than from a PodSpec from the apiserver, there are three ways that a container manifest can be provided to the Kubelet.
|
||||
|
||||
File: Path passed as a flag on the command line. Files under this path will be monitored periodically for updates. The monitoring period is 20s by default and is configurable via a flag.
|
||||
|
||||
|
||||
@@ -11,3 +11,15 @@ tags:
|
||||
- fundamental
|
||||
---
|
||||
The container orchestration layer that exposes the API and interfaces to define, deploy, and manage the lifecycle of containers.
|
||||
|
||||
<!--more-->
|
||||
|
||||
This layer is composed by many different components, such as (but not restricted to):
|
||||
|
||||
* {{< glossary_tooltip text="etcd" term_id="etcd" >}}
|
||||
* {{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}
|
||||
* {{< glossary_tooltip text="Scheduler" term_id="kube-scheduler" >}}
|
||||
* {{< glossary_tooltip text="Controller Manager" term_id="kube-controller-manager" >}}
|
||||
* {{< glossary_tooltip text="Cloud Controller Manager" term_id="cloud-controller-manager" >}}
|
||||
|
||||
These components can be run as traditional operating system services (daemons) or as containers. The hosts running these components were historically called {{< glossary_tooltip text="masters" term_id="master" >}}.
|
||||
@@ -4,7 +4,7 @@ id: cronjob
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/workloads/controllers/cron-jobs/
|
||||
short_description: >
|
||||
Manages a [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) that runs on a periodic schedule.
|
||||
A repeating task (a Job) that runs on a regular schedule.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
|
||||
@@ -4,7 +4,7 @@ id: deployment
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/workloads/controllers/deployment/
|
||||
short_description: >
|
||||
An API object that manages a replicated application.
|
||||
Manages a replicated application on your cluster.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
@@ -12,9 +12,10 @@ tags:
|
||||
- core-object
|
||||
- workload
|
||||
---
|
||||
An API object that manages a replicated application.
|
||||
An API object that manages a replicated application, typically by running Pods with no local state.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Each replica is represented by a {{< glossary_tooltip term_id="pod" >}}, and the Pods are distributed among the {{< glossary_tooltip text="nodes" term_id="node" >}} of a cluster.
|
||||
|
||||
Each replica is represented by a {{< glossary_tooltip term_id="pod" >}}, and the Pods are distributed among the
|
||||
{{< glossary_tooltip text="nodes" term_id="node" >}} of a cluster.
|
||||
For workloads that do require local state, consider using a {{< glossary_tooltip term_id="StatefulSet" >}}.
|
||||
|
||||
@@ -0,0 +1,15 @@
|
||||
---
|
||||
title: Master
|
||||
id: master
|
||||
date: 2020-04-16
|
||||
short_description: >
|
||||
Legacy term, used as synonym for nodes running the control plane.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
---
|
||||
Legacy term, used as synonym for {{< glossary_tooltip text="nodes" term_id="node" >}} hosting the {{< glossary_tooltip text="control plane" term_id="control-plane" >}}.
|
||||
|
||||
<!--more-->
|
||||
The term is still being used by some provisioning tools, such as {{< glossary_tooltip text="kubeadm" term_id="kubeadm" >}}, and managed services, to {{< glossary_tooltip text="label" term_id="label" >}} {{< glossary_tooltip text="nodes" term_id="node" >}} with `kubernetes.io/role` and control placement of {{< glossary_tooltip text="control plane" term_id="control-plane" >}} {{< glossary_tooltip text="pods" term_id="pod" >}}.
|
||||
@@ -4,7 +4,7 @@ id: pod
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/workloads/pods/pod-overview/
|
||||
short_description: >
|
||||
The smallest and simplest Kubernetes object. A Pod represents a set of running containers on your cluster.
|
||||
A Pod represents a set of running containers in your cluster.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
|
||||
@@ -16,4 +16,3 @@ tags:
|
||||
<!--more-->
|
||||
|
||||
When processes inside Pods access the cluster, they are authenticated by the API server as a particular service account, for example, `default`. When you create a Pod, if you do not specify a service account, it is automatically assigned the default service account in the same {{< glossary_tooltip text="Namespace" term_id="namespace" >}}.
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ id: statefulset
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/workloads/controllers/statefulset/
|
||||
short_description: >
|
||||
Manages the deployment and scaling of a set of Pods, *and provides guarantees about the ordering and uniqueness* of these Pods.
|
||||
Manages deployment and scaling of a set of Pods, with durable storage and persistent identifiers for each Pod.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
@@ -18,3 +18,5 @@ tags:
|
||||
<!--more-->
|
||||
|
||||
Like a {{< glossary_tooltip term_id="deployment" >}}, a StatefulSet manages Pods that are based on an identical container spec. Unlike a Deployment, a StatefulSet maintains a sticky identity for each of their Pods. These pods are created from the same spec, but are not interchangeable: each has a persistent identifier that it maintains across any rescheduling.
|
||||
|
||||
If you want to use storage volumes to provide persistence for your workload, you can use a StatefulSet as part of the solution. Although individual Pods in a StatefulSet are susceptible to failure, the persistent Pod identifiers make it easier to match existing volumes to the new Pods that replace any that have failed.
|
||||
|
||||
@@ -351,6 +351,21 @@ Output format | Description
|
||||
`-o=wide` | Output in the plain-text format with any additional information, and for pods, the node name is included
|
||||
`-o=yaml` | Output a YAML formatted API object
|
||||
|
||||
Examples using `-o=custom-columns`:
|
||||
|
||||
```bash
|
||||
# All images running in a cluster
|
||||
kubectl get pods -A -o=custom-columns='DATA:spec.containers[*].image'
|
||||
|
||||
# All images excluding "k8s.gcr.io/coredns:1.6.2"
|
||||
kubectl get pods -A -o=custom-columns='DATA:spec.containers[?(@.image!="k8s.gcr.io/coredns:1.6.2")].image'
|
||||
|
||||
# All fields under metadata regardless of name
|
||||
kubectl get pods -A -o=custom-columns='DATA:metadata.*'
|
||||
```
|
||||
|
||||
More examples in the kubectl [reference documentation](/docs/reference/kubectl/overview/#custom-columns).
|
||||
|
||||
### Kubectl output verbosity and debugging
|
||||
|
||||
Kubectl verbosity is controlled with the `-v` or `--v` flags followed by an integer representing the log level. General Kubernetes logging conventions and the associated log levels are described [here](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md).
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: kubectl
|
||||
content_template: templates/tool-reference
|
||||
weight: 28
|
||||
weight: 30
|
||||
---
|
||||
|
||||
{{% capture synopsis %}}
|
||||
|
||||
@@ -8,7 +8,7 @@ weight: 10
|
||||
|
||||
A scheduling Policy can be used to specify the *predicates* and *priorities*
|
||||
that the {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}
|
||||
runs to [filter and score nodes](/docs/concepts/scheduling/kube-scheduler/#kube-scheduler-implementation),
|
||||
runs to [filter and score nodes](/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler-implementation),
|
||||
respectively.
|
||||
|
||||
You can set a scheduling policy by running
|
||||
@@ -120,6 +120,6 @@ The following *priorities* implement scoring:
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
* Learn about [scheduling](/docs/concepts/scheduling/kube-scheduler/)
|
||||
* Learn about [scheduling](/docs/concepts/scheduling-eviction/kube-scheduler/)
|
||||
* Learn about [kube-scheduler profiles](/docs/reference/scheduling/profiles/)
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -177,5 +177,5 @@ only has one pending pods queue.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
* Learn about [scheduling](/docs/concepts/scheduling/kube-scheduler/)
|
||||
* Learn about [scheduling](/docs/concepts/scheduling-eviction/kube-scheduler/)
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -52,28 +52,28 @@ their authors, not the Kubernetes team.
|
||||
| Lisp | [github.com/brendandburns/cl-k8s](https://github.com/brendandburns/cl-k8s) |
|
||||
| Lisp | [github.com/xh4/cube](https://github.com/xh4/cube) |
|
||||
| Node.js (TypeScript) | [github.com/Goyoo/node-k8s-client](https://github.com/Goyoo/node-k8s-client) |
|
||||
| Node.js | [github.com/tenxcloud/node-kubernetes-client](https://github.com/tenxcloud/node-kubernetes-client) |
|
||||
| Node.js | [github.com/godaddy/kubernetes-client](https://github.com/godaddy/kubernetes-client) |
|
||||
| Node.js | [github.com/ajpauwels/easy-k8s](https://github.com/ajpauwels/easy-k8s)
|
||||
| Node.js | [github.com/godaddy/kubernetes-client](https://github.com/godaddy/kubernetes-client) |
|
||||
| Node.js | [github.com/tenxcloud/node-kubernetes-client](https://github.com/tenxcloud/node-kubernetes-client) |
|
||||
| Perl | [metacpan.org/pod/Net::Kubernetes](https://metacpan.org/pod/Net::Kubernetes) |
|
||||
| PHP | [github.com/maclof/kubernetes-client](https://github.com/maclof/kubernetes-client) |
|
||||
| PHP | [github.com/allansun/kubernetes-php-client](https://github.com/allansun/kubernetes-php-client) |
|
||||
| PHP | [github.com/maclof/kubernetes-client](https://github.com/maclof/kubernetes-client) |
|
||||
| PHP | [github.com/travisghansen/kubernetes-client-php](https://github.com/travisghansen/kubernetes-client-php) |
|
||||
| Python | [github.com/eldarion-gondor/pykube](https://github.com/eldarion-gondor/pykube) |
|
||||
| Python | [github.com/fiaas/k8s](https://github.com/fiaas/k8s) |
|
||||
| Python | [github.com/mnubo/kubernetes-py](https://github.com/mnubo/kubernetes-py) |
|
||||
| Python | [github.com/tomplus/kubernetes_asyncio](https://github.com/tomplus/kubernetes_asyncio) |
|
||||
| Ruby | [github.com/Ch00k/kuber](https://github.com/Ch00k/kuber) |
|
||||
| Ruby | [github.com/abonas/kubeclient](https://github.com/abonas/kubeclient) |
|
||||
| Ruby | [github.com/Ch00k/kuber](https://github.com/Ch00k/kuber) |
|
||||
| Ruby | [github.com/kontena/k8s-client](https://github.com/kontena/k8s-client) |
|
||||
| Rust | [github.com/clux/kube-rs](https://github.com/clux/kube-rs) |
|
||||
| Rust | [github.com/ynqa/kubernetes-rust](https://github.com/ynqa/kubernetes-rust) |
|
||||
| Scala | [github.com/doriordan/skuber](https://github.com/doriordan/skuber) |
|
||||
| dotNet | [github.com/tonnyeremin/kubernetes_gen](https://github.com/tonnyeremin/kubernetes_gen) |
|
||||
| Scala | [github.com/joan38/kubernetes-client](https://github.com/joan38/kubernetes-client) |
|
||||
| DotNet | [github.com/tonnyeremin/kubernetes_gen](https://github.com/tonnyeremin/kubernetes_gen) |
|
||||
| DotNet (RestSharp) | [github.com/masroorhasan/Kubernetes.DotNet](https://github.com/masroorhasan/Kubernetes.DotNet) |
|
||||
| Elixir | [github.com/obmarg/kazan](https://github.com/obmarg/kazan/) |
|
||||
| Elixir | [github.com/coryodaniel/k8s](https://github.com/coryodaniel/k8s) |
|
||||
| Haskell | [github.com/kubernetes-client/haskell](https://github.com/kubernetes-client/haskell) |
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
@@ -462,11 +462,11 @@ For more information about Minikube, see the [proposal](https://git.k8s.io/commu
|
||||
|
||||
## Additional Links
|
||||
|
||||
* **Goals and Non-Goals**: For the goals and non-goals of the Minikube project, please see our [roadmap](https://git.k8s.io/minikube/docs/contributors/roadmap.md).
|
||||
* **Development Guide**: See [CONTRIBUTING.md](https://git.k8s.io/minikube/CONTRIBUTING.md) for an overview of how to send pull requests.
|
||||
* **Building Minikube**: For instructions on how to build/test Minikube from source, see the [build guide](https://git.k8s.io/minikube/docs/contributors/build_guide.md).
|
||||
* **Adding a New Dependency**: For instructions on how to add a new dependency to Minikube, see the [adding dependencies guide](https://git.k8s.io/minikube/docs/contributors/adding_a_dependency.md).
|
||||
* **Adding a New Addon**: For instructions on how to add a new addon for Minikube, see the [adding an addon guide](https://git.k8s.io/minikube/docs/contributors/adding_an_addon.md).
|
||||
* **Goals and Non-Goals**: For the goals and non-goals of the Minikube project, please see our [roadmap](https://minikube.sigs.k8s.io/docs/contrib/roadmap/).
|
||||
* **Development Guide**: See [Contributing](https://minikube.sigs.k8s.io/docs/contrib/) for an overview of how to send pull requests.
|
||||
* **Building Minikube**: For instructions on how to build/test Minikube from source, see the [build guide](https://minikube.sigs.k8s.io/docs/contrib/building/).
|
||||
* **Adding a New Dependency**: For instructions on how to add a new dependency to Minikube, see the [adding dependencies guide](https://minikube.sigs.k8s.io/docs/contrib/drivers/).
|
||||
* **Adding a New Addon**: For instructions on how to add a new addon for Minikube, see the [adding an addon guide](https://minikube.sigs.k8s.io/docs/contrib/addons/).
|
||||
* **MicroK8s**: Linux users wishing to avoid running a virtual machine may consider [MicroK8s](https://microk8s.io/) as an alternative.
|
||||
|
||||
## Community
|
||||
|
||||
@@ -41,7 +41,7 @@ When systemd is chosen as the init system for a Linux distribution, the init pro
|
||||
and consumes a root control group (`cgroup`) and acts as a cgroup manager. Systemd has a tight
|
||||
integration with cgroups and will allocate cgroups per process. It's possible to configure your
|
||||
container runtime and the kubelet to use `cgroupfs`. Using `cgroupfs` alongside systemd means
|
||||
that there will then be two different cgroup managers.
|
||||
that there will be two different cgroup managers.
|
||||
|
||||
Control groups are used to constrain resources that are allocated to processes.
|
||||
A single cgroup manager will simplify the view of what resources are being allocated
|
||||
|
||||
+4
-7
@@ -368,7 +368,7 @@ For information on using the `kubeadm` tool to set up a Kubernetes cluster with
|
||||
|
||||
{{% tab name="Weave Net" %}}
|
||||
|
||||
For more information on setting up your Kubernetes cluster with Weave Net, please see [Integrating Kubernetes via the Addon]((https://www.weave.works/docs/net/latest/kube-addon/).
|
||||
For more information on setting up your Kubernetes cluster with Weave Net, please see [Integrating Kubernetes via the Addon](https://www.weave.works/docs/net/latest/kube-addon/).
|
||||
|
||||
Weave Net works on `amd64`, `arm`, `arm64` and `ppc64le` platforms without any extra action required.
|
||||
Weave Net sets hairpin mode by default. This allows Pods to access themselves via their Service IP address
|
||||
@@ -609,13 +609,10 @@ of Pod network add-ons.
|
||||
|
||||
## Version skew policy {#version-skew-policy}
|
||||
|
||||
The `kubeadm` tool of version vX.Y may deploy clusters with a control plane of version vX.Y or vX.(Y-1).
|
||||
`kubeadm` vX.Y can also upgrade an existing kubeadm-created cluster of version vX.(Y-1).
|
||||
The `kubeadm` tool of version v{{< skew latestVersion >}} may deploy clusters with a control plane of version v{{< skew latestVersion >}} or v{{< skew prevMinorVersion >}}.
|
||||
`kubeadm` v{{< skew latestVersion >}} can also upgrade an existing kubeadm-created cluster of version v{{< skew prevMinorVersion >}}.
|
||||
|
||||
Due to that we can't see into the future, kubeadm CLI vX.Y may or may not be able to deploy vX.(Y+1) clusters.
|
||||
|
||||
Example: `kubeadm` v1.8 can deploy both v1.7 and v1.8 clusters and upgrade v1.7 kubeadm-created clusters to
|
||||
v1.8.
|
||||
Due to that we can't see into the future, kubeadm CLI v{{< skew latestVersion >}} may or may not be able to deploy v{{< skew nextMinorVersion >}} clusters.
|
||||
|
||||
These resources provide more information on supported version skew between kubelets and the control plane, and other Kubernetes components:
|
||||
|
||||
|
||||
@@ -194,7 +194,7 @@ sudo apt-mark hold kubelet kubeadm kubectl
|
||||
cat <<EOF > /etc/yum.repos.d/kubernetes.repo
|
||||
[kubernetes]
|
||||
name=Kubernetes
|
||||
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-$basearch
|
||||
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-\$basearch
|
||||
enabled=1
|
||||
gpgcheck=1
|
||||
repo_gpgcheck=1
|
||||
|
||||
@@ -6,22 +6,22 @@ weight: 30
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
This quickstart helps to install a Kubernetes cluster hosted on GCE, Azure, OpenStack, AWS, vSphere, Oracle Cloud Infrastructure (Experimental) or Baremetal with [Kubespray](https://github.com/kubernetes-incubator/kubespray).
|
||||
This quickstart helps to install a Kubernetes cluster hosted on GCE, Azure, OpenStack, AWS, vSphere, Packet (bare metal), Oracle Cloud Infrastructure (Experimental) or Baremetal with [Kubespray](https://github.com/kubernetes-sigs/kubespray).
|
||||
|
||||
Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks, [inventory](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/ansible.md), provisioning tools, and domain knowledge for generic OS/Kubernetes clusters configuration management tasks. Kubespray provides:
|
||||
Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks, [inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md), provisioning tools, and domain knowledge for generic OS/Kubernetes clusters configuration management tasks. Kubespray provides:
|
||||
|
||||
* a highly available cluster
|
||||
* composable attributes
|
||||
* support for most popular Linux distributions
|
||||
* Container Linux by CoreOS
|
||||
* Debian Jessie, Stretch, Wheezy
|
||||
* Debian Buster, Jessie, Stretch, Wheezy
|
||||
* Ubuntu 16.04, 18.04
|
||||
* CentOS/RHEL 7
|
||||
* Fedora/CentOS Atomic
|
||||
* openSUSE Leap 42.3/Tumbleweed
|
||||
* CentOS/RHEL/Oracle Linux 7
|
||||
* Fedora 28
|
||||
* openSUSE Leap 15
|
||||
* continuous integration tests
|
||||
|
||||
To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/comparisons.md) to [kubeadm](/docs/admin/kubeadm/) and [kops](../kops).
|
||||
To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md) to [kubeadm](/docs/admin/kubeadm/) and [kops](../kops).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -31,11 +31,11 @@ To choose a tool which best fits your use case, read [this comparison](https://g
|
||||
|
||||
### (1/5) Meet the underlay requirements
|
||||
|
||||
Provision servers with the following [requirements](https://github.com/kubernetes-incubator/kubespray#requirements):
|
||||
Provision servers with the following [requirements](https://github.com/kubernetes-sigs/kubespray#requirements):
|
||||
|
||||
* **Ansible v2.5 (or newer) and python-netaddr is installed on the machine that will run Ansible commands**
|
||||
* **Ansible v2.7.8 and python-netaddr is installed on the machine that will run Ansible commands**
|
||||
* **Jinja 2.9 (or newer) is required to run the Ansible Playbooks**
|
||||
* The target servers must have **access to the Internet** in order to pull docker images
|
||||
* The target servers must have access to the Internet in order to pull docker images. Otherwise, additional configuration is required ([See Offline Environment](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/downloads.md#offline-environment))
|
||||
* The target servers are configured to allow **IPv4 forwarding**
|
||||
* **Your ssh key must be copied** to all the servers part of your inventory
|
||||
* The **firewalls are not managed**, you'll need to implement your own rules the way you used to. in order to avoid any issue during deployment you should disable your firewall
|
||||
@@ -44,12 +44,13 @@ Provision servers with the following [requirements](https://github.com/kubernete
|
||||
Kubespray provides the following utilities to help provision your environment:
|
||||
|
||||
* [Terraform](https://www.terraform.io/) scripts for the following cloud providers:
|
||||
* [AWS](https://github.com/kubernetes-incubator/kubespray/tree/master/contrib/terraform/aws)
|
||||
* [OpenStack](https://github.com/kubernetes-incubator/kubespray/tree/master/contrib/terraform/openstack)
|
||||
* [AWS](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/aws)
|
||||
* [OpenStack](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/openstack)
|
||||
* [Packet](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/packet)
|
||||
|
||||
### (2/5) Compose an inventory file
|
||||
|
||||
After you provision your servers, create an [inventory file for Ansible](http://docs.ansible.com/ansible/intro_inventory.html). You can do this manually or via a dynamic inventory script. For more information, see "[Building your own inventory](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)".
|
||||
After you provision your servers, create an [inventory file for Ansible](http://docs.ansible.com/ansible/intro_inventory.html). You can do this manually or via a dynamic inventory script. For more information, see "[Building your own inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)".
|
||||
|
||||
### (3/5) Plan your cluster deployment
|
||||
|
||||
@@ -58,14 +59,14 @@ Kubespray provides the ability to customize many aspects of the deployment:
|
||||
* Choice deployment mode: kubeadm or non-kubeadm
|
||||
* CNI (networking) plugins
|
||||
* DNS configuration
|
||||
* Choice of control plane: native/binary or containerized with docker or rkt
|
||||
* Choice of control plane: native/binary or containerized
|
||||
* Component versions
|
||||
* Calico route reflectors
|
||||
* Component runtime options
|
||||
* {{< glossary_tooltip term_id="docker" >}}
|
||||
* {{< glossary_tooltip term_id="rkt" >}}
|
||||
* {{< glossary_tooltip term_id="containerd" >}}
|
||||
* {{< glossary_tooltip term_id="cri-o" >}}
|
||||
* Certificate generation methods (**Vault being discontinued**)
|
||||
* Certificate generation methods
|
||||
|
||||
Kubespray customizations can be made to a [variable file](http://docs.ansible.com/ansible/playbooks_variables.html). If you are just getting started with Kubespray, consider using the Kubespray defaults to deploy your cluster and explore Kubernetes.
|
||||
|
||||
@@ -73,18 +74,18 @@ Kubespray customizations can be made to a [variable file](http://docs.ansible.co
|
||||
|
||||
Next, deploy your cluster:
|
||||
|
||||
Cluster deployment using [ansible-playbook](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#starting-custom-deployment).
|
||||
Cluster deployment using [ansible-playbook](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#starting-custom-deployment).
|
||||
|
||||
```shell
|
||||
ansible-playbook -i your/inventory/inventory.ini cluster.yml -b -v \
|
||||
--private-key=~/.ssh/private_key
|
||||
```
|
||||
|
||||
Large deployments (100+ nodes) may require [specific adjustments](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/large-deployments.md) for best results.
|
||||
Large deployments (100+ nodes) may require [specific adjustments](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/large-deployments.md) for best results.
|
||||
|
||||
### (5/5) Verify the deployment
|
||||
|
||||
Kubespray provides a way to verify inter-pod connectivity and DNS resolve with [Netchecker](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/netcheck.md). Netchecker ensures the netchecker-agents pods can resolve DNS requests and ping each over within the default namespace. Those pods mimic similar behavior of the rest of the workloads and serve as cluster health indicators.
|
||||
Kubespray provides a way to verify inter-pod connectivity and DNS resolve with [Netchecker](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/netcheck.md). Netchecker ensures the netchecker-agents pods can resolve DNS requests and ping each over within the default namespace. Those pods mimic similar behavior of the rest of the workloads and serve as cluster health indicators.
|
||||
|
||||
## Cluster operations
|
||||
|
||||
@@ -92,16 +93,16 @@ Kubespray provides additional playbooks to manage your cluster: _scale_ and _upg
|
||||
|
||||
### Scale your cluster
|
||||
|
||||
You can add worker nodes from your cluster by running the scale playbook. For more information, see "[Adding nodes](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#adding-nodes)".
|
||||
You can remove worker nodes from your cluster by running the remove-node playbook. For more information, see "[Remove nodes](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#remove-nodes)".
|
||||
You can add worker nodes from your cluster by running the scale playbook. For more information, see "[Adding nodes](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#adding-nodes)".
|
||||
You can remove worker nodes from your cluster by running the remove-node playbook. For more information, see "[Remove nodes](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#remove-nodes)".
|
||||
|
||||
### Upgrade your cluster
|
||||
|
||||
You can upgrade your cluster by running the upgrade-cluster playbook. For more information, see "[Upgrades](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/upgrades.md)".
|
||||
You can upgrade your cluster by running the upgrade-cluster playbook. For more information, see "[Upgrades](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/upgrades.md)".
|
||||
|
||||
## Cleanup
|
||||
|
||||
You can reset your nodes and wipe out all components installed with Kubespray via the [reset playbook](https://github.com/kubernetes-incubator/kubespray/blob/master/reset.yml).
|
||||
You can reset your nodes and wipe out all components installed with Kubespray via the [reset playbook](https://github.com/kubernetes-sigs/kubespray/blob/master/reset.yml).
|
||||
|
||||
{{< caution >}}
|
||||
When running the reset playbook, be sure not to accidentally target your production cluster!
|
||||
@@ -109,13 +110,13 @@ When running the reset playbook, be sure not to accidentally target your product
|
||||
|
||||
## Feedback
|
||||
|
||||
* Slack Channel: [#kubespray](https://kubernetes.slack.com/messages/kubespray/)
|
||||
* [GitHub Issues](https://github.com/kubernetes-incubator/kubespray/issues)
|
||||
* Slack Channel: [#kubespray](https://kubernetes.slack.com/messages/kubespray/) (You can get your invite [here](http://slack.k8s.io/))
|
||||
* [GitHub Issues](https://github.com/kubernetes-sigs/kubespray/issues)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
Check out planned work on Kubespray's [roadmap](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/roadmap.md).
|
||||
Check out planned work on Kubespray's [roadmap](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/roadmap.md).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -24,7 +24,7 @@ Kubernetes versions are expressed as **x.y.z**,
|
||||
where **x** is the major version, **y** is the minor version, and **z** is the patch version, following [Semantic Versioning](http://semver.org/) terminology.
|
||||
For more information, see [Kubernetes Release Versioning](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md#kubernetes-release-versioning).
|
||||
|
||||
The Kubernetes project maintains release branches for the most recent three minor releases.
|
||||
The Kubernetes project maintains release branches for the most recent three minor releases ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}).
|
||||
|
||||
Applicable fixes, including security fixes, may be backported to those three release branches, depending on severity and feasibility.
|
||||
Patch releases are cut from those branches at a regular cadence, or as needed.
|
||||
@@ -41,8 +41,8 @@ In [highly-available (HA) clusters](/docs/setup/production-environment/tools/kub
|
||||
|
||||
Example:
|
||||
|
||||
* newest `kube-apiserver` is at **1.13**
|
||||
* other `kube-apiserver` instances are supported at **1.13** and **1.12**
|
||||
* newest `kube-apiserver` is at **{{< skew latestVersion >}}**
|
||||
* other `kube-apiserver` instances are supported at **{{< skew latestVersion >}}** and **{{< skew prevMinorVersion >}}**
|
||||
|
||||
### kubelet
|
||||
|
||||
@@ -50,8 +50,8 @@ Example:
|
||||
|
||||
Example:
|
||||
|
||||
* `kube-apiserver` is at **1.13**
|
||||
* `kubelet` is supported at **1.13**, **1.12**, and **1.11**
|
||||
* `kube-apiserver` is at **{{< skew latestVersion >}}**
|
||||
* `kubelet` is supported at **{{< skew latestVersion >}}**, **{{< skew prevMinorVersion >}}**, and **{{< skew oldestMinorVersion >}}**
|
||||
|
||||
{{< note >}}
|
||||
If version skew exists between `kube-apiserver` instances in an HA cluster, this narrows the allowed `kubelet` versions.
|
||||
@@ -59,8 +59,8 @@ If version skew exists between `kube-apiserver` instances in an HA cluster, this
|
||||
|
||||
Example:
|
||||
|
||||
* `kube-apiserver` instances are at **1.13** and **1.12**
|
||||
* `kubelet` is supported at **1.12**, and **1.11** (**1.13** is not supported because that would be newer than the `kube-apiserver` instance at version **1.12**)
|
||||
* `kube-apiserver` instances are at **{{< skew latestVersion >}}** and **{{< skew prevMinorVersion >}}**
|
||||
* `kubelet` is supported at **{{< skew prevMinorVersion >}}**, and **{{< skew oldestMinorVersion >}}** (**{{< skew latestVersion >}}** is not supported because that would be newer than the `kube-apiserver` instance at version **{{< skew prevMinorVersion >}}**)
|
||||
|
||||
### kube-controller-manager, kube-scheduler, and cloud-controller-manager
|
||||
|
||||
@@ -68,8 +68,8 @@ Example:
|
||||
|
||||
Example:
|
||||
|
||||
* `kube-apiserver` is at **1.13**
|
||||
* `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` are supported at **1.13** and **1.12**
|
||||
* `kube-apiserver` is at **{{< skew latestVersion >}}**
|
||||
* `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` are supported at **{{< skew latestVersion >}}** and **{{< skew prevMinorVersion >}}**
|
||||
|
||||
{{< note >}}
|
||||
If version skew exists between `kube-apiserver` instances in an HA cluster, and these components can communicate with any `kube-apiserver` instance in the cluster (for example, via a load balancer), this narrows the allowed versions of these components.
|
||||
@@ -77,9 +77,9 @@ If version skew exists between `kube-apiserver` instances in an HA cluster, and
|
||||
|
||||
Example:
|
||||
|
||||
* `kube-apiserver` instances are at **1.13** and **1.12**
|
||||
* `kube-apiserver` instances are at **{{< skew latestVersion >}}** and **{{< skew prevMinorVersion >}}**
|
||||
* `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` communicate with a load balancer that can route to any `kube-apiserver` instance
|
||||
* `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` are supported at **1.12** (**1.13** is not supported because that would be newer than the `kube-apiserver` instance at version **1.12**)
|
||||
* `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` are supported at **{{< skew prevMinorVersion >}}** (**{{< skew latestVersion >}}** is not supported because that would be newer than the `kube-apiserver` instance at version **{{< skew prevMinorVersion >}}**)
|
||||
|
||||
### kubectl
|
||||
|
||||
@@ -87,8 +87,8 @@ Example:
|
||||
|
||||
Example:
|
||||
|
||||
* `kube-apiserver` is at **1.13**
|
||||
* `kubectl` is supported at **1.14**, **1.13**, and **1.12**
|
||||
* `kube-apiserver` is at **{{< skew latestVersion >}}**
|
||||
* `kubectl` is supported at **{{< skew nextMinorVersion >}}**, **{{< skew latestVersion >}}**, and **{{< skew prevMinorVersion >}}**
|
||||
|
||||
{{< note >}}
|
||||
If version skew exists between `kube-apiserver` instances in an HA cluster, this narrows the supported `kubectl` versions.
|
||||
@@ -96,27 +96,27 @@ If version skew exists between `kube-apiserver` instances in an HA cluster, this
|
||||
|
||||
Example:
|
||||
|
||||
* `kube-apiserver` instances are at **1.13** and **1.12**
|
||||
* `kubectl` is supported at **1.13** and **1.12** (other versions would be more than one minor version skewed from one of the `kube-apiserver` components)
|
||||
* `kube-apiserver` instances are at **{{< skew latestVersion >}}** and **{{< skew prevMinorVersion >}}**
|
||||
* `kubectl` is supported at **{{< skew latestVersion >}}** and **{{< skew prevMinorVersion >}}** (other versions would be more than one minor version skewed from one of the `kube-apiserver` components)
|
||||
|
||||
## Supported component upgrade order
|
||||
|
||||
The supported version skew between components has implications on the order in which components must be upgraded.
|
||||
This section describes the order in which components must be upgraded to transition an existing cluster from version **1.n** to version **1.(n+1)**.
|
||||
This section describes the order in which components must be upgraded to transition an existing cluster from version **{{< skew prevMinorVersion >}}** to version **{{< skew latestVersion >}}**.
|
||||
|
||||
### kube-apiserver
|
||||
|
||||
Pre-requisites:
|
||||
|
||||
* In a single-instance cluster, the existing `kube-apiserver` instance is **1.n**
|
||||
* In an HA cluster, all `kube-apiserver` instances are at **1.n** or **1.(n+1)** (this ensures maximum skew of 1 minor version between the oldest and newest `kube-apiserver` instance)
|
||||
* The `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` instances that communicate with this server are at version **1.n** (this ensures they are not newer than the existing API server version, and are within 1 minor version of the new API server version)
|
||||
* `kubelet` instances on all nodes are at version **1.n** or **1.(n-1)** (this ensures they are not newer than the existing API server version, and are within 2 minor versions of the new API server version)
|
||||
* In a single-instance cluster, the existing `kube-apiserver` instance is **{{< skew prevMinorVersion >}}**
|
||||
* In an HA cluster, all `kube-apiserver` instances are at **{{< skew prevMinorVersion >}}** or **{{< skew latestVersion >}}** (this ensures maximum skew of 1 minor version between the oldest and newest `kube-apiserver` instance)
|
||||
* The `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` instances that communicate with this server are at version **{{< skew prevMinorVersion >}}** (this ensures they are not newer than the existing API server version, and are within 1 minor version of the new API server version)
|
||||
* `kubelet` instances on all nodes are at version **{{< skew prevMinorVersion >}}** or **{{< skew oldestMinorVersion >}}** (this ensures they are not newer than the existing API server version, and are within 2 minor versions of the new API server version)
|
||||
* Registered admission webhooks are able to handle the data the new `kube-apiserver` instance will send them:
|
||||
* `ValidatingWebhookConfiguration` and `MutatingWebhookConfiguration` objects are updated to include any new versions of REST resources added in **1.(n+1)** (or use the [`matchPolicy: Equivalent` option](/docs/reference/access-authn-authz/extensible-admission-controllers/#matching-requests-matchpolicy) available in v1.15+)
|
||||
* The webhooks are able to handle any new versions of REST resources that will be sent to them, and any new fields added to existing versions in **1.(n+1)**
|
||||
* `ValidatingWebhookConfiguration` and `MutatingWebhookConfiguration` objects are updated to include any new versions of REST resources added in **{{< skew latestVersion >}}** (or use the [`matchPolicy: Equivalent` option](/docs/reference/access-authn-authz/extensible-admission-controllers/#matching-requests-matchpolicy) available in v1.15+)
|
||||
* The webhooks are able to handle any new versions of REST resources that will be sent to them, and any new fields added to existing versions in **{{< skew latestVersion >}}**
|
||||
|
||||
Upgrade `kube-apiserver` to **1.(n+1)**
|
||||
Upgrade `kube-apiserver` to **{{< skew latestVersion >}}**
|
||||
|
||||
{{< note >}}
|
||||
Project policies for [API deprecation](/docs/reference/using-api/deprecation-policy/) and
|
||||
@@ -128,17 +128,17 @@ require `kube-apiserver` to not skip minor versions when upgrading, even in sing
|
||||
|
||||
Pre-requisites:
|
||||
|
||||
* The `kube-apiserver` instances these components communicate with are at **1.(n+1)** (in HA clusters in which these control plane components can communicate with any `kube-apiserver` instance in the cluster, all `kube-apiserver` instances must be upgraded before upgrading these components)
|
||||
* The `kube-apiserver` instances these components communicate with are at **{{< skew latestVersion >}}** (in HA clusters in which these control plane components can communicate with any `kube-apiserver` instance in the cluster, all `kube-apiserver` instances must be upgraded before upgrading these components)
|
||||
|
||||
Upgrade `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` to **1.(n+1)**
|
||||
Upgrade `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` to **{{< skew latestVersion >}}**
|
||||
|
||||
### kubelet
|
||||
|
||||
Pre-requisites:
|
||||
|
||||
* The `kube-apiserver` instances the `kubelet` communicates with are at **1.(n+1)**
|
||||
* The `kube-apiserver` instances the `kubelet` communicates with are at **{{< skew latestVersion >}}**
|
||||
|
||||
Optionally upgrade `kubelet` instances to **1.(n+1)** (or they can be left at **1.n** or **1.(n-1)**)
|
||||
Optionally upgrade `kubelet` instances to **{{< skew latestVersion >}}** (or they can be left at **{{< skew prevMinorVersion >}}** or **{{< skew oldestMinorVersion >}}**)
|
||||
|
||||
{{< warning >}}
|
||||
Running a cluster with `kubelet` instances that are persistently two minor versions behind `kube-apiserver` is not recommended:
|
||||
|
||||
@@ -66,7 +66,7 @@ This page shows you how to set up a simple Ingress which routes requests to Serv
|
||||
1. Create a Deployment using the following command:
|
||||
|
||||
```shell
|
||||
kubectl run web --image=gcr.io/google-samples/hello-app:1.0 --port=8080
|
||||
kubectl create deployment web --image=gcr.io/google-samples/hello-app:1.0 --port=8080
|
||||
```
|
||||
|
||||
Output:
|
||||
@@ -78,7 +78,7 @@ This page shows you how to set up a simple Ingress which routes requests to Serv
|
||||
1. Expose the Deployment:
|
||||
|
||||
```shell
|
||||
kubectl expose deployment web --target-port=8080 --type=NodePort
|
||||
kubectl expose deployment web --type=NodePort --port=8080
|
||||
```
|
||||
|
||||
Output:
|
||||
|
||||
@@ -251,15 +251,14 @@ The name of an APIService object must be a valid
|
||||
|
||||
#### Contacting the extension apiserver
|
||||
|
||||
Once the Kubernetes apiserver has determined a request should be sent to a extension apiserver,
|
||||
Once the Kubernetes apiserver has determined a request should be sent to an extension apiserver,
|
||||
it needs to know how to contact it.
|
||||
|
||||
The `service` stanza is a reference to the service for a extension apiserver.
|
||||
The `service` stanza is a reference to the service for an extension apiserver.
|
||||
The service namespace and name are required. The port is optional and defaults to 443.
|
||||
The path is optional and defaults to "/".
|
||||
|
||||
Here is an example of an extension apiserver that is configured to be called on port "1234"
|
||||
at the subpath "/my-path", and to verify the TLS connection against the ServerName
|
||||
Here is an example of an extension apiserver that is configured to be called on port "1234",
|
||||
and to verify the TLS connection against the ServerName
|
||||
`my-service-name.my-service-namespace.svc` using a custom CA bundle.
|
||||
|
||||
```yaml
|
||||
|
||||
@@ -56,7 +56,7 @@ Take a look inside the resolv.conf file.
|
||||
[Known issues](#known-issues) below for more information)
|
||||
|
||||
```shell
|
||||
kubectl exec dnsutils cat /etc/resolv.conf
|
||||
kubectl exec -ti dnsutils -- cat /etc/resolv.conf
|
||||
```
|
||||
|
||||
Verify that the search path and name server are set up like the following
|
||||
|
||||
@@ -184,5 +184,3 @@ resources:
|
||||
kubectl get secrets --all-namespaces -o json | kubectl replace -f -
|
||||
```
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
@@ -6,6 +6,7 @@ reviewers:
|
||||
- klueska
|
||||
- lmdaly
|
||||
- nolancon
|
||||
- bg-chun
|
||||
|
||||
content_template: templates/task
|
||||
min-kubernetes-server-version: v1.18
|
||||
@@ -13,7 +14,7 @@ min-kubernetes-server-version: v1.18
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
{{< feature-state state="beta" >}}
|
||||
{{< feature-state state="beta" for_k8s_version="v1.18" >}}
|
||||
|
||||
An increasing number of systems leverage a combination of CPUs and hardware accelerators to support latency-critical execution and high-throughput parallel computation. These include workloads in fields such as telecommunications, scientific computing, machine learning, financial services and data analytics. Such hybrid systems comprise a high performance environment.
|
||||
|
||||
@@ -53,11 +54,16 @@ Support for the Topology Manager requires `TopologyManager` [feature gate](/docs
|
||||
|
||||
The Topology Manager currently:
|
||||
|
||||
- Works on Nodes with the `static` CPU Manager Policy enabled. See [control CPU Management Policies](/docs/tasks/administer-cluster/cpu-management-policies/)
|
||||
- Works on Pods making CPU requests or Device requests via extended resources
|
||||
- Aligns Pods of all QoS classes.
|
||||
- Aligns the requested resources that Hint Provider provides topology hints for.
|
||||
|
||||
If these conditions are met, Topology Manager will align the requested resources.
|
||||
|
||||
{{< note >}}
|
||||
To align CPU resources with other requested resources in a Pod Spec, the CPU Manager should be enabled and proper CPU Manager policy should be configured on a Node. See [control CPU Management Policies](/docs/tasks/administer-cluster/cpu-management-policies/).
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
Topology Manager supports four allocation policies. You can set a policy via a Kubelet flag, `--topology-manager-policy`.
|
||||
There are four supported policies:
|
||||
|
||||
@@ -72,7 +78,7 @@ This is the default policy and does not perform any topology alignment.
|
||||
|
||||
### best-effort policy {#policy-best-effort}
|
||||
|
||||
For each container in a Guaranteed Pod, kubelet, with `best-effort` topology
|
||||
For each container in a Pod, the kubelet, with `best-effort` topology
|
||||
management policy, calls each Hint Provider to discover their resource availability.
|
||||
Using this information, the Topology Manager stores the
|
||||
preferred NUMA Node affinity for that container. If the affinity is not preferred,
|
||||
@@ -83,7 +89,7 @@ resource allocation decision.
|
||||
|
||||
### restricted policy {#policy-restricted}
|
||||
|
||||
For each container in a Guaranteed Pod, kubelet, with `restricted` topology
|
||||
For each container in a Pod, the kubelet, with `restricted` topology
|
||||
management policy, calls each Hint Provider to discover their resource availability.
|
||||
Using this information, the Topology Manager stores the
|
||||
preferred NUMA Node affinity for that container. If the affinity is not preferred,
|
||||
@@ -97,7 +103,7 @@ resource allocation decision.
|
||||
|
||||
### single-numa-node policy {#policy-single-numa-node}
|
||||
|
||||
For each container in a Guaranteed Pod, kubelet, with `single-numa-node` topology
|
||||
For each container in a Pod, the kubelet, with `single-numa-node` topology
|
||||
management policy, calls each Hint Provider to discover their resource availability.
|
||||
Using this information, the Topology Manager determines if a single NUMA Node affinity is possible.
|
||||
If it is, Topology Manager will store this and the *Hint Providers* can then use this information when making the
|
||||
@@ -135,8 +141,7 @@ spec:
|
||||
|
||||
This pod runs in the `Burstable` QoS class because requests are less than limits.
|
||||
|
||||
If the selected policy is anything other than `none` , Topology Manager would not consider either of these Pod
|
||||
specifications.
|
||||
If the selected policy is anything other than `none`, Topology Manager would consider these Pod specifications. The Topology Manager would consult the Hint Providers to get topology hints. In the case of the `static`, the CPU Manager policy would return default topology hint, because these Pods do not have explicity request CPU resources.
|
||||
|
||||
|
||||
```yaml
|
||||
@@ -155,7 +160,26 @@ spec:
|
||||
example.com/device: "1"
|
||||
```
|
||||
|
||||
This pod runs in the `Guaranteed` QoS class because `requests` are equal to `limits`.
|
||||
This pod with integer CPU request runs in the `Guaranteed` QoS class because `requests` are equal to `limits`.
|
||||
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
containers:
|
||||
- name: nginx
|
||||
image: nginx
|
||||
resources:
|
||||
limits:
|
||||
memory: "200Mi"
|
||||
cpu: "300m"
|
||||
example.com/device: "1"
|
||||
requests:
|
||||
memory: "200Mi"
|
||||
cpu: "300m"
|
||||
example.com/device: "1"
|
||||
```
|
||||
|
||||
This pod with sharing CPU request runs in the `Guaranteed` QoS class because `requests` are equal to `limits`.
|
||||
|
||||
|
||||
```yaml
|
||||
@@ -173,10 +197,15 @@ spec:
|
||||
```
|
||||
This pod runs in the `BestEffort` QoS class because there are no CPU and memory requests.
|
||||
|
||||
The Topology Manager would consider both of the above pods. The Topology Manager would consult the Hint Providers, which are CPU and Device Manager to get topology hints for the pods.
|
||||
In the case of the `Guaranteed` pod the `static` CPU Manager policy would return hints relating to the CPU request and the Device Manager would send back hints for the requested device.
|
||||
The Topology Manager would consider the above pods. The Topology Manager would consult the Hint Providers, which are CPU and Device Manager to get topology hints for the pods.
|
||||
|
||||
In the case of the `BestEffort` pod the CPU Manager would send back the default hint as there is no CPU request and the Device Manager would send back the hints for each of the requested devices.
|
||||
In the case of the `Guaranteed` pod with integer CPU request, the `static` CPU Manager policy would return topology hints relating to the exclusive CPU and the Device Manager would send back hints for the requested device.
|
||||
|
||||
In the case of the `Guaranteed` pod with sharing CPU request, the `static` CPU Manager policy would return default topology hint as there is no exclusive CPU request and the Device Manager would send back hints for the requested device.
|
||||
|
||||
In the above two cases of the `Guaranteed` pod, the `none` CPU Manager policy would return default topology hint.
|
||||
|
||||
In the case of the `BestEffort` pod, the `static` CPU Manager policy would send back the default topology hint as there is no CPU request and the Device Manager would send back the hints for each of the requested devices.
|
||||
|
||||
Using this information the Topology Manager calculates the optimal hint for the pod and stores this information, which will be used by the Hint Providers when they are making their resource assignments.
|
||||
|
||||
|
||||
+1
-1
@@ -49,7 +49,7 @@ In this exercise, you create a Pod that runs a container based on the
|
||||
In the configuration file, you can see that the Pod has a single `Container`.
|
||||
The `periodSeconds` field specifies that the kubelet should perform a liveness
|
||||
probe every 5 seconds. The `initialDelaySeconds` field tells the kubelet that it
|
||||
should wait 5 second before performing the first probe. To perform a probe, the
|
||||
should wait 5 seconds before performing the first probe. To perform a probe, the
|
||||
kubelet executes the command `cat /tmp/healthy` in the target container. If the
|
||||
command succeeds, it returns 0, and the kubelet considers the container to be alive and
|
||||
healthy. If the command returns a non-zero value, the kubelet kills the container
|
||||
|
||||
@@ -94,7 +94,7 @@ worker node, but it can't run on that machine. Again, the information from
|
||||
### My pod is crashing or otherwise unhealthy
|
||||
|
||||
Once your pod has been scheduled, the methods described in [Debug Running Pods](
|
||||
/docs/tasks/debug-application-cluster/debug-running-pods/) are available for debugging.
|
||||
/docs/tasks/debug-application-cluster/debug-running-pod/) are available for debugging.
|
||||
|
||||
|
||||
## Debugging ReplicationControllers
|
||||
|
||||
@@ -1,52 +1,70 @@
|
||||
---
|
||||
title: Parallel Processing using Expansions
|
||||
content_template: templates/concept
|
||||
content_template: templates/task
|
||||
min-kubernetes-server-version: v1.8
|
||||
weight: 20
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
In this example, we will run multiple Kubernetes Jobs created from
|
||||
a common template. You may want to be familiar with the basic,
|
||||
non-parallel, use of [Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/) first.
|
||||
This task demonstrates running multiple {{< glossary_tooltip text="Jobs" term_id="job" >}}
|
||||
based on a common template. You can use this approach to process batches of work in
|
||||
parallel.
|
||||
|
||||
For this example there are only three items: _apple_, _banana_, and _cherry_.
|
||||
The sample Jobs process each item simply by printing a string then pausing.
|
||||
|
||||
See [using Jobs in real workloads](#using-jobs-in-real-workloads) to learn about how
|
||||
this pattern fits more realistic use cases.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
You should be familiar with the basic,
|
||||
non-parallel, use of [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/).
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
For basic templating you need the command-line utility `sed`.
|
||||
|
||||
To follow the advanced templating example, you need a working installation of
|
||||
[Python](https://www.python.org/), and the Jinja2 template
|
||||
library for Python.
|
||||
|
||||
Once you have Python set up, you can install Jinja2 by running:
|
||||
```shell
|
||||
pip install --user jinja2
|
||||
```
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
{{% capture steps %}}
|
||||
|
||||
## Basic Template Expansion
|
||||
## Create Jobs based on a template
|
||||
|
||||
First, download the following template of a job to a file called `job-tmpl.yaml`
|
||||
First, download the following template of a Job to a file called `job-tmpl.yaml`.
|
||||
Here's what you'll download:
|
||||
|
||||
{{< codenew file="application/job/job-tmpl.yaml" >}}
|
||||
|
||||
Unlike a *pod template*, our *job template* is not a Kubernetes API type. It is just
|
||||
a yaml representation of a Job object that has some placeholders that need to be filled
|
||||
in before it can be used. The `$ITEM` syntax is not meaningful to Kubernetes.
|
||||
```shell
|
||||
# Use curl to download job-tmpl.yaml
|
||||
curl -L -s -O https://k8s.io/examples/application/job/job-tmpl.yaml
|
||||
```
|
||||
|
||||
In this example, the only processing the container does is to `echo` a string and sleep for a bit.
|
||||
In a real use case, the processing would be some substantial computation, such as rendering a frame
|
||||
of a movie, or processing a range of rows in a database. The `$ITEM` parameter would specify for
|
||||
example, the frame number or the row range.
|
||||
The file you downloaded is not yet a valid Kubernetes
|
||||
{{< glossary_tooltip text="manifest" term_id="manifest" >}}.
|
||||
Instead that template is a YAML representation of a Job object with some placeholders
|
||||
that need to be filled in before it can be used. The `$ITEM` syntax is not meaningful to Kubernetes.
|
||||
|
||||
This Job and its Pod template have a label: `jobgroup=jobexample`. There is nothing special
|
||||
to the system about this label. This label
|
||||
makes it convenient to operate on all the jobs in this group at once.
|
||||
We also put the same label on the pod template so that we can check on all Pods of these Jobs
|
||||
with a single command.
|
||||
After the job is created, the system will add more labels that distinguish one Job's pods
|
||||
from another Job's pods.
|
||||
Note that the label key `jobgroup` is not special to Kubernetes. You can pick your own label scheme.
|
||||
|
||||
Next, expand the template into multiple files, one for each item to be processed.
|
||||
### Create manifests from the template
|
||||
|
||||
The following shell snippet uses `sed` to replace the string `$ITEM` with the loop
|
||||
variable, writing into a temporary directory named `jobs`. Run this now:
|
||||
|
||||
```shell
|
||||
# Download job-templ.yaml
|
||||
curl -L -s -O https://k8s.io/examples/application/job/job-tmpl.yaml
|
||||
|
||||
# Expand files into a temporary directory
|
||||
# Expand the template into multiple files, one for each item to be processed.
|
||||
mkdir ./jobs
|
||||
for i in apple banana cherry
|
||||
do
|
||||
@@ -68,11 +86,12 @@ job-banana.yaml
|
||||
job-cherry.yaml
|
||||
```
|
||||
|
||||
Here, we used `sed` to replace the string `$ITEM` with the loop variable.
|
||||
You could use any type of template language (jinja2, erb) or write a program
|
||||
to generate the Job objects.
|
||||
You could use any type of template language (for example: Jinja2; ERB), or
|
||||
write a program to generate the Job manifests.
|
||||
|
||||
Next, create all the jobs with one kubectl command:
|
||||
### Create Jobs from the manifests
|
||||
|
||||
Next, create all the Jobs with one kubectl command:
|
||||
|
||||
```shell
|
||||
kubectl create -f ./jobs
|
||||
@@ -96,22 +115,23 @@ The output is similar to this:
|
||||
|
||||
```
|
||||
NAME COMPLETIONS DURATION AGE
|
||||
process-item-apple 1/1 14s 20s
|
||||
process-item-banana 1/1 12s 20s
|
||||
process-item-apple 1/1 14s 22s
|
||||
process-item-banana 1/1 12s 21s
|
||||
process-item-cherry 1/1 12s 20s
|
||||
```
|
||||
|
||||
Here we use the `-l` option to select all jobs that are part of this
|
||||
group of jobs. (There might be other unrelated jobs in the system that we
|
||||
do not care to see.)
|
||||
Using the `-l` option to kubectl selects only the Jobs that are part
|
||||
of this group of jobs (there might be other unrelated jobs in the system).
|
||||
|
||||
You can check on the Pods as well using the same
|
||||
{{< glossary_tooltip text="label selector" term_id="selector" >}}:
|
||||
|
||||
We can check on the pods as well using the same label selector:
|
||||
|
||||
```shell
|
||||
kubectl get pods -l jobgroup=jobexample
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
The output is similar to:
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
@@ -126,7 +146,7 @@ We can use this single command to check on the output of all jobs at once:
|
||||
kubectl logs -f -l jobgroup=jobexample
|
||||
```
|
||||
|
||||
The output is:
|
||||
The output should be:
|
||||
|
||||
```
|
||||
Processing item apple
|
||||
@@ -134,26 +154,40 @@ Processing item banana
|
||||
Processing item cherry
|
||||
```
|
||||
|
||||
## Multiple Template Parameters
|
||||
### Clean up {#cleanup-1}
|
||||
|
||||
In the first example, each instance of the template had one parameter, and that parameter was also
|
||||
used as a label. However label keys are limited in [what characters they can
|
||||
contain](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set).
|
||||
```shell
|
||||
# Remove the Jobs you created
|
||||
# Your cluster automatically cleans up their Pods
|
||||
kubectl delete job -l jobgroup=jobexample
|
||||
```
|
||||
|
||||
This slightly more complex example uses the jinja2 template language to generate our objects.
|
||||
We will use a one-line python script to convert the template to a file.
|
||||
## Use advanced template parameters
|
||||
|
||||
In the [first example](#create-jobs-based-on-a-template), each instance of the template had one
|
||||
parameter, and that parameter was also used in the Job's name. However,
|
||||
[names](/docs/concepts/overview/working-with-objects/names/#names) are restricted
|
||||
to contain only certain characters.
|
||||
|
||||
This slightly more complex example uses the
|
||||
[Jinja template language](https://palletsprojects.com/p/jinja/) to generate manifests
|
||||
and then objects from those manifests, with a multiple parameters for each Job.
|
||||
|
||||
For this part of the task, you are going to use a one-line Python script to
|
||||
convert the template to a set of manifests.
|
||||
|
||||
First, copy and paste the following template of a Job object, into a file called `job.yaml.jinja2`:
|
||||
|
||||
|
||||
```liquid
|
||||
{%- set params = [{ "name": "apple", "url": "https://www.orangepippin.com/varieties/apples", },
|
||||
{ "name": "banana", "url": "https://en.wikipedia.org/wiki/Banana", },
|
||||
{ "name": "raspberry", "url": "https://www.raspberrypi.org/" }]
|
||||
{%- 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"] %}
|
||||
---
|
||||
apiVersion: batch/v1
|
||||
kind: Job
|
||||
metadata:
|
||||
@@ -172,51 +206,108 @@ spec:
|
||||
image: busybox
|
||||
command: ["sh", "-c", "echo Processing URL {{ url }} && sleep 5"]
|
||||
restartPolicy: Never
|
||||
---
|
||||
{%- endfor %}
|
||||
|
||||
```
|
||||
|
||||
The above template defines parameters for each job object using a list of
|
||||
python dicts (lines 1-4). Then a for loop emits one job yaml object
|
||||
for each set of parameters (remaining lines).
|
||||
We take advantage of the fact that multiple yaml documents can be concatenated
|
||||
with the `---` separator (second to last line).
|
||||
.) We can pipe the output directly to kubectl to
|
||||
create the objects.
|
||||
The above template defines two parameters for each Job object using a list of
|
||||
python dicts (lines 1-4). A `for` loop emits one Job manifest for each
|
||||
set of parameters (remaining lines).
|
||||
|
||||
You will need the jinja2 package if you do not already have it: `pip install --user jinja2`.
|
||||
Now, use this one-line python program to expand the template:
|
||||
This example relies on a feature of YAML. One YAML file can contain multiple
|
||||
documents (Kubernetes manifests, in this case), separated by `---` on a line
|
||||
by itself.
|
||||
You can pipe the output directly to `kubectl` to create the Jobs.
|
||||
|
||||
Next, use this one-line Python program to expand the template:
|
||||
|
||||
```shell
|
||||
alias render_template='python -c "from jinja2 import Template; import sys; print(Template(sys.stdin.read()).render());"'
|
||||
```
|
||||
|
||||
|
||||
|
||||
The output can be saved to a file, like this:
|
||||
Use `render_template` to convert the parameters and template into a single
|
||||
YAML file containing Kubernetes manifests:
|
||||
|
||||
```shell
|
||||
# This requires the alias you defined earlier
|
||||
cat job.yaml.jinja2 | render_template > jobs.yaml
|
||||
```
|
||||
|
||||
Or sent directly to kubectl, like this:
|
||||
You can view `jobs.yaml` to verify that the `render_template` script worked
|
||||
correctly.
|
||||
|
||||
Once you are happy that `render_template` is working how you intend,
|
||||
you can pipe its output into `kubectl`:
|
||||
|
||||
```shell
|
||||
cat job.yaml.jinja2 | render_template | kubectl apply -f -
|
||||
```
|
||||
|
||||
## Alternatives
|
||||
Kubernetes accepts and runs the Jobs you created.
|
||||
|
||||
If you have a large number of job objects, you may find that:
|
||||
### Clean up {#cleanup-2}
|
||||
|
||||
- Even using labels, managing so many Job objects is cumbersome.
|
||||
- You exceed resource quota when creating all the Jobs at once,
|
||||
and do not want to wait to create them incrementally.
|
||||
- Very large numbers of jobs created at once overload the
|
||||
Kubernetes apiserver, controller, or scheduler.
|
||||
|
||||
In this case, you can consider one of the
|
||||
other [job patterns](/docs/concepts/jobs/run-to-completion-finite-workloads/#job-patterns).
|
||||
```shell
|
||||
# Remove the Jobs you created
|
||||
# Your cluster automatically cleans up their Pods
|
||||
kubectl delete job -l jobgroup=jobexample
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
{{% capture discussion %}}
|
||||
|
||||
## Using Jobs in real workloads
|
||||
|
||||
In a real use case, each Job performs some substantial computation, such as rendering a frame
|
||||
of a movie, or processing a range of rows in a database. If you were rendering a movie
|
||||
you would set `$ITEM` to the frame number. If you were processing rows from a database
|
||||
table, you would set `$ITEM` to represent the range of database rows to process.
|
||||
|
||||
In the task, you ran a command to collect the output from Pods by fetching
|
||||
their logs. In a real use case, each Pod for a Job writes its output to
|
||||
durable storage before completing. You can use a PersistentVolume for each Job,
|
||||
or an external storage service. For example, if you are rendering frames for a movie,
|
||||
use HTTP to `PUT` the rendered frame data to a URL, using a different URL for each
|
||||
frame.
|
||||
|
||||
## Labels on Jobs and Pods
|
||||
|
||||
After you create a Job, Kubernetes automatically adds additional
|
||||
{{< glossary_tooltip text="labels" term_id="label" >}} that
|
||||
distinguish one Job's pods from another Job's pods.
|
||||
|
||||
In this example, each Job and its Pod template have a label:
|
||||
`jobgroup=jobexample`.
|
||||
|
||||
Kubernetes itself pays no attention to labels named `jobgroup`. Setting a label
|
||||
for all the Jobs you create from a template makes it convenient to operate on all
|
||||
those Jobs at once.
|
||||
In the [first example](#create-jobs-based-on-a-template) you used a template to
|
||||
create several Jobs. The template ensures that each Pod also gets the same label, so
|
||||
you can check on all Pods for these templated Jobs with a single command.
|
||||
|
||||
{{< note >}}
|
||||
The label key `jobgroup` is not special or reserved.
|
||||
You can pick your own labelling scheme.
|
||||
There are [recommended labels](/docs/concepts/overview/working-with-objects/common-labels/#labels)
|
||||
that you can use if you wish.
|
||||
{{< /note >}}
|
||||
|
||||
## Alternatives
|
||||
|
||||
If you plan to create a large number of Job objects, you may find that:
|
||||
|
||||
- Even using labels, managing so many Jobs is cumbersome.
|
||||
- If you create many Jobs in a batch, you might place high load
|
||||
on the Kubernetes control plane. Alternatively, the Kubernetes API
|
||||
server could rate limit you, temporarily rejecting your requests with a 429 status.
|
||||
- You are limited by a {{< glossary_tooltip text="resource quota" term_id="resource-quota" >}}
|
||||
on Jobs: the API server permanently rejects some of your requests
|
||||
when you create a great deal of work in one batch.
|
||||
|
||||
There are other [job patterns](/docs/concepts/jobs/run-to-completion-finite-workloads/#job-patterns)
|
||||
that you can use to process large amounts of work without creating very many Job
|
||||
objects.
|
||||
|
||||
You could also consider writing your own [controller](/docs/concepts/architecture/controller/)
|
||||
to manage Job objects automatically.
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -239,7 +239,7 @@ the only other supported resource metric is memory. These resources do not chan
|
||||
to cluster, and should always be available, as long as the `metrics.k8s.io` API is available.
|
||||
|
||||
You can also specify resource metrics in terms of direct values, instead of as percentages of the
|
||||
requested value, by using a `target` type of `AverageValue` instead of `AverageUtilization`, and
|
||||
requested value, by using a `target.type` of `AverageValue` instead of `Utilization`, and
|
||||
setting the corresponding `target.averageValue` field instead of the `target.averageUtilization`.
|
||||
|
||||
There are two other types of metrics, both of which are considered *custom metrics*: pod metrics and
|
||||
|
||||
@@ -88,11 +88,11 @@ a Deployment that runs the nginx:1.14.2 Docker image:
|
||||
nginx-deployment-1771418926-7o5ns 1/1 Running 0 16h
|
||||
nginx-deployment-1771418926-r18az 1/1 Running 0 16h
|
||||
|
||||
1. Display information about a pod:
|
||||
1. Display information about a Pod:
|
||||
|
||||
kubectl describe pod <pod-name>
|
||||
|
||||
where `<pod-name>` is the name of one of your pods.
|
||||
where `<pod-name>` is the name of one of your Pods.
|
||||
|
||||
## Updating the deployment
|
||||
|
||||
|
||||
@@ -19,7 +19,7 @@ weight: 20
|
||||
|
||||
<div class="katacoda">
|
||||
<div class="katacoda__alert">
|
||||
To interact with the Terminal, please use the desktop/tablet version
|
||||
The screen is too narrow to interact with the Terminal, please use a desktop/tablet.
|
||||
</div>
|
||||
<div class="katacoda__box" id="inline-terminal-1" data-katacoda-id="kubernetes-bootcamp/1" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;"></div>
|
||||
</div>
|
||||
|
||||
@@ -76,7 +76,7 @@ weight: 10
|
||||
|
||||
<p>You can create and manage a Deployment by using the Kubernetes command line interface, <b>Kubectl</b>. Kubectl uses the Kubernetes API to interact with the cluster. In this module, you'll learn the most common Kubectl commands needed to create Deployments that run your applications on a Kubernetes cluster.</p>
|
||||
|
||||
<p>When you create a Deployment, you'll need to specify the container image for your application and the number of replicas that you want to run. You can change that information later by updating your Deployment; Modules <a href="/docs/tutorials/kubernetes-basics/scale-intro/">5</a> and <a href="/docs/tutorials/kubernetes-basics/update-intro/">6</a> of the bootcamp discuss how you can scale and update your Deployments.</p>
|
||||
<p>When you create a Deployment, you'll need to specify the container image for your application and the number of replicas that you want to run. You can change that information later by updating your Deployment; Modules <a href="/docs/tutorials/kubernetes-basics/scale/scale-intro/">5</a> and <a href="/docs/tutorials/kubernetes-basics/update/update-intro/">6</a> of the bootcamp discuss how you can scale and update your Deployments.</p>
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -29,7 +29,7 @@ weight: 10
|
||||
|
||||
<div class="col-md-8">
|
||||
<h2>Kubernetes Pods</h2>
|
||||
<p>When you created a Deployment in Module <a href="/docs/tutorials/kubernetes-basics/deploy-intro/">2</a>, Kubernetes created a <b>Pod</b> to host your application instance. A Pod is a Kubernetes abstraction that represents a group of one or more application containers (such as Docker or rkt), and some shared resources for those containers. Those resources include:</p>
|
||||
<p>When you created a Deployment in Module <a href="/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/">2</a>, Kubernetes created a <b>Pod</b> to host your application instance. A Pod is a Kubernetes abstraction that represents a group of one or more application containers (such as Docker or rkt), and some shared resources for those containers. Those resources include:</p>
|
||||
<ul>
|
||||
<li>Shared storage, as Volumes</li>
|
||||
<li>Networking, as a unique cluster IP address</li>
|
||||
@@ -108,7 +108,7 @@ weight: 10
|
||||
<div class="row">
|
||||
<div class="col-md-8">
|
||||
<h2>Troubleshooting with kubectl</h2>
|
||||
<p>In Module <a href="/docs/tutorials/kubernetes-basics/deploy-intro/">2</a>, you used Kubectl command-line interface. You'll continue to use it in Module 3 to get information about deployed applications and their environments. The most common operations can be done with the following kubectl commands:</p>
|
||||
<p>In Module <a href="/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/">2</a>, you used Kubectl command-line interface. You'll continue to use it in Module 3 to get information about deployed applications and their environments. The most common operations can be done with the following kubectl commands:</p>
|
||||
<ul>
|
||||
<li><b>kubectl get</b> - list resources</li>
|
||||
<li><b>kubectl describe</b> - show detailed information about a resource</li>
|
||||
|
||||
@@ -1,12 +0,0 @@
|
||||
|
||||
|
||||
<table style="background-color:#eeeeee">
|
||||
<tr>
|
||||
<td>
|
||||
<p><b>NOTICE</b></p>
|
||||
<p>As of March 14, 2017, the Kubernetes SIG-Docs-Maintainers group have begun migration of the User Guide content as announced previously to the <a href="https://git.k8s.io/community/sig-docs">SIG Docs community</a> through the <a href="https://groups.google.com/forum/#!forum/kubernetes-sig-docs">kubernetes-sig-docs</a> group and <a href="https://kubernetes.slack.com/messages/sig-docs/">kubernetes.slack.com #sig-docs</a> channel.</p>
|
||||
<p>The user guides within this section are being refactored into topics within Tutorials, Tasks, and Concepts. Anything that has been moved will have a notice placed in its previous location as well as a link to its new location. The reorganization implements a new table of contents and should improve the documentation's findability and readability for a wider range of audiences.</p>
|
||||
<p>For any questions, please contact: <a href="mailto:kubernetes-sig-docs@googlegroups.com">kubernetes-sig-docs@googlegroups.com</a></p>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
@@ -39,7 +39,7 @@ por lo que debe completarse antes de que la llamada para eliminar el contenedor
|
||||
No se le pasa ningún parámetro.
|
||||
|
||||
Puedes encontrar información más detallada sobre el comportamiento de finalización de un contenedor
|
||||
[Finalización de Pods](/docs/es/concepts/workloads/pods/pod/#termination-of-pods).
|
||||
[Finalización de Pods](/docs/concepts/workloads/pods/pod/#termination-of-pods).
|
||||
|
||||
### Implementación de controladores de hooks
|
||||
|
||||
|
||||
@@ -312,7 +312,7 @@ Si vous utilisez uniquement DNS pour découvrir l'IP du cluster pour un service,
|
||||
|
||||
### DNS
|
||||
|
||||
Vous pouvez (et devrait presque toujours) configurer un service DNS pour votre cluster Kubernetes à l'aide d'un [add-on](/docs/concepts/cluster-administration/addons/).
|
||||
Vous pouvez (et devriez presque toujours) configurer un service DNS pour votre cluster Kubernetes à l'aide d'un [add-on](/docs/concepts/cluster-administration/addons/).
|
||||
|
||||
Un serveur DNS prenant en charge les clusters, tel que CoreDNS, surveille l'API Kubernetes pour les nouveaux services et crée un ensemble d'enregistrements DNS pour chacun.
|
||||
Si le DNS a été activé dans votre cluster, tous les pods devraient automatiquement être en mesure de résoudre les services par leur nom DNS.
|
||||
@@ -384,7 +384,7 @@ Si vous définissez le champ `type` sur` NodePort`, le plan de contrôle Kuberne
|
||||
Chaque nœud assure le proxy de ce port (le même numéro de port sur chaque nœud) vers votre service.
|
||||
Votre service signale le port alloué dans son champ `.spec.ports[*].nodePort`.
|
||||
|
||||
Si vous souhaitez spécifier une ou des adresses IP particulières pour proxyer le port, vous pouvez définir l'indicateur `--nodeport-addresses` dans kube-proxy sur des blocs IP particuliers; cela est pris en charge depuis Kubernetes v1.10.
|
||||
Si vous souhaitez spécifier une ou des adresses IP particulières pour proxyfier le port, vous pouvez définir l'indicateur `--nodeport-addresses` dans kube-proxy sur des blocs IP particuliers; cela est pris en charge depuis Kubernetes v1.10.
|
||||
Cet indicateur prend une liste délimitée par des virgules de blocs IP (par exemple 10.0.0.0/8, 192.0.2.0/25) pour spécifier les plages d'adresses IP que kube-proxy doit considérer comme locales pour ce nœud.
|
||||
|
||||
Par exemple, si vous démarrez kube-proxy avec l'indicateur `--nodeport-addresses=127.0.0.0/8`, kube-proxy sélectionne uniquement l'interface de boucle locale pour les services NodePort.
|
||||
|
||||
@@ -0,0 +1,208 @@
|
||||
---
|
||||
title: Récupération d'une image d'un registre privé
|
||||
content_template: templates/task
|
||||
weight: 100
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
Cette page montre comment créer un Pod qui utilise un Secret pour récupérer une image d'un registre privé.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
* Pour faire cet exercice, vous avez besoin d'un
|
||||
[Docker ID](https://docs.docker.com/docker-id/) et un mot de passe.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## Connectez-vous à Docker
|
||||
|
||||
Sur votre ordinateur, vous devez vous authentifier à un registre afin de récupérer une image privée :
|
||||
|
||||
```shell
|
||||
docker login
|
||||
```
|
||||
|
||||
Une fois que c'est fait, entrez votre nom d'utilisateur et votre mot de passe Docker.
|
||||
|
||||
Le processus de connexion crée ou met à jour un fichier `config.json` qui contient un token d'autorisation.
|
||||
|
||||
Consultez le fichier `config.json` :
|
||||
|
||||
```shell
|
||||
cat ~/.docker/config.json
|
||||
```
|
||||
|
||||
La sortie comporte une section similaire à celle-ci :
|
||||
|
||||
```json
|
||||
{
|
||||
"auths": {
|
||||
"https://index.docker.io/v1/": {
|
||||
"auth": "c3R...zE2"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
Si vous utilisez le credentials store de Docker, vous ne verrez pas cette entrée `auth` mais une entrée `credsStore` avec le nom du Store comme valeur.
|
||||
{{< /note >}}
|
||||
|
||||
## Créez un Secret basé sur les identifiants existants du Docker {#registry-secret-existing-credentials}
|
||||
|
||||
Le cluster Kubernetes utilise le type Secret de `docker-registry` pour s'authentifier avec
|
||||
un registre de conteneurs pour y récupérer une image privée.
|
||||
|
||||
Si vous avez déjà lancé `docker login`, vous pouvez copier ces identifiants dans Kubernetes
|
||||
|
||||
```shell
|
||||
kubectl create secret generic regcred \
|
||||
--from-file=.dockerconfigjson=<path/to/.docker/config.json> \
|
||||
--type=kubernetes.io/dockerconfigjson
|
||||
```
|
||||
|
||||
Si vous avez besoin de plus de contrôle (par exemple, pour définir un Namespace ou un label sur le nouveau secret), vous pouvez alors personnaliser le secret avant de le stocker.
|
||||
Assurez-vous de :
|
||||
|
||||
- Attribuer la valeur `.dockerconfigjson` dans le nom de l'élément data
|
||||
- Encoder le fichier docker en base64 et colle cette chaîne, non interrompue, comme valeur du champ `data[".dockerconfigjson"]`.
|
||||
- Mettre `type` à `kubernetes.io/dockerconfigjson`.
|
||||
|
||||
Exemple:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: myregistrykey
|
||||
namespace: awesomeapps
|
||||
data:
|
||||
.dockerconfigjson: UmVhbGx5IHJlYWxseSByZWVlZWVlZWVlZWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGx5eXl5eXl5eXl5eXl5eXl5eXl5eSBsbGxsbGxsbGxsbGxsbG9vb29vb29vb29vb29vb29vb29vb29vb29vb25ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg==
|
||||
type: kubernetes.io/dockerconfigjson
|
||||
```
|
||||
|
||||
Si vous obtenez le message d'erreur `error: no objects passed to create`, cela peut signifier que la chaîne encodée en base64 est invalide.
|
||||
Si vous obtenez un message d'erreur comme `Secret "myregistrykey" is invalid: data[.dockerconfigjson]: invalid value ...`, cela signifie que la chaîne encodée en base64 a été décodée avec succès, mais n'a pas pu être interprétée comme un fichier `.docker/config.json`.
|
||||
|
||||
## Créez un Secret en fournissant les identifiants sur la ligne de commande
|
||||
|
||||
Créez ce secret, en le nommant `regcred` :
|
||||
|
||||
```shell
|
||||
kubectl create secret docker-registry regcred --docker-server=<your-registry-server> --docker-username=<your-name> --docker-password=<your-pword> --docker-email=<your-email>
|
||||
```
|
||||
|
||||
où :
|
||||
|
||||
* `<your-registry-server>` est votre FQDN de registre de docker privé. (https://index.docker.io/v1/ for DockerHub)
|
||||
* `<your-name>` est votre nom d'utilisateur Docker.
|
||||
* `<your-pword>` est votre mot de passe Docker.
|
||||
* `<your-email>` est votre email Docker.
|
||||
|
||||
Vous avez réussi à définir vos identifiants Docker dans le cluster comme un secret appelé `regcred`.
|
||||
|
||||
{{< note >}}
|
||||
Saisir des secrets sur la ligne de commande peut les conserver dans l'historique de votre shell sans protection, et ces secrets peuvent également être visibles par d'autres utilisateurs sur votre ordinateur pendant l'exécution de `kubectl`.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
## Inspection du secret `regcred`
|
||||
|
||||
Pour comprendre le contenu du Secret `regcred` que vous venez de créer, commencez par visualiser le Secret au format YAML :
|
||||
|
||||
```shell
|
||||
kubectl get secret regcred --output=yaml
|
||||
```
|
||||
|
||||
La sortie est similaire à celle-ci :
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
...
|
||||
name: regcred
|
||||
...
|
||||
data:
|
||||
.dockerconfigjson: eyJodHRwczovL2luZGV4L ... J0QUl6RTIifX0=
|
||||
type: kubernetes.io/dockerconfigjson
|
||||
```
|
||||
|
||||
La valeur du champ `.dockerconfigjson` est une représentation en base64 de vos identifiants Docker.
|
||||
|
||||
Pour comprendre ce que contient le champ `.dockerconfigjson`, convertissez les données secrètes en un format lisible :
|
||||
|
||||
```shell
|
||||
kubectl get secret regcred --output="jsonpath={.data.\.dockerconfigjson}" | base64 --decode
|
||||
```
|
||||
|
||||
La sortie est similaire à celle-ci :
|
||||
|
||||
```json
|
||||
{"auths":{"your.private.registry.example.com":{"username":"janedoe","password":"xxxxxxxxxxx","email":"jdoe@example.com","auth":"c3R...zE2"}}}
|
||||
```
|
||||
|
||||
Pour comprendre ce qui se cache dans le champ `auth', convertissez les données encodées en base64 dans un format lisible :
|
||||
|
||||
```shell
|
||||
echo "c3R...zE2" | base64 --decode
|
||||
```
|
||||
|
||||
La sortie en tant que nom d'utilisateur et mot de passe concaténés avec un `:`, est similaire à ceci :
|
||||
|
||||
```none
|
||||
janedoe:xxxxxxxxxxx
|
||||
```
|
||||
|
||||
Remarquez que les données secrètes contiennent le token d'autorisation similaire à votre fichier local `~/.docker/config.json`.
|
||||
|
||||
Vous avez réussi à définir vos identifiants de Docker comme un Secret appelé `regcred` dans le cluster.
|
||||
|
||||
## Créez un Pod qui utilise votre Secret
|
||||
|
||||
Voici un fichier de configuration pour un Pod qui a besoin d'accéder à vos identifiants Docker dans `regcred` :
|
||||
|
||||
{{< codenew file="pods/private-reg-pod.yaml" >}}
|
||||
|
||||
Téléchargez le fichier ci-dessus :
|
||||
|
||||
```shell
|
||||
wget -O my-private-reg-pod.yaml https://k8s.io/examples/pods/private-reg-pod.yaml
|
||||
```
|
||||
|
||||
Dans le fichier `my-private-reg-pod.yaml`, remplacez `<your-private-image>` par le chemin d'accès à une image dans un registre privé tel que
|
||||
|
||||
```none
|
||||
your.private.registry.example.com/janedoe/jdoe-private:v1
|
||||
```
|
||||
|
||||
Pour récupérer l'image du registre privé, Kubernetes a besoin des identifiants.
|
||||
Le champ `imagePullSecrets` dans le fichier de configuration spécifie que Kubernetes doit obtenir les informations d'identification d'un Secret nommé `regcred`.
|
||||
|
||||
Créez un Pod qui utilise votre secret et vérifiez que le Pod est bien lancé :
|
||||
|
||||
```shell
|
||||
kubectl apply -f my-private-reg-pod.yaml
|
||||
kubectl get pod private-reg
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* Pour en savoir plus sur les [Secrets](/docs/concepts/configuration/secret/).
|
||||
* Pour en savoir plus sur l'[utilisation d'un registre privé](/docs/concepts/containers/images/#using-a-private-registry).
|
||||
* Pour en savoir plus sur l'[ajout d'un imagePullSecrets à un compte de service](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account).
|
||||
* Voir [kubectl crée un Secret de registre de docker](/docs/reference/generated/kubectl/kubectl-commands/#-em-secret-docker-registry-em-).
|
||||
* Voir [Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core).
|
||||
* Voir le champ `imagePullSecrets` de [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -0,0 +1,11 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: private-reg
|
||||
spec:
|
||||
containers:
|
||||
- name: private-reg-container
|
||||
image: <your-private-image>
|
||||
imagePullSecrets:
|
||||
- name: regcred
|
||||
|
||||
@@ -1,12 +0,0 @@
|
||||
|
||||
|
||||
<table style="background-color:#eeeeee">
|
||||
<tr>
|
||||
<td>
|
||||
<p><b>NOTICE</b></p>
|
||||
<p>À compter du 14 mars 2017, le groupe Kubernetes SIG-Docs-Maintainers a commencé la migration du contenu du guide de l'utilisateur, comme annoncé précédemment. <a href="https://git.k8s.io/community/sig-docs">SIG Docs community</a> à travers le groupe <a href="https://groups.google.com/forum/#!forum/kubernetes-sig-docs">kubernetes-sig-docs</a> et le canal Slack <a href="https://kubernetes.slack.com/messages/sig-docs/">kubernetes.slack.com #sig-docs</a> .</p>
|
||||
<p>Les guides de l’utilisateur dans cette section sont en train d’être refondus dans des rubriques dans Tutoriels, Tâches et Concepts. Tout ce qui a été déplacé aura un avis placé à son emplacement précédent, ainsi qu'un lien vers son nouvel emplacement. La réorganisation met en œuvre une nouvelle table des matières et devrait faciliter la recherche et améliorer la lisibilité de la documentation pour un public plus large.</p>
|
||||
<p>Pour toute question, veuillez contacter:<a href="mailto:kubernetes-sig-docs@googlegroups.com">kubernetes-sig-docs@googlegroups.com</a></p>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
@@ -17,11 +17,11 @@ kamu belajar lebih dalam bagaimana cara kerja Kubernetes.
|
||||
|
||||
## Ikhtisar
|
||||
|
||||
Untuk menggunakan Kubernetes, kamu menggunakan obyek-obyek *Kubernetes API* untuk merepresentasikan
|
||||
Untuk menggunakan Kubernetes, kamu menggunakan objek-objek *Kubernetes API* untuk merepresentasikan
|
||||
*state* yang diinginkan: apa yang aplikasi atau *workload* lain yang ingin kamu
|
||||
jalankan, *image* kontainer yang digunakan, jaringan atau *resource disk* apa yang ingin
|
||||
kamu sediakan, dan lain sebagainya. Kamu membuat *state* yang diinginkan dengan cara membuat
|
||||
obyek dengan menggunakan API Kubernetes, dan biasanya menggunakan `command-line interface`, yaitu `kubectl`.
|
||||
objek dengan menggunakan API Kubernetes, dan biasanya menggunakan `command-line interface`, yaitu `kubectl`.
|
||||
Kamu juga dapat secara langsung berinteraksi dengan klaster untuk membuat atau mengubah
|
||||
*state* yang kamu inginkan.
|
||||
|
||||
@@ -38,16 +38,16 @@ suatu aplikasi, dan lain sebagainya. *Control Plane* Kubernetes terdiri dari sek
|
||||
* **[kubelet](/docs/admin/kubelet/)**, yang menjadi perantara komunikasi dengan *master*.
|
||||
* **[kube-proxy](/docs/admin/kube-proxy/)**, sebuah *proxy* yang merupakan representasi jaringan yang ada pada setiap *node*.
|
||||
|
||||
## Obyek Kubernetes
|
||||
## Objek Kubernetes
|
||||
|
||||
Kubernetes memiliki beberapa abstraksi yang merepresentasikan *state* dari sistem kamu:
|
||||
apa yang aplikasi atau *workload* lain yang ingin kamu jalankan, jaringan atau *resource disk* apa yang ingin
|
||||
kamu sediakan, serta beberapa informasi lain terkait apa yang sedang klaster kamu lakukan.
|
||||
Abstraksi ini direpresentasikan oleh obyek yang tersedia di API Kubernetes;
|
||||
lihat [ikhtisar obyek-obyek Kubernetes](/docs/concepts/abstractions/overview/)
|
||||
Abstraksi ini direpresentasikan oleh objek yang tersedia di API Kubernetes;
|
||||
lihat [ikhtisar objek-objek Kubernetes](/docs/concepts/abstractions/overview/)
|
||||
untuk penjelasan yang lebih mendetail.
|
||||
|
||||
Obyek mendasar Kubernetes termasuk:
|
||||
Objek mendasar Kubernetes termasuk:
|
||||
|
||||
* [Pod](/docs/concepts/workloads/pods/pod-overview/)
|
||||
* [Service](/docs/concepts/services-networking/service/)
|
||||
@@ -55,7 +55,7 @@ Obyek mendasar Kubernetes termasuk:
|
||||
* [Namespace](/docs/concepts/overview/working-with-objects/namespaces/)
|
||||
|
||||
Sebagai tambahan, Kubernetes memiliki beberapa abstraksi yang lebih tinggi yang disebut kontroler.
|
||||
Kontroler merupakan obyek mendasar dengan fungsi tambahan, contoh dari kontroler ini adalah:
|
||||
Kontroler merupakan objek mendasar dengan fungsi tambahan, contoh dari kontroler ini adalah:
|
||||
|
||||
* [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)
|
||||
* [Deployment](/docs/concepts/workloads/controllers/deployment/)
|
||||
@@ -67,14 +67,14 @@ Kontroler merupakan obyek mendasar dengan fungsi tambahan, contoh dari kontroler
|
||||
|
||||
Berbagai bagian *Control Plane* Kubernetes, seperti *master* dan *process-process* kubelet,
|
||||
mengatur bagaimana Kubernetes berkomunikasi dengan klaster kamu. *Control Plane*
|
||||
menjaga seluruh *record* dari obyek Kubernetes serta terus menjalankan
|
||||
iterasi untuk melakukan manajemen *state* obyek. *Control Plane* akan memberikan respon
|
||||
menjaga seluruh *record* dari objek Kubernetes serta terus menjalankan
|
||||
iterasi untuk melakukan manajemen *state* objek. *Control Plane* akan memberikan respon
|
||||
apabila terdapat perubahan pada klaster kamu dan mengubah *state* saat ini agar sesuai
|
||||
dengan *state* yang diinginkan.
|
||||
|
||||
Contohnya, ketika kamu menggunakan API Kubernetes untuk membuat sebuah *Deployment*,
|
||||
kamu memberikan sebuah *state* baru yang harus dipenuhi oleh sistem. *Control Plane*
|
||||
kemudian akan mencatat obyek apa saja yang dibuat, serta menjalankan instruksi yang kamu berikan
|
||||
kemudian akan mencatat objek apa saja yang dibuat, serta menjalankan instruksi yang kamu berikan
|
||||
dengan cara melakukan `start` aplikasi dan melakukan `scheduling` aplikasi tersebut
|
||||
pada *node*, dengan kata lain mengubah *state* saat ini agar sesuai dengan *state* yang diinginkan.
|
||||
|
||||
@@ -92,7 +92,7 @@ kamu berkomunikasi dengan *master* klaster Kubernetes kamu.
|
||||
menjalankan aplikasi kamu. Master mengontrol setiap node; kamu akan jarang berinteraksi
|
||||
dengan *node* secara langsung.
|
||||
|
||||
#### Metadata obyek
|
||||
#### Metadata objek
|
||||
|
||||
|
||||
* [Anotasi](/docs/concepts/overview/working-with-objects/annotations/)
|
||||
|
||||
@@ -255,7 +255,7 @@ Servis _frontend_ akan meliputi kedua set replika dengan menentukan subset bersa
|
||||
tier: frontend
|
||||
```
|
||||
|
||||
Anda dapat mengatur jumlah replika rilis _stable_ dan _canary_ untuk menentukan rasio dari tiap rilis yang akan menerima _traffic production live_ (dalam kasus ini 3:1).
|
||||
Kamu dapat mengatur jumlah replika rilis _stable_ dan _canary_ untuk menentukan rasio dari tiap rilis yang akan menerima _traffic production live_ (dalam kasus ini 3:1).
|
||||
Ketika telah yakin, kamu dapat memindahkan _track stable_ ke rilis baru dan menghapus _canary_.
|
||||
|
||||
Untuk contoh yang lebih jelas, silahkan cek [tutorial melakukan deploy Ghost](https://github.com/kelseyhightower/talks/tree/master/kubecon-eu-2016/demo#deploy-a-canary).
|
||||
@@ -322,7 +322,7 @@ kubectl scale deployment/my-nginx --replicas=1
|
||||
deployment.extensions/my-nginx scaled
|
||||
```
|
||||
|
||||
Sekarang anda hanya memiliki satu _pod_ yang dikelola oleh deployment.
|
||||
Sekarang kamu hanya memiliki satu _pod_ yang dikelola oleh deployment.
|
||||
|
||||
```shell
|
||||
kubectl get pods -l app=nginx
|
||||
|
||||
@@ -0,0 +1,217 @@
|
||||
---
|
||||
title: Bin Packing Sumber Daya untuk Sumber Daya Tambahan
|
||||
content_template: templates/concept
|
||||
weight: 10
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
{{< feature-state for_k8s_version="1.16" state="alpha" >}}
|
||||
|
||||
_Kube-scheduler_ dapat dikonfigurasikan untuk mengaktifkan pembungkusan rapat
|
||||
(_bin packing_) sumber daya bersama dengan sumber daya tambahan melalui fungsi prioritas
|
||||
`RequestedToCapacityRatioResourceAllocation`. Fungsi-fungsi prioritas dapat digunakan
|
||||
untuk menyempurnakan _kube-scheduler_ sesuai dengan kebutuhan.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Mengaktifkan _Bin Packing_ menggunakan RequestedToCapacityRatioResourceAllocation
|
||||
|
||||
Sebelum Kubernetes 1.15, _kube-scheduler_ digunakan untuk memungkinkan mencetak
|
||||
skor berdasarkan rasio permintaan terhadap kapasitas sumber daya utama seperti
|
||||
CPU dan Memori. Kubernetes 1.16 menambahkan parameter baru ke fungsi prioritas
|
||||
yang memungkinkan pengguna untuk menentukan sumber daya beserta dengan bobot
|
||||
untuk setiap sumber daya untuk memberi nilai dari Node berdasarkan rasio
|
||||
permintaan terhadap kapasitas. Hal ini memungkinkan pengguna untuk _bin pack_
|
||||
sumber daya tambahan dengan menggunakan parameter yang sesuai untuk meningkatkan
|
||||
pemanfaatan sumber daya yang langka dalam klaster yang besar. Perilaku
|
||||
`RequestedToCapacityRatioResourceAllocation` dari fungsi prioritas dapat
|
||||
dikontrol melalui pilihan konfigurasi yang disebut ` RequestToCapacityRatioArguments`.
|
||||
Argumen ini terdiri dari dua parameter yaitu `shape` dan `resources`. Shape
|
||||
memungkinkan pengguna untuk menyempurnakan fungsi menjadi yang paling tidak
|
||||
diminta atau paling banyak diminta berdasarkan nilai `utilization` dan `score`.
|
||||
Sumber daya terdiri dari `name` yang menentukan sumber daya mana yang dipertimbangkan
|
||||
selama penilaian dan `weight` yang menentukan bobot masing-masing sumber daya.
|
||||
|
||||
Di bawah ini adalah contoh konfigurasi yang menetapkan `requestedToCapacityRatioArguments`
|
||||
pada perilaku _bin packing_ untuk sumber daya tambahan` intel.com/foo` dan `intel.com/bar`
|
||||
|
||||
```json
|
||||
{
|
||||
"kind" : "Policy",
|
||||
"apiVersion" : "v1",
|
||||
|
||||
...
|
||||
|
||||
"priorities" : [
|
||||
|
||||
...
|
||||
|
||||
{
|
||||
"name": "RequestedToCapacityRatioPriority",
|
||||
"weight": 2,
|
||||
"argument": {
|
||||
"requestedToCapacityRatioArguments": {
|
||||
"shape": [
|
||||
{"utilization": 0, "score": 0},
|
||||
{"utilization": 100, "score": 10}
|
||||
],
|
||||
"resources": [
|
||||
{"name": "intel.com/foo", "weight": 3},
|
||||
{"name": "intel.com/bar", "weight": 5}
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
],
|
||||
}
|
||||
```
|
||||
|
||||
**Fitur ini dinonaktifkan secara _default_**
|
||||
|
||||
### Tuning RequestedToCapacityRatioResourceAllocation Priority Function
|
||||
|
||||
`shape` digunakan untuk menentukan perilaku dari fungsi `RequestedToCapacityRatioPriority`.
|
||||
|
||||
```yaml
|
||||
{"utilization": 0, "score": 0},
|
||||
{"utilization": 100, "score": 10}
|
||||
```
|
||||
|
||||
Argumen di atas memberikan Node nilai 0 jika utilisasi 0% dan 10 untuk utilisasi 100%,
|
||||
yang kemudian mengaktfikan perilaku _bin packing_. Untuk mengaktifkan dari paling
|
||||
yang tidak diminta, nilainya harus dibalik sebagai berikut.
|
||||
|
||||
```yaml
|
||||
{"utilization": 0, "score": 100},
|
||||
{"utilization": 100, "score": 0}
|
||||
```
|
||||
|
||||
`resources` adalah parameter opsional yang secara _default_ diatur ke:
|
||||
|
||||
``` yaml
|
||||
"resources": [
|
||||
{"name": "CPU", "weight": 1},
|
||||
{"name": "Memory", "weight": 1}
|
||||
]
|
||||
```
|
||||
|
||||
Ini dapat digunakan untuk menambahkan sumber daya tambahan sebagai berikut:
|
||||
|
||||
```yaml
|
||||
"resources": [
|
||||
{"name": "intel.com/foo", "weight": 5},
|
||||
{"name": "CPU", "weight": 3},
|
||||
{"name": "Memory", "weight": 1}
|
||||
]
|
||||
```
|
||||
|
||||
Parameter `weight` adalah opsional dan diatur ke 1 jika tidak ditentukan.
|
||||
Selain itu, `weight` tidak dapat diatur ke nilai negatif.
|
||||
|
||||
### Bagaimana Fungsi Prioritas RequestedToCapacityRatioResourceAllocation Menilai Node
|
||||
|
||||
Bagian ini ditujukan bagi kamu yang ingin memahami secara detail internal
|
||||
dari fitur ini.
|
||||
Di bawah ini adalah contoh bagaimana nilai dari Node dihitung untuk satu kumpulan
|
||||
nilai yang diberikan.
|
||||
|
||||
```
|
||||
Sumber daya yang diminta
|
||||
|
||||
intel.com/foo : 2
|
||||
Memory: 256MB
|
||||
CPU: 2
|
||||
|
||||
Bobot dari sumber daya
|
||||
|
||||
intel.com/foo : 5
|
||||
Memory: 1
|
||||
CPU: 3
|
||||
|
||||
FunctionShapePoint {{0, 0}, {100, 10}}
|
||||
|
||||
Spesifikasi dari Node 1
|
||||
|
||||
Tersedia:
|
||||
|
||||
intel.com/foo : 4
|
||||
Memory : 1 GB
|
||||
CPU: 8
|
||||
|
||||
Digunakan:
|
||||
|
||||
intel.com/foo: 1
|
||||
Memory: 256MB
|
||||
CPU: 1
|
||||
|
||||
|
||||
Nilai Node:
|
||||
|
||||
intel.com/foo = resourceScoringFunction((2+1),4)
|
||||
= (100 - ((4-3)*100/4)
|
||||
= (100 - 25)
|
||||
= 75
|
||||
= rawScoringFunction(75)
|
||||
= 7
|
||||
|
||||
Memory = resourceScoringFunction((256+256),1024)
|
||||
= (100 -((1024-512)*100/1024))
|
||||
= 50
|
||||
= rawScoringFunction(50)
|
||||
= 5
|
||||
|
||||
CPU = resourceScoringFunction((2+1),8)
|
||||
= (100 -((8-3)*100/8))
|
||||
= 37.5
|
||||
= rawScoringFunction(37.5)
|
||||
= 3
|
||||
|
||||
NodeScore = (7 * 5) + (5 * 1) + (3 * 3) / (5 + 1 + 3)
|
||||
= 5
|
||||
|
||||
|
||||
Spesifikasi dari Node 2
|
||||
|
||||
Tersedia:
|
||||
|
||||
intel.com/foo: 8
|
||||
Memory: 1GB
|
||||
CPU: 8
|
||||
|
||||
Digunakan:
|
||||
|
||||
intel.com/foo: 2
|
||||
Memory: 512MB
|
||||
CPU: 6
|
||||
|
||||
|
||||
Nilai Node:
|
||||
|
||||
intel.com/foo = resourceScoringFunction((2+2),8)
|
||||
= (100 - ((8-4)*100/8)
|
||||
= (100 - 25)
|
||||
= 50
|
||||
= rawScoringFunction(50)
|
||||
= 5
|
||||
|
||||
Memory = resourceScoringFunction((256+512),1024)
|
||||
= (100 -((1024-768)*100/1024))
|
||||
= 75
|
||||
= rawScoringFunction(75)
|
||||
= 7
|
||||
|
||||
CPU = resourceScoringFunction((2+6),8)
|
||||
= (100 -((8-8)*100/8))
|
||||
= 100
|
||||
= rawScoringFunction(100)
|
||||
= 10
|
||||
|
||||
NodeScore = (5 * 5) + (7 * 1) + (10 * 3) / (5 + 1 + 3)
|
||||
= 7
|
||||
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,160 @@
|
||||
---
|
||||
title: Penyetelan Kinerja Penjadwal
|
||||
content_template: templates/concept
|
||||
weight: 70
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.14" state="beta" >}}
|
||||
|
||||
[kube-scheduler](/docs/concepts/scheduling/kube-scheduler/#kube-scheduler)
|
||||
merupakan penjadwal (_scheduler_) Kubernetes bawaan yang bertanggung jawab
|
||||
terhadap penempatan Pod-Pod pada seluruh Node di dalam sebuah klaster.
|
||||
|
||||
Node-Node di dalam klaster yang sesuai dengan syarat-syarat penjadwalan dari
|
||||
sebuah Pod disebut sebagai Node-Node layak (_feasible_). Penjadwal mencari Node-Node
|
||||
layak untuk sebuah Pod dan kemudian menjalankan fungsi-fungsi untuk menskor Node-Node tersebut, memilih sebuah Node dengan skor tertinggi di antara
|
||||
Node-Node layak lainnya, di mana Pod akan dijalankan. Penjadwal kemudian memberitahu
|
||||
API server soal keputusan ini melalui sebuah proses yang disebut _Binding_.
|
||||
|
||||
Laman ini menjelaskan optimasi penyetelan (_tuning_) kinerja yang relevan
|
||||
untuk klaster Kubernetes berskala besar.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
Pada klaster berskala besar, kamu bisa menyetel perilaku penjadwal
|
||||
untuk menyeimbangkan hasil akhir penjadwalan antara latensi (seberapa cepat Pod-Pod baru ditempatkan)
|
||||
dan akurasi (seberapa akurat penjadwal membuat keputusan penjadwalan yang tepat).
|
||||
|
||||
Kamu bisa mengonfigurasi setelan ini melalui pengaturan `percentageOfNodesToScore` pada kube-scheduler.
|
||||
Pengaturan KubeSchedulerConfiguration ini menentukan sebuah ambang batas untuk
|
||||
penjadwalan Node-Node di dalam klaster kamu.
|
||||
|
||||
### Pengaturan Ambang Batas
|
||||
|
||||
Opsi `percentageOfNodesToScore` menerima semua angka numerik antara 0 dan 100.
|
||||
Angka 0 adalah angka khusus yang menandakan bahwa kube-scheduler harus menggunakan
|
||||
nilai bawaan.
|
||||
Jika kamu mengatur `percentageOfNodesToScore` dengan angka di atas 100, kube-scheduler
|
||||
akan membulatkan ke bawah menjadi 100.
|
||||
|
||||
Untuk mengubah angkanya, sunting berkas konfigurasi kube-scheduler (biasanya `/etc/kubernetes/config/kube-scheduler.yaml`),
|
||||
lalu _ulang kembali_ kube-scheduler.
|
||||
|
||||
Setelah kamu selesai menyunting, jalankan perintah
|
||||
```bash
|
||||
kubectl get componentstatuses
|
||||
```
|
||||
untuk memverifikasi komponen kube-scheduler berjalan dengan baik (_healthy_). Keluarannya kira-kira seperti ini:
|
||||
```
|
||||
NAME STATUS MESSAGE ERROR
|
||||
controller-manager Healthy ok
|
||||
scheduler Healthy ok
|
||||
...
|
||||
```
|
||||
|
||||
## Ambang Batas Penskoran Node {#persentase-penskoran-node}
|
||||
|
||||
Untuk meningkatan kinerja penjadwalan, kube-scheduler dapat berhenti mencari
|
||||
Node-Node yang layak saat sudah berhasil menemukannya. Pada klaster berskala besar,
|
||||
hal ini menghemat waktu dibandingkan dengan pendekatan awam yang mengecek setiap Node.
|
||||
|
||||
Kamu bisa mengatur ambang batas untuk menentukan berapa banyak jumlah Node minimal yang dibutuhkan, sebagai
|
||||
persentase bagian dari seluruh Node di dalam klaster kamu. kube-scheduler akan mengubahnya menjadi
|
||||
bilangan bulat berisi jumlah Node. Saat penjadwalan, jika kube-scheduler mengidentifikasi
|
||||
cukup banyak Node-Node layak untuk melewati jumlah persentase yang diatur, maka kube-scheduler
|
||||
akan berhenti mencari Node-Node layak dan lanjut ke [fase penskoran] (/docs/concepts/scheduling/kube-scheduler/#kube-scheduler-implementation).
|
||||
|
||||
[Bagaimana penjadwal mengecek Node](#bagaimana-penjadwal-mengecek-node) menjelaskan proses ini secara detail.
|
||||
|
||||
### Ambang Batas Bawaan
|
||||
|
||||
Jika kamu tidak mengatur sebuah ambang batas, maka Kubernetes akan
|
||||
menghitung sebuah nilai menggunakan pendekatan linier, yaitu 50% untuk klaster dengan 100 Node,
|
||||
serta 10% untuk klaster dengan 5000 Node.
|
||||
|
||||
Artinya, kube-scheduler selalu menskor paling tidak 5% dari klaster kamu, terlepas dari
|
||||
seberapa besar klasternya, kecuali kamu secara eksplisit mengatur `percentageOfNodesToScore`
|
||||
menjadi lebih kecil dari 5.
|
||||
|
||||
Jika kamu ingin penjadwal untuk memasukkan seluruh Node di dalam klaster ke dalam penskoran,
|
||||
maka aturlah `percentageOfNodesToScore` menjadi 100.
|
||||
|
||||
## Contoh
|
||||
|
||||
Contoh konfigurasi di bawah ini mengatur `percentageOfNodesToScore` menjadi 50%.
|
||||
|
||||
```yaml
|
||||
apiVersion: kubescheduler.config.k8s.io/v1alpha1
|
||||
kind: KubeSchedulerConfiguration
|
||||
algorithmSource:
|
||||
provider: DefaultProvider
|
||||
|
||||
...
|
||||
|
||||
percentageOfNodesToScore: 50
|
||||
```
|
||||
|
||||
|
||||
## Menyetel percentageOfNodesToScore
|
||||
|
||||
`percentageOfNodesToScore` merupakan angka 1 sampai 100 dengan
|
||||
nilai bawaan yang dihitung berdasarkan ukuran klaster. Di sini juga terdapat
|
||||
batas bawah yang telah ditetapkan, yaitu 50 Node.
|
||||
|
||||
{{< note >}}Pada klaster dengan kurang dari 50 Node layak, penjadwal masih
|
||||
terus memeriksa seluruh Node karena Node-Node layak belum mencukupi supaya
|
||||
penjadwal dapat menghentikan proses pencarian lebih awal.
|
||||
|
||||
Pada klaster kecil, jika kamu mengatur `percentageOfNodesToScore` dengan angka kecil,
|
||||
pengaturan ini hampir atau sama sekali tidak berpengaruh, karena alasan yang sama.
|
||||
|
||||
Jika klaster kamu punya ratusan Node, gunakan angka bawaan untuk opsi konfigurasi ini.
|
||||
Mengubah angkanya kemungkinan besar tidak akan mengubah kinerja penjadwal secara berarti.
|
||||
{{< /note >}}
|
||||
|
||||
Sebuah catatan penting yang perlu dipertimbangkan saat mengatur angka ini adalah
|
||||
ketika klaster dengan jumlah Node sedikit diperiksa untuk kelayakan, beberapa Node
|
||||
tidak dikirim untuk diskor bagi sebuah Pod. Hasilnya, sebuah Node yang mungkin memiliki
|
||||
nilai lebih tinggi untuk menjalankan Pod tersebut bisa saja tidak diteruskan ke fase penskoran.
|
||||
Hal ini berdampak pada penempatan Pod yang kurang ideal.
|
||||
|
||||
Kamu sebaiknya menghindari pengaturan `percentageOfNodesToScore` menjadi sangat rendah,
|
||||
agar kube-scheduler tidak seringkali membuat keputusan penempatan Pod yang buruk.
|
||||
Hindari pengaturan persentase di bawah 10%, kecuali _throughput_ penjadwal sangat penting
|
||||
untuk aplikasi kamu dan skor dari Node tidak begitu penting. Dalam kata lain, kamu
|
||||
memilih untuk menjalankan Pod pada Node manapun selama Node tersebut layak.
|
||||
|
||||
## Bagaimana Penjadwal Mengecek Node
|
||||
|
||||
Bagian ini ditujukan untuk kamu yang ingin mengerti bagaimana fitur ini bekerja secara internal.
|
||||
|
||||
Untuk memberikan semua Node di dalam klaster sebuah kesempatan yang adil untuk
|
||||
dipertimbangkan dalam menjalankan Pod, penjadwal mengecek Node satu persatu
|
||||
secara _round robin_. Kamu dapat membayangkan Node-Node ada di dalam sebuah array.
|
||||
Penjadwal mulai dari indeks array pertama dan mengecek kelayakan dari Node sampai
|
||||
jumlahnya telah mencukupi sesuai dengan `percentageOfNodesToScore`. Untuk Pod berikutnya,
|
||||
penjadwal melanjutkan dari indeks array Node yang terhenti ketika memeriksa
|
||||
kelayakan Node-Node untuk Pod sebelumnya.
|
||||
|
||||
Jika Node-Node berada di beberapa zona, maka penjadwal akan mengecek Node satu persatu
|
||||
pada seluruh zona untuk memastikan bahwa Node-Node dari zona berbeda masuk dalam pertimbangan
|
||||
kelayakan. Sebagai contoh, ada 6 Node di dalam 2 zona:
|
||||
|
||||
```
|
||||
Zona 1: Node 1, Node 2, Node 3, Node 4
|
||||
Zona 2: Node 5, Node 6
|
||||
```
|
||||
|
||||
Penjadwal mempertimbangkan kelayakan dari Node-Node tersebut dengan urutan berikut:
|
||||
|
||||
```
|
||||
Node 1, Node 5, Node 2, Node 6, Node 3, Node 4
|
||||
```
|
||||
|
||||
Setelah semua Node telah dicek, penjadwal akan kembali pada Node 1.
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,249 @@
|
||||
---
|
||||
title: Kerangka Kerja Penjadwalan (Scheduling Framework)
|
||||
content_template: templates/concept
|
||||
weight: 60
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
{{< feature-state for_k8s_version="1.15" state="alpha" >}}
|
||||
|
||||
Kerangka kerja penjadwalan (_Scheduling Framework_) adalah arsitektur yang dapat
|
||||
dipasang (_pluggable_) pada penjadwal Kubernetes untuk membuat kustomisasi
|
||||
penjadwal lebih mudah. Hal itu dilakukan dengan menambahkan satu kumpulan "plugin"
|
||||
API ke penjadwal yang telah ada. _Plugin_ dikompilasi ke dalam penjadwal.
|
||||
Beberapa API memungkinkan sebagian besar fitur penjadwalan diimplementasikan
|
||||
sebagai _plugin_, sambil tetap mempertahankan penjadwalan "inti" sederhana dan
|
||||
terpelihara. Silahkan merujuk pada [proposal desain dari kerangka penjadwalan]
|
||||
[kep] untuk informasi teknis lebih lanjut tentang desain kerangka kerja
|
||||
tersebut.
|
||||
|
||||
[kep]: https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20180409-scheduling-framework.md
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
# Alur kerja kerangka kerja
|
||||
|
||||
Kerangka kerja penjadwalan mendefinisikan beberapa titik ekstensi. _Plugin_ penjadwal
|
||||
mendaftar untuk dipanggil di satu atau lebih titik ekstensi. Beberapa _plugin_ ini
|
||||
dapat mengubah keputusan penjadwalan dan beberapa hanya bersifat informasi.
|
||||
|
||||
Setiap upaya untuk menjadwalkan satu Pod dibagi menjadi dua fase, **Siklus Penjadwalan (_Scheduling Cycle_)** dan **Siklus Pengikatan (_Binding Cycle_)**.
|
||||
|
||||
## Siklus Penjadwalan dan Siklus Pengikatan
|
||||
|
||||
Siklus penjadwalan memilih sebuah Node untuk Pod, dan siklus pengikatan menerapkan
|
||||
keputusan tersebut ke klaster. Secara bersama-sama, siklus penjadwalan dan siklus
|
||||
pengikatan diartikan sebagai sebuah "konteks penjadwalan (_scheduling context_)".
|
||||
|
||||
Siklus penjadwalan dijalankan secara serial, sementara siklus pengikatan dapat
|
||||
berjalan secara bersamaan.
|
||||
|
||||
Siklus penjadwalan atau pengikatan dapat dibatalkan jika Pod telah ditentukan
|
||||
untuk tidak terjadwalkan atau jika terdapat kesalahan internal. Pod akan
|
||||
dikembalikan ke antrian dan dicoba lagi.
|
||||
|
||||
## Titik-titik ekstensi
|
||||
|
||||
Gambar berikut menunjukkan konteks penjadwalan Pod dan titik-titik ekstensi
|
||||
yang diperlihatkan oleh kerangka penjadwalan. Dalam gambar ini "Filter"
|
||||
setara dengan "Predicate" dan "Scoring" setara dengan "Priority Function".
|
||||
|
||||
Satu _plugin_ dapat mendaftar di beberapa titik ekstensi untuk melakukan pekerjaan
|
||||
yang lebih kompleks atau _stateful_.
|
||||
|
||||
{{< figure src="/images/docs/scheduling-framework-extensions.png" title="Titik-titik ekstensi dari kerangka kerja Penjadwalan" >}}
|
||||
|
||||
### QueueSort {#queue-sort}
|
||||
|
||||
_Plugin_ ini digunakan untuk mengurutkan Pod-Pod dalam antrian penjadwalan. _Plugin_
|
||||
QueueSort pada dasarnya menyediakan fungsi `Less (Pod1, Pod2)`. Hanya satu jenis
|
||||
_plugin_ QueueSort yang dapat diaktifkan dalam waktu yang bersamaan.
|
||||
|
||||
### PreFilter {#pre-filter}
|
||||
|
||||
_Plugin_ ini digunakan untuk melakukan pra-proses informasi tentang Pod, atau untuk
|
||||
memeriksa tertentu kondisi yang harus dipenuhi oleh klaster atau Pod. Jika
|
||||
_plugin_ PreFilter menghasilkan hasil yang salah, siklus penjadwalan dibatalkan.
|
||||
|
||||
### Filter
|
||||
|
||||
_Plugin_ ini digunakan untuk menyaring Node yang tidak dapat menjalankan Pod.
|
||||
Untuk setiap Node, penjadwal akan memanggil _plugin_ Filter sesuai dengan urutan
|
||||
mereka dikonfigurasi. Jika ada _plugin_ Filter menandai Node menjadi _infeasible_,
|
||||
maka _plugin_ yang lainnya tidak akan dipanggil untuk Node itu. Node-Node dapat dievaluasi
|
||||
secara bersamaan.
|
||||
|
||||
### PreScore {#pre-score}
|
||||
|
||||
_Plugin_ ini digunakan untuk melakukan pekerjaan "pra-penilaian", yang
|
||||
menghasilkan keadaan yang dapat dibagi untuk digunakan oleh _plugin-plugin_ Score.
|
||||
Jika _plugin_ PreScore mengeluarkan hasil salah, maka siklus penjadwalan dibatalkan.
|
||||
|
||||
### Score {#score}
|
||||
|
||||
_Plugin_ ini digunakan untuk menentukan peringkat Node yang telah melewati fase
|
||||
penyaringan. Penjadwal akan memanggil setiap _plugin_ Score untuk setiap Node.
|
||||
Akan ada kisaran bilangan bulat yang telah ditetapkan untuk mewakili skor
|
||||
minimum dan maksimum. Setelah fase [NormalizeScore](#normalize-scoring),
|
||||
penjadwal akan menggabungkan skor Node dari semua _plugin_ sesuai dengan bobot
|
||||
_plugin_ yang telah dikonfigurasi.
|
||||
|
||||
### NormalizeScore {#normalize-score}
|
||||
|
||||
_Plugin_ ini digunakan untuk memodifikasi skor sebelum penjadwal menghitung
|
||||
peringkat akhir Node-Node. _Plugin_ yang mendaftar untuk titik ekstensi ini akan
|
||||
dipanggil dengan hasil [Score](#score) dari _plugin_ yang sama. Hal ini dilakukan
|
||||
sekali untuk setiap _plugin_ dan setiap siklus penjadwalan.
|
||||
|
||||
Sebagai contoh, anggaplah sebuah _plugin_ `BlinkingLightScorer` memberi peringkat
|
||||
pada Node-Node berdasarkan berapa banyak kedipan lampu yang mereka miliki.
|
||||
|
||||
```go
|
||||
func ScoreNode(_ *v1.pod, n *v1.Node) (int, error) {
|
||||
return getBlinkingLightCount(n)
|
||||
}
|
||||
```
|
||||
|
||||
Namun, jumlah maksimum kedipan lampu mungkin kecil jika dibandingkan dengan
|
||||
`NodeScoreMax`. Untuk memperbaikinya, `BlinkingLightScorer` juga harus mendaftar
|
||||
untuk titik ekstensi ini.
|
||||
|
||||
```go
|
||||
func NormalizeScores(scores map[string]int) {
|
||||
highest := 0
|
||||
for _, score := range scores {
|
||||
highest = max(highest, score)
|
||||
}
|
||||
for node, score := range scores {
|
||||
scores[node] = score*NodeScoreMax/highest
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Jika ada _plugin_ NormalizeScore yang menghasilkan hasil yang salah, maka siklus
|
||||
penjadwalan dibatalkan.
|
||||
|
||||
{{< note >}}
|
||||
_Plugin_ yang ingin melakukan pekerjaan "pra-pemesanan" harus menggunakan
|
||||
titik ekstensi NormalizeScore.
|
||||
{{< /note >}}
|
||||
|
||||
### Reserve
|
||||
|
||||
Ini adalah titik ekstensi yang bersifat informasi. _Plugin_ yang mempertahankan
|
||||
keadaan _runtime_ (alias "_stateful plugins_") harus menggunakan titik ekstensi ini
|
||||
untuk diberitahukan oleh penjadwal ketika sumber daya pada suatu Node dicadangkan
|
||||
untuk Pod yang telah disiapkan. Proses ini terjadi sebelum penjadwal benar-benar
|
||||
mengikat Pod ke Node, dan itu ada untuk mencegah kondisi balapan (_race conditions_)
|
||||
ketika penjadwal menunggu agar pengikatan berhasil.
|
||||
|
||||
Ini adalah langkah terakhir dalam siklus penjadwalan. Setelah Pod berada dalam
|
||||
status dicadangkan, maka itu akan memicu _plugin_ [Unreserve](#unreserve)
|
||||
(apabila gagal) atau _plugin_ [PostBind](#post-bind) (apabila sukses)
|
||||
di akhir siklus pengikatan.
|
||||
|
||||
### Permit
|
||||
|
||||
_Plugin_ Permit dipanggil pada akhir siklus penjadwalan untuk setiap Pod
|
||||
untuk mencegah atau menunda pengikatan ke Node kandidat. _Plugin_ Permit dapat
|
||||
melakukan salah satu dari ketiga hal ini:
|
||||
|
||||
1. **approve** \
|
||||
Setelah semua _plugin_ Permit menyetujui sebuah Pod, Pod tersebut akan dikirimkan untuk diikat.
|
||||
|
||||
2. **deny** \
|
||||
Jika ada _plugin_ Permit yang menolak sebuah Pod, Pod tersebut akan dikembalikan ke
|
||||
antrian penjadwalan. Hal ini akan memicu _plugin_ [Unreserve](#unreserve).
|
||||
|
||||
3. **wait** (dengan batas waktu) \
|
||||
Jika _plugin_ Permit menghasilkan "wait", maka Pod disimpan dalam
|
||||
daftar Pod "yang menunggu" internal, dan siklus pengikatan Pod ini dimulai tetapi akan langsung diblokir
|
||||
sampai mendapatkan [_approved_](#frameworkhandle). Jika waktu tunggu habis, ** wait ** menjadi ** deny **
|
||||
dan Pod dikembalikan ke antrian penjadwalan, yang memicu _plugin_ [Unreserve](#unreserve).
|
||||
|
||||
{{< note >}}
|
||||
Ketika setiap _plugin_ dapat mengakses daftar Pod-Pod "yang menunggu" dan menyetujuinya
|
||||
(silahkan lihat [`FrameworkHandle`](#frameworkhandle)), kami hanya mengharapkan
|
||||
_plugin_ Permit untuk menyetujui pengikatan Pod dalam kondisi "menunggu" yang
|
||||
telah dipesan. Setelah Pod disetujui, akan dikirim ke fase [PreBind](#pre-bind).
|
||||
{{< /note >}}
|
||||
|
||||
### PreBind {#pre-bind}
|
||||
|
||||
_Plugin_ ini digunakan untuk melakukan pekerjaan apa pun yang diperlukan sebelum
|
||||
Pod terikat. Sebagai contoh, _plugin_ PreBind dapat menyediakan _network volume_
|
||||
dan melakukan _mounting_ pada Node target sebelum mengizinkan Pod berjalan di
|
||||
sana.
|
||||
|
||||
Jika ada _plugin_ PreBind yang menghasilkan kesalahan, maka Pod [ditolak](#unreserve)
|
||||
dan kembali ke antrian penjadwalan.
|
||||
|
||||
### Bind
|
||||
|
||||
_Plugin_ ini digunakan untuk mengikat Pod ke Node. _Plugin-plugin_ Bind tidak akan
|
||||
dipanggil sampai semua _plugin_ PreBind selesai. Setiap _plugin_ Bind dipanggil
|
||||
sesuai urutan saat dikonfigurasi. _Plugin_ Bind dapat memilih untuk menangani
|
||||
atau tidak Pod yang diberikan. Jika _plugin_ Bind memilih untuk menangani Pod,
|
||||
** _plugin_ Bind yang tersisa dilewati **.
|
||||
|
||||
### PostBind {#post-bind}
|
||||
|
||||
Ini adalah titik ekstensi bersifat informasi. _Plugin-plugin_ PostBind dipanggil
|
||||
setelah sebuah Pod berhasil diikat. Ini adalah akhir dari siklus pengikatan, dan
|
||||
dapat digunakan untuk membersihkan sumber daya terkait.
|
||||
|
||||
### Unreserve
|
||||
|
||||
Ini adalah titik ekstensi bersifat informasi. Jika sebuah Pod telah dipesan dan
|
||||
kemudian ditolak di tahap selanjutnya, maka _plugin-plugin_ Unreserve akan
|
||||
diberitahu. _Plugin_ Unreserve harus membersihkan status yang terkait dengan Pod
|
||||
yang dipesan.
|
||||
|
||||
_Plugin_ yang menggunakan titik ekstensi ini sebaiknya juga harus digunakan
|
||||
[Reserve](#unreserve).
|
||||
|
||||
## _Plugin_ API
|
||||
|
||||
Ada dua langkah untuk _plugin_ API. Pertama, _plugin_ harus mendaftar dan mendapatkan
|
||||
konfigurasi, kemudian mereka menggunakan antarmuka titik ekstensi. Antarmuka (_interface_)
|
||||
titik ekstensi memiliki bentuk sebagai berikut.
|
||||
|
||||
```go
|
||||
type Plugin interface {
|
||||
Name() string
|
||||
}
|
||||
|
||||
type QueueSortPlugin interface {
|
||||
Plugin
|
||||
Less(*v1.pod, *v1.pod) bool
|
||||
}
|
||||
|
||||
type PreFilterPlugin interface {
|
||||
Plugin
|
||||
PreFilter(context.Context, *framework.CycleState, *v1.pod) error
|
||||
}
|
||||
|
||||
// ...
|
||||
```
|
||||
|
||||
## Konfigurasi _plugin_
|
||||
|
||||
Kamu dapat mengaktifkan atau menonaktifkan _plugin_ dalam konfigurasi penjadwal.
|
||||
Jika kamu menggunakan Kubernetes v1.18 atau yang lebih baru, kebanyakan
|
||||
[plugin-plugin penjadwalan](/docs/reference/scheduling/profiles/#scheduling-plugins)
|
||||
sudah digunakan dan diaktifkan secara bawaan.
|
||||
|
||||
Selain _plugin-plugin_ bawaan, kamu juga dapat mengimplementasikan _plugin-plugin_ penjadwalan
|
||||
kamu sendiri dan mengonfigurasinya bersama-sama dengan _plugin-plugin_ bawaan.
|
||||
Kamu bisa mengunjungi [plugin-plugin penjadwalan](https://github.com/kubernetes-sigs/scheduler-plugins)
|
||||
untuk informasi lebih lanjut.
|
||||
|
||||
Jika kamu menggunakan Kubernetes v1.18 atau yang lebih baru, kamu dapat
|
||||
mengonfigurasi sekumpulan _plugin_ sebagai profil penjadwal dan kemudian menetapkan
|
||||
beberapa profil agar sesuai dengan berbagai jenis beban kerja. Pelajari lebih
|
||||
lanjut di [multi profil](/docs/reference/scheduling/profiles/#multiple-profiles).
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Ikhtisar Keamanan _Cloud Native_
|
||||
title: Ikhtisar Keamanan Cloud Native
|
||||
content_template: templates/concept
|
||||
weight: 1
|
||||
---
|
||||
|
||||
@@ -0,0 +1,140 @@
|
||||
---
|
||||
title: Dual-stack IPv4/IPv6
|
||||
feature:
|
||||
title: Dual-stack IPv4/IPv6
|
||||
description: >
|
||||
Pengalokasian alamat IPv4 dan IPv6 untuk Pod dan Service
|
||||
|
||||
content_template: templates/concept
|
||||
weight: 70
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
|
||||
|
||||
_Dual-stack_ IPv4/IPv6 memungkinkan pengalokasian alamat IPv4 dan IPv6 untuk
|
||||
{{< glossary_tooltip text="Pod" term_id="pod" >}} dan {{< glossary_tooltip text="Service" term_id="service" >}}.
|
||||
|
||||
Jika kamu mengaktifkan jaringan _dual-stack_ IPv4/IPv6 untuk klaster Kubernetes
|
||||
kamu, klaster akan mendukung pengalokasian kedua alamat IPv4 dan IPv6 secara
|
||||
bersamaan.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Fitur-fitur yang didukung
|
||||
|
||||
Mengaktifkan _dual-stack_ IPv4 / IPv6 pada klaster Kubernetes kamu untuk
|
||||
menyediakan fitur-fitur berikut ini:
|
||||
|
||||
* Jaringan Pod _dual-stack_ (pengalokasian sebuah alamat IPv4 dan IPv6 untuk setiap Pod)
|
||||
* Service yang mendukung IPv4 dan IPv6 (setiap Service hanya untuk satu keluarga alamat)
|
||||
* Perutean Pod ke luar klaster (misalnya Internet) melalui antarmuka IPv4 dan IPv6
|
||||
|
||||
## Prasyarat
|
||||
|
||||
Prasyarat berikut diperlukan untuk menggunakan _dual-stack_ IPv4/IPv6 pada
|
||||
klaster Kubernetes :
|
||||
|
||||
* Kubernetes versi 1.16 atau yang lebih baru
|
||||
* Dukungan dari penyedia layanan untuk jaringan _dual-stack_ (Penyedia layanan _cloud_ atau yang lainnya harus dapat menyediakan antarmuka jaringan IPv4/IPv6 yang dapat dirutekan) untuk Node Kubernetes
|
||||
* Sebuah _plugin_ jaringan yang mendukung _dual-stack_ (seperti Kubenet atau Calico)
|
||||
* Kube-proxy yang berjalan dalam mode IPVS
|
||||
|
||||
## Mengaktifkan _dual-stack_ IPv4/IPv6
|
||||
|
||||
Untuk mengaktifkan _dual-stack_ IPv4/IPv6, aktifkan [gerbang fitur (_feature gate_)](/docs/reference/command-line-tools-reference/feature-gates/) `IPv6DualStack`
|
||||
untuk komponen-komponen yang relevan dari klaster kamu, dan tetapkan jaringan
|
||||
_dual-stack_ pada klaster:
|
||||
|
||||
* kube-controller-manager:
|
||||
* `--feature-gates="IPv6DualStack=true"`
|
||||
* `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>` misalnya `--cluster-cidr=10.244.0.0/16,fc00::/24`
|
||||
* `--service-cluster-ip-range=<IPv4 CIDR>,<IPv6 CIDR>`
|
||||
* `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` nilai bawaannya adalah /24
|
||||
untuk IPv4 dan /64 untuk IPv6
|
||||
* kubelet:
|
||||
* `--feature-gates="IPv6DualStack=true"`
|
||||
* kube-proxy:
|
||||
* `--proxy-mode=ipvs`
|
||||
* `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>`
|
||||
* `--feature-gates="IPv6DualStack=true"`
|
||||
|
||||
{{< caution >}}
|
||||
Jika kamu menentukan blok alamat IPv6 yang lebih besar dari /24 melalui
|
||||
`--cluster-cidr` pada baris perintah, maka penetapan tersebut akan gagal.
|
||||
{{< /caution >}}
|
||||
|
||||
## Service
|
||||
|
||||
Jika klaster kamu mengaktifkan jaringan _dual-stack_ IPv4/IPv6, maka kamu dapat
|
||||
membuat {{<glossary_tooltip text ="Service" term_id ="service">}} dengan
|
||||
alamat IPv4 atau IPv6. Kamu dapat memilih keluarga alamat untuk clusterIP
|
||||
Service kamu dengan mengatur bagian, `.spec.ipFamily`, pada Service tersebut.
|
||||
Kamu hanya dapat mengatur bagian ini saat membuat Service baru. Mengatur bagian
|
||||
`.spec.ipFamily` bersifat opsional dan hanya boleh digunakan jika kamu berencana
|
||||
untuk mengaktifkan {{<glossary_tooltip text ="Service "term_id ="service">}}
|
||||
dan {{<glossary_tooltip text ="Ingress "term_id ="ingress">}} IPv4 dan IPv6
|
||||
pada klaster kamu. Konfigurasi bagian ini bukanlah syarat untuk lalu lintas
|
||||
[_egress_] (#lalu-lintas-egress).
|
||||
|
||||
{{< note >}}
|
||||
Keluarga alamat bawaan untuk klaster kamu adalah keluarga alamat dari rentang
|
||||
clusterIP Service pertama yang dikonfigurasi melalui opsi
|
||||
`--service-cluster-ip-range` pada kube-controller-manager.
|
||||
{{< /note >}}
|
||||
|
||||
Kamu dapat mengatur `.spec.ipFamily` menjadi salah satu dari:
|
||||
|
||||
* `IPv4`: Dimana server API akan mengalokasikan IP dari `service-cluster-ip-range` yaitu `ipv4`
|
||||
* `IPv6`: Dimana server API akan mengalokasikan IP dari `service-cluster-ip-range` yaitu `ipv6`
|
||||
|
||||
Spesifikasi Service berikut ini tidak memasukkan bagian `ipFamily`.
|
||||
Kubernetes akan mengalokasikan alamat IP (atau yang dikenal juga sebagai
|
||||
"_cluster IP_") dari `service-cluster-ip-range` yang dikonfigurasi pertama kali
|
||||
untuk Service ini.
|
||||
|
||||
{{< codenew file="service/networking/dual-stack-default-svc.yaml" >}}
|
||||
|
||||
Spesifikasi Service berikut memasukkan bagian `ipFamily`. Sehingga Kubernetes
|
||||
akan mengalokasikan alamat IPv6 (atau yang dikenal juga sebagai "_cluster IP_")
|
||||
dari `service-cluster-ip-range` yang dikonfigurasi untuk Service ini.
|
||||
|
||||
{{< codenew file="service/networking/dual-stack-ipv6-svc.yaml" >}}
|
||||
|
||||
Sebagai perbandingan, spesifikasi Service berikut ini akan dialokasikan sebuah alamat
|
||||
IPv4 (atau yang dikenal juga sebagai "_cluster IP_") dari `service-cluster-ip-range`
|
||||
yang dikonfigurasi untuk Service ini.
|
||||
|
||||
{{< codenew file="service/networking/dual-stack-ipv4-svc.yaml" >}}
|
||||
|
||||
### Tipe _LoadBalancer_
|
||||
|
||||
Penyedia layanan _cloud_ yang mendukung IPv6 untuk pengaturan beban eksternal,
|
||||
Mengatur bagian `type` menjadi` LoadBalancer` sebagai tambahan terhadap mengatur bagian
|
||||
`ipFamily` menjadi `IPv6` menyediakan sebuah _cloud load balancer_ untuk Service kamu.
|
||||
|
||||
## Lalu lintas _egress_
|
||||
|
||||
Penggunaan blok alamat IPv6 yang dapat dirutekan dan yang tidak dapat dirutekan
|
||||
secara publik diperbolehkan selama {{<glossary_tooltip text="CNI" term_id= "cni">}}
|
||||
dari penyedia layanan dapat mengimplementasikan transportasinya. Jika kamu memiliki
|
||||
Pod yang menggunakan IPv6 yang dapat dirutekan secara publik dan ingin agar Pod
|
||||
mencapai tujuan di luar klaster (misalnya Internet publik), kamu harus mengatur
|
||||
IP samaran untuk lalu lintas keluar dan balasannya. [_ip-masq-agent_](https://github.com/kubernetes-incubator/ip-masq-agent)
|
||||
bersifat _dual-stack aware_, jadi kamu bisa menggunakan ip-masq-agent untuk
|
||||
_masquerading_ IP dari klaster _dual-stack_.
|
||||
|
||||
## Masalah-masalah yang diketahui
|
||||
|
||||
* Kubenet memaksa pelaporan posisi IP untuk IPv4,IPv6 IP (--cluster-cidr)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* [Validasi jaringan _dual-stack_ IPv4/IPv6](/docs/tasks/network/validate-dual-stack)
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,184 @@
|
||||
---
|
||||
title: EndpointSlice
|
||||
feature:
|
||||
title: EndpointSlice
|
||||
description: >
|
||||
Pelacakan _endpoint_ jaringan yang dapat diskalakan pada klaster Kubernetes.
|
||||
|
||||
content_template: templates/concept
|
||||
weight: 15
|
||||
---
|
||||
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.17" state="beta" >}}
|
||||
|
||||
EndpointSlice menyediakan sebuah cara yang mudah untuk melacak _endpoint_ jaringan dalam sebuah
|
||||
klaster Kubernetes. EndpointSlice memberikan alternatif yang lebih _scalable_ dan lebih dapat diperluas dibandingkan dengan Endpoints.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Motivasi
|
||||
|
||||
Endpoints API telah menyediakan sebuah cara yang mudah dan sederhana untuk
|
||||
melacak _endpoint_ jaringan pada Kubernetes. Sayangnya, seiring dengan besarnya klaster Kubernetes
|
||||
dan Service, batasan-batasan yang dimiliki API tersebut semakin terlihat.
|
||||
Terutama, hal tersebut termasuk kendala-kendala mengenai proses _scaling_ _endpoint_ jaringan
|
||||
dalam jumlah yang besar.
|
||||
|
||||
Karena semua _endpoint_ jaringan untuk sebuah Service disimpan dalam satu sumber daya
|
||||
Endpoints, sumber daya tersebut dapat menjadi cukup besar. Hal itu dapat mempengaruhi kinerja
|
||||
dari komponen-komponen Kubernetes (terutama _master control plane_) dan menyebabkan
|
||||
lalu lintas jaringan dan pemrosesan yang cukup besar ketika Endpoints berubah.
|
||||
EndpointSlice membantu kamu menghindari masalah-masalah tersebut dan juga menyediakan platform
|
||||
yang dapat diperluas untuk fitur-fitur tambahan seperti _topological routing_.
|
||||
|
||||
## Sumber daya EndpointSlice
|
||||
|
||||
Pada Kubernetes, sebuah EndpointSlice memiliki referensi-referensi terhadap sekumpulan _endpoint_
|
||||
jaringan. _Controller_ EndpointSlice secara otomatis membuat EndpointSlice
|
||||
untuk sebuah Service Kubernetes ketika sebuah {{< glossary_tooltip text="selektor"
|
||||
term_id="selector" >}} dituliskan. EndpointSlice tersebut akan memiliki
|
||||
referensi-referensi menuju Pod manapun yang cocok dengan selektor pada Service tersebut. EndpointSlice mengelompokkan
|
||||
_endpoint_ jaringan berdasarkan kombinasi Service dan Port yang unik.
|
||||
Nama dari sebuah objek EndpointSlice haruslah berupa
|
||||
[nama subdomain DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) yang sah.
|
||||
|
||||
Sebagai contoh, berikut merupakan sampel sumber daya EndpointSlice untuk sebuah Service Kubernetes
|
||||
yang bernama `example`.
|
||||
|
||||
```yaml
|
||||
apiVersion: discovery.k8s.io/v1beta1
|
||||
kind: EndpointSlice
|
||||
metadata:
|
||||
name: example-abc
|
||||
labels:
|
||||
kubernetes.io/service-name: example
|
||||
addressType: IPv4
|
||||
ports:
|
||||
- name: http
|
||||
protocol: TCP
|
||||
port: 80
|
||||
endpoints:
|
||||
- addresses:
|
||||
- "10.1.2.3"
|
||||
conditions:
|
||||
ready: true
|
||||
hostname: pod-1
|
||||
topology:
|
||||
kubernetes.io/hostname: node-1
|
||||
topology.kubernetes.io/zone: us-west2-a
|
||||
```
|
||||
|
||||
Secara bawaan, setiap EndpointSlice yang dikelola oleh _controller_ EndpointSlice tidak akan memiliki
|
||||
lebih dari 100 _endpoint_. Di bawah skala tersebut, EndpointSlice akan memetakan 1:1
|
||||
dengan Endpoints dan Service dan akan memiliki kinerja yang sama.
|
||||
|
||||
EndpointSlice dapat bertindak sebagai sumber kebenaran untuk kube-proxy sebagai acuan mengenai
|
||||
bagaimana cara untuk merutekan lalu lintas jaringan internal. Ketika diaktifkan, EndpointSlice semestinya memberikan peningkatan
|
||||
kinerja untuk Service yang memiliki Endpoints dalam jumlah besar.
|
||||
|
||||
### Tipe-tipe Alamat
|
||||
|
||||
EndpointSlice mendukung tiga tipe alamat:
|
||||
|
||||
* IPv4
|
||||
* IPv6
|
||||
* FQDN (_Fully Qualified Domain Name_)
|
||||
|
||||
### Topologi
|
||||
|
||||
Setiap _endpoint_ pada EndpointSlice dapat memiliki informasi topologi yang relevan.
|
||||
Hal ini digunakan untuk mengindikasikan di mana _endpoint_ berada, berisi informasi mengenai
|
||||
Node yang bersangkutan, zona, dan wilayah. Ketika nilai-nilai tersebut tersedia,
|
||||
label-label Topology berikut akan ditambahkan oleh _controller_ EndpointSlice:
|
||||
|
||||
* `kubernetes.io/hostname` - Nama dari Node tempat _endpoint_ berada.
|
||||
* `topology.kubernetes.io/zone` - Zona tempat _endpoint_ berada.
|
||||
* `topology.kubernetes.io/region` - Region tempat _endpoint_ berada.
|
||||
|
||||
Nilai-nilai dari label-label berikut berasal dari sumber daya yang diasosiasikan dengan tiap
|
||||
_endpoint_ pada sebuah _slice_. Label _hostname_ merepresentasikan nilai dari kolom NodeName
|
||||
pada Pod yang bersangkutan. Label zona dan wilayah merepresentasikan nilai
|
||||
dari label-label dengan nama yang sama pada Node yang bersangkutan.
|
||||
|
||||
### Pengelolaan
|
||||
|
||||
Secara bawaan, EndpointSlice dibuat dan dikelola oleh _controller_
|
||||
EndpointSlice. Ada berbagai macam kasus lain untuk EndpointSlice, seperti
|
||||
implementasi _service mesh_, yang memungkinkan adanya entitas atau _controller_ lain
|
||||
yang dapat mengelola beberapa EndpointSlice sekaligus. Untuk memastikan beberapa entitas dapat
|
||||
mengelola EndpointSlice tanpa mengganggu satu sama lain, sebuah
|
||||
label `endpointslice.kubernetes.io/managed-by` digunakan untuk mengindikasikan entitas
|
||||
yang mengelola sebuah EndpointSlice. _Controller_ EndpointSlice akan menambahkan
|
||||
`endpointslice-controller.k8s.io` sebagai nilai dari label tersebut pada seluruh
|
||||
EndpointSlice yang dikelolanya. Entitas lain yang mengelola EndpointSlice juga diharuskan untuk
|
||||
menambahkan nilai yang unik untuk label tersebut.
|
||||
|
||||
### Kepemilikan
|
||||
|
||||
Pada kebanyakan kasus, EndpointSlice akan dimiliki oleh Service yang diikutinya. Hal ini diindikasikan dengan referensi pemilik pada tiap EndpointSlice dan
|
||||
juga label `kubernetes.io/service-name` yang memudahkan pencarian seluruh
|
||||
EndpointSlice yang dimiliki oleh sebuah Service.
|
||||
|
||||
## _Controller_ EndpointSlice
|
||||
|
||||
_Controller_ EndpointSlice mengamati Service dan Pod untuk memastikan EndpointSlice
|
||||
yang bersangkutan berada dalam kondisi terkini. _Controller_ EndpointSlice akan mengelola EndpointSlice untuk
|
||||
setiap Service yang memiliki selektor. Ini akan merepresentasikan IP dari Pod
|
||||
yang cocok dengan selektor dari Service tersebut.
|
||||
|
||||
### Ukuran EndpointSlice
|
||||
|
||||
Secara bawaan, jumlah _endpoint_ yang dapat dimiliki tiap EndpointSlice dibatasi sebanyak 100 _endpoint_. Kamu dapat
|
||||
mengaturnya melalui opsi `--max-endpoints-per-slice` {{< glossary_tooltip
|
||||
text="kube-controller-manager" term_id="kube-controller-manager" >}} sampai dengan
|
||||
jumlah maksimum sebanyak 1000 _endpoint_.
|
||||
|
||||
### Distribusi EndpointSlice
|
||||
|
||||
Tiap EndpointSlice memiliki sekumpulan _port_ yang berlaku untuk seluruh _endpoint_ dalam sebuah sumber daya. Ketika nama _port_ digunakan untuk sebuah Service, Pod mungkin mendapatkan
|
||||
nomor target _port_ yang berbeda-beda untuk nama _port_ yang sama, sehingga membutuhkan
|
||||
EndpointSlice yang berbeda. Hal ini mirip dengan logika mengenai bagaimana _subset_ dikelompokkan
|
||||
dengan Endpoints.
|
||||
|
||||
_Controller EndpointSlice_ akan mencoba untuk mengisi EndpointSlice sebanyak mungkin, tetapi tidak
|
||||
secara aktif melakukan _rebalance_ terhadap EndpointSlice tersebut. Logika dari _controller_ cukup sederhana:
|
||||
|
||||
1. Melakukan iterasi terhadap EndpointSlice yang sudah ada, menghapus _endpoint_ yang sudah tidak lagi
|
||||
dibutuhkan dan memperbarui _endpoint_ yang sesuai yang mungkin telah berubah.
|
||||
2. Melakukan iterasi terhadap EndpointSlice yang sudah dimodifikasi pada langkah pertama dan
|
||||
mengisinya dengan _endpoint_ baru yang dibutuhkan.
|
||||
3. Jika masih tersisa _endpoint_ baru untuk ditambahkan, mencoba untuk menambahkannya pada
|
||||
_slice_ yang tidak berubah sebelumnya dan/atau membuat _slice_ yang baru.
|
||||
|
||||
Terlebih penting, langkah ketiga memprioritaskan untuk membatasi pembaruan EndpointSlice terhadap
|
||||
distribusi dari EndpointSlice yang benar-benar penuh. Sebagai contoh, jika ada 10
|
||||
_endpoint_ baru untuk ditambahkan dan ada 2 EndpointSlice yang masing-masing memiliki ruang untuk 5 _endpoint_ baru,
|
||||
pendekatan ini akan membuat sebuah EndpointSlice baru daripada mengisi 2
|
||||
EndpointSlice yang sudah ada. Dengan kata lain, pembuatan sebuah EndpointSlice
|
||||
lebih diutamakan daripada pembaruan beberapa EndpointSlice.
|
||||
|
||||
Dengan kube-proxy yang berjalan pada tiap Node dan mengamati EndpointSlice, setiap perubahan
|
||||
pada sebuah EndpointSlice menjadi sangat mahal karena hal tersebut akan dikirimkan ke
|
||||
setiap Node dalam klaster. Pendekatan ini ditujukan untuk membatasi jumlah
|
||||
perubahan yang perlu dikirimkan ke setiap Node, meskipun hal tersebut berdampak pada banyaknya
|
||||
EndpointSlice yang tidak penuh.
|
||||
|
||||
Pada praktiknya, distribusi yang kurang ideal seperti ini akan jarang ditemukan. Kebanyakan perubahan yang diproses oleh _controller_ EndpointSlice akan cukup kecil untuk dapat masuk pada
|
||||
EndpointSlice yang sudah ada, dan jika tidak, cepat atau lambat sebuah EndpointSlice baru
|
||||
akan segera dibutuhkan. Pembaruan bertahap (_rolling update_) dari Deployment juga menyediakan sebuah proses
|
||||
pengemasan ulang EndpointSlice yang natural seiring dengan digantikannya seluruh Pod dan _endpoint_ yang
|
||||
bersangkutan.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* [Mengaktifkan EndpointSlice](/docs/tasks/administer-cluster/enabling-endpointslices)
|
||||
* Baca [Menghubungkan Aplikasi dengan Service](/docs/concepts/services-networking/connect-applications-service/)
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,206 @@
|
||||
---
|
||||
title: Topologi Service (_Service Topology_)
|
||||
feature:
|
||||
title: Topologi Service (_Service Topology_)
|
||||
description: >
|
||||
Rute lalu lintas layanan berdasarkan topologi klaster.
|
||||
|
||||
content_template: templates/concept
|
||||
weight: 10
|
||||
---
|
||||
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.17" state="alpha" >}}
|
||||
|
||||
Topologi Service memungkinkan Service untuk
|
||||
merutekan lalu lintas jaringan berdasarkan topologi Node dalam klaster. Misalnya, suatu
|
||||
layanan dapat menentukan lalu lintas jaringan yang lebih diutamakan untuk dirutekan ke
|
||||
beberapa _endpoint_ yang berada pada Node yang sama dengan klien, atau pada
|
||||
_availability zone_ yang sama.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Pengantar
|
||||
|
||||
Secara _default_, lalu lintas jaringan yang dikirim ke `ClusterIP` atau` NodePort` dari Service
|
||||
dapat dialihkan ke alamat _backend_ untuk Service tersebut. Sejak Kubernetes 1.7
|
||||
dimungkinkan untuk merutekan lalu lintas jaringan "eksternal" ke Pod yang berjalan di
|
||||
Node yang menerima lalu lintas jaringan, tetapi fitur ini tidak didukung untuk `ClusterIP` dari
|
||||
Service, dan topologi yang lebih kompleks — seperti rute zonasi —
|
||||
belum memungkinkan. Fitur topologi Service mengatasi kekurangan ini dengan
|
||||
mengizinkan pembuat layanan untuk mendefinisikan kebijakan dalam merutekan lalu lintas jaringan
|
||||
berdasarkan label Node untuk Node-Node asal dan tujuan.
|
||||
|
||||
Dengan menggunakan label Node yang sesuai antara asal dan tujuan, operator dapat
|
||||
menunjuk kelompok Node yang "lebih dekat" dan "lebih jauh" antara satu sama lain,
|
||||
dengan menggunakan metrik apa pun yang masuk akal untuk memenuhi persyaratan
|
||||
dari operator itu. Untuk sebagian besar operator di _cloud_ publik, misalnya, ada
|
||||
preferensi untuk menjaga layanan lalu lintas jaringan dalam zona yang sama, karena lalu lintas jaringan
|
||||
antar zona memiliki biaya yang dibebankan, sementara lalu lintas jaringan
|
||||
dalam zona yang sama tidak ada biaya. Kebutuhan umum lainnya termasuk kemampuan untuk merutekan
|
||||
lalu lintas jaringan ke Pod lokal yang dikelola oleh sebuah DaemonSet, atau menjaga lalu lintas jaringan ke
|
||||
Node yang terhubung ke _top-of-rack switch_ yang sama untuk mendapatkan
|
||||
latensi terendah.
|
||||
|
||||
|
||||
## Menggunakan Topologi Service
|
||||
|
||||
Jika klaster kamu mengaktifkan topologi layanan kamu dapat mengontrol rute lalu lintas jaringan Service
|
||||
dengan mengatur bagian `topologyKeys` pada spesifikasi Service. Bagian ini
|
||||
adalah daftar urutan label-label Node yang akan digunakan untuk mengurutkan _endpoint_
|
||||
saat mengakses Service ini. Lalu lintas jaringan akan diarahkan ke Node yang nilai
|
||||
label pertamanya cocok dengan nilai dari Node asal untuk label yang sama. Jika
|
||||
tidak ada _backend_ untuk Service pada Node yang sesuai, maka label kedua akan
|
||||
dipertimbangkan, dan seterusnya, sampai tidak ada label yang tersisa.
|
||||
|
||||
Jika tidak ditemukan kecocokan, lalu lintas jaringan akan ditolak, sama seperti jika tidak ada
|
||||
sama sekali _backend_ untuk Service tersebut. Artinya, _endpoint_ dipilih
|
||||
berdasarkan kunci topologi yang pertama yang tersedia pada _backend_. Jika dalam
|
||||
bagian ini ditentukan dan semua entri tidak memiliki _backend_ yang sesuai dengan
|
||||
topologi klien, maka Service tidak memiliki _backend_ untuk klien dan koneksi harus
|
||||
digagalkan. Nilai khusus `" * "` dapat digunakan untuk mengartikan "topologi
|
||||
apa saja". Nilai _catch-all_ ini, jika digunakan, maka hanya sebagai
|
||||
nilai terakhir dalam daftar.
|
||||
|
||||
Jika `topologyKeys` tidak ditentukan atau kosong, tidak ada batasan topologi
|
||||
yang akan diterapkan.
|
||||
|
||||
Seandainya sebuah klaster dengan Node yang dilabeli dengan nama _host_ ,
|
||||
nama zona, dan nama wilayah mereka, maka kamu dapat mengatur nilai
|
||||
`topologyKeys` dari sebuah Service untuk mengarahkan lalu lintas jaringan seperti berikut ini.
|
||||
|
||||
* Hanya ke _endpoint_ dalam Node yang sama, gagal jika tidak ada _endpoint_ pada
|
||||
Node: `[" kubernetes.io/hostname "]`.
|
||||
* Lebih memilih ke _endpoint_ dalam Node yang sama, jika tidak ditemukan maka ke _endpoint_ pada
|
||||
zona yang sama, diikuti oleh wilayah yang sama, dan selain itu gagal:
|
||||
`[" kubernetes.io/hostname ", "topology.kubernetes.io/zone", "topology.kubernetes.io/region"] `.
|
||||
Ini mungkin berguna, misalnya, dalam kasus di mana lokalitas data sangat penting.
|
||||
* Lebih memilih ke _endpoint_ dalam zona yang sama, tetapi memilih _endpoint_ mana saja yang
|
||||
tersedia apabila tidak ada yang tersedia dalam zona ini:
|
||||
`[" topology.kubernetes.io/zone "," * "]`.
|
||||
|
||||
|
||||
## Batasan
|
||||
|
||||
* Topologi Service tidak kompatibel dengan `externalTrafficPolicy=Local`, dan
|
||||
karena itu Service tidak dapat menggunakan kedua fitur ini sekaligus. Dimungkinkan untuk menggunakan
|
||||
kedua fitur pada klaster yang sama untuk Service yang berbeda, bukan untuk
|
||||
Service yang sama.
|
||||
|
||||
* Untuk saat ini kunci topologi yang valid hanya terbatas pada `kubernetes.io/hostname`,
|
||||
`topology.kubernetes.io/zone`, dan` topology.kubernetes.io/region`, tetapi akan
|
||||
digeneralisasikan ke label Node yang lain di masa depan.
|
||||
|
||||
* Kunci topologi harus merupakan kunci label yang valid dan paling banyak hanya 16 kunci yang dapat ditentukan.
|
||||
|
||||
* Nilai _catch-all_, `" * "`, harus menjadi nilai terakhir pada kunci topologi, jika
|
||||
nilai itu digunakan.
|
||||
|
||||
|
||||
## Contoh
|
||||
|
||||
Berikut ini adalah contoh umum penggunaan fitur topologi Service.
|
||||
|
||||
### Hanya pada _endpoint_ pada Node lokal
|
||||
|
||||
Service yang hanya merutekan ke _endpoint_ pada Node lokal. Jika tidak ada _endpoint_ pada Node, lalu lintas jaringan akan dihentikan:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: my-service
|
||||
spec:
|
||||
selector:
|
||||
app: my-app
|
||||
ports:
|
||||
- protocol: TCP
|
||||
port: 80
|
||||
targetPort: 9376
|
||||
topologyKeys:
|
||||
- "kubernetes.io/hostname"
|
||||
```
|
||||
|
||||
### Lebih memilih _endpoint_ pada Node lokal
|
||||
|
||||
Service yang lebih memilih _endpoint_ pada Node lokal tetapi akan memilih ke _endpoint_
|
||||
dalam klaster jika _endpoint_ pada Node lokal tidak ada:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: my-service
|
||||
spec:
|
||||
selector:
|
||||
app: my-app
|
||||
ports:
|
||||
- protocol: TCP
|
||||
port: 80
|
||||
targetPort: 9376
|
||||
topologyKeys:
|
||||
- "kubernetes.io/hostname"
|
||||
- "*"
|
||||
```
|
||||
|
||||
|
||||
### Hanya untuk _endpoint_ pada Zona atau Wilayah
|
||||
|
||||
Service yang lebih memilih _endpoint_ zona daripada wilayah. Jika tidak ada _endpoint_ pada
|
||||
keduanya, make lalu lintas jaringan akan dihentikan.
|
||||
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: my-service
|
||||
spec:
|
||||
selector:
|
||||
app: my-app
|
||||
ports:
|
||||
- protocol: TCP
|
||||
port: 80
|
||||
targetPort: 9376
|
||||
topologyKeys:
|
||||
- "topology.kubernetes.io/zone"
|
||||
- "topology.kubernetes.io/region"
|
||||
```
|
||||
|
||||
### Lebih memilih _endpoint_ pada Node Lokal, Zonal, terakhir Regional
|
||||
|
||||
Service yang lebih memilih _endpoint_ pada Node lokal, zonal, kemudian regional
|
||||
tetapi jika tetap tidak ditemukan maka akan memilih _endpoint_ diseluruh klaster.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: my-service
|
||||
spec:
|
||||
selector:
|
||||
app: my-app
|
||||
ports:
|
||||
- protocol: TCP
|
||||
port: 80
|
||||
targetPort: 9376
|
||||
topologyKeys:
|
||||
- "kubernetes.io/hostname"
|
||||
- "topology.kubernetes.io/zone"
|
||||
- "topology.kubernetes.io/region"
|
||||
- "*"
|
||||
```
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* Baca tentang [mengaktifkan topologi Service](/docs/tasks/administer-cluster/enabling-service-topology)
|
||||
* Baca [menghubungkan aplikasi dengan Service](/docs/concepts/services-networking/connect-applications-service/)
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -11,8 +11,8 @@ weight: 30
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
Deployment menyediakan pembaruan [Pods](/docs/id/concepts/workloads/pods/pod/) dan
|
||||
[ReplicaSets](/docs/id/concepts/workloads/controllers/replicaset/) secara deklaratif.
|
||||
Deployment menyediakan pembaruan [Pods](/id/docs/concepts/workloads/pods/pod/) dan
|
||||
[ReplicaSets](/id/docs/concepts/workloads/controllers/replicaset/) secara deklaratif.
|
||||
|
||||
Kamu mendeskripsikan sebuah state yang diinginkan dalam Deployment, kemudian Deployment {{< glossary_tooltip term_id="controller" >}} mengubah state sekarang menjadi seperti pada deskripsi secara bertahap. Kamu dapat mendefinisikan Deployment untuk membuat ReplicaSets baru atau untuk menghapus Deployment yang sudah ada dan mengadopsi semua resourcenya untuk Deployment baru.
|
||||
|
||||
|
||||
@@ -3,7 +3,7 @@ title: Dokumentasi Kubernetes
|
||||
noedit: true
|
||||
cid: docsHome
|
||||
layout: docsportal_home
|
||||
class: gridPage
|
||||
class: gridPage gridPageHome
|
||||
linkTitle: "Home"
|
||||
main_menu: true
|
||||
weight: 10
|
||||
|
||||
+23
@@ -0,0 +1,23 @@
|
||||
---
|
||||
title: Service
|
||||
id: service
|
||||
date: 2020-04-05
|
||||
full_link: /docs/concepts/services-networking/service/
|
||||
short_description: >
|
||||
Sebuah Cara untuk mengekspos aplikasi yang berjalan pada sebuah kumpulan Pod sebagai layanan jaringan.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- core-object
|
||||
---
|
||||
Suatu cara yang abstrak untuk mengekspos aplikasi yang berjalan pada sebuah kumpulan
|
||||
{{<glossary_tooltip text="Pod" term_id="pod">}} sebagai layanan jaringan.
|
||||
<!--more-->
|
||||
|
||||
Rangkaian Pod yang ditargetkan oleh Service (biasanya) ditentukan oleh
|
||||
{{<glossary_tooltip text="selector" term_id="selector">}}.
|
||||
Jika lebih banyak Pod ditambahkan atau dihapus, maka kumpulan Pod yang cocok
|
||||
dengan Selector juga akan berubah. Service memastikan bahwa lalu lintas
|
||||
jaringan dapat diarahkan ke kumpulan Pod yang ada saat ini sebagai
|
||||
Workload.
|
||||
@@ -0,0 +1,94 @@
|
||||
---
|
||||
title: Tugas (Tasks)
|
||||
main_menu: true
|
||||
weight: 50
|
||||
content_template: templates/concept
|
||||
---
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
Bagian dokumentasi Kubernetes ini berisi halaman-halaman yang perlihatkan
|
||||
bagaimana melakukan setiap tugas (_task_). Halaman tugas menunjukkan cara melakukan
|
||||
satu hal saja, biasanya dengan memberikan urutan langkah pendek.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Antarmuka Pengguna Berbasis Web (Dashboard)
|
||||
|
||||
Melakukan _deploy_ dan mengakses _dashboard_ berbasis web untuk
|
||||
membantu kamu mengelola dan memantau aplikasi yang dimasukkan ke dalam container
|
||||
di Kubernetes.
|
||||
|
||||
## Menggunakan Baris Perintah kubectl
|
||||
|
||||
Instalasi dan konfigurasi utilitas baris perintah `kubectl` yang digunakan untuk
|
||||
mengelola secara langsung klaster Kubernetes.
|
||||
|
||||
## Mengkonfigurasi Pod dan Container
|
||||
|
||||
Melakukan tugas konfigurasi yang umum untuk Pod dan Container.
|
||||
|
||||
## Menjalankan Aplikasi
|
||||
|
||||
Melakukan tugas manajemen aplikasi secara umum, seperti _rolling updates_, memasukkan
|
||||
informasi ke dalam Pod, dan penskalaan Pod secara horisontal.
|
||||
|
||||
## Menjalankan Job
|
||||
|
||||
Menjalankan Job dengan menggunakan pemrosesan paralel.
|
||||
|
||||
## Mengakses Aplikasi dalam Klaster
|
||||
|
||||
Mengkonfigurasi _load balancing_, _port forwarding_, atau membangun _firewall_
|
||||
atau konfigurasi DNS untuk mengakses aplikasi dalam sebuah klaster.
|
||||
|
||||
## _Monitoring, Logging_, dan _Debugging_
|
||||
|
||||
Mengatur _monitoring_ (pemantauan) dan _logging_ (pencatatan) untuk memecahkan
|
||||
masalah klaster atau melakukan _debug_ (pelacakan) aplikasi yang dikontainerisasi.
|
||||
|
||||
## Mengakses API Kubernetes
|
||||
|
||||
Mempelajari berbagai metode untuk mengakses API Kubernetes secara langsung.
|
||||
|
||||
## Menggunakan TLS
|
||||
|
||||
Mengkonfigurasi aplikasi kamu untuk percaya dan menggunakan klaster _Certificate
|
||||
Authority_ (CA).
|
||||
|
||||
## Mengelola Klaster
|
||||
|
||||
Mempelajari tugas umum untuk mengelola klaster.
|
||||
|
||||
## Mengelola Aplikasi yang _Stateful_
|
||||
|
||||
Melakukan tugas umum untuk mengelola aplikasi yang _Stateful_, termasuk
|
||||
penskalaan, penghapusan, dan _debugging_ StatefulSets.
|
||||
|
||||
## _Daemon_ Klaster
|
||||
|
||||
Melakukan tugas-tugas umum untuk mengelola DaemonSet, seperti melakukan _rolling
|
||||
updates_.
|
||||
|
||||
## Mengelola GPU
|
||||
|
||||
Mengkonfigurasi dan menjadwalkan GPU NVIDIA untuk digunakan sebagai sumber daya
|
||||
oleh Node dalam sebuah klaster.
|
||||
|
||||
## Mengelola _HugePages_
|
||||
|
||||
Mengkonfigurasi dan menjadwalkan _HugePages_ sebagai sumber daya yang dapat
|
||||
dijadwalkan dalam sebuah klaster.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
Jika kamu ingin menulis halaman tugas (_task_), silahkan lihat
|
||||
[Membuat Dokumentasi _Pull Request_](/docs/home/contribute/create-pull-request/).
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
title: "Mengakes Aplikasi-aplikasi di sebuah Klaster"
|
||||
weight: 60
|
||||
---
|
||||
|
||||
+201
@@ -0,0 +1,201 @@
|
||||
---
|
||||
title: Menggunakan Port Forwarding untuk Mengakses Aplikasi di sebuah Klaster
|
||||
content_template: templates/task
|
||||
weight: 40
|
||||
min-kubernetes-server-version: v1.10
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
Halaman ini menunjukkan bagaimana menggunakan `kubectl port-forward` untuk menghubungkan sebuah server Redis yang sedang berjalan di sebuah klaster Kubernetes. Tipe dari koneksi ini dapat berguna untuk melakukan _debugging_ basis data.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
* Install [redis-cli](http://redis.io/topics/rediscli).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## Membuat Deployment dan Service Redis
|
||||
|
||||
1. Buat sebuah Deployment yang menjalankan Redis:
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-deployment.yaml
|
||||
```
|
||||
|
||||
Keluaran dari sebuah perintah yang sukses akan memverifikasi bahwa Deployment telah terbuat:
|
||||
|
||||
```
|
||||
deployment.apps/redis-master created
|
||||
```
|
||||
|
||||
Lihat status Pod untuk memeriksa apakah sudah siap:
|
||||
|
||||
```shell
|
||||
kubectl get pods
|
||||
```
|
||||
|
||||
Keluaran menampilkan Pod yang telah terbuat:
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
redis-master-765d459796-258hz 1/1 Running 0 50s
|
||||
```
|
||||
|
||||
Lihat status Deployment:
|
||||
|
||||
```shell
|
||||
kubectl get deployment
|
||||
```
|
||||
|
||||
Keluaran menampilkan bahwa Deployment telah terbuat:
|
||||
|
||||
```
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
redis-master 1/1 1 1 55s
|
||||
```
|
||||
|
||||
Deployment secara otomatis mengatur sebuah ReplicaSet.
|
||||
Lihat status ReplicaSet menggunakan:
|
||||
|
||||
```shell
|
||||
kubectl get replicaset
|
||||
```
|
||||
|
||||
Keluaran menampilkan bahwa ReplicaSet telah terbuat:
|
||||
|
||||
```
|
||||
NAME DESIRED CURRENT READY AGE
|
||||
redis-master-765d459796 1 1 1 1m
|
||||
```
|
||||
|
||||
|
||||
2. Buat sebuah Service untuk mengekspos Redis di jaringan:
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-service.yaml
|
||||
```
|
||||
|
||||
Keluaran dari perintah yang sukses akan memverifikasi bahwa Service telah terbuat:
|
||||
|
||||
```
|
||||
service/redis-master created
|
||||
```
|
||||
|
||||
Lihat Service yang telah terbuat menggunakan:
|
||||
|
||||
```shell
|
||||
kubectl get service redis-master
|
||||
```
|
||||
|
||||
Keluaran menampilkan service yang telah terbuat:
|
||||
|
||||
```
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
redis-master ClusterIP 10.0.0.213 <none> 6379/TCP 27s
|
||||
```
|
||||
|
||||
3. Periksa apakah server Redis berjalan di Pod, dan mendengarkan porta 6379:
|
||||
|
||||
```shell
|
||||
# Ubah redis-master-765d459796-258hz menjadi nama Pod
|
||||
kubectl get pod redis-master-765d459796-258hz --template='{{(index (index .spec.containers 0).ports 0).containerPort}}{{"\n"}}'
|
||||
```
|
||||
|
||||
Keluaran akan menampilkan porta dari Redis di Pod tersebut:
|
||||
|
||||
```
|
||||
6379
|
||||
```
|
||||
|
||||
(ini adalah porta TCP yang dialokasi untuk Redis di internet)
|
||||
|
||||
## Meneruskan sebuah porta lokal ke sebuah porta pada Pod
|
||||
|
||||
1. `kubectl port-forward` memungkinkan penggunaan nama sumber daya, seperti sebuah nama Pod, untuk memilih Pod yang sesuai untuk melakukan penerusan porta.
|
||||
|
||||
|
||||
```shell
|
||||
# Ubah redis-master-765d459796-258hz menjadi nama Pod
|
||||
kubectl port-forward redis-master-765d459796-258hz 7000:6379
|
||||
```
|
||||
|
||||
yang sama seperti
|
||||
|
||||
```shell
|
||||
kubectl port-forward pods/redis-master-765d459796-258hz 7000:6379
|
||||
```
|
||||
|
||||
atau
|
||||
|
||||
```shell
|
||||
kubectl port-forward deployment/redis-master 7000:6379
|
||||
```
|
||||
|
||||
atau
|
||||
|
||||
```shell
|
||||
kubectl port-forward replicaset/redis-master 7000:6379
|
||||
```
|
||||
|
||||
atau
|
||||
|
||||
```shell
|
||||
kubectl port-forward service/redis-master 7000:6379
|
||||
```
|
||||
|
||||
Semua perintah di atas berfungsi. Keluarannya mirip dengan ini:
|
||||
|
||||
```
|
||||
I0710 14:43:38.274550 3655 portforward.go:225] Forwarding from 127.0.0.1:7000 -> 6379
|
||||
I0710 14:43:38.274797 3655 portforward.go:225] Forwarding from [::1]:7000 -> 6379
|
||||
```
|
||||
|
||||
2. Memulai antarmuka baris perintah (*command line*) Redis:
|
||||
|
||||
```shell
|
||||
redis-cli -p 7000
|
||||
```
|
||||
|
||||
3. Pada baris perintah di Redis, masukkan perintah `ping`:
|
||||
|
||||
```
|
||||
ping
|
||||
```
|
||||
|
||||
Sebuah permintaan *ping* yang sukses akan mengembalikan:
|
||||
|
||||
```
|
||||
PONG
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture discussion %}}
|
||||
|
||||
## Diskusi
|
||||
|
||||
Koneksi-koneksi yang dibuat ke porta lokal 7000 diteruskan ke porta 6379 dari Pod yang menjalankan server Redis.
|
||||
Dengan koneksi ini, kamu dapat menggunakan *workstation* lokal untuk melakukan *debug* basis data yang berjalan di Pod.
|
||||
|
||||
{{< note >}}
|
||||
`kubectl port-forward` hanya bisa diimplementasikan untuk porta TCP saja.
|
||||
Dukungan untuk protokol UDP bisa dilihat di
|
||||
[issue 47862](https://github.com/kubernetes/kubernetes/issues/47862).
|
||||
{{< /note >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
Belajar lebih tentang [kubectl port-forward](/docs/reference/generated/kubectl/kubectl-commands/#port-forward).
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,168 @@
|
||||
---
|
||||
title: Antarmuka Pengguna Berbasis Web (Dashboard)
|
||||
content_template: templates/concept
|
||||
weight: 10
|
||||
card:
|
||||
name: tasks
|
||||
weight: 30
|
||||
title: Menggunakan Antarmuka Pengguna Berbasis Web Dashboard
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
Dashboard adalah antarmuka pengguna Kubernetes. Kamu dapat menggunakan Dashboard untuk men-_deploy_ aplikasi yang sudah dikontainerisasi ke klaster Kubernetes, memecahkan masalah pada aplikasi kamu, dan mengatur sumber daya klaster. Kamu dapat menggunakan Dashboard untuk melihat ringkasan dari aplikasi yang sedang berjalan di klaster kamu, dan juga membuat atau mengedit objek individu sumber daya Kubernetes (seperti Deployment, Job, DaemonSet, dll.). Sebagai contoh, kamu dapat mengembangkan sebuah Deployment, menginisiasi sebuah pembaruan bertahap (_rolling update_), memulai kembali sebuah Pod atau men-_deploy_ aplikasi baru menggunakan sebuah _deploy wizard_.
|
||||
|
||||
Dashboard juga menyediakan informasi tentang status dari sumber daya Kubernetes di klaster kamu dan kesalahan apapun yang mungkin telah terjadi..
|
||||
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Men-_deploy_ Antarmuka Pengguna Dashboard
|
||||
|
||||
Antarmuka Dashboard tidak ter-_deploy_ secara bawaan. Untuk men-_deploy_-nya, kamu dapat menjalankan perintah berikut:
|
||||
|
||||
```
|
||||
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-beta8/aio/deploy/recommended.yaml
|
||||
```
|
||||
|
||||
## Mengakses Antarmuka Dashboard
|
||||
|
||||
|
||||
Untuk melindungi data klaster kamu, pen-_deploy_-an Dashboard menggunakan sebuah konfigurasi _RBAC_ yang minimal secara bawaan. Saat ini, Dashboard hanya mendukung otentikasi dengan _Bearer Token_. Untuk membuat token untuk demo, kamu dapat mengikuti petunjuk kita untuk [membuat sebuah contoh pengguna](https://github.com/kubernetes/dashboard/blob/master/docs/user/access-control/creating-sample-user.md).
|
||||
|
||||
{{< warning >}}
|
||||
Contoh pengguna yang telah dibuat di tutorial tersebut akan memiliki hak istimewa sebagai administrator dan hanyalah untuk tujuan pembelajaran.
|
||||
{{< /warning >}}
|
||||
|
||||
### Proksi antarmuka baris perintah (CLI)
|
||||
Kamu dapat mengakses Dashboard menggunakan perkakas CLI kubectl dengan menjalankan perintah berikut:
|
||||
|
||||
```
|
||||
kubectl proxy
|
||||
```
|
||||
|
||||
Kubectl akan membuat Dashboard tersedia di http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/.
|
||||
|
||||
Antarmuka pengguna berbasis web tersebut hanya dapat di akses dari mesin dimana perintah tersebut dijalankan. Lihat `kubectl proxy --help` untuk lebih lanjut.
|
||||
|
||||
{{< note >}}
|
||||
Metode otentikasi Kubeconfig tidak mendukung penyedia identitas eksternal atau otentikasi berbasis sertifikat elektronik x509.
|
||||
{{< /note >}}
|
||||
|
||||
## Tampilan selamat datang
|
||||
|
||||
Ketika kamu mengakses Dashboard di klaster yang kosong, kamu akan melihat laman selamat datang. Laman ini berisi tautan ke dokumen ini serta tombol untuk men-_deploy_ aplikasi pertama kamu. Selain itu, kamu dapat melihat aplikasi-aplikasi sistem mana saja yang berjalan secara bawaan di [Namespace](/docs/tasks/administer-cluster/namespaces/) `kube-system` dari klaster kamu, misalnya Dashboard itu sendiri.
|
||||
|
||||
|
||||
|
||||
## Men-_deploy_ aplikasi yang sudah dikontainerisasi
|
||||
|
||||
Dashboard memungkinkan kamu untuk membuat dan men-_deploy_ aplikasi yang sudah dikontainerisasi sebagai Deployment dan Service opsional dengan sebuah _wizard_ sederhana. Kamu secara manual dapat menentukan detail aplikasi, atau mengunggah sebuah berkas YAML atau JSON yang berisi konfigurasi aplikasi.
|
||||
|
||||
Tekan tombol **CREATE** di pojok kanan atas di laman apapun untuk memulai.
|
||||
|
||||
### Menentukan detail aplikasi
|
||||
|
||||
_Deploy wizard_ meminta kamu untuk menyediakan informasi sebagai berikut:
|
||||
|
||||
- **App name** (wajib): Nama dari aplikasi kamu. Sebuah [label](/docs/concepts/overview/working-with-objects/labels/) dengan nama tersebut akan ditambahkan ke Deployment dan Service, jika ada, akan di-_deploy_.
|
||||
|
||||
Nama aplikasi harus unik di dalam [Namespace](/docs/tasks/administer-cluster/namespaces/) Kubernetes yang kamu pilih. Nama tersebut harus dimulai dengan huruf kecil, dan diakhiri dengan huruf kecil atau angka, dan hanya berisi huruf kecil, angka dan tanda hubung (-). Nama tersebut juga dibatasi hanya 24 karakter. Spasi di depan dan belakang nama tersebut diabaikan.
|
||||
|
||||
- **Container image** (wajib): Tautan publik dari sebuah [_image_](/docs/concepts/containers/images/) kontainer Docker pada _registry_ apapun, atau sebuah _image_ privat (biasanya di-_hosting_ di Google Container Registry atau Docker Hub). Spesifikasi _image_ kontainer tersebut harus diakhiri dengan titik dua.
|
||||
|
||||
- **Number of pods** (wajib): Berapa banyak Pod yang kamu inginkan untuk men-_deploy_ aplikasimu. Nilainya haruslah sebuah bilangan bulat positif.
|
||||
|
||||
Sebuah [Deployment](/docs/concepts/workloads/controllers/deployment/) akan terbuat untuk mempertahankan jumlah Pod di klaster kamu.
|
||||
|
||||
- **Service** (opsional): Untuk beberapa aplikasi (misalnya aplikasi _frontend_) kamu mungkin akan mengekspos sebuah [Service](/docs/concepts/services-networking/service/) ke alamat IP publik yang mungkin berada diluar klaster kamu(Service eksternal). Untuk Service eksternal, kamu mungkin perlu membuka lebih dari satu porta jaringan untuk mengeksposnya. Lihat lebih lanjut [di sini](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/).
|
||||
|
||||
Service lainnya yang hanya dapat diakses dari dalam klaster disebut Service internal.
|
||||
|
||||
Terlepas dari jenis Service, jika kamu memilih untuk membuat sebuah Service dan Container kamu berjalan di sebuah porta(arah masuk), kamu perlu menentukan dua porta. Service akan memetakan porta(arah masuk) ke porta target yang ada di sisi Container. Service akan mengarahkan ke Pod-Pod kamu yang sudah di-_deploy_. Protokol yang didukung adalah TCP dan UDP. Nama DNS internal untuk Service ini akan sesuai dengan nama aplikasi yang telah kamu tentukan diatas.
|
||||
|
||||
Jika membutuhkan, kamu dapat membuka bagian **Advanced options** di mana kamu dapat menyetel lebih banyak pengaturan:
|
||||
|
||||
- **Description**: Tels yang kamu masukkan ke sini akan ditambahkan sebagai sebuah [anotasi](/docs/concepts/overview/working-with-objects/annotations/) ke Deployment dan akan ditampilkan di detail aplikasi.
|
||||
|
||||
- **Labels**: [Label-label](/docs/concepts/overview/working-with-objects/labels/) bawaan yang akan digunakan untuk aplikasi kamu adalah `name` dan `version` aplikasi. Kamu dapat menentukan label lain untuk diterapkan ke Deployment, Service (jika ada), dan Pod, seperti `release`, `environment`, `tier`, `partition`, dan `track` rilis.
|
||||
|
||||
Contoh:
|
||||
|
||||
```conf
|
||||
release=1.0
|
||||
tier=frontend
|
||||
environment=pod
|
||||
track=stable
|
||||
```
|
||||
|
||||
- **_Namespace_**: Kubernetes mendukung beberapa klaster virtual yang berjalan di atas klaster fisik yang sama. Klaster virtual ini disebut [Namespace](/docs/tasks/administer-cluster/namespaces/). Mereka mengizinkan kamu untuk mempartisi sumber daya ke beberapa grup yang diberi nama secara logis.
|
||||
|
||||
Dashboard menampilkan semua Namespace yang tersedia dalam sebuah daftar _dropdown_, dan mengizinkan kamu untuk membuat Namespace baru. Nama yang diizinkan untuk Namespace terdiri dari maksimal 63 karakter alfanumerik dan tanda hubung (-), dan tidak boleh ada huruf kapital.
|
||||
Nama dari Namespace tidak boleh terdiri dari angka saja. Jika nama Namespace disetel menjadi sebuah angka, misalnya 10, maka Pod tersebut akan ditaruh di Namespace `default`.
|
||||
|
||||
Jika pembuatan Namespace berhasil, Namespace tersebut akan dipilih secara bawaan. Jika pembuatannya gagal, maka Namespace yang pertama akan terpilih.
|
||||
|
||||
- **_Image Pull Secret_**: Jika kamu menggunakan _image_ kontainer Docker yang privat, mungkin diperlukan kredensial [_pull secret_](/docs/concepts/configuration/secret/).
|
||||
|
||||
Dashboard menampilkan semua _secret_ yang tersedia dengan daftar _dropdown_, dan mengizinkan kamu untuk membuat _secret_ baru. Nama _secret_ tersebut harus mengikuti aturan Nama DNS, misalnya `new.image-pull.secret`. Isi dari sebuah _secret_ harus dienkode dalam bentuk _base64_ dan ditentukan dalam sebuah berkas [`.dockercfg`](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod). Nama kredensial dapat berisi maksimal 253 karakter.
|
||||
|
||||
Jika pembuatan _image pull secret_ berhasil, _image pull secret_ tersebut akan terpilih secara bawaan. Jika gagal, maka tidak ada _secret_ yang dipilih.
|
||||
|
||||
- **_CPU requirement (cores)_** dan **_Memory requirement (MiB)_**: Kamu dapat menentukan [batasan sumber daya](/docs/tasks/configure-pod-container/limit-range/) minimal untuk Container. Secara bawaan, Pod-Pod berjalan dengan CPU dan memori yang tak dibatasi.
|
||||
|
||||
- **_Run command_** dan **_Run command arguments_**: Secara bawaan, Container-Container kamu akan menjalankan perintah [_entrypoint_](/docs/user-guide/containers/#containers-and-commands) bawaan dari _image_ Docker yang ditentukan. Kamu dapat menggunakan opsi _Run command_ dan _Run command arguments_ untuk mengganti bawaannya.
|
||||
|
||||
- **_Run as priveleged_**: Pengaturan ini untuk menentukan sebuah proses yang berjalan dalam [_privileged container_](/docs/user-guide/pods/#privileged-mode-for-pod-containers) sepadan dengan proses yang berjalan sebagai _root_ pada _host_-nya. _Priveleged container_ dapat menggunakan kemampuan seperti memanipulasi _stack_ jaringan dan mengakses perangkat-perangkat.
|
||||
|
||||
- **_Environment variables_**: Kubernetes mengekspos Service melalui [_environment variable_](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/). Kamu dapat membuat _environment variable_ atau meneruskan argumen ke perintah-perintah untuk menjalankan Container dengan nilai dari _environment variable_. _Environment Variable_ dapat digunakan pada aplikasi-aplikasi untuk menemukan sebuah Service. Nilai _environment variable_ dapat merujuk ke variabel lain menggunakan sintaksis `$(VAR_NAME)`.
|
||||
|
||||
### Menggungah berkas YAML atau JSON
|
||||
|
||||
Kubernetes mendukung pengaturan deklaratif. Dengan cara ini, semua pengaturan disimpan dalam bentuk berkas YAML atau JSON menggunakan skema sumber daya [[API](/docs/concepts/overview/kubernetes-api/).
|
||||
|
||||
Sebagai alternatif untuk menentukan detail aplikasi di _deploy wizard_, kamu dapat menentukan sendiri detail aplikasi kamu dalam berkas YAML atau JSON, dan mengunggah berkas tersebut menggunakan Dashboard.
|
||||
|
||||
## Menggunakan Dashboard
|
||||
Bagian ini akan menjelaskan bagian-bagian yang ada pada Antarmuka Dashboard Kubernetes; apa saja yang mereka sediakan dan bagaimana cara menggunakanya.
|
||||
|
||||
### Navigation
|
||||
|
||||
Ketika ada objek Kubernetes yang sudah didefinisikan di dalam klaster, Dashboard akan menampilkanya di tampilan awalnya. Secara bawaan hanya objek-objek dalam Namespace _default_ saja yang ditampilkan di sini dan kamu dapat menggantinya dengan selektor Namespace yang berada di menu navigasi.
|
||||
|
||||
Dashboard menampilkan jenis objek Kubernetes dan mengelompokanya dalam beberapa kategori menu.
|
||||
|
||||
#### Admin Overview
|
||||
Untuk administrasi klaster dan Namespace, Dashboard menampilkan Node, Namespace dan PresistentVolume dan memiliki tampilan yang detail untuk objek-objek tersebut. Daftar Node berisi metrik penggunaan CPU dan memori yang dikumpulkan dari semua Node. Tampilan detail menampilkan metrik-metrik untuk sebuah Node, spesifikasinya, status, sumber daya yang dialokasikan, _event-event_, dan Pod-Pod yang sedang berjalan di Node tersebut.
|
||||
|
||||
#### Workloads
|
||||
Menampilkan semua aplikasi yang sedang berjalan di Namespace yang dipilih. Tampilan ini menampilkan aplikasi berdasarkan jenis beban kerja (misalnya, Deployment, Replica Set, Stateful Set, dll.) dan setiap jenis beban kerja memiliki tampilanya sendiri. Daftar ini merangkum informasi yang dapat ditindaklanjuti, seperti berapa banyak Pod yang siap untuk setiap Replica Set atau penggunaan memori pada sebuah Pod.
|
||||
|
||||
Tampilan detail dari beban kerja menampilkan status dan informasi spesifik serta hubungan antara objek. Misalnya, Pod-Pod yang diatur oleh ReplicaSet atau, ReplicaSet-ReplicaSet baru, dan HorizontalPodAutoscaler untuk Deployment.
|
||||
|
||||
#### Services
|
||||
Menampilkan sumber daya Kubernetes yang mengizinkan untuk mengekspos Service-Service ke jaringan luar dan menemukannya (_service discovery_) di dalam klaster. Untuk itu, tampilan dari Service dan Ingress menunjukan Pod-Pod yang ditarget oleh mereka, _endpoint-endpoint_ internal untuk koneksi klaster, dan _endpoint-endpoint_ eksternal untuk pengguna eksternal.
|
||||
|
||||
#### Storage
|
||||
Tampilan Storage menampilkan sumber-sumber daya PersistentVolumeClaim yang digunakan oleh aplikasi untuk menyimpan data.
|
||||
|
||||
#### Config Maps dan Secrets
|
||||
Menampilkan semua sumber daya Kubernetes yang digunakan untuk pengaturan aplikasi yang sedang berjalan di klaster. Pada tampilan ini kamu dapat mengedit dan mengelola objek-objek konfigurasi dan menampilkan kredensial yang tersembunyi secara bawaan.
|
||||
|
||||
#### Logs Viewer
|
||||
Laman daftar dan detail Pod tertaut dengan laman penampil log (_log viewer_). Kamu dapat menelusuri log yang berasal dari Container-Container pada sebuah Pod.
|
||||
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
Untuk informasi lebih lanjut, lihat
|
||||
[Laman proyek Kubernetes Dashboard](https://github.com/kubernetes/dashboard).
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,52 @@
|
||||
---
|
||||
title: Contoh Template Tugas (Task)
|
||||
content_template: templates/task
|
||||
toc_hide: true
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
{{< note >}}
|
||||
Pastikan juga kamu [membuat isian di daftar isi](/docs/home/contribute/write-new-topic/#creating-an-entry-in-the-table-of-contents) untuk dokumen baru kamu.
|
||||
{{< /note >}}
|
||||
|
||||
Halaman ini menunjukkan bagaimana ...
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
* Lakukan ini.
|
||||
* Lakukan ini juga.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## Menjalankan ...
|
||||
|
||||
1. Lakukan ini.
|
||||
1. Selanjutnya lakukan ini. Bila mungkin silahkan baca [penjelasan terkait](...).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture discussion %}}
|
||||
|
||||
## Memahami ...
|
||||
**[Bagian opsional]**
|
||||
|
||||
Berikut ini hal-hal yang menarik untuk diketahui tentang langkah-langkah yang baru saja kamu lakukan.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
**[Bagian optional]**
|
||||
|
||||
* Pelajari tentang [menulis topik baru](/docs/home/contribute/write-new-topic/).
|
||||
* Lihat [menggunakan _template_ halaman - _template_ tugas](/docs/home/contribute/page-templates/#task_template) untuk mengetahui cara menggunakan _template_ ini.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
title: "Memasukkan Data ke dalam Aplikasi"
|
||||
weight: 30
|
||||
---
|
||||
|
||||
+119
@@ -0,0 +1,119 @@
|
||||
---
|
||||
title: Mendefinisikan Variabel Lingkungan untuk sebuah Kontainer
|
||||
content_template: templates/task
|
||||
weight: 20
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
Laman ini menunjukkan bagaimana cara untuk mendefinisikan variabel lingkungan (_environment variable_) untuk sebuah Container di dalam sebuah Pod Kubernetes.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## Mendefinisikan sebuah variabel lingkungan untuk sebuah Container
|
||||
|
||||
Ketika kamu membuat sebuah Pod, kamu dapat mengatur variabel lingkungan untuk Container-Container yang berjalan di dalam sebuah Pod.
|
||||
Untuk mengatur variabel lingkungan, sertakan bagian `env` atau `envFrom` pada berkas konfigurasi.
|
||||
|
||||
Dalam latihan ini, kamu membuat sebuah Pod yang menjalankan satu buah Container.
|
||||
Berkas konfigurasi untuk Pod tersebut mendefinisikan sebuah variabel lingkungan dengan nama `DEMO_GREETING` yang bernilai `"Hello from the environment"`.
|
||||
Berikut berkas konfigurasi untuk Pod tersebut:
|
||||
|
||||
{{< codenew file="pods/inject/envars.yaml" >}}
|
||||
|
||||
1. Buatlah sebuah Pod berdasarkan berkas konfigurasi YAML tersebut:
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/pods/inject/envars.yaml
|
||||
```
|
||||
|
||||
2. Tampilkan Pod-Pod yang sedang berjalan:
|
||||
|
||||
```shell
|
||||
kubectl get pods -l purpose=demonstrate-envars
|
||||
```
|
||||
|
||||
Keluarannya mirip seperti ini:
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
envar-demo 1/1 Running 0 9s
|
||||
```
|
||||
|
||||
3. Dapatkan sebuah _shell_ ke Container yang sedang berjalan di Pod kamu:
|
||||
|
||||
```shell
|
||||
kubectl exec -it envar-demo -- /bin/bash
|
||||
```
|
||||
|
||||
4. Di _shell_ kamu, jalankan perintah `printenv` untuk melihat daftar variabel lingkungannya.
|
||||
|
||||
```shell
|
||||
root@envar-demo:/# printenv
|
||||
```
|
||||
|
||||
Keluarannya mirip seperti ini:
|
||||
|
||||
```
|
||||
NODE_VERSION=4.4.2
|
||||
EXAMPLE_SERVICE_PORT_8080_TCP_ADDR=10.3.245.237
|
||||
HOSTNAME=envar-demo
|
||||
...
|
||||
DEMO_GREETING=Hello from the environment
|
||||
DEMO_FAREWELL=Such a sweet sorrow
|
||||
```
|
||||
|
||||
5. Untuk keluar dari _shell_ tersebut, masukkan perintah `exit`.
|
||||
|
||||
{{< note >}}
|
||||
Variabel-variabel lingkungan yang diatur menggunakan bagian `env` atau `envFrom` akan mengesampingkan
|
||||
variabel-variabel lingkungan yang ditentukan di dalam _image_ kontainer.
|
||||
{{< /note >}}
|
||||
|
||||
## Menggunakan variabel-variabel lingkungan di dalam konfigurasi kamu
|
||||
|
||||
Variabel-variabel lingkungan yang kamu definisikan di dalam sebuah konfigurasi Pod dapat digunakan di tempat lain dalam konfigurasi, contohnya di dalam perintah-perintah dan argumen-argumen yang kamu atur dalam Container-Container milik Pod.
|
||||
Pada contoh konfigurasi berikut, variabel-variabel lingkungan `GREETING`, `HONORIFIC`, dan `NAME` disetel masing-masing menjadi `Warm greetings to`, `The Most Honorable`, dan `Kubernetes`.
|
||||
Variabel-variabel lingkungan tersebut kemudian digunakan dalam argumen CLI yang diteruskan ke Container `env-print-demo`.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: print-greeting
|
||||
spec:
|
||||
containers:
|
||||
- name: env-print-demo
|
||||
image: bash
|
||||
env:
|
||||
- name: GREETING
|
||||
value: "Warm greetings to"
|
||||
- name: HONORIFIC
|
||||
value: "The Most Honorable"
|
||||
- name: NAME
|
||||
value: "Kubernetes"
|
||||
command: ["echo"]
|
||||
args: ["$(GREETING) $(HONORIFIC) $(NAME)"]
|
||||
```
|
||||
|
||||
Setelah dibuat, perintah `echo Warm greetings to The Most Honorable Kubernetes` dijalankan di Container tersebut.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* Pelajari lebih lanjut tentang [variabel lingkungan](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/).
|
||||
* Pelajari tentang [menggunakan informasi rahasia sebagai variabel lingkungan](/docs/user-guide/secrets/#using-secrets-as-environment-variables).
|
||||
* Lihat [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core).
|
||||
|
||||
{{% /capture %}}
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user