07. Hands on Demo - Visualizing the System with Kiali

So welcome back.

And in the previous video, the very important step of labelling the namespace that you want Istio to automatically inject those proxies or side cars into your pods.

Without that label, you're not going to get a proxy, you won't see any data when we start doing our diagnostics.

So with that job out of the way, we can now go ahead and finally, the actual applications yaml file.

So this should be simple, then kubectl, apply dash F on the file for application full stack dot yaml.

Now in this system, if I do a kubectl, get po.

And again, for the video, I'll put a watch on that it doesn't matter.

If you're not able to do that, you should see seven pods starting up and can you see I might need to do a freeze frame here.

But can you see that the pots are going through some kind of initialization process, I don't know if you're familiar with in its containers, but an empty container is where a container runs before the main container starts.

And that's because Istio needs to do some setup.

And also a crucial difference that you'll notice is that all of the pods here have two containers inside them, not one.

Even though if you inspect the YAML, I won't bother for the video.

But if you do look in the yaml, I only have a single container defined inside the well, you know what's going on.

Now, you know that Istio is automatically injecting that additional sidecar container, which is going to work as the proxy here.

If you're if you're seeing the number one here, on the second number, you've probably forgotten to label the namespace.

So go back a video and make sure you do that labelling.

Now these seven parts are going to take a while to start up.

This is useful actually, just while I've been talking, I am seeing an error coming back from the server.

Don't be surprised when this happens to you.

It's simply because I really am pushing mini cube here and when there's getting some really horrible errors here.

But when the mini cube cluster is under pressure, and we're doing major changes to it, occasionally you will lose access to the kubectl command.

My recommendation here is you just wait a bit, let things settle down.

I'm going to go for a break now.

And I'm thinking in five minutes time, I will expect to see all seven parts correctly up and running.

Let's hope that's the case.

I'll stop recording now.

And it took about two and a half minutes for me before all of the parts are showing to have to in the status of running.

Don't worry if it takes longer for you.

And as I say Don't worry if you do get some kubectl errors along the way.

Basically, the Istio proxies do some quite heavy work on that startup and it can stress mini cube.

Just while things are starting up.

I know I've said this before, but just to underline, we're using minkube here for the demos.

But you shouldn't expect minkube to give you production standard performance by any means.

Now the apps up and running, I think it's worth showing you the application in action.

So I'll show you the front end of this system.

If you do a minkube IP to find your IP address that you need to work with.

Remember, this is different every time you start a new minkube cluster.

So do check that IP address.

And if you visit that address colon 30,080.

I've set up a node port on that particular port that should allow you to access the front end of this application.

It's a fleet management system, I think there are five vehicles that are being tracked by this system.

The idea is that there are GPS messages being sent to our system by remote vehicles.

And when we receive an update for a vehicle that vehicle moves on the map.

As I say some of you will be familiar with an earlier version of this, but some of you will not.

And there is quite a big problem with this system.

A one might not be immediately obvious, but this just isn't working properly.

It's not working properly, because vehicles are simply not updating and the period that they're supposed to be.

I know for a fact that for example, this city truck should be going at about 1520 miles an hour or something like that.

On average, we get a new report for a vehicle about every five seconds, five to 10 seconds, something like that.

I'm not doing any video editing here, but I'm following the city truck.

And I don't have specific timings on this but was simply not a report just came in there for this vehicle here.

But the other vehicles appear to be pretty stale.

There's some sort of bottleneck going on here in this system.

So a bug report has been raised and it's our job to find Find out what the problem is.

And if we can to fix it.

Before we do that, let's have a little click around, you can click on any of these vehicles and the information window down at the bottom here should give you information about that vehicle, such as its last position, the name of the driver.

And there should also be a staff photograph of that driver, as well.

And yeah, as I say, you wouldn't know this if you haven't worked on the system before.

But it should be a lot more responsive than this.

These vehicles are really, really crawling along, I haven't seen any of the vehicles go above 10 miles per hour, it would normally be quite a bit faster than that on an open road.

This is very daunting given that it's, it's very hard to diagnose problem, it's obviously some kind of bottleneck that's going on here.

If you refresh this app, really what should happen on refreshes within a few seconds, you should get all of the vehicles appearing on the left hand side within a few seconds, because it's it's when the next report comes in for that vehicle, it gets added to the list.

