日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

RELATEED CONSULTING
相關(guān)咨詢
選擇下列產(chǎn)品馬上在線溝通
服務(wù)時間：8:30-17:00
你可能遇到了下面的問題
關(guān)閉右側(cè)工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案
Linkerd 升級到全新的 2.12 版本

Linkerd 升級到全新的 2.12 版本

作者：陽明 2022-09-12 21:10:42

云計算

云原生 Linkerd 2.12 是采用 Gateway API 作為核心配置機制的第一步。雖然這個 API 對于服務(wù)網(wǎng)格用例來說還不是完美的，但它為這個版本提供了一個強大的起點，更重要的是，在 Gateway API 的基礎(chǔ)上構(gòu)建將使我們能夠?qū)⑻囟ㄓ?Linkerd 的配置對象的數(shù)量保持在最低限度，即使我們引入了新功能。

在祁陽等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強發(fā)展的系統(tǒng)性、市場前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務(wù)理念，為客戶提供成都網(wǎng)站建設(shè)、網(wǎng)站制作 網(wǎng)站設(shè)計制作按需設(shè)計,公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),成都品牌網(wǎng)站建設(shè),全網(wǎng)營銷推廣,外貿(mào)網(wǎng)站建設(shè),祁陽網(wǎng)站建設(shè)費用合理。

Linkerd 最新的 2.12 版本已經(jīng)發(fā)布了，這個龐大的版本為 Linkerd 引入了基于路由的策略，允許用戶以完全零信任的方式定義和執(zhí)行基于 HTTP 路由的授權(quán)策略。這些策略建立在 Linkerd 強大的工作負載身份之上，由雙向 TLS 保護，并使用 Kubernetes 新推出的 Gateway API 的類型進行配置。

更新日志

Linkerd 2.12 是采用 Gateway API 作為核心配置機制的第一步。雖然這個 API 對于服務(wù)網(wǎng)格用例來說還不是完美的，但它為這個版本提供了一個強大的起點，更重要的是，在 Gateway API 的基礎(chǔ)上構(gòu)建將使我們能夠?qū)⑻囟ㄓ?Linkerd 的配置對象的數(shù)量保持在最低限度，即使我們引入了新功能。這是我們?yōu)?Kubernetes 成為最簡單和最輕量的服務(wù)網(wǎng)格的目標的重要組成部分。此外 2.12 版本還引入了訪問日志記錄，這是一個期待已久的功能，允許 Linkerd 生成 Apache 樣式的請求日志。它增加了對 iptables-nft 的支持，并引入了許多其他改進和性能增強。

Per-route 策略

Linkerd 的新的 per-route 策略擴展了現(xiàn)有的基于端口的策略，對服務(wù)如何被允許相互通信進行更精細的控制。這些策略是為采取零信任安全方法的組織設(shè)計的，這種方法不僅需要加密，還需要強大的工作負載身份和明確的授權(quán)。

  • 將網(wǎng)絡(luò)視為對抗性的：它們不依賴 IP 地址，也不要求 CNI 層或底層網(wǎng)絡(luò)的任何其他方面是安全的。
  • 使用安全的工作負載身份：Linkerd 的工作負載身份是由 ServiceAccounts 自動生成的，并在連接時通過雙向 TLS 進行加密驗證。
  • 在 Pod 級別上強制執(zhí)行：每個連接和每個請求都經(jīng)過驗證。
  • 很容易的允許模式：有安全意識的采用者可以很容易地默認拒絕對敏感資源的訪問，除非明確允許（"最小特權(quán)原則"）。

默認拒絕配置在 Kubernetes 中可能會有一些問題，因為 health 和 readiness 探針狀態(tài)需要在沒有授權(quán)的情況下通過。在 Linkerd 2.12 中，health 和 readiness 狀態(tài)探測現(xiàn)在是默認授權(quán)的，但也可以明確授權(quán)，同時仍然鎖定其他應(yīng)用端點。

Gateway API

Linkerd 2.12 提供了支持 Kubernetes Gateway API 的第一步。雖然 Gateway API 最初是作為 Kubernetes 中長期存在的 Ingress 資源的一個更豐富、更靈活的替代品而設(shè)計的，但它為描述服務(wù)網(wǎng)狀流量提供了一個很好的基礎(chǔ)，并允許 Linkerd 將其增加的配置保持在最低水平。

在 Linkerd 2.12 中，Linkerd 提供了 Gateway API 的部分實現(xiàn)來配置 Linkerd 的基于路由的策略。這樣我們就可以開始使用 Gateway API，而不用實現(xiàn)規(guī)范中對 Linkerd 沒有意義的部分。隨著 Gateway API 的發(fā)展，也會慢慢地更好滿足 Linkerd 的需求。

訪問日志

Linkerd 2.12 還引入了訪問日志記錄，它允許代理發(fā)出 Apache 樣式的請求日志。出于性能和資源利用率的原因，此功能默認關(guān)閉（尤其是對于高流量工作負載），但也可以在需要它的情況下輕松啟用。

其他更新

Linkerd 2.12 還有大量的其他改進、性能提升和錯誤修復(fù)，包括：

  • 一個新的config.linkerd.io/shutdown-grace-period 注解，用于配置代理的最大寬限期，以便優(yōu)雅地關(guān)閉。
  • 一個新的iptables-nft 模式，用于 Linkerd 的 init 容器中的iptables-nft 支持。
  • 修復(fù)了某些控制平面組件在信任根輪換后未按要求重啟的問題。
  • 修正了當在 Linkerd 命名空間中發(fā)現(xiàn)意外的 Pod 時，linkerd check 命令崩潰的問題。
  • 修改了proxy.await 的 Helm 值，這樣用戶就可以在控制平面組件上禁用linkerd-await。
  • 注釋，允許 Linkerd 擴展部署在必要時被自動縮放器驅(qū)逐。
  • 能夠在獨立模式下運行Linkerd CNI 插件。
  • 多集群擴展中的 ServiceAccount token Secret，支持 Kubernetes 版本>= v1.24。

升級

現(xiàn)在我們將集群中的 Linkerd 升級到最新的 2.12 版本。

首先需要更新 Linkerd CLI 工具，執(zhí)行如下所示的命令即可：

$ curl --proto '=https' --tlsv1.2 -sSfL https://run.linkerd.io/install | sh

這會將你的本地 CLI 升級到最新版本。當然我們有可以通過 Linkerd 的 Release 頁面直接下載對應(yīng)平臺的 CLI 安裝包。

$ wget https://github.91chi.fun/https://github.com//linkerd/linkerd2/releases/download/stable-2.12.0/linkerd2-cli-stable-2.12.0-darwin-arm64
$ sudo mv linkerd2-cli-stable-2.12.0-darwin-arm64 /usr/local/bin/linkerd
$ chmod +x /usr/local/bin/linkerd

驗證 CLI 已安裝并正確運行：

$ linkerd version
Client version: stable-2.12.0
Server version: stable-2.11.1

可以看到 CLI 升級成功了，由于控制平面還沒升級，所以看到的還是現(xiàn)在的 2.11.1 版本。

接下來就可以升級 Kubernetes 集群上的 Linkerd 控制平面了，不用擔心，現(xiàn)有的數(shù)據(jù)平面將繼續(xù)使用更新版本的控制平面運行，并且你的網(wǎng)格服務(wù)不會出現(xiàn)故障。

如果你使用的是 viz 插件自帶的 Prometheus 組件，那么升級后數(shù)據(jù)會丟失，如果你配置的外置的 Prometheus 則不用擔心該問題。

Linkerd SMI 擴展

如果你使用 CLI 安裝了 Linkerd 2.11.x，并且正在使用 TrafficSplit CRD，則需要注意丟失 TS 的 CR，如果你不使用此 CRD，則可以忽略該注意事項。

TrafficSplit CRD 不再隨 Linkerd 2.12.0 提供，而是由 Linkerd SMI 擴展提供。

同樣首先從 Release 頁面下載對應(yīng)的可執(zhí)行包：

$ wget https://github.91chi.fun/https://github.com//linkerd/linkerd-smi/releases/download/v0.2.0/linkerd-smi-0.2.0-darwin-arm64
$ chmod +x linkerd-smi-0.2.0-darwin-arm64
$ sudo mv linkerd-smi-0.2.0-darwin-arm64 /usr/local/bin/linkerd-smi
$ linkerd-smi version
v0.2.0

同樣 Linkerd SMI 也可以通過 CLI 工具進行安裝，此擴展包含一個 SMI-Adaptor，它將 SMI 資源轉(zhuǎn)換為本地 Linkerd 資源。

$ linkerd smi install | kubectl apply -f -
$ linkerd smi check

此外也可以通過下面的 Helm 方式來安裝 Linkerd SMI 擴展。但在安裝該擴展之前，你需要在 CRD 中添加以下注釋和標簽，以便 linkerd-smi chart 可以采用它：

$ kubectl annotate --overwrite crd/trafficsplits.split.smi-spec.io \
  meta.helm.sh/release-name=linkerd-smi \
  meta.helm.sh/release-namespace=linkerd-smi
