Merge branch 'master' into fix-restart-always-docs
This commit is contained in:
Marcin Niemira
+5
-5
@@ -149,12 +149,12 @@ users:
|
||||
username: exp
|
||||
```
|
||||
|
||||
The `fake-ca-file`, `fake-cert-file` and `fake-key-file` above is the placeholders
|
||||
for the real path of the certification files. You need change these to the real path
|
||||
of certification files in your environment.
|
||||
The `fake-ca-file`, `fake-cert-file` and `fake-key-file` above are the placeholders
|
||||
for the pathnames of the certificate files. You need change these to the actual pathnames
|
||||
of certificate files in your environment.
|
||||
|
||||
Some times you may want to use base64 encoded data here instead of the path of the
|
||||
certification files, then you need add the suffix `-data` to the keys. For example,
|
||||
Sometimes you may want to use Base64-encoded data embedded here instead of separate
|
||||
certificate files; in that case you need add the suffix `-data` to the keys, for example,
|
||||
`certificate-authority-data`, `client-certificate-data`, `client-key-data`.
|
||||
|
||||
Each context is a triple (cluster, user, namespace). For example, the
|
||||
|
||||
+1
-1
@@ -275,7 +275,7 @@ the version.
|
||||
|
||||
## Webhook conversion
|
||||
|
||||
{{< feature-state state="stable" for_kubernetes_version="1.16" >}}
|
||||
{{< feature-state state="stable" for_k8s_version="v1.16" >}}
|
||||
|
||||
{{< note >}}
|
||||
Webhook conversion is available as beta since 1.15, and as alpha since Kubernetes 1.13. The
|
||||
|
||||
+6
-6
@@ -243,7 +243,7 @@ If you later recreate the same CustomResourceDefinition, it will start out empty
|
||||
|
||||
## Specifying a structural schema
|
||||
|
||||
{{< feature-state state="stable" for_kubernetes_version="1.16" >}}
|
||||
{{< feature-state state="stable" for_k8s_version="v1.16" >}}
|
||||
|
||||
CustomResources traditionally store arbitrary JSON (next to `apiVersion`, `kind` and `metadata`, which is validated by the API server implicitly). With [OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation) a schema can be specified, which is validated during creation and updates, compare below for details and limits of such a schema.
|
||||
|
||||
@@ -364,7 +364,7 @@ Structural schemas are a requirement for `apiextensions.k8s.io/v1`, and disables
|
||||
|
||||
### Pruning versus preserving unknown fields
|
||||
|
||||
{{< feature-state state="stable" for_kubernetes_version="1.16" >}}
|
||||
{{< feature-state state="stable" for_k8s_version="v1.16" >}}
|
||||
|
||||
CustomResourceDefinitions traditionally store any (possibly validated) JSON as is in etcd. This means that unspecified fields (if there is a [OpenAPI v3.0 validation schema](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation) at all) are persisted. This is in contrast to native Kubernetes resources such as a pod where unknown fields are dropped before being persisted to etcd. We call this "pruning" of unknown fields.
|
||||
|
||||
@@ -604,7 +604,7 @@ meaning all finalizers have been executed.
|
||||
|
||||
### Validation
|
||||
|
||||
{{< feature-state state="stable" for_kubernetes_version="1.16" >}}
|
||||
{{< feature-state state="stable" for_k8s_version="v1.16" >}}
|
||||
|
||||
Validation of custom objects is possible via
|
||||
[OpenAPI v3 schemas](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#schemaObject) or [validatingadmissionwebhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook). In `apiextensions.k8s.io/v1` schemas are required, in `apiextensions.k8s.io/v1beta1` they are optional.
|
||||
@@ -781,7 +781,7 @@ crontab "my-new-cron-object" created
|
||||
|
||||
### Defaulting
|
||||
|
||||
{{< feature-state state="stable" for_kubernetes_version="1.17" >}}
|
||||
{{< feature-state state="stable" for_k8s_version="v1.17" >}}
|
||||
|
||||
{{< note >}}
|
||||
To use defaulting, your CustomResourceDefinition must use API version `apiextensions.k8s.io/v1`.
|
||||
@@ -866,7 +866,7 @@ Default values for `metadata` fields of `x-kubernetes-embedded-resources: true`
|
||||
|
||||
### Publish Validation Schema in OpenAPI v2
|
||||
|
||||
{{< feature-state state="stable" for_kubernetes_version="1.16" >}}
|
||||
{{< feature-state state="stable" for_k8s_version="v1.16" >}}
|
||||
|
||||
{{< note >}}
|
||||
OpenAPI v2 Publishing is available as beta since 1.15, and as alpha since 1.14. The
|
||||
@@ -1051,7 +1051,7 @@ The column's `format` controls the style used when `kubectl` prints the value.
|
||||
|
||||
### Subresources
|
||||
|
||||
{{< feature-state state="stable" for_kubernetes_version="1.16" >}}
|
||||
{{< feature-state state="stable" for_k8s_version="v1.16" >}}
|
||||
|
||||
Custom resources support `/status` and `/scale` subresources.
|
||||
|
||||
|
||||
@@ -14,7 +14,7 @@ In upcoming releases, Cloud Controller Manager will
|
||||
be the preferred way to integrate Kubernetes with any cloud. This will ensure cloud providers
|
||||
can develop their features independently from the core Kubernetes release cycles.
|
||||
|
||||
{{< feature-state for_k8s_version="1.8" state="alpha" >}}
|
||||
{{< feature-state for_k8s_version="v1.8" state="alpha" >}}
|
||||
|
||||
Before going into how to build your own cloud controller manager, some background on how it works under the hood is helpful. The cloud controller manager is code from `kube-controller-manager` utilizing Go interfaces to allow implementations from any cloud to be plugged in. Most of the scaffolding and generic controller implementations will be in core, but it will always exec out to the cloud interfaces it is provided, so long as the [cloud provider interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go#L42-L62) is satisfied.
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@ content_template: templates/task
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
{{< feature-state for_k8s_version="1.5" state="alpha" >}}
|
||||
{{< feature-state for_k8s_version="v1.5" state="alpha" >}}
|
||||
|
||||
You can replicate Kubernetes masters in `kube-up` or `kube-down` scripts for Google Compute Engine.
|
||||
This document describes how to use kube-up/down scripts to manage highly available (HA) masters and how HA masters are implemented for use with GCE.
|
||||
|
||||
@@ -50,18 +50,18 @@ The upgrade workflow at high level is the following:
|
||||
|
||||
## Determine which version to upgrade to
|
||||
|
||||
1. Find the latest stable 1.17 version:
|
||||
1. Find the latest stable 1.18 version:
|
||||
|
||||
{{< tabs name="k8s_install_versions" >}}
|
||||
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
|
||||
apt update
|
||||
apt-cache madison kubeadm
|
||||
# find the latest 1.17 version in the list
|
||||
# find the latest 1.18 version in the list
|
||||
# it should look like 1.18.x-00, where x is the latest patch
|
||||
{{% /tab %}}
|
||||
{{% tab name="CentOS, RHEL or Fedora" %}}
|
||||
yum list --showduplicates kubeadm --disableexcludes=kubernetes
|
||||
# find the latest 1.17 version in the list
|
||||
# find the latest 1.18 version in the list
|
||||
# it should look like 1.18.x-0, where x is the latest patch
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
@@ -107,7 +107,7 @@ If you attempt to use `kubectl exec` to create a shell you will see an error
|
||||
because there is no shell in this container image.
|
||||
|
||||
```shell
|
||||
kubectl exec -it pause -- sh
|
||||
kubectl exec -it ephemeral-demo -- sh
|
||||
```
|
||||
|
||||
```
|
||||
|
||||
@@ -43,21 +43,39 @@ To enable the rolling update feature of a DaemonSet, you must set its
|
||||
You may want to set [`.spec.updateStrategy.rollingUpdate.maxUnavailable`](/docs/concepts/workloads/controllers/deployment/#max-unavailable) (default
|
||||
to 1) and [`.spec.minReadySeconds`](/docs/concepts/workloads/controllers/deployment/#min-ready-seconds) (default to 0) as well.
|
||||
|
||||
### Creating a DaemonSet with `RollingUpdate` update strategy
|
||||
|
||||
### Step 1: Checking DaemonSet `RollingUpdate` update strategy
|
||||
This YAML file specifies a DaemonSet with an update strategy as 'RollingUpdate'
|
||||
|
||||
First, check the update strategy of your DaemonSet, and make sure it's set to
|
||||
{{< codenew file="controllers/fluentd-daemonset.yaml" >}}
|
||||
|
||||
After verifying the update strategy of the DaemonSet manifest, create the DaemonSet:
|
||||
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/examples/controllers/fluentd-daemonset.yaml
|
||||
```
|
||||
|
||||
Alternatively, use `kubectl apply` to create the same DaemonSet if you plan to
|
||||
update the DaemonSet with `kubectl apply`.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/controllers/fluentd-daemonset.yaml
|
||||
```
|
||||
|
||||
### Checking DaemonSet `RollingUpdate` update strategy
|
||||
|
||||
Check the update strategy of your DaemonSet, and make sure it's set to
|
||||
`RollingUpdate`:
|
||||
|
||||
```shell
|
||||
kubectl get ds/<daemonset-name> -o go-template='{{.spec.updateStrategy.type}}{{"\n"}}'
|
||||
kubectl get ds/fluentd-elasticsearch -o go-template='{{.spec.updateStrategy.type}}{{"\n"}}' -n kube-system
|
||||
```
|
||||
|
||||
If you haven't created the DaemonSet in the system, check your DaemonSet
|
||||
manifest with the following command instead:
|
||||
|
||||
```shell
|
||||
kubectl apply -f ds.yaml --dry-run=client -o go-template='{{.spec.updateStrategy.type}}{{"\n"}}'
|
||||
kubectl apply -f https://k8s.io/examples/controllers/fluentd-daemonset.yaml --dry-run=client -o go-template='{{.spec.updateStrategy.type}}{{"\n"}}'
|
||||
```
|
||||
|
||||
The output from both commands should be:
|
||||
@@ -69,28 +87,13 @@ RollingUpdate
|
||||
If the output isn't `RollingUpdate`, go back and modify the DaemonSet object or
|
||||
manifest accordingly.
|
||||
|
||||
### Step 2: Creating a DaemonSet with `RollingUpdate` update strategy
|
||||
|
||||
If you have already created the DaemonSet, you may skip this step and jump to
|
||||
step 3.
|
||||
|
||||
After verifying the update strategy of the DaemonSet manifest, create the DaemonSet:
|
||||
|
||||
```shell
|
||||
kubectl create -f ds.yaml
|
||||
```
|
||||
|
||||
Alternatively, use `kubectl apply` to create the same DaemonSet if you plan to
|
||||
update the DaemonSet with `kubectl apply`.
|
||||
|
||||
```shell
|
||||
kubectl apply -f ds.yaml
|
||||
```
|
||||
|
||||
### Step 3: Updating a DaemonSet template
|
||||
### Updating a DaemonSet template
|
||||
|
||||
Any updates to a `RollingUpdate` DaemonSet `.spec.template` will trigger a rolling
|
||||
update. This can be done with several different `kubectl` commands.
|
||||
update. Let's update the DaemonSet by applying a new YAML file. This can be done with several different `kubectl` commands.
|
||||
|
||||
{{< codenew file="controllers/fluentd-daemonset-update.yaml" >}}
|
||||
|
||||
#### Declarative commands
|
||||
|
||||
@@ -99,21 +102,17 @@ If you update DaemonSets using
|
||||
use `kubectl apply`:
|
||||
|
||||
```shell
|
||||
kubectl apply -f ds-v2.yaml
|
||||
kubectl apply -f https://k8s.io/examples/application/fluentd-daemonset-update.yaml
|
||||
```
|
||||
|
||||
#### Imperative commands
|
||||
|
||||
If you update DaemonSets using
|
||||
[imperative commands](/docs/tasks/manage-kubernetes-objects/imperative-command/),
|
||||
use `kubectl edit` or `kubectl patch`:
|
||||
use `kubectl edit` :
|
||||
|
||||
```shell
|
||||
kubectl edit ds/<daemonset-name>
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl patch ds/<daemonset-name> -p=<strategic-merge-patch>
|
||||
kubectl edit ds/fluentd-elasticsearch -n kube-system
|
||||
```
|
||||
|
||||
##### Updating only the container image
|
||||
@@ -122,21 +121,21 @@ If you just need to update the container image in the DaemonSet template, i.e.
|
||||
`.spec.template.spec.containers[*].image`, use `kubectl set image`:
|
||||
|
||||
```shell
|
||||
kubectl set image ds/<daemonset-name> <container-name>=<container-new-image>
|
||||
kubectl set image ds/fluentd-elasticsearch fluentd-elasticsearch=quay.io/fluentd_elasticsearch/fluentd:v2.6.0 -n kube-system
|
||||
```
|
||||
|
||||
### Step 4: Watching the rolling update status
|
||||
### Watching the rolling update status
|
||||
|
||||
Finally, watch the rollout status of the latest DaemonSet rolling update:
|
||||
|
||||
```shell
|
||||
kubectl rollout status ds/<daemonset-name>
|
||||
kubectl rollout status ds/fluentd-elasticsearch -n kube-system
|
||||
```
|
||||
|
||||
When the rollout is complete, the output is similar to this:
|
||||
|
||||
```shell
|
||||
daemonset "<daemonset-name>" successfully rolled out
|
||||
daemonset "fluentd-elasticsearch" successfully rolled out
|
||||
```
|
||||
|
||||
## Troubleshooting
|
||||
@@ -156,7 +155,7 @@ When this happens, find the nodes that don't have the DaemonSet pods scheduled o
|
||||
by comparing the output of `kubectl get nodes` and the output of:
|
||||
|
||||
```shell
|
||||
kubectl get pods -l <daemonset-selector-key>=<daemonset-selector-value> -o wide
|
||||
kubectl get pods -l name=fluentd-elasticsearch -o wide -n kube-system
|
||||
```
|
||||
|
||||
Once you've found those nodes, delete some non-DaemonSet pods from the node to
|
||||
@@ -183,6 +182,13 @@ If `.spec.minReadySeconds` is specified in the DaemonSet, clock skew between
|
||||
master and nodes will make DaemonSet unable to detect the right rollout
|
||||
progress.
|
||||
|
||||
## Clean up
|
||||
|
||||
Delete DaemonSet from a namespace :
|
||||
|
||||
```shell
|
||||
kubectl delete ds fluentd-elasticsearch -n kube-system
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@ title: Schedule GPUs
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
{{< feature-state state="beta" for_k8s_version="1.10" >}}
|
||||
{{< feature-state state="beta" for_k8s_version="v1.10" >}}
|
||||
|
||||
Kubernetes includes **experimental** support for managing AMD and NVIDIA GPUs
|
||||
(graphical processing units) across several nodes.
|
||||
|
||||
@@ -75,7 +75,7 @@ metrics-server, which needs to be launched separately. See
|
||||
for instructions. The HorizontalPodAutoscaler can also fetch metrics directly from Heapster.
|
||||
|
||||
{{< note >}}
|
||||
{{< feature-state state="deprecated" for_k8s_version="1.11" >}}
|
||||
{{< feature-state state="deprecated" for_k8s_version="v1.11" >}}
|
||||
Fetching metrics from Heapster is deprecated as of Kubernetes 1.11.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
@@ -97,7 +97,7 @@ a Deployment that runs the nginx:1.14.2 Docker image:
|
||||
## Updating the deployment
|
||||
|
||||
You can update the deployment by applying a new YAML file. This YAML file
|
||||
specifies that the deployment should be updated to use nginx 1.8.
|
||||
specifies that the deployment should be updated to use nginx 1.16.1.
|
||||
|
||||
{{< codenew file="application/deployment-update.yaml" >}}
|
||||
|
||||
|
||||
+5
@@ -0,0 +1,5 @@
|
||||
---
|
||||
title: "Setup Konnectivity Service"
|
||||
weight: 20
|
||||
---
|
||||
|
||||
@@ -0,0 +1,52 @@
|
||||
---
|
||||
title: Set up Konnectivity service
|
||||
content_template: templates/task
|
||||
weight: 70
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
The Konnectivity service provides TCP level proxy for the Master → Cluster
|
||||
communication.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## Configure the Konnectivity service
|
||||
|
||||
First, you need to configure the API Server to use the Konnectivity service
|
||||
to direct its network traffic to cluster nodes:
|
||||
|
||||
1. Set the `--egress-selector-config-file` flag of the API Server, it is the
|
||||
path to the API Server egress configuration file.
|
||||
1. At the path, create a configuration file. For example,
|
||||
|
||||
{{< codenew file="admin/konnectivity/egress-selector-configuration.yaml" >}}
|
||||
|
||||
Next, you need to deploy the Konnectivity server and agents.
|
||||
[kubernetes-sigs/apiserver-network-proxy](https://github.com/kubernetes-sigs/apiserver-network-proxy)
|
||||
is a reference implementation.
|
||||
|
||||
Deploy the Konnectivity server on your master node. The provided yaml assumes
|
||||
that the Kubernetes components are deployed as a {{< glossary_tooltip text="static Pod"
|
||||
term_id="static-pod" >}} in your cluster. If not, you can deploy the Konnectivity
|
||||
server as a DaemonSet.
|
||||
|
||||
{{< codenew file="admin/konnectivity/konnectivity-server.yaml" >}}
|
||||
|
||||
Then deploy the Konnectivity agents in your cluster:
|
||||
|
||||
{{< codenew file="admin/konnectivity/konnectivity-agent.yaml" >}}
|
||||
|
||||
Last, if RBAC is enabled in your cluster, create the relevant RBAC rules:
|
||||
|
||||
{{< codenew file="admin/konnectivity/konnectivity-rbac.yaml" >}}
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -59,7 +59,7 @@ You must use a kubectl version that is within one minor version difference of yo
|
||||
|
||||
{{< tabs name="kubectl_install" >}}
|
||||
{{< tab name="Ubuntu, Debian or HypriotOS" codelang="bash" >}}
|
||||
sudo apt-get update && sudo apt-get install -y apt-transport-https
|
||||
sudo apt-get update && sudo apt-get install -y apt-transport-https gnupg2
|
||||
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
|
||||
echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list
|
||||
sudo apt-get update
|
||||
@@ -419,7 +419,7 @@ You can test if you have bash-completion v2 already installed with `type _init_c
|
||||
brew install bash-completion@2
|
||||
```
|
||||
|
||||
As stated in the output of this command, add the following to your `~/.bashrc` file:
|
||||
As stated in the output of this command, add the following to your `~/.bash_profile` file:
|
||||
|
||||
```shell
|
||||
export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d"
|
||||
@@ -432,10 +432,10 @@ Reload your shell and verify that bash-completion v2 is correctly installed with
|
||||
|
||||
You now have to ensure that the kubectl completion script gets sourced in all your shell sessions. There are multiple ways to achieve this:
|
||||
|
||||
- Source the completion script in your `~/.bashrc` file:
|
||||
- Source the completion script in your `~/.bash_profile` file:
|
||||
|
||||
```shell
|
||||
echo 'source <(kubectl completion bash)' >>~/.bashrc
|
||||
echo 'source <(kubectl completion bash)' >>~/.bash_profile
|
||||
|
||||
```
|
||||
|
||||
@@ -448,8 +448,8 @@ You now have to ensure that the kubectl completion script gets sourced in all yo
|
||||
- If you have an alias for kubectl, you can extend shell completion to work with that alias:
|
||||
|
||||
```shell
|
||||
echo 'alias k=kubectl' >>~/.bashrc
|
||||
echo 'complete -F __start_kubectl k' >>~/.bashrc
|
||||
echo 'alias k=kubectl' >>~/.bash_profile
|
||||
echo 'complete -F __start_kubectl k' >>~/.bash_profile
|
||||
```
|
||||
|
||||
- If you installed kubectl with Homebrew (as explained [above](#install-with-homebrew-on-macos)), then the kubectl completion script should already be in `/usr/local/etc/bash_completion.d/kubectl`. In that case, you don't need to do anything.
|
||||
|
||||
Reference in New Issue
Block a user