But after refreshing, we're having to wait minutes.

So I really don't know where to start, if we do a kubectl get p o Of course on this system, we only have seven pods.

But in a real system, you would have dozens, hundreds, maybe even 1000s of pots to work through.

But I think even with seven pots, it's arguable that this is going to be a very difficult problem to trace.

I could I guess look at the logs of all of these microservices.

But there's a very good chance that this problem, it may well be a network problem or something it might not even be obvious from looking at the logs, or even looking at the code what's going on.

But also we have the problem that when you to this project, remember, and I don't even know how these things connect together, I don't know in what order they're being called, I don't know where the problem is even likely to be.

So it's time to finally cut to the chase and show you just one of the tools that Istio ships with that can help us diagnose this kind of problem.

It's just one of them.

And through the rest of the course we'll be picking up everything else.

But if we have a look in the Istio namespace at the pods in there, one of those control plane components is this one here called key Olli.

And you'll also find if we do a get SPC on that namespace, there is a corresponding service for it here.

And in preparation for this course, I've set this up as a node port running on port 31,000.

So that means you can visit your minikube IP address, colon 31,000.

So I visited that IP address colon 31,000.

And it's redirected me to this overview page here.

And we'll be having a look at the details of what all of this information means in a short while.

But as a start points, I think we're going to have a quick look at the documentation field for kiali.

And you can find that through the icon here the question mark, and there's a link to the documentation right there.

The points of kiali.

And I love the way their sales pitch here really says it better than I can really so I'm just going to read it out.

Keolis job is to tell you what microservices are part of your Istio service mesh is going to tell us how they're connected.

And it's going to tell us how they're performing.

Now, that's a very exciting prospect given that we don't know much about the system yet.

So we'll drop onto this dashboard, which is giving us the overall health of the application.

Now it's divided into two.

That's the two namespaces that we have.

One of which is the Istio system namespace.

Now we're going to assume that's presumably working as it should be.

So we won't worry about that too much.

But we also have a dashboard for the default namespace.

Now the system that we're working on is a pretty dynamic system.

And you may not see the same information that I'm seeing here on the video, I am seeing that there is a one service here in the seven because some applications applications just means pods really, it's telling us that one of the pods is degraded and six pods are showing healthy.

Don't be surprised if in your application, you are seeing seven healthy pots that's perfectly possible.

As I say this is a dynamic system.

So you might need to wait a bit to get the information that you need.

Now, okay, well where do we start here well, and let's go straight to the graph link on the left hand side and you may need to drop that The list here on the top left and tick the default namespace.

I think that's ticked for me because I've been practising off camera.

But if you're not seeing anything, then click here and tick the default namespace, make sure the Istio system is unchecked, because that would just, that would just really clog everything up.

And I'm currently looking at the versioned app graph, which I think is the default.

So just make sure that you're on that as well.

And this, I think, is absolutely wonderful.

What we're seeing here is a graph of all of our micro services, I should really say all of our pods and services.

And it's also showing us how they're all connected together.

So if you're in a particularly complex part of your architecture, and you really can't get your head around how things are working, then this is a great starting point.

Now I'm going to great detail about this, because we do have a whole section on kiali.

Coming up later in the course I kind of want to, I want to keep some things in reserve really.

But I am going to just suggest we this is quite an expanded graph, it's probably a bit easier to understand if you drop down this list and go to the service graph.

As you can see, it's a little bit of a smaller chart.

Now the way that this graph has been built is Istio is gathering data constantly based on what it sees going through the service mesh, and it's collating that data together.

But I have to be really clear here that this is a very dynamic picture that we're seeing if your top left here, this is really important.

What we're seeing here is the data that's been gathered together over the last for me five minutes, but you can alter this to go back over a longer time window.

Now, what I mean by that is, if you're only looking at the last minute, and maybe you've not done anything with the system, maybe no requests have come in over the last minute, then you'll get a blank graph here.

And then if you go to the front page, and then refresh it, you'll start to see requests going through.

I don't know if you've noticed, but when I had it on the five minutes, I'm getting a big red line between this service here and this service here.

But if I switch to one minute, and previously over the minute window that was showing the green line, but now even on the one minute window, it has switched to a red line.

