Page History

Welcome back.

And in this section, we're going to build on our knowledge of virtual services and destination rules from the previous section.

So we're still doing traffic management.

But now we're going to discover what Istio gateways are, and why you probably need one.

So yeah, if you've done any work on Istio in the past, you've probably come across Ingress gateways.

And I have to say that really, in the Istio documentation, they don't do a very good job of explaining why you need to set up an Ingress gateway, or even what it is.

So I'm hearing the documentation and at the time of recording, they say, in a regular Kubernetes environment, then you can set up a Kubernetes Ingress resource, and that choose to specify services that should be exposed outside the cluster.

I don't know if you work with Kubernetes Ingress before.

If not check out any decent Kubernetes training course there should be a section on Ingress in there.

But a very short description of a Kubernetes Ingress resources, that's a way of exposing multiple services to the outside world without needing lots of expensive load balancers.

And I mean, here hardware load balancers, I won't go into detail on that.

If you've used them before, then you know about them.

If you haven't used them before, then it's not urgent.

But it would be worthwhile that you pick up that standard Kubernetes information.

But what they're saying here is, and the second sentence, in an Istio service measure a better approach is to use a different configuration model, namely, an Istio gateway.

And then they don't go on to say anything about why why do we need this replacement for what we've presumably had in the past that was working absolutely fine.

This might have changed by the time you read the documentation.

But I'm moaning again that when I started working with Istio, I was looking at this and thinking, well, I don't know what this Istio gateway offers me, I don't know why I need one.

And I was just completely lost.

So that's the point of this course, to tell you why you probably do need to configure this Ingress gateway is very useful.

And you will very likely be replacing your existing Kubernetes standard plane Ingress controller with the Istio version.

But why? Well, this is supposed to be a practical course.

So I'm going to explain through a practical requirement.

You're all familiar now with canaries, and how we can implement canaries using virtual services.

So we have a new experimental front end that's been developed, the developers have pushed this to Docker Hub, and they given it the tag of six dash experimental.

So that's available to us.

And we can now deploy that into our cluster.

But the requirement is that it's a potentially risky release, we don't want to risk millions of support tickets coming in.

So we're going to do this in a staged manner, we're only going to deploy this to 10% of requests.

So this is easy.

We know how to do this, we did it in the previous section, it should be easy, you can probably guess that there's a catch.

I wonder if you can spot what the catch is? Why is this not going to work based on what we learned in the previous section? Well, of course, I'll explain why it doesn't work.

But let's just try it.

So for the practicals, if you have come straight to this section, or you're starting with a brand new minkube that you've just started up, then I've supplied a set files for you in the folder called three gateways.

And that's in the downloads for this course.

And I will assume you know by now that the routine is you need to apply the YAML files in order.

The order is particularly important for the first and the second.

And you need to give each of those time to complete before you move on to the rest.

So if you are starting from a clean sheet, you will find that this file called six Istio rules is actually blank.

So we haven't got any special traffic management going on.

There's no canaries or anything like that.

However, I know many of you will have rolled on from the previous section, and I certainly have so I've still got some work left behind from the previous section where we were doing canaries.

So what you will need to do to get a nice clean starting points is do a kubectl deletes dash F on that file six Istio rules.

And I think we also created the seventh version in that previous session, that seventh version was the demonstration of sticky sessions.

So if you have that, then delete that as well.

And I'm going to go into that file.

Now this is six Istio rules.

And I'm going to delete the contents of that file and save it.

Because of course, we're going to do some special configurations in this session.

But also in the fifth file the application no istio.

Going further down, you'll recall, we set up a canary for the staff service.

So we have, so don't know what state your file is in.

But I currently have one replica of this image called six placeholder, we don't want that anymore, because we're not doing a canary on this.

So I suggest we change the replicas of that down to zero.

Again, if you come straight to this session, and using the predefined files for this section, then you'll find that's already been done.

And going further down into what was the risky version of the staff service.

Yeah, that's okay, we'll leave one replica of that running.

So kubectl, apply on those changes.

And we should be able to verify now with the cube CTL.

Get PL Yeah, I've got a staff service terminating.

So going back just to one pod for staff service won't be doing any fancy traffic management on that service in this session will be worth checking that this is working.

So back to the front end, as always, the minkube address colon 30,080 should give you the fleet manager front end.

And now regardless of which vehicle we visit, we should be getting a nice photograph for the staff.

So if you're in this position, you're now ready to attack the challenge of creating a canary for the front end.

So we're going to try to implement that Canary then using all of the theory that we had in the previous section.

And the starting point is to modify the standard Kubernetes yaml.

We only to find the yaml for the web app deployments, and you should find it starting at line 70.

So this is the standard Image, Image version six.

And just as before, we're going to add in some labels to here.

