14. Telemetry - Kiali Dynamic Traffic Routing

So welcome back.

And we're exploring kiali.

And I'm running out of steam really, I've shown you most of the observation features in kiali.

And anything that I've missed, I'm sure you'll pick up really easily.

I think this is an invaluable tool on any Kubernetes architecture.

And a frequently asked question, Well, istio is quite complicated is it really worth me having it on my project.

And obviously, that is a complicated question, depending on what value you get from Istio.

But I would almost go so far as to argue that just this graph on its own is enough justification for using Istio, potentially, that's definitely debatable, because to make this work, as you know, now, you do need the complexity of having those proxies running.

And therefore you need more system resources to run Istio.

But I think even if you're not doing the traffic management and the policies and the security that's coming later in the course, just having this observability of the structure of your system, calculated dynamically at runtime, I think is so so powerful.

So that's all about observability.

But this final video on kiali, we're going to look at how you can make dynamic changes to your application live.

So that's quite a bold claim.

And to illustrate this, I've just gone on to the service graph.

Now when we go further in the course, we've got a whole section coming up on traffic management.

And using Istio, we can do very clever things such as setting up Canary releases, we can do a B testing, we can even do things such as deploying a test microservice, into a production cluster.

And we can hide that test service from everybody except the engineers of the system, we've got a video coming up on that, and I've called it dark releases.

And that could even mean with this do you don't need to have for staging or a test environment.

So that's quite a bold claim.

And we'll definitely need to go into a lot of detail on that, it still achieves that using its own custom configuration, we're going to be writing YAML to do that.

And to fully understand it, we need to pick up jargon terms such as virtual services, and destination rules.

So all that's coming later on, I don't want to get too deep into that.

But I do want to show you that you can change those Istio configurations through this graphical interface.

We'll definitely revisit this when we are in the traffic management system.

But for now, I just want to do a quick demo.

Let's say that for some reason, we've got a serious problem with this staff service here.

Perhaps it's gone crazy, perhaps it's taking up all of the CPU in the cluster, or it's causing auto scaling to spin up lots of nodes that we can't afford.

Or maybe it's making requests to some third party service.

And, and it's gone crazy.

And we're running a risk of getting accused of doing a denial of service attack or something.

My point is there's an emergency situation with this particular service.

Well, as I've said, we can write some Istio yaml to cut this connection, just to reject all traffic going along this connection.

And we can do all of that without having to delete pods.

How can we do that? Well, as I say there is specific Istio configuration to do that.

But we haven't learned any of that configuration just yet.

I'm going to go on to the command line though, just to prove.

As I say the this feature, these traffic management features are implemented by a Kubernetes object provided by Istio called Virtual services.

So if I do kubectl, get virtual services and getting no resources found.

You can shorten that down by the way to vs kubectl get vs.

Now what I'm just wanting to show here is I haven't sort of slipped any of these configurations in behind your back.

The yaml that we've worked with is just a regular workload of services and parts.

In Istio there's also some Diaz, which are destination rules, and I'll do that longhand as well.

I'm just proving the point here that we have no Istio traffic management going on.

But what I'm showing you here is that we can very easily so here's our service that we want to close off, I can right click on that service and To show details, just as we've done before, and there's quite an upskill, I have to admit, I didn't even notice this for a long time using kiali.

There's an Actions button here.

And what I can do with these actions is I can create a weighted routing, or routing, create matching, routing or routing, I can suspend traffic.

As I say all of that is done by Istio yaml.

But these buttons will generate that yaml and will apply it automatically.

Of course, I'll need to talk about what all of this weighted and matching businesses.

But for this demo, we're just going to go for the simple option of suspend traffic.

Let's click that.

When we go further with this in traffic management, there be lots of options here.

But for suspending the traffic, we just have to click Create a need to be very careful with doing that in a production system.

But I'm just going to go to the graph.

And I'm going to expect to see some changes on this real time graph.

The first change you can see is there's a little icon next to that service, which is sort of a kind of a railroad icon, it's showing you that there is some routing or routing applied to that service.

I'm playing for time, I'm waiting to see a change there.

Actually, if I go back to my command line, I just want to show you now that those commands I was issuing, I've done nothing apart from that if I now do get virtual services, I have an entry there Fleetman staff service.

And if I repeat the get destination rules, yeah, we've got some destination rules as well.

So it's done some magic, it's created what is actually a yaml file, and it's applied it to the cluster, I didn't need to write any yaml.

And yeah, while I've been talking, you can see now we have a red line.

Now just to be clear about why we've got a red line going from this other this other part here.

