The Kubernetes Dilemma

Kubernetes and the ecosystem surrounding it are all cloud-native; however, the cost of cloud-native platforms is really high and this leads to a dilemma can you reduce the complexity of your Kubernetes cluster by supplementing self-hosted cloud-native projects with cloud vendor services.

The severity of these choices can be difficult to measure; however, consider the case where a Kubernetes cluster overlays the cloud-vendor 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-vendor 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-vendor common networking interface to avoid overlaying the Host Network with a self-hosted software defined network.

2. Use the cloud vendors or a 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;

Infrastructure

  1. Compute

  2. Networking

Application

  1. Identity and Access Management

  2. Observability Solutions

  3. Database Managed Service

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

Testimonials

Our customers highly rate us.

© Copyright 2024 Servana Managed Services Ltd. All Rights Reserved. Servana Managed Services is a limited company registered in England and Wales with number #10551720 and VAT registered with number GB-284560287.