Does Istio replace the default networking kuberentes api?

Service Mesh with Istio
#1

Hi

Recently I was checking Istio and to know how is about. I see that works with the yaml files but also changes the api of networking.k8s.io/v1 to the Istio one. I was wondering if in production environment the default networking of kuberentes is replaced 100% with the istio one. Also i’ll be glad to know how much often in productions environemts are using Istio. So after succeding in the CKA certification, know if Istio is a must learn with helm to work in production.

Best Regards

#2

Istio doesn’t replace the core networking API. It does compliment it though. It is worth looking into as many places do use it. Benefits include

  • mTLS security for workloads without having to change application code
  • Improved traffic routing, e.g. you can do a 1%-99% traffic split on a service that has any number of replicas behind it - even only 2.
  • Traffic visualization using Kiali (comes with Istio)
  • Enhanced ingress using istio gateways etc.

Helm is almost essential to know, more so than Istio. Nobody deploys anything to production with kubectl apply. Even it using something like Argo-CD, it’s best to have that deploy helm charts rather than collections of individual manifests. Pretty much everything 3rd party you want to deploy into your clusters (e.g. Prometheus etc), are installed by helm charts.

1 Like
#3

Hi @Alistair_KodeKloud

Thanks for the answers, helps a lot. I imagine that also Argo-CD is a must in production environment, but not sure if that’s true with your comment. I mean, you can link the Argo-CD with the repo main branch, while the devops team are working in different branches. So as far as I know, if you create your testing scenarios well, the main branch will be working well most of the time, and if there is any error in the main branch, you can go back to a healty push. I find this great, because you reduce the admins for the cluster, which improves security in many ways, and also use the tools of git in your development of the infrastructure, without damaging your cloud environment. So there is any case when using Argo-CD is not a good case ? I’m asking to know if is a must like heml, because it seems to be, at least in production environment.

So it seems like for working in kubernetes you need at least experience with it in form of certification or repo, and also understanding of helm. In that case you can code the infrastructure in a repo. But if you really want to administrate the cluster and also the CD/CI pipeline you will need experience with istio and Argo-CD, and I imagine that that kind of jobs are for senior engineers because of the responsabilities implied. I’m seeing all of this right ?

Thanks and have a nice day.

PD: I understand that if your team is working with istio, at least you must know the api calls to put them in the yaml files like {this.is.my.data.} :slightly_smiling_face: