Kubernetes infrastructure is the combination of resources (including servers, physical or virtual machines, cloud platforms and more) that supports a Kubernetes environment.  

Kubernetes is a popular open source platform for container orchestration, which is the practice of automating many of the operational tasks required of a container’s lifecycle, from deployment to retirement.  

Under the hood, Kubernetes’ infrastructure and architecture revolves around the concept of a cluster, which is a set of machines called “nodes” in Kubernetes terminology. When you deploy containerized workloads with Kubernetes, you deploy them onto the cluster. Nodes represent the machines, which may be physical or virtual machines, responsible for running your containerized workloads. Every Kubernetes cluster has a master node and at least one such worker node, though typically a cluster will have several or more worker nodes. 

Another important Kubernetes concept is the “pod.” Per the official documentation, a pod is the smallest deployable unit in Kubernetes, and they run on the nodes of your cluster. To think of it a different way, the pods represent the various components of your application. A pod often runs a single container, though it can run multiple containers in certain circumstances.  

Finally, another fundamental element of Kubernetes cluster architecture is the control plane. This includes the API server and four other components that effectively manage your nodes (or machines) according to your desired state.

The infrastructure requirements necessary to run Kubernetes depend on what specifically you’re using it for. You can run a version of Kubernetes in a virtual machine on a laptop, for example, for development or testing purposes. You can similarly set up an environment quickly on a hosted service. Many production use cases, however, will require more substantial resources to support the applications you’re running. Large-scale, highly distributed systems might run across multiple cloud and on-premises servers to achieve performance goals or ensure high availability. These scenarios would require a greater investment in appropriate infrastructure resources. 

Infrastructure as code is the practice of provisioning and operating modern infrastructure using a programming language, similar to how software applications are developed and maintained. 

Sometimes referred to as configuration management tools, infrastructure as code tools introduce more automation to traditional IT operations and allow DevOps teams, in particular, to focus more on optimizing areas like development time, deployment frequency, system performance, reliability, resiliency and security. They are able to do this because infrastructure as code allows them to spend less time on repetitive infrastructure management tasks. 

Because Kubernetes similarly automates a lot of the operational effort required to run containerized applications, some people think of it as infrastructure as code, even though it is actually considered a container orchestration tool. Like infrastructure as code, Kubernetes allows you to declare a desired state for your cluster and automate many of the tasks required to achieve or return to that state. Some organizations and teams use an infrastructure as code (or configuration management) tool in conjunction with Kubernetes for needs such as managing their cloud infrastructure. 

Kubernetes security is one facet of an overall approach to container security. The aim of this latter field is ultimately to secure all aspects of the software development lifecycle (including your CI/CD pipeline, if applicable).     

Kubernetes itself includes many important security features, though they typically need to be configured (and optimized over time) for your environment and threat model in order to minimize risks.  

A good example of this is Role-Based Access Control, or RBAC. This gives administrators granular control over what users are able to access and do within the environment, which can reduce the risk of privilege escalation attacks and other threats. Older versions of Kubernetes, however, did not turn on RBAC by default. Even if you’re running the latest version, you’ll want to ensure your settings are properly set for each user, and only grant access or privileges that are absolutely necessary. It’s also a good idea to review these on a regular basis.  

The Cloud Native Computing Foundation, the organization that houses the Kubernetes open source project, published a blog post on nine different best practices for Kubernetes security—including properly setting up RBAC and making sure you’re using the most recent version. (This is a general best practice with any software platform.) They also advise making use of the Kubernetes namespaces feature for increased isolation, as well as hardening the nodes running on your cluster by turning off access to sensitive ports and limiting access to the Kubernetes API.  

Security and infrastructure operations experts also usually advise making sure you’ve got proper tools for monitoring and logging in place when running containerized applications in production environments. This is to help ensure you retain the necessary visibility and auditability of your environments as they become increasingly complex. 

There are multiple options for implementing and managing Kubernetes. The best choice depends on your use cases, available skills and resources and other factors. Getting up and running with the open source platform can require a lot of internal expertise. In general, Kubernetes and cloud-native development are often best for teams that have already adopted DevOps and other modern software practices and technologies. 

Organizations that lack the necessary internal skills to effectively manage Kubernetes on their own may want to consider one of the commercial or hosted options that are based on the underlying open source platform. There are also many options for complementary tools (such as infrastructure as code and security tools) and third-party support.