Well, that's just illustrating that whatever this request is, is resulting in this request.

So obviously, when this error comes back to this position tracker service, the position tracker is, is throwing that back as an error to the caller.

So it's calling, it's causing a chain of failure, basically.

So if I go to the front end, we can demonstrate this now just by selecting any of these vehicles.

And I can tell you that that staff service that we've just shut down is responsible for showing the name of the driver, and the photograph the driver as well.

So we've got a very ugly situation here, we definitely need to improve this, that we've just got a broken image and a question mark.

By the way, just for the course, I also decided in the event of any exceptions arriving on the front end, I do pop up this error, just so we know that it's happening.

The default behaviour in Angular, which I'm using here would just be to log that to the console, kinda then don't know that something's going wrong.

So I thought it might be useful for the course.

Now, whether you find that useful or not, it's entirely down to you.

on all of my projects, the yaml that we write is the single source of truth.

We never ever go into a cluster and start doing kubectl edits and changing any of the pods or services without changing the yaml and committing it to the source repository.

So many of you will be horrified at the idea that with this UI, we can just go in and start making massive changes to our configuration, there's two main uses of this.

And the first use would be in the event of an emergency.

If you really are, you know, you really don't have time to do all of that proper engineering, and you just need to get something modified on the fly while you're diagnosing.

And then of course, when you work out the cause of the problem, you'll back off from this, put things right, and then do everything using proper engineering.

The other big use of this I found is, like we're doing here, we're running on minkube.

So it really doesn't matter if I make some ad hoc changes, you are going to find that the Istio yaml files are not pleasant to work with.

I can't do them from the top of my head, I have to look in the in the in the documentation to understand the YAML structure.

So actually, this could be a pretty clever way of just generating that yaml.

If we go into the service and go show details, what we can do here on these tabs, which have not mentioned before, is we can show the virtual service and the destination role.

So I'll click on virtual service.

Now remember, we haven't yet covered what virtual services are.

So don't worry if you don't understand this.

But I can very helpfully, I can click on that link.

And it will give me a sort of graphical view of what's going on.

Saying that basically, for this service, we're going to have a fault, aborting with 503 100% of the time.

And the YAML, that has been applied to my cluster I can find here.

So that's absolutely brilliant, I could copy and paste that now and use it as a start point for my own yambol.

If I want that to be part of my source code, that's entirely up to you a couple of uses of being able to modify these services on the fly, definitely use with caution, but I wanted to cover it.

Now, of course, I can always, if I right click on the service and go show details.

Again, one of the other actions was to delete all of the traffic routing, I can click on that, and click on Delete.

And that's now got rid of the virtual service and the destination rule.

And that will have applied it to my cluster.

So let's check yet no destination rules, and no virtual services.

And we should find now on the front end, that if I click on one of the vehicles, brilliant, I am now getting staff details return.

So that's superb.

You'll find by the way that these changes are pretty much instantaneous.

Should we demo that, I'll do suspend traffic, I'm going to work as quickly as I can create, switch to the front end, select a vehicle.

And yeah, we're getting the error back on the front end.

Back into here, actions, delete the traffic routing, I won't do a video at it quick as I can delete.

So the front end, select a vehicle and we've got the staff information back again.

So those changes are pretty quick.

I know that will be a massive feature for some of you.

And some of you will be horrified at the thought of doing that.

So that's entirely up to you.

But for me, the most important use of this, I found is by using the service graph or the workload graph so I can get an immediate picture of how my system hangs together, which services are communicating with which other services and I can also see at a glance if there are any errors going on in the application.

So very useful package, and I think possibly worth the cost of Istio on itself.

We do have some more telemetry features coming up though in the next video, we're going to look at distributed tracing, using a tool called Jaeger.

I'll see you for that.

돌아온 걸 환영해

그리고 우리는 키알리를 탐험하고 있습니다.

그리고 저는 정말 힘이 다해서 키알리의 대부분의 관찰 기능을 보여드렸습니다.

그리고 내가 놓쳤던 건, 네가 정말 쉽게 찾을 수 있을 거야.

저는 이것이 모든 쿠베르네츠 건축에서 매우 귀중한 도구라고 생각합니다.

그리고 자주 묻는 질문이 있습니다. 글쎄요, istio는 꽤 복잡합니다. 제 프로젝트에 참여할 만한 가치가 있습니다.

분명히, 그것은 복잡한 질문입니다. 여러분이 Istio로부터 어떤 가치를 얻느냐에 따라 다릅니다.

하지만 저는 거의 이 그래프만으로 Istio를 사용할 수 있다고 주장합니다. 잠재적으로 이것은 논쟁의 여지가 있습니다. 왜냐하면 이 작업을 하기 위해서는, 아시다시피, 프록시를 실행하는 복잡성이 필요하기 때문입니다.

따라서 Istio를 실행하려면 더 많은 시스템 리소스가 필요합니다.

하지만 트래픽 관리, 정책 및 보안은 나중에 진행되지 않더라도 런타임에 동적으로 계산되는 시스템 구조를 관찰할 수 있습니다. 저는 매우 강력하다고 생각합니다.

이것이 바로 관찰가능성에 관한 것입니다.

하지만 이 마지막 비디오인 kiali에서는 응용 프로그램을 실시간으로 동적으로 변경하는 방법에 대해 살펴보겠습니다.

그래서 그것은 꽤 대담한 주장입니다.

이를 설명하기 위해 서비스 그래프를 살펴봤습니다.

이제 코스에서 좀 더 나아가면, 교통 관리에 관한 모든 부분이 나옵니다.

Istio를 사용하면 카나리 릴리스 설정, B 테스트, 심지어 테스트 마이크로 서비스, 프로덕션 클러스터에 배치 등 매우 영리한 작업을 수행할 수 있습니다.

그리고 우리는 그 테스트 서비스를 시스템의 엔지니어들을 제외한 모든 사람들로부터 숨길 수 있습니다. 우리는 그것에 대한 비디오를 가지고 있습니다. 저는 이것을 다크 릴리즈라고 불렀습니다.

이는 스테이징이나 테스트 환경을 위해 필요하지 않다는 것을 의미하기도 합니다.

그래서 그것은 꽤 대담한 주장입니다.

그리고 우리는 분명히 그것에 대해 많은 세부사항이 필요할 것입니다. 그것은 여전히 자체적인 맞춤 구성을 사용하여 YAML을 작성할 것입니다.

이를 완전히 이해하기 위해서는 가상 서비스나 목적지 규칙과 같은 전문 용어를 익혀야 합니다.

그래서 그 모든 것은 나중에 일어날 것입니다. 저는 너무 깊이 들어가고 싶지 않습니다.

하지만 이 그래픽 인터페이스를 통해 이러한 Istio 구성을 변경할 수 있다는 것을 보여드리고 싶습니다.

교통 관리 시스템에 있을 때 반드시 다시 방문하도록 하겠습니다.

하지만 지금은 간단한 데모를 하고 싶습니다.

어떤 이유로든, 여기 직원 서비스에 심각한 문제가 있다고 가정해 봅시다.

미친 듯이 날뛰거나, 클러스터의 모든 CPU를 차지하거나, 자동 확장으로 인해 감당할 수 없는 많은 노드가 회전할 수 있습니다.

아니면 제3자 서비스에 요청을 하는 것일 수도 있습니다.

그리고 그것은 미쳐버렸습니다.

서비스 거부 공격 등의 혐의로 고발될 위험이 있습니다.

제 요점은 이 특별한 서비스에 긴급 상황이 발생했다는 것입니다.

제가 말씀드렸듯이, 이 연결을 끊기 위해 Istioaml을 좀 쓸 수 있습니다. 이 연결을 따라 가는 모든 트래픽을 거부하기 위해서죠.

깍지 떼지 않고도 이 모든 것을 할 수 있습니다.

어떻게 그럴 수 있죠? 글쎄요, 제가 말하듯이 그렇게 하기 위한 구체적인 Istio 구성이 있습니다.

하지만 아직 이러한 구성을 배우지 못했습니다.

하지만 나는 단지 증명하기 위해 사령부로 갈 것이다.

내가 이 기능을 말하듯이, 이러한 트래픽 관리 기능은 가상 서비스라고 불리는 Istio가 제공하는 Kubernetes 객체에 의해 구현된다.

그래서 제가 kubectl을 한다면, 가상 서비스를 받을 수 있고 자원을 찾을 수 없습니다.

당신은 vs kubectl get vs를 통해 그것을 줄일 수 있다.

제가 여기서 보여드리고 싶은 것은 이런 구성을 여러분 등 뒤에서 놓쳐본 적이 없다는 것입니다.

우리가 함께 일해 온 소금은 서비스와 부품의 일반적인 작업 부하에 불과합니다.

Istio에는 목적지 규칙인 디아즈도 몇 명 있습니다. 그리고 저는 그 일을 직접 할 것입니다.

나는 단지 여기서 우리가 아이스티오 교통 관리를 하고 있지 않다는 것을 증명하고 있다.