# 添加smi repo倉庫
$ helm repo add l5d-smi https://linkerd.github.io/linkerd-smi
$ helm upgrade --install linkerd-smi -n linkerd-smi --create-namespace l5d-smi/linkerd-smi
Release "linkerd-smi" has been upgraded. Happy Helming!
NAME: linkerd-smi
LAST DEPLOYED: Sun Sep 11 14:54:02 2022
NAMESPACE: linkerd-smi
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
The Linkerd SMI extension was successfully installed 
$ kubectl get pods -n linkerd-smi
NAME                           READY   STATUS      RESTARTS        AGE
namespace-metadata--1-jnttx    0/1     Completed   0               17m
smi-adaptor-5788b875d4-r4b7w   2/2     Running     6 (5m53s ago)   17m

最后，你可以繼續(xù)使用通常的 CLI 升級說明，但在應(yīng)用 linkerd upgrade --crds 的輸出時避免使用 --prune 標志以避免刪除 TrafficSplit CRD！

升級

接下來我們可以直接使用 linkerd upgrade 命令來升級控制平面，該命令確保控制平面的所有現(xiàn)有配置和 mTLS 被保留下來。

$ kubectl get crd |grep linkerd
serverauthorizations.policy.linkerd.io                     2022-08-19T04:06:33Z
servers.policy.linkerd.io                                  2022-08-19T04:06:33Z
serviceprofiles.linkerd.io                                 2022-08-19T04:06:33Z
$ linkerd upgrade --crds | \
  kubectl apply --prune -l linkerd.io/control-plane-ns=linkerd \
  --prune-whitelist=apiextensions.k8s.io/v1/customresourcedefinition \
  --prune-whitelist=split.smi-spec.io/v1alpha2/trafficsplit \
  -f -
customresourcedefinition.apiextensions.k8s.io/authorizationpolicies.policy.linkerd.io created
customresourcedefinition.apiextensions.k8s.io/httproutes.policy.linkerd.io created
customresourcedefinition.apiextensions.k8s.io/meshtlsauthentications.policy.linkerd.io created
customresourcedefinition.apiextensions.k8s.io/networkauthentications.policy.linkerd.io created
customresourcedefinition.apiextensions.k8s.io/serverauthorizations.policy.linkerd.io configured
customresourcedefinition.apiextensions.k8s.io/servers.policy.linkerd.io configured
customresourcedefinition.apiextensions.k8s.io/serviceprofiles.linkerd.io configured
customresourcedefinition.apiextensions.k8s.io/trafficsplits.split.smi-spec.io configured

注意，上面更新命令中我們使用了 --prune 標志，該標志可以刪除在新版本中不再存在的前一版本的 Linkerd 資源，上面我們是更新新版本的 CRD 資源，可以看到新增了 4 個 CRD，因為現(xiàn)在引入了 Gateway API。

$ kubectl get crd |grep linkerd
authorizationpolicies.policy.linkerd.io                    2022-09-11T02:56:13Z
httproutes.policy.linkerd.io                               2022-09-11T02:56:13Z
meshtlsauthentications.policy.linkerd.io                   2022-09-11T02:56:14Z
networkauthentications.policy.linkerd.io                   2022-09-11T02:56:14Z
serverauthorizations.policy.linkerd.io                     2022-08-19T04:06:33Z
servers.policy.linkerd.io                                  2022-08-19T04:06:33Z
serviceprofiles.linkerd.io                                 2022-08-19T04:06:33Z

不過需要注意的是新增的 Gateway API 相關(guān)的 CRD 并不是原始 Kubernetes 下面定義的，而是也是在 policy.linkerd.io 的組下面，這是因為 Linkerd 對這些 CRD 也做了一些適配。

接下來直接使用下面的命令更新控制平面資源對象：

$ linkerd upgrade | \
 kubectl apply --prune -l linkerd.io/control-plane-ns=linkerd -f -

接下來，再次運行此命令并添加一些 --prune-whitelist 標志，這可以確保正確修剪某些集群范圍的資源所必需的。

$ linkerd upgrade | kubectl apply --prune -l linkerd.io/control-plane-ns=linkerd \
  --prune-whitelist=rbac.authorization.k8s.io/v1/clusterrole \
  --prune-whitelist=rbac.authorization.k8s.io/v1/clusterrolebinding \
  --prune-whitelist=apiregistration.k8s.io/v1/apiservice -f -

升級過程完成后，同樣可以運行檢查命令來確保一切正常：

$ linkerd check

該命令將針對控制平面進行一系列檢查，并確保其正常運行。

現(xiàn)在再次查看 Linkerd 版本，正常 Server 端的版本也更新了。

$ linkerd version
Client version: stable-2.12.0
Server version: stable-2.12.0

接著我們就可以升級數(shù)據(jù)平面了，最簡單的方法是在你的服務(wù)上運行滾動部署，允許代理注入器在它們出現(xiàn)時注入最新版本的代理。

$ kubectl -n  rollout restart deploy

