03. Getting Started - What is Istio?

In this section of the course, we're going to get straight into using Istio as quickly as possible.

And you're going to be working through a demonstration of how Istio can be used in a live cluster.

And I'll be aiming to show you the very powerful benefits that Istio can bring to your projects.

Before we get hands on, though, of course, I need to explain what Istio actually is.

For now, I'm not going to go deep, there's a lot of Istio architecture to get through because Istio is really a collection of different tools and frameworks sort of all packaged together.

So there are quite a few moving parts in Istio and you will be learning the detail of Istio as we go through all the different aspects of Istio through the course, there is a session coming up on the architecture of Istio where I'll be explaining all of the buzzwords that you might have heard of, like envoy pilot Citadel, and well, there's quite a few of those words.

But for now, we're just going to get a feel for what Istio is at a high level.

So what is Istio then? Well, Istio is just one example of what has become known as a service mesh.

So to answer the question of what is Istio? Well, I could just say Istio is a service mesh.

Okay, well, that means we need to know what a service meshes are the concepts of a service mesh at the time of recording at least is a relatively new thing.

Or at least it's only recently that they've become popular and heavily used.

Service meshes I think have been could become popular because as more and more real world projects are using cluster based micro service architectures, we're beginning to discover as an industry that the existing frameworks like Kubernetes, on its own, is not quite enough.

Well, that's the first time actually I've mentioned Kubernetes in this video.

So I really need to point out that a service mesh is not going to be a replacement for Kubernetes, it's actually going to be an extra layer of software that you deploy alongside Kubernetes.

And before we go too far, I should also say that service meshes are not just relevant to Kubernetes.

Any kind of distributed architecture, that is where we have multiple software components networking with each other, would benefit from a service mesh.

It's just that at the time that I'm making this course at least Kubernetes is by far and away the most successful framework for building distributed architectures, or as they call them, orchestration frameworks.

So for that reason, on this course, I'll keep focused on micro service architectures that are targeting Kubernetes.

Doesn't matter though, if you're using Kubernetes, to build a non micro service architecture, as long as you're on Kubernetes, this course is good for you.

While I still haven't said what a service mesh is yet, so let's think about a standard micro service architecture that you're running on Kubernetes.

And as you know, we're going to have a whole bunch of Kubernetes pods.

And each pod typically contains a container.

As you know, we can have multiple containers inside a pod, but it's quite standard to have a single container inside each pod.

Now, these containers are all networked together, because we can use the service discovery mechanism inside Kubernetes to make network calls from any container to any other container.

Of course, you know Kubernetes, so you'll be well familiar with all of that, I hope.

Now the problem with just a bad Kubernetes deployment is that whilst Kubernetes is very good at handling and managing the pods.

So for example, if I wanted to take this part out of service for some reason, I could just issue a command to the cube API or run a cube CTL command or we could modify and apply some yamo then Kubernetes will respond to that the shedule will it would take that part out of service absolutely fine.

But what Kubernetes is not so good at is managing or giving us any visibility at all, or the interconnections between the pods.

We know that for example, the container here is able to make a network call to the container here.

But it's not easy to infer anything about what's happening in this connection.

It's possible for example, there's there's a fault inside this container, which means some of these network requests are not being satisfied.

I guess if we know that this container is problematic, we could of course, look into the software in that container or look at the logs of that container, and work out what's going wrong.

And I'm sure you'll be well familiar with doing that kind of exercise.

But that's okay if you'd know which container is failing.

But if you've got 1000s of microservices, we're going to have an uncountable number of combinations of possible network calls between these parts.

With just standard Kubernetes, we don't have any kind of visibility or control over the connections between the containers.

So this is where a service mesh can help.

Although it's not necessarily implemented like this, you can think of a service mesh as being a layer of software that is kind of sitting underneath all of the pods in our system.

Now, I'm not being technically precise yet.

But this is more of a mental model of the way you can think about this, we will look at exactly how Istio implements all of this shortly.

But conceptually, what we're going to do is to somehow set things up so that all network traffic that's running through our cluster, is going to be routed or routed through this service mesh software.

Let's go through an example.

Our container here wants to talk to the container in this part here.

So we're going to make a network call.

And traditionally, we would do that using Kubernetes.

As a service concept, I've not bothered putting services on here, but you know that we would just make a network call from this container to whatever the service representing this pod is called.

And that would result in a direct call between the two containers.

But with the service mesh, we're going to set things up so that all calls are directed via this service mesh, we're going to make it so that the container doesn't actually call the target container.

Instead, its network request is routed to the service mesh, and then the service mesh will be responsible for directing the call onwards to the target container.

Well, what's the point of that this looks quite inefficient.

But the point is, the service mesh can implement some logic, either before the call is routed to the target container, or the this mess logic could run.

After the target container is completed and has returned.

Maybe this container returns http 200.

Back to the service mesh, this logic here could then run after the call has been made.

Or it could be a combination of both.

Now I'm being very vague here.

What is this mesh logic? Well, it can be anything.

But at the time that I'm recording this, the big features that everybody's looking for from a service mesh are things like telemetry.

So telemetry is just a fancy word for gathering metrics.

You're probably if you've been working on a Kubernetes cluster, you've been used to using things like Prometheus and grafana, to gather metrics about the overall health of the cluster.

This is really the same thing.

But here we're gathering metrics about individual network requests.

So we could make this little mesh logic, for example, be every time a request is received by the service mesh, it could make a record of the time that this request was received, then it forwards on the request to the target container.

And when it returns, the mesh logic could calculate the time that that request took, it could record the response code, whether it's an error or whether it was a success.

And it could put all of that into a database somewhere.

And that would mean over time, we could inspect the results of this telemetry, we could find out if a particular service is returning too many errors, for example.

And without a service mesh, it would be really difficult to get that kind of information.

But there are many other features that a service mesh can insert here.

We're going to be seeing all of those features on this course.

Another big feature would be tracing which would allow us to take arbitrarily complex chains of network calls that are all sorts of wire together to implement a single use case.

We could get the mesh to tell us exactly what that chain was, how long each step in the chain took and exactly what was happening in that chain.

That's a very difficult thing to do.

In a regular distributed cluster.

We can also implement security A massive feature of a service mesh is traffic management, that's going to allow us to do very clever things such as maybe rerouting requests, depending on some particular requirement that we have.

So that's a service mesh in general, and I'm always going to think about it in my head is being like this a kind of layer sitting under the parts through which all of our traffic is going to flow through.

So that's how service meshes work in general, I guess there's probably 1000 different ways that service meshes could be implemented.

You're here for Istio in this course.

So I'm now going to tell you how Istio implements a service mesh, the trick that Istio pulls off is for each of the pods in your system, which will probably in general, just have a single container inside them.

Istio is going to inject or add its own container.

This container is called a proxy.

And it is just a container.

Now let's look again at the scenario where this container here is going to make a network call to this container here.

Well in Istio things are setup so that the network request from the container is going to be routed or routed to its proxy.

And it's here that that mesh logic can be implemented.

I'll come back to the mesh logic in a moment.

Now on this course, I'm not going to get into really deep details of Istio that would be for an advanced this steel internals course or something.

But just in case you're curious Istio will have done some IP tables configuration on the container here.

So the container thinks it's making a remote call, but actually, it's just calling the proxy.

So it's at this point, then the proxy can inject the mesh logic that we were talking about before.

So the proxy then is responsible for relaying that call to the target pots proxy.

Again, there could be some mesh logic here.

But ultimately, the content, the target container is going to receive that call.

And it's possible that this container as a result of this request needs to call container in another part of the story would continue that request would be routed through this proxy to the new target proxy, and then on to the target container.

So although conceptually, if I can just go back a step, I think of the service mesh as kind of sitting underneath all of the pods, and all of the traffic is being routed through this mesh.

But in reality, it's implemented as proxies that are placed inside every pod.

So the actual implementation is different to the conceptual model of service mesh, but the end result is the same.

So returning back to this model, then where we have a proxy inside each of the pods in our system.

The whole purpose of this then is this proxy can add in any logic that we like, as a result of requests being made from one container to another.

So the way this works in Istio let's go back through the scenario, when making a call from this container to this container, that call is going to be rerouted or rerouted through this proxy.

Theoretically, this proxy could do anything but in Istio The way it works is we'll have a whole bunch of pods running, if you like alongside our application.