하지만 제가 여기서 보여드리는 것은 아주 쉽게 종료할 수 있는 서비스입니다. 이 서비스를 마우스 오른쪽 단추로 클릭해서 세부 정보를 보여드릴 수 있습니다. 전에 했던 것처럼요. 꽤 높은 수준의 스킬이 있다는 것을 인정해야겠네요. 저는 키알을 사용하는 것조차 오랫동안 알아차리지 못했습니다.

여기에 Actions 버튼이 있습니다.

이러한 작업을 통해 가중 라우팅 또는 라우팅 생성, 일치, 라우팅 또는 라우팅 생성, 트래픽 일시 중단 등을 수행할 수 있습니다.

내가 말했듯이 그것은 Istioyaml에 의해 행해졌다.

하지만 이 버튼들은 야멜을 생성해 자동으로 적용됩니다.

물론, 저는 이 모든 가중되고 일치하는 비즈니스에 대해 이야기해야 할 필요가 있습니다.

이 데모에서는 트래픽 일시 중단이라는 간단한 옵션을 살펴보겠습니다.

클릭해 보겠습니다.

트래픽 관리에서 이 문제를 좀 더 자세히 살펴보면, 여기에는 다양한 옵션이 있습니다.

그러나 트래픽을 일시 중단하려면 프로덕션 시스템에서 작업을 수행할 때 매우 주의해야 합니다.를 클릭하기만 하면 됩니다.

그래프로 가보겠습니다.

그리고 저는 이 실시간 그래프에서 몇 가지 변화를 기대하겠습니다.

첫 번째 변경 사항은 서비스 옆에 작은 아이콘이 있다는 것입니다. 일종의 철도 아이콘입니다. 서비스에 어떤 라우팅이나 라우팅이 적용되어 있다는 것을 보여줍니다.

나는 시간을 두고 놀고 있어, 거기서 변화를 기다리고 있어.

사실, 제 명령어로 돌아가보면, 지금 제가 명령한 명령들을 보여드리고 싶습니다. 제가 가상 서비스를 받는다면, 플리트먼 직원 서비스를 받을 수 있다는 것 말고는 아무것도 하지 않았습니다.

목적지를 찾는 규칙을 반복하면, 네, 목적지 규칙도 있습니다.

그래서 마법도 좀 걸렸고, 얌 파일도 만들어졌고, 클러스터에 적용되었죠. 저는 얌을 쓸 필요가 없었습니다.

네, 제가 얘기한 동안 빨간 줄이 생겼다는 걸 보실 수 있습니다.

여기서 다른 부분으로부터 빨간색 선을 긋는 이유를 확실히 짚고 넘어가겠습니다.

음, 그건 단지 이 요청이 어떤 것이든 간에, 이 요청을 초래한다는 것을 보여주는 것입니다.

분명히, 이 오류가 위치 추적기 서비스로 되돌아 올 때 위치 추적기는 그 오류를 발신자에게 다시 던집니다.

그래서 그것은 기본적으로 연쇄적인 실패를 야기하고 있습니다.

그래서 제가 프런트 엔드로 간다면, 우리는 이 차량들 중 아무거나 선택해서 지금 이것을 증명할 수 있습니다.

그리고 방금 종료한 직원 서비스는 운전기사의 이름과 사진을 보여주는 역할도 담당한다고 말씀드릴 수 있습니다.

그래서 우리는 매우 추악한 상황에 처해 있습니다. 우리는 분명히 이것을 개선할 필요가 있습니다. 우리는 단지 부러진 이미지와 물음표를 가지고 있습니다.

그건 그렇고, 코스의 경우, 저는 프런트 엔드에 어떤 예외도 있을 경우 이 오류를 발생시키기로 결정했습니다. 우리는 이 오류가 발생했다는 것을 알 수 있습니다.

Angular(각각)의 기본 동작은 콘솔에 기록해서 뭔가 잘못되고 있다는 것을 모르는 것입니다.

그래서 코스에 도움이 될 것 같아서요.

그게 유용하든 그렇지 않든 그건 전적으로 당신에게 달렸어요.

내 모든 프로젝트에서 우리가 쓰는 얌은 진실의 유일한 원천이야

우리는 결코 클러스터에 들어가 yaml을 변경하지 않고 소스 저장소에 커밋하지 않고 어떤 포드나 서비스라도 변경하기 시작하지 않습니다.

여러분 중 많은 분들이 이 UI를 사용하면 구성을 크게 변경할 수 있다는 생각에 놀라실 것입니다. 여기에는 두 가지 주요 용도가 있습니다.