So I'm just trying to be clear here that you might not see the same as meet up surprise, if you're seeing the green line, at least temporarily, at least for a short period.

But clearly, there's something wrong here between this service call staff service, and this service called Fleetman.

Driver monitoring.

And if I click on the line, it will give me a chart here showing me that for me, and it are good.

I'm glad that's happened, just while I was talking there, there was an automatic refresh, and it is now showing that 100% of the requests have returned.

Okay.

So you might have thought just looking at that, that everything's okay.

But yeah, clearly over the last five minutes, it looks like 50% of the requests have been okay, 50% of the requests have been in error.

Clearly, there's something wrong here.

And although it looked like if I go back to the overview, it is saying that the staff services degraded, I'm beginning to think now that the staff services, okay, the staff service, though, is calling this service called driver monitoring.

And that is somehow failing, or it's clearly not working very well.

And that's making it look like the staff services having problems.

That's just my first thought.

But without this graph, I wouldn't have known anything about this system.

So this is wonderful, even without having any great knowledge of the system.

I'm able to visualise the system and see how it's hanging together.

And I now have a very clear clue that the problem is either with this staff service, or with this Fleetman driver monitoring.

My might not be it might be caused by something weird going on over here.

But certainly this area is deeply suspicious.

I don't want to spend too long on this demo, I just want to give you a flavour and later on in the course, we will look in more detail at kiali.

And look at all of the other tabs and so on.

But before I move on, I do want to get a better clue as to what's going on here.

And you might just be able to notice that the symbol here is different to this symbol here.

What's going on? Well, there is a button down here at the bottom for legend.

And that will give you the key to what the symbols mean.

The triangles which is most stuff this graph is a service.

That's a regular service that you're familiar with.

in Kubernetes, if you do kubectl, get SVC.

The triangles are what you're seeing there.

This symbol here is different.

It's this here, it's for a service entry.

Now server century is in fact an Istio specific concepts.

And we will be looking in detail at service entries.

Later on in the course we have a section on calling external services.

That's really what this is, in fact, it's not part of our Kubernetes cluster.

It's some URL that we are calling that is not part of our cluster.

So the fact that this is external is perhaps giving yet another clue as to what the source of this problem is.

So we've got some clues, but I think we need to drill a little further.

So in the next video, I'll show you how we can look in a bit more detail at what's going on between these two services.

다시 오신 것을 환영합니다.

그리고 이전 비디오에서 Istio가 해당 프록시 또는 사이드카를 포드에 자동으로 삽입하도록하려는 네임 스페이스에 레이블을 지정하는 매우 중요한 단계입니다.

이 레이블이 없으면 프록시를 얻을 수 없으며 진단을 시작할 때 데이터를 볼 수 없습니다.

따라서 그 작업이 중단되면 이제 실제 애플리케이션 yaml 파일을 계속 진행할 수 있습니다.

따라서 이것은 간단해야합니다. 그런 다음 kubectl은 응용 프로그램 전체 스택 점 yaml의 파일에 대시 F를 적용합니다.

이제이 시스템에서 kubectl을 수행하면 po를 얻습니다.

그리고 다시, 비디오의 경우 중요하지 않은 시계를 놓을 것입니다.

그렇게 할 수 없다면 7 개의 포드가 시작되는 것을 볼 수 있으며 여기서 고정 프레임을 수행해야 할 수도 있습니다.

하지만 팟이 일종의 초기화 프로세스를 거치고 있음을 알 수 있습니다. 컨테이너에 익숙한 지 모르겠지만 빈 컨테이너는 기본 컨테이너가 시작되기 전에 컨테이너가 실행되는 곳입니다.

Istio가 몇 가지 설정을해야하기 때문입니다.

또한 눈에 띄는 중요한 차이점은 여기에있는 모든 포드에는 하나가 아닌 두 개의 컨테이너가 있다는 것입니다.

YAML을 살펴 보더라도 비디오는 신경 쓰지 않을 것입니다.

하지만 yaml을 살펴보면 우물 안에 정의 된 단일 컨테이너 만 있습니다. 무슨 일이 일어나는지 알 것입니다.

이제 Istio가 여기에서 프록시로 작동 할 추가 사이드카 컨테이너를 자동으로 주입한다는 것을 알고 있습니다.

두 번째 숫자에서 1 번을 본다면 네임 스페이스에 레이블을 지정하는 것을 잊었을 것입니다.

그러니 비디오로 돌아가서 라벨링을했는지 확인하십시오.

이제이 7 가지 부분은 시작하는 데 시간이 걸립니다.

이것은 실제로 유용합니다. 제가 이야기하는 동안 서버에서 오류가 다시 발생하는 것을보고 있습니다.

이런 일이 발생하더라도 놀라지 마십시오.

그것은 내가 정말로 여기에 미니 큐브를 밀고 있고 여기에 정말 끔찍한 오류가 발생했기 때문입니다.

그러나 미니 큐브 클러스터에 압력이 가해 져서 주요 변경 작업을 수행하는 경우 때때로 kubectl 명령에 대한 액세스 권한을 잃게됩니다.

여기서 제 추천은 조금만 기다리세요.

이제 휴식을 취하겠습니다.

그리고 저는 5 분 안에 7 개의 부품이 모두 올바르게 작동하는 것을 볼 수있을 것이라고 생각하고 있습니다.

그럴 수 있기를 바랍니다.

이제 녹음을 중지하겠습니다.

그리고 모든 부품이 실행 상태로 표시되기까지 약 2 분 30 초가 걸렸습니다.

시간이 오래 걸리더라도 걱정하지 마십시오.

그리고 내가 말했듯이 도중에 kubectl 오류가 발생하더라도 걱정하지 마십시오.

기본적으로 Istio 프록시는 해당 시작에서 상당히 무거운 작업을 수행하며 미니 큐브에 스트레스를 줄 수 있습니다.

일이 시작되는 동안.

나는 전에 이것을 말했지만 밑줄을 긋기 위해 여기에서 데모를 위해 minkube를 사용하고 있습니다.

그러나 minkube가 어떤 방식 으로든 생산 표준 성능을 제공한다고 기 대해서는 안됩니다.

이제 앱이 실행 중이므로 실제 애플리케이션을 보여줄 가치가 있다고 생각합니다.

이 시스템의 프론트 엔드를 보여 드리겠습니다.

minkube IP를 사용하여 작업해야하는 IP 주소를 찾는 경우.

새 minkube 클러스터를 시작할 때마다 다릅니다.

따라서 해당 IP 주소를 확인하십시오.

그리고 그 주소 콜론 30,080을 방문하면.

이 애플리케이션의 프런트 엔드에 액세스 할 수 있도록 특정 포트에 노드 포트를 설정했습니다.

이것은 함대 관리 시스템입니다.이 시스템에 의해 추적되는 차량이 5 대라고 생각합니다.

아이디어는 원격 차량에 의해 우리 시스템으로 전송되는 GPS 메시지가 있다는 것입니다.

그리고 우리가 차량에 대한 업데이트를 받으면 해당 차량이지도에서 이동합니다.

내가 말했듯이 여러분 중 일부는 이전 버전에 익숙 할 것이지만 일부는 그렇지 않습니다.

그리고이 시스템에는 상당히 큰 문제가 있습니다.

하나는 즉시 명확하지 않을 수도 있지만 제대로 작동하지 않습니다.

차량이 단순히 업데이트되지 않고 있어야하는 기간이기 때문에 제대로 작동하지 않습니다.

예를 들어,이 도시 트럭은 시속 1520 마일 정도의 속도로 주행해야한다는 사실을 알고 있습니다.

평균적으로 우리는 약 5 초, 5-10 초마다 차량에 대한 새로운 보고서를받습니다.

저는 여기서 비디오 편집을하지 않지만 도시 트럭을 따라 가고 있습니다.

그리고 나는 이것에 대한 구체적인 타이밍을 가지고 있지 않지만 단순히 여기에이 차량에 대한 보고서가 들어오지 않았습니다.

그러나 다른 차량은 상당히 오래된 것 같습니다.

이 시스템에서 일종의 병목 현상이 일어나고 있습니다.

따라서 버그 보고서가 제기되었으며 문제가 무엇인지 알아내는 것이 우리의 임무입니다.

그리고 우리가 그것을 고칠 수 있다면.

