Reword docs to make k8s arch clear (#8723)

* Reword docs to make k8s arch clear

Co-authored-by: Iryna Shustava <ishustava@users.noreply.github.com>
This commit is contained in:
Luke Kysow 2020-09-22 10:31:29 -07:00 committed by GitHub
parent d8fb480ca1
commit cacc7a1d68
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 12 additions and 10 deletions

View File

@ -252,9 +252,9 @@ spec:
## Architecture ## Architecture
We recommend running Consul on Kubernetes with the same Consul runs on Kubernetes with the same
[general architecture](/docs/internals/architecture) [architecture](/docs/internals/architecture)
as running it anywhere else. There are some benefits Kubernetes can provide as other platforms. There are some benefits Kubernetes can provide
that eases operating a Consul cluster and we document those below. The standard that eases operating a Consul cluster and we document those below. The standard
[production deployment guide](https://learn.hashicorp.com/consul/datacenter-deploy/deployment-guide) is still an [production deployment guide](https://learn.hashicorp.com/consul/datacenter-deploy/deployment-guide) is still an
important read even if running Consul within Kubernetes. important read even if running Consul within Kubernetes.
@ -293,24 +293,26 @@ so this must done manually when removing servers.
The client agents are run as a **DaemonSet**. This places one agent The client agents are run as a **DaemonSet**. This places one agent
(within its own pod) on each Kubernetes node. (within its own pod) on each Kubernetes node.
The clients expose the Consul HTTP API via a static port (default 8500) The clients expose the Consul HTTP API via a static port (8500)
bound to the host port. This enables all other pods on the node to connect bound to the host port. This enables all other pods on the node to connect
to the node-local agent using the host IP that can be retrieved via the to the node-local agent using the host IP that can be retrieved via the
Kubernetes downward API. See Kubernetes downward API. See
[accessing the Consul HTTP API](/docs/k8s/installation/install#accessing-the-consul-http-api) [accessing the Consul HTTP API](/docs/k8s/installation/install#accessing-the-consul-http-api)
for an example. for an example.
There is a major limitation to this: there is no way to bind to a local-only We do not use a **NodePort** Kubernetes service because requests to node ports get randomly routed
to any pod in the service and we need to be able to route directly to the Consul
client running on our node.
-> **Note:** There is no way to bind to a local-only
host port. Therefore, any other node can connect to the agent. This should be host port. Therefore, any other node can connect to the agent. This should be
considered for security. For a properly production-secured agent with TLS considered for security. For a properly production-secured agent with TLS
and ACLs, this is safe. and ACLs, this is safe.
Some people prefer to run **Consul agent per pod** architectures, since this We run Consul clients as a **DaemonSet** instead of running a client in each
makes it easy to register the pod as a service. However, this turns application pod as a sidecar because this would turn
a pod into a "node" in Consul and also causes an explosion of resource usage a pod into a "node" in Consul and also causes an explosion of resource usage
since every pod needs a Consul agent. We recommend instead running an since every pod needs a Consul agent. Service registration should be handled via the
agent (in a dedicated pod) per node, via the DaemonSet. This maintains the
node equivalence in Consul. Service registration should be handled via the
catalog syncing feature with Services rather than pods. catalog syncing feature with Services rather than pods.
-> **Note:** Due to a limitation of anti-affinity rules with DaemonSets, -> **Note:** Due to a limitation of anti-affinity rules with DaemonSets,