Page History

So we're working on a service mesh.

And there are lots of service mesh implementations out there.

Istio is just one of them.

And the way that Istio implements a service mesh is by using proxies.

The idea is that if a particular container is making a call to another container in our cluster, then the magic is the calls are routed or routed via these proxy components.

And you also know that they're implemented as sidecar containers in Kubernetes.

So already, we have two terms for this proxy.

If you're working on an Istio cluster, and somebody says, oh, the proxy in my pod is failing, you know that they're probably talking about the Istio proxy.

But they might also say, Oh, my sidecar is failing in my pod.

And that also usually would mean proxy.

But something that we've not looked at is where does this proxy come from, and I can tell you that Istio has not implemented this proxy.

In fact, you're going to find a lot of Istio comes from third party components that have been very cleverly assembled together to give a sort of easy to use, well, a relatively easy to use service mesh.

The proxy in Istio comes from an open source project called envoy.

Here I am on the envoy websites, it's at envoy proxy.io.

So envoy has been developed kind of completely independently to Istio.

And envoy is just a proxy for cluster based applications.

Now info isn't particularly written with Kubernetes in mind.

Kubernetes is just one environment that envoy can run in, just in case you're interested envoy came from lyf, which you might well be familiar with.

Lyft are not a well known name in the UK at the time, I'm recording this, I think they're currently a US and Canada operation.

So taxi scheduling, like Uber, basically.

So they anyway, they originally created this.

And they claim it's used by the claim it's used by absolutely everybody.

If we go down to the features here, basically, many of the features that I've been saying, we get from Istio in the service mesh are actually coming directly from envoy.

So for example, things like circuit braking a little bit like we did in the warm up demo application.

What we were doing there when we made that change to a yaml file was we were in fact, configuring envoy.

So we will making changes to the proxy and the tracing.

When we used Jaeger, and we used kiali.

Those features were actually coming as a as a result really of envoy gathering the metrics that we need.

So envoy really is a critical component of Istio a lot of the features that we have are coming directly from envoy.

So you might be wondering, Well, why don't we just use envoy.

And that's certainly a good arguments.

And there are probably some projects do use envoy without Istio.

But envoy does need a supporting environment around it.

And you do need additional tools to make it really to make it usable just think of envoy as being a very low level tool.

And it's not very easy to work with at a sort of engineering level.

In the next video, which I'm going to make an optional video, I know some of you will want to have a little bit of a play with MVP.

So we'll do a very short demo and a very simple demo on getting envoy up and running on its own, which might give you a taste for envoy.

But for 90% of this course we're going to be letting Istio manage envoy.

And believe me that really does make your life a lot lot easier.

But before we go any further, let's just update this picture now.

And a really annoying thing about these proxies is that you've basically got three words for them.

You could call it the proxy, you could call it the sidecar.

You could call it envoy.

Or you can use any combination of these three terms.

So don't be surprised if on your project your manager says, Hey, can you debug this envoy proxy? Or this envoy sidecar? Or can you debug my sidecar proxy? Or can you deal with my envoy proxies? It is really weird that we've got this very overloaded term in Istio but for our purposes, those three words mean the same thing or any combination thereof.

So one question that you might have here.

And I certainly felt this myself when I started on my Istio journey was given that these envoy proxies implement really most of the features that we're looking for from a service mesh, such as traffic management and telemetry, why don't we just use envoy? What is Istio bringing to the table? First of all? The answer is yes, she could absolutely go ahead yourself as a project and download envoy and build a service mesh for yourself.

That's perfectly possible and respectable routes to take.

But I certainly would not want to do that.

And over time, I've realised that Istio brings an awful lot to the table.

But as a sort of a quick answer, I'm going to say that the the thing about envoy is that it's very generic, it's capable of being deployed into many different types of cluster, it doesn't really have any particular connection with Kubernetes, it is just a proxy, you can download the source code from envoy, it's all in c++, and you can build it into a binary executable.

And so that means that really in envoy, there's no reference to Kubernetes at all, there's no real references to clusters.

It means that envoy has its own massive terminology, and its own set of concepts, all of its own.

And you would have to learn all of those concepts and terminologies and configurations.