그 전에 약간의 클릭을합시다.이 차량들 중 하나를 클릭하면 여기 아래에있는 정보 창에 마지막 위치, 운전자 이름과 같은 해당 차량에 대한 정보가 표시됩니다.

또한 그 운전자의 직원 사진도 있어야합니다.

그리고 예, 제가 말했듯이 이전에 시스템에서 작업 한 적이 없다면 이것을 모를 것입니다.

그러나 이것보다 훨씬 더 반응이 좋습니다.

이 차량들은 정말로, 정말로 기어 가고 있습니다. 나는 어떤 차량도 시속 10 마일 이상으로가는 것을 본 적이 없습니다. 그것은 일반적으로 열린 도로에서보다 상당히 빠를 것입니다.

이것은 문제를 진단하기가 매우 어렵고 여기에서 벌어지고있는 일종의 병목 현상이라는 점을 감안할 때 매우 벅찬 일입니다.

이 앱을 새로 고침하면 몇 초 안에 새로 고침 할 때 어떤 일이 일어나야하는지 몇 초 안에 모든 차량이 왼쪽에 나타나야합니다. 그 차량에 대한 다음 보고서가 들어올 때이기 때문입니다. 목록에 추가되었습니다.

하지만 상쾌한 후에는 몇 분을 기다려야합니다.

그래서 저는 정말로 어디서부터 시작해야할지 모르겠습니다. kubectl get p o를하면 당연히이 시스템에는 7 개의 포드 만 있습니다.

그러나 실제 시스템에서는 수십, 수백, 어쩌면 1000 개의 냄비를 처리해야합니다.

그러나 나는 7 개의 냄비를 가지고 있어도 이것이 추적하기 매우 어려운 문제가 될 것이라고 생각한다.

이 모든 마이크로 서비스의 로그를 살펴볼 수 있습니다.

그러나이 문제는 네트워크 문제 일 수도 있고 로그를 보거나 코드에서 무슨 일이 일어나고 있는지조차도 명확하지 않을 수도 있습니다.

그러나 또한 우리는 당신이이 프로젝트에 참여할 때, 기억하세요. 그리고 저는 이러한 것들이 어떻게 연결되는지조차 모릅니다. 어떤 순서로 호출되는지 모르겠습니다. 문제가 어디인지 모르겠습니다. 그럴 가능성도 있습니다.

이제 마침내 추격을 시작하고 Istio가 제공하는 이러한 종류의 문제를 진단하는 데 도움이 될 수있는 도구 중 하나만 보여줄 때입니다.

그 중 하나 일뿐입니다.

나머지 과정 동안 우리는 다른 모든 것을 다룰 것입니다.

하지만 거기에있는 포드에서 Istio 네임 스페이스를 살펴보면 이러한 컨트롤 플레인 구성 요소 중 하나가 여기에서 키 Olli라고하는 것입니다.

또한 해당 네임 스페이스에서 SPC 가져 오기를 수행하면 여기에 해당 서비스가 있음을 알 수 있습니다.

이 과정을 준비하기 위해 포트 31,000에서 실행되는 노드 포트로 설정했습니다.

즉, minikube IP 주소 인 콜론 31,000을 방문 할 수 있습니다.

그래서 그 IP 주소 콜론 31,000을 방문했습니다.

여기에있는이 개요 페이지로 리디렉션됩니다.

그리고 우리는이 모든 정보가 의미하는 바에 대해 잠시 후에 자세히 살펴볼 것입니다.

하지만 시작점으로 kiali에 대한 문서 필드를 빠르게 살펴볼 것입니다.

여기 아이콘을 통해 물음표와 문서 링크가 바로 거기에 있음을 알 수 있습니다.

키 알리의 요점.

그리고 저는 그들의 판매 피치가 제가 할 수있는 것보다 더 잘 말하는 방식을 좋아합니다. 그래서 저는 그것을 읽어 보려고합니다.

Keolis의 임무는 Istio 서비스 메시의 일부인 마이크로 서비스가 연결 방식을 알려주는 것입니다.

그리고 그들이 어떻게 수행하고 있는지 알려줄 것입니다.

이제 우리가 아직 시스템에 대해 많이 알지 못한다는 점을 감안할 때 매우 흥미로운 전망입니다.

