Merge pull request #23075 from annajung/merged-master-dev-1.19
Merged master dev 1.19
This commit is contained in:
Kubernetes Prow Robot
GitHub
commit
9d0baba1e1
|
|
@ -46,7 +46,7 @@ Kubernetes is open source giving you the freedom to take advantage of on-premise
|
|||
<br>
|
||||
<br>
|
||||
<br>
|
||||
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna20" button id="desktopKCButton">Attend KubeCon in Boston on November 17-20, 2020</a>
|
||||
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna20" button id="desktopKCButton">Attend KubeCon NA virtually on November 17-20, 2020</a>
|
||||
</div>
|
||||
<div id="videoPlayer">
|
||||
<iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>
|
||||
|
|
|
|||
|
|
@ -162,6 +162,31 @@ are built in and may not be overwritten:
|
|||
that only matches the `catch-all` FlowSchema will be rejected with an HTTP 429
|
||||
error.
|
||||
|
||||
## Health check concurrency exemption
|
||||
|
||||
The suggested configuration gives no special treatment to the health
|
||||
check requests on kube-apiservers from their local kubelets --- which
|
||||
tend to use the secured port but supply no credentials. With the
|
||||
suggested config, these requests get assigned to the `global-default`
|
||||
FlowSchema and the corresponding `global-default` priority level,
|
||||
where other traffic can crowd them out.
|
||||
|
||||
If you add the following additional FlowSchema, this exempts those
|
||||
requests from rate limiting.
|
||||
|
||||
{{< caution >}}
|
||||
|
||||
Making this change also allows any hostile party to then send
|
||||
health-check requests that match this FlowSchema, at any volume they
|
||||
like. If you have a web traffic filter or similar external security
|
||||
mechanism to protect your cluster's API server from general internet
|
||||
traffic, you can configure rules to block any health check requests
|
||||
that originate from outside your cluster.
|
||||
|
||||
{{< /caution >}}
|
||||
|
||||
{{< codenew file="priority-and-fairness/health-for-strangers.yaml" >}}
|
||||
|
||||
## Resources
|
||||
The flow control API involves two kinds of resources.
|
||||
[PriorityLevelConfigurations](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io)
|
||||
|
|
|
|||
|
|
@ -259,7 +259,7 @@ EOF
|
|||
This needs to be done for each pod that is using a private registry.
|
||||
|
||||
However, setting of this field can be automated by setting the imagePullSecrets
|
||||
in a [ServiceAccount](/docs/tasks/configure-pod-container/configure-service-accounts/) resource.
|
||||
in a [ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/) resource.
|
||||
|
||||
Check [Add ImagePullSecrets to a Service Account](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) for detailed instructions.
|
||||
|
||||
|
|
|
|||
|
|
@ -97,7 +97,7 @@ This diagram shows the extension points in a Kubernetes system.
|
|||
1. Users often interact with the Kubernetes API using `kubectl`. [Kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/) extend the kubectl binary. They only affect the individual user's local environment, and so cannot enforce site-wide policies.
|
||||
2. The apiserver handles all requests. Several types of extension points in the apiserver allow authenticating requests, or blocking them based on their content, editing content, and handling deletion. These are described in the [API Access Extensions](/docs/concepts/extend-kubernetes/#api-access-extensions) section.
|
||||
3. The apiserver serves various kinds of *resources*. *Built-in resource kinds*, like `pods`, are defined by the Kubernetes project and can't be changed. You can also add resources that you define, or that other projects have defined, called *Custom Resources*, as explained in the [Custom Resources](/docs/concepts/extend-kubernetes/#user-defined-types) section. Custom Resources are often used with API Access Extensions.
|
||||
4. The Kubernetes scheduler decides which nodes to place pods on. There are several ways to extend scheduling. These are described in the [Scheduler Extensions](/docs/concepts/overview/extending#scheduler-extensions) section.
|
||||
4. The Kubernetes scheduler decides which nodes to place pods on. There are several ways to extend scheduling. These are described in the [Scheduler Extensions](/docs/concepts/extend-kubernetes/#scheduler-extensions) section.
|
||||
5. Much of the behavior of Kubernetes is implemented by programs called Controllers which are clients of the API-Server. Controllers are often used in conjunction with Custom Resources.
|
||||
6. The kubelet runs on servers, and helps pods appear like virtual servers with their own IPs on the cluster network. [Network Plugins](/docs/concepts/extend-kubernetes/#network-plugins) allow for different implementations of pod networking.
|
||||
7. The kubelet also mounts and unmounts volumes for containers. New types of storage can be supported via [Storage Plugins](/docs/concepts/extend-kubernetes/#storage-plugins).
|
||||
|
|
|
|||
|
|
@ -8,8 +8,6 @@ content_type: concept
|
|||
weight: 50
|
||||
---
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
<!-- overview -->
|
||||
A network policy is a specification of how groups of {{< glossary_tooltip text="pods" term_id="pod">}} are allowed to communicate with each other and other network endpoints.
|
||||
|
||||
|
|
|
|||
|
|
@ -254,6 +254,16 @@ FlexVolume resize is possible only when the underlying driver supports resize.
|
|||
Expanding EBS volumes is a time-consuming operation. Also, there is a per-volume quota of one modification every 6 hours.
|
||||
{{< /note >}}
|
||||
|
||||
#### Recovering from Failure when Expanding Volumes
|
||||
|
||||
If expanding underlying storage fails, the cluster administrator can manually recover the Persistent Volume Claim (PVC) state and cancel the resize requests. Otherwise, the resize requests are continuously retried by the controller without administrator intervention.
|
||||
|
||||
1. Mark the PersistentVolume(PV) that is bound to the PersistentVolumeClaim(PVC) with `Retain` reclaim policy.
|
||||
2. Delete the PVC. Since PV has `Retain` reclaim policy - we will not loose any data when we recreate the PVC.
|
||||
3. Delete the `claimRef` entry from PV specs, so as new PVC can bind to it. This should make the PV `Available`.
|
||||
4. Re-create the PVC with smaller size than PV and set `volumeName` field of the PVC to the name of the PV. This should bind new PVC to existing PV.
|
||||
5. Don't forget to restore the reclaim policy of the PV.
|
||||
|
||||
|
||||
## Types of Persistent Volumes
|
||||
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ A _Pod_ (as in a pod of whales or pea pod) is a group of one or more
|
|||
for how to run the containers. A Pod's contents are always co-located and
|
||||
co-scheduled, and run in a shared context. A Pod models an
|
||||
application-specific "logical host": it contains one or more application
|
||||
containers which are relatively tightly coupled.
|
||||
containers which are relatively tightly coupled.
|
||||
In non-cloud contexts, applications executed on the same physical or virtual machine are analogous to cloud applications executed on the same logical host.
|
||||
|
||||
As well as application containers, a Pod can contain
|
||||
|
|
@ -51,7 +51,7 @@ with shared namespaces and shared filesystem volumes.
|
|||
|
||||
Usually you don't need to create Pods directly, even singleton Pods. Instead, create them using workload resources such as {{< glossary_tooltip text="Deployment"
|
||||
term_id="deployment" >}} or {{< glossary_tooltip text="Job" term_id="job" >}}.
|
||||
If your Pods need to track state, consider the
|
||||
If your Pods need to track state, consider the
|
||||
{{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} resource.
|
||||
|
||||
Pods in a Kubernetes cluster are used in two main ways:
|
||||
|
|
@ -65,7 +65,7 @@ Pods in a Kubernetes cluster are used in two main ways:
|
|||
tightly coupled and need to share resources. These co-located containers
|
||||
form a single cohesive unit of service—for example, one container serving data
|
||||
stored in a shared volume to the public, while a separate _sidecar_ container
|
||||
refreshes or updates those files.
|
||||
refreshes or updates those files.
|
||||
The Pod wraps these containers, storage resources, and an ephemeral network
|
||||
identity together as a single unit.
|
||||
|
||||
|
|
@ -190,7 +190,7 @@ changing existing code.
|
|||
## Resource sharing and communication
|
||||
|
||||
Pods enable data sharing and communication among their constituent
|
||||
containters.
|
||||
containers.
|
||||
|
||||
### Storage in Pods {#pod-storage}
|
||||
|
||||
|
|
@ -257,8 +257,8 @@ but cannot be controlled from there.
|
|||
* Lean about [RuntimeClass](/docs/concepts/containers/runtime-class/) and how you can use it to
|
||||
configure different Pods with different container runtime configurations.
|
||||
* Read about [Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/).
|
||||
* Read about [PodDisruptionBudget](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/) and how you can use it to manage application availability during disruptions.
|
||||
* Pod is a top-level resource in the Kubernetes REST API.
|
||||
* Read about [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) and how you can use it to manage application availability during disruptions.
|
||||
* Pod is a top-level resource in the Kubernetes REST API.
|
||||
The [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
|
||||
object definition describes the object in detail.
|
||||
* [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) explains common layouts for Pods with more than one container.
|
||||
|
|
|
|||
|
|
@ -78,7 +78,7 @@ Here are the possible values for `phase`:
|
|||
|
||||
Value | Description
|
||||
:-----|:-----------
|
||||
`Pending` | The Pod has been accepted by the Kubernetes cluster, but one or more of the containers has not been set up and made ready to run. This includes time a Pod spends waiting to bescheduled as well as the time spent downloading container images over the network.
|
||||
`Pending` | The Pod has been accepted by the Kubernetes cluster, but one or more of the containers has not been set up and made ready to run. This includes time a Pod spends waiting to be scheduled as well as the time spent downloading container images over the network.
|
||||
`Running` | The Pod has been bound to a node, and all of the containers have been created. At least one container is still running, or is in the process of starting or restarting.
|
||||
`Succeeded` | All containers in the Pod have terminated in success, and will not be restarted.
|
||||
`Failed` | All containers in the Pod have terminated, and at least one container has terminated in failure. That is, the container either exited with non-zero status or was terminated by the system.
|
||||
|
|
@ -392,7 +392,7 @@ An example flow:
|
|||
### Forced Pod termination {#pod-termination-forced}
|
||||
|
||||
{{< caution >}}
|
||||
Forced deletions can be potentially disruptiove for some workloads and their Pods.
|
||||
Forced deletions can be potentially disruptive for some workloads and their Pods.
|
||||
{{< /caution >}}
|
||||
|
||||
By default, all deletes are graceful within 30 seconds. The `kubectl delete` command supports
|
||||
|
|
|
|||
|
|
@ -160,10 +160,10 @@ There are some implicit conventions worth noting here:
|
|||
|
||||
- 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".
|
||||
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 incoming Pod 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".
|
||||
|
||||
- Be aware of what will happen if the incomingPod’s `topologySpreadConstraints[*].labelSelector` doesn’t match its own labels. In the above example, if we remove the incoming Pod’s labels, it can still be placed onto "zoneB" since the constraints are still satisfied. However, after the placement, the degree of imbalance of the cluster remains unchanged - it’s still zoneA having 2 Pods which hold label {foo:bar}, and zoneB having 1 Pod which holds label {foo:bar}. So if this is not what you expect, we recommend the workload’s `topologySpreadConstraints[*].labelSelector` to match its own labels.
|
||||
- Be aware of what will happen if the incoming Pod’s `topologySpreadConstraints[*].labelSelector` doesn’t match its own labels. In the above example, if we remove the incoming Pod’s labels, it can still be placed onto "zoneB" since the constraints are still satisfied. However, after the placement, the degree of imbalance of the cluster remains unchanged - it’s still zoneA having 2 Pods which hold label {foo:bar}, and zoneB having 1 Pod which holds label {foo:bar}. So if this is not what you expect, we recommend the workload’s `topologySpreadConstraints[*].labelSelector` to match its own labels.
|
||||
|
||||
- If the incoming Pod has `spec.nodeSelector` or `spec.affinity.nodeAffinity` defined, nodes not matching them will be bypassed.
|
||||
|
||||
|
|
|
|||
|
|
@ -53,7 +53,7 @@ roles and permissions.
|
|||
|
||||
- Read the [Contribution overview](/docs/contribute/new-content/overview/) to
|
||||
learn about the different ways you can contribute.
|
||||
- Check [kubernetes/website issues list](/https://github.com/kubernetes/website/issues/)
|
||||
- Check [`kubernetes/website` issues list](https://github.com/kubernetes/website/issues/)
|
||||
for issues that make good entry points.
|
||||
- [Open a pull request using GitHub](/docs/contribute/new-content/open-a-pr/#changes-using-github)
|
||||
to existing documentation and learn more about filing issues in GitHub.
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ client libraries:
|
|||
## CLI Reference
|
||||
|
||||
* [kubectl](/docs/reference/kubectl/overview/) - Main CLI tool for running commands and managing Kubernetes clusters.
|
||||
* [JSONPath](/docs/reference/kubectl/jsonpath/) - Syntax guide for using [JSONPath expressions](http://goessner.net/articles/JsonPath/) with kubectl.
|
||||
* [JSONPath](/docs/reference/kubectl/jsonpath/) - Syntax guide for using [JSONPath expressions](https://goessner.net/articles/JsonPath/) with kubectl.
|
||||
* [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) - CLI tool to easily provision a secure Kubernetes cluster.
|
||||
|
||||
## Components Reference
|
||||
|
|
@ -50,6 +50,8 @@ client libraries:
|
|||
|
||||
## Design Docs
|
||||
|
||||
An archive of the design docs for Kubernetes functionality. Good starting points are [Kubernetes Architecture](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) and [Kubernetes Design Overview](https://git.k8s.io/community/contributors/design-proposals).
|
||||
An archive of the design docs for Kubernetes functionality. Good starting points are
|
||||
[Kubernetes Architecture](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) and
|
||||
[Kubernetes Design Overview](https://git.k8s.io/community/contributors/design-proposals).
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,4 @@
|
|||
---
|
||||
title: Accessing the API
|
||||
weight: 20
|
||||
toc-hide: true
|
||||
---
|
||||
|
|
@ -18,7 +18,7 @@ Attribute-based access control (ABAC) defines an access control paradigm whereby
|
|||
|
||||
To enable `ABAC` mode, specify `--authorization-policy-file=SOME_FILENAME` and `--authorization-mode=ABAC` on startup.
|
||||
|
||||
The file format is [one JSON object per line](http://jsonlines.org/). There
|
||||
The file format is [one JSON object per line](https://jsonlines.org/). There
|
||||
should be no enclosing list or map, just one map per line.
|
||||
|
||||
Each line is a "policy object", where each such object is a map with the following
|
||||
|
|
@ -127,7 +127,7 @@ up the verbosity:
|
|||
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"group": "system:unauthenticated", "readonly": true, "nonResourcePath": "*"}}
|
||||
```
|
||||
|
||||
[Complete file example](http://releases.k8s.io/{{< param "githubbranch" >}}/pkg/auth/authorizer/abac/example_policy_file.jsonl)
|
||||
[Complete file example](https://releases.k8s.io/{{< param "githubbranch" >}}/pkg/auth/authorizer/abac/example_policy_file.jsonl)
|
||||
|
||||
## A quick note on service accounts
|
||||
|
||||
|
|
|
|||
|
|
@ -25,8 +25,8 @@ is authenticated and authorized. The controllers consist of the
|
|||
`kube-apiserver` binary, and may only be configured by the cluster
|
||||
administrator. In that list, there are two special controllers:
|
||||
MutatingAdmissionWebhook and ValidatingAdmissionWebhook. These execute the
|
||||
mutating and validating (respectively) [admission control
|
||||
webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)
|
||||
mutating and validating (respectively)
|
||||
[admission control webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)
|
||||
which are configured in the API.
|
||||
|
||||
Admission controllers may be "validating", "mutating", or both. Mutating
|
||||
|
|
@ -351,7 +351,10 @@ plugins:
|
|||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
The ImagePolicyWebhook config file must reference a [kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) formatted file which sets up the connection to the backend. It is required that the backend communicate over TLS.
|
||||
The ImagePolicyWebhook config file must reference a
|
||||
[kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
|
||||
formatted file which sets up the connection to the backend.
|
||||
It is required that the backend communicate over TLS.
|
||||
|
||||
The kubeconfig file's cluster field must point to the remote service, and the user field must contain the returned authorizer.
|
||||
|
||||
|
|
@ -371,7 +374,8 @@ users:
|
|||
client-key: /path/to/key.pem # key matching the cert
|
||||
```
|
||||
|
||||
For additional HTTP configuration, refer to the [kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) documentation.
|
||||
For additional HTTP configuration, refer to the
|
||||
[kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) documentation.
|
||||
|
||||
#### Request Payloads
|
||||
|
||||
|
|
@ -454,7 +458,8 @@ your Kubernetes deployment, you MUST use this admission controller to enforce th
|
|||
be used to apply default resource requests to Pods that don't specify any; currently, the default LimitRanger
|
||||
applies a 0.1 CPU requirement to all Pods in the `default` namespace.
|
||||
|
||||
See the [limitRange design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) and the [example of Limit Range](/docs/tasks/configure-pod-container/limit-range/) for more details.
|
||||
See the [limitRange design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md)
|
||||
and the [example of Limit Range](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/) for more details.
|
||||
|
||||
### MutatingAdmissionWebhook {#mutatingadmissionwebhook}
|
||||
|
||||
|
|
@ -731,16 +736,30 @@ for more information.
|
|||
|
||||
### SecurityContextDeny {#securitycontextdeny}
|
||||
|
||||
This admission controller will deny any pod that attempts to set certain escalating [SecurityContext](/docs/user-guide/security-context) fields. This should be enabled if a cluster doesn't utilize [pod security policies](/docs/user-guide/pod-security-policy) to restrict the set of values a security context can take.
|
||||
This admission controller will deny any pod that attempts to set certain escalating
|
||||
[SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core)
|
||||
fields, as shown in the
|
||||
[Configure a Security Context for a Pod or Container](/docs/tasks/configure-pod-container/security-context/)
|
||||
task.
|
||||
This should be enabled if a cluster doesn't utilize
|
||||
[pod security policies](/docs/concepts/policy/pod-security-policy/)
|
||||
to restrict the set of values a security context can take.
|
||||
|
||||
### ServiceAccount {#serviceaccount}
|
||||
|
||||
This admission controller implements automation for [serviceAccounts](/docs/user-guide/service-accounts).
|
||||
This admission controller implements automation for
|
||||
[serviceAccounts](/docs/tasks/configure-pod-container/configure-service-account/).
|
||||
We strongly recommend using this admission controller if you intend to make use of Kubernetes `ServiceAccount` objects.
|
||||
|
||||
### StorageObjectInUseProtection
|
||||
|
||||
The `StorageObjectInUseProtection` plugin adds the `kubernetes.io/pvc-protection` or `kubernetes.io/pv-protection` finalizers to newly created Persistent Volume Claims (PVCs) or Persistent Volumes (PV). In case a user deletes a PVC or PV the PVC or PV is not removed until the finalizer is removed from the PVC or PV by PVC or PV Protection Controller. Refer to the [Storage Object in Use Protection](/docs/concepts/storage/persistent-volumes/#storage-object-in-use-protection) for more detailed information.
|
||||
The `StorageObjectInUseProtection` plugin adds the `kubernetes.io/pvc-protection` or `kubernetes.io/pv-protection`
|
||||
finalizers to newly created Persistent Volume Claims (PVCs) or Persistent Volumes (PV).
|
||||
In case a user deletes a PVC or PV the PVC or PV is not removed until the finalizer is removed
|
||||
from the PVC or PV by PVC or PV Protection Controller.
|
||||
Refer to the
|
||||
[Storage Object in Use Protection](/docs/concepts/storage/persistent-volumes/#storage-object-in-use-protection)
|
||||
for more detailed information.
|
||||
|
||||
### TaintNodesByCondition {#taintnodesbycondition}
|
||||
|
||||
|
|
|
|||
|
|
@ -20,13 +20,24 @@ This page provides an overview of authenticating.
|
|||
All Kubernetes clusters have two categories of users: service accounts managed
|
||||
by Kubernetes, and normal users.
|
||||
|
||||
Normal users are assumed to be managed by an outside, independent service. An
|
||||
admin distributing private keys, a user store like Keystone or Google Accounts,
|
||||
even a file with a list of usernames and passwords. In this regard, _Kubernetes
|
||||
does not have objects which represent normal user accounts._ Normal users
|
||||
cannot be added to a cluster through an API call.
|
||||
It is assumed that a cluster-independent service manages normal users in the following ways:
|
||||
|
||||
Even though normal user cannot be added via an API call, but any user that presents a valid certificate signed by the cluster’s certificate authority (CA) is considered authenticated. In this configuration, Kubernetes determines the username from the common name field in the ‘subject’ of the cert (e.g., “/CN=bob”). From there, the role based access control (RBAC) sub-system would determine whether the user is authorized to perform a specific operation on a resource. You can refer to [creating user certificate request](/docs/reference/access-authn-authz/certificate-signing-requests/#user-csr) for more details about this.
|
||||
- an administrator distributing private keys
|
||||
- a user store like Keystone or Google Accounts
|
||||
- a file with a list of usernames and passwords
|
||||
|
||||
In this regard, _Kubernetes does not have objects which represent normal user
|
||||
accounts._ Normal users cannot be added to a cluster through an API call.
|
||||
|
||||
Even though normal user cannot be added via an API call, but any user that
|
||||
presents a valid certificate signed by the cluster’s certificate authority
|
||||
(CA) is considered authenticated. In this configuration, Kubernetes determines
|
||||
the username from the common name field in the ‘subject’ of the cert (e.g.,
|
||||
“/CN=bob”). From there, the role based access control (RBAC) sub-system would
|
||||
determine whether the user is authorized to perform a specific operation on a
|
||||
resource. For more details, refer to the normal users topic in
|
||||
[certificate request](/docs/reference/access-authn-authz/certificate-signing-requests/#normal-user)
|
||||
for more details about this.
|
||||
|
||||
In contrast, service accounts are users managed by the Kubernetes API. They are
|
||||
bound to specific namespaces, and created automatically by the API server or
|
||||
|
|
@ -315,8 +326,12 @@ wish to utilize multiple OAuth clients should explore providers which support th
|
|||
tokens on behalf of another.
|
||||
|
||||
Kubernetes does not provide an OpenID Connect Identity Provider.
|
||||
You can use an existing public OpenID Connect Identity Provider (such as Google, or [others](http://connect2id.com/products/nimbus-oauth-openid-connect-sdk/openid-connect-providers)).
|
||||
Or, you can run your own Identity Provider, such as CoreOS [dex](https://github.com/coreos/dex), [Keycloak](https://github.com/keycloak/keycloak), CloudFoundry [UAA](https://github.com/cloudfoundry/uaa), or Tremolo Security's [OpenUnison](https://github.com/tremolosecurity/openunison).
|
||||
You can use an existing public OpenID Connect Identity Provider (such as Google, or
|
||||
[others](https://connect2id.com/products/nimbus-oauth-openid-connect-sdk/openid-connect-providers)).
|
||||
Or, you can run your own Identity Provider, such as CoreOS [dex](https://github.com/coreos/dex),
|
||||
[Keycloak](https://github.com/keycloak/keycloak),
|
||||
CloudFoundry [UAA](https://github.com/cloudfoundry/uaa), or
|
||||
Tremolo Security's [OpenUnison](https://github.com/tremolosecurity/openunison).
|
||||
|
||||
For an identity provider to work with Kubernetes it must:
|
||||
|
||||
|
|
@ -400,7 +415,7 @@ Webhook authentication is a hook for verifying bearer tokens.
|
|||
* `--authentication-token-webhook-config-file` a configuration file describing how to access the remote webhook service.
|
||||
* `--authentication-token-webhook-cache-ttl` how long to cache authentication decisions. Defaults to two minutes.
|
||||
|
||||
The configuration file uses the [kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)
|
||||
The configuration file uses the [kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
|
||||
file format. Within the file, `clusters` refers to the remote service and
|
||||
`users` refers to the API server webhook. An example would be:
|
||||
|
||||
|
|
|
|||
|
|
@ -138,8 +138,6 @@ field of the returned object is the result of the query.
|
|||
|
||||
```bash
|
||||
kubectl create -f - -o yaml << EOF
|
||||
```
|
||||
```
|
||||
apiVersion: authorization.k8s.io/v1
|
||||
kind: SelfSubjectAccessReview
|
||||
spec:
|
||||
|
|
@ -149,7 +147,10 @@ spec:
|
|||
verb: create
|
||||
namespace: dev
|
||||
EOF
|
||||
```
|
||||
|
||||
The generated `SelfSubjectAccessReview` is:
|
||||
```
|
||||
apiVersion: authorization.k8s.io/v1
|
||||
kind: SelfSubjectAccessReview
|
||||
metadata:
|
||||
|
|
|
|||
|
|
@ -589,7 +589,7 @@ Example of a response to forbid a request, customizing the HTTP status code and
|
|||
When allowing a request, a mutating admission webhook may optionally modify the incoming object as well.
|
||||
This is done using the `patch` and `patchType` fields in the response.
|
||||
The only currently supported `patchType` is `JSONPatch`.
|
||||
See [JSON patch](http://jsonpatch.com/) documentation for more details.
|
||||
See [JSON patch](https://jsonpatch.com/) documentation for more details.
|
||||
For `patchType: JSONPatch`, the `patch` field contains a base64-encoded array of JSON patch operations.
|
||||
|
||||
As an example, a single patch operation that would set `spec.replicas` would be `[{"op": "add", "path": "/spec/replicas", "value": 3}]`
|
||||
|
|
|
|||
|
|
@ -10,8 +10,8 @@ weight: 50
|
|||
---
|
||||
|
||||
<!-- overview -->
|
||||
This is a Cluster Administrator guide to service accounts. It assumes knowledge of
|
||||
the [User Guide to Service Accounts](/docs/user-guide/service-accounts).
|
||||
This is a Cluster Administrator guide to service accounts. You should be familiar with
|
||||
[configuring Kubernetes service accounts](/docs/tasks/configure-pod-container/configure-service-account/).
|
||||
|
||||
Support for authorization and user accounts is planned but incomplete. Sometimes
|
||||
incomplete features are referred to in order to better describe service accounts.
|
||||
|
|
|
|||
|
|
@ -1,5 +1,4 @@
|
|||
---
|
||||
title: Command line tools reference
|
||||
weight: 60
|
||||
toc-hide: true
|
||||
---
|
||||
|
|
|
|||
|
|
@ -417,11 +417,11 @@ Each feature gate is designed for enabling/disabling a specific feature:
|
|||
- `CustomResourceDefaulting`: Enable CRD support for default values in OpenAPI v3 validation schemas.
|
||||
- `CustomResourcePublishOpenAPI`: Enables publishing of CRD OpenAPI specs.
|
||||
- `CustomResourceSubresources`: Enable `/status` and `/scale` subresources
|
||||
on resources created from [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/).
|
||||
on resources created from [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
|
||||
- `CustomResourceValidation`: Enable schema based validation on resources created from
|
||||
[CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/).
|
||||
[CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
|
||||
- `CustomResourceWebhookConversion`: Enable webhook-based conversion
|
||||
on resources created from [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/).
|
||||
on resources created from [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
|
||||
troubleshoot a running Pod.
|
||||
- `DisableAcceleratorUsageMetrics`: [Disable accelerator metrics collected by the kubelet](/docs/concepts/cluster-administration/monitoring.md).
|
||||
- `DevicePlugins`: Enable the [device-plugins](/docs/concepts/cluster-administration/device-plugins/)
|
||||
|
|
@ -475,6 +475,9 @@ Each feature gate is designed for enabling/disabling a specific feature:
|
|||
- `LegacyNodeRoleBehavior`: When disabled, legacy behavior in service load balancers and node disruption will ignore the `node-role.kubernetes.io/master` label in favor of the feature-specific labels provided by `NodeDisruptionExclusion` and `ServiceNodeExclusion`.
|
||||
- `LocalStorageCapacityIsolation`: Enable the consumption of [local ephemeral storage](/docs/concepts/configuration/manage-compute-resources-container/) and also the `sizeLimit` property of an [emptyDir volume](/docs/concepts/storage/volumes/#emptydir).
|
||||
- `LocalStorageCapacityIsolationFSQuotaMonitoring`: When `LocalStorageCapacityIsolation` is enabled for [local ephemeral storage](/docs/concepts/configuration/manage-compute-resources-container/) and the backing filesystem for [emptyDir volumes](/docs/concepts/storage/volumes/#emptydir) supports project quotas and they are enabled, use project quotas to monitor [emptyDir volume](/docs/concepts/storage/volumes/#emptydir) storage consumption rather than filesystem walk for better performance and accuracy.
|
||||
[local ephemeral storage](/docs/concepts/configuration/manage-resources-containers/) and the backing filesystem for
|
||||
[emptyDir volumes](/docs/concepts/storage/volumes/#emptydir) supports project quotas and they are enabled, use project quotas to monitor
|
||||
[emptyDir volume](/docs/concepts/storage/volumes/#emptydir) storage consumption rather than filesystem walk for better performance and accuracy.
|
||||
- `MountContainers`: Enable using utility containers on host as the volume mounter.
|
||||
- `MountPropagation`: Enable sharing volume mounted by one container to other containers or pods.
|
||||
For more details, please see [mount propagation](/docs/concepts/storage/volumes/#mount-propagation).
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ A tool that lets you use OCI container runtimes with Kubernetes CRI.
|
|||
CRI-O is an implementation of the {{< glossary_tooltip term_id="cri" >}}
|
||||
to enable using {{< glossary_tooltip text="container" term_id="container" >}}
|
||||
runtimes that are compatible with the Open Container Initiative (OCI)
|
||||
[runtime spec](http://www.github.com/opencontainers/runtime-spec).
|
||||
[runtime spec](https://www.github.com/opencontainers/runtime-spec).
|
||||
|
||||
Deploying CRI-O allows Kubernetes to use any OCI-compliant runtime as the container
|
||||
runtime for running {{< glossary_tooltip text="Pods" term_id="pod" >}}, and to fetch
|
||||
|
|
|
|||
|
|
@ -14,4 +14,9 @@ tags:
|
|||
|
||||
<!--more-->
|
||||
|
||||
Some examples of Managed Services are AWS EC2, Azure SQL Database, and GCP Pub/Sub, but they can be any software offering that can be used by an application. [Service Catalog](/docs/concepts/service-catalog/) provides a way to list, provision, and bind with Managed Services offered by {{< glossary_tooltip text="Service Brokers" term_id="service-broker" >}}.
|
||||
Some examples of Managed Services are AWS EC2, Azure SQL Database, and
|
||||
GCP Pub/Sub, but they can be any software offering that can be used by an application.
|
||||
[Service Catalog](/docs/concepts/extend-kubernetes/service-catalog/) provides a way to
|
||||
list, provision, and bind with Managed Services offered by
|
||||
{{< glossary_tooltip text="Service Brokers" term_id="service-broker" >}}.
|
||||
|
||||
|
|
|
|||
|
|
@ -14,5 +14,10 @@ tags:
|
|||
|
||||
<!--more-->
|
||||
|
||||
A platform developer may, for example, use [Custom Resources](/docs/concepts/api-extension/custom-resources/) or [Extend the Kubernetes API with the aggregation layer](/docs/concepts/api-extension/apiserver-aggregation/) to add functionality to their instance of Kubernetes, specifically for their application. Some Platform Developers are also {{< glossary_tooltip text="contributors" term_id="contributor" >}} and develop extensions which are contributed to the Kubernetes community. Others develop closed-source commercial or site-specific extensions.
|
||||
A platform developer may, for example, use [Custom Resources](/docs/concepts/extend-Kubernetes/api-extension/custom-resources/) or
|
||||
[Extend the Kubernetes API with the aggregation layer](/docs/concepts/extend-Kubernetes/api-extension/apiserver-aggregation/)
|
||||
to add functionality to their instance of Kubernetes, specifically for their application.
|
||||
Some Platform Developers are also {{< glossary_tooltip text="contributors" term_id="contributor" >}} and
|
||||
develop extensions which are contributed to the Kubernetes community.
|
||||
Others develop closed-source commercial or site-specific extensions.
|
||||
|
||||
|
|
|
|||
|
|
@ -14,4 +14,9 @@ tags:
|
|||
|
||||
<!--more-->
|
||||
|
||||
{{< glossary_tooltip text="Service Brokers" term_id="service-broker" >}} implement the [Open Service Broker API spec](https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md) and provide a standard interface for applications to use their Managed Services. [Service Catalog](/docs/concepts/service-catalog/) provides a way to list, provision, and bind with Managed Services offered by Service Brokers.
|
||||
{{< glossary_tooltip text="Service Brokers" term_id="service-broker" >}} implement the
|
||||
[Open Service Broker API spec](https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md)
|
||||
and provide a standard interface for applications to use their Managed Services.
|
||||
[Service Catalog](/docs/concepts/extend-kubernetes/service-catalog/) provides a way to
|
||||
list, provision, and bind with Managed Services offered by Service Brokers.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,4 @@
|
|||
---
|
||||
title: Kubernetes Issues and Security
|
||||
weight: 10
|
||||
toc-hide: true
|
||||
---
|
||||
|
|
@ -204,6 +204,13 @@ kubectl get events --sort-by=.metadata.creationTimestamp
|
|||
|
||||
# Compares the current state of the cluster against the state that the cluster would be in if the manifest was applied.
|
||||
kubectl diff -f ./my-manifest.yaml
|
||||
|
||||
# Produce a period-delimited tree of all keys returned for nodes
|
||||
# Helpful when locating a key within a complex nested JSON structure
|
||||
kubectl get nodes -o json | jq -c 'path(..)|[.[]|tostring]|join(".")'
|
||||
|
||||
# Produce a period-delimited tree of all keys returned for pods, etc
|
||||
kubectl get pods -o json | jq -c 'path(..)|[.[]|tostring]|join(".")'
|
||||
```
|
||||
|
||||
## Updating Resources
|
||||
|
|
|
|||
|
|
@ -10,11 +10,16 @@ card:
|
|||
---
|
||||
|
||||
<!-- overview -->
|
||||
The kubectl command line tool lets you control Kubernetes clusters. For configuration, `kubectl` looks for a file named `config` in the `$HOME/.kube` directory. You can specify other [kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) files by setting the KUBECONFIG environment variable or by setting the [`--kubeconfig`](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) flag.
|
||||
|
||||
This overview covers `kubectl` syntax, describes the command operations, and provides common examples. For details about each command, including all the supported flags and subcommands, see the [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) reference documentation. For installation instructions see [installing kubectl](/docs/tasks/kubectl/install/).
|
||||
|
||||
The kubectl command line tool lets you control Kubernetes clusters.
|
||||
For configuration, `kubectl` looks for a file named `config` in the `$HOME/.kube` directory.
|
||||
You can specify other [kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
|
||||
files by setting the KUBECONFIG environment variable or by setting the
|
||||
[`--kubeconfig`](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) flag.
|
||||
|
||||
This overview covers `kubectl` syntax, describes the command operations, and provides common examples.
|
||||
For details about each command, including all the supported flags and subcommands, see the
|
||||
[kubectl](/docs/reference/generated/kubectl/kubectl-commands/) reference documentation.
|
||||
For installation instructions see [installing kubectl](/docs/tasks/tools/install-kubectl/).
|
||||
|
||||
<!-- body -->
|
||||
|
||||
|
|
@ -28,9 +33,12 @@ kubectl [command] [TYPE] [NAME] [flags]
|
|||
|
||||
where `command`, `TYPE`, `NAME`, and `flags` are:
|
||||
|
||||
* `command`: Specifies the operation that you want to perform on one or more resources, for example `create`, `get`, `describe`, `delete`.
|
||||
* `command`: Specifies the operation that you want to perform on one or more resources,
|
||||
for example `create`, `get`, `describe`, `delete`.
|
||||
|
||||
* `TYPE`: Specifies the [resource type](#resource-types). Resource types are case-insensitive and you can specify the singular, plural, or abbreviated forms. For example, the following commands produce the same output:
|
||||
* `TYPE`: Specifies the [resource type](#resource-types). Resource types are case-insensitive and
|
||||
you can specify the singular, plural, or abbreviated forms.
|
||||
For example, the following commands produce the same output:
|
||||
|
||||
```shell
|
||||
kubectl get pod pod1
|
||||
|
|
@ -208,11 +216,13 @@ In this example, the following command outputs the details for a single pod as a
|
|||
kubectl get pod web-pod-13je7 -o yaml
|
||||
```
|
||||
|
||||
Remember: See the [kubectl](/docs/user-guide/kubectl/) reference documentation for details about which output format is supported by each command.
|
||||
Remember: See the [kubectl](/docs/reference/kubectl/kubectl/) reference documentation
|
||||
for details about which output format is supported by each command.
|
||||
|
||||
#### Custom columns
|
||||
|
||||
To define custom columns and output only the details that you want into a table, you can use the `custom-columns` option. You can choose to define the custom columns inline or use a template file: `-o custom-columns=<spec>` or `-o custom-columns-file=<filename>`.
|
||||
To define custom columns and output only the details that you want into a table, you can use the `custom-columns` option.
|
||||
You can choose to define the custom columns inline or use a template file: `-o custom-columns=<spec>` or `-o custom-columns-file=<filename>`.
|
||||
|
||||
##### Examples
|
||||
|
||||
|
|
@ -496,12 +506,8 @@ kubectl whoami
|
|||
Current user: plugins-user
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* Start using the [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) commands.
|
||||
|
||||
* To find out more about plugins, take a look at the [example cli plugin](https://github.com/kubernetes/sample-cli-plugin).
|
||||
|
|
|
|||
|
|
@ -1,5 +1,4 @@
|
|||
---
|
||||
title: Setup tools reference
|
||||
weight: 50
|
||||
toc-hide: true
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,5 +1,30 @@
|
|||
---
|
||||
title: "Kubeadm"
|
||||
weight: 10
|
||||
toc-hide: true
|
||||
no_list: true
|
||||
content_type: concept
|
||||
card:
|
||||
name: reference
|
||||
weight: 40
|
||||
---
|
||||
|
||||
<img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px">Kubeadm is a tool built to provide `kubeadm init` and `kubeadm join` as best-practice “fast paths” for creating Kubernetes clusters.
|
||||
|
||||
kubeadm performs the actions necessary to get a minimum viable cluster up and running. By design, it cares only about bootstrapping, not about provisioning machines. Likewise, installing various nice-to-have addons, like the Kubernetes Dashboard, monitoring solutions, and cloud-specific addons, is not in scope.
|
||||
|
||||
Instead, we expect higher-level and more tailored tooling to be built on top of kubeadm, and ideally, using kubeadm as the basis of all deployments will make it easier to create conformant clusters.
|
||||
|
||||
## How to install
|
||||
|
||||
To install kubeadm, see the [installation guide](/docs/setup/production-environment/tools/kubeadm/install-kubeadm).
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init) to bootstrap a Kubernetes control-plane node
|
||||
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join) to bootstrap a Kubernetes worker node and join it to the cluster
|
||||
* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade) to upgrade a Kubernetes cluster to a newer version
|
||||
* [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config) if you initialized your cluster using kubeadm v1.7.x or lower, to configure your cluster for `kubeadm upgrade`
|
||||
* [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token) to manage tokens for `kubeadm join`
|
||||
* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
|
||||
* [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version) to print the kubeadm version
|
||||
* [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha) to preview a set of features made available for gathering feedback from the community
|
||||
|
|
|
|||
|
|
@ -15,7 +15,6 @@ However, it might not be obvious _how_ kubeadm does that.
|
|||
|
||||
This document provides additional details on what happen under the hood, with the aim of sharing knowledge on Kubernetes cluster best practices.
|
||||
|
||||
|
||||
<!-- body -->
|
||||
## Core design principles
|
||||
|
||||
|
|
@ -518,6 +517,7 @@ Please note that:
|
|||
- The automatic CSR approval is managed by the csrapprover controller, according with configuration done the `kubeadm init` process
|
||||
|
||||
### (optional) Write init kubelet configuration
|
||||
|
||||
{{< feature-state for_k8s_version="v1.9" state="alpha" >}}
|
||||
|
||||
If kubeadm is invoked with `--feature-gates=DynamicKubeletConfig`:
|
||||
|
|
@ -530,5 +530,3 @@ If kubeadm is invoked with `--feature-gates=DynamicKubeletConfig`:
|
|||
Please note that:
|
||||
|
||||
1. To make dynamic kubelet configuration work, flag `--dynamic-config-dir=/var/lib/kubelet/config/dynamic` should be specified in `/etc/systemd/system/kubelet.service.d/10-kubeadm.conf`
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -3,8 +3,10 @@ reviewers:
|
|||
- luxas
|
||||
- jbeda
|
||||
title: kubeadm alpha
|
||||
content_type: concept
|
||||
weight: 90
|
||||
---
|
||||
|
||||
{{< caution >}}
|
||||
`kubeadm alpha` provides a preview of a set of features made available for gathering feedback
|
||||
from the community. Please try it out and give us feedback!
|
||||
|
|
@ -67,7 +69,6 @@ Use the following command to enable the DynamicKubeletConfiguration feature.
|
|||
{{< tab name="enable-dynamic" include="generated/kubeadm_alpha_kubelet_config_enable-dynamic.md" />}}
|
||||
{{< /tabs >}}
|
||||
|
||||
|
||||
## kubeadm alpha selfhosting pivot {#cmd-selfhosting}
|
||||
|
||||
The subcommand `pivot` can be used to convert a static Pod-hosted control plane into a self-hosted one.
|
||||
|
|
@ -79,8 +80,8 @@ The subcommand `pivot` can be used to convert a static Pod-hosted control plane
|
|||
{{< tab name="pivot" include="generated/kubeadm_alpha_selfhosting_pivot.md" />}}
|
||||
{{< /tabs >}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
## What's next
|
||||
* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) to bootstrap a Kubernetes control-plane node
|
||||
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to connect a node to the cluster
|
||||
* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
|
||||
|
|
|
|||
|
|
@ -6,6 +6,7 @@ title: kubeadm config
|
|||
content_type: concept
|
||||
weight: 50
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
During `kubeadm init`, kubeadm uploads the `ClusterConfiguration` object to your cluster
|
||||
in a ConfigMap called `kubeadm-config` in the `kube-system` namespace. This configuration is then read during
|
||||
|
|
@ -19,30 +20,31 @@ In Kubernetes v1.13.0 and later to list/pull kube-dns images instead of the Core
|
|||
the `--config` method described [here](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-addon)
|
||||
has to be used.
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
## kubeadm config view {#cmd-config-view}
|
||||
|
||||
{{< include "generated/kubeadm_config_view.md" >}}
|
||||
|
||||
## kubeadm config print init-defaults {#cmd-config-print-init-defaults}
|
||||
|
||||
{{< include "generated/kubeadm_config_print_init-defaults.md" >}}
|
||||
|
||||
## kubeadm config print join-defaults {#cmd-config-print-join-defaults}
|
||||
|
||||
{{< include "generated/kubeadm_config_print_join-defaults.md" >}}
|
||||
|
||||
## kubeadm config migrate {#cmd-config-migrate}
|
||||
|
||||
{{< include "generated/kubeadm_config_migrate.md" >}}
|
||||
|
||||
## kubeadm config images list {#cmd-config-images-list}
|
||||
|
||||
{{< include "generated/kubeadm_config_images_list.md" >}}
|
||||
|
||||
## kubeadm config images pull {#cmd-config-images-pull}
|
||||
|
||||
{{< include "generated/kubeadm_config_images_pull.md" >}}
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/) to upgrade a Kubernetes cluster to a newer version
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,9 @@
|
|||
---
|
||||
title: kubeadm init phase
|
||||
weight: 90
|
||||
content_type: concept
|
||||
---
|
||||
|
||||
`kubeadm init phase` enables you to invoke atomic steps of the bootstrap process.
|
||||
Hence, you can let kubeadm do some of the work and you can fill in the gaps
|
||||
if you wish to apply customization.
|
||||
|
|
@ -80,7 +82,6 @@ Use the following phase to create a local etcd instance based on a static Pod fi
|
|||
{{< tab name="local" include="generated/kubeadm_init_phase_etcd_local.md" />}}
|
||||
{{< /tabs >}}
|
||||
|
||||
|
||||
## kubeadm init phase upload-config {#cmd-phase-upload-config}
|
||||
|
||||
You can use this command to upload the kubeadm configuration to your cluster.
|
||||
|
|
@ -93,7 +94,6 @@ Alternatively, you can use [kubeadm config](/docs/reference/setup-tools/kubeadm/
|
|||
{{< tab name="kubelet" include="generated/kubeadm_init_phase_upload-config_kubelet.md" />}}
|
||||
{{< /tabs >}}
|
||||
|
||||
|
||||
## kubeadm init phase upload-certs {#cmd-phase-upload-certs}
|
||||
|
||||
Use the following phase to upload control-plane certificates to the cluster.
|
||||
|
|
@ -103,7 +103,6 @@ By default the certs and encryption key expire after two hours.
|
|||
{{< tab name="upload-certs" include="generated/kubeadm_init_phase_upload-certs.md" />}}
|
||||
{{< /tabs >}}
|
||||
|
||||
|
||||
## kubeadm init phase mark-control-plane {#cmd-phase-mark-control-plane}
|
||||
|
||||
Use the following phase to label and taint the node with the `node-role.kubernetes.io/master=""` key-value pair.
|
||||
|
|
@ -112,7 +111,6 @@ Use the following phase to label and taint the node with the `node-role.kubernet
|
|||
{{< tab name="mark-control-plane" include="generated/kubeadm_init_phase_mark-control-plane.md" />}}
|
||||
{{< /tabs >}}
|
||||
|
||||
|
||||
## kubeadm init phase bootstrap-token {#cmd-phase-bootstrap-token}
|
||||
|
||||
Use the following phase to configure bootstrap tokens.
|
||||
|
|
@ -156,7 +154,8 @@ Please note that kube-dns usage with kubeadm is deprecated as of v1.18 and will
|
|||
For more details on each field in the `v1beta2` configuration you can navigate to our
|
||||
[API reference pages.] (https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2)
|
||||
|
||||
## What's next
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) to bootstrap a Kubernetes control-plane node
|
||||
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to connect a node to the cluster
|
||||
* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
|
||||
|
|
|
|||
|
|
@ -9,12 +9,12 @@ weight: 20
|
|||
<!-- overview -->
|
||||
This command initializes a Kubernetes control-plane node.
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
{{< include "generated/kubeadm_init.md" >}}
|
||||
|
||||
### Init workflow {#init-workflow}
|
||||
|
||||
`kubeadm init` bootstraps a Kubernetes control-plane node by executing the
|
||||
following steps:
|
||||
|
||||
|
|
@ -166,7 +166,7 @@ to download the certificates when additional control-plane nodes are joining, by
|
|||
|
||||
The following phase command can be used to re-upload the certificates after expiration:
|
||||
|
||||
```
|
||||
```shell
|
||||
kubeadm init phase upload-certs --upload-certs --certificate-key=SOME_VALUE --config=SOME_YAML_FILE
|
||||
```
|
||||
|
||||
|
|
@ -175,7 +175,7 @@ If the flag `--certificate-key` is not passed to `kubeadm init` and
|
|||
|
||||
The following command can be used to generate a new key on demand:
|
||||
|
||||
```
|
||||
```shell
|
||||
kubeadm alpha certs certificate-key
|
||||
```
|
||||
|
||||
|
|
@ -226,26 +226,26 @@ token distribution for easier automation. To implement this automation, you must
|
|||
know the IP address that the control-plane node will have after it is started,
|
||||
or use a DNS name or an address of a load balancer.
|
||||
|
||||
1. Generate a token. This token must have the form `<6 character string>.<16
|
||||
character string>`. More formally, it must match the regex:
|
||||
`[a-z0-9]{6}\.[a-z0-9]{16}`.
|
||||
1. Generate a token. This token must have the form `<6 character string>.<16
|
||||
character string>`. More formally, it must match the regex:
|
||||
`[a-z0-9]{6}\.[a-z0-9]{16}`.
|
||||
|
||||
kubeadm can generate a token for you:
|
||||
kubeadm can generate a token for you:
|
||||
|
||||
```shell
|
||||
```shell
|
||||
kubeadm token generate
|
||||
```
|
||||
```
|
||||
|
||||
1. Start both the control-plane node and the worker nodes concurrently with this token.
|
||||
As they come up they should find each other and form the cluster. The same
|
||||
`--token` argument can be used on both `kubeadm init` and `kubeadm join`.
|
||||
1. Start both the control-plane node and the worker nodes concurrently with this token.
|
||||
As they come up they should find each other and form the cluster. The same
|
||||
`--token` argument can be used on both `kubeadm init` and `kubeadm join`.
|
||||
|
||||
1. Similar can be done for `--certificate-key` when joining additional control-plane
|
||||
nodes. The key can be generated using:
|
||||
1. Similar can be done for `--certificate-key` when joining additional control-plane
|
||||
nodes. The key can be generated using:
|
||||
|
||||
```shell
|
||||
kubeadm alpha certs certificate-key
|
||||
```
|
||||
```shell
|
||||
kubeadm alpha certs certificate-key
|
||||
```
|
||||
|
||||
Once the cluster is up, you can grab the admin credentials from the control-plane node
|
||||
at `/etc/kubernetes/admin.conf` and use that to talk to the cluster.
|
||||
|
|
@ -255,8 +255,6 @@ it does not allow the root CA hash to be validated with
|
|||
`--discovery-token-ca-cert-hash` (since it's not generated when the nodes are
|
||||
provisioned). For details, see the [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/).
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [kubeadm init phase](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/) to understand more about
|
||||
|
|
@ -264,4 +262,3 @@ provisioned). For details, see the [kubeadm join](/docs/reference/setup-tools/ku
|
|||
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to bootstrap a Kubernetes worker node and join it to the cluster
|
||||
* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/) to upgrade a Kubernetes cluster to a newer version
|
||||
* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,9 @@
|
|||
---
|
||||
title: kubeadm join phase
|
||||
weight: 90
|
||||
content_type: concept
|
||||
---
|
||||
|
||||
`kubeadm join phase` enables you to invoke atomic steps of the join process.
|
||||
Hence, you can let kubeadm do some of the work and you can fill in the gaps
|
||||
if you wish to apply customization.
|
||||
|
|
@ -56,7 +58,8 @@ Using this phase you can join a node as a control-plane instance.
|
|||
{{< tab name="mark-control-plane" include="generated/kubeadm_join_phase_control-plane-join_mark-control-plane.md" />}}
|
||||
{{< /tabs >}}
|
||||
|
||||
## What's next
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) to bootstrap a Kubernetes control-plane node
|
||||
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to connect a node to the cluster
|
||||
* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
|
||||
|
|
|
|||
|
|
@ -9,7 +9,6 @@ weight: 30
|
|||
<!-- overview -->
|
||||
This command initializes a Kubernetes worker node and joins it to the cluster.
|
||||
|
||||
|
||||
<!-- body -->
|
||||
{{< include "generated/kubeadm_join.md" >}}
|
||||
|
||||
|
|
@ -105,18 +104,18 @@ if the `kubeadm init` command was called with `--upload-certs`.
|
|||
|
||||
**Advantages:**
|
||||
|
||||
- Allows bootstrapping nodes to securely discover a root of trust for the
|
||||
control-plane node even if other worker nodes or the network are compromised.
|
||||
- Allows bootstrapping nodes to securely discover a root of trust for the
|
||||
control-plane node even if other worker nodes or the network are compromised.
|
||||
|
||||
- Convenient to execute manually since all of the information required fits
|
||||
into a single `kubeadm join` command that is easy to copy and paste.
|
||||
- Convenient to execute manually since all of the information required fits
|
||||
into a single `kubeadm join` command that is easy to copy and paste.
|
||||
|
||||
**Disadvantages:**
|
||||
|
||||
- The CA hash is not normally known until the control-plane node has been provisioned,
|
||||
which can make it more difficult to build automated provisioning tools that
|
||||
use kubeadm. By generating your CA in beforehand, you may workaround this
|
||||
limitation.
|
||||
- The CA hash is not normally known until the control-plane node has been provisioned,
|
||||
which can make it more difficult to build automated provisioning tools that
|
||||
use kubeadm. By generating your CA in beforehand, you may workaround this
|
||||
limitation.
|
||||
|
||||
#### Token-based discovery without CA pinning
|
||||
|
||||
|
|
@ -134,18 +133,18 @@ kubeadm join --token abcdef.1234567890abcdef --discovery-token-unsafe-skip-ca-ve
|
|||
|
||||
**Advantages:**
|
||||
|
||||
- Still protects against many network-level attacks.
|
||||
- Still protects against many network-level attacks.
|
||||
|
||||
- The token can be generated ahead of time and shared with the control-plane node and
|
||||
worker nodes, which can then bootstrap in parallel without coordination. This
|
||||
allows it to be used in many provisioning scenarios.
|
||||
- The token can be generated ahead of time and shared with the control-plane node and
|
||||
worker nodes, which can then bootstrap in parallel without coordination. This
|
||||
allows it to be used in many provisioning scenarios.
|
||||
|
||||
**Disadvantages:**
|
||||
|
||||
- If an attacker is able to steal a bootstrap token via some vulnerability,
|
||||
they can use that token (along with network-level access) to impersonate the
|
||||
control-plane node to other bootstrapping nodes. This may or may not be an appropriate
|
||||
tradeoff in your environment.
|
||||
- If an attacker is able to steal a bootstrap token via some vulnerability,
|
||||
they can use that token (along with network-level access) to impersonate the
|
||||
control-plane node to other bootstrapping nodes. This may or may not be an appropriate
|
||||
tradeoff in your environment.
|
||||
|
||||
#### File or HTTPS-based discovery
|
||||
|
||||
|
|
@ -158,21 +157,21 @@ In case the discovery file does not contain credentials, the TLS discovery token
|
|||
|
||||
**Example `kubeadm join` commands:**
|
||||
|
||||
- `kubeadm join --discovery-file path/to/file.conf` (local file)
|
||||
- `kubeadm join --discovery-file path/to/file.conf` (local file)
|
||||
|
||||
- `kubeadm join --discovery-file https://url/file.conf` (remote HTTPS URL)
|
||||
- `kubeadm join --discovery-file https://url/file.conf` (remote HTTPS URL)
|
||||
|
||||
**Advantages:**
|
||||
|
||||
- Allows bootstrapping nodes to securely discover a root of trust for the
|
||||
control-plane node even if the network or other worker nodes are compromised.
|
||||
- Allows bootstrapping nodes to securely discover a root of trust for the
|
||||
control-plane node even if the network or other worker nodes are compromised.
|
||||
|
||||
**Disadvantages:**
|
||||
|
||||
- Requires that you have some way to carry the discovery information from
|
||||
the control-plane node to the bootstrapping nodes. If the discovery file contains credentials
|
||||
you must keep it secret and transfer it over a secure channel. This might be possible with your
|
||||
cloud provider or provisioning tool.
|
||||
- Requires that you have some way to carry the discovery information from
|
||||
the control-plane node to the bootstrapping nodes. If the discovery file contains credentials
|
||||
you must keep it secret and transfer it over a secure channel. This might be possible with your
|
||||
cloud provider or provisioning tool.
|
||||
|
||||
### Securing your installation even more {#securing-more}
|
||||
|
||||
|
|
@ -194,7 +193,9 @@ After that, `kubeadm join` will block until the admin has manually approved the
|
|||
```shell
|
||||
kubectl get csr
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```
|
||||
NAME AGE REQUESTOR CONDITION
|
||||
node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ 18s system:bootstrap:878f07 Pending
|
||||
|
|
@ -203,7 +204,9 @@ node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ 18s system:bootstra
|
|||
```shell
|
||||
kubectl certificate approve node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```
|
||||
certificatesigningrequest "node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ" approved
|
||||
```
|
||||
|
|
@ -211,7 +214,9 @@ certificatesigningrequest "node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ"
|
|||
```shell
|
||||
kubectl get csr
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```
|
||||
NAME AGE REQUESTOR CONDITION
|
||||
node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ 1m system:bootstrap:878f07 Approved,Issued
|
||||
|
|
@ -232,7 +237,9 @@ it off regardless. Doing so will disable the ability to use the `--discovery-tok
|
|||
```shell
|
||||
kubectl -n kube-public get cm cluster-info -o yaml | grep "kubeconfig:" -A11 | grep "apiVersion" -A10 | sed "s/ //" | tee cluster-info.yaml
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```
|
||||
apiVersion: v1
|
||||
kind: Config
|
||||
|
|
@ -276,11 +283,8 @@ kubeadm config print join-defaults
|
|||
|
||||
For details on individual fields in `JoinConfiguration` see [the godoc](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#JoinConfiguration).
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) to bootstrap a Kubernetes control-plane node
|
||||
* [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token/) to manage tokens for `kubeadm join`
|
||||
* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,9 @@
|
|||
---
|
||||
title: kubeadm reset phase
|
||||
weight: 90
|
||||
content_type: concept
|
||||
---
|
||||
|
||||
`kubeadm reset phase` enables you to invoke atomic steps of the node reset process.
|
||||
Hence, you can let kubeadm do some of the work and you can fill in the gaps
|
||||
if you wish to apply customization.
|
||||
|
|
@ -47,7 +49,8 @@ Using this phase you can perform cleanup on this node.
|
|||
{{< tab name="cleanup-node" include="generated/kubeadm_reset_phase_cleanup-node.md" />}}
|
||||
{{< /tabs >}}
|
||||
|
||||
## What's next
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) to bootstrap a Kubernetes control-plane node
|
||||
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to connect a node to the cluster
|
||||
* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
|
||||
|
|
|
|||
|
|
@ -9,7 +9,6 @@ weight: 60
|
|||
<!-- overview -->
|
||||
Performs a best effort revert of changes made by `kubeadm init` or `kubeadm join`.
|
||||
|
||||
|
||||
<!-- body -->
|
||||
{{< include "generated/kubeadm_reset.md" >}}
|
||||
|
||||
|
|
@ -36,9 +35,7 @@ etcdctl del "" --prefix
|
|||
|
||||
See the [etcd documentation](https://github.com/coreos/etcd/tree/master/etcdctl) for more information.
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) to bootstrap a Kubernetes control-plane node
|
||||
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to bootstrap a Kubernetes worker node and join it to the cluster
|
||||
|
||||
|
|
|
|||
|
|
@ -14,8 +14,6 @@ the cluster and a control-plane node, as described in [authenticating with boots
|
|||
`kubeadm init` creates an initial token with a 24-hour TTL. The following commands allow you to manage
|
||||
such a token and also to create and manage new ones.
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
## kubeadm token create {#cmd-token-create}
|
||||
{{< include "generated/kubeadm_token_create.md" >}}
|
||||
|
|
@ -29,8 +27,6 @@ such a token and also to create and manage new ones.
|
|||
## kubeadm token list {#cmd-token-list}
|
||||
{{< include "generated/kubeadm_token_list.md" >}}
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to bootstrap a Kubernetes worker node and join it to the cluster
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,7 @@
|
|||
---
|
||||
title: kubeadm upgrade phase
|
||||
weight: 90
|
||||
content_type: concept
|
||||
---
|
||||
In v1.15.0, kubeadm introduced preliminary support for `kubeadm upgrade node` phases.
|
||||
Phases for other `kubeadm upgrade` sub-commands such as `apply`, could be added in the
|
||||
|
|
@ -18,7 +19,8 @@ be called on a primary control-plane node.
|
|||
{{< tab name="kubelet-config" include="generated/kubeadm_upgrade_node_phase_kubelet-config.md" />}}
|
||||
{{< /tabs >}}
|
||||
|
||||
## What's next
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) to bootstrap a Kubernetes control-plane node
|
||||
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to connect a node to the cluster
|
||||
* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
|
||||
|
|
|
|||
|
|
@ -47,8 +47,6 @@ reports of unexpected results.
|
|||
{{< include "generated/kubeadm_upgrade_node.md" >}}
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config/) if you initialized your cluster using kubeadm v1.7.x or lower, to configure your cluster for `kubeadm upgrade`
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,5 @@ weight: 80
|
|||
<!-- overview -->
|
||||
This command prints the version of kubeadm.
|
||||
|
||||
|
||||
<!-- body -->
|
||||
{{< include "generated/kubeadm_version.md" >}}
|
||||
|
||||
|
|
|
|||
|
|
@ -1,30 +0,0 @@
|
|||
---
|
||||
reviewers:
|
||||
- luxas
|
||||
- jbeda
|
||||
title: Overview of kubeadm
|
||||
weight: 10
|
||||
card:
|
||||
name: reference
|
||||
weight: 40
|
||||
---
|
||||
<img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px">Kubeadm is a tool built to provide `kubeadm init` and `kubeadm join` as best-practice “fast paths” for creating Kubernetes clusters.
|
||||
|
||||
kubeadm performs the actions necessary to get a minimum viable cluster up and running. By design, it cares only about bootstrapping, not about provisioning machines. Likewise, installing various nice-to-have addons, like the Kubernetes Dashboard, monitoring solutions, and cloud-specific addons, is not in scope.
|
||||
|
||||
Instead, we expect higher-level and more tailored tooling to be built on top of kubeadm, and ideally, using kubeadm as the basis of all deployments will make it easier to create conformant clusters.
|
||||
|
||||
## How to install
|
||||
|
||||
To install kubeadm, see the [installation guide](/docs/setup/production-environment/tools/kubeadm/install-kubeadm).
|
||||
|
||||
## What's next
|
||||
|
||||
* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init) to bootstrap a Kubernetes control-plane node
|
||||
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join) to bootstrap a Kubernetes worker node and join it to the cluster
|
||||
* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade) to upgrade a Kubernetes cluster to a newer version
|
||||
* [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config) if you initialized your cluster using kubeadm v1.7.x or lower, to configure your cluster for `kubeadm upgrade`
|
||||
* [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token) to manage tokens for `kubeadm join`
|
||||
* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
|
||||
* [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version) to print the kubeadm version
|
||||
* [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha) to preview a set of features made available for gathering feedback from the community
|
||||
|
|
@ -1,5 +1,4 @@
|
|||
---
|
||||
title: Using the Kubernetes API
|
||||
weight: 10
|
||||
toc-hide: true
|
||||
---
|
||||
|
|
@ -84,7 +84,7 @@ Currently, there are several API groups in use:
|
|||
* The named groups are at REST path `/apis/$GROUP_NAME/$VERSION`, and use `apiVersion: $GROUP_NAME/$VERSION`
|
||||
(for example, `apiVersion: batch/v1`). You can find the full list of supported API groups in [Kubernetes API reference](/docs/reference/).
|
||||
|
||||
The two paths that support extending the API with [custom resources](/docs/concepts/api-extension/custom-resources/) are:
|
||||
The two paths that support extending the API with [custom resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) are:
|
||||
|
||||
- [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)
|
||||
for basic CRUD needs.
|
||||
|
|
|
|||
|
|
@ -19,13 +19,13 @@ You can use a client library for the programming language you are using.
|
|||
Client libraries often handle common tasks such as authentication for you.
|
||||
Most client libraries can discover and use the Kubernetes Service Account to
|
||||
authenticate if the API client is running inside the Kubernetes cluster, or can
|
||||
understand the [kubeconfig file](/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig/)
|
||||
understand the [kubeconfig file](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
|
||||
format to read the credentials and the API Server address.
|
||||
|
||||
## Officially-supported Kubernetes client libraries
|
||||
|
||||
The following client libraries are officially maintained by [Kubernetes SIG API
|
||||
Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery).
|
||||
The following client libraries are officially maintained by
|
||||
[Kubernetes SIG API Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery).
|
||||
|
||||
|
||||
| Language | Client Library | Sample Programs |
|
||||
|
|
|
|||
|
|
@ -289,8 +289,7 @@ API versions are supported in a series of subsequent releases.
|
|||
### REST resources (aka API objects)
|
||||
|
||||
Consider a hypothetical REST resource named Widget, which was present in API v1
|
||||
in the above timeline, and which needs to be deprecated. We
|
||||
[document](/docs/reference/deprecation-policy/) and
|
||||
in the above timeline, and which needs to be deprecated. We document and
|
||||
[announce](https://groups.google.com/forum/#!forum/kubernetes-announce) the
|
||||
deprecation in sync with release X+1. The Widget resource still exists in API
|
||||
version v1 (deprecated) but not in v2alpha1. The Widget resource continues to
|
||||
|
|
|
|||
|
|
@ -29,6 +29,9 @@ when using kubeadm to set up a kubernetes cluster.
|
|||
document assumes these default ports. However, they are configurable through
|
||||
the kubeadm config file.
|
||||
* Each host must [have docker, kubelet, and kubeadm installed](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/).
|
||||
* Each host should have access to the Kubernetes container image registry (`k8s.gcr.io`) or list/pull the required etcd image using
|
||||
`kubeadm config images list/pull`. This guide will setup etcd instances as
|
||||
[static pods](/docs/tasks/configure-pod-container/static-pod/) managed by a kubelet.
|
||||
* Some infrastructure to copy files between hosts. For example `ssh` and `scp`
|
||||
can satisfy this requirement.
|
||||
|
||||
|
|
|
|||
|
|
@ -122,7 +122,7 @@ kube-system kube-ui ClusterIP 10.0.0.3 <none>
|
|||
...
|
||||
```
|
||||
|
||||
Similarly, you can take a look at the set of [pods](/docs/concepts/workloads/pods/pod/) that were created during cluster startup.
|
||||
Similarly, you can take a look at the set of [pods](/docs/concepts/workloads/pods/) that were created during cluster startup.
|
||||
You can do this via the
|
||||
|
||||
```shell
|
||||
|
|
|
|||
|
|
@ -8,9 +8,6 @@ content_type: concept
|
|||
|
||||
This topic discusses multiple ways to interact with clusters.
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Accessing for the first time with kubectl
|
||||
|
|
@ -29,8 +26,9 @@ Check the location and credentials that kubectl knows about with this command:
|
|||
kubectl config view
|
||||
```
|
||||
|
||||
Many of the [examples](/docs/user-guide/kubectl-cheatsheet) provide an introduction to using
|
||||
kubectl and complete documentation is found in the [kubectl manual](/docs/user-guide/kubectl-overview).
|
||||
Many of the [examples](/docs/reference/kubectl/cheatsheet/) provide an introduction to using
|
||||
kubectl and complete documentation is found in the
|
||||
[kubectl manual](/docs/reference/kubectl/overview/).
|
||||
|
||||
## Directly accessing the REST API
|
||||
|
||||
|
|
@ -165,7 +163,7 @@ client libraries.
|
|||
* To get the library, run the following command: `go get k8s.io/client-go@kubernetes-<kubernetes-version-number>`, see [INSTALL.md](https://github.com/kubernetes/client-go/blob/master/INSTALL.md#for-the-casual-user) for detailed installation instructions. See [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go#compatibility-matrix) to see which versions are supported.
|
||||
* Write an application atop of the client-go clients. Note that client-go defines its own API objects, so if needed, please import API definitions from client-go rather than from the main repository, e.g., `import "k8s.io/client-go/kubernetes"` is correct.
|
||||
|
||||
The Go client can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)
|
||||
The Go client can use the same [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
|
||||
as the kubectl CLI does to locate and authenticate to the apiserver. See this [example](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go).
|
||||
|
||||
If the application is deployed as a Pod in the cluster, please refer to the [next section](#accessing-the-api-from-a-pod).
|
||||
|
|
@ -174,7 +172,7 @@ If the application is deployed as a Pod in the cluster, please refer to the [nex
|
|||
|
||||
To use [Python client](https://github.com/kubernetes-client/python), run the following command: `pip install kubernetes`. See [Python Client Library page](https://github.com/kubernetes-client/python) for more installation options.
|
||||
|
||||
The Python client can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)
|
||||
The Python client can use the same [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
|
||||
as the kubectl CLI does to locate and authenticate to the apiserver. See this [example](https://github.com/kubernetes-client/python/tree/master/examples).
|
||||
|
||||
### Other languages
|
||||
|
|
@ -219,7 +217,9 @@ In each case, the credentials of the pod are used to communicate securely with t
|
|||
|
||||
The previous section was about connecting the Kubernetes API server. This section is about
|
||||
connecting to other services running on Kubernetes cluster. In Kubernetes, the
|
||||
[nodes](/docs/admin/node), [pods](/docs/user-guide/pods) and [services](/docs/user-guide/services) all have
|
||||
[nodes](/docs/concepts/architecture/nodes/),
|
||||
[pods](/docs/concepts/workloads/pods/) and
|
||||
[services](/docs/concepts/services-networking/service/) all have
|
||||
their own IPs. In many cases, the node IPs, pod IPs, and some service IPs on a cluster will not be
|
||||
routable, so they will not be reachable from a machine outside the cluster,
|
||||
such as your desktop machine.
|
||||
|
|
@ -230,7 +230,7 @@ You have several options for connecting to nodes, pods and services from outside
|
|||
|
||||
- Access services through public IPs.
|
||||
- Use a service with type `NodePort` or `LoadBalancer` to make the service reachable outside
|
||||
the cluster. See the [services](/docs/user-guide/services) and
|
||||
the cluster. See the [services](/docs/concepts/services-networking/service/) and
|
||||
[kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) documentation.
|
||||
- Depending on your cluster environment, this may just expose the service to your corporate network,
|
||||
or it may expose it to the internet. Think about whether the service being exposed is secure.
|
||||
|
|
|
|||
|
|
@ -7,19 +7,14 @@ weight: 110
|
|||
<!-- overview -->
|
||||
|
||||
This page shows how to use a Volume to communicate between two Containers running
|
||||
in the same Pod. See also how to allow processes to communicate by [sharing process namespace](/docs/tasks/configure-pod-container/share-process-namespace/) between containers.
|
||||
|
||||
|
||||
|
||||
in the same Pod. See also how to allow processes to communicate by
|
||||
[sharing process namespace](/docs/tasks/configure-pod-container/share-process-namespace/)
|
||||
between containers.
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Creating a Pod that runs two Containers
|
||||
|
|
@ -103,14 +98,15 @@ The output is similar to this:
|
|||
Recall that the debian Container created the `index.html` file in the nginx root
|
||||
directory. Use `curl` to send a GET request to the nginx server:
|
||||
|
||||
root@two-containers:/# curl localhost
|
||||
```
|
||||
root@two-containers:/# curl localhost
|
||||
```
|
||||
|
||||
The output shows that nginx serves a web page written by the debian container:
|
||||
|
||||
Hello from the debian container
|
||||
|
||||
|
||||
|
||||
```
|
||||
Hello from the debian container
|
||||
```
|
||||
|
||||
<!-- discussion -->
|
||||
|
||||
|
|
@ -128,20 +124,14 @@ The Volume in this exercise provides a way for Containers to communicate during
|
|||
the life of the Pod. If the Pod is deleted and recreated, any data stored in
|
||||
the shared Volume is lost.
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* Learn more about
|
||||
[patterns for composite containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns).
|
||||
* Learn more about [patterns for composite containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns).
|
||||
|
||||
* Learn about
|
||||
[composite containers for modular architecture](http://www.slideshare.net/Docker/slideshare-burns).
|
||||
* Learn about [composite containers for modular architecture](https://www.slideshare.net/Docker/slideshare-burns).
|
||||
|
||||
* See
|
||||
[Configuring a Pod to Use a Volume for Storage](/docs/tasks/configure-pod-container/configure-volume-storage/).
|
||||
* See [Configuring a Pod to Use a Volume for Storage](/docs/tasks/configure-pod-container/configure-volume-storage/).
|
||||
|
||||
* See [Configure a Pod to share process namespace between containers in a Pod](/docs/tasks/configure-pod-container/share-process-namespace/)
|
||||
|
||||
|
|
@ -149,7 +139,3 @@ the shared Volume is lost.
|
|||
|
||||
* See [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -11,33 +11,21 @@ microservice. The backend microservice is a hello greeter. The
|
|||
frontend and backend are connected using a Kubernetes
|
||||
{{< glossary_tooltip term_id="service" >}} object.
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "objectives" %}}
|
||||
|
||||
|
||||
* Create and run a microservice using a {{< glossary_tooltip term_id="deployment" >}} object.
|
||||
* Route traffic to the backend using a frontend.
|
||||
* Use a Service object to connect the frontend application to the
|
||||
backend application.
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
* This task uses
|
||||
[Services with external load balancers](/docs/tasks/access-application-cluster/create-external-load-balancer/), which
|
||||
require a supported environment. If your environment does not
|
||||
support this, you can use a Service of type
|
||||
[NodePort](/docs/concepts/services-networking/service/#nodeport) instead.
|
||||
|
||||
|
||||
|
||||
This task uses
|
||||
[Services with external load balancers](/docs/tasks/access-application-cluster/create-external-load-balancer/), which
|
||||
require a supported environment. If your environment does not support this, you can use a Service of type
|
||||
[NodePort](/docs/concepts/services-networking/service/#nodeport) instead.
|
||||
|
||||
<!-- lessoncontent -->
|
||||
|
||||
|
|
@ -153,8 +141,8 @@ service/frontend created
|
|||
```
|
||||
|
||||
{{< note >}}
|
||||
The nginx configuration is baked into the [container
|
||||
image](/examples/service/access/Dockerfile). A better way to do this would
|
||||
The nginx configuration is baked into the
|
||||
[container image](/examples/service/access/Dockerfile). A better way to do this would
|
||||
be to use a
|
||||
[ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/),
|
||||
so that you can change the configuration more easily.
|
||||
|
|
@ -203,27 +191,22 @@ The output shows the message generated by the backend:
|
|||
{"message":"Hello"}
|
||||
```
|
||||
|
||||
|
||||
|
||||
## {{% heading "cleanup" %}}
|
||||
|
||||
|
||||
To delete the Services, enter this command:
|
||||
|
||||
kubectl delete services frontend hello
|
||||
```shell
|
||||
kubectl delete services frontend hello
|
||||
```
|
||||
|
||||
To delete the Deployments, the ReplicaSets and the Pods that are running the backend and frontend applications, enter this command:
|
||||
|
||||
kubectl delete deployment frontend hello
|
||||
|
||||
|
||||
```shell
|
||||
kubectl delete deployment frontend hello
|
||||
```
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* Learn more about [Services](/docs/concepts/services-networking/service/)
|
||||
* Learn more about [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/)
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ weight: 100
|
|||
|
||||
<!-- overview -->
|
||||
|
||||
An [Ingress](/docs/concepts/services-networking/ingress/) is an API object that defines rules which allow external access
|
||||
An [Ingress](/docs/concepts/services-networking/ingress/) is an API object that defines rules which allow external access
|
||||
to services in a cluster. An [Ingress controller](/docs/concepts/services-networking/ingress-controllers/) fulfills the rules set in the Ingress.
|
||||
|
||||
This page shows you how to set up a simple Ingress which routes requests to Service web or web2 depending on the HTTP URI.
|
||||
|
|
@ -41,7 +41,7 @@ This page shows you how to set up a simple Ingress which routes requests to Serv
|
|||
```shell
|
||||
minikube addons enable ingress
|
||||
```
|
||||
|
||||
|
||||
1. Verify that the NGINX Ingress controller is running
|
||||
|
||||
```shell
|
||||
|
|
@ -71,31 +71,31 @@ This page shows you how to set up a simple Ingress which routes requests to Serv
|
|||
```
|
||||
|
||||
Output:
|
||||
|
||||
|
||||
```shell
|
||||
deployment.apps/web created
|
||||
```
|
||||
|
||||
1. Expose the Deployment:
|
||||
1. Expose the Deployment:
|
||||
|
||||
```shell
|
||||
kubectl expose deployment web --type=NodePort --port=8080
|
||||
```
|
||||
|
||||
Output:
|
||||
|
||||
|
||||
Output:
|
||||
|
||||
```shell
|
||||
service/web exposed
|
||||
```
|
||||
|
||||
|
||||
1. Verify the Service is created and is available on a node port:
|
||||
|
||||
```shell
|
||||
kubectl get service web
|
||||
```
|
||||
|
||||
```
|
||||
|
||||
Output:
|
||||
|
||||
|
||||
```shell
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
web NodePort 10.104.133.249 <none> 8080:31637/TCP 12m
|
||||
|
|
@ -106,24 +106,24 @@ This page shows you how to set up a simple Ingress which routes requests to Serv
|
|||
```shell
|
||||
minikube service web --url
|
||||
```
|
||||
|
||||
|
||||
Output:
|
||||
|
||||
|
||||
```shell
|
||||
http://172.17.0.15:31637
|
||||
```
|
||||
|
||||
|
||||
{{< note >}}Katacoda environment only: at the top of the terminal panel, click the plus sign, and then click **Select port to view on Host 1**. Enter the NodePort, in this case `31637`, and then click **Display Port**.{{< /note >}}
|
||||
|
||||
|
||||
Output:
|
||||
|
||||
|
||||
```shell
|
||||
Hello, world!
|
||||
Version: 1.0.0
|
||||
Hostname: web-55b8c6998d-8k564
|
||||
```
|
||||
|
||||
You can now access the sample app via the Minikube IP address and NodePort. The next step lets you access
|
||||
|
||||
You can now access the sample app via the Minikube IP address and NodePort. The next step lets you access
|
||||
the app using the Ingress resource.
|
||||
|
||||
## Create an Ingress resource
|
||||
|
|
@ -132,37 +132,39 @@ The following file is an Ingress resource that sends traffic to your Service via
|
|||
|
||||
1. Create `example-ingress.yaml` from the following file:
|
||||
|
||||
apiVersion: networking.k8s.io/v1beta1
|
||||
kind: Ingress
|
||||
metadata:
|
||||
name: example-ingress
|
||||
annotations:
|
||||
nginx.ingress.kubernetes.io/rewrite-target: /$1
|
||||
spec:
|
||||
rules:
|
||||
- host: hello-world.info
|
||||
http:
|
||||
paths:
|
||||
- path: /
|
||||
backend:
|
||||
serviceName: web
|
||||
servicePort: 8080
|
||||
```yaml
|
||||
apiVersion: networking.k8s.io/v1beta1
|
||||
kind: Ingress
|
||||
metadata:
|
||||
name: example-ingress
|
||||
annotations:
|
||||
nginx.ingress.kubernetes.io/rewrite-target: /$1
|
||||
spec:
|
||||
rules:
|
||||
- host: hello-world.info
|
||||
http:
|
||||
paths:
|
||||
- path: /
|
||||
backend:
|
||||
serviceName: web
|
||||
servicePort: 8080
|
||||
```
|
||||
|
||||
1. Create the Ingress resource by running the following command:
|
||||
|
||||
|
||||
```shell
|
||||
kubectl apply -f example-ingress.yaml
|
||||
```
|
||||
|
||||
|
||||
Output:
|
||||
|
||||
|
||||
```shell
|
||||
ingress.networking.k8s.io/example-ingress created
|
||||
```
|
||||
|
||||
1. Verify the IP address is set:
|
||||
1. Verify the IP address is set:
|
||||
|
||||
```shell
|
||||
```shell
|
||||
kubectl get ingress
|
||||
```
|
||||
|
||||
|
|
@ -173,7 +175,7 @@ The following file is an Ingress resource that sends traffic to your Service via
|
|||
example-ingress hello-world.info 172.17.0.15 80 38s
|
||||
```
|
||||
|
||||
1. Add the following line to the bottom of the `/etc/hosts` file.
|
||||
1. Add the following line to the bottom of the `/etc/hosts` file.
|
||||
|
||||
{{< note >}}If you are running Minikube locally, use `minikube ip` to get the external IP. The IP address displayed within the ingress list will be the internal IP.{{< /note >}}
|
||||
|
||||
|
|
@ -190,7 +192,7 @@ The following file is an Ingress resource that sends traffic to your Service via
|
|||
```
|
||||
|
||||
Output:
|
||||
|
||||
|
||||
```shell
|
||||
Hello, world!
|
||||
Version: 1.0.0
|
||||
|
|
@ -207,26 +209,26 @@ The following file is an Ingress resource that sends traffic to your Service via
|
|||
kubectl create deployment web2 --image=gcr.io/google-samples/hello-app:2.0
|
||||
```
|
||||
Output:
|
||||
|
||||
|
||||
```shell
|
||||
deployment.apps/web2 created
|
||||
```
|
||||
|
||||
|
||||
1. Expose the Deployment:
|
||||
|
||||
```shell
|
||||
kubectl expose deployment web2 --port=8080 --type=NodePort
|
||||
```
|
||||
|
||||
Output:
|
||||
|
||||
Output:
|
||||
|
||||
```shell
|
||||
service/web2 exposed
|
||||
```
|
||||
|
||||
|
||||
## Edit Ingress
|
||||
|
||||
1. Edit the existing `example-ingress.yaml` and add the following lines:
|
||||
1. Edit the existing `example-ingress.yaml` and add the following lines:
|
||||
|
||||
```yaml
|
||||
- path: /v2
|
||||
|
|
@ -241,7 +243,8 @@ The following file is an Ingress resource that sends traffic to your Service via
|
|||
kubectl apply -f example-ingress.yaml
|
||||
```
|
||||
|
||||
Output:
|
||||
Output:
|
||||
|
||||
```shell
|
||||
ingress.networking/example-ingress configured
|
||||
```
|
||||
|
|
@ -255,6 +258,7 @@ The following file is an Ingress resource that sends traffic to your Service via
|
|||
```
|
||||
|
||||
Output:
|
||||
|
||||
```shell
|
||||
Hello, world!
|
||||
Version: 1.0.0
|
||||
|
|
@ -268,6 +272,7 @@ The following file is an Ingress resource that sends traffic to your Service via
|
|||
```
|
||||
|
||||
Output:
|
||||
|
||||
```shell
|
||||
Hello, world!
|
||||
Version: 2.0.0
|
||||
|
|
|
|||
|
|
@ -9,15 +9,10 @@ weight: 100
|
|||
This page shows how to use kubectl to list all of the Container images
|
||||
for Pods running in a cluster.
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
In this exercise you will use kubectl to fetch all of the Pods
|
||||
|
|
@ -30,14 +25,14 @@ of Containers for each.
|
|||
- Format the output to include only the list of Container image names
|
||||
using `-o jsonpath={..image}`. This will recursively parse out the
|
||||
`image` field from the returned json.
|
||||
- See the [jsonpath reference](/docs/user-guide/jsonpath/)
|
||||
- See the [jsonpath reference](/docs/reference/kubectl/jsonpath/)
|
||||
for further information on how to use jsonpath.
|
||||
- Format the output using standard tools: `tr`, `sort`, `uniq`
|
||||
- Use `tr` to replace spaces with newlines
|
||||
- Use `sort` to sort the results
|
||||
- Use `uniq` to aggregate image counts
|
||||
|
||||
```sh
|
||||
```shell
|
||||
kubectl get pods --all-namespaces -o jsonpath="{..image}" |\
|
||||
tr -s '[[:space:]]' '\n' |\
|
||||
sort |\
|
||||
|
|
@ -52,7 +47,7 @@ field within the Pod. This ensures the correct field is retrieved
|
|||
even when the field name is repeated,
|
||||
e.g. many fields are called `name` within a given item:
|
||||
|
||||
```sh
|
||||
```shell
|
||||
kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}"
|
||||
```
|
||||
|
||||
|
|
@ -74,7 +69,7 @@ Pod is returned instead of a list of items.
|
|||
The formatting can be controlled further by using the `range` operation to
|
||||
iterate over elements individually.
|
||||
|
||||
```sh
|
||||
```shell
|
||||
kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\
|
||||
sort
|
||||
```
|
||||
|
|
@ -84,7 +79,7 @@ sort
|
|||
To target only Pods matching a specific label, use the -l flag. The
|
||||
following matches only Pods with labels matching `app=nginx`.
|
||||
|
||||
```sh
|
||||
```shell
|
||||
kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx
|
||||
```
|
||||
|
||||
|
|
@ -93,7 +88,7 @@ kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx
|
|||
To target only pods in a specific namespace, use the namespace flag. The
|
||||
following matches only Pods in the `kube-system` namespace.
|
||||
|
||||
```sh
|
||||
```shell
|
||||
kubectl get pods --namespace kube-system -o jsonpath="{..image}"
|
||||
```
|
||||
|
||||
|
|
@ -102,27 +97,14 @@ kubectl get pods --namespace kube-system -o jsonpath="{..image}"
|
|||
As an alternative to jsonpath, Kubectl supports using [go-templates](https://golang.org/pkg/text/template/)
|
||||
for formatting the output:
|
||||
|
||||
|
||||
```sh
|
||||
```shell
|
||||
kubectl get pods --all-namespaces -o go-template --template="{{range .items}}{{range .spec.containers}}{{.image}} {{end}}{{end}}"
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- discussion -->
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
### Reference
|
||||
|
||||
* [Jsonpath](/docs/user-guide/jsonpath/) reference guide
|
||||
* [Jsonpath](/docs/reference/kubectl/jsonpath/) reference guide
|
||||
* [Go template](https://golang.org/pkg/text/template/) reference guide
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -14,15 +14,19 @@ card:
|
|||
|
||||
<!-- overview -->
|
||||
|
||||
Dashboard is a web-based Kubernetes user interface. You can use Dashboard to deploy containerized applications to a Kubernetes cluster, troubleshoot your containerized application, and manage the cluster resources. You can use Dashboard to get an overview of applications running on your cluster, as well as for creating or modifying individual Kubernetes resources (such as Deployments, Jobs, DaemonSets, etc). For example, you can scale a Deployment, initiate a rolling update, restart a pod or deploy new applications using a deploy wizard.
|
||||
Dashboard is a web-based Kubernetes user interface.
|
||||
You can use Dashboard to deploy containerized applications to a Kubernetes cluster,
|
||||
troubleshoot your containerized application, and manage the cluster resources.
|
||||
You can use Dashboard to get an overview of applications running on your cluster,
|
||||
as well as for creating or modifying individual Kubernetes resources
|
||||
(such as Deployments, Jobs, DaemonSets, etc).
|
||||
For example, you can scale a Deployment, initiate a rolling update, restart a pod
|
||||
or deploy new applications using a deploy wizard.
|
||||
|
||||
Dashboard also provides information on the state of Kubernetes resources in your cluster and on any errors that may have occurred.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Deploying the Dashboard UI
|
||||
|
|
@ -35,8 +39,10 @@ kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0/a
|
|||
|
||||
## Accessing the Dashboard UI
|
||||
|
||||
|
||||
To protect your cluster data, Dashboard deploys with a minimal RBAC configuration by default. Currently, Dashboard only supports logging in with a Bearer Token. To create a token for this demo, you can follow our guide on [creating a sample user](https://github.com/kubernetes/dashboard/blob/master/docs/user/access-control/creating-sample-user.md).
|
||||
To protect your cluster data, Dashboard deploys with a minimal RBAC configuration by default.
|
||||
Currently, Dashboard only supports logging in with a Bearer Token.
|
||||
To create a token for this demo, you can follow our guide on
|
||||
[creating a sample user](https://github.com/kubernetes/dashboard/blob/master/docs/user/access-control/creating-sample-user.md).
|
||||
|
||||
{{< warning >}}
|
||||
The sample user created in the tutorial will have administrative privileges and is for educational purposes only.
|
||||
|
|
@ -59,13 +65,17 @@ Kubeconfig Authentication method does NOT support external identity providers or
|
|||
|
||||
## Welcome view
|
||||
|
||||
When you access Dashboard on an empty cluster, you'll see the welcome page. This page contains a link to this document as well as a button to deploy your first application. In addition, you can view which system applications are running by default in the `kube-system` [namespace](/docs/tasks/administer-cluster/namespaces/) of your cluster, for example the Dashboard itself.
|
||||
When you access Dashboard on an empty cluster, you'll see the welcome page.
|
||||
This page contains a link to this document as well as a button to deploy your first application.
|
||||
In addition, you can view which system applications are running by default in the `kube-system`
|
||||
[namespace](/docs/tasks/administer-cluster/namespaces/) of your cluster, for example the Dashboard itself.
|
||||
|
||||
|
||||
|
||||
## Deploying containerized applications
|
||||
|
||||
Dashboard lets you create and deploy a containerized application as a Deployment and optional Service with a simple wizard. You can either manually specify application details, or upload a YAML or JSON file containing application configuration.
|
||||
Dashboard lets you create and deploy a containerized application as a Deployment and optional Service with a simple wizard.
|
||||
You can either manually specify application details, or upload a YAML or JSON file containing application configuration.
|
||||
|
||||
Click the **CREATE** button in the upper right corner of any page to begin.
|
||||
|
||||
|
|
@ -73,17 +83,29 @@ Click the **CREATE** button in the upper right corner of any page to begin.
|
|||
|
||||
The deploy wizard expects that you provide the following information:
|
||||
|
||||
- **App name** (mandatory): Name for your application. A [label](/docs/concepts/overview/working-with-objects/labels/) with the name will be added to the Deployment and Service, if any, that will be deployed.
|
||||
- **App name** (mandatory): Name for your application.
|
||||
A [label](/docs/concepts/overview/working-with-objects/labels/) with the name will be
|
||||
added to the Deployment and Service, if any, that will be deployed.
|
||||
|
||||
The application name must be unique within the selected Kubernetes [namespace](/docs/tasks/administer-cluster/namespaces/). It must start with a lowercase character, and end with a lowercase character or a number, and contain only lowercase letters, numbers and dashes (-). It is limited to 24 characters. Leading and trailing spaces are ignored.
|
||||
The application name must be unique within the selected Kubernetes [namespace](/docs/tasks/administer-cluster/namespaces/).
|
||||
It must start with a lowercase character, and end with a lowercase character or a number,
|
||||
and contain only lowercase letters, numbers and dashes (-). It is limited to 24 characters.
|
||||
Leading and trailing spaces are ignored.
|
||||
|
||||
- **Container image** (mandatory): The URL of a public Docker [container image](/docs/concepts/containers/images/) on any registry, or a private image (commonly hosted on the Google Container Registry or Docker Hub). The container image specification must end with a colon.
|
||||
- **Container image** (mandatory):
|
||||
The URL of a public Docker [container image](/docs/concepts/containers/images/) on any registry,
|
||||
or a private image (commonly hosted on the Google Container Registry or Docker Hub).
|
||||
The container image specification must end with a colon.
|
||||
|
||||
- **Number of pods** (mandatory): The target number of Pods you want your application to be deployed in. The value must be a positive integer.
|
||||
- **Number of pods** (mandatory): The target number of Pods you want your application to be deployed in.
|
||||
The value must be a positive integer.
|
||||
|
||||
A [Deployment](/docs/concepts/workloads/controllers/deployment/) will be created to maintain the desired number of Pods across your cluster.
|
||||
A [Deployment](/docs/concepts/workloads/controllers/deployment/) will be created to
|
||||
maintain the desired number of Pods across your cluster.
|
||||
|
||||
- **Service** (optional): For some parts of your application (e.g. frontends) you may want to expose a [Service](/docs/concepts/services-networking/service/) onto an external, maybe public IP address outside of your cluster (external Service).
|
||||
- **Service** (optional): For some parts of your application (e.g. frontends) you may want to expose a
|
||||
[Service](/docs/concepts/services-networking/service/) onto an external,
|
||||
maybe public IP address outside of your cluster (external Service).
|
||||
|
||||
{{< note >}}
|
||||
For external Services, you may need to open up one or more ports to do so.
|
||||
|
|
@ -91,13 +113,22 @@ The deploy wizard expects that you provide the following information:
|
|||
|
||||
Other Services that are only visible from inside the cluster are called internal Services.
|
||||
|
||||
Irrespective of the Service type, if you choose to create a Service and your container listens on a port (incoming), you need to specify two ports. The Service will be created mapping the port (incoming) to the target port seen by the container. This Service will route to your deployed Pods. Supported protocols are TCP and UDP. The internal DNS name for this Service will be the value you specified as application name above.
|
||||
Irrespective of the Service type, if you choose to create a Service and your container listens
|
||||
on a port (incoming), you need to specify two ports.
|
||||
The Service will be created mapping the port (incoming) to the target port seen by the container.
|
||||
This Service will route to your deployed Pods. Supported protocols are TCP and UDP.
|
||||
The internal DNS name for this Service will be the value you specified as application name above.
|
||||
|
||||
If needed, you can expand the **Advanced options** section where you can specify more settings:
|
||||
|
||||
- **Description**: The text you enter here will be added as an [annotation](/docs/concepts/overview/working-with-objects/annotations/) to the Deployment and displayed in the application's details.
|
||||
- **Description**: The text you enter here will be added as an
|
||||
[annotation](/docs/concepts/overview/working-with-objects/annotations/)
|
||||
to the Deployment and displayed in the application's details.
|
||||
|
||||
- **Labels**: Default [labels](/docs/concepts/overview/working-with-objects/labels/) to be used for your application are application name and version. You can specify additional labels to be applied to the Deployment, Service (if any), and Pods, such as release, environment, tier, partition, and release track.
|
||||
- **Labels**: Default [labels](/docs/concepts/overview/working-with-objects/labels/) to be used
|
||||
for your application are application name and version.
|
||||
You can specify additional labels to be applied to the Deployment, Service (if any), and Pods,
|
||||
such as release, environment, tier, partition, and release track.
|
||||
|
||||
Example:
|
||||
|
||||
|
|
@ -108,66 +139,111 @@ If needed, you can expand the **Advanced options** section where you can specify
|
|||
track=stable
|
||||
```
|
||||
|
||||
- **Namespace**: Kubernetes supports multiple virtual clusters backed by the same physical cluster. These virtual clusters are called [namespaces](/docs/tasks/administer-cluster/namespaces/). They let you partition resources into logically named groups.
|
||||
- **Namespace**: Kubernetes supports multiple virtual clusters backed by the same physical cluster.
|
||||
These virtual clusters are called [namespaces](/docs/tasks/administer-cluster/namespaces/).
|
||||
They let you partition resources into logically named groups.
|
||||
|
||||
Dashboard offers all available namespaces in a dropdown list, and allows you to create a new namespace. The namespace name may contain a maximum of 63 alphanumeric characters and dashes (-) but can not contain capital letters.
|
||||
Namespace names should not consist of only numbers. If the name is set as a number, such as 10, the pod will be put in the default namespace.
|
||||
Dashboard offers all available namespaces in a dropdown list, and allows you to create a new namespace.
|
||||
The namespace name may contain a maximum of 63 alphanumeric characters and dashes (-) but can not contain capital letters.
|
||||
Namespace names should not consist of only numbers.
|
||||
If the name is set as a number, such as 10, the pod will be put in the default namespace.
|
||||
|
||||
In case the creation of the namespace is successful, it is selected by default. If the creation fails, the first namespace is selected.
|
||||
In case the creation of the namespace is successful, it is selected by default.
|
||||
If the creation fails, the first namespace is selected.
|
||||
|
||||
- **Image Pull Secret**: In case the specified Docker container image is private, it may require [pull secret](/docs/concepts/configuration/secret/) credentials.
|
||||
- **Image Pull Secret**:
|
||||
In case the specified Docker container image is private, it may require
|
||||
[pull secret](/docs/concepts/configuration/secret/) credentials.
|
||||
|
||||
Dashboard offers all available secrets in a dropdown list, and allows you to create a new secret. The secret name must follow the DNS domain name syntax, for example `new.image-pull.secret`. The content of a secret must be base64-encoded and specified in a [`.dockercfg`](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) file. The secret name may consist of a maximum of 253 characters.
|
||||
Dashboard offers all available secrets in a dropdown list, and allows you to create a new secret.
|
||||
The secret name must follow the DNS domain name syntax, for example `new.image-pull.secret`.
|
||||
The content of a secret must be base64-encoded and specified in a
|
||||
[`.dockercfg`](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) file.
|
||||
The secret name may consist of a maximum of 253 characters.
|
||||
|
||||
In case the creation of the image pull secret is successful, it is selected by default. If the creation fails, no secret is applied.
|
||||
|
||||
- **CPU requirement (cores)** and **Memory requirement (MiB)**: You can specify the minimum [resource limits](/docs/tasks/configure-pod-container/limit-range/) for the container. By default, Pods run with unbounded CPU and memory limits.
|
||||
- **CPU requirement (cores)** and **Memory requirement (MiB)**:
|
||||
You can specify the minimum [resource limits](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
|
||||
for the container. By default, Pods run with unbounded CPU and memory limits.
|
||||
|
||||
- **Run command** and **Run command arguments**: By default, your containers run the specified Docker image's default [entrypoint command](/docs/tasks/inject-data-application/define-command-argument-container/). You can use the command options and arguments to override the default.
|
||||
- **Run command** and **Run command arguments**:
|
||||
By default, your containers run the specified Docker image's default
|
||||
[entrypoint command](/docs/tasks/inject-data-application/define-command-argument-container/).
|
||||
You can use the command options and arguments to override the default.
|
||||
|
||||
- **Run as privileged**: This setting determines whether processes in [privileged containers](/docs/user-guide/pods/#privileged-mode-for-pod-containers) are equivalent to processes running as root on the host. Privileged containers can make use of capabilities like manipulating the network stack and accessing devices.
|
||||
- **Run as privileged**: This setting determines whether processes in
|
||||
[privileged containers](/docs/concepts/workloads/pods/#privileged-mode-for-containers)
|
||||
are equivalent to processes running as root on the host.
|
||||
Privileged containers can make use of capabilities like manipulating the network stack and accessing devices.
|
||||
|
||||
- **Environment variables**: Kubernetes exposes Services through [environment variables](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/). You can compose environment variable or pass arguments to your commands using the values of environment variables. They can be used in applications to find a Service. Values can reference other variables using the `$(VAR_NAME)` syntax.
|
||||
- **Environment variables**: Kubernetes exposes Services through
|
||||
[environment variables](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/).
|
||||
You can compose environment variable or pass arguments to your commands using the values of environment variables.
|
||||
They can be used in applications to find a Service.
|
||||
Values can reference other variables using the `$(VAR_NAME)` syntax.
|
||||
|
||||
### Uploading a YAML or JSON file
|
||||
|
||||
Kubernetes supports declarative configuration. In this style, all configuration is stored in YAML or JSON configuration files using the Kubernetes [API](/docs/concepts/overview/kubernetes-api/) resource schemas.
|
||||
Kubernetes supports declarative configuration.
|
||||
In this style, all configuration is stored in YAML or JSON configuration files
|
||||
using the Kubernetes [API](/docs/concepts/overview/kubernetes-api/) resource schemas.
|
||||
|
||||
As an alternative to specifying application details in the deploy wizard, you can define your application in YAML or JSON files, and upload the files using Dashboard.
|
||||
As an alternative to specifying application details in the deploy wizard,
|
||||
you can define your application in YAML or JSON files, and upload the files using Dashboard.
|
||||
|
||||
## Using Dashboard
|
||||
Following sections describe views of the Kubernetes Dashboard UI; what they provide and how can they be used.
|
||||
|
||||
### Navigation
|
||||
|
||||
When there are Kubernetes objects defined in the cluster, Dashboard shows them in the initial view. By default only objects from the _default_ namespace are shown and this can be changed using the namespace selector located in the navigation menu.
|
||||
When there are Kubernetes objects defined in the cluster, Dashboard shows them in the initial view.
|
||||
By default only objects from the _default_ namespace are shown and
|
||||
this can be changed using the namespace selector located in the navigation menu.
|
||||
|
||||
Dashboard shows most Kubernetes object kinds and groups them in a few menu categories.
|
||||
|
||||
#### Admin Overview
|
||||
For cluster and namespace administrators, Dashboard lists Nodes, Namespaces and Persistent Volumes and has detail views for them. Node list view contains CPU and memory usage metrics aggregated across all Nodes. The details view shows the metrics for a Node, its specification, status, allocated resources, events and pods running on the node.
|
||||
For cluster and namespace administrators, Dashboard lists Nodes, Namespaces and Persistent Volumes and has detail views for them.
|
||||
Node list view contains CPU and memory usage metrics aggregated across all Nodes.
|
||||
The details view shows the metrics for a Node, its specification, status,
|
||||
allocated resources, events and pods running on the node.
|
||||
|
||||
#### Workloads
|
||||
Shows all applications running in the selected namespace. The view lists applications by workload kind (e.g., Deployments, Replica Sets, Stateful Sets, etc.) and each workload kind can be viewed separately. The lists summarize actionable information about the workloads, such as the number of ready pods for a Replica Set or current memory usage for a Pod.
|
||||
|
||||
Detail views for workloads show status and specification information and surface relationships between objects. For example, Pods that Replica Set is controlling or New Replica Sets and Horizontal Pod Autoscalers for Deployments.
|
||||
Shows all applications running in the selected namespace.
|
||||
The view lists applications by workload kind (e.g., Deployments, Replica Sets, Stateful Sets, etc.)
|
||||
and each workload kind can be viewed separately.
|
||||
The lists summarize actionable information about the workloads,
|
||||
such as the number of ready pods for a Replica Set or current memory usage for a Pod.
|
||||
|
||||
Detail views for workloads show status and specification information and
|
||||
surface relationships between objects.
|
||||
For example, Pods that Replica Set is controlling or New Replica Sets and Horizontal Pod Autoscalers for Deployments.
|
||||
|
||||
#### Services
|
||||
Shows Kubernetes resources that allow for exposing services to external world and discovering them within a cluster. For that reason, Service and Ingress views show Pods targeted by them, internal endpoints for cluster connections and external endpoints for external users.
|
||||
|
||||
Shows Kubernetes resources that allow for exposing services to external world and
|
||||
discovering them within a cluster.
|
||||
For that reason, Service and Ingress views show Pods targeted by them,
|
||||
internal endpoints for cluster connections and external endpoints for external users.
|
||||
|
||||
#### Storage
|
||||
|
||||
Storage view shows Persistent Volume Claim resources which are used by applications for storing data.
|
||||
|
||||
#### Config Maps and Secrets
|
||||
Shows all Kubernetes resources that are used for live configuration of applications running in clusters. The view allows for editing and managing config objects and displays secrets hidden by default.
|
||||
|
||||
Shows all Kubernetes resources that are used for live configuration of applications running in clusters.
|
||||
The view allows for editing and managing config objects and displays secrets hidden by default.
|
||||
|
||||
#### Logs viewer
|
||||
Pod lists and detail pages link to a logs viewer that is built into Dashboard. The viewer allows for drilling down logs from containers belonging to a single Pod.
|
||||
|
||||
Pod lists and detail pages link to a logs viewer that is built into Dashboard.
|
||||
The viewer allows for drilling down logs from containers belonging to a single Pod.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -6,13 +6,10 @@ content_type: task
|
|||
<!-- overview -->
|
||||
This page shows how to access clusters using the Kubernetes API.
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Accessing the Kubernetes API
|
||||
|
|
@ -170,7 +167,7 @@ client-go defines its own API objects, so if needed, import API definitions from
|
|||
|
||||
{{< /note >}}
|
||||
|
||||
The Go client can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)
|
||||
The Go client can use the same [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
|
||||
as the kubectl CLI does to locate and authenticate to the API server. See this [example](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go):
|
||||
|
||||
```golang
|
||||
|
|
@ -199,7 +196,7 @@ If the application is deployed as a Pod in the cluster, see [Accessing the API f
|
|||
|
||||
To use [Python client](https://github.com/kubernetes-client/python), run the following command: `pip install kubernetes` See [Python Client Library page](https://github.com/kubernetes-client/python) for more installation options.
|
||||
|
||||
The Python client can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)
|
||||
The Python client can use the same [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
|
||||
as the kubectl CLI does to locate and authenticate to the API server. See this [example](https://github.com/kubernetes-client/python/blob/master/examples/out_of_cluster_config.py):
|
||||
|
||||
```python
|
||||
|
|
@ -229,7 +226,7 @@ mvn install
|
|||
|
||||
See [https://github.com/kubernetes-client/java/releases](https://github.com/kubernetes-client/java/releases) to see which versions are supported.
|
||||
|
||||
The Java client can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)
|
||||
The Java client can use the same [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
|
||||
as the kubectl CLI does to locate and authenticate to the API server. See this [example](https://github.com/kubernetes-client/java/blob/master/examples/src/main/java/io/kubernetes/client/examples/KubeConfigFileClientExample.java):
|
||||
|
||||
```java
|
||||
|
|
@ -283,7 +280,7 @@ public class KubeConfigFileClientExample {
|
|||
|
||||
To use [dotnet client](https://github.com/kubernetes-client/csharp), run the following command: `dotnet add package KubernetesClient --version 1.6.1` See [dotnet Client Library page](https://github.com/kubernetes-client/csharp) for more installation options. See [https://github.com/kubernetes-client/csharp/releases](https://github.com/kubernetes-client/csharp/releases) to see which versions are supported.
|
||||
|
||||
The dotnet client can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)
|
||||
The dotnet client can use the same [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
|
||||
as the kubectl CLI does to locate and authenticate to the API server. See this [example](https://github.com/kubernetes-client/csharp/blob/master/examples/simple/PodList.cs):
|
||||
|
||||
```csharp
|
||||
|
|
@ -318,7 +315,7 @@ namespace simple
|
|||
|
||||
To install [JavaScript client](https://github.com/kubernetes-client/javascript), run the following command: `npm install @kubernetes/client-node`. See [https://github.com/kubernetes-client/javascript/releases](https://github.com/kubernetes-client/javascript/releases) to see which versions are supported.
|
||||
|
||||
The JavaScript client can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)
|
||||
The JavaScript client can use the same [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
|
||||
as the kubectl CLI does to locate and authenticate to the API server. See this [example](https://github.com/kubernetes-client/javascript/blob/master/examples/example.js):
|
||||
|
||||
```javascript
|
||||
|
|
@ -338,7 +335,7 @@ k8sApi.listNamespacedPod('default').then((res) => {
|
|||
|
||||
See [https://github.com/kubernetes-client/haskell/releases](https://github.com/kubernetes-client/haskell/releases) to see which versions are supported.
|
||||
|
||||
The [Haskell client](https://github.com/kubernetes-client/haskell) can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)
|
||||
The [Haskell client](https://github.com/kubernetes-client/haskell) can use the same [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
|
||||
as the kubectl CLI does to locate and authenticate to the API server. See this [example](https://github.com/kubernetes-client/haskell/blob/master/kubernetes-client/example/App.hs):
|
||||
|
||||
```haskell
|
||||
|
|
@ -388,7 +385,7 @@ While running in a Pod, the Kubernetes apiserver is accessible via a Service nam
|
|||
do this automatically.
|
||||
|
||||
The recommended way to authenticate to the API server is with a
|
||||
[service account](/docs/user-guide/service-accounts) credential. By default, a Pod
|
||||
[service account](/docs/tasks/configure-pod-container/configure-service-account/) credential. By default, a Pod
|
||||
is associated with a service account, and a credential (token) for that
|
||||
service account is placed into the filesystem tree of each container in that Pod,
|
||||
at `/var/run/secrets/kubernetes.io/serviceaccount/token`.
|
||||
|
|
|
|||
|
|
@ -17,7 +17,8 @@ This page shows how to connect to services running on the Kubernetes cluster.
|
|||
|
||||
## Accessing services running on the cluster
|
||||
|
||||
In Kubernetes, [nodes](/docs/admin/node), [pods](/docs/user-guide/pods) and [services](/docs/user-guide/services) all have
|
||||
In Kubernetes, [nodes](/docs/concepts/architecture/nodes/),
|
||||
[pods](/docs/concepts/workloads/pods/) and [services](/docs/concepts/services-networking/service/) all have
|
||||
their own IPs. In many cases, the node IPs, pod IPs, and some service IPs on a cluster will not be
|
||||
routable, so they will not be reachable from a machine outside the cluster,
|
||||
such as your desktop machine.
|
||||
|
|
@ -28,7 +29,7 @@ You have several options for connecting to nodes, pods and services from outside
|
|||
|
||||
- Access services through public IPs.
|
||||
- Use a service with type `NodePort` or `LoadBalancer` to make the service reachable outside
|
||||
the cluster. See the [services](/docs/user-guide/services) and
|
||||
the cluster. See the [services](/docs/concepts/services-networking/service/) and
|
||||
[kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) documentation.
|
||||
- Depending on your cluster environment, this may just expose the service to your corporate network,
|
||||
or it may expose it to the internet. Think about whether the service being exposed is secure.
|
||||
|
|
|
|||
|
|
@ -13,9 +13,6 @@ upgrading your cluster's
|
|||
master and worker nodes, performing node maintenance (e.g. kernel upgrades), and upgrading the Kubernetes API version of a
|
||||
running cluster.
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Creating and configuring a Cluster
|
||||
|
|
@ -81,24 +78,33 @@ Different providers, and tools, will manage upgrades differently. It is recomme
|
|||
* [Digital Rebar](https://provision.readthedocs.io/en/tip/doc/content-packages/krib.html)
|
||||
* ...
|
||||
|
||||
To upgrade a cluster on a platform not mentioned in the above list, check the order of component upgrade on the [Skewed versions](/docs/setup/release/version-skew-policy/#supported-component-upgrade-order) page.
|
||||
To upgrade a cluster on a platform not mentioned in the above list, check the order of component upgrade on the
|
||||
[Skewed versions](/docs/setup/release/version-skew-policy/#supported-component-upgrade-order) page.
|
||||
|
||||
## Resizing a cluster
|
||||
|
||||
If your cluster runs short on resources you can easily add more machines to it if your cluster is running in [Node self-registration mode](/docs/admin/node/#self-registration-of-nodes).
|
||||
If you're using GCE or Google Kubernetes Engine it's done by resizing the Instance Group managing your Nodes. It can be accomplished by modifying number of instances on `Compute > Compute Engine > Instance groups > your group > Edit group` [Google Cloud Console page](https://console.developers.google.com) or using gcloud CLI:
|
||||
If your cluster runs short on resources you can easily add more machines to it if your cluster
|
||||
is running in [Node self-registration mode](/docs/concepts/architecture/nodes/#self-registration-of-nodes).
|
||||
If you're using GCE or Google Kubernetes Engine it's done by resizing the Instance Group managing your Nodes.
|
||||
It can be accomplished by modifying number of instances on
|
||||
`Compute > Compute Engine > Instance groups > your group > Edit group`
|
||||
[Google Cloud Console page](https://console.developers.google.com) or using gcloud CLI:
|
||||
|
||||
```shell
|
||||
gcloud compute instance-groups managed resize kubernetes-node-pool --size=42 --zone=$ZONE
|
||||
```
|
||||
|
||||
The Instance Group will take care of putting appropriate image on new machines and starting them, while the Kubelet will register its Node with the API server to make it available for scheduling. If you scale the instance group down, system will randomly choose Nodes to kill.
|
||||
The Instance Group will take care of putting appropriate image on new machines and starting them,
|
||||
while the Kubelet will register its Node with the API server to make it available for scheduling.
|
||||
If you scale the instance group down, system will randomly choose Nodes to kill.
|
||||
|
||||
In other environments you may need to configure the machine yourself and tell the Kubelet on which machine API server is running.
|
||||
|
||||
### Resizing an Azure Kubernetes Service (AKS) cluster
|
||||
|
||||
Azure Kubernetes Service enables user-initiated resizing of the cluster from either the CLI or the Azure Portal and is described in the [Azure AKS documentation](https://docs.microsoft.com/en-us/azure/aks/scale-cluster).
|
||||
Azure Kubernetes Service enables user-initiated resizing of the cluster from either the CLI or
|
||||
the Azure Portal and is described in the
|
||||
[Azure AKS documentation](https://docs.microsoft.com/en-us/azure/aks/scale-cluster).
|
||||
|
||||
|
||||
### Cluster autoscaling
|
||||
|
|
@ -106,7 +112,8 @@ Azure Kubernetes Service enables user-initiated resizing of the cluster from eit
|
|||
If you are using GCE or Google Kubernetes Engine, you can configure your cluster so that it is automatically rescaled based on
|
||||
pod needs.
|
||||
|
||||
As described in [Compute Resource](/docs/concepts/configuration/manage-compute-resources-container/), users can reserve how much CPU and memory is allocated to pods.
|
||||
As described in [Compute Resource](/docs/concepts/configuration/manage-resources-containers/),
|
||||
users can reserve how much CPU and memory is allocated to pods.
|
||||
This information is used by the Kubernetes scheduler to find a place to run the pod. If there is
|
||||
no node that has enough free capacity (or doesn't match other pod requirements) then the pod has
|
||||
to wait until some pods are terminated or a new node is added.
|
||||
|
|
@ -185,7 +192,8 @@ kubectl uncordon $NODENAME
|
|||
|
||||
If you deleted the node's VM instance and created a new one, then a new schedulable node resource will
|
||||
be created automatically (if you're using a cloud provider that supports
|
||||
node discovery; currently this is only Google Compute Engine, not including CoreOS on Google Compute Engine using kube-register). See [Node](/docs/admin/node) for more details.
|
||||
node discovery; currently this is only Google Compute Engine, not including CoreOS on Google Compute Engine using kube-register).
|
||||
See [Node](/docs/concepts/architecture/nodes/) for more details.
|
||||
|
||||
## Advanced Topics
|
||||
|
||||
|
|
|
|||
|
|
@ -50,7 +50,7 @@ and more. For more information, see [DNS for Services and Pods](/docs/concepts/s
|
|||
If a Pod's `dnsPolicy` is set to `default`, it inherits the name resolution
|
||||
configuration from the node that the Pod runs on. The Pod's DNS resolution
|
||||
should behave the same as the node.
|
||||
But see [Known issues](/docs/tasks/debug-application-cluster/dns-debugging-resolution/#known-issues).
|
||||
But see [Known issues](/docs/tasks/administer-cluster/dns-debugging-resolution/#known-issues).
|
||||
|
||||
If you don't want this, or if you want a different DNS config for pods, you can
|
||||
use the kubelet's `--resolv-conf` flag. Set this flag to "" to prevent Pods from
|
||||
|
|
|
|||
|
|
@ -27,11 +27,8 @@ The upgrade workflow at high level is the following:
|
|||
1. Upgrade additional control plane nodes.
|
||||
1. Upgrade worker nodes.
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
- You need to have a kubeadm Kubernetes cluster running version 1.18.0 or later.
|
||||
- [Swap must be disabled](https://serverfault.com/questions/684771/best-way-to-disable-swap-in-linux).
|
||||
- The cluster should use a static control plane and etcd pods or external etcd.
|
||||
|
|
@ -46,8 +43,6 @@ The upgrade workflow at high level is the following:
|
|||
or between PATCH versions of the same MINOR. That is, you cannot skip MINOR versions when you upgrade.
|
||||
For example, you can upgrade from 1.y to 1.y+1, but not from 1.y to 1.y+2.
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Determine which version to upgrade to
|
||||
|
|
|
|||
|
|
@ -10,14 +10,9 @@ weight: 40
|
|||
|
||||
This page shows how to use Romana for NetworkPolicy.
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
Complete steps 1, 2, and 3 of the [kubeadm getting started guide](/docs/getting-started-guides/kubeadm/).
|
||||
|
||||
|
||||
Complete steps 1, 2, and 3 of the [kubeadm getting started guide](/docs/reference/setup-tools/kubeadm/kubeadm/).
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
|
|
@ -33,13 +28,10 @@ To apply network policies use one of the following:
|
|||
* [Example of Romana network policy](https://github.com/romana/core/blob/master/doc/policy.md).
|
||||
* The NetworkPolicy API.
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
Once you have installed Romana, you can follow the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) to try out Kubernetes NetworkPolicy.
|
||||
|
||||
|
||||
Once you have installed Romana, you can follow the
|
||||
[Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/)
|
||||
to try out Kubernetes NetworkPolicy.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -10,14 +10,10 @@ weight: 50
|
|||
|
||||
This page shows how to use Weave Net for NetworkPolicy.
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
You need to have a Kubernetes cluster. Follow the [kubeadm getting started guide](/docs/getting-started-guides/kubeadm/) to bootstrap one.
|
||||
|
||||
|
||||
You need to have a Kubernetes cluster. Follow the
|
||||
[kubeadm getting started guide](/docs/reference/setup-tools/kubeadm/kubeadm/) to bootstrap one.
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
|
|
@ -25,7 +21,10 @@ You need to have a Kubernetes cluster. Follow the [kubeadm getting started guide
|
|||
|
||||
Follow the [Integrating Kubernetes via the Addon](https://www.weave.works/docs/net/latest/kube-addon/) guide.
|
||||
|
||||
The Weave Net addon for Kubernetes comes with a [Network Policy Controller](https://www.weave.works/docs/net/latest/kube-addon/#npc) that automatically monitors Kubernetes for any NetworkPolicy annotations on all namespaces and configures `iptables` rules to allow or block traffic as directed by the policies.
|
||||
The Weave Net addon for Kubernetes comes with a
|
||||
[Network Policy Controller](https://www.weave.works/docs/net/latest/kube-addon/#npc)
|
||||
that automatically monitors Kubernetes for any NetworkPolicy annotations on all
|
||||
namespaces and configures `iptables` rules to allow or block traffic as directed by the policies.
|
||||
|
||||
## Test the installation
|
||||
|
||||
|
|
@ -49,13 +48,10 @@ weave-net-pmw8w 2/2 Running 0 9d
|
|||
|
||||
Each Node has a weave Pod, and all Pods are `Running` and `2/2 READY`. (`2/2` means that each Pod has `weave` and `weave-npc`.)
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
Once you have installed the Weave Net addon, you can follow the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) to try out Kubernetes NetworkPolicy. If you have any question, contact us at [#weave-community on Slack or Weave User Group](https://github.com/weaveworks/weave#getting-help).
|
||||
|
||||
|
||||
|
||||
Once you have installed the Weave Net addon, you can follow the
|
||||
[Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/)
|
||||
to try out Kubernetes NetworkPolicy. If you have any question, contact us at
|
||||
[#weave-community on Slack or Weave User Group](https://github.com/weaveworks/weave#getting-help).
|
||||
|
||||
|
|
|
|||
|
|
@ -16,9 +16,6 @@ are low. This is especially important when dealing with incompressible
|
|||
compute resources, such as memory or disk space. If such resources are exhausted,
|
||||
nodes become unstable.
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Eviction Policy
|
||||
|
|
@ -53,8 +50,7 @@ like `free -m`. This is important because `free -m` does not work in a
|
|||
container, and if users use the [node
|
||||
allocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) feature, out of resource decisions
|
||||
are made local to the end user Pod part of the cgroup hierarchy as well as the
|
||||
root node. This
|
||||
[script](/docs/tasks/administer-cluster/out-of-resource/memory-available.sh)
|
||||
root node. This [script](/docs/tasks/administer-cluster/memory-available.sh)
|
||||
reproduces the same set of steps that the `kubelet` performs to calculate
|
||||
`memory.available`. The `kubelet` excludes inactive_file (i.e. # of bytes of
|
||||
file-backed memory on inactive LRU list) from its calculation as it assumes that
|
||||
|
|
|
|||
|
|
@ -56,7 +56,9 @@ an integrated [Role-Based Access Control (RBAC)](/docs/reference/access-authn-au
|
|||
set of permissions bundled into roles. These permissions combine verbs (get, create, delete) with
|
||||
resources (pods, services, nodes) and can be namespace or cluster scoped. A set of out of the box
|
||||
roles are provided that offer reasonable default separation of responsibility depending on what
|
||||
actions a client might want to perform. It is recommended that you use the [Node](/docs/reference/access-authn-authz/node/) and [RBAC](/docs/reference/access-authn-authz/rbac/) authorizers together, in combination with the
|
||||
actions a client might want to perform. It is recommended that you use the
|
||||
[Node](/docs/reference/access-authn-authz/node/) and
|
||||
[RBAC](/docs/reference/access-authn-authz/rbac/) authorizers together, in combination with the
|
||||
[NodeRestriction](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) admission plugin.
|
||||
|
||||
As with authentication, simple and broad roles may be appropriate for smaller clusters, but as
|
||||
|
|
@ -79,7 +81,7 @@ Kubelets expose HTTPS endpoints which grant powerful control over the node and c
|
|||
|
||||
Production clusters should enable Kubelet authentication and authorization.
|
||||
|
||||
Consult the [Kubelet authentication/authorization reference](/docs/admin/kubelet-authentication-authorization) for more information.
|
||||
Consult the [Kubelet authentication/authorization reference](/docs/reference/command-line-tools-reference/kubelet-authentication-authorization) for more information.
|
||||
|
||||
## Controlling the capabilities of a workload or user at runtime
|
||||
|
||||
|
|
@ -252,9 +254,8 @@ are not encrypted or an attacker gains read access to etcd.
|
|||
### Receiving alerts for security updates and reporting vulnerabilities
|
||||
|
||||
Join the [kubernetes-announce](https://groups.google.com/forum/#!forum/kubernetes-announce)
|
||||
group for emails about security announcements. See the [security reporting](/security/)
|
||||
group for emails about security announcements. See the
|
||||
[security reporting](/docs/reference/issues-security/security/)
|
||||
page for more on how to report vulnerabilities.
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ weight: 110
|
|||
|
||||
This page shows how to configure liveness, readiness and startup probes for containers.
|
||||
|
||||
The [kubelet](/docs/admin/kubelet/) uses liveness probes to know when to
|
||||
The [kubelet](/docs/reference/command-line-tools-reference/kubelet/) uses liveness probes to know when to
|
||||
restart a container. For example, liveness probes could catch a deadlock,
|
||||
where an application is running, but unable to make progress. Restarting a
|
||||
container in such a state can help to make the application more available
|
||||
|
|
|
|||
|
|
@ -29,13 +29,11 @@ PersistentVolume.
|
|||
{{< glossary_tooltip text="kubectl" term_id="kubectl" >}}
|
||||
command-line tool must be configured to communicate with your cluster. If you
|
||||
do not already have a single-node cluster, you can create one by using
|
||||
[Minikube](/docs/getting-started-guides/minikube).
|
||||
[Minikube](/docs/setup/learning-environment/minikube/).
|
||||
|
||||
* Familiarize yourself with the material in
|
||||
[Persistent Volumes](/docs/concepts/storage/persistent-volumes/).
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Create an index.html file on your Node
|
||||
|
|
|
|||
|
|
@ -39,10 +39,14 @@ When they do, they are authenticated as a particular Service Account (for exampl
|
|||
|
||||
When you create a pod, if you do not specify a service account, it is
|
||||
automatically assigned the `default` service account in the same namespace.
|
||||
If you get the raw json or yaml for a pod you have created (for example, `kubectl get pods/<podname> -o yaml`), you can see the `spec.serviceAccountName` field has been [automatically set](/docs/user-guide/working-with-resources/#resources-are-automatically-modified).
|
||||
If you get the raw json or yaml for a pod you have created (for example, `kubectl get pods/<podname> -o yaml`),
|
||||
you can see the `spec.serviceAccountName` field has been
|
||||
[automatically set](/docs/concepts/overview/working-with-objects/object-management/).
|
||||
|
||||
You can access the API from inside a pod using automatically mounted service account credentials, as described in [Accessing the Cluster](/docs/user-guide/accessing-the-cluster/#accessing-the-api-from-a-pod).
|
||||
The API permissions of the service account depend on the [authorization plugin and policy](/docs/reference/access-authn-authz/authorization/#authorization-modules) in use.
|
||||
You can access the API from inside a pod using automatically mounted service account credentials, as described in
|
||||
[Accessing the Cluster](/docs/tasks/access-application-cluster/access-cluster).
|
||||
The API permissions of the service account depend on the
|
||||
[authorization plugin and policy](/docs/reference/access-authn-authz/authorization/#authorization-modules) in use.
|
||||
|
||||
In version 1.6+, you can opt out of automounting API credentials for a service account by setting `automountServiceAccountToken: false` on the service account:
|
||||
|
||||
|
|
|
|||
|
|
@ -243,7 +243,7 @@ exit
|
|||
|
||||
## Set capabilities for a Container
|
||||
|
||||
With [Linux capabilities](http://man7.org/linux/man-pages/man7/capabilities.7.html),
|
||||
With [Linux capabilities](https://man7.org/linux/man-pages/man7/capabilities.7.html),
|
||||
you can grant certain privileges to a process without granting all the privileges
|
||||
of the root user. To add or remove Linux capabilities for a Container, include the
|
||||
`capabilities` field in the `securityContext` section of the Container manifest.
|
||||
|
|
|
|||
|
|
@ -9,7 +9,8 @@ weight: 20
|
|||
|
||||
<!-- overview -->
|
||||
|
||||
Kubernetes ships with a default scheduler that is described [here](/docs/admin/kube-scheduler/).
|
||||
Kubernetes ships with a default scheduler that is described
|
||||
[here](/docs/reference/command-line-tools-reference/kube-scheduler/).
|
||||
If the default scheduler does not suit your needs you can implement your own scheduler.
|
||||
Not just that, you can even run multiple schedulers simultaneously alongside the default
|
||||
scheduler and instruct Kubernetes what scheduler to use for each of your pods. Let's
|
||||
|
|
@ -20,16 +21,10 @@ document. Please refer to the kube-scheduler implementation in
|
|||
[pkg/scheduler](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/pkg/scheduler)
|
||||
in the Kubernetes source directory for a canonical example.
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Package the scheduler
|
||||
|
|
@ -83,7 +78,7 @@ Note also that we created a dedicated service account `my-scheduler` and bind th
|
|||
`system:kube-scheduler` to it so that it can acquire the same privileges as `kube-scheduler`.
|
||||
|
||||
Please see the
|
||||
[kube-scheduler documentation](/docs/admin/kube-scheduler/) for
|
||||
[kube-scheduler documentation](/docs/reference/command-line-tools-reference/kube-scheduler/) for
|
||||
detailed description of other command line arguments.
|
||||
|
||||
## Run the second scheduler in the cluster
|
||||
|
|
@ -100,6 +95,7 @@ Verify that the scheduler pod is running:
|
|||
```shell
|
||||
kubectl get pods --namespace=kube-system
|
||||
```
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
....
|
||||
|
|
@ -125,8 +121,10 @@ The control plane creates the lock objects for you, but the namespace must alrea
|
|||
You can use the `kube-system` namespace.
|
||||
{{< /note >}}
|
||||
|
||||
If RBAC is enabled on your cluster, you must update the `system:kube-scheduler` cluster role. Add your scheduler name to the resourceNames of the rule applied for `endpoints` and `leases` resources, as in the following example:
|
||||
```
|
||||
If RBAC is enabled on your cluster, you must update the `system:kube-scheduler` cluster role.
|
||||
Add your scheduler name to the resourceNames of the rule applied for `endpoints` and `leases` resources, as in the following example:
|
||||
|
||||
```shell
|
||||
kubectl edit clusterrole system:kube-scheduler
|
||||
```
|
||||
|
||||
|
|
@ -134,10 +132,11 @@ kubectl edit clusterrole system:kube-scheduler
|
|||
|
||||
## Specify schedulers for pods
|
||||
|
||||
Now that our second scheduler is running, let's create some pods, and direct them to be scheduled by either the default scheduler or the one we just deployed. In order to schedule a given pod using a specific scheduler, we specify the name of the
|
||||
Now that our second scheduler is running, let's create some pods, and direct them
|
||||
to be scheduled by either the default scheduler or the one we just deployed.
|
||||
In order to schedule a given pod using a specific scheduler, we specify the name of the
|
||||
scheduler in that pod spec. Let's look at three examples.
|
||||
|
||||
|
||||
- Pod spec without any scheduler name
|
||||
|
||||
{{< codenew file="admin/sched/pod1.yaml" >}}
|
||||
|
|
@ -147,9 +146,9 @@ scheduler in that pod spec. Let's look at three examples.
|
|||
|
||||
Save this file as `pod1.yaml` and submit it to the Kubernetes cluster.
|
||||
|
||||
```shell
|
||||
kubectl create -f pod1.yaml
|
||||
```
|
||||
```shell
|
||||
kubectl create -f pod1.yaml
|
||||
```
|
||||
|
||||
- Pod spec with `default-scheduler`
|
||||
|
||||
|
|
@ -160,9 +159,9 @@ kubectl create -f pod1.yaml
|
|||
|
||||
Save this file as `pod2.yaml` and submit it to the Kubernetes cluster.
|
||||
|
||||
```shell
|
||||
kubectl create -f pod2.yaml
|
||||
```
|
||||
```shell
|
||||
kubectl create -f pod2.yaml
|
||||
```
|
||||
|
||||
- Pod spec with `my-scheduler`
|
||||
|
||||
|
|
@ -174,17 +173,15 @@ kubectl create -f pod2.yaml
|
|||
|
||||
Save this file as `pod3.yaml` and submit it to the Kubernetes cluster.
|
||||
|
||||
```shell
|
||||
kubectl create -f pod3.yaml
|
||||
```
|
||||
```shell
|
||||
kubectl create -f pod3.yaml
|
||||
```
|
||||
|
||||
Verify that all three pods are running.
|
||||
|
||||
```shell
|
||||
kubectl get pods
|
||||
```
|
||||
|
||||
|
||||
```shell
|
||||
kubectl get pods
|
||||
```
|
||||
|
||||
<!-- discussion -->
|
||||
|
||||
|
|
@ -206,4 +203,3 @@ verify that the pods were scheduled by the desired schedulers.
|
|||
kubectl get events
|
||||
```
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -13,19 +13,15 @@ This page explains how to add versioning information to
|
|||
[CustomResourceDefinitions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#customresourcedefinition-v1beta1-apiextensions), to indicate the stability
|
||||
level of your CustomResourceDefinitions or advance your API to a new version with conversion between API representations. It also describes how to upgrade an object from one version to another.
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
You should have a initial understanding of [custom resources](/docs/concepts/api-extension/custom-resources/).
|
||||
You should have a initial understanding of [custom resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
|
||||
|
||||
{{< version-check >}}
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Overview
|
||||
|
|
@ -374,7 +370,9 @@ conversions that call an external service in case a conversion is required. For
|
|||
* Watch is created in one version but the changed object is stored in another version.
|
||||
* custom resource PUT request is in a different version than storage version.
|
||||
|
||||
To cover all of these cases and to optimize conversion by the API server, the conversion requests may contain multiple objects in order to minimize the external calls. The webhook should perform these conversions independently.
|
||||
To cover all of these cases and to optimize conversion by the API server,
|
||||
the conversion requests may contain multiple objects in order to minimize the external calls.
|
||||
The webhook should perform these conversions independently.
|
||||
|
||||
### Write a conversion webhook server
|
||||
|
||||
|
|
@ -385,7 +383,12 @@ that is validated in a Kubernetes e2e test. The webhook handles the
|
|||
results wrapped in `ConversionResponse`. Note that the request
|
||||
contains a list of custom resources that need to be converted independently without
|
||||
changing the order of objects.
|
||||
The example server is organized in a way to be reused for other conversions. Most of the common code are located in the [framework file](https://github.com/kubernetes/kubernetes/tree/v1.15.0/test/images/crd-conversion-webhook/converter/framework.go) that leaves only [one function](https://github.com/kubernetes/kubernetes/blob/v1.15.0/test/images/crd-conversion-webhook/converter/example_converter.go#L29-L80) to be implemented for different conversions.
|
||||
The example server is organized in a way to be reused for other conversions.
|
||||
Most of the common code are located in the
|
||||
[framework file](https://github.com/kubernetes/kubernetes/tree/v1.15.0/test/images/crd-conversion-webhook/converter/framework.go)
|
||||
that leaves only
|
||||
[one function](https://github.com/kubernetes/kubernetes/blob/v1.15.0/test/images/crd-conversion-webhook/converter/example_converter.go#L29-L80)
|
||||
to be implemented for different conversions.
|
||||
|
||||
{{< note >}}
|
||||
The example conversion webhook server leaves the `ClientAuth` field
|
||||
|
|
@ -398,12 +401,17 @@ how to [authenticate API servers](/docs/reference/access-authn-authz/extensible-
|
|||
|
||||
#### Permissible mutations
|
||||
|
||||
A conversion webhook must not mutate anything inside of `metadata` of the converted object other than `labels` and `annotations`. Attempted changes to `name`, `UID` and `namespace` are rejected and fail the request which caused the conversion. All other changes are just ignored.
|
||||
A conversion webhook must not mutate anything inside of `metadata` of the converted object
|
||||
other than `labels` and `annotations`.
|
||||
Attempted changes to `name`, `UID` and `namespace` are rejected and fail the request
|
||||
which caused the conversion. All other changes are just ignored.
|
||||
|
||||
### Deploy the conversion webhook service
|
||||
|
||||
Documentation for deploying the conversion webhook is the same as for the [admission webhook example service](/docs/reference/access-authn-authz/extensible-admission-controllers/#deploy_the_admission_webhook_service).
|
||||
The assumption for next sections is that the conversion webhook server is deployed to a service named `example-conversion-webhook-server` in `default` namespace and serving traffic on path `/crdconvert`.
|
||||
Documentation for deploying the conversion webhook is the same as for the
|
||||
[admission webhook example service](/docs/reference/access-authn-authz/extensible-admission-controllers/#deploy_the_admission_webhook_service).
|
||||
The assumption for next sections is that the conversion webhook server is deployed to a service
|
||||
named `example-conversion-webhook-server` in `default` namespace and serving traffic on path `/crdconvert`.
|
||||
|
||||
{{< note >}}
|
||||
When the webhook server is deployed into the Kubernetes cluster as a
|
||||
|
|
@ -639,7 +647,7 @@ at the subpath "/my-path", and to verify the TLS connection against the ServerNa
|
|||
{{< tabs name="CustomResourceDefinition_versioning_example_4" >}}
|
||||
{{% tab name="apiextensions.k8s.io/v1" %}}
|
||||
```yaml
|
||||
apiVersion: apiextensions.k8s.io/v1b
|
||||
apiVersion: apiextensions.k8s.io/v1
|
||||
kind: CustomResourceDefinition
|
||||
...
|
||||
spec:
|
||||
|
|
|
|||
|
|
@ -16,7 +16,6 @@ This page shows how to install a
|
|||
into the Kubernetes API by creating a
|
||||
[CustomResourceDefinition](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#customresourcedefinition-v1beta1-apiextensions).
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
|
|
@ -24,9 +23,7 @@ into the Kubernetes API by creating a
|
|||
|
||||
* Make sure your Kubernetes cluster has a master version of 1.16.0 or higher to use `apiextensions.k8s.io/v1`, or 1.7.0 or higher for `apiextensions.k8s.io/v1beta1`.
|
||||
|
||||
* Read about [custom resources](/docs/concepts/api-extension/custom-resources/).
|
||||
|
||||
|
||||
* Read about [custom resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
|
|
@ -427,7 +424,9 @@ spec:
|
|||
|
||||
The field `someRandomField` has been pruned.
|
||||
|
||||
Note that the `kubectl create` call uses `--validate=false` to skip client-side validation. Because the [OpenAPI validation schemas are also published](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#publish-validation-schema-in-openapi-v2) to kubectl, it will also check for unknown fields and reject those objects long before they are sent to the API server.
|
||||
Note that the `kubectl create` call uses `--validate=false` to skip client-side validation.
|
||||
Because the [OpenAPI validation schemas are also published](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#publish-validation-schema-in-openapi-v2)
|
||||
to kubectl, it will also check for unknown fields and reject those objects long before they are sent to the API server.
|
||||
|
||||
### Controlling pruning
|
||||
|
||||
|
|
@ -533,11 +532,14 @@ allOf:
|
|||
|
||||
With one of those specification, both an integer and a string validate.
|
||||
|
||||
In [Validation Schema Publishing](/docs/tasks/extend-kubernetes/custom-resources/extend-api-custom-resource-definitions/#publish-validation-schema-in-openapi-v2), `x-kubernetes-int-or-string: true` is unfolded to one of the two patterns shown above.
|
||||
In [Validation Schema Publishing](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#publish-validation-schema-in-openapi-v2),
|
||||
`x-kubernetes-int-or-string: true` is unfolded to one of the two patterns shown above.
|
||||
|
||||
### RawExtension
|
||||
|
||||
RawExtensions (as in `runtime.RawExtension` defined in [k8s.io/apimachinery](https://github.com/kubernetes/apimachinery/blob/03ac7a9ade429d715a1a46ceaa3724c18ebae54f/pkg/runtime/types.go#L94)) holds complete Kubernetes objects, i.e. with `apiVersion` and `kind` fields.
|
||||
RawExtensions (as in `runtime.RawExtension` defined in
|
||||
[k8s.io/apimachinery](https://github.com/kubernetes/apimachinery/blob/03ac7a9ade429d715a1a46ceaa3724c18ebae54f/pkg/runtime/types.go#L94))
|
||||
holds complete Kubernetes objects, i.e. with `apiVersion` and `kind` fields.
|
||||
|
||||
It is possible to specify those embedded objects (both completely without constraints or partially specified) by setting `x-kubernetes-embedded-resource: true`. For example:
|
||||
|
||||
|
|
@ -569,8 +571,6 @@ See [Custom resource definition versioning](/docs/tasks/extend-kubernetes/custom
|
|||
for more information about serving multiple versions of your
|
||||
CustomResourceDefinition and migrating your objects from one version to another.
|
||||
|
||||
|
||||
|
||||
<!-- discussion -->
|
||||
## Advanced topics
|
||||
|
||||
|
|
|
|||
|
|
@ -9,17 +9,10 @@ weight: 20
|
|||
This page shows how to define environment variables for a container
|
||||
in a Kubernetes Pod.
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Define an environment variable for a container
|
||||
|
|
@ -123,13 +116,10 @@ spec:
|
|||
|
||||
Upon creation, the command `echo Warm greetings to The Most Honorable Kubernetes` is run on the container.
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* Learn more about [environment variables](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/).
|
||||
* Learn about [using secrets as environment variables](/docs/user-guide/secrets/#using-secrets-as-environment-variables).
|
||||
* Learn about [using secrets as environment variables](/docs/concepts/configuration/secret/#using-secrets-as-environment-variables).
|
||||
* See [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core).
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -128,8 +128,8 @@ You can read more about removing jobs in [garbage collection](/docs/concepts/wor
|
|||
## Writing a Cron Job Spec
|
||||
|
||||
As with all other Kubernetes configs, a cron job needs `apiVersion`, `kind`, and `metadata` fields. For general
|
||||
information about working with config files, see [deploying applications](/docs/user-guide/deploying-applications),
|
||||
and [using kubectl to manage resources](/docs/user-guide/working-with-resources) documents.
|
||||
information about working with config files, see [deploying applications](/docs/tasks/run-application/run-stateless-application-deployment/),
|
||||
and [using kubectl to manage resources](/docs/concepts/overview/working-with-objects/object-management/) documents.
|
||||
|
||||
A cron job config also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).
|
||||
|
||||
|
|
@ -142,7 +142,8 @@ All modifications to a cron job, especially its `.spec`, are applied only to the
|
|||
The `.spec.schedule` is a required field of the `.spec`.
|
||||
It takes a [Cron](https://en.wikipedia.org/wiki/Cron) format string, such as `0 * * * *` or `@hourly`, as schedule time of its jobs to be created and executed.
|
||||
|
||||
The format also includes extended `vixie cron` step values. As explained in the [FreeBSD manual](https://www.freebsd.org/cgi/man.cgi?crontab%285%29):
|
||||
The format also includes extended `vixie cron` step values. As explained in the
|
||||
[FreeBSD manual](https://www.freebsd.org/cgi/man.cgi?crontab%285%29):
|
||||
|
||||
> Step values can be used in conjunction with ranges. Following a range
|
||||
> with `/<number>` specifies skips of the number's value through the
|
||||
|
|
|
|||
|
|
@ -17,25 +17,20 @@ from a task queue, completes it, deletes it from the queue, and exits.
|
|||
Here is an overview of the steps in this example:
|
||||
|
||||
1. **Start a message queue service.** In this example, we use RabbitMQ, but you could use another
|
||||
one. In practice you would set up a message queue service once and reuse it for many jobs.
|
||||
one. In practice you would set up a message queue service once and reuse it for many jobs.
|
||||
1. **Create a queue, and fill it with messages.** Each message represents one task to be done. In
|
||||
this example, a message is just an integer that we will do a lengthy computation on.
|
||||
this example, a message is just an integer that we will do a lengthy computation on.
|
||||
1. **Start a Job that works on tasks from the queue**. The Job starts several pods. Each pod takes
|
||||
one task from the message queue, processes it, and repeats until the end of the queue is reached.
|
||||
|
||||
|
||||
|
||||
one task from the message queue, processes it, and repeats until the end of the queue is reached.
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
Be familiar with the basic,
|
||||
non-parallel, use of [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/).
|
||||
non-parallel, use of [Job](/docs/concepts/workloads/controllers/job/).
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Starting a message queue service
|
||||
|
|
@ -304,7 +299,7 @@ do not need to modify your "worker" program to be aware that there is a work que
|
|||
|
||||
It does require that you run a message queue service.
|
||||
If running a queue service is inconvenient, you may
|
||||
want to consider one of the other [job patterns](/docs/concepts/jobs/run-to-completion-finite-workloads/#job-patterns).
|
||||
want to consider one of the other [job patterns](/docs/concepts/workloads/controllers/job/#job-patterns).
|
||||
|
||||
This approach creates a pod for every work item. If your work items only take a few seconds,
|
||||
though, creating a Pod for every work item may add a lot of overhead. Consider another
|
||||
|
|
|
|||
|
|
@ -16,31 +16,24 @@ from a task queue, processes it, and repeats until the end of the queue is reach
|
|||
Here is an overview of the steps in this example:
|
||||
|
||||
1. **Start a storage service to hold the work queue.** In this example, we use Redis to store
|
||||
our work items. In the previous example, we used RabbitMQ. In this example, we use Redis and
|
||||
a custom work-queue client library because AMQP does not provide a good way for clients to
|
||||
detect when a finite-length work queue is empty. In practice you would set up a store such
|
||||
as Redis once and reuse it for the work queues of many jobs, and other things.
|
||||
our work items. In the previous example, we used RabbitMQ. In this example, we use Redis and
|
||||
a custom work-queue client library because AMQP does not provide a good way for clients to
|
||||
detect when a finite-length work queue is empty. In practice you would set up a store such
|
||||
as Redis once and reuse it for the work queues of many jobs, and other things.
|
||||
1. **Create a queue, and fill it with messages.** Each message represents one task to be done. In
|
||||
this example, a message is just an integer that we will do a lengthy computation on.
|
||||
this example, a message is just an integer that we will do a lengthy computation on.
|
||||
1. **Start a Job that works on tasks from the queue**. The Job starts several pods. Each pod takes
|
||||
one task from the message queue, processes it, and repeats until the end of the queue is reached.
|
||||
|
||||
|
||||
|
||||
one task from the message queue, processes it, and repeats until the end of the queue is reached.
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
Be familiar with the basic,
|
||||
non-parallel, use of [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/).
|
||||
|
||||
|
||||
non-parallel, use of [Job](/docs/concepts/workloads/controllers/job/).
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
|
|
@ -227,14 +220,13 @@ Working on lemon
|
|||
|
||||
As you can see, one of our pods worked on several work units.
|
||||
|
||||
|
||||
|
||||
<!-- discussion -->
|
||||
|
||||
## Alternatives
|
||||
|
||||
If running a queue service or modifying your containers to use a work queue is inconvenient, you may
|
||||
want to consider one of the other [job patterns](/docs/concepts/jobs/run-to-completion-finite-workloads/#job-patterns).
|
||||
want to consider one of the other
|
||||
[job patterns](/docs/concepts/workloads/controllers/job/#job-patterns).
|
||||
|
||||
If you have a continuous stream of background processing work to run, then
|
||||
consider running your background workers with a `ReplicaSet` instead,
|
||||
|
|
|
|||
|
|
@ -17,12 +17,10 @@ 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.
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
You should be familiar with the basic,
|
||||
non-parallel, use of [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/).
|
||||
non-parallel, use of [Job](/docs/concepts/workloads/controllers/job/).
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
|
|
@ -33,12 +31,11 @@ To follow the advanced templating example, you need a working installation of
|
|||
library for Python.
|
||||
|
||||
Once you have Python set up, you can install Jinja2 by running:
|
||||
|
||||
```shell
|
||||
pip install --user jinja2
|
||||
```
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Create Jobs based on a template
|
||||
|
|
@ -305,7 +302,7 @@ If you plan to create a large number of Job objects, you may find that:
|
|||
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)
|
||||
There are other [job patterns](/docs/concepts/workloads/controllers/job/#job-patterns)
|
||||
that you can use to process large amounts of work without creating very many Job
|
||||
objects.
|
||||
|
||||
|
|
|
|||
|
|
@ -10,17 +10,10 @@ weight: 10
|
|||
|
||||
This page shows how to perform a rolling update on a DaemonSet.
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
* The DaemonSet rolling update feature is only supported in Kubernetes version 1.6 or later.
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## DaemonSet Update Strategy
|
||||
|
|
@ -164,7 +157,7 @@ make room for new DaemonSet pods.
|
|||
|
||||
{{< note >}}
|
||||
This will cause service disruption when deleted pods are not controlled by any controllers or pods are not
|
||||
replicated. This does not respect [PodDisruptionBudget](/docs/tasks/configure-pod-container/configure-pod-disruption-budget/)
|
||||
replicated. This does not respect [PodDisruptionBudget](/docs/tasks/run-application/configure-pdb/)
|
||||
either.
|
||||
{{< /note >}}
|
||||
|
||||
|
|
|
|||
|
|
@ -14,53 +14,54 @@ This page shows how to manually rotate the certificate authority (CA) certificat
|
|||
|
||||
|
||||
- For more information about authentication in Kubernetes, see [Authenticating](/docs/reference/access-authn-authz/authentication).
|
||||
- For more information about best practices for CA certificates, see [Single root CA](docs/setup/best-practices/certificates/#single-root-ca).
|
||||
- For more information about best practices for CA certificates, see [Single root CA](/docs/setup/best-practices/certificates/#single-root-ca).
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Rotate the CA certificates manually
|
||||
|
||||
{{< caution >}}
|
||||
|
||||
Make sure to back up your certificate directory along with configuration files and any other necessary files.
|
||||
|
||||
This approach assumes operation of the Kubernetes control plane in a HA configuration with multiple API servers. Graceful termination of the API server is also assumed so clients can cleanly disconnect from one API server and reconnect to another.
|
||||
This approach assumes operation of the Kubernetes control plane in a HA configuration with multiple API servers.
|
||||
Graceful termination of the API server is also assumed so clients can cleanly disconnect from one API server and reconnect to another.
|
||||
|
||||
Configurations with a single API server will experience unavailability while the API server is being restarted.
|
||||
|
||||
{{< /caution >}}
|
||||
|
||||
1. Distribute the new CA certificates and private keys (ex: `ca.crt`, `ca.key`, `front-proxy-ca.crt`, and `front-proxy-ca.key`) to all your control plane nodes in the Kubernetes certificates directory.
|
||||
1. Distribute the new CA certificates and private keys
|
||||
(ex: `ca.crt`, `ca.key`, `front-proxy-ca.crt`, and `front-proxy-ca.key`)
|
||||
to all your control plane nodes in the Kubernetes certificates directory.
|
||||
|
||||
1. Update *Kubernetes controller manager's* `--root-ca-file` to include both old and new CA and restart controller manager.
|
||||
|
||||
Any service account created after this point will get secrets that include both old and new CAs.
|
||||
Any service account created after this point will get secrets that include both old and new CAs.
|
||||
|
||||
{{< note >}}
|
||||
|
||||
Remove the flag `--client-ca-file` from the *Kubernetes controller manager* configuration. You can also replace the existing client CA file or change this configuration item to reference a new, updated CA. [Issue 1350](https://github.com/kubernetes/kubeadm/issues/1350) tracks an issue with *Kubernetes controller manager* being unable to accept a CA bundle.
|
||||
|
||||
{{< /note >}}
|
||||
{{< note >}}
|
||||
Remove the flag `--client-ca-file` from the *Kubernetes controller manager* configuration.
|
||||
You can also replace the existing client CA file or change this configuration item to reference a new, updated CA.
|
||||
[Issue 1350](https://github.com/kubernetes/kubeadm/issues/1350) tracks an issue with *Kubernetes controller manager* being unable to accept a CA bundle.
|
||||
{{< /note >}}
|
||||
|
||||
1. Update all service account tokens to include both old and new CA certificates.
|
||||
|
||||
If any pods are started before new CA is used by API servers, they will get this update and trust both old and new CAs.
|
||||
If any pods are started before new CA is used by API servers, they will get this update and trust both old and new CAs.
|
||||
|
||||
```shell
|
||||
base64_encoded_ca="$(base64 <path to file containing both old and new CAs>)"
|
||||
```shell
|
||||
base64_encoded_ca="$(base64 <path to file containing both old and new CAs>)"
|
||||
|
||||
for namespace in $(kubectl get ns --no-headers | awk '{print $1}'); do
|
||||
for token in $(kubectl get secrets --namespace "$namespace" --field-selector type=kubernetes.io/service-account-token -o name); do
|
||||
kubectl get $token --namespace "$namespace" -o yaml | \
|
||||
/bin/sed "s/\(ca.crt:\).*/\1 ${base64_encoded_ca}" | \
|
||||
kubectl apply -f -
|
||||
done
|
||||
done
|
||||
```
|
||||
for namespace in $(kubectl get ns --no-headers | awk '{print $1}'); do
|
||||
for token in $(kubectl get secrets --namespace "$namespace" --field-selector type=kubernetes.io/service-account-token -o name); do
|
||||
kubectl get $token --namespace "$namespace" -o yaml | \
|
||||
/bin/sed "s/\(ca.crt:\).*/\1 ${base64_encoded_ca}" | \
|
||||
kubectl apply -f -
|
||||
done
|
||||
done
|
||||
```
|
||||
|
||||
1. Restart all pods using in-cluster configs (ex: kube-proxy, coredns, etc) so they can use the updated certificate authority data from *ServiceAccount* secrets.
|
||||
|
||||
* Make sure coredns, kube-proxy and other pods using in-cluster configs are working as expected.
|
||||
* Make sure coredns, kube-proxy and other pods using in-cluster configs are working as expected.
|
||||
|
||||
1. Append the both old and new CA to the file against `--client-ca-file` and `--kubelet-certificate-authority` flag in the `kube-apiserver` configuration.
|
||||
|
||||
|
|
@ -68,77 +69,88 @@ Configurations with a single API server will experience unavailability while the
|
|||
|
||||
1. Update certificates for user accounts by replacing the content of `client-certificate-data` and `client-key-data` respectively.
|
||||
|
||||
For information about creating certificates for individual user accounts, see [Configure certificates for user accounts](/docs/setup/best-practices/certificates/#configure-certificates-for-user-accounts).
|
||||
For information about creating certificates for individual user accounts, see
|
||||
[Configure certificates for user accounts](/docs/setup/best-practices/certificates/#configure-certificates-for-user-accounts).
|
||||
|
||||
Additionally, update the `certificate-authority-data` section in the kubeconfig files, respectively with Base64-encoded old and new certificate authority data
|
||||
Additionally, update the `certificate-authority-data` section in the kubeconfig files,
|
||||
respectively with Base64-encoded old and new certificate authority data
|
||||
|
||||
1. Follow below steps in a rolling fashion.
|
||||
|
||||
1. Restart any other *[aggregated api servers](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)* or *webhook handlers* to trust the new CA certificates.
|
||||
1. Restart any other *[aggregated api servers](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)*
|
||||
or *webhook handlers* to trust the new CA certificates.
|
||||
|
||||
1. Restart the kubelet by update the file against `clientCAFile` in kubelet configuration and `certificate-authority-data` in kubelet.conf to use both the old and new CA on all nodes.
|
||||
1. Restart the kubelet by update the file against `clientCAFile` in kubelet configuration and
|
||||
`certificate-authority-data` in kubelet.conf to use both the old and new CA on all nodes.
|
||||
|
||||
If your kubelet is not using client certificate rotation update `client-certificate-data` and `client-key-data` in kubelet.conf on all nodes along with the kubelet client certificate file usually found in `/var/lib/kubelet/pki`.
|
||||
If your kubelet is not using client certificate rotation update `client-certificate-data` and
|
||||
`client-key-data` in kubelet.conf on all nodes along with the kubelet client certificate file
|
||||
usually found in `/var/lib/kubelet/pki`.
|
||||
|
||||
|
||||
1. Restart API servers with the certificates (`apiserver.crt`, `apiserver-kubelet-client.crt` and `front-proxy-client.crt`) signed by new CA. You can use the existing private keys or new private keys. If you changed the private keys then update these in the Kubernetes certificates directory as well.
|
||||
1. Restart API servers with the certificates (`apiserver.crt`, `apiserver-kubelet-client.crt` and
|
||||
`front-proxy-client.crt`) signed by new CA.
|
||||
You can use the existing private keys or new private keys.
|
||||
If you changed the private keys then update these in the Kubernetes certificates directory as well.
|
||||
|
||||
Since the pod trusts both old and new CAs, there will be a momentarily disconnection after which the pod's kube client will reconnect to the new API server that uses the certificate signed by the new CA.
|
||||
Since the pod trusts both old and new CAs, there will be a momentarily disconnection
|
||||
after which the pod's kube client will reconnect to the new API server
|
||||
that uses the certificate signed by the new CA.
|
||||
|
||||
* Restart Scheduler to use the new CAs.
|
||||
* Restart Scheduler to use the new CAs.
|
||||
|
||||
* Make sure control plane components logs no TLS errors.
|
||||
* Make sure control plane components logs no TLS errors.
|
||||
|
||||
{{< note >}}
|
||||
{{< note >}}
|
||||
To generate certificates and private keys for your cluster using the `openssl` command line tool, see [Certificates (`openssl`)](/docs/concepts/cluster-administration/certificates/#openssl).
|
||||
You can also use [`cfssl`](/docs/concepts/cluster-administration/certificates/#cfssl).
|
||||
{{< /note >}}
|
||||
|
||||
To generate certificates and private keys for your cluster using the `openssl` command line tool, see [Certificates (`openssl`)](/docs/concepts/cluster-administration/certificates/#openssl).
|
||||
You can also use [`cfssl`](/docs/concepts/cluster-administration/certificates/#cfssl).
|
||||
1. Annotate any Daemonsets and Deployments to trigger pod replacement in a safer rolling fashion.
|
||||
|
||||
{{< /note >}}
|
||||
Example:
|
||||
|
||||
1. Annotate any Daemonsets and Deployments to trigger pod replacement in a safer rolling fashion.
|
||||
```shell
|
||||
for namespace in $(kubectl get namespace -o jsonpath='{.items[*].metadata.name}'); do
|
||||
for name in $(kubectl get deployments -n $namespace -o jsonpath='{.items[*].metadata.name}'); do
|
||||
kubectl patch deployment -n ${namespace} ${name} -p '{"spec":{"template":{"metadata":{"annotations":{"ca-rotation": "1"}}}}}';
|
||||
done
|
||||
for name in $(kubectl get daemonset -n $namespace -o jsonpath='{.items[*].metadata.name}'); do
|
||||
kubectl patch daemonset -n ${namespace} ${name} -p '{"spec":{"template":{"metadata":{"annotations":{"ca-rotation": "1"}}}}}';
|
||||
done
|
||||
done
|
||||
```
|
||||
|
||||
Example:
|
||||
|
||||
```shell
|
||||
for namespace in $(kubectl get namespace -o jsonpath='{.items[*].metadata.name}'); do
|
||||
for name in $(kubectl get deployments -n $namespace -o jsonpath='{.items[*].metadata.name}'); do
|
||||
kubectl patch deployment -n ${namespace} ${name} -p '{"spec":{"template":{"metadata":{"annotations":{"ca-rotation": "1"}}}}}';
|
||||
done
|
||||
for name in $(kubectl get daemonset -n $namespace -o jsonpath='{.items[*].metadata.name}'); do
|
||||
kubectl patch daemonset -n ${namespace} ${name} -p '{"spec":{"template":{"metadata":{"annotations":{"ca-rotation": "1"}}}}}';
|
||||
done
|
||||
done
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
|
||||
To limit the number of concurrent disruptions that your application experiences, see [configure pod disruption budget](docs/tasks/run-application/configure-pdb/).
|
||||
|
||||
{{< /note >}}
|
||||
{{< note >}}
|
||||
To limit the number of concurrent disruptions that your application experiences,
|
||||
see [configure pod disruption budget](/docs/tasks/run-application/configure-pdb/).
|
||||
{{< /note >}}
|
||||
|
||||
1. If your cluster is using bootstrap tokens to join nodes, update the ConfigMap `cluster-info` in the `kube-public` namespace with new CA.
|
||||
|
||||
```shell
|
||||
base64_encoded_ca="$(base64 /etc/kubernetes/pki/ca.crt)"
|
||||
```shell
|
||||
base64_encoded_ca="$(base64 /etc/kubernetes/pki/ca.crt)"
|
||||
|
||||
kubectl get cm/cluster-info --namespace kube-public -o yaml | \
|
||||
/bin/sed "s/\(certificate-authority-data:\).*/\1 ${base64_encoded_ca}" | \
|
||||
kubectl apply -f -
|
||||
```
|
||||
kubectl get cm/cluster-info --namespace kube-public -o yaml | \
|
||||
/bin/sed "s/\(certificate-authority-data:\).*/\1 ${base64_encoded_ca}" | \
|
||||
kubectl apply -f -
|
||||
```
|
||||
|
||||
1. Verify the cluster functionality.
|
||||
|
||||
1. Validate the logs from control plane components, along with the kubelet and the kube-proxy are not throwing any tls errors, see [looking at the logs](/docs/tasks/debug-application-cluster/debug-cluster/#looking-at-logs).
|
||||
1. Validate the logs from control plane components, along with the kubelet and the
|
||||
kube-proxy are not throwing any tls errors, see
|
||||
[looking at the logs](/docs/tasks/debug-application-cluster/debug-cluster/#looking-at-logs).
|
||||
|
||||
1. Validate logs from any aggregated api servers and pods using in-cluster config.
|
||||
1. Validate logs from any aggregated api servers and pods using in-cluster config.
|
||||
|
||||
1. Once the cluster functionality is successfully verified:
|
||||
|
||||
1. Update all service account tokens to include new CA certificate only.
|
||||
1. Update all service account tokens to include new CA certificate only.
|
||||
|
||||
* All pods using an in-cluster kubeconfig will eventually need to be restarted to pick up the new SA secret for the old CA to be completely untrusted.
|
||||
* All pods using an in-cluster kubeconfig will eventually need to be restarted to pick up the new SA secret for the old CA to be completely untrusted.
|
||||
|
||||
1. Restart the control plane components by removing the old CA from the kubeconfig files and the files against `--client-ca-file`, `--root-ca-file` flags resp.
|
||||
1. Restart the control plane components by removing the old CA from the kubeconfig files and the files against `--client-ca-file`, `--root-ca-file` flags resp.
|
||||
|
||||
1. Restart kubelet by removing the old CA from file against the `clientCAFile` flag and kubelet kubeconfig file.
|
||||
|
||||
1. Restart kubelet by removing the old CA from file against the `clientCAFile` flag and kubelet kubeconfig file.
|
||||
|
|
|
|||
|
|
@ -310,7 +310,12 @@ You can install kubectl as part of the Google Cloud SDK.
|
|||
|
||||
## Verifying kubectl configuration
|
||||
|
||||
In order for kubectl to find and access a Kubernetes cluster, it needs a [kubeconfig file](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/), which is created automatically when you create a cluster using [kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh) or successfully deploy a Minikube cluster. By default, kubectl configuration is located at `~/.kube/config`.
|
||||
In order for kubectl to find and access a Kubernetes cluster, it needs a
|
||||
[kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/),
|
||||
which is created automatically when you create a cluster using
|
||||
[kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh)
|
||||
or successfully deploy a Minikube cluster.
|
||||
By default, kubectl configuration is located at `~/.kube/config`.
|
||||
|
||||
Check that kubectl is properly configured by getting the cluster state:
|
||||
|
||||
|
|
@ -518,5 +523,7 @@ compinit
|
|||
* [Install Minikube](/docs/tasks/tools/install-minikube/)
|
||||
* See the [getting started guides](/docs/setup/) for more about creating clusters.
|
||||
* [Learn how to launch and expose your application.](/docs/tasks/access-application-cluster/service-access-application-cluster/)
|
||||
* If you need access to a cluster you didn't create, see the [Sharing Cluster Access document](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/).
|
||||
* If you need access to a cluster you didn't create, see the
|
||||
[Sharing Cluster Access document](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/).
|
||||
* Read the [kubectl reference docs](/docs/reference/kubectl/kubectl/)
|
||||
|
||||
|
|
|
|||
|
|
@ -118,7 +118,7 @@ Pod runs a Container based on the provided Docker image.
|
|||
```
|
||||
|
||||
{{< note >}}
|
||||
For more information about `kubectl`commands, see the [kubectl overview](/docs/user-guide/kubectl-overview/).
|
||||
For more information about `kubectl` commands, see the [kubectl overview](/docs/reference/kubectl/overview/).
|
||||
{{< /note >}}
|
||||
|
||||
## Create a Service
|
||||
|
|
|
|||
|
|
@ -412,7 +412,7 @@ protocol between the loadbalancer and backend to communicate the true client IP
|
|||
such as the HTTP [Forwarded](https://tools.ietf.org/html/rfc7239#section-5.2)
|
||||
or [X-FORWARDED-FOR](https://en.wikipedia.org/wiki/X-Forwarded-For)
|
||||
headers, or the
|
||||
[proxy protocol](http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt).
|
||||
[proxy protocol](https://www.haproxy.org/download/1.5/doc/proxy-protocol.txt).
|
||||
Load balancers in the second category can leverage the feature described above
|
||||
by creating an HTTP health check pointing at the port stored in
|
||||
the `service.spec.healthCheckNodePort` field on the Service.
|
||||
|
|
|
|||
|
|
@ -7,9 +7,13 @@ weight: 30
|
|||
---
|
||||
|
||||
<!-- overview -->
|
||||
This tutorial shows you how to run [Apache Cassandra](http://cassandra.apache.org/) on Kubernetes. Cassandra, a database, needs persistent storage to provide data durability (application _state_). In this example, a custom Cassandra seed provider lets the database discover new Cassandra instances as they join the Cassandra cluster.
|
||||
This tutorial shows you how to run [Apache Cassandra](https://cassandra.apache.org/) on Kubernetes.
|
||||
Cassandra, a database, needs persistent storage to provide data durability (application _state_).
|
||||
In this example, a custom Cassandra seed provider lets the database discover new Cassandra instances as they join the Cassandra cluster.
|
||||
|
||||
*StatefulSets* make it easier to deploy stateful applications into your Kubernetes cluster. For more information on the features used in this tutorial, see [StatefulSet](/docs/concepts/workloads/controllers/statefulset/).
|
||||
*StatefulSets* make it easier to deploy stateful applications into your Kubernetes cluster.
|
||||
For more information on the features used in this tutorial, see
|
||||
[StatefulSet](/docs/concepts/workloads/controllers/statefulset/).
|
||||
|
||||
{{< note >}}
|
||||
Cassandra and Kubernetes both use the term _node_ to mean a member of a cluster. In this
|
||||
|
|
@ -38,12 +42,17 @@ new Cassandra Pods as they appear inside your Kubernetes cluster.
|
|||
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
To complete this tutorial, you should already have a basic familiarity with {{< glossary_tooltip text="Pods" term_id="pod" >}}, {{< glossary_tooltip text="Services" term_id="service" >}}, and {{< glossary_tooltip text="StatefulSets" term_id="StatefulSet" >}}.
|
||||
To complete this tutorial, you should already have a basic familiarity with
|
||||
{{< glossary_tooltip text="Pods" term_id="pod" >}},
|
||||
{{< glossary_tooltip text="Services" term_id="service" >}}, and
|
||||
{{< glossary_tooltip text="StatefulSets" term_id="StatefulSet" >}}.
|
||||
|
||||
### Additional Minikube setup instructions
|
||||
|
||||
{{< caution >}}
|
||||
[Minikube](/docs/getting-started-guides/minikube/) defaults to 1024MiB of memory and 1 CPU. Running Minikube with the default resource configuration results in insufficient resource errors during this tutorial. To avoid these errors, start Minikube with the following settings:
|
||||
[Minikube](/docs/setup/learning-environment/minikube/) defaults to 1024MiB of memory and 1 CPU.
|
||||
Running Minikube with the default resource configuration results in insufficient resource
|
||||
errors during this tutorial. To avoid these errors, start Minikube with the following settings:
|
||||
|
||||
```shell
|
||||
minikube start --memory 5120 --cpus=4
|
||||
|
|
@ -51,11 +60,11 @@ minikube start --memory 5120 --cpus=4
|
|||
{{< /caution >}}
|
||||
|
||||
|
||||
|
||||
<!-- lessoncontent -->
|
||||
## Creating a headless Service for Cassandra {#creating-a-cassandra-headless-service}
|
||||
|
||||
In Kubernetes, a {{< glossary_tooltip text="Service" term_id="service" >}} describes a set of {{< glossary_tooltip text="Pods" term_id="pod" >}} that perform the same task.
|
||||
In Kubernetes, a {{< glossary_tooltip text="Service" term_id="service" >}} describes a set of
|
||||
{{< glossary_tooltip text="Pods" term_id="pod" >}} that perform the same task.
|
||||
|
||||
The following Service is used for DNS lookups between Cassandra Pods and clients within your cluster:
|
||||
|
||||
|
|
@ -83,14 +92,17 @@ NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
|||
cassandra ClusterIP None <none> 9042/TCP 45s
|
||||
```
|
||||
|
||||
If you don't see a Service named `cassandra`, that means creation failed. Read [Debug Services](/docs/tasks/debug-application-cluster/debug-service/) for help troubleshooting common issues.
|
||||
If you don't see a Service named `cassandra`, that means creation failed. Read
|
||||
[Debug Services](/docs/tasks/debug-application-cluster/debug-service/)
|
||||
for help troubleshooting common issues.
|
||||
|
||||
## Using a StatefulSet to create a Cassandra ring
|
||||
|
||||
The StatefulSet manifest, included below, creates a Cassandra ring that consists of three Pods.
|
||||
|
||||
{{< note >}}
|
||||
This example uses the default provisioner for Minikube. Please update the following StatefulSet for the cloud you are working with.
|
||||
This example uses the default provisioner for Minikube.
|
||||
Please update the following StatefulSet for the cloud you are working with.
|
||||
{{< /note >}}
|
||||
|
||||
{{< codenew file="application/cassandra/cassandra-statefulset.yaml" >}}
|
||||
|
|
@ -182,7 +194,8 @@ Use `kubectl edit` to modify the size of a Cassandra StatefulSet.
|
|||
kubectl edit statefulset cassandra
|
||||
```
|
||||
|
||||
This command opens an editor in your terminal. The line you need to change is the `replicas` field. The following sample is an excerpt of the StatefulSet file:
|
||||
This command opens an editor in your terminal. The line you need to change is the `replicas` field.
|
||||
The following sample is an excerpt of the StatefulSet file:
|
||||
|
||||
```yaml
|
||||
# Please edit the object below. Lines beginning with a '#' will be ignored,
|
||||
|
|
@ -225,10 +238,12 @@ Use `kubectl edit` to modify the size of a Cassandra StatefulSet.
|
|||
|
||||
## {{% heading "cleanup" %}}
|
||||
|
||||
Deleting or scaling a StatefulSet down does not delete the volumes associated with the StatefulSet. This setting is for your safety because your data is more valuable than automatically purging all related StatefulSet resources.
|
||||
Deleting or scaling a StatefulSet down does not delete the volumes associated with the StatefulSet.
|
||||
This setting is for your safety because your data is more valuable than automatically purging all related StatefulSet resources.
|
||||
|
||||
{{< warning >}}
|
||||
Depending on the storage class and reclaim policy, deleting the *PersistentVolumeClaims* may cause the associated volumes to also be deleted. Never assume you’ll be able to access data if its volume claims are deleted.
|
||||
Depending on the storage class and reclaim policy, deleting the *PersistentVolumeClaims* may cause the associated volumes
|
||||
to also be deleted. Never assume you’ll be able to access data if its volume claims are deleted.
|
||||
{{< /warning >}}
|
||||
|
||||
1. Run the following commands (chained together into a single command) to delete everything in the Cassandra StatefulSet:
|
||||
|
|
|
|||
|
|
@ -15,25 +15,23 @@ weight: 40
|
|||
<!-- overview -->
|
||||
This tutorial demonstrates running [Apache Zookeeper](https://zookeeper.apache.org) on
|
||||
Kubernetes using [StatefulSets](/docs/concepts/workloads/controllers/statefulset/),
|
||||
[PodDisruptionBudgets](/docs/concepts/workloads/pods/disruptions/#specifying-a-poddisruptionbudget),
|
||||
and [PodAntiAffinity](/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature).
|
||||
|
||||
[PodDisruptionBudgets](/docs/concepts/workloads/pods/disruptions/#pod-disruption-budget),
|
||||
and [PodAntiAffinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity).
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
Before starting this tutorial, you should be familiar with the following
|
||||
Kubernetes concepts.
|
||||
|
||||
- [Pods](/docs/user-guide/pods/single-container/)
|
||||
- [Pods](/docs/concepts/workloads/pods/)
|
||||
- [Cluster DNS](/docs/concepts/services-networking/dns-pod-service/)
|
||||
- [Headless Services](/docs/concepts/services-networking/service/#headless-services)
|
||||
- [PersistentVolumes](/docs/concepts/storage/volumes/)
|
||||
- [PersistentVolume Provisioning](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/)
|
||||
- [StatefulSets](/docs/concepts/workloads/controllers/statefulset/)
|
||||
- [PodDisruptionBudgets](/docs/concepts/workloads/pods/disruptions/#specifying-a-poddisruptionbudget)
|
||||
- [PodAntiAffinity](/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature)
|
||||
- [kubectl CLI](/docs/user-guide/kubectl/)
|
||||
- [PodDisruptionBudgets](/docs/concepts/workloads/pods/disruptions/#pod-disruption-budget)
|
||||
- [PodAntiAffinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)
|
||||
- [kubectl CLI](/docs/reference/kubectl/kubectl/)
|
||||
|
||||
You will require a cluster with at least four nodes, and each node requires at least 2 CPUs and 4 GiB of memory. In this tutorial you will cordon and drain the cluster's nodes. **This means that the cluster will terminate and evict all Pods on its nodes, and the nodes will temporarily become unschedulable.** You should use a dedicated cluster for this tutorial, or you should ensure that the disruption you cause will not interfere with other tenants.
|
||||
|
||||
|
|
@ -75,7 +73,7 @@ ZooKeeper servers keep their entire state machine in memory, and write every mut
|
|||
The manifest below contains a
|
||||
[Headless Service](/docs/concepts/services-networking/service/#headless-services),
|
||||
a [Service](/docs/concepts/services-networking/service/),
|
||||
a [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions//#specifying-a-poddisruptionbudget),
|
||||
a [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/#pod-disruption-budgets),
|
||||
and a [StatefulSet](/docs/concepts/workloads/controllers/statefulset/).
|
||||
|
||||
{{< codenew file="application/zookeeper/zookeeper.yaml" >}}
|
||||
|
|
@ -127,7 +125,7 @@ zk-2 1/1 Running 0 40s
|
|||
```
|
||||
|
||||
The StatefulSet controller creates three Pods, and each Pod has a container with
|
||||
a [ZooKeeper](http://www-us.apache.org/dist/zookeeper/stable/) server.
|
||||
a [ZooKeeper](https://www-us.apache.org/dist/zookeeper/stable/) server.
|
||||
|
||||
### Facilitating Leader Election
|
||||
|
||||
|
|
@ -502,7 +500,7 @@ The command used to start the ZooKeeper servers passed the configuration as comm
|
|||
### Configuring Logging
|
||||
|
||||
One of the files generated by the `zkGenConfig.sh` script controls ZooKeeper's logging.
|
||||
ZooKeeper uses [Log4j](http://logging.apache.org/log4j/2.x/), and, by default,
|
||||
ZooKeeper uses [Log4j](https://logging.apache.org/log4j/2.x/), and, by default,
|
||||
it uses a time and size based rolling file appender for its logging configuration.
|
||||
|
||||
Use the command below to get the logging configuration from one of Pods in the `zk` `StatefulSet`.
|
||||
|
|
@ -524,7 +522,10 @@ log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout
|
|||
log4j.appender.CONSOLE.layout.ConversionPattern=%d{ISO8601} [myid:%X{myid}] - %-5p [%t:%C{1}@%L] - %m%n
|
||||
```
|
||||
|
||||
This is the simplest possible way to safely log inside the container. Because the applications write logs to standard out, Kubernetes will handle log rotation for you. Kubernetes also implements a sane retention policy that ensures application logs written to standard out and standard error do not exhaust local storage media.
|
||||
This is the simplest possible way to safely log inside the container.
|
||||
Because the applications write logs to standard out, Kubernetes will handle log rotation for you.
|
||||
Kubernetes also implements a sane retention policy that ensures application logs written to
|
||||
standard out and standard error do not exhaust local storage media.
|
||||
|
||||
Use [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands/#logs) to retrieve the last 20 log lines from one of the Pods.
|
||||
|
||||
|
|
@ -679,7 +680,7 @@ statefulset.apps/zk rolled back
|
|||
|
||||
### Handling Process Failure
|
||||
|
||||
[Restart Policies](/docs/user-guide/pod-states/#restartpolicy) control how
|
||||
[Restart Policies](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) control how
|
||||
Kubernetes handles process failures for the entry point of the container in a Pod.
|
||||
For Pods in a `StatefulSet`, the only appropriate `RestartPolicy` is Always, and this
|
||||
is the default value. For stateful applications you should **never** override
|
||||
|
|
@ -832,7 +833,9 @@ domains to ensure availability. To avoid an outage, due to the loss of an
|
|||
individual machine, best practices preclude co-locating multiple instances of the
|
||||
application on the same machine.
|
||||
|
||||
By default, Kubernetes may co-locate Pods in a `StatefulSet` on the same node. For the three server ensemble you created, if two servers are on the same node, and that node fails, the clients of your ZooKeeper service will experience an outage until at least one of the Pods can be rescheduled.
|
||||
By default, Kubernetes may co-locate Pods in a `StatefulSet` on the same node.
|
||||
For the three server ensemble you created, if two servers are on the same node, and that node fails,
|
||||
the clients of your ZooKeeper service will experience an outage until at least one of the Pods can be rescheduled.
|
||||
|
||||
You should always provision additional capacity to allow the processes of critical
|
||||
systems to be rescheduled in the event of node failures. If you do so, then the
|
||||
|
|
@ -978,7 +981,8 @@ pod "zk-1" deleted
|
|||
node "kubernetes-node-ixsl" drained
|
||||
```
|
||||
|
||||
The `zk-1` Pod cannot be scheduled because the `zk` `StatefulSet` contains a `PodAntiAffinity` rule preventing co-location of the Pods, and as only two nodes are schedulable, the Pod will remain in a Pending state.
|
||||
The `zk-1` Pod cannot be scheduled because the `zk` `StatefulSet` contains a `PodAntiAffinity` rule preventing
|
||||
co-location of the Pods, and as only two nodes are schedulable, the Pod will remain in a Pending state.
|
||||
|
||||
```shell
|
||||
kubectl get pods -w -l app=zk
|
||||
|
|
@ -1119,9 +1123,10 @@ kubectl uncordon kubernetes-node-ixsl
|
|||
node "kubernetes-node-ixsl" uncordoned
|
||||
```
|
||||
|
||||
You can use `kubectl drain` in conjunction with `PodDisruptionBudgets` to ensure that your services remain available during maintenance. If drain is used to cordon nodes and evict pods prior to taking the node offline for maintenance, services that express a disruption budget will have that budget respected. You should always allocate additional capacity for critical services so that their Pods can be immediately rescheduled.
|
||||
|
||||
|
||||
You can use `kubectl drain` in conjunction with `PodDisruptionBudgets` to ensure that your services remain available during maintenance.
|
||||
If drain is used to cordon nodes and evict pods prior to taking the node offline for maintenance,
|
||||
services that express a disruption budget will have that budget respected.
|
||||
You should always allocate additional capacity for critical services so that their Pods can be immediately rescheduled.
|
||||
|
||||
## {{% heading "cleanup" %}}
|
||||
|
||||
|
|
|
|||
|
|
@ -365,7 +365,7 @@ Deleting the Deployments and Services also deletes any running Pods. Use labels
|
|||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* Add [ELK logging and monitoring](../guestbook-logs-metrics-with-elk/) to your Guestbook application
|
||||
* Add [ELK logging and monitoring](/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk/) to your Guestbook application
|
||||
* Complete the [Kubernetes Basics](/docs/tutorials/kubernetes-basics/) Interactive Tutorials
|
||||
* Use Kubernetes to create a blog using [Persistent Volumes for MySQL and Wordpress](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/#visit-your-new-wordpress-blog)
|
||||
* Read more about [connecting applications](/docs/concepts/services-networking/connect-applications-service/)
|
||||
|
|
|
|||
|
|
@ -0,0 +1,20 @@
|
|||
apiVersion: flowcontrol.apiserver.k8s.io/v1alpha1
|
||||
kind: FlowSchema
|
||||
metadata:
|
||||
name: health-for-strangers
|
||||
spec:
|
||||
matchingPrecedence: 1000
|
||||
priorityLevelConfiguration:
|
||||
name: exempt
|
||||
rules:
|
||||
- nonResourceRules:
|
||||
- nonResourceURLs:
|
||||
- "/healthz"
|
||||
- "/livez"
|
||||
- "/readyz"
|
||||
verbs:
|
||||
- "*"
|
||||
subjects:
|
||||
- kind: Group
|
||||
group:
|
||||
name: system:unauthenticated
|
||||
|
|
@ -83,7 +83,7 @@ reglas de red en el anfitrión y haciendo reenvío de conexiones.
|
|||
|
||||
### Runtime de contenedores
|
||||
|
||||
El {{< glossary_definition term_id="container-runtime" text="runtime de los contenedores" >}} es el software responsable de ejecutar los contenedores. Kubernetes soporta varios de
|
||||
El {{< glossary_tooltip term_id="container-runtime" text="runtime de los contenedores" >}} es el software responsable de ejecutar los contenedores. Kubernetes soporta varios de
|
||||
ellos: [Docker](http://www.docker.com), [containerd](https://containerd.io), [cri-o](https://cri-o.io/), [rktlet](https://github.com/kubernetes-incubator/rktlet) y cualquier implementación de la interfaz de runtime de contenedores de Kubernetes, o [Kubernetes CRI](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md).
|
||||
|
||||
## Addons
|
||||
|
|
|
|||
|
|
@ -0,0 +1,17 @@
|
|||
---
|
||||
title: Reviewer
|
||||
id: reviewer
|
||||
date: 2018-04-12
|
||||
full_link:
|
||||
short_description: >
|
||||
Une personne qui examine la qualité et l'exactitude du code sur une partie du projet.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- community
|
||||
---
|
||||
Une personne qui examine la qualité et l'exactitude du code sur une partie du projet.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Les réviseurs connaissent bien la base de code (codebase) et les principes d'ingénierie logicielle. Le statut du réviseur est limité à une partie de la base de code.
|
||||
|
|
@ -1,4 +1,30 @@
|
|||
---
|
||||
title: "Containers"
|
||||
title: Containers
|
||||
weight: 40
|
||||
description: La tecnologia per distribuire un'applicazione insieme con le dipendenze necessarie per la sua esecuzione.
|
||||
content_type: concept
|
||||
no_list: true
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
Ogni _container_ che viene eseguito è riproducibile; la pratica di includere le dipendenze all'interno di ciascuno _container_ permette di ottenere sempre lo stesso risultato ad ogni esecuzione del medesimo _container_.
|
||||
|
||||
I _Container_ permettono di disaccoppiare le applicazioni dall'infrastruttura del host su cui vengono eseguite. Questo approccio rende più facile il _deployment_ su cloud o sitemi operativi differenti tra loro.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Immagine di container
|
||||
L'[immagine di un container](/docs/concepts/containers/images/) e' un pacchetto software che contiene tutto ciò che serve per eseguire un'applicazione: il codice sorgente e ciascun _runtime_ necessario, librerie applicative e di sistema, e le impostazioni predefinite per ogni configurazione necessaria.
|
||||
|
||||
Un _container_ è immutabile per definizione: non è possibile modificare il codice di un _container_ in esecuzione. Se si ha un'applicazione containerizzata e la si vuole modificare, si deve costruire un nuovo _container_ che includa il cambiamento desiderato, e quindi ricreare il _container_ partendo dalla nuova immagine aggiornata.
|
||||
|
||||
## Container runtimes
|
||||
|
||||
{{< glossary_definition term_id="container-runtime" length="all" >}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* Leggi in merito [immagine di container](/docs/concepts/containers/images/)
|
||||
* Leggi in merito [Pods](/docs/concepts/workloads/pods/)
|
||||
|
||||
|
|
|
|||
|
|
@ -41,13 +41,12 @@ Kubernetesはオープンソースなので、オンプレミスやパブリッ
|
|||
<button id="desktopShowVideoButton" onclick="kub.showVideo()">ビデオを見る</button>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
<a href="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2020/" button id="desktopKCButton">2020年4月のKubeCon アムステルダムに参加する</a>
|
||||
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu20" button id="desktopKCButton">2020年8月17日-20日のKubeCon EUバーチャルに参加する</a>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
<a href="https://events19.lfasiallc.com/events/kubecon-cloudnativecon-china-2019/" button id="desktopKCButton">2020年7月のKubeCon 上海に参加する</a>
|
||||
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna20" button id="desktopKCButton">2020年11月17日-20日のKubeCon NAバーチャルに参加する</a>
|
||||
</div>
|
||||
<div id="videoPlayer">
|
||||
<iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>
|
||||
|
|
|
|||
|
|
@ -19,14 +19,14 @@ Kubernetesを機能させるには、*Kubernetes API オブジェクト* を使
|
|||
|
||||
一旦desired state (望ましい状態)を設定すると、Pod Lifecycle Event Generator([PLEG](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/pod-lifecycle-event-generator.md))を使用した*Kubernetes コントロールプレーン*が機能し、クラスターの現在の状態をdesired state (望ましい状態)に一致させます。そのためにKubernetesはさまざまなタスク(たとえば、コンテナの起動または再起動、特定アプリケーションのレプリカ数のスケーリング等)を自動的に実行します。Kubernetesコントロールプレーンは、クラスターで実行されている以下のプロセスで構成されています。
|
||||
|
||||
* **Kubernetes Master** :[kube-apiserver](/docs/admin/kube-apiserver/)、[kube-controller-manager](/docs/admin/kube-controller-manager/)、[kube-scheduler](/docs/admin/kube-scheduler/) の3プロセスの集合です。これらのプロセスはクラスター内の一つのノード上で実行されます。実行ノードはマスターノードとして指定します。
|
||||
* **Kubernetes Master**: [kube-apiserver](/docs/admin/kube-apiserver/)、[kube-controller-manager](/docs/admin/kube-controller-manager/)、[kube-scheduler](/docs/admin/kube-scheduler/) の3プロセスの集合です。これらのプロセスはクラスター内の一つのノード上で実行されます。実行ノードはマスターノードとして指定します。
|
||||
* クラスター内の個々の非マスターノードは、それぞれ2つのプロセスを実行します。
|
||||
* **[kubelet](/docs/admin/kubelet/)**, Kubernetes Masterと通信します。
|
||||
* **[kube-proxy](/docs/admin/kube-proxy/)**, 各ノードのKubernetesネットワークサービスを反映するネットワークプロキシです。
|
||||
* **[kubelet](/docs/admin/kubelet/)**: Kubernetes Masterと通信します。
|
||||
* **[kube-proxy](/docs/admin/kube-proxy/)**: 各ノードのKubernetesネットワークサービスを反映するネットワークプロキシです。
|
||||
|
||||
## Kubernetesオブジェクト
|
||||
## Kubernetesオブジェクト {#kubernetes-objects}
|
||||
|
||||
Kubernetesには、デプロイ済みのコンテナ化されたアプリケーションやワークロード、関連するネットワークとディスクリソース、クラスターが何をしているかに関するその他の情報といった、システムの状態を表現する抽象が含まれています。これらの抽象は、Kubernetes APIのオブジェクトによって表現されます。詳細については、[Kubernetesオブジェクトについて知る](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/)をご覧ください。
|
||||
Kubernetesには、デプロイ済みのコンテナ化されたアプリケーションやワークロード、関連するネットワークとディスクリソース、クラスターが何をしているかに関するその他の情報といった、システムの状態を表現する抽象が含まれています。これらの抽象は、Kubernetes APIのオブジェクトによって表現されます。詳細については、[Kubernetesオブジェクトについて知る](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects)をご覧ください。
|
||||
|
||||
基本的なKubernetesのオブジェクトは次のとおりです。
|
||||
|
||||
|
|
@ -43,7 +43,7 @@ Kubernetesには、[コントローラー](/docs/concepts/architecture/controlle
|
|||
* [ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)
|
||||
* [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)
|
||||
|
||||
## Kubernetesコントロールプレーン
|
||||
## Kubernetesコントロールプレーン {#kubernetes-control-plane}
|
||||
|
||||
Kubernetesマスターや kubeletプロセスといったKubernetesコントロールプレーンのさまざまなパーツは、Kubernetesがクラスターとどのように通信するかを統制します。コントロールプレーンはシステム内のすべてのKubernetesオブジェクトの記録を保持し、それらのオブジェクトの状態を管理するために継続的制御ループを実行します。コントロールプレーンの制御ループは常にクラスターの変更に反応し、システム内のすべてのオブジェクトの実際の状態が、指定した状態に一致するように動作します。
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
---
|
||||
title: "Kubernetesのアーキテクチャ"
|
||||
title: "クラスターのアーキテクチャ"
|
||||
weight: 30
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,14 +1,14 @@
|
|||
---
|
||||
title: クラウドコントローラーマネージャーとそのコンセプト
|
||||
content_type: concept
|
||||
weight: 30
|
||||
weight: 40
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
クラウドコントローラマネージャー(CCM)のコンセプト(バイナリと混同しないでください)は、もともとクラウドベンダー固有のソースコードと、Kubernetesのコアソースコードを独立して進化させることが出来るように作られました。クラウドコントローラーマネージャーは、Kubernetesコントローラーマネージャー、APIサーバー、そしてスケジューラーのような他のマスターコンポーネントと並行して動きます。またKubernetesのアドオンとしても動かすことができ、その場合はKubernetes上で動きます。
|
||||
クラウドコントローラマネージャー(CCM)のコンセプト(バイナリと混同しないでください)は、もともとクラウドベンダー固有のソースコードと、Kubernetesのコアソースコードを独立して進化させることができるように作られました。クラウドコントローラーマネージャーは、Kubernetesコントローラーマネージャー、APIサーバー、そしてスケジューラーのような他のマスターコンポーネントと並行して動きます。またKubernetesのアドオンとしても動かすことができ、その場合はKubernetes上で動きます。
|
||||
|
||||
クラウドコントローラーマネージャーの設計は「プラグインメカニズム」をベースにしています。そうすることで、新しいクラウドプロバイダーがプラグインを使ってKubernetesと簡単に統合出来るようになります。新しいクラウドプロバイダーに向けてKubernetesのオンボーディングを行ったり、古いモデルを利用しているクラウドプロバイダーに、新しいCCMモデルに移行させるような計画があります。
|
||||
クラウドコントローラーマネージャーの設計は「プラグインメカニズム」をベースにしています。そうすることで、新しいクラウドプロバイダーがプラグインを使ってKubernetesと簡単に統合できるようになります。新しいクラウドプロバイダーに向けてKubernetesのオンボーディングを行ったり、古いモデルを利用しているクラウドプロバイダーに、新しいCCMモデルに移行させるような計画があります。
|
||||
|
||||
このドキュメントでは、クラウドコントローラーマネージャーの背景にあるコンセプトと、それに関連する機能の詳細について話します。
|
||||
|
||||
|
|
@ -52,7 +52,7 @@ CCMは、Kubernetesコントローラーマネージャー(KCM)からいくつ
|
|||
ボリュームコントローラーは、意図的にCCMの一部になっていません。複雑さと、ベンダー固有のボリュームロジックを抽象化するのに費やした労力を考え、CCMの一部に移行しないことが決定されました。
|
||||
{{< /note >}}
|
||||
|
||||
CCMを使ったボリュームをサポートする元の計画は、プラガブルなボリュームをサポートするため、Flexボリュームを使うことでした。しかし、競合しているCSIとして知られている機能が、Flexを置き換える予定です。
|
||||
CCMを使ったボリュームをサポートする元の計画は、プラガブルなボリュームをサポートするため、[Flex](/docs/concepts/storage/volumes/#flexVolume)ボリュームを使うことでした。しかし、競合している[CSI](/docs/concepts/storage/volumes/#csi)として知られている機能が、Flexを置き換える予定です。
|
||||
|
||||
これらのダイナミクスを考慮し、我々はCSIが利用できるようになるまで、間を取った暫定措置を取ることにしました。
|
||||
|
||||
|
|
@ -79,11 +79,11 @@ CCMの大半の機能は、KCMから派生しています。前セクション
|
|||
|
||||
#### ルートコントローラー
|
||||
|
||||
ルートコントローラーは、クラスタ内の異なるノード上で稼働しているコンテナが相互に通信出来るように、クラウド内のルートを適切に設定する責務を持ちます。ルートコントローラーはGoogle Compute Engineのクラスターのみに該当します。
|
||||
ルートコントローラーは、クラスタ内の異なるノード上で稼働しているコンテナが相互に通信できるように、クラウド内のルートを適切に設定する責務を持ちます。ルートコントローラーはGoogle Compute Engineのクラスターのみに該当します。
|
||||
|
||||
#### サービスコントローラー
|
||||
|
||||
サービスコントローラーは、サービスの作成、更新、そして削除イベントの待ち受けに責務を持ちます。Kubernetes内のサービスの現在の状態を、クラウド上のロードバランサー(ELB、Google LB、またOracle Cloud Infrastructure LBなど)に反映するための設定を行います。更に、クラウドロードバランサーのバックエンドが最新の状態になっていることを保証します。
|
||||
サービスコントローラーは、サービスの作成、更新、そして削除イベントの待ち受けに責務を持ちます。Kubernetes内のサービスの現在の状態を、クラウド上のロードバランサー(ELB、Google LB、またOracle Cloud Infrastructure LBなど)に反映するための設定を行います。さらに、クラウドロードバランサーのバックエンドが最新の状態になっていることを保証します。
|
||||
|
||||
### 2. Kubelet
|
||||
|
||||
|
|
@ -93,7 +93,7 @@ CCMの大半の機能は、KCMから派生しています。前セクション
|
|||
|
||||
## プラグインメカニズム
|
||||
|
||||
クラウドコントローラーマネージャーは、Goのインターフェースを利用してクラウドの実装をプラグイン化出来るようにしています。具体的には、[こちら](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62)で定義されているクラウドプロバイダーインターフェースを利用しています。
|
||||
クラウドコントローラーマネージャーは、Goのインターフェースを利用してクラウドの実装をプラグイン化できるようにしています。具体的には、[こちら](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62)で定義されているクラウドプロバイダーインターフェースを利用しています。
|
||||
|
||||
上で強調した4つの共有コントローラーの実装、そしていくつかの共有クラウドプロバイダーインターフェースと一部の連携機能は、Kubernetesのコアにとどまります。クラウドプロバイダー特有の実装はコア機能外で構築され、コア機能内で定義されたインターフェースを実装します。
|
||||
|
||||
|
|
@ -223,13 +223,18 @@ rules:
|
|||
|
||||
下記のクラウドプロバイダーがCCMを実装しています:
|
||||
|
||||
* [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
|
||||
* [Oracle](https://github.com/oracle/oci-cloud-controller-manager)
|
||||
* [Azure](https://github.com/kubernetes/cloud-provider-azure)
|
||||
* [GCP](https://github.com/kubernetes/cloud-provider-gcp)
|
||||
* [Alibaba Cloud](https://github.com/kubernetes/cloud-provider-alibaba-cloud)
|
||||
* [AWS](https://github.com/kubernetes/cloud-provider-aws)
|
||||
* [Azure](https://github.com/kubernetes/cloud-provider-azure)
|
||||
* [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud)
|
||||
* [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)
|
||||
* [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)
|
||||
* [TencentCloud](https://github.com/TencentCloud/tencentcloud-cloud-controller-manager)
|
||||
|
||||
|
||||
## クラスター管理
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,90 @@
|
|||
---
|
||||
title: コントローラー
|
||||
content_type: concept
|
||||
weight: 30
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
ロボット工学やオートメーションの分野において、 _制御ループ_ とは、あるシステムの状態を制御する終了状態のないループのことです。
|
||||
|
||||
ここでは、制御ループの一例として、部屋の中にあるサーモスタットを挙げます。
|
||||
|
||||
あなたが温度を設定すると、それはサーモスタットに *目的の状態(desired state)* を伝えることになります。実際の部屋の温度は *現在の状態* です。サーモスタットは、装置をオンまたはオフにすることによって、現在の状態を目的の状態に近づけるように動作します。
|
||||
|
||||
{{< glossary_definition term_id="controller" length="short">}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## コントローラーパターン
|
||||
|
||||
コントローラーは少なくとも1種類のKubernetesのリソースを監視します。これらの[オブジェクト](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects)には目的の状態を表すspecフィールドがあります。リソースのコントローラーは、現在の状態を目的の状態に近づける責務を持ちます。
|
||||
|
||||
コントローラーは自分自身でアクションを実行する場合もありますが、Kubernetesではコントローラーが{{< glossary_tooltip text="APIサーバー" term_id="kube-apiserver" >}}に意味のある副作用を持つメッセージを送信することが一般的です。以下では、このような例を見ていきます。
|
||||
|
||||
{{< comment >}}
|
||||
ネームスペースコントローラーなどの一部のビルトインのコントローラーは、specのないオブジェクトに対して作用します。簡単のため、このページではそのような詳細な説明は省略します。
|
||||
{{< /comment >}}
|
||||
|
||||
### APIサーバー経由でコントロールする
|
||||
|
||||
{{< glossary_tooltip term_id="job" >}}コントローラーはKubernetesのビルトインのコントローラーの一例です。ビルトインのコントローラーは、クラスターのAPIサーバーとやりとりをして状態を管理します。
|
||||
|
||||
Jobは、1つ以上の{{< glossary_tooltip term_id="pod" >}}を起動して、タスクを実行した後に停止する、Kubernetesのリソースです。
|
||||
|
||||
(1度[スケジュール](/ja/docs/concepts/scheduling-eviction/)されると、Podオブジェクトはkubeletに対する目的の状態の一部になります。)
|
||||
|
||||
Jobコントローラーが新しいタスクを見つけると、その処理が完了するように、クラスター上のどこかで、一連のNode上のkubeletが正しい数のPodを実行することを保証します。ただし、Jobコントローラーは、自分自身でPodやコンテナを実行することはありません。代わりに、APIサーバーに対してPodの作成や削除を依頼します。{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}上の他のコンポーネントが(スケジュールして実行するべき新しいPodが存在するという)新しい情報を基に動作することによって、最終的に目的の処理が完了します。
|
||||
|
||||
新しいJobが作成されたとき、目的の状態は、そのJobが完了することです。JobコントローラーはそのJobに対する現在の状態を目的の状態に近づけるようにします。つまり、そのJobが行ってほしい処理を実行するPodを作成し、Jobが完了に近づくようにします。
|
||||
|
||||
コントローラーは、コントローラーを設定するオブジェクトも更新します。たとえば、あるJobが完了した場合、Jobコントローラーは、Jobオブジェクトに`Finished`というマークを付けます。
|
||||
|
||||
(これは、部屋が設定温度になったことを示すために、サーモスタットがランプを消灯するのに少し似ています。)
|
||||
|
||||
### 直接的なコントロール
|
||||
|
||||
Jobとは対照的に、クラスターの外部に変更を加える必要があるコントローラーもあります。
|
||||
|
||||
たとえば、クラスターに十分な数の{{< glossary_tooltip text="Node" term_id="node" >}}が存在することを保証する制御ループの場合、そのコントローラーは、必要に応じて新しいNodeをセットアップするために、現在のクラスターの外部とやりとりをする必要があります。
|
||||
|
||||
外部の状態とやりとりをするコントローラーは、目的の状態をAPIサーバーから取得した後、外部のシステムと直接通信し、現在の状態を目的の状態に近づけます。
|
||||
|
||||
(クラスター内のノードを水平にスケールさせるコントローラーが実際に存在します。詳しくは、[クラスターのオートスケーリング](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling)を読んでください。)
|
||||
|
||||
## 目的の状態 vs 現在の状態 {#desired-vs-current}
|
||||
|
||||
Kubernetesはシステムに対してクラウドネイティブな見方をするため、常に変化し続けるような状態を扱えるように設計されています。
|
||||
|
||||
処理を実行したり、制御ループが故障を自動的に修正したりしているどの時点でも、クラスターは変化中である可能性があります。つまり、クラスターは決して安定した状態にならない可能性があるということです。
|
||||
|
||||
コントローラーがクラスターのために実行されていて、有用な変更が行われるのであれば、全体的な状態が安定しているかどうかは問題にはなりません。
|
||||
|
||||
## 設計
|
||||
|
||||
設計理念として、Kubernetesは多数のコントローラーを使用しており、各コントローラーはクラスターの状態の特定の側面をそれぞれ管理しています。最もよくあるパターンは、特定の制御ループ(コントローラー)が目的の状態として1種類のリソースを使用し、目的の状態を実現することを管理するために別の種類のリソースを用意するというものです。
|
||||
|
||||
相互にリンクされた単一のモノリシックな制御ループよりは、複数の単純なコントローラーが存在する方が役に立ちます。コントローラーは故障することがあるため、Kubernetesは故障を許容するように設計されています。
|
||||
|
||||
たとえば、Jobのコントローラーは、Jobオブジェクト(新しい処理を見つけるため)およびPodオブジェクト(Jobを実行し、処理が完了したか確認するため)を監視します。この場合、なにか別のものがJobを作成し、JobコントローラーはPodを作成します。
|
||||
|
||||
{{< note >}}
|
||||
同じ種類のオブジェクトを作成または更新するコントローラーが、複数存在する場合があります。実際には、Kubernetesコントローラーは、自分が制御するリソースに関連するリソースにのみ注意を払うように作られています。
|
||||
|
||||
たとえば、DeploymentとJobがありますが、これらは両方ともPodを作成するものです。しかし、JobコントローラーはDeploymentが作成したPodを削除することはありません。各コントローラーが2つのPodを区別できる情報({{< glossary_tooltip term_id="label" text="ラベル" >}})が存在するためです。
|
||||
{{< /note >}}
|
||||
|
||||
## コントローラーを実行する方法 {#running-controllers}
|
||||
|
||||
Kubernetesには、{{< glossary_tooltip term_id="kube-controller-manager" >}}内部で動作する一組のビルトインのコントローラーが用意されています。これらビルトインのコントローラーは、コアとなる重要な振る舞いを提供します。
|
||||
|
||||
DeploymentコントローラーとJobコントローラーは、Kubernetes自体の一部として同梱されているコントローラーの例です(それゆえ「ビルトイン」のコントローラーと呼ばれます)。Kubernetesは回復性のあるコントロールプレーンを実行できるようにしているため、ビルトインのコントローラーの一部が故障しても、コントロールプレーンの別の部分が作業を引き継いでくれます。
|
||||
|
||||
Kubernetesを拡張するためにコントロールプレーンの外で動作するコントローラーもあります。もし望むなら、新しいコントローラーを自分で書くこともできます。自作のコントローラーをPodセットとして動作させたり、Kubernetesの外部で動作させることもできます。どのような動作方法が最も適しているかは、そのコントローラーがどのようなことを行うのかに依存します。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [Kubernetesコントロールプレーン](/ja/docs/concepts/#kubernetes-control-plane)について読む
|
||||
* 基本的な[Kubernetesオブジェクト](/ja/docs/concepts/#kubernetes-objects)について学ぶ
|
||||
* [Kubernetes API](/ja/docs/concepts/overview/kubernetes-api/)について学ぶ
|
||||
* 自分でコントローラーを書きたい場合は、「Kubernetesを拡張する」の[エクステンションパターン](/ja/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns)を読んでください。
|
||||
|
|
@ -6,8 +6,8 @@ weight: 20
|
|||
|
||||
<!-- overview -->
|
||||
|
||||
本ドキュメントでは、KubernetesにおけるMaster(実態はAPIサーバー)及びクラスター間のコミュニケーション経路についてまとめます。
|
||||
この文書の目的は、信頼できないネットワーク上（またはクラウドプロバイダ上の完全にパブリックなIP上）でクラスタを実行できるように、ユーザーがインストールをカスタマイズしてネットワーク構成を強化できるようにすることです。
|
||||
本ドキュメントでは、KubernetesにおけるMaster(実態はAPIサーバー)およびクラスター間のコミュニケーション経路についてまとめます。
|
||||
この文書の目的は、信頼できないネットワーク上(またはクラウドプロバイダ上の完全にパブリックなIP上)でクラスタを実行できるように、ユーザーがインストールをカスタマイズしてネットワーク構成を強化できるようにすることです。
|
||||
|
||||
|
||||
|
||||
|
|
@ -16,8 +16,8 @@ weight: 20
|
|||
|
||||
## クラスターからマスターへの通信
|
||||
|
||||
クラスターからマスターへのすべての通信経路は、APIサーバーで終端します（他のマスターコンポーネントはどれもリモートサービスを公開するように設計されていません）。
|
||||
一般的には、1つ以上の形式のクライアント[認証](/docs/reference/access-authn-authz/authentication/)が有効になっている状態で、APIサーバーはセキュアなHTTPSポート（443）でリモート接続をlistenするように構成されています。
|
||||
クラスターからマスターへのすべての通信経路は、APIサーバーで終端します(他のマスターコンポーネントはどれもリモートサービスを公開するように設計されていません)。
|
||||
一般的には、1つ以上の形式のクライアント[認証](/docs/reference/access-authn-authz/authentication/)が有効になっている状態で、APIサーバーはセキュアなHTTPSポート(443)でリモート接続をlistenするように構成されています。
|
||||
特に[匿名のリクエスト](/docs/reference/access-authn-authz/authentication/#anonymous-requests)または[サービスアカウントトークン](/docs/reference/access-authn-authz/authentication/#service-account-tokens)が許可されている場合は、1つまたは複数の[認証](/docs/reference/access-authn-authz/authorization/)を有効にする必要があります。
|
||||
|
||||
ノードには、有効なクライアント認証情報を使って安全にAPIサーバーに接続できるように、クラスターのパブリックなルート証明書をプロビジョニングする必要があります。
|
||||
|
|
@ -26,15 +26,15 @@ kubeletのクライアント証明書を自動プロビジョニングする方
|
|||
|
||||
APIサーバーに接続したいPodは、サービスアカウントを利用することで接続を安全にすることができます。そうすることで、Podが作成されたときにKubernetesがパブリックなルート証明書と有効なBearer TokenをPodに自動的に挿入します。
|
||||
|
||||
`kubernetes`サービスには（すべてのネームスペースで）、APIサーバー上のHTTPSエンドポイントに（kube-proxy経由で）リダイレクトされる仮想IPアドレスが設定されています。
|
||||
`kubernetes`サービスには(すべてのネームスペースで)、APIサーバー上のHTTPSエンドポイントに(kube-proxy経由で)リダイレクトされる仮想IPアドレスが設定されています。
|
||||
|
||||
マスターコンポーネントは、セキュアなポートを介してクラスターAPIサーバーとも通信します。
|
||||
|
||||
その結果、クラスター（ノードとそのノードで実行されているPod）からマスターへの接続はデフォルトで保護され、信頼できないネットワークやパブリックネットワークを介して実行できます。
|
||||
その結果、クラスター(ノードとそのノードで実行されているPod)からマスターへの接続はデフォルトで保護され、信頼できないネットワークやパブリックネットワークを介して実行できます。
|
||||
|
||||
## マスターからクラスターへの通信
|
||||
|
||||
マスター（APIサーバー）からクラスターへの通信には、2つの主要な通信経路があります。
|
||||
マスター(APIサーバー)からクラスターへの通信には、2つの主要な通信経路があります。
|
||||
1つ目は、APIサーバーからクラスター内の各ノードで実行されるkubeletプロセスへの通信です。
|
||||
2つ目は、APIサーバーのプロキシ機能を介した、APIサーバーから任意のノード、Pod、またはサービスへのアクセスです。
|
||||
|
||||
|
|
@ -43,7 +43,7 @@ APIサーバーに接続したいPodは、サービスアカウントを利用
|
|||
APIサーバーからkubeletへの接続は以下の目的で使用されます:
|
||||
|
||||
* Podのログを取得する
|
||||
* 実行中のPodに（kubectlを通して）接続する
|
||||
* 実行中のPodに(kubectlを通して)接続する
|
||||
* kubeletのポート転送機能を提供する
|
||||
|
||||
これらの接続は、kubeletのHTTPSエンドポイントで終了します。
|
||||
|
|
@ -64,7 +64,7 @@ API URL内のノード、Pod、またはサービス名に`https:`を付ける
|
|||
### SSHトンネル
|
||||
|
||||
Kubernetesはマスターからクラスターへの通信経路を保護するためにSSHトンネルをサポートしています。
|
||||
この設定では、APIサーバーはクラスター内の各ノード（ポート22でlistenしているsshサーバーに接続）へのSSHトンネルを開始し、トンネルを介してkubelet、ノード、Pod、またはサービス宛てのすべてのトラフィックを渡します。
|
||||
この設定では、APIサーバーはクラスター内の各ノード(ポート22でlistenしているsshサーバーに接続)へのSSHトンネルを開始し、トンネルを介してkubelet、ノード、Pod、またはサービス宛てのすべてのトラフィックを渡します。
|
||||
このトンネルにより、ノードが実行されているネットワークの外部にトラフィックが公開されないようにします。
|
||||
|
||||
SSHトンネルは現在非推奨なので、自分がしていることが分からない限り、使用しないでください。この通信チャネルに代わるものが設計されています。
|
||||
|
|
|
|||
|
|
@ -43,7 +43,6 @@ kubectl describe node <ノード名>
|
|||
|
||||
| ノードのCondition | 概要 |
|
||||
|----------------|-------------|
|
||||
| `OutOfDisk` | 新しいPodを追加するために必要なディスク容量が足りない場合に`True`になります。それ以外のときは`False`です。 |
|
||||
| `Ready` | ノードの状態がHealthyでPodを配置可能な場合に`True`になります。ノードの状態に問題があり、Podが配置できない場合に`False`になります。ノードコントローラーが、`node-monitor-grace-period`で設定された時間内(デフォルトでは40秒)に該当ノードと疎通できない場合、`Unknown`になります。 |
|
||||
| `MemoryPressure` | ノードのメモリが圧迫されているときに`True`になります。圧迫とは、メモリの空き容量が少ないことを指します。それ以外のときは`False`です。 |
|
||||
| `PIDPressure` | プロセスが圧迫されているときに`True`になります。圧迫とは、プロセス数が多すぎることを指します。それ以外のときは`False`です。 |
|
||||
|
|
@ -69,18 +68,9 @@ Ready conditionが`pod-eviction-timeout`に設定された時間を超えても`
|
|||
|
||||
バージョン1.5よりも前のKubernetesでは、ノードコントローラーはAPIサーバーから到達不能なそれらのPodを[強制削除](/ja/docs/concepts/workloads/pods/pod/#podの強制削除)していました。しかしながら、1.5以降では、ノードコントローラーはクラスター内でPodが停止するのを確認するまでは強制的に削除しないようになりました。到達不能なノード上で動いているPodは`Terminating`または`Unknown`のステータスになります。Kubernetesが基盤となるインフラストラクチャーを推定できない場合、クラスター管理者は手動でNodeオブジェクトを削除する必要があります。KubernetesからNodeオブジェクトを削除すると、そのノードで実行されているすべてのPodオブジェクトがAPIサーバーから削除され、それらの名前が解放されます。
|
||||
|
||||
バージョン1.12において、`TaintNodesByCondition`機能がBetaに昇格し、それによってノードのライフサイクルコントローラーがconditionを表した[taint](/docs/concepts/configuration/taint-and-toleration/)を自動的に生成するようになりました。
|
||||
同様に、スケジューラーがPodを配置するノードを検討する際、ノードのtaintとPodのtolerationsを見るかわりにconditionを無視するようになりました。
|
||||
ノードのライフサイクルコントローラーがconditionを表した[taint](/docs/concepts/configuration/taint-and-toleration/)を自動的に生成します。
|
||||
|
||||
ユーザーは、古いスケジューリングモデルか、新しくてより柔軟なスケジューリングモデルのどちらかを選択できるようになりました。
|
||||
上記のtolerationがないPodは古いスケジュールモデルに従ってスケジュールされます。しかし、特定のノードのtaintを許容するPodについては、条件に合ったノードにスケジュールすることができます。
|
||||
|
||||
{{< caution >}}
|
||||
|
||||
この機能を有効にすると、conditionが観測されてからtaintが作成されるまでの間にわずかな遅延が発生します。
|
||||
この遅延は通常1秒未満ですが、正常にスケジュールされているが、kubeletによって配置を拒否されたPodの数が増える可能性があります。
|
||||
|
||||
{{< /caution >}}
|
||||
スケジューラーがPodをノードに割り当てる際、ノードのtaintを考慮します。Podが許容するtaintは例外です。
|
||||
|
||||
### CapacityとAllocatable {#capacity}
|
||||
|
||||
|
|
@ -91,7 +81,7 @@ allocatableブロックは、通常のPodによって消費されるノード上
|
|||
|
||||
CapacityとAllocatableについて深く知りたい場合は、ノード上でどのように[コンピュートリソースが予約されるか](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)を読みながら学ぶことができます。
|
||||
|
||||
### Info
|
||||
### Info {#info}
|
||||
|
||||
カーネルのバージョン、Kubernetesのバージョン（kubeletおよびkube-proxyのバージョン）、（使用されている場合）Dockerのバージョン、OS名など、ノードに関する一般的な情報です。
|
||||
この情報はノードからkubeletを通じて取得されます。
|
||||
|
|
@ -114,6 +104,7 @@ CapacityとAllocatableについて深く知りたい場合は、ノード上で
|
|||
```
|
||||
|
||||
Kubernetesは内部的にNodeオブジェクトを作成し、 `metadata.name`フィールドに基づくヘルスチェックによってノードを検証します。ノードが有効な場合、つまり必要なサービスがすべて実行されている場合は、Podを実行する資格があります。それ以外の場合、該当ノードが有効になるまではいかなるクラスターの活動に対しても無視されます。
|
||||
Nodeオブジェクトの名前は有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。
|
||||
|
||||
{{< note >}}
|
||||
Kubernetesは無効なノードのためにオブジェクトを保存し、それをチェックし続けます。
|
||||
|
|
@ -136,9 +127,19 @@ Kubernetesは無効なノードのためにオブジェクトを保存し、そ
|
|||
ノードが到達不能(例えば、ノードがダウンしているなどので理由で、ノードコントローラーがハートビートの受信を停止した場合)になると、ノードコントローラーは、NodeStatusのNodeReady conditionをConditionUnknownに変更する役割があります。その後も該当ノードが到達不能のままであった場合、Graceful Terminationを使って全てのPodを退役させます。デフォルトのタイムアウトは、ConditionUnknownの報告を開始するまで40秒、その後Podの追い出しを開始するまで5分に設定されています。
|
||||
ノードコントローラーは、`--node-monitor-period`に設定された秒数ごとに各ノードの状態をチェックします。
|
||||
|
||||
バージョン1.13よりも前のKubernetesにおいて、NodeStatusはノードからのハートビートでした。Kubernetes 1.13から、NodeLeaseがアルファ機能として導入されました（Feature Gate `NodeLease`, [KEP-0009](https://github.com/kubernetes/community/blob/master/keps/sig-node/0009-node-heartbeat.md)）。
|
||||
#### ハートビート
|
||||
ハートビートは、Kubernetesノードから送信され、ノードが利用可能か判断するのに役立ちます。
|
||||
２つのハートビートがあります：`NodeStatus`の更新と[Lease object](/docs/reference/generated/kubernetes-api/{{< latest-version >}}#lease-v1-coordination-k8s-io)です。
|
||||
各ノードは`kube-node-lease`という{{< glossary_tooltip term_id="namespace" text="namespace">}}に関連したLeaseオブジェクトを持ちます。
|
||||
Leaseは軽量なリソースで、クラスターのスケールに応じてノードのハートビートにおけるパフォーマンスを改善します。
|
||||
|
||||
kubeletが`NodeStatus`とLeaseオブジェクトの作成および更新を担当します。
|
||||
|
||||
- kubeletは、ステータスに変化があったり、設定した間隔の間に更新がない時に`NodeStatus`を更新します。`NodeStatus`更新のデフォルト間隔は５分です。（到達不能の場合のデフォルトタイムアウトである40秒よりもはるかに長いです）
|
||||
- kubeletは10秒間隔(デフォルトの更新間隔)でLeaseオブジェクトの生成と更新を実施します。Leaseの更新は`NodeStatus`の更新とは独立されて行われます。Leaseの更新が失敗した場合、kubeletは200ミリ秒から始まり7秒を上限とした指数バックオフでリトライします。
|
||||
|
||||
#### 信頼性
|
||||
|
||||
NodeLeaseが有効になっている場合、各ノードは `kube-node-lease`というNamespaceに関連付けられた`Lease`オブジェクトを持ち、ノードによって定期的に更新されます。NodeStatusとNodeLeaseの両方がノードからのハートビートとして扱われます。NodeLeaseは頻繁に更新されますが、NodeStatusはノードからマスターへの変更があるか、または十分な時間が経過した場合にのみ報告されます（デフォルトは1分で、到達不能の場合のデフォルトタイムアウトである40秒よりも長いです）。NodeLeaseはNodeStatusよりもはるかに軽量であるため、スケーラビリティとパフォーマンスの両方の観点においてノードのハートビートのコストを下げます。
|
||||
|
||||
Kubernetes 1.4では、マスターに問題が発生した場合の対処方法を改善するように、ノードコントローラーのロジックをアップデートしています（マスターのネットワークに問題があるため）
|
||||
バージョン1.4以降、ノードコントローラーは、Podの退役について決定する際に、クラスター内のすべてのノードの状態を調べます。
|
||||
|
|
@ -201,6 +202,11 @@ DaemonSetコントローラーによって作成されたPodはKubernetesスケ
|
|||
これは、再起動の準備中にアプリケーションからアプリケーションが削除されている場合でも、デーモンがマシンに属していることを前提としているためです。
|
||||
{{< /note >}}
|
||||
|
||||
{{< caution >}}
|
||||
`kubectl cordon`はノードに'unschedulable'としてマークします。それはロードバランサーのターゲットリストからノードを削除するという
|
||||
サービスコントローラーの副次的な効果をもたらします。これにより、ロードバランサトラフィックの流入をcordonされたノードから効率的に除去する事ができます。
|
||||
{{< /caution >}}
|
||||
|
||||
### ノードのキャパシティ
|
||||
|
||||
ノードのキャパシティ（CPUの数とメモリの量）はNodeオブジェクトの一部です。
|
||||
|
|
@ -213,6 +219,11 @@ Kubernetesスケジューラーは、ノード上のすべてのPodに十分な
|
|||
|
||||
Pod以外のプロセス用にリソースを明示的に予約したい場合は、このチュートリアルに従って[Systemデーモン用にリソースを予約](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved)してください。
|
||||
|
||||
## ノードのトポロジー
|
||||
|
||||
{{< feature-state state="alpha" >}}
|
||||
`TopologyManager`の[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にすると、
|
||||
kubeletはリソースの割当を決定する際にトポロジーのヒントを利用できます。
|
||||
|
||||
## APIオブジェクト
|
||||
|
||||
|
|
@ -220,3 +231,7 @@ NodeはKubernetesのREST APIにおけるトップレベルのリソースです
|
|||
[Node APIオブジェクト](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core).
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [ノードコンポーネント](/ja/docs/concepts/overview/components/#node-components)について読む。
|
||||
* ノードレベルのトポロジーについて読む: [ノードのトポロジー管理ポリシーを制御する](/docs/tasks/administer-cluster/topology-manager/)
|
||||
|
|
|
|||
|
|
@ -16,13 +16,13 @@ Kubernetesクラスターの計画、セットアップ、設定の例を知る
|
|||
|
||||
ガイドを選択する前に、いくつかの考慮事項を挙げます。
|
||||
|
||||
- ユーザーのコンピューター上でKubernetesを試したいでしょうか、それとも高可用性のあるマルチノードクラスターを構築したいでしょうか? あなたのニーズにあったディストリビューションを選択してください。
|
||||
- ユーザーのコンピューター上でKubernetesを試したいでしょうか、それとも高可用性のあるマルチノードクラスターを構築したいでしょうか？あなたのニーズにあったディストリビューションを選択してください。
|
||||
- **もしあなたが高可用性を求める場合**、 [複数ゾーンにまたがるクラスター](/docs/concepts/cluster-administration/federation/)の設定について学んでください。
|
||||
- [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/)のような**ホストされているKubernetesクラスター**を使用するのか、それとも**自分自身でクラスターをホストするのでしょうか**?
|
||||
- 使用するクラスターは**オンプレミス**なのか、それとも**クラウド (IaaS)**でしょうか? Kubernetesはハイブリッドクラスターを直接サポートしていません。その代わりユーザーは複数のクラスターをセットアップできます。
|
||||
- Kubernetesを**"ベアメタル"なハードウェア** 上で稼働させますか? それとも**仮想マシン (VMs)** 上で稼働させますか?
|
||||
- [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/)のような**ホストされているKubernetesクラスター**を使用するのか、それとも**自分自身でクラスターをホストするのでしょうか**？
|
||||
- 使用するクラスターは**オンプレミス**なのか、それとも**クラウド(IaaS)** でしょうか？Kubernetesはハイブリッドクラスターを直接サポートしていません。その代わりユーザーは複数のクラスターをセットアップできます。
|
||||
- Kubernetesを **「ベアメタル」なハードウェア**上で稼働させますか？それとも**仮想マシン(VMs)** 上で稼働させますか？
|
||||
- **もしオンプレミスでKubernetesを構築する場合**、どの[ネットワークモデル](/ja/docs/concepts/cluster-administration/networking/)が最適か検討してください。
|
||||
- **ただクラスターを稼働させたいだけ**でしょうか、それとも**Kubernetesプロジェクトのコードの開発**を行いたいでしょうか? もし後者の場合、開発が進行中のディストリビューションを選択してください。いくつかのディストリビューションはバイナリリリースのみ使用していますが、多くの選択肢があります。
|
||||
- **ただクラスターを稼働させたいだけ**でしょうか、それとも**Kubernetesプロジェクトのコードの開発**を行いたいでしょうか？もし後者の場合、開発が進行中のディストリビューションを選択してください。いくつかのディストリビューションはバイナリリリースのみ使用していますが、多くの選択肢があります。
|
||||
- クラスターを稼働させるのに必要な[コンポーネント](/ja/docs/concepts/overview/components/)についてよく理解してください。
|
||||
|
||||
注意: 全てのディストリビューションがアクティブにメンテナンスされている訳ではありません。最新バージョンのKubernetesでテストされたディストリビューションを選択してください。
|
||||
|
|
|
|||
|
|
@ -1,42 +0,0 @@
|
|||
---
|
||||
title: コントローラーマネージャーの指標
|
||||
content_type: concept
|
||||
weight: 100
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
コントローラーマネージャーの指標は、コントローラー内部のパフォーマンスについての重要で正確な情報と、クラウドコントローラーの状態についての情報を提供します。
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
## コントローラーマネージャーの指標とは何か
|
||||
|
||||
コントローラーマネージャーの指標は、コントローラー内部のパフォーマンスについての重要で正確な情報と、クラウドコントローラーの状態についての情報を提供します。
|
||||
これらの指標にはgo_routineのカウントなどの一般的なGo言語ランタイムの指標と、etcdのリクエストレイテンシまたはCloudprovider（AWS、GCE、OpenStack）APIのレイテンシといったコントローラー固有の指標が含まれていて、クラスターの状態を測定するために利用できます。
|
||||
|
||||
Kubernetes 1.7からGCE、AWS、Vsphere、OpenStackのストレージ操作の詳細なCloudproviderの指標が利用可能になりました。
|
||||
これらの指標は永続的ボリュームの操作状況を監視するために利用できます。
|
||||
|
||||
たとえば、GCEの場合にはこれらの指標は次のように呼び出されます。
|
||||
|
||||
```
|
||||
cloudprovider_gce_api_request_duration_seconds { request = "instance_list"}
|
||||
cloudprovider_gce_api_request_duration_seconds { request = "disk_insert"}
|
||||
cloudprovider_gce_api_request_duration_seconds { request = "disk_delete"}
|
||||
cloudprovider_gce_api_request_duration_seconds { request = "attach_disk"}
|
||||
cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"}
|
||||
cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
|
||||
```
|
||||
|
||||
|
||||
|
||||
## 設定
|
||||
|
||||
クラスターではコントローラーマネージャーの指標はコントローラーマネージャーが実行されているホストの`http://localhost:10252/metrics`から取得可能です。
|
||||
|
||||
この指標は[prometheusフォーマット](https://prometheus.io/docs/instrumenting/exposition_formats/)で出力され人間が読める形式になっています。
|
||||
|
||||
本番環境ではこれらの指標を定期的に収集し、なんらかの時系列データベースで使用できるようにprometheusやその他の指標のスクレイパーを構成することが推奨されます。
|
||||
|
||||
|
||||
|
|
@ -81,7 +81,7 @@ Details on how the AOS system works can be accessed here: http://www.apstra.com/
|
|||
|
||||
[AWS VPC CNI](https://github.com/aws/amazon-vpc-cni-k8s)は、Kubernetesクラスター向けの統合されたAWS Virtual Private Cloud(VPC)ネットワーキングを提供します。このCNIプラグインは、高いスループットと可用性、低遅延、および最小のネットワークジッタを提供します。さらに、ユーザーは、Kubernetesクラスターを構築するための既存のAWS VPCネットワーキングとセキュリティのベストプラクティスを適用できます。これには、ネットワークトラフィックの分離にVPCフローログ、VPCルーティングポリシー、およびセキュリティグループを使用する機能が含まれます。
|
||||
|
||||
このCNIプラグインを使用すると、Kubernetes PodはVPCネットワーク上と同じIPアドレスをPod内に持つことができます。CNIはAWS Elastic Networking Interfaces（ENI）を各Kubernetesノードに割り当て、ノード上のPodに各ENIのセカンダリIP範囲を使用します。このCNIには、Podの起動時間を短縮するためのENIとIPアドレスの事前割り当ての制御が含まれており、最大2,000ノードの大規模クラスターが可能です。
|
||||
このCNIプラグインを使用すると、Kubernetes PodはVPCネットワーク上と同じIPアドレスをPod内に持つことができます。CNIはAWS Elastic Networking Interface(ENI)を各Kubernetesノードに割り当て、ノード上のPodに各ENIのセカンダリIP範囲を使用します。このCNIには、Podの起動時間を短縮するためのENIとIPアドレスの事前割り当ての制御が含まれており、最大2,000ノードの大規模クラスターが可能です。
|
||||
|
||||
さらに、このCNIは[ネットワークポリシーの適用のためにCalico](https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/calico.html)と一緒に実行できます。AWS VPC CNIプロジェクトは、[GitHubのドキュメント](https://github.com/aws/amazon-vpc-cni-k8s)とともにオープンソースで公開されています。
|
||||
|
||||
|
|
@ -89,7 +89,7 @@ Details on how the AOS system works can be accessed here: http://www.apstra.com/
|
|||
[Azure CNI](https://docs.microsoft.com/en-us/azure/virtual-network/container-networking-overview) is an [open source](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md) plugin that integrates Kubernetes Pods with an Azure Virtual Network (also known as VNet) providing network performance at par with VMs. Pods can connect to peered VNet and to on-premises over Express Route or site-to-site VPN and are also directly reachable from these networks. Pods can access Azure services, such as storage and SQL, that are protected by Service Endpoints or Private Link. You can use VNet security policies and routing to filter Pod traffic. The plugin assigns VNet IPs to Pods by utilizing a pool of secondary IPs pre-configured on the Network Interface of a Kubernetes node.
|
||||
|
||||
Azure CNI is available natively in the [Azure Kubernetes Service (AKS)] (https://docs.microsoft.com/en-us/azure/aks/configure-azure-cni).
|
||||
|
||||
|
||||
|
||||
### Big Cloud Fabric from Big Switch Networks
|
||||
|
||||
|
|
@ -289,4 +289,3 @@ to run, and in both cases, the network provides one IP address per pod - as is s
|
|||
|
||||
ネットワークモデルの初期設計とその根拠、および将来の計画については、[ネットワーク設計ドキュメント](https://git.k8s.io/community/contributors/design-proposals/network/networking.md)で詳細に説明されています。
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ weight: 30
|
|||
|
||||
<!-- overview -->
|
||||
|
||||
[Pod](/ja/docs/concepts/workloads/pods/pod/)が稼働する[Node](/ja/docs/concepts/architecture/nodes/)を特定のものに指定したり、優先条件を指定して制限することができます。
|
||||
{{< glossary_tooltip text="Pod" term_id="pod" >}}が稼働する{{< glossary_tooltip text="Node" term_id="node" >}}を特定のものに指定したり、優先条件を指定して制限することができます。
|
||||
これを実現するためにはいくつかの方法がありますが、推奨されている方法は[ラベルでの選択](/ja/docs/concepts/overview/working-with-objects/labels/)です。
|
||||
スケジューラーが最適な配置を選択するため、一般的にはこのような制限は不要です(例えば、複数のPodを別々のNodeへデプロイしたり、Podを配置する際にリソースが不十分なNodeにはデプロイされないことが挙げられます)が、
|
||||
SSDが搭載されているNodeにPodをデプロイしたり、同じアベイラビリティーゾーン内で通信する異なるサービスのPodを同じNodeにデプロイする等、柔軟な制御が必要なこともあります。
|
||||
|
|
@ -27,7 +27,7 @@ SSDが搭載されているNodeにPodをデプロイしたり、同じアベイ
|
|||
|
||||
### ステップ0: 前提条件
|
||||
|
||||
この例では、KubernetesのPodに関して基本的な知識を有していることと、[Kubernetesクラスターのセットアップ](https://github.com/kubernetes/kubernetes#documentation)がされていることが前提となっています。
|
||||
この例では、KubernetesのPodに関して基本的な知識を有していることと、[Kubernetesクラスターのセットアップ](/ja/docs/setup/)がされていることが前提となっています。
|
||||
|
||||
### ステップ1: Nodeへのラベルの付与
|
||||
|
||||
|
|
@ -63,17 +63,20 @@ nodeSelectorを以下のように追加します:
|
|||
`kubectl apply -f https://k8s.io/examples/pods/pod-nginx.yaml`により、Podは先ほどラベルを付与したNodeへスケジュールされます。
|
||||
`kubectl get pods -o wide`で表示される"NODE"の列から、PodがデプロイされているNodeを確認することができます。
|
||||
|
||||
## 補足: ビルトインNodeラベル
|
||||
## 補足: ビルトインNodeラベル {#built-in-node-labels}
|
||||
|
||||
明示的に[付与](#step-one-attach-label-to-the-node)するラベルの他に、事前にNodeへ付与されているものもあります。
|
||||
以下のようなラベルが該当します。
|
||||
|
||||
* `kubernetes.io/hostname`
|
||||
* `failure-domain.beta.kubernetes.io/zone`
|
||||
* `failure-domain.beta.kubernetes.io/region`
|
||||
* `beta.kubernetes.io/instance-type`
|
||||
* `kubernetes.io/os`
|
||||
* `kubernetes.io/arch`
|
||||
* [`kubernetes.io/hostname`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-hostname)
|
||||
* [`failure-domain.beta.kubernetes.io/zone`](/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domainbetakubernetesiozone)
|
||||
* [`failure-domain.beta.kubernetes.io/region`](/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domainbetakubernetesioregion)
|
||||
* [`topology.kubernetes.io/zone`](/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone)
|
||||
* [`topology.kubernetes.io/region`](/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone)
|
||||
* [`beta.kubernetes.io/instance-type`](/docs/reference/kubernetes-api/labels-annotations-taints/#beta-kubernetes-io-instance-type)
|
||||
* [`node.kubernetes.io/instance-type`](/docs/reference/kubernetes-api/labels-annotations-taints/#nodekubernetesioinstance-type)
|
||||
* [`kubernetes.io/os`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-os)
|
||||
* [`kubernetes.io/arch`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-arch)
|
||||
|
||||
{{< note >}}
|
||||
これらのラベルは、クラウドプロバイダー固有であり、確実なものではありません。
|
||||
|
|
@ -88,131 +91,127 @@ Nodeにラベルを付与することで、Podは特定のNodeやNodeグルー
|
|||
これは、安全性が損なわれたNodeがkubeletの認証情報をNodeのオブジェクトに設定したり、スケジューラーがそのようなNodeにデプロイすることを防ぎます。
|
||||
|
||||
`NodeRestriction`プラグインは、kubeletが`node-restriction.kubernetes.io/`プレフィックスを有するラベルの設定や上書きを防ぎます。
|
||||
Nodeの隔離にラベルのプレフィックスを使用するためには、以下の３点を確認してください。
|
||||
Nodeの隔離にラベルのプレフィックスを使用するためには、以下のようにします。
|
||||
|
||||
1. NodeRestrictionを使用するため、Kubernetesのバージョンがv1.11以上であること。
|
||||
2. [Node authorizer](/docs/reference/access-authn-authz/node/)を使用していることと、[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)が有効になっていること。
|
||||
3. Nodeに`node-restriction.kubernetes.io/` プレフィックスのラベルを付与し、そのラベルがnode selectorに指定されていること。
|
||||
1. [Node authorizer](/docs/reference/access-authn-authz/node/)を使用していることと、[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)が_有効_になっていること。
|
||||
2. Nodeに`node-restriction.kubernetes.io/` プレフィックスのラベルを付与し、そのラベルがnode selectorに指定されていること。
|
||||
例えば、`example.com.node-restriction.kubernetes.io/fips=true` または `example.com.node-restriction.kubernetes.io/pci-dss=true`のようなラベルです。
|
||||
|
||||
## Affinity と Anti-Affinity {#affinity-and-anti-affinity}
|
||||
## アフィニティとアンチアフィニティ {#affinity-and-anti-affinity}
|
||||
|
||||
`nodeSelector`はPodの稼働を特定のラベルが付与されたNodeに制限する最も簡単な方法です。
|
||||
Affinity/Anti-Affinityでは、より柔軟な指定方法が提供されています。
|
||||
アフィニティ/アンチアフィニティでは、より柔軟な指定方法が提供されています。
|
||||
拡張機能は以下の通りです。
|
||||
|
||||
1. 様々な指定方法がある ("AND条件"に限らない)
|
||||
2. 必須条件ではなく優先条件を指定でき、条件を満たさない場合でもPodをスケジュールさせることができる
|
||||
3. Node自体のラベルではなく、Node(または他のトポロジカルドメイン)上で稼働している他のPodのラベルに対して条件を指定することができ、そのPodと同じ、または異なるドメインで稼働させることができる
|
||||
1. アフィニティ/アンチアフィニティという用語はとても表現豊かです。この用語は論理AND演算で作成された完全一致だけではなく、より多くのマッチングルールを提供します。
|
||||
2. 必須条件ではなく優先条件を指定でき、条件を満たさない場合でもPodをスケジュールさせることができます。
|
||||
3. Node自体のラベルではなく、Node(または他のトポロジカルドメイン)上で稼働している他のPodのラベルに対して条件を指定することができ、そのPodと同じ、または異なるドメインで稼働させることができます。
|
||||
|
||||
Affinityは"Node Affinity"と"Inter-Pod Affinity/Anti-Affinity"の2種類から成ります。
|
||||
Node affinityは`nodeSelector`(前述の2つのメリットがあります)に似ていますが、Inter-Pod Affinity/Anti-Affinityは、上記の3番目の機能に記載している通り、NodeのラベルではなくPodのラベルに対して制限をかけます。
|
||||
アフィニティは"Nodeアフィニティ"と"Pod間アフィニティ/アンチアフィニティ"の2種類から成ります。
|
||||
Nodeアフィニティは`nodeSelector`(前述の2つのメリットがあります)に似ていますが、Pod間アフィニティ/アンチアフィニティは、上記の3番目の機能に記載している通り、NodeのラベルではなくPodのラベルに対して制限をかけます。
|
||||
|
||||
`nodeSelector`は問題なく使用することができますが、Node affinityは`nodeSelector`で指定できる条件を全て実現できるため、将来的には推奨されなくなります。
|
||||
### Nodeアフィニティ
|
||||
|
||||
### Node Affinity
|
||||
Nodeアフィニティは概念的には、NodeのラベルによってPodがどのNodeにスケジュールされるかを制限する`nodeSelector`と同様です。
|
||||
|
||||
Node Affinityはα機能としてKubernetesのv1.2から導入されました。
|
||||
Node Affinityは概念的には、NodeのラベルによってPodがどのNodeにスケジュールされるかを制限する`nodeSelector`と同様です。
|
||||
|
||||
現在は2種類のNode Affinityがあり、`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`です。
|
||||
現在は2種類のNodeアフィニティがあり、`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`です。
|
||||
前者はNodeにスケジュールされるPodが条件を満たすことが必須(`nodeSelector`に似ていますが、より柔軟に条件を指定できます)であり、後者は条件を指定できますが保証されるわけではなく、優先的に考慮されます。
|
||||
"IgnoredDuringExecution"の意味するところは、`nodeSelector`の機能と同様であり、Nodeのラベルが変更され、Podがその条件を満たさなくなった場合でも
|
||||
PodはそのNodeで稼働し続けるということです。
|
||||
将来的には、`requiredDuringSchedulingIgnoredDuringExecution`に、PodのNode Affinityに記された必須要件を満たさなくなったNodeからそのPodを退避させることができる機能を備えた`requiredDuringSchedulingRequiredDuringExecution`が提供される予定です。
|
||||
将来的には、`requiredDuringSchedulingIgnoredDuringExecution`に、PodのNodeアフィニティに記された必須要件を満たさなくなったNodeからそのPodを退避させることができる機能を備えた`requiredDuringSchedulingRequiredDuringExecution`が提供される予定です。
|
||||
|
||||
それぞれの使用例として、
|
||||
`requiredDuringSchedulingIgnoredDuringExecution` は、"インテルCPUを供えたNode上でPodを稼働させる"、
|
||||
`preferredDuringSchedulingIgnoredDuringExecution`は、"ゾーンXYZでPodの稼働を試みますが、実現不可能な場合には他の場所で稼働させる"
|
||||
といった方法が挙げられます。
|
||||
|
||||
Node Affinityは、PodSpecの`affinity`フィールドにある`nodeAffinity`フィールドで特定します。
|
||||
Nodeアフィニティは、PodSpecの`affinity`フィールドにある`nodeAffinity`フィールドで特定します。
|
||||
|
||||
Node Affinityを使用したPodの例を以下に示します:
|
||||
Nodeアフィニティを使用したPodの例を以下に示します:
|
||||
|
||||
{{< codenew file="pods/pod-with-node-affinity.yaml" >}}
|
||||
|
||||
このNode Affinityでは、Podはキーが`kubernetes.io/e2e-az-name`、値が`e2e-az1`または`e2e-az2`のラベルが付与されたNodeにしか配置されません。
|
||||
このNodeアフィニティでは、Podはキーが`kubernetes.io/e2e-az-name`、値が`e2e-az1`または`e2e-az2`のラベルが付与されたNodeにしか配置されません。
|
||||
加えて、キーが`another-node-label-key`、値が`another-node-label-value`のラベルが付与されたNodeが優先されます。
|
||||
|
||||
この例ではオペレーター`In`が使われています。
|
||||
Node Affinityでは、`In`、`NotIn`、`Exists`、`DoesNotExist`、`Gt`、`Lt`のオペレーターが使用できます。
|
||||
`NotIn`と`DoesNotExist`はNode Anti-Affinity、またはPodを特定のNodeにスケジュールさせない場合に使われる[Taints](/docs/concepts/configuration/taint-and-toleration/)に使用します。
|
||||
Nodeアフィニティでは、`In`、`NotIn`、`Exists`、`DoesNotExist`、`Gt`、`Lt`のオペレーターが使用できます。
|
||||
`NotIn`と`DoesNotExist`はNodeアンチアフィニティ、またはPodを特定のNodeにスケジュールさせない場合に使われる[Taints](/docs/concepts/configuration/taint-and-toleration/)に使用します。
|
||||
|
||||
`nodeSelector`と`nodeAffinity`の両方を指定した場合、Podは**両方の**条件を満たすNodeにスケジュールされます。
|
||||
|
||||
`nodeAffinity`内で複数の`nodeSelectorTerms`を指定した場合、Podは**いずれかの**`nodeSelectorTerms`を満たしたNodeへスケジュールされます。
|
||||
`nodeAffinity`内で複数の`nodeSelectorTerms`を指定した場合、Podは**全ての**`nodeSelectorTerms`を満たしたNodeへスケジュールされます。
|
||||
|
||||
`nodeSelectorTerms`内で複数の`matchExpressions`を指定した場合にはPodは**全ての**`matchExpressions`を満たしたNodeへスケジュールされます。
|
||||
`nodeSelectorTerms`内で複数の`matchExpressions`を指定した場合にはPodは**いずれかの**`matchExpressions`を満たしたNodeへスケジュールされます。
|
||||
|
||||
PodがスケジュールされたNodeのラベルを削除したり変更しても、Podは削除されません。
|
||||
言い換えると、AffinityはPodをスケジュールする際にのみ考慮されます。
|
||||
言い換えると、アフィニティはPodをスケジュールする際にのみ考慮されます。
|
||||
|
||||
`preferredDuringSchedulingIgnoredDuringExecution`内の`weight`フィールドは、1から100の範囲で指定します。
|
||||
全ての必要条件(リソースやRequiredDuringScheduling Affinity等)を満たしたNodeに対して、スケジューラーはそのNodeがMatchExpressionsを満たした場合に、このフィルードの"weight"を加算して合計を計算します。
|
||||
全ての必要条件(リソースやRequiredDuringSchedulingアフィニティ等)を満たしたNodeに対して、スケジューラーはそのNodeがMatchExpressionsを満たした場合に、このフィルードの"weight"を加算して合計を計算します。
|
||||
このスコアがNodeの他の優先機能のスコアと組み合わせれ、最も高いスコアを有したNodeが優先されます。
|
||||
|
||||
### Inter-Pod Affinity/Anti-Affinity
|
||||
### Pod間アフィニティとアンチアフィニティ
|
||||
|
||||
Inter-Pod AffinityとAnti-Affinityは、Nodeのラベルではなく、すでにNodeで稼働しているPodのラベルに従ってPodがスケジュールされるNodeを制限します。
|
||||
このポリシーは、"XにてルールYを満たすPodがすでに稼働している場合、このPodもXで稼働させる(Anti-Affinityの場合は稼働させない)"という形式です。
|
||||
Pod間アフィニティとアンチアフィニティは、Nodeのラベルではなく、すでにNodeで稼働しているPodのラベルに従ってPodがスケジュールされるNodeを制限します。
|
||||
このポリシーは、"XにてルールYを満たすPodがすでに稼働している場合、このPodもXで稼働させる(アンチアフィニティの場合は稼働させない)"という形式です。
|
||||
Yはnamespaceのリストで指定したLabelSelectorで表されます。
|
||||
Nodeと異なり、Podはnamespaceで区切られているため(それゆえPodのラベルも暗黙的にnamespaceで区切られます)、Podのラベルを指定するlabel selectorは、どのnamespaceにselectorを適用するかを指定する必要があります。
|
||||
概念的に、XはNodeや、ラック、クラウドプロバイダゾーン、クラウドプロバイダのリージョン等を表すトポロジードメインです。
|
||||
これらを表すためにシステムが使用するNode Labelのキーである`topologyKey`を使うことで、トポロジードメインを指定することができます。
|
||||
これらを表すためにシステムが使用するNodeラベルのキーである`topologyKey`を使うことで、トポロジードメインを指定することができます。
|
||||
先述のセクション[補足: ビルトインNodeラベル](#interlude-built-in-node-labels)にてラベルの例が紹介されています。
|
||||
|
||||
|
||||
{{< note >}}
|
||||
Inter-Pod AffinityとAnti-Affinityは、大規模なクラスター上で使用する際にスケジューリングを非常に遅くする恐れのある多くの処理を要します。
|
||||
Pod間アフィニティとアンチアフィニティは、大規模なクラスター上で使用する際にスケジューリングを非常に遅くする恐れのある多くの処理を要します。
|
||||
そのため、数百台以上のNodeから成るクラスターでは使用することを推奨されません。
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
Pod Anti-Affinityは、Nodeに必ずラベルが付与されている必要があります。
|
||||
例えば、クラスターの全てのNodeが、`topologyKey`で指定されたものに合致する適切なラベルが必要になります。
|
||||
Podのアンチアフィニティは、Nodeに必ずラベルが付与されている必要があります。
|
||||
言い換えると、クラスターの全てのNodeが、`topologyKey`で指定されたものに合致する適切なラベルが必要になります。
|
||||
それらが付与されていないNodeが存在する場合、意図しない挙動を示すことがあります。
|
||||
{{< /note >}}
|
||||
|
||||
Node Affinityと同様に、Pod AffinityとPod Anti-Affinityにも必須条件と優先条件を示す`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`があります。
|
||||
前述のNode Affinityのセクションを参照してください。
|
||||
`requiredDuringSchedulingIgnoredDuringExecution`を指定するAffinityの使用例は、"Service AのPodとService BのPodが密に通信する際、それらを同じゾーンで稼働させる場合"です。
|
||||
また、`preferredDuringSchedulingIgnoredDuringExecution`を指定するAnti-Affinityの使用例は、"ゾーンをまたいでPodのサービスを稼働させる場合"(Podの数はゾーンの数よりも多いため、必須条件を指定すると合理的ではありません)です。
|
||||
Nodeアフィニティと同様に、PodアフィニティとPodアンチアフィニティにも必須条件と優先条件を示す`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`があります。
|
||||
前述のNodeアフィニティのセクションを参照してください。
|
||||
`requiredDuringSchedulingIgnoredDuringExecution`を指定するアフィニティの使用例は、"Service AのPodとService BのPodが密に通信する際、それらを同じゾーンで稼働させる場合"です。
|
||||
また、`preferredDuringSchedulingIgnoredDuringExecution`を指定するアンチアフィニティの使用例は、"ゾーンをまたいでPodのサービスを稼働させる場合"(Podの数はゾーンの数よりも多いため、必須条件を指定すると合理的ではありません)です。
|
||||
|
||||
Inter-Pod Affinityは、PodSpecの`affinity`フィールド内に`podAffinity`で指定し、Inter-Pod Anti-Affinityは、`podAntiAffinity`で指定します。
|
||||
Pod間アフィニティは、PodSpecの`affinity`フィールド内に`podAffinity`で指定し、Pod間アンチアフィニティは、`podAntiAffinity`で指定します。
|
||||
|
||||
#### Pod Affinityを使用したPodの例
|
||||
#### Podアフィニティを使用したPodの例
|
||||
|
||||
{{< codenew file="pods/pod-with-pod-affinity.yaml" >}}
|
||||
|
||||
このPodのAffifnityは、Pod AffinityとPod Anti-Affinityを1つずつ定義しています。
|
||||
このPodのアフィニティは、PodアフィニティとPodアンチアフィニティを1つずつ定義しています。
|
||||
この例では、`podAffinity`に`requiredDuringSchedulingIgnoredDuringExecution`、`podAntiAffinity`に`preferredDuringSchedulingIgnoredDuringExecution`が設定されています。
|
||||
Pod Affinityは、「キーが"security"、値が"S1"のラベルが付与されたPodが少なくとも1つは稼働しているNodeが同じゾーンにあれば、PodはそのNodeにスケジュールされる」という条件を指定しています(より正確には、キーが"security"、値が"S1"のラベルが付与されたPodが稼働しており、キーが`failure-domain.beta.kubernetes.io/zone`、値がVであるNodeが少なくとも1つはある状態で、
|
||||
Podアフィニティは、「キーが"security"、値が"S1"のラベルが付与されたPodが少なくとも1つは稼働しているNodeが同じゾーンにあれば、PodはそのNodeにスケジュールされる」という条件を指定しています(より正確には、キーが"security"、値が"S1"のラベルが付与されたPodが稼働しており、キーが`failure-domain.beta.kubernetes.io/zone`、値がVであるNodeが少なくとも1つはある状態で、
|
||||
Node Nがキー`failure-domain.beta.kubernetes.io/zone`、値Vのラベルを持つ場合に、PodはNode Nで稼働させることができます)。
|
||||
Pod Anti-Affinityは、「すでにあるNode上で、キーが"security"、値が"S2"であるPodが稼働している場合に、Podを可能な限りそのNode上で稼働させない」という条件を指定しています
|
||||
Podアンチアフィニティは、「すでにあるNode上で、キーが"security"、値が"S2"であるPodが稼働している場合に、Podを可能な限りそのNode上で稼働させない」という条件を指定しています
|
||||
(`topologyKey`が`failure-domain.beta.kubernetes.io/zone`であった場合、キーが"security"、値が"S2"であるであるPodが稼働しているゾーンと同じゾーン内のNodeにはスケジュールされなくなります)。
|
||||
Pod AffinityとPod Anti-Affinityや、`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`に関する他の使用例は[デザインドック](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)を参照してください。
|
||||
PodアフィニティとPodアンチアフィニティや、`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`に関する他の使用例は[デザインドック](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)を参照してください。
|
||||
|
||||
Pod AffinityとPod Anti-Affinityで使用できるオペレーターは、`In`、`NotIn`、 `Exists`、 `DoesNotExist`です。
|
||||
PodアフィニティとPodアンチアフィニティで使用できるオペレーターは、`In`、`NotIn`、 `Exists`、 `DoesNotExist`です。
|
||||
|
||||
原則として、`topologyKey`には任意のラベルとキーが使用できます。
|
||||
しかし、パフォーマンスやセキュリティの観点から、以下の制約があります:
|
||||
|
||||
1. Affinityと、`requiredDuringSchedulingIgnoredDuringExecution`を指定したPod Anti-Affinityでは、`topologyKey`を指定しないことは許可されていません。
|
||||
2. `requiredDuringSchedulingIgnoredDuringExecution`を指定したPod Anti-Affinityでは、`kubernetes.io/hostname`の`topologyKey`を制限するため、アドミッションコントローラー`LimitPodHardAntiAffinityTopology`が導入されました。
|
||||
1. アフィニティと、`requiredDuringSchedulingIgnoredDuringExecution`を指定したPodアンチアフィニティは、`topologyKey`を指定しないことは許可されていません。
|
||||
2. `requiredDuringSchedulingIgnoredDuringExecution`を指定したPodアンチアフィニティでは、`kubernetes.io/hostname`の`topologyKey`を制限するため、アドミッションコントローラー`LimitPodHardAntiAffinityTopology`が導入されました。
|
||||
トポロジーをカスタマイズする場合には、アドミッションコントローラーを修正または無効化する必要があります。
|
||||
3. `preferredDuringSchedulingIgnoredDuringExecution`を指定したPod Anti-Affinityでは、`topologyKey`を指定しなかった場合、"全てのトポロジー"と解釈されます("全てのトポロジー"とは、ここでは`kubernetes.io/hostname`、`failure-domain.beta.kubernetes.io/zone`、`failure-domain.beta.kubernetes.io/region`を合わせたものを意味します)。
|
||||
3. `preferredDuringSchedulingIgnoredDuringExecution`を指定したPodアンチアフィニティでは、`topologyKey`を省略することはできません。
|
||||
4. 上記の場合を除き、`topologyKey` は任意のラベルとキーを指定することができあます。
|
||||
|
||||
`labelSelector`と`topologyKey`に加え、`labelSelector`が合致すべき`namespaces`のリストを特定することも可能です(これは`labelSelector`と`topologyKey`を定義することと同等です)。
|
||||
省略した場合や空の場合は、AffinityとAnti-Affinityが定義されたPodのnamespaceがデフォルトで設定されます。
|
||||
省略した場合や空の場合は、アフィニティとアンチアフィニティが定義されたPodのnamespaceがデフォルトで設定されます。
|
||||
|
||||
`requiredDuringSchedulingIgnoredDuringExecution`が指定されたAffinityとAnti-Affinityでは、`matchExpressions`に記載された全ての条件が満たされるNodeにPodがスケジュールされます。
|
||||
`requiredDuringSchedulingIgnoredDuringExecution`が指定されたアフィニティとアンチアフィニティでは、`matchExpressions`に記載された全ての条件が満たされるNodeにPodがスケジュールされます。
|
||||
|
||||
|
||||
#### 実際的なユースケース
|
||||
|
||||
Inter-Pod AffinityとAnti-Affinityは、ReplicaSet、StatefulSet、Deploymentなどのより高レベルなコレクションと併せて使用すると更に有用です。
|
||||
Pod間アフィニティとアンチアフィニティは、ReplicaSet、StatefulSet、Deploymentなどのより高レベルなコレクションと併せて使用するとさらに有用です。
|
||||
Workloadが、Node等の定義された同じトポロジーに共存させるよう、簡単に設定できます。
|
||||
|
||||
|
||||
|
|
@ -325,7 +324,7 @@ web-server-1287567482-s330j 1/1 Running 0 7m 10.192.3
|
|||
##### 同じNodeに共存させない場合
|
||||
|
||||
上記の例では `PodAntiAffinity`を`topologyKey: "kubernetes.io/hostname"`と合わせて指定することで、redisクラスター内の2つのインスタンスが同じホストにデプロイされない場合を扱いました。
|
||||
同様の方法で、Anti-Affinityを用いて高可用性を実現したStatefulSetの使用例は[ZooKeeper tutorial](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure)を参照してください。
|
||||
同様の方法で、アンチアフィニティを用いて高可用性を実現したStatefulSetの使用例は[ZooKeeper tutorial](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure)を参照してください。
|
||||
|
||||
|
||||
## nodeName
|
||||
|
|
@ -338,7 +337,7 @@ web-server-1287567482-s330j 1/1 Running 0 7m 10.192.3
|
|||
`nodeName`を使用することによる制約は以下の通りです:
|
||||
|
||||
- その名前のNodeが存在しない場合、Podは起動されす、自動的に削除される場合があります。
|
||||
- その名前のNodeにPodを稼働させるためのリソースがない場合、Podの起動は失敗し、理由はOutOfmemoryやOutOfcpuになります。
|
||||
- その名前のNodeにPodを稼働させるためのリソースがない場合、Podの起動は失敗し、理由は例えばOutOfmemoryやOutOfcpuになります。
|
||||
- クラウド上のNodeの名前は予期できず、変更される可能性があります。
|
||||
|
||||
`nodeName`を指定したPodの設定ファイルの例を示します:
|
||||
|
|
@ -364,8 +363,9 @@ spec:
|
|||
|
||||
[Taints](/docs/concepts/configuration/taint-and-toleration/)を使うことで、NodeはPodを追い出すことができます。
|
||||
|
||||
[Node Affinity](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)と
|
||||
[Inter-Pod Affinity/Anti-Affinity](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)
|
||||
には、Taintsの要点に関して様々な背景が紹介されています。
|
||||
|
||||
[Nodeアフィニティ](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)と
|
||||
[Pod間アフィニティ/アンチアフィニティ](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)
|
||||
のデザインドキュメントには、これらの機能の追加のバックグラウンドの情報が記載されています。
|
||||
|
||||
一度PodがNodeに割り当たると、kubeletはPodを起動してノード内のリソースを確保します。
|
||||
[トポロジーマネージャー](/docs/tasks/administer-cluster/topology-manager/)はNodeレベルのリソース割り当てを決定する際に関与します。
|
||||
|
|
|
|||
|
|
@ -0,0 +1,629 @@
|
|||
---
|
||||
title: コンテナのリソース管理
|
||||
content_type: concept
|
||||
weight: 40
|
||||
feature:
|
||||
title: 自動ビンパッキング
|
||||
description: >
|
||||
可用性を犠牲にすることなく、リソース要件やその他の制約に基づいてコンテナを自動的に配置します。リソース利用率の向上と、リソースの節約のために、クリティカルなワークロードとベストエフォートなワークロードを混在させます。
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
{{< glossary_tooltip term_id="pod" >}}を指定する際に、{{< glossary_tooltip text="コンテナ" term_id="container" >}}が必要とする各リソースの量をオプションで指定することができます。
|
||||
指定する最も一般的なリソースはCPUとメモリ(RAM)ですが、他にもあります。
|
||||
|
||||
Pod内のコンテナのリソース*要求*を指定すると、スケジューラはこの情報を使用して、どのNodeにPodを配置するかを決定します。コンテナに*制限*ソースを指定すると、kubeletはその制限を適用し、実行中のコンテナが設定した制限を超えてリソースを使用することができないようにします。また、kubeletは、少なくともそのシステムリソースのうち、*要求*の量を、そのコンテナが使用するために特別に確保します。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 要求と制限
|
||||
|
||||
Podが動作しているNodeに利用可能なリソースが十分にある場合、そのリソースの`要求`が指定するよりも多くのリソースをコンテナが使用することが許可されます
|
||||
ただし、コンテナはそのリソースの`制限`を超えて使用することはできません。
|
||||
|
||||
たとえば、コンテナに256MiBの`メモリー`要求を設定し、そのコンテナが8GiBのメモリーを持つNodeにスケジュールされたPod内に存在し、他のPodが存在しない場合、コンテナはより多くのRAMを使用しようとする可能性があります。
|
||||
|
||||
そのコンテナに4GiBの`メモリー`制限を設定すると、kubelet(および{{< glossary_tooltip text="コンテナランタイム" term_id="container-runtime" >}}) が制限を適用します。ランタイムは、コンテナーが設定済みのリソース制限を超えて使用するのを防ぎます。例えば、コンテナ内のプロセスが、許容量を超えるメモリを消費しようとすると、システムカーネルは、メモリ不足(OOM)エラーで、割り当てを試みたプロセスを終了します。
|
||||
|
||||
制限は、違反が検出されるとシステムが介入するように事後的に、またはコンテナーが制限を超えないようにシステムが防ぐように強制的に、実装できます。
|
||||
異なるランタイムは、同じ制限を実装するために異なる方法をとることができます。
|
||||
|
||||
## リソースタイプ
|
||||
|
||||
*CPU*と*メモリー*はいずれも*リソースタイプ*です。リソースタイプには基本単位があります。
|
||||
CPUは計算処理を表し、[Kubernetes CPUs](#meaning-of-cpu)の単位で指定されます。
|
||||
メモリはバイト単位で指定されます。
|
||||
Kubernetes v1.14以降を使用している場合は、*huge page*リソースを指定することができます。
|
||||
Huge PageはLinux固有の機能であり、Nodeのカーネルはデフォルトのページサイズよりもはるかに大きいメモリブロックを割り当てます。
|
||||
|
||||
たとえば、デフォルトのページサイズが4KiBのシステムでは、`hugepages-2Mi: 80Mi`という制限を指定できます。
|
||||
コンテナが40を超える2MiBの巨大ページ(合計80 MiB)を割り当てようとすると、その割り当ては失敗します。
|
||||
|
||||
{{< note >}}
|
||||
`hugepages-*`リソースをオーバーコミットすることはできません。
|
||||
これは`memory`や`cpu`リソースとは異なります。
|
||||
{{< /note >}}
|
||||
|
||||
CPUとメモリーは、まとめて*コンピュートリソース*または単に*リソース*と呼ばれます。
|
||||
コンピューティングリソースは、要求され、割り当てられ、消費され得る測定可能な量です。
|
||||
それらは[API resources](/docs/concepts/overview/kubernetes-api/)とは異なります。
|
||||
Podや[Services](/docs/concepts/services-networking/service/)などのAPIリソースは、Kubernetes APIサーバーを介して読み取りおよび変更できるオブジェクトです。
|
||||
|
||||
## Podとコンテナのリソース要求と制限
|
||||
|
||||
Podの各コンテナは、次の1つ以上を指定できます。
|
||||
|
||||
* `spec.containers[].resources.limits.cpu`
|
||||
* `spec.containers[].resources.limits.memory`
|
||||
* `spec.containers[].resources.limits.hugepages-<size>`
|
||||
* `spec.containers[].resources.requests.cpu`
|
||||
* `spec.containers[].resources.requests.memory`
|
||||
* `spec.containers[].resources.requests.hugepages-<size>`
|
||||
|
||||
要求と制限はそれぞれのコンテナでのみ指定できますが、このPodリソースの要求と制限の関係性について理解すると便利です。
|
||||
特定のリソースタイプの*Podリソース要求/制限*は、Pod内の各コンテナに対するそのタイプのリソース要求/制限の合計です。
|
||||
|
||||
## Kubernetesにおけるリソースの単位
|
||||
|
||||
### CPUの意味
|
||||
|
||||
CPUリソースの制限と要求は、*cpu*単位で測定されます。
|
||||
Kuberenetesにおける1つのCPUは、クラウドプロバイダーの**1 vCPU/コア**およびベアメタルのインテルプロセッサーの**1 ハイパースレッド**に相当します。
|
||||
|
||||
要求を少数で指定することもできます。
|
||||
`spec.containers[].resources.requests.cpu`が`0.5`のコンテナは、1CPUを要求するコンテナの半分のCPUが保証されます。
|
||||
`0.1`という表現は`100m`という表現と同等であり、`100ミリCPU`と読み替えることができます。
|
||||
`100ミリコア`という表現も、同じことを意味しています。
|
||||
`0.1`のような小数点のある要求はAPIによって`100m`に変換され、`1m`より細かい精度は許可されません。
|
||||
このため、`100m`の形式が推奨されます。
|
||||
|
||||
CPUは常に相対量としてではなく、絶対量として要求されます。
|
||||
0.1は、シングルコア、デュアルコア、あるいは48コアマシンのどのCPUに対してでも、同一の量を要求します。
|
||||
|
||||
### メモリーの意味
|
||||
|
||||
`メモリー`の制限と要求はバイト単位で測定されます。
|
||||
E、P、T、G、M、Kのいずれかのサフィックスを使用して、メモリーを整数または固定小数点整数として表すことができます。
|
||||
また、Ei、Pi、Ti、Gi、Mi、Kiのような2の累乗の値を使用することもできます。
|
||||
たとえば、以下はほぼ同じ値を表しています。
|
||||
|
||||
```shell
|
||||
128974848, 129e6, 129M, 123Mi
|
||||
```
|
||||
|
||||
例を見てみましょう。
|
||||
次のPodには2つのコンテナがあります。
|
||||
各コンテナには、0.25cpuおよび64MiB(2<sup>26</sup>バイト)のメモリー要求と、0.5cpuおよび128MiBのメモリー制限があります
|
||||
Podには0.5cpuと128MiBのメモリー要求があり、1cpuと256MiBのメモリ制限があると言えます。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: frontend
|
||||
spec:
|
||||
containers:
|
||||
- name: db
|
||||
image: mysql
|
||||
env:
|
||||
- name: MYSQL_ROOT_PASSWORD
|
||||
value: "password"
|
||||
resources:
|
||||
requests:
|
||||
memory: "64Mi"
|
||||
cpu: "250m"
|
||||
limits:
|
||||
memory: "128Mi"
|
||||
cpu: "500m"
|
||||
- name: wp
|
||||
image: wordpress
|
||||
resources:
|
||||
requests:
|
||||
memory: "64Mi"
|
||||
cpu: "250m"
|
||||
limits:
|
||||
memory: "128Mi"
|
||||
cpu: "500m"
|
||||
```
|
||||
|
||||
## リソース要求を含むPodがどのようにスケジュールされるか
|
||||
|
||||
Podを作成すると、KubernetesスケジューラーはPodを実行するNodeを選択します。
|
||||
各Nodeには、リソースタイプごとに最大容量があります。それは、Podに提供できるCPUとメモリの量です。
|
||||
スケジューラーは、リソースタイプごとに、スケジュールされたコンテナのリソース要求の合計がNodeの容量より少ないことを確認します。
|
||||
Node上の実際のメモリーまたはCPUリソースの使用率は非常に低いですが、容量チェックが失敗した場合、スケジューラーはNodeにPodを配置しないことに注意してください。
|
||||
これにより、例えば日々のリソース要求のピーク時など、リソース利用が増加したときに、Nodeのリソース不足から保護されます。
|
||||
|
||||
## リソース制限のあるPodがどのように実行されるか
|
||||
|
||||
kubeletがPodのコンテナを開始すると、CPUとメモリーの制限がコンテナランタイムに渡されます。
|
||||
|
||||
Dockerを使用する場合:
|
||||
|
||||
- `spec.containers[].resources.requests.cpu`は、潜在的に小数であるコア値に変換され、1024倍されます。
|
||||
`docker run`コマンドの[`--cpu-shares`](https://docs.docker.com/engine/reference/run/#cpu-share-constraint)フラグの値は、この数値と2のいずれか大きい方が用いられます。
|
||||
|
||||
- `spec.containers[].resources.limits.cpu`はミリコアの値に変換され、100倍されます。
|
||||
結果の値は、コンテナが100ミリ秒ごとに使用できるCPU時間の合計です。
|
||||
コンテナは、この間隔の間、CPU時間の占有率を超えて使用することはできません。
|
||||
|
||||
{{< note >}}
|
||||
デフォルトのクォータ期間は100ミリ秒です。
|
||||
CPUクォータの最小分解能は1ミリ秒です。
|
||||
{{</ note >}}
|
||||
|
||||
- `spec.containers[].resources.limits.memory`は整数に変換され、`docker run`コマンドの[`--memory`](https://docs.docker.com/engine/reference/run/#/user-memory-constraints)フラグの値として使用されます。
|
||||
|
||||
コンテナがメモリー制限を超過すると、終了する場合があります。
|
||||
コンテナが再起動可能である場合、kubeletは他のタイプのランタイム障害と同様にコンテナを再起動します。
|
||||
|
||||
コンテナがメモリー要求を超過すると、Nodeのメモリーが不足するたびにそのPodが排出される可能性があります。
|
||||
|
||||
コンテナは、長時間にわたってCPU制限を超えることが許可される場合と許可されない場合があります。
|
||||
ただし、CPUの使用量が多すぎるために、コンテナが強制終了されることはありません。
|
||||
|
||||
コンテナをスケジュールできないか、リソース制限が原因で強制終了されているかどうかを確認するには、[トラブルシューティング](#troubleshooting)のセクションを参照してください。
|
||||
|
||||
### コンピュートリソースとメモリーリソースの使用量を監視する
|
||||
|
||||
Podのリソース使用量は、Podのステータスの一部として報告されます。
|
||||
|
||||
オプションの[監視ツール](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)がクラスターにおいて利用可能な場合、Podのリソース使用量は[メトリクスAPI](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#the-metrics-api)から直接、もしくは監視ツールから取得できます。
|
||||
|
||||
## ローカルのエフェメラルストレージ
|
||||
|
||||
<!-- feature gate LocalStorageCapacityIsolation -->
|
||||
{{< feature-state for_k8s_version="v1.10" state="beta" >}}
|
||||
|
||||
Nodeには、ローカルに接続された書き込み可能なデバイス、または場合によってはRAMによってサポートされるローカルのエフェメラルストレージがあります。
|
||||
"エフェメラル"とは、耐久性について長期的な保証がないことを意味します。
|
||||
|
||||
Podは、スクラッチ領域、キャッシュ、ログ用にエフェメラルなローカルストレージを使用しています。
|
||||
kubeletは、ローカルのエフェメラルストレージを使用して、Podにスクラッチ領域を提供し、[`emptyDir`](https://kubernetes.io/docs/concepts/storage/volumes/#emptydir) {{< glossary_tooltip term_id="volume" text="ボリューム" >}}をコンテナにマウントできます。
|
||||
|
||||
また、kubeletはこの種類のストレージを使用して、[Nodeレベルのコンテナログ](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)、コンテナイメージ、実行中のコンテナの書き込み可能なレイヤーを保持します。
|
||||
|
||||
{{< caution >}}
|
||||
Nodeに障害が発生すると、そのエフェメラルストレージ内のデータが失われる可能性があります。
|
||||
アプリケーションは、ローカルのエフェメラルストレージにパフォーマンスのサービス品質保証(ディスクのIOPSなど)を期待することはできません。
|
||||
{{< /caution >}}
|
||||
|
||||
ベータ版の機能として、Kubernetesでは、Podが消費するローカルのエフェメラルストレージの量を追跡、予約、制限することができます。
|
||||
|
||||
### ローカルエフェメラルストレージの設定
|
||||
|
||||
Kubernetesは、Node上のローカルエフェメラルストレージを構成する2つの方法をサポートしています。
|
||||
{{< tabs name="local_storage_configurations" >}}
|
||||
{{% tab name="シングルファイルシステム" %}}
|
||||
この構成では、さまざまな種類のローカルのエフェメラルデータ(`emptyDir`ボリュームや、書き込み可能なレイヤー、コンテナイメージ、ログなど)をすべて1つのファイルシステムに配置します。
|
||||
kubeletを構成する最も効果的な方法は、このファイルシステムをKubernetes(kubelet)データ専用にすることです。
|
||||
|
||||
kubeletは[Nodeレベルのコンテナログ](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)も書き込み、これらをエフェメラルなローカルストレージと同様に扱います。
|
||||
|
||||
kubeletは、設定されたログディレクトリ(デフォルトでは`/var/log`)内のファイルにログを書き出し、ローカルに保存された他のデータのベースディレクトリ(デフォルトでは`/var/lib/kubelet`)を持ちます。
|
||||
|
||||
通常、`/var/lib/kubelet`と`/var/log`はどちらもシステムルートファイルシステムにあり、kubeletはそのレイアウトを考慮して設計されています。
|
||||
|
||||
Nodeには、Kubernetesに使用されていない他のファイルシステムを好きなだけ持つことができます。
|
||||
{{% /tab %}}
|
||||
{{% tab name="2ファイルシステム" %}}
|
||||
Node上にファイルシステムがありますが、このファイルシステムは、ログや`emptyDir`ボリュームなど、実行中のPodの一時的なデータに使用されます。
|
||||
このファイルシステムは、例えばKubernetesに関連しないシステムログなどの他のデータに使用することができ、ルートファイルシステムとすることさえ可能です。
|
||||
|
||||
また、kubeletは[ノードレベルのコンテナログ](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)を最初のファイルシステムに書き込み、これらをエフェメラルなローカルストレージと同様に扱います。
|
||||
|
||||
また、別の論理ストレージデバイスでバックアップされた別のファイルシステムを使用することもできます。
|
||||
この設定では、コンテナイメージレイヤーと書き込み可能なレイヤーを配置するようにkubeletに指示するディレクトリは、この2番目のファイルシステム上にあります。
|
||||
|
||||
最初のファイルシステムは、コンテナイメージレイヤーや書き込み可能なレイヤーを保持していません。
|
||||
|
||||
Nodeには、Kubernetesに使用されていない他のファイルシステムを好きなだけ持つことができます。
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
kubeletは、ローカルストレージの使用量を測定できます。
|
||||
これは、以下の条件で提供されます。
|
||||
|
||||
- `LocalStorageCapacityIsolation`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)が有効になっています。(デフォルトでオンになっています。)
|
||||
- そして、ローカルのエフェメラルストレージ用にサポートされている構成の1つを使用してNodeをセットアップします。
|
||||
|
||||
別の構成を使用している場合、kubeletはローカルのエフェメラルストレージにリソース制限を適用しません。
|
||||
|
||||
{{< note >}}
|
||||
kubeletは、`tmpfs`のemptyDirボリュームをローカルのエフェメラルストレージとしてではなく、コンテナメモリーとして追跡します。
|
||||
{{< /note >}}
|
||||
|
||||
### ローカルのエフェメラルストレージの要求と制限設定
|
||||
|
||||
ローカルのエフェメラルストレージを管理するためには_ephemeral-storage_パラメーターを利用することができます。
|
||||
Podの各コンテナは、次の1つ以上を指定できます。
|
||||
* `spec.containers[].resources.limits.ephemeral-storage`
|
||||
* `spec.containers[].resources.requests.ephemeral-storage`
|
||||
|
||||
`ephemeral-storage`の制限と要求はバイト単位で記します。
|
||||
ストレージは、次のいずれかの接尾辞を使用して、通常の整数または固定小数点整数として表すことができます。
|
||||
E、P、T、G、M、K。Ei、Pi、Ti、Gi、Mi、Kiの2のべき乗を使用することもできます。
|
||||
たとえば、以下はほぼ同じ値を表しています。
|
||||
|
||||
```shell
|
||||
128974848, 129e6, 129M, 123Mi
|
||||
```
|
||||
|
||||
次の例では、Podに2つのコンテナがあります。
|
||||
各コンテナには、2GiBのローカルのエフェメラルストレージ要求があります。
|
||||
各コンテナには、4GiBのローカルのエフェメラルストレージ制限があります。
|
||||
したがって、Podには4GiBのローカルのエフェメラルストレージの要求と、8GiBのローカルのエフェメラルストレージ制限があります。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: frontend
|
||||
spec:
|
||||
containers:
|
||||
- name: db
|
||||
image: mysql
|
||||
env:
|
||||
- name: MYSQL_ROOT_PASSWORD
|
||||
value: "password"
|
||||
resources:
|
||||
requests:
|
||||
ephemeral-storage: "2Gi"
|
||||
limits:
|
||||
ephemeral-storage: "4Gi"
|
||||
- name: wp
|
||||
image: wordpress
|
||||
resources:
|
||||
requests:
|
||||
ephemeral-storage: "2Gi"
|
||||
limits:
|
||||
ephemeral-storage: "4Gi"
|
||||
```
|
||||
|
||||
### エフェメラルストレージを要求するPodのスケジュール方法
|
||||
|
||||
Podを作成すると、KubernetesスケジューラーはPodを実行するNodeを選択します。
|
||||
各Nodeには、Podに提供できるローカルのエフェメラルストレージの上限があります。
|
||||
詳細については、[Node割り当て可能](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)を参照してください。
|
||||
|
||||
スケジューラーは、スケジュールされたコンテナのリソース要求の合計がNodeの容量より少なくなるようにします。
|
||||
|
||||
### エフェメラルストレージの消費管理 {#resource-emphemeralstorage-consumption}
|
||||
|
||||
kubeletがローカルのエフェメラルストレージをリソースとして管理している場合、kubeletはストレージの使用量を測定します
|
||||
|
||||
- _tmpfs_`emptyDir`ボリュームを除く`emptyDir`ボリューム
|
||||
- Nodeレベルのログを保持するディレクトリ
|
||||
- 書き込み可能なコンテナレイヤー
|
||||
|
||||
Podが許可するよりも多くのエフェメラルストレージを使用している場合、kubeletはPodの排出をトリガーするシグナルを設定します。
|
||||
|
||||
コンテナレベルの分離の場合、コンテナの書き込み可能なレイヤーとログ使用量がストレージの制限を超えると、kubeletはPodに排出のマークを付けます。
|
||||
Podレベルの分離の場合、kubeletはPod内のコンテナの制限を合計し、Podの全体的なストレージ制限を計算します。
|
||||
このケースでは、すべてのコンテナからのローカルのエフェメラルストレージの使用量とPodの`emptyDir`ボリュームの合計がPod全体のストレージ制限を超過する場合、
|
||||
kubeletはPodをまた排出対象としてマークします。
|
||||
|
||||
{{< caution >}}
|
||||
kubeletがローカルのエフェメラルストレージを測定していない場合、ローカルストレージの制限を超えるPodは、ローカルストレージのリソース制限に違反しても排出されません。
|
||||
|
||||
ただし、書き込み可能なコンテナレイヤー、Nodeレベルのログ、または`emptyDir`ボリュームのファイルシステムスペースが少なくなると、Nodeはローカルストレージが不足していると汚染{{< glossary_tooltip text="taints" term_id="taint" >}}し、この汚染は、汚染を特に許容しないPodの排出をトリガーします。
|
||||
|
||||
ローカルのエフェメラルストレージについては、サポートされている[設定](＃configurations-for-local-ephemeral-storage)をご覧ください。
|
||||
{{< /caution >}}
|
||||
|
||||
kubeletはPodストレージの使用状況を測定するさまざまな方法をサポートしています
|
||||
|
||||
{{< tabs name="resource-emphemeralstorage-measurement" >}}
|
||||
{{% tab name="定期スキャン" %}}
|
||||
kubeletは、`emptyDir`ボリューム、コンテナログディレクトリ、書き込み可能なコンテナレイヤーをスキャンする定期的なスケジュールチェックを実行します。
|
||||
|
||||
スキャンは、使用されているスペースの量を測定します。
|
||||
|
||||
{{< note >}}
|
||||
このモードでは、kubeletは削除されたファイルのために、開いているファイルディスクリプタを追跡しません。
|
||||
|
||||
あなた(またはコンテナ)が`emptyDir`ボリューム内にファイルを作成した後、何かがそのファイルを開き、そのファイルが開かれたままの状態でファイルを削除した場合、削除されたファイルのinodeはそのファイルを閉じるまで残りますが、kubeletはそのスペースを使用中として分類しません。
|
||||
{{< /note >}}
|
||||
{{% /tab %}}
|
||||
{{% tab name="ファイルシステムプロジェクトクォータ" %}}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.15" state="alpha" >}}
|
||||
|
||||
プロジェクトクォータは、ファイルシステム上のストレージ使用量を管理するためのオペレーティングシステムレベルの機能です。
|
||||
Kubernetesでは、プロジェクトクォータを有効にしてストレージの使用状況を監視することができます。
|
||||
ノード上の`emptyDir`ボリュームをバックアップしているファイルシステムがプロジェクトクォータをサポートしていることを確認してください。
|
||||
例えば、XFSやext4fsはプロジェクトクォータを提供しています。
|
||||
|
||||
{{< note >}}
|
||||
プロジェクトクォータはストレージの使用状況を監視しますが、制限を強制するものではありません。
|
||||
{{< /note >}}
|
||||
|
||||
Kubernetesでは、`1048576`から始まるプロジェクトIDを使用します。
|
||||
使用するプロジェクトIDは`/etc/projects`と`/etc/projid`に登録されます。
|
||||
この範囲のプロジェクトIDをシステム上で別の目的で使用する場合は、それらのプロジェクトIDを`/etc/projects`と`/etc/projid`に登録し、
|
||||
Kubernetesが使用しないようにする必要があります。
|
||||
|
||||
クォータはディレクトリスキャンよりも高速で正確です。
|
||||
ディレクトリがプロジェクトに割り当てられると、ディレクトリ配下に作成されたファイルはすべてそのプロジェクト内に作成され、カーネルはそのプロジェクト内のファイルによって使用されているブロックの数を追跡するだけです。
|
||||
ファイルが作成されて削除されても、開いているファイルディスクリプタがあれば、スペースを消費し続けます。
|
||||
クォータトラッキングはそのスペースを正確に記録しますが、ディレクトリスキャンは削除されたファイルが使用するストレージを見落としてしまいます。
|
||||
|
||||
プロジェクトクォータを使用する場合は、次のことを行う必要があります。
|
||||
|
||||
* kubelet設定で、`LocalocalStorpactionCapactionIsolationFSQuotaMonitoring=true`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gate/)を有効にします。
|
||||
|
||||
* ルートファイルシステム(またはオプションのランタイムファイルシステム))がプロジェクトクォータを有効にしていることを確認してください。
|
||||
すべてのXFSファイルシステムはプロジェクトクォータをサポートしています。
|
||||
ext4ファイルシステムでは、ファイルシステムがマウントされていない間は、プロジェクトクォータ追跡機能を有効にする必要があります。
|
||||
```bash
|
||||
# ext4の場合、/dev/block-deviceがマウントされていません
|
||||
sudo tune2fs -O project -Q prjquota /dev/block-device
|
||||
```
|
||||
|
||||
* ルートファイルシステム(またはオプションのランタイムファイルシステム)がプロジェクトクォータを有効にしてマウントされていることを確認してください。
|
||||
XFSとext4fsの両方で、マウントオプションは`prjquota`という名前になっています。
|
||||
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
## 拡張リソース
|
||||
|
||||
拡張リソースは`kubernetes.io`ドメインの外で完全に修飾されたリソース名です。
|
||||
これにより、クラスタオペレータはKubernetesに組み込まれていないリソースをアドバタイズし、ユーザはそれを利用することができるようになります。
|
||||
|
||||
拡張リソースを使用するためには、2つのステップが必要です。
|
||||
第一に、クラスタオペレーターは拡張リソースをアドバタイズする必要があります。
|
||||
第二に、ユーザーはPodで拡張リソースを要求する必要があります。
|
||||
|
||||
### 拡張リソースの管理
|
||||
|
||||
#### Nodeレベルの拡張リソース
|
||||
|
||||
Nodeレベルの拡張リソースはNodeに関連付けられています。
|
||||
|
||||
##### デバイスプラグイン管理のリソース
|
||||
各Nodeにデバイスプラグインで管理されているリソースをアドバタイズする方法については、[デバイスプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)を参照してください。
|
||||
|
||||
##### その他のリソース
|
||||
新しいNodeレベルの拡張リソースをアドバタイズするには、クラスタオペレータはAPIサーバに`PATCH`HTTPリクエストを送信し、クラスタ内のNodeの`status.capacity`に利用可能な量を指定します。
|
||||
この操作の後、ノードの`status.capacity`には新しいリソースが含まれます。
|
||||
`status.allocatable`フィールドは、kubeletによって非同期的に新しいリソースで自動的に更新されます。
|
||||
スケジューラはPodの適合性を評価する際にNodeの`status.allocatable`値を使用するため、Nodeの容量に新しいリソースを追加してから、そのNodeでリソースのスケジューリングを要求する最初のPodが現れるまでには、短い遅延が生じる可能性があることに注意してください。
|
||||
|
||||
**例:**
|
||||
|
||||
以下は、`curl`を使用して、Masterが`k8s-master`であるNode`k8s-node-1`で5つの`example.com/foo`リソースを示すHTTPリクエストを作成する方法を示す例です。
|
||||
|
||||
```shell
|
||||
curl --header "Content-Type: application/json-patch+json" \
|
||||
--request PATCH \
|
||||
--data '[{"op": "add", "path": "/status/capacity/example.com~1foo", "value": "5"}]' \
|
||||
http://k8s-master:8080/api/v1/nodes/k8s-node-1/status
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
上記のリクエストでは、`~1`はパッチパス内の文字`/`のエンコーディングです。
|
||||
JSON-Patchの操作パス値は、JSON-Pointerとして解釈されます。
|
||||
詳細については、[IETF RFC 6901, section 3](https://tools.ietf.org/html/rfc6901#section-3)を参照してください。
|
||||
{{< /note >}}
|
||||
|
||||
#### クラスターレベルの拡張リソース
|
||||
|
||||
クラスターレベルの拡張リソースはノードに関連付けられていません。
|
||||
これらは通常、リソース消費とリソースクォータを処理するスケジューラー拡張機能によって管理されます。
|
||||
|
||||
[スケジューラーポリシー構成](https://github.com/kubernetes/kubernetes/blob/release-1.10/pkg/scheduler/api/v1/types.go#L31)では。スケジューラー拡張機能によって扱われる拡張リソースを指定できます。
|
||||
|
||||
**例:**
|
||||
|
||||
次のスケジューラーポリシーの構成は、クラスターレベルの拡張リソース"example.com/foo"がスケジューラー拡張機能によって処理されることを示しています。
|
||||
|
||||
- スケジューラーは、Podが"example.com/foo"を要求した場合にのみ、Podをスケジューラー拡張機能に送信します。
|
||||
- `ignoredByScheduler`フィールドは、スケジューラがその`PodFitsResources`述語で"example.com/foo"リソースをチェックしないことを指定します。
|
||||
|
||||
```json
|
||||
{
|
||||
"kind": "Policy",
|
||||
"apiVersion": "v1",
|
||||
"extenders": [
|
||||
{
|
||||
"urlPrefix":"<extender-endpoint>",
|
||||
"bindVerb": "bind",
|
||||
"managedResources": [
|
||||
{
|
||||
"name": "example.com/foo",
|
||||
"ignoredByScheduler": true
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### 拡張リソースの消費
|
||||
|
||||
ユーザーは、CPUやメモリのようにPodのスペックで拡張されたリソースを消費できます。
|
||||
利用可能な量以上のリソースが同時にPodに割り当てられないように、スケジューラーがリソースアカウンティングを行います。
|
||||
|
||||
APIサーバーは、拡張リソースの量を整数の値で制限します。
|
||||
有効な数量の例は、`3`、`3000m`、`3Ki`です。
|
||||
無効な数量の例は、`0.5`、`1500m`です。
|
||||
|
||||
{{< note >}}
|
||||
拡張リソースは不透明な整数リソースを置き換えます。
|
||||
ユーザーは、予約済みの`kubernetes.io`以外のドメイン名プレフィックスを使用できます。
|
||||
{{< /note >}}
|
||||
|
||||
Podで拡張リソースを消費するには、コンテナ名の`spec.containers[].resources.limits`マップにキーとしてリソース名を含めます。
|
||||
|
||||
{{< note >}}
|
||||
拡張リソースはオーバーコミットできないので、コンテナスペックに要求と制限の両方が存在する場合は等しくなければなりません。
|
||||
{{< /note >}}
|
||||
|
||||
Podは、CPU、メモリ、拡張リソースを含むすべてのリソース要求が満たされた場合にのみスケジュールされます。
|
||||
リソース要求が満たされない限り、Podは`PENDING`状態のままです。
|
||||
|
||||
**例:**
|
||||
|
||||
下のPodはCPUを2つ、"example.com/foo"(拡張リソース)を1つ要求しています。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: my-pod
|
||||
spec:
|
||||
containers:
|
||||
- name: my-container
|
||||
image: myimage
|
||||
resources:
|
||||
requests:
|
||||
cpu: 2
|
||||
example.com/foo: 1
|
||||
limits:
|
||||
example.com/foo: 1
|
||||
```
|
||||
|
||||
## トラブルシューティング
|
||||
|
||||
### failedSchedulingイベントメッセージが表示され、Podが保留中になる
|
||||
|
||||
スケジューラーがPodが収容されるNodeを見つけられない場合、場所が見つかるまでPodはスケジュールされないままになります。
|
||||
スケジューラーがPodの場所を見つけられないたびに、次のようなイベントが生成されます。
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
前述の例では、"frontend"という名前のPodは、Node上のCPUリソースが不足しているためにスケジューリングに失敗しています。
|
||||
同様のエラーメッセージは、メモリー不足による失敗を示唆することもあります(PodExceedsFreeMemory)。
|
||||
一般的に、このタイプのメッセージでPodが保留されている場合は、いくつか試すべきことがあります。
|
||||
|
||||
- クラスタにNodeを追加します。
|
||||
- 不要なポッドを終了して、保留中のPodのためのスペースを空けます。
|
||||
- PodがすべてのNodeよりも大きくないことを確認してください。
|
||||
例えば、すべてのNodeが`cpu: 1`の容量を持っている場合、`cpu: 1.1`を要求するPodは決してスケジューリングされません。
|
||||
|
||||
Nodeの容量や割り当て量は`kubectl describe nodes`コマンドで調べることができる。
|
||||
例えば、以下のようになる。
|
||||
|
||||
```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%)
|
||||
```
|
||||
|
||||
前述の出力では、Podが1120m以上のCPUや6.23Gi以上のメモリーを要求した場合、そのPodはNodeに収まらないことがわかります。
|
||||
|
||||
`Pods`セクションを見れば、どのPodがNode上でスペースを占有しているかがわかります。
|
||||
|
||||
システムデーモンが利用可能なリソースの一部を使用しているため、Podに利用可能なリソースの量はNodeの容量よりも少なくなっています。
|
||||
`allocatable`フィールド[NodeStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#nodestatus-v1-core)は、Podに利用可能なリソースの量を与えます。
|
||||
詳細については、[ノード割り当て可能なリソース](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md)を参照してください。
|
||||
|
||||
[リソースクォータ](/docs/concepts/policy/resource-quotas/)機能は、消費できるリソースの総量を制限するように設定することができます。
|
||||
名前空間と組み合わせて使用すると、1つのチームがすべてのリソースを占有するのを防ぐことができます。
|
||||
|
||||
### コンテナが終了した
|
||||
|
||||
コンテナはリソース不足のため、終了する可能性があります。
|
||||
コンテナがリソース制限に達したために強制終了されているかどうかを確認するには、対象のPodで`kubectl describe pod`を呼び出します。
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
上記の例では、`Restart Count：5`はPodの`simmemleak`コンテナが終了して、5回再起動したことを示しています。
|
||||
|
||||
`-o go-template=...`オプションを指定して、`kubectl get pod`を呼び出し、以前に終了したコンテナのステータスを取得できます。
|
||||
|
||||
```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]]
|
||||
```
|
||||
|
||||
`reason：OOM Killed`が原因でコンテナが終了したことがわかります。`OOM`はメモリー不足を表します。
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [コンテナとPodへのメモリーリソースの割り当て](/docs/tasks/configure-pod-container/assign-memory-resource/)ハンズオンを行う
|
||||
|
||||
* [コンテナとPodへのCPUリソースの割り当て](/docs/tasks/configure-pod-container/assign-cpu-resource/)ハンズオンを行う
|
||||
|
||||
* 要求と制限の違いの詳細については、[リソースQoS](https://git.k8s.io/community/contributors/design-proposals/node/resource-qos.md)を参照する
|
||||
|
||||
* [コンテナ](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)APIリファレンスを読む
|
||||
|
||||
* [リソース要求](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcerequirements-v1-core)APIリファレンスを読む
|
||||
|
||||
* XFSの[プロジェクトクォータ](http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html)について読む
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue