solo.io Gloo Platform, 18 Jul 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Istio Upgrade Guide: In-Place vs. Canary Upgrades

Description

Are you looking to upgrade your Istio service mesh but unsure of the best approach? In this video, we'll walk you through the two main upgrade methods: In-Place Upgrades and Canary Upgrades. Whether you're running Istio on your own or through the Gloo Platform, this step-by-step guide will help you seamlessly transition to the latest version and ensure a smooth deployment.

🔹 Understanding the Naming Scheme:
Before diving into the upgrade process, we'll explain Istio's version naming scheme. Discover how the major, minor, and patch numbers come into play, and learn how to identify which upgrade method is suitable for your specific version.

🔹 Canary Upgrade: A Safe and Gradual Approach:
The Canary Upgrade is an excellent strategy when moving from one minor version to another (e.g., 1.16 to 1.17). By deploying a second control plane with the new revision and gradually migrating your workloads, you get the opportunity to thoroughly test the new revision before making a complete switch. We'll demonstrate this method using Istio version 1.16.3 and upgrading to version 1.17.

🔹 Leveraging Istio Lifecycle Manager:
Discover how to utilize the Istio Lifecycle Manager to deploy Istio and perform upgrades. We'll walk you through the process of updating the existing applied lifecycle object for your cluster, introducing the new revision tag and version tag in the YAML configuration.

🔹 Deploying New Operators and Gateways:
Learn how to deploy the new operator for the 1.17 revision in a designated namespace using the Gloo Platform. We'll explain how the operators automatically watch the Istio operator resources in the same namespace, ensuring a smooth upgrade process.

🔹 Upgrading Istiod and Workloads:
Follow our instructions to deploy Istiod 1.17 and restart the workloads connected to the old control plane, enabling them to use the new Istiod revision.

🔹 Verifying Application Access:
Ensuring your applications can be accessed correctly during the upgrade is crucial. We'll guide you in testing access to your applications deployed using the Istio Ingress Gateway.

🔹 Updating Gateway and Services:
Discover how to patch the services to target the new Istio revision (1.17) while maintaining the same external IP address, ensuring continuity during the migration.

🔹 Cleaning Up Old Revisions:
Once the Canary Upgrade is successful, we'll show you how to update the lifecycle manager objects to remove all entries related to the old revision (1.16). The Gloo Platform will handle the uninstallation of components associated with the old revision.

🔹 Conclusion:
Upgrading Istio is essential for maintaining a robust and efficient service mesh. With this comprehensive guide, you'll have the knowledge and confidence to perform In-Place or Canary Upgrades smoothly, depending on your Istio version. Watch the video now to master the art of Istio upgrades and optimize your cloud-native infrastructure! Don't forget to subscribe to our channel for more valuable tutorials and updates. Happy upgrading! 🚀🔝

A

In istio,, you have two ways to perform: an upgrade:. You can do an in-place upgrade or.

A

You can do a canary upgrade,, where you deploy a second control plane with a different revision.

A

And you slowly move your workloads to this new revision.. This gives you a chance to.

A

Test the new revision, and once everything is fine, you can get rid of the previous one.

A

So before we do an upgrade itself, let's start by looking at the naming scheme, that's used in istio.

A

If I look at the gloo platform to see what istio version that we already have,, we have 1.16.3,.

A

So, in this case the major is one,, the minor is 16, and the patch is three,.

A

So if I want to do a patch upgrade, for example, 1.16.3 to 1.16.4,, I would do an in-place upgrade.

A

And a minor upgrade would be going from 1.16 to 1.17. In that case, I would do a canary upgrade,.

A

And that's what we're going to demonstrate in this lab.

A

So again we have here 1.16.3,, so I'm going to set some environment variables so that.

A

The old version is 1.16 and I want to go to the new version, which is 1.17.

A

So once we set these variables the same way, we use the istio lifecycle manager, object to deploy istio.

A

We can also use it to perform these upgrades.. We just update the existing applied lifecycle, object.

A

That we've created for cluster one- and this part is exactly the same,. But we're going.

A

To add a second part, which corresponds to the second revision that we want to install and the.

A

Only difference is the new revision tag and the tag of the version that we want to use.

A

