06. Hands on Demo - Enabling Sidecar Injection

You'll know from previously that Istio contains sort of two sections, there is the control plane, they're the set of pods that are running in their own Istio namespace.

And we've seen that we've got that it's up and running absolutely fine.

In the Istio system namespace, there's the control plane parts.

What we also need to think about though, is the data plane.

They're the proxies, that we want Istio to run inside every single one of our pods.

Now being very vague about how they get there, there are several ways that you can put these proxies into your pots.

Now, one way which I've never done myself, and I'm not even showing were to bother covering it on the course, you can use an Istio binary, and it's the application to run your YAML file through, and it will add yaml into your yaml file.

And that yaml will be simply adding a container to every single one of your pod definitions.

So you end up with a bigger yaml file.

Now I personally absolutely hate that idea, because it's damaging my yaml member i said earlier on that is the Oh should have no impact on your applications code.

Well, I think it should also have no impacts on your applications.

yaml your Kubernetes definitions.

So for that reason, the professional approach and we don't touch the yaml file, but we set a flag in Istio and that flag tells Istio that for a particular namespace, we want it to automatically inject it calls it injecting that proxy container into every one of our pods in earlier versions of Istio and in fact, I'm showing you here a screenshot from the very earliest version of this course, where the control plane was very much more complicated.

There was actually a pod sat there responsible purely for doing what's called sidecar injection.

Now that pod doesn't exist anymore, you have seen it in your Istio system.

But the functionality is still there.

That functionality is now inside Istio D.

So let's have a quick look at what that functionality is.

Now haven't used this terminology so far.

But you're probably familiar with the with a term sidecar from regular Kubernetes as a sidecar is where you have an extra container in your pod that's doing some kind of extra help.

So think of it as a helper container.

So often in the documentation, you'll find the Istio proxies are called the side cars.

And one of the control plane components is an injector.

That's basically monitoring for whenever you shedule a pod.

This pod detects that.

And it automatically adds that sidecar or as I've been calling them, the proxy, the only caches we do have to configure that by default, the sidecar injector will do nothing.

And the way it works is we need to set up a label.

And this works on a namespace by namespace basis.

So we if we have a particular namespace that we want Istio to gather data about, then we take that namespace, we give it a label, if you want STL to work across your entire architecture, then you would simply add a label to all of the namespaces that you have in your system.

Now on this course, we're only going to be working in the default namespace.

So things are really simple.

If I do a kubectl, describe on the default namespace, I should have said describe ns defaults, then this is just the default setup that we got with minkube, we have a namespace called defaults, and there are no labels applied to it.

I don't know if you've done this before, I don't know how familiar you are with this.

But you can do this manually using kubectl.

We can do kubectl label namespace.

And the namespace that we're labelling is the default namespace.

And the label that we need to set up is the label called Istio dash injection.

And we need to set that to the value of enabled, it's absolutely critical that you type this correctly.

Otherwise, when you run the application, there will be no Istio data gathered for the application.

If I recall the previous describe namespace default, you can now see that that label is correctly set up.

And just in case you do want to store this in the yaml you could always do get namespace default data dash o yaml.

output that namespace in YAML format, and you could copy the contents of this into a yaml file and it would just be In the metadata for that namespace, so it's really important that you have that in place.

And for that reason, I've kept this in a video of its own.

In the next video, we'll actually run the application

이전에 Istio에 일종의 두 섹션이 포함되어 있다는 것을 알게 될 것입니다. 제어 플레인은 자체 Istio 네임 스페이스에서 실행되는 포드 집합입니다.

그리고 우리는 그것이 완전히 잘 작동하고 있다는 것을 확인했습니다.

Istio 시스템 네임 스페이스에는 컨트롤 플레인 부분이 있습니다.

우리가 생각해야 할 것은 데이터 플레인입니다.

Istio가 모든 포드 내부에서 실행되기를 바라는 프록시입니다.

이제 그들이 어떻게 거기에 도달하는지에 대해 매우 모호하기 때문에 이러한 프록시를 냄비에 넣을 수있는 몇 가지 방법이 있습니다.

이제 제가 직접 해본 적이없고 보여주지 않은 한 가지 방법은 과정에서 다루지 않는 것이 었습니다. Istio 바이너리를 사용할 수 있으며 YAML 파일을 실행할 수있는 응용 프로그램입니다. yaml을 yaml 파일에 추가합니다.

그리고 그 yaml은 단순히 모든 포드 정의에 컨테이너를 추가하는 것입니다.

따라서 더 큰 yaml 파일이 생성됩니다.

이제 저는 개인적으로 그 아이디어를 절대적으로 싫어합니다. 왜냐하면 그것은 제 yaml 회원을 해치고 있기 때문입니다. 앞서 말씀 드렸던 것은 Oh가 귀하의 애플리케이션 코드에 영향을 미치지 않아야한다는 것입니다.

글쎄, 당신의 응용 프로그램에도 영향을 미치지 않아야한다고 생각합니다.

Kubernetes 정의를 yaml하십시오.

따라서 전문적인 접근 방식으로 yaml 파일을 건드리지 않지만 Istio에서 플래그를 설정하고 해당 플래그는 Istio에 특정 네임 스페이스에 대해 자동으로 주입하여 해당 프록시 컨테이너를 Istio의 이전 버전에있는 모든 포드와 실제로 여기에서는 제어 플레인이 훨씬 더 복잡한이 과정의 가장 초기 버전의 스크린 샷을 보여 드리겠습니다.

실제로 거기에는 사이드카 주입이라고하는 것을 순전히 책임지는 포드가있었습니다.

이제 포드가 더 이상 존재하지 않으므로 Istio 시스템에서 확인했습니다.

그러나 기능은 여전히 ​​있습니다.

이 기능은 이제 Istio D 안에 있습니다.

이제 그 기능이 무엇인지 간단히 살펴 보겠습니다.

지금까지이 용어를 사용하지 않았습니다.

그러나 사이드카는 일종의 추가 도움을 수행하는 팟 (Pod)에 추가 컨테이너가있는 곳이므로 일반 Kubernetes의 사이드카라는 용어에 익숙 할 것입니다.

그래서 그것을 도우미 컨테이너로 생각하십시오.

문서에서 종종 Istio 프록시를 사이드카라고 부릅니다.

컨트롤 플레인 구성 요소 중 하나는 인젝터입니다.

그것은 기본적으로 포드를 흘릴 때마다 모니터링하는 것입니다.

이 포드는이를 감지합니다.

그리고 자동으로 사이드카를 추가하거나 프록시라고 부르면서 기본적으로 구성해야하는 유일한 캐시 인 사이드카 인젝터는 아무것도하지 않습니다.

작동 방식은 라벨을 설정하는 것입니다.

그리고 이것은 네임 스페이스별로 네임 스페이스에서 작동합니다.

따라서 Istio가 데이터를 수집 할 특정 네임 스페이스가있는 경우 해당 네임 스페이스를 가져 와서 레이블을 지정합니다. STL이 전체 아키텍처에서 작동하도록하려면 레이블을 모든 시스템에있는 네임 스페이스.

이제이 과정에서는 기본 네임 스페이스에서만 작업 할 것입니다.

그래서 상황은 정말 간단합니다.

kubectl을 수행하고 기본 네임 스페이스에 대해 설명하면 ns 기본값 설명이라고 말 했어야합니다. 그러면 이것은 minkube로 얻은 기본 설정일 뿐이며 defaults라는 네임 스페이스가 있으며 레이블이 적용되지 않습니다.

이전에이 일을 해본 적이 있는지 모르겠지만,이 일에 얼마나 익숙한 지 모르겠습니다.

그러나 kubectl을 사용하여 수동으로 수행 할 수 있습니다.

kubectl 레이블 네임 스페이스를 수행 할 수 있습니다.

그리고 레이블을 지정하는 네임 스페이스가 기본 네임 스페이스입니다.

그리고 설정해야하는 라벨은 Istio dash injection이라는 라벨입니다.

이 값을 enabled 값으로 설정해야합니다. 올바르게 입력하는 것이 절대적으로 중요합니다.

그렇지 않으면 애플리케이션을 실행할 때 애플리케이션에 대해 수집 된 Istio 데이터가 없습니다.

이전 설명 네임 스페이스 기본값을 기억하면 이제 해당 레이블이 올바르게 설정되었음을 알 수 있습니다.

그리고 이것을 yaml에 저장하려는 경우 항상 네임 스페이스 기본 데이터 대시 o yaml을 얻을 수 있습니다.

그 네임 스페이스를 YAML 형식으로 출력하고이 내용을 yaml 파일에 복사 할 수 있으며 해당 네임 스페이스의 메타 데이터에있을 것이므로 제자리에 두는 것이 정말 중요합니다.

그래서 저는 이것을 자체 비디오로 보관했습니다.

다음 비디오에서는 실제로 애플리케이션을 실행합니다.