KalmOverview
Traffic management is one of the most important tasks in a cluster. Kalm provides a simple API layer on top of Kubernetes' default network model and istio traffic routing rules.
Let's go over how Kubernetes and Istio traffic management works, and what Kalm provides on top of these existing components.
Background
The source of traffic to be managed can be either external - coming from outside the cluster, or internal - amongst entities within a cluster. Let's look at each in detail.
External Traffic Management
Kubernetes Ingress & Services
Kubernetes Ingress is a simple specification for HTTP workloads. There are multiple implementations of Kubernetes Ingress, including NGINX Ingress Controller and many others.
However, Kubernetes Ingress has certain limitations:
Designed for HTTP, it does not expose arbitrary ports or protocols. NodePort and LoadBalancer Services are required to handle non-HTTP/HTTPS traffic. This can sometimes make traffic management more fragmented.
It does not (yet) provide specification or implementation for advanced routing functionality such as traffic splitting, mirroring, or fault injection. Because Kubernetes Ingress needs to accomindate for a wide range of HTTP proxy implementations, it only provides support for basic common functionality. This can be too limiting.
Istio
Istio uses Gateways to manage layer 4-6 load balancing properties such as ports and TLS, and VirtualServices to handle layer 7 application-level traffic routing. This model prevents fragmentation, as the Gateway handles everything regarding ports and protocols, and all routing related rules are managed altogether by the VirtualService.
Internal traffic management
Kubernetes
There are a few types of internal traffic, each handled by different Kubernetes components.
- Highly-coupled container-to-container communication. Container level communication is sufficiently handled by Pods, and is outside the scope of this discussion.
- pod-to-pod communication. Pod level communication is handled by the Kubernetes Container Network Interface.
- pod-to-service communication. A Service is an abstraction which defines a logical set of Pods and a set of access policies.
The default networking functionality of Kubernetes works well for basic internal traffic management, but Istio can help take things further.
Istio
Istio's Sidecar Injection can make pod-to-pod communications secure with mutual TLS, and generate telemetry to enable distributed monitoring and tracking.
For pod-to-service communications, Istio differs from Kubernetes significantly. Although Kubernetes' Kube-proxy (working under IPVS mode) can support connection level load balancing in L4, it does not understand L7 protocols such as HTTP.
Istio inject Pods with istio-proxy, which allows for L7 load balancing. This means it can support more advanced scenarios, such as load balancing long-period connection protocols such as gRPC. In addition, Istio's data plane proxy, Envoy, allows for filters to be set along the traffic path.
Traffic Management Features in Kalm
Making Istio "just work"
While Istio provides useful and valuable traffic management functionality on top of Kubernetes, it also adds to the complexity and can be challenging and time consuming to configure and utilize correctly.
Kalm integrates Istio by default and makes its powerful traffic management features easily accessible out of the box. Kalm's HttpRoute - TODO and HttpsCert - TODO CRDs provides an intuitive interface for common devop tasks.
Kalm provides an abstraction layer over Istio and Kubernetes Networking without restricting direct access. You can configure Istio directly whenever the situation calls for it.
Cost Considerations
Although for hobbyist clusters, running Istio may be undesirable due to higher resource consumption, for real-world production clusters we believe the functionality can easily justifies the added overhead.