Kubernetes 運算子

版本 1.62 最新版

了解運算子

Jaeger 運算子是 Kubernetes 運算子的實作。運算子是可以簡化執行其他軟體之操作複雜性的軟體。更具體而言，運算子是一種封裝、部署和管理 Kubernetes 應用程式的方法。

Kubernetes 應用程式是指部署在 Kubernetes 上並使用 Kubernetes API 和 kubectl (kubernetes) 或 oc (OKD) 工具管理的應用程式。為了能夠充分利用 Kubernetes，您需要一組一致的 API 來擴充，以便為在 Kubernetes 上執行的應用程式提供服務和管理。將運算子視為在 Kubernetes 上管理此類型應用程式的執行階段。

安裝運算子

Jaeger 運算子可以安裝在以 Kubernetes 為基礎的叢集中，並且能夠在特定命名空間或整個叢集中監看新的 Jaeger 自訂資源 (CR)。每個叢集通常只有一個 Jaeger 運算子，但在多租戶情境中，每個命名空間最多可能有一個 Jaeger 運算子。偵測到新的 Jaeger CR 時，運算子會嘗試將自己設定為資源的擁有者，將標籤 jaegertracing.io/operated-by 設定為新的 CR，並以運算子的命名空間和名稱作為標籤的值。

雖然我們希望 Jaeger 運算子適用於盡可能多的 Kubernetes 版本，但僅預期我們會修正可在 Kubernetes 最近三個次要版本（目前、目前-1 和 目前-2）中重現的錯誤，這是比較實際的做法。

雖然多個運算子可能同時監看同一組命名空間，但哪個運算子會成功將自己設定為 CR 的擁有者是未定義的行為。自動注入 sidecar 也可能會導致未定義的行為。因此，強烈建議每個命名空間最多有一個運算子在監看。請注意，命名空間可能包含任意數量的 Jaeger 執行個體 (CR)。

Jaeger 運算子版本會追蹤一個版本的 Jaeger 元件 (jaeger-query、jaeger-collector、jaeger-agent)。當發行新版本的 Jaeger 元件時，將會發行新版本的運算子，該運算子了解如何將先前版本的執行個體升級至新版本。

先決條件

自 1.31 版起，Jaeger 運算子會使用 Webhook 來驗證 Jaeger 自訂資源 (CR)。這需要安裝 cert-manager 。支援版本的更詳細清單可在相容性矩陣中找到。安裝指南可在此處找到。

必須安裝 cert-manager 1.6.1 或更高版本。

安裝模式

可以安裝 Jaeger 運算子來監看整個叢集或特定命名空間中新的 Jaeger 自訂資源 (CR)。當設定為叢集模式時，運算子可以

監看所有命名空間中與 Jaeger 資源相關的事件
監看命名空間本身，尋找 sidecar.jaegertracing.io/inject 註解
監看所有部署，根據 sidecar.jaegertracing.io/inject 註解注入或移除 sidecar
在必要時建立叢集角色繫結

當不使用叢集範圍的資源 (ClusterRole 和 ClusterRoleBinding) 時，請將 WATCH_NAMESPACE 設定為 Jaeger 運算子應監看與 Jaeger 資源相關事件的命名空間逗號分隔清單。Jaeger 運算子可以在指定的命名空間（例如，observability）中執行，並管理另一個命名空間（例如，myproject）中的 Jaeger 資源。為此，請為運算子應監看資源的每個命名空間使用類似以下的 RoleBinding

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: jaeger-operator-in-myproject
  namespace: myproject
subjects:
- kind: ServiceAccount
  name: jaeger-operator
  namespace: observability
roleRef:
  kind: Role
  name: jaeger-operator
  apiGroup: rbac.authorization.k8s.io

在 Kubernetes 上安裝運算子

下列指示將建立 observability 命名空間，並在此處安裝 Jaeger 運算子。依預設，運算子將監看所有命名空間。

請確保您的 kubectl 命令已正確設定為連線到有效的 Kubernetes 叢集。如果沒有叢集，可以使用 minikube 在本機建立一個叢集。

若要安裝運算子，請執行

kubectl create namespace observability # <1>
kubectl create -f https://github.com/jaegertracing/jaeger-operator/releases/download/v1.62.0.0/jaeger-operator.yaml -n observability # <2>

<1> 這會建立部署檔案中預設使用的命名空間。如果您想要將 Jaeger 運算子安裝在不同的命名空間中，您必須編輯部署檔案，將 observability 變更為所需的命名空間值。

<2> 這會為 apiVersion: jaegertracing.io/v1 安裝「自訂資源定義 (Custom Resource Definition)」。

如果想要只監看特定的命名空間，運算子將會以叢集範圍模式安裝，您需要將運算子資訊清單的 ClusterRole 和 ClusterRoleBinding 變更為 Role 和 RoleBinding，並且在 jaeger 運算子的 Deployment 中設定 WATCH_NAMESPACE 環境變數。

此時，應該會有可用的 jaeger-operator 部署。您可以使用下列指令檢視它

$ kubectl get deployment jaeger-operator -n observability

NAME              DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
jaeger-operator   1         1         1            1           48s

運算子現在已準備好建立 Jaeger 執行個體。

在 OKD/OpenShift 上安裝運算子

前一節的指示也適用於在 OKD 或 OpenShift 上安裝運算子。當您安裝基於角色的存取控制 (RBAC) 規則、自訂資源定義和運算子時，請確保您以具備權限的使用者身分登入。

oc login -u <privileged user>

oc new-project observability # <1>
oc create -f https://github.com/jaegertracing/jaeger-operator/releases/download/v1.62.0.0/jaeger-operator.yaml -n observability # <2>

<2> 這會為 apiVersion: jaegertracing.io/v1 安裝「自訂資源定義 (Custom Resource Definition)」。

安裝運算子後，將 jaeger-operator 角色授與應該能夠安裝個別 Jaeger 執行個體的使用者。下列範例建立一個角色繫結，允許使用者 developer 建立 Jaeger 執行個體

oc create \
  rolebinding developer-jaeger-operator \
  --role=jaeger-operator \
  --user=developer

授與角色後，切換回不具備權限的使用者。

快速入門 - 部署 AllInOne 映像檔

建立 Jaeger 執行個體最簡單的方法是建立類似下列範例的 YAML 檔案。這會安裝預設的 AllInOne 策略，此策略會將 all-in-one 映像檔（結合 jaeger-agent、jaeger-collector、jaeger-query 和 Jaeger UI）部署在單一 pod 中，預設使用記憶體內儲存體。

此預設策略適用於開發、測試和示範目的，而不適用於生產環境。

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: simplest

然後，YAML 檔案可以搭配 kubectl 使用

kubectl apply -f simplest.yaml

幾秒鐘後，新的記憶體內 all-in-one Jaeger 執行個體將會可用，適用於快速示範和開發目的。若要檢查已建立的執行個體，請列出 jaeger 物件

$ kubectl get jaegers
NAME        CREATED AT
simplest    28s

若要取得 pod 名稱，請查詢屬於 simplest Jaeger 執行個體的 pod

$ kubectl get pods -l app.kubernetes.io/instance=simplest
NAME                        READY     STATUS    RESTARTS   AGE
simplest-6499bb6cdd-kqx75   1/1       Running   0          2m

同樣地，可以從直接使用從先前範例取得的 pod 名稱的 pod 查詢記錄，或從屬於我們執行個體的所有 pod 查詢記錄

$ kubectl logs -l app.kubernetes.io/instance=simplest
...
{"level":"info","ts":1535385688.0951214,"caller":"healthcheck/handler.go:133","msg":"Health Check state change","status":"ready"}

在 OKD/OpenShift 上，必須指定容器名稱。

$ kubectl logs -l app.kubernetes.io/instance=simplest -c jaeger
...
{"level":"info","ts":1535385688.0951214,"caller":"healthcheck/handler.go:133","msg":"Health Check state change","status":"ready"}

設定運算子

Jaeger 運算子可以透過命令列介面參數、環境變數或設定檔進行設定。當相同的變數在不同層級指定時，優先順序為

命令列參數 (旗標)
環境變數
設定檔

每個項目都優先於其下方的項目。可用的選項可以透過使用 --help 旗標執行運算子來檢視，例如

$ podman run jaegertracing/jaeger-operator:master start --help

範例

透過指定 Jaeger 運算子部署的旗標來設定 log-level 參數 (摘錄)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: jaeger-operator
spec:
  template:
    spec:
      containers:
      - name: jaeger-operator
        image: jaegertracing/jaeger-operator:master
        args: ["start", "--log-level=debug"]

透過指定 Jaeger 運算子部署的環境變數來設定 log-level 參數 (摘錄)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: jaeger-operator
spec:
  template:
    spec:
      containers:
      - name: jaeger-operator
        image: jaegertracing/jaeger-operator:master
        args: ["start"]
        env:
        - name: LOG-LEVEL
          value: debug

在設定檔中設定 log-level 參數

log-level: debug

若要使用設定檔，請在 ${HOME}/.jaeger-operator.yaml 建立檔案，或透過 --config 指定位置。

部署策略

當您建立 Jaeger 執行個體時，它會與策略相關聯。策略定義在自訂資源檔案中，並決定要用於 Jaeger 後端的架構。預設策略為 allInOne。其他可能的值為 production 和 streaming。

可用的策略將在以下各節中說明。

AllInOne (預設) 策略

此策略適用於開發、測試和示範目的。

主要的後端元件 jaeger-agent、jaeger-collector 和 jaeger-query 服務都會封裝到單一可執行檔中，此檔案會設定為 (預設) 使用記憶體內儲存體。此策略無法擴展超過一個複本。

生產策略

production 策略顧名思義，適用於生產環境，在生產環境中，追蹤資料的長期儲存很重要，而且需要更具可擴展性和高可用性的架構。因此，每個後端元件都會個別部署。

jaeger-agent 可以作為 sidecar 注入到已檢測的應用程式上，或作為 daemonset 注入。

可以將 jaeger-collector 設定為依需求自動調整。預設情況下，當沒有提供 .Spec.Collector.Replicas 的值時，Jaeger 運算子會為 jaeger-collector 建立水平 Pod 自動調整程式 (HPA) 設定。我們建議為 .Spec.Collector.MaxReplicas 設定明確的值，同時為預期 jaeger-collector 的 pod 將使用的資源設定合理的值。當沒有設定 .Spec.Collector.MaxReplicas 時，運算子會將 100 設定為其值。請在 Kubernetes 網站閱讀關於 HPA 的詳細資訊。可以透過將 .Spec.Collector.Autoscale 設定為 false 來明確停用此功能。以下是一個範例，設定 jaeger-collector 的限制以及最大複本數

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: simple-prod
spec:
  strategy: production
  collector:
    maxReplicas: 5
    resources:
      limits:
        cpu: 100m
        memory: 128Mi

jaeger-query 和 jaeger-collector 服務會設定為支援的儲存體類型 - 目前為 Cassandra 或 Elasticsearch。這些元件的每個元件都可以根據效能和復原需求佈建多個執行個體。

主要額外需求是提供儲存體類型和選項的詳細資訊，例如

    storage:
      type: elasticsearch
      options:
        es:
          server-urls: http://elasticsearch:9200

串流策略

streaming 策略旨在透過提供一個有效地介於收集器和後端儲存體 (Cassandra 或 Elasticsearch) 之間的串流功能來擴充 production 策略。這提供在負載高的情況下減少後端儲存體壓力，並讓其他追蹤後處理功能能夠直接從串流平台 (Kafka) 利用即時 span 資料的優點。

可以將 jaeger-collector 設定為依需求自動調整，如「生產策略」章節所述。

也可以將 jaeger-ingester 設定為依需求自動調整。預設情況下，當沒有提供 .Spec.Ingester.Replicas 的值時，Jaeger 運算子會為 jaeger-ingester 建立水平 Pod 自動調整程式 (HPA) 設定。我們建議為 .Spec.Ingester.MaxReplicas 設定明確的值，同時為預期 jaeger-ingester 的 pod 將使用的資源設定合理的值。當沒有設定 .Spec.Ingester.MaxReplicas 時，運算子會將 100 設定為其值。請在 Kubernetes 網站閱讀關於 HPA 的詳細資訊。可以透過將 .Spec.Ingester.Autoscale 設定為 false 來明確停用此功能。以下是一個範例，設定 jaeger-ingester 的限制以及最大複本數

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: simple-streaming
spec:
  strategy: streaming
  ingester:
    maxReplicas: 8
    resources:
      limits:
        cpu: 100m
        memory: 128Mi

可以使用 Strimzi 的 Kafka 運算子來設定 Kafka 環境。

現有的 Kafka 叢集

唯一需要的其他資訊是提供存取 Kafka 平台的詳細資訊，該平台會在 collector 元件 (作為產生者) 和 ingester 元件 (作為取用者) 中設定

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: simple-streaming
spec:
  strategy: streaming
  collector:
    options:
      kafka: # <1>
        producer:
          topic: jaeger-spans
          brokers: my-cluster-kafka-brokers.kafka:9092
  ingester:
    options:
      kafka: # <1>
        consumer:
          topic: jaeger-spans
          brokers: my-cluster-kafka-brokers.kafka:9092
      ingester:
        deadlockInterval: 5s # <2>
  storage:
    type: elasticsearch
    options:
      es:
        server-urls: http://elasticsearch:9200

<1> 識別 jaeger-collector 用於產生訊息，以及 jaeger-ingester 用於取用訊息的 Kafka 設定。

