12. Telemetry - Starting the Demo System

Welcome back.

And this is the start of part two of the course.

Part One was about setting the scene.

The warm up exercise, I hope has given you a taste for Istio, although we didn't go into any details.

And we've also established the overall architecture of Istio.

So one lens apart too.

And for the rest of the course, we're going to be going into detail on the major features of Istio.

The only problem for me has been where do we start, we could do all of this in any order, really.

But I've decided to lead with telemetry.

So in this section, we will be using three user interfaces that are bundled with Istio, firstly, kiali, then Jaeger, and then grafana.

The reason I've decided to do this section first is that with these tools in our toolbox, we'll be able to use these graphical features later in the course.

So it will be good for the demos.

As always through the course we are going to be running a demonstration system.

And for this session, we're going to be running a version of the fleet manager, which is actually working, there's no faults to find, or at least that I know of.

And that's just so we don't get any crashes or nasties getting in the way of looking at these wonderful user interfaces.

The files that you need for this section of the course are in the course fold called one, telemetry.

And if you did the one exercise, then you'll recognise the structure of what we have here.

I've separated everything out into separate yaml files.

So we know what everything is doing.

Just in case you didn't do the warm up, maybe you've come straight to the telemetry section, I will explain in detail exactly how we start up this system.

Now I would recommend, first of all, especially if you've done the previous session that you do a minkube deletes I'm probably being overcautious there.

But that will get rid of any potential that anything left behind from previous isn't going to get in our way.

I'm sure I mentioned this previously, but we are going to need a minkube with at least four gigabytes of RAM to fit everything in.

So you'll do a minkube start dash dash memory, and at least 4096.

And I hope your host machine can handle that.

Once minkube is started up, it's really just the case of applying these YAML files.

In order actually, you can apply them all at once except for the first one.

The first of the files is the file that I've called one istio in it dot yaml.

I say I've called it that I promise you I have obtained up from the official istio downloads.

I've just renamed these files to make it clearer what's going on.

And in the installation chapter towards the end of this course, I'll explain exactly how I've got that file.

But this is the one file you do have to apply first, because this creates a set of custom resource definitions.

It is a quirk of Kubernetes that if you're using these custom resource definitions, you have to apply them in a file on their own.

As a separate step.

At the time of recording, I am seeing a warning here is just warning me that the API version of custom resource definition is going to be removed in version 1.22 of Kubernetes.

So this could be a problem for you, if you're watching this course long into the future and you are running Kubernetes 1.22, then this file might not have applied for you by version 1.22 of Kubernetes, I will have updated the course.

And so this shouldn't be a problem for you, when you watch the course.

If you do get an error here, then I need to know about it.

So get in touch.

But I am just using the files that have been supplied by Istio here.

So I haven't made any changes.

So it is a it is something that's going to have to be cleaned up in the future.

But for me at the time of recording, that will not be a problem.

Hope it's not a problem for you.

Once that step is complete, we can immediately go on to applying the second of the files, which I've called Istio minkube.

Now, I don't want to mislead you with that file name.

This really is just Istio is Istio that I've slightly tuned for this course.

Again, I will explain those tunings in the installation chapter.

But it really is just a few little tweaks, such as applying node ports to kiali and Yeager and refiners so we can access them easily.

Really, this is just an STL file.

In the early versions of the course, I had to work really hard to make it runnable on minkube, which is why I use that file name.

It's a legacy thing really, I could have called this STL dot yaml.

When you apply that you'll see a lot of resources created.

And if we then go straight on to do a kubectl get po on the Istio system namespace.

You'll see those control plane pods starting up.

As I mentioned in the introduction, this is getting much simpler.

It used to be a much bigger namespace you might see some videos later on in the course that were recorded in the first edition, of course, and you'll see a lot of other junk in here.

It's really good that they've cleaned this down.

As we've mentioned, the main pod in here is the Istio, D The Istio daemon.

So before I move on, I'm going to wait until all of these pods have started.

That will take a few minutes.

Yes, and that took about two minutes for me, but I am running on a pretty fast computer here.

So don't worry if this takes quite a long time.

For all of the pods to be in the status of running, you'll notice that all of the pods have just one container inside them, except for the Prometheus pod, which has two containers.

So once you're in this state, you have the Istio control plane up and running.

Now the next file is the three kiali secret dot yaml file.

Actually, this file is now redundant.

In the early versions of this course, you needed to set up a username and password for kiali.

And we did it using this yaml file.

In the version of Istio that you're using.