These are assets of Istio pods which are in their own namespace called the Istio system.

And inside there are the pods that are effectively running Istio itself.

Now this is an update to the course because in earlier versions of Istio there were loads of pods inside that Istio system namespace and they all had very exotic and strange names such as pilot and Citadel and galley.

And while there were a few others.

Now each of those pods had a different area of responsibility.

For example, one pod would be responsible for telemetry, another pod would be responsible for traffic routing.

Another pod was responsible for validating the YAML that we're going to be applying later on.

So it was very complicated namespacing fact books in later versions of Istio This came around at version 1.5.

So probably by the time you watch this, this will be quite a long time ago now, the whole of stos internals were factored.

Basically it was simplified.

And instead of all of those complicated pods, essentially the whole of Istio now is implemented with a single pod.

And that pod is called I'm not sure how to pronounce This is Cod, some people call it is the odd, it actually stands for the Istio demon.

And also, if you just think of this as being most of stos functionality is implemented inside this pod, so it is significantly simpler.

So one of the things that Istio D is responsible for is gathering statistics.

In other words, telemetry about your system.

Well, these proxies are all aware of these Istio pods.

So, the proxies are going to be able to call these pods in order to implement their logic.

So, for example, one thing that this Istio telemetry pod could do is it could record the time and date that a particular request was made, then the proxy could go on and called with target proxy, which is then routed to the target container.

The container then does its logic, and that's going to take an amount of time.

But then when the return chain reaches to here, the proxy can again call the Istio telemetry pod with the time and date that the request was returned, it could also record the status code, and anything else that we're going to find interesting.

And if this telemetry pod is able to gather that data together somewhere, then of course, we'll be able to interrogate that data, we'll be able to find out if our particular calls that are failing or taking too long or whatever.

There's a demo coming up on that in just a few moments.

Just a couple more jargon terms, before we move on, you're going to see these jargon terms everywhere in the Istio documentation.

And the first jargon term is the data plane.

An old data plane really is, is a collective term for all of the proxies that we have running in our architecture, the data plane, or just the proxies that Istio have put into our system.

By contrast, all of those pods that are running in that Istio system.

In other words, the pods that are really implementing stos functionality are collectively called the control plane.

Well, as I mentioned previously, this used to be a very complicated namespace, there were a lot of pods inside the control plane, and you had to learn all of the names of these parts.

It's really good news that it's now much much simpler inside that control plane.

The core of the control plane is that single pod that we call the Istio demon.

There are, however, a few of the pods inside the control plane, we will meet them as we go through this course.

But in the main they are user interface parks, we're going to be meeting quite a few different user interfaces, such as a programme called kiali, which is a very neat user interface for visualising your pods and how they connect together.

So that's implemented as a pod inside the control plane.

At the time of recording, there are about six different pods in this control plane.

I'm not going to overload you with information right now.

But you are going to be seeing those pods as soon as we start the hands on demos.

So that's the control plane compared to the data plane, which is the set of proxies that Istio has added to each of our parts.

There's just one last thing I haven't addressed, though, I haven't told you what changes are we going to have to make to our containers to make all of this work? Well the answer for Istio.

And in fact, the answer for any good service mesh is that we should not have to make any changes whatsoever to our containers, it shouldn't matter whether they're running on service mesh, or not.

So Istio is not invasive into our application, you can think of a service mesh as something that we either switch on in our cluster, or we switch off, and it doesn't make a difference to the functioning of our application.

However, that's the kind of ideal, there is actually one area where Istio does make some requirements on our containers.

And that's related to tracing.

So I'll hold back on that until we get to the tracing section on the course.

But for now, it's enough to say that really Istio should not have much effect at least on the actual code that you're putting inside your containers.

So that's it for Istio at a very high level.

Much more details still to come.

But for now, I hope you've got at least a handle on what Istio is.

But I think to get a really proper feel for Istio it would be great if we could have a play with Istio so in the next video we'll do Just that

이 섹션에서는 가능한 한 빨리 Istio를 사용하는 방법에 대해 알아 보겠습니다.

그리고 라이브 클러스터에서 Istio를 사용하는 방법에 대한 데모를 진행할 것입니다.

