Shulou(Shulou.com)05/31 Report--

This article introduces the relevant knowledge of "what features Istio 1.7 has". In the operation process of actual cases, many people will encounter such difficulties. Next, let Xiaobian lead you to learn how to deal with these situations! I hope you can read carefully and learn something!

Istio 1.7.0 Released

Just a few days ago, Istio released version 1.7, exactly three months apart from the release of version 1.6, perfectly fulfilling its quarterly release promise. The slogan for this release is "Istio's great community," as more than 200 developers from more than 40 companies contributed. Istio officially describes it this way:

It's because of this amazing community that Istio is able to make so many improvements every quarter.

Istio's team has emerged from last month's trouble with reselling trademarks, seemingly to highlight Istio's great community.

This idea to heal the broken hearts of community developers? The author believes that as developers and users do not have to care too much about Google's business practices, at least at this stage Istio is still evolving as an open source identity, and it can also be used by me, which is enough.

1.7 There are four major updates in the release.

security enhancement

Acknowledges the advantages of using Secure Discovery Services (SDS) as certificate distribution and considers it an important security best practice. This feature is now also used on egress gateways.

Trust domain validation now validates TCP traffic in addition to HTTP support, and also supports configuration in MeshConfig, providing more flexibility.

ECC can be used for CA communication, improving security and efficiency.

Gateways default to non-root deployments, based primarily on a best practice: Don't let a process run with more permissions than it needs, which can lead to unnecessary confusion.

Improved ease of use

The main improvement in ease of use is still to istioctl

Command-line tool enhancements:

DestinationRuleISTIOCONFIGistioctl x uninstall Production Operations Improvements

There are also some improvements in operations, such as:

You can support Sidecar startup before launching your app container. If your app needs to access resources via Sidecar proxy at startup, this change will make the deployment more stable (avoiding situations where your app cannot access resources because Sidecar is not started).

Istio Operator as the best way to install. Operator has been available in previous versions, and it seems that Istio wants to push Operator as an alternative to other installation formats. However, the author must complain about the official release document description of this article:

TheIstio Operator is a great way to install Istio, as it automates a fair amount of toil. Canary control plane deployments are also important; they allow ultra-safe upgrades of Istio. Unfortunately, you couldn't use them together -until now.

Operator does not currently support canary updates. I really admire the writer's ability to beat around the bush.

Provides istio-agent metrics to observe its operation

Improvements in the collection of Prometheus indicators

VM Security

Continued development of virtual machine-related features is a key focus of the year, which Istio has emphasized several times. This is due to the complexity and hybrid nature of today's customer application deployment environments, where VM remains a primary deployment option. Compared to some hosted competitors (such as AWS APP Mesh), Istio lacks this ability, making these customers have to wait and see. VM support becomes a top priority, and this is also a business consideration.

However, this update doesn't have many heavyweight features released, only minor improvements have been made, and it's still in alpha phase. For example, security features have also been added to VM, supporting automatic certificate rotation; istioctl

It is now possible to verify the proxy state of VMs; RPM installation packages have been added, etc.

A gentle knife--escalating pain

Objectively speaking, most of the contents of the above official release documents are not painful and have little impact on users at the use level. What really matters to users is installation and upgrade changes. The Istio team did not emphasize this point on the release front page, which caused strong discomfort and serious suspicion that Istio was deliberately avoiding the problem. Let's look at what I think is the most important change:

Excessive platform version restrictions

Require Kubernetes 1.16+

Kubernetes 1.16+ is now required for installation.

This is the first time Istio has explicitly addressed Kubernetes version restrictions in a new Release Note. Although older versions of Istio also have platform version requirements, they usually say something like this:

Istio 1.5 has been tested with these Kubernetes releases: 1.14, 1.15, 1.16.

Implicit in this description is that we tested compatibility in these versions, but we are not saying that Istio is incompatible with other versions, maybe, probably compatible, we just did not test it. This time, the description is "required." Please carefully understand the difference between these two statements.

To verify the true compatibility of version 1.7, The author did an installation test, the test environment for Docker desktop version built-in Kubernetes, version 1.15.5.

First, verify that the cluster environment is legitimate using the preflight command (istioctl verify-install has been eliminated in the new version

Command)

$ bin/istioctl x precheckError: 1 error occurred:* The Kubernetes API version: v1.15.5 is lower than the minimum version: 1.16

