As more people install VMware PKS and the adoption of Kubernetes spreads within organizations, there is a healthy debate taking place. The conversation is mostly around where we need to be opinionated in the product and what choices we need to expose to help you cater to the diverse needs of your application development teams.
With the introduction of Network Profiles in PKS 1.2.0, we have enabled PKS to offer networking choices that cater to the diverse needs of applications. This means you can deploy Kubernetes clusters in a manner that best suits your organizational and security needs.
The software-defined networking capabilities of VMware NSX-T enable us to automate the creation and configuration of network objects required for Kubernetes. These objects include routers, load balancers, logical switches, and IP address subnets for clusters and namespaces. Such capabilities significantly speed up and simplify the creation and management of Kubernetes clusters. By dedicating logical instances of network objects for Kubernetes clusters and namespaces, PKS gives you the advantage of configuring these network objects in a manner that would best suit your application’s security, scale, and throughput requirements.
Extending Network Policies to More Use Cases
In PKS 1.2, when we first introduced Network Profiles, you could specify the size of the load balancer based on a number of parameters. These include the size of the Kubernetes cluster, the expected number of services that would be deployed on the cluster, and throughput requirements.
With PKS 1.2.1, we now have started to incrementally build on this framework to support additional use cases. One of these new use cases is providing a choice of whether a cluster’s pods need to have routable IP addresses instead of the global default non-routable (NAT’ed) approach. These routable IP addresses provide traceability of pods that make egress requests. The ‘routable pods’ will help you trace the egress requests from specific pods to shared services. To use routable pods, you must specify an IP address block that has a routable address space in the network profile.
Fig: Clusters deployed with routable and non-routable IP addresses for Pods
Overriding the Global Default IP Address Block
Even if you want to continue to keep the default NAT’ed approach for your pod networks, you can use the routable pods feature of Network Profiles to override the global default IP address block configured in NSX-T for PKS. All you have to do is specify a new IP address block and set the routable pod option to “false” in the network profile. This setting may be crucial if the Kubernetes install base in your organization is growing and you are running out of globally allocated IP address blocks for pod networks.
To ensure network profiles meet your organizational compliance, security, and budget needs, while taking into account development needs, the RBAC capabilities in PKS only allow admins to create network profiles. The team consuming the Kubernetes platform can use this network profile when it creates a Kubernetes cluster to override the global network settings.
Conclusion
Network Profiles introduce networking customization options for PKS administrators and operators. In future releases of PKS, we will continue to expand the functionality of Network Profiles to provide more flexibility and choices for networking configurations. Please stay tuned and we’ll be right back with more.
Visit our website to learn more about VMware PKS.
