What Is Kubernetes?

Kubernetes is an open source platform for managing containers at large scale, commonly used to manage workloads in cloud environments. Containers are lightweight units that run on the host’s common shared operating system but are isolated from each other. Kubernetes helps manage containers as a cluster, providing powerful, customizable automation capabilities. Application developers, IT system administrators, and DevOps engineers use Kubernetes to automatically deploy, scale, maintain, schedule, and operate multiple containers. Kubernetes can be used to manage any type of workload. Today it is the most common method for managing microservices applications with a large number of service instances, each deployed as a container. Kubernetes can be deployed in all public clouds and also in a local data center, creating a private cloud. This makes Kubernetes an ideal platform for hosting cloud-native applications that can scale quickly and be easily ported between environments.

Return to Top

Kubernetes Architecture and Components

When you deploy Kubernetes, it creates a cluster consisting of one or more worker machines, called nodes, that run containerized applications. Worker nodes host pods, which are the main component used to manage application workloads. A pod runs one or more containers. The Kubernetes control plane manages the worker nodes and pods in the cluster. In a production environment, the control plane typically runs on multiple machines, and clusters run on multiple nodes (up to thousands of nodes), to provide fault tolerance and high availability.

Image Source: Kubernetes

Kubernetes Control Plane

The control plane is responsible for managing cluster processes. The primary processes are kube-apiserver, etcd, kube-scheduler, kube-controller-manager, and cloud-controller-manager. In some cases, third-party solutions are used to add features like cluster-level logging, cluster DNS management, and resource monitoring.

kube-apiserver

kube-apiserver is a core component of a Kubernetes cluster, responsible for handling internal and external traffic. kube-apiserver is the only component connected to the etcd database. It serves as the primary front-end to the shared state of the cluster. It is primarily responsible for handling API calls concerned with authentication, authorization, and admission control.

etcd Database

etcd is a database system for storing cluster state, network information, and other persistent information. It stores information in the form of key-value pairs. etcd uses an MVCC (multiversion concurrently control) mechanism for updates. etcd supports most HTTP libraries and curl. When you make updates to the etcd database, they are immediately reflected in the kube-api server.

kube-scheduler

kube-scheduler is responsible for assigning newly created pods to suitable nodes in the cluster. It uses a scheduling framework that supports plugins, enabling users to extend its core functionality with custom scheduling policies. The scheduler evaluates each pod’s requirements and filters out nodes that do not meet them, such as those lacking sufficient resources or missing required labels. Then, it scores the remaining eligible nodes and selects the highest scoring one for pod placement. This process is highly customizable, allowing developers to build custom scheduling plugins using the scheduler framework.

kube-controller-manager

This is the control plane component that runs controller processes, which are responsible for adjusting cluster state to match a desired configuration. Logically, each controller is a separate process, but to reduce complexity, they are all compiled into one binary and run in one process known as kube-controller-manager. Here are common types of Kubernetes controllers:

Node controller-responsible for notification and response when a node is down.
Job controller-creates a pod that runs a job, which is a one-time task, and shuts it down when the job is complete.
Endpoint controller-configures endpoint objects which enable pods to connect to services. A service is an abstraction that allows entities, both inside and outside the Kubernetes cluster, to connect to pods without knowing their specific IP.
Service account and token controllers-create a default account and API access token for a new namespace.

cloud-controller-manager

cloud-controller-manager is similar to kube-controller-manager except that it interacts with cloud-specific APIs. The main difference is that kube-controller-manager handles components that only interact with the cluster, while cloud-controller manager handles those that interact with a public cloud platform. In later versions of Kubernetes, it handles some controller actions that were previously handled by kube-controller-manager.

Node Components

Node components run on each Kubernetes node, maintain running pods, and provide the Kubernetes runtime environment. Note: Since version 1.24, Kubernetes removed support for docker, and today the main supported container runtimes are containerd and CRI-Ο.

kubelet

Each compute node contains a kubelet, an agent that communicates with the control plane to determine if the pod’s containers are running. When the control plane needs to perform a specific operation on a node, the kubelet receives the pod specification through the API server and executes the operation. It then checks that the relevant containers are healthy and running.

kube-proxy

Each compute node includes a network proxy that facilitates Kubernetes network services. This is kube-proxy, which either forwards traffic itself or relies on the operating system’s packet filtering layer to handle network traffic inside and outside the cluster. kube-proxy runs on each node to serve traffic from external entities and manage subnets for individual hosts. It it not only a network proxy, but can also act as a service load balancer on the node, managing network routing of UDP and TCP packets, and routing traffic to all service endpoints.

Container Runtime Interface (CRI)

The container runtime interface (CRI) is a plugin interface that enables Kubernetes to use different container runtimes without modifying the core components. It defines the communication protocol between the kubelet and container runtimes like containerd and CRI-O. CRI abstracts container operations such as starting, stopping, and monitoring containers, allowing Kubernetes to support a variety of runtimes in a consistent way. Since Kubernetes version 1.24, Docker is no longer supported directly, and all runtimes must comply with the CRI specification.

Add-on Components

Kubernetes has add-ons that use Kubernetes resources (such as DaemonSets, StatefulSets, or deployments) to implement cluster functionality. Add-on resources typically reside in the kube-system namespace (a namespace reserved for control plane components), because they provide cluster-level functionality.

Cluster DNS

CoreDNS is the default DNS server in Kubernetes and provides internal DNS resolution for services and pods. It is deployed as a Kubernetes add-on and runs as a deployment in the kube-system namespace. CoreDNS listens for DNS queries from pods and translates service names into cluster IP addresses. It is highly extensible through a plugin-based architecture, enabling customization of DNS behavior for different workloads.

Kubernetes Dashboard (Web UI)

The Kubernetes Dashboard is a web-based interface for managing and monitoring applications running in the cluster. It provides insights into resource usage and allows basic operations like scaling deployments or restarting pods. However, the dashboard is no longer deployed by default due to security concerns, such as the risk of exposing cluster-level privileges if misconfigured. Users must explicitly install and secure it before use.

Cluster-level Logging

Application logs help you understand what is going on in your application. Logs are especially useful for debugging problems and monitoring cluster activity. In a Kubernetes cluster, logs require separate storage and an independent lifecycle that is not dependent on nodes, pods, or containers. The reason is that if a node, pod, or container terminates, the logs should still be available. This concept is called cluster-level logging. A cluster-level logging architecture requires a separate backend to store, analyze, and query the logs. Kubernetes does not provide a native storage solution for log data. Instead, there are several logging solutions that integrate with Kubernetes. Kubernetes supports dynamic log levels, which let administrators change the verbosity of logging without restarting components. This is useful for debugging issues in production environments. Additionally, Kubernetes supports OCI-compliant structured logs, which standardize log output formats for better interoperability with log analysis tools.

Return to Top

The Kubernetes Storage Model

By default, Kubernetes storage is ephemeral, meaning that when a resource shuts down, its storage also terminates and the data is lost. However, Kubernetes supports many forms of persistent storage, both on-premises and in the cloud. This includes on-premise persistent storage, and files, block, or object storage from public cloud providers. Storage can be referenced directly from pods, but this is not recommended as it violates the container/pod portability principle. Kubernetes provides the concept of PersistentVolumes (PVs) and PersistentVolumeClaim (PVCs), which separate the storage implementation from functionality, allowing Pods to access storage in a portable way. PVs are where administrators define storage volumes and their performance and capacity parameters. A DevOps engineer uses PVCs to describe the storage required by an application. Kubernetes then retrieves available storage from the defined PV and binds a PVC to it. Since the PVC is defined in the Pod’s YAML, the declaration is propagated along with the pod. Requesting storage can be as simple as specifying just the storage capacity and tier. PVs can be grouped into storage classes, which are Kubernetes application programming interfaces for setting storage parameters. A storage class specifies the name of the volume plug-in, the storage provider (for example, a cloud service), and the CSI driver used. Container Storage Interface (CSI) is a driver specification that allows containers running within Kubernetes to interact with cloud storage services and standard equipment from storage vendors. CSI is now mandatory for new volume drivers.

Return to Top

The Kubernetes Network Model

Each Pod in a cluster has a unique cluster-wide IP address. This means that you don’t need to explicitly create links between pods, and you rarely need to map container ports to host ports. This creates a clean, backwards-compatible model that lets you treat pods as if they were physical hosts or virtual machines (VMs) in terms of port assignment, naming, service discovery, load balancing, application configuration, and migration. Kubernetes imposes the following two requirements on network implementations (unless you define an explicit network segmentation policy):

Pods can communicate with any other pod on any other node without network address translation (NAT).
Agents on a node (system daemons, kubelets, etc.) can communicate with all pods on the same node.

Kubernetes IP addresses exist within a pod scope. Containers in a pod share a network namespace that contains IP and MAC addresses. This means that all containers in a pod can access each other’s ports using the localhost. This also means that a pod’s containers must coordinate port usage, just like a VM’s processes. This is called the “IP per pod” model. The specific implementation will depend on the container runtime you are using.

Benefits of the Kubernetes networking model

A primary benefit, and a key motivation for this model, was to make it easy to port applications from VMs to containers. If a workload previously ran on a VM, the VM had an IP and could communicate with other VMs on the local network. Kubernetes provides similar functionality. In addition, the Kubernetes networking model enables containers in pods to communicate via loopback; enables pods to communicate with each other; and enables service resources to expose applications running in a pod for access outside the cluster. In the same way, services can expose services for use within the cluster.

CNI Plugins

Container Network Interface (CNI) plugins implement the Kubernetes networking model and configure network interfaces for pods. Calico is a leading CNI and network security solution, providing both networking and robust network policy enforcement. It can operate in flexible modes, including Layer 3 routing using BGP or overlay networking using IP-in-IP or VXLAN. Calico enforces policies at the kernel level using iptables or eBPF (Extended Berkeley Packet Filter), delivering enhanced security and performance. Other popular CNI plugins include Flannel, Cilium, and Weave.

Emergence of service mesh and ambient mesh modes

