Glosario

Kubernetes (K8s): Quick Learn Guide

What Is Kubernetes?

Kubernetes, also abbreviated as K8s, is an open source platform for automating and orchestrating deployment, scaling, and management of containerized applications and workloads. It provides compute infrastructure with built-in flexibility, scalability, reliability, high availability, and portability for apps running as containers in any environment – on-premises, in the cloud, and at the edge.

Kubernetes automates the most common tasks associated with managing containerized workloads at scale, including deployment, load balancing, horizontal scaling, rollouts and rollbacks, and self-healing.

Many organizations are already using Kubernetes in production – whether for some or the majority of their apps – and others are evaluating it. Its popularity has made Kubernetes the de facto standard for container orchestration and management.

Kubernetes Benefits

Kubernetes adoption is growing rapidly because it can help:

  • Accelerate and simplify the application release life cycle
  • Enable workload portability across public, private, and hybrid cloud, and multi-cloud environments
  • Improve efficiency of resource utilization
  • Make it easier to achieve scalability and production readiness
  • Optimize the environment to meet business SLAs

Kubernetes and Microservices

Refactoring traditional monolith applications into smaller, loosely coupled parts, called microservices helps improve business agility because new app features and updates can be released faster and scaled more easily. Adoption of a cloud-native, microservices architecture drives the need to evolve the underlying compute infrastructure, so we observe the transition from physical systems and virtual machines to containers as one of the most efficient ways to run microservices.

As the number of microservices and containers grows, so too does the need to automate container management. This is where Kubernetes comes into play.

Kubernetes Versus Docker

Kubernetes orchestrates and runs containerized apps at scale; however, it doesn’t provide the means for packaging application code into a containerized format for distribution and execution (a container image includes the app code and necessary runtimes, libraries, and other software dependencies). For pods to run, Kubernetes also requires that a container runtime be installed on every node. Kubernetes originally used Docker Engine as the container runtime. As of Kubernetes 1.24, however, the container runtime must comply with the Container Runtime Interface (CRI), which Docker Engine does not. Two popular CRI-compliant container runtimes are CRI-O and containerd (originally a Docker project).

To package apps into containers, you need a tool like Docker, one of the most popular tools for building, sharing, and running containerized apps. It streamlines and automates packaging of apps into portable container images that are ready to execute and deploy on-premises, in the cloud, including in Kubernetes environments. Docker-packaged containers can be run natively on containerd and CRI-O runtimes.

Kubernetes Architecture

A Kubernetes platform is made up of nodes that are joined together into a cluster where they share pooled compute resources. Each cluster manages pods which are smallest deployable units in the Kubernetes architecture. A pod contains one or more app containers. Pods are grouped together to make up a service. Apps inside a Kubernetes cluster can be accessed from outside using several methods, with the Ingress controller being one of the most popular and efficient ones.

Let’s take a closer look at the components in a Kubernetes environment:

Kubernetes Pods

A Kubernetes pod is the smallest executable unit that can be deployed in Kubernetes. The pod is a “virtual host” for the app container image or images (like a physical server or virtual machine for traditional apps), and it encapsulates one or more containers that share the same compute, storage, and networking resources (and so can be considered to be coupled relatively tightly). Pods are deployed and executed on Kubernetes nodes.

Kubernetes Nodes

A Kubernetes node is the smallest unit of a compute infrastructure. The node can be a virtual machine or a physical server that allocates processor, memory, storage, and networking resources to deploy, run, scale, and manage pods. Nodes are joined together to form a cluster.

Kubernetes Clusters

A Kubernetes cluster is a group of nodes where pooled compute resources are shared across pods. There are two types of nodes in a cluster:

  • Worker nodes – Run the containerized apps in the pods
  • Master nodes – Run the Kubernetes control plane which orchestrates and manages worker nodes and pods

Typically, there is more than one node of each type in a Kubernetes cluster, for high availability and fault tolerance.

Kubernetes Deployments

A Kubernetes deployment describes how to run an app as a set of replicas (or instances) of the pod in a cluster. A deployment defines:

  • The number of pod replicas to run
  • How to roll out pod updates gradually
  • How to roll back pod replicas to the previous state
  • How to scale pod replicas horizontally

App Connectivity in Kubernetes

Kubernetes supports a dual IPv4/IPv6 stack to provide network connectivity for containerized apps running in a cluster. Both communication to and from apps in the Kubernetes cluster and communication among services within the cluster are managed at Layer 4 (IP address, port) and Layer 7 (hostname, universal resource identifier [URI]) and include routing, load balancing, security, monitoring, and visibility capabilities.

Kubernetes Networking

In the Kubernetes networking model, each pod has a unique IP address that is dynamically assigned from the cluster’s pool of private addresses. All pods running on all nodes in the same cluster belong to the same IP network and can communicate with each other over that network. Multiple containers within a pod communicate with one another via the loopback interface.

Kubernetes Services

A Kubernetes service makes the app or microservice running as one or more pods in the cluster accessible (“exposes it”) on the network. A Kubernetes service represents the app as a logical group of designated pods that perform the same function, for example, web serving. The same selector (or label) is applied to all pods in a service to mark their membership in the service. Kubernetes uses the label to track the set of pods for a service as new pods are deployed or running pods are terminated.

Kubernetes services can communicate to each other within the cluster according to the defined connectivity policies, and can be made accessible from outside the cluster, for example, by using an Ingress controller.

Kubernetes Ingress

The Ingress object, a part of the Kubernetes Ingress API, can be used to externally expose applications running in Kubernetes through Layer 7 (application layer) protocols like HTTP. Ingress gateways and Ingress controllers are tools designed to control the Ingress object and manage communications between users and applications (user-to-service or north-south connectivity).

By design, the Ingress object has limited support for customized request-handling policies; for example, you cannot define and attach security policies to it. As a result, many vendors use custom resource definitions (CRDs) to expand the capabilities of their Ingress controllers, as a way to satisfy evolving customer requirements.

As an example, NGINX Ingress Controller defines custom resources (VirtualServer, VirtualServerRoute, TransportServer, and Policy) to enhance performance, resilience, uptime, security, and observability for API gateway, load balancer, and Ingress functionality at the edge of a Kubernetes cluster.

NGINX provides load balancing, authentication, authorization, access control, encryption, observability, and traffic splitting (circuit breaker, A/B testing, and blue-green and canary deployments) services to ensure that communication is fast, reliable, and secure. In support of frequent app releases, NGINX custom resources also enable self-service governance across multi-tenant development and DevOps teams.

Kubernetes Gateway API

The Gateway API is an open source project intended to improve and standardize service networking in Kubernetes. Managed by the Kubernetes community, the Gateway API specification evolved from the Kubernetes Ingress API to solve limitations of the Ingress resource in production environments, including the ability to define fine-grained policies for request processing and delegate control over configuration across multiple teams and roles.

Learn more about the NGINX’s implementation of the Gateway API in 5 Things to Know about NGINX Gateway Fabric on our blog.

Service Mesh

A service mesh is an infrastructure layer that controls communications among services in a Kubernetes cluster (service-to-service or east-west connectivity). The most common service mesh use cases include mTLS authentication / encryption and observability for communications happening between services in a K8s cluster.

Learn more about unified app delivery with NGINX Gateway Fabric that is designed to effectively combine Ingress controller and service mesh use cases in one tool in Announcing NGINX Gateway Fabric Version 1.0 on our blog.

Kubernetes Security

Kubernetes security is a layered approach to protect infrastructure (on-premises and cloud compute resources, networking communications, and management plane) and applications running inside a Kubernetes cluster.

To secure infrastructure, follow the general security recommendations, tutorials, and best practices for protecting cloud and on-premises implementations.

For secure applications, implement strong security controls at the edge and within a Kubernetes cluster to provide authentication, authorization, access control, encryption, monitoring, and visibility, with optional web application firewall and denial-of-service protection, for all communications to/from and within a cluster.

Read more about securing Kubernetes in our blog Six Ways to Secure Kubernetes Using Traffic Management Tools.

Kubernetes in Production

In the early days of Kubernetes adoption, a Do-It-Yourself (DIY) approach was dominant, however, it is complex and hard to build and operate for many organizations. Because of this, for production deployments, organizations are adopting cloud-managed Kubernetes platforms and prepackaged Kubernetes distributions that integrate various technology components, simplifying maintenance lifecycle, and can be deployed across hybrid and multi-cloud environments.

Some examples of the managed and pre-packaged Kubernetes platforms are shown below:

Cloud-managed Kubernetes:

Pre-packaged Kubernetes distributions:

How NGINX Can Help

NGINX’s Kubernetes-native connectivity and security stack helps improve customer experiences with reduced complexity, increased uptime, and detailed real-time visibility at scale for Kubernetes applications running on-premises, in the cloud, and at the edge.

Connectivity Stack for Kubernetes – Optimize, scale, and secure Kubernetes apps across hybrid, multi-cloud environments.

  • NGINX Ingress Controller – A unified API gateway, load balancer, and Ingress controller that enables better business SLAs and insights into app health and performance at scale across distributed Kubernetes environments.
  • NGINX Gateway Fabric – A unified app delivery fabric that streamlines app, service, and API connectivity across hybrid, multicloud Kubernetes environments.
  • NGINX App Protect – A comprehensive WAF security and denial-of-service (DoS) defense solution designed to protect apps and APIs from Layer 7 attacks.

Get started by requesting your free 30-day trial of NGINX Ingress Controller with NGINX App Protect WAF and DoS.