Let’s Connect ELB on Istio Ingress! — ALB
Istio often acts as a service mesh within a K8S cluster. Not only does it serve as a service mesh, but it also serves as an Ingress, such as Nginx Ingress and ELB Ingress.
If you use the Ingress provided by Istio, the AWS Load Balancer is created, but it is created as Classic Load Balancer (a.k.a CLB).
The CLB will be deprecated at AWS in the future, so it should be replaced by Network Load Balancer (a.k.a NLB) or Application Load Balancer (a.k.a ALB).
So, in this article, I change CLB to ALB as Ingress.
what is Istio? 🤔
Before we dive in, let’s talk about Istio.
Istio helps you deliver service meshes such as AWS App Mesh.
Istio is actually a CNCF graduation that makes Envoy a little easier for users to use in a Kubernetes.
That is, Envoy == Istio.
However, Envoy is made of C++, and is difficult because it is a very low-level tool. So Istio that makes it easy to implement.
It's not 100%, but Istio is the abstraction layer above Envoy 🙂
Istio also uses SideCar Container Pattern among Pod design patterns.
Inside a pod, there is a Proxy with SideCar, which is Istio. And Proxy is managed by Istiod.
With Istio, you can use the following features:
- Collect telemetry results from proxy
- Implement policies using proxy
- Canary deployment, A/B deployment, dark deployment, and more
- Ability to deploy test software to live production environments
- and fault injection, circuit breaking, mTLS, etc..
There are many other functions, but we’ll talk about them in other articles.
Let’s install Istio 👏
Based on MAC m1 🍎
- Install “isioctl” using the brew
$ brew install istioctl
2. Install Istio by specifying a profile.
Istio offers a variety of profiles, but I’ll install it as default here.
$ istioctl install --set profile=default
give you additional information about the profile…
- Default and demo are the most frequently used profiles (The rest is…))
- For production environments, default is the best choice
- Demo is needed in places that require a lot of tracing, such as mini-kube
3. The installation is complete. Let’s check it out through the command!
$ kubectl get all -n istio-system
If you see like this, you did it successfully 🎖
Let’s check something!
If you look at the pods, you can see that the isio-ingress gateway and the isiod were created because I gave the profile default earlier.
The default profile does not mean that you cannot install egress.
$ kubectl edit istiooperators.install.istio.io -n istio-system
You can use above command to change settings.
And the most notable thing is the service/istio-ingress gateway. If you look at EXTERNAL-IP, you can see that AWS Domain is assigned, which is CLB.
$ aws elb describe-load-balancers
You can see that the generated LB is output.
In fact, this configuration alone is enough to serve as Ingress. Using Istio’s CRD Gateway, VirtualService, and DestinationRule 😎
However, as I said before, CLB is no longer available, so we need to change it to NLB and ALB.
Let’s change to ALB!
If you change CLB to ALB, you can change it to ALB instead of CLB as shown in the figure.
However, unlike CLB, ALB requires something called AWS Load Balancer Controller.
Installing the AWS Load Balancer Controller alone requires a lot of space, so we won’t cover it here.
If you look at the official AWS document, you’ll be able to follow it easily.
The AWS Load Balancer Controller performs exactly the same role as the Nginx Ingress Controller. However, it is provided by AWS.
Let’s see if the AWS LB Controller is installed properly! 🙏
$ kubectl get all -n kube-system
It’s working fine 😀
Then let’s connect it!
- Modify service/istio-ingressgateway.
$ kubectl edit -n istio-system service istio-ingressgateway
Modify as follows.
It comes out after using “:wq”
The reason for this is not to use CLB. If it is type: Loadbalancer, CLB is automatically generated, and we will change the type to NodePort because we will not use it.
The previously created CLB in Istio will then be deleted, leaving only ALB.
I thought ClusterIP could do it, so I changed it. It didn't work.
If you think about it, it's natural.
From an ALB perspective, each instance is communicated to the target group, and the ALB is responsible for sending communications within the EKS cluster
Since it's not, of course, you have to access it through the node port.
2. create Ingress
There are a lot of annotations, but it’s very intuitive, so you can easily figure out which one it is.
But let me tell you about some of the important things.
“Use http, https listeners, and redirect to https if communications come through http!”
“I will use the instance to have ip mode and instance! Note”
“Designate the ALB as public! If you want to do it as a private, use the internal”
I think there’s about this much, and if you want to know more, please refer to this link!
This completes all settings.
You can think of it as following 👍
I learned how to connect Istio Ingress to ALB. If it’s your first time, I think it could be very difficult.😅
Thank you for reading 😉