Change:
This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: There are words should be unified in and . For the sake of clarity, the same words should be used for things that have the same meaning. Proposed Solution: We should use either the terms "network solution" or "network add-on". Page to Update: Troubleshooting kubeadm: Installing Addons: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
modifying the kubeadm troubleshooting page to use "addon" instead of "solution" seems fine to me. PRs welcome! /help /sig cluster-lifecycle /kind cleanup /priority backlog
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : modifying the kubeadm troubleshooting page to use "addon" instead of "solution" seems fine to me. PRs welcome! /sig cluster-lifecycle /kind cleanup /priority backlog </details
/assign
/assign

Discussion:
- If there are pods in one of these states _right after_ `kubeadm init`, please open an issue in the kubeadm repo. `coredns` (or `kube-dns`) should be in the `Pending` state <del> until you have deployed the network solution. </del> <ins> until you have deployed the network add-on. </ins> - If you see Pods in the `RunContainerError`, `CrashLoopBackOff` or `Error` state <del> 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. </del> <ins> after deploying the network add-on and nothing happens to `coredns` (or `kube-dns`), it's very likely that the Pod Network add-on that you installed is somehow broken. </ins> 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. - If you install a version of Docker older than 1.12.1, remove the `MountFlags=slave` option

## `coredns` (or `kube-dns`) is stuck in the `Pending` state This is **expected** and part of the design. kubeadm is network provider-agnostic, so the admin <del> should [install the pod network solution](/docs/concepts/cluster-administration/addons/) </del> <ins> should [install the pod network add-on](/docs/concepts/cluster-administration/addons/) </ins> of choice. You have to install a Pod Network before CoreDNS may be deployed fully. Hence the `Pending` state before the network is set up. ## `HostPort` services do not work The `HostPort` and `HostIP` functionality is available depending on your Pod Network <del> provider. Please contact the author of the Pod Network solution to find out whether </del> <ins> provider. Please contact the author of the Pod Network add-on to find out whether </ins> `HostPort` and `HostIP` functionality are available. Calico, Canal, and Flannel CNI providers are verified to support HostPort.