Service meshes have emerged as a way to manage service-to-service communication in Kubernetes clusters, providing features like traffic routing, observability, and security. The most widely used service mesh is Istio, which uses sidecar proxies based on Envoy to intercept and manage traffic. Recently, Istio introduced Ambient Mode, a new architecture that eliminates the need for sidecar containers, reducing resource overhead and simplifying service mesh management. To deliver a unified platform for network security and service mesh, Tigera’s Calico Cloud enhances Istio Ambient Mode, providing hardened security and simplified management. This unique approach allows organizations to deploy and manage next-generation service mesh features with lower operational complexity, leveraging Calico’s proven security and management framework without the burden of managing disparate tools.

Learn more in the detailed guide to:

Related technology updates:

[Blog] How Network Security Policies can Protect Your Environment

Return to Top

The Shift from Ingress to Kubernetes Gateway API

Traditionally, Ingress controllers handled incoming (north-south) traffic by translating simple routing rules into proxy configurations. While effective for basic HTTP/HTTPS traffic management, Ingress has struggled to meet the growing demands of modern, large-scale Kubernetes environments. The most popular implementation, Ingress NGINX, is now being retired. The Kubernetes Gateway API, which reached v1.0 in late 2023, is a major redesign intended to overcome the limitations of Ingress. It introduces a role-oriented model with distinct resources, such as GatewayClass, Gateway, and HTTPRoute, making it easier to separate infrastructure and application concerns. Gateway API is protocol-agnostic and supports not just HTTP but also TCP, gRPC, and other protocols. The Gateway API offers better extensibility, standardized policy expression, and clearer configuration structures. For organizations managing east-west traffic or integrating service mesh architectures, it provides a unified and scalable traffic control model.

Return to Top

What Is Kubernetes Management?

Kubernetes management refers to the set of tools, practices, and processes used to deploy, operate, secure, and optimize Kubernetes clusters and workloads. While Kubernetes automates many operational tasks, managing a cluster at scale requires continuous oversight to ensure reliability, performance, security, and cost-efficiency. Key aspects of Kubernetes management include:

Cluster lifecycle management: Provisioning, upgrading, scaling, and decommissioning clusters, whether running in the cloud, on-premises, or in hybrid environments. Tools like kubeadm, kops, and managed services such as Amazon EKS and Google GKE help automate these tasks.
Configuration and policy management: Ensuring consistent application and infrastructure configuration across environments using tools like Helm, Kustomize, and GitOps platforms such as Argo CD or Flux. Policy management includes enforcing security, compliance, and operational policies using tools like Open Policy Agent (OPA) or Kyverno.
Monitoring and observability: Monitoring the health and performance of nodes, pods, and applications using Prometheus, Grafana, and third-party observability platforms. Effective observability includes logging, metrics, and distributed tracing.
Security management: Managing authentication (via RBAC or external identity providers), securing network traffic with service mesh (e.g., Istio), enforcing runtime security, and applying network policies to isolate workloads.
Resource and cost optimization: Allocating CPU, memory, and storage efficiently using Kubernetes resource requests and limits. Autoscaling features (horizontal pod autoscaling, cluster autoscaler) help balance performance with cost.
Backup and disaster recovery: Protecting cluster state and persistent data using tools like Velero to backup and restore Kubernetes resources and volumes.

Kubernetes management ensures that clusters remain healthy, secure, and aligned with business and technical objectives as they scale and evolve. Learn more in the detailed guide to Kubernetes management

Related technology updates:

Return to Top

Deploying Workloads in Kubernetes

What Is a Kubernetes Deployment?

The process of manually updating containerized applications is time consuming and tedious. To upgrade a service to the next version, you would need to start the new version of the pod, stop the old version of the pod, check if the new version starts successfully, and if not, roll back manually to the old version. Performing these steps manually can involve human error, and even if you script them, the scripting could fail to work correctly, all of which creates bottlenecks in the release process. With the Kubernetes deployment object, this process becomes automated and repeatable. A deployment enables updating workloads in a fully automated way, managed by the Kubernetes control panel, and the entire update process is done server-side with no client interaction. A Kubernetes deployment is a resource object that provides declarative updates to applications. Deployments allow you to describe the lifecycle of your application, including the container images it uses, how many pods it requires, and how to update it. Like any Kubernetes object, a deployment is a way to tell the Kubernetes system what your cluster’s workload should look like. When an object is created, the cluster checks if the object exists, creates it if not, and maintains the desired state described in the object’s configuration. A deployment runs any number of pods and is always available. You can use Kubernetes deployment objects to deploy or update ReplicaSets or pods, rollback to a previous deployment version, scale deployments up or down, and pause or resume a deployment. Server-side apply is a feature in Kubernetes that allows users to manage the fields of Kubernetes objects declaratively, with conflict detection handled by the API server. Unlike client-side apply, where configuration changes are merged and sent by the client, server-side apply processes the merge and conflict resolution entirely on the server. Learn more in the detailed guide to Kubernetes Deployment

Related product offering: Octopus Deploy | Continuous Delivery and Deployment Platform

