Content updates

website/content/docs/k8s/dns/views/enable.mdx

@@ -7,7 +7,7 @@ description: ->
 
 # Enable Consul DNS proxy for Kubernetes
 
-This page describes the process to deploy a Consul DNS proxy in a Kubernetes Pod so that services in that pod can resolve Consul DNS requests. For more information, refer to [Consul DNS views for Kubernetes](/consul/docs/k8s/dns/views).
+This page describes the process to deploy a Consul DNS proxy in a Kubernetes Pod so that Services can resolve Consul DNS requests. For more information, refer to [Consul DNS views for Kubernetes](/consul/docs/k8s/dns/views).
 
 ## Prerequisites
 
@@ -16,25 +16,63 @@ You must meet the following minimum application versions to enable the Consul DN
 - Consul v1.20.0 or higher
 - Either Consul on Kubernetes or the Consul Helm chart, v1.6.0 or higher
 
-## Update Consul values
+## Update Helm values
 
-Update the [Helm values for your Consul on Kubernetes deployment](/consul/docs/k8s/helm) with the `dns.proxy.enabled` parameter set to `true`.
+To enable the Consul DNS proxy, add the required [Helm values](/consul/docs/k8s/helm) to your Consul on Kubernetes deployment:
 
-## Retrieve Consul DNS proxy address
+```yaml
+connectInject:
+  enabled: true
+dns:
+  enabled: true
+  proxy: true
+```
+
+### ACLs
+
+We recommend you create a dedicated [ACL token with DNS permissions](/consul/docs/security/acl/tokens/create/create-a-dns-token) for the Consul DNS proxy. The Consul DNS proxy requires the following ACL permissions:
+
+```hcl
+node_prefix "" {
+  policy = "read"
+}
+
+service_prefix "" {
+  policy = "read"
+}
+```
+
+You can manage ACL tokens with Consul on Kubernetes, or you can configure the DNS proxy to access a token stored in Kubernetes secret. To use a Kubernetes secret, add the following configuration to your Helm chart:
+
+```yaml
+dns:
+  proxy:
+    aclToken:
+      secretName: <Consul-DNS-Token>
+      secretKey: <Token-Value>
+```
+
+## Retrieve Consul DNS proxy's address
 
 To look up the IP address for the Consul DNS proxy in the Kubernetes Pod, run the following command:
 
 ```shell-session
-$ kubectl get services –namespace consul
+$ kubectl get services –-all-namespaces
+
+NAMESPACE     NAME                      TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)                  AGE
+consul        consul-connect-injector   ClusterIP   10.96.41.171   <none>        443/TCP                  12m
+consul        consul-dns                ClusterIP   10.96.148.46   <none>        53/TCP,53/UDP            12m
+default       kubernetes                ClusterIP   10.96.0.1      <none>        443/TCP                  21m
+kube-system   kube-dns                  ClusterIP   10.96.0.10     <none>        53/UDP,53/TCP,9153/TCP   21m
 ```
 