And you would have to somehow map that into your Kubernetes clusters.

Now to explain, I've just gone to the envoy website.

And we really do not need to understand the invoice documentation at all.

I'm just using this as an illustrative example.

I'm pretty much the hello world example here.

And this is showing you how to bootstrap a simple envoy proxy, and to connect your components to it.

And if I just go a little further down, I'm just pointing here at this is a minimal bootstrap config file.

And I don't know how you feel about this config file, it depends on what kinds of things you've worked on, if you're used to configuring Apache or nginx service, and you'll see a lot of commonality in here.

But I want to really point out that there is absolutely nothing Kubernetes like inside here, there's a lot of talk about listeners, filter chains, virtual hosts, route conflicts, clusters, now, okay, we have a Kubernetes cluster.

But the definition of cluster in envoy is completely different to the definition of a Kubernetes cluster, we have references to load balancing here and endpoints and socket addresses, and so on.

And really, as a Kubernetes engineer, I don't really recognise any of this.

So if I wanted to use envoy in my Kubernetes cluster, I'm going to have to do a lot of work an awful lot of work to configure envoy properly.

So that's what Istio brings to the table.

And as a sort of sales pitch for Istio Istio really does simplify envoy if you're working on a cluster like Kubernetes.

So Istio really does understand Kubernetes.

Now by that I mean, when we're configuring these proxies, we are able to use regular Kubernetes yaml.

Well, not quite regular Kubernetes yaml, it's going to be these custom resource definitions.

So they are extensions to Kubernetes.

But that's fine, they're still Kubernetes objects, we're going to use kubectl apply as normal.

And then under the hood, our Kubernetes yaml is going to be transformed into envoy configuration automatically.

So as an Istio engineer, unless things go horribly wrong, you don't need to work at the level of envoy.

So you could think of his scales being an abstraction layer over the top of envoy.

It's not quite technically correct.

But do you know what that's good enough for me, I've just come back into the text editor to look at the YAML file that we applied back in the warm up exercise.

This is the file called for application full stack dot yaml in the warm up exercise, and the bulk of this is regular Kubernetes yaml that you will recognise with deployments.

And going a little further down.

We're going to find some services regular Kubernetes services, but we did a little bit of work a very short amount of work on this entry here around to line 207 C which we can tell comes from Istio because of its API version.

And it's this object called a virtual service.

So we don't know what a virtual service is yet, they will be covered in detail on this course.

But the configuration of this just feels very similar to the sorts of things you will have been doing in regular Kubernetes.

But I can now reveal that what was happening with this virtual services, this was being converted under the hood into configuration that envoy understands.

So I hope that's answering the question of what has Istio ever done for us.

It's hidden, the low level details of envoy is one thing.

So the proxies then supplied by envoy, which becomes sidecar containers on a Kubernetes platform, are, I think, the most critical components in the whole of Istio.

And I mentioned previously that the set of proxies are collectively called the data plane in Istio, that's the distinguish the proxies from the rest of Istio, which is called the control plane.

And the control plane used to be really complicated in earlier versions of Istio.

But now, it's essentially a single pod, called the Istio demon.

And actually, this video as replaced what used to be a very long section on this course, covering the architecture of Istio.

But in modern versions of Istio once you understand the fact that there are proxies running, they happen to be implemented by envoy, it doesn't really matter, you probably not need to understand the detail of envoy for a very long time, if ever, the overall architecture of Istio is very much simpler than it used to be, which is why this short video has been able to replace a very long chapter, but I do have a video coming up which looks in a bit more detail in envoy.

I've only put this video in the course for people who really really really want details on envoy.

You don't have to study the next video you can safely skip it.

If you're not interested in looking at the internals of envoy

그래서 우리는 서비스 메시에 대해 작업하고 있습니다.

그리고 많은 서비스 메시 구현이 있습니다.

Istio는 그중 하나 일뿐입니다.

Istio가 서비스 메시를 구현하는 방법은 프록시를 사용하는 것입니다.

아이디어는 특정 컨테이너가 클러스터의 다른 컨테이너를 호출하는 경우 이러한 프록시 구성 요소를 통해 호출이 라우팅되거나 라우팅된다는 것입니다.