그리고 첫 번째 용도는 응급상황이 발생했을 때 사용할 수 있습니다.

만약 여러분이 정말 그런 모든 적절한 엔지니어링을 할 시간이 없다면, 진단하는 동안 당장 무언가를 수정하기만 하면 됩니다.

그리고 물론, 문제의 원인을 알아낼 때, 여러분은 이 문제에서 물러나, 일을 바로잡고, 적절한 엔지니어링을 사용하여 모든 것을 할 것입니다.

제가 발견한 또 다른 큰 용도는, 우리가 여기서 하는 것처럼, 우리는 밍큐브를 타고 달리고 있다는 것입니다.

따라서 제가 특별히 변경해도 상관없습니다. Istioaml 파일은 작업하기에 좋지 않습니다.

저는 그것을 머리 위에서 할 수 없고, YAML 구조를 이해하기 위해 문서의 안을 들여다봐야 합니다.

그래서 사실, 이것은 단지 야멜을 생산하는 아주 영리한 방법이 될 수 있습니다.

서비스에 들어가서 세부 정보를 표시하면 이전에 언급하지 않았던 이러한 탭에서 가상 서비스와 대상 역할을 표시할 수 있습니다.

가상 서비스를 클릭하겠습니다.

가상 서비스가 무엇인지에 대해서는 아직 다루지 않았습니다.

그러니 이것을 이해하지 못하더라도 걱정하지 마세요.

하지만 아주 유용하게 링크를 클릭할 수 있습니다.

그리고 그것은 제게 무슨 일이 일어나고 있는지 그래픽으로 볼 수 있게 해 줄 것입니다.

말하자면, 이 서비스의 경우, 고장이 발생하게 됩니다. 503 100%로 중단됩니다.

YAML은 제 클러스터에 적용되었습니다. 여기서 찾을 수 있습니다.

아주 훌륭합니다. 지금 복사해서 붙여 넣을 수 있고, 제 얌볼의 시작점으로 사용할 수 있습니다.

만약 제가 그것이 제 소스 코드의 일부이기를 원한다면, 그것은 전적으로 여러분에게 달려있습니다. 즉, 이러한 서비스를 즉시 수정할 수 있는 몇 가지 용도는 물론, 주의해서 사용하지만, 저는 그것을 다루고 싶었습니다.

물론, 서비스를 마우스 오른쪽 버튼으로 클릭하고 세부 정보를 표시하면 언제든지 가능합니다.

다른 작업 중 하나는 트래픽 라우팅을 모두 삭제하는 것이었습니다. 이 작업을 클릭하고 삭제를 클릭합니다.

이제 가상 서비스와 대상 규칙이 제거됩니다.

그리고 그것은 그것을 제 클러스터에 적용시킬 것입니다.

이제 대상 규칙이나 가상 서비스는 없는지 확인해 보겠습니다.

이제 앞쪽에서 차량 중 하나를 클릭하면 직원의 세부 정보가 반환된다는 것을 알아내야 합니다.

정말 훌륭하군요.

그런데 이런 변화들은 거의 순간적이라는 것을 알게 되실 겁니다.

제가 교통정지를 할 수 있다면 최대한 빨리 일을 하고, 프론트 엔드로 전환하고, 차량을 선택하겠습니다.

그리고 네, 프런트 엔드에서 오류가 다시 발생하고 있습니다.

여기서 다시, 액션, 트래픽 라우팅 삭제, 삭제할 수 있는 것처럼 빨리 비디오를 만들지 않겠습니다.

앞쪽에서 차량을 선택하면 직원 정보가 다시 표시됩니다.

그래서 이런 변화들은 꽤 빨랐습니다.

나는 그것이 여러분 중 몇몇에게 큰 특징이 될 것이라는 것을 안다.

그리고 여러분 중 몇몇은 그렇게 하는 것을 생각하면 소름이 끼칠 것입니다.

그러니까 그건 전적으로 당신에게 달렸어요.

하지만 제가 발견한 가장 중요한 용도는 서비스 그래프나 작업량 그래프를 통해 시스템이 어떻게 연동되는지, 어떤 서비스가 다른 서비스와 통신하는지, 그리고 애플리케이션에 오류가 있는지 한눈에 볼 수 있다는 것입니다.

매우 유용한 패키지입니다. 그리고 아마도 아이스티온의 비용만큼의 가치가 있다고 생각합니다.

다음 비디오에서는 Jaeger라는 도구를 사용하여 분산 추적을 살펴보겠습니다.

그 일로 뵙겠습니다.