Offered by Octopus

Related technology updates:

[Blog] Testing Kubernetes locally

Kubernetes Deployment vs. StatefulSets

A StatefulSet is a workload API object for managing stateful applications. Kubernetes users don’t need to worry about how pods are scheduled-they can deploy pods sequentially, attach them to persistent storage volumes, and each pod maintains its own persistent network ID. Like deployments, StatefulSets manage pods based on a container specification. However, they differ from deployments in that they maintain a static ID for each pod. Pods can be created according to the same specification, but are not interchangeable, and are assigned a unique identifier that persists even as they are scheduled to other nodes. The main differences between Deployment and StatefulSet are:

DEPLOYMENTS ARE USED FOR STATELESS APPLICATIONS	STATEFULSETS ARE USED FOR STATEFUL APPLICATIONS
Pods in a deployment are interchangeable	Pods in a StatefulSet have a unique identifier
Deployments require a service to facilitate interaction with pods	in StatefulSets a headless service manages the pod’s network IDs

Kubernetes Deployment vs. Kubernetes Helm

Kubernetes Deployment and Helm are both tools used to manage applications in a Kubernetes environment. But they serve different purposes and have different strengths and weaknesses. Kubernetes Deployment is a core feature of Kubernetes. It’s used to manage stateless applications and services. With a Deployment, you can describe the desired state of your application, and Kubernetes will automatically manage the underlying Pods to ensure that the state of your application matches your specifications. On the other hand, Helm is a package manager for Kubernetes. With Helm, you can package your Kubernetes applications into charts, which are collections of files that describe a related set of Kubernetes resources. Helm charts make it easy to deploy and manage complex applications, and they also support versioning so you can roll back to a previous version of your application if necessary. While Kubernetes Deployment is a powerful tool for managing stateless applications, it lacks some of the features that Helm offers. For example, Helm supports dependencies between different components of your application, and it provides a way to manage configuration information that can be shared across multiple environments. Learn more in the detailed guide to Kubernetes Helm

Related product offering: Octopus Deploy | Continuous Delivery and Deployment Platform

Related technology updates:

Kubernetes Autoscaling

When deploying a specific workload or an entire Kubernetes cluster, you plan capacity based on known application loads. However, these loads can change over time, or might spike unexpectedly. When this happens, you could run out of computing resources, slowing down services and frustrating users. Manually allocating resources is inefficient and does not allow rapid response to changes in demand. Kubernetes autoscaling can help. Kubernetes provides several autoscaling tools that can help you automatically provision more or less resources for workloads, or for your entire cluster. The primary autoscaling mechanisms in Kubernetes are:

Horizontal pod autoscaling (HPA)-scales pods across multiple nodes if they need more capacity, or terminates pods on some nodes if they need less capacity.
Vertical pod autoscaling (VPA)-increases the resource requirements of a pod, ensuring it is scheduled to a node with more resources available or more powerful hardware capabilities (or conversely, reduces resource requirements if the pod is overprovisioned).
Cluster Autoscaler-automatically scales up the cluster by adding nodes, and terminates nodes when they are not running any pods (this works by interfacing with cloud services like Amazon EC2). This ensures that the cluster has enough capacity to meet the requirements of all current workloads.
Horizontal Pod Autoscaler v2-extends the original HPA by supporting multiple metrics for scaling decisions, including custom and external metrics. This allows you to scale workloads not just based on CPU or memory usage, but also on metrics such as request rate or queue length. HPA v2 uses the Kubernetes metrics API and integrates with monitoring systems like Prometheus.
KEDA (Kubernetes Event-driven Autoscaling)-a Kubernetes-based component that allows apps to scale based on external event sources such as message queues, databases, or custom metrics. It extends HPΑ functionality by enabling autoscaling from event sources outside the Kubernetes cluster.
Vertical Pod Autoscaler-automatically adjusts CPU and memory requests for pods based on their usage over time. It helps optimize resource allocation and ensures workloads get sufficient resources without overprovisioning. VPA can be used in three modes: recommend, auto, and off.
Node autoscaling-Kubernetes can dynamically adjust the number of worker nodes in the cluster based on demand. The Cluster Autoscaler is the primary component responsible for this. It adds nodes when pods can’t be scheduled due to resource constraints, and removes underutilized nodes to save costs when demand decreases.

Kubernetes Dashboards

When it comes to managing your Kubernetes clusters, there are several graphical user interfaces (GUIs) available. The Kubernetes Dashboard is a web-based Ul for Kubernetes clusters, built into the Kubernetes distribution. It allows users to manage and troubleshoot applications running in the cluster, as well as the cluster itself. While the Kubernetes Dashboard offers a lot of functionality, it can be a bit overwhelming for beginners. For example, Lens is a free Kubernetes dashboard that helps manage and troubleshoot Kubernetes workloads across multiple clusters. Learn more in the detailed guide to Kubernetes Lens.

Managing Kubernetes Costs and Performance