그리고 Istio가 귀하의 프로젝트에 제공 할 수있는 매우 강력한 이점을 보여 드리고자합니다.

물론 시작하기 전에 Istio가 실제로 무엇인지 설명해야합니다.

지금은 깊이 들어 가지 않을 것입니다. Istio는 실제로 다양한 도구와 프레임 워크가 모두 함께 패키지 된 모음이기 때문에 통과해야 할 Istio 아키텍처가 많습니다.

따라서 Istio에는 움직이는 부분이 상당히 많으며 과정을 통해 Istio의 모든 다른 측면을 살펴보면서 Istio의 세부 사항을 배우게 될 것입니다. Istio의 아키텍처에 대해 설명 할 세션이 있습니다. 특사 조종사 시타델과 같이 여러분이 들어 보셨을 모든 유행어, 그리고 글쎄요, 그 말이 꽤 많이 있습니다.

그러나 지금은 Istio가 높은 수준에있는 것에 대한 느낌을 얻을 것입니다.

그렇다면 Istio는 무엇입니까? 글쎄, Istio는 서비스 메시로 알려진 것의 한 예일뿐입니다.

그래서 Istio가 무엇인지에 대한 질문에 답하기 위해? 글쎄, Istio가 서비스 메시라고 말할 수 있습니다.

좋아요, 그것은 우리가 서비스 메시가 무엇인지 알아야한다는 것을 의미합니다. 적어도 기록 할 때 서비스 메시의 개념은 상대적으로 새로운 것입니다.

또는 적어도 최근에야 인기를 얻고 많이 사용되었습니다.

점점 더 많은 실제 프로젝트가 클러스터 기반 마이크로 서비스 아키텍처를 사용함에 따라 Kubernetes와 같은 기존 프레임 워크만으로는 충분하지 않다는 사실을 업계로 발견하기 시작했기 때문에 서비스 메시가 인기를 끌 수 있다고 생각합니다.

사실이 비디오에서 Kubernetes에 대해 언급 한 것은 이번이 처음입니다.

따라서 저는 서비스 메시가 Kubernetes를 대체하는 것이 아니라 실제로 Kubernetes와 함께 배포하는 소프트웨어의 추가 계층이 될 것이라는 점을 지적해야합니다.

그리고 너무 멀리 가기 전에 서비스 메시가 Kubernetes에만 국한되지 않는다고 말해야합니다.

여러 소프트웨어 구성 요소가 서로 네트워킹되어있는 모든 종류의 분산 아키텍처는 서비스 메시의 이점을 누릴 수 있습니다.

제가이 과정을 적어도 Kubernetes는 분산 아키텍처 구축을위한 가장 성공적인 프레임 워크라고 부르는 것처럼 오케스트레이션 프레임 워크라고 부르는 것은 그 당시 제가이 과정을 적어도 Kubernetes라고 할 때입니다.

따라서이 과정에서는 Kubernetes를 대상으로하는 마이크로 서비스 아키텍처에 계속 초점을 맞출 것입니다.

하지만 Kubernetes를 사용하는 한 비 마이크로 서비스 아키텍처를 구축하기 위해 Kubernetes를 사용하는 경우이 과정이 적합합니다.

아직 서비스 메시가 무엇인지 아직 말하지 않았지만 Kubernetes에서 실행중인 표준 마이크로 서비스 아키텍처에 대해 생각해 보겠습니다.

아시다시피, 우리는 쿠 버네 티스 팟 (Pod) 전체를 갖게 될 것입니다.

그리고 각 포드에는 일반적으로 컨테이너가 포함됩니다.

아시다시피 pod 안에 여러 개의 컨테이너를 가질 수 있지만 각 pod 안에 단일 컨테이너를 두는 것은 매우 표준입니다.

이제 Kubernetes 내부의 서비스 검색 메커니즘을 사용하여 모든 컨테이너에서 다른 컨테이너로 네트워크 호출을 수행 할 수 있으므로 이러한 컨테이너는 모두 네트워크로 연결됩니다.

물론 쿠 버네 티스를 알고 있으므로이 모든 것에 대해 잘 알고 계시길 바랍니다.

이제 잘못된 Kubernetes 배포의 문제는 Kubernetes가 포드를 처리하고 관리하는 데 매우 능숙하다는 것입니다.

예를 들어 어떤 이유로이 부분을 서비스에서 제외하려면 큐브 API에 명령을 내리거나 큐브 CTL 명령을 실행하거나 일부 yamo를 수정하고 적용하면 Kubernetes가 해당 shedule에 응답합니다. 그 부분을 서비스에서 완전히 벗어나게 할 것입니다.

하지만 쿠 버네 티스가 그다지 잘하지 않는 것은 우리에게 가시성 또는 포드 간의 상호 연결을 관리하거나 제공하는 것입니다.

예를 들어 여기 컨테이너가 여기 컨테이너에 네트워크 호출을 할 수 있다는 것을 알고 있습니다.

그러나 이와 관련하여 무슨 일이 일어나고 있는지를 추론하는 것은 쉽지 않습니다.

예를 들어,이 컨테이너 내부에 결함이있어 이러한 네트워크 요청 중 일부가 충족되지 않을 수 있습니다.

이 컨테이너가 문제가 있다는 것을 안다면 당연히 해당 컨테이너의 소프트웨어를 조사하거나 해당 컨테이너의 로그를 살펴보고 무엇이 잘못되었는지 알아낼 수 있습니다.

그리고 나는 당신이 그런 종류의 운동을하는 것에 대해 잘 알고있을 것이라고 확신합니다.

그러나 어떤 컨테이너가 실패하는지 알면 괜찮습니다.

그러나 마이크로 서비스가 1000 개라면 이러한 부분간에 가능한 네트워크 호출 조합이 셀 수 없을 정도로 많을 것입니다.

표준 Kubernetes만으로는 컨테이너 간의 연결에 대한 가시성이나 제어가 없습니다.

이것이 바로 서비스 메시가 도움이 될 수있는 곳입니다.

반드시 이와 같이 구현되는 것은 아니지만 서비스 메시를 시스템의 모든 포드 아래에있는 일종의 소프트웨어 계층으로 생각할 수 있습니다.

지금은 아직 기술적으로 정확하지 않습니다.

그러나 이것은 여러분이 이것에 대해 생각할 수있는 방식의 정신적 모델에 가깝습니다. 우리는 Istio가이 모든 것을 어떻게 구현하는지 정확히 살펴볼 것입니다.

하지만 개념적으로 우리가 할 일은 클러스터를 통해 실행되는 모든 네트워크 트래픽이이 서비스 메시 소프트웨어를 통해 라우팅되거나 라우팅되도록 어떻게 든 설정하는 것입니다.

예를 들어 보겠습니다.

여기에있는 컨테이너는 여기이 부분의 컨테이너와 대화하려고합니다.

그래서 우리는 네트워크 호출을 할 것입니다.

전통적으로 우리는 Kubernetes를 사용하여이를 수행했습니다.

서비스 개념으로서 저는 여기에 서비스를 넣는 것을 귀찮게하지 않았지만,이 컨테이너에서이 포드를 나타내는 서비스가 호출되는 모든 것에 네트워크 호출을 할 것이라는 것을 알고 있습니다.

그러면 두 컨테이너간에 직접 호출이 발생합니다.

그러나 서비스 메시를 사용하여 모든 호출이이 서비스 메시를 통해 전달되도록 설정하고 컨테이너가 실제로 대상 컨테이너를 호출하지 않도록 만들 것입니다.

대신 네트워크 요청이 서비스 메시로 라우팅 된 다음 서비스 메시가 호출을 대상 컨테이너로 전달하는 역할을합니다.

글쎄요, 이것이 상당히 비효율적으로 보이는 이유는 무엇입니까?
그러나 요점은 호출이 대상 컨테이너로 라우팅되기 전에 서비스 메시가 일부 논리를 구현하거나이 복잡한 논리가 실행될 수 있다는 것입니다.

대상 컨테이너가 완료되고 반환 된 후.

이 컨테이너는 http 200을 반환 할 수 있습니다.

서비스 메시로 돌아가서이 로직은 호출이 이루어진 후 실행될 수 있습니다.

또는 둘 다의 조합 일 수도 있습니다.

이제 저는 여기에서 매우 모호합니다.

이 메시 로직은 무엇입니까? 글쎄, 그것은 무엇이든 될 수 있습니다.

하지만 제가 이것을 기록 할 당시 모든 사람들이 서비스 메시에서 찾고있는 큰 기능은 원격 측정과 같은 것입니다.

따라서 원격 측정은 메트릭 수집을위한 멋진 단어 일뿐입니다.

아마도 Kubernetes 클러스터에서 작업하고 있다면 Prometheus 및 grafana와 같은 것을 사용하여 클러스터의 전반적인 상태에 대한 메트릭을 수집하는 데 익숙했을 것입니다.

이것은 정말 같은 것입니다.

그러나 여기서는 개별 네트워크 요청에 대한 메트릭을 수집하고 있습니다.

예를 들어 서비스 메시에서 요청을 수신 할 때마다이 요청을 수신 한 시간을 기록한 다음 요청을 대상 컨테이너로 전달할 수 있도록이 작은 메시 로직을 만들 수 있습니다.

그리고 그것이 반환 될 때, 메시 로직은 그 요청이 걸린 시간을 계산할 수 있고, 그것이 오류이든 성공이든 응답 코드를 기록 할 수 있습니다.

그리고 그 모든 것을 데이터베이스 어딘가에 저장할 수 있습니다.

이는 시간이 지남에 따라이 원격 측정의 결과를 검사 할 수 있다는 것을 의미합니다. 예를 들어 특정 서비스가 너무 많은 오류를 반환하는지 확인할 수 있습니다.

그리고 서비스 메시가 없으면 그런 종류의 정보를 얻기가 정말 어려울 것입니다.

그러나 서비스 메시가 여기에 삽입 할 수있는 다른 많은 기능이 있습니다.

이 과정에서 이러한 모든 기능을 살펴 보겠습니다.

또 다른 큰 기능은 단일 사용 사례를 구현하기 위해 모든 종류의 와이어 인 임의의 복잡한 네트워크 호출 체인을 사용할 수있는 추적입니다.

우리는 그 체인이 정확히 무엇인지, 체인의 각 단계가 얼마나 걸 렸는지, 그리고 그 체인에서 정확히 무슨 일이 일어나고 있는지 알려주는 메시를 얻을 수 있습니다.

그것은 매우 어려운 일입니다.

정규 분산 클러스터에서.

보안을 구현할 수도 있습니다. 서비스 메시의 방대한 기능은 트래픽 관리입니다.이를 통해 특정 요구 사항에 따라 요청을 다시 라우팅하는 것과 같은 매우 영리한 작업을 수행 할 수 있습니다.

그래서 그것은 일반적으로 서비스 메시이고, 저는 항상 이것이 우리의 모든 트래픽이 통과 할 부분 아래에있는 일종의 레이어라고 생각할 것입니다.

이것이 서비스 메시가 일반적으로 작동하는 방식입니다. 아마도 서비스 메시를 구현할 수있는 방법은 1000 가지가 될 것입니다.

이 과정에서 Istio를 위해 여기에 있습니다.

이제 Istio가 서비스 메시를 구현하는 방법에 대해 설명하겠습니다. Istio가 제공하는 트릭은 일반적으로 내부에 단일 컨테이너 만있는 시스템의 각 포드에 대한 것입니다.

Istio는 자체 컨테이너를 주입하거나 추가 할 것입니다.

이 컨테이너를 프록시라고합니다.

그리고 그것은 단지 용기입니다.

이제 여기에서이 컨테이너가 여기에서이 컨테이너에 네트워크 호출을하는 시나리오를 다시 살펴 보겠습니다.

Istio에서는 컨테이너의 네트워크 요청이 프록시로 라우팅되거나 라우팅되도록 설정되어 있습니다.

메시 로직을 구현할 수 있습니다.

잠시 후에 메시 로직으로 돌아오겠습니다.

이제이 과정에서 고급이 강철 내부 과정이나 그 밖의 것을위한 Istio에 대해 자세히 설명하지 않겠습니다.

그러나 궁금한 경우 Istio가 여기 컨테이너에서 몇 가지 IP 테이블 구성을 수행했을 것입니다.