However, they have removed the requirement to login with a username and password, you can integrate kiali into authentication systems.

Actually, for many purposes, it's fine to leave kiali without a username and password, you typically deploy the services behind an Ingress gateway, which would typically handle authentication that's a bit beyond the scope of this course for us is going to be fine just to have kiali running without the username and password.

So you can apply this file if you want.

If you don't apply the file, it won't hurt.

So file three then is redundant.

It doesn't matter if you apply it or not.

But file four is absolutely critical.

You might remember from the warm up demo that we manually labelled the default namespace.

And all future demos, that labelling is done automatically by File Number four, let's have a quick look at that file.

It's a simple modification of the default namespace, where we're adding in the label called Istio injection.

And that value is set to enabled.

Once that label is applied to a namespace.

From that point on, whenever we start a pod, in that namespace, Istio will automatically inject that sidecar, the proxy, which is needed if we want to gather data about that namespace.

So it's important that you have that label applied.

Before you start up the pods in that namespace.

I'm going to show you what would happen if you forgot to apply that file.

So I'm going to temporarily not apply that file.

But if you're following along, then you should apply it.

The fifth file is just the application that we're running.

And there's a really important point that I want to get across on this course, if you have a look at that file, I'll invite you to have a look at it for yourself, I won't bother looking at it on the video, you can take my word for it, if you if you prefer that there's absolutely no Istio configuration inside that yaml file.

It's just standard Kubernetes.

It's some pods and services to run my system.

Now what I'm trying to get across here is that I've worked with some projects in the past who have said, yeah, we really love to use this kiali to visualise our system.

But we've had a look at Istio and it looks complicated.

And it looks like there's a lot of configuration to put in place a lot of yaml files and so on.

And we need to set up virtual services and destination rules.

And I think the reference manual actually on the str website sort of implies that you need over but no, I'm demonstrating here in this section of the course we're going to be using till all of stos telemetry features.

But we don't have to create any special YAML configuration.

Apart from the minus step of labelling the namespace, we then just deploy a normal Kubernetes application.

And just with that, we'll get all of the wonderful telemetry features from Istio.

It's only when you want to start doing things like custom routing, or routing, then you do need little bits of yaml.

But it's only little bits, you don't need special YAML for your entire system.

So I'll keep making that point as we go through the course.

But if you just want to check file five for yourself, just to just convince yourself, there's nothing special in there.

I'm just going to apply it remember, I have forgotten to label the default namespace and I just want to demonstrate if you do forget that label.

I'll need to wait a short while.

So yes, you can see that because I forgot to label the default namespace.

The pods have started up if you like normally, there's one container in each of the pods.

So we need that data plane running.

We need those extra containers to be running.

What do you do if you've forgotten to label a namespace that you want to monitor.

Use Istio or a related question is What would you do if you already have a cluster running? And you want to add Istio to that cluster? How would how do we get that container into these already running pods? Well, I'm sorry that as far as I know, there's no way to get this proxy injected into an already running pod.

The quick answer is you just have to restart all of your pods.

now realise for some projects, that could be a problem.

If this were a micro service project, then it should be absolutely fine to delete any pod, let it restart, if your micro service system is well designed, it should still run absolutely fine.

Maybe with degraded features or degraded performance.

I realised that if you're working on maybe a monolith project, and you've got one big part that you didn't touch, then you'd potentially have a problem.

Also, if you're applying Istio to an existing cluster with hundreds of pods, it's quite common just to write a bash script or something like that, that just stops the pods one after the other.

But maybe with a minute's delay, after each restart, for us on the course, what we can do is simply delete all of these pods.

And we do need to of course, remember to apply file for first.

So cube CTL, apply dash F on File Number four, don't worry about this warning, it's just a misleading warning, really, it's saying that we're applying a patch to a namespace that's already been created.

And it could be difficult to recreate the state of this cluster, there has been a long standing issue, that they've still not closed that that warning really should be more meaningful.

It's certainly not a problem for us.

That namespace has been configured, and that label will be in place.

And just to demonstrate I'm playing for time a little bit, if we do a kubectl get p O.

Now, unfortunately, that won't affect the already running pods, as previously said, and you could wait as long as you like hear those pods will continue running with just one container.

So the fix for us is a kubectl delete pod, dash dash, all.

And that will we often call this bouncing the pods, because they're a part of the deployment, they will be immediately restarted.

And if I as quickly as I can go on to do a kubectl get po.