Managing costs and performance in a Kubernetes environment can be challenging, but it is vital for maintaining the health and efficiency of your applications. Kubernetes provides several tools to help you monitor and control your resources. Resource requests and limits are one of the primary means of managing costs and performance in Kubernetes. By setting resource requests, you tell Kubernetes the minimum amount of resources that a container needs. On the other hand, by setting limits, you specify the maximum amount of resources a container can use. Another way to manage costs is by using Kubernetes namespaces to group and isolate resources. This allows you to allocate resources to different teams or projects and track their usage. Performance in Kubernetes can be managed by using effective logging and monitoring. Kubernetes provides built-in tools for logging and monitoring, like the Kubernetes Dashboard, and supports integration with external monitoring tools like Komdor. Learn more in the detailed guide to Kubernetes pricing

Kubernetes in the Cloud

It is common to deploy Kubernetes clusters on public cloud resources. Let’s see how this works with the leading cloud providers-Amazon, Microsoft Azure, and Google Cloud.

Kubernetes on AWS

When running Kubernetes on Amazon Web Services (AWS), you can choose to self-manage your Kubernetes infrastructure on Amazon EC2 in an infrastructure as a service (laas) model, or use Amazon Elastic Kubernetes Service (EKS) to get an automatically provisioned and managed Kubernetes control plane. Either way, Amazon provides security, elastic scalability, and high availability for your Kubernetes cluster, and the open source community has integrated Kubernetes with AWS services like Virtual Private Cloud (VPC), Identity and Access Management (IAM), and Amazon’s native service discovery. Here the primary options for deploying Kubernetes on AWS:

Amazon EC2 -comprehensive management of Kubernetes deployments. Configure and run Kubernetes nodes on compute instance type of your choice.
Amazon EKS -a cloud-based container management service that natively integrates with Kubernetes to deploy applications. The EKS service uses Kubernetes to automatically manage and scale clusters of infrastructure resources on AWS. Amazon EKS lets you use Kubernetes without installing, operating, or managing container orchestration software.
Amazon elastic container registry (ECR) -a fully managed Docker container registry that lets you store, share, and retrieve container images for use in Kubernetes clusters.

Kubernetes on Azure

Microsoft Azure is Microsoft’s public cloud computing platform. It provides various cloud services such as computing, analytics, storage, and networking. In the context of Kubernetes, Azure offers the following service options:

Azure Virtual Machines (VMs)-like in AWS, you can run Azure VMs and use them to install and manage components of a Kubernetes cluster, as a self managed option.
Azure Kubernetes Service (AKS)-lets you deploy managed Kubernetes clusters on Azure. AKS reduces the complexity and operational overhead of managing Kubernetes by shifting most responsibilities to Azure. Azure handles critical tasks such as health monitoring and maintenance, managing the Kubernetes control plane, leaving you to maintain Kubernetes worker nodes.
Azure container instances (ACI)-provides the fastest and easiest way to run containers on Azure without having to manage virtual machines or use advanced services. ACI supports Kubernetes, and is a lightweight option for running smaller Kubernetes clusters.
Azure container registry (ACR)-a managed private Docker registry service based on the open source Docker Registry 2.0. Lets you create and maintain your own, private container registry to store and manage Docker container images and related artifacts.

Kubernetes on Google Cloud

Google Cloud is a set of public cloud computing services provided by Google. The platform includes a variety of managed services for developing compute, storage, and software services running on Google hardware. Google Cloud provides two main options for running Kubernetes:

Google Kubernetes Engine (GKE)-GKE provides a hosting environment for deploying, managing, and scaling containerized applications. A GKE environment consists of multiple Google Compute Engine (GCE) instances that are grouped together to form a cluster. Like EKS and AKS, GKE fully manages the Kubernetes control plane and handles critical operational tasks for a Kubernetes cluster.
Google Anthos-a cloud-agnostic hybrid container environment that lets you run managed Kubernetes clusters in any environment. Anthos is a software product that lets you bridge the gap between on-premise data centers and cloud environments, using container clusters instead of cloud virtual machines (VMs).

Return to Top

Kubernetes and CI/CD

CI/CD is a software development practice that enables developers to continuously integrate and deploy code changes. In continuous integration (CI), developers integrate their code changes into a shared repository frequently, usually several times a day. Each integration is verified by an automated build, which can include tests to ensure that the new code does not break the build or introduce new bugs. In continuous deployment (CD), code changes are automatically built, tested, and deployed to production. This allows developers to continuously deliver new features and updates to users, without the need for manual intervention. When used together, Kubernetes and CI/CD can help developers build and deploy applications more quickly and reliably. For example, a developer might use a CI/CD pipeline to build and test their code, and then use Kubernetes to deploy the application to production. Kubernetes can then manage the running application, scaling it up or down as needed and automatically restarting or rescheduling failed containers. Kubernetes and CI/CD are often used together in cloud-native architectures, where applications are built as microservices and deployed in containers. In these architectures, CI/CD pipelines are used to build and deploy individual microservices, while Kubernetes is used to manage the overall application. This allows developers to build and deploy applications more quickly and easily, while still being able to manage and scale them in production.

Return to Top

GitOps and Kubernetes