따라서 컨테이너는 원격 호출을한다고 생각하지만 실제로는 프록시를 호출하는 것입니다.

이 시점에서 프록시는 이전에 얘기했던 메시 로직을 주입 할 수 있습니다.

따라서 프록시는 해당 호출을 대상 포트 프록시로 중계하는 역할을합니다.

다시 말하지만 여기에 메시 로직이있을 수 있습니다.

그러나 궁극적으로 콘텐츠, 대상 컨테이너는 해당 호출을 수신하게됩니다.

그리고이 요청의 결과로이 컨테이너가 스토리의 다른 부분에서 컨테이너를 호출해야 할 수도 있습니다. 요청은이 프록시를 통해 새 대상 프록시로 라우팅 된 다음 대상 컨테이너로 라우팅됩니다.

따라서 개념적으로는 한 단계 뒤로 돌아 가면 서비스 메시가 모든 포드 아래에있는 것으로 생각하고 모든 트래픽이이 메시를 통해 라우팅됩니다.

그러나 실제로는 모든 포드 내부에 배치되는 프록시로 구현됩니다.

따라서 실제 구현은 서비스 메시의 개념적 모델과 다르지만 최종 결과는 동일합니다.

이 모델로 돌아가서 시스템의 각 포드 내부에 프록시가 있습니다.

이것의 전체 목적은이 프록시가 한 컨테이너에서 다른 컨테이너로 요청이 이루어지면서 우리가 좋아하는 로직을 추가 할 수 있다는 것입니다.

이 작업이 Istio에서 작동하는 방식으로 시나리오를 다시 살펴 보겠습니다.이 컨테이너에서이 컨테이너로 호출 할 때 해당 호출은이 프록시를 통해 다시 라우팅되거나 다시 라우팅됩니다.

이론적으로이 프록시는 Istio에서만 할 수 있습니다. 작동 방식은 응용 프로그램과 함께 원하는 경우 전체 pod를 실행하는 것입니다.

이는 Istio 시스템이라는 자체 네임 스페이스에있는 Istio 포드의 자산입니다.

그리고 내부에는 Istio 자체를 효과적으로 실행하는 포드가 있습니다.

이제 Istio의 이전 버전에는 Istio 시스템 네임 스페이스 내부에 많은 포드가 있었고 모두 조종사, 요새 및 갤리와 같은 매우 이국적이고 이상한 이름을 가졌기 때문에 이것은 과정의 업데이트입니다.

그리고 다른 몇 가지가 있습니다.

이제 각 포드의 책임 영역이 다릅니다.

예를 들어 한 포드는 원격 분석을 담당하고 다른 포드는 트래픽 라우팅을 담당합니다.

다른 포드는 나중에 적용 할 YAML의 유효성을 검사했습니다.

따라서 Istio의 이후 버전에서는 매우 복잡한 네임 스페이스 팩트 북이었습니다. 이것은 버전 1.5에서 나왔습니다.

그래서 아마 당신이 이것을 볼 때, 이것은 지금 꽤 오래 전일 것입니다. stos 내부 전체가 고려되었습니다.

기본적으로 단순화되었습니다.

그리고 모든 복잡한 포드 대신 기본적으로 Istio 전체가 이제 단일 포드로 구현됩니다.

그리고 그 꼬투리는 'This is Cod'라고 발음하는 방법을 잘 모르겠습니다. 어떤 사람들은 이것을 이상하다고 부르고 실제로 Istio 악마를 의미합니다.

또한 이것이 대부분의 stos 기능이이 포드 내부에 구현되어 있다고 생각하면 훨씬 간단합니다.

Istio D가 담당하는 일 중 하나는 통계 수집입니다.

즉, 시스템에 대한 원격 측정입니다.

이 프록시는 모두이 Istio 포드를 알고 있습니다.

따라서 프록시는 논리를 구현하기 위해 이러한 포드를 호출 할 수 있습니다.

예를 들어이 Istio 텔레 메 트리 포드가 수행 할 수있는 한 가지 작업은 특정 요청이 이루어진 시간과 날짜를 기록한 다음 프록시가 계속해서 대상 프록시를 호출하여 대상 컨테이너로 라우팅 될 수 있다는 것입니다.

