a wonderful basic illustration of ISTO. I have done Kubernetes for the last 3 years and have been very involve in Kubernetes operation and troubleshooting. we were using LinkerD for service mesh. and just migrated to ISTIO. your illustration of component of ISTO was great help to me. Thank you very much for your help!!
Ah great to hear Mathew! One thing to be aware of with Istio though - they LOVE dropped breaking changes at random and without warning. With the release of Istio 1.7, I've got to go through the entire course and make wholesale changes. This is a major issue for projects and Istio don't seem to care much about it. Thank goodness Kubernetes aren't so cavalier. Good luck with it!
Thank you. Great way of teaching. I watched other few videos from different sources. But this was the best and to the point. ... subscribed and shared.
Aw that's very kind, thanks for the sub. Sadly I've been very lax about adding new content to the channel over the past year, I really will get busy on uploading some content soon. All the best!
Richard, Very well explained. Great job ! I am not sure why this mesh stuff is needed. It looks like a modern day ESB to me. I put all my service containers that need to talk to each other on the same pod. They talk to each other on localhost..very fast..and log aggregation tells me if something has failed. Kubernetes already generate proxies for services, why we need another layer ? Interpod communication should be minimal..it is bad architecture to have chatty pods in my view.. container services talk in http (No SSL) because they are not exposed outside the pod.. SSL terminates at ingress and not needed beyond that. Simple architectures and lean tech stack is most efficient..although I will keep my mind open and keep learning :)
All good points, it depends on your architecture - obviously, you're not into microservices (which is fine!) but for those going down the microservices route, all of this becomes needed (should be baked into kubernetes imo, Istio is the market leader right now but it's fussy and complicated so I'm hoping for something better to come along). Certainly is a modern day ESB, especially if paired with a pub/sub broker.
Hi yes. A sidecar in kubernetes generally is any kind of "helper" container that runs alongside some kind of main container. As you know, in Istio the proxy is implemented as a second container, so it's often referred to as "the sidecar", although sidecars can be used for other things. If you're talking about Istio, then people will know that Proxy == Sidecar
So what is the differences between pod network solution (like Weave-net) and Service mesh in context of kubernetes? Can pod network solution(wevae-net or Calico) and Service mesh (like istio) be present at the same time in kubernetes?
calico and weave are operating at L3 or L4 which setup the overlay network for pods, and Istio Envoy is L7 and it's in a pod as a sidecar container. You need some solution to connect those istio proxies, that's where the cni(calico or weavenet) comes in.
Nice Richard, do you have topics with examples on how to measure performance (scaling will come later) of istio - I didn't see anything on the training course. I'm eluding to istio.io/docs/ops/deployment/performance-and-scalability/ on how they perform their measurements. Thanks
Sorry Gerry I missed your comment - too late now I guess! We do touch a little on this, but not much - I know they have their own tools to do load testing. Biggest issue for me rather than performance (I don't feel any particular impact from Istio) is that the sidecars do make requests which means you will need a bigger cluster and hence more costs.
True. The previous course to this was microservice oriented though, so in the courses, I do refer to pods and microservices a bit interchangeably. But yes!
![[#2024MAMA] BIGBANG (빅뱅) - 뱅뱅뱅 (BANG BANG BANG) + FANTASTIC BABY | Mnet 241123 방송](http://i.ytimg.com/vi/EQsYfiPR9uM/mqdefault.jpg)
a wonderful basic illustration of ISTO. I have done Kubernetes for the last 3 years and have been very involve in Kubernetes operation and troubleshooting. we were using LinkerD for service mesh. and just migrated to ISTIO. your illustration of component of ISTO was great help to me. Thank you very much for your help!!
Ah great to hear Mathew! One thing to be aware of with Istio though - they LOVE dropped breaking changes at random and without warning. With the release of Istio 1.7, I've got to go through the entire course and make wholesale changes. This is a major issue for projects and Istio don't seem to care much about it. Thank goodness Kubernetes aren't so cavalier. Good luck with it!
your tutorials are the best on RUclips!
Aw you're very kind! I really do need to get more onto youtube, I've been far too lazy! Will get something new up ASAP! All the best!
@@RichardChesterwood Videos on the following topics would be extremely helpful for many:
Docker
Ansible
Kubernetes
Really nice explanation to understand the high level working of Istio.
so far this is the best video i watched for the past few weeks tackling service mesh (istio). good work!
Ah you're very kind Richard, many thanks!
Clean and precise explanation. thanks Richard
You're very kind Rajeev!
Very well explained Richard... liked the simplicity with which you explained it!!
Brilliant Aritro! Many thanks!
Thank you. Great way of teaching. I watched other few videos from different sources. But this was the best and to the point. ... subscribed and shared.
Aw that's very kind, thanks for the sub. Sadly I've been very lax about adding new content to the channel over the past year, I really will get busy on uploading some content soon. All the best!
Great introduction - really appreciate your style
Many thanks!
Thank you very much for your course. Really appreciate it
Many thanks Marco!
这是我看到的调理最清晰的istio视频
谢谢你！(Thankyou! - I've used google translate there so I hope it has worked correctly!)
Such a great explanation! Thank you!
Many thanks!
Richard, Very well explained. Great job !
I am not sure why this mesh stuff is needed. It looks like a modern day ESB to me. I put all my service containers that need to talk to each other on the same pod. They talk to each other on localhost..very fast..and log aggregation tells me if something has failed.
Kubernetes already generate proxies for services, why we need another layer ?
Interpod communication should be minimal..it is bad architecture to have chatty pods in my view..
container services talk in http (No SSL) because they are not exposed outside the pod..
SSL terminates at ingress and not needed beyond that.
Simple architectures and lean tech stack is most efficient..although I will keep my mind open and keep learning :)
All good points, it depends on your architecture - obviously, you're not into microservices (which is fine!) but for those going down the microservices route, all of this becomes needed (should be baked into kubernetes imo, Istio is the market leader right now but it's fussy and complicated so I'm hoping for something better to come along). Certainly is a modern day ESB, especially if paired with a pub/sub broker.
Very clear your explanation, thank you!
Thanks Marquinhe!
Fantastic presentation Richard, really helped me under Istio
Great to hear thanks - good luck with it!
Great explination !
Great job! Thank you
Nice Explanation ..!!
Many thanks!
Of course it was for interview questions. :)
Ah the dreaded interview questions. Can't understand why they persist in doing this (asking pre-set questions). Good luck with it though!
Thanks 🙏
Hi . Is proxy container same as a sidecar container?
Hi yes. A sidecar in kubernetes generally is any kind of "helper" container that runs alongside some kind of main container. As you know, in Istio the proxy is implemented as a second container, so it's often referred to as "the sidecar", although sidecars can be used for other things. If you're talking about Istio, then people will know that Proxy == Sidecar
So what is the differences between pod network solution (like Weave-net) and Service mesh in context of kubernetes? Can pod network solution(wevae-net or Calico) and Service mesh (like istio) be present at the same time in kubernetes?
calico and weave are operating at L3 or L4 which setup the overlay network for pods, and Istio Envoy is L7 and it's in a pod as a sidecar container. You need some solution to connect those istio proxies, that's where the cni(calico or weavenet) comes in.
Nice Richard, do you have topics with examples on how to measure performance (scaling will come later) of istio - I didn't see anything on the training course.
I'm eluding to istio.io/docs/ops/deployment/performance-and-scalability/ on how they perform their measurements. Thanks
Sorry Gerry I missed your comment - too late now I guess! We do touch a little on this, but not much - I know they have their own tools to do load testing. Biggest issue for me rather than performance (I don't feel any particular impact from Istio) is that the sidecars do make requests which means you will need a bigger cluster and hence more costs.
It was all good, besides that a pod is not a microservice
True. The previous course to this was microservice oriented though, so in the courses, I do refer to pods and microservices a bit interchangeably. But yes!
Pp