分類 | 跳轉連結 |
日誌採集 | |
應用監控 | |
阿里雲Prometheus監控 | |
開源Prometheus監控(ack-prometheus-operator組件) | |
服務警示管理 | |
其他問題 |
日誌採集
如何排查容器日誌採集異常?
問題現象
當您已配置採集ACK叢集容器日誌後,但在Log Service控制台預覽頁面未能查到日誌時,說明日誌尚未被成功採集。此時建議分階段排查配置、採集組件與節點狀態、以及日誌採集容器本身的作業記錄,定位採集流程可能存在的問題。
排查前須知
採集容器檔案中的日誌時,需注意如下事項。
步驟一:檢查採集配置
檢查日誌採集配置是否正確,確保日誌採集相關配置無誤,並且容器內日誌有持續輸出。
控制台
在叢集列表頁面,單擊目的地組群名稱,然後在左側導覽列,選擇。
在資來源物件瀏覽器頁簽的搜尋方塊中,搜尋clusteraliyunpipelineconfig,然後單擊搜尋結果ClusterAliyunPipelineConfig。
在ClusterAliyunPipelineConfig面板中,找到目標clusteraliyunpipelineconfig資源,單擊其右側操作列下的YAML編輯。
kubectl
您可以執行以下命令,查看所有由
AliyunPipelineConfig建立的日誌採集配置。kubectl get clusteraliyunpipelineconfigs查看由
AliyunPipelineConfig建立的日誌採集配置的詳細資料和狀態。您可以執行以下命令進行查看。其中,
<config_name>為AliyunPipelineConfig的名稱,請根據實際情況替換。kubectl get clusteraliyunpipelineconfigs <config_name> -o yaml
更多配置項說明,請參見CR參數說明。
配置項 | 檢查點說明 | 樣本 |
| Project 名稱是否正確。登入Log Service控制台,確定您安裝的日誌採集組件產生的Project的名稱。 |
|
| 採集的記錄檔路徑存在且有輸出。更多詳情請參見容器檔案路徑映射。 |
|
| 容器發現功能已開啟。 |
|
| Log Service Endpoint 正確。 |
|
| 地區資訊正確。 |
|
步驟二:檢查採集組件和機器組運行狀態
確認每個 Worker 節點均已部署採集組件(如 Logtail/LoongCollector),並運行正常,且採集容器心跳OK數量與Worker 節點數一致。
檢查採集組件Pod狀態
機器組心跳狀態檢查
在Project列表地區,單擊目標Project。