컨테이너는 논리를 수행하고 시간이 오래 걸립니다.

그러나 반환 체인이 여기에 도달하면 프록시는 요청이 반환 된 시간과 날짜를 사용하여 Istio 원격 분석 포드를 다시 호출 할 수 있으며 상태 코드 및 흥미로운 내용을 기록 할 수 있습니다.

그리고이 원격 분석 포드가 해당 데이터를 어딘가에 모을 수 있다면 물론 해당 데이터를 조사 할 수 있고 특정 호출이 실패하거나 너무 오래 걸리는지 여부를 확인할 수 있습니다.

몇 분 안에 이에 대한 데모가 있습니다.

계속 진행하기 전에 Istio 문서에서 이러한 전문 용어를 볼 수 있습니다.

첫 번째 전문 용어는 데이터 플레인입니다.

오래된 데이터 플레인은 실제로 아키텍처에서 실행중인 모든 프록시, 데이터 플레인 또는 Istio가 시스템에 넣은 프록시를 총칭하는 용어입니다.

이와 대조적으로 해당 Istio 시스템에서 실행중인 모든 포드.

즉, 실제로 stos 기능을 구현하는 포드를 통칭하여 컨트롤 플레인이라고합니다.

이전에 언급했듯이 이것은 예전에는 매우 복잡한 네임 스페이스 였고, 컨트롤 플레인 내부에는 많은 포드가 있었고, 이러한 부분의 모든 이름을 배워야했습니다.

컨트롤 플레인 내부가 훨씬 더 간단 해졌다는 것은 정말 좋은 소식입니다.

컨트롤 플레인의 핵심은 Istio 악마라고 부르는 단일 포드입니다.

그러나 컨트롤 플레인 내부에는 몇 개의 포드가 있습니다.이 과정을 진행하면서 만나게됩니다.

하지만 기본적으로는 사용자 인터페이스 파크입니다. 우리는 kiali라는 프로그램과 같이 여러 가지 사용자 인터페이스를 만나게 될 것입니다. 예를 들어 pod를 시각화하고 서로 연결하는 방식을위한 매우 깔끔한 사용자 인터페이스입니다.

그래서 그것은 컨트롤 플레인 내부의 포드로 구현됩니다.

녹음 당시이 컨트롤 플레인에는 약 6 개의 다른 포드가 있습니다.

지금 당장 정보로 과부하를주지 않을 것입니다.

하지만 데모를 시작하자마자 그 포드를 보게 될 것입니다.

이것이 데이터 플레인과 비교 한 컨트롤 플레인입니다. 데이터 플레인은 Istio가 각 파트에 추가 한 프록시 세트입니다.

마지막으로 언급하지 않은 것이 하나 있습니다.이 모든 작업을 수행하기 위해 컨테이너에 어떤 변경을해야하는지 말씀하지 않았습니다. Istio에 대한 대답입니다.

사실 좋은 서비스 메시에 대한 대답은 컨테이너를 변경하지 않아도되며 서비스 메시에서 실행되는지 여부는 중요하지 않다는 것입니다.

따라서 Istio는 응용 프로그램에 침입하지 않습니다. 서비스 메시를 클러스터에서 켜거나 끄는 것으로 생각할 수 있으며 응용 프로그램의 기능에 영향을주지 않습니다.

그러나 그것은 이상적인 종류입니다. 실제로 Istio가 컨테이너에 대한 몇 가지 요구 사항을 만드는 한 영역이 있습니다.

그리고 그것은 추적과 관련이 있습니다.

따라서 코스의 추적 섹션에 도달 할 때까지이를 보류하겠습니다.

그러나 지금은 Istio가 컨테이너 내부에 넣는 실제 코드에 최소한 영향을 미치지 않아야한다고 말하는 것으로 충분합니다.

그래서 그것은 매우 높은 수준의 Istio를위한 것입니다.

더 많은 세부 사항은 아직 올 것입니다.

하지만 지금은 Istio가 무엇인지에 대해 최소한 이해했으면합니다.

하지만 Istio에 대해 정말 적절한 느낌을 얻기 위해 Istio와 함께 플레이 할 수 있다면 좋을 것 같습니다. 다음 비디오에서는 그렇게 할 것입니다.