또한 Kubernetes에서 사이드카 컨테이너로 구현된다는 것도 알고 있습니다.

이미이 프록시에 대해 두 가지 용어가 있습니다.

Istio 클러스터에서 작업 중이고 누군가 내 팟 (Pod)의 프록시가 실패한다고 말하면 아마도 Istio 프록시에 대해 이야기하고있는 것입니다.

그러나 그들은 또한 "오, 내 사이드카가 내 포드에서 작동하지 않습니다.

그리고 그것은 또한 일반적으로 프록시를 의미합니다.

하지만 우리가 보지 못한 것은이 프록시의 출처가 어디인지입니다. Istio가이 프록시를 구현하지 않았다는 것을 말씀 드릴 수 있습니다.

사실, 많은 Istio는 사용하기 쉽고 비교적 사용하기 쉬운 서비스 메시를 제공하기 위해 매우 영리하게 조립 된 타사 구성 요소에서 비롯된 것입니다.

Istio의 프록시는 envoy라는 오픈 소스 프로젝트에서 제공됩니다.

여기 저는 envoy 웹 사이트에 있으며 envoy proxy.io에 있습니다.

Envoy는 Istio와 완전히 독립적으로 개발되었습니다.

Envoy는 클러스터 기반 애플리케이션의 프록시 일뿐입니다.

이제 정보는 특별히 Kubernetes를 염두에두고 작성되지 않았습니다.

쿠 버네 티스는 envoy가 실행될 수있는 하나의 환경 일뿐입니다. 관심이있는 경우 envoy가 익숙한 lyf에서 온 경우에 대비해 사용할 수 있습니다.

Lyft는 당시 영국에서 잘 알려진 이름이 아니 었습니다. 저는 이것을 기록하고 있습니다. 현재 미국과 캐나다에서 운영되고있는 것 같습니다.

기본적으로 Uber와 같은 택시 일정.

어쨌든 그들은 원래 이것을 만들었습니다.

그리고 그들은 그것이 절대적으로 모든 사람들이 사용하는 주장에 의해 사용된다고 주장합니다.

여기서 기능으로 내려 가면 기본적으로 제가 말씀 드린 서비스 메시의 Istio에서 얻은 많은 기능은 실제로 envoy에서 직접 가져온 것입니다.

예를 들어, 워밍업 데모 애플리케이션에서했던 것처럼 회로 제동과 같은 것들이 있습니다.

yaml 파일을 변경했을 때 우리가했던 것은 실제로 envoy를 구성하는 것이 었습니다.

따라서 프록시와 추적을 변경합니다.

예거를 사용했을 때 키 알리를 사용했습니다.

이러한 기능은 실제로 우리가 필요로하는 메트릭을 수집하는 특사의 결과로 제공되었습니다.

따라서 envoy는 실제로 Istio의 중요한 구성 요소이며, 우리가 보유한 많은 기능이 envoy에서 직접 제공됩니다.

그래서 궁금하실 것입니다. 글쎄요, 우리는 단지 특사를 사용하는 것이 어떻습니까?

그리고 그것은 확실히 좋은 주장입니다.

그리고 아마도 Istio없이 envoy를 사용하는 프로젝트가있을 것입니다.

그러나 Envoy는 주변에 지원 ​​환경이 필요합니다.

그리고 실제로 사용하기 위해서는 추가 도구가 필요합니다. Envoy를 매우 낮은 수준의 도구라고 생각하면됩니다.

그리고 일종의 엔지니어링 수준에서 작업하는 것은 그리 쉽지 않습니다.

다음 비디오에서 옵션 비디오를 만들려고합니다. 여러분 중 일부는 MVP와 약간의 플레이를 원할 것임을 알고 있습니다.

그래서 우리는 아주 짧은 데모와 아주 간단한 데모를 할 것입니다. 엔보이를 시작하고 실행하는 것에 대한 아주 간단한 데모를 할 것입니다.

그러나이 과정의 90 %는 Istio가 특사를 관리하도록 할 것입니다.

그리고 그것이 정말로 당신의 삶을 훨씬 더 쉽게 만들어주는 것을 믿으십시오.

하지만 더 진행하기 전에 지금이 그림을 업데이트하겠습니다.