So again, we're going from 1.16.3,. So in this case you can see here that we're going to 1.17...

A

Yeah 1.17.1,, so when I apply this.

A

What gloo platform is going to do is it's going to deploy a new operator for the.

A

1.17 in this 1.17 namespace and it's going to create a new istio operator, object,, the yaml,.

A

To represent the new installation of 1.17 revision and basically gloo will configure these operators.

A

To automatically watch the istio operator, resources that are in the same namespace...

A

So then the next step is the operator is being deployed.... The operator will deploy istiod 1.17,.

A

So this mechanism is the same mechanism that you would follow for the gateways as well.

A

We would deploy a new gateway with the new revision and we do the same thing for the.

A

Ingress gateway, as well as the east-west gateway,, and then we do the same thing for.

A

The istio control plane on the second cluster,, followed by the two gateways.. So again, everything.

A

Is done as code, so we defined that we want these two revisions to be deployed in the two clusters.

A

It should be that simple,. So if I go here, I can see that this gateway will.

A

Be created very quickly because I already have the operator running,.

A

And I see the istio, the ingress and egress gateway, the everything is fine, and now it can go here.

A

And see that I have this operator being deployed as well.

A

And now the gateways are created, so it would be very fast to deploy this newer, version.

A

We can also check the status of each of these istio operator. Lifecycle manager, objects.

A

As in the gateway lifecycle manager object, each of them have a status field.

A

Where you can see the different revisions across the different clusters and see if they're, healthy.

A

And so on., so now that we've upgraded. What I want to do is restart the different pods.

A

That are connected to this control plane,, so we want them to use the new revision istiod. over.

A

Here we can see all the pods that are across all the namespaces that are used in this old revision,.

A

And I'm going to change the label of these namespaces and restart the deployments.

A

So normally in production, you'd, probably relabel just the namespace of one test.

A

Application and then you would... and you would restart the application and validate it, works.

A

And then you would kind of move on incrementally until you're happy with all of your workloads.

A

And obviously you can definitely automate this incremental namespace.

A

Upgrade process and testing, so here we're restarting everything.

A

So that everything's connected to the new control plane, which is revision, 1.17...

A

And this command here will.

A

Give me a way to test access to the http bin application that I've deployed in the cluster.

A

And I've exposed this using the istio ingress gateway,.

A

So basically, I just need to check that this application can still be accessed properly.

A

You can see we're getting a 200.. Everything is up and running correctly, so everything is fine,.

A

But right now we're still using the old gateway..., the gateway of.

A

The previous revision of the gateway, the 1.16 gateway, to expose this application.

A

I can look at this gateway object here.

A

And you can see that it's still using the 1.16 revision,.

A

So what I need to do now is I've moved my workloads to the new revision.... I want to.

A

Move the gateway to the new revision as well,, and you can also do the opposite by starting.

A

By the gateway and finishing by the workloads., if you recall, we decided to create a service.

A

And for the ingress gateway that is not managed by the gloo platform,.

A

And we did that so that we can use the same service. The load balancer.

A

Service and we get so- we can keep the same external ip as we upgrade istio,.

A

And now all we have to do is patch that services, so that they're now targeting the new revision.

A

So I can simply patch this the way I...

A

And we can check that everything is fine...

A

They can check that everything's working well with the new revision, and I can still.

A

Access my access service correctly and we've basically finished my migration, because I don't.

A

Have any more services or any pods that are connected to the previous revision anymore.

A

There's also, this convenient istio ctl command that will list all the proxies.

A

That are connected to what specific version of the control plane. So that's another handy, cli.

A

So when you're finished,, you can now update these. These lifecycle manager, objects,.

A

And we just we're just going to update it to remove all the old entries...all, the old.

A

Entries that are corresponding to the old revision of istio.

A

And what the platform will do is it's going to see that change and it's going to automate the process.

A

Of uninstalling,, removing all of the components that are associated with the old revision.

A

So you can see that the 1.16 control plane and the gateways that correspond to this.

A

1.16 revision and even uninstalling the istio operator itself, that was for 1.17.

A

So all that's left is 1.17 and and if you go back to the ui, you can see that it's.

A

All the new updates are reflected properly. I can see 1.17 and everything's healthy.