From 21d305dec2326cdd2b1dadd59c0fe37653da8bcb Mon Sep 17 00:00:00 2001 From: Xiong Ding Date: Mon, 16 Dec 2024 16:06:12 -0800 Subject: [PATCH] new notes about istio --- _posts/2024-12-16-istio.md | 63 +++++++++++++++++++++++++++++++++----- 1 file changed, 56 insertions(+), 7 deletions(-) diff --git a/_posts/2024-12-16-istio.md b/_posts/2024-12-16-istio.md index 201c201..a7f38ba 100644 --- a/_posts/2024-12-16-istio.md +++ b/_posts/2024-12-16-istio.md @@ -6,12 +6,61 @@ categories: [network] tags: [network, istio, envoy] --- +Istio used to have a micro-service architecture. However, starting from v1.5, +It moved back to a monolithic architecture. This largely simplifies the +management of Istio. After v1.5, we only need to worry about two components: +the proxy agent and istiod daemon. See more details in this +[blog](https://blog.christianposta.com/microservices/istio-as-an-example-of-when-not-to-do-microservices/). + +It sounds simple with only two components, right? The reality is not. See below +pods I grabbed from an old installation. + +``` +$ k get pods -A | grep istio +istio-operator istio-operator-6f7d5894cc-mw5bp 1/1 Running +istio-system istio-egressgateway-58c576f5f-w9wht 1/1 Running +istio-system istio-ingressgateway-775747ccd7-66pdg 1/1 Running +istio-system istiod-888fc4cbb-4trqq 1/1 Running +``` + +First, let's talk about `istio-operator`. This pod actually should not exit. It +is discouraged to install istio using operator mode any more. It is deprecated +in istion 1.23 and will be removed +[in version 1.24](https://istio.io/latest/blog/2024/in-cluster-operator-deprecation-announcement/). +Quote from the +[source code](https://github.com/istio/istio/blob/765457711ef83305458d91d7bca5f185fb6bb68b/operator/README.md?plain=1#L15) + +> The operator formerly acted as an in-cluster operator, dynamically +> reconciling and Istio installation. This mode has now been removed, and it +> only serves as a client-side CLI tool to install Istio. + +We can safely remove this pod/deployment if we use helm or istioctl to install +istio. + +Second, let's turn to (ingress/egress)gateways. First, we should not mistake +them with k8s gateway api. They are related, but not the same. + +A quick recap on k8s gateway api. Gateway is similar to ingress. GatewayClass +to Gateway is what IngressClass to Ingress. However, gateway is more powerful. +Gateway supports L4 and L7 routing. While ingress only supports http routing. +Ingress can only route traffic to a single namespace, it can’t be used as a +unified gateway across multiple namespaces. Gateway api becomes available since +k8s 1.24. However, it is not natively implemented inside k8s. It exists as an +add-on. You need to manually install +[those CRDs](https://gateway-api.sigs.k8s.io/guides/#installing-gateway-api) or +choose an [implementation](https://gateway-api.sigs.k8s.io/implementations/) +which handles it for you. + +Finally, John Howard has an +[excellent blog](https://blog.howardjohn.info/posts/istio-install/) talking +about all these istio confusions. Please check it out! + ## Pilot Pilot has two components: `pilot-agent` and `pilot-discovery`. If you have read -my [Envoy notes](envoy.md), you know that the xDS protocol has two parts: proxy -and management server. `pilot-agent` is the proxy part, and `pilot-discovery` -is the management server part. +my Envoy notes below, you know that the xDS protocol has two parts: proxy and +management server. `pilot-agent` is the proxy part, and `pilot-discovery` is +the management server part. ### Pilot-agent @@ -217,10 +266,10 @@ for more details. ## Envoy Envoy is a proxy solution. There are so many proxies in the market: nginx, -haproxy, trafik and etc, but why Envoy stands out? It is because the xDS APIs, -or a fancier name, xDS protocol. Envoy project incubated a protocol that allows -dynamically changing proxy configurations using a channel between proxy and the -management server. +haproxy, trafik and etc, but why does Envoy stand out? It is because the xDS +APIs, or a fancier name, xDS protocol. Envoy project incubated a protocol that +allows dynamically changing proxy configurations using a channel between proxy +and the management server. Alex Burnos has a [great article](https://medium.com/@aburnos/data-plane-control-plane-and-their-apis-explained-d0a3fa7291f3)