So we have the app web app label, but we're going to put in a version for this.

And the version is going to be as always, you can use anything you like here.

So I'm going to call it the original version.

So that should be okay, but we want a new deployment.

So I'll take a copy of this entire deployment block and paste it in afterwards.

This is from line 92 onwards.

So we have a second version.

And be careful here, I always forget to do this, you will need a unique name for it or it just gets ignored and you get really confused.

So let's call this web app dash x veteran mental.

So therefore, the version tag for this will be experimental.

And the important thing is to change the image here, this is going to be image six dash, experimental.

I have previously built an image for this and uploaded it to Docker Hub.

So that should be enough.

Now.

If we apply that file, so this is file number five, application, no Istio, and I'll put a watch on kubectl get po and we should see, actually the previous pod is going to be terminated so that those labels can be applied.

The labels are immutable, so it has to terminate the old pod.

So the end result of this.

Luckily, the web app pops up pods are quite lightweight.

So I don't think we'll have problems with resources here.

After a few seconds, about half a minute for me, you should now have the old web app, the experimental web app.

And both of them should be up and running.

I'm going to spoil it a bit.

Now this experimental new web app, it just has a red banner on the top, I didn't have time to do anything fancy.

So what should happen now is bear in mind, we haven't got any Istio configuration on this yet.

But we do have two pods, each with a different image servicing the minkube address colon 30,000.

And remember, we're just start using standard Kubernetes here.

So that Port 30,080 is if I do a kubectl get SVC that will confirm that we have a Fleetman web app service which is configured as a node port on 30,080.

And we've got the two pods behind that node port.

So the Kubernetes feature of a node port should be now balanced.

Seeing the traffic between the old and the new version.

Now the balancing is a bit random.

So if I do a refresh, so I've got the old one, the new one, so you should be able to recognise the new one very easily with the big red banner.

And the new one, new one, new, new send out some getting a long run of news before I've gone back to the old, don't expect this to be an exact 5050 balancing.

I can't remember the exact details of that.

But it is related to the way that Kubernetes is implementing that node port.

Now, I have had problems with caching on this Angular app.

And I'm not an Angular developer.

So I've had to hack around a little bit.

If you're having any kind of problems here, you might need to delete your cache, or do a hard refresh.

So I think on Chrome, a hard refresh is a control and refresh or Ctrl f5.

That'll be a command on Macintosh.

And if you're running on Firefox, I think Ctrl f5, should do the job.

Now I have struggled with this off camera, I've had it working a few times and then it sort of randomly stopped working.

So caches can be very difficult to get working.

But it seems okay now on the recording, just in case at home, you have any problems, I would actually recommend that you do this using curl to remove all of the vagaries of different browsers.

So you can do a curl on your minkube IP address.

For me at the moment, it's ending 167 colon 30,080.

problem with that is it's just a Angular app.

So you're just going to get sort of a header.

And all of the logic is implemented in JavaScript, but I have set the title to vary.

So if you're following along, and you maybe don't have a bash shell, you could just visually check what you're getting as a result of the title.

Or if you want a decent decent bash shell, you could do that curl, and then pipe the output into a grep.

And we'll just grep for the string title.

And that should just isolate the one line that will vary.

Depending on which version we get, you might want to add the dash s.

Option into curl and that will remove the progress indicator.

So I've got the new version, new version, old version, old version, old, old, old, so get these long runs of them.

But I think we're seeing a roughly 5050 balance.

Anyway, that's just setting up the points of this is we want to set up a 9010 Canary.

So you know how to do that, in principle, as in the previous videos, you could write some yaml, you're going to need a virtual service in a destination role.

Or you can cheat and you can generate that yaml using kiali.

There's a few ways we can do that, we could go to the service graph and find the Fleetman web app service.

Now be careful here.

If you've not used that web app recently, then that service might not be appearing on the graph.

If that's the case, make sure you go to the front end and do a few refreshes there.

And then on the triangle here, we can right click and get into the details of the service.

Now because I'm recording this in the update for the course I just want to mention if you go to the version dap graph, which actually a little bit more useful here, because we can see the two versions that we're deploying the experimental version, and the original version of this web app.

The problem is in recent versions of kiali, this didn't used to be the case.

But in more recent versions on the version graph, we don't by default, see any of the services, they've sort of tidy it up this diagram a little bit.

So if you're disappointed with that, if you'd like to be able to see the experimental and original versions, and you'd like to be able to click through from here to get to the services details, then you can easily drop down this display list and check the checkbox for service nodes.

And that gets the user interface back to how it used to be in earlier versions.

So I think this is a bit more useful for this use case we can see both versions of the pods.

But we can also see the corresponding service.

So I'm going to go through this routes.

We can right click there and click on Show Details.

We can now go to the actions link here, just as we did previously, we can create a weighted routing.