You can see now that all of the pods are restarting This time, we're seeing the magical two containers inside each of the pods, and it will go through that initialization process.

So if you're in the same position where you have the six pods running in the default namespace, and there are two containers ready in each of them, then you have the Istio data plane up and running.

And remember from our previous steps, if we get the pods on the Istio system namespace, what you're seeing here is the control plane.

Hope you're in a similar position.

That's close this video, we'll just check that the applications running.

If you find the IP address of your minkube with minkube IP, and visiting that IP address colon 30,080, you should be seeing the application up and running.

This is a different version of the application to the one we had in the warm up system.

This version of the system should be working.

There's no faults in it, as far as I know, at least.

As you can see, for me, at least the vehicles are moving pretty quickly and I'm getting a rapid update.

If I do a refresh here, I'm finding that all of the vehicles are appearing on the left hand side within say five to 10 seconds or something like that.

So the plan is for the next few videos.

We're going to use this Theo's telemetry and we're going to use the various user interfaces to visualise what's going on under the hood.

We'll go into more detail on kiali in the next video

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

그리고 이것은 과정의 두 번째 부분의 시작입니다.

파트 1은 장면 설정에 관한 것이 었습니다.

워밍업 운동을 통해 Istio를 맛보 셨기를 바랍니다. 자세한 내용은 다루지 않았습니다.

또한 Istio의 전체 아키텍처도 구축했습니다.

따라서 렌즈 하나도 떨어져 있습니다.

나머지 과정에서는 Istio의 주요 기능에 대해 자세히 살펴 보겠습니다.

저에게 유일한 문제는 어디서부터 시작해야하는지,이 모든 것을 어떤 순서로든 실제로 할 수 있다는 것입니다.

하지만 저는 원격 측정을 주도하기로 결정했습니다.

따라서이 섹션에서는 Istio와 함께 번들로 제공되는 세 가지 사용자 인터페이스 (먼저 kiali, Jaeger, grafana)를 사용합니다.

이 섹션을 먼저 수행하기로 결정한 이유는 도구 상자에있는 이러한 도구를 사용하여 나중에 과정에서 이러한 그래픽 기능을 사용할 수 있기 때문입니다.

그래서 그것은 데모에 좋을 것입니다.

과정을 통해 항상 우리는 데모 시스템을 실행할 것입니다.

그리고이 세션에서는 실제로 작동하는 차량 관리자 버전을 실행할 것입니다. 실제로 작동하고, 찾을 결함이 없거나, 적어도 제가 알고있는 것입니다.

그리고 그것은 우리가 이러한 멋진 사용자 인터페이스를 보는 데 방해가되는 충돌이나 문제를 일으키지 않도록하기위한 것입니다.

코스의이 섹션에 필요한 파일은 원격 측정이라는 코스 폴더에 있습니다.

그리고 한 가지 운동을했다면 여기에있는 것의 구조를 인식하게 될 것입니다.

모든 것을 별도의 yaml 파일로 분리했습니다.

그래서 우리는 모든 것이 무엇을하고 있는지 압니다.

워밍업을하지 않았거나 원격 측정 섹션으로 바로 오셨을 경우를 대비해이 시스템을 시작하는 방법을 자세히 설명하겠습니다.

이제는 우선, 특히 이전 세션을 수행 한 경우 minkube 삭제를 수행하는 것이 좋습니다. 아마도 거기에서 지나치게 조심 스러울 것입니다.

그러나 그것은 이전에 남겨진 것이 우리를 방해하지 않을 잠재력을 제거 할 것입니다.

앞서 언급 한 것은 확실하지만 모든 것을 수용하려면 최소 4GB의 RAM이있는 minkube가 필요합니다.

따라서 minkube 시작 대시 대시 메모리 및 최소 4096을 수행합니다.

그리고 나는 당신의 호스트 컴퓨터가 그것을 처리 할 수 ​​있기를 바랍니다.

minkube가 시작되면 실제로 이러한 YAML 파일을 적용하는 경우입니다.

실제로 순서대로 첫 번째를 제외하고 한 번에 모두 적용 할 수 있습니다.

첫 번째 파일은 내가 하나의 istio라고 부르는 파일이다. dot yaml.

공식 istio 다운로드를 통해 얻은 것임을 약속합니다.

무슨 일이 일어나고 있는지 명확하게하기 위해이 파일의 이름을 변경했습니다.

이 과정이 끝날 무렵의 설치 장에서 해당 파일을 얻는 방법을 정확히 설명하겠습니다.

