Kubernetes is the de facto standard for orchestrating modern cloud-native workloads. But, it doesn’t provide for secure communication out of the box. This means everyone who needs to implement encryption-in-transit to adopt a zero trust security posture for their Kubernetes deployments needs to figure it out for themselves.
Traditional network security relies on a strong defensive perimeter around a trusted internal network to keep bad actors out and sensitive data in. In an increasingly complex networking environment, maintaining a robust perimeter is increasingly difficult.
Istio is one of the three core technologies in the container-based cloud native stack. The other two are Kubernetes and Knative, and both of them already support the arm64 architecture. Envoy, Istio’s data plane has supported arm64 as early as version 1.16 (October 2020 ). With the release of Istio 1.15, the control plane supports arm64 as well. You don’t need to build the arm image manually, it works out of the box.
Today, digital transformation is a well-established priority for almost all organizations across industries. With digital transformation, which includes adopting cloud, microservices, and container technologies, C-Suite leaders intend to deliver services faster and on demand.
Start Using Service Mesh Now with Tetrate Istio Distro on the Azure Container Marketplace for Kubernetes Applications
Service mesh is entering the mainstream as a preferred solution for securing, connecting, and managing today’s distributed, dynamic applications. Tetrate Istio Distro (TID) is the easiest way to get started with Istio, the most widely used service mesh, and is available now from the Azure Container Marketplace for Kubernetes Applications with enterprise support via Tetrate Istio Subscription (TIS). Tetrate Istio Distro is a vetted, upstream distribution of Istio that is simple to install, manage, and upgrade with FIPS-verified builds available for FedRAMP environments.
The Azure Container Marketplace allows application teams and operators to acquire and deploy Tetrate Istio Distro to their AKS clusters as a single task.
- If you are just starting with Istio, Tetrate Istio Distro on the Azure Container Marketplace offers a streamlined way to deploy Istio to new and existing AKS clusters.
- If you already use Istio, Tetrate Istio Distro makes Istio lifecycle management safe and easy.
- Tetrate Istio Subscription offers enterprise support plus access to the expertise of Istio and Envoy creators and core contributors.
- Azure Container Marketplace is a simple, flexible way to procure Istio support from Tetrate.
Tetrate has worked closely with the Azure team to make the process of deploying Istio on AKS seamless. We’d like to share the highlights of that work and how you can get started using Istio today.
Apache SkyWalking is an application performance monitor tool for distributed systems. It observes metrics, logs, traces, and events in the service mesh environment and uses that data to generate a dependency graph of your pods and services. This dependency graph can provide quick insights into your system, especially when there’s an issue.
However, when troubleshooting network issues in SkyWalking’s service topology, it is not always easy to pinpoint where the error actually is. There are two reasons for the difficulty:
- Traffic through the Envoy sidecar is not easy to observe. Data from Envoy’s Access Log Service (ALS) shows traffic between services (sidecar-to-sidecar), but not metrics on communication between the Envoy sidecar and the service it proxies. Without that information, it is more difficult to understand the impact of the sidecar.
- There is a lack of data from transport layer (OSI Layer 4) communication. Since services generally use application layer (OSI Layer 7) protocols such as HTTP, observability data is generally restricted to application layer communication. However, the root cause may actually be in the transport layer, which is typically opaque to observability tools.
Access to metrics from Envoy-to-service and transport layer communication can make it easier to diagnose service issues. To this end, SkyWalking needs to collect and analyze transport layer metrics between processes inside Kubernetes pods—a task well suited to eBPF. We investigated using eBPF for this purpose and present our results and a demo below.
Who Is This For?
You should read this if you run Kubernetes and/or Istio on a public cloud, and you care about your cloud bill. Cloud providers charge money for data egress, including data leaving one availability zone destined for another. If your Kubernetes deployments span availability zones, you are likely being charged for egress between internal components. Even if you don’t run Kubernetes/Istio, you’ll still run into cross-zone data egress costs, which this article will help you understand and minimize.
Istio recently announced “ambient mesh”—an experimental, “sidecar-less” deployment model for Istio. We’ve written about sidecar vs. sidecar-less recently in the context of getting the most performance and resiliency out of the service mesh. In this article, we’ll present our take on ambient mesh in particular.
Deploying Kubernetes clusters across availability zones can offer significant reliability benefits, especially when you use Istio for application routing and load balancing. If you have built redundant failure domains in separate zones, the mesh can automatically shift traffic to another zone should one zone fail. Istio’s locality-aware load balancing can also help reduce latency and cross-zone traffic charges from your cloud provider by keeping traffic within the same zone as much as possible.
One of Istio’s core capabilities is to facilitate a zero trust network architecture by managing identity for services in the mesh. To retrieve valid certificates for mTLS communication in the mesh, individual workloads issue a certificate signing request (CSR) to istiod. Istiod, in turn, validates the request and uses a certificate authority (CA) to sign the CSR to generate the certificate. By default, Istio uses its own self-signed CA for this purpose, but best practice is to integrate Istio into your existing PKI by creating an intermediate CA for each Istio deployment.