-Note the `ClusterIP`. Use this address when you update the ConfigMap object.
+Note the `CLUSTER-IP` for the `consul-dns` service. Use this address when you update the ConfigMap resource.
 
 ## Update Kubernetes ConfigMap
 
 Create or update a [ConfigMap object in the Kubernetes cluster](https://kubernetes.io/docs/concepts/configuration/configmap/) so that Kubernetes forwards DNS requests with the `.consul` domain to the IP address of the Consul DNS proxy.
 
-The following example configures Kubernetes to forward Consul DNS requests in the cluster to the Consul DNS Proxy running on `10.150.0.1`.
+The following example of a ConfigMap resource configures Kubernetes to forward Consul DNS requests in the cluster to the Consul DNS Proxy running on `10.150.0.1`.
 
 ```yaml
 apiVersion: v1
@@ -65,12 +103,13 @@ data:
     }  
 ```
 
-For information about the other fields in this ConfigMap object, refer to [the Kubernetes documentation](https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/#coredns).
+For information about the other fields in this ConfigMap, refer to [the Kubernetes documentation](https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/#coredns).
 
 ## Next steps
 
 After you enable the Consul DNS proxy, services in the Kubernetes cluster can resolve Consul DNS addresses.
 
 - To learn more about Consul DNS for service discovery, refer to [DNS usage overview](/consul/docs/services/discovery/dns-overview).
-- If your datacenter has ACLs enabled, create a [Consul ACL token](/consul/docs/security/acl/tokens) for the Consul DNS proxy.
-- To use Consul DNS for service discovery with other runtimes, across cloud regions, or between cloud providers, [establish a cluster peering connection](/consul/docs/k8s/connect/cluster-peering/usage/establish-peering). Refer to [cluster peering](/consul/docs/connect/cluster-peering) for more information.
+- If your datacenter has ACLs enabled, create a [Consul ACL token](/consul/docs/security/acl/tokens) for the Consul DNS proxy and then restart the DNS proxy.
+- To enable service discovery across admin partitions, [export services between partitions](/consul/docs/connect/config-entries/exported-services).
+- To use Consul DNS for service discovery with other runtimes, across cloud regions, or between cloud providers, [establish a cluster peering connection](/consul/docs/k8s/connect/cluster-peering/usage/establish-peering).

website/content/docs/k8s/dns/views/index.mdx

@@ -2,43 +2,47 @@
 layout: docs
 page_title: Consul DNS views for Kubernetes
 description: ->
-    Learn how to schedule a Consul DNS proxy for Kubernetes Pods so that your applications can return Consul DNS results for service discovery.
+    Kubernetes clusters can use the Consul DNS proxy to return service discovery results from the Consul catalog. Learn about how to configure your k8s cluster so that applications can resolve Consul DNS addresses without gossip communication.
 ---
 
 # Consul DNS views for Kubernetes
 
-This topic describes how to schedule a dedicated Consul DNS proxy in a Kubernetes Pod so that Kubernetes Services can use Consul DNS addresses. 
+This topic describes how to schedule a dedicated Consul DNS proxy in a Kubernetes Pod so that Kubernetes Services can use Consul DNS addresses. You can use the Consul DNS proxy to enable service discovery across admin partitions in Kubernetes deployments without using agent gossip.
 
 ## Introduction
 
-Kubernetes operators typically choose networking tools such as [kube-dns](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/) or [CoreDNS](https://kubernetes.io/docs/tasks/administer-cluster/coredns/) for their service discovery operations, and choose to bypass Consul DNS entirely. These options may be sufficient for service networking operations within a single Kubernetes cluster.
+Kubernetes operators typically choose networking tools such as [kube-dns](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/) or [CoreDNS](https://kubernetes.io/docs/tasks/administer-cluster/coredns/) for their service discovery operations, and choose to bypass Consul DNS entirely. These DNS options are often sufficient for service networking operations within a single Kubernetes cluster.
 
-Because Consul is interoperabile between runtimes and cloud providers, you can use Consul on Kubernetes to discover services that were registered with any Consul datacenter, even ones running on non-Kubernetes deployments. For example, you can [create a cluster peering connection](/consul/docs/k8s/connect/cluster-peering/usage/establish-peering) between a Consul datacenter running on Kubernetes and a Consul datacenter running on a virtual machine. Then, you can run the Consul DNS proxy as a Kubernetes Service so that other Services can use Consul DNS to resolve the services running on the VM.
+Consul on Kubernetes supports [configuring Kubernetes to resolve Consul DNS](/consul/docs/k8s/dns). However, two common challenges result when you rely on stub domain configurations:
 
-To use Consul DNS for service discovery on Kubernetes, deploy a `consul-proxy` service in each Kubernetes Pod that needs to resolve Consul DNS. All DNS requests in the Kubernetes Pod are sent to the Kubernetes controller first. The controller forwards requests for the `.consul` domain to the `consul-proxy` service, which then queries the Consul catalog and returns service discovery results.
+- Kubernetes requires Consul to use gossip communication with agents or dataplanes in order to enable Consul DNS.
+- Consul requires that admin partitions be included in the DNS address. Otherwise, DNS queries assume the `default` partition by default.
 
-The `consul-proxy` does not require the presence of Consul client agents or Consul dataplanes. As a result, it removes gossip communication as a requirement for Consul DNS.
+The `consul-dns` proxy does not require the presence of Consul client agents or Consul dataplanes, removing gossip communication as a requirement for Consul DNS on Kubernetes. The proxy is also designed for deployment in a Kubernetes cluster with [external servers enabled](/consul/docs/k8s/deployment-configurations/servers-outside-kubernetes). When a cluster runs in a non-default admin partition and uses the proxy to query external servers, Consul automatically recognizes the admin partition that originated the request and returns service discovery results scoped to that specific admin partition.
+
+To use Consul DNS for service discovery on Kubernetes, deploy a `consul-proxy` service in each Kubernetes Pod that needs to resolve Consul DNS. Kubenetes will send all DNS requests to the Kubernetes controller first. The controller forwards requests for the `.consul` domain to the `consul-proxy` service, which then queries the Consul catalog and returns service discovery results.
 
 ## Workflows
 
 The process to enable Consul DNS views for service discovery in Kubernetes deployments consists of the following steps:
 
-1. Update the Helm chart for your Consul on Kubernetes deployment so that `dns.proxy.enabled=true`. When you apply the update, Kubernetes deploys the Consul DNS proxy.
-1. Look up the IP address for the Consul DNS proxy in the Kubernetes Pod.
-1. Update the DNS configuration in the Kubernetes cluster to forward requests for the `.consul` domain to the IP address of the Consul DNS proxy.
+1. In a cluster configured to use [external Consul servers](/consul/docs/k8s/deployment-configurations/servers-outside-kubernetes), update the Helm values for your Consul on Kubernetes deployment so that `dns.proxy.enabled=true`. When you apply the updated configuration, Kubernetes deploys the Consul DNS proxy.
+1. Look up the IP address for the Consul DNS proxy in the Kubernetes cluster.
+1. Update the ConfigMap resource in the Kubernetes cluster so that it forwards requests for the `.consul` domain to the IP address of the Consul DNS proxy.
 
-For more information about the underlying concepts, refer to [DNS forwarding overview](/consul/docs/services/discovery/dns-forwarding).
+For more information about the underlying concepts described in this workflow, refer to [DNS forwarding overview](/consul/docs/services/discovery/dns-forwarding).
 
 ## Benefits
 
 Consul on Kubernetes currently uses [Consul dataplanes](/consul/docs/connect/dataplane) by default. These lightweight processes provide Consul access to the sidecar proxies in the service mesh, but leave Kubernetes in charge of most other service discovery and service mesh operations.
 
-- **Use KubeDNS and Consul DNS in a single deployment**.  The Consul DNS proxy enables any Service in a Pod to resolve an address through Consul DNS without changes to the underlying Kubernetes DNS functionality.
-- **Consul service discovery using less resources**. When you use the Consul DNS proxy for service discovery, you do not need to schedule Consul client agents or dataplanes. One Kubernetes Service that uses the same resources as a single Consul dataplane provides the entire Pod access to the Consul catalog.
+- **Use Kubernetes DNS and Consul DNS in a single deployment**. The Consul DNS proxy enables any Service in a Pod to resolve an address through Consul DNS without disrupting the underlying Kubernetes DNS functionality.
+- **Consul service discovery using less resources**. When you use the Consul DNS proxy for service discovery, you do not need to schedule Consul client agents or dataplanes as sidecars. One Kubernetes Service that uses the same resources as a single Consul dataplane provides Pods access to the Consul service catalog.
 - **Consul DNS without gossip communication**. The Consul DNS service runs on both Consul server and Consul client agents, which use [gossip communication](/consul/docs/security/encryption/gossip) to ensure that service discovery results are up-to-date. The Consul DNS proxy provides access to Consul DNS without the security overhead of agent-to-agent gossip.
 
 ## Constraints and limitations
 
 If you experience issues using the Consul DNS proxy for Kubernetes, refer to the following list of technical constraints and limitations.
 
-- You cannot schedule the Consul DNS proxy in other container-based environments. You must use Kubernetes as your runtime to use the Consul DNS proxy.
+-  You must use Kubernetes as your runtime to use the Consul DNS proxy. You cannot schedule the Consul DNS proxy in other container-based environments.
+-  To perform DNS lookups on other admin partitions, you must [export services between partitions](/consul/docs/connect/config-entries/exported-services) before you can query them.