Release 1.9 (#5978)
* Trivial change to open release branch * Undo trivial change * add service ipvs overview * Add instructions on how to setup kubectl * Document conntrack dependency for kube-proxy * Add an a This is kind of jarring / missing an article. I'm guessing it should either be ' to a rack of bare metal servers.' or '...to racks of bare metal servers.'. * adding example responses for common issues - support request - code bug report * Trivial change to open release branch * Undo trivial change * Signed-off-by: Ziqi Zhao <zhaoziqi@qiniu.com> (#5366) Fix the not-working test case yaml for /doc/concepts/storage/volumes.md * kubectl-overview * temp fix for broken pod and deployment links * Update Table of Solutions for Juju * Revise certificates documentation (#5965) * Update review-issues.md Some edits for clarity and condensed language. * Update init-containers.md Fix leading spaces in commands. * Update kubectl-overview.md Fix format. * Update clc.md Fix format. * Update openstack-heat.md The url no need. just highlight. * Typo I believe this should be "users" not "uses" * making explicit hostname uniq requirement * Update scheduling-hugepages.md * Update update-daemon-set.md * fix redirection of PersistentVolume * Update hpa.md * update kubectl instruction * Use the format of kubeadm init * fix spelling error guarnatees to guarantees * add matchLabels description (#6020) * search and replace for k8s.github.io to website (#6019) * fix scale command of object-management (#6011) * Update replicaset.md (#6009) * Update secret.md (#6008) * specify password for mysql image (#5990) * specify password for mysql image * specify password for mysql image * link error for run-stateless-application-deployment.md (#5985) * link error for run-stateless-application-deployment.md * link error for run-stateless-application-deployment.md * Add performance implications of inter-pod affinity/anti-affinity (#5979) * 404 monthly maintenance - October 2017 (#5977) * Updated redirects * More redirects * Add conjure-up to Turnkey Cloud Solutions list (#5973) * Add conjure-up to Turnkey Cloud Solutions list * Changed wording slightly * change the StatefulSet to ReplicaSet in reference (#5968) * Clarification of failureThreshold of probes (#5963) * Mention usage of block storage version param (#5925) Mention usage of block storage version (bs-version) parameter to workaround attachment issues using older K8S versions on an OpenStack cloud with path-based endpoints. Resolves: https://github.com/kubernetes/kubernetes.github.io/issues/5924 * Update sysctl-cluster.md (#5894) Include guide on enabling unsafe sysctls in minikube * Avoid Latin phrases & format note (#5889) * Avoid Latin phrases & format note according the Documentation Style Guide * Update scratch.md * Update scratch.md * resolves jekyll rendering error (#5976) - chinese isn't understood for keys in YAML frontmatter in jekyll, so replaced it with the english equivalent that doesn't throw the following error on rendering: Error reading file src/kubernetes.github.io/cn/docs/concepts/cluster-administration/device-plugins.md: (<unknown>): could not find expected ':' while scanning a simple key at line 4 column 1 * Change VM to pod. (#6022) * Add link to custom metrics. (#6023) * Rephrase core group. (#6024) * Added explanation on context to when joining (#6018) * Update create-cluster-kubeadm.md (#5761) Update Canal version in pod network apply commands * Fixes issue #5620 (#5869) * Fixes issue #5620 Signed-off-by: Brad Topol <btopol@us.ibm.com> * Restructured so that review process is for both current and upcoming releases. Added content describing the use of tech reviewers. * Removed incorrect Kubernetes reviewer link. * Fixed tech reviewer URL to now use website * Update pod-priority-preemption.md fix-wrong-link-to-pod-preemption * pod-security-policy.md: add links to the page about admission plugins. * Adding all files for BlaBlaCar case study (#5857) * Adding all files for BlaBlaCar case study * Update blablacar.html * Fix changed URL for google containers * Add /docs/reference/auto-generated directory * correct the downwardapi redirect * Remove links using "here" * Rename to /docs/reference/generated directory * add Concept template * Change title to just Ingress * Link mistake (#6038) * link mistake * link mistake * skip title check for skip_title_check.txt * skip title check for skip_title_check.txt * remove doesn't exist link. * Fix podpreset task (#5705) * Add a simple pod manifest to pod overview (#5986) * Split PodPreset concept out from task doc (#5984) * Add selector spec description (#5789) * Add selector spec description * Fix selector field explanation * Put orphaned topics in TOC. (#6051) * static-pod example bad format in the final page (#6050) * static-pod example bad format in the final page * static-pod example bad format in the final page * static-pod example bad format in the final page * static-pod example bad format in the final page * static-pod example bad format in the final page * Fix `backoffLimit` field misplacement (#6042) It should be placed in JobSpec according to: https://github.com/kubernetes/kubernetes/blob/master/api/swagger-spec/batch_v1.json#L1488-L1514 * Update addons.md (#6061) * add info about VMware NSX-T CNI plugin (#5987) * add info about VMware NSX-T CNI plugin Hello, I'm VMware Networking and Security Architect and would like to include short information about our CNI plugin implementation similar to what other vendors did Best regards Emil Gagala * Update networking.md * Update networking.md * Update networking.md * Update: Using universal zsh configuration (#5669) * Update install-kubectl.md Zsh is not only oh-my-zsh, so I added universal configuration for zsh that also can be used in prezto. * fix merge error after rebase * Operating etcd cluster for Kubernetes bad format in the final page (#6056) * Operating etcd cluster for Kubernetes bad format in the final page * Update configure-upgrade-etcd.md * Update configure-upgrade-etcd.md * Usage note and warning tags. (#6053) * Usage note and warning tags. * Update configure-upgrade-etcd.md * Update configure-upgrade-etcd.md * Document jekyll includes snippets * Add jekyll includes to docs home toc - Remove extra kubernetes home in toc * document docker cgroupdriver req (#5937) * Update test blacklists (#6063) * Update toc check blacklist * Update title check blacklist * wip * wip * Fix typo * Document unconfined apparmor profile * Revert "Document the unconfined profile for AppArmor" (#6268) * CRD Validation: remove alpha warning, change enable instructions to (#6066) disable * Documented service annotation for AWS ELB SSL policy * kubeadm: add a note about the new `--print-join-command` flag. This is a new flag for the `kubeadm token create` command. * Add a note to PDB page * Improve Kubeadm reference doc (#6103) * automatically-generated kubeadm reference doc * user-mantained kubeadm reference doc * Documentation for CSIPersistentVolume * change replicaset documentation to use apps/v1 APIs * Update service.md ipvs alpha version -> beta version * Updated Deployment concept docs (#6494) * Updated Deployment concept docs * Addressed comments * Documentation for volume scheduling alpha feature * Update admission control docs for webhooks * Improve DNS documentation (#6479) * update ds for 1.9 * Update service.md * Update service.md * Revert "begin updating webhook documentation" (#6575) * Update version numbers to include 1.9 (#6518) * Update site versions for 1.9 * Removed 1.4 docs * Update _config.yml * Update _config.yml * updates for raw block devices * rbac: docs for aggregated cluster roles (#6474) * Added IPv6 information for Kubelet arguments (#6498) * Added IPv6 info to kube-proxy arguments * Added IPv6 information for argument for kubelet * Update PVC resizing documentation (#6487) * Updates for Windows Server version 1709 with K8s v1.8 (#6180) * Updated for WSv1709 and K8s v1.8 * Updated picture and CNI config * Fixed formatting on CNI Config * Updated docs to reference Microsoft/SDN GitHub docs * fix typo * Workaround for Jekyllr frontmatter * Added section on features and limitations, with example yaml files. * Update index.md * Added kubeadm section, few other small fixes * Few minor grammar fixes * Update access-cluster.md with a comment that for IPv6 the user should use [::1] for the localhost * Addressed a number of issues brought up against the base PR * Fixed windows-host-setup link * Rewrite PodSecurityPolicy guide * Update index.md Signed-off-by: Alin Balutoiu <abalutoiu@cloudbasesolutions.com> Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org> * Spelling correction and sentence capitalization. - Corrected the spelling error for storing, was put in as 'stoing'. - Capitalized list items. - Added '.' at end of sentences in the list items. * Update index.md * Update index.md * Addressed comments and rebased * Fixed formatting * Fixed formatting * Updated header link * Updated hyperlinks * Updated warning * formatting * formatting * formatting * Revert "Update access-cluster.md with a comment that for IPv6" This reverts commit31e4dbdc25. * Revert "fix typo" This reverts commitc05678752d. * Revert "Workaround for Jekyllr frontmatter" This reverts commitb84ac59624. * Fixed grammatical issues and reverted non-related commits * Revert "Rewrite PodSecurityPolicy guide" This reverts commit5d39cfeae4. * Revert "Spelling correction and sentence capitalization." This reverts commit47eed4346e. * Fixed auto-numbering * Minor formatting updates * CoreDNS feature documentation (#6463) * Initial placeholder PR for CoreDNS feature documentation * Remove from admin, add content * Fix missing endcapture * Add to tasks.yml * Review feedback * Postpone Deletion of a Persistent Volume Claim in case It Is Used by a Pod (#6415) * Postpone Deletion of a Persistent Volume Claim in case It Is Used by a Pod A new feature PVC Protection was added into K8s 1.9 that's why this documentation change is needed. * Added tag at the top of each new area. * Fix typo * Fix: switched on in (all kubelets) -> (all K8s components). * Added link to admission controller * Moved PVC Protection configuration into Before you begin section. * Added steps how to verify PVC Protection feature. * Fixes for admission controller plugin description and for PVC Protection description in PVC lifecycle. * Testing official rendering of enumerations (1., 2., 3., etc.) * Re-write to address comments from review. * Fixed definition when a PVC is in active use by a pod. * Change auditing docs page for 1.9 release (#6427) * Change auditing docs page for 1.9 release Signed-off-by: Mik Vyatskov <vmik@google.com> * Address review comments Signed-off-by: Mik Vyatskov <vmik@google.com> * Address review comments Signed-off-by: Mik Vyatskov <vmik@google.com> * Address review comments Signed-off-by: Mik Vyatskov <vmik@google.com> * Fix broken link Signed-off-by: Mik Vyatskov <vmik@google.com> * short circuit deny docs (#6536) * line wrap * short circuit deny * address comments * Add kubeadm 1.9 upgrade docs (#6485) * kubeadm: Improve kubeadm documentation for v1.9 (#6645) * Update admission control docs for webhooks (re-send #6368) (#6650) * Update admission control docs for webhooks * update in response to comments * Revamp rkt and add CRI-O as alternative runtime (#6371) Signed-off-by: Lorenzo Fontana <lo@linux.com> * Documented NLB for Kubernetes 1.9 (#6260) * Added IPV6 information to setup cluster using kubeadm (#6465) * Added IPV6 information to setup cluster using kubeadm * Updated kubeadm.md & create-cluster-kubeadm.md with IPv6 related information * Added IPv6 options for kubeadm --init & automated address binding for kube-proxy based on version of IP configured for API server) * Changes to kubeadm.md as per comments * Modified kubeadm.md and create-cluster-kubeadm.md * Implemented changes requested by zacharysarah * Removed autogenerated kubeadm.md changes * StatefulSet 1.9 updates. (#6550) * updates sts concept and tutorials to use 1.9 apps/v1 * Update statefulset.md * clarify pod name label * Garbage collection updates for 1.9 (#6555) * 1.9 gc policy update * carify deletion * Couple nits for dnsConfig doc (#6652) * Add doc for AllowedFlexVolume (#6563) * Update OpenStack Cloud Provider API support for v1.9 (#6638) * Flex volume is GA. Remove alpha notation. (#6666) * Update generated ref docs for Kubernetes and Federation components. (#6658) * Update generated ref docs for Kubernetes and Federation components. * Rename kubectl-options to kubectl. * Add title to kubectl. * Fix double synopsis. * Update Federation API ref docs for 1.9. (#6636) * Update federation API ref docs. * Move and redirect. * Move generated Federation docs to the generated directory. * Fix titles. * Type * Fix titles * Update auto-generated Kubernetes APi ref docs. (#6646) * Update kubectl commands for 1.9 (#6635) * add ExtendedResourceToleration admission controller (#6618) * Update API reference paths for v1.9 (#6681)
This commit is contained in:
Zach Corleissen
@@ -0,0 +1,20 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
namespace: ns1
|
||||
name: dns-example
|
||||
spec:
|
||||
containers:
|
||||
- name: test
|
||||
image: nginx
|
||||
dnsPolicy: "None"
|
||||
dnsConfig:
|
||||
nameservers:
|
||||
- 1.2.3.4
|
||||
searches:
|
||||
- ns1.svc.cluster.local
|
||||
- my.dns.search.suffix
|
||||
options:
|
||||
- name: ndots
|
||||
value: "2"
|
||||
- name: edns0
|
||||
@@ -2,21 +2,24 @@
|
||||
approvers:
|
||||
- davidopp
|
||||
- thockin
|
||||
title: DNS Pods and Services
|
||||
title: DNS for Services and Pods
|
||||
---
|
||||
{% capture overview %}
|
||||
This page provides an overview of DNS support by Kubernetes.
|
||||
{% endcapture %}
|
||||
|
||||
* TOC
|
||||
{:toc}
|
||||
|
||||
## Introduction
|
||||
{% capture body %}
|
||||
|
||||
As of Kubernetes 1.3, DNS is a built-in service launched automatically using the addon manager [cluster add-on](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/README.md).
|
||||
## Introduction
|
||||
|
||||
Kubernetes DNS schedules a DNS Pod and Service on the cluster, and configures
|
||||
the kubelets to tell individual containers to use the DNS Service's IP to
|
||||
resolve DNS names.
|
||||
|
||||
## What things get DNS names?
|
||||
### What things get DNS names?
|
||||
|
||||
Every Service defined in the cluster (including the DNS server itself) is
|
||||
assigned a DNS name. By default, a client Pod's DNS search list will
|
||||
@@ -28,17 +31,15 @@ in namespace `bar` can look up this service by simply doing a DNS query for
|
||||
`foo`. A Pod running in namespace `quux` can look up this service by doing a
|
||||
DNS query for `foo.bar`.
|
||||
|
||||
## Supported DNS schema
|
||||
|
||||
The following sections detail the supported record types and layout that is
|
||||
supported. Any other layout or names or queries that happen to work are
|
||||
considered implementation details and are subject to change without warning.
|
||||
For more up-to-date specification, see
|
||||
[Kubernetes DNS-Based Service Discovery](https://github.com/kubernetes/dns/blob/master/docs/specification.md).
|
||||
|
||||
### Services
|
||||
## Services
|
||||
|
||||
#### A records
|
||||
### A records
|
||||
|
||||
"Normal" (not headless) Services are assigned a DNS A record for a name of the
|
||||
form `my-svc.my-namespace.svc.cluster.local`. This resolves to the cluster IP
|
||||
@@ -50,7 +51,7 @@ Services, this resolves to the set of IPs of the pods selected by the Service.
|
||||
Clients are expected to consume the set or else use standard round-robin
|
||||
selection from the set.
|
||||
|
||||
#### SRV records
|
||||
### SRV records
|
||||
|
||||
SRV Records are created for named ports that are part of normal or [Headless
|
||||
Services](/docs/concepts/services-networking/service/#headless-services).
|
||||
@@ -62,37 +63,29 @@ For a headless service, this resolves to multiple answers, one for each pod
|
||||
that is backing the service, and contains the port number and a CNAME of the pod
|
||||
of the form `auto-generated-name.my-svc.my-namespace.svc.cluster.local`.
|
||||
|
||||
#### Backwards compatibility
|
||||
## Pods
|
||||
|
||||
Previous versions of kube-dns made names of the form
|
||||
`my-svc.my-namespace.cluster.local` (the 'svc' level was added later). This
|
||||
is no longer supported.
|
||||
### A Records
|
||||
|
||||
### Pods
|
||||
When enabled, pods are assigned a DNS A record in the form of
|
||||
"`pod-ip-address.my-namespace.pod.cluster.local`".
|
||||
|
||||
#### A Records
|
||||
For example, a pod with IP `1.2.3.4` in the namespace `default` with a DNS name
|
||||
of `cluster.local` would have an entry: `1-2-3-4.default.pod.cluster.local`.
|
||||
|
||||
When enabled, pods are assigned a DNS A record in the form of `pod-ip-address.my-namespace.pod.cluster.local`.
|
||||
|
||||
For example, a pod with IP `1.2.3.4` in the namespace `default` with a DNS name of `cluster.local` would have an entry: `1-2-3-4.default.pod.cluster.local`.
|
||||
|
||||
#### A Records and hostname based on Pod's hostname and subdomain fields
|
||||
### Pod's hostname and subdomain fields
|
||||
|
||||
Currently when a pod is created, its hostname is the Pod's `metadata.name` value.
|
||||
|
||||
With v1.2, users can specify a Pod annotation, `pod.beta.kubernetes.io/hostname`, to specify what the Pod's hostname should be.
|
||||
The Pod annotation, if specified, takes precedence over the Pod's name, to be the hostname of the pod.
|
||||
For example, given a Pod with annotation `pod.beta.kubernetes.io/hostname: my-pod-name`, the Pod will have its hostname set to "my-pod-name".
|
||||
The Pod spec has an optional `hostname` field, which can be used to specify the
|
||||
Pod's hostname. When specified, it takes precedence over the Pod's name to be
|
||||
the hostname of the pod. For example, given a Pod with `hostname` set to
|
||||
"`my-host`", the Pod will have its hostname set to "`my-host`".
|
||||
|
||||
With v1.3, the PodSpec has a `hostname` field, which can be used to specify the Pod's hostname. This field value takes precedence over the
|
||||
`pod.beta.kubernetes.io/hostname` annotation value.
|
||||
|
||||
v1.2 introduces a beta feature where the user can specify a Pod annotation, `pod.beta.kubernetes.io/subdomain`, to specify the Pod's subdomain.
|
||||
The final domain will be "<hostname>.<subdomain>.<pod namespace>.svc.<cluster domain>".
|
||||
For example, a Pod with the hostname annotation set to "foo", and the subdomain annotation set to "bar", in namespace "my-namespace", will have the FQDN "foo.bar.my-namespace.svc.cluster.local"
|
||||
|
||||
With v1.3, the PodSpec has a `subdomain` field, which can be used to specify the Pod's subdomain. This field value takes precedence over the
|
||||
`pod.beta.kubernetes.io/subdomain` annotation value.
|
||||
The Pod spec also has an optional `subdomain` field which can be used to specify
|
||||
its subdomain. For example, a Pod with `hostname` set to "`foo`", and `subdomain`
|
||||
set to "`bar`", in namespace "`my-namespace`", will have the fully qualified
|
||||
domain name (FQDN) "`foo.bar.my-namespace.svc.cluster.local`".
|
||||
|
||||
Example:
|
||||
|
||||
@@ -143,105 +136,49 @@ spec:
|
||||
name: busybox
|
||||
```
|
||||
|
||||
If there exists a headless service in the same namespace as the pod and with the same name as the subdomain, the cluster's KubeDNS Server also returns an A record for the Pod's fully qualified hostname.
|
||||
Given a Pod with the hostname set to "busybox-1" and the subdomain set to "default-subdomain", and a headless Service named "default-subdomain" in the same namespace, the pod will see its own FQDN as "busybox-1.default-subdomain.my-namespace.svc.cluster.local". DNS serves an A record at that name, pointing to the Pod's IP. Both pods "busybox1" and "busybox2" can have their distinct A records.
|
||||
If there exists a headless service in the same namespace as the pod and with
|
||||
the same name as the subdomain, the cluster's KubeDNS Server also returns an A
|
||||
record for the Pod's fully qualified hostname.
|
||||
For example, given a Pod with the hostname set to "`busybox-1`" and the subdomain set to
|
||||
"`default-subdomain`", and a headless Service named "`default-subdomain`" in
|
||||
the same namespace, the pod will see its own FQDN as
|
||||
"`busybox-1.default-subdomain.my-namespace.svc.cluster.local`". DNS serves an
|
||||
A record at that name, pointing to the Pod's IP. Both pods "`busybox1`" and
|
||||
"`busybox2`" can have their distinct A records.
|
||||
|
||||
As of Kubernetes v1.2, the Endpoints object also has the annotation `endpoints.beta.kubernetes.io/hostnames-map`. Its value is the json representation of map[string(IP)][endpoints.HostRecord], for example: '{"10.245.1.6":{HostName: "my-webserver"}}'.
|
||||
If the Endpoints are for a headless service, an A record is created with the format <hostname>.<service name>.<pod namespace>.svc.<cluster domain>
|
||||
For the example json, if endpoints are for a headless service named "bar", and one of the endpoints has IP "10.245.1.6", an A record is created with the name "my-webserver.bar.my-namespace.svc.cluster.local" and the A record lookup would return "10.245.1.6".
|
||||
This endpoints annotation generally does not need to be specified by end-users, but can used by the internal service controller to deliver the aforementioned feature.
|
||||
The Endpoints object can specify the `hostname` for any endpoint addresses,
|
||||
along with its IP.
|
||||
|
||||
With v1.3, The Endpoints object can specify the `hostname` for any endpoint, along with its IP. The hostname field takes precedence over the hostname value
|
||||
that might have been specified via the `endpoints.beta.kubernetes.io/hostnames-map` annotation.
|
||||
### Pod's DNS Policy
|
||||
|
||||
With v1.3, the following annotations are deprecated: `pod.beta.kubernetes.io/hostname`, `pod.beta.kubernetes.io/subdomain`, `endpoints.beta.kubernetes.io/hostnames-map`.
|
||||
DNS policies can be set on a per-pod basis. Currently Kubernetes supports the
|
||||
following pod-specific DNS policies. These policies are specified in the
|
||||
`dnsPolicy` field of a Pod Spec.
|
||||
|
||||
## How do I test if it is working?
|
||||
- "`Default`": The Pod inherits the name resolution configuration from the node
|
||||
that the pods run on.
|
||||
See [related discussion](/docs/tasks/administer-cluster/dns-custom-nameservers/#inheriting-dns-from-the-node)
|
||||
for more details.
|
||||
- "`ClusterFirst`": Any DNS query that does not match the configured cluster
|
||||
domain suffix, such as "`www.kubernetes.io`", is forwarded to the upstream
|
||||
nameserver inherited from the node. Cluster aministrators may have extra
|
||||
stub-domain and upstream DNS servers configured.
|
||||
See [related discussion](/docs/tasks/administer-cluster/dns-custom-nameservers/#impacts-on-pods)
|
||||
for details on how DNS queries are handled in those cases.
|
||||
- "`ClusterFirstWithHostNet`": For Pods running with hostNetwork, you should
|
||||
explicitly set its DNS policy "`ClusterFirstWithHostNet`".
|
||||
- "`None`": A new option value introduced in Kubernetes v1.9. This Alpha feature
|
||||
allows a Pod to ignore DNS settings from the Kubernetes environment. All DNS
|
||||
settings are supposed to be provided using the `dnsConfig` field in the Pod Spec.
|
||||
See [DNS config](#dns-config) subsection below.
|
||||
|
||||
### Create a simple Pod to use as a test environment
|
||||
**NOTE:** "Default" is not the default DNS policy. If `dnsPolicy` is not
|
||||
explicitly specified, then “ClusterFirst” is used.
|
||||
{: .note}
|
||||
|
||||
Create a file named busybox.yaml with the
|
||||
following contents:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: busybox
|
||||
namespace: default
|
||||
spec:
|
||||
containers:
|
||||
- image: busybox
|
||||
command:
|
||||
- sleep
|
||||
- "3600"
|
||||
imagePullPolicy: IfNotPresent
|
||||
name: busybox
|
||||
restartPolicy: Always
|
||||
```
|
||||
|
||||
Then create a pod using this file:
|
||||
|
||||
```
|
||||
kubectl create -f busybox.yaml
|
||||
```
|
||||
|
||||
### Wait for this pod to go into the running state
|
||||
|
||||
You can get its status with:
|
||||
```
|
||||
kubectl get pods busybox
|
||||
```
|
||||
|
||||
You should see:
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
busybox 1/1 Running 0 <some-time>
|
||||
```
|
||||
|
||||
### Validate that DNS is working
|
||||
|
||||
Once that pod is running, you can exec nslookup in that environment:
|
||||
|
||||
```
|
||||
kubectl exec -ti busybox -- nslookup kubernetes.default
|
||||
```
|
||||
|
||||
You should see something like:
|
||||
|
||||
```
|
||||
Server: 10.0.0.10
|
||||
Address 1: 10.0.0.10
|
||||
|
||||
Name: kubernetes.default
|
||||
Address 1: 10.0.0.1
|
||||
```
|
||||
|
||||
If you see that, DNS is working correctly.
|
||||
|
||||
### Troubleshooting Tips
|
||||
|
||||
If the nslookup command fails, check the following:
|
||||
|
||||
#### Check the local DNS configuration first
|
||||
Take a look inside the resolv.conf file. (See [Inheriting DNS from the node](#inheriting-dns-from-the-node) and [Known issues](#known-issues) below for more information)
|
||||
|
||||
```
|
||||
kubectl exec busybox cat /etc/resolv.conf
|
||||
```
|
||||
|
||||
Verify that the search path and name server are set up like the following (note that search path may vary for different cloud providers):
|
||||
|
||||
```
|
||||
search default.svc.cluster.local svc.cluster.local cluster.local google.internal c.gce_project_id.internal
|
||||
nameserver 10.0.0.10
|
||||
options ndots:5
|
||||
```
|
||||
|
||||
### DNS Policy
|
||||
|
||||
By default, DNS policy for a pod is 'ClusterFirst'. So pods running with hostNetwork cannot resolve DNS names. To have DNS options set along with hostNetwork, you should specify DNS policy explicitly to 'ClusterFirstWithHostNet'. Update the busybox.yaml as following:
|
||||
The example below shows a Pod with its DNS policy set to
|
||||
"`ClusterFirstWithHostNet`" because it has `hostNetwork` set to `true`.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
@@ -262,157 +199,58 @@ spec:
|
||||
dnsPolicy: ClusterFirstWithHostNet
|
||||
```
|
||||
|
||||
#### Quick diagnosis
|
||||
### Pod's DNS Config
|
||||
|
||||
Errors such as the following indicate a problem with the kube-dns add-on or associated Services:
|
||||
Kubernetes v1.9 introduces an Alpha feature that allows users more control on
|
||||
the DNS settings for a Pod. To enable this feature, the cluster aministrator
|
||||
needs to enable the `CustomPodDNS` feature gate on the apiserver and the kubelet,
|
||||
for example, "`--feature-gates=CustomPodDNS=true,...`".
|
||||
When the feature gate is enabled, users can set the `dnsPolicy` field of a Pod
|
||||
to "`None`" and they can add a new field `dnsConfig` to a Pod Spec.
|
||||
|
||||
The `dnsConfig` field is optional and it can work with any `dnsPolicy` settings.
|
||||
However, when a Pod's `dnsPolicy` is set to "`None`", the `dnsConfig` field has
|
||||
to be specified.
|
||||
|
||||
Below are the properties a user can specify in the `dnsConfig` field:
|
||||
|
||||
- `nameservers`: a list of IP addresses that will be used as DNS servers for the
|
||||
Pod. There can be at most 3 IP addresses specified. When the Pod's `dnsPolicy`
|
||||
is set to "`None`", the list must contain at least one IP address, otherwise
|
||||
this property is optional.
|
||||
The servers listed will be combined to the base nameservers generated from the
|
||||
specified DNS policy with duplicate addresses removed.
|
||||
- `searches`: a list of DNS search domains for hostname lookup in the Pod.
|
||||
This property is optional. When specified, the provided list will be merged
|
||||
into the base search domain names generated from the chosen DNS policy.
|
||||
Duplicate domain names are removed.
|
||||
Kubernetes allows for at most 6 search domains.
|
||||
- `options`: an optional list of objects where each object may have a `name`
|
||||
property (required) and a `value` property (optional). The contents in this
|
||||
property will be merged to the options generated from the specified DNS policy.
|
||||
Duplicate entries are removed.
|
||||
|
||||
The following is an example Pod with custom DNS settings:
|
||||
|
||||
{% include code.html language="yaml" file="custom-dns.yaml" ghlink="/docs/concepts/services-networking/custom-dns.yaml" %}
|
||||
|
||||
When the Pod above is created, the container `test` gets the following contents
|
||||
in its `/etc/resolv.conf` file:
|
||||
|
||||
```
|
||||
$ kubectl exec -ti busybox -- nslookup kubernetes.default
|
||||
Server: 10.0.0.10
|
||||
Address 1: 10.0.0.10
|
||||
|
||||
nslookup: can't resolve 'kubernetes.default'
|
||||
nameserver 1.2.3.4
|
||||
search ns1.svc.cluster.local my.dns.search.suffix
|
||||
options ndots:2
|
||||
options edns0
|
||||
```
|
||||
|
||||
or
|
||||
{% endcapture %}
|
||||
|
||||
```
|
||||
$ kubectl exec -ti busybox -- nslookup kubernetes.default
|
||||
Server: 10.0.0.10
|
||||
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
|
||||
{% capture whatsnext %}
|
||||
|
||||
nslookup: can't resolve 'kubernetes.default'
|
||||
```
|
||||
For guidance on administering DNS configurations, check
|
||||
[Configure DNS Service](/docs/tasks/administer-cluster/dns-custom-nameservers/)
|
||||
|
||||
#### Check if the DNS pod is running
|
||||
{% endcapture %}
|
||||
|
||||
Use the kubectl get pods command to verify that the DNS pod is running.
|
||||
|
||||
```
|
||||
kubectl get pods --namespace=kube-system -l k8s-app=kube-dns
|
||||
```
|
||||
|
||||
You should see something like:
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
...
|
||||
kube-dns-v19-ezo1y 3/3 Running 0 1h
|
||||
...
|
||||
```
|
||||
|
||||
If you see that no pod is running or that the pod has failed/completed, the DNS add-on may not be deployed by default in your current environment and you will have to deploy it manually.
|
||||
|
||||
#### Check for Errors in the DNS pod
|
||||
|
||||
Use `kubectl logs` command to see logs for the DNS daemons.
|
||||
|
||||
```
|
||||
kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c kubedns
|
||||
kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c dnsmasq
|
||||
kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c sidecar
|
||||
```
|
||||
|
||||
See if there is any suspicious log. W, E, F letter at the beginning represent Warning, Error and Failure. Please search for entries that have these as the logging level and use [kubernetes issues](https://github.com/kubernetes/kubernetes/issues) to report unexpected errors.
|
||||
|
||||
#### Is DNS service up?
|
||||
|
||||
Verify that the DNS service is up by using the `kubectl get service` command.
|
||||
|
||||
```
|
||||
kubectl get svc --namespace=kube-system
|
||||
```
|
||||
|
||||
You should see:
|
||||
|
||||
```
|
||||
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
...
|
||||
kube-dns 10.0.0.10 <none> 53/UDP,53/TCP 1h
|
||||
...
|
||||
```
|
||||
|
||||
If you have created the service or in the case it should be created by default but it does not appear, see this [debugging services page](/docs/tasks/debug-application-cluster/debug-service/) for more information.
|
||||
|
||||
#### Are DNS endpoints exposed?
|
||||
|
||||
You can verify that DNS endpoints are exposed by using the `kubectl get endpoints` command.
|
||||
|
||||
```
|
||||
kubectl get ep kube-dns --namespace=kube-system
|
||||
```
|
||||
|
||||
You should see something like:
|
||||
|
||||
```
|
||||
NAME ENDPOINTS AGE
|
||||
kube-dns 10.180.3.17:53,10.180.3.17:53 1h
|
||||
```
|
||||
|
||||
If you do not see the endpoints, see endpoints section in the [debugging services documentation](/docs/tasks/debug-application-cluster/debug-service/).
|
||||
|
||||
For additional Kubernetes DNS examples, see the [cluster-dns examples](https://github.com/kubernetes/examples/tree/master/staging/cluster-dns) in the Kubernetes GitHub repository.
|
||||
|
||||
## Kubernetes Federation (Multiple Zone support)
|
||||
|
||||
Release 1.3 introduced Cluster Federation support for multi-site
|
||||
Kubernetes installations. This required some minor
|
||||
(backward-compatible) changes to the way
|
||||
the Kubernetes cluster DNS server processes DNS queries, to facilitate
|
||||
the lookup of federated services (which span multiple Kubernetes clusters).
|
||||
See the [Cluster Federation Administrators' Guide](/docs/concepts/cluster-administration/federation/) for more
|
||||
details on Cluster Federation and multi-site support.
|
||||
|
||||
## How it Works
|
||||
|
||||
The running Kubernetes DNS pod holds 3 containers - kubedns, dnsmasq and a health check called healthz.
|
||||
The kubedns process watches the Kubernetes master for changes in Services and Endpoints, and maintains
|
||||
in-memory lookup structures to service DNS requests. The dnsmasq container adds DNS caching to improve
|
||||
performance. The healthz container provides a single health check endpoint while performing dual healthchecks
|
||||
(for dnsmasq and kubedns).
|
||||
|
||||
The DNS pod is exposed as a Kubernetes Service with a static IP. Once assigned the
|
||||
kubelet passes DNS configured using the `--cluster-dns=10.0.0.10` flag to each
|
||||
container.
|
||||
|
||||
DNS names also need domains. The local domain is configurable, in the kubelet using
|
||||
the flag `--cluster-domain=<default local domain>`.
|
||||
|
||||
The Kubernetes cluster DNS server (based off the [SkyDNS](https://github.com/skynetservices/skydns) library)
|
||||
supports forward lookups (A records), service lookups (SRV records) and reverse IP address lookups (PTR records).
|
||||
|
||||
## Inheriting DNS from the node
|
||||
When running a pod, kubelet will prepend the cluster DNS server and search
|
||||
paths to the node's own DNS settings. If the node is able to resolve DNS names
|
||||
specific to the larger environment, pods should be able to, also. See "Known
|
||||
issues" below for a caveat.
|
||||
|
||||
If you don't want this, or if you want a different DNS config for pods, you can
|
||||
use the kubelet's `--resolv-conf` flag. Setting it to "" means that pods will
|
||||
not inherit DNS. Setting it to a valid file path means that kubelet will use
|
||||
this file instead of `/etc/resolv.conf` for DNS inheritance.
|
||||
|
||||
## Known issues
|
||||
Kubernetes installs do not configure the nodes' resolv.conf files to use the
|
||||
cluster DNS by default, because that process is inherently distro-specific.
|
||||
This should probably be implemented eventually.
|
||||
|
||||
Linux's libc is impossibly stuck ([see this bug from
|
||||
2005](https://bugzilla.redhat.com/show_bug.cgi?id=168253)) with limits of just
|
||||
3 DNS `nameserver` records and 6 DNS `search` records. Kubernetes needs to
|
||||
consume 1 `nameserver` record and 3 `search` records. This means that if a
|
||||
local installation already uses 3 `nameserver`s or uses more than 3 `search`es,
|
||||
some of those settings will be lost. As a partial workaround, the node can run
|
||||
`dnsmasq` which will provide more `nameserver` entries, but not more `search`
|
||||
entries. You can also use kubelet's `--resolv-conf` flag.
|
||||
|
||||
If you are using Alpine version 3.3 or earlier as your base image, DNS may not
|
||||
work properly owing to a known issue with Alpine. Check [here](https://github.com/kubernetes/kubernetes/issues/30215)
|
||||
for more information.
|
||||
|
||||
## References
|
||||
|
||||
- [Docs for the DNS cluster addon](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/dns/README.md)
|
||||
|
||||
## What's next
|
||||
- [Autoscaling the DNS Service in a Cluster](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/).
|
||||
{% include templates/concept.md %}
|
||||
|
||||
@@ -188,9 +188,9 @@ having working [readiness probes](/docs/tasks/configure-pod-container/configure-
|
||||
|
||||
|
||||
|
||||
### Proxy-mode: ipvs[alpha]
|
||||
### Proxy-mode: ipvs
|
||||
|
||||
**Warning:** This is an alpha feature and not recommended for production clusters yet.
|
||||
{% assign for_k8s_version="v1.9" %}{% include feature-state-beta.md %}
|
||||
|
||||
In this mode, kube-proxy watches Kubernetes `services` and `endpoints`,
|
||||
call `netlink` interface create ipvs rules accordingly and sync ipvs rules with Kubernetes
|
||||
@@ -471,7 +471,7 @@ metadata:
|
||||
cloud.google.com/load-balancer-type: "Internal"
|
||||
[...]
|
||||
```
|
||||
Use `cloud.google.com/load-balancer-type: "internal"` for masters with version 1.7.0 to 1.7.3.
|
||||
Use `cloud.google.com/load-balancer-type: "internal"` for masters with version 1.7.0 to 1.7.3.
|
||||
For more information, see the [docs](https://cloud.google.com/kubernetes-engine/docs/internal-load-balancing).
|
||||
{% endcapture %}
|
||||
|
||||
@@ -505,7 +505,7 @@ metadata:
|
||||
For partial SSL support on clusters running on AWS, starting with 1.3 three
|
||||
annotations can be added to a `LoadBalancer` service:
|
||||
|
||||
```
|
||||
```yaml
|
||||
metadata:
|
||||
name: my-service
|
||||
annotations:
|
||||
@@ -550,6 +550,25 @@ In the above example, if the service contained three ports, `80`, `443`, and
|
||||
`8443`, then `443` and `8443` would use the SSL certificate, but `80` would just
|
||||
be proxied HTTP.
|
||||
|
||||
Beginning in 1.9, services can use [predefined AWS SSL policies](http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html)
|
||||
for any HTTPS or SSL listeners. To see which policies are available for use, run
|
||||
the awscli command:
|
||||
|
||||
```bash
|
||||
aws elb describe-load-balancer-policies --query 'PolicyDescriptions[].PolicyName'
|
||||
```
|
||||
|
||||
Any one of those policies can then be specified using the
|
||||
"`service.beta.kubernetes.io/aws-load-balancer-ssl-negotiation-policy`"
|
||||
annotation, for example:
|
||||
|
||||
```yaml
|
||||
metadata:
|
||||
name: my-service
|
||||
annotations:
|
||||
service.beta.kubernetes.io/aws-load-balancer-ssl-negotiation-policy: "ELBSecurityPolicy-TLS-1-2-2017-01"
|
||||
```
|
||||
|
||||
#### PROXY protocol support on AWS
|
||||
|
||||
To enable [PROXY protocol](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)
|
||||
@@ -566,6 +585,66 @@ annotation:
|
||||
Since version 1.3.0 the use of this annotation applies to all ports proxied by the ELB
|
||||
and cannot be configured otherwise.
|
||||
|
||||
#### Network Load Balancer support on AWS [alpha]
|
||||
|
||||
**Warning:** This is an alpha feature and not recommended for production clusters yet.
|
||||
|
||||
Starting in version 1.9.0, Kubernetes supports Network Load Balancer (NLB). To
|
||||
use a Network Load Balancer on AWS, use the annotation `service.beta.kubernetes.io/aws-load-balancer-type`
|
||||
with the value set to `nlb`.
|
||||
|
||||
```yaml
|
||||
metadata:
|
||||
name: my-service
|
||||
annotations:
|
||||
service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
|
||||
```
|
||||
|
||||
Unlike classic Elastic Load Balancers, Network Load Balancers (NLBs) forward the
|
||||
client's IP through to the node. If a service's `spec.externalTrafficPolicy` is
|
||||
set to `Cluster`, the client's IP address will not be propagated to the end
|
||||
pods.
|
||||
|
||||
By setting `spec.externalTrafficPolicy` to `Local`, client IP addresses will be
|
||||
propagated to the end pods, but this could result in uneven distribution of
|
||||
traffic. Nodes without any pods for a particular LoadBalancer service will fail
|
||||
the NLB Target Group's health check on the auto-assigned
|
||||
`spec.healthCheckNodePort` and not recieve any traffic.
|
||||
|
||||
In order to achieve even traffic, either use a DaemonSet, or specify a
|
||||
[pod anti-affinity](/docs/concepts/configuration/assign-pod-node/#inter-pod-affinity-and-anti-affinity-beta-feature)
|
||||
to not locate pods on the same node.
|
||||
|
||||
NLB can also be used with the [internal load balancer](/docs/concepts/services-networking/service/#internal-load-balancer)
|
||||
annotation.
|
||||
|
||||
In order for client traffic to reach instances behind an NLB, the Node security
|
||||
groups are modified with the following IP rules:
|
||||
|
||||
| Rule | Protocol | Port(s) | IpRange(s) | IpRange Description |
|
||||
|------|----------|---------|------------|---------------------|
|
||||
| Health Check | TCP | NodePort(s) (`spec.healthCheckNodePort` for `spec.externalTrafficPolicy = Local`) | VPC CIDR | kubernetes.io/rule/nlb/health=\<loadBalancerName\> |
|
||||
| Client Traffic | TCP | NodePort(s) | `spec.loadBalancerSourceRanges` (defaults to `0.0.0.0/0`) | kubernetes.io/rule/nlb/client=\<loadBalancerName\> |
|
||||
| MTU Discovery | ICMP | 3,4 | `spec.loadBalancerSourceRanges` (defaults to `0.0.0.0/0`) | kubernetes.io/rule/nlb/mtu=\<loadBalancerName\> |
|
||||
|
||||
Be aware that if `spec.loadBalancerSourceRanges` is not set, Kubernetes will
|
||||
allow traffic from `0.0.0.0/0` to the Node Security Group(s). If nodes have
|
||||
public IP addresses, be aware that non-NLB traffic can also reach all instances
|
||||
in those modified security groups. IPv6 is not yet supported for source ranges.
|
||||
|
||||
In order to limit which client IP's can access the Network Load Balancer,
|
||||
specify `loadBalancerSourceRanges`.
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
loadBalancerSourceRanges:
|
||||
- "143.231.0.0/16"
|
||||
```
|
||||
|
||||
**Note:** NLB only works with certain instance classes, see the [AWS documentation](http://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-register-targets.html#register-deregister-targets)
|
||||
for supported instance types.
|
||||
|
||||
|
||||
### External IPs
|
||||
|
||||
If there are external IPs that route to one or more cluster nodes, Kubernetes services can be exposed on those
|
||||
|
||||
Reference in New Issue
Block a user