The Kubernetes Dilemma

Kubernetes and the ecosystem surrounding it are all “cloud-native”; however, using Kubernetes doesn’t make your architecture cloud-native because there are many ways to supplement cloud vendor features in Kubernetes with self-hosted options.

The severity of these choices can be difficult to measure; however, consider the case where a Kubernetes cluster overlays the cloud-native network and implements an access control list inside the namespace. The access control list does not exist at the infrastructure level, and connectivity between hosts is allowed at the host level; because the software-defined network overlays the host network, it is impossible to secure the service at the infrastructure level. If, however, a cloud-native common network interface (i.e. CNI) is selected. Then, the underlying infrastructure network will manage the ACL, securing services at the lowest level.

With Kubernetes;

  1. It is possible to run software-defined networks and network access control lists on top of the existing Host Network.
  2. It is possible to run self-hosted Observability inside the Kubernetes cluster or export this to another cluster.
  3. It is possible to run self-hosted ingress load-balancing capabilities on top of the existing infrastructure load-balancing capabilities. We could reduce the security by terminating TLS in the cluster but not in the namespace.
  4. It is possible to run self-hosted databases.

To implement cloud-native architecture into your cloud migration, you should rely on cloud-native vendor capabilities integrated into Kubernetes. For example;

  1. Use a cloud-native common networking interface to avoid overlaying the Host Network with a self-hosted SDN.
  2. Use the cloud vendors or software as a service Observability solution.
  3. Use the cloud-vendors Identity and Access Management capability to provide limited access to compute resources.
  4. Use the cloud-vendors Managed Database Services.
  5. Use the cloud-vendors Load Balancing services to provide a secure ingress into your cluster.
  6. Use Kubernetes deployment tools like Helm, WeaveFlux, and ArgoCD for managing application releases.

The key with cloud-native hosting is integrating into and supporting your applications with primitive cloud vendor capabilities for essential functions like;

  • Compute
  • Networking
  • Identity and Access Management
  • Observability
  • Databases

By following these principles, you reduce overall maintenance and can focus entirely on managing your applications in Kubernetes.