Kubernetes architecture

You can check the previous article on Container orchestration with Kubernetes here

The chief components of Kubernetes architecture include the following:

Clusters and nodes (compute)

Clusters are the building blocks of Kubernetes architecture. The clusters are made up of nodes, each of which represents a single compute host (virtual or physical machine).

Each cluster consists of a master node that serves as the control plan for the cluster, and multiple worker nodes that deploy, run, and manage containerized applications. The master node runs a scheduler service that automates when and where the containers are deployed based on developer-set deployment requirements and available computing capacity. Each worker node includes the tool that is being used to manage the containers — such as Docker — and a software agent called a Kubelet that receives and executes orders from the master node.

Developers manage cluster operations using kubectl, a command-line interface (cli) that communicates directly with the Kubernetes API.

For a deeper dive into Kubernetes clusters, read: “Kubernetes Clusters: Architecture for Rapid, Controlled Cloud App Delivery.”

Pods and deployments (software)

Pods are groups of containers that share the same compute resources and the same network. They are also the unit of scalability in Kubernetes: if a container in a pod is getting more traffic than it can handle, Kubernetes will replicate the pod to other nodes in the cluster. For this reason, it’s a good practice to keep pods compact so that they contain only containers that must share resources.

The deployment controls the creation and state of the containerized application and keeps it running. It specifies how many replicas of a pod should run on the cluster. If a pod fails, the deployment will create a new one.

Istio service mesh

Kubernetes can deploy and scale pods, but it can’t manage or automate routing between them and doesn’t provide any tools to monitor, secure, or debug these connections. As the number of containers in a cluster grows, the number of possible connection paths between them escalates exponentially (for example, two containers have two potential connections, but 10 pods have 90), creating a potential configuration and management nightmare.

Enter Istio, an open source service mesh layer for Kubernetes clusters. To each Kubernetes cluster, Istio adds a sidecar container — essentially invisible to the programmer and the administrator — that configures, monitors, and manages interactions between the other containers.

With Istio, you set a single policy that configures connections between containers so that you don’t have to configure each connection individually. This makes connections between containers easier to debug.

Istio also provides a dashboard that DevOps teams and administrators can use to monitor latency, time-in-service errors, and other characteristics of the connections between containers. And, it builds in security — specifically, identity management that keeps unauthorized users from spoofing a service call between containers — and authentication, authorization and auditing (AAA) capabilities that security professionals can use to monitor the cluster.

Knative and serverless computing

Knative (pronounced ‘kay-native’) is an open source platform that sits on top of Kubernetes and provides two important classes of benefits for cloud-native development:

Knative provides an easy onramp to serverless computing

Serverless computing is a relatively new way of deploying code that makes cloud native applications more efficient and cost-effective. Instead of deploying an ongoing instance of code that sits idle while waiting for requests, serverless brings up the code as needed — scaling it up or down as demand fluctuates — and then takes the code down when not in use. Serverless prevents wasted computing capacity and power and reduces costs because you only pay to run the code when its actually running.

Knative enables developers to build a container once and run it as a software service or as a serverless function. It’s all transparent to the developer: Knative handles the details in the background, and the developer can focus on code.

Knative simplifies container development and orchestration

For developers, containerizing code requires lots of repetitive steps, and orchestrating containers requires lots of configuration and scripting (such as generating configuration files, installing dependencies, managing logging and tracing, and writing continuous integration/continuous deployment (CI/CD) scripts.)

Knative makes these tasks easier by automating them through three components:

Build: Knative’s Build component automatically transforms source code into a cloud-native container or function. Specifically, it pulls the code from repository, installs the required dependencies, builds the container image, and puts it in a container registry for other developers to use. Developers need to specify the location of these components so Knative can find them, but once that’s done, Knative automates the build.

Serve: The Serve component runs containers as scalable services; it can scale up to thousands of container instances or scale down to none (called scaling to zero). In addition, Serve has two very useful features: configuration, which saves versions of a container (called snapshots) every time you push the container to production and lets you run those versions concurrently; and service routing, which lets you direct different amounts of traffic to these versions. You can use these features together to gradually phase a container rollout or to stage a canary test of a containerized application before putting it into global production.

Event: Event enables specified events to trigger container-based services or functions. This is especially integral to Knative’s serverless capabilities; something needs to tell the system to bring up a function when needed. Event allows teams to express interest in types of events, and it then automatically connects to the event producer and routs the events to the container, eliminating the need to program these connections.