From 2085cf666b55af1c0cdeaf78b927bb9c6798bb96 Mon Sep 17 00:00:00 2001 From: Martin Dietze Date: Wed, 14 Mar 2018 16:30:05 +0100 Subject: [PATCH 01/18] Guide for upgrading kubeadm HA clusters. (#7557) * Guide for upgrading kubeadm HA clusters. * kubeadm HA upgrade guide: text changes from code review. * Guide for upgrading kubeadm HA clusters: proposed changes after second round of code review. --- _data/tasks.yml | 1 + .../setup-tools/kubeadm/kubeadm-upgrade.md | 1 + .../independent/create-cluster-kubeadm.md | 1 + .../administer-cluster/kubeadm-upgrade-ha.md | 133 ++++++++++++++++++ 4 files changed, 136 insertions(+) create mode 100644 docs/tasks/administer-cluster/kubeadm-upgrade-ha.md diff --git a/_data/tasks.yml b/_data/tasks.yml index 9fc290e8e1..e9210213bc 100644 --- a/_data/tasks.yml +++ b/_data/tasks.yml @@ -151,6 +151,7 @@ toc: - docs/tasks/administer-cluster/kubeadm-upgrade-1-7.md - docs/tasks/administer-cluster/kubeadm-upgrade-1-8.md - docs/tasks/administer-cluster/kubeadm-upgrade-1-9.md + - docs/tasks/administer-cluster/kubeadm-upgrade-ha.md - docs/tasks/administer-cluster/namespaces.md - docs/tasks/administer-cluster/namespaces-walkthrough.md - docs/tasks/administer-cluster/dns-horizontal-autoscaling.md diff --git a/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md b/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md index d65b7d5947..6d115d0fd1 100755 --- a/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md +++ b/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md @@ -23,6 +23,7 @@ Please check these documents out for more detailed how-to-upgrade guidance: * [1.8.x to 1.8.y upgrades](/docs/tasks/administer-cluster/kubeadm-upgrade-1-8/) * [1.8.x to 1.9.x upgrades](/docs/tasks/administer-cluster/kubeadm-upgrade-1-9/) * [1.9.x to 1.9.y upgrades](/docs/tasks/administer-cluster/kubeadm-upgrade-1-9/) + * [1.9.x to 1.9.y HA cluster upgrades](/docs/tasks/administer-cluster/kubeadm-upgrade-ha/) ## kubeadm upgrade plan {#cmd-upgrade-plan} {% include_relative generated/kubeadm_upgrade_plan.md %} diff --git a/docs/setup/independent/create-cluster-kubeadm.md b/docs/setup/independent/create-cluster-kubeadm.md index b8ddcadcff..6586778372 100644 --- a/docs/setup/independent/create-cluster-kubeadm.md +++ b/docs/setup/independent/create-cluster-kubeadm.md @@ -485,6 +485,7 @@ Instructions for upgrading kubeadm clusters are available for: * [1.8.x to 1.8.y upgrades](/docs/tasks/administer-cluster/kubeadm-upgrade-1-8/) * [1.8 to 1.9 upgrades/downgrades](/docs/tasks/administer-cluster/kubeadm-upgrade-1-9/) * [1.9.x to 1.9.y upgrades](/docs/tasks/administer-cluster/kubeadm-upgrade-1-9/) + * [1.9.x to 1.9.y HA cluster upgrades](/docs/tasks/administer-cluster/kubeadm-upgrade-ha/) ## Explore other add-ons {#other-addons} diff --git a/docs/tasks/administer-cluster/kubeadm-upgrade-ha.md b/docs/tasks/administer-cluster/kubeadm-upgrade-ha.md new file mode 100644 index 0000000000..0da21d9bb1 --- /dev/null +++ b/docs/tasks/administer-cluster/kubeadm-upgrade-ha.md @@ -0,0 +1,133 @@ +--- +reviewers: +- jamiehannaford +- luxas +- timothysc +- jbeda +title: Upgrading kubeadm HA clusters from 1.9.x to 1.9.y +--- + +{% capture overview %} + +This guide is for upgrading `kubeadm` HA clusters from version 1.9.x to 1.9.y where `y > x`. The term "`kubeadm` HA clusters" refers to clusters of more than one master node created with `kubeadm`. To set up an HA cluster for Kubernetes version 1.9.x `kubeadm` requires additional manual steps. See [Creating HA clusters with kubeadm](/docs/setup/independent/high-availability/) for instructions on how to do this. The upgrade procedure described here targets clusters created following those very instructions. See [Upgrading/downgrading kubeadm clusters between v1.8 to v1.9](/docs/tasks/administer-cluster/kubeadm-upgrade-1-9/) for more instructions on how to create an HA cluster with `kubeadm`. + +{% endcapture %} + +{% capture prerequisites %} + +Before proceeding: + +- You need to have a functional `kubeadm` HA cluster running version 1.9.0 or higher in order to use the process described here. +- Make sure you read the [release notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.9.md) carefully. +- Note that `kubeadm upgrade` will not touch any of your workloads, only Kubernetes-internal components. As a best-practice you should back up anything important to you. For example, any application-level state, such as a database and application might depend on (like MySQL or MongoDB) should be backed up beforehand. +- Read [Upgrading/downgrading kubeadm clusters between v1.8 to v1.9](/docs/tasks/administer-cluster/kubeadm-upgrade-1-9/) to learn about the relevant prerequisites. + +{% endcapture %} + +{% capture steps %} + +## Preparation + +Some preparation is needed prior to starting the upgrade. First download the version of `kubeadm` that matches the version of Kubernetes that you are upgrading to: + +```shell +# Use the latest stable release or manually specify a +# released Kubernetes version +export VERSION=$(curl -sSL https://dl.k8s.io/release/stable.txt) +export ARCH=amd64 # or: arm, arm64, ppc64le, s390x +curl -sSL https://dl.k8s.io/release/${VERSION}/bin/linux/${ARCH}/kubeadm > /tmp/kubeadm +chmod a+rx /tmp/kubeadm +``` + +Copy this file to `/tmp` on your primary master if necessary. Run this command for checking prerequisites and determining the versions you will receive: + +```shell +/tmp/kubeadm upgrade plan +``` + +If the prerequisites are met you'll get a summary of the software versions kubeadm will upgrade to, like this: + + Upgrade to the latest stable version: + + COMPONENT CURRENT AVAILABLE + API Server v1.9.0 v1.9.2 + Controller Manager v1.9.0 v1.9.2 + Scheduler v1.9.0 v1.9.2 + Kube Proxy v1.9.0 v1.9.2 + Kube DNS 1.14.5 1.14.7 + Etcd 3.2.7 3.1.11 + +**Caution:** Currently the only supported configuration for kubeadm HA clusters requires the use of an externally managed etcd cluster. Upgrading etcd is not supported as a part of the upgrade. If necessary you will have to upgrade the etcd cluster according to [etcd's upgrade instructions](/docs/tasks/administer-cluster/configure-upgrade-etcd/), which is beyond the scope of these instructions. +{: .caution} + +## Upgrading your control plane + +The following procedure must be applied on a single master node and repeated for each subsequent master node sequentially. + +Before initiating the upgrade with `kubeadm` `configmap/kubeadm-config` needs to be modified for the current master host. Replace any hard reference to a master host name with the current master hosts' name: + +```shell +kubectl get configmap -n kube-system kubeadm-config -o yaml >/tmp/kubeadm-config-cm.yaml +sed -i 's/^\([ \t]*nodeName:\).*/\1 /' /tmp/kubeadm-config-cm.yaml +kubectl apply -f /tmp/kubeadm-config-cm.yaml --force +``` + +Now the upgrade process can start. Use the target version determined in the preparation step and run the following command (press “y” when prompted): + +```shell +/tmp/kubeadm upgrade apply v +``` + +If the operation was successful you’ll get a message like this: + + [upgrade/successful] SUCCESS! Your cluster was upgraded to "v1.9.2". Enjoy! + +To upgrade the cluster with CoreDNS as the default internal DNS, invoke `kubeadm upgrade apply` with the `--feature-gates=CoreDNS=true` flag. + +Next, manually upgrade your CNI provider + +Your Container Network Interface (CNI) provider may have its own upgrade instructions to follow. Check the [addons](/docs/concepts/cluster-administration/addons/) page to find your CNI provider and see if there are additional upgrade steps necessary. + +**Note:** The `kubeadm upgrade apply` step has been known to fail when run initially on the secondary masters (timed out waiting for the restarted static pods to come up). It should succeed if retried after a minute or two. +{: .note} + +## Upgrade base software packages + +At this point all the static pod manifests in your cluster, for example API Server, Controller Manager, Scheduler, Kube Proxy have been upgraded, however the base software, for example `kubelet`, `kubectl`, `kubeadm` installed on your nodes’ OS are still of the old version. For upgrading the base software packages we will upgrade them and restart services on all nodes one by one: + +```shell +# use your distro's package manager, e.g. 'yum' on RH-based systems +# for the versions stick to kubeadm's output (see above) +yum install -y kubelet- kubectl- kubeadm- kubernetes-cni- +systemctl restart kubelet +``` + +In this example an _rpm_-based system is assumed and `yum` is used for installing the upgraded software. On _deb_-based systems it will be `apt-get update` and then `apt-get install =` for all packages. + +Now the new version of the `kubelet` should be running on the host. Verify this using the following command on the respective host: + +```shell +systemctl status kubelet +``` + +Verify that the upgraded node is available again by executing the following from wherever you run `kubectl` commands: + +```shell +kubectl get nodes +``` + +If the `STATUS` column of the above command shows `Ready` for the upgraded host, you can continue (you may have to repeat this for a couple of time before the node gets `Ready`). + +## If something goes wrong + +If the upgrade fails the situation afterwards depends on the phase in which things went wrong: + +1. If `/tmp/kubeadm upgrade apply` failed to upgrade the cluster it will try to perform a rollback. Hence if that happened on the first master, chances are pretty good that the cluster is still intact. + + You can run `/tmp/kubeadm upgrade apply` again as it is idempotent and should eventually make sure the actual state is the desired state you are declaring. You can use `/tmp/kubeadm upgrade apply` to change a running cluster with `x.x.x --> x.x.x` with `--force`, which can be used to recover from a bad state. + +2. If `/tmp/kubeadm upgrade apply` on one of the secondary masters failed you still have a working, upgraded cluster, but with the secondary masters in a somewhat undefined condition. You will have to find out what went wrong and join the secondaries manually. As mentioned above, sometimes upgrading one of the secondary masters fails waiting for the restarted static pods first, but succeeds when the operation is simply repeated after a little pause of one or two minutes. + +{% endcapture %} + +{% include templates/task.md %} From 1549d297835ad3dcfa750dd3f87aa799d0cc4b95 Mon Sep 17 00:00:00 2001 From: Kai Chen Date: Wed, 14 Mar 2018 13:32:03 -0700 Subject: [PATCH 02/18] Point the KubeletConfig doc to the release-1.9 code base (#7696) The version will be updated to v1beta1 with the official 1.10 release. --- docs/tasks/administer-cluster/kubelet-config-file.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/tasks/administer-cluster/kubelet-config-file.md b/docs/tasks/administer-cluster/kubelet-config-file.md index 42e85e6b65..424ad3a971 100644 --- a/docs/tasks/administer-cluster/kubelet-config-file.md +++ b/docs/tasks/administer-cluster/kubelet-config-file.md @@ -27,7 +27,7 @@ providing parameters via a config file, which simplifies node deployment. The subset of the Kubelet's configuration that can be configured via a file is defined by the `KubeletConfiguration` struct -[here (v1alpha1)](https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/apis/kubeletconfig/v1alpha1/types.go). +[here (v1alpha1)](https://github.com/kubernetes/kubernetes/blob/release-1.9/pkg/kubelet/apis/kubeletconfig/v1alpha1/types.go). The configuration file must be a JSON or YAML representation of the parameters in this struct. Note that this structure, and thus the config file API, is still considered alpha and is not subject to stability guarantees. From f5558e0e57199138ebda183152c3a008d7d34eb4 Mon Sep 17 00:00:00 2001 From: DiamondYuan <541832074@qq.com> Date: Thu, 15 Mar 2018 04:45:05 +0800 Subject: [PATCH 03/18] Fix js error in homepage (#7680) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit When document.querySelector('#docsToc') is null ,get TypeError Cannot read property 'querySelector' of null 。 --- _includes/footer-scripts.html | 1 + 1 file changed, 1 insertion(+) diff --git a/_includes/footer-scripts.html b/_includes/footer-scripts.html index 091545d12a..07f1e86bd8 100644 --- a/_includes/footer-scripts.html +++ b/_includes/footer-scripts.html @@ -32,6 +32,7 @@ ga('send', 'pageview'); function hideNav(toc){ if (!toc) toc = document.querySelector('#docsToc') + if (!toc) return var container = toc.querySelector('.container') // container is built dynamically, so it may not be present on the first runloop From 49a81e1a69a0d7d0b8f98bf7119583b025517792 Mon Sep 17 00:00:00 2001 From: Chao Xu Date: Wed, 14 Mar 2018 18:40:25 -0700 Subject: [PATCH 04/18] Update the doc on admission webhooks (#7733) --- .../admin/extensible-admission-controllers.md | 317 +++++++++--------- 1 file changed, 163 insertions(+), 154 deletions(-) diff --git a/docs/admin/extensible-admission-controllers.md b/docs/admin/extensible-admission-controllers.md index 7e67c2d252..afe5d58308 100644 --- a/docs/admin/extensible-admission-controllers.md +++ b/docs/admin/extensible-admission-controllers.md @@ -4,6 +4,7 @@ reviewers: - lavalamp - whitlockjc - caesarxuchao +- deads2k title: Dynamic Admission Control --- @@ -20,11 +21,169 @@ the following: * They need to be compiled into kube-apiserver. * They are only configurable when the apiserver starts up. -1.7 introduces two alpha features, *Initializers* and *External Admission -Webhooks*, that address these limitations. These features allow admission -controllers to be developed out-of-tree and configured at runtime. +Two features, *Admission Webhooks* (beta in 1.9) and *Initializers* (alpha), +address these limitations. They allow admission controllers to be developed +out-of-tree and configured at runtime. -This page describes how to use Initializers and External Admission Webhooks. +This page describes how to use Admission Webhooks and Initializers. + +## Admission Webhooks + +### What are admission webhooks? + +Admission webhooks are HTTP callbacks that receive admission requests and do +something with them. You can define two types of admission webhooks, +[ValidatingAdmissionWebhooks](/docs/admin/admission-controllers.md#validatingadmissionwebhook-alpha-in-18-beta-in-19) +and +[MutatingAdmissionWebhooks](/docs/admin/admission-controllers.md#mutatingadmissionwebhook-beta-in-19). +With `ValidatingAdmissionWebhooks`, you may reject requests to enforce custom +admission policies. With `MutatingAdmissionWebhooks`, you may change requests to +enforce custom defaults. + +### Experimenting with admission webhooks + +Admission webhooks are essentially part of the cluster control-plane. You should +write and deploy them with great caution. Please read the [user +guides](https://github.com/kubernetes/website/pull/6836/files)(WIP) for +instructions if you intend to write/deploy production-grade admission webhooks. +In the following, we describe how to quickly experiment with admission webhooks. + +### Prerequisites + +* Ensure that the Kubernetes cluster is at least as new as v1.9. + +* Ensure that MutatingAdmissionWebhook and ValidatingAdmissionWebhook + admission controllers are enabled. + [Here](/docs/admin/admission-controllers.md#is-there-a-recommended-set-of-admission-controllers-to-use) + is a recommended set of admission controllers to enable in general. + +* Ensure that the admissionregistration.k8s.io/v1beta1 API is enabled. + +### Write an admission webhook server + +Please refer to the implementation of the [admission webhook +server](https://github.com/kubernetes/kubernetes/blob/v1.10.0-beta.1/test/images/webhook/main.go) +that is validated in a Kubernetes e2e test. The webhook handles the +`admissionReview` requests sent by the apiservers, and sends back its decision +wrapped in `admissionResponse`. + +The example admission webhook server leaves the `ClientAuth` field +[empty](https://github.com/kubernetes/kubernetes/blob/v1.10.0-beta.1/test/images/webhook/config.go#L48-L49), +which defaults to `NoClientCert`. This means that the webhook server does not +authenticate the identity of the clients, supposedly apiservers. If you need +mutual TLS or other ways to authenticate the clients, see +how to [authenticate apiservers](#authenticate-apiservers). + +### Deploy the admission webhook service + +The webhook server in the e2e test is deployed in the Kubernetes cluster, via +the [deployment API](/docs/api-reference/{{page.version}}/#deployment-v1beta1-apps). +The test also creates a [service](/docs/api-reference/{{page.version}}/#service-v1-core) +as the front-end of the webhook server. See +[code](https://github.com/kubernetes/kubernetes/blob/v1.10.0-beta.1/test/e2e/apimachinery/webhook.go#L196). + +You may also deploy your webhooks outside of the cluster. You will need to update +your [webhook client configurations](https://github.com/kubernetes/kubernetes/blob/v1.10.0-beta.1/staging/src/k8s.io/api/admissionregistration/v1beta1/types.go#L218) accordingly. + +### Configure admission webhooks on the fly + +You can dynamically configure what resources are subject to what admission +webhooks via +[ValidatingWebhookConfiguration](https://github.com/kubernetes/kubernetes/blob/v1.10.0-beta.1/staging/src/k8s.io/api/admissionregistration/v1beta1/types.go#L68) +or +[MutatingWebhookConifuration](https://github.com/kubernetes/kubernetes/blob/v1.10.0-beta.1/staging/src/k8s.io/api/admissionregistration/v1beta1/types.go#L98). + +The following is an example `validatingWebhookConfiguration`, a mutating webhook +configuration is similar. + +```yaml +apiVersion: admissionregistration.k8s.io/v1beta1 +kind: ValidatingWebhookConfiguration +metadata: + name: +webhooks: +- name: + rules: + - apiGroups: + - "" + apiVersions: + - v1 + operations: + - CREATE + resources: + - pods + clientConfig: + service: + namespace: + name: + caBundle: +``` + +When an apiserver receives a request that matches one of the `rules`, the +apiserver sends an `admissionReview` request to webhook as specified in the +`clientConfig`. + +After you create the webhook configuration, the system will take a few seconds +to honor the new configuration. + +### Authenticate apiservers + +If your admission webhooks require authentication, you can configure the +apiservers to use basic auth, bearer token, or a cert to authenticate itself to +the webhooks. There are three steps to complete the configuration. + +* When starting the apiserver, specify the location of the admission control + configuration file via the `--admission-control-config-file` flag. + +* In the admission control configuration file, specify where the + MutatingAdmissionWebhook controller and ValidatingAdmissionWebhook controller + should read the credentials. The credentials are stored in kubeConfig files + (yes, the same schema that's used by kubectl), so the field name is + `kubeConfigFile`. Here is an example admission control configuration file: + +```yaml +apiVersion: apiserver.k8s.io/v1alpha1 +kind: AdmissionConfiguration +plugins: +- name: ValidatingAdmissionWebhook + configuration: + apiVersion: apiserver.config.k8s.io/v1alpha1 + kind: WebhookAdmission + kubeConfigFile: +- name: MutatingAdmissionWebhook + configuration: + apiVersion: apiserver.config.k8s.io/v1alpha1 + kind: WebhookAdmission + kubeConfigFile: +``` + +The schema of `admissionConfiguration` is defined +[here](https://github.com/kubernetes/kubernetes/blob/v1.10.0-beta.0/staging/src/k8s.io/apiserver/pkg/apis/apiserver/v1alpha1/types.go#L27). + +* In the kubeConfig file, provide the credentials: + +```yaml +apiVersion: v1 +kind: Config +users: +# DNS name of webhook service, i.e., ..svc, or the URL +# of the webhook server. +- name: 'webhook1.ns1.svc' + user: + client-certificate-data: + client-key-data: +# The `name` supports using * to wildmatch prefixing segments. +- name: '*.webhook-company.org' + user: + password: + username: +# '*' is the default match. +- name: '*' + user: + token: +``` + +Of course you need to set up the webhook server to handle these authentications. ## Initializers @@ -135,153 +294,3 @@ the pods will be stuck in an uninitialized state. Make sure that all expansions of the `` tuple in a `rule` are valid. If they are not, separate them in different `rules`. - -## External Admission Webhooks - -### What are external admission webhooks? - -External admission webhooks are HTTP callbacks that are intended to receive -admission requests and do something with them. What an external admission -webhook does is up to you, but there is an -[interface](https://github.com/kubernetes/kubernetes/blob/v1.7.0-rc.1/pkg/apis/admission/v1alpha1/types.go) -that it must adhere to so that it responds with whether or not the -admission request should be allowed. - -Unlike initializers or the plugin-style admission controllers, external -admission webhooks are not allowed to mutate the admission request in any way. - -Because admission is a high security operation, the external admission webhooks -must support TLS. - -### When to use admission webhooks? - -A simple example use case for an external admission webhook is to do semantic validation -of Kubernetes resources. Suppose that your infrastructure requires that all `Pod` -resources have a common set of labels, and you do not want any `Pod` to be -persisted to Kubernetes if those needs are not met. You could write your -external admission webhook to do this validation and respond accordingly. - -### How are external admission webhooks triggered? - -Whenever a request comes in, the `GenericAdmissionWebhook` admission plugin will -get the list of interested external admission webhooks from -`externalAdmissionHookConfiguration` objects (explained below) and call them in -parallel. If **all** of the external admission webhooks approve the admission -request, the admission chain continues. If **any** of the external admission -webhooks deny the admission request, the admission request will be denied, and -the reason for doing so will be based on the _first_ external admission webhook -denial reason. _This means if there is more than one external admission webhook -that denied the admission request, only the first will be returned to the -user._ If there is an error encountered when calling an external admission -webhook, that request is ignored and will not be used to approve/deny the -admission request. - -**Note:** The admission chain depends solely on the order of the -`--admission-control` option passed to `kube-apiserver`. - -### Enable external admission webhooks - -*External Admission Webhooks* is an alpha feature, so it is disabled by default. -To turn it on, you need to - -* Include "GenericAdmissionWebhook" in the `--admission-control` flag when - starting the apiserver. If you have multiple `kube-apiserver` replicas, all - should have the same flag setting. - -* Enable the dynamic admission controller registration API by adding - `admissionregistration.k8s.io/v1alpha1` to the `--runtime-config` flag passed - to `kube-apiserver`, e.g. - `--runtime-config=admissionregistration.k8s.io/v1alpha1`. Again, all replicas - should have the same flag setting. - -### Write a webhook admission controller - -See [caesarxuchao/example-webhook-admission-controller](https://github.com/caesarxuchao/example-webhook-admission-controller) -for an example webhook admission controller. - -The communication between the webhook admission controller and the apiserver, or -more precisely, the GenericAdmissionWebhook admission controller, needs to be -TLS secured. You need to generate a CA cert and use it to sign the server cert -used by your webhook admission controller. The pem formatted CA cert is supplied -to the apiserver via the dynamic registration API -`externaladmissionhookconfigurations.clientConfig.caBundle`. - -For each request received by the apiserver, the GenericAdmissionWebhook -admission controller sends an -[admissionReview](https://github.com/kubernetes/kubernetes/blob/v1.7.0-rc.1/pkg/apis/admission/v1alpha1/types.go#L27) -to the relevant webhook admission controller. The webhook admission controller -gathers information like `object`, `oldobject`, and `userInfo`, from -`admissionReview.spec`, sends back a response with the body also being the -`admissionReview`, whose `status` field is filled with the admission decision. - -### Deploy the webhook admission controller - -See [caesarxuchao/example-webhook-admission-controller deployment](https://github.com/caesarxuchao/example-webhook-admission-controller/tree/master/deployment) -for an example deployment. - -The webhook admission controller should be deployed via the -[deployment API](/docs/api-reference/{{page.version}}/#deployment-v1beta1-apps). -You also need to create a -[service](/docs/api-reference/{{page.version}}/#service-v1-core) as the -front-end of the deployment. - -### Configure webhook admission controller on the fly - -You can configure what webhook admission controllers are enabled and what -resources are subject to the admission controller via creating -externaladmissionhookconfigurations. - -We suggest that you first deploy the webhook admission controller and make sure -it is working properly before creating the externaladmissionhookconfigurations. -Otherwise, depending whether the webhook is configured as fail open or fail -closed, operations will be unconditionally accepted or rejected. - -The following is an example `externaladmissionhookconfiguration`: - -```yaml -apiVersion: admissionregistration.k8s.io/v1alpha1 -kind: ExternalAdmissionHookConfiguration -metadata: - name: example-config -externalAdmissionHooks: -- name: pod-image.k8s.io - rules: - - apiGroups: - - "" - apiVersions: - - v1 - operations: - - CREATE - resources: - - pods - failurePolicy: Ignore - clientConfig: - caBundle: - service: - name: - namespace: -``` - -For a request received by the apiserver, if the request matches any of the -`rules` of an `externalAdmissionHook`, the `GenericAdmissionWebhook` admission -controller will send an `admissionReview` request to the `externalAdmissionHook` -to ask for admission decision. - -The `rule` is similar to the `rule` in `initializerConfiguration`, with two -differences: - -* The addition of the `operations` field, specifying what operations the webhook - is interested in; - -* The `resources` field accepts subresources in the form or resource/subresource. - -Make sure that all expansions of the `` tuple -in a `rule` are valid. If they are not, separate them to different `rules`. - -You can also specify the `failurePolicy`. In 1.7, the system supports `Ignore` -and `Fail` policies, meaning that upon a communication error with the webhook -admission controller, the `GenericAdmissionWebhook` can admit or reject the -operation based on the configured policy. - -After you create the `externalAdmissionHookConfiguration`, the system will take a few -seconds to honor the new configuration. From bb1658f93271e48b9edc88b33393833e5cb11a9a Mon Sep 17 00:00:00 2001 From: Philip Mallory Date: Wed, 14 Mar 2018 21:36:22 -0700 Subject: [PATCH 05/18] Remove page that only contains placeholder text (#7697) * Remove page that only contains placeholder text * update landing page * fix url so that the internal link works correctly --- _data/setup.yml | 3 +-- docs/setup/hosted-solutions/overview.md | 20 -------------------- 2 files changed, 1 insertion(+), 22 deletions(-) delete mode 100644 docs/setup/hosted-solutions/overview.md diff --git a/_data/setup.yml b/_data/setup.yml index 971c5a4070..009dcde78a 100644 --- a/_data/setup.yml +++ b/_data/setup.yml @@ -27,9 +27,8 @@ toc: - docs/getting-started-guides/alternatives.md - title: Hosted Solutions - landing_page: /docs/setup/hosted-solutions/overview/ + landing_page: /docs/setup/pick-right-solution/#hosted-solutions section: - - docs/setup/hosted-solutions/overview.md - title: Running Kubernetes on Google Kubernetes Engine path: https://cloud.google.com/kubernetes-engine/docs/before-you-begin/ - title: Running Kubernetes on Azure Container Service diff --git a/docs/setup/hosted-solutions/overview.md b/docs/setup/hosted-solutions/overview.md deleted file mode 100644 index a2c2d30385..0000000000 --- a/docs/setup/hosted-solutions/overview.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: Hosted Kubernetes Solutions ---- - -{% capture overview %} - -TODO - -{% endcapture %} - - -{% capture body %} - -TODO - -{% endcapture %} - - -{% include templates/concept.md %} - From f5c7f91bdf7146c5d1909b0d96ca5ae01f534f0a Mon Sep 17 00:00:00 2001 From: Shahid Iqbal Date: Thu, 15 Mar 2018 16:07:26 +0000 Subject: [PATCH 06/18] Added details for scaling node count on AKS (#7756) Added link to docs for scaling nodes on AKS --- docs/tasks/administer-cluster/cluster-management.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/docs/tasks/administer-cluster/cluster-management.md b/docs/tasks/administer-cluster/cluster-management.md index 92ab47a3bd..5ee611a801 100644 --- a/docs/tasks/administer-cluster/cluster-management.md +++ b/docs/tasks/administer-cluster/cluster-management.md @@ -82,6 +82,11 @@ Instance Group will take care of putting appropriate image on new machines and s In other environments you may need to configure the machine yourself and tell the Kubelet on which machine API server is running. +### Resizing an Azure Kubernetes Service (AKS) cluster + +Azure Kubernetes Service enables user-initiated resizing of the cluster from either the CLI or the Azure Portal and is described in the [Azure AKS documentation](https://docs.microsoft.com/en-us/azure/aks/scale-cluster). + + ### Cluster autoscaling If you are using GCE or Google Kubernetes Engine, you can configure your cluster so that it is automatically rescaled based on From 047fed383fe74077755b57b01fdaf1cacef9429a Mon Sep 17 00:00:00 2001 From: Qiming Date: Fri, 16 Mar 2018 00:10:25 +0800 Subject: [PATCH 07/18] Fix a typo related to LimitRanger admission controller (#7754) --- docs/concepts/policy/resource-quotas.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/concepts/policy/resource-quotas.md b/docs/concepts/policy/resource-quotas.md index e44091700c..1f4c770ce9 100644 --- a/docs/concepts/policy/resource-quotas.md +++ b/docs/concepts/policy/resource-quotas.md @@ -25,7 +25,7 @@ Resource quotas work like this: status code `403 FORBIDDEN` with a message explaining the constraint that would have been violated. - If quota is enabled in a namespace for compute resources like `cpu` and `memory`, users must specify requests or limits for those values; otherwise, the quota system may reject pod creation. Hint: Use - the LimitRange admission controller to force defaults for pods that make no compute resource requirements. + the `LimitRanger` admission controller to force defaults for pods that make no compute resource requirements. See the [walkthrough](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) for an example of how to avoid this problem. Examples of policies that could be created using namespaces and quotas are: From ae16e101952d85043a1646b5d827db847d07fba2 Mon Sep 17 00:00:00 2001 From: Yunkai Feng Date: Fri, 16 Mar 2018 00:14:25 +0800 Subject: [PATCH 08/18] Update device-plugins.md (#7752) Add Solarflare device plugin example --- docs/concepts/cluster-administration/device-plugins.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/concepts/cluster-administration/device-plugins.md b/docs/concepts/cluster-administration/device-plugins.md index ac755e15fc..00786c49fc 100644 --- a/docs/concepts/cluster-administration/device-plugins.md +++ b/docs/concepts/cluster-administration/device-plugins.md @@ -138,7 +138,7 @@ For examples of device plugin implementations, see: * it requires using [nvidia-docker 2.0](https://github.com/NVIDIA/nvidia-docker) which allows you to run GPU enabled docker containers * The [NVIDIA GPU device plugin for COS base OS](https://github.com/GoogleCloudPlatform/container-engine-accelerators/tree/master/cmd/nvidia_gpu). * The [RDMA device plugin](https://github.com/hustcat/k8s-rdma-device-plugin) - +* The [Solarflare device plugin](https://github.com/vikaschoudhary16/sfc-device-plugin) {% endcapture %} {% include templates/concept.md %} From c61553370a8e36c53c3defad48e32307b0ad4ea1 Mon Sep 17 00:00:00 2001 From: Jamon Camisso Date: Thu, 15 Mar 2018 12:18:25 -0400 Subject: [PATCH 09/18] Update upgrades.md (#7751) --- docs/getting-started-guides/ubuntu/upgrades.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/docs/getting-started-guides/ubuntu/upgrades.md b/docs/getting-started-guides/ubuntu/upgrades.md index 267aa122b3..d94e9f0b55 100644 --- a/docs/getting-started-guides/ubuntu/upgrades.md +++ b/docs/getting-started-guides/ubuntu/upgrades.md @@ -48,6 +48,14 @@ After the snapshot, upgrade the etcd service with: This will handle upgrades between minor versions of etcd. Instructions on how to upgrade from 2.x to 3.x can be found [here](https://github.com/juju-solutions/bundle-canonical-kubernetes/wiki/Etcd-2.3-to-3.x-upgrade) in the juju-solutions wiki. +### Upgrade kubeapi-load-balancer + +The Kubernetes Charms are generally all updated and released at the same time. A core part of a cluster on Ubuntu is the kubeapi-load-balancer component. Incorrect or missing changes there can have an effect on API availability and access controls. To ensure API service continuity for the master and workers when they are updated, this upgrade needs to precede them. + +To upgrade the charm run: + + juju upgrade-charm kubeapi-load-balancer + ### Upgrade Kubernetes The Kubernetes Charms use snap channels to drive payloads. From ac2f75b05addca4173da80830f13e5b2fe8eeaa9 Mon Sep 17 00:00:00 2001 From: Kai Chen Date: Thu, 15 Mar 2018 09:23:25 -0700 Subject: [PATCH 10/18] Reference ahmetb's recipes repo for more scenarios enabled by NetworkPolicy (#7750) --- docs/concepts/services-networking/network-policies.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/concepts/services-networking/network-policies.md b/docs/concepts/services-networking/network-policies.md index 5874351e09..049e268919 100644 --- a/docs/concepts/services-networking/network-policies.md +++ b/docs/concepts/services-networking/network-policies.md @@ -186,3 +186,4 @@ This ensures that even pods that aren't selected by any other NetworkPolicy will - See the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) walkthrough for further examples. +- See more [Recipes](https://github.com/ahmetb/kubernetes-network-policy-recipes) for common scenarios enabled by the NetworkPolicy resource. \ No newline at end of file From d942390c63cb056a1e87777f0140384f8c63d8a2 Mon Sep 17 00:00:00 2001 From: Sun Lintong Date: Fri, 16 Mar 2018 00:53:24 +0800 Subject: [PATCH 11/18] It's better to be "behavior" (#7738) * Correct spelling mistake The whole file only appeared once * Correct spell Correct the word "resource" spell. * Is "kube/.config" should be ".kube/config" It seems that the file is ".kube/config" * behaviour to behavior --- docs/admin/admission-controllers.md | 2 +- docs/admin/authentication.md | 2 +- docs/admin/high-availability/building.md | 2 +- docs/admin/multiple-zones.md | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/admin/admission-controllers.md b/docs/admin/admission-controllers.md index 32d676f6a8..4aeacc2c84 100644 --- a/docs/admin/admission-controllers.md +++ b/docs/admin/admission-controllers.md @@ -329,7 +329,7 @@ When the admission controller sets a compute resource request, it does this by * the pod spec rather than mutating the `container.resources` fields. The annotations added contain the information on what compute resources were auto-populated. -See the [InitialResouces proposal](https://git.k8s.io/community/contributors/design-proposals/autoscaling/initial-resources.md) for more details. +See the [InitialResources proposal](https://git.k8s.io/community/contributors/design-proposals/autoscaling/initial-resources.md) for more details. ### LimitPodHardAntiAffinity diff --git a/docs/admin/authentication.md b/docs/admin/authentication.md index 2c106e4406..6d1db7e15c 100644 --- a/docs/admin/authentication.md +++ b/docs/admin/authentication.md @@ -373,7 +373,7 @@ users: refresh-token: q1bKLFOyUiosTfawzA93TzZIDzH2TNa2SMm0zEiPKTUwME6BkEo6Sql5yUWVBSWpKUGphaWpxSVAfekBOZbBhaEW+VlFUeVRGcluyVF5JT4+haZmPsluFoFu5XkpXk5BXq name: oidc ``` -Once your `id_token` expires, `kubectl` will attempt to refresh your `id_token` using your `refresh_token` and `client_secret` storing the new values for the `refresh_token` and `id_token` in your `kube/.config`. +Once your `id_token` expires, `kubectl` will attempt to refresh your `id_token` using your `refresh_token` and `client_secret` storing the new values for the `refresh_token` and `id_token` in your `.kube/config`. ##### Option 2 - Use the `--token` Option diff --git a/docs/admin/high-availability/building.md b/docs/admin/high-availability/building.md index 1ae1b74c6e..4175c3d6f6 100644 --- a/docs/admin/high-availability/building.md +++ b/docs/admin/high-availability/building.md @@ -219,7 +219,7 @@ endpoints. You can switch to the new reconciler by adding the flag {% include feature-state-alpha.md %} If you want to know more, you can check the following resources: -- [issue kubernetes/kuberenetes#22609](https://github.com/kubernetes/kubernetes/issues/22609), +- [issue kubernetes/kubernetes#22609](https://github.com/kubernetes/kubernetes/issues/22609), which gives additional context - [master/reconcilers/mastercount.go](https://github.com/kubernetes/kubernetes/blob/dd9981d038012c120525c9e6df98b3beb3ef19e1/pkg/master/reconcilers/mastercount.go#L63), the implementation of the master count reconciler diff --git a/docs/admin/multiple-zones.md b/docs/admin/multiple-zones.md index e15b61bf2a..2bb6c818f7 100644 --- a/docs/admin/multiple-zones.md +++ b/docs/admin/multiple-zones.md @@ -36,7 +36,7 @@ zone information. Kubernetes will automatically spread the pods in a replication controller or service across nodes in a single-zone cluster (to reduce the impact of -failures.) With multiple-zone clusters, this spreading behaviour is +failures.) With multiple-zone clusters, this spreading behavior is extended across zones (to reduce the impact of zone failures.) (This is achieved via `SelectorSpreadPriority`). This is a best-effort placement, and so if the zones in your cluster are heterogeneous From 63a928805390ebf194010dee9a3d6b4057e79738 Mon Sep 17 00:00:00 2001 From: Sun Lintong Date: Fri, 16 Mar 2018 01:03:24 +0800 Subject: [PATCH 12/18] Correct spelling mistake (#7736) * Correct spelling mistake The whole file only appeared once * Correct spell Correct the word "resource" spell. * Is "kube/.config" should be ".kube/config" It seems that the file is ".kube/config" From 99125b914880fcff76afa5243d637e4c253b9a7b Mon Sep 17 00:00:00 2001 From: Sascha Marcel Schmidt Date: Thu, 15 Mar 2018 18:18:23 +0100 Subject: [PATCH 13/18] fixes common name and organization and base64 (#7727) --- .../services-networking/connect-applications-service.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/concepts/services-networking/connect-applications-service.md b/docs/concepts/services-networking/connect-applications-service.md index 5587498f2b..e6fe3b1f79 100644 --- a/docs/concepts/services-networking/connect-applications-service.md +++ b/docs/concepts/services-networking/connect-applications-service.md @@ -185,10 +185,10 @@ Following are the manual steps to follow in case you run into problems running m ```shell #create a public private key pair -openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /d/tmp/nginx.key -out /d/tmp/nginx.crt -subj "/CN=nginxsvc/O=nginxsvc" +openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /d/tmp/nginx.key -out /d/tmp/nginx.crt -subj "/CN=my-nginx/O=my-nginx" #convert the keys to base64 encoding -cat /d/tmp/nginx.crt | base 64 -cat /d/tmp/nginx.key | base 64 +cat /d/tmp/nginx.crt | base64 +cat /d/tmp/nginx.key | base64 ``` Use the output from the previous commands to create a yaml file as follows. The base64 encoded value should all be on a single line. From d4e72419874b6a038b89170d71ada8b545b2b8dd Mon Sep 17 00:00:00 2001 From: Weibin Lin Date: Fri, 16 Mar 2018 03:13:23 +0800 Subject: [PATCH 14/18] Remove the redundant "`" in pick-right-solution.md (#7720) --- docs/setup/pick-right-solution.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/setup/pick-right-solution.md b/docs/setup/pick-right-solution.md index bc8b087a44..ce0c5f44ef 100644 --- a/docs/setup/pick-right-solution.md +++ b/docs/setup/pick-right-solution.md @@ -62,7 +62,7 @@ a Kubernetes cluster from scratch. * [Kubermatic](https://www.loodse.com) provides managed Kubernetes clusters for various public clouds, including AWS and Digital Ocean, as well as on-premises with OpenStack integration. * [Pivotal Container Service](https://pivotal.io/platform/pivotal-container-service) provides enterprise-grade Kubernetes for both on-premises and public clouds. PKS enables on-demand provisioning of Kubernetes clusters, multi-tenancy and fully automated day-2 operations. -` + # Turnkey Cloud Solutions These solutions allow you to create Kubernetes clusters on a range of Cloud IaaS providers with only a From 934a164a066aa488c42879ead9119fc3ddb9e5e8 Mon Sep 17 00:00:00 2001 From: RongZhang Date: Thu, 15 Mar 2018 14:14:24 -0500 Subject: [PATCH 15/18] Update Kubespray documents (#7723) --- docs/getting-started-guides/kubespray.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/docs/getting-started-guides/kubespray.md b/docs/getting-started-guides/kubespray.md index 9ee3443038..3bc5f1a5f2 100644 --- a/docs/getting-started-guides/kubespray.md +++ b/docs/getting-started-guides/kubespray.md @@ -10,7 +10,7 @@ Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks, [in * a highly available cluster * composable attributes -* support for most popular Linux distributions (CoreOS, Debian Jessie, Ubuntu 16.04, CentOS/RHEL 7) +* support for most popular Linux distributions (CoreOS, Debian Jessie, Ubuntu 16.04, CentOS/RHEL 7, Fedora/CentOS Atomic) * continuous integration tests To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/comparisons.md) to [kubeadm](/docs/admin/kubeadm/) and [kops](../kops). @@ -79,7 +79,8 @@ Kubespray provides additional playbooks to manage your cluster: _scale_ and _upg ### Scale your cluster -You can scale your cluster by running the scale playbook. For more information, see "[Adding nodes](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#adding-nodes)". +You can add worker nodes from your cluster by running the scale playbook. For more information, see "[Adding nodes](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#adding-nodes)". +You can remove worker nodes from your cluster by running the remove-node playbook. For more information, see "[Remove nodes](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#remove-nodes)". ### Upgrade your cluster From be1901c0a457c14603f8f2201a180d1944172d16 Mon Sep 17 00:00:00 2001 From: chenpengdev Date: Fri, 16 Mar 2018 03:15:24 +0800 Subject: [PATCH 16/18] Use the international standard for punctuation (#7719) --- docs/concepts/configuration/assign-pod-node.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/concepts/configuration/assign-pod-node.md b/docs/concepts/configuration/assign-pod-node.md index a99896a2ac..7ef1b40ba0 100644 --- a/docs/concepts/configuration/assign-pod-node.md +++ b/docs/concepts/configuration/assign-pod-node.md @@ -88,7 +88,7 @@ feature, currently in beta, greatly expands the types of constraints you can exp 3. you can constrain against labels on other pods running on the node (or other topological domain), rather than against labels on the node itself, which allows rules about which pods can and cannot be co-located -The affinity feature consists of two types of affinity, "node affinity" and "inter-pod affinity/anti-affinity." +The affinity feature consists of two types of affinity, "node affinity" and "inter-pod affinity/anti-affinity". Node affinity is like the existing `nodeSelector` (but with the first two benefits listed above), while inter-pod affinity/anti-affinity constrains against pod labels rather than node labels, as described in the third item listed above, in addition to having the first and second properties listed above. @@ -147,7 +147,7 @@ For more information on node affinity, see the design doc Inter-pod affinity and anti-affinity were introduced in Kubernetes 1.4. Inter-pod affinity and anti-affinity allow you to constrain which nodes your pod is eligible to be scheduled *based on labels on pods that are already running on the node* rather than based on labels on nodes. The rules are of the form "this pod should (or, in the case of -anti-affinity, should not) run in an X if that X is already running one or more pods that meet rule Y." Y is expressed +anti-affinity, should not) run in an X if that X is already running one or more pods that meet rule Y". Y is expressed as a LabelSelector with an associated list of namespaces (or "all" namespaces); unlike nodes, because pods are namespaced (and therefore the labels on pods are implicitly namespaced), a label selector over pod labels must specify which namespaces the selector should apply to. Conceptually X is a topology domain @@ -203,7 +203,7 @@ empty `topologyKey` is not allowed. In addition to `labelSelector` and `topologyKey`, you can optionally specify a list `namespaces` of namespaces which the `labelSelector` should match against (this goes at the same level of the definition as `labelSelector` and `topologyKey`). If omitted, it defaults to the namespace of the pod where the affinity/anti-affinity definition appears. -If defined but empty, it means "all namespaces." +If defined but empty, it means "all namespaces". All `matchExpressions` associated with `requiredDuringSchedulingIgnoredDuringExecution` affinity and anti-affinity must be satisfied for the pod to be scheduled onto a node. From fec4155adc2afbf8654901f1c50471f222eb0411 Mon Sep 17 00:00:00 2001 From: Kai Chen Date: Thu, 15 Mar 2018 12:17:25 -0700 Subject: [PATCH 17/18] Remove reference to the deprecated OVS document (#7718) --- docs/concepts/cluster-administration/networking.md | 2 +- docs/concepts/services-networking/ingress.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/concepts/cluster-administration/networking.md b/docs/concepts/cluster-administration/networking.md index 7af520617e..da28b5ddfe 100644 --- a/docs/concepts/cluster-administration/networking.md +++ b/docs/concepts/cluster-administration/networking.md @@ -216,7 +216,7 @@ The Nuage platform uses overlays to provide seamless policy-based networking bet ### OpenVSwitch -[OpenVSwitch](/docs/admin/ovs-networking) is a somewhat more mature but also +[OpenVSwitch](https://www.openvswitch.org/) is a somewhat more mature but also complicated way to build an overlay network. This is endorsed by several of the "Big Shops" for networking. diff --git a/docs/concepts/services-networking/ingress.md b/docs/concepts/services-networking/ingress.md index 7716da443b..02ce829749 100644 --- a/docs/concepts/services-networking/ingress.md +++ b/docs/concepts/services-networking/ingress.md @@ -16,7 +16,7 @@ Throughout this doc you will see a few terms that are sometimes used interchange * Node: A single virtual or physical machine in a Kubernetes cluster. * Cluster: A group of nodes firewalled from the internet, that are the primary compute resources managed by Kubernetes. * Edge router: A router that enforces the firewall policy for your cluster. This could be a gateway managed by a cloud provider or a physical piece of hardware. -* Cluster network: A set of links, logical or physical, that facilitate communication within a cluster according to the [Kubernetes networking model](/docs/concepts/cluster-administration/networking/). Examples of a Cluster network include Overlays such as [flannel](https://github.com/coreos/flannel#flannel) or SDNs such as [OVS](/docs/admin/ovs-networking/). +* Cluster network: A set of links, logical or physical, that facilitate communication within a cluster according to the [Kubernetes networking model](/docs/concepts/cluster-administration/networking/). Examples of a Cluster network include Overlays such as [flannel](https://github.com/coreos/flannel#flannel) or SDNs such as [OVS](https://www.openvswitch.org/). * Service: A Kubernetes [Service](/docs/concepts/services-networking/service/) that identifies a set of pods using label selectors. Unless mentioned otherwise, Services are assumed to have virtual IPs only routable within the cluster network. ## What is Ingress? From 4ac258363735f8d35150e4dcd0213516fcdc83b9 Mon Sep 17 00:00:00 2001 From: Dusan Susic Date: Thu, 15 Mar 2018 21:40:23 +0100 Subject: [PATCH 18/18] Naming clarification (#7677) * Naming clarification It isn't mentioned that this is crucial to get etcd working. * Update high-availability.md --- docs/setup/independent/high-availability.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/setup/independent/high-availability.md b/docs/setup/independent/high-availability.md index e651a6e98c..f246182b35 100644 --- a/docs/setup/independent/high-availability.md +++ b/docs/setup/independent/high-availability.md @@ -273,7 +273,7 @@ Please select one of the tabs to see installation instructions for the respectiv --peer-key-file=/etc/kubernetes/pki/etcd/peer-key.pem \ --peer-client-cert-auth \ --peer-trusted-ca-file=/etc/kubernetes/pki/etcd/ca.pem \ - --initial-cluster etcd0=https://:2380,etcd1=https://:2380,etcd2=https://:2380 \ + --initial-cluster =https://:2380,=https://:2380,=https://:2380 \ --initial-cluster-token my-etcd-token \ --initial-cluster-state new @@ -282,7 +282,7 @@ Please select one of the tabs to see installation instructions for the respectiv EOF ``` - Make sure you replace ``, `` and `` with the appropriate IPv4 addresses. + Make sure you replace ``, `` and `` with the appropriate IPv4 addresses. Also, make sure that you replace ``, `` and `` with real hostnames of each machine. These machines must be able to reach every other using DNS or make sure that records are added to `/etc/hosts`. 1. Finally, launch etcd like so: