istio 和 kong
by Chris Cooney
克里斯·庫尼(Chris Cooney)
如何啟動和運行Istio (How to get Istio up and running)
而一旦完成,您就可以做的瘋狂的事情。 (And the crazy stuff you can do once it is.)
The moment you get Istio working on your cluster, it feels like you’ve taken quite a serious leap forward. The level of monitoring, security, and functionality you immediately gain are light years ahead of the competition. A few months ago, we took the plunge and installed Istio onto our Kubernetes cluster and… hot damn. We’ll begin at the beginning, with installation and the pitfalls we found, then an overview of the tools we’ve found most useful.
讓Istio在群集上工作的那一刻,感覺您已經邁出了重要的一步。 您立即獲得的監視,安全性和功能級別比競爭產品輕了幾年。 幾個月前,我們嘗試了一下,將Istio安裝到我們的Kubernetes集群上,然后……該死。 我們將從一開始就開始,從安裝和發現的陷阱開始,然后概述我們發現最有用的工具。
使電動機運轉。 (Getting the motor running.)
The easiest and most efficient way to install Istio is using the Helm chart. You get a production ready installation out of the box. You have a few options but Istio provides a convenient download command so you can pull down a versioned bundle of the Istio Helm chart. The following will get you version 1.0.6
of the Istio package.
安裝Istio的最簡單,最有效的方法是使用Helm圖表。 開箱即用即可進行生產準備安裝。 您有一些選擇,但是Istio提供了方便的下載命令,因此您可以下拉Istio Helm圖表的版本捆綁。 以下內容將為您提供Istio軟件包的1.0.6
版本。
curl -L https://git.io/getLatestIstio | ISTIO_VERSION=1.0.6 sh -
Within this downloaded bundle, is a convenient little helm chart. It is located in install/kubernetes/helm/istio
. Once you’re in this directory, it’s a simple helm installation. We prefer to use helm upgrade — install
rather than a straight up install so that the same command can be automated:
在此下載的軟件包中,是一個方便的掌舵圖。 它位于install/kubernetes/helm/istio
。 進入該目錄后,便可以輕松安裝頭盔。 我們更喜歡使用helm upgrade — install
而不是直接安裝,以便可以自動執行同一命令:
helm upgrade istio . -f values.yaml \--namespace istio-system \--install
This will use the default values.yaml
file that is provided in the folder. You can alter this file to switch on or off different features.
這將使用該文件夾中提供的默認values.yaml
文件。 您可以更改此文件以打開或關閉不同的功能。
有關卸載Istio的說明 (A note on uninstalling Istio)
Common sense would dictate that a helm delete --purge istio
would remove all of the Istio resources, but it doesn’t remove the CustomResourceDefinition
types. We had to dig around and delete the CRDs manually. We ended up scripting this. Just something to keep in mind.
常識表明, helm delete --purge istio
會刪除所有Istio資源,但不會刪除CustomResourceDefinition
類型。 我們不得不手動挖掘并刪除CRD。 我們最終編寫了腳本。 只是要記住一點。
Once it was installed, we configured some endpoints and started reviewing what our new cluster could do. Oh boy, we were not disappointed.
安裝完成后,我們配置了一些端點并開始查看新集群可以做什么。 哦,男孩,我們沒有失望。
配置Istio (Configuring Istio)
The last thing to do is to annotate a namespace to indicate that Istio can perform automatic sidecar injection. This is the simplest way to use Istio. The annotation is simple. An example namespace yaml you could use is the following:
最后要做的是注釋一個名稱空間,以指示Istio可以執行自動邊車注入。 這是使用Istio的最簡單方法。 注釋很簡單。 您可以使用的示例名稱空間yaml是:
apiVersion: v1kind: Namespacemetadata: name: my-namespacelabels: istio-injection: enabled
Any applications that are deployed into this namespace will get an envoy proxy. This proxy will analyze your network traffic and publish to the Istio Prometheus server, where downstream systems can make use of it.
部署到該名稱空間的所有應用程序都將獲得特使代理。 該代理將分析您的網絡流量,并將其發布到Istio Prometheus服務器,下游系統可以在其中使用它。
我怎么知道我是否有特使代理人? (How do I know if I have an Envoy Proxy?)
Simple, run kubectl get pods
within your desired namespace. You’ll see something like this:
在所需的名稱空間中運行簡單的kubectl get pods
。 您會看到以下內容:
my-application-pod 2/2 Running 0 2d
Assuming you’re only deploying one container per pod, a second container will now appear. This second container is your envoy proxy. If it’s there and it’s ready, you’re good to go.
假設每個吊艙僅部署一個容器,現在將顯示另一個容器。 第二個容器是您的特使代理。 如果它已經準備好了,那您就很好了。
凱莉 (Kiali)
I’m coming right out of the gate with my favorite. Kiali provides live network diagramming and HTTP statistics for your applications. It’s a real crowd pleaser and it gives you an excellent “at a glance” dashboard.
我和我的最愛一起出來了。 Kiali為您的應用程序提供實時網絡圖表和HTTP統計信息。 這真是一個令人愉悅的人群,它為您提供了出色的“概覽”儀表板。
Look at the right-hand side of that image. On top of the high level of visibility, you get detail. You could stick the network overview on a TV screen. When one of those lines go red, you can dig into the HTTP details under the hood.
查看該圖像的右側。 除了高度可見性之外,您還可以獲得詳細信息。 您可以將網絡概述粘貼在電視屏幕上。 當其中一行變為紅色時,您可以深入了解HTTP細節。
凱莉古怪 (Quirks of Kiali)
You might see traffic coming from “unknown” in kiali, like this:
您可能會看到來自Kiali中“未知”的流量,如下所示:
This is actually the Kubernetes health check. It’s nothing to be concerned about. You can hide this by doing one of a few things:
這實際上是Kubernetes的健康檢查。 不用擔心。 您可以通過執行以下操作之一來隱藏它:
- Adjust your healthcheck to use a local exec on the docker container, rather than an HTTP based check. This is a bit hacky. 調整您的運行狀況檢查,以在Docker容器上使用本地exec,而不是基于HTTP的檢查。 這有點hacky。
- Use a different port than your main application port for your health check. This is the direction we’ve gone with, which also opens another door for (more on this later) 使用與主應用程序端口不同的端口進行健康檢查。 這是我們所走的方向,也為它打開了另一扇門(稍后會詳細介紹)
Istio is working on this and there is a fix in the brand new v1.1 release.
Istio正在研究此問題,全新的v1.1版本中有一個修復程序。
格拉法納 (Grafana)
Istio will populate a Grafana instance immediately for you. This Grafana instance is absolutely packed with useful application metrics, driven by the data published out of each application’s envoy proxy.
Istio將立即為您填充Grafana實例。 這個Grafana實例絕對包含有用的應用程序指標,這些指標由每個應用程序的特使代理發布的數據驅動。
As soon as you deploy a new application with an envoy proxy, you get metrics that typically takes teams weeks to put together:
一旦使用特使代理部署新應用程序,您就會獲得通常需要花費團隊數周才能得出的指標:
It’s important to recognize, I didn’t configure any of this. Istio is involved enough in your system to pull all of this out for you. And to top it off, this is one of many dashboards. There are tons of them, more than I think I’ll ever use. In the case of monitoring, more is more. I’d rather have too much detail and tone it down, than no visibility at all.
認識到這一點很重要, 我沒有配置任何東西。 Istio已充分參與您的系統,可以為您提供所有這些服務。 最重要的是,這是許多儀表板之一。 有很多,超過了我的預期。 在監視的情況下,更多就是更多。 我寧愿有太多的細節并調低色調,也不愿完全看不見。
普羅米修斯 (Prometheus)
This is the engine behind everything that’s going on. Prometheus is scraping and aggregating vast sums of data and presenting it in a convenient way. I haven’t had to spend a huge amount of time playing with it, to tell you the truth. The Istio services provide some incredibly useful, out of the box functionality. Prometheus can be used to write your own graphs or scrape custom metrics from your applications.
這是正在發生的一切背后的引擎。 Prometheus正在抓取和匯總大量數據,并以方便的方式進行呈現。 我不需要花很多時間來玩這個,就可以告訴你真相。 Istio服務提供了一些非常有用的即用型功能。 Prometheus可用于編寫您自己的圖形或從應用程序中刮取自定義指標。
Off of the back of this data, you can trigger alerts using Alert Manager, creating highly sophisticated monitoring and alerting platform for your applications.
在這些數據的支持下,您可以使用Alert Manager觸發警報,從而為您的應用程序創建高度復雜的監視和警報平臺。
您獲得的控制權 (The control you gain)
On top of all of this, Istio has some baked in utilities that really pushes the limit. You’ll be able to trigger faults, cause outages, blackhole traffic and much more. I’ve detailed a few of the cool features that I’ve had a chance to play with, but there are far more.
最重要的是,Istio推出了一些實用程序,這些實用程序確實在推動極限。 您將能夠觸發故障,引起中斷,黑洞流量等等。 我已經詳細介紹了一些我可以使用的很酷的功能,但是還有更多。
故障注入 (Fault Injection)
With Istio, you can inject failures. For example, the following YAML will cause 100% of requests to return an HTTP status code of 500. Useful for when you’re simulating a third party outage.
使用Istio,您可以注入故障。 例如,以下YAML將導致100%的請求返回500的HTTP狀態代碼。在模擬第三方中斷時很有用。
apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: ratings spec: hosts: - ratings http: - fault: abort: httpStatus: 500 percent: 100 match: - headers: end-user: exact: json route: - destination: host: ratings subset: v
The documentation is pretty good and you can dive into all sorts of this functionality. What I’m doing here is simply showing you the surface.
該文檔非常好,您可以深入了解此功能。 我在這里所做的只是向您展示表面。
彈性政策為標準 (Resilience policies as standard)
How often have you written logic to implement retries? Front-loading all of this in a product makes it difficult to focus on the specific business value. Istio makes this simpler. For example, by baking retries in:
您多久編寫一次邏輯以實施重試? 將所有這些預先加載到產品中,使得很難專注于特定的業務價值。 Istio使此過程更簡單。 例如,通過以下方式進行重試:
apiVersion: networking.istio.io/v1alpha3kind: VirtualService metadata: name: ratings spec: hosts: — ratings http: — route: — destination: host: ratings subset: v1 retries: attempts: 3 perTryTimeout: 2s
This will ensure that requests made by your service are retried three times, with a timeout of two seconds in each. No more pollution of your application code — load that into the service mesh and keep your services simple.
這將確保重試您的服務發出的請求3次,每次超時2秒。 不再污染您的應用程序代碼-將其加載到服務網格中并保持服務簡單。
相互TLS (Mutual TLS)
Service to service encryption can be tough. Ensuring certificates don’t expire is a serious operation… but not with Istio. Istio uses the certificate manager pod to ensure that your applications have their very own, shiny certificate.
服務到服務的加密可能很困難。 確保證書不過期是一項嚴肅的工作……但Istio卻不這樣做。 Istio使用證書管理器窗格來確保您的應用程序具有自己的閃亮證書。
Then, with the correct DestinationRule
, you can mandate that your applications will only allow TLS encrypted traffic. This ensures that all inter-cluster communication is locked down. The application doesn’t have a clue. It issues the request in HTTP and the Envoy proxy sidecar will transparently upgrade it to Mutual TLS. The following destination rule will ensure that all requests to v1
of the productpage
service must be encrypted using mutual TLS.
然后,使用正確的DestinationRule
,您可以強制您的應用程序僅允許TLS加密流量。 這樣可以確保所有群集間通信都被鎖定。 該應用程序沒有任何線索。 它以HTTP發出請求,Envoy代理sidecar將透明地將其升級為Mutual TLS。 以下目標規則將確保必須使用雙向TLS對對productpage
服務v1
的所有請求進行加密。
apiVersion: networking.istio.io/v1alpha3kind: DestinationRulemetadata: name: productpagespec: host: productpage trafficPolicy: tls: mode: ISTIO_MUTUAL subsets: - name: v1 labels: version: v1
沒有免費的午餐 (There’s no such thing as a free lunch)
As with everything, there are some dangers and tradeoffs. Istio is brilliant, I’m thoroughly impressed. It’s easy to go off the rails and find yourself with a service mash, rather than a service mesh.
與所有內容一樣,存在一些危險和權衡取舍。 Istio非常出色,給我留下了深刻的印象。 脫離服務軌很容易找到服務混搭,而不是服務網格。
凌亂的整合層 (Messy integration layers)
Anyone who has worked in a sufficiently large organization will have seen this. “Integration layers” that are originally designed to link two applications together. Then they get a little extra logic, a few files here and there, some routing rules sprinkled over the top and all of a sudden, they’re a nest of complexity.
在足夠大的組織中工作的任何人都會看到這一點。 最初設計為將兩個應用程序鏈接在一起的“集成層”。 然后,他們獲得了一些額外的邏輯,到處都是一些文件,一些路由規則散布在頂部,突然之間,它們變得非常復雜。
Be careful with Istio in this regard. It is tremendously powerful but requires careful thought. Some features are cool but you might not actually need them. And sometimes, dare I say it, a little repetition in microservices is more desirable than a service mesh with more logic in it than your actual applications.
在這方面,請謹慎使用Istio。 它功能強大,但需要仔細考慮。 有些功能很酷,但您實際上可能不需要它們。 有時候,我敢說,微服務中的一些重復比其中包含比實際應用中更多邏輯的服務網格更可取。
復雜 (Complexity)
Kubernetes offers a lot to learn. The learning curve is quite kind, especially when compared to the alternatives, but the domain is broad. When you introduce Istio, you also introduce a series of new, more complex concepts. VirtualService
and Gateway
types of Custom Resource Definitions that you will need to become comfortable with.
Kubernetes提供了很多知識。 學習曲線很親切,尤其是與其他選擇相比時,但領域很廣。 介紹Istio時,還介紹了一系列新的,更復雜的概念。 您需要熟悉的自定義資源定義的VirtualService
和Gateway
類型。
This is a trade-off. Look at your cluster or your team and decide. Is our monitoring doing the job perfectly? Are our applications resilient? Do the engineers complain about the repetition of logic? Make sure you’re getting something in return for this complexity and this trade is a no-brainer. Just don’t sleepwalk into a nightmare.
這是一個權衡。 查看您的集群或團隊并做出決定。 我們的監控是否完美地完成了工作? 我們的應用程序具有彈性嗎? 工程師是否抱怨邏輯的重復? 確保您從這種復雜性中得到了回報,而這筆交易毫無疑問。 只是不要夢walk以求。
瞬息萬變...快 (It’s changing… fast)
Istio has recently announced that it is production ready and with its 1.1
release, addressed a lot of the existing concerns. That said, this is a new product. If you’re the type of organization that struggles to keep up, the pace that Istio is moving at might be a detriment to you. Falling behind might be catastrophic, especially if security vulnerabilities and bugs turn up.
Istio最近宣布已準備好生產,并且其1.1
版本已解決了許多現有問題。 也就是說,這是一個新產品。 如果您是那種難以跟上的組織,那么Istio的發展步伐可能會對您不利。 落后可能會帶來災難性的后果,尤其是在出現安全漏洞和錯誤的情況下。
Once again, this is a burden you need to reason about. Do you have the capability to keep up? If not, could you? And even if you could, is it worth it? Do you really need this extra operational overhead?
再一次,這是您需要考慮的負擔。 你有能力跟上嗎? 如果沒有,可以嗎? 即使可以,這值得嗎? 您是否真的需要這些額外的運營開銷?
那是所有人 (That’s all folks)
I’ve given the highlights of my experience with Istio. I’ve personally used all the functionality in this article and it has been outstanding. We’ve seen the odd quirk or two but nothing that has given us much pause for thought. All in all, provided you have a situation that needs it, Istio takes your cluster to the next level.
我已經介紹了Istio的經歷。 我已經親自使用了本文中的所有功能,并且功能非常出色。 我們已經看到一兩個奇怪的怪癖,但是沒有什么讓我們停下來思考。 總而言之,只要您有需要的情況,Istio便可以將您的集群提升到一個新的水平。
I’m talking about Istio, Kubernetes, and DevOps regularly, on my twitter account.
我經常在我的Twitter帳戶上談論Istio,Kubernetes和DevOps。
翻譯自: https://www.freecodecamp.org/news/how-to-get-istio-up-and-running-1935dc7cfb90/
istio 和 kong