update with master content resolving merge conflicts
This commit is contained in:
MAKOSCAFEE
@@ -123,10 +123,10 @@ The output is similar to this:
|
||||
|
||||
Using `jsonpath` approach:
|
||||
|
||||
```
|
||||
$ APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')
|
||||
$ TOKEN=$(kubectl get secret $(kubectl get serviceaccount default -o jsonpath='{.secrets[0].name}') -o jsonpath='{.data.token}' | base64 --decode )
|
||||
$ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
|
||||
```shell
|
||||
APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')
|
||||
TOKEN=$(kubectl get secret $(kubectl get serviceaccount default -o jsonpath='{.secrets[0].name}') -o jsonpath='{.data.token}' | base64 --decode )
|
||||
curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
|
||||
{
|
||||
"kind": "APIVersions",
|
||||
"versions": [
|
||||
|
||||
@@ -26,8 +26,6 @@ To install Kubernetes on a set of machines, consult one of the existing [Getting
|
||||
|
||||
The current state of cluster upgrades is provider dependent, and some releases may require special care when upgrading. It is recommended that administrators consult both the [release notes](https://git.k8s.io/kubernetes/CHANGELOG.md), as well as the version specific upgrade notes prior to upgrading their clusters.
|
||||
|
||||
* [Upgrading to 1.6](/docs/admin/upgrade-1-6)
|
||||
|
||||
### Upgrading an Azure Kubernetes Service (AKS) cluster
|
||||
|
||||
Azure Kubernetes Service enables easy self-service upgrades of the control plane and nodes in your cluster. The process is
|
||||
@@ -79,6 +77,8 @@ Different providers, and tools, will manage upgrades differently. It is recomme
|
||||
* [Digital Rebar](https://provision.readthedocs.io/en/tip/doc/content-packages/krib.html)
|
||||
* ...
|
||||
|
||||
To upgrade a cluster on a platform not mentioned in the above list, check the order of component upgrade on the [Skewed versions](docs/setup/version-skew-policy/#supported-component-upgrade-order) page.
|
||||
|
||||
## Resizing a cluster
|
||||
|
||||
If your cluster runs short on resources you can easily add more machines to it if your cluster is running in [Node self-registration mode](/docs/admin/node/#self-registration-of-nodes).
|
||||
@@ -219,3 +219,5 @@ kubectl convert -f pod.yaml --output-version v1
|
||||
```
|
||||
|
||||
For more options, please refer to the usage of [kubectl convert](/docs/reference/generated/kubectl/kubectl-commands#convert) command.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -34,7 +34,7 @@ in the Kubernetes source directory for a canonical example.
|
||||
|
||||
Package your scheduler binary into a container image. For the purposes of this example,
|
||||
let's just use the default scheduler (kube-scheduler) as our second scheduler as well.
|
||||
Clone the [Kubernetes source code from Github](https://github.com/kubernetes/kubernetes)
|
||||
Clone the [Kubernetes source code from GitHub](https://github.com/kubernetes/kubernetes)
|
||||
and build the source.
|
||||
|
||||
```shell
|
||||
|
||||
@@ -120,7 +120,7 @@ Though etcd keeps unique member IDs internally, it is recommended to use a uniqu
|
||||
|
||||
The following message is displayed:
|
||||
|
||||
8211f1d0f64f3269, started, member1, http://10.0.0.1:12380, http://10.0.0.1:2379
|
||||
8211f1d0f64f3269, started, member1, http://10.0.0.1:2380, http://10.0.0.1:2379
|
||||
91bc3c398fb3c146, started, member2, http://10.0.0.2:2380, http://10.0.0.2:2379
|
||||
fd422379fda50e48, started, member3, http://10.0.0.3:2380, http://10.0.0.3:2379
|
||||
|
||||
|
||||
@@ -90,8 +90,8 @@ Connecting to nginx (10.100.0.16:80)
|
||||
Let's say you want to limit access to the `nginx` service so that only pods with the label `access: true` can query it. To do that, create a `NetworkPolicy` that allows connections only from those pods:
|
||||
|
||||
```yaml
|
||||
kind: NetworkPolicy
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: NetworkPolicy
|
||||
metadata:
|
||||
name: access-nginx
|
||||
spec:
|
||||
|
||||
@@ -12,7 +12,7 @@ content_template: templates/concept
|
||||
{{< feature-state for_k8s_version="v1.11" state="beta" >}}
|
||||
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.**
|
||||
can develop their features independently from the core Kubernetes release cycles.
|
||||
|
||||
{{< feature-state for_k8s_version="1.8" state="alpha" >}}
|
||||
|
||||
@@ -33,7 +33,7 @@ To build an out-of-tree cloud-controller-manager for your cloud, follow these st
|
||||
|
||||
1. Create a go package with an implementation that satisfies [cloudprovider.Interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go).
|
||||
2. Use [main.go in cloud-controller-manager](https://github.com/kubernetes/kubernetes/blob/master/cmd/cloud-controller-manager/controller-manager.go) from Kubernetes core as a template for your main.go. As mentioned above, the only difference should be the cloud package that will be imported.
|
||||
3. Import your cloud package in `main.go`, ensure your package has an `init` block to run [cloudprovider.RegisterCloudProvider](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/plugins.go#L42-L52).
|
||||
3. Import your cloud package in `main.go`, ensure your package has an `init` block to run [cloudprovider.RegisterCloudProvider](https://github.com/kubernetes/cloud-provider/blob/master/plugins.go).
|
||||
|
||||
Using existing out-of-tree cloud providers as an example may be helpful. You can find the list [here](/docs/tasks/administer-cluster/running-cloud-controller.md#examples).
|
||||
|
||||
|
||||
@@ -9,7 +9,7 @@ content_template: templates/task
|
||||
{{% capture overview %}}
|
||||
This page explains how to configure your DNS Pod and customize the
|
||||
DNS resolution process. In Kubernetes version 1.11 and later, CoreDNS is at GA
|
||||
and is installed by default with kubeadm. See [Configuring CoreDNS](#config-coredns)
|
||||
and is installed by default with kubeadm. See [CoreDNS ConfigMap options](#coredns-configmap-options)
|
||||
and [Using CoreDNS for Service Discovery](/docs/tasks/administer-cluster/coredns/).
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -162,7 +162,7 @@ During translation, all FQDN nameservers will be omitted from the CoreDNS config
|
||||
|
||||
## Kube-dns
|
||||
|
||||
Kube-dns is now available as a optional DNS server since CoreDNS is now the default.
|
||||
Kube-dns is now available as an optional DNS server since CoreDNS is now the default.
|
||||
The running DNS Pod holds 3 containers:
|
||||
|
||||
- "`kubedns`": watches the Kubernetes master for changes
|
||||
|
||||
@@ -12,6 +12,8 @@ Kubernetes cluster.
|
||||
|
||||
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
* This guide assumes your nodes use the AMD64 or Intel 64 CPU architecture
|
||||
|
||||
* Make sure the [DNS feature](/docs/concepts/services-networking/dns-pod-service/) itself is enabled.
|
||||
|
||||
* Kubernetes version 1.4.0 or later is recommended.
|
||||
@@ -22,9 +24,12 @@ Kubernetes cluster.
|
||||
|
||||
## Determining whether DNS horizontal autoscaling is already enabled
|
||||
|
||||
List the Deployments in your cluster in the kube-system namespace:
|
||||
List the {{< glossary_tooltip text="Deployments" term_id="deployment" >}}
|
||||
in your cluster in the kube-system namespace:
|
||||
|
||||
kubectl get deployment --namespace=kube-system
|
||||
```shell
|
||||
kubectl get deployment --namespace=kube-system
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
@@ -41,7 +46,9 @@ already enabled, and you can skip to
|
||||
|
||||
List the Deployments in your cluster in the kube-system namespace:
|
||||
|
||||
kubectl get deployment --namespace=kube-system
|
||||
```shell
|
||||
kubectl get deployment --namespace=kube-system
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
@@ -58,7 +65,9 @@ ReplicationController instead of a Deployment. So if you don't see kube-dns,
|
||||
or a similar name, in the preceding output, list the ReplicationControllers in
|
||||
your cluster in the kube-system namespace:
|
||||
|
||||
kubectl get rc --namespace=kube-system
|
||||
```shell
|
||||
kubectl get rc --namespace=kube-system
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
@@ -98,7 +107,9 @@ In the file, replace `<SCALE_TARGET>` with your scale target.
|
||||
Go to the directory that contains your configuration file, and enter this
|
||||
command to create the Deployment:
|
||||
|
||||
kubectl apply -f dns-horizontal-autoscaler.yaml
|
||||
```shell
|
||||
kubectl apply -f dns-horizontal-autoscaler.yaml
|
||||
```
|
||||
|
||||
The output of a successful command is:
|
||||
|
||||
@@ -108,9 +119,11 @@ DNS horizontal autoscaling is now enabled.
|
||||
|
||||
## Tuning autoscaling parameters
|
||||
|
||||
Verify that the dns-autoscaler ConfigMap exists:
|
||||
Verify that the dns-autoscaler {{< glossary_tooltip text="ConfigMap" term_id="configmap" >}} exists:
|
||||
|
||||
kubectl get configmap --namespace=kube-system
|
||||
```shell
|
||||
kubectl get configmap --namespace=kube-system
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
@@ -121,11 +134,15 @@ The output is similar to this:
|
||||
|
||||
Modify the data in the ConfigMap:
|
||||
|
||||
kubectl edit configmap dns-autoscaler --namespace=kube-system
|
||||
```shell
|
||||
kubectl edit configmap dns-autoscaler --namespace=kube-system
|
||||
```
|
||||
|
||||
Look for this line:
|
||||
|
||||
linear: '{"coresPerReplica":256,"min":1,"nodesPerReplica":16}'
|
||||
```yaml
|
||||
linear: '{"coresPerReplica":256,"min":1,"nodesPerReplica":16}'
|
||||
```
|
||||
|
||||
Modify the fields according to your needs. The "min" field indicates the
|
||||
minimal number of DNS backends. The actual number of backends number is
|
||||
@@ -152,7 +169,9 @@ use depends on different conditions.
|
||||
|
||||
This option works for all situations. Enter this command:
|
||||
|
||||
kubectl scale deployment --replicas=0 dns-autoscaler --namespace=kube-system
|
||||
```shell
|
||||
kubectl scale deployment --replicas=0 dns-autoscaler --namespace=kube-system
|
||||
```
|
||||
|
||||
The output is:
|
||||
|
||||
@@ -160,7 +179,9 @@ The output is:
|
||||
|
||||
Verify that the replica count is zero:
|
||||
|
||||
kubectl get deployment --namespace=kube-system
|
||||
```shell
|
||||
kubectl get deployment --namespace=kube-system
|
||||
```
|
||||
|
||||
The output displays 0 in the DESIRED and CURRENT columns:
|
||||
|
||||
@@ -174,7 +195,9 @@ The output displays 0 in the DESIRED and CURRENT columns:
|
||||
This option works if dns-autoscaler is under your own control, which means
|
||||
no one will re-create it:
|
||||
|
||||
kubectl delete deployment dns-autoscaler --namespace=kube-system
|
||||
```shell
|
||||
kubectl delete deployment dns-autoscaler --namespace=kube-system
|
||||
```
|
||||
|
||||
The output is:
|
||||
|
||||
@@ -182,7 +205,7 @@ The output is:
|
||||
|
||||
### Option 3: Delete the dns-autoscaler manifest file from the master node
|
||||
|
||||
This option works if dns-autoscaler is under control of the
|
||||
This option works if dns-autoscaler is under control of the (deprecated)
|
||||
[Addon Manager](https://git.k8s.io/kubernetes/cluster/addons/README.md),
|
||||
and you have write access to the master node.
|
||||
|
||||
@@ -235,6 +258,6 @@ is under consideration as a future development.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
Learn more about the
|
||||
* Learn more about the
|
||||
[implementation of cluster-proportional-autoscaler](https://github.com/kubernetes-incubator/cluster-proportional-autoscaler).
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -33,8 +33,8 @@ The alpha version of the encryption feature prior to 1.13 used the `--experiment
|
||||
## Understanding the encryption at rest configuration.
|
||||
|
||||
```yaml
|
||||
kind: EncryptionConfiguration
|
||||
apiVersion: apiserver.config.k8s.io/v1
|
||||
kind: EncryptionConfiguration
|
||||
resources:
|
||||
- resources:
|
||||
- secrets
|
||||
@@ -92,13 +92,23 @@ Name | Encryption | Strength | Speed | Key Length | Other Considerations
|
||||
Each provider supports multiple keys - the keys are tried in order for decryption, and if the provider
|
||||
is the first provider, the first key is used for encryption.
|
||||
|
||||
__Storing the raw encryption key in the EncryptionConfig only moderately improves your security posture, compared to no encryption.
|
||||
Please use `kms` provider for additional security.__ By default, the `identity` provider is used to protect secrets in etcd, which
|
||||
provides no encryption. `EncryptionConfiguration` was introduced to encrypt secrets locally, with a locally managed key.
|
||||
Encrypting secrets with a locally managed key protects against an etcd compromise, but it fails to protect against a host compromise.
|
||||
Since the encryption keys are stored on the host in the EncryptionConfig YAML file, a skilled attacker can access that file and
|
||||
extract the encryption keys. This was a stepping stone in development to the `kms` provider, introduced in 1.10, and beta since 1.12. Envelope encryption
|
||||
creates dependence on a separate key, not stored in Kubernetes. In this case, an attacker would need to compromise etcd, the
|
||||
kubeapi-server, and the third-party KMS provider to retrieve the plaintext values, providing a higher level of security than
|
||||
locally-stored encryption keys.
|
||||
|
||||
## Encrypting your data
|
||||
|
||||
Create a new encryption config file:
|
||||
|
||||
```yaml
|
||||
kind: EncryptionConfiguration
|
||||
apiVersion: apiserver.config.k8s.io/v1
|
||||
kind: EncryptionConfiguration
|
||||
resources:
|
||||
- resources:
|
||||
- secrets
|
||||
@@ -190,8 +200,8 @@ With a single `kube-apiserver`, step 2 may be skipped.
|
||||
To disable encryption at rest place the `identity` provider as the first entry in the config:
|
||||
|
||||
```yaml
|
||||
kind: EncryptionConfiguration
|
||||
apiVersion: apiserver.config.k8s.io/v1
|
||||
kind: EncryptionConfiguration
|
||||
resources:
|
||||
- resources:
|
||||
- secrets
|
||||
|
||||
+6
-2
@@ -16,6 +16,9 @@ A cluster may stop working properly if a critical add-on is evicted (either manu
|
||||
and becomes pending (for example when the cluster is highly utilized and either there are other pending pods that schedule into the space
|
||||
vacated by the evicted critical add-on pod or the amount of resources available on the node changed for some other reason).
|
||||
|
||||
Note that marking a pod as critical is not meant to prevent evictions entirely; it only prevents the pod from becoming permanently unavailable.
|
||||
For static pods, this means it can't be evicted, but for non-static pods, it just means they will always be rescheduled.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -24,9 +27,10 @@ vacated by the evicted critical add-on pod or the amount of resources available
|
||||
|
||||
### Marking pod as critical
|
||||
|
||||
To be considered critical, the pod has to run in the `kube-system` namespace (configurable via flag) and
|
||||
Prior to v1.11, critical pod has to run in the `kube-system` namespace, this restriction was removed after v1.11 and pod in any namespace can be configed as a critical pod by the following either way:
|
||||
|
||||
* Have the priorityClassName set as "system-cluster-critical" or "system-node-critical", the latter being the highest for entire cluster. Alternatively, you could add an annotation `scheduler.alpha.kubernetes.io/critical-pod` as key and empty string as value to your pod, but this annotation is deprecated as of version 1.13 and will be removed in 1.14.
|
||||
* Ensure the PodPriority [feature gates](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) is enabled. Have the priorityClassName set as "system-cluster-critical" or "system-node-critical", the latter being the highest for entire cluster, the two priority class names available since v1.10+
|
||||
|
||||
* Alternatively, ensure both PodPriority and ExperimentalCriticalPodAnnotation feature gates are enabled, you could add an annotation `scheduler.alpha.kubernetes.io/critical-pod` as key and empty string as value to your pod, but this annotation is deprecated as of version 1.13 and will be removed in a future release.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -107,7 +107,7 @@ KUBE_GCE_ZONE=replica-zone KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up
|
||||
|
||||
* Try to place master replicas in different zones. During a zone failure, all masters placed inside the zone will fail.
|
||||
To survive zone failure, also place nodes in multiple zones
|
||||
(see [multiple-zones](/docs/setup/multiple-zones/) for details).
|
||||
(see [multiple-zones](/docs/setup/best-practices/multiple-zones/) for details).
|
||||
|
||||
* Do not use a cluster with two master replicas. Consensus on a two-replica cluster requires both replicas running when changing persistent state.
|
||||
As a result, both replicas are needed and a failure of any replica turns cluster into majority failure state.
|
||||
|
||||
@@ -80,8 +80,8 @@ To encrypt the data:
|
||||
1. Create a new encryption configuration file using the appropriate properties for the `kms` provider:
|
||||
|
||||
```yaml
|
||||
kind: EncryptionConfiguration
|
||||
apiVersion: apiserver.config.k8s.io/v1
|
||||
kind: EncryptionConfiguration
|
||||
resources:
|
||||
- resources:
|
||||
- secrets
|
||||
@@ -136,8 +136,8 @@ To switch from a local encryption provider to the `kms` provider and re-encrypt
|
||||
1. Add the `kms` provider as the first entry in the configuration file as shown in the following example.
|
||||
|
||||
```yaml
|
||||
kind: EncryptionConfiguration
|
||||
apiVersion: apiserver.config.k8s.io/v1
|
||||
kind: EncryptionConfiguration
|
||||
resources:
|
||||
- resources:
|
||||
- secrets
|
||||
@@ -166,8 +166,8 @@ To disable encryption at rest:
|
||||
1. Place the `identity` provider as the first entry in the configuration file:
|
||||
|
||||
```yaml
|
||||
kind: EncryptionConfiguration
|
||||
apiVersion: apiserver.config.k8s.io/v1
|
||||
kind: EncryptionConfiguration
|
||||
resources:
|
||||
- resources:
|
||||
- secrets
|
||||
|
||||
@@ -17,7 +17,7 @@ Client certificates generated by [kubeadm](/docs/reference/setup-tools/kubeadm/k
|
||||
|
||||
Be familiar with [PKI certificates and requirements in Kubernetes](/docs/setup/certificates/).
|
||||
|
||||
Have a working Kubernetes cluster installed using kubeadm with your certificates stored in `/etc/kubernetes/pki` folder; in case you are using a different location, the following can be adapted accordingly.
|
||||
You should be familiar with [PKI certificates and requirements in Kubernetes](/docs/setup/best-practices/certificates/).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -89,7 +89,7 @@ If you are running an HA cluster, this command needs to be executed on all the c
|
||||
|
||||
`kubeadm alpha certs renew` provides the following options:
|
||||
|
||||
- `--use-api` allows you to use the Kubernetes certificates API for signing certificates (instead of the local CA/front-proxy-CA); see next paragraphs for more information.
|
||||
The Kubernetes certificates normally reach their expiration date after one year.
|
||||
|
||||
- `--csr-only` can be used to renew certificats with an external CA by generating certificate signing requests (without actually renewing certificates in place); see next paragraph for more information.
|
||||
|
||||
@@ -105,8 +105,10 @@ These are advanced topics for users who need to integrate their organization's c
|
||||
|
||||
### Set up a signer
|
||||
|
||||
The Kubernetes Certificate Authority does not work out of the box.
|
||||
You can configure an external signer such as [cert-manager][cert-manager-issuer], or you can use the build-in signer.
|
||||
The Kubernetes Certificate Authority does not work out of the box.
|
||||
You can configure an external signer such as [cert-manager][cert-manager-issuer], or you can use the build-in signer.
|
||||
The built-in signer is part of [`kube-controller-manager`][kcm].
|
||||
To activate the build-in signer, you pass the `--cluster-signing-cert-file` and `--cluster-signing-key-file` arguments.
|
||||
|
||||
The built-in signer is part of [`kube-controller-manager`][kcm].
|
||||
|
||||
@@ -131,7 +133,9 @@ If you're creating a new cluster, you can use a kubeadm [configuration file][con
|
||||
|
||||
You can create the certificate signing requests for the Kubernetes certificates API with `kubeadm alpha certs renew --use-api`.
|
||||
|
||||
The command outputs the name of the certificate to approve, then blocks and waits for approval to occur. e.g.:
|
||||
If you set up an external signer such as [cert-manager][cert-manager], certificate signing requests (CSRs) are automatically approved.
|
||||
Otherwise, you must manually approve certificates with the [`kubectl certificate`][certs] command.
|
||||
The following kubeadm command outputs the name of the certificate to approve, then blocks and waits for approval to occur:
|
||||
|
||||
```shell
|
||||
sudo kubeadm alpha certs renew apiserver --use-api &
|
||||
@@ -162,13 +166,15 @@ You can view a list of pending certificates with `kubectl get csr`.
|
||||
|
||||
This section provide more details about how to execute manual certificate renewal using an external CA.
|
||||
|
||||
{{< caution >}}
|
||||
These are advanced topics for users who need to integrate their organization's certificate infrastructure into a kubeadm-built cluster. If the default kubeadm configuration satisfies your needs, you should let kubeadm manage certificates instead.
|
||||
{{< /caution >}}
|
||||
To better integrate with external CAs, kubeadm can also produce certificate signing requests (CSRs).
|
||||
A CSR represents a request to a CA for a signed certificate for a client.
|
||||
In kubeadm terms, any certificate that would normally be signed by an on-disk CA can be produced as a CSR instead. A CA, however, cannot be produced as a CSR.
|
||||
|
||||
### Create certificate signing requests (CSR)
|
||||
|
||||
To better integrate with external CAs, kubeadm can produce certificate signing requests (CSRs).
|
||||
You can pass in a directory with `--csr-dir` to output the CSRs to the specified location.
|
||||
If `--csr-dir` is not specified, the default certificate directory (`/etc/kubernetes/pki`) is used.
|
||||
Both the CSR and the accompanying private key are given in the output. After a certificate is signed, the certificate and the private key must be copied to the PKI directory (by default `/etc/kubernetes/pki`).
|
||||
|
||||
A CSR represents a request to a CA for a signed certificate for a client.
|
||||
|
||||
@@ -176,10 +182,13 @@ You can create certificate signing requests with `kubeadm alpha certs renew --cs
|
||||
|
||||
Both the CSR and the accompanying private key are given in the output; you can pass in a directory with `--csr-dir` to output the CSRs to the specified location.
|
||||
|
||||
### Renew certificates
|
||||
Certificates can be renewed with `kubeadm alpha certs renew --csr-only`.
|
||||
As with `kubeadm init`, an output directory can be specified with the `--csr-dir` flag.
|
||||
To use the new certificates, copy the signed certificate and private key into the PKI directory (by default `/etc/kubernetes/pki`)
|
||||
|
||||
A CSR contains a certificate's name, domain(s), and IPs, but it does not specify usages.
|
||||
|
||||
A CSR contains a certificate's name, domains, and IPs, but it does not specify usages.
|
||||
It is the responsibility of the CA to specify [the correct cert usages][cert-table] when issuing a certificate.
|
||||
|
||||
* In `openssl` this is done with the [`openssl ca` command][openssl-ca].
|
||||
@@ -189,11 +198,8 @@ After a certificate is signed using your preferred method, the certificate and t
|
||||
|
||||
[openssl-ca]: https://superuser.com/questions/738612/openssl-ca-keyusage-extension
|
||||
[cfssl-usages]: https://github.com/cloudflare/cfssl/blob/master/doc/cmd/cfssl.txt#L170
|
||||
[certs]: /docs/setup/certificates
|
||||
[cert-cas]: /docs/setup/certificates/#single-root-ca
|
||||
[cert-table]: /docs/setup/certificates/#all-certificates
|
||||
[manage-tls]: /docs/tasks/tls/managing-tls-in-a-cluster/
|
||||
[cert-manager]: https://github.com/jetstack/cert-manager
|
||||
[certs]: /docs/reference/generated/kubectl/kubectl-commands#certificate
|
||||
[certs]: /docs/setup/best-practices/certificates/
|
||||
[cert-cas]: /docs/setup/best-practices/certificates/#single-root-ca
|
||||
[cert-table]: /docs/setup/best-practices/certificates/#all-certificates
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -0,0 +1,205 @@
|
||||
---
|
||||
reviewers:
|
||||
- sig-cluster-lifecycle
|
||||
title: Certificate Management with kubeadm
|
||||
content_template: templates/task
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.15" state="stable" >}}
|
||||
|
||||
Client certificates generated by [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) expire after 1 year. This page explains how to manage certificate renewals with kubeadm.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
Be familiar with [PKI certificates and requirements in Kubernetes](/docs/setup/certificates/).
|
||||
|
||||
You should be familiar with [PKI certificates and requirements in Kubernetes](/docs/setup/best-practices/certificates/).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## Check certificate expiration
|
||||
|
||||
`check-expiration` can be used to check certificate expiration.
|
||||
|
||||
```
|
||||
kubeadm alpha certs check-expiration
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```
|
||||
CERTIFICATE EXPIRES RESIDUAL TIME EXTERNALLY MANAGED
|
||||
admin.conf May 15, 2020 13:03 UTC 364d false
|
||||
apiserver May 15, 2020 13:00 UTC 364d false
|
||||
apiserver-etcd-client May 15, 2020 13:00 UTC 364d false
|
||||
apiserver-kubelet-client May 15, 2020 13:00 UTC 364d false
|
||||
controller-manager.conf May 15, 2020 13:03 UTC 364d false
|
||||
etcd-healthcheck-client May 15, 2020 13:00 UTC 364d false
|
||||
etcd-peer May 15, 2020 13:00 UTC 364d false
|
||||
etcd-server May 15, 2020 13:00 UTC 364d false
|
||||
front-proxy-client May 15, 2020 13:00 UTC 364d false
|
||||
scheduler.conf May 15, 2020 13:03 UTC 364d false
|
||||
```
|
||||
|
||||
The command shows expiration/residual time for the client certificates in the `/etc/kubernetes/pki` folder and for the client certificate embedded in the KUBECONFIG files used by kubeadm (`admin.conf`, `controller-manager.conf` and `scheduler.conf`).
|
||||
|
||||
Additionally, kubeadm informs the user if the certificate is externally managed; in this case, the user should take care of managing certificate renewal manually/using other tools.
|
||||
|
||||
{{< warning >}}
|
||||
`kubeadm` cannot manage certificates signed by an external CA.
|
||||
{{< /warning >}}
|
||||
|
||||
{{< note >}}
|
||||
`kubelet.conf` is not included in the list above because kubeadm configures kubelet for automatic certificate renewal.
|
||||
{{< /note >}}
|
||||
|
||||
## Automatic certificate renewal
|
||||
|
||||
`kubeadm` renews all the certificates during control plane [upgrade](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-15/).
|
||||
|
||||
This feature is designed for addressing the simplest use cases;
|
||||
if you don't have specific requirements on certificate renewal and perform Kubernetes version upgrades regularly (less than 1 year in between each upgrade), kubeadm will take care of keeping your cluster up to date and reasonably secure.
|
||||
|
||||
{{< note >}}
|
||||
It is a best practice to upgrade your cluster frequently in order to stay secure.
|
||||
{{< /note >}}
|
||||
|
||||
If you have more complex requirements for certificate renewal, you can opt out from the default behavior by passing `--certificate-renewal=false` to `kubeadm upgrade apply` or to `kubeadm upgrade node`.
|
||||
|
||||
|
||||
## Manual certificate renewal
|
||||
|
||||
You can renew your certificates manually at any time with the `kubeadm alpha certs renew` command.
|
||||
|
||||
This command performs the renewal using CA (or front-proxy-CA) certificate and key stored in `/etc/kubernetes/pki`.
|
||||
|
||||
{{< warning >}}
|
||||
If you are running an HA cluster, this command needs to be executed on all the control-plane nodes.
|
||||
{{< /warning >}}
|
||||
|
||||
{{< note >}}
|
||||
`alpha certs renew` uses the existing certificates as the authoritative source for attributes (Common Name, Organization, SAN, etc.) instead of the kubeadm-config ConfigMap. It is strongly recommended to keep them both in sync.
|
||||
{{< /note >}}
|
||||
|
||||
`kubeadm alpha certs renew` provides the following options:
|
||||
|
||||
The Kubernetes certificates normally reach their expiration date after one year.
|
||||
|
||||
- `--csr-only` can be used to renew certificats with an external CA by generating certificate signing requests (without actually renewing certificates in place); see next paragraph for more information.
|
||||
|
||||
- It's also possible to renew a single certificate instead of all.
|
||||
|
||||
## Renew certificates with the Kubernetes certificates API
|
||||
|
||||
This section provide more details about how to execute manual certificate renewal using the Kubernetes certificates API.
|
||||
|
||||
{{< caution >}}
|
||||
These are advanced topics for users who need to integrate their organization's certificate infrastructure into a kubeadm-built cluster. If the default kubeadm configuration satisfies your needs, you should let kubeadm manage certificates instead.
|
||||
{{< /caution >}}
|
||||
|
||||
### Set up a signer
|
||||
|
||||
The Kubernetes Certificate Authority does not work out of the box.
|
||||
You can configure an external signer such as [cert-manager][cert-manager-issuer], or you can use the build-in signer.
|
||||
The built-in signer is part of [`kube-controller-manager`][kcm].
|
||||
To activate the build-in signer, you pass the `--cluster-signing-cert-file` and `--cluster-signing-key-file` arguments.
|
||||
|
||||
The built-in signer is part of [`kube-controller-manager`][kcm].
|
||||
|
||||
To activate the build-in signer, you must pass the `--cluster-signing-cert-file` and `--cluster-signing-key-file` flags.
|
||||
|
||||
If you're creating a new cluster, you can use a kubeadm [configuration file][config]:
|
||||
|
||||
```yaml
|
||||
apiVersion: kubeadm.k8s.io/v1beta2
|
||||
kind: ClusterConfiguration
|
||||
controllerManager:
|
||||
extraArgs:
|
||||
cluster-signing-cert-file: /etc/kubernetes/pki/ca.crt
|
||||
cluster-signing-key-file: /etc/kubernetes/pki/ca.key
|
||||
```
|
||||
|
||||
[cert-manager-issuer]: https://cert-manager.readthedocs.io/en/latest/tutorials/ca/creating-ca-issuer.html
|
||||
[kcm]: /docs/reference/command-line-tools-reference/kube-controller-manager/
|
||||
[config]: https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2
|
||||
|
||||
### Create certificate signing requests (CSR)
|
||||
|
||||
You can create the certificate signing requests for the Kubernetes certificates API with `kubeadm alpha certs renew --use-api`.
|
||||
|
||||
If you set up an external signer such as [cert-manager][cert-manager], certificate signing requests (CSRs) are automatically approved.
|
||||
Otherwise, you must manually approve certificates with the [`kubectl certificate`][certs] command.
|
||||
The following kubeadm command outputs the name of the certificate to approve, then blocks and waits for approval to occur:
|
||||
|
||||
```shell
|
||||
sudo kubeadm alpha certs renew apiserver --use-api &
|
||||
```
|
||||
The output is similar to this:
|
||||
```
|
||||
[1] 2890
|
||||
[certs] certificate request "kubeadm-cert-kube-apiserver-ld526" created
|
||||
```
|
||||
|
||||
### Approve certificate signing requests (CSR)
|
||||
|
||||
If you set up an external signer, certificate signing requests (CSRs) are automatically approved.
|
||||
|
||||
Otherwise, you must manually approve certificates with the [`kubectl certificate`][certs] command. e.g.
|
||||
|
||||
```shell
|
||||
kubectl certificate approve kubeadm-cert-kube-apiserver-ld526
|
||||
```
|
||||
The output is similar to this:
|
||||
```shell
|
||||
certificatesigningrequest.certificates.k8s.io/kubeadm-cert-kube-apiserver-ld526 approved
|
||||
```
|
||||
|
||||
You can view a list of pending certificates with `kubectl get csr`.
|
||||
|
||||
## Renew certificates with external CA
|
||||
|
||||
This section provide more details about how to execute manual certificate renewal using an external CA.
|
||||
|
||||
To better integrate with external CAs, kubeadm can also produce certificate signing requests (CSRs).
|
||||
A CSR represents a request to a CA for a signed certificate for a client.
|
||||
In kubeadm terms, any certificate that would normally be signed by an on-disk CA can be produced as a CSR instead. A CA, however, cannot be produced as a CSR.
|
||||
|
||||
### Create certificate signing requests (CSR)
|
||||
|
||||
You can pass in a directory with `--csr-dir` to output the CSRs to the specified location.
|
||||
If `--csr-dir` is not specified, the default certificate directory (`/etc/kubernetes/pki`) is used.
|
||||
Both the CSR and the accompanying private key are given in the output. After a certificate is signed, the certificate and the private key must be copied to the PKI directory (by default `/etc/kubernetes/pki`).
|
||||
|
||||
A CSR represents a request to a CA for a signed certificate for a client.
|
||||
|
||||
You can create certificate signing requests with `kubeadm alpha certs renew --csr-only`.
|
||||
|
||||
Both the CSR and the accompanying private key are given in the output; you can pass in a directory with `--csr-dir` to output the CSRs to the specified location.
|
||||
|
||||
Certificates can be renewed with `kubeadm alpha certs renew --csr-only`.
|
||||
As with `kubeadm init`, an output directory can be specified with the `--csr-dir` flag.
|
||||
To use the new certificates, copy the signed certificate and private key into the PKI directory (by default `/etc/kubernetes/pki`)
|
||||
|
||||
A CSR contains a certificate's name, domain(s), and IPs, but it does not specify usages.
|
||||
|
||||
A CSR contains a certificate's name, domains, and IPs, but it does not specify usages.
|
||||
It is the responsibility of the CA to specify [the correct cert usages][cert-table] when issuing a certificate.
|
||||
|
||||
* In `openssl` this is done with the [`openssl ca` command][openssl-ca].
|
||||
* In `cfssl` you specify [usages in the config file][cfssl-usages]
|
||||
|
||||
After a certificate is signed using your preferred method, the certificate and the private key must be copied to the PKI directory (by default `/etc/kubernetes/pki`).
|
||||
|
||||
[openssl-ca]: https://superuser.com/questions/738612/openssl-ca-keyusage-extension
|
||||
[cfssl-usages]: https://github.com/cloudflare/cfssl/blob/master/doc/cmd/cfssl.txt#L170
|
||||
[certs]: /docs/setup/best-practices/certificates/
|
||||
[cert-cas]: /docs/setup/best-practices/certificates/#single-root-ca
|
||||
[cert-table]: /docs/setup/best-practices/certificates/#all-certificates
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -285,8 +285,10 @@ A possible workaround is described [here](https://github.com/kubernetes/kubeadm/
|
||||
{{< tabs name="k8s_kubelet_and_kubeadm" >}}
|
||||
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
|
||||
# replace x in 1.13.x-00 with the latest patch version
|
||||
apt-mark unhold kubelet kubeadm
|
||||
apt-get update
|
||||
apt-get install -y kubelet=1.13.x-00 kubeadm=1.13.x-00
|
||||
apt-mark hold kubelet kubeadm
|
||||
{{% /tab %}}
|
||||
{{% tab name="CentOS, RHEL or Fedora" %}}
|
||||
# replace x in 1.13.x-0 with the latest patch version
|
||||
|
||||
@@ -228,9 +228,9 @@ are merged into a single document.
|
||||
{{< tabs name="k8s_install_kubelet" >}}
|
||||
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
|
||||
# replace x in 1.14.x-00 with the latest patch version
|
||||
apt-mark unhold kubelet && \
|
||||
apt-mark unhold kubelet kubectl && \
|
||||
apt-get update && apt-get install -y kubelet=1.14.x-00 kubectl=1.14.x-00 && \
|
||||
apt-mark hold kubelet
|
||||
apt-mark hold kubelet kubectl
|
||||
{{% /tab %}}
|
||||
{{% tab name="CentOS, RHEL or Fedora" %}}
|
||||
# replace x in 1.14.x-0 with the latest patch version
|
||||
@@ -260,7 +260,7 @@ sudo kubeadm upgrade apply
|
||||
|
||||
Also `sudo kubeadm upgrade plan` is not needed.
|
||||
|
||||
## Ugrade worker nodes
|
||||
## Upgrade worker nodes
|
||||
|
||||
The upgrade procedure on worker nodes should be executed one node at a time or few nodes at a time,
|
||||
without compromising the minimum required capacity for running your workloads.
|
||||
@@ -290,16 +290,12 @@ without compromising the minimum required capacity for running your workloads.
|
||||
kubectl drain $NODE --ignore-daemonsets
|
||||
```
|
||||
|
||||
You should see output similar to this:
|
||||
You should see output similar to this:
|
||||
|
||||
```shell
|
||||
kubectl drain ip-172-31-85-18
|
||||
node "ip-172-31-85-18" cordoned
|
||||
error: unable to drain node "ip-172-31-85-18", aborting command...
|
||||
|
||||
There are pending nodes to be drained:
|
||||
ip-172-31-85-18
|
||||
error: DaemonSet-managed pods (use --ignore-daemonsets to ignore): calico-node-5798d, kube-proxy-thjp9
|
||||
node/ip-172-31-85-18 cordoned
|
||||
WARNING: ignoring DaemonSet-managed Pods: kube-system/kube-proxy-dj7d7, kube-system/weave-net-z65qx
|
||||
node/ip-172-31-85-18 drained
|
||||
```
|
||||
|
||||
### Upgrade the kubelet config
|
||||
|
||||
@@ -9,7 +9,7 @@ content_template: templates/task
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
This page explains how to upgrade a highly available (HA) Kubernetes cluster created with `kubeadm` from version 1.12.x to version 1.13.y. In addition to upgrading, you must also follow the instructions in [Creating HA clusters with kubeadm](/docs/setup/independent/high-availability/).
|
||||
This page explains how to upgrade a highly available (HA) Kubernetes cluster created with `kubeadm` from version 1.12.x to version 1.13.y. In addition to upgrading, you must also follow the instructions in [Creating HA clusters with kubeadm](/docs/setup/production-environment/tools/kubeadm/high-availability/).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -30,15 +30,15 @@ it simplifies node deployment and configuration management.
|
||||
|
||||
The subset of the Kubelet's configuration that can be configured via a file
|
||||
is defined by the `KubeletConfiguration` struct
|
||||
[here (v1beta1)](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/pkg/kubelet/apis/config/types.go).
|
||||
[here (v1beta1)](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go).
|
||||
|
||||
The configuration file must be a JSON or YAML representation of the parameters
|
||||
in this struct. Make sure the Kubelet has read permissions on the file.
|
||||
|
||||
Here is an example of what this file might look like:
|
||||
```
|
||||
kind: KubeletConfiguration
|
||||
apiVersion: kubelet.config.k8s.io/v1beta1
|
||||
kind: KubeletConfiguration
|
||||
evictionHard:
|
||||
memory.available: "200Mi"
|
||||
```
|
||||
|
||||
@@ -273,8 +273,12 @@ kubectl get deployment
|
||||
```
|
||||
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
|
||||
cattle 5 5 5 5 10s
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl get pods -l run=cattle
|
||||
```
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
cattle-2263376956-41xy6 1/1 Running 0 34s
|
||||
cattle-2263376956-kw466 1/1 Running 0 34s
|
||||
|
||||
+1
-1
@@ -45,7 +45,7 @@ DaemonSet configurations for Cilium, and the necessary configurations to connect
|
||||
to the etcd instance deployed in minikube as well as appropriate RBAC settings:
|
||||
|
||||
```shell
|
||||
kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.4/examples/kubernetes/1.13/cilium-minikube.yaml
|
||||
kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.5/examples/kubernetes/1.14/cilium-minikube.yaml
|
||||
```
|
||||
```
|
||||
configmap/cilium-config created
|
||||
|
||||
+1
-1
@@ -36,7 +36,7 @@ To apply network policies use one of the following:
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
Once your have installed Romana, you can follow the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) to try out Kubernetes NetworkPolicy.
|
||||
Once you have installed Romana, you can follow the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) to try out Kubernetes NetworkPolicy.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -140,7 +140,7 @@ The `kubelet` has the following default hard eviction threshold:
|
||||
|
||||
The `kubelet` evaluates eviction thresholds per its configured housekeeping interval.
|
||||
|
||||
* `housekeeping-interval` is the interval between container housekeepings.
|
||||
* `housekeeping-interval` is the interval between container housekeepings which defaults to `10s`.
|
||||
|
||||
### Node Conditions
|
||||
|
||||
|
||||
@@ -149,9 +149,6 @@ This is an example of a valid response:
|
||||
|
||||
```none
|
||||
apiVersion: v1
|
||||
data:
|
||||
kubelet: |
|
||||
{...}
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
creationTimestamp: 2017-09-14T20:23:33Z
|
||||
@@ -160,6 +157,9 @@ metadata:
|
||||
resourceVersion: "119980"
|
||||
selfLink: /api/v1/namespaces/kube-system/configmaps/my-node-config-gkt4c2m4b2
|
||||
uid: 946d785e-998a-11e7-a8dd-42010a800006
|
||||
data:
|
||||
kubelet: |
|
||||
{...}
|
||||
```
|
||||
|
||||
The ConfigMap is created in the `kube-system` namespace because this
|
||||
|
||||
@@ -4,13 +4,12 @@ reviewers:
|
||||
- mml
|
||||
- foxish
|
||||
- kow3ns
|
||||
title: Safely Drain a Node while Respecting Application SLOs
|
||||
title: Safely Drain a Node while Respecting the PodDisruptionBudget
|
||||
content_template: templates/task
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
This page shows how to safely drain a machine, respecting the application-level
|
||||
disruption SLOs you have specified using PodDisruptionBudget.
|
||||
This page shows how to safely drain a machine, respecting the PodDisruptionBudget you have defined.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
@@ -46,11 +45,10 @@ documentation for more details.
|
||||
|
||||
When `kubectl drain` returns successfully, that indicates that all of
|
||||
the pods (except the ones excluded as described in the previous paragraph)
|
||||
have been safely evicted (respecting the desired graceful
|
||||
termination period, and without violating any application-level
|
||||
disruption SLOs). It is then safe to bring down the node by powering
|
||||
down its physical machine or, if running on a cloud platform, deleting its
|
||||
virtual machine.
|
||||
have been safely evicted (respecting the desired graceful termination period,
|
||||
and respecting the PodDisruptionBudget you have defined). It is then safe to
|
||||
bring down the node by powering down its physical machine or, if running on a
|
||||
cloud platform, deleting its virtual machine.
|
||||
|
||||
First, identify the name of the node you wish to drain. You can list all of the nodes in your cluster with
|
||||
|
||||
|
||||
@@ -9,7 +9,8 @@ content_template: templates/task
|
||||
{{< feature-state for_k8s_version="v1.12" state="beta" >}}
|
||||
|
||||
This document describes how to configure and use kernel parameters within a
|
||||
Kubernetes cluster using the sysctl interface.
|
||||
Kubernetes cluster using the {{< glossary_tooltip term_id="sysctl" >}}
|
||||
interface.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -80,7 +81,7 @@ kubelet --allowed-unsafe-sysctls \
|
||||
'kernel.msg*,net.ipv4.route.min_pmtu' ...
|
||||
```
|
||||
|
||||
For minikube, this can be done via the `extra-config` flag:
|
||||
For {{< glossary_tooltip term_id="minikube" >}}, this can be done via the `extra-config` flag:
|
||||
|
||||
```shell
|
||||
minikube start --extra-config="kubelet.allowed-unsafe-sysctls=kernel.msg*,net.ipv4.route.min_pmtu"...
|
||||
|
||||
Reference in New Issue
Block a user