따라서이 대시 보드로 이동하여 애플리케이션의 전반적인 상태를 확인합니다.

이제 두 개로 나뉩니다.

이것이 우리가 가진 두 개의 네임 스페이스입니다.

그중 하나는 Istio 시스템 네임 스페이스입니다.

이제 우리는 그것이 예상대로 작동한다고 가정 할 것입니다.

그래서 우리는 그것에 대해 너무 걱정하지 않을 것입니다.

그러나 기본 네임 스페이스에 대한 대시 보드도 있습니다.

이제 우리가 작업하고있는 시스템은 매우 역동적 인 시스템입니다.

여기 비디오에서 볼 수있는 것과 동일한 정보가 표시되지 않을 수 있습니다. 일부 응용 프로그램 응용 프로그램은 실제로 포드를 의미하기 때문에 여기에 하나의 서비스가 있다는 것을 알 수 있습니다. 포드 중 하나가 성능이 저하되었음을 알려줍니다. 6 개의 포드가 건강하게 보입니다.

응용 프로그램에서 완벽하게 가능한 7 개의 건강한 냄비를보고 있다고해서 놀라지 마십시오.

내가 말했듯이 이것은 동적 시스템입니다.

따라서 필요한 정보를 얻으려면 조금 기다려야 할 수도 있습니다.

자, 그럼 여기서부터 시작하겠습니다. 왼쪽에있는 그래프 링크로 바로 이동하겠습니다. 왼쪽 상단에 목록을 드롭하고 기본 네임 스페이스를 선택해야 할 수도 있습니다.

카메라 밖에서 연습을 해왔 기 때문에 그게 틱한 것 같아요.

그러나 아무것도 표시되지 않으면 여기를 클릭하고 기본 네임 스페이스를 선택하고 Istio 시스템이 선택 해제되어 있는지 확인하십시오. 그렇게하면 모든 것을 막을 수 있습니다.

현재 버전이 지정된 앱 그래프를보고 있는데, 이것이 기본값이라고 생각합니다.

그러니 당신도 그렇게하고 있는지 확인하십시오.

제 생각에 이것은 정말 훌륭합니다.

여기서 우리가보고있는 것은 우리의 모든 마이크로 서비스의 그래프입니다. 우리의 모든 pod와 서비스를 말해야합니다.

또한 이들이 모두 어떻게 연결되어 있는지 보여줍니다.

따라서 아키텍처의 특히 복잡한 부분에 있고 실제로 작동 방식을 이해할 수 없다면 이것이 훌륭한 출발점입니다.

이제 kiali에 대한 전체 섹션이 있기 때문에 이에 대해 자세히 설명하겠습니다.

나중에 제가 원하는 코스의 후반부에 올라 오는데, 저는 정말로 일부를 비축 해두고 싶습니다.

그러나 저는 이것이 상당히 확장 된 그래프라고 제안 할 것입니다.이 목록을 드롭 다운하고 서비스 그래프로 이동하면 이해하기가 더 쉬울 것입니다.

보시다시피 조금 작은 차트입니다.

이제이 그래프가 구축 된 방식은 Istio가 서비스 메시를 통과하는 것을 기반으로 지속적으로 데이터를 수집하고 해당 데이터를 함께 수집하는 것입니다.

하지만 여기에서 여러분의 상단이 여기 왼쪽에 있다면 이것이 매우 역동적 인 그림이라는 것을 분명히해야합니다. 이것은 정말 중요합니다.

여기서 우리가보고있는 것은 지난 5 분 동안 함께 수집 된 데이터입니다.하지만이 데이터를 변경하여 더 긴 시간을 거슬러 올라갈 수 있습니다.

제가 의미하는 바는, 마지막 순간 만보고 있고 시스템에 아무 작업도하지 않았을 수도 있고, 마지막 순간에 요청이 들어오지 않았을 수도 있다는 것입니다. 그러면 공백이 표시됩니다. 여기 그래프.

그런 다음 첫 페이지로 이동하여 새로 고치면 요청이 진행되는 것을 볼 수 있습니다.

눈치 채 셨는지 모르겠지만 5 분 만에 여기에있는이 서비스와 여기에있는이 서비스 사이에 큰 빨간색 선이 생겼습니다.