그러나 이것은 사용자 지정 리소스 정의 집합을 만들기 때문에 먼저 적용해야하는 파일입니다.

이러한 사용자 지정 리소스 정의를 사용하는 경우 자체적으로 파일에 적용해야한다는 것이 Kubernetes의 특징입니다.

별도의 단계로.

기록 할 때 사용자 지정 리소스 정의의 API 버전이 Kubernetes 버전 1.22에서 제거 될 것이라는 경고 만 여기에 표시됩니다.

따라서 이것은 문제가 될 수 있습니다.이 과정을 오랫동안 시청하고 Kubernetes 1.22를 실행하고 있다면이 파일이 Kubernetes 버전 1.22까지 적용되지 않았을 수 있으며 과정을 업데이트했습니다.

따라서 코스를 시청할 때 이것은 문제가되지 않아야합니다.

여기에서 오류가 발생하면 그것에 대해 알아야합니다.

그러니 연락하십시오.

하지만 여기서 Istio에서 제공 한 파일을 사용하고 있습니다.

그래서 변경하지 않았습니다.

그래서 그것은 미래에 정리해야 할 것입니다.

그러나 녹음 당시에는 문제가되지 않습니다.

당신에게 문제가되지 않기를 바랍니다.

이 단계가 완료되면 즉시 Istio minkube라고 부르는 두 번째 파일을 적용 할 수 있습니다.

이제 그 파일 이름으로 오해하고 싶지 않습니다.

이것은 정말로 Istio가 Istio이며 제가이 과정을 위해 약간 조정 한 것입니다.

다시 한 번 설치 장에서 이러한 조정에 대해 설명합니다.

하지만 노드 포트를 kiali와 Yeager 및 리파이너에 적용하여 쉽게 액세스 할 수 있도록하는 것과 같은 약간의 조정 작업입니다.

실제로 이것은 단지 STL 파일입니다.

코스의 초기 버전에서는 minkube에서 실행 가능하게 만들기 위해 정말 열심히 노력해야했기 때문에 그 파일 이름을 사용했습니다.

정말 레거시 것입니다. 저는이 STL dot yaml이라고 부를 수있었습니다.

이를 적용하면 많은 리소스가 생성되는 것을 볼 수 있습니다.

그런 다음 곧바로 Istio 시스템 네임 스페이스에서 kubectl get po를 수행합니다.

해당 컨트롤 플레인 포드가 시작되는 것을 볼 수 있습니다.

소개에서 언급했듯이 이것은 훨씬 더 간단 해졌습니다.

예전에는 훨씬 더 큰 네임 스페이스 였는데, 물론 초판에서 녹화 된 비디오를 나중에 볼 수 있으며 여기에서 다른 많은 쓰레기를 볼 수 있습니다.

그들이 이것을 깨끗하게해서 정말 좋습니다.

앞서 언급했듯이 여기에있는 주요 포드는 Istio, D Istio 데몬입니다.

계속 진행하기 전에이 모든 포드가 시작될 때까지 기다릴 것입니다.

몇 분 정도 걸립니다.

예, 약 2 분 정도 걸렸지 만 여기서는 꽤 빠른 컴퓨터에서 실행 중입니다.

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

모든 포드가 실행 중 상태가 되려면 두 개의 컨테이너가있는 Prometheus 포드를 제외하고 모든 포드에 컨테이너가 하나만있는 것을 알 수 있습니다.

따라서이 상태가되면 Istio 컨트롤 플레인이 가동되고 실행됩니다.

이제 다음 파일은 세 개의 kiali secret dot yaml 파일입니다.

실제로이 파일은 이제 중복됩니다.

이 과정의 초기 버전에서는 kiali에 대한 사용자 이름과 암호를 설정해야했습니다.

그리고 우리는이 yaml 파일을 사용하여 그것을했습니다.

사용중인 Istio 버전에서.

그러나 사용자 이름과 비밀번호를 사용하여 로그인 할 필요가 없으므로 kiali를 인증 시스템에 통합 할 수 있습니다.

사실, 많은 목적을 위해 사용자 이름과 비밀번호없이 kiali를 남겨 두는 것이 좋습니다. 일반적으로 Ingress 게이트웨이 뒤에 서비스를 배포합니다. 일반적으로이 과정의 범위를 약간 벗어난 인증을 처리합니다. 사용자 이름과 암호없이 kiali를 실행합니다.

따라서 원하는 경우이 파일을 적용 할 수 있습니다.