GitOps is a new way to manage Kubernetes clusters and deploy applications to production. It is a development method that uses Git as a single source of truth, using declarative configuration to represent both infrastructure and applications. GitOps uses a software agent to identify differences between the configuration stored in Git and resources actually running in your cluster. If there is a discrepancy, this agent automatically updates or rolls back the cluster. Using Git at the heart of the delivery pipeline, developers can use familiar tools to make changes to applications and infrastructure, simply by creating a pull requests, accelerating and simplifying operational tasks.

GitOps and Declarative Configuration

Kubernetes with Gitops is just one example of many modern cloud-native tools that are “declarative”, treating configuration as code. Declarative means that resources are defined as a set of requirements, rather than a list of instructions that define how to create them (as in a traditional script). When these declarative configurations are versioned in Git, you have a single source of truth, which lets you easily deploy applications to a Kubernetes cluster and roll them back if necessary. This makes rollback easier-you can use “Git revert” to revert to a previous application state. In the event of a disaster, the Git repository stores the state of the entire cluster, making it easy to restore workloads.

GitOps and Security

When system declarations are stored in a version control system and serve as a trusted source of information, there is one place from which to drive the entire cluster. Git provides strong security guarantees, allowing you to sign commits with an SSH key, so you can be certain who is the author and what is the origin of your code. Once you have declared a state in Git, the system automatically applies changes to that state. A primary benefit of this approach is that you don’t need cluster credentials to make changes to a Kubernetes cluster (i.e. no more “kubectl” commands). GitOps has an isolated environment with externally-defined state definitions. This creates a separation between the Cl and CD environment, which is highly beneficial to security.

GitOps and Reliability

When a cluster’s system state is declared and placed under version control, software agents can notify when reality does not match expectations. GitOps agents allow the entire system, or any part of it, to self-heal. This is not “self healing” in the sense of routine errors in nodes or pods, which are anyway handled by Kubernetes. It is healing in a broader sense, such as recovering from human error or software bugs. In this case, the software agent acts as an operational feedback and control loop, which restores the cluster to the desired state.

Return to Top

What Is Argo?

Argo is an open source project managed by the Cloud Native Computing Foundation (CNCF). It is used to build and manage applications on Kubernetes using a GitOps-style continuous delivery (CD) workflow. A unique feature of Argo is that it is Kubernetes-native, designed from the ground up for modern containerized environments. Argo allows you to automate deployments and releases, and simplify rollbacks in case something goes wrong. The Argo project consists of 4 different projects: Argo Workflows, Argo CD, Argo Rollouts, and Argo Events.

Argo CD

Argo CD is a Kubernetes native continuous deployment (CD) tool. Unlike external CD tools that only allow push-based deployment, Argo CD can pull updated code from a Git repository and deploy it directly to Kubernetes resources. This allows developers to manage infrastructure configuration and application updates from one system. Argo CD offers the following key features:

Deploy applications manually or automatically to a Kubernetes cluster.
Automatically synchronize the application state to the current version of the declarative configuration.
Web-based user interface and command line interface (CLI).
Ability to visualize deployment issues and detect and correct configuration drifts.
Role-Based Access Control (RBAC) to enable multi-cluster management.
Single sign-on (SSO) with multiple providers and protocols.
Triggering actions with webhooks via GitLab, GitHub, or BitBucket.

Learn more in the detailed guide to Argo CD

Related product offering: Codefresh | GitOps Software Delivery Platform

Offered by Codefresh

Related technology updates:

[Webinar] CNCF Webinar: GitOps Continuous Delivery with Argo and Codefresh

Argo Workflows

Argo Workflows is an open source container-native workflow engine for orchestrating parallel tasks on Kubernetes. Argo workflows are implemented as Kubernetes CRDs. With Argo Workflows, you can:

Define a workflow where each step in the workflow is a container.
Model multi-step workflows as a series of actions, or use graphs (DAGs) to capture dependencies between actions.
Easily run compute-intensive jobs for machine learning and data processing on Kubernetes.
Run CI/CD pipelines natively on Kubernetes without configuring complex tooling.

Learn more in the detailed guide to Argo Workflows

Related product offering: Codefresh | GitOps Software Delivery Platform

Argo Rollouts

Argo Rollouts is a set of Kubernetes controllers and CRDs that provide advanced deployment features for Kubernetes such as blue-green deployment, canary deployment, canary analytics, experiments, and incremental serving capabilities. Argo Rollout can integrate with Kubernetes ingress controllers and service mesh platforms, leveraging traffic shaping to incrementally switch traffic to new versions during updates. It can also obtain metrics from other providers, validate KPIs that indicate success of a release, and drive automated promotions or rollbacks based on these metrics. Learn more in the detailed guide to Argo Rollouts

Related product offering: Codefresh | GitOps Software Delivery Platform

Offered by Codefresh

Related technology updates:

[Blog] Minimize Failed Deployments with Argo Rollouts and Smoke Tests

Argo Events

