new notes about istio

_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)