原文出自：Rookout blog
原文作者：Gedalyah Reback（Senior Product Marketing Manager at Rookout）
Kubernetes 既具有革命性，又具有傳播性。這是一次徹底的改革，需要一系列全新的配套、支持工具，來覆蓋和支撐整個生態(tài)系統(tǒng)。實際上，目前已有數百種專為 k8s 而設計的工具，其中既有開源的，也有授權的。
選擇 Kubernetes 技術堆棧似乎是一項很艱巨的任務，因為這一套生態(tài)系統(tǒng)是十分龐大的。如果要將所有工具及其調試方法完整地列出來，這就超出了本文的范圍。Developer-first observability 要求簡化這些雜亂無章的工具。全面了解和調試 Kubernetes 部署需要一個總體的工具和策略，該工具和策略比使用堆棧中的每個工具更直接，并且高效。話雖如此，大多數單獨的工具都提供內部可觀察性。知道如何獲得這些可以為開發(fā)人員提供有利條件。
本文，并不會對每一種工具都進行詳盡的介紹，但本文所列的這份清單，將涵蓋最基本的關鍵點以及每一項中的主要工具。
調試 K8S 服務網格和入口控制器
我們已經有了編排和部署工具，那么為什么我們需要一些聽起來多余的東西呢？這就是協(xié)調 Kubernetes 與微服務之間的關鍵所在。服務網格和入口控制器作為可配置的抽象層來控制進出 Kubernetes 的流量。
服務網格對 Kubernetes 內的服務進行協(xié)調（即東西向流量）。
入口控制器協(xié)調流入（入口）（以及可能流出（出口））的 Kubernetes 流量（即南北流量）。在 Kubernetes 中，我們會使用 Kubernetes API 來實現配置和部署以下內容：
1. 接受入口（傳入）流量并通過負載均衡將其路由到 Pod 上；
2. 監(jiān)控 Pod 并自動更新負載均衡規(guī)則；
3. 管理與集群外服務通信的出口（傳出）流量；
你的 Kubernetes 堆棧是否真的需要這兩種工具，這是值得商榷的，因此，實際上這兩個類別中的所有工具都在相互競爭。此外，您還可以在這里混合使用 API 網關，這就像入口控制器能實現控制入口流量和出口流量一樣。
三大服務網格分別是 Istio、Linkerd 和 Consul。他們使用管理集群級數據流量的“控制平面”和“數據平面”直接處理網格內服務之間的數據處理功能。
1. 調試 Istio
以下兩個命令都能很好地觀測道 Istio 網格中的流量：
您還可以瀏覽調試日志。請注意，這 debug 是 Istio 日志的五種可能輸出之一（其他是 none、 error、 warn和 info）。請注意，調試將提供最多的數據，一些開發(fā)人員認為 Istio 在日志方面信息量很大。
以下示例定義了要分析的不同范圍：
2. 調試 Linkerd
調試的默認方法是使用調試容器（調試邊車）。但是，Linkerd 調試的工作方式因您使用的應用程序類型而異。
例如，您將使用指標來調試 HTTP 應用程序和gRPC 應用程序的 請求 跟蹤。
1.調試 502，即錯誤的網關響應
2.調試 控制平面端點
3.使用指標調試 HTTP 應用程序
4.使用請求跟蹤調試 gRPC 應用程序
對于 Linkerd 調試容器/sidercar：
3. 調試Consul
Consul 調試命令 在 Consul 中非常簡單。使用 -capture 定義您要分析的內容，并為間隔、持續(xù)時間、API、 Go pprof 包等添加參數。
4. NGINX 入口控制器
NGINX 很有趣，因為它很容易將兩個獨立的工具混為一談： NGINX 入口控制器 和 NGINX 服務網格。本節(jié)著眼于入口控制器。為了了解 NGINX 如何定位這兩個工具，他們的架構圖很有幫助：
NGINX 架構圖（入口控制器與服務網格）（來源：NGINX 文檔）
您可以在這里介紹兩種類型的日志：用于 NGINX 入口控制器 本身， 和/或 更強大的整體 NGINX 日志。
使用 NGINX 入口日志進行調試
您可以通過添加 到 Kubernetes 部署的部分來將日志級別更改為 調試。請注意，必須使用 NGINX 部署構建 - 以便稍后獲得調試日志。–v=5-args-with-debug
使用常規(guī) NGINX 錯誤日志進行調試
當你配置 NGINX 日志時，你必須設置錯誤日志，這對于調試來說是最重要的。
但在你這樣做之前，你需要確保首先編譯 NGINX（如果使用開源版本）并帶有調試選項（是的，這感覺沒有必要，但目前情況就是這樣，因為 NGINX嘗試管理它對存儲日志數據的承諾。當然，默認情況下該選項可能只是關閉，但我們并不生活在那個替代的現實中）。
首先，下載 NGINX 的開源版本。然后開始編譯過程。
添加 –with-debug 參數：
編譯：
安裝：
并重新啟動。
現在，第 2 階段。仔細檢查安裝是否 –with-debug 可用：
打開 NGINX 配置文件：
并設置 debug 參數：
NGINX 文檔中提供了更多選項 。最后，我要補充一點，您還可以使用 Syslog 作為替代方案，它需要一個 syslog: 前綴，然后指定一個服務器（通過 IP、UNIX 套接字或域）。
5. 在 Traefik（入口控制器）中調試
Traefik Kubernetes Ingress 控制器是另一個入口控制器選項。它管理 Kubernetes 集群服務；也就是說，它通過支持 Ingress 規(guī)范來管理對集群服務的訪問。不要將它與公司的其他工具混為一談：Traefik Mesh 和 Traefik Gateway。
與 NGINX 一樣，您可以同時設置 Traefik Ingress 日志和/或 常規(guī) Traefik 日志和調試。
Traefik 調試日志
您可以配置 調試級別的 Traefik 日志 或通過 Traefix API debugs 進行調試。兩者都可以通過以下三種方式之一完成：通過 Traefik CLI、 .yaml 配置文件或 .toml 配置文件。
日志方面，這是一個快速的三步過程： 1. 設置 filepath. 2. 設置 format (json 或 text)。3. 設置 level. 此示例展示了如何在 Traefik CLI 中執(zhí)行此操作，但您也可以使用 YAML 或 TOML 配置文件。
DEBUG 是 Traefik 中的六個日志級別之一，但默認為 ERROR （其他為 PANIC、 FATAL、 WARN和 INFO）。
Traefix API 調試
在 CLI 中，設置 API：
然后，您將為 Kubernetes 和其他容器編排器或基礎設施管理器（Docker Swarm、Docker 等）提供不同的配置選項。當然，讓我們展示一個基于 Traefik 文檔的 Kubernetes CRD 示例（在 YAML 中） ：
然后將其設置為在 CLI 中調試：
調試用于基礎設施管理的 Kubernetes 工具
包管理器、基礎設施即代碼、配置管理器、自動化引擎等。這是一個相當不拘一格的類別，因為許多競爭工具對相同的任務采用不同的方法，有時不是直接競爭，而是互補工具。
比較各種 Kubernetes 自動化、包和配置工具的非詳盡維恩圖 (Gedalyah Reback)
因此，其中許多工具可能能夠達到列表中其他工具無法達到的目的。同時，雖然您通?？梢詳U展它們以完成其他類型的任務，但與其中一種替代方案相比可能非常困難。由于這種重疊，Kubernetes 架構圖可能看起來像科學怪人應用程序。
（* in combination with CrossPlane, Helm and Kustomize can provision cloud resources ** kubectl apply -k (docs) *** when you provision K8S resources with terraform provider is actually deploy）
不過，每個用例都是不同的。無論您最終使用了哪些工具或使用了多少工具，您都應該知道在哪里以及如何調試它們。
使用 Pulumi，您可以使用成熟的編程語言編寫或定義您的基礎設施：Go、Python、C#、vanilla JS 和 TypeScript。Terraform 使用 HCL 定義基礎設施，然后使用 JSON 狀態(tài)文件對其進行跟蹤。Ansible 雖然使用 YAML 來定義基礎架構，并且本質上是無狀態(tài)的。選項從那里擴展。
6. 調試 Helm
Helm 已經成為很多人事實上的 Kubernetes 包管理器。它利用稱為 Helm Charts 的 Kubernetes 部署的復雜模板。模板化或構建用于部署的圖表本身就是一個過程。有幾種方法可以 調試 Helm 模板。
The –debug Flag
首先，檢查您已經安裝了哪些模板：
然后讓服務器渲染模板并返回清單：
或者…
您也可以將 –debug 標志與大多數其他命令一起使用。無論您在做什么，它都會提供更詳細的日志響應。您可以將這些日志推遲到特定文件，如下所示：
7 、調試 Terraform
Terraform 并不是為 Kubernetes 原生設計的，但它已成為一種流行的選擇。Terraform 使用它稱為提供程序的支持包系統(tǒng)，并構建了自己的 Kubernetes 提供程序。它使用 HashiCorp 配置語言 (HCL) 來部署和管理 Kubernetes 資源、集群、API 等。
或者，您可能更喜歡通過像 Kubernetes 這樣的提供程序來工作 hashicorp/helm，它比 vanilla Kubernetes 選項更強大。您可以將 Terraform 日志用于多個日志級別之一，包括調試。還有用于調試 Terraform 提供程序或插件集成的特定策略。
Terraform 調試日志
您可以使用 或 來記錄 Terraform 本身， TF_LOG 或者 使用 來記錄TF_LOG_CORETerraform 和所有提供者 TF_LOG_PROVIDER。您可以將日志設置擴展到只有一個特定的提供程 TF_LOG_PROVIDER_。
或者，您可以使用 stderr 進行日志記錄，但不能在 Terraform 中使用 stdout，因為它已經是專用通道。
您可以使用原生 tflog 包進行結構化日志記錄，然后設置日志級別。根據您使用的是框架還是 SDK Terraform 插件，您可以設置創(chuàng)建調試日志的上下文。考慮 Terraform 文檔中的以下示例：
8. 調試 Kustomize
您可能已經從拼寫中猜到這是 Kubernetes 原生的。Kustomize 是一個配置管理器，它的名字來源于自定義配置文件。它不像 Helm 那樣依賴模板，而是更喜歡嚴格使用 YAML 文件，甚至使用 YAML 文件來配置其他 YAML 文件。
現在，對于任何想要獨立于 kubectl 和其他元素調試 Kustomize 的人來說，它更加復雜。有點像尋找舊約中提到的地獄，不可能找到任何關于日志記錄、跟蹤，尤其是 Kustomize 本身的調試的文檔。一段時間以來，一直存在對嚴格屬于 Kustomize 的日志的需求，但有一些 解決方法。
您可以 在應用程序log_level 內的文件中進行調試 。deployment.yml
之后，您將添加 kustomization.yml 文件，刪除原始資源，然后重新部署應用程序。
9. 調試 Ansible
您必須啟用調試設置，默認情況下是關閉的。接下來，您可以使用 debugger 關鍵字，如Ansible 文檔中的此示例 所示：
ansible.cfg 在該部分的文件中 全局啟用它 [defaults] ：
10. 調試 Pulumi
Pulumi 是社區(qū)中較新的孩子之一，主要是 IaC 工具。它通過將 Kubernetes API 公開為 SDK 來部署，然后在其工作的基礎設施中使用容器和 Kubernetes 集群管理 IaC。話雖如此，Pulumi 嘗試使用已經在生態(tài)系統(tǒng)中廣泛使用的工具，因此它使用 TF_LOG 和使用它的規(guī)則就像在 Terraform 中一樣。
Pulumi 還具有原生日志配置，可以使用常規(guī)編程語言而不是 CLI/領域特定語言進行操作。此示例涵蓋 Java：
此外，您還可以實現 Pulumi Debug API。Pulumi 的文檔使用這個多選樣式示例，參數中列出了不同的選項：
調試 Kubernetes 工具是一種冒險
每個工具都有不止一種方法來調試其服務和實現。有些有不同的方法來調試日志，而另一些則包括跟蹤收集作為選項。開發(fā)人員優(yōu)先的可觀察性要求您找到提供最清晰答案和最簡單設置的選項。一些競爭工具也有可能在同一個 Kubernetes 堆棧中協(xié)作。希望本概述能讓您了解現有的內容，以及您希望使用哪些工具進行 Kubernetes 調試。
但是要真正了解整個 Kubernetes 堆棧中發(fā)生的事情，需要一個真正的總體工具。
Bootes——K8s多集群多云管理平臺
kaiyun開云創(chuàng)新K8s多集群多云管理平臺（Bootes），云原生混合云管平臺，通過單一控制面板實現跨混合云的Kubernetes統(tǒng)一管理，專注于Kubernetes的多云統(tǒng)一管理，無縫對接多套異構環(huán)境的Kubernetes集群。提供多租戶的Kubernetes原生資源對象管理、應用管理、一站式應用商店、統(tǒng)一的監(jiān)控告警平臺、GitOps、租戶級別的資源計量等能力。友好易用的管理界面讓用戶快速開展應用的部署、管理、監(jiān)控等作業(yè)。
獲取K8s多集群多云管理解決方案>>
---------------
獲取更多云原生技術干貨，請關注“深圳kaiyun開云創(chuàng)新”公眾號>>
讓企業(yè)都能高效創(chuàng)新
企業(yè)云原生數字化創(chuàng)新平臺CloudOS?
可插拔云原生工具集Cloud Native Toolkit
開發(fā)者專屬一站式在線服務Methodot