<2> 死結間隔預設為停用 (設定為 0)，以防止 jaeger-ingester 在沒有收到訊息時終止。可以設定此選項以指定在終止前等待訊息的分鐘數。

自行佈建的 Kafka 叢集

若要使用自行佈建的方法，不應定義產生者/取用者代理程式屬性。

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: auto-provision-kafka
spec:
  strategy: streaming
  storage:
    type: elasticsearch
    options:
      es:
        # Note: This assumes elasticsearch is running in the "default" namespace.
        server-urls: http://elasticsearch.default.svc:9200

可以透過將旗標 --kafka-provision 設定為 false 來停用 Kafka 叢集的自行佈建。預設值為 auto，這會讓 Jaeger 運算子查詢 Kubernetes 叢集，以了解其處理 Kafka 自訂資源的能力。這通常由 Kafka 運算子在其安裝過程中設定，因此，如果預期 Kafka 運算子在 Jaeger 運算子之後執行，則可以將旗標設定為 true。

了解自訂資源定義

在 Kubernetes API 中，資源是一個端點，用於儲存特定種類的 API 物件集合。例如，內建的 Pods 資源包含 Pod 物件的集合。自訂資源定義 (CRD) 物件在叢集中定義新的唯一物件 Kind，並讓 Kubernetes API 伺服器處理其整個生命週期。

若要建立自訂資源 (CR) 物件，叢集管理員必須先建立自訂資源定義 (CRD)。CRD 允許叢集使用者建立 CR，以將新的資源類型新增到其專案中。運算子會監看要建立的自訂資源物件，當它看到正在建立自訂資源時，會根據自訂資源物件中定義的參數建立應用程式。

雖然只有叢集管理員可以建立 CRD，但如果開發人員具有 CRD 的讀取和寫入權限，就可以從現有的 CRD 建立 CR。

作為參考，以下說明如何建立更複雜的 all-in-one 執行個體

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: my-jaeger
spec:
  strategy: allInOne # <1>
  allInOne:
    image: jaegertracing/all-in-one:latest # <2>
    options: # <3>
      log-level: debug # <4>
  storage:
    type: memory # <5>
    options: # <6>
      memory: # <7>
        max-traces: 100000
  ingress:
    enabled: false # <8>
  agent:
    strategy: DaemonSet # <9>
  annotations:
    scheduler.alpha.kubernetes.io/critical-pod: "" # <10>

<1> 預設策略為 allInOne。其他可能的值為 production 和 streaming。

<2> 要使用的映像檔，以規則的 Docker 語法。

<3> 要逐字傳遞給底層二進制檔的（非儲存相關）選項。請參閱 Jaeger 文件和/或相關二進制檔的 --help 選項，以取得所有可用選項。

<4> 此選項是一個簡單的 key: value 對應。在此案例中，我們希望將選項 --log-level=debug 傳遞給二進制檔。

<5> 要使用的儲存類型。預設為 memory，但可以是任何其他支援的儲存類型（Cassandra、Elasticsearch、Kafka）。

<6> 所有與儲存相關的選項都應放置在此處，而不是放在「allInOne」或其他組件選項下。

<7> 某些選項具有命名空間，我們也可以將它們分解為巢狀物件。我們可以指定 memory.max-traces: 100000。

<8> 預設情況下，會為 jaeger-query 服務建立一個 Ingress 物件。可以將其 enabled 選項設定為 false 來停用。如果部署在 OpenShift 上，則會以 Route 物件表示。

<9> 預設情況下，運算子會假設 jaeger-agent 作為目標 Pod 內的 sidecar 部署。將策略指定為「DaemonSet」會變更此設定，並讓運算子將 jaeger-agent 部署為 DaemonSet。請注意，您的追蹤器用戶端可能必須覆寫「JAEGER_AGENT_HOST」環境變數，才能使用節點的 IP。

<10> 定義要套用至所有部署（而非服務）的註釋。這些註釋可被個別組件上定義的註釋覆寫。

您可以在 GitHub 上檢視不同 Jaeger 配置的自訂資源範例：在 GitHub 上。

設定自訂資源

您可以使用最簡單的範例（如上所示）並使用預設值建立 Jaeger 實例，或者您可以建立自己的自訂資源檔。

Span 儲存選項

Cassandra 儲存

當儲存類型設定為 Cassandra 時，運算子會自動建立一個批次作業，該作業會建立 Jaeger 執行所需的架構。此批次作業會封鎖 Jaeger 安裝，使其僅在架構成功建立後才開始。可以將 enabled 屬性設定為 false 來停用此批次作業的建立

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: cassandra-without-create-schema
spec:
  strategy: allInOne
  storage:
    type: cassandra
    cassandraCreateSchema:
      enabled: false # <1>

<1> 預設為 true

批次作業的進一步方面也可以設定。以下顯示一個包含所有可能選項的範例

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: cassandra-with-create-schema
spec:
  strategy: allInOne # <1>
  storage:
    type: cassandra
    options: # <2>
      cassandra:
        servers: cassandra
        keyspace: jaeger_v1_datacenter3
    cassandraCreateSchema: # <3>
      datacenter: "datacenter3"
      mode: "test"

<1> production 和 streaming 也適用。

<2> 這些選項適用於常規 Jaeger 組件，例如 collector 和 query。

<3> create-schema 作業的選項。

預設的 create-schema 作業使用 MODE=prod，這表示複製因子為 2，使用 NetworkTopologyStrategy 作為類別，實際上表示 Cassandra 叢集中至少需要 3 個節點。如果需要 SimpleStrategy，請將模式設定為 test，然後將複製因子設定為 1。請參閱 create-schema 指令碼以取得更多詳細資訊。

Elasticsearch 儲存

預設情況下，Elasticsearch 儲存不需要執行任何初始化作業。但是，Elasticsearch 儲存需要執行一個 cron 作業，以從儲存中清除舊資料。

當啟用輪換（es.use-aliases）時，Jaeger 運算子也會部署一個作業來初始化 Elasticsearch 儲存，以及另外兩個 cron 作業來執行所需的索引管理動作。

外部 Elasticsearch

Jaeger 可以與外部 Elasticsearch 叢集搭配使用。以下範例顯示使用外部 Elasticsearch 叢集（由 Elasticsearch Operator 建立）的 Jaeger CR，其中 TLS CA 憑證從磁碟區掛載，而使用者/密碼儲存在密碼中。

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: simple-prod
spec:
  strategy: production
  storage:
    type: elasticsearch # <1>
    options:
      es:
        server-urls: https://quickstart-es-http.default.svc:9200 # <2>
        index-prefix: my-prefix
        tls: # <3>
          ca: /es/certificates/ca.crt
    secretName: jaeger-secret # <4>
  volumeMounts: # <5>
    - name: certificates
      mountPath: /es/certificates/
      readOnly: true
  volumes:
    - name: certificates
      secret:
        secretName: quickstart-es-http-certs-public

<1> 儲存類型 Elasticsearch。

<2> 指向在預設命名空間中執行的 Elasticsearch 服務的 URL。

<3> TLS 設定。在此案例中僅有 CA 憑證，但當使用相互 TLS 時，它也可以包含 es.tls.key 和 es.tls.cert。

<4> 定義環境變數 ES_PASSWORD 和 ES_USERNAME 的密碼。由 kubectl create secret generic jaeger-secret --from-literal=ES_PASSWORD=changeme --from-literal=ES_USERNAME=elastic 建立

<5> 磁碟區掛載和掛載到所有儲存組件中的磁碟區。

自行佈建

在某些情況下，Jaeger Operator 可以使用 Elasticsearch Operator 來佈建合適的 Elasticsearch 叢集。Jaeger CR 公開與 OpenShift 叢集記錄相同的設定。

此功能僅在 OKD/OpenShift 叢集上支援。此功能不支援 Spark 依賴項問題 #294 。

當 Jaeger production 實例中沒有 es.server-urls 選項，且 elasticsearch 設定為儲存類型時，Jaeger Operator 會透過 Elasticsearch Operator 建立一個 Elasticsearch 叢集，方法是根據儲存區段中提供的設定建立自訂資源。Elasticsearch 叢集旨在專用於單個 Jaeger 實例。

以下是一個範例，其中 Jaeger 具有使用 AWS gp2 持久儲存的單節點 Elasticsearch 叢集

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: simple-prod
spec:
  strategy: production
  storage:
    type: elasticsearch
    elasticsearch:
      nodeCount: 1 # <1>
      storage: # <2>
        storageClassName: gp2
        size: 5Gi
      resources: # <3>
        requests:
          cpu: 200m
          memory: 4Gi
        limits:
          memory: 4Gi
      redundancyPolicy: ZeroRedundancy # <4>

<1> Elasticsearch 節點的數量。為了實現高可用性，請至少使用 3 個節點。不要使用 2 個節點，因為可能會發生「腦裂」問題。

<2> 持久儲存設定。在此案例中為 AWS gp2，大小為 5Gi。如果省略，則會使用 emptyDir。Elasticsearch 運算子會佈建 PersistentVolumeClaim 和 PersistentVolume，它們不會與 Jaeger 實例一起移除。如果建立具有相同名稱和命名空間的 Jaeger，則可以掛載相同的磁碟區。由於 OpenShift SCC 原則，某些儲存在 default 命名空間中可能會失敗。

<3> Elasticsearch 節點的資源。在此案例中為 4Gi，預設需要 2Gi 的堆積空間。請參閱 Elasticsearch 文件，以取得記憶體建議。

<4> 資料複製原則定義 Elasticsearch 分片如何在叢集中的資料節點之間複製。如果未指定，Jaeger Operator 會根據節點數量自動確定最合適的複製。

FullRedundancy Elasticsearch 會將每個索引的主要分片完整複製到每個資料節點。這提供了最高的安全性，但代價是需要最高的磁碟空間量和最差的效能。
MultipleRedundancy Elasticsearch 會將每個索引的主要分片完整複製到一半的資料節點。這在安全性和效能之間提供了良好的權衡。
SingleRedundancy Elasticsearch 會建立每個索引的主要分片的一個複本。只要至少存在兩個資料節點，資料就始終可用且可恢復。當使用 5 個或更多節點時，效能優於 MultipleRedundancy。您無法在單個 Elasticsearch 節點的部署上套用此原則。
ZeroRedundancy Elasticsearch 不會建立主要分片的複本。如果節點關閉或失敗，資料可能無法使用或遺失。當您更關心效能而不是安全性，或已實施自己的磁碟/PVC 備份/還原策略時，請使用此模式。

可以將旗標 --es-provision 設定為 false 來停用 Elasticsearch 叢集的自我佈建。預設值為 auto，這將使 Jaeger Operator 查詢 Kubernetes 叢集，以了解其處理 Elasticsearch 自訂資源的能力。這通常由 Elasticsearch Operator 在其安裝過程中設定，因此，如果預期 Elasticsearch Operator 在 Jaeger Operator 之後執行，則可以將旗標設定為 true。

目前，每個命名空間只能有一個具有自我佈建的 Elasticsearch 實例的 Jaeger。

Elasticsearch 索引清理程式作業

當使用 elasticsearch 儲存時，預設會建立一個 cron 作業來從中清理舊的追蹤，下面列出了它的選項，以便您可以根據您的使用案例設定它。連線設定衍生自儲存選項。

storage:
  type: elasticsearch
  esIndexCleaner:
    enabled: true                                 // turn the cron job deployment on and off
    numberOfDays: 7                               // number of days to wait before deleting a record
    schedule: "55 23 * * *"                       // cron expression for it to run

與儲存的連線設定衍生自儲存選項。

Elasticsearch 輪換

這個索引管理策略比使用預設的每日索引更複雜，它需要一個初始化作業來準備儲存空間，以及兩個 cron 作業來管理索引。第一個 cron 作業用於滾動到新的索引，第二個用於從讀取別名中移除索引。當啟用儲存選項 es.use-aliases 時，會使用滾動功能。

若要深入了解 Jaeger 中的滾動索引管理，請參考這篇文章：文章。

storage:
  type: elasticsearch
  options:
    es:
      use-aliases: true
  esRollover:
    conditions: "{\"max_age\": \"2d\"}"          // conditions when to rollover to a new index
    readTTL: 168h                                // how long should be old data available for reading (7 days)
    schedule: "55 23 * * *"                      // cron expression for it to run

與儲存的連線設定衍生自儲存選項。

Elasticsearch 索引生命週期管理

索引生命週期管理 (ILM) 是 Elasticsearch X-Pack 外掛程式的功能，用於管理索引的生命週期。在 Operator 的上下文中，這表示可以使用 ILM 來取代滾動 cron 作業。Jaeger 專案未提供與 ILM 的直接整合，但可以將 Jaeger 實例設定為使用索引別名（ILM 需要），並停用索引範本建立和滾動 cron 作業。這允許使用者在部署 Jaeger 之前，在自訂索引範本中設定 ILM。

spec:
  strategy: production
  collector:
    options:
      es:
        use-aliases: true # <1>
  query:
    options:
      es:
        use-aliases: true  # <1>
  storage:
    type: elasticsearch
    options:
      es:
        create-index-templates: false  # <2>
        server-urls: http://elasticsearch:9200

<1> 設定 jaeger-query 和 jaeger-collector 以使用讀取和寫入索引別名。

<2> 停用預設索引範本的建立。

儲存外掛程式

從 v1.58 開始，將不再支援 Sidecar 外掛程式。自訂儲存後端應遷移至遠端儲存 API。