And I think what we're looking for then is for the original version of the web app to be a 90% waiting and this new experimental version to just be 10% So we'll do that, and then click on Create.

And in theory, it should be as easy as that, well, you know, this isn't going to work.

And perhaps you want to think about why it's not going to work.

It's quite subtle.

But it's a kind of a really crucial concept.

But before we go on, I'm going to grab the YAML from this so I can replicate everything.

So I'm just using the same trick I use previously, I've gone to the YAML view for the new virtual service.

And then in our file, six Istio rules, which is currently blank, we'll paste that in and remove all of the unnecessary self link UID resource version, generation creation, timestamp, and labels can all be deleted.

Now, what you're seeing here is a screenshot from the original version of this course.

And in very early versions of istio, there were a few fields which had a Tilda alongside them, and they were essentially no fields that weren't being used.

kiali doesn't do that anymore.

So you won't see these appearing.

So don't worry if my screen doesn't quite match yours, we're not going to be using TCP TLS or export to at least in this video.

But we are going to be using gateways a little bit later on.

So for now, you don't need gateways, but when we add it, you are going to have to add that manually.

And back into kiali, I want to rescue the destination rule as well.

So again, destination rules, go into the detail, click on the yaml and then copy that in to our file.

Again, self link UID resource version, generation creation timestamp and labels can all go traffic policy would be used.

If we wanted to set session affinity, which we don't, so I can remove that.

So I've generated the YAML, they're really quite simple.

Other way you could do this is just use my YAML file where I've supplied as part of the downloads for this course, six istio rules dot YAML in the folder for this section.

So I'm going to remove the kiali configuration to check that that works.

Okay.

So go to details, actions, delete all traffic routing.

So we're now back to how we were and back on the graph.

This is now not showing the virtual service icon.

Great.

And we can do a kubectl apply dash F on the Istio rules.

So what I want to see now, although it's kind of quite difficult to tell the proportions because it was 5050 before, but it was kind of hard to count, I think it should be pretty obvious if this is responding in a 9010 fashion.

So I'll start by doing this graphically.

So we've got old, old, old, old.

This is quite dull, isn't it? I just stopped the recording there because I have gone to the front end.

And I've had a massive long sequence of just the old version coming back here on Chrome.

And I'm fairly certain This is a caching thing.

So I think I'm coming.

I mean, even control refreshing here isn't making any difference.

I'm sure this is a bug in my Angular configuration.

I've done the same in Firefox.

And for some reason Firefox is sometimes giving the right answer.

And I've got a bit of I've gotten a bit of a bad mood about this.

But actually, I think I've struck on quite an important piece of guidance that if you're working on setting up canaries, or any kind of intelligent routing or routing for your front end components, I would strongly recommend that you use curl to check your configurations.

So as I've been saying up until now, oh, it doesn't matter.

If you don't have curl available, I think I'm now going to say doesn't matter what operating system you're using, go get yourself an implementation of curl so that you can do local tests.

Probably the best way if you're on Windows is to get cygwin.

If you don't want to change shells, then you could always download curl from the URL you can see here.

Yeah, I think we're going to proceed them by using curl dash s, the minkube IP address colon 30,080.

And we'll grep for the title.

Now, I think it would be worth doing this in a loop again.

Again, you'll need a proper bash shell for this.

So if not, you're just gonna have to keep recalling the command but I'm going to do a while true semi colon Do not kill command and then semicolon there and then a sleep of maybe half a second and then semi colon done.

I think that's right.

Let's give it a try.

That's looking okay.

So what we're seeing then, from here is a much clearer result of our configuration.

And I think we can pretty quickly conclude from this, that we're not seeing a 9010 Canary, we probably need to leave it to run for a while, we certainly get big clumps.

I'll just stop there and count the results on this screen.

There's 24 of the canary.

And there are 25 of the old version, which proves for some reason the split that we've got in here on this virtual service is not working.

So as I've been hinting, you might want to have a think for yourself as to why this isn't working.

If you can't think of anything, then the big clue is what's the difference between the service we're working on here, and the service we're working on in the previous section, the staff service, that's got to be a clue.

If that doesn't help, you might want to stop the video now because I'm going to put a clue on the screen.

So if you need a clue, then I've gone all the way back to the architecture picture from a previous section, of course, parts containers, sidecar proxies, all that kind of business.

Does that help? Well, I'm going to explain what the problem is in the next video.

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

이 섹션에서는 이전 섹션의 가상 서비스 및 대상 규칙에 대한 지식을 바탕으로 구축 할 것입니다.

그래서 우리는 여전히 트래픽 관리를하고 있습니다.

하지만 이제 우리는 Istio 게이트웨이가 무엇인지, 그리고 왜 필요한지 알아볼 것입니다.

예, 과거에 Istio에서 작업 한 적이 있다면 Ingress 게이트웨이를 접했을 것입니다.

그리고 Istio 문서에서 Ingress 게이트웨이를 설정해야하는 이유 또는 그게 무엇인지 설명하는 데는 그다지 좋은 일을하지 못합니다.

그래서 기록을들을 때 일반 Kubernetes 환경에서 Kubernetes Ingress 리소스를 설정하고 클러스터 외부에 노출되어야하는 서비스를 지정하도록 선택할 수 있다고합니다.

전에 Kubernetes Ingress를 사용했는지 모르겠습니다.

괜찮은 Kubernetes 교육 과정을 확인하지 않은 경우 Ingress에 대한 섹션이 있어야합니다.

그러나 Kubernetes Ingress 리소스에 대한 매우 간단한 설명은 값 비싼로드 밸런서를 많이 필요로하지 않고 외부 세계에 여러 서비스를 노출하는 방법입니다.

여기 하드웨어로드 밸런서에 대해서는 자세히 설명하지 않겠습니다.

이전에 사용해 본 적이 있다면 알고 있습니다.

이전에 사용하지 않았다면 긴급하지 않습니다.

그러나 표준 Kubernetes 정보를 선택하는 것이 좋습니다.

그러나 여기서 그들이 말하는 것은 Istio 서비스 측정에서 두 번째 문장에서 더 나은 접근 방식은 다른 구성 모델, 즉 Istio 게이트웨이를 사용하는 것입니다.

그리고 그들은 왜 우리가 과거에 절대적으로 잘 작동했던 것으로 추정되는 대체품이 왜 필요한지에 대해 아무 말도하지 않습니다.

이것은 문서를 읽을 때 변경되었을 수 있습니다.

하지만 Istio와 함께 일하기 시작했을 때 이것을보고 생각했습니다. 글쎄,이 Istio 게이트웨이가 나에게 제공하는 것이 무엇인지 모르겠습니다. 왜 필요한지 모르겠습니다.

그리고 나는 완전히 길을 잃었습니다.

이것이이 과정의 요점이며,이 Ingress 게이트웨이를 구성해야하는 이유를 설명하는 것이 매우 유용합니다.

그리고 기존 Kubernetes 표준 플레인 Ingress 컨트롤러를 Istio 버전으로 대체 할 가능성이 높습니다.

그런데 왜? 글쎄, 이것은 실용적인 과정이어야합니다.

그래서 저는 실질적인 요구 사항을 통해 설명 할 것입니다.

이제 모두 카나리아와 가상 서비스를 사용하여 카나리아를 구현하는 방법에 익숙합니다.

그래서 우리는 개발 된 새로운 실험적인 프런트 엔드를 가지고 있으며, 개발자들은 이것을 Docker Hub에 푸시했고 6 개의 대시 실험이라는 태그를 부여했습니다.

그래서 우리가 사용할 수 있습니다.

이제이를 클러스터에 배포 할 수 있습니다.

그러나 요구 사항은 잠재적으로 위험한 릴리스라는 것입니다. 우리는 수백만 건의 지원 티켓이 들어오는 위험을 감수하고 싶지 않습니다.

따라서이 작업을 단계적으로 수행하고 요청의 10 %에만 배포 할 것입니다.

그래서 이것은 쉽습니다.

우리는 이것을하는 방법을 알고 있습니다. 우리는 이전 섹션에서 해냈습니다. 그것은 쉬울 것입니다. 아마도 캐치가 있다고 추측 할 수있을 것입니다.

캐치가 뭔지 알아볼 수 있을까요? 이전 섹션에서 배운 내용에 따라 이것이 작동하지 않는 이유는 무엇입니까? 물론, 왜 작동하지 않는지 설명하겠습니다.

하지만 시도 해보자.

따라서 실용성을 위해이 섹션으로 곧바로 왔거나 방금 시작한 새로운 minkube로 시작하는 경우 세 게이트웨이라는 폴더에 세트 파일을 제공했습니다.

그리고 그것은이 과정의 다운로드에 있습니다.

그리고 지금 쯤이면 YAML 파일을 순서대로 적용해야한다는 것을 알고 있다고 가정하겠습니다.

순서는 특히 첫 번째와 두 번째에 중요합니다.

나머지 작업으로 넘어 가기 전에 각 시간을 완료해야합니다.

따라서 깨끗한 시트에서 시작하는 경우 6 개의 Istio 규칙이라는이 파일이 실제로 비어 있음을 알 수 있습니다.

따라서 우리는 특별한 트래픽 관리가 진행되지 않았습니다.

카나리아 같은 것은 없습니다.

그러나 많은 분들이 이전 섹션에서 롤업 할 것이라는 것을 알고 있으며, 저는 확실히 이전 섹션에서 카나리아를하고 있던 작업이 남아 있습니다.

따라서 깔끔한 시작점을 얻기 위해해야 ​​할 일은 kubectl이 6 개의 Istio 규칙에서 해당 파일에서 대시 F를 삭제하는 것입니다.

그리고 저는 우리가 이전 세션에서 일곱 번째 버전도 만들었다 고 생각합니다. 일곱 번째 버전은 고정 세션의 데모였습니다.

그래서 당신이 가지고 있다면 그것도 삭제하십시오.

그리고 저는 그 파일에 들어갈 것입니다.

이제 이것은 6 개의 Istio 규칙입니다.

그 파일의 내용을 삭제하고 저장하겠습니다.

물론이 세션에서는 몇 가지 특별한 구성을 수행 할 것입니다.

그러나 다섯 번째 파일에는 응용 프로그램이 없습니다.

더 내려 가면 직원 서비스를 위해 카나리아를 설치했습니다.

그래서 우리는 당신의 파일이 어떤 상태인지 모릅니다.

하지만 현재 6 개의 자리 표시 자라는이 이미지의 복제본이 하나 있습니다. 더 이상 원하지 않습니다. 왜냐하면 우리는 이것에 대해 카나리아를하고 있지 않기 때문입니다.

그래서 저는 그 복제본을 0으로 변경하는 것이 좋습니다.

다시 말하지만이 세션으로 바로 와서이 섹션에 대해 미리 정의 된 파일을 사용하면 이미 완료되었음을 알 수 있습니다.

그리고 직원 서비스의 위험한 버전으로 더 내려갑니다.

예, 괜찮습니다. 실행중인 복제본 하나만 남겨 두겠습니다.

따라서 kubectl은 해당 변경 사항에 적용하십시오.

이제 큐브 CTL로 확인할 수 있습니다.

PL 가져 오기 네, 직원 서비스가 종료됩니다.

따라서 직원 서비스를 위해 하나의 포드로 돌아가는 것은이 세션에서 해당 서비스에 대한 멋진 트래픽 관리를 수행하지 않을 것입니다. 이것이 작동하는지 확인할 가치가 있습니다.

따라서 항상 프런트 엔드로 돌아 가면 minkube 주소 콜론 30,080은 플릿 관리자 프런트 엔드를 제공해야합니다.

그리고 이제 우리가 어떤 차량을 방문하든 관계없이 직원들에게 멋진 사진을 찍어야합니다.

따라서이 위치에 있다면 이제 프런트 엔드 용 카나리아를 만드는 도전을 공격 할 준비가 된 것입니다.

그래서 우리는 그 카나리아를 구현하고 이전 섹션에서 우리가 가지고 있던 모든 이론을 사용하려고 시도 할 것입니다.

그리고 시작점은 표준 Kubernetes yaml을 수정하는 것입니다.

웹 앱 배포 용 yaml 만 찾을 수 있으며 70 번 줄부터 찾아야합니다.

이것이 표준 이미지, 이미지 버전 6입니다.

그리고 이전과 마찬가지로 여기에 레이블을 추가 할 것입니다.

그래서 우리는 앱 웹 앱 레이블을 가지고 있지만 이것에 대한 버전을 넣을 것입니다.

그리고 버전은 항상 그렇듯이 여기에서 원하는 것을 사용할 수 있습니다.

그래서 나는 그것을 원래 버전이라고 부를 것입니다.

그래도 괜찮지 만 새로운 배포를 원합니다.

따라서이 전체 배포 블록의 사본을 가져와 나중에 붙여 넣겠습니다.

92 번 줄부터입니다.

그래서 두 번째 버전이 있습니다.

그리고 여기서 조심하세요. 저는 항상 이것을하는 것을 잊습니다. 당신은 그것에 대한 고유 한 이름이 필요합니다. 그렇지 않으면 그냥 무시되고 정말 혼란스러워집니다.

이 웹 앱을 대시 x 베테랑 정신이라고 부르겠습니다.

따라서 이에 대한 버전 태그는 실험적입니다.

그리고 중요한 것은 여기에서 이미지를 변경하는 것입니다. 이것은 실험적인 이미지 6 대시가 될 것입니다.

이전에 이에 대한 이미지를 빌드하고 Docker Hub에 업로드했습니다.

이 정도면 충분합니다.

지금.

해당 파일을 적용하면 파일 번호 5, 애플리케이션, Istio가 없습니다. kubectl get po에 감시를두면 확인해야합니다. 실제로 이전 포드가 종료되어 해당 레이블을 적용 할 수 있습니다. .

레이블은 변경할 수 없으므로 이전 포드를 종료해야합니다.

그래서 이것의 최종 결과.

다행히 웹 앱 팝업 창은 매우 가볍습니다.

그래서 나는 우리가 여기서 자원에 문제가 없을 것이라고 생각합니다.

몇 초 후, 약 30 분이 지나면 이전 웹 앱인 실험용 웹 앱이 생겼을 것입니다.

그리고 둘 다 실행 중이어야합니다.

나는 그것을 조금 망칠 것이다.

이제이 실험적인 새로운 웹 앱은 상단에 빨간색 배너 만 표시되어 있습니다. 멋진 작업을 할 시간이 없었습니다.

그래서 지금 일어나야 할 일은 명심하십시오. 아직 Istio 구성이 없습니다.

그러나 우리는 각각 다른 이미지가 minkube 주소 콜론 30,000을 서비스하는 두 개의 포드를 가지고 있습니다.

그리고 여기서는 표준 Kubernetes를 사용하기 시작했습니다.

따라서 포트 30,080은 kubectl get SVC를 수행하면 30,080의 노드 포트로 구성된 Fleetman 웹 앱 서비스가 있음을 확인하는 것입니다.

그리고 우리는 그 노드 포트 뒤에 두 개의 포드가 있습니다.

따라서 이제 노드 포트의 Kubernetes 기능이 균형을 이루어야합니다.

이전 버전과 새 버전 간의 트래픽을 확인합니다.

이제 균형은 약간 무작위입니다.

그래서 제가 새로 고침을한다면, 저는 오래된 것, 새로운 것을 얻었습니다. 그래서 당신은 큰 빨간색 배너로 아주 쉽게 새로운 것을 알아볼 수있을 것입니다.

그리고 새것, 새것, 새것, 새것은 내가 예전으로 돌아 가기 전에 긴 뉴스를 보내는데 이것이 정확한 5050 밸런싱이 될 것이라고 기대하지 마십시오.

정확한 세부 사항을 기억할 수 없습니다.

그러나 이는 Kubernetes가 해당 노드 포트를 구현하는 방식과 관련이 있습니다.

이제이 Angular 앱에서 캐싱하는 데 문제가 있습니다.

저는 Angular 개발자가 아닙니다.

그래서 약간 해킹을해야했습니다.

여기에 문제가있는 경우 캐시를 삭제하거나 강제로 새로 고침해야 할 수 있습니다.

그래서 Chrome에서 하드 새로 고침은 제어 및 새로 고침 또는 Ctrl f5라고 생각합니다.

그것은 매킨토시에서 명령이 될 것입니다.

Firefox에서 실행중인 경우 Ctrl f5가 작동해야한다고 생각합니다.

이제 저는이 오프 카메라로 어려움을 겪었습니다. 몇 번 작동하게했는데 무작위로 작동을 멈췄습니다.

따라서 캐시는 작동하기가 매우 어려울 수 있습니다.

그러나 지금은 녹음에서 괜찮아 보입니다. 집에서 문제가 발생하는 경우를 대비하여 실제로 curl을 사용하여 다른 브라우저의 모든 모호함을 제거하는 것이 좋습니다.

그래서 당신은 당신의 minkube IP 주소에 컬을 할 수 있습니다.

지금은 167 콜론 30,080으로 끝납니다.

문제는 단지 Angular 앱이라는 것입니다.

그래서 당신은 일종의 헤더를 얻게 될 것입니다.

그리고 모든 논리는 JavaScript로 구현되지만 제목은 다양하게 설정했습니다.

따라서 따라가는 중이고 bash 셸이없는 경우 제목의 결과로 얻는 내용을 시각적으로 확인할 수 있습니다.

또는 괜찮은 bash 쉘을 원한다면 그 curl을 수행 한 다음 출력을 grep으로 파이프 할 수 있습니다.

그리고 우리는 문자열 제목을 grep 할 것입니다.

그리고 그것은 변화 할 하나의 선을 분리해야합니다.

우리가 얻는 버전에 따라 대시를 추가 할 수 있습니다.

컬 옵션을 선택하면 진행률 표시기가 제거됩니다.

그래서 저는 새 버전, 새 버전, 이전 버전, 이전 버전, 이전 버전, 이전 버전, 이전 버전을 가지고 있습니다.

그러나 나는 대략 5050의 균형을보고 있다고 생각합니다.

어쨌든, 그것은 단지 이것의 요점을 설정하는 것입니다. 우리는 9010 카나리아를 설정하고자합니다.

따라서 원칙적으로 이전 비디오에서와 같이 yaml을 작성할 수 있습니다. 대상 역할에 가상 서비스가 필요합니다.

또는 속임수를 사용하고 kiali를 사용하여 yaml을 생성 할 수 있습니다.

이를 수행 할 수있는 몇 가지 방법이 있습니다. 서비스 그래프로 이동하여 Fleetman 웹 앱 서비스를 찾을 수 있습니다.

이제 여기서 조심하세요.

최근에 해당 웹 앱을 사용하지 않은 경우 해당 서비스가 그래프에 표시되지 않을 수 있습니다.

이 경우 프런트 엔드로 이동하여 몇 가지 새로 고침을 수행하십시오.

그런 다음 여기 삼각형을 마우스 오른쪽 버튼으로 클릭하여 서비스 세부 정보로 이동할 수 있습니다.

이제이 과정을 업데이트에 기록하고 있기 때문에 버전 dap 그래프로 이동하면 언급하고 싶습니다. 실제로 여기에서 조금 더 유용합니다. 실험을 배포하는 두 가지 버전을 볼 수 있기 때문입니다. 이 웹 앱의 원래 버전입니다.

문제는 최신 버전의 kiali에 있습니다. 예전에는 그렇지 않았습니다.

그러나 버전 그래프의 최신 버전에서는 기본적으로 서비스가 표시되지 않고이 다이어그램을 약간 정리했습니다.

따라서 실망 스럽거나 실험 버전과 원본 버전을보고 싶으면 여기에서 클릭하여 서비스 세부 정보를 확인하고 싶으면 쉽게 드롭 할 수 있습니다. 이 디스플레이 목록 아래로 이동하고 서비스 노드의 확인란을 선택합니다.

그리고 사용자 인터페이스를 이전 버전에서 사용하던 방식으로 되돌립니다.

그래서 저는 이것이이 사용 사례에 좀 더 유용하다고 생각합니다. 두 버전의 포드를 모두 볼 수 있습니다.

하지만 해당 서비스도 볼 수 있습니다.

그래서 저는이 경로를 통과 할 것입니다.

여기를 마우스 오른쪽 버튼으로 클릭하고 세부 정보 표시를 클릭합니다.

이제 여기에서 작업 링크로 이동할 수 있습니다. 이전과 마찬가지로 가중치 기반 라우팅을 만들 수 있습니다.

그리고 우리가 찾고있는 것은 웹 앱의 원래 버전이 90 % 대기하고이 새로운 실험 버전이 10 %가되는 것입니다. 그래서 우리는 그렇게 할 것입니다. 그리고 나서 만들기를 클릭합니다.

그리고 이론적으로는 그렇게 쉬워야합니다. 음, 알다시피 이것은 효과가 없을 것입니다.

그리고 아마도 그것이 작동하지 않는 이유에 대해 생각하고 싶을 것입니다.

아주 미묘합니다.

그러나 그것은 일종의 정말 중요한 개념입니다.

하지만 계속 진행하기 전에 모든 것을 복제 할 수 있도록 여기에서 YAML을 가져 오겠습니다.

그래서 저는 이전에 사용한 것과 동일한 트릭을 사용하고 있으며 새로운 가상 서비스에 대한 YAML보기로 이동했습니다.

그런 다음 현재 비어있는 6 개의 Istio 규칙을 파일에 붙여넣고 불필요한 셀프 링크 UID 리소스 버전, 생성 생성, 타임 스탬프 및 레이블을 모두 삭제할 수 있습니다.

이제 여기 보시는 것은이 과정의 원본 버전의 스크린 샷입니다.

그리고 istio의 초기 버전에는 Tilda가 옆에있는 필드가 몇 개 있었으며 기본적으로 사용되지 않는 필드가 없었습니다.

kiali는 더 이상 그렇게하지 않습니다.

따라서 이러한 항목이 표시되지 않습니다.

따라서 내 화면이 귀하의 화면과 일치하지 않더라도 걱정하지 마십시오.이 비디오에서는 TCP TLS를 사용하거나 내 보내지 않을 것입니다.

그러나 우리는 조금 후에 게이트웨이를 사용할 것입니다.

따라서 지금은 게이트웨이가 필요하지 않지만 추가 할 때 수동으로 추가해야합니다.

그리고 다시 키 알리로 돌아가 목적지 규칙도 구하고 싶습니다.

다시 한 번, 대상 규칙은 세부 사항으로 이동하여 yaml을 클릭 한 다음 파일에 복사합니다.

다시 말하지만, 자체 링크 UID 리소스 버전, 생성 생성 타임 스탬프 및 레이블은 모두 트래픽 정책을 사용할 수 있습니다.

세션 어피 니티를 설정하고 싶은 경우에는 제거 할 수 있습니다.

그래서 YAML을 생성했습니다. 정말 간단합니다.

이 작업을 수행 할 수있는 다른 방법은이 과정에 대한 다운로드의 일부로 제공 한 내 YAML 파일을 사용하는 것입니다.이 섹션의 폴더에는 6 개의 istio 규칙이 YAML에 있습니다.

그래서 작동하는지 확인하기 위해 kiali 구성을 제거 할 것입니다.

괜찮아.

따라서 세부 정보, 작업으로 이동하여 모든 트래픽 라우팅을 삭제하십시오.

이제 우리는 우리가 어떻게 지 냈는지 다시 그래프로 돌아 왔습니다.

이제 가상 서비스 아이콘이 표시되지 않습니다.

큰.

그리고 kubectl이 Istio 규칙에 대시 F를 적용 할 수 있습니다.

그래서 제가 지금보고 싶은 것은 이전에 5050 이었기 때문에 비율을 말하기는 꽤 어렵지만 계산하기가 다소 어려웠습니다. 이것이 9010 방식으로 반응한다면 꽤 분명해야한다고 생각합니다.

그래서 저는 이것을 그래픽으로 시작하겠습니다.

그래서 우리는 늙고, 늙고, 늙었습니다.

이것은 꽤 지루하지 않습니까? 나는 프론트 엔드로 갔기 때문에 거기에서 녹음을 중지했습니다.

그리고 저는 Chrome에서 이전 버전으로 돌아 오는 엄청난 긴 시퀀스를 가지고 있습니다.

그리고 저는 이것이 캐싱이라고 확신합니다.

그래서 내가 오는 것 같아요.

여기에서 새로 고침을 제어해도 아무런 차이가 없습니다.

Angular 구성의 버그라고 확신합니다.

Firefox에서도 똑같이했습니다.

그리고 어떤 이유로 Firefox는 때때로 올바른 대답을 제공합니다.

그리고 나는 이것에 대해 약간의 기분이 나빠졌습니다.

하지만 실제로는 카나리아를 설정하는 작업이나 프런트 엔드 구성 요소에 대한 모든 종류의 지능형 라우팅 또는 라우팅을 작업하는 경우 curl을 사용하는 것이 좋습니다. 구성을 확인하십시오.

그래서 내가 지금까지 말했듯이, 오, 그것은 중요하지 않습니다.

컬을 사용할 수없는 경우 사용중인 운영 체제는 중요하지 않다고 생각합니다. 로컬 테스트를 수행 할 수 있도록 컬을 직접 구현하십시오.

Windows를 사용하는 경우 가장 좋은 방법은 cygwin을 사용하는 것입니다.

셸을 변경하지 않으려면 여기에서 볼 수있는 URL에서 항상 curl을 다운로드 할 수 있습니다.

그래, 나는 우리가 컬 대시 s, minkube IP 주소 콜론 30,080을 사용하여 진행할 것이라고 생각한다.

그리고 우리는 제목에 대해 grep 할 것입니다.

자, 나는 이것을 루프에서 다시 할 가치가 있다고 생각합니다.

다시 말하지만이를 위해서는 적절한 bash 쉘이 필요합니다.

그렇지 않다면, 당신은 계속해서 명령을 기억해야 할 것입니다.하지만 저는 잠시 동안 진정한 세미콜론 명령을 죽이지 않고 세미콜론을 죽인 다음 거기에서 세미콜론을 수행 한 다음 0.5 초 정도 잠을 자고 세미콜론을 완료합니다.

나는 그것이 옳다고 생각한다.

한번 시도해 봅시다.

괜찮아 보입니다.

그래서 우리가보고있는 것은 여기에서 우리 구성의 훨씬 더 명확한 결과입니다.

그리고 저는 이것으로부터 꽤 빨리 결론을 내릴 수 있다고 생각합니다. 우리는 9010 카나리아를 보지 못한다는 것입니다. 우리는 아마도 잠시 동안 실행하도록 두어야 할 것입니다. 우리는 확실히 큰 덩어리를 얻습니다.

여기서 멈추고이 화면에서 결과를 세겠습니다.

카나리아가 24 개 있습니다.

그리고 이전 버전의 25 개가 있습니다. 어떤 이유로이 가상 서비스에 대한 분할이 작동하지 않음을 증명합니다.

그래서 제가 암시 한 것처럼 이것이 작동하지 않는 이유에 대해 스스로 생각하고 싶을 수도 있습니다.

아무것도 생각할 수 없다면 여기서 작업중인 서비스와 이전 섹션에서 작업중인 서비스 인 직원 서비스의 차이점이 무엇인지 가장 큰 단서는 단서가 될 것입니다. .

그래도 도움이되지 않으면 화면에 단서를 표시 할 것이기 때문에 지금 비디오를 중지하는 것이 좋습니다.

따라서 단서가 필요하면 이전 섹션의 아키텍처 사진으로 돌아갔습니다. 물론 부품 컨테이너, 사이드카 프록시, 모든 종류의 비즈니스입니다.

도움이 되나요? 음, 다음 비디오에서 문제가 무엇인지 설명하겠습니다.