파일을 적용하지 않으면 아프지 않습니다.

따라서 세 번째 파일은 중복됩니다.

적용 여부는 중요하지 않습니다.

그러나 파일 4는 절대적으로 중요합니다.

준비 데모에서 수동으로 기본 네임 스페이스에 레이블을 지정한 것을 기억할 수 있습니다.

이후의 모든 데모에서는 레이블이 파일 번호 4에 의해 자동으로 수행됩니다. 해당 파일을 간단히 살펴 보겠습니다.

Istio injection이라는 레이블에 추가하는 기본 네임 스페이스의 간단한 수정입니다.

그리고 그 값은 enabled로 설정됩니다.

해당 레이블이 네임 스페이스에 적용되면.

그 시점부터 pod를 시작할 때마다 해당 네임 스페이스에서 Istio는 해당 네임 스페이스에 대한 데이터를 수집하려는 경우 필요한 사이드카 인 프록시를 자동으로 삽입합니다.

따라서 해당 레이블을 적용하는 것이 중요합니다.

해당 네임 스페이스에서 포드를 시작하기 전에.

해당 파일을 적용하는 것을 잊었을 경우 어떻게되는지 보여 드리겠습니다.

따라서 해당 파일을 일시적으로 적용하지 않겠습니다.

하지만 따라가는 경우 적용해야합니다.

다섯 번째 파일은 우리가 실행중인 응용 프로그램입니다.

이 과정에서 제가 이해하고 싶은 정말 중요한 점이 있습니다. 그 파일을 봤다면 직접 확인해 보도록 초대 할 것입니다. 비디오에서 보지 않겠습니다. , yaml 파일 내에 Istio 구성이 전혀없는 것을 선호한다면 내 말을 받아 들일 수 있습니다.

표준 Kubernetes 일뿐입니다.

내 시스템을 실행하는 것은 일부 포드 및 서비스입니다.

이제 제가 여기서 다루고 자하는 것은 과거에 몇몇 프로젝트와 함께 일한 적이 있다는 것입니다. 예, 우리는이 kiali를 사용하여 시스템을 시각화하는 것을 정말 좋아합니다.

하지만 우리는 Istio를 살펴 봤는데 복잡해 보입니다.

그리고 많은 yaml 파일 등을 배치해야하는 많은 구성이있는 것 같습니다.

그리고 가상 서비스 및 대상 규칙을 설정해야합니다.

그리고 저는 실제로 str 웹 사이트에있는 참조 매뉴얼이 여러분이 필요하다는 것을 암시한다고 생각합니다. 그러나 저는이 섹션에서 우리가 모든 원격 측정 기능을 사용할 때까지 사용할 과정의이 섹션에서 시연하고 있습니다.

그러나 특별한 YAML 구성을 만들 필요는 없습니다.

네임 스페이스에 레이블을 지정하는 마이너스 단계와는 별도로 일반 Kubernetes 애플리케이션을 배포합니다.

이것으로 Istio의 모든 멋진 원격 측정 기능을 얻을 수 있습니다.

사용자 지정 라우팅 또는 라우팅과 같은 작업을 시작하려는 경우에만 약간의 yaml이 필요합니다.

그러나 그것은 단지 작은 부분 일 뿐이며 전체 시스템에 특별한 YAML이 필요하지 않습니다.

그래서 저는 우리가 코스를 진행하면서 그 점을 계속해서 말할 것입니다.

그러나 파일 5를 직접 확인하고 싶을 경우, 자신을 설득하기 위해 특별한 것이 없습니다.

그냥 적용하겠습니다. 기본 네임 스페이스에 레이블을 지정하는 것을 잊었으며 해당 레이블을 잊어 버린 경우 시연하고 싶습니다.

잠시 기다려야합니다.

예, 기본 네임 스페이스에 레이블을 지정하는 것을 잊었 기 때문에 알 수 있습니다.

일반적으로 원하는 경우 포드가 시작되었으며 각 포드에는 하나의 컨테이너가 있습니다.

따라서 데이터 플레인이 실행되어야합니다.

실행하려면 추가 컨테이너가 필요합니다.

모니터링하려는 네임 스페이스에 레이블을 지정하는 것을 잊은 경우 어떻게합니까?

Istio를 사용하거나 관련 질문은 이미 클러스터를 실행 중이면 어떻게 하시겠습니까? Istio를 해당 클러스터에 추가 하시겠습니까? 컨테이너를 이미 실행중인 포드에 어떻게 넣을까요? 글쎄요, 제가 아는 한이 프록시를 이미 실행중인 포드에 주입 할 방법이 없다는 점에 유감입니다.

빠른 대답은 모든 포드를 다시 시작하면된다는 것입니다.

이제 일부 프로젝트의 경우 문제가 될 수 있음을 인식합니다.

이것이 마이크로 서비스 프로젝트라면 pod를 삭제하고 다시 시작하는 것이 좋습니다. 마이크로 서비스 시스템이 잘 설계되어 있다면 여전히 완벽하게 실행되어야합니다.

기능이 저하되거나 성능이 저하되었을 수 있습니다.

모놀리스 프로젝트를 진행하고 있는데 손대지 않은 큰 부분이 하나 있다면 잠재적으로 문제가있을 것임을 깨달았습니다.

또한 수백 개의 포드가있는 기존 클러스터에 Istio를 적용하는 경우 bash 스크립트 또는 이와 유사한 것을 작성하는 것이 매우 일반적이며, 이는 포드를 차례로 중지합니다.

하지만 다시 시작할 때마다 1 분 정도 지연된 상태에서 코스를 진행하는 동안 우리가 할 수있는 일은 단순히 모든 포드를 삭제하는 것입니다.

그리고 당연히 먼저 파일을 신청하는 것을 기억해야합니다.

따라서 큐브 CTL, 파일 번호 4에 대시 F를 적용합니다.이 경고에 대해 걱정하지 마십시오. 잘못된 경고 일뿐입니다. 실제로 이미 생성 된 네임 스페이스에 패치를 적용하고 있다는 의미입니다.

그리고이 클러스터의 상태를 재현하는 것은 어려울 수 있습니다. 오랫동안 지속 된 문제가 있었으며, 그 경고가 실제로 더 의미가 있어야한다는 사실을 아직 닫지 않았습니다.

확실히 우리에게는 문제가되지 않습니다.

해당 네임 스페이스가 구성되었으며 해당 레이블이 제자리에 있습니다.

그리고 단지 내가 시간을두고 플레이하고 있음을 보여주기 위해 우리가 kubectl을하면 p O를 얻습니다.

이제 불행히도 이전에 말했듯이 이미 실행중인 포드에는 영향을주지 않으며 해당 포드가 하나의 컨테이너로 계속 실행되는 것을 듣고 싶은 한 기다릴 수 있습니다.

따라서 우리를위한 수정 사항은 kubectl delete pod, dash dash, 모두입니다.

그리고이를 배포의 일부이기 때문에이를 팟 (Bouncing the Pod)이라고 부르는 경우가 많으며 즉시 다시 시작됩니다.

그리고 내가 가능한 한 빨리 kubectl get po를 할 수 있다면.

이제 모든 pod가 다시 시작되는 것을 볼 수 있습니다. 이번에는 각 pod 내부에 마법 같은 두 개의 컨테이너가 있고 초기화 프로세스를 거치게됩니다.

따라서 기본 네임 스페이스에서 실행중인 6 개의 포드가 있고 각각에 두 개의 컨테이너가 준비되어있는 동일한 위치에있는 경우 Istio 데이터 플레인이 실행되고있는 것입니다.

그리고 이전 단계에서 Istio 시스템 네임 스페이스에 포드를 가져 오면 여기에 표시되는 것은 제어 플레인입니다.

비슷한 위치에 있기를 바랍니다.

이 비디오를 마치겠습니다. 애플리케이션이 실행 중인지 확인하겠습니다.

minkube IP로 minkube의 IP 주소를 찾고 해당 IP 주소 콜론 30,080을 방문하면 애플리케이션이 실행되고있는 것을 볼 수 있습니다.

이것은 워밍업 시스템에있는 것과 다른 버전의 응용 프로그램입니다.

이 버전의 시스템이 작동해야합니다.

적어도 내가 아는 한 그 안에 결점은 없습니다.

보시다시피, 저에게는 적어도 전차가 꽤 빨리 움직이고 있고 저는 빠른 업데이트를 받고 있습니다.

여기서 새로 고침하면 5 ~ 10 초 정도의 시간 내에 모든 차량이 왼쪽에 나타납니다.

그래서 계획은 다음 몇 개의 비디오를위한 것입니다.

이 Theo의 원격 측정법을 사용하고 다양한 사용자 인터페이스를 사용하여 내부에서 일어나는 일을 시각화 할 것입니다.

다음 비디오에서 kiali에 대해 자세히 살펴 보겠습니다.