Understanding POD's

Kubernetes
Network concepts
1
Introduction
2
Understanding Containers
3
ACI Access Policies
4
VMware Domain Definition
5
Linux Host Setup
6
ACI Kubernetes
7
Configure VMware Integration
8
Initialize Kubernetes
9
Deploy Applications
10
Conclusion
11
Reference

In the previous section we showed you basic concepts around containers. Kubernetes is a extensible open source platform for managing containerized workloads and services. It facilitates declarative configuration but it's most powerful tool is how it can automate the configuration and deployment of these workloads.

The most fundamental building block of Kubernetes is a POD. A POD is a group of one or more containers that share the a linux namespace that contains storage, network and other services. PODs are co-located and scheduled to run in the same context. You could think of a POD as a logical host.

In the context of networking, POD's share the same IP. And there are some important rules about how those POD's communicate. These rules are shared across the kubernetes architecture and it is important to understand them.

  • All containers can communicate with other containers without NAT.
  • All nodes can communicate with all containers without NAT.
  • The IP address that a container sees itself as is the same IP that others see it at

The model that kubernetes employs makes the orchestration of containers a little less complex because it makes a POD look similar to a virtual machine or physical servers deployed in the datacenter. As you can see this model was adopted to simplify the movement of traditional compute resources into orchestrated containers.

In the integration that you just configured a full /16 network was separated just for this POD network. The network is 10.209.X.X/16 that can handle a large number of pods. In a production environment you want this large subnet to be as big as possible for your cluster needs. This network is internal to the kubernetes fabric and doesn't contain any visibility to the outside world. The ACI fabric will route the packets internally for this kubernetes POD inside of a ACI EPG that isn't advertised to the outside world.

Once the policies are built, you can adjust these to configure additional rules that satisfy the security requirements of your network. For example, you could have a physical bare-metal compute system running Oracle database that you would want containers to be able to reach. This relationship is possible by creating contracts between the POD network and the database EPG.

By default all PODS are deployed into the default namespace in the kubernetes cluster. These are translated directly into the kube-default EPG inside the ACI fabric. This methodology is done on purpose. In DEVOPS organization the process of creating the application is preferred to be open. Containers are created, used and removed frequently. Developers just need for the network to carry the connections between the containers.

For the network administrator this is an ideal situation. A localized section of the network that could be considered it's own world, isolated by the ACI fabric to avoid security problems. Once the applications require more complex and deterministic network architectures, the application can be moved to a separate Tenant/EPG that has more secure operating parameters defined by the network administrator and policy members of your organization.

The ACI fabric will have visibility to these PODS as they are deployed giving the network administrator a easier task of troubleshooting problems that may arise on application deployments or just DEVOPS programers working day to day.