Kubernetes isn’t designed for multi-tenancy, however right here’s a technique to obtain zone-based isolation of workloads inside the similar Kubernetes cluster.
by Hans Emmanuel, Chief Answer Architect, Cloud Native Computing Observe, HPE Pointnext Companies
As we all know, Kubernetes doesn’t present multi-tenancy out of the field. There are some workarounds for reaching multi-tenancy utilizing totally different tenancy fashions, relying on the requirement. However the reality is that Kubernetes just isn’t designed in a multi-tenant sample. And with regards to networking, the container networking interface (CNI) spec just isn’t involved concerning the community segregation of workloads. So, the Kubernetes CNIs will not be supposed to supply L2/L3 community isolation out of the field. The CNI-backed community insurance policies are the Kubernetes object used for network-level isolation of workloads, which generally leverages the firewall guidelines in employee nodes.
However what if it is required to deploy employee nodes throughout a number of community zones, resulting from varied considerations from software homeowners and different stakeholders? And in some instances – for instance, to be aligned with totally different compliance necessities – it’s obligatory to have separation of bodily and community workloads.
Normally, separate Kubernetes clusters (in a cluster-as-a-service mannequin) are used when it’s pivotal to have the isolation of workloads. However generally operating and managing a number of Kubernetes clusters causes some operational burden.
On this weblog, I’ll clarify an method that HPE used for considered one of our clients, with Calico CNI in BGP (border gateway protocol) mode to attain the zone-based isolation of workloads inside the similar Kubernetes cluster.
We used HPE ProLiant DL360 Gen10 servers because the employee nodes. The diagram beneath exhibits a high-level view of the deployment topology. Right here the employee nodes are deployed throughout totally different remoted community zones. Inter-zone visitors will probably be crossing the core firewall. The important thing level on this topology is the BGP route reflectors per zone. As proven within the diagram, employee nodes within the yellow zone are peered to the corresponding route reflectors, which is able to guarantee that the Calico-advertised routes will probably be contained inside the zone.
The datacentre is utilizing leaf-spine topology and digital routing and forwarding (VRFs) utilized in community materials for the multi-tenancy at L3 degree. Route reflectors are peered in the direction of corresponding VRFs in border leaf switches. All of the inter-VRF (zone) visitors will probably be crossing the core FW, and solely permitted visitors will cross it.
On this topology, the employee nodes in a zone don’t have any thought concerning the workloads operating in employee nodes in different zones. Even when a workload in a single zone wants to speak to a workload in one other zone, it will be routed in the direction of core FW and solely the allowed visitors will move.
Conclusion: Although multi-tenancy just isn’t an out-of-the-box answer in Kubernetes, generally we have to lengthen it to fulfill technical expectations and safety necessities. Right here we achieved this with Calico CNI, with its in depth BGP capabilities.
Expertise companies consulting from HPE Advisory & Skilled Companies may also help you get essentially the most out of your Kubernetes multi-tenancy design and implementation. We perceive that after cloud-native workloads attain manufacturing maturity, it’s inevitable to design and implement the next degree of community safety and efficiency requirements. The International Cloud-Native Computing apply in HPE Advisory & Skilled Companies may also help you construct your enterprise-grade community design and configuration, drawing on our deep experience and expertise of cloud-native computing applied sciences.
To study extra, see our HPE Container Adoption Service answer transient.
Be taught extra about HPE Pointnext Companies and the way we enable you to keep forward of what is subsequent.
Hans Emmanuel is a Chief Answer Architect in HPE’s Cloud Native Computing Observe Space, HPE Pointnext Advisory & Skilled Companies. He began his profession as a Linux server engineer again in 2010 and has since labored on a wide range of personal cloud options and cloud-native applied sciences. Hans has labored on DevOps and improvement initiatives; design and implementation of Devops/DevSecOps pipelines; and self-managed Kubernetes clusters.
Hewlett Packard Enterprise