dev-1.20 branch version for pod-lifecycle.md for feature state for k8s version
This commit is contained in:
reylejano-rxm
@@ -1,4 +1,6 @@
|
||||
---
|
||||
linktitle: Kubernetes Documentation
|
||||
title: Documentation
|
||||
sitemap:
|
||||
priority: 1.0
|
||||
---
|
||||
|
||||
@@ -261,7 +261,7 @@ a Lease object.
|
||||
|
||||
#### Reliability
|
||||
|
||||
In most cases, node controller limits the eviction rate to
|
||||
In most cases, the node controller limits the eviction rate to
|
||||
`--node-eviction-rate` (default 0.1) per second, meaning it won't evict pods
|
||||
from more than 1 node per 10 seconds.
|
||||
|
||||
|
||||
@@ -115,7 +115,8 @@ metadata:
|
||||
spec:
|
||||
containers:
|
||||
- name: demo
|
||||
image: game.example/demo-game
|
||||
image: alpine
|
||||
command: ["sleep", "3600"]
|
||||
env:
|
||||
# Define the environment variable
|
||||
- name: PLAYER_INITIAL_LIVES # Notice that the case is different here
|
||||
|
||||
@@ -47,6 +47,13 @@ Limits can be implemented either reactively (the system intervenes once it sees
|
||||
or by enforcement (the system prevents the container from ever exceeding the limit). Different
|
||||
runtimes can have different ways to implement the same restrictions.
|
||||
|
||||
{{< note >}}
|
||||
If a Container specifies its own memory limit, but does not specify a memory request, Kubernetes
|
||||
automatically assigns a memory request that matches the limit. Similarly, if a Container specifies its own
|
||||
CPU limit, but does not specify a CPU request, Kubernetes automatically assigns a CPU request that matches
|
||||
the limit.
|
||||
{{< /note >}}
|
||||
|
||||
## Resource types
|
||||
|
||||
*CPU* and *memory* are each a *resource type*. A resource type has a base unit.
|
||||
|
||||
@@ -38,7 +38,7 @@ No parameters are passed to the handler.
|
||||
|
||||
This hook is called immediately before a container is terminated due to an API request or management event such as liveness probe failure, preemption, resource contention and others. A call to the preStop hook fails if the container is already in terminated or completed state.
|
||||
It is blocking, meaning it is synchronous,
|
||||
so it must complete before the call to delete the container can be sent.
|
||||
so it must complete before the signal to stop the container can be sent.
|
||||
No parameters are passed to the handler.
|
||||
|
||||
A more detailed description of the termination behavior can be found in
|
||||
@@ -56,7 +56,8 @@ Resources consumed by the command are counted against the Container.
|
||||
### Hook handler execution
|
||||
|
||||
When a Container lifecycle management hook is called,
|
||||
the Kubernetes management system executes the handler in the Container registered for that hook.
|
||||
the Kubernetes management system execute the handler according to the hook action,
|
||||
`exec` and `tcpSocket` are executed in the container, and `httpGet` is executed by the kubelet process.
|
||||
|
||||
Hook handler calls are synchronous within the context of the Pod containing the Container.
|
||||
This means that for a `PostStart` hook,
|
||||
@@ -64,10 +65,21 @@ the Container ENTRYPOINT and hook fire asynchronously.
|
||||
However, if the hook takes too long to run or hangs,
|
||||
the Container cannot reach a `running` state.
|
||||
|
||||
The behavior is similar for a `PreStop` hook.
|
||||
If the hook hangs during execution,
|
||||
the Pod phase stays in a `Terminating` state and is killed after `terminationGracePeriodSeconds` of pod ends.
|
||||
If a `PostStart` or `PreStop` hook fails,
|
||||
`PreStop` hooks are not executed asynchronously from the signal
|
||||
to stop the Container; the hook must complete its execution before
|
||||
the signal can be sent.
|
||||
If a `PreStop` hook hangs during execution,
|
||||
the Pod's phase will be `Terminating` and remain there until the Pod is
|
||||
killed after its `terminationGracePeriodSeconds` expires.
|
||||
This grace period applies to the total time it takes for both
|
||||
the `PreStop` hook to execute and for the Container to stop normally.
|
||||
If, for example, `terminationGracePeriodSeconds` is 60, and the hook
|
||||
takes 55 seconds to complete, and the Container takes 10 seconds to stop
|
||||
normally after receiving the signal, then the Container will be killed
|
||||
before it can stop normally, since `terminationGracePeriodSeconds` is
|
||||
less than the total time (55+10) it takes for these two things to happen.
|
||||
|
||||
If either a `PostStart` or `PreStop` hook fails,
|
||||
it kills the Container.
|
||||
|
||||
Users should make their hook handlers as lightweight as possible.
|
||||
@@ -121,4 +133,3 @@ Events:
|
||||
* Get hands-on experience
|
||||
[attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
|
||||
|
||||
|
||||
|
||||
@@ -11,21 +11,17 @@ weight: 10
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state state="alpha" >}}
|
||||
{{< caution >}}Alpha features can change rapidly. {{< /caution >}}
|
||||
|
||||
Network plugins in Kubernetes come in a few flavors:
|
||||
|
||||
* CNI plugins: adhere to the appc/CNI specification, designed for interoperability.
|
||||
* CNI plugins: adhere to the [Container Network Interface](https://github.com/containernetworking/cni) (CNI) specification, designed for interoperability.
|
||||
* Kubernetes follows the [v0.4.0](https://github.com/containernetworking/cni/blob/spec-v0.4.0/SPEC.md) release of the CNI specification.
|
||||
* Kubenet plugin: implements basic `cbr0` using the `bridge` and `host-local` CNI plugins
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Installation
|
||||
|
||||
The kubelet has a single default network plugin, and a default network common to the entire cluster. It probes for plugins when it starts up, remembers what it finds, and executes the selected plugin at appropriate times in the pod lifecycle (this is only true for Docker, as rkt manages its own CNI plugins). There are two Kubelet command line parameters to keep in mind when using plugins:
|
||||
The kubelet has a single default network plugin, and a default network common to the entire cluster. It probes for plugins when it starts up, remembers what it finds, and executes the selected plugin at appropriate times in the pod lifecycle (this is only true for Docker, as CRI manages its own CNI plugins). There are two Kubelet command line parameters to keep in mind when using plugins:
|
||||
|
||||
* `cni-bin-dir`: Kubelet probes this directory for plugins on startup
|
||||
* `network-plugin`: The network plugin to use from `cni-bin-dir`. It must match the name reported by a plugin probed from the plugin directory. For CNI plugins, this is simply "cni".
|
||||
@@ -166,9 +162,4 @@ This option is provided to the network-plugin; currently **only kubenet supports
|
||||
* `--network-plugin=kubenet` specifies that we use the `kubenet` network plugin with CNI `bridge` and `host-local` plugins placed in `/opt/cni/bin` or `cni-bin-dir`.
|
||||
* `--network-plugin-mtu=9001` specifies the MTU to use, currently only used by the `kubenet` network plugin.
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -2,4 +2,6 @@
|
||||
title: "Overview"
|
||||
weight: 20
|
||||
description: Get a high-level outline of Kubernetes and the components it is built from.
|
||||
sitemap:
|
||||
priority: 0.9
|
||||
---
|
||||
|
||||
@@ -41,6 +41,7 @@ The Kubernetes API server serves an OpenAPI spec via the `/openapi/v2` endpoint.
|
||||
You can request the response format using request headers as follows:
|
||||
|
||||
<table>
|
||||
<caption style="display:none">Valid request header values for OpenAPI v2 queries</caption>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Header</th>
|
||||
@@ -68,7 +69,6 @@ You can request the response format using request headers as follows:
|
||||
<td><em>serves </em><code>application/json</code></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
<caption>Valid request header values for OpenAPI v2 queries</caption>
|
||||
</table>
|
||||
|
||||
Kubernetes implements an alternative Protobuf based serialization format that
|
||||
@@ -102,13 +102,22 @@ to ensure that the API presents a clear, consistent view of system resources
|
||||
and behavior, and to enable controlling access to end-of-life and/or
|
||||
experimental APIs.
|
||||
|
||||
Refer to [API versions reference](/docs/reference/using-api/api-overview/#api-versioning)
|
||||
for more details on the API version level definitions.
|
||||
|
||||
To make it easier to evolve and to extend its API, Kubernetes implements
|
||||
[API groups](/docs/reference/using-api/api-overview/#api-groups) that can be
|
||||
[enabled or disabled](/docs/reference/using-api/api-overview/#enabling-or-disabling).
|
||||
|
||||
API resources are distinguished by their API group, resource type, namespace
|
||||
(for namespaced resources), and name. The API server may serve the same
|
||||
underlying data through multiple API version and handle the conversion between
|
||||
API versions transparently. All these different versions are actually
|
||||
representations of the same resource. For example, suppose there are two
|
||||
versions `v1` and `v1beta1` for the same resource. An object created by the
|
||||
`v1beta1` version can then be read, updated, and deleted by either the
|
||||
`v1beta1` or the `v1` versions.
|
||||
|
||||
Refer to [API versions reference](/docs/reference/using-api/api-overview/#api-versioning)
|
||||
for more details on the API version level definitions.
|
||||
|
||||
## API Extension
|
||||
|
||||
The Kubernetes API can be extended in one of two ways:
|
||||
|
||||
@@ -10,6 +10,8 @@ weight: 10
|
||||
card:
|
||||
name: concepts
|
||||
weight: 10
|
||||
sitemap:
|
||||
priority: 0.9
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
@@ -28,9 +28,6 @@ resource can only be in one namespace.
|
||||
|
||||
Namespaces are a way to divide cluster resources between multiple users (via [resource quota](/docs/concepts/policy/resource-quotas/)).
|
||||
|
||||
In future versions of Kubernetes, objects in the same namespace will have the same
|
||||
access control policies by default.
|
||||
|
||||
It is not necessary to use multiple namespaces just to separate slightly different
|
||||
resources, such as different versions of the same software: use
|
||||
[labels](/docs/concepts/overview/working-with-objects/labels) to distinguish
|
||||
|
||||
@@ -20,7 +20,7 @@ The kube-scheduler can be configured to enable bin packing of resources along wi
|
||||
|
||||
## Enabling Bin Packing using RequestedToCapacityRatioResourceAllocation
|
||||
|
||||
Before Kubernetes 1.15, Kube-scheduler used to allow scoring nodes based on the request to capacity ratio of primary resources like CPU and Memory. Kubernetes 1.16 added a new parameter to the priority function that allows the users to specify the resources along with weights for each resource to score nodes based on the request to capacity ratio. This allows users to bin pack extended resources by using appropriate parameters improves the utilization of scarce resources in large clusters. The behavior of the `RequestedToCapacityRatioResourceAllocation` priority function can be controlled by a configuration option called `requestedToCapacityRatioArguments`. This argument consists of two parameters `shape` and `resources`. Shape allows the user to tune the function as least requested or most requested based on `utilization` and `score` values. Resources
|
||||
Before Kubernetes 1.15, Kube-scheduler used to allow scoring nodes based on the request to capacity ratio of primary resources like CPU and Memory. Kubernetes 1.16 added a new parameter to the priority function that allows the users to specify the resources along with weights for each resource to score nodes based on the request to capacity ratio. This allows users to bin pack extended resources by using appropriate parameters and improves the utilization of scarce resources in large clusters. The behavior of the `RequestedToCapacityRatioResourceAllocation` priority function can be controlled by a configuration option called `requestedToCapacityRatioArguments`. This argument consists of two parameters `shape` and `resources`. Shape allows the user to tune the function as least requested or most requested based on `utilization` and `score` values. Resources
|
||||
consists of `name` which specifies the resource to be considered during scoring and `weight` specify the weight of each resource.
|
||||
|
||||
Below is an example configuration that sets `requestedToCapacityRatioArguments` to bin packing behavior for extended resources `intel.com/foo` and `intel.com/bar`
|
||||
|
||||
@@ -181,7 +181,7 @@ When you set `setHostnameAsFQDN: true` in the Pod spec, the kubelet writes the P
|
||||
{{< note >}}
|
||||
In Linux, the hostname field of the kernel (the `nodename` field of `struct utsname`) is limited to 64 characters.
|
||||
|
||||
If a Pod enables this feature and its FQDN is longer than 64 character, it will fail to start. The Pod will remain in `Pending` status (`ContainerCreating` as seen by `kubectl`) generating error events, such as Failed to construct FQDN from pod hostname and cluster domain, FQDN `long-FDQN` is too long (64 characters is the max, 70 characters requested). One way of improving user experience for this scenario is to create an [admission webhook controller](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) to control FQDN size when users create top level objects, for example, Deployment.
|
||||
If a Pod enables this feature and its FQDN is longer than 64 character, it will fail to start. The Pod will remain in `Pending` status (`ContainerCreating` as seen by `kubectl`) generating error events, such as Failed to construct FQDN from pod hostname and cluster domain, FQDN `long-FQDN` is too long (64 characters is the max, 70 characters requested). One way of improving user experience for this scenario is to create an [admission webhook controller](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) to control FQDN size when users create top level objects, for example, Deployment.
|
||||
{{< /note >}}
|
||||
|
||||
### Pod's DNS Policy
|
||||
|
||||
@@ -881,6 +881,10 @@ There are other annotations to manage Classic Elastic Load Balancers that are de
|
||||
# health check. This value must be less than the service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval
|
||||
# value. Defaults to 5, must be between 2 and 60
|
||||
|
||||
service.beta.kubernetes.io/aws-load-balancer-security-groups: "sg-53fae93f"
|
||||
# A list of existing security groups to be added to ELB created. Unlike the annotation
|
||||
# service.beta.kubernetes.io/aws-load-balancer-extra-security-groups, this replaces all other security groups previously assigned to the ELB.
|
||||
|
||||
service.beta.kubernetes.io/aws-load-balancer-extra-security-groups: "sg-53fae93f,sg-42efd82e"
|
||||
# A list of additional security groups to be added to the ELB
|
||||
|
||||
|
||||
@@ -13,7 +13,7 @@ weight: 10
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
A _Deployment_ provides declarative updates for {{< glossary_tooltip text="Pods" term_id="pod" >}}
|
||||
A _Deployment_ provides declarative updates for {{< glossary_tooltip text="Pods" term_id="pod" >}} and
|
||||
{{< glossary_tooltip term_id="replica-set" text="ReplicaSets" >}}.
|
||||
|
||||
You describe a _desired state_ in a Deployment, and the Deployment {{< glossary_tooltip term_id="controller" >}} changes the actual state to the desired state at a controlled rate. You can define Deployments to create new ReplicaSets, or to remove existing Deployments and adopt all their resources with new Deployments.
|
||||
@@ -102,7 +102,7 @@ Follow the steps given below to create the above Deployment:
|
||||
The output is similar to:
|
||||
```
|
||||
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
|
||||
deployment.apps/nginx-deployment successfully rolled out
|
||||
deployment "nginx-deployment" successfully rolled out
|
||||
```
|
||||
|
||||
4. Run the `kubectl get deployments` again a few seconds later.
|
||||
@@ -205,7 +205,7 @@ Follow the steps given below to update your Deployment:
|
||||
```
|
||||
or
|
||||
```
|
||||
deployment.apps/nginx-deployment successfully rolled out
|
||||
deployment "nginx-deployment" successfully rolled out
|
||||
```
|
||||
|
||||
Get more details on your updated Deployment:
|
||||
@@ -857,7 +857,7 @@ kubectl rollout status deployment.v1.apps/nginx-deployment
|
||||
The output is similar to this:
|
||||
```
|
||||
Waiting for rollout to finish: 2 of 3 updated replicas are available...
|
||||
deployment.apps/nginx-deployment successfully rolled out
|
||||
deployment "nginx-deployment" successfully rolled out
|
||||
```
|
||||
and the exit status from `kubectl rollout` is 0 (success):
|
||||
```shell
|
||||
|
||||
@@ -13,7 +13,8 @@ of its primary containers starts OK, and then through either the `Succeeded` or
|
||||
|
||||
Whilst a Pod is running, the kubelet is able to restart containers to handle some
|
||||
kind of faults. Within a Pod, Kubernetes tracks different container
|
||||
[states](#container-states) and handles
|
||||
[states](#container-states) and determines what action to take to make the Pod
|
||||
healthy again.
|
||||
|
||||
In the Kubernetes API, Pods have both a specification and an actual status. The
|
||||
status for a Pod object consists of a set of [Pod conditions](#pod-conditions).
|
||||
@@ -32,7 +33,7 @@ Like individual application containers, Pods are considered to be relatively
|
||||
ephemeral (rather than durable) entities. Pods are created, assigned a unique
|
||||
ID ([UID](/docs/concepts/overview/working-with-objects/names/#uids)), and scheduled
|
||||
to nodes where they remain until termination (according to restart policy) or
|
||||
deletion.
|
||||
deletion.
|
||||
If a {{< glossary_tooltip term_id="node" >}} dies, the Pods scheduled to that node
|
||||
are [scheduled for deletion](#pod-garbage-collection) after a timeout period.
|
||||
|
||||
@@ -140,9 +141,8 @@ and Never. The default value is Always.
|
||||
The `restartPolicy` applies to all containers in the Pod. `restartPolicy` only
|
||||
refers to restarts of the containers by the kubelet on the same node. After containers
|
||||
in a Pod exit, the kubelet restarts them with an exponential back-off delay (10s, 20s,
|
||||
40s, …), that is capped at five minutes. Once a container has executed with no problems
|
||||
for 10 minutes without any problems, the kubelet resets the restart backoff timer for
|
||||
that container.
|
||||
40s, …), that is capped at five minutes. Once a container has executed for 10 minutes
|
||||
without any problems, the kubelet resets the restart backoff timer forthat container.
|
||||
|
||||
## Pod conditions
|
||||
|
||||
|
||||
@@ -13,6 +13,13 @@ card:
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
*Kubernetes welcomes improvements from all contributors, new and experienced!*
|
||||
|
||||
{{< note >}}
|
||||
To learn more about contributing to Kubernetes in general, see the
|
||||
[contributor documentation](https://www.kubernetes.dev/docs/).
|
||||
{{< /note >}}
|
||||
|
||||
This website is maintained by [Kubernetes SIG Docs](/docs/contribute/#get-involved-with-sig-docs).
|
||||
|
||||
Kubernetes documentation contributors:
|
||||
@@ -22,8 +29,6 @@ Kubernetes documentation contributors:
|
||||
- Translate the documentation
|
||||
- Manage and publish the documentation parts of the Kubernetes release cycle
|
||||
|
||||
Kubernetes documentation welcomes improvements from all contributors, new and experienced!
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Getting started
|
||||
|
||||
@@ -230,11 +230,9 @@ Build the Kubernetes documentation in your local `<web-base>`.
|
||||
|
||||
```shell
|
||||
cd <web-base>
|
||||
make docker-serve
|
||||
git submodule update --init --recursive --depth 1 # if not already done
|
||||
make container-serve
|
||||
```
|
||||
{{< note >}}
|
||||
The use of `make docker-serve` is deprecated. Please use `make container-serve` instead.
|
||||
{{< /note >}}
|
||||
|
||||
View the [local preview](https://localhost:1313/docs/reference/generated/kubectl/kubectl-commands/).
|
||||
|
||||
|
||||
@@ -182,13 +182,10 @@ Verify the [local preview](http://localhost:1313/docs/reference/generated/kubern
|
||||
|
||||
```shell
|
||||
cd <web-base>
|
||||
make docker-serve
|
||||
git submodule update --init --recursive --depth 1 # if not already done
|
||||
make container-serve
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
The use of `make docker-serve` is deprecated. Please use `make container-serve` instead.
|
||||
{{< /note >}}
|
||||
|
||||
## Commit the changes
|
||||
|
||||
In `<web-base>` run `git add` and `git commit` to commit the change.
|
||||
|
||||
@@ -73,7 +73,9 @@ For an example of adding a label, see the PR for adding the [Italian language la
|
||||
|
||||
### Find community
|
||||
|
||||
Let Kubernetes SIG Docs know you're interested in creating a localization! Join the [SIG Docs Slack channel](https://kubernetes.slack.com/messages/C1J0BPD2M/). Other localization teams are happy to help you get started and answer any questions you have.
|
||||
Let Kubernetes SIG Docs know you're interested in creating a localization! Join the [SIG Docs Slack channel](https://kubernetes.slack.com/messages/sig-docs) and the [SIG Docs Localizations Slack channel](https://kubernetes.slack.com/messages/sig-docs-localizations). Other localization teams are happy to help you get started and answer any questions you have.
|
||||
|
||||
Please also consider participating in the [SIG Docs Localization Subgroup meeting](https://github.com/kubernetes/community/tree/master/sig-docs). The mission of the SIG Docs localization subgroup is to work across the SIG Docs localization teams to collaborate on defining and documenting the processes for creating localized contribution guides. In addition, the SIG Docs localization subgroup will look for opportunities for the creation and sharing of common tools across localization teams and also serve to identify new requirements to the SIG Docs Leadership team. If you have questions about this meeting, please inquire on the [SIG Docs Localizations Slack channel](https://kubernetes.slack.com/messages/sig-docs-localizations).
|
||||
|
||||
You can also create a Slack channel for your localization in the `kubernetes/community` repository. For an example of adding a Slack channel, see the PR for [adding a channel for Persian](https://github.com/kubernetes/community/pull/4980).
|
||||
|
||||
|
||||
@@ -98,7 +98,8 @@ deadlines.
|
||||
1. Open a pull request against the
|
||||
`dev-{{< skew nextMinorVersion >}}` branch in the `kubernetes/website` repository, with a small
|
||||
commit that you will amend later.
|
||||
2. Use the Prow command `/milestone {{< skew nextMinorVersion >}}` to
|
||||
2. Edit the pull request description to include links to `k/k` PR(s) and `k/enhancement` issue(s).
|
||||
3. Use the Prow command `/milestone {{< skew nextMinorVersion >}}` to
|
||||
assign the PR to the relevant milestone. This alerts the docs person managing
|
||||
this release that the feature docs are coming.
|
||||
|
||||
|
||||
@@ -414,6 +414,8 @@ 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.
|
||||
* `--authentication-token-webhook-version` determines whether to use `authentication.k8s.io/v1beta1` or `authentication.k8s.io/v1`
|
||||
`TokenReview` objects to send/receive information from the webhook. Defaults to `v1beta1`.
|
||||
|
||||
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
|
||||
@@ -447,72 +449,167 @@ contexts:
|
||||
name: webhook
|
||||
```
|
||||
|
||||
When a client attempts to authenticate with the API server using a bearer token
|
||||
as discussed [above](#putting-a-bearer-token-in-a-request),
|
||||
the authentication webhook POSTs a JSON-serialized `authentication.k8s.io/v1beta1` `TokenReview` object containing the token
|
||||
to the remote service. Kubernetes will not challenge a request that lacks such a header.
|
||||
When a client attempts to authenticate with the API server using a bearer token as discussed [above](#putting-a-bearer-token-in-a-request),
|
||||
the authentication webhook POSTs a JSON-serialized `TokenReview` object containing the token to the remote service.
|
||||
|
||||
Note that webhook API objects are subject to the same [versioning compatibility rules](/docs/concepts/overview/kubernetes-api/)
|
||||
as other Kubernetes API objects. Implementers should be aware of looser
|
||||
compatibility promises for beta objects and check the "apiVersion" field of the
|
||||
request to ensure correct deserialization. Additionally, the API server must
|
||||
enable the `authentication.k8s.io/v1beta1` API extensions group (`--runtime-config=authentication.k8s.io/v1beta1=true`).
|
||||
Note that webhook API objects are subject to the same [versioning compatibility rules](/docs/concepts/overview/kubernetes-api/) as other Kubernetes API objects.
|
||||
Implementers should check the `apiVersion` field of the request to ensure correct deserialization,
|
||||
and **must** respond with a `TokenReview` object of the same version as the request.
|
||||
|
||||
The POST body will be of the following format:
|
||||
{{< tabs name="TokenReview_request" >}}
|
||||
{{% tab name="authentication.k8s.io/v1" %}}
|
||||
{{< note >}}
|
||||
The Kubernetes API server defaults to sending `authentication.k8s.io/v1beta1` token reviews for backwards compatibility.
|
||||
To opt into receiving `authentication.k8s.io/v1` token reviews, the API server must be started with `--authentication-token-webhook-version=v1`.
|
||||
{{< /note >}}
|
||||
|
||||
```json
|
||||
```yaml
|
||||
{
|
||||
"apiVersion": "authentication.k8s.io/v1",
|
||||
"kind": "TokenReview",
|
||||
"spec": {
|
||||
# Opaque bearer token sent to the API server
|
||||
"token": "014fbff9a07c...",
|
||||
|
||||
# Optional list of the audience identifiers for the server the token was presented to.
|
||||
# Audience-aware token authenticators (for example, OIDC token authenticators)
|
||||
# should verify the token was intended for at least one of the audiences in this list,
|
||||
# and return the intersection of this list and the valid audiences for the token in the response status.
|
||||
# This ensures the token is valid to authenticate to the server it was presented to.
|
||||
# If no audiences are provided, the token should be validated to authenticate to the Kubernetes API server.
|
||||
"audiences": ["https://myserver.example.com", "https://myserver.internal.example.com"]
|
||||
}
|
||||
}
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="authentication.k8s.io/v1beta1" %}}
|
||||
```yaml
|
||||
{
|
||||
"apiVersion": "authentication.k8s.io/v1beta1",
|
||||
"kind": "TokenReview",
|
||||
"spec": {
|
||||
"token": "(BEARERTOKEN)"
|
||||
# Opaque bearer token sent to the API server
|
||||
"token": "014fbff9a07c...",
|
||||
|
||||
# Optional list of the audience identifiers for the server the token was presented to.
|
||||
# Audience-aware token authenticators (for example, OIDC token authenticators)
|
||||
# should verify the token was intended for at least one of the audiences in this list,
|
||||
# and return the intersection of this list and the valid audiences for the token in the response status.
|
||||
# This ensures the token is valid to authenticate to the server it was presented to.
|
||||
# If no audiences are provided, the token should be validated to authenticate to the Kubernetes API server.
|
||||
"audiences": ["https://myserver.example.com", "https://myserver.internal.example.com"]
|
||||
}
|
||||
}
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
The remote service is expected to fill the `status` field of
|
||||
the request to indicate the success of the login. The response body's `spec`
|
||||
field is ignored and may be omitted. A successful validation of the bearer
|
||||
token would return:
|
||||
The remote service is expected to fill the `status` field of the request to indicate the success of the login.
|
||||
The response body's `spec` field is ignored and may be omitted.
|
||||
The remote service must return a response using the same `TokenReview` API version that it received.
|
||||
A successful validation of the bearer token would return:
|
||||
|
||||
```json
|
||||
{{< tabs name="TokenReview_response_success" >}}
|
||||
{{% tab name="authentication.k8s.io/v1" %}}
|
||||
```yaml
|
||||
{
|
||||
"apiVersion": "authentication.k8s.io/v1beta1",
|
||||
"apiVersion": "authentication.k8s.io/v1",
|
||||
"kind": "TokenReview",
|
||||
"status": {
|
||||
"authenticated": true,
|
||||
"user": {
|
||||
# Required
|
||||
"username": "janedoe@example.com",
|
||||
# Optional
|
||||
"uid": "42",
|
||||
"groups": [
|
||||
"developers",
|
||||
"qa"
|
||||
],
|
||||
# Optional group memberships
|
||||
"groups": ["developers", "qa"],
|
||||
# Optional additional information provided by the authenticator.
|
||||
# This should not contain confidential data, as it can be recorded in logs
|
||||
# or API objects, and is made available to admission webhooks.
|
||||
"extra": {
|
||||
"extrafield1": [
|
||||
"extravalue1",
|
||||
"extravalue2"
|
||||
]
|
||||
}
|
||||
}
|
||||
},
|
||||
# Optional list audience-aware token authenticators can return,
|
||||
# containing the audiences from the `spec.audiences` list for which the provided token was valid.
|
||||
# If this is omitted, the token is considered to be valid to authenticate to the Kubernetes API server.
|
||||
"audiences": ["https://myserver.example.com"]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
An unsuccessful request would return:
|
||||
|
||||
```json
|
||||
{{% /tab %}}
|
||||
{{% tab name="authentication.k8s.io/v1beta1" %}}
|
||||
```yaml
|
||||
{
|
||||
"apiVersion": "authentication.k8s.io/v1beta1",
|
||||
"kind": "TokenReview",
|
||||
"status": {
|
||||
"authenticated": false
|
||||
"authenticated": true,
|
||||
"user": {
|
||||
# Required
|
||||
"username": "janedoe@example.com",
|
||||
# Optional
|
||||
"uid": "42",
|
||||
# Optional group memberships
|
||||
"groups": ["developers", "qa"],
|
||||
# Optional additional information provided by the authenticator.
|
||||
# This should not contain confidential data, as it can be recorded in logs
|
||||
# or API objects, and is made available to admission webhooks.
|
||||
"extra": {
|
||||
"extrafield1": [
|
||||
"extravalue1",
|
||||
"extravalue2"
|
||||
]
|
||||
}
|
||||
},
|
||||
# Optional list audience-aware token authenticators can return,
|
||||
# containing the audiences from the `spec.audiences` list for which the provided token was valid.
|
||||
# If this is omitted, the token is considered to be valid to authenticate to the Kubernetes API server.
|
||||
"audiences": ["https://myserver.example.com"]
|
||||
}
|
||||
}
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
HTTP status codes can be used to supply additional error context.
|
||||
An unsuccessful request would return:
|
||||
|
||||
{{< tabs name="TokenReview_response_error" >}}
|
||||
{{% tab name="authentication.k8s.io/v1" %}}
|
||||
```yaml
|
||||
{
|
||||
"apiVersion": "authentication.k8s.io/v1",
|
||||
"kind": "TokenReview",
|
||||
"status": {
|
||||
"authenticated": false,
|
||||
# Optionally include details about why authentication failed.
|
||||
# If no error is provided, the API will return a generic Unauthorized message.
|
||||
# The error field is ignored when authenticated=true.
|
||||
"error": "Credentials are expired"
|
||||
}
|
||||
}
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="authentication.k8s.io/v1beta1" %}}
|
||||
```yaml
|
||||
{
|
||||
"apiVersion": "authentication.k8s.io/v1beta1",
|
||||
"kind": "TokenReview",
|
||||
"status": {
|
||||
"authenticated": false,
|
||||
# Optionally include details about why authentication failed.
|
||||
# If no error is provided, the API will return a generic Unauthorized message.
|
||||
# The error field is ignored when authenticated=true.
|
||||
"error": "Credentials are expired"
|
||||
}
|
||||
}
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
### Authenticating Proxy
|
||||
|
||||
|
||||
@@ -52,7 +52,7 @@ Kubernetes reviews only the following API request attributes:
|
||||
* **Resource** - The ID or name of the resource that is being accessed (for resource requests only) -- For resource requests using `get`, `update`, `patch`, and `delete` verbs, you must provide the resource name.
|
||||
* **Subresource** - The subresource that is being accessed (for resource requests only).
|
||||
* **Namespace** - The namespace of the object that is being accessed (for namespaced resource requests only).
|
||||
* **API group** - The {{< glossary_tooltip text="API Group" term_id="api-group" >}} being accessed (for resource requests only). An empty string designates the [core API group](/docs/concepts/overview/kubernetes-api/).
|
||||
* **API group** - The {{< glossary_tooltip text="API Group" term_id="api-group" >}} being accessed (for resource requests only). An empty string designates the [core API group](/docs/reference/using-api/api-overview/#api-groups).
|
||||
|
||||
## Determine the Request Verb
|
||||
|
||||
|
||||
@@ -1,18 +0,0 @@
|
||||
---
|
||||
title: rkt
|
||||
id: rkt
|
||||
date: 2019-01-24
|
||||
full_link: https://coreos.com/rkt/
|
||||
short_description: >
|
||||
A security-minded, standards-based container engine.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- security
|
||||
- tool
|
||||
---
|
||||
A security-minded, standards-based container engine.
|
||||
|
||||
<!--more-->
|
||||
|
||||
rkt is an application {{< glossary_tooltip text="container" term_id="container" >}} engine featuring a {{< glossary_tooltip text="Pod" term_id="pod" >}}-native approach, a pluggable execution environment, and a well-defined surface area. rkt allows users to apply different configurations at both the Pod and application level. Each Pod executes directly in the classic Unix process model, in a self-contained, isolated environment.
|
||||
@@ -20,10 +20,7 @@ by implementing one or more of these extension points.
|
||||
|
||||
You can specify scheduling profiles by running `kube-scheduler --config <filename>`,
|
||||
using the component config APIs
|
||||
([`v1alpha1`](https://pkg.go.dev/k8s.io/kube-scheduler@v0.18.0/config/v1alpha1?tab=doc#KubeSchedulerConfiguration)
|
||||
or [`v1alpha2`](https://pkg.go.dev/k8s.io/kube-scheduler@v0.18.0/config/v1alpha2?tab=doc#KubeSchedulerConfiguration)).
|
||||
The `v1alpha2` API allows you to configure kube-scheduler to run
|
||||
[multiple profiles](#multiple-profiles).
|
||||
([`v1beta1`](https://pkg.go.dev/k8s.io/kube-scheduler@v0.19.0/config/v1beta1?tab=doc#KubeSchedulerConfiguration)).
|
||||
|
||||
A minimal configuration looks as follows:
|
||||
|
||||
|
||||
@@ -12,6 +12,14 @@ weight: 90
|
||||
from the community. Please try it out and give us feedback!
|
||||
{{< /caution >}}
|
||||
|
||||
## kubeadm alpha certs {#cmd-certs}
|
||||
|
||||
A collection of operations for operating Kubernetes certificates.
|
||||
|
||||
{{< tabs name="tab-certs" >}}
|
||||
{{< tab name="overview" include="generated/kubeadm_alpha_certs.md" />}}
|
||||
{{< /tabs >}}
|
||||
|
||||
## kubeadm alpha certs renew {#cmd-certs-renew}
|
||||
|
||||
You can renew all Kubernetes certificates using the `all` subcommand or renew them selectively.
|
||||
@@ -42,6 +50,15 @@ to enable the automatic copy of certificates when joining additional control-pla
|
||||
{{< tab name="certificate-key" include="generated/kubeadm_alpha_certs_certificate-key.md" />}}
|
||||
{{< /tabs >}}
|
||||
|
||||
## kubeadm alpha certs generate-csr {#cmd-certs-generate-csr}
|
||||
|
||||
This command can be used to generate certificate signing requests (CSRs) which
|
||||
can be submitted to a certificate authority (CA) for signing.
|
||||
|
||||
{{< tabs name="tab-certs-generate-csr" >}}
|
||||
{{< tab name="certificate-generate-csr" include="generated/kubeadm_alpha_certs_generate-csr.md" />}}
|
||||
{{< /tabs >}}
|
||||
|
||||
## kubeadm alpha certs check-expiration {#cmd-certs-check-expiration}
|
||||
|
||||
This command checks expiration for the certificates in the local PKI managed by kubeadm.
|
||||
|
||||
@@ -16,6 +16,10 @@ You can use `kubeadm config print` to print the default configuration and `kubea
|
||||
convert your old configuration files to a newer version. `kubeadm config images list` and
|
||||
`kubeadm config images pull` can be used to list and pull the images that kubeadm requires.
|
||||
|
||||
For more information navigate to
|
||||
[Using kubeadm init with a configuration file](/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file)
|
||||
or [Using kubeadm join with a configuration file](/docs/reference/setup-tools/kubeadm/kubeadm-join/#config-file).
|
||||
|
||||
In Kubernetes v1.13.0 and later to list/pull kube-dns images instead of the CoreDNS image
|
||||
the `--config` method described [here](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-addon)
|
||||
has to be used.
|
||||
|
||||
@@ -119,6 +119,17 @@ Use the following phase to configure bootstrap tokens.
|
||||
{{< tab name="bootstrap-token" include="generated/kubeadm_init_phase_bootstrap-token.md" />}}
|
||||
{{< /tabs >}}
|
||||
|
||||
## kubeadm init phase kubelet-finialize {#cmd-phase-kubelet-finalize-all}
|
||||
|
||||
Use the following phase to update settings relevant to the kubelet after TLS
|
||||
bootstrap. You can use the `all` subcommand to run all `kubelet-finalize`
|
||||
phases.
|
||||
|
||||
{{< tabs name="tab-kubelet-finalize" >}}
|
||||
{{< tab name="kublet-finalize" include="generated/kubeadm_init_phase_kubelet-finalize.md" />}}
|
||||
{{< tab name="kublet-finalize-all" include="generated/kubeadm_init_phase_kubelet-finalize_all.md" />}}
|
||||
{{< tab name="kublet-finalize-cert-rotation" include="generated/kubeadm_init_phase_kubelet-finalize_experimental-cert-rotation.md" />}}
|
||||
{{< /tabs >}}
|
||||
|
||||
## kubeadm init phase addon {#cmd-phase-addon}
|
||||
|
||||
|
||||
@@ -114,16 +114,18 @@ The config file is still considered beta and may change in future versions.
|
||||
|
||||
It's possible to configure `kubeadm init` with a configuration file instead of command
|
||||
line flags, and some more advanced features may only be available as
|
||||
configuration file options. This file is passed with the `--config` option.
|
||||
configuration file options. This file is passed using the `--config` flag and it must
|
||||
contain a `ClusterConfiguration` structure and optionally more structures separated by `---\n`
|
||||
Mixing `--config` with others flags may not be allowed in some cases.
|
||||
|
||||
The default configuration can be printed out using the
|
||||
[kubeadm config print](/docs/reference/setup-tools/kubeadm/kubeadm-config/) command.
|
||||
|
||||
It is **recommended** that you migrate your old `v1beta1` configuration to `v1beta2` using
|
||||
If your configuration is not using the latest version it is **recommended** that you migrate using
|
||||
the [kubeadm config migrate](/docs/reference/setup-tools/kubeadm/kubeadm-config/) command.
|
||||
|
||||
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).
|
||||
For more information on the fields and usage of the configuration you can navigate to our API reference
|
||||
page and pick a version from [the list](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#pkg-subdirectories).
|
||||
|
||||
### Adding kube-proxy parameters {#kube-proxy}
|
||||
|
||||
|
||||
@@ -273,15 +273,17 @@ The config file is still considered beta and may change in future versions.
|
||||
It's possible to configure `kubeadm join` with a configuration file instead of command
|
||||
line flags, and some more advanced features may only be available as
|
||||
configuration file options. This file is passed using the `--config` flag and it must
|
||||
contain a `JoinConfiguration` structure.
|
||||
contain a `JoinConfiguration` structure. Mixing `--config` with others flags may not be
|
||||
allowed in some cases.
|
||||
|
||||
To print the default values of `JoinConfiguration` run the following command:
|
||||
The default configuration can be printed out using the
|
||||
[kubeadm config print](/docs/reference/setup-tools/kubeadm/kubeadm-config/) command.
|
||||
|
||||
```shell
|
||||
kubeadm config print join-defaults
|
||||
```
|
||||
If your configuration is not using the latest version it is **recommended** that you migrate using
|
||||
the [kubeadm config migrate](/docs/reference/setup-tools/kubeadm/kubeadm-config/) command.
|
||||
|
||||
For details on individual fields in `JoinConfiguration` see [the godoc](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#JoinConfiguration).
|
||||
For more information on the fields and usage of the configuration you can navigate to our API reference
|
||||
page and pick a version from [the list](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#pkg-subdirectories).
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
@@ -15,6 +15,7 @@ be called on a primary control-plane node.
|
||||
|
||||
{{< tabs name="tab-phase" >}}
|
||||
{{< tab name="phase" include="generated/kubeadm_upgrade_node_phase.md" />}}
|
||||
{{< tab name="preflight" include="generated/kubeadm_upgrade_node_phase_preflight.md" />}}
|
||||
{{< tab name="control-plane" include="generated/kubeadm_upgrade_node_phase_control-plane.md" />}}
|
||||
{{< tab name="kubelet-config" include="generated/kubeadm_upgrade_node_phase_kubelet-config.md" />}}
|
||||
{{< /tabs >}}
|
||||
|
||||
@@ -4,401 +4,141 @@ reviewers:
|
||||
- justinsb
|
||||
- quinton-hoole
|
||||
title: Running in multiple zones
|
||||
weight: 10
|
||||
weight: 20
|
||||
content_type: concept
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
This page describes how to run a cluster in multiple zones.
|
||||
|
||||
|
||||
This page describes running Kubernetes across multiple zones.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Introduction
|
||||
## Background
|
||||
|
||||
Kubernetes 1.2 adds support for running a single cluster in multiple failure zones
|
||||
(GCE calls them simply "zones", AWS calls them "availability zones", here we'll refer to them as "zones").
|
||||
This is a lightweight version of a broader Cluster Federation feature (previously referred to by the affectionate
|
||||
nickname ["Ubernetes"](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/multicluster/federation.md)).
|
||||
Full Cluster Federation allows combining separate
|
||||
Kubernetes clusters running in different regions or cloud providers
|
||||
(or on-premises data centers). However, many
|
||||
users simply want to run a more available Kubernetes cluster in multiple zones
|
||||
of their single cloud provider, and this is what the multizone support in 1.2 allows
|
||||
(this previously went by the nickname "Ubernetes Lite").
|
||||
Kubernetes is designed so that a single Kubernetes cluster can run
|
||||
across multiple failure zones, typically where these zones fit within
|
||||
a logical grouping called a _region_. Major cloud providers define a region
|
||||
as a set of failure zones (also called _availability zones_) that provide
|
||||
a consistent set of features: within a region, each zone offers the same
|
||||
APIs and services.
|
||||
|
||||
Multizone support is deliberately limited: a single Kubernetes cluster can run
|
||||
in multiple zones, but only within the same region (and cloud provider). Only
|
||||
GCE and AWS are currently supported automatically (though it is easy to
|
||||
add similar support for other clouds or even bare metal, by simply arranging
|
||||
for the appropriate labels to be added to nodes and volumes).
|
||||
Typical cloud architectures aim to minimize the chance that a failure in
|
||||
one zone also impairs services in another zone.
|
||||
|
||||
## Control plane behavior
|
||||
|
||||
## Functionality
|
||||
All [control plane components](/docs/concepts/overview/components/#control-plane-components)
|
||||
support running as a pool of interchangable resources, replicated per
|
||||
component.
|
||||
|
||||
When nodes are started, the kubelet automatically adds labels to them with
|
||||
zone information.
|
||||
|
||||
Kubernetes will automatically spread the pods in a replication controller
|
||||
or service across nodes in a single-zone cluster (to reduce the impact of
|
||||
failures.) With multiple-zone clusters, this spreading behavior is
|
||||
extended across zones (to reduce the impact of zone failures.) (This is
|
||||
achieved via `SelectorSpreadPriority`). This is a best-effort
|
||||
placement, and so if the zones in your cluster are heterogeneous
|
||||
(e.g. different numbers of nodes, different types of nodes, or
|
||||
different pod resource requirements), this might prevent perfectly
|
||||
even spreading of your pods across zones. If desired, you can use
|
||||
homogeneous zones (same number and types of nodes) to reduce the
|
||||
probability of unequal spreading.
|
||||
|
||||
When persistent volumes are created, the `PersistentVolumeLabel`
|
||||
admission controller automatically adds zone labels to them. The scheduler (via the
|
||||
`VolumeZonePredicate` predicate) will then ensure that pods that claim a
|
||||
given volume are only placed into the same zone as that volume, as volumes
|
||||
cannot be attached across zones.
|
||||
|
||||
## Limitations
|
||||
|
||||
There are some important limitations of the multizone support:
|
||||
|
||||
* We assume that the different zones are located close to each other in the
|
||||
network, so we don't perform any zone-aware routing. In particular, traffic
|
||||
that goes via services might cross zones (even if some pods backing that service
|
||||
exist in the same zone as the client), and this may incur additional latency and cost.
|
||||
|
||||
* Volume zone-affinity will only work with a `PersistentVolume`, and will not
|
||||
work if you directly specify an EBS volume in the pod spec (for example).
|
||||
|
||||
* Clusters cannot span clouds or regions (this functionality will require full
|
||||
federation support).
|
||||
|
||||
* Although your nodes are in multiple zones, kube-up currently builds
|
||||
a single master node by default. While services are highly
|
||||
available and can tolerate the loss of a zone, the control plane is
|
||||
located in a single zone. Users that want a highly available control
|
||||
plane should follow the [high availability](/docs/setup/production-environment/tools/kubeadm/high-availability/) instructions.
|
||||
|
||||
### Volume limitations
|
||||
The following limitations are addressed with [topology-aware volume binding](/docs/concepts/storage/storage-classes/#volume-binding-mode).
|
||||
|
||||
* StatefulSet volume zone spreading when using dynamic provisioning is currently not compatible with
|
||||
pod affinity or anti-affinity policies.
|
||||
|
||||
* If the name of the StatefulSet contains dashes ("-"), volume zone spreading
|
||||
may not provide a uniform distribution of storage across zones.
|
||||
|
||||
* When specifying multiple PVCs in a Deployment or Pod spec, the StorageClass
|
||||
needs to be configured for a specific single zone, or the PVs need to be
|
||||
statically provisioned in a specific zone. Another workaround is to use a
|
||||
StatefulSet, which will ensure that all the volumes for a replica are
|
||||
provisioned in the same zone.
|
||||
|
||||
## Walkthrough
|
||||
|
||||
We're now going to walk through setting up and using a multi-zone
|
||||
cluster on both GCE & AWS. To do so, you bring up a full cluster
|
||||
(specifying `MULTIZONE=true`), and then you add nodes in additional zones
|
||||
by running `kube-up` again (specifying `KUBE_USE_EXISTING_MASTER=true`).
|
||||
|
||||
### Bringing up your cluster
|
||||
|
||||
Create the cluster as normal, but pass MULTIZONE to tell the cluster to manage multiple zones; creating nodes in us-central1-a.
|
||||
|
||||
GCE:
|
||||
|
||||
```shell
|
||||
curl -sS https://get.k8s.io | MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-a NUM_NODES=3 bash
|
||||
```
|
||||
|
||||
AWS:
|
||||
|
||||
```shell
|
||||
curl -sS https://get.k8s.io | MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a NUM_NODES=3 bash
|
||||
```
|
||||
|
||||
This step brings up a cluster as normal, still running in a single zone
|
||||
(but `MULTIZONE=true` has enabled multi-zone capabilities).
|
||||
|
||||
### Nodes are labeled
|
||||
|
||||
View the nodes; you can see that they are labeled with zone information.
|
||||
They are all in `us-central1-a` (GCE) or `us-west-2a` (AWS) so far. The
|
||||
labels are `failure-domain.beta.kubernetes.io/region` for the region,
|
||||
and `failure-domain.beta.kubernetes.io/zone` for the zone:
|
||||
|
||||
```shell
|
||||
kubectl get nodes --show-labels
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```shell
|
||||
NAME STATUS ROLES AGE VERSION LABELS
|
||||
kubernetes-master Ready,SchedulingDisabled <none> 6m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-1,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master
|
||||
kubernetes-minion-87j9 Ready <none> 6m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9
|
||||
kubernetes-minion-9vlv Ready <none> 6m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
|
||||
kubernetes-minion-a12q Ready <none> 6m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q
|
||||
```
|
||||
|
||||
### Add more nodes in a second zone
|
||||
|
||||
Let's add another set of nodes to the existing cluster, reusing the
|
||||
existing master, running in a different zone (us-central1-b or us-west-2b).
|
||||
We run kube-up again, but by specifying `KUBE_USE_EXISTING_MASTER=true`
|
||||
kube-up will not create a new master, but will reuse one that was previously
|
||||
created instead.
|
||||
|
||||
GCE:
|
||||
|
||||
```shell
|
||||
KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-b NUM_NODES=3 kubernetes/cluster/kube-up.sh
|
||||
```
|
||||
|
||||
On AWS we also need to specify the network CIDR for the additional
|
||||
subnet, along with the master internal IP address:
|
||||
|
||||
```shell
|
||||
KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2b NUM_NODES=3 KUBE_SUBNET_CIDR=172.20.1.0/24 MASTER_INTERNAL_IP=172.20.0.9 kubernetes/cluster/kube-up.sh
|
||||
```
|
||||
|
||||
|
||||
View the nodes again; 3 more nodes should have launched and be tagged
|
||||
in us-central1-b:
|
||||
|
||||
```shell
|
||||
kubectl get nodes --show-labels
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```shell
|
||||
NAME STATUS ROLES AGE VERSION LABELS
|
||||
kubernetes-master Ready,SchedulingDisabled <none> 16m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-1,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master
|
||||
kubernetes-minion-281d Ready <none> 2m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d
|
||||
kubernetes-minion-87j9 Ready <none> 16m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9
|
||||
kubernetes-minion-9vlv Ready <none> 16m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
|
||||
kubernetes-minion-a12q Ready <none> 17m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q
|
||||
kubernetes-minion-pp2f Ready <none> 2m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-pp2f
|
||||
kubernetes-minion-wf8i Ready <none> 2m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-wf8i
|
||||
```
|
||||
|
||||
### Volume affinity
|
||||
|
||||
Create a volume using the dynamic volume creation (only PersistentVolumes are supported for zone affinity):
|
||||
|
||||
```bash
|
||||
kubectl apply -f - <<EOF
|
||||
{
|
||||
"apiVersion": "v1",
|
||||
"kind": "PersistentVolumeClaim",
|
||||
"metadata": {
|
||||
"name": "claim1",
|
||||
"annotations": {
|
||||
"volume.alpha.kubernetes.io/storage-class": "foo"
|
||||
}
|
||||
},
|
||||
"spec": {
|
||||
"accessModes": [
|
||||
"ReadWriteOnce"
|
||||
],
|
||||
"resources": {
|
||||
"requests": {
|
||||
"storage": "5Gi"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
EOF
|
||||
```
|
||||
When you deploy a cluster control plane, place replicas of
|
||||
control plane components across multple failure zones. If availability is
|
||||
an important concern, select at least three failure zones and replicate
|
||||
each individual control plane component (API server, scheduler, etcd,
|
||||
cluster controller manager) across at least three failure zones.
|
||||
If you are running a cloud controller manager then you should
|
||||
also replicate this across all the failure zones you selected.
|
||||
|
||||
{{< note >}}
|
||||
For version 1.3+ Kubernetes will distribute dynamic PV claims across
|
||||
the configured zones. For version 1.2, dynamic persistent volumes were
|
||||
always created in the zone of the cluster master
|
||||
(here us-central1-a / us-west-2a); that issue
|
||||
([#23330](https://github.com/kubernetes/kubernetes/issues/23330))
|
||||
was addressed in 1.3+.
|
||||
Kubernetes does not provide cross-zone resilience for the API server
|
||||
endpoints. You can use various techniques to improve availability for
|
||||
the cluster API server, including DNS round-robin, SRV records, or
|
||||
a third-party load balancing solution with health checking.
|
||||
{{< /note >}}
|
||||
|
||||
Now let's validate that Kubernetes automatically labeled the zone & region the PV was created in.
|
||||
## Node behavior
|
||||
|
||||
```shell
|
||||
kubectl get pv --show-labels
|
||||
```
|
||||
Kubernetes automatically spreads the Pods for
|
||||
workload resources (such as {{< glossary_tooltip text="Deployment" term_id="deployment" >}}
|
||||
or {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}})
|
||||
across different nodes in a cluster. This spreading helps
|
||||
reduce the impact of failures.
|
||||
|
||||
The output is similar to this:
|
||||
When nodes start up, the kubelet on each node automatically adds
|
||||
{{< glossary_tooltip text="labels" term_id="label" >}} to the Node object
|
||||
that represents that specific kubelet in the Kubernetes API.
|
||||
These labels can include
|
||||
[zone information](/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone).
|
||||
|
||||
```shell
|
||||
NAME CAPACITY ACCESSMODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE LABELS
|
||||
pv-gce-mj4gm 5Gi RWO Retain Bound default/claim1 manual 46s failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a
|
||||
```
|
||||
If your cluster spans multiple zones or regions, you can use node labels
|
||||
in conjunction with
|
||||
[Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
|
||||
to control how Pods are spread across your cluster among fault domains:
|
||||
regions, zones, and even specific nodes.
|
||||
These hints enable the
|
||||
{{< glossary_tooltip text="scheduler" term_id="kube-scheduler" >}} to place
|
||||
Pods for better expected availability, reducing the risk that a correlated
|
||||
failure affects your whole workload.
|
||||
|
||||
So now we will create a pod that uses the persistent volume claim.
|
||||
Because GCE PDs / AWS EBS volumes cannot be attached across zones,
|
||||
this means that this pod can only be created in the same zone as the volume:
|
||||
For example, you can set a constraint to make sure that the
|
||||
3 replicas of a StatefulSet are all running in different zones to each
|
||||
other, whenever that is feasible. You can define this declaratively
|
||||
without explicitly defining which availability zones are in use for
|
||||
each workload.
|
||||
|
||||
```yaml
|
||||
kubectl apply -f - <<EOF
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: mypod
|
||||
spec:
|
||||
containers:
|
||||
- name: myfrontend
|
||||
image: nginx
|
||||
volumeMounts:
|
||||
- mountPath: "/var/www/html"
|
||||
name: mypd
|
||||
volumes:
|
||||
- name: mypd
|
||||
persistentVolumeClaim:
|
||||
claimName: claim1
|
||||
EOF
|
||||
```
|
||||
### Distributing nodes across zones
|
||||
|
||||
Note that the pod was automatically created in the same zone as the volume, as
|
||||
cross-zone attachments are not generally permitted by cloud providers:
|
||||
Kubernetes' core does not create nodes for you; you need to do that yourself,
|
||||
or use a tool such as the [Cluster API](https://cluster-api.sigs.k8s.io/) to
|
||||
manage nodes on your behalf.
|
||||
|
||||
```shell
|
||||
kubectl describe pod mypod | grep Node
|
||||
```
|
||||
Using tools such as the Cluster API you can define sets of machines to run as
|
||||
worker nodes for your cluster across multiple failure domains, and rules to
|
||||
automatically heal the cluster in case of whole-zone service disruption.
|
||||
|
||||
```shell
|
||||
Node: kubernetes-minion-9vlv/10.240.0.5
|
||||
```
|
||||
## Manual zone assignment for Pods
|
||||
|
||||
And check node labels:
|
||||
You can apply [node selector constraints](/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector)
|
||||
to Pods that you create, as well as to Pod templates in workload resources
|
||||
such as Deployment, StatefulSet, or Job.
|
||||
|
||||
```shell
|
||||
kubectl get node kubernetes-minion-9vlv --show-labels
|
||||
```
|
||||
## Storage access for zones
|
||||
|
||||
```shell
|
||||
NAME STATUS AGE VERSION LABELS
|
||||
kubernetes-minion-9vlv Ready 22m v1.6.0+fff5156 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
|
||||
```
|
||||
When persistent volumes are created, the `PersistentVolumeLabel`
|
||||
[admission controller](/docs/reference/access-authn-authz/admission-controllers/)
|
||||
automatically adds zone labels to any PersistentVolumes that are linked to a specific
|
||||
zone. The {{< glossary_tooltip text="scheduler" term_id="kube-scheduler" >}} then ensures,
|
||||
through its `NoVolumeZoneConflict` predicate, that pods which claim a given PersistentVolume
|
||||
are only placed into the same zone as that volume.
|
||||
|
||||
### Pods are spread across zones
|
||||
You can specify a {{< glossary_tooltip text="StorageClass" term_id="storage-class" >}}
|
||||
for PersistentVolumeClaims that specifies the failure domains (zones) that the
|
||||
storage in that class may use.
|
||||
To learn about configuring a StorageClass that is aware of failure domains or zones,
|
||||
see [Allowed topologies](/docs/concepts/storage/storage-classes/#allowed-topologies).
|
||||
|
||||
Pods in a replication controller or service are automatically spread
|
||||
across zones. First, let's launch more nodes in a third zone:
|
||||
## Networking
|
||||
|
||||
GCE:
|
||||
By itself, Kubernetes does not include zone-aware networking. You can use a
|
||||
[network plugin](docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
|
||||
to configure cluster networking, and that network solution might have zone-specific
|
||||
elements. For example, if your cloud provider supports Services with
|
||||
`type=LoadBalancer`, the load balancer might only send traffic to Pods running in the
|
||||
same zone as the load balancer element processing a given connection.
|
||||
Check your cloud provider's documentation for details.
|
||||
|
||||
```shell
|
||||
KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-f NUM_NODES=3 kubernetes/cluster/kube-up.sh
|
||||
```
|
||||
For custom or on-premises deployments, similar considerations apply.
|
||||
{{< glossary_tooltip text="Service" term_id="service" >}} and
|
||||
{{< glossary_tooltip text="Ingress" term_id="ingress" >}} behavior, including handling
|
||||
of different failure zones, does vary depending on exactly how your cluster is set up.
|
||||
|
||||
AWS:
|
||||
## Fault recovery
|
||||
|
||||
```shell
|
||||
KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2c NUM_NODES=3 KUBE_SUBNET_CIDR=172.20.2.0/24 MASTER_INTERNAL_IP=172.20.0.9 kubernetes/cluster/kube-up.sh
|
||||
```
|
||||
When you set up your cluster, you might also need to consider whether and how
|
||||
your setup can restore service if all of the failure zones in a region go
|
||||
off-line at the same time. For example, do you rely on there being at least
|
||||
one node able to run Pods in a zone?
|
||||
Make sure that any cluster-critical repair work does not rely
|
||||
on there being at least one healthy node in your cluster. For example: if all nodes
|
||||
are unhealthy, you might need to run a repair Job with a special
|
||||
{{< glossary_tooltip text="toleration" term_id="toleration" >}} so that the repair
|
||||
can complete enough to bring at least one node into service.
|
||||
|
||||
Verify that you now have nodes in 3 zones:
|
||||
|
||||
```shell
|
||||
kubectl get nodes --show-labels
|
||||
```
|
||||
|
||||
Create the guestbook-go example, which includes an RC of size 3, running a simple web app:
|
||||
|
||||
```shell
|
||||
find kubernetes/examples/guestbook-go/ -name '*.json' | xargs -I {} kubectl apply -f {}
|
||||
```
|
||||
|
||||
The pods should be spread across all 3 zones:
|
||||
|
||||
```shell
|
||||
kubectl describe pod -l app=guestbook | grep Node
|
||||
```
|
||||
|
||||
```shell
|
||||
Node: kubernetes-minion-9vlv/10.240.0.5
|
||||
Node: kubernetes-minion-281d/10.240.0.8
|
||||
Node: kubernetes-minion-olsh/10.240.0.11
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl get node kubernetes-minion-9vlv kubernetes-minion-281d kubernetes-minion-olsh --show-labels
|
||||
```
|
||||
|
||||
```shell
|
||||
NAME STATUS ROLES AGE VERSION LABELS
|
||||
kubernetes-minion-9vlv Ready <none> 34m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
|
||||
kubernetes-minion-281d Ready <none> 20m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d
|
||||
kubernetes-minion-olsh Ready <none> 3m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-f,kubernetes.io/hostname=kubernetes-minion-olsh
|
||||
```
|
||||
|
||||
|
||||
Load-balancers span all zones in a cluster; the guestbook-go example
|
||||
includes an example load-balanced service:
|
||||
|
||||
```shell
|
||||
kubectl describe service guestbook | grep LoadBalancer.Ingress
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```shell
|
||||
LoadBalancer Ingress: 130.211.126.21
|
||||
```
|
||||
|
||||
Set the above IP:
|
||||
|
||||
```shell
|
||||
export IP=130.211.126.21
|
||||
```
|
||||
|
||||
Explore with curl via IP:
|
||||
|
||||
```shell
|
||||
curl -s http://${IP}:3000/env | grep HOSTNAME
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```shell
|
||||
"HOSTNAME": "guestbook-44sep",
|
||||
```
|
||||
|
||||
Again, explore multiple times:
|
||||
|
||||
```shell
|
||||
(for i in `seq 20`; do curl -s http://${IP}:3000/env | grep HOSTNAME; done) | sort | uniq
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```shell
|
||||
"HOSTNAME": "guestbook-44sep",
|
||||
"HOSTNAME": "guestbook-hum5n",
|
||||
"HOSTNAME": "guestbook-ppm40",
|
||||
```
|
||||
|
||||
The load balancer correctly targets all the pods, even though they are in multiple zones.
|
||||
|
||||
### Shutting down the cluster
|
||||
|
||||
When you're done, clean up:
|
||||
|
||||
GCE:
|
||||
|
||||
```shell
|
||||
KUBERNETES_PROVIDER=gce KUBE_USE_EXISTING_MASTER=true KUBE_GCE_ZONE=us-central1-f kubernetes/cluster/kube-down.sh
|
||||
KUBERNETES_PROVIDER=gce KUBE_USE_EXISTING_MASTER=true KUBE_GCE_ZONE=us-central1-b kubernetes/cluster/kube-down.sh
|
||||
KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-a kubernetes/cluster/kube-down.sh
|
||||
```
|
||||
|
||||
AWS:
|
||||
|
||||
```shell
|
||||
KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2c kubernetes/cluster/kube-down.sh
|
||||
KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2b kubernetes/cluster/kube-down.sh
|
||||
KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a kubernetes/cluster/kube-down.sh
|
||||
```
|
||||
Kubernetes doesn't come with an answer for this challenge; however, it's
|
||||
something to consider.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
To learn how the scheduler places Pods in a cluster, honoring the configured constraints,
|
||||
visit [Scheduling and Eviction](/docs/concepts/scheduling-eviction/).
|
||||
|
||||
+1
-1
@@ -139,7 +139,7 @@ is not supported by kubeadm.
|
||||
|
||||
For more information about `kubeadm init` arguments, see the [kubeadm reference guide](/docs/reference/setup-tools/kubeadm/kubeadm/).
|
||||
|
||||
For a complete list of configuration options, see the [configuration file documentation](/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file).
|
||||
To configure `kubeadm init` with a configuration file see [Using kubeadm init with a configuration file](/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file).
|
||||
|
||||
To customize control plane components, including optional IPv6 assignment to liveness probe for control plane components and etcd server, provide extra arguments to each component as documented in [custom arguments](/docs/setup/production-environment/tools/kubeadm/control-plane-flags/).
|
||||
|
||||
|
||||
@@ -132,31 +132,12 @@ The following file is an Ingress resource that sends traffic to your Service via
|
||||
|
||||
1. Create `example-ingress.yaml` from the following file:
|
||||
|
||||
```yaml
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: Ingress
|
||||
metadata:
|
||||
name: example-ingress
|
||||
annotations:
|
||||
nginx.ingress.kubernetes.io/rewrite-target: /$1
|
||||
spec:
|
||||
rules:
|
||||
- host: hello-world.info
|
||||
http:
|
||||
paths:
|
||||
- path: /
|
||||
pathType: Prefix
|
||||
backend:
|
||||
service:
|
||||
name: web
|
||||
port:
|
||||
number: 8080
|
||||
```
|
||||
{{< codenew file="service/networking/example-ingress.yaml" >}}
|
||||
|
||||
1. Create the Ingress resource by running the following command:
|
||||
|
||||
```shell
|
||||
kubectl apply -f example-ingress.yaml
|
||||
kubectl apply -f https://k8s.io/examples/service/networking/example-ingress.yaml
|
||||
```
|
||||
|
||||
Output:
|
||||
|
||||
+1
-1
@@ -152,7 +152,7 @@ for database debugging.
|
||||
or
|
||||
|
||||
```shell
|
||||
kubectl port-forward service/redis-master 7000:6379
|
||||
kubectl port-forward service/redis-master 7000:redis
|
||||
```
|
||||
|
||||
Any of the above commands works. The output is similar to this:
|
||||
|
||||
@@ -222,7 +222,7 @@ data:
|
||||
fallthrough in-addr.arpa ip6.arpa
|
||||
}
|
||||
prometheus :9153
|
||||
proxy . /etc/resolv.conf
|
||||
forward . /etc/resolv.conf
|
||||
cache 30
|
||||
loop
|
||||
reload
|
||||
|
||||
@@ -341,4 +341,11 @@ to prevent system OOMs, and promote eviction of workloads so cluster state can r
|
||||
The Pod eviction may evict more Pods than needed due to stats collection timing gap. This can be mitigated by adding
|
||||
the ability to get root container stats on an on-demand basis [(https://github.com/google/cadvisor/issues/1247)](https://github.com/google/cadvisor/issues/1247) in the future.
|
||||
|
||||
### active_file memory is not considered as available memory
|
||||
|
||||
On Linux, the kernel tracks the number of bytes of file-backed memory on active LRU list as the `active_file` statistic. The kubelet treats `active_file` memory areas as not reclaimable. For workloads that make intensive use of block-backed local storage, including ephemeral local storage, kernel-level caches of file and block data means that many recently accessed cache pages are likely to be counted as `active_file`. If enough of these kernel block buffers are on the active LRU list, the kubelet is liable to observe this as high resource use and taint the node as experiencing memory pressure - triggering Pod eviction.
|
||||
|
||||
For more more details, see [https://github.com/kubernetes/kubernetes/issues/43916](https://github.com/kubernetes/kubernetes/issues/43916)
|
||||
|
||||
You can work around that behavior by setting the memory limit and memory request the same for containers likely to perform intensive I/O activity. You will need to estimate or measure an optimal memory limit value for that container.
|
||||
|
||||
|
||||
@@ -39,22 +39,7 @@ the kubelet command line option `--reserved-cpus` to set an
|
||||
|
||||
## Node Allocatable
|
||||
|
||||
```text
|
||||
Node Capacity
|
||||
---------------------------
|
||||
| kube-reserved |
|
||||
|-------------------------|
|
||||
| system-reserved |
|
||||
|-------------------------|
|
||||
| eviction-threshold |
|
||||
|-------------------------|
|
||||
| |
|
||||
| allocatable |
|
||||
| (available for pods) |
|
||||
| |
|
||||
| |
|
||||
---------------------------
|
||||
```
|
||||
|
||||
|
||||
`Allocatable` on a Kubernetes node is defined as the amount of compute resources
|
||||
that are available for pods. The scheduler does not over-subscribe
|
||||
|
||||
@@ -11,7 +11,7 @@ content_type: concept
|
||||
|
||||
{{< feature-state state="beta" for_k8s_version="v1.11" >}}
|
||||
|
||||
Since cloud providers develop and release at a different pace compared to the Kubernetes project, abstracting the provider-specific code to the {{< glossary_tooltip text="`cloud-controller-manager`" term_id="cloud-controller-manager" >}} binary allows cloud vendors to evolve independently from the core Kubernetes code.
|
||||
Since cloud providers develop and release at a different pace compared to the Kubernetes project, abstracting the provider-specific code to the `{{< glossary_tooltip text="cloud-controller-manager" term_id="cloud-controller-manager" >}}` binary allows cloud vendors to evolve independently from the core Kubernetes code.
|
||||
|
||||
The `cloud-controller-manager` can be linked to any cloud provider that satisfies [cloudprovider.Interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go). For backwards compatibility, the [cloud-controller-manager](https://github.com/kubernetes/kubernetes/tree/master/cmd/cloud-controller-manager) provided in the core Kubernetes project uses the same cloud libraries as `kube-controller-manager`. Cloud providers already supported in Kubernetes core are expected to use the in-tree cloud-controller-manager to transition out of Kubernetes core.
|
||||
|
||||
|
||||
@@ -6,23 +6,21 @@ reviewers:
|
||||
- kow3ns
|
||||
title: Safely Drain a Node while Respecting the PodDisruptionBudget
|
||||
content_type: task
|
||||
min-kubernetes-server-version: 1.5
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
This page shows how to safely drain a node, respecting the PodDisruptionBudget you have defined.
|
||||
|
||||
This page shows how to safely drain a {{< glossary_tooltip text="node" term_id="node" >}},
|
||||
respecting the PodDisruptionBudget you have defined.
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
This task assumes that you have met the following prerequisites:
|
||||
|
||||
* You are using Kubernetes release >= 1.5.
|
||||
* Either:
|
||||
{{% version-check %}}
|
||||
This task also assumes that you have met the following prerequisites:
|
||||
1. You do not require your applications to be highly available during the
|
||||
node drain, or
|
||||
1. You have read about the [PodDisruptionBudget concept](/docs/concepts/workloads/pods/disruptions/)
|
||||
and [Configured PodDisruptionBudgets](/docs/tasks/run-application/configure-pdb/) for
|
||||
1. You have read about the [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) concept,
|
||||
and have [configured PodDisruptionBudgets](/docs/tasks/run-application/configure-pdb/) for
|
||||
applications that need them.
|
||||
|
||||
|
||||
@@ -35,10 +33,10 @@ You can use `kubectl drain` to safely evict all of your pods from a
|
||||
node before you perform maintenance on the node (e.g. kernel upgrade,
|
||||
hardware maintenance, etc.). Safe evictions allow the pod's containers
|
||||
to [gracefully terminate](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)
|
||||
and will respect the `PodDisruptionBudgets` you have specified.
|
||||
and will respect the PodDisruptionBudgets you have specified.
|
||||
|
||||
{{< note >}}
|
||||
By default `kubectl drain` will ignore certain system pods on the node
|
||||
By default `kubectl drain` ignores certain system pods on the node
|
||||
that cannot be killed; see
|
||||
the [kubectl drain](/docs/reference/generated/kubectl/kubectl-commands/#drain)
|
||||
documentation for more details.
|
||||
@@ -78,29 +76,29 @@ The `kubectl drain` command should only be issued to a single node at a
|
||||
time. However, you can run multiple `kubectl drain` commands for
|
||||
different nodes in parallel, in different terminals or in the
|
||||
background. Multiple drain commands running concurrently will still
|
||||
respect the `PodDisruptionBudget` you specify.
|
||||
respect the PodDisruptionBudget you specify.
|
||||
|
||||
For example, if you have a StatefulSet with three replicas and have
|
||||
set a `PodDisruptionBudget` for that set specifying `minAvailable:
|
||||
2`. `kubectl drain` will only evict a pod from the StatefulSet if all
|
||||
three pods are ready, and if you issue multiple drain commands in
|
||||
parallel, Kubernetes will respect the PodDisruptionBudget and ensure
|
||||
that only one pod is unavailable at any given time. Any drains that
|
||||
would cause the number of ready replicas to fall below the specified
|
||||
budget are blocked.
|
||||
set a PodDisruptionBudget for that set specifying `minAvailable: 2`,
|
||||
`kubectl drain` only evicts a pod from the StatefulSet if all three
|
||||
replicas pods are ready; if then you issue multiple drain commands in
|
||||
parallel, Kubernetes respects the PodDisruptionBudget and ensure
|
||||
that only 1 (calculated as `replicas - minAvailable`) Pod is unavailable
|
||||
at any given time. Any drains that would cause the number of ready
|
||||
replicas to fall below the specified budget are blocked.
|
||||
|
||||
## The Eviction API
|
||||
## The Eviction API {#eviction-api}
|
||||
|
||||
If you prefer not to use [kubectl drain](/docs/reference/generated/kubectl/kubectl-commands/#drain) (such as
|
||||
to avoid calling to an external command, or to get finer control over the pod
|
||||
eviction process), you can also programmatically cause evictions using the eviction API.
|
||||
|
||||
You should first be familiar with using [Kubernetes language clients](/docs/tasks/administer-cluster/access-cluster-api/#programmatic-access-to-the-api).
|
||||
You should first be familiar with using [Kubernetes language clients](/docs/tasks/administer-cluster/access-cluster-api/#programmatic-access-to-the-api) to access the API.
|
||||
|
||||
The eviction subresource of a
|
||||
pod can be thought of as a kind of policy-controlled DELETE operation on the pod
|
||||
itself. To attempt an eviction (perhaps more REST-precisely, to attempt to
|
||||
*create* an eviction), you POST an attempted operation. Here's an example:
|
||||
Pod can be thought of as a kind of policy-controlled DELETE operation on the Pod
|
||||
itself. To attempt an eviction (more precisely: to attempt to
|
||||
*create* an Eviction), you POST an attempted operation. Here's an example:
|
||||
|
||||
```json
|
||||
{
|
||||
@@ -116,21 +114,19 @@ itself. To attempt an eviction (perhaps more REST-precisely, to attempt to
|
||||
You can attempt an eviction using `curl`:
|
||||
|
||||
```bash
|
||||
curl -v -H 'Content-type: application/json' http://127.0.0.1:8080/api/v1/namespaces/default/pods/quux/eviction -d @eviction.json
|
||||
curl -v -H 'Content-type: application/json' https://your-cluster-api-endpoint.example/api/v1/namespaces/default/pods/quux/eviction -d @eviction.json
|
||||
```
|
||||
|
||||
The API can respond in one of three ways:
|
||||
|
||||
- If the eviction is granted, then the pod is deleted just as if you had sent
|
||||
a `DELETE` request to the pod's URL and you get back `200 OK`.
|
||||
- If the eviction is granted, then the Pod is deleted just as if you had sent
|
||||
a `DELETE` request to the Pod's URL and you get back `200 OK`.
|
||||
- If the current state of affairs wouldn't allow an eviction by the rules set
|
||||
forth in the budget, you get back `429 Too Many Requests`. This is
|
||||
typically used for generic rate limiting of *any* requests, but here we mean
|
||||
that this request isn't allowed *right now* but it may be allowed later.
|
||||
Currently, callers do not get any `Retry-After` advice, but they may in
|
||||
future versions.
|
||||
- If there is some kind of misconfiguration, like multiple budgets pointing at
|
||||
the same pod, you will get `500 Internal Server Error`.
|
||||
- If there is some kind of misconfiguration; for example multiple PodDisruptionBudgets
|
||||
that refer the same Pod, you get a `500 Internal Server Error` response.
|
||||
|
||||
For a given eviction request, there are two cases:
|
||||
|
||||
@@ -139,21 +135,25 @@ For a given eviction request, there are two cases:
|
||||
- There is at least one budget. In this case, any of the three above responses may
|
||||
apply.
|
||||
|
||||
In some cases, an application may reach a broken state where it will never return anything
|
||||
other than 429 or 500. This can happen, for example, if the replacement pod created by the
|
||||
application's controller does not become ready, or if the last pod evicted has a very long
|
||||
termination grace period.
|
||||
## Stuck evictions
|
||||
|
||||
In some cases, an application may reach a broken state, one where unless you intervene the
|
||||
eviction API will never return anything other than 429 or 500.
|
||||
|
||||
For example: this can happen if ReplicaSet is creating Pods for your application but
|
||||
the replacement Pods do not become `Ready`. You can also see similar symptoms if the
|
||||
last Pod evicted has a very long termination grace period.
|
||||
|
||||
In this case, there are two potential solutions:
|
||||
|
||||
- Abort or pause the automated operation. Investigate the reason for the stuck application, and restart the automation.
|
||||
- After a suitably long wait, `DELETE` the pod instead of using the eviction API.
|
||||
- Abort or pause the automated operation. Investigate the reason for the stuck application,
|
||||
and restart the automation.
|
||||
- After a suitably long wait, `DELETE` the Pod from your cluster's control plane, instead
|
||||
of using the eviction API.
|
||||
|
||||
Kubernetes does not specify what the behavior should be in this case; it is up to the
|
||||
application owners and cluster owners to establish an agreement on behavior in these cases.
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
@@ -162,4 +162,3 @@ application owners and cluster owners to establish an agreement on behavior in t
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -222,6 +222,13 @@ Container is automatically assigned the default limit. Cluster administrators ca
|
||||
[LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core/)
|
||||
to specify a default value for the CPU limit.
|
||||
|
||||
## If you specify a CPU limit but do not specify a CPU request
|
||||
|
||||
If you specify a CPU limit for a Container but do not specify a CPU request, Kubernetes automatically
|
||||
assigns a CPU request that matches the limit. Similarly, if a Container specifies its own memory limit,
|
||||
but does not specify a memory request, Kubernetes automatically assigns a memory request that matches
|
||||
the limit.
|
||||
|
||||
## Motivation for CPU requests and limits
|
||||
|
||||
By configuring the CPU requests and limits of the Containers that run in your
|
||||
|
||||
@@ -9,29 +9,29 @@ content_type: concept
|
||||
<!-- overview -->
|
||||
|
||||
Resource usage metrics, such as container CPU and memory usage,
|
||||
are available in Kubernetes through the Metrics API. These metrics can be either accessed directly
|
||||
by user, for example by using `kubectl top` command, or used by a controller in the cluster, e.g.
|
||||
are available in Kubernetes through the Metrics API. These metrics can be accessed either directly
|
||||
by the user with the `kubectl top` command, or by a controller in the cluster, for example
|
||||
Horizontal Pod Autoscaler, to make decisions.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## The Metrics API
|
||||
|
||||
Through the Metrics API you can get the amount of resource currently used
|
||||
Through the Metrics API, you can get the amount of resource currently used
|
||||
by a given node or a given pod. This API doesn't store the metric values,
|
||||
so it's not possible for example to get the amount of resources used by a
|
||||
so it's not possible, for example, to get the amount of resources used by a
|
||||
given node 10 minutes ago.
|
||||
|
||||
The API is no different from any other API:
|
||||
|
||||
- it is discoverable through the same endpoint as the other Kubernetes APIs under `/apis/metrics.k8s.io/` path
|
||||
- it offers the same security, scalability and reliability guarantees
|
||||
- it is discoverable through the same endpoint as the other Kubernetes APIs under the path: `/apis/metrics.k8s.io/`
|
||||
- it offers the same security, scalability, and reliability guarantees
|
||||
|
||||
The API is defined in [k8s.io/metrics](https://github.com/kubernetes/metrics/blob/master/pkg/apis/metrics/v1beta1/types.go)
|
||||
repository. You can find more information about the API there.
|
||||
|
||||
{{< note >}}
|
||||
The API requires metrics server to be deployed in the cluster. Otherwise it will be not available.
|
||||
The API requires the metrics server to be deployed in the cluster. Otherwise it will be not available.
|
||||
{{< /note >}}
|
||||
|
||||
## Measuring Resource Usage
|
||||
@@ -49,22 +49,19 @@ The kubelet chooses the window for the rate calculation.
|
||||
Memory is reported as the working set, in bytes, at the instant the metric was collected.
|
||||
In an ideal world, the "working set" is the amount of memory in-use that cannot be freed under memory pressure.
|
||||
However, calculation of the working set varies by host OS, and generally makes heavy use of heuristics to produce an estimate.
|
||||
It includes all anonymous (non-file-backed) memory since kubernetes does not support swap.
|
||||
It includes all anonymous (non-file-backed) memory since Kubernetes does not support swap.
|
||||
The metric typically also includes some cached (file-backed) memory, because the host OS cannot always reclaim such pages.
|
||||
|
||||
## Metrics Server
|
||||
|
||||
[Metrics Server](https://github.com/kubernetes-incubator/metrics-server) is a cluster-wide aggregator of resource usage data.
|
||||
It is deployed by default in clusters created by `kube-up.sh` script
|
||||
as a Deployment object. If you use a different Kubernetes setup mechanism you can deploy it using the provided
|
||||
By default, it is deployed in clusters created by `kube-up.sh` script
|
||||
as a Deployment object. If you use a different Kubernetes setup mechanism, you can deploy it using the provided
|
||||
[deployment components.yaml](https://github.com/kubernetes-sigs/metrics-server/releases) file.
|
||||
|
||||
Metric server collects metrics from the Summary API, exposed by
|
||||
[Kubelet](/docs/reference/command-line-tools-reference/kubelet/) on each node.
|
||||
|
||||
Metrics Server is registered with the main API server through
|
||||
Metrics Server collects metrics from the Summary API, exposed by
|
||||
[Kubelet](/docs/reference/command-line-tools-reference/kubelet/) on each node, and is registered with the main API server via
|
||||
[Kubernetes aggregator](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/).
|
||||
|
||||
Learn more about the metrics server in
|
||||
[the design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md).
|
||||
|
||||
|
||||
@@ -114,11 +114,7 @@ Now, we will see how the autoscaler reacts to increased load.
|
||||
We will start a container, and send an infinite loop of queries to the php-apache service (please run it in a different terminal):
|
||||
|
||||
```shell
|
||||
kubectl run -it --rm load-generator --image=busybox /bin/sh
|
||||
|
||||
Hit enter for command prompt
|
||||
|
||||
while true; do wget -q -O- http://php-apache; done
|
||||
kubectl run -i --tty load-generator --rm --image=busybox --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done"
|
||||
```
|
||||
|
||||
Within a minute or so, we should see the higher CPU load by executing:
|
||||
|
||||
@@ -319,7 +319,7 @@ For instance if there are 80 replicas and the target has to be scaled down to 10
|
||||
then during the first step 8 replicas will be reduced. In the next iteration when the number
|
||||
of replicas is 72, 10% of the pods is 7.2 but the number is rounded up to 8. On each loop of
|
||||
the autoscaler controller the number of pods to be change is re-calculated based on the number
|
||||
of current replicas. When the number of replicas falls below 40 the first policy_(Pods)_ is applied
|
||||
of current replicas. When the number of replicas falls below 40 the first policy _(Pods)_ is applied
|
||||
and 4 replicas will be reduced at a time.
|
||||
|
||||
`periodSeconds` indicates the length of time in the past for which the policy must hold true.
|
||||
@@ -328,7 +328,7 @@ allows at most 10% of the current replicas to be scaled down in one minute.
|
||||
|
||||
The policy selection can be changed by specifying the `selectPolicy` field for a scaling
|
||||
direction. By setting the value to `Min` which would select the policy which allows the
|
||||
smallest change in the replica count. Setting the value to `Disabled` completely disabled
|
||||
smallest change in the replica count. Setting the value to `Disabled` completely disables
|
||||
scaling in that direction.
|
||||
|
||||
### Stabilization Window
|
||||
@@ -405,8 +405,9 @@ behavior:
|
||||
periodSeconds: 60
|
||||
```
|
||||
|
||||
To allow a final drop of 5 pods, another policy can be added with a selection
|
||||
strategy of maximum:
|
||||
To ensure that no more than 5 Pods are removed per minute, you can add a second scale-down
|
||||
policy with a fixed size of 5, and set `selectPolicy` to minimum. Setting `selectPolicy` to `Min` means
|
||||
that the autoscaler chooses the policy that affects the smallest number of Pods:
|
||||
|
||||
```yaml
|
||||
behavior:
|
||||
@@ -418,7 +419,7 @@ behavior:
|
||||
- type: Pods
|
||||
value: 5
|
||||
periodSeconds: 60
|
||||
selectPolicy: Max
|
||||
selectPolicy: Min
|
||||
```
|
||||
|
||||
### Example: disable scale down
|
||||
@@ -441,4 +442,3 @@ behavior:
|
||||
* kubectl autoscale command: [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale).
|
||||
* Usage example of [Horizontal Pod Autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/).
|
||||
|
||||
|
||||
|
||||
@@ -76,11 +76,16 @@ cat <<EOF | cfssl genkey - | cfssljson -bare server
|
||||
"192.0.2.24",
|
||||
"10.0.34.2"
|
||||
],
|
||||
"CN": "my-pod.my-namespace.pod.cluster.local",
|
||||
"CN": "system:node:my-pod.my-namespace.pod.cluster.local",
|
||||
"key": {
|
||||
"algo": "ecdsa",
|
||||
"size": 256
|
||||
}
|
||||
},
|
||||
"names": [
|
||||
{
|
||||
"O": "system:nodes"
|
||||
}
|
||||
]
|
||||
}
|
||||
EOF
|
||||
```
|
||||
|
||||
@@ -8,34 +8,42 @@ no_list: true
|
||||
## kubectl
|
||||
|
||||
The Kubernetes command-line tool, `kubectl`, allows you to run commands against
|
||||
Kubernetes clusters. You can use kubectl to deploy applications, inspect and manage
|
||||
cluster resources, and view logs.
|
||||
Kubernetes clusters. You can use `kubectl` to deploy applications, inspect and
|
||||
manage cluster resources, and view logs.
|
||||
|
||||
See [Install and Set Up kubectl](/docs/tasks/tools/install-kubectl/) for information about how to
|
||||
download and install `kubectl` and set it up for accessing your cluster.
|
||||
See [Install and Set Up `kubectl`](/docs/tasks/tools/install-kubectl/) for
|
||||
information about how to download and install `kubectl` and set it up for
|
||||
accessing your cluster.
|
||||
|
||||
You can also read the [`kubectl` reference documentation](/docs/reference/kubectl/).
|
||||
<a class="btn btn-primary" href="/docs/tasks/tools/install-kubectl/" role="button" aria-label="View kubectl Install and Set Up Guide">View kubectl Install and Set Up Guide</a>
|
||||
|
||||
## Minikube
|
||||
You can also read the
|
||||
[`kubectl` reference documentation](/docs/reference/kubectl/).
|
||||
|
||||
[Minikube](https://minikube.sigs.k8s.io/) is a tool that lets you run
|
||||
Kubernetes locally. Minikube runs a single-node Kubernetes cluster on your personal
|
||||
computer (including Windows, macOS and Linux PCs) so that you can try out Kubernetes,
|
||||
or for daily development work.
|
||||
## minikube
|
||||
|
||||
You can follow the official [Get Started!](https://minikube.sigs.k8s.io/docs/start/)
|
||||
guide, or read [Install Minikube](/docs/tasks/tools/install-minikube/) if your focus
|
||||
is on getting the tool installed.
|
||||
[`minikube`](https://minikube.sigs.k8s.io/) is a tool that lets you run Kubernetes
|
||||
locally. `minikube` runs a single-node Kubernetes cluster on your personal
|
||||
computer (including Windows, macOS and Linux PCs) so that you can try out
|
||||
Kubernetes, or for daily development work.
|
||||
|
||||
Once you have Minikube working, you can use it to
|
||||
You can follow the official
|
||||
[Get Started!](https://minikube.sigs.k8s.io/docs/start/) guide if your focus is
|
||||
on getting the tool installed.
|
||||
|
||||
<a class="btn btn-primary" href="https://minikube.sigs.k8s.io/docs/start/" role="button" aria-label="View minikube Get Started! Guide">View minikube Get Started! Guide</a>
|
||||
|
||||
Once you have `minikube` working, you can use it to
|
||||
[run a sample application](/docs/tutorials/hello-minikube/).
|
||||
|
||||
## kind
|
||||
|
||||
Like Minikube, [kind](https://kind.sigs.k8s.io/docs/) lets you run Kubernetes on
|
||||
your local computer. Unlike Minikube, kind only works with a single container runtime:
|
||||
it requires that you have [Docker](https://docs.docker.com/get-docker/) installed
|
||||
and configured.
|
||||
Like `minikube`, [`kind`](https://kind.sigs.k8s.io/docs/) lets you run Kubernetes on
|
||||
your local computer. Unlike `minikube`, `kind` only works with a single container
|
||||
runtime: it requires that you have [Docker](https://docs.docker.com/get-docker/)
|
||||
installed and configured.
|
||||
|
||||
[Quick Start](https://kind.sigs.k8s.io/docs/user/quick-start/) shows you what you
|
||||
need to do to get up and running with kind.
|
||||
[Quick Start](https://kind.sigs.k8s.io/docs/user/quick-start/) shows you what
|
||||
you need to do to get up and running with `kind`.
|
||||
|
||||
<a class="btn btn-primary" href="https://kind.sigs.k8s.io/docs/user/quick-start/" role="button" aria-label="View kind Quick Start Guide">View kind Quick Start Guide</a>
|
||||
|
||||
@@ -1,262 +0,0 @@
|
||||
---
|
||||
title: Install Minikube
|
||||
content_type: task
|
||||
weight: 20
|
||||
card:
|
||||
name: tasks
|
||||
weight: 10
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
This page shows you how to install [Minikube](/docs/tutorials/hello-minikube), a tool that runs a single-node Kubernetes cluster in a virtual machine on your personal computer.
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< tabs name="minikube_before_you_begin" >}}
|
||||
{{% tab name="Linux" %}}
|
||||
To check if virtualization is supported on Linux, run the following command and verify that the output is non-empty:
|
||||
```
|
||||
grep -E --color 'vmx|svm' /proc/cpuinfo
|
||||
```
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="macOS" %}}
|
||||
To check if virtualization is supported on macOS, run the following command on your terminal.
|
||||
```
|
||||
sysctl -a | grep -E --color 'machdep.cpu.features|VMX'
|
||||
```
|
||||
If you see `VMX` in the output (should be colored), the VT-x feature is enabled in your machine.
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="Windows" %}}
|
||||
To check if virtualization is supported on Windows 8 and above, run the following command on your Windows terminal or command prompt.
|
||||
```
|
||||
systeminfo
|
||||
```
|
||||
If you see the following output, virtualization is supported on Windows.
|
||||
```
|
||||
Hyper-V Requirements: VM Monitor Mode Extensions: Yes
|
||||
Virtualization Enabled In Firmware: Yes
|
||||
Second Level Address Translation: Yes
|
||||
Data Execution Prevention Available: Yes
|
||||
```
|
||||
|
||||
If you see the following output, your system already has a Hypervisor installed and you can skip the next step.
|
||||
```
|
||||
Hyper-V Requirements: A hypervisor has been detected. Features required for Hyper-V will not be displayed.
|
||||
```
|
||||
|
||||
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Installing minikube
|
||||
|
||||
{{< tabs name="tab_with_md" >}}
|
||||
{{% tab name="Linux" %}}
|
||||
|
||||
### Install kubectl
|
||||
|
||||
Make sure you have kubectl installed. You can install kubectl according to the instructions in [Install and Set Up kubectl](/docs/tasks/tools/install-kubectl/#install-kubectl-on-linux).
|
||||
|
||||
### Install a Hypervisor
|
||||
|
||||
If you do not already have a hypervisor installed, install one of these now:
|
||||
|
||||
• [KVM](https://www.linux-kvm.org/), which also uses QEMU
|
||||
|
||||
• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
|
||||
|
||||
Minikube also supports a `--driver=none` option that runs the Kubernetes components on the host and not in a VM.
|
||||
Using this driver requires [Docker](https://www.docker.com/products/docker-desktop) and a Linux environment but not a hypervisor.
|
||||
|
||||
If you're using the `none` driver in Debian or a derivative, use the `.deb` packages for
|
||||
Docker rather than the snap package, which does not work with Minikube.
|
||||
You can download `.deb` packages from [Docker](https://www.docker.com/products/docker-desktop).
|
||||
|
||||
{{< caution >}}
|
||||
The `none` VM driver can result in security and data loss issues.
|
||||
Before using `--driver=none`, consult [this documentation](https://minikube.sigs.k8s.io/docs/reference/drivers/none/) for more information.
|
||||
{{< /caution >}}
|
||||
|
||||
Minikube also supports a `vm-driver=podman` similar to the Docker driver. Podman run as superuser privilege (root user) is the best way to ensure that your containers have full access to any feature available on your system.
|
||||
|
||||
{{< caution >}}
|
||||
The `podman` driver requires running the containers as root because regular user accounts don't have full access to all operating system features that their containers might need to run.
|
||||
{{< /caution >}}
|
||||
|
||||
### Install Minikube using a package
|
||||
|
||||
There are *experimental* packages for Minikube available; you can find Linux (AMD64) packages
|
||||
from Minikube's [releases](https://github.com/kubernetes/minikube/releases) page on GitHub.
|
||||
|
||||
Use your Linux's distribution's package tool to install a suitable package.
|
||||
|
||||
### Install Minikube via direct download
|
||||
|
||||
If you're not installing via a package, you can download a stand-alone
|
||||
binary and use that.
|
||||
|
||||
```shell
|
||||
curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 \
|
||||
&& chmod +x minikube
|
||||
```
|
||||
|
||||
Here's an easy way to add the Minikube executable to your path:
|
||||
|
||||
```shell
|
||||
sudo mkdir -p /usr/local/bin/
|
||||
sudo install minikube /usr/local/bin/
|
||||
```
|
||||
|
||||
### Install Minikube using Homebrew
|
||||
|
||||
As yet another alternative, you can install Minikube using Linux [Homebrew](https://docs.brew.sh/Homebrew-on-Linux):
|
||||
|
||||
```shell
|
||||
brew install minikube
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="macOS" %}}
|
||||
### Install kubectl
|
||||
|
||||
Make sure you have kubectl installed. You can install kubectl according to the instructions in [Install and Set Up kubectl](/docs/tasks/tools/install-kubectl/#install-kubectl-on-macos).
|
||||
|
||||
### Install a Hypervisor
|
||||
|
||||
If you do not already have a hypervisor installed, install one of these now:
|
||||
|
||||
• [HyperKit](https://github.com/moby/hyperkit)
|
||||
|
||||
• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
|
||||
|
||||
• [VMware Fusion](https://www.vmware.com/products/fusion)
|
||||
|
||||
### Install Minikube
|
||||
The easiest way to install Minikube on macOS is using [Homebrew](https://brew.sh):
|
||||
|
||||
```shell
|
||||
brew install minikube
|
||||
```
|
||||
|
||||
You can also install it on macOS by downloading a stand-alone binary:
|
||||
|
||||
```shell
|
||||
curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-darwin-amd64 \
|
||||
&& chmod +x minikube
|
||||
```
|
||||
|
||||
Here's an easy way to add the Minikube executable to your path:
|
||||
|
||||
```shell
|
||||
sudo mv minikube /usr/local/bin
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="Windows" %}}
|
||||
### Install kubectl
|
||||
|
||||
Make sure you have kubectl installed. You can install kubectl according to the instructions in [Install and Set Up kubectl](/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows).
|
||||
|
||||
### Install a Hypervisor
|
||||
|
||||
If you do not already have a hypervisor installed, install one of these now:
|
||||
|
||||
• [Hyper-V](https://msdn.microsoft.com/en-us/virtualization/hyperv_on_windows/quick_start/walkthrough_install)
|
||||
|
||||
• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
|
||||
|
||||
{{< note >}}
|
||||
Hyper-V can run on three versions of Windows 10: Windows 10 Enterprise, Windows 10 Professional, and Windows 10 Education.
|
||||
{{< /note >}}
|
||||
|
||||
### Install Minikube using Chocolatey
|
||||
|
||||
The easiest way to install Minikube on Windows is using [Chocolatey](https://chocolatey.org/) (run as an administrator):
|
||||
|
||||
```shell
|
||||
choco install minikube
|
||||
```
|
||||
|
||||
After Minikube has finished installing, close the current CLI session and restart. Minikube should have been added to your path automatically.
|
||||
|
||||
### Install Minikube using an installer executable
|
||||
|
||||
To install Minikube manually on Windows using [Windows Installer](https://docs.microsoft.com/en-us/windows/desktop/msi/windows-installer-portal), download [`minikube-installer.exe`](https://github.com/kubernetes/minikube/releases/latest/download/minikube-installer.exe) and execute the installer.
|
||||
|
||||
### Install Minikube via direct download
|
||||
|
||||
To install Minikube manually on Windows, download [`minikube-windows-amd64`](https://github.com/kubernetes/minikube/releases/latest), rename it to `minikube.exe`, and add it to your path.
|
||||
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
## Confirm Installation
|
||||
|
||||
To confirm successful installation of both a hypervisor and Minikube, you can run the following command to start up a local Kubernetes cluster:
|
||||
|
||||
{{< note >}}
|
||||
|
||||
For setting the `--driver` with `minikube start`, enter the name of the hypervisor you installed in lowercase letters where `<driver_name>` is mentioned below. A full list of `--driver` values is available in [specifying the VM driver documentation](/docs/setup/learning-environment/minikube/#specifying-the-vm-driver).
|
||||
|
||||
{{< /note >}}
|
||||
|
||||
{{< caution >}}
|
||||
When using KVM, note that libvirt's default QEMU URI under Debian and some other systems is `qemu:///session` whereas Minikube's default QEMU URI is `qemu:///system`. If this is the case for your system, you will need to pass `--kvm-qemu-uri qemu:///session` to `minikube start`.
|
||||
{{< /caution >}}
|
||||
|
||||
```shell
|
||||
minikube start --driver=<driver_name>
|
||||
```
|
||||
|
||||
Once `minikube start` finishes, run the command below to check the status of the cluster:
|
||||
|
||||
```shell
|
||||
minikube status
|
||||
```
|
||||
|
||||
If your cluster is running, the output from `minikube status` should be similar to:
|
||||
|
||||
```
|
||||
host: Running
|
||||
kubelet: Running
|
||||
apiserver: Running
|
||||
kubeconfig: Configured
|
||||
```
|
||||
|
||||
After you have confirmed whether Minikube is working with your chosen hypervisor, you can continue to use Minikube or you can stop your cluster. To stop your cluster, run:
|
||||
|
||||
```shell
|
||||
minikube stop
|
||||
```
|
||||
|
||||
## Clean up local state {#cleanup-local-state}
|
||||
|
||||
If you have previously installed Minikube, and run:
|
||||
```shell
|
||||
minikube start
|
||||
```
|
||||
|
||||
and `minikube start` returned an error:
|
||||
```
|
||||
machine does not exist
|
||||
```
|
||||
|
||||
then you need to clear minikube's local state:
|
||||
```shell
|
||||
minikube delete
|
||||
```
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* [Running Kubernetes Locally via Minikube](/docs/setup/learning-environment/minikube/)
|
||||
+5
@@ -0,0 +1,5 @@
|
||||
---
|
||||
title: "Example: Configuring a Java Microservice"
|
||||
weight: 10
|
||||
---
|
||||
|
||||
+30
@@ -0,0 +1,30 @@
|
||||
---
|
||||
title: "Interactive Tutorial - Configuring a Java Microservice"
|
||||
weight: 20
|
||||
---
|
||||
|
||||
<!DOCTYPE html>
|
||||
|
||||
<html lang="en">
|
||||
|
||||
<body>
|
||||
|
||||
<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
|
||||
<link href="/docs/tutorials/kubernetes-basics/public/css/overrides.css" rel="stylesheet">
|
||||
<script src="https://katacoda.com/embed.js"></script>
|
||||
|
||||
<div class="layout" id="top">
|
||||
|
||||
<main class="content katacoda-content">
|
||||
<div class="katacoda">
|
||||
<div class="katacoda__alert">
|
||||
To interact with the Terminal, please use the desktop/tablet version
|
||||
</div>
|
||||
<div class="katacoda__box" id="inline-terminal-1" data-katacoda-id="kubernetes-bootcamp/9" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;"></div>
|
||||
</div>
|
||||
</main>
|
||||
|
||||
</div>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
+39
@@ -0,0 +1,39 @@
|
||||
---
|
||||
title: "Externalizing config using MicroProfile, ConfigMaps and Secrets"
|
||||
content_type: tutorial
|
||||
weight: 10
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
In this tutorial you will learn how and why to externalize your microservice’s configuration. Specifically, you will learn how to use Kubernetes ConfigMaps and Secrets to set environment variables and then consume them using MicroProfile Config.
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
### Creating Kubernetes ConfigMaps & Secrets
|
||||
There are several ways to set environment variables for a Docker container in Kubernetes, including: Dockerfile, kubernetes.yml, Kubernetes ConfigMaps, and Kubernetes Secrets. In the tutorial, you will learn how to use the latter two for setting your environment variables whose values will be injected into your microservices. One of the benefits for using ConfigMaps and Secrets is that they can be re-used across multiple containers, including being assigned to different environment variables for the different containers.
|
||||
|
||||
ConfigMaps are API Objects that store non-confidential key-value pairs. In the Interactive Tutorial you will learn how to use a ConfigMap to store the application's name. For more information regarding ConfigMaps, you can find the documentation [here](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/).
|
||||
|
||||
Although Secrets are also used to store key-value pairs, they differ from ConfigMaps in that they're intended for confidential/sensitive information and are stored using Base64 encoding. This makes secrets the appropriate choice for storing such things as credentials, keys, and tokens, the former of which you'll do in the Interactive Tutorial. For more information on Secrets, you can find the documentation [here](https://kubernetes.io/docs/concepts/configuration/secret/).
|
||||
|
||||
|
||||
### Externalizing Config from Code
|
||||
Externalized application configuration is useful because configuration usually changes depending on your environment. In order to accomplish this, we'll use Java's Contexts and Dependency Injection (CDI) and MicroProfile Config. MicroProfile Config is a feature of MicroProfile, a set of open Java technologies for developing and deploying cloud-native microservices.
|
||||
|
||||
CDI provides a standard dependency injection capability enabling an application to be assembled from collaborating, loosely-coupled beans. MicroProfile Config provides apps and microservices a standard way to obtain config properties from various sources, including the application, runtime, and environment. Based on the source's defined priority, the properties are automatically combined into a single set of properties that the application can access via an API. Together, CDI & MicroProfile will be used in the Interactive Tutorial to retrieve the externally provided properties from the Kubernetes ConfigMaps and Secrets and get injected into your application code.
|
||||
|
||||
Many open source frameworks and runtimes implement and support MicroProfile Config. Throughout the interactive tutorial, you'll be using Open Liberty, a flexible open-source Java runtime for building and running cloud-native apps and microservices. However, any MicroProfile compatible runtime could be used instead.
|
||||
|
||||
|
||||
## {{% heading "objectives" %}}
|
||||
|
||||
* Create a Kubernetes ConfigMap and Secret
|
||||
* Inject microservice configuration using MicroProfile Config
|
||||
|
||||
|
||||
<!-- lessoncontent -->
|
||||
|
||||
## Example: Externalizing config using MicroProfile, ConfigMaps and Secrets
|
||||
### [Start Interactive Tutorial](/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice-interactive/)
|
||||
@@ -136,6 +136,9 @@ Kubernetes [*Service*](/docs/concepts/services-networking/service/).
|
||||
|
||||
The `--type=LoadBalancer` flag indicates that you want to expose your Service
|
||||
outside of the cluster.
|
||||
|
||||
The application code inside the image `k8s.gcr.io/echoserver` only listens on TCP port 8080. If you used
|
||||
`kubectl expose` to expose a different port, clients could not connect to that other port.
|
||||
|
||||
2. View the Service you just created:
|
||||
|
||||
@@ -283,4 +286,3 @@ minikube delete
|
||||
* Learn more about [Deploying applications](/docs/tasks/run-application/run-stateless-application-deployment/).
|
||||
* Learn more about [Service objects](/docs/concepts/services-networking/service/).
|
||||
|
||||
|
||||
|
||||
@@ -72,7 +72,7 @@ weight: 10
|
||||
<div class="row">
|
||||
<div class="col-md-8">
|
||||
<p><b>The Master is responsible for managing the cluster.</b> The master coordinates all activities in your cluster, such as scheduling applications, maintaining applications' desired state, scaling applications, and rolling out new updates.</p>
|
||||
<p><b>A node is a VM or a physical computer that serves as a worker machine in a Kubernetes cluster.</b> Each node has a Kubelet, which is an agent for managing the node and communicating with the Kubernetes master. The node should also have tools for handling container operations, such as Docker or rkt. A Kubernetes cluster that handles production traffic should have a minimum of three nodes.</p>
|
||||
<p><b>A node is a VM or a physical computer that serves as a worker machine in a Kubernetes cluster.</b> Each node has a Kubelet, which is an agent for managing the node and communicating with the Kubernetes master. The node should also have tools for handling container operations, such as containerd or Docker. A Kubernetes cluster that handles production traffic should have a minimum of three nodes.</p>
|
||||
|
||||
</div>
|
||||
<div class="col-md-4">
|
||||
|
||||
Reference in New Issue
Block a user