하지만 1 분으로 전환하면 이전에는 녹색 선이 표시된 분 창을 넘었지만 지금은 1 분 창에서도 빨간색 선으로 전환되었습니다.

그래서 저는 여기서 당신이 깜짝 만남과 똑같은 것을 보지 못할 수도 있다는 것을 분명히하려고합니다. 만약 당신이 적어도 일시적으로, 적어도 짧은 기간 동안 녹색 선을보고 있다면.

하지만 분명히이 서비스 콜 직원 서비스와 Fleetman이라는 서비스 사이에 뭔가 잘못된 것이 있습니다.

운전자 모니터링.

그리고 선을 클릭하면 여기에 차트가 표시됩니다.

그 일이 일어나서 기쁩니다. 제가 그곳에서 이야기하는 동안 자동 새로 고침이 있었고 이제 요청의 100 %가 반환되었음을 보여줍니다.

괜찮아.

그래서 당신은 그것을보고 모든 것이 괜찮다고 생각했을 것입니다.

하지만 예, 지난 5 분 동안 분명히 요청의 50 %는 괜찮은 것 같고 요청의 50 %는 오류가있는 것 같습니다.

분명히 여기에 뭔가 잘못된 것이 있습니다.

개요로 돌아가 보면 직원 서비스가 저하 된 것 같았지만 직원 서비스, 그래도 직원 서비스가이 서비스를 운전자 모니터링이라고 부르고 있다고 생각하기 시작했습니다.

그리고 그것은 어떻게 든 실패하거나 분명히 잘 작동하지 않습니다.

그리고 그것은 직원 서비스에 문제가있는 것처럼 보이게합니다.

그것은 내 첫 번째 생각입니다.

하지만이 그래프가 없었다면이 시스템에 대해 알 수 없었을 것입니다.

따라서 이것은 시스템에 대한 큰 지식이 없어도 훌륭합니다.

나는 시스템을 시각화하고 그것이 어떻게 함께 매달려 있는지 볼 수 있습니다.

그리고 이제 문제가이 직원 서비스 나이 Fleetman 운전자 모니터링에 문제가 있다는 매우 명확한 단서를 얻었습니다.

여기에서 이상한 일이 벌어지고있는 것이 아닐 수도 있습니다.

그러나 확실히이 영역은 매우 의심 스럽습니다.

이 데모에 너무 오래 쓰고 싶지는 않습니다. 여러분에게 맛을 알려 드리고자합니다. 나중에는 kiali에 대해 자세히 살펴 보겠습니다.

그리고 다른 모든 탭 등을 살펴보십시오.

하지만 계속 진행하기 전에 여기서 무슨 일이 일어나고 있는지 더 잘 알고 싶습니다.

그리고 여기에있는 기호가 여기에있는이 기호와 다르다는 것을 알 수있을 것입니다.

무슨 일이야? 음, 여기 하단에 전설 버튼이 있습니다.

그리고 그것은 상징이 의미하는 바에 대한 열쇠를 줄 것입니다.

이 그래프에서 가장 중요한 삼각형은 서비스입니다.

익숙한 정규 서비스입니다.

Kubernetes에서 kubectl을 수행하는 경우 SVC를 가져옵니다.

삼각형은 여러분이 거기에서보고있는 것입니다.

여기이 기호는 다릅니다.

여기는 서비스 항목 용입니다.

이제 서버 세기는 사실 Istio 특정 개념입니다.

그리고 우리는 서비스 항목에 대해 자세히 살펴볼 것입니다.

과정 후반에 외부 서비스 호출에 대한 섹션이 있습니다.

이것이 바로 이것이 우리 Kubernetes 클러스터의 일부가 아닙니다.

클러스터의 일부가 아닌 우리가 호출하는 일부 URL입니다.

따라서 이것이 외부 적이라는 사실은 아마도이 문제의 원인에 대한 또 다른 단서를 제공 할 것입니다.

그래서 우리는 몇 가지 단서를 얻었지만 조금 더 드릴 필요가 있다고 생각합니다.

그래서 다음 비디오에서는이 두 서비스 사이에 무슨 일이 일어나는지 좀 더 자세히 살펴볼 수있는 방법을 보여 드리겠습니다.