指標儲存選項

Prometheus

將 spec.metricsStorage.type 設定為 prometheus，即可讓 Jaeger 使用與 PromQL 相容的儲存實作，以取得 jaeger-query R.E.D 指標，用於服務效能監控功能。

以下是一個 Jaeger CR 的範例，使用 allInOne 部署策略、記憶體內的 Span 儲存和 Prometheus 指標儲存。

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: jaeger-spm
spec:
  strategy: allInOne
  allInOne:
    image: jaegertracing/all-in-one:latest
    options:
      log-level: debug
      query:
        base-path: /jaeger
      prometheus: # <1>
        server-url: "http://prometheus:9090" # <2>
    metricsStorage: # <3>
      type: prometheus # <4>
  storage:
    options:
      memory:
        max-traces: 100000

<1> prometheus 命名空間設定的開始，定義為簡單的 key: value 對應。所有可用的選項都記錄在Jaeger All-In-One with Prometheus CLI 區段中

<2> 使用 http://prometheus:9090 覆寫預設的 https://127.0.0.1:9090 Prometheus 伺服器 URL。

<3> 啟用指標查詢功能的部分。

<4> 選取 prometheus 作為指標儲存後端。

推導依賴關係

推導依賴關係的處理會從儲存空間收集 Span，分析服務之間的連結，並儲存它們以供稍後在 UI 中顯示。此作業只能與 production 策略和 cassandra 或 elasticsearch 儲存類型一起使用。

storage:
  type: elasticsearch
  dependencies:
    enabled: true                                 # turn the job deployment on and off
    schedule: "55 23 * * *"                       # cron expression for it to run
    sparkMaster:                                  # spark master connection string, when empty spark runs in embedded local mode
    resources:
      requests:
        memory: 4096Mi
      limits:
        memory: 4096Mi

與儲存的連線設定衍生自儲存選項。

請務必分配足夠的記憶體資源。Spark 文件建議至少 8Gi 的記憶體。但是，此作業至少可以使用 2Gi 的記憶體啟動。正確的記憶體設定將取決於正在處理的資料量。請注意，此作業會將當天的所有資料載入到記憶體中。

自動注入 Jaeger Agent Sidecar

目前，僅支援自動注入 jaeger-agent sidecar 至 Deployments。

對於其他控制器類型，請參閱下方的手動定義 Jaeger Agent Sidecar。

對自動注入其他控制器類型的支援正在透過Issue #750 追蹤中。

如果部署或其命名空間具有註解 sidecar.jaegertracing.io/inject，且具有適當的值，則 Operator 可以在 Deployment 工作負載中注入 jaeger-agent sidecar。值可以是 "true" （字串形式），或 Jaeger 實例名稱，如 kubectl get jaegers 所傳回。當使用 "true" 時，部署的命名空間中應該只有一個 Jaeger 實例，否則，Operator 無法自動判斷要使用哪個 Jaeger 實例。部署上的特定 Jaeger 實例名稱的優先順序高於在其命名空間上套用的 true。

以下程式碼片段顯示一個簡單的應用程式，它將注入一個 sidecar，其中 jaeger-agent 指向同一命名空間中可用的單一 Jaeger 實例。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  annotations:
    "sidecar.jaegertracing.io/inject": "true" # <1>
spec:
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: acme/myapp:myversion

<1> 可以是 "true" （字串形式）或 Jaeger 實例名稱。

完整的部署範例可在deploy/examples/business-application-injected-sidecar.yaml 取得。

當注入 sidecar 時，可以從 localhost 上的預設位置存取 jaeger-agent。

注入 Sidecar 的部署層級組態

由於 sidecar 可能會注入到非 jaeger-operator 管理的部署中，因此許多在部署層級應用的組態不會應用於 sidecar 的部署，除非它們在 jaeger-agent 節點下指定。sidecar 的部署支援以下組態

磁碟區（和 VolumeMounts）
ImagePullSecrets

例如，以下 Jaeger 組態會將 agent-volume 和 agent-imagePullSecrets 新增至 sidecar 的部署。

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: my-jaeger
spec:
  agent:
    volumeMounts:
    - name: agent-volume
      mountPath: /tmp/agent
      readOnly: true
    volumes:
      - name: agent-volume
        secret:
          secretName: agent-secret
    imagePullSecrets:
    - name: agent-imagePullSecret

手動定義 Jaeger Agent Sidecar

對於 Deployments 以外的控制器類型（例如 StatefulSets、DaemonSets 等），可以在規格中手動定義 jaeger-agent sidecar。

以下程式碼片段顯示您可以包含在 containers 區段中，用於 jaeger-agent sidecar 的手動定義

- name: jaeger-agent
  image: jaegertracing/jaeger-agent:latest
  imagePullPolicy: IfNotPresent
  ports:
    - containerPort: 5775
      name: zk-compact-thrift
      protocol: UDP
    - containerPort: 5778
      name: config-rest
      protocol: TCP
    - containerPort: 6831
      name: jg-compact-thrift
      protocol: UDP
    - containerPort: 6832
      name: jg-binary-thrift
      protocol: UDP
    - containerPort: 14271
      name: admin-http
      protocol: TCP
  args:
    - --reporter.grpc.host-port=dns:///jaeger-collector-headless.observability:14250
    - --reporter.type=grpc

完整的 StatefulSet 範例可在deploy/examples/statefulset-manual-sidecar.yaml 取得。

可以從 localhost 上的預設位置存取 jaeger-agent。

將 Agent 安裝為 DaemonSet

預設情況下，Operator 預期將 jaeger-agent 作為 sidecar 部署到目標應用程式。這對於多租戶情境或擁有更好的負載平衡等多種用途來說很方便，但在某些情況下，您可能會想要將 jaeger-agent 安裝為 DaemonSet。在這種情況下，請將 jaeger-agent 的策略指定為 DaemonSet，如下所示

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: my-jaeger
spec:
  agent:
    strategy: DaemonSet

如果您嘗試在同一個叢集上安裝兩個以 DaemonSet 作為策略的 Jaeger 實例，則只會部署一個 DaemonSet，因為 Agent 需要繫結到節點上眾所周知的連接埠。因此，第二個 Daemon 集將無法繫結到這些連接埠。

您的追蹤器用戶端很可能需要知道 jaeger-agent 所在的位置。這通常是透過將環境變數 JAEGER_AGENT_HOST 設定為 Kubernetes 節點的 IP 值來完成，例如

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: acme/myapp:myversion
        env:
        - name: JAEGER_AGENT_HOST
          valueFrom:
            fieldRef:
              fieldPath: status.hostIP

OpenShift

在 OpenShift 中，只有在設定特殊的安全性內容時，才能設定 HostPort。jaeger-agent 可以使用一個具有繫結到 HostPort 權限的獨立服務帳戶，如下所示