在左側導覽列中,選擇。
在機器組列表中,單擊目標機器組。
在機器組配置頁面,記錄心跳狀態為 OK 的機器數量,並核對是否與叢集中的 Worker 節點數量一致。 詳情請參見心跳狀態解決方案。
步驟三:查看LoongCollector(Logtail)作業記錄
定位採集容器內部是否有採集異常或錯誤提示,從而進一步分析問題原因。
進入採集組件 Pod
kubectl exec -it -n kube-system loongcollector-ds-XXXX -- bashLogtail日誌儲存在Logtail容器中的
/usr/local/ilogtail/目錄中,檔案名稱為ilogtail.LOG和logtail_plugin.LOG。登入Logtail容器,執行以下命令查看記錄檔:開啟/usr/local/ilogtail/目錄。 cd /usr/local/ilogtail 查看ilogtail.LOG和logtail_plugin.LOG檔案。 cat ilogtail.LOG cat logtail_plugin.LOG查看錯誤記錄檔的警示類型,並根據查詢Log Service採集資料常見的錯誤類型對應的解決辦法。
其他營運操作
查看Kubernetes叢集中Log Service相關組件的狀態
查看Kubernetes叢集中Log Service相關組件的狀態
執行如下命令,查看Log Service的Deployment的狀態和資訊。
kubectl get deploy -n kube-system | grep -E 'alibaba-log-controller|loongcollector-operator'返回結果:
NAME READY UP-TO-DATE AVAILABLE AGE alibaba-log-controller 1/1 1 1 11d執行以下命令,查看關於DaemonSet資源的狀態資訊。
kubectl get ds -n kube-system | grep -E 'logtail-ds|loongcollector-ds'返回結果:
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE logtail-ds 2 2 2 2 2 **ux 11d查看Logtail的版本號碼、IP地址、啟動時間
相關資訊儲存在Logtail容器的
/usr/local/ilogtail/app_info.json檔案中。kubectl exec logtail-ds-****k -n kube-system cat /usr/local/ilogtail/app_info.json系統將返回如下類似結果。
{ "UUID" : "", "hostname" : "logtail-****k", "instance_id" : "0EB****_172.20.4.2_1517810940", "ip" : "172.20.4.2", "logtail_version" : "0.16.2", "os" : "Linux; 3.10.0-693.2.2.el7.x86_64; #1 SMP Tue Sep 12 22:26:13 UTC 2017; x86_64", "update_time" : "2018-02-05 06:09:01" }
如何將ACK叢集日誌傳輸到另一個阿里雲帳號的Project?
Project無法刪除?
問題現象
如何刪除Project,或是在刪除過程中遇到“許可權不足”的錯誤提示時無法刪除?
解決方案
刪除Project或Logstore的步驟,請參見管理Project、管理Logstore。如果無法刪除,請參見刪除Project時提示“操作拒絕,許可權不足”。
Log Service採集資料常見的錯誤類型
錯誤類型 | 錯誤說明 | 解決方案 |
LOG_GROUP_WAIT_TOO_LONG_ALARM | 資料包從產生到發送的過程中等待的時間較長。 | 檢查發送是否正常,或者是否存在資料量超過預設配置、配額不足或者網路存在問題。 |
LOGFILE_PERMINSSION_ALARM | Logtail無許可權讀取指定檔案。 | 檢查伺服器Logtail的啟動帳號,建議以root方式啟動。 |
SPLIT_LOG_FAIL_ALARM | 行首正則與日誌行首匹配失敗,無法對日誌做分行。 | 檢查行首正則正確性。 如果是單行日誌可以配置為 |
MULTI_CONFIG_MATCH_ALARM | 預設情況下,一個檔案只能匹配一個Logtail配置。當多個Logtail配置匹配同一個檔案時,只會生效一個。 說明 Docker標準輸出可以被多個Logtail配置採集。 |
|
REGEX_MATCH_ALARM | 完整正則模式下,日誌內容和Regex不匹配。 | 複製錯誤資訊中的日誌範例,並產生新的Regex。 |
PARSE_LOG_FAIL_ALARM | JSON、分隔字元等模式下,由於日誌格式不符合定義而解析失敗。 | 單擊錯誤資訊,查看失敗的詳細報錯。 |
CATEGORY_CONFIG_ALARM | Logtail採集配置不合法。 | 常見的錯誤為Regex提取檔案路徑作為Topic失敗。 |
LOGTAIL_CRASH_ALARM | Logtail因超過伺服器資源使用上限而崩潰。 | 修改CPU、記憶體使用量上限。更多資訊,請參見設定Logtail啟動參數。 |
REGISTER_INOTIFY_FAIL_ALARM | 在Linux系統中註冊日誌監聽失敗,可能由於沒有檔案夾許可權或檔案夾被刪除。 | 檢查Logtail是否有許可權訪問該檔案夾,或者該檔案夾是否被刪除。 |
DISCARD_DATA_ALARM | 配置Logtail使用的CPU資源不夠或網路發送流控。 | 修改CPU使用上限或網路發送並發限制。更多資訊,請參見設定Logtail啟動參數。 |
SEND_DATA_FAIL_ALARM |
|
|
REGISTER_INOTIFY_FAIL_ALARM | Logtail為日誌目錄註冊的inotify watcher失敗。 | 檢查目錄是否存在以及目錄使用權限設定。 |
SEND_QUOTA_EXCEED_ALARM | 日誌寫入流量超出限制。 | 在控制台上增加Shard數量。更多資訊,請參見分裂Shard。 |
READ_LOG_DELAY_ALARM | 日誌採集進度落後於日誌產生進度,一般是由於配置Logtail使用的CPU資源不夠或是網路發送流控導致。 | 修改CPU使用上限或網路發送並發限制。更多資訊,請參見設定Logtail啟動參數。 在匯入歷史資料時,短時間內會採集大量資料,因此出現該錯誤可暫時忽略。 |
DROP_LOG_ALARM | 日誌採集進度落後於日誌產生進度,且未處理的日誌輪轉超過20個,一般是由於配置Logtail使用的CPU資源不夠或是網路發送流控導致。 | 修改CPU使用上限或網路發送並發限制。更多資訊,請參見設定Logtail啟動參數。 |
LOGDIR_PERMINSSION_ALARM | 沒有日誌監控目錄讀取許可權。 | 檢查日誌監控目錄是否存在。如果存在,請檢查目錄使用權限設定。 |
ENCODING_CONVERT_ALARM | 編碼轉換失敗。 | 檢查日誌編碼格式配置是否與日誌編碼格式一致。 |
OUTDATED_LOG_ALARM | 到期的日誌,日誌時間落後超過12小時。可能原因:
|
|
STAT_LIMIT_ALARM | 日誌採集配置目錄中的檔案數超限。 | 檢查採集的目標目錄下是否有較多的檔案和子目錄,合理設定監控的根目錄和目錄最大監控深度。 您也可以修改mem_usage_limit參數。更多資訊,請參見設定Logtail啟動參數。 |
DROP_DATA_ALARM | 進程退出時日誌落盤到本地逾時,此時會丟棄未落盤完成的日誌。 | 該報錯通常為採集嚴重阻塞導致。您可以修改CPU使用上限或網路發送並發限制。更多資訊,請參見設定Logtail啟動參數。 |
INPUT_COLLECT_ALARM | 輸入源採集異常。 | 根據錯誤提示處理。 |
HTTP_LOAD_ADDRESS_ALARM | HTTP資料擷取配置中,設定的Addresses不合法。 | 檢查Addresses合法性。 |
HTTP_COLLECT_ALARM | HTTP資料擷取異常。 | 根據錯誤提示排查,一般由於逾時導致。 |
FILTER_INIT_ALARM | 過濾器初始化異常。 | 一般由於過濾器的Regex非法導致,請根據提示修複。 |
INPUT_CANAL_ALARM | MySQL Binlog運行異常。 | 根據錯誤提示排查。 在配置更新時,canal服務可能重啟,服務重啟的錯誤可以忽略。 |
CANAL_INVALID_ALARM | MySQL Binlog內部狀態異常。 | 此錯誤一般由於運行時表的schema資訊變更導致meta不一致。請確認報錯期間是否修改過表的schema。 |
MYSQL_INIT_ALARM | MySQL初始化異常。 | 根據錯誤提示處理。 |
MYSQL_CHECKPOING_ALARM | MySQL Checkpoint格式異常。 | 確認是否修改該配置中的Checkpoint相關配置。 |
MYSQL_TIMEOUT_ALARM | MySQL查詢逾時。 | 確認MySQL伺服器和網路是否異常。 |
MYSQL_PARSE_ALARM | MySQL查詢結果解析失敗。 | 確認MySQL配置的Checkpoint格式是否匹配對應欄位的格式。 |
AGGREGATOR_ADD_ALARM | 向隊列中添加資料失敗。 | 由於資料發送過快。如果真實資料量很大,則可忽略。 |
ANCHOR_FIND_ALARM | processor_anchor外掛程式錯誤、配置錯誤或存在不符合配置的日誌。 | 單擊錯誤查看詳細報錯,報錯根據內容分為如下類型。請根據詳細報錯中的資訊,檢查相應的配置是否存在問題。
|
ANCHOR_JSON_ALARM | processor_anchor外掛程式錯誤,對已配置的Start和Stop所確定的內容執行JSON展開時發生錯誤。 | 單擊錯誤查看詳細報錯,檢查所處理的內容以及相關的配置,確定是否有配置錯誤或不合法日誌。 |
CANAL_RUNTIME_ALARM | Binlog外掛程式執行階段錯誤。 | 單擊錯誤查看詳細報錯,根據錯誤資訊進行進一步地排查。一般情況下,該錯誤與所串連的MySQL master相關。 |
CHECKPOINT_INVALID_ALARM | Checkpoint解析失敗。 | 單擊錯誤查看詳細報錯,根據其中的檢查點鍵、檢查點內容(前1024個位元組)以及具體的錯誤資訊進行進一步排查。 |
DIR_EXCEED_LIMIT_ALARM | Logtail同時監聽的目錄數超出限制。 | 檢查當前Logstore的採集配置以及該Logtail上應用的其他配置是否會包含較多的目錄數,合理設定監控的根目錄和目錄最大監控深度。 |
DOCKER_FILE_MAPPING_ALARM | 執行Logtail命令添加Docker檔案對應失敗。 | 單擊錯誤查看詳細報錯,根據其中的命令以及具體的錯誤資訊進行進一步排查。 |
DOCKER_FILE_MATCH_ALARM | 無法在Docker容器中尋找到指定檔案。 | 單擊錯誤查看詳細報錯,根據其中的容器資訊以及尋找的檔案路徑進行進一步排查。 |
DOCKER_REGEX_COMPILE_ALARM | service_docker_stdout外掛程式錯誤,根據配置中的BeginLineRegex編譯失敗。 | 單擊錯誤查看詳細報錯,檢查其中的Regex是否正確。 |
DOCKER_STDOUT_INIT_ALARM | service_docker_stdout外掛程式初始化失敗。 | 單擊錯誤查看詳細報錯,報錯根據內容分為如下類型。
|
DOCKER_STDOUT_START_ALARM | service_docker_stdout外掛程式採集時,stdout大小超過限制。 | 一般由於首次採集時stdout已存在,可忽略。 |
DOCKER_STDOUT_STAT_ALARM | service_docker_stdout外掛程式無法檢測到stdout。 | 一般由於容器退出時無法訪問到stdout,可忽略。 |
FILE_READER_EXCEED_ALARM | Logtail同時開啟的檔案對象數量超過限制。 | 一般由於當前處於採集狀態的檔案數過多,請檢查採集配置是否合理。 |
GEOIP_ALARM | processor_geoip外掛程式錯誤。 | 單擊錯誤查看詳細報錯,報錯根據內容分為如下類型。
|
HTTP_INIT_ALARM | metric_http外掛程式錯誤,配置中指定的ResponseStringMatchRegex編譯錯誤。 | 單擊錯誤查看詳細報錯,檢查其中的Regex是否正確。 |
HTTP_PARSE_ALARM | metric_http外掛程式錯誤,擷取HTTP響應失敗。 | 單擊錯誤查看詳細報錯,根據其中的具體錯誤資訊對配置內容或所請求的HTTP伺服器進行檢查。 |
INIT_CHECKPOINT_ALARM | Binlog外掛程式錯誤,載入檢查點失敗,外掛程式將忽略檢查點並從頭開始處理。 | 單擊錯誤查看詳細報錯,根據其中的具體錯誤資訊來確定是否可忽略此錯誤。 |
LOAD_LOCAL_EVENT_ALARM | Logtail執行了本地事件處理。 | 此警告一般不會出現,如果非人為操作引起此警告,才需要進行錯誤排查。請單擊錯誤查看詳細報錯,根據其中的檔案名稱、配置名、project、logstore等資訊進行進一步地排查。 |
LOG_REGEX_FIND_ALARM | processor_split_log_regex以及 processor_split_log_string外掛程式錯誤,無法從日誌中擷取到配置中指定的SplitKey。 | 單擊錯誤查看詳細報錯,檢查是否存在配置錯誤的情況。 |
LUMBER_CONNECTION_ALARM | service_lumberjack外掛程式錯誤,停止外掛程式時關閉伺服器錯誤。 | 單擊錯誤查看詳細報錯,根據其中的具體錯誤資訊進行進一步排查,此錯誤一般可忽略。 |
LUMBER_LISTEN_ALARM | service_lumberjack外掛程式錯誤,初始化進行監聽時發生錯誤。 | 單擊錯誤查看詳細報錯,報錯根據內容分為如下類型。
|
LZ4_COMPRESS_FAIL_ALARM | Logtail執行LZ4壓縮發生錯誤。 | 單擊錯誤查看詳細報錯,根據其中的log lines、project、category、region等值來進行進一步排查。 |
MYSQL_CHECKPOINT_ALARM | MySQL外掛程式錯誤,檢查點相關錯誤。 | 單擊錯誤查看詳細報錯,報錯根據內容分為如下類型。
|
NGINX_STATUS_COLLECT_ALARM | nginx_status外掛程式錯誤,擷取狀態發生錯誤。 | 單擊錯誤查看詳細報錯,根據其中的URL以及具體的錯誤資訊來進行進一步排查。 |
NGINX_STATUS_INIT_ALARM | nginx_status外掛程式錯誤,初始化解析配置中指定的URL失敗。 | 單擊錯誤查看詳細報錯,根據其中的URL檢查地址是否正確配置。 |
OPEN_FILE_LIMIT_ALARM | Logtail已開啟檔案數量超過限制,無法開啟新的檔案。 | 單擊錯誤查看詳細報錯,根據其中的記錄檔路徑、Project、Logstore等資訊進行進一步排查。 |
OPEN_LOGFILE_FAIL_ALARM | Logtail開啟檔案出錯。 | 單擊錯誤查看詳細報錯,根據其中的記錄檔路徑、Project、Logstore等資訊進行進一步排查。 |
PARSE_DOCKER_LINE_ALARM | service_docker_stdout外掛程式錯誤,解析日誌失敗。 | 單擊錯誤查看詳細報錯,報錯根據內容分為如下類型。
|
PLUGIN_ALARM | 外掛程式初始化及相關調用發生錯誤。 | 單擊錯誤查看詳細報錯,報錯根據內容分為如下類型,請根據具體的錯誤資訊進行進一步排查。
|
PROCESSOR_INIT_ALARM | processor_regex外掛程式錯誤,編譯配置中指定的RegexRegex失敗。 | 單擊錯誤查看詳細報錯,檢查其中的Regex是否正確。 |
PROCESS_TOO_SLOW_ALARM | Logtail日誌解析速度過慢。 |
|
REDIS_PARSE_ADDRESS_ALARM | redis外掛程式錯誤,配置中提供的ServerUrls存在解析失敗的情況。 | 單擊錯誤查看詳細報錯,對其中報錯的URL進行檢查。 |
REGEX_FIND_ALARM | processor_regex外掛程式錯誤,無法從日誌中找到配置中SourceKey指定的欄位。 | 單擊錯誤查看詳細報錯,檢查是否存在SourceKey配置錯誤或日誌不合法的情況。 |
REGEX_UNMATCHED_ALARM | processor_regex外掛程式錯誤,匹配失敗。 | 單擊錯誤查看詳細報錯,報錯根據內容分為如下類型,請根據具體的錯誤資訊進行排查。
|
SAME_CONFIG_ALARM | 同一個Logstore下存在同名的配置,後發現的配置會被拋棄。 | 單擊錯誤查看詳細報錯,根據其中的配置路徑等資訊排查是否存在配置錯誤的情況。 |
SPLIT_FIND_ALARM | split_char以及split_string外掛程式錯誤,無法從日誌中找到配置中SourceKey指定的欄位。 | 單擊錯誤查看詳細報錯,檢查是否存在SourceKey配置錯誤或日誌不合法的情況。 |
SPLIT_LOG_ALARM | processor_split_char以及processor_split_string外掛程式錯誤,解析得到的欄位數量與SplitKeys中指定的不相同。 | 單擊錯誤查看詳細報錯,檢查是否存在SourceKey配置錯誤或日誌不合法的情況。 |
STAT_FILE_ALARM | 通過LogFileReader對象進行檔案採集時發生錯誤。 | 單擊錯誤查看詳細報錯,根據其中的檔案路徑、錯誤資訊進行進一步排查。 |
SERVICE_SYSLOG_INIT_ALARM | service_syslog外掛程式錯誤,初始化失敗。 | 單擊錯誤查看詳細報錯,檢查配置中的Address是否正確。 |
SERVICE_SYSLOG_STREAM_ALARM | service_syslog外掛程式錯誤,通過TCP採集時發生錯誤。 | 單擊錯誤查看詳細報錯,報錯根據內容分為如下類型,請根據詳細報錯中的具體錯誤資訊進行排查。
|
SERVICE_SYSLOG_PACKET_ALARM | service_syslog外掛程式錯誤,通過UDP採集時發生錯誤。 | 單擊錯誤查看詳細報錯,報錯根據內容分為如下類型,請根據詳細報錯中的具體錯誤資訊進行排查。
|
PARSE_TIME_FAIL_ALARM | 解析日誌時間失敗。 | 您可以通過以下兩種方法定位及解決問題:
|
應用監控
為什麼ACK叢集應用安裝探針後沒有監控資料?
問題原因
應用監控被暫停。
應用所在pod的探針沒有被正確載入。
解決方案
檢查應用監控是否被暫停。
檢查探針是否被正確載入。
登入Container Service管理主控台,在叢集列表頁面,單擊目的地組群名稱進入叢集詳情頁。
在左側導覽列選擇。
在容器組頁面頂部選擇您的應用所在的命名空間,然後單擊目標應用右側單擊YAML 編輯。
在編輯YAML對話方塊中查看YAML檔案中是否存在initContainers。