Argo Events is a dependency manager for Kubernetes that lets you define dependencies from different event sources, such as webhooks, Amazon S3, time-based schedules, streaming events, and so on-and trigger Kubernetes objects after an event dependency is resolved. Argo Events is not useful by itself-you need to integrate it with a system that can execute workflow steps. For example, you can set up Argo Events with Argo Workflows to orchestrate Kubernetes jobs in parallel. Learn more in the detailed guide to Argo Events

Related product offering: Codefresh | GitOps Software Delivery Platform

Offered by Codefresh

Related technology updates:

[Blog] Progressive Delivery for Kubernetes Config Maps Using Argo Rollouts

Return to Top

Kubernetes and Hybrid Cloud

A hybrid cloud is a combination of a public cloud and a private cloud, allowing organizations to take advantage of the benefits of both environments. Kubernetes can be used to manage containers in a hybrid cloud environment, allowing organizations to run their applications in both the public cloud and their own on-premises data center. This provides the benefits of the public cloud, such as scalability and access to a wide range of services, along with the control and security of a private cloud. Kubernetes can help organizations manage their hybrid cloud infrastructure by providing a common platform for deploying, scaling, and managing applications in both environments. Kubernetes can also help organizations manage the movement of applications and data between public and private clouds, ensuring that applications run optimally in each environment. Learn more in the detailed guide to Hybrid IT

Return to Top

Kubernetes vs. Rancher: What Is the Difference?

Kubernetes and Rancher are both powerful tools used in the container orchestration ecosystem, but they serve different purposes and operate at different layers of the infrastructure stack. Kubernetes is an open-source platform designed for automating the deployment, scaling, and management of containerized applications. It handles container scheduling, load balancing, scaling, and self-healing tasks, making it the de facto standard for container orchestration. Kubernetes provides the core functionality to manage containerized workloads, but it can be complex to set up and manage, especially in large-scale or multi-cluster environments. Rancher is a complete container management platform that simplifies the deployment and management of Kubernetes clusters. Rancher provides a user-friendly interface and additional tools that make it easier to manage multiple Kubernetes clusters across different environments, whether on-premises, in the cloud, or in a hybrid setup. Rancher also includes features like integrated monitoring, logging, security policies, and multi-cluster management, which are not part of Kubernetes by default. Organizations that require a more straightforward, integrated solution for managing multiple Kubernetes clusters might find Rancher particularly valuable, whereas those with the expertise to manage Kubernetes clusters directly might choose to use Kubernetes without Rancher. Learn more in the detailed guide to Kubernetes Rancher

Related product offering: Spot Ocean CD | Cloud Native Continuous Delivery

Return to Top

Kubernetes Security

Kubernetes has some security benefits, like easy version control, but its complexity and popularity make it an attractive target for attackers. One way for developers to address Kubernetes security is to consider how to implement security during each stage of the DevOps pipeline.

Security in the Build Stage

Kubernetes security starts when you build the code for container images. A secure environment requires shifting security left, including testing and assessing code-related risks. During the build stage, you must ensure the container images are current and don’t have vulnerabilities. You don’t always have a list of the open source components included in the container, so scanning for open source libraries and dependencies is important. Once you’ve identified all the components in play, it is possible to detect known vulnerabilities, identify the images at risk of new vulnerabilities, and track open source license compliance. Regular base image scanning is an important first step to securing the Kubernetes environment.

Security in the Deployment Stage

When you deploy Kubernetes, you have powerful controls to secure applications and clusters, but configuring these controls can be challenging and requires Kubernetes expertise. Avoid using defaults to reduce exposure, restrict user permissions, limit access to nodes, and segment the network to control communication between containers. Scanning during deployment is important to ensure base image security, including continuous vulnerability scans and environment updates. Ensure that all images used are from allow-listed registries.

Security in the Production Stage

Ensuring application security at runtime is more complex and requires implementing a networking layer with the CNI. In multi-tenant networks, every namespace in a Kubernetes cluster has private addressable subnets and can only access other pods exposed as services. Most next-gen networking layers have policies deployable via Kubernetes-these policies let cluster admins determine network access control lists to control access to services and ports.

Learn more in the detailed guides to:

Related technology updates:

[eBook] O’Reilly eBook: Kubernetes Security and Observability

Return to Top

Other Notable Kubernetes Tools

Kubernetes has a large ecosystem of tools that improve its networking, security, deployment, and observability capabilities. Here are some of the most notable tools used in Kubernetes environments:

