removing toc shortcode. (#10720)
This commit is contained in:
@@ -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 %}}
|
||||
|
||||
|
||||
@@ -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 %}}
|
||||
|
||||
|
||||
+1
-2
@@ -18,7 +18,6 @@ vacated by the evicted critical add-on pod or the amount of resources available
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
@@ -51,7 +50,7 @@ killed for this purpose. Please ensure that rescheduler is not enabled along wit
|
||||
|
||||
Rescheduler doesn't have any user facing configuration (component config) or API.
|
||||
|
||||
### Marking pod as critical when using Rescheduler.
|
||||
### Marking pod as critical when using Rescheduler.
|
||||
|
||||
To be considered critical, the pod has to run in the `kube-system` namespace (configurable via flag) and
|
||||
|
||||
|
||||
@@ -14,7 +14,6 @@ This document describes how to use kube-up/down scripts to manage highly availab
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
|
||||
@@ -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>}}
|
||||
|
||||
|
||||
@@ -13,7 +13,6 @@ This guide explains how to use events in federation control plane to help in deb
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
|
||||
@@ -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 %}}
|
||||
|
||||
|
||||
@@ -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
|
||||
@@ -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 %}}
|
||||
|
||||
|
||||
@@ -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 %}}
|
||||
|
||||
|
||||
@@ -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 %}}
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -19,7 +19,6 @@ This document walks you through an example of enabling Horizontal Pod Autoscaler
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
@@ -28,7 +28,6 @@ to match the observed average CPU utilization to the target specified by user.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
@@ -161,7 +160,7 @@ 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
|
||||
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,6 @@ protocol that is similar to the
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
|
||||
Reference in New Issue
Block a user