그리고이 프록시에 대한 정말 성가신 점은 기본적으로 세 단어가 있다는 것입니다.

프록시라고 부를 수 있고 사이드카라고 부를 수 있습니다.

특사라고 부를 수 있습니다.

또는이 세 가지 용어의 조합을 사용할 수 있습니다.

따라서 프로젝트에서 관리자가 "이 특사 프록시를 디버깅 할 수 있습니까?"라고 말하더라도 놀라지 마십시오. 아니면이 특사 사이드카? 아니면 내 사이드카 프록시를 디버깅 할 수 있습니까? 아니면 내 특사 프록시를 처리 할 수 ​​있습니까? Istio에 이처럼 과중한 용어가 있다는 것은 정말 이상합니다.하지만 우리의 목적을 위해이 세 단어는 같은 의미 또는 그 조합을 의미합니다.

여기에 한 가지 질문이있을 수 있습니다.

그리고 Istio 여정을 시작했을 때 이러한 특사 프록시가 트래픽 관리 및 원격 측정과 같은 서비스 메시에서 찾고있는 대부분의 기능을 구현한다는 사실을 직접 느꼈습니다. 사절? Istio가 테이블에 가져 오는 것은 무엇입니까? 가장 먼저? 대답은 그렇습니다. 그녀는 절대적으로 프로젝트를 진행하고 특사를 다운로드하고 서비스 메시를 구축 할 수 있습니다.

그것은 완벽하게 가능하고 존경할만한 길입니다.

그러나 나는 확실히하고 싶지 않습니다.

그리고 시간이 지남에 따라 Istio가 테이블에 많은 것을 가져다 준다는 것을 깨달았습니다.

그러나 일종의 빠른 대답으로, 저는 envoy가 매우 일반적이고 다양한 유형의 클러스터에 배포 할 수 있으며 실제로 Kubernetes와 특별한 연결이 없다는 것입니다. , 프록시 일 뿐이며 envoy에서 소스 코드를 다운로드 할 수 있으며 모두 C ++로되어 있으며 바이너리 실행 파일로 빌드 할 수 있습니다.

즉, 실제로 특사에서는 Kubernetes에 대한 참조가 전혀없고 클러스터에 대한 실제 참조도 없습니다.

이는 envoy가 자체적으로 방대한 용어와 자체 개념 세트를 가지고 있음을 의미합니다.

그리고 이러한 모든 개념과 용어 및 구성을 배워야합니다.

그리고이를 Kubernetes 클러스터에 어떻게 든 매핑해야합니다.

이제 설명하기 위해 방금 특사 웹 사이트로 이동했습니다.

그리고 우리는 송장 문서를 전혀 이해할 필요가 없습니다.

저는 이것을 예시로 사용하고 있습니다.

나는 여기에서 거의 hello world의 예입니다.

그리고 이것은 간단한 엔보이 프록시를 부트 스트랩하고 컴포넌트를 연결하는 방법을 보여줍니다.

그리고 조금 더 아래로 내려 가면 여기에 최소한의 부트 스트랩 구성 파일이 있습니다.

이 구성 파일에 대해 어떻게 생각하는지 모르겠습니다. Apache 또는 nginx 서비스를 구성하는 데 익숙한 경우 작업 한 종류에 따라 다르며 여기에서 많은 공통점을 볼 수 있습니다. .

하지만 여기 안에는 쿠 버네 티스가 전혀 없다는 점을 지적하고 싶습니다. 리스너, 필터 체인, 가상 호스트, 경로 충돌, 클러스터에 대해 많은 이야기가 있습니다. 이제 쿠 버네 티스 클러스터가 있습니다.

그러나 envoy의 클러스터 정의는 Kubernetes 클러스터의 정의와 완전히 다르며 여기에로드 밸런싱, 엔드 포인트 및 소켓 주소 등에 대한 참조가 있습니다.

그리고 실제로 쿠 버네 티스 엔지니어로서 저는 이것을 전혀 인식하지 못합니다.

따라서 내 Kubernetes 클러스터에서 envoy를 사용하려면 envoy를 올바르게 구성하기 위해 많은 작업을 수행해야합니다.