As expected, the pre-check failed, and an error occurred that the version was too low. The author ignored the pre-check results and tried to force the installation to see if the pre-check was just a scare:

$ bin/istioctl installThis will install the default Istio profile into the cluster. Proceed? (y/N) yThe Kubernetes version v1.15.5 is not supported by Istio 1.7.0. The minimum supported Kubernetes version is 1.16.Proceeding with the installation, but you might experience problems. See https://istio.io/latest/docs/setup/platform-setup/ for a list of supported versions.✘ Istio core encountered an error: failed to wait for resource: failed to verify CRD creation: the server could not find the requested resource

The verification result was slapped in the face by reality. In addition to the version restrictions, Istio is also very strict in telling you that the installation process will continue, but you may encounter various problems. Sure enough, an error was reported during the installation of Istio core, and the installation process was stuck and could not continue. This time, Istio's required is for real.

Why is this mandatory version restriction the most annoying for users? The root cause is that most enterprises and users currently use Kubernetes that do not reach version 1.16+ at all, most of which are based on 1.14, 1.12, or even lower. At present, the Kubernetes services of the two major cloud vendors (AWS EKS and GCloud GKE) are also compatible with version 1.14+, which can also indicate that a large number of old users are likely to use version 1.14. However, Istio does not follow this rule, which is equivalent to directly kicking a large number of users out of the field, Istio 1.7 does not take you to play.

Another potential problem is that it creates great confusion for users who want to upgrade. As an example, an enterprise's operations team is about to upgrade Kubernetes version 1.14 to 1.16, and the architecture team is about to upgrade Istio 1.2 installed on it to 1.7. The problem the team faced was that to upgrade to Istio 1.7, Kubernetes had to be upgraded to 1.16; however, once 1.16 was upgraded, the original 1.2 version was likely to have compatibility issues because Istio 1.2 claimed to have been tested only on Kubernetes 1.12 - 1.14. Istio 1.7's overly strict platform version restrictions gave these users a fatal knife, and the upgrade road was full of thorns. They'll have to settle for the old version.

Since version 1.5, Istio has emphasized ease of use and user experience, while arbitrarily abandoning backward compatibility, shutting out a large number of users. His contradictory behavior is inconceivable.

Changes to resource version numbers

This issue appears in a Change Note installation section and is likely to become a new pain point for upgraded users.

Upgraded the CRD and Webhook versions to v1. ( Issue #18771

),( Issue #18838

)

As you can see from Issue, Kubernetes changed the API version of webhook to v1 in 1.16 and removed the old v1beta version in 1.19. This aggressive behavior resulted in Istio having to complete the corresponding migration prior to its own version 1.8. I also verified this problem in the official Istio Slack:

Yes this is a hard requirement. Most specifically CRDs, and other apis use APIs that were promoted to v1 in 1.16 are being used.

The Istio development team also complained in Issue that the other party was too aggressive, leaving them with a pretty tight window, probably a lot of work, and a grievance that a clever woman could not cook without rice. I can't help but sigh: this is the same brother, each other is too urgent!

For users, it means that you have to update the version number of your mesh configuration file. If the cluster is large, it is likely that there will be a lot of workload (mainly testing and verification). You'll probably also need to upgrade via canary, as compatibility issues may arise whether you upgrade Istio first or modify the configuration first (what about usability and user experience?).

LTS or STS (short term support)?

On the Istio Release Support Bulletin page, you can see that older releases are gradually being discontinued, especially the landmark version 1.5, which stopped maintenance three months after release, making it the shortest-lived release in Istio history. This led me to question the quality of its architectural reconstruction. Istio defines LTS (long term support) in the Build and Release rhythm page as follows:

Support is provided until 3 months after the next LTS

Even the so-called long-term support is only three months. This means that with each new release, the previous version is no longer supported (including updates, bug fixes, etc.) Let's compare Ubuntu's definition of LTS, here's a description of Ubuntu 20.04 LTS:

Download a long-term support (LTS) version of Ubuntu built specifically for desktop PCs and laptops. LTS means "long-term support" and is usually 5 years. The LTS release will provide free security and maintenance updates through April 2025.

"What are the features of Istio 1.7" is introduced here. Thank you for reading it. If you want to know more about industry-related knowledge, you can pay attention to the website. Xiaobian will output more high-quality practical articles for everyone!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.