oc create -f https://raw.githubusercontent.com/jaegertracing/jaeger-operator/main/examples/openshift/hostport-scc-daemonset.yaml # <1>
oc new-project myproject
oc create -f https://raw.githubusercontent.com/jaegertracing/jaeger-operator/main/examples/openshift/service_account_jaeger-agent-daemonset.yaml # <2>
oc adm policy add-scc-to-user daemonset-with-hostport -z jaeger-agent-daemonset # <3>
oc apply -f https://raw.githubusercontent.com/jaegertracing/jaeger-operator/main/examples/openshift/agent-as-daemonset.yaml # <4>

<1> 具有 allowHostPorts 原則的 SecurityContextConstraints

<2> 要由 jaeger-agent 使用的 ServiceAccount

<3> 將安全性原則新增至服務帳戶

<4> 使用上述步驟中建立的 serviceAccount 建立 Jaeger 實例

若沒有此類政策，則會發生以下錯誤，導致無法建立 DaemonSet：

Warning FailedCreate 4s (x14 over 45s) daemonset-controller Error creating: pods "agent-as-daemonset-agent-daemonset-" is forbidden: unable to validate against any security context constraint: [spec.containers[0].securityContext.containers[0].hostPort: Invalid value: 5775: Host ports are not allowed to be used

幾秒後，DaemonSet 應該就會啟動並執行。

$ oc get daemonset agent-as-daemonset-agent-daemonset
NAME                                 DESIRED   CURRENT   READY     UP-TO-DATE   AVAILABLE
agent-as-daemonset-agent-daemonset   1         1         1         1            1

Calico CNI

在 AWS EKS (或 Fargate) 中執行自訂 Calico CNI 時，指向服務的 Webhook 可能無法連線。

當請求 jaeger 資源時，會顯示以下錯誤。

Error from server (InternalError): Internal error occurred: failed calling webhook "myservice.mynamespace.svc": Post "https://myservice.mynamespace.svc:443/mutate?timeout=30s": Address is not allowed

為了解決這個問題

請在 jaeger-operator 部署上設定 hostNetwork:true
將 /healtz 和 /readyz 的連接埠從 8081 變更為其他值
將 kube-rbac-proxy 的安全連接埠從 8443 變更為其他值
將 webhook-server 的連接埠從 9443 變更為其他值
- 此設定由 webhook-bind-port 旗標控制

Jaeger Operator 設定範例

---
apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/name: jaeger-operator
    name: jaeger-operator
  name: jaeger-operator-webhook-service
  namespace: monitoring
spec:
  ports:
  - port: 443
    protocol: TCP
    targetPort: 10290
  selector:
    app.kubernetes.io/name: jaeger-operator
    name: jaeger-operator
---
...
    spec:
      hostNetwork: true
      containers:
      - args:
        - start
        - --health-probe-bind-address=:10280
        - --webhook-bind-port=10290
        - --leader-elect
        command:
        - /jaeger-operator
      ...
      ports:
        - containerPort: 10290
          name: webhook-server
          protocol: TCP
      ...
      readinessProbe:
          httpGet:
            path: /readyz
            port: 10280
      ...
      livenessProbe:
          httpGet:
            path: /healthz
            port: 10280

Kube-rbac-proxy 設定範例

---
apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/component: metrics
    app.kubernetes.io/name: jaeger-operator
    name: jaeger-operator
  name: jaeger-operator-metrics
  namespace: monitoring
spec:
  ports:
  - name: https
    port: 10270
    protocol: TCP
    targetPort: https
  selector:
    app.kubernetes.io/name: jaeger-operator
    name: jaeger-operator
---
...
    spec:
      hostNetwork: true
      containers:
      - args:
        - --secure-listen-address=0.0.0.0:10270
        - --upstream=http://127.0.0.1:8383/
        - --logtostderr=true
        - --v=0
      ...
      ports:
        - containerPort: 10270
          name: https
          protocol: TCP

上述連接埠值必須是全域唯一的，因此 jaeger-operator 的連接埠可以在每個 k8s 節點上公開。

Secrets 支援

Operator 支援將 secrets 傳遞給 jaeger-collector、jaeger-query 和 all-in-one 部署。例如，這可用於傳遞憑證 (使用者名稱/密碼) 來存取底層儲存後端 (例如：Elasticsearch)。這些 secrets 在 (Collector/Query/All-In-One) 節點中會以環境變數的形式提供。

    storage:
      type: elasticsearch
      options:
        es:
          server-urls: http://elasticsearch:9200
      secretName: jaeger-secrets

secret 本身將在 jaeger-operator 自訂資源之外進行管理。

設定 UI

有關 UI 的各種設定選項的資訊，請參閱這裡，以 JSON 格式定義。

若要在自訂資源中套用 UI 設定變更，可以將相同的資訊以 YAML 格式包含在下方，如下所示

    ui:
      options:
        dependencies:
          menuEnabled: false
        tracking:
          gaID: UA-000000-2
        menu:
        - label: "About Jaeger"
          items:
            - label: "Documentation"
              url: "https://jaeger.dev.org.tw/docs/latest"
        linkPatterns:
        - type: "logs"
          key: "customer_id"
          url: /search?limit=20&lookback=1h&service=frontend&tags=%7B%22customer_id%22%3A%22#{customer_id}%22%7D
          text: "Search for other traces for customer_id=#{customer_id}"

定義取樣策略

如果追蹤是由 Istio Proxy 開始的，則這並不相關，因為取樣決策是在那裡做出的。而 Jaeger 取樣決策僅在您使用 Jaeger Tracer (用戶端) 時才相關。

可以使用 Operator 來定義取樣策略，這些策略將提供給已設定為使用遠端取樣器的追蹤器。

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: with-sampling
spec:
  strategy: allInOne
  sampling:
    options:
      default_strategy:
        type: probabilistic
        param: 0.5

此範例定義了一個預設的取樣策略，它是機率性的，追蹤實例有 50% 的機率被取樣。

請參閱有關收集器取樣設定的 Jaeger 文件，了解如何設定服務和端點取樣。該文件中描述的 JSON 表示形式可以透過轉換為 YAML 來在 Operator 中使用。

更精細的設定

可以使用自訂資源來定義應用於所有 Jaeger 組件或個別組件層級的更精細 Kubernetes 設定。

當需要一個通用定義（適用於所有 Jaeger 組件）時，它會在 spec 節點下定義。當定義與個別組件相關時，它會放置在 spec/<component> 節點下。

支援的設定類型包括

親和性以決定 Pod 可以分配到哪些節點
註釋
標籤
資源以限制 CPU 和記憶體
容忍度結合 taints 以允許 Pod 避免被節點排斥
磁碟區和磁碟區掛載
serviceAccount 以使用個別身分執行每個組件
securityContext 以定義執行組件的權限

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: simple-prod
spec:
  strategy: production
  storage:
    type: elasticsearch
    options:
      es:
        server-urls: http://elasticsearch:9200
  annotations:
    key1: value1
  labels:
    key2: value2
  resources:
    requests:
      memory: "64Mi"
      cpu: "250m"
    limits:
      memory: "128Mi"
      cpu: "500m"
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/e2e-az-name
            operator: In
            values:
            - e2e-az1
            - e2e-az2
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: another-node-label-key
            operator: In
            values:
            - another-node-label-value
  tolerations:
    - key: "key1"
      operator: "Equal"
      value: "value1"
      effect: "NoSchedule"
    - key: "key1"
      operator: "Equal"
      value: "value1"
      effect: "NoExecute"
  serviceAccount: nameOfServiceAccount
  securityContext:
    runAsUser: 1000
  volumeMounts:
    - name: config-vol
      mountPath: /etc/config
  volumes:
    - name: config-vol
      configMap:
        name: log-config
        items:
          - key: log_level
            path: log_level

注意：如有必要，可以透過其 serviceAccounts 為組件設定 imagePullSecrets (請參閱 https://kubernetes.dev.org.tw/docs/tasks/configure-pod-container/configure-service-account/#add-image-pull-secret-to-service-account) 。對於 Sidecar，請參閱注入的 Sidecar 的部署層級設定章節。

存取 Jaeger 主控台 (UI)

Kubernetes

運算子會建立 Kubernetes ingress 路由，這是 Kubernetes 用於將服務暴露給外部世界的標準，但預設情況下它不包含 Ingress 提供者。請參閱Kubernetes 文件，瞭解為您的平台取得 Ingress 提供者的最合適方法。以下指令會在 minikube 上啟用 Ingress 提供者。

minikube addons enable ingress

一旦啟用 Ingress，就可以透過查詢 Ingress 物件找到 Jaeger 主控台的位址

$ kubectl get ingress
NAME             HOSTS     ADDRESS          PORTS     AGE
simplest-query   *         192.168.122.34   80        3m

在此範例中，Jaeger UI 可在 http://192.168.122.34 取得。

若要在 Ingress 中啟用 TLS，請傳遞一個帶有 TLS 憑證的 Secret 名稱的 secretName

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: ingress-with-tls
spec:
  ingress:
    secretName: my-tls-secret

OpenShift

當運算子在 OpenShift 上執行時，運算子會自動為查詢服務建立一個 Route 物件。使用以下指令檢查主機名稱/埠號

oc get routes

請務必搭配從上述指令取得的主機名稱/埠號使用 https，否則您會看到類似「應用程式無法使用」的訊息。

預設情況下，Jaeger UI 受 OpenShift 的 OAuth 服務保護，任何有效的使用者都可以登入。若要停用此功能並使 Jaeger UI 不受保護，請在自訂資源檔案中將 Ingress 屬性 security 設定為 none

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: disable-oauth-proxy
spec:
  ingress:
    security: none

自訂的 SAR 和 Delegate URL 值可以指定為 .Spec.Ingress.OpenShift.SAR 和 .Spec.Ingress.Openshift.DelegateURLs 的一部分，如下所示

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: custom-sar-oauth-proxy
spec:
  ingress:
    openshift:
      sar: '{"namespace": "default", "resource": "pods", "verb": "get"}'
      delegateUrls: '{"/":{"namespace": "default", "resource": "pods", "verb": "get"}}'

當設定 delegateUrls 時，Jaeger 運算子需要在使用 UI Proxy ({InstanceName}-ui-proxy) 的服務帳戶和角色 system:auth-delegator 之間建立新的 ClusterRoleBinding，這也是 OpenShift OAuth Proxy 所要求的。因此，運算子本身使用的服務帳戶也需要有相同的叢集角色繫結。為了完成此操作，必須建立如下所示的 ClusterRoleBinding

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: jaeger-operator-with-auth-delegator
  namespace: observability
subjects:
- kind: ServiceAccount
  name: jaeger-operator
  namespace: observability
roleRef:
  kind: ClusterRole
  name: system:auth-delegator
  apiGroup: rbac.authorization.k8s.io

不喜歡讓使用者使用此叢集角色部署 Jaeger 執行個體的叢集管理員可以不用將此叢集角色新增到運算子的服務帳戶。在這種情況下，運算子會自動偵測到缺少必要的權限，並會記錄類似以下的訊息：the requested instance specifies the delegateUrls option for the OAuth Proxy, but this operator cannot assign the proper cluster role to it (system:auth-delegator). Create a cluster role binding between the operator's service account and the cluster role 'system:auth-delegator' in order to allow instances to use 'delegateUrls'。

Jaeger 運算子也支援透過 OpenShift OAuth Proxy 使用 htpasswd 檔案進行驗證。若要使用此功能，請在 OpenShift 特定項目中指定 htpasswdFile 選項，指向本機磁碟中的 htpasswd 檔案位置。可以使用 htpasswd 公用程式建立 htpasswd 檔案

$ htpasswd -cs /tmp/htpasswd jdoe
New password:
Re-type new password:
Adding password for user jdoe

然後，這個檔案可以用作 kubectl create secret 指令的輸入

$ kubectl create secret generic htpasswd --from-file=htpasswd=/tmp/htpasswd
secret/htpasswd created

一旦建立密鑰，就可以在 Jaeger CR 中指定為磁碟區/磁碟區掛載

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: with-htpasswd
spec:
  ingress:
    openshift:
      sar: '{"namespace": "default", "resource": "pods", "verb": "get"}'
      htpasswdFile: /usr/local/data/htpasswd
  volumeMounts:
  - name: htpasswd-volume
    mountPath: /usr/local/data
  volumes:
  - name: htpasswd-volume
    secret:
      secretName: htpasswd

升級運算子及其受管理執行個體

每個版本的 Jaeger 運算子都會遵循一個 Jaeger 版本。每當安裝新版本的 Jaeger 運算子時，運算子管理的所有 Jaeger 執行個體都會升級到運算子支援的版本。例如，使用 Jaeger 運算子 1.12.0 建立的名稱為 simplest 的執行個體將執行 Jaeger 1.12.0。一旦 Jaeger 運算子升級到 1.13.0，執行個體 simplest 將升級到 1.13.0 版本，並遵循 Jaeger 專案的官方升級說明。

Jaeger 運算子可以透過變更部署 (kubectl edit deployment jaeger-operator) 或透過專用工具 (例如 Operator Lifecycle Manager (OLM) ) 手動升級。

更新 Jaeger 執行個體 (實驗性)

可以透過變更 CustomResource 來更新 Jaeger 執行個體，方法是透過 kubectl edit jaeger simplest (其中 simplest 是 Jaeger 的執行個體名稱)，或透過 kubectl apply -f simplest.yaml 套用更新的 YAML 檔案。

Jaeger 執行個體的名稱無法更新，因為它是資源識別資訊的一部分。

可以套用較簡單的變更，例如變更複本大小，而不用太過擔心，而應密切注意策略變更，這可能會導致個別元件 (收集器/查詢/代理程式) 中斷。

雖然支援變更備份儲存體，但不支援資料移轉。

移除 Jaeger 執行個體

若要移除執行個體，請使用 delete 指令，並搭配建立執行個體時使用的自訂資源檔案

kubectl delete -f simplest.yaml

或者，您也可以透過執行以下指令移除 Jaeger 執行個體

kubectl delete jaeger simplest

刪除執行個體不會從此執行個體使用的任何永久儲存體中移除資料。但是，記憶體中執行個體的資料將會遺失。

追蹤和偵錯運算子

從 1.16.0 版開始，Jaeger 運算子能夠產生與其自身作業相關的 spans。若要利用此功能，必須設定 operator.yaml 以啟用追蹤，方法是將旗標 --tracing-enabled=true 設定為容器的 args，並將 Jaeger 代理程式新增為 Pod 的 sidecar。以下是已啟用追蹤並假設 Jaeger 執行個體與 Jaeger 運算子位於相同命名空間的 operator.yaml 摘錄

...
        # .Spec.Template.Spec.Containers[0].Args
        args: ["start", "--tracing-enabled=true"]
...
      # add as a second container to .Spec.Template.Spec.Containers
      - name: jaeger-agent
        image: jaegertracing/jaeger-agent:latest # it's best to keep this version in sync with the operator's
        env:
        - name: POD_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        args:
        - --reporter.grpc.host-port=dns:///jaeger-collector-headless.$(POD_NAMESPACE).svc.cluster.local:14250
        ports:
        - containerPort: 6831
          name: jg-compact-thrift
          protocol: UDP

請注意，您也必須手動佈建 Jaeger 執行個體。您可以在 Jaeger 運算子初始化後執行此操作。jaeger-agent 會將運算子 spans 保留在內部緩衝區中，直到連線到 Jaeger 執行個體為止。以下 Jaeger CR 可用於佈建適用於非生產用途的 Jaeger 執行個體

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: jaeger

當旗標 --log-level 設定為 debug 時，Jaeger 運算子也會提供廣泛的記錄。以下是將記錄層級設定為偵錯的 operator.yaml 摘錄

        # .Spec.Template.Spec.Containers[0].Args
        args: ["start", "--log-level=debug"]

請注意，追蹤和偵錯層級的記錄可以同時啟用。

使用 OLM 時，可以透過變更 Subscription 的 config 屬性來設定 Jaeger 運算子。若要設定 log-level 參數，訂閱會如下所示 (摘錄)

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: jaeger
  namespace: openshift-operators
spec:
  channel: stable
  config:
    env:
      - name: LOG-LEVEL
        value: debug
  installPlanApproval: Automatic
  name: jaeger
  source: community-operators
  sourceNamespace: openshift-marketplace

監控運算子

Jaeger 運算子會在 0.0.0.0:8383/metrics 上啟動一個與 Prometheus 相容的端點，其中包含可用於監控程序的內部指標。值得關注的指標包括

# Total number of reconciliations and their outcomes (cumulative)
controller_runtime_reconcile_total{controller="jaeger-controller",result="error"}
controller_runtime_reconcile_total{controller="jaeger-controller",result="success"}

# Total number of retries (cumulative)
workqueue_retries_total{name="jaeger-controller"}

# Current number of reconciliation loops in progress (gauge)
workqueue_depth{name="jaeger-controller"}

# How long (in seconds) the oldest reconciliation loop is taking. (gauge)
workqueue_unfinished_work_seconds{name="jaeger-controller"}

# How long (in seconds) it takes to process an item from the workqueue. (bucket)
workqueue_work_duration_seconds_bucket{name="jaeger-controller"}

少量的協調錯誤是正常的 (controller_runtime_reconcile_total{controller="jaeger-controller",result="error"})，因為可能有數個程序同時因為不同原因而變更資源。每當發生失敗時，運算子會嘗試再次協調，增加 workqueue_retries_total{name="jaeger-controller"} 指標。但是，如果錯誤率隨著時間的推移持續增加，或超過合理閾值，則可能需要進行調查。合理閾值可能會因叢集而異，具體取決於叢集中發生的情況，但 10% 是一個不錯的起點。

從 v1.17.0 開始，Jaeger 運算子只有在自訂資源變更或先前的協調失敗時才會觸發協調迴圈。因此，此指標 (controller_runtime_reconcile_total{controller="jaeger-controller"}) 在很長一段時間內都具有相同的值是正常的：它僅表示自訂資源未變更。如果此數字每秒都在變更，則表示叢集中有某些內容會定期變更自訂資源，或 Jaeger 運算子正在復原其他元件正在執行的變更。未來版本的 Jaeger 運算子可能會觸發定期協調迴圈。

工作佇列深度 (workqueue_depth{name="jaeger-controller"}) 表示目前作用中的協調迴圈數。對於小型叢集，或不常佈建 Jaeger 執行個體的叢集，此數字在大多數時間應該保持接近於零。對於持續一段時間而言，任何高於 0 的值都表示協調迴圈卡住了。如果發生這種情況，指標 workqueue_unfinished_work_seconds{name="jaeger-controller"} 也會持續增加。這種情況表示 Jaeger 運算子中存在錯誤。根據經驗，協調必須在幾分鐘內完成，除非涉及 Elasticsearch 或 Kafka 的佈建。耗時超過 10 分鐘的協調迴圈可以視為「卡住」。Elasticsearch 或 Kafka 的佈建可能需要數分鐘。在正常情況下，協調迴圈會在 1 分鐘內完成。

工作佇列儲存區 (workqueue_unfinished_work_seconds{name="jaeger-controller"} 和 workqueue_work_duration_seconds_bucket{name="jaeger-controller"}) 與處理每個協調迴圈所花費的時間直接相關。新的 Jaeger 執行個體的前 3 個迴圈之一所花費的時間遠比後續迴圈多的情況是正常的，特別是當叢集尚未快取基礎元件的容器映像時。使用自動佈建功能來建立 Elasticsearch 和/或 Kafka 叢集也會影響此指標。一般規則是：幾個長時間執行的協調迴圈是正常的，特別是當它們發生在指標 controller_runtime_reconcile_total{controller="jaeger-controller"} 增加的同時。

Jaeger Operator 目前尚未發布自己的指標。相反地，它會提供它所使用組件（例如 Operator SDK）所回報的指標。

解除安裝 Operator

若要解除安裝 Operator，請執行以下命令

kubectl delete -n observability -f https://github.com/jaegertracing/jaeger-operator/releases/download/v1.62.0.0/jaeger-operator.yaml