Istio – A popular service mesh that enhances Kubernetes networking by managing service-to-service communication. Istio provides traffic management, security, and observability features, enabling fine-grained control over microservices interactions.
Helm – A package manager for Kubernetes that simplifies application deployment by using charts. Helm allows users to define, install, and upgrade applications in a Kubernetes cluster with minimal manual intervention.
KEDA (Kubernetes Event-Driven Autoscaling) – A Kubernetes-based event-driven autoscaler that dynamically adjusts workloads based on external event sources like message queues or monitoring data. KEDA works in conjunction with horizontal pod autoscaling (HPA).
Calico – Calico is a flexible and comprehensive Kubernetes networking and security solution. It provides essential features like network policy enforcement and supports both traditional overlay networking (IP-in-IP or VXLAN) and high-performance eBPF-based networking. Its support for overlay and non-overlay networking models makes it a versatile choice for securing pod-to-pod communication across diverse environments.
Cilium – A cloud-native networking and security solution that uses eBPF for high-performance networking, observability, and security policy enforcement. Cilium enables advanced networking capabilities, such as transparent encryption and deep visibility into network flows.
Kubeflow – A machine learning (ML) toolkit for Kubernetes that simplifies the deployment, training, and scaling of ML models. It provides an end-to-end ML pipeline orchestration within a Kubernetes environment.
Prometheus – A monitoring and alerting tool designed for Kubernetes. It collects and processes time-series metrics from various sources, including Kubernetes workloads, to enable real-time observability and alerting.
Fluentd – A logging agent that aggregates and forwards logs from Kubernetes pods to various destinations, such as Elasticsearch, Amazon S3, or a centralized logging system. Fluentd simplifies log management in distributed environments.
Spinnaker – A continuous delivery platform that integrates with Kubernetes to automate multi-cloud deployments. It enables safe and repeatable software releases by supporting canary deployments, blue-green deployments, and rolling updates.

Related technology updates:

KubeVirt – An extension for Kubernetes that enables running and managing virtual machines (VMs) alongside containers. KubeVirt bridges the gap between traditional VM-based workloads and cloud-native containerized applications, allowing organizations to modernize infrastructure without fully refactoring legacy systems. It provides APIs and controllers to treat VMs as first-class Kubernetes resources.

These tools help simplify Kubernetes operations, improve security and networking, and enable automation across cloud-native infrastructure. Learn more in the detailed guides to Cilium vs Calico

Related technology updates:

[Blog] Introducing the Calico eBPF Dataplane

Return to Top

Kubernetes Troubleshooting

Kubernetes troubleshooting is the process of identifying, diagnosing, and resolving issues with a Kubernetes cluster, node, pod, or container. More broadly, Kubernetes troubleshooting includes effective error management and actions to proactively prevent problems with Kubernetes components. Kubernetes is a complex system, and troubleshooting a problem in a Kubernetes cluster is equally complex. Diagnosing and resolving issues can be challenging even on small local Kubernetes clusters. The root cause of a problem could be a single container, one or more pods, a controller, a control plane component, one or more infrastructure components, or some combination. This problem is exacerbated in large production environments with low visibility and many moving parts. Teams must use multiple tools to gather the data they need to troubleshoot, and in some cases, additional tools to diagnose and resolve issues they discover. To make matters worse, Kubernetes is often used to build microservices applications developed by separate teams. In other cases, DevOps and application development teams work together on the same cluster. This makes the division of responsibility unclear. If there is an issue with the pod, is it a DevOps issue or an issue for the relevant application team? Without best practices, clear troubleshooting processes, and the right tools, Kubernetes troubleshooting can quickly become confusing, time consuming, and frustrating, and can impact the reliability of workloads running in a Kubernetes cluster. Learn more in our detailed guide to Kubernetes Troubleshooting

Or read the guides to the most common Kubernetes errors and how to solve them:

Return to Top

Kubernetes Networking with Tigera

Tigera provides Calico, a unified network security and observability platform to prevent, detect, and mitigate security breaches in Kubernetes clusters. As the creator and maintainer of Calico Open Source, the most widely adopted container networking and security solution, Calico builds upon this foundation to deliver advanced security and observability for cloud-native applications. Calico software powers more than 100M containers across 8M nodes in 166 countries, and it is trusted by more than 50% of Fortune 100 companies. At Calico’s core is a pluggable data plane architecture that enables support for multiple data planes, including eBPF, nftables, standard Linux, VPP, and Windows. This flexibility allows organizations to optimize for scalability and performance across any environment, whether running on public cloud providers or on-premises.

Calico’s Key Capabilities

Network Security Policy Enforcement

Calico extends Kubernetes networking with fine-grained Network Security Policy controls and hierarchical policy tiers. This approach allows platform and security teams to define global guardrails that prevent unauthorized lateral movement while ensuring consistent enforcement across all clusters and distributions.

Network Security Observability

Calico delivers deep visibility into east-west traffic between workloads. Through capabilities like the Calico Service Graph, teams can visualize service dependencies, monitor network flows, and identify anomalous behavior or misconfigurations. This empowers organizations with the risk mitigation capabilities necessary to secure all types of network traffic, including egress, ingress, in-cluster, and cross-cluster.

Consistent Security Across Environments

Calico offers centralized network security management across popular managed Kubernetes services, including Amazon EKS, Azure AKS, and Google GKE, as well as self-managed Kubernetes distributions such as Red Hat OpenShift and SUSE Rancher. This ensures a consistent experience and unified visibility for both single- and multi-cluster deployments, whether running in the cloud or on premises. By integrating Calico into a Kubernetes stack, organizations move beyond basic connectivity to a secure, observable foundation. Calico commercial editions help teams meet rigorous compliance requirements such as PCI DSS, SOC 2, and HIPAA while scaling confidently across diverse environments.

Return to Top