As part of our tradition of promoting service mesh adoption, Tetrate is proud to announce our contribution of the first official CNCF Istio course through the Linux Foundation, called Introduction to Istio (LFS144x).
With the release of Envoy Gateway 0.2, you may be wondering what’s happening in this part of the ecosystem, where things are headed, or maybe just wondering what Envoy Gateway (EG) even is. In this post, Tetrate’s Matt Turner explores all this and more.
How do network requests get into your Kubernetes cluster from the outside? Chances are you’re using an ingress controller: a set of HTTP reverse proxies that transit traffic into the cluster, and an operator that controls them. You might be using something like Ambassador or Contour, Traefik or HAproxy. You might be using your cloud provider’s solution, or just the “default” Nginx Ingress. Or you might be using a more full-featured “API Gateway” (of which more later) like Tyk or Kong, or have a separate gateway in another layer in front of your Kubernetes ingress, like AWS’s API Gateway, or an on-prem F5. Suffice to say, there are many options to choose from.
In my other blog post this week, I talk about the new Kubernetes Gateway API and the release of Envoy Gateway 0.2. In this post we’re going to get hands-on with Envoy Gateway and the Gateway API. Below are instructions that walk you step-by-step through installing Envoy Gateway, and a simple use case of exposing an HTTP app outside the cluster, through an Envoy proxy.
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.
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.
This article will show how to use Apache SkyWalking with eBPF to make network troubleshooting easier in a service mesh environment.
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:
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.
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.
Tetrate is excited to announce and welcome David Wang to the team! David is joining as the Head of Marketing for Tetrate. He will be building and leading a world-class marketing team to develop a strategic narrative for Tetrate in the emerging Service Mesh market. David will spearhead an innovative, repeatable, and scalable GTM strategy for Tetrate. In addition, he will also create brand awareness and credibility with the analyst firms, enterprises, and the market while continuing to grow Tetrate’s unrivaled reputation within the developer community.
