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.
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
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.