이것이 Istio가 테이블에 가져온 것입니다.

그리고 Istio에 대한 일종의 판매 피치로서 Kubernetes와 같은 클러스터에서 작업하는 경우 Istio는 실제로 Envoy를 단순화합니다.

따라서 Istio는 실제로 Kubernetes를 이해합니다.

이제 이러한 프록시를 구성 할 때 일반 Kubernetes yaml을 사용할 수 있습니다.

음, 일반적인 Kubernetes yaml은 아니지만 이러한 사용자 지정 리소스 정의가 될 것입니다.

따라서 그들은 Kubernetes의 확장입니다.

하지만 괜찮습니다. 여전히 Kubernetes 객체이므로 kubectl apply를 정상적으로 사용할 것입니다.

그런 다음 내부적으로 Kubernetes yaml이 자동으로 envoy 구성으로 변환됩니다.

따라서 Istio 엔지니어는 일이 끔찍하게 잘못되지 않는 한 특사 수준에서 작업 할 필요가 없습니다.

따라서 그의 비늘이 특사 위에있는 추상화 레이어라고 생각할 수 있습니다.

기술적으로는 정확하지 않습니다.

하지만 그것이 저에게 충분한 지 알고 계십니까? 저는 방금 워밍업 연습에서 다시 적용한 YAML 파일을보기 위해 텍스트 편집기로 돌아 왔습니다.

이것은 워밍업 실습에서 애플리케이션 전체 스택 dot yaml에 대해 호출되는 파일이며,이 중 대부분은 배포시 인식 할 일반 Kubernetes yaml입니다.

그리고 조금 더 내려갑니다.

일부 서비스 일반 Kubernetes 서비스를 찾을 것입니다.하지만 API 버전으로 인해 Istio에서 가져온 207 C 행까지이 항목에 대해 매우 짧은 작업을 수행했습니다.

그리고 그것은 가상 서비스라고 불리는이 객체입니다.

따라서 우리는 아직 가상 서비스가 무엇인지 모릅니다.이 과정에서 자세히 다룰 것입니다.

그러나 이것의 구성은 일반 쿠 버네 티스에서 할 일과 매우 유사하게 느껴집니다.

하지만 이제이 가상 서비스에서 무슨 일이 일어나고 있는지 알 수 있습니다. 이것은 내부에서 Envoy가 이해하는 구성으로 변환되고 있다는 것입니다.

그래서 나는 그것이 Istio가 우리를 위해 한 일에 대한 질문에 답하기를 바랍니다.

숨겨져 있고, 사절의 낮은 수준의 세부 사항이 한 가지입니다.

따라서 쿠 버네 티스 플랫폼에서 사이드카 컨테이너가되는 envoy가 제공하는 프록시는 Istio 전체에서 가장 중요한 구성 요소라고 생각합니다.

앞서 언급 한 바에 따르면 Istio에서는 프록시 집합을 집합 적으로 데이터 플레인이라고합니다. 이것이 컨트롤 플레인이라고하는 Istio의 나머지 부분과 프록시를 구분하는 것입니다.

컨트롤 플레인은 이전 버전의 Istio에서 정말 복잡했습니다.

그러나 이제는 본질적으로 Istio 악마라고 불리는 단일 포드입니다.

실제로이 비디오는 Istio의 아키텍처를 다루는이 과정에서 매우 긴 섹션을 ​​대체했습니다.

그러나 Istio의 최신 버전에서는 프록시가 실행되고 있다는 사실을 이해하면 envoy가 구현하게됩니다. 실제로 중요하지 않습니다. 아마도 envoy의 세부 사항을 오랫동안 이해할 필요가 없을 것입니다. , Istio의 전체적인 아키텍처는 예전보다 훨씬 간단합니다. 그래서이 짧은 비디오가 매우 긴 챕터를 대체 할 수 있었지만, 특사에서 좀 더 자세히 보이는 비디오가 올 것입니다.

이 비디오는 정말 특사에 대한 세부 사항을 정말로 원하는 사람들을 위해 코스에 넣었습니다.

다음 비디오를 공부할 필요가 없습니다. 안전하게 건너 뛸 수 있습니다.

Envoy의 내부를 보는 데 관심이 없다면