independent: update CoreDNS mentions for kubeadm (#8753)
Give CoreDNS instead of kube-dns examples in: - docs/setup/independent/create-cluster-kubeadm.md - docs/setup/independent/troubleshooting-kubeadm.md
This commit is contained in:
Lubomir I. Ivanov
committed by
Misty Linville
Misty Linville
parent
f57085d519
commit
cac04327ea
@@ -20,7 +20,54 @@ kubeadm's simplicity means it can serve a wide range of use cases:
|
||||
- Users familiar with Kubernetes can spin up clusters with kubeadm and test their applications.
|
||||
- Larger projects can include kubeadm as a building block in a more complex system that can also include other installer tools.
|
||||
|
||||
kubeadm's overall feature state is **Beta**.
|
||||
kubeadm is designed to be a simple way for new users to start trying
|
||||
Kubernetes out, possibly for the first time, a way for existing users to
|
||||
test their application on and stitch together a cluster easily, and also to be
|
||||
a building block in other ecosystem and/or installer tool with a larger
|
||||
scope.
|
||||
|
||||
You can install _kubeadm_ very easily on operating systems that support
|
||||
installing deb or rpm packages. The responsible SIG for kubeadm,
|
||||
[SIG Cluster Lifecycle](https://github.com/kubernetes/community/tree/master/sig-cluster-lifecycle), provides these packages pre-built for you,
|
||||
but you may also on other OSes.
|
||||
|
||||
|
||||
### kubeadm Maturity
|
||||
|
||||
| Area | Maturity Level |
|
||||
|---------------------------|--------------- |
|
||||
| Command line UX | beta |
|
||||
| Implementation | beta |
|
||||
| Config file API | alpha |
|
||||
| Self-hosting | alpha |
|
||||
| kubeadm alpha subcommands | alpha |
|
||||
| CoreDNS | GA |
|
||||
| DynamicKubeletConfig | alpha |
|
||||
|
||||
|
||||
kubeadm's overall feature state is **Beta** and will soon be graduated to
|
||||
**General Availability (GA)** during 2018. Some sub-features, like self-hosting
|
||||
or the configuration file API are still under active development. The
|
||||
implementation of creating the cluster may change slightly as the tool evolves,
|
||||
but the overall implementation should be pretty stable. Any commands under
|
||||
`kubeadm alpha` are by definition, supported on an alpha level.
|
||||
|
||||
|
||||
### Support timeframes
|
||||
|
||||
Kubernetes releases are generally supported for nine months, and during that
|
||||
period a patch release may be issued from the release branch if a severe bug or
|
||||
security issue is found. Here are the latest Kubernetes releases and the support
|
||||
timeframe; which also applies to `kubeadm`.
|
||||
|
||||
| Kubernetes version | Release month | End-of-life-month |
|
||||
|--------------------|----------------|-------------------|
|
||||
| v1.6.x | March 2017 | December 2017 |
|
||||
| v1.7.x | June 2017 | March 2018 |
|
||||
| v1.8.x | September 2017 | June 2018 |
|
||||
| v1.9.x | December 2017 | September 2018 |
|
||||
| v1.10.x | March 2018 | December 2018 |
|
||||
| v1.11.x | June 2018 | March 2019 |
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -99,11 +146,38 @@ is ready to run Kubernetes. These prechecks expose warnings and exit on errors.
|
||||
then downloads and installs the cluster control plane components. This may take several minutes.
|
||||
The output should look like:
|
||||
|
||||
```
|
||||
```none
|
||||
[init] Using Kubernetes version: vX.Y.Z
|
||||
[preflight] Running pre-flight checks
|
||||
|
||||
... (log output of initialization workflow) ...
|
||||
[kubeadm] WARNING: starting in 1.8, tokens expire after 24 hours by default (if you require a non-expiring token use --token-ttl 0)
|
||||
[certificates] Generated ca certificate and key.
|
||||
[certificates] Generated apiserver certificate and key.
|
||||
[certificates] apiserver serving cert is signed for DNS names [kubeadm-master kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 10.138.0.4]
|
||||
[certificates] Generated apiserver-kubelet-client certificate and key.
|
||||
[certificates] Generated sa key and public key.
|
||||
[certificates] Generated front-proxy-ca certificate and key.
|
||||
[certificates] Generated front-proxy-client certificate and key.
|
||||
[certificates] Valid certificates and keys now exist in "/etc/kubernetes/pki"
|
||||
[kubeconfig] Wrote KubeConfig file to disk: "admin.conf"
|
||||
[kubeconfig] Wrote KubeConfig file to disk: "kubelet.conf"
|
||||
[kubeconfig] Wrote KubeConfig file to disk: "controller-manager.conf"
|
||||
[kubeconfig] Wrote KubeConfig file to disk: "scheduler.conf"
|
||||
[controlplane] Wrote Static Pod manifest for component kube-apiserver to "/etc/kubernetes/manifests/kube-apiserver.yaml"
|
||||
[controlplane] Wrote Static Pod manifest for component kube-controller-manager to "/etc/kubernetes/manifests/kube-controller-manager.yaml"
|
||||
[controlplane] Wrote Static Pod manifest for component kube-scheduler to "/etc/kubernetes/manifests/kube-scheduler.yaml"
|
||||
[etcd] Wrote Static Pod manifest for a local etcd instance to "/etc/kubernetes/manifests/etcd.yaml"
|
||||
[init] Waiting for the kubelet to boot up the control plane as Static Pods from directory "/etc/kubernetes/manifests"
|
||||
[init] This often takes around a minute; or longer if the control plane images have to be pulled.
|
||||
[apiclient] All control plane components are healthy after 39.511972 seconds
|
||||
[uploadconfig] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
|
||||
[markmaster] Will mark node master as master by adding a label and a taint
|
||||
[markmaster] Master master tainted and labelled with key/value: node-role.kubernetes.io/master=""
|
||||
[bootstraptoken] Using token: <token>
|
||||
[bootstraptoken] Configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
|
||||
[bootstraptoken] Configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
|
||||
[bootstraptoken] Creating the "cluster-info" ConfigMap in the "kube-public" namespace
|
||||
[addons] Applied essential addon: CoreDNS
|
||||
[addons] Applied essential addon: kube-proxy
|
||||
|
||||
Your Kubernetes master has initialized successfully!
|
||||
|
||||
@@ -156,9 +230,8 @@ created, and deleted with the `kubeadm token` command. See the
|
||||
You must install a pod network add-on so that your pods can communicate with
|
||||
each other.
|
||||
|
||||
The network must be deployed before any applications. An
|
||||
internal helper service, kube-dns, will not start up before a network is installed. kubeadm
|
||||
supports only Container Network Interface (CNI) based networks. It does not support kubenet.
|
||||
**The network must be deployed before any applications. Also, CoreDNS will not start up before a network is installed.
|
||||
kubeadm only supports Container Network Interface (CNI) based networks (and does not support kubenet).**
|
||||
|
||||
Several projects provide Kubernetes pod networks using CNI, some of which also
|
||||
support [Network Policy](/docs/concepts/services-networking/networkpolicies/). See the [add-ons page](/docs/concepts/cluster-administration/addons/) for a complete list of available network add-ons.
|
||||
@@ -263,11 +336,12 @@ kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl versio
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
Once you install a pod network, you can confirm that it works by
|
||||
checking that the kube-dns pod is Running in the output of `kubectl get pods --all-namespaces`.
|
||||
Once the kube-dns pod is up and running, you can continue by joining your nodes.
|
||||
|
||||
If your network is not working or kube-dns is not in the Running state, check
|
||||
Once a pod network has been installed, you can confirm that it is working by
|
||||
checking that the CoreDNS pod is Running in the output of `kubectl get pods --all-namespaces`.
|
||||
And once the CoreDNS pod is up and running, you can continue by joining your nodes.
|
||||
|
||||
If your network is not working or CoreDNS is not in the Running state, check
|
||||
out our [troubleshooting docs](/docs/setup/independent/troubleshooting-kubeadm/).
|
||||
|
||||
### Master Isolation
|
||||
|
||||
@@ -101,14 +101,17 @@ Right after `kubeadm init` there should not be any pods in these states.
|
||||
until you have deployed the network solution.
|
||||
- If you see Pods in the `RunContainerError`, `CrashLoopBackOff` or `Error` state
|
||||
after deploying the network solution and nothing happens to `coredns` (or `kube-dns`),
|
||||
it's very likely that the Pod Network solution that you installed is somehow broken.
|
||||
You might have to grant it more RBAC privileges or use a newer version. Please file
|
||||
it's very likely that the Pod Network solution and nothing happens to the DNS server, it's very
|
||||
likely that the Pod Network solution that you installed is somehow broken. You
|
||||
might have to grant it more RBAC privileges or use a newer version. Please file
|
||||
an issue in the Pod Network providers' issue tracker and get the issue triaged there.
|
||||
|
||||
#### `coredns` (or `kube-dns`) is stuck in the `Pending` state
|
||||
|
||||
kubeadm does not install a [pod network solution](https://kubernetes.io/docs/concepts/cluster-administration/addons/)
|
||||
by default. You have to install a Pod Network before `coredns` (or `kube-dns`) pods will be scheduled.
|
||||
This is **expected** and part of the design. kubeadm is network provider-agnostic, so the admin
|
||||
should [install the pod network solution](/docs/concepts/cluster-administration/addons/)
|
||||
of choice. You have to install a Pod Network
|
||||
before CoreDNS may deployed fully. Hence the `Pending` state before the network is set up.
|
||||
|
||||
#### `HostPort` services do not work
|
||||
|
||||
@@ -140,7 +143,7 @@ services](/docs/concepts/services-networking/service/#type-nodeport) or use `Hos
|
||||
|
||||
The following error indicates a possible certificate mismatch.
|
||||
|
||||
```sh
|
||||
```none
|
||||
# kubectl get pods
|
||||
Unable to connect to the server: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "kubernetes")
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user