一般來說穩(wěn)定版的控制平面與上一個穩(wěn)定版的數(shù)據(jù)平面是兼容的，所以數(shù)據(jù)平面的升級可以在控制平面升級后的任何時候進行，但是不建議超過一個穩(wěn)定版本的差距。

同樣更新完成后可以使用 check 命令來校驗數(shù)據(jù)平面狀態(tài)。

$ linkerd check --proxy
# ......
linkerd-data-plane
------------------
√ data plane namespace exists
√ data plane proxies are ready
? data plane is up-to-date
    some proxies are not running the current version:
        * emoji-696d9d8f95-5vn9w (stable-2.11.1)
        * vote-bot-646b9fd6fd-8xj2j (stable-2.11.1)
        * voting-ff4c54b8d-xhjv7 (stable-2.11.1)
        * web-5f86686c4d-58p7k (stable-2.11.1)
        * web-svc-2-f9d77474f-vxlrh (stable-2.11.1)
        * ingress-nginx-controller-f56c7f6fd-rxhrs (stable-2.11.1)
    see https://linkerd.io/2.12/checks/#l5d-data-plane-version for hints
? data plane and cli versions match
    emoji-696d9d8f95-5vn9w running stable-2.11.1 but cli running stable-2.12.0
    see https://linkerd.io/2.12/checks/#l5d-data-plane-cli-version for hints
√ data plane pod labels are configured correctly
√ data plane service labels are configured correctly
√ data plane service annotations are configured correctly
√ opaque ports are properly annotated

Linkerd extensions checks
=========================

- Running smi extension check

該命令通過一組檢查來驗證數(shù)據(jù)平面是否正常運行，并將列出仍在運行舊版本代理的 pod，然后我們可以根據(jù)實際情況去升級對應(yīng)的 pod 即可。

Linkerd Viz 擴展

另外還有一個需要注意的是 viz 插件，在最新版本中已經(jīng)沒有內(nèi)置 grafana 了，所以這里我們先直接將該插件卸載干凈（該插件不會影響網(wǎng)格的核心功能），然后重新安裝最新版本。

$ linkerd viz install | kubectl delete -f -

卸載完成后重新安裝，由于新版本已經(jīng)沒有內(nèi)置 Grafana 了，我們重新安裝的使用可以通過 --set grafana.url 來指定外部的 Grafana 地址（如果是集群外的地址可以通過 grafana.externalUrl 參數(shù)指定），同樣我們還可以使用外部的 Prometheus：

$ linkerd viz install --set grafana.url=grafana:3000,prometheusUrl=http://prometheus.kube-mon.svc.cluster.local:9090,prometheus.enabled=false | kubectl apply -f -

重新安裝后查看 viz 的 pod 列表：

$ kubectl get pods -n linkerd-viz
NAME                           READY   STATUS    RESTARTS   AGE
metrics-api-674bf48d7f-kzr5b   2/2     Running   0          17m
tap-67d6d8ff4d-q7nqn           2/2     Running   0          5m21s
tap-injector-7c565f754-jgvc5   2/2     Running   0          5m20s
web-87b958bcf-d5pfp            2/2     Running   0          5m20s

可以看到現(xiàn)在沒有了 Grafana 和 Prometheus 了，因為我們對接的外部 Prometheus，而 Grafana 則是新版本中沒有內(nèi)置使用了，上面我們指定的 Grafana 地址在 viz 同命名空間之下，所以這里我們手動安裝一個即可。

如果單個 Grafana 實例指向多個 Linkerd，你可以通過其 UID 中的不同前綴分隔儀表板，可以在每個 Linkerd 實例的 grafana.uidPrefix 設(shè)置中配置這些前綴。

這里我們直接使用 Helm Chart 來進行安裝，定制一個如下所示的 values 文件：

podAnnotations:
  linkerd.io/inject: enabled
grafana.ini:
  server:
    root_url: "%(protocol)s://%(domain)s:/grafana/"
  auth:
    disable_login_form: true
  auth.anonymous:
    enabled: true
    org_role: Editor
  auth.basic:
    enabled: false
  analytics:
    check_for_updates: false
  panels:
    disable_sanitize_html: true
  log:
    mode: console
  log.console:
    format: text
    level: info
datasources:
  datasources.yaml:
    apiVersion: 1
    datasources:
      - name: prometheus
        type: prometheus
        access: proxy
        orgId: 1
        url: http://prometheus.kube-mon.svc.cluster.local:9090
        isDefault: true
        jsonData:
          timeInterval: "5s"
        editable: true
dashboardProviders:
  dashboardproviders.yaml:
    apiVersion: 1
    providers:
      - name: "default"
        orgId: 1
        folder: ""
        type: file
                                                 

                                                新聞標題：Linkerd 升級到全新的 2.12 版本                                                

                                                分享URL：http://m.5511xx.com/article/cddgops.html