在頁面頂部選擇命名空間為ack-onepilot。查看Pod列表中是否存在名稱首碼為ack-onepilot的Pod,且ack-onepilot的所有Pod均已變換完畢。
如果存在,則執行步驟6。
如果不存在,則在應用市場中安裝ack-onepilot。具體操作,請參見如何卸載arms-pilot和安裝ack-onepilot。
在工作負載下的無狀態或有狀態頁面目標應用右側操作列中選擇,在編輯YAML對話方塊查看YAML檔案中的spec.template.metadata層級下是否存在以下Labels註解。
labels: armsPilotAutoEnable: "on" armsPilotCreateAppName: "<your-deployment-name>" # 請將<your-deployment-name>替換為您的應用程式名稱。 armsSecAutoEnable: "on" # 如果需要接入應用安全,則需要配置此參數。如果存在,則執行步驟7。
如果不存在,則在編輯YAML對話方塊中的spec.template.metadata層級下添加以上Labels註解,然後單擊更新。
在頁面目標應用右側選擇,查看ack-onepilot的Pod日誌是否報STS錯誤,即提示
"Message":"STS錯誤"。如果報STS錯誤,則需為應用所在叢集授權,並重啟應用所在Pod。具體操作,請參見為Container ServiceKubernetes版授權。
如果未報STS錯誤,請提交工單。
在頁面目標應用右側單擊YAML 編輯,在編輯YAML對話方塊中查看YAML檔案中是否存在以下javaagent參數。
-javaagent:/home/admin/.opt/ArmsAgent/aliyun-java-agent.jar說明如果您使用的探針版本在2.7.3.5以下,請將本文中的aliyun-java-agent.jar替換為arms-bootstrap-1.7.0-SNAPSHOT.jar。建議您儘快將探針升級至最新版本。
叢集中不存在ARMS Addon Token
問題現象
目的地組群中不存在ARMS Addon Token。
登入Container Service管理主控台,在叢集列表頁面,單擊目的地組群名稱進入叢集詳情頁。
在左側導覽列選擇。
在頂部選擇命名空間為kube-system,查看addon.arms.token是否存在。

解決方案
為Container ServiceKubernetes版授予ARMS資源的存取權限。
為什麼應用更換了叢集或Namespace後監控資料異常?
問題現象
使用指標自訂大盤,更換了Namespace後應用程式名稱前面的Namespace沒有同步更新。

應用更換了叢集後,RED指標正常展示,但是容器監控下的CPU、記憶體無資料。
可能原因
Namespace、ClusterId這些容器相關的資訊在應用建立時寫入配置,且該部分配置資訊目前並無自動重新整理邏輯,當更換叢集或者調整Namespace後會影響容器相關資料的查詢和展示。
解決方案
刪除應用後,建立應用重新上報監控資料。具體操作,請參見刪除應用。
該方式會導致歷史資料丟失。
提交工單。
如何自訂Java探針掛載路徑
問題背景
在標準部署情境中,ack-onepilot 組件會通過注入 JAVA_TOOL_OPTIONS 環境變數指定 Java 探針(Agent)的掛載路徑。但在某些情境下,使用者可能需要自訂探針掛載路徑以滿足特定需求:
統一組態管理
需通過 Kubernetes ConfigMap 集中管理探針路徑,實現多環境配置一致性。
持久化儲存需求
企業安全規範或營運要求將探針檔案儲存體在自訂持久化卷(PVC)中。
解決方案
自訂Java探針掛載路徑對 ack-onepilot 與 Java 探針版本要求如下:
ack-onepilot 版本不低於 4.1.0。
ARMS Java 探針版本不低於4.2.2,您也可以根據需求自主控制Java探針版本。
ack-onepilot組件由 MSE 和 ARMS 共用,因此自訂 Java 探針掛載路徑對於 MSE 服務治理應用同樣生效。
為需要自訂掛載Java探針的Kubernetes工作負載(如Kubernetes Deployment)添加
disableJavaToolOptionsInjection註解。添加該註解後ack-onepilot組件將不會通過JAVA_TOOL_OPTIONS環境變數自動指定Java探針的掛載路徑及其他JVM參數。
執行以下命令查看目標無狀態(Deployment)應用的YAML檔案。
kubectl get deployment {deployment名稱} -o yaml說明若您不清楚{deployment名稱},請先執行以下命令查看所有無狀態(Deployment)應用,在執行結果中找到目標無狀態(Deployment)應用,再查看目標無狀態(Deployment)應用的YAML檔案。
kubectl get deployments --all-namespace啟動編輯目標無狀態(Deployment)應用的YAML檔案。
kubectl edit deployment {Deployment名稱} -o yaml在YAML檔案中的spec.template.metadata層級下添加以下內容。
labels: armsPilotAutoEnable: "on" armsPilotCreateAppName: "<your-deployment-name>" # 請將<your-deployment-name>替換為您的應用程式名稱。 disableJavaToolOptionsInjection: "true" # 如需自訂Java探針掛載路徑,請將此開關設為true。
在您的應用啟動指令碼或Java啟動命令中自行添加ARMS Java探針的掛載路徑。
其中,
/home/admin/.opt/AliyunJavaAgent/aliyun-java-agent.jar為探針預設掛載路徑,請將該路徑替換為需要自訂掛載的路徑。java -javaagent:/home/admin/.opt/AliyunJavaAgent/aliyun-java-agent.jar ... ... -jar xxx.jar其餘的重要訊息,如上報Region、上報License Key等資訊將由ack-onepilot通過環境變數的方式注入。
ACK叢集如何跨地區上報資料?
問題現象
如果您需要在A地區跨地區向B地區上報資料,該如何處理?
解決方案
將ack-onepilot組件升級至4.0.0或以上版本。
在目標容器叢集ack-onepilot命名空間下的ack-onepilot-ack-onepilot應用中添加ARMS_REPORT_REGION環境變數,值為ARMS所支援的RegionId(例如cn-hangzhou、cn-beijing)。
重啟現有應用或部署一個新的應用,完成跨地區上報。
說明當添加環境變數後,該叢集下所有應用均會跨地區上報到上一步中指定地區。
如何卸載arms-pilot和安裝ack-onepilot
問題背景
ACK舊版應用監控組件arms-pilot已不再維護,您可以安裝升級後的ack-onepilot組件用於監控您的應用,ack-onepilot完全相容arms-pilot,您無需修改應用配置即可無縫接入ack-onepilot。本文介紹如何卸載arms-pilot和安裝ack-onepilot。
解決方案
低於1.16版本的ACK叢集無法安裝ack-onepilot組件,請先升級叢集版本。具體操作,請參見升級ACK叢集K8s版本。
同時安裝ack-onepilot和arms-pilot會導致探針掛載失敗,因此,請卸載arms-pilot後再安裝ack-onepilot。
在卸載和安裝的過程中,arms-pilot組件修改的配置無法自動繼承到ack-onepilot中,請儲存相關參數並在安裝ack-onepilot後重新進行配置。
需要等待arms-pilot組件卸載乾淨,才能安裝ack-onepilot,否則ack-onepilot可能會認為環境中已經存在arms-pilot而不工作。
卸載arms-pilot。
登入Container Service管理主控台,在叢集列表頁面單擊目的地組群名稱。
在左側導覽列選擇。
在Helm頁面的arms-pilot右側操作列,單擊刪除。
在刪除應用對話方塊單擊確定。
檢查arms-pilot是否已卸載。
進入Container Service管理主控台目的地組群下的頁面,在頁面頂部選擇命名空間為arms-pilot,確認該命名空間下的Pod已經被刪除。
說明如果您修改了arms-pilot組件所在的命名空間,此處請選擇對應命名空間。
安裝ack-onepilot。
登入Container Service管理主控台,在叢集列表頁面單擊目的地組群名稱。
在左側導覽列單擊組件管理,然後通過關鍵字搜尋ack-onepilot。
在ack-onepilot卡片上單擊安裝。
說明ack-onepilot組件預設支援1000個pod規模,叢集pod每超過1000個,ack-onepilot資源對應的CPU請增加0.5核、記憶體請增加512 MB。
在彈出的頁面中可以配置相關的參數,建議使用預設值,單擊確認。
說明安裝完成後,您可以在組件管理頁面升級、配置或卸載ack-onepilot組件。
檢查ack-onepilot是否已安裝。
進入Container Service管理主控台目的地組群下的頁面,在頁面頂部選擇命名空間為ack-onepilot,確認該命名空間下的pod已在運行中。

阿里雲Prometheus監控
Prometheus監控頁面顯示未找到相關監控大盤
問題現象
如果您開啟阿里雲Prometheus監控後,在Container Service管理主控台的頁面上,看到未找到相關監控大盤的提示,按照以下操作步驟解決。

解決方案
重新安裝Prometheus監控組件。
卸載組件:
登入Container Service管理主控台,在左側導覽列選擇叢集列表。
在叢集列表頁面,單擊目的地組群名稱,然後在左側導覽列,單擊組件管理。
在組件管理頁面,單擊日誌與監控頁簽,找到ack-arms-prometheus組件。單擊卸載,然後在彈框中單擊確認,
重新安裝組件:
確認卸載完成後,單擊安裝,然後在彈框中單擊確認。
等待安裝完成後。返回到Prometheus監控頁面查看問題是否已解決。
如果問題仍未解決,請繼續以下操作。
檢查Prometheus執行個體接入。
登入ARMS控制台。
在左側導覽列,單擊接入管理。
在已接入環境頁簽,查看容器環境列表,確認是否存在與叢集名稱相同的容器環境。
沒有相應容器環境:參見通過ARMS或Prometheus控制台接入。
有相應容器環境:單擊目標容器環境操作列的探針設定,進入探針設定頁面。
檢查安裝探針是否正常運行。
為什麼可觀測監控Prometheus版資料異常無法顯示?
問題原因
Managed Service for Prometheus資料異常無法顯示,可能是因為同步阿里雲Prometheus雲端服務時任務未成功,導致資源註冊失敗,或者由於Prometheus執行個體未正確接入。請按照以下流程檢查並解決問題。
解決方案
檢查接入Managed Service for Prometheus任務狀態。
登入Container Service管理主控台,在左側導覽列選擇叢集列表。
在叢集列表頁面,單擊目的地組群名稱,然後在左側導覽列,選擇。
在任務頁面頂部設定命名空間為arms-prom,然後單擊o11y-init-environment查看任務狀態是否成功。
若未成功,則可能是同步阿里雲Prometheus雲端服務並註冊資源失敗。可以通過查看其Pod日誌擷取具體失敗原因,詳情請參見Pod異常問題排查。
如果Pod已不存在,請按以下步驟繼續操作。
重新安裝Prometheus監控組件。
卸載組件:
登入Container Service管理主控台,在左側導覽列選擇叢集列表。
在叢集列表頁面,單擊目的地組群名稱,然後在左側導覽列,單擊組件管理。
在組件管理頁面,單擊日誌與監控頁簽,找到ack-arms-prometheus組件。單擊卸載,然後在彈框中單擊確認,
重新安裝組件:
確認卸載完成後,單擊安裝,然後在彈框中單擊確認。
等待安裝完成後。返回到Prometheus監控頁面查看問題是否已解決。
如果問題仍未解決,請繼續以下操作。
檢查Prometheus執行個體接入。
登入ARMS控制台。
在左側導覽列,單擊接入管理。
在已接入環境頁簽,查看容器環境列表,確認是否存在與叢集名稱相同的容器環境。
沒有相應容器環境:參見通過ARMS或Prometheus控制台接入。
有相應容器環境:單擊目標容器環境操作列的探針設定,進入探針設定頁面。
檢查安裝探針是否正常運行。
阿里雲Prometheus監控無法重新安裝出現報錯“rendered manifests contain a resource that already exists”
問題現象
卸載可觀測監控 Prometheus 版後,重新安裝可觀測監控 Prometheus 版時,出現以下報錯資訊。
rendered manifests contain a resource that already exists. Unable to continue with install: existing resource conflict: kind: ClusterRole, namespace: , name: arms-pilot-prom-k8s
問題原因
通過命令手動刪除arms-prom後,可能會存在角色等資源殘留。
解決方案
執行以下命令,找到arms-prometheus的ClusterRole。
kubectl get ClusterRoles --all-namespaces | grep prom執行以下命令,刪除上一步查詢的ClusterRole。
kubectl delete ClusterRole [$Cluster_Roles] -n arms-prom說明[$Cluster_Roles] 為上一步查詢的ClusterRole。
如果刪除後依然報錯,需要查看報錯資訊中的kind值,查看是否存在ClusterRole以外的其他資源殘留,使用類似方法,依次刪除即可。
如何查看ack-arms-prometheus組件版本?
問題背景
您需要查看叢集中部署的ack-arms-prometheus組件版本以及是否需要更新。
解決方案
登入Container Service管理主控台,在左側導覽列選擇叢集列表。
在叢集列表頁面,單擊目的地組群名稱,然後在左側導覽列,單擊組件管理。
在組件管理頁面,單擊日誌與監控頁簽,找到ack-arms-prometheus組件。
在組件下方顯示目前的版本資訊,如有新版本需要升級,可單擊版本右側升級完成組件升級。
說明當已安裝的組件版本不是最新版本時,才會顯示升級操作。
為什麼GPU監控無法部署?
問題原因
如果您的GPU節點上存在汙點,可能導致GPU監控無法部署。您可以通過以下步驟查看GPU節點的汙點情況。
解決方案
執行以下命令,查看目標GPU節點的汙點情況。
如果您的GPU節點擁有自訂的汙點,可找到汙點相關的條目。本文以
key為test-key、value為test-value、effect為NoSchedule為例說明:kubectl describe node cn-beijing.47.100.***.***預期輸出:
Taints:test-key=test-value:NoSchedule通過以下兩種方式處理GPU節點的汙點。
執行以下命令,刪除GPU節點的汙點。
kubectl taint node cn-beijing.47.100.***.*** test-key=test-value:NoSchedule-對GPU節點的汙點進行容忍度聲明,允許Pod調度到該汙點的節點上。
# 1.執行以下命令,編輯ack-prometheus-gpu-exporter。 kubectl edit daemonset -n arms-prom ack-prometheus-gpu-exporter # 2. 在YAML中添加如下欄位,聲明對汙點的容忍度。 #省略其他欄位。 #tolerations欄位添加在containers欄位上面,且與containers欄位同級。 tolerations: - key: "test-key" operator: "Equal" value: "test-value" effect: "NoSchedule" containers: #省略其他欄位。
手動刪除資源或將導致重新安裝阿里雲Prometheus失敗,如何完整地手動刪除ARMS-Prometheus?
問題背景
只刪除阿里雲Prometheus的命名空間,會導致資源刪除後有殘留配置,影響再次安裝。您可以執行以下操作,完整地手動刪除ARMS-Prometheus殘餘配置。
解決方案
刪除arms-prom命名空間。
kubectl delete namespace arms-prom刪除ClusterRole。
kubectl delete ClusterRole arms-kube-state-metrics kubectl delete ClusterRole arms-node-exporter kubectl delete ClusterRole arms-prom-ack-arms-prometheus-role kubectl delete ClusterRole arms-prometheus-oper3 kubectl delete ClusterRole arms-prometheus-ack-arms-prometheus-role kubectl delete ClusterRole arms-pilot-prom-k8s kubectl delete ClusterRole gpu-prometheus-exporter kubectl delete ClusterRole o11y:addon-controller:role kubectl delete ClusterRole arms-aliyunserviceroleforarms-clusterrole刪除ClusterRoleBinding。
kubectl delete ClusterRoleBinding arms-node-exporter kubectl delete ClusterRoleBinding arms-prom-ack-arms-prometheus-role-binding kubectl delete ClusterRoleBinding arms-prometheus-oper-bind2 kubectl delete ClusterRoleBinding arms-kube-state-metrics kubectl delete ClusterRoleBinding arms-pilot-prom-k8s kubectl delete ClusterRoleBinding arms-prometheus-ack-arms-prometheus-role-binding kubectl delete ClusterRoleBinding gpu-prometheus-exporter kubectl delete ClusterRoleBinding o11y:addon-controller:rolebinding kubectl delete ClusterRoleBinding arms-kube-state-metrics-agent kubectl delete ClusterRoleBinding arms-node-exporter-agent kubectl delete ClusterRoleBinding arms-aliyunserviceroleforarms-clusterrolebinding刪除Role及RoleBinding。
kubectl delete Role arms-pilot-prom-spec-ns-k8s kubectl delete Role arms-pilot-prom-spec-ns-k8s -n kube-system kubectl delete RoleBinding arms-pilot-prom-spec-ns-k8s kubectl delete RoleBinding arms-pilot-prom-spec-ns-k8s -n kube-system
手動刪除ARMS-Prometheus資源後,請在Container Service管理主控台的營運管理>組件管理中,重新安裝ack-arms-prometheus組件。
安裝ack-arms-prometheus組件時報錯xxx in use
問題原因
當您部署ack-arms-prometheus 組件時,報錯提示“xxx in use”,應該是存在資源被佔用或殘留的問題,導致組件安裝失敗。
解決方案
登入Container Service管理主控台,在左側導覽列單擊叢集列表。
在叢集列表頁面中,單擊目的地組群名稱或者目的地組群右側操作列下的詳情。
在叢集管理頁面左側導覽列選擇,檢查是否存在ack-arms-prometheus。
存在:在Helm頁面刪除ack-arms-prometheus,並在組件管理頁面重新安裝ack-arms-prometheus。關於安裝ack-arms-prometheus的具體操作,請參見管理組件。
不存在:
若沒有ack-arms-prometheus,表明刪除ack-arms-prometheus helm有資源殘留,需要手動清理。關於刪除ack-arms-prometheus殘留資源的具體操作,請參見阿里雲Prometheus監控常見問題。
在組件管理頁面安裝ack-arms-prometheus。關於安裝ack-arms-prometheus的具體操作,請參見管理組件。
提示Component Not Installed後繼續安裝ack-arms-prometheus組件,安裝失敗
問題現象
嘗試安裝 ack-arms-prometheus 組件時,先出現“Component Not Installed”提示,再次嘗試安裝時仍然失敗。
解決方案
檢查是否已經安裝ack-arms-prometheus組件。
登入Container Service管理主控台,在左側導覽列單擊叢集列表。
在叢集列表頁面中,單擊目的地組群名稱或者目的地組群右側操作列下的詳情。
在叢集管理頁面左側導覽列選擇應用>Helm。
在Helm頁面檢查是否存在ack-arms-prometheus組件。
已有ack-arms-prometheus:在Helm頁面刪除ack-arms-prometheus,並在組件管理頁面重新安裝ack-arms-prometheus。關於安裝ack-arms-prometheus的具體操作,請參見管理組件。
沒有ack-arms-prometheus組件:需進行以下操作。
若沒有ack-arms-prometheus,說明刪除ack-arms-prometheus helm有資源殘留,需要手動清理。關於刪除ack-arms-prometheus殘留資源的具體操作,請參見阿里雲Prometheus監控常見問題。
在組件管理頁面安裝ack-arms-prometheus。操作入口,請參見管理組件。
檢查ack-arms-prometheus的日誌是否有報錯。
登入Container Service管理主控台,在左側導覽列單擊叢集列表。
在叢集列表頁面,單擊目的地組群名稱,然後在左側導覽列,選擇。
在無狀態頁面頂部設定命名空間為arms-prom,然後單擊arms-prometheus-ack-arms-prometheus。
單擊日誌頁簽,查看日誌中是否有報錯。
檢查Agent是否安裝報錯。
登入ARMS控制台。
在左側導覽列,單擊接入管理。
在已接入環境頁簽,查看容器環境列表,單擊目標容器環境操作列的探針設定,進入探針設定頁面。
開源Prometheus監控
如何配置DingTalk警示通知?
問題現象
在部署開源 Prometheus 後,您需要配置通過DingTalk發送警示通知。
解決方案
部署prometheus-operator時報錯
問題現象
Can't install release with errors: rpc error: code = Unknown desc = object is being deleted: customresourcedefinitions.apiextensions.k8s.io "xxxxxxxx.monitoring.coreos.com" already exists解決方案
在卸載prometheus-operator的時候沒有將上一次部署的自訂資源(CRD)及時清理掉,執行如下命令,刪除CRD並重新部署。
kubectl delete crd prometheuses.monitoring.coreos.com
kubectl delete crd prometheusrules.monitoring.coreos.com
kubectl delete crd servicemonitors.monitoring.coreos.com
kubectl delete crd alertmanagers.monitoring.coreos.com郵件警示沒有生效
問題現象
在部署開源 Prometheus 後,您配置的郵件警示沒有發送警示通知。
解決方案
郵件警示沒有生效,有可能是因為smtp_auth_password填寫的是您的登入密碼,而非授權碼。另外SMTP的伺服器位址需要加連接埠號碼。
單擊YAML更新,出現“叢集無法訪問,請重試或提交工單反饋”
問題現象
在部署開源 Prometheus 後,當您單擊YAML更新時,出現"當前叢集暫時無法訪問,請稍後重試或提交工單反饋" 報錯。
解決方案
此問題原因是tiller的設定檔過大,導致的叢集無法訪問,您可以先將部分注釋刪除,再將設定檔以ConfigMap形式,掛載到pod中,目前prometheus-operator只支援prometheus和alertmanager pod的掛載,詳情請參見Prometheus掛載自訂ConfigMap中的方法二。
部署prometheus-operator後,如何開啟其中的功能
問題現象
在部署開源 Prometheus 後,您可能需要進一步配置以啟用其中功能。
解決方案
當部署好prometheus-operator後,如果要開啟部分功能,在叢集資訊頁面,選擇,在ack-prometheus-operator右側,單擊更新,找到對應的開關,進行相應的設定,然後單擊確定開啟您想要的功能。
TSDB和阿里雲雲端硬碟如何選擇
問題現象
在選擇儲存方案時,如何選擇 TSDB和阿里雲雲端硬碟,並且如何配置資料回收策略。
解決方案
TSDB支援的地區比較少,而阿里雲雲端硬碟是全域支援,資料回收策略請參見以下配置。
Grafana Dashboard顯示有問題
問題現象
在部署開源 Prometheus 後,Grafana Dashboard看板顯示有問題。
解決方案
在叢集資訊頁面選擇,在ack-prometheus-operator右側,單擊更新,查看clusterVersion的值是否為正確的叢集版本。Kubernetes叢集是1.16以前的版本,這裡請填寫1.14.8-aliyun.1,1.16及以後的版本,請填寫1.16.6-aliyun.1。
刪除ack-prometheus-operator的命名空間後,重新安裝ack-prometheus-operator失敗
問題原因
只刪除ack-prometheus的命名空間,會導致資源刪除後有殘留配置,影響再次安裝。您可以執行以下操作,刪除殘餘配置。
解決方案
刪除RBAC許可權。
刪除ClusterRole。
kubectl delete ClusterRole ack-prometheus-operator-grafana-clusterrole kubectl delete ClusterRole ack-prometheus-operator-kube-state-metrics kubectl delete ClusterRole psp-ack-prometheus-operator-kube-state-metrics kubectl delete ClusterRole psp-ack-prometheus-operator-prometheus-node-exporter kubectl delete ClusterRole ack-prometheus-operator-operator kubectl delete ClusterRole ack-prometheus-operator-operator-psp kubectl delete ClusterRole ack-prometheus-operator-prometheus kubectl delete ClusterRole ack-prometheus-operator-prometheus-psp刪除ClusterRoleBinding。
kubectl delete ClusterRoleBinding ack-prometheus-operator-grafana-clusterrolebinding kubectl delete ClusterRoleBinding ack-prometheus-operator-kube-state-metrics kubectl delete ClusterRoleBinding psp-ack-prometheus-operator-kube-state-metrics kubectl delete ClusterRoleBinding psp-ack-prometheus-operator-prometheus-node-exporter kubectl delete ClusterRoleBinding ack-prometheus-operator-operator kubectl delete ClusterRoleBinding ack-prometheus-operator-operator-psp kubectl delete ClusterRoleBinding ack-prometheus-operator-prometheus kubectl delete ClusterRoleBinding ack-prometheus-operator-prometheus-psp
刪除CRD。
kubectl delete crd alertmanagerconfigs.monitoring.coreos.com kubectl delete crd alertmanagers.monitoring.coreos.com kubectl delete crd podmonitors.monitoring.coreos.com kubectl delete crd probes.monitoring.coreos.com kubectl delete crd prometheuses.monitoring.coreos.com kubectl delete crd prometheusrules.monitoring.coreos.com kubectl delete crd servicemonitors.monitoring.coreos.com kubectl delete crd thanosrulers.monitoring.coreos.com
服務警示管理
警示規則同步失敗且報錯資訊為The Project does not exist : k8s-log-xxx
問題現象
警示中心中警示規則同步狀態,提示The Project does not exist : k8s-log-xxx。
問題原因
未建立SLS事件中心資源。
解決方案
在Log Service管理主控台確認是否達到Quota上限。資源詳情請參見基礎資源。
重新安裝ack-node-problem-detector組件。
重新安裝組件,會重新建立預設的名為k8s-log-xxxxxx的Project。
卸載ack-node-problem-detector組件。
在Container Service管理主控台目的地組群管理頁左側導覽列中,選擇。
單擊日誌與監控頁簽,在ack-node-problem-detector組件的卡片中單擊卸載。然後在彈框中單擊確認。
待卸載完成後,安裝ack-node-problem-detector組件。
在左側導覽列,選擇
在警示配置頁面,單擊開始安裝,控制台會自動建立Project,安裝組件、升級組件。
然後在警示配置頁面,將對應的警示規則集右側的啟動狀態關閉,等待其警示規則狀態為規則已關閉後,再啟動重試。
警示規則同步狀態失敗出現類似報錯資訊this rule have no xxx contact groups reference
問題現象
警示規則同步狀態失敗出現類似報錯資訊this rule have no xxx contact groups reference。
問題原因
警示規則同步狀態失敗出現類似報錯資訊this rule have no xxx contact groups reference。
解決方案
已建立連絡人,並將連絡人加入連絡人分組中。
在對應警示規則集右側單擊編輯通知對象,為該組警示規則配置訂閱的連絡人分組。
其他問題
kubectl top pod/node為什麼全部沒有資料?
問題現象
在命令列中執行kubectl top pod或者kubectl top node沒有資料。
解決方案
執行以下命令,檢查metrics-server的API Service是否正常。
kubectl get apiservices | grep metrics-server
返回結果中
v1beta1.metrics.k8s.io顯示True,說明metrics-server的API Service正常。可選:如果metrics-server的API Service不正常,在叢集節點上執行以下命令,檢查metrics-server的443連接埠與8082連接埠是否可以在叢集中正常訪問。
curl -v <metrics-server_Pod_IP>:8082/apis/metrics/v1alpha1/nodes curl -v <metrics-server_Pod_IP>:443/apis/metrics/v1alpha1/nodes執行以上命令,能正常返回資料,說明metrics-server的443連接埠與8082連接埠可以在叢集中正常訪問。
可選:如果metrics-server的443連接埠與8082連接埠無法在叢集中正常訪問,重啟metrics-server。
您可以通過刪除metrics-server的Pod的方式重啟metrics-server。
登入Container Service管理主控台,在左側導覽列選擇叢集列表。
在叢集列表頁面,單擊目的地組群名稱,然後在左側導覽列,選擇。
在無狀態頁面頂部設定命名空間為kube-system,單擊metrics-server。
在容器組頁簽下,選擇metrics-server的Pod操作列下的更多>刪除,然後在對話方塊單擊確定。
kubectl top pod/node為什麼部分沒有資料?
問題現象
在命令列中執行kubectl top pod或者kubectl top node部分沒有資料。
解決方案
請按照以下方式進行預檢查。
檢查是特定的節點上所有Pod無資料,還是特定的Pod無資料。如果是特定的節點上所有Pod無資料,請檢查節點是否存在時區漂移,可以通過NTP伺服器的
date命令進行時區校正。檢查metrics-server Pod到特定的Node的10255連接埠的網路連通性。
HPA無法擷取metrics資料怎麼辦?
問題現象
在使用 Kubernetes 的HPA(水平Pod自動擴縮器)時,您可能會遇到無法擷取指標metrics資料的情況。
解決方案
請按照以下方式進行預檢查。
檢查對應的Pod執行kubectl top pod 的結果。如果資料異常,請參見kubectl top pod/node為什麼全部沒有資料?和kubectl top pod/node為什麼部分沒有資料?的檢查方法進行檢查。
滾動發布時為什麼HPA額外彈出了多餘的Pod?
問題現象
在進行 Kubernetes 滾動發布(Rolling Update)時,您可能會發現 HPA(水平Pod自動擴縮器)意外地啟動了額外的 Pod。
解決方案
請按照以下方式進行預檢查。
檢查metrics-server是否升級到了最新的版本。如果版本沒有問題,您可以使用kubectl edit deployments -n kube-system metrics-server命令,在command中加入以下啟動參數。
--metric-resolution=15s
--enable-hpa-rolling-update-skipped=true
> YAML 編輯