ATTN: Upcoming breaking changes to Consul on Kubernetes

By Q4 2022, the Consul on Kubernetes product will be looking to make some changes to the default deployment of Consul of Kubernetes to align with our target use case around zero trust networking with Service Mesh.

The following changes will occur:

  1. Deploy Consul Service Mesh by default - connectInject.enabled and controller.enabled will both be set to true by default to deploy the Connect Inject deployment and the CRD controller to apply CRDs on Kubernetes. If service mesh is not a use case that is utilized, the recommendation is to explicitly set those values to false to prevent undesired consequences upon upgrading to the version that introduces this change.

  2. Disabling of Client agents by default for Consul Service Mesh and Sync Catalog - Consul Service Mesh will introduce a new architecture that will allow for the deployment of Consul on Kubernetes without node-local agents running alongside workloads. This will remove the need for gossip communication amongst workload nodes and the need for a hostPort to be exposed on Kubernetes. As opposed to client agents deployed on each workload node, a new component will be introduced alongside each pod’s Envoy sidecar to allow for the configuration of the proxy itself by retrieving the configuration from the Consul servers via xDS. The Consul servers will still operate in a dual mode to allow for both traditional client agents to join the mesh outside of Kubernetes, and the ability for Envoy proxies to be managed by the new component. The implementation of this new architecture will enable the deployment of Consul on Kubernetes environments such as EKS Fargate and GKE Autopilot where hostPorts are not supported. In addition, for the use case where Consul Servers reside on a separate network than the networked utilized by workloads themselves, the removal of gossip communication amongst workload nodes will allow for a simplified network configuration by removing the need for network peering between workload nodes and Consul servers.

    Sync Catalog will also be modified to dial the servers directly instead of using a client agent.

    For the use cases outside of Sync Catalog and Service Mesh, i.e traditional service discovery via client agents and Consul Vault storage backend, Consul clients could still be deployed through the configuration of a separate Helm config stanza.

  3. Deploy Consul on Kubernetes with 1 server replica by default, to accommodate for a frictionless install experience for Kubernetes on local developer environments. Setting server.replicas to 3 is considered best practice for production deployments of Consul on Kubernetes, however it is not required for development deployments.

  4. Enable namespace mirroring by default (enterprise only) - Both connjectInject.consulNamespaces.mirroringK8S and syncCatalog.consulNamespaces.mirroringK8S will be set to true by default to allow for the registering of services to a mirrored Consul namespace of the same name, as opposed to a ‘default` namespace.

We’re excited to see these changes be released in a future release, and will look forward to these changes being implemented by Q4 2022.

Thank you,
The Consul on Kubernetes Team

Is the solution called Consul Service Mesh, or Consul Connect officially? I am looking to write an article on this, and so I am interested to call it the correct name.

1 Like

Hi @darkn3rd We are now referring to the solution as Consul Service Mesh formally. We used the name Consul Connect before but we have decided that it is better to refer to it as Consul Service Mesh to make it easier for users to quickly understand the solution.

1 Like