Merge branch 'master' into release-1.12
This commit is contained in:
Tim Fogarty
@@ -10,7 +10,6 @@ This topic discusses multiple ways to interact with clusters.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
@@ -285,16 +284,16 @@ The redirect capabilities have been deprecated and removed. Please use a proxy
|
||||
There are several different proxies you may encounter when using Kubernetes:
|
||||
|
||||
1. The [kubectl proxy](#directly-accessing-the-rest-api):
|
||||
|
||||
|
||||
- runs on a user's desktop or in a pod
|
||||
- proxies from a localhost address to the Kubernetes apiserver
|
||||
- client to proxy uses HTTP
|
||||
- proxy to apiserver uses HTTPS
|
||||
- locates apiserver
|
||||
- adds authentication headers
|
||||
|
||||
|
||||
1. The [apiserver proxy](#discovering-builtin-services):
|
||||
|
||||
|
||||
- is a bastion built into the apiserver
|
||||
- connects a user outside of the cluster to cluster IPs which otherwise might not be reachable
|
||||
- runs in the apiserver processes
|
||||
@@ -302,23 +301,23 @@ There are several different proxies you may encounter when using Kubernetes:
|
||||
- proxy to target may use HTTP or HTTPS as chosen by proxy using available information
|
||||
- can be used to reach a Node, Pod, or Service
|
||||
- does load balancing when used to reach a Service
|
||||
|
||||
|
||||
1. The [kube proxy](/docs/concepts/services-networking/service/#ips-and-vips):
|
||||
|
||||
|
||||
- runs on each node
|
||||
- proxies UDP and TCP
|
||||
- does not understand HTTP
|
||||
- provides load balancing
|
||||
- is just used to reach services
|
||||
|
||||
|
||||
1. A Proxy/Load-balancer in front of apiserver(s):
|
||||
|
||||
|
||||
- existence and implementation varies from cluster to cluster (e.g. nginx)
|
||||
- sits between all clients and one or more apiservers
|
||||
- acts as load balancer if there are several apiservers.
|
||||
|
||||
|
||||
1. Cloud Load Balancers on external services:
|
||||
|
||||
|
||||
- are provided by some cloud providers (e.g. AWS ELB, Google Cloud Load Balancer)
|
||||
- are created automatically when the Kubernetes service has type `LoadBalancer`
|
||||
- use UDP/TCP only
|
||||
|
||||
@@ -16,7 +16,6 @@ well as any provider specific details that may be necessary.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
|
||||
@@ -18,7 +18,6 @@ Dashboard also provides information on the state of Kubernetes resources in your
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
|
||||
+1
@@ -3,6 +3,7 @@ title: Extend the Kubernetes API with CustomResourceDefinitions
|
||||
reviewers:
|
||||
- deads2k
|
||||
- enisoc
|
||||
- sttts
|
||||
content_template: templates/task
|
||||
weight: 20
|
||||
---
|
||||
|
||||
-174
@@ -1,174 +0,0 @@
|
||||
---
|
||||
title: Migrate a ThirdPartyResource to CustomResourceDefinition
|
||||
reviewers:
|
||||
- enisoc
|
||||
- deads2k
|
||||
content_template: templates/task
|
||||
weight: 50
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
This page shows how to migrate data stored in a ThirdPartyResource (TPR) to a
|
||||
[CustomResourceDefinition](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#customresourcedefinition-v1beta1-apiextensions) (CRD).
|
||||
|
||||
Kubernetes does not automatically migrate existing TPRs.
|
||||
This is due to API changes introduced as part of
|
||||
[graduating to beta](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/thirdpartyresources.md)
|
||||
under a new name and API group.
|
||||
Instead, both TPR and CRD are available and operate independently in Kubernetes 1.7.
|
||||
Users must migrate each TPR one by one to preserve their data before upgrading to Kubernetes 1.8.
|
||||
|
||||
The simplest way to migrate is to stop all clients that use a given TPR, then delete the TPR and
|
||||
start from scratch with a CRD.
|
||||
This page describes an optional process that eases the transition by migrating existing TPR data for
|
||||
you **on a best-effort basis**.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
* Make sure your Kubernetes cluster has a **master version of exactly 1.7.x** (any patch release),
|
||||
as this is the only version that supports both TPR and CRD.
|
||||
* If you use a TPR-based custom controller, check with the author of the controller first.
|
||||
Some or all of these steps may be unnecessary if the custom controller handles the migration for
|
||||
you.
|
||||
* Be familiar with the concept of [custom resources](/docs/concepts/api-extension/custom-resources/),
|
||||
which were known as *third-party resources* until Kubernetes 1.7.
|
||||
* Be familiar with [CustomResourceDefinitions](/docs/concepts/api-extension/custom-resources/#customresourcedefinitions),
|
||||
which are a simple way to implement custom resources.
|
||||
* **Before performing a migration on real data, conduct a dry run by going through these steps in a test cluster.**
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
## Migrate TPR data
|
||||
|
||||
1. **Rewrite the TPR definition**
|
||||
|
||||
Clients that access the REST API for your custom resource should not need any changes.
|
||||
However, you will need to rewrite your TPR definition as a CRD.
|
||||
|
||||
Make sure you specify values for the CRD fields that match what the server used to fill in for
|
||||
you with TPR.
|
||||
|
||||
For example, if your ThirdPartyResource looks like this:
|
||||
|
||||
|
||||
apiVersion: extensions/v1beta1
|
||||
kind: ThirdPartyResource
|
||||
metadata:
|
||||
name: cron-tab.stable.example.com
|
||||
description: "A specification of a Pod to run on a cron style schedule"
|
||||
versions:
|
||||
- name: v1
|
||||
|
||||
|
||||
A matching CustomResourceDefinition could look like this:
|
||||
|
||||
```yaml
|
||||
apiVersion: apiextensions.k8s.io/v1beta1
|
||||
kind: CustomResourceDefinition
|
||||
metadata:
|
||||
name: crontabs.stable.example.com
|
||||
spec:
|
||||
scope: Namespaced
|
||||
group: stable.example.com
|
||||
versions:
|
||||
- name: v1
|
||||
served: true
|
||||
storage: true
|
||||
names:
|
||||
kind: CronTab
|
||||
plural: crontabs
|
||||
singular: crontab
|
||||
```
|
||||
|
||||
1. **Install the CustomResourceDefinition**
|
||||
|
||||
While the source TPR is still active, install the matching CRD with `kubectl create`.
|
||||
Existing TPR data remains accessible because TPRs take precedence over CRDs when both try
|
||||
to serve the same resource.
|
||||
|
||||
After you create the CRD, make sure the *Established* condition goes to True.
|
||||
You can check it with a command like this:
|
||||
|
||||
```shell
|
||||
kubectl get crd -o 'custom-columns=NAME:{.metadata.name},ESTABLISHED:{.status.conditions[?(@.type=="Established")].status}'
|
||||
```
|
||||
|
||||
The output should look like this:
|
||||
|
||||
```console
|
||||
NAME ESTABLISHED
|
||||
crontabs.stable.example.com True
|
||||
```
|
||||
|
||||
1. **Stop all clients that use the TPR**
|
||||
|
||||
The API server attempts to prevent TPR data for the resource from changing while it
|
||||
copies objects to the CRD, but it can't guarantee consistency in all cases, such as with
|
||||
[multiple masters](/docs/admin/high-availability/).
|
||||
Stopping clients, such as TPR-based custom controllers, helps to avoid inconsistencies in
|
||||
the copied data.
|
||||
|
||||
In addition, clients that watch TPR data do not receive any more events once the migration
|
||||
begins.
|
||||
You must restart them after the migration completes so they start watching CRD data instead.
|
||||
|
||||
1. **Back up TPR data**
|
||||
|
||||
In case the data migration fails, save a copy of existing data for the resource:
|
||||
|
||||
```shell
|
||||
kubectl get crontabs --all-namespaces -o yaml > crontabs.yaml
|
||||
```
|
||||
|
||||
You should also save a copy of the TPR definition if you don't have one already:
|
||||
|
||||
```shell
|
||||
kubectl get thirdpartyresource cron-tab.stable.example.com -o yaml --export > tpr.yaml
|
||||
```
|
||||
|
||||
1. **Delete the TPR definition**
|
||||
|
||||
Normally, when you delete a TPR definition, the API server tries to clean up any objects stored
|
||||
in that resource.
|
||||
Because a matching CRD exists, the server copies objects to the CRD instead of deleting them.
|
||||
|
||||
```shell
|
||||
kubectl delete thirdpartyresource cron-tab.stable.example.com
|
||||
```
|
||||
|
||||
1. **Verify the new CRD data**
|
||||
|
||||
It can take up to 10 seconds for the TPR controller to notice when you delete the TPR definition
|
||||
and to initiate the migration. The TPR data remains accessible during this time.
|
||||
|
||||
Once the migration completes, the resource begins serving through the CRD.
|
||||
Check that all your objects were correctly copied:
|
||||
|
||||
```shell
|
||||
kubectl get crontabs --all-namespaces -o yaml
|
||||
```
|
||||
|
||||
If the copy failed, you can quickly revert to the set of objects that existed just before the
|
||||
migration by recreating the TPR definition:
|
||||
|
||||
```shell
|
||||
kubectl create -f tpr.yaml
|
||||
```
|
||||
|
||||
1. **Restart clients**
|
||||
|
||||
After verifying the CRD data, restart any clients you stopped before the migration, such as
|
||||
custom controllers and other watchers.
|
||||
These clients now access CRD data when they make requests on the same API endpoints
|
||||
that the TPR previously served.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
* Learn more about [custom resources](/docs/concepts/api-extension/custom-resources/).
|
||||
* Learn more about [using CustomResourceDefinitions](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/).
|
||||
* See [CustomResourceDefinition](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#customresourcedefinition-v1beta1-apiextensions).
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -32,7 +32,9 @@ the corresponding `PersistentVolume` is not be deleted. Instead, it is moved to
|
||||
|
||||
1. List the PersistentVolumes in your cluster:
|
||||
|
||||
kubectl get pv
|
||||
```shell
|
||||
kubectl get pv
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
@@ -46,13 +48,17 @@ the corresponding `PersistentVolume` is not be deleted. Instead, it is moved to
|
||||
|
||||
1. Choose one of your PersistentVolumes and change its reclaim policy:
|
||||
|
||||
kubectl patch pv <your-pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
|
||||
```shell
|
||||
kubectl patch pv <your-pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
|
||||
```
|
||||
|
||||
where `<your-pv-name>` is the name of your chosen PersistentVolume.
|
||||
|
||||
1. Verify that your chosen PersistentVolume has the right policy:
|
||||
|
||||
kubectl get pv
|
||||
```shell
|
||||
kubectl get pv
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
|
||||
@@ -15,7 +15,6 @@ running cluster.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
|
||||
@@ -21,7 +21,6 @@ in the Kubernetes source directory for a canonical example.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
|
||||
@@ -12,7 +12,6 @@ content_template: templates/task
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
|
||||
@@ -20,7 +20,6 @@ directives.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
@@ -178,7 +177,7 @@ spec:
|
||||
```
|
||||
|
||||
This pod runs in the `Guaranteed` QoS class because `requests` are equal to `limits`.
|
||||
And the container's resource limit for the CPU resource is an integer greater than
|
||||
And the container's resource limit for the CPU resource is an integer greater than
|
||||
or equal to one. The `nginx` container is granted 2 exclusive CPUs.
|
||||
|
||||
|
||||
@@ -213,8 +212,8 @@ spec:
|
||||
```
|
||||
|
||||
This pod runs in the `Guaranteed` QoS class because only `limits` are specified
|
||||
and `requests` are set equal to `limits` when not explicitly specified. And the
|
||||
container's resource limit for the CPU resource is an integer greater than or
|
||||
and `requests` are set equal to `limits` when not explicitly specified. And the
|
||||
container's resource limit for the CPU resource is an integer greater than or
|
||||
equal to one. The `nginx` container is granted 2 exclusive CPUs.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -22,7 +22,6 @@ To dive a little deeper into implementation details, all cloud controller manage
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
|
||||
+2
-41
@@ -18,54 +18,15 @@ vacated by the evicted critical add-on pod or the amount of resources available
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Rescheduler: guaranteed scheduling of critical add-ons
|
||||
**Rescheduler is deprecated as of Kubernetes 1.10 and will be removed in version 1.12 in
|
||||
accordance with the [deprecation policy](/docs/reference/deprecation-policy) for beta features.**
|
||||
|
||||
**To avoid eviction of critical pods, you must
|
||||
[enable priorities in scheduler](/docs/concepts/configuration/pod-priority-preemption/)
|
||||
before upgrading to Kubernetes 1.10 or higher.**
|
||||
|
||||
Rescheduler ensures that critical pods created by DaemonSet controller are always scheduled
|
||||
(assuming the cluster has enough resources to run the critical add-on pods in the absence of regular pods).
|
||||
If the scheduler determines that no node has enough free resources to run the critical add-on pod
|
||||
given the pods that are already running in the cluster
|
||||
(indicated by critical add-on pod's pod condition PodScheduled set to false, the reason set to Unschedulable)
|
||||
the rescheduler tries to free up space for the DaemonSet critical pod by evicting some pods; then the scheduler will schedule the add-on pod.
|
||||
|
||||
To avoid situation when another pod is scheduled into the space prepared for the critical add-on,
|
||||
the chosen node gets a temporary taint "CriticalAddonsOnly" before the eviction(s)
|
||||
(see [more details](https://git.k8s.io/community/contributors/design-proposals/scheduling/taint-toleration-dedicated.md)).
|
||||
Each critical add-on has to tolerate it,
|
||||
while the other pods shouldn't tolerate the taint. The taint is removed once the add-on is successfully scheduled.
|
||||
|
||||
*Warning:* currently there is no guarantee which node is chosen and which pods are being killed
|
||||
in order to schedule critical pods, so if rescheduler is enabled your pods might be occasionally
|
||||
killed for this purpose. Please ensure that rescheduler is not enabled along with priorities & preemptions in default-scheduler as rescheduler is oblivious to priorities and it may evict high priority pods, instead of low priority ones.
|
||||
|
||||
## Config
|
||||
|
||||
Rescheduler doesn't have any user facing configuration (component config) or API.
|
||||
|
||||
### Marking pod as critical when using Rescheduler.
|
||||
### Marking pod as critical
|
||||
|
||||
To be considered critical, the pod has to run in the `kube-system` namespace (configurable via flag) and
|
||||
|
||||
* have the `scheduler.alpha.kubernetes.io/critical-pod` annotation set to empty string, and
|
||||
* have the PodSpec's `tolerations` field set to `[{"key":"CriticalAddonsOnly", "operator":"Exists"}]`.
|
||||
* Have the priorityClassName set as "system-cluster-critical" or "system-node-critical", the latter being the highest for entire cluster. Alternatively, you could add an annotation `scheduler.alpha.kubernetes.io/critical-pod` as key and empty string as value to your pod, but this annotation is deprecated as of version 1.13 and will be removed in 1.14.
|
||||
|
||||
The first one marks a pod a critical. The second one is required by Rescheduler algorithm.
|
||||
|
||||
A pod could also be considered critical, if its priority is greater than or equal to system-critical-priority.
|
||||
|
||||
### Marking pod as critical when priorites are enabled.
|
||||
|
||||
To be considered critical, the pod has to run in the `kube-system` namespace (configurable via flag) and
|
||||
|
||||
* Have the priorityClass set as "system-cluster-critical" or "system-node-critical", the latter being the highest for entire cluster and `scheduler.alpha.kubernetes.io/critical-pod` annotation set to empty string(This will be deprecated too).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -14,7 +14,6 @@ This document describes how to use kube-up/down scripts to manage highly availab
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
|
||||
@@ -21,7 +21,7 @@ Before proceeding:
|
||||
- You need to have a `kubeadm` HA cluster running version 1.11 or higher.
|
||||
- Make sure you read the [release notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.12.md) carefully.
|
||||
- Make sure to back up any important components, such as app-level state stored in a database. `kubeadm upgrade` does not touch your workloads, only components internal to Kubernetes, but backups are always a best practice.
|
||||
- Check the prerequisites for [Upgrading/downgrading kubeadm clusters between v1.11 to v1.12](/docs/tasks/administer-cluster/kubeadm-upgrade-1-12/).
|
||||
- Check the prerequisites for [Upgrading/downgrading kubeadm clusters between v1.11 to v1.12](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-12/).
|
||||
|
||||
{{< note >}}
|
||||
**Note**: All commands on any control plane or etcd node should be
|
||||
|
||||
@@ -68,7 +68,7 @@ kubectl get pod default-cpu-demo --output=yaml --namespace=default-cpu-example
|
||||
The output shows that the Pod's Container has a CPU request of 500 millicpus and
|
||||
a CPU limit of 1 cpu. These are the default values specified by the LimitRange.
|
||||
|
||||
```shel
|
||||
```shell
|
||||
containers:
|
||||
- image: nginx
|
||||
imagePullPolicy: Always
|
||||
|
||||
+1
-1
@@ -70,7 +70,7 @@ kubectl get pod default-mem-demo --output=yaml --namespace=default-mem-example
|
||||
The output shows that the Pod's Container has a memory request of 256 MiB and
|
||||
a memory limit of 512 MiB. These are the default values specified by the LimitRange.
|
||||
|
||||
```shel
|
||||
```shell
|
||||
containers:
|
||||
- image: nginx
|
||||
imagePullPolicy: Always
|
||||
|
||||
@@ -20,7 +20,6 @@ This example demonstrates how to use Kubernetes namespaces to subdivide your clu
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
|
||||
@@ -18,7 +18,6 @@ nodes become unstable.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
@@ -205,7 +204,7 @@ If `nodefs` filesystem has met eviction thresholds, `kubelet` frees up disk spac
|
||||
|
||||
If the `kubelet` is unable to reclaim sufficient resource on the node, `kubelet` begins evicting Pods.
|
||||
|
||||
The `kubelet` ranks Pods for eviction first by whether or not their usage of the starved resource exceeds requests,
|
||||
The `kubelet` ranks Pods for eviction first by whether or not their usage of the starved resource exceeds requests,
|
||||
then by [Priority](https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/), and then by the consumption of the starved compute resource relative to the Pods' scheduling requests.
|
||||
|
||||
As a result, `kubelet` ranks and evicts Pods in the following order:
|
||||
@@ -213,15 +212,15 @@ As a result, `kubelet` ranks and evicts Pods in the following order:
|
||||
* `BestEffort` or `Burstable` Pods whose usage of a starved resource exceeds its request.
|
||||
Such pods are ranked by Priority, and then usage above request.
|
||||
* `Guaranteed` pods and `Burstable` pods whose usage is beneath requests are evicted last.
|
||||
`Guaranteed` Pods are guaranteed only when requests and limits are specified for all
|
||||
the containers and they are equal. Such pods are guaranteed to never be evicted because
|
||||
`Guaranteed` Pods are guaranteed only when requests and limits are specified for all
|
||||
the containers and they are equal. Such pods are guaranteed to never be evicted because
|
||||
of another Pod's resource consumption. If a system daemon (such as `kubelet`, `docker`,
|
||||
and `journald`) is consuming more resources than were reserved via `system-reserved` or
|
||||
`kube-reserved` allocations, and the node only has `Guaranteed` or `Burstable` Pods using
|
||||
less than requests remaining, then the node must choose to evict such a Pod in order to
|
||||
`kube-reserved` allocations, and the node only has `Guaranteed` or `Burstable` Pods using
|
||||
less than requests remaining, then the node must choose to evict such a Pod in order to
|
||||
preserve node stability and to limit the impact of the unexpected consumption to other Pods.
|
||||
In this case, it will choose to evict pods of Lowest Priority first.
|
||||
|
||||
|
||||
If necessary, `kubelet` evicts Pods one at a time to reclaim disk when `DiskPressure`
|
||||
is encountered. If the `kubelet` is responding to `inode` starvation, it reclaims
|
||||
`inodes` by evicting Pods with the lowest quality of service first. If the `kubelet`
|
||||
|
||||
@@ -23,7 +23,6 @@ on each node.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
|
||||
@@ -17,7 +17,6 @@ The `cloud-controller-manager` can be linked to any cloud provider that satisfie
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
|
||||
@@ -16,7 +16,6 @@ This means that the pods are visible on the API server but cannot be controlled
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
@@ -103,7 +102,7 @@ Notice we cannot delete the pod with the API server (e.g. via [`kubectl`](/docs/
|
||||
|
||||
{{<note>}}
|
||||
**Note**: Make sure the kubelet has permission to create the mirror pod in the API server.
|
||||
If not, the creation request is rejected by the API server. See
|
||||
If not, the creation request is rejected by the API server. See
|
||||
[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/).
|
||||
{{</note>}}
|
||||
|
||||
|
||||
@@ -216,7 +216,7 @@ spec:
|
||||
- Verify that the scheduling of the second pod fails with the below warning:
|
||||
|
||||
```shell
|
||||
Warning FailedScheduling 18s (x4 over 21s) default-scheduler persistentvolumeclaim "slzc" is being deleted
|
||||
Warning FailedScheduling 18s (x4 over 21s) default-scheduler persistentvolumeclaim "slzc" is being deleted
|
||||
```
|
||||
|
||||
- Wait until the pod status of both pods is `Terminated` or `Completed` (either delete the pods or wait until they finish). Afterwards, check that the PVC is removed.
|
||||
|
||||
@@ -45,7 +45,7 @@ You can do that using [kubectl](/docs/user-guide/kubectl/) by running:
|
||||
kubectl --context=federation-cluster create -f mydeployment.yaml
|
||||
```
|
||||
|
||||
The '--context=federation-cluster' flag tells kubectl to submit the
|
||||
The `--context=federation-cluster` flag tells kubectl to submit the
|
||||
request to the Federation apiserver instead of sending it to a Kubernetes
|
||||
cluster.
|
||||
|
||||
|
||||
@@ -13,7 +13,6 @@ This guide explains how to use events in federation control plane to help in deb
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
|
||||
@@ -106,7 +106,7 @@ Currently the default distribution is only available on the federated HPA, but i
|
||||
future, users preferences could also be specified to control and/or restrict this
|
||||
distribution.
|
||||
|
||||
## Updating a federated ReplicaSet
|
||||
## Updating a federated HPA
|
||||
|
||||
You can update a federated HPA as you would update a Kubernetes
|
||||
HPA; however, for a federated HPA, you must send the request to
|
||||
|
||||
@@ -55,7 +55,7 @@ rather a
|
||||
globally reachable via a single, static IP address.
|
||||
|
||||
Clients inside your federated Kubernetes clusters (Pods) will be
|
||||
automatically routed to the cluster-local shard of the Federated Service
|
||||
automatically routed to the cluster-local shard of the Federated Service
|
||||
backing the Ingress in their cluster if it exists and is healthy, or the closest healthy shard in a
|
||||
different cluster if it does not. Note that this involves a network
|
||||
trip to the HTTP(s) load balancer, which resides outside your local
|
||||
@@ -85,7 +85,7 @@ You can create a federated ingress in any of the usual ways, for example, using
|
||||
kubectl --context=federation-cluster create -f myingress.yaml
|
||||
```
|
||||
For example ingress YAML configurations, see the [Ingress User Guide](/docs/concepts/services-networking/ingress/).
|
||||
The '--context=federation-cluster' flag tells kubectl to submit the
|
||||
The `--context=federation-cluster` flag tells kubectl to submit the
|
||||
request to the Federation API endpoint, with the appropriate
|
||||
credentials. If you have not yet configured such a context, see the
|
||||
[federation admin guide](/docs/admin/federation/) or one of the
|
||||
|
||||
@@ -40,7 +40,7 @@ You can do that using [kubectl](/docs/user-guide/kubectl/) by running:
|
||||
kubectl --context=federation-cluster create -f myjob.yaml
|
||||
```
|
||||
|
||||
The '--context=federation-cluster' flag tells kubectl to submit the
|
||||
The `--context=federation-cluster` flag tells kubectl to submit the
|
||||
request to the federation API server instead of sending it to a Kubernetes
|
||||
cluster.
|
||||
|
||||
|
||||
@@ -41,7 +41,7 @@ You can do that using kubectl by running:
|
||||
kubectl --context=federation-cluster create -f myns.yaml
|
||||
```
|
||||
|
||||
The '--context=federation-cluster' flag tells kubectl to submit the
|
||||
The `--context=federation-cluster` flag tells kubectl to submit the
|
||||
request to the Federation apiserver instead of sending it to a Kubernetes
|
||||
cluster.
|
||||
|
||||
|
||||
@@ -18,7 +18,6 @@ Creating them in the federation control plane ensures that they are synchronized
|
||||
across all the clusters in federation.
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
|
||||
@@ -297,130 +297,130 @@ metadata:
|
||||
|
||||
### Define a container environment variable with data from a single ConfigMap
|
||||
|
||||
1. Define an environment variable as a key-value pair in a ConfigMap:
|
||||
1. Define an environment variable as a key-value pair in a ConfigMap:
|
||||
|
||||
```shell
|
||||
kubectl create configmap special-config --from-literal=special.how=very
|
||||
```
|
||||
```shell
|
||||
kubectl create configmap special-config --from-literal=special.how=very
|
||||
```
|
||||
|
||||
1. Assign the `special.how` value defined in the ConfigMap to the `SPECIAL_LEVEL_KEY` environment variable in the Pod specification.
|
||||
1. Assign the `special.how` value defined in the ConfigMap to the `SPECIAL_LEVEL_KEY` environment variable in the Pod specification.
|
||||
|
||||
```shell
|
||||
kubectl edit pod dapi-test-pod
|
||||
```
|
||||
```shell
|
||||
kubectl edit pod dapi-test-pod
|
||||
```
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: dapi-test-pod
|
||||
spec:
|
||||
containers:
|
||||
- name: test-container
|
||||
image: k8s.gcr.io/busybox
|
||||
command: [ "/bin/sh", "-c", "env" ]
|
||||
env:
|
||||
# Define the environment variable
|
||||
- name: SPECIAL_LEVEL_KEY
|
||||
valueFrom:
|
||||
configMapKeyRef:
|
||||
# The ConfigMap containing the value you want to assign to SPECIAL_LEVEL_KEY
|
||||
name: special-config
|
||||
# Specify the key associated with the value
|
||||
key: special.how
|
||||
restartPolicy: Never
|
||||
```
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: dapi-test-pod
|
||||
spec:
|
||||
containers:
|
||||
- name: test-container
|
||||
image: k8s.gcr.io/busybox
|
||||
command: [ "/bin/sh", "-c", "env" ]
|
||||
env:
|
||||
# Define the environment variable
|
||||
- name: SPECIAL_LEVEL_KEY
|
||||
valueFrom:
|
||||
configMapKeyRef:
|
||||
# The ConfigMap containing the value you want to assign to SPECIAL_LEVEL_KEY
|
||||
name: special-config
|
||||
# Specify the key associated with the value
|
||||
key: special.how
|
||||
restartPolicy: Never
|
||||
```
|
||||
|
||||
1. Save the changes to the Pod specification. Now, the Pod's output includes `SPECIAL_LEVEL_KEY=very`.
|
||||
1. Save the changes to the Pod specification. Now, the Pod's output includes `SPECIAL_LEVEL_KEY=very`.
|
||||
|
||||
### Define container environment variables with data from multiple ConfigMaps
|
||||
|
||||
1. As with the previous example, create the ConfigMaps first.
|
||||
1. As with the previous example, create the ConfigMaps first.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
name: special-config
|
||||
namespace: default
|
||||
data:
|
||||
special.how: very
|
||||
```
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
name: special-config
|
||||
namespace: default
|
||||
data:
|
||||
special.how: very
|
||||
```
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
name: env-config
|
||||
namespace: default
|
||||
data:
|
||||
log_level: INFO
|
||||
```
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
name: env-config
|
||||
namespace: default
|
||||
data:
|
||||
log_level: INFO
|
||||
```
|
||||
|
||||
1. Define the environment variables in the Pod specification.
|
||||
1. Define the environment variables in the Pod specification.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: dapi-test-pod
|
||||
spec:
|
||||
containers:
|
||||
- name: test-container
|
||||
image: k8s.gcr.io/busybox
|
||||
command: [ "/bin/sh", "-c", "env" ]
|
||||
env:
|
||||
- name: SPECIAL_LEVEL_KEY
|
||||
valueFrom:
|
||||
configMapKeyRef:
|
||||
name: special-config
|
||||
key: special.how
|
||||
- name: LOG_LEVEL
|
||||
valueFrom:
|
||||
configMapKeyRef:
|
||||
name: env-config
|
||||
key: log_level
|
||||
restartPolicy: Never
|
||||
```
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: dapi-test-pod
|
||||
spec:
|
||||
containers:
|
||||
- name: test-container
|
||||
image: k8s.gcr.io/busybox
|
||||
command: [ "/bin/sh", "-c", "env" ]
|
||||
env:
|
||||
- name: SPECIAL_LEVEL_KEY
|
||||
valueFrom:
|
||||
configMapKeyRef:
|
||||
name: special-config
|
||||
key: special.how
|
||||
- name: LOG_LEVEL
|
||||
valueFrom:
|
||||
configMapKeyRef:
|
||||
name: env-config
|
||||
key: log_level
|
||||
restartPolicy: Never
|
||||
```
|
||||
|
||||
1. Save the changes to the Pod specification. Now, the Pod's output includes `SPECIAL_LEVEL_KEY=very` and `LOG_LEVEL=info`.
|
||||
1. Save the changes to the Pod specification. Now, the Pod's output includes `SPECIAL_LEVEL_KEY=very` and `LOG_LEVEL=INFO`.
|
||||
|
||||
## Configure all key-value pairs in a ConfigMap as container environment variables
|
||||
|
||||
{{< note >}}
|
||||
**Note:** This functionality is available to users running Kubernetes v1.6 and later.
|
||||
**Note:** This functionality is available in Kubernetes v1.6 and later.
|
||||
{{< /note >}}
|
||||
|
||||
1. Create a ConfigMap containing multiple key-value pairs.
|
||||
1. Create a ConfigMap containing multiple key-value pairs.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
name: special-config
|
||||
namespace: default
|
||||
data:
|
||||
SPECIAL_LEVEL: very
|
||||
SPECIAL_TYPE: charm
|
||||
```
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
name: special-config
|
||||
namespace: default
|
||||
data:
|
||||
SPECIAL_LEVEL: very
|
||||
SPECIAL_TYPE: charm
|
||||
```
|
||||
|
||||
1. Use `envFrom` to define all of the ConfigMap's data as container environment variables. The key from the ConfigMap becomes the environment variable name in the Pod.
|
||||
1. Use `envFrom` to define all of the ConfigMap's data as container environment variables. The key from the ConfigMap becomes the environment variable name in the Pod.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: dapi-test-pod
|
||||
spec:
|
||||
containers:
|
||||
- name: test-container
|
||||
image: k8s.gcr.io/busybox
|
||||
command: [ "/bin/sh", "-c", "env" ]
|
||||
envFrom:
|
||||
- configMapRef:
|
||||
name: special-config
|
||||
restartPolicy: Never
|
||||
```
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: dapi-test-pod
|
||||
spec:
|
||||
containers:
|
||||
- name: test-container
|
||||
image: k8s.gcr.io/busybox
|
||||
command: [ "/bin/sh", "-c", "env" ]
|
||||
envFrom:
|
||||
- configMapRef:
|
||||
name: special-config
|
||||
restartPolicy: Never
|
||||
```
|
||||
|
||||
1. Save the changes to the Pod specification. Now, the Pod's output includes `SPECIAL_LEVEL=very` and `SPECIAL_TYPE=charm`.
|
||||
|
||||
@@ -602,9 +602,9 @@ data:
|
||||
|
||||
### Restrictions
|
||||
|
||||
1. You must create a ConfigMap before referencing it in a Pod specification (unless you mark the ConfigMap as "optional"). If you reference a ConfigMap that doesn't exist, the Pod won't start. Likewise, references to keys that don't exist in the ConfigMap will prevent the pod from starting.
|
||||
- You must create a ConfigMap before referencing it in a Pod specification (unless you mark the ConfigMap as "optional"). If you reference a ConfigMap that doesn't exist, the Pod won't start. Likewise, references to keys that don't exist in the ConfigMap will prevent the pod from starting.
|
||||
|
||||
1. If you use `envFrom` to define environment variables from ConfigMaps, keys that are considered invalid will be skipped. The pod will be allowed to start, but the invalid names will be recorded in the event log (`InvalidVariableNames`). The log message lists each skipped key. For example:
|
||||
- If you use `envFrom` to define environment variables from ConfigMaps, keys that are considered invalid will be skipped. The pod will be allowed to start, but the invalid names will be recorded in the event log (`InvalidVariableNames`). The log message lists each skipped key. For example:
|
||||
|
||||
```shell
|
||||
kubectl get events
|
||||
@@ -612,9 +612,9 @@ data:
|
||||
0s 0s 1 dapi-test-pod Pod Warning InvalidEnvironmentVariableNames {kubelet, 127.0.0.1} Keys [1badkey, 2alsobad] from the EnvFrom configMap default/myconfig were skipped since they are considered invalid environment variable names.
|
||||
```
|
||||
|
||||
1. ConfigMaps reside in a specific [namespace](/docs/concepts/overview/working-with-objects/namespaces/). A ConfigMap can only be referenced by pods residing in the same namespace.
|
||||
- ConfigMaps reside in a specific [namespace](/docs/concepts/overview/working-with-objects/namespaces/). A ConfigMap can only be referenced by pods residing in the same namespace.
|
||||
|
||||
1. Kubelet doesn't support the use of ConfigMaps for pods not found on the API server.
|
||||
- Kubelet doesn't support the use of ConfigMaps for pods not found on the API server.
|
||||
This includes pods created via the Kubelet's --manifest-url flag, --config flag, or the Kubelet REST API.
|
||||
|
||||
{{< note >}}
|
||||
|
||||
@@ -30,7 +30,6 @@ When they do, they are authenticated as a particular Service Account (for exampl
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
@@ -181,7 +180,7 @@ token: ...
|
||||
|
||||
## Add ImagePullSecrets to a service account
|
||||
|
||||
First, create an imagePullSecret, as described [here](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod).
|
||||
First, create an imagePullSecret, as described [here](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod).
|
||||
Next, verify it has been created. For example:
|
||||
|
||||
```shell
|
||||
@@ -296,7 +295,7 @@ spec:
|
||||
```
|
||||
|
||||
The kubelet will request and store the token on behalf of the pod, make the
|
||||
token avaialble to the pod at a configurable file path, and refresh the token as
|
||||
token available to the pod at a configurable file path, and refresh the token as
|
||||
it approaches expiration. Kubelet proactively rotates the token if it is older
|
||||
than 80% of its total TTL, or if the token is older than 24 hours.
|
||||
|
||||
@@ -304,5 +303,3 @@ The application is responsible for reloading the token when it rotates. Periodic
|
||||
reloading (e.g. once every 5 minutes) is sufficient for most usecases.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
@@ -14,7 +14,6 @@ More information can be found on the Kompose website at [http://kompose.io](http
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
@@ -33,7 +32,7 @@ We have multiple ways to install Kompose. Our preferred method is downloading th
|
||||
Kompose is released via GitHub on a three-week cycle, you can see all current releases on the [GitHub release page](https://github.com/kubernetes/kompose/releases).
|
||||
|
||||
```sh
|
||||
# Linux
|
||||
# Linux
|
||||
curl -L https://github.com/kubernetes/kompose/releases/download/v1.1.0/kompose-linux-amd64 -o kompose
|
||||
|
||||
# macOS
|
||||
@@ -98,7 +97,7 @@ you need is an existing `docker-compose.yml` file.
|
||||
services:
|
||||
|
||||
redis-master:
|
||||
image: k8s.gcr.io/redis:e2e
|
||||
image: k8s.gcr.io/redis:e2e
|
||||
ports:
|
||||
- "6379"
|
||||
|
||||
@@ -124,8 +123,8 @@ you need is an existing `docker-compose.yml` file.
|
||||
|
||||
```bash
|
||||
$ kompose up
|
||||
We are going to create Kubernetes Deployments, Services and PersistentVolumeClaims for your Dockerized application.
|
||||
If you need different kind of resources, use the 'kompose convert' and 'kubectl create -f' commands instead.
|
||||
We are going to create Kubernetes Deployments, Services and PersistentVolumeClaims for your Dockerized application.
|
||||
If you need different kind of resources, use the 'kompose convert' and 'kubectl create -f' commands instead.
|
||||
|
||||
INFO Successfully created Service: redis
|
||||
INFO Successfully created Service: web
|
||||
@@ -157,7 +156,7 @@ you need is an existing `docker-compose.yml` file.
|
||||
deployment.apps/redis-master created
|
||||
deployment.apps/redis-slave created
|
||||
```
|
||||
|
||||
|
||||
Your deployments are running in Kubernetes.
|
||||
|
||||
4. Access your application.
|
||||
@@ -252,7 +251,7 @@ INFO Kubernetes file "redis-slave-service.yaml" created
|
||||
INFO Kubernetes file "frontend-deployment.yaml" created
|
||||
INFO Kubernetes file "mlbparks-deployment.yaml" created
|
||||
INFO Kubernetes file "mongodb-deployment.yaml" created
|
||||
INFO Kubernetes file "mongodb-claim0-persistentvolumeclaim.yaml" created
|
||||
INFO Kubernetes file "mongodb-claim0-persistentvolumeclaim.yaml" created
|
||||
INFO Kubernetes file "redis-master-deployment.yaml" created
|
||||
INFO Kubernetes file "redis-slave-deployment.yaml" created
|
||||
|
||||
@@ -261,10 +260,10 @@ mlbparks-deployment.yaml mongodb-service.yaml redis-slave
|
||||
frontend-deployment.yaml mongodb-claim0-persistentvolumeclaim.yaml redis-master-service.yaml
|
||||
frontend-service.yaml mongodb-deployment.yaml redis-slave-deployment.yaml
|
||||
redis-master-deployment.yaml
|
||||
```
|
||||
```
|
||||
|
||||
When multiple docker-compose files are provided the configuration is merged. Any configuration that is common will be over ridden by subsequent file.
|
||||
|
||||
|
||||
### OpenShift
|
||||
|
||||
```sh
|
||||
@@ -290,11 +289,11 @@ It also supports creating buildconfig for build directive in a service. By defau
|
||||
|
||||
```sh
|
||||
$ kompose --provider openshift --file buildconfig/docker-compose.yml convert
|
||||
WARN [foo] Service cannot be created because of missing port.
|
||||
INFO OpenShift Buildconfig using git@github.com:rtnpro/kompose.git::master as source.
|
||||
WARN [foo] Service cannot be created because of missing port.
|
||||
INFO OpenShift Buildconfig using git@github.com:rtnpro/kompose.git::master as source.
|
||||
INFO OpenShift file "foo-deploymentconfig.yaml" created
|
||||
INFO OpenShift file "foo-imagestream.yaml" created
|
||||
INFO OpenShift file "foo-buildconfig.yaml" created
|
||||
INFO OpenShift file "foo-buildconfig.yaml" created
|
||||
```
|
||||
|
||||
**Note**: If you are manually pushing the Openshift artifacts using ``oc create -f``, you need to ensure that you push the imagestream artifact before the buildconfig artifact, to workaround this Openshift issue: https://github.com/openshift/origin/issues/4518 .
|
||||
@@ -418,15 +417,15 @@ Using `kompose up` with a `build` key:
|
||||
|
||||
```none
|
||||
$ kompose up
|
||||
INFO Build key detected. Attempting to build and push image 'docker.io/foo/bar'
|
||||
INFO Building image 'docker.io/foo/bar' from directory 'build'
|
||||
INFO Image 'docker.io/foo/bar' from directory 'build' built successfully
|
||||
INFO Pushing image 'foo/bar:latest' to registry 'docker.io'
|
||||
INFO Attempting authentication credentials 'https://index.docker.io/v1/
|
||||
INFO Successfully pushed image 'foo/bar:latest' to registry 'docker.io'
|
||||
INFO We are going to create Kubernetes Deployments, Services and PersistentVolumeClaims for your Dockerized application. If you need different kind of resources, use the 'kompose convert' and 'kubectl create -f' commands instead.
|
||||
|
||||
INFO Deploying application in "default" namespace
|
||||
INFO Build key detected. Attempting to build and push image 'docker.io/foo/bar'
|
||||
INFO Building image 'docker.io/foo/bar' from directory 'build'
|
||||
INFO Image 'docker.io/foo/bar' from directory 'build' built successfully
|
||||
INFO Pushing image 'foo/bar:latest' to registry 'docker.io'
|
||||
INFO Attempting authentication credentials 'https://index.docker.io/v1/
|
||||
INFO Successfully pushed image 'foo/bar:latest' to registry 'docker.io'
|
||||
INFO We are going to create Kubernetes Deployments, Services and PersistentVolumeClaims for your Dockerized application. If you need different kind of resources, use the 'kompose convert' and 'kubectl create -f' commands instead.
|
||||
|
||||
INFO Deploying application in "default" namespace
|
||||
INFO Successfully created Service: foo
|
||||
INFO Successfully created Deployment: foo
|
||||
|
||||
@@ -479,7 +478,7 @@ The `*-daemonset.yaml` files contain the Daemon Set objects
|
||||
If you want to generate a Chart to be used with [Helm](https://github.com/kubernetes/helm) simply do:
|
||||
|
||||
```sh
|
||||
$ kompose convert -c
|
||||
$ kompose convert -c
|
||||
INFO Kubernetes file "web-svc.yaml" created
|
||||
INFO Kubernetes file "redis-svc.yaml" created
|
||||
INFO Kubernetes file "web-deployment.yaml" created
|
||||
@@ -509,7 +508,7 @@ For example:
|
||||
|
||||
```yaml
|
||||
version: "2"
|
||||
services:
|
||||
services:
|
||||
nginx:
|
||||
image: nginx
|
||||
dockerfile: foobar
|
||||
@@ -517,7 +516,7 @@ services:
|
||||
cap_add:
|
||||
- ALL
|
||||
container_name: foobar
|
||||
labels:
|
||||
labels:
|
||||
kompose.service.type: nodeport
|
||||
```
|
||||
|
||||
|
||||
@@ -24,7 +24,6 @@ answer the following questions:
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
@@ -191,7 +190,7 @@ and in the logs to monitor the state of the auditing subsystem.
|
||||
|
||||
### Truncate
|
||||
|
||||
Both log and webhook backends support batching. As an example, the following is the list of flags
|
||||
Both log and webhook backends support truncating. As an example, the following is the list of flags
|
||||
available for the log backend:
|
||||
|
||||
- `audit-log-truncate-enabled` whether event and batch truncating is enabled.
|
||||
|
||||
@@ -15,7 +15,6 @@ Horizontal Pod Autoscaler, to make decisions.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
|
||||
@@ -7,7 +7,6 @@ title: Debugging Kubernetes nodes with crictl
|
||||
content_template: templates/task
|
||||
---
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
@@ -230,7 +229,7 @@ deleted by the Kubelet.
|
||||
```bash
|
||||
crictl runp pod-config.json
|
||||
```
|
||||
|
||||
|
||||
The ID of the sandbox is returned.
|
||||
|
||||
### Create a container
|
||||
|
||||
@@ -14,7 +14,6 @@ your pods. But there are a number of ways to get even more information about you
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
|
||||
@@ -14,7 +14,6 @@ This is *not* a guide for people who want to debug their cluster. For that you
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
@@ -109,7 +108,7 @@ will not use the command line you intended it to use.
|
||||
|
||||
The first thing to do is to delete your pod and try creating it again with the `--validate` option.
|
||||
For example, run `kubectl create --validate -f mypod.yaml`.
|
||||
If you misspelled `command` as `commnd` then will give an error like this:
|
||||
If you misspelled `command` as `commnd` then will give an error like this:
|
||||
|
||||
```shell
|
||||
I0805 10:43:25.129850 46757 schema.go:126] unknown field: commnd
|
||||
|
||||
@@ -14,7 +14,6 @@ You may also visit [troubleshooting document](/docs/troubleshooting/) for more i
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
|
||||
@@ -14,7 +14,6 @@ This document will hopefully help you to figure out what's going wrong.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
|
||||
@@ -38,7 +38,6 @@ of the potential inaccuracy.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
|
||||
@@ -47,6 +47,11 @@ Get a shell to the running Container:
|
||||
```shell
|
||||
kubectl exec -it shell-demo -- /bin/bash
|
||||
```
|
||||
{{< note >}}
|
||||
|
||||
The double dash symbol "--" is used to separate the arguments you want to pass to the command from the kubectl arguments.
|
||||
|
||||
{{< /note >}}
|
||||
|
||||
In your shell, list the root directory:
|
||||
|
||||
|
||||
@@ -20,7 +20,6 @@ in the Kubernetes logging overview.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
@@ -263,7 +262,7 @@ In this case you need to be able to change the parameters of `DaemonSet` and `Co
|
||||
|
||||
If you're using GKE and Stackdriver Logging is enabled in your cluster, you
|
||||
cannot change its configuration, because it's managed and supported by GKE.
|
||||
However, you can disable the default integration and deploy your own.
|
||||
However, you can disable the default integration and deploy your own.
|
||||
{{< note >}}**Note:** You will have to support and maintain a newly deployed configuration
|
||||
yourself: update the image and configuration, adjust the resources and so on.{{< /note >}}
|
||||
To disable the default logging integration, use the following command:
|
||||
@@ -325,7 +324,7 @@ kubectl get cm fluentd-gcp-config --namespace kube-system -o yaml > fluentd-gcp-
|
||||
```
|
||||
|
||||
Then in the value for the key `containers.input.conf` insert a new filter right after
|
||||
the `source` section.
|
||||
the `source` section.
|
||||
{{< note >}}**Note:** Order is important.{{< /note >}}
|
||||
|
||||
Updating `ConfigMap` in the apiserver is more complicated than updating `DaemonSet`. It's better
|
||||
|
||||
@@ -94,7 +94,7 @@ However, you can use [ConfigMap](/docs/tasks/configure-pod-container/configure-p
|
||||
following the steps:
|
||||
|
||||
* **Step 1:** Change the config files in `config/`.
|
||||
* **Step 2:** Create the ConfigMap `node-problem-detector-config` with `kubectl create configmap
|
||||
* **Step 2:** Create the ConfigMap `node-problem-detector-config` with `kubectl create configmap
|
||||
node-problem-detector-config --from-file=config/`.
|
||||
* **Step 3:** Change the `node-problem-detector.yaml` to use the ConfigMap:
|
||||
|
||||
|
||||
@@ -19,7 +19,6 @@ you're using.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
@@ -103,4 +102,4 @@ problem, such as:
|
||||
* Cloud provider, OS distro, network configuration, and Docker version
|
||||
* Steps to reproduce the problem
|
||||
|
||||
{{% /capture %}}
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -23,7 +23,6 @@ using `kubefed`.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
@@ -41,14 +40,14 @@ for installation instructions for your platform.
|
||||
|
||||
## Getting `kubefed`
|
||||
|
||||
Download the client tarball corresponding to the particular release and
|
||||
Download the client tarball corresponding to the particular release and
|
||||
extract the binaries in the tarball:
|
||||
|
||||
{{< note >}}
|
||||
**Note:** Until Kubernetes version `1.8.x` the federation project was
|
||||
**Note:** Until Kubernetes version `1.8.x` the federation project was
|
||||
maintained as part of the [core kubernetes repo](https://github.com/kubernetes/kubernetes).
|
||||
Between Kubernetes releases `1.8` and `1.9`, the federation project moved into
|
||||
a separate [federation repo](https://github.com/kubernetes/federation), where it is
|
||||
Between Kubernetes releases `1.8` and `1.9`, the federation project moved into
|
||||
a separate [federation repo](https://github.com/kubernetes/federation), where it is
|
||||
now maintained. Consequently, the federation release information is available on the
|
||||
[release page](https://github.com/kubernetes/federation/releases).
|
||||
{{< /note >}}
|
||||
@@ -60,7 +59,7 @@ curl -LO https://storage.googleapis.com/kubernetes-release/release/${RELEASE-VER
|
||||
tar -xzvf kubernetes-client-linux-amd64.tar.gz
|
||||
```
|
||||
{{< note >}}
|
||||
**Note:** The `RELEASE-VERSION` variable should either be set to or replaced with the actual version needed.
|
||||
**Note:** The `RELEASE-VERSION` variable should either be set to or replaced with the actual version needed.
|
||||
{{< /note >}}
|
||||
|
||||
Copy the extracted binary to one of the directories in your `$PATH`
|
||||
@@ -79,7 +78,7 @@ tar -xzvf federation-client-linux-amd64.tar.gz
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
**Note:** The `RELEASE-VERSION` variable should be replaced with one of the release versions available at [federation release page](https://github.com/kubernetes/federation/releases).
|
||||
**Note:** The `RELEASE-VERSION` variable should be replaced with one of the release versions available at [federation release page](https://github.com/kubernetes/federation/releases).
|
||||
{{< /note >}}
|
||||
|
||||
Copy the extracted binary to one of the directories in your `$PATH`
|
||||
@@ -92,7 +91,7 @@ sudo chmod +x /usr/local/bin/kubefed
|
||||
|
||||
### Install kubectl
|
||||
|
||||
You can install a matching version of kubectl using the instructions on
|
||||
You can install a matching version of kubectl using the instructions on
|
||||
the [kubectl install page](https://kubernetes.io/docs/tasks/tools/install-kubectl/).
|
||||
|
||||
## Choosing a host cluster.
|
||||
@@ -177,7 +176,7 @@ without the Google Cloud DNS API scope by default. If you want to use a
|
||||
Google Kubernetes Engine cluster as a Federation host, you must create it using the `gcloud`
|
||||
command with the appropriate value in the `--scopes` field. You cannot
|
||||
modify a Google Kubernetes Engine cluster directly to add this scope, but you can create a
|
||||
new node pool for your cluster and delete the old one.
|
||||
new node pool for your cluster and delete the old one.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** This will cause pods in the cluster to be rescheduled.
|
||||
@@ -200,7 +199,7 @@ gcloud container node-pools delete default-pool --cluster gke-cluster
|
||||
|
||||
`kubefed init` sets up the federation control plane in the host
|
||||
cluster and also adds an entry for the federation API server in your
|
||||
local kubeconfig.
|
||||
local kubeconfig.
|
||||
{{< note >}}
|
||||
**Note:** In the beta release of Kubernetes 1.6, `kubefed init` does not automatically set the current context to the
|
||||
newly deployed federation. You can set the current context manually by running:
|
||||
@@ -436,7 +435,7 @@ Where `<patch-file-name>` is the name of the file you created above.
|
||||
|
||||
## Adding a cluster to a federation
|
||||
|
||||
After you've deployed a federation control plane, you'll need to make that control plane aware of the clusters it should manage.
|
||||
After you've deployed a federation control plane, you'll need to make that control plane aware of the clusters it should manage.
|
||||
|
||||
To join clusters into the federation:
|
||||
|
||||
@@ -463,7 +462,7 @@ To join clusters into the federation:
|
||||
kubefed join gondor --host-cluster-context=rivendell
|
||||
```
|
||||
|
||||
A new context has now been added to your kubeconfig named `fellowship` (after the name of your federation).
|
||||
A new context has now been added to your kubeconfig named `fellowship` (after the name of your federation).
|
||||
|
||||
|
||||
{{< note >}}
|
||||
|
||||
@@ -4,12 +4,11 @@ content_template: templates/task
|
||||
weight: 30
|
||||
---
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
In this example, we will run a Kubernetes Job with multiple parallel
|
||||
worker processes.
|
||||
worker processes.
|
||||
|
||||
In this example, as each pod is created, it picks up one unit of work
|
||||
from a task queue, completes it, deletes it from the queue, and exits.
|
||||
@@ -25,7 +24,6 @@ Here is an overview of the steps in this example:
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
|
||||
@@ -26,7 +26,6 @@ Here is an overview of the steps in this example:
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
|
||||
@@ -12,7 +12,6 @@ non-parallel, use of [Jobs](/docs/concepts/workloads/controllers/jobs-run-to-com
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
|
||||
@@ -17,7 +17,6 @@ and the current limitations.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
@@ -33,7 +32,7 @@ from 1.10.
|
||||
|
||||
Then you have to install GPU drivers from the corresponding vendor on the nodes
|
||||
and run the corresponding device plugin from the GPU vendor
|
||||
([AMD](#deploying-amd-gpu-device-plugin), [NVIDIA](#deploying-nvidia-gpu-device-plugin)).
|
||||
([AMD](#deploying-amd-gpu-device-plugin), [NVIDIA](#deploying-nvidia-gpu-device-plugin)).
|
||||
|
||||
When the above conditions are true, Kubernetes will expose `nvidia.com/gpu` or
|
||||
`amd.com/gpu` as a schedulable resource.
|
||||
|
||||
@@ -191,7 +191,7 @@ zk-pdb 2 1 7s
|
||||
```
|
||||
|
||||
The non-zero value for `ALLOWED-DISRUPTIONS` means that the disruption controller has seen the pods,
|
||||
counted the matching pods, and update the status of the PDB.
|
||||
counted the matching pods, and updated the status of the PDB.
|
||||
|
||||
You can get more information about the status of a PDB with this command:
|
||||
|
||||
|
||||
@@ -19,7 +19,6 @@ This document walks you through an example of enabling Horizontal Pod Autoscaler
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
@@ -386,7 +385,7 @@ section to your HorizontalPodAutoscaler manifest to specify that you need one wo
|
||||
averageValue: 30
|
||||
```
|
||||
|
||||
When possible, it's preferrable to use the custom metric target types instead of external metrics, since it's
|
||||
When possible, it's preferable to use the custom metric target types instead of external metrics, since it's
|
||||
easier for cluster administrators to secure the custom metrics API. The external metrics API potentially allows
|
||||
access to any metric, so cluster administrators should take care when exposing it.
|
||||
|
||||
|
||||
@@ -28,7 +28,6 @@ to match the observed average CPU utilization to the target specified by user.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
@@ -161,8 +160,8 @@ into a desired replica count (e.g. due to an error fetching the metrics
|
||||
from the metrics APIs), scaling is skipped.
|
||||
|
||||
Finally, just before HPA scales the target, the scale reccomendation is recorded. The
|
||||
controller considers all recommendations within a configurable window choosing the
|
||||
highest recommendation from within that window. This value can be configured using the `--horizontal-pod-autoscaler-downscale-stabilization-window` flag, which defaults to 5 minutes.
|
||||
controller considers all recommendations within a configurable window choosing the
|
||||
highest recommendation from within that window. This value can be configured using the `--horizontal-pod-autoscaler-downscale-stabilization-window` flag, which defaults to 5 minutes.
|
||||
This means that scaledowns will occur gradually, smoothing out the impact of rapidly
|
||||
fluctuating metric values.
|
||||
|
||||
|
||||
@@ -42,7 +42,6 @@ Rolling updates are initiated with the `kubectl rolling-update` command:
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
|
||||
@@ -21,7 +21,7 @@ This task shows how to scale a StatefulSet. Scaling a StatefulSet refers to incr
|
||||
* StatefulSets are only available in Kubernetes version 1.5 or later.
|
||||
To check your version of Kubernetes, run `kubectl version`.
|
||||
|
||||
* Not all stateful applications scale nicely. If you are unsure about whether to scale your StatefulSets, see [StatefulSet concepts](/docs/concepts/workloads/controllers/statefulset/) or [StatefulSet tutorial](/docs/tutorials/stateful-application/basic-stateful-set/) for futher information.
|
||||
* Not all stateful applications scale nicely. If you are unsure about whether to scale your StatefulSets, see [StatefulSet concepts](/docs/concepts/workloads/controllers/statefulset/) or [StatefulSet tutorial](/docs/tutorials/stateful-application/basic-stateful-set/) for further information.
|
||||
|
||||
* You should perform scaling only when you are confident that your stateful application
|
||||
cluster is completely healthy.
|
||||
|
||||
@@ -21,7 +21,6 @@ protocol that is similar to the
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
|
||||
@@ -233,7 +233,7 @@ You can install kubectl as part of the Google Cloud SDK.
|
||||
sudo mv ./kubectl /usr/local/bin/kubectl
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="Windows" %}}
|
||||
{{% tab name="Windows" %}}
|
||||
1. Download the latest release {{< param "fullversion" >}} from [this link](https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe).
|
||||
|
||||
Or if you have `curl` installed, use this command:
|
||||
|
||||
Reference in New Issue
Block a user