如何解決與 kubernetes 服務的通信問題

Question

設置 jaeger 跟蹤...所以以前我有一個二進制可執行文件 (jaeger-agent) 與服務器端應用程序一起在 Linux CentOS 8 機器上運行。 跟蹤跨度被發送到端口 14250 上的 jaeger-collector 服務（由 kubernetes 設置）並且一切正常。 然后最近由於系統崩潰，我們不得不重新啟動 jaeger 跟蹤服務。 現在事情已經停止工作，並且從日志中可以看到“504 網關超時”並且代理無法再與收集器通信。

在 AWS 中，我們運行了一個 kubernetes 服務“jaeger-collector”，它符合這里的服務https://github.com/jaegertracing/jaeger-kubernetes/blob/master/jaeger-production-template.yml ，唯一的區別是我使用的是 1.16 版。

該服務沒有外部 IP。 如何使用curl測試與 jaeger-collector 服務的通信？ 或者我是否需要一個外部 IP，也許這就是網關超時的原因？ 我嘗試將curl與 ClusterIP 一起使用，但似乎不起作用。

Answer 1

我嘗試在 Kubernetes 1.16 集群上應用您的文件，但存在一些問題：

1. 它使用在 Kubernetes 1.16中廢棄的 apiVersions 。 ie- apiVersion: extensions/v1beta1應該變成apps/v1 。
2. Deployments 沒有任何選擇器，Daemonset 也沒有。

.spec.selector 字段定義了 Deployment 如何找到要管理的 Pod。

看起來你正在應用一些非常古老的東西。 Kubernetes 在其文檔中指出了以下內容，所以我想知道這是否適用於默認選擇器的舊版本 Kubernetes。

從 Kubernetes 1.8 開始，您必須指定一個與 .spec.template 的標簽匹配的 pod 選擇器。 Pod 選擇器在留空時將不再是默認設置。

看起來你應該采取一種新的方法——環顧四周，我在這里和這里找到了一些很好的教程，而 Jaeger 自己在這里提供了類似的方法。 它們都使用Kubernetes Operators 。

Kubernetes operator 是特定於應用程序的控制器，它擴展了 Kubernetes API 的功能，以代表 Kubernetes 用戶創建、配置和管理復雜應用程序的實例

我不知道你的意思是“所以以前我有一個二進制可執行文件（jaeger-agent）在 Linux CentOS 8 機器上與服務器端應用程序一起運行”

您正在應用的文件看起來像是將代理部署為 daemonset ，這意味着代理在集群的每個節點上作為 pod 運行。 如果它在您的 k8 集群中運行，那么這就是我通常對 kubernetes services 進行故障排除的方法。 如果它完全在你的集群之外運行，那么你需要確保它與之通信的服務暴露在集群之外，可能使用 LoadBalancer 類型。