kube-prometheus部署

该文详细介绍了如何在k8s环境中部署kube-prometheusv0.11.0的docker版本,包括下载项目、替换镜像源、拉取镜像、修改yaml文件以及部署和配置监控kube-controller-manager和kube-scheduler的过程。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

kube-prometheus(v0.11.0版本)(docker版)

kube-prometheus stackk8s 1.20k8s 1.21k8s 1.22k8s 1.23k8s 1.24
release-0.8×××
release-0.9×××
release-0.10×××
release-0.11×××
main××××

v0.11.0

kube-prometheus-0.11.0

k8s-v1.23.9

1.获取项目

mkdir ~/kube-prometheus && cd ~/kube-prometheus
wget https://github.com/prometheus-operator/kube-prometheus/archive/refs/tags/v0.11.0.tar.gz
tar xf v0.11.0.tar.gz && rm -rf v0.11.0.tar.gz

2、拉取(导入)镜像(docker版)

cd kube-prometheus-0.11.0

[root@master ~/kube-prometheus/kube-prometheus-0.11.0]# find ./manifests -type f |xargs grep 'image: '|sort|uniq|awk '{print $3}'|grep ^[a-zA-Z]|grep -Evw 'error|kubeRbacProxy'|sort -rn|uniq |grep -n ".*"
1:quay.io/prometheus/prometheus:v2.36.1
2:quay.io/prometheus-operator/prometheus-operator:v0.57.0
3:quay.io/prometheus/node-exporter:v1.3.1
4:quay.io/prometheus/blackbox-exporter:v0.21.0
5:quay.io/prometheus/alertmanager:v0.24.0
6:quay.io/brancz/kube-rbac-proxy:v0.12.0
7:k8s.gcr.io/prometheus-adapter/prometheus-adapter:v0.9.1
8:k8s.gcr.io/kube-state-metrics/kube-state-metrics:v2.5.0
9:jimmidyson/configmap-reload:v0.5.0
10:grafana/grafana:8.5.5
[root@master ~/kube-prometheus/kube-prometheus-0.11.0]#

# grep image prometheusAdapter-deployment.yaml
        image: k8s.gcr.io/prometheus-adapter/prometheus-adapter:v0.9.1

# grep image kubeStateMetrics-deployment.yaml
        image: k8s.gcr.io/kube-state-metrics/kube-state-metrics:v2.5.0
cd ~/kube-prometheus/kube-prometheus-0.11.0/manifests

#1、 修改镜像(默认谷歌k8s.gcr.io)
sed -i 's/k8s.gcr.io\/prometheus-adapter/v5cn/g' prometheusAdapter-deployment.yaml

把		k8s.gcr.io/prometheus-adapter/prometheus-adapter:v0.9.1
修改为	   v5cn/prometheus-adapter:v0.9.1

# 2、修改镜像(默认谷歌k8s.gcr.io)
sed -i 's/k8s.gcr.io\/kube-state-metrics/dyrnq/g' kubeStateMetrics-deployment.yaml

把		k8s.gcr.io/kube-state-metrics/kube-state-metrics:v2.5.0
修改为	   dyrnq/kube-state-metrics:v2.5.0
# k8s-master上pull镜像
find ~/kube-prometheus/kube-prometheus-0.11.0/manifests -type f |xargs grep 'image: '|sort|uniq|awk '{print $3}'|grep ^[a-zA-Z]|grep -Evw 'error|kubeRbacProxy'|sort -rn|uniq |xargs -i docker pull {}
# 所有node节点pull镜像
cat > ~/pull.sh << 'EOF'
        v5cn/prometheus-adapter:v0.9.1
        quay.io/prometheus/prometheus:v2.36.1
        quay.io/prometheus-operator/prometheus-operator:v0.57.0
        quay.io/prometheus/node-exporter:v1.3.1
        quay.io/prometheus/blackbox-exporter:v0.21.0
        quay.io/prometheus/alertmanager:v0.24.0
        quay.io/brancz/kube-rbac-proxy:v0.12.0
        jimmidyson/configmap-reload:v0.5.0
        grafana/grafana:8.5.5
        dyrnq/kube-state-metrics:v2.5.0
EOF

cat ~/pull.sh |xargs -i docker  pull {}

3、部署kube-prometheus项目

cd ~/kube-prometheus/kube-prometheus-0.11.0

# 方式1
kubectl apply --server-side -f manifests/setup
kubectl apply -f manifests/

# 方式2(可能要多执行几遍,所以推荐使用方式1)
kubectl apply --server-side -Rf manifests

4、暴露prometheus、grafana、alertmanager服务(将ClusterIP修改为NodePort)

#1、prometheus
kubectl patch svc/prometheus-k8s -n monitoring --patch '{"spec": {"type":"NodePort"}}'

#2、grafana
kubectl patch svc/grafana -n monitoring --patch '{"spec": {"type":"NodePort"}}'

#3、alertmanager
kubectl patch svc/alertmanager-main -n monitoring --patch '{"spec": {"type":"NodePort"}}'
kubectl get svc -n monitoring |grep NodePort
  • grafana默认用户名密码 : admin/admin
  • 若以上访问不到界面的话  去manifests下清理networkPolicy.yaml关键字文件

6、监控kube-controller-manager+kube-scheduler

a、默认没监控到以上两个服务的原因分析:

1、和 ServiceMonitor 的定义有关系

2、先来查看下 kube-scheduler 组件对应的 ServiceMonitor 资源的定义

3、在ServiceMonitor 资源对象里的selector.matchLabelskube-system 这个命名空间下面匹配具有 k8s-app=kube-scheduler 这样的 Service

4、但是系统中根本就没有对应的 Service:(问题所在)

5、所以需要去创建一个对应的 Service 对象,才能与 ServiceMonitor 进行关联:(解决问题) 

cat manifests/kubernetesControlPlane-serviceMonitorKubeScheduler.yaml
kubectl get svc -n kube-system -l app.kubernetes.io/name=kube-scheduler

No resources found in kube-system namespace.

# cat manifests/kubernetesControlPlane-serviceMonitorKubeControllerManager.yaml

#2、先来查看下 kube-scheduler组件对应的 ServiceMonitor资源的定义
# cat manifests/kubernetesControlPlane-serviceMonitorKubeScheduler.yaml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  labels:
    app.kubernetes.io/name: kube-scheduler
    app.kubernetes.io/part-of: kube-prometheus
  name: kube-scheduler
  namespace: monitoring
spec:
  endpoints:
  - bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token
    interval: 30s
    port: https-metrics
    scheme: https
    tlsConfig:
      insecureSkipVerify: true
  jobLabel: app.kubernetes.io/name
  namespaceSelector:
    matchNames:
    - kube-system
  selector:
    matchLabels:
      app.kubernetes.io/name: kube-scheduler

b、解决问题:

mkdir ~/my-kube-prometheus && cd ~/my-kube-prometheus

1、对kube-Controller-manager的监控

cat > ~/my-kube-prometheus/prometheus-kubeControllerManagerService.yaml << EOF
apiVersion: v1
kind: Service
metadata:
  namespace: kube-system
  name: kube-controller-manager
  labels:  #必须和上面的 ServiceMonitor 下面的 matchLabels 保持一致
    app.kubernetes.io/name: kube-controller-manager
spec:
  selector:
    component: kube-controller-manager
  ports:
  - name: https-metrics
    port: 10257
    targetPort: 10257  #controller-manager的安全端口为10257
EOF

其中最重要的是上面 labels 和 selector 部分,labels 区域的配置必须和我们上面的 ServiceMonitor 对象中的 selector 保持一致,selector 下面配置的是 component=kube-scheduler,为什么会是这个 label 标签呢,我们可以去 describe 下 kube-scheduler 这个 Pod:

# kubectl describe pod kube-scheduler-master -n kube-system
Name:                 kube-scheduler-master
Namespace:            kube-system
Priority:             2000001000
Priority Class Name:  system-node-critical
Node:                 master/192.168.1.201
Start Time:           Tue, 04 Jan 2022 10:09:14 +0800
Labels:               component=kube-scheduler
                      tier=control-plane
......

可以看到这个 Pod 具有 component=kube-schedulertier=control-plane 这两个标签,而前面这个标签具有更唯一的特性,所以使用前面这个标签较好,这样上面创建的 Service 就可以和这个 Pod 进行关联了

kubectl apply -f ~/my-kube-prometheus/prometheus-kubeControllerManagerService.yaml

kubectl get svc -n kube-system
 sed -i 's/bind-address=127.0.0.1/bind-address=0.0.0.0/g' /etc/kubernetes/manifests/kube-controller-manager.yaml

因为 kube-controller-manager 启动的时候默认绑定的是 127.0.0.1 地址,所以要通过 IP 地址去访问就被拒绝了,所以需要将 --bind-address=127.0.0.1 更改为 --bind-address=0.0.0.0 ,更改后 kube-scheduler 会自动重启,重启完成后再去查看 Prometheus 上面的采集目标就正常了

2、对kube-Scheduler的监控

cat > ~/my-kube-prometheus/prometheus-kubeSchedulerService.yaml << EOF
apiVersion: v1
kind: Service
metadata:
  namespace: kube-system
  name: kube-scheduler
  labels:  #必须和上面的 ServiceMonitor 下面的 matchLabels 保持一致
    app.kubernetes.io/name: kube-scheduler
spec:
  selector:
    component: kube-scheduler
  ports:
  - name: https-metrics
    port: 10259  
    targetPort: 10259  #需要注意现在版本默认的安全端口是10259
EOF
kubectl apply -f ~/my-kube-prometheus/prometheus-kubeSchedulerService.yaml
sed -i 's/bind-address=127.0.0.1/bind-address=0.0.0.0/g' /etc/kubernetes/manifests/kube-scheduler.yaml

如果要清理 Prometheus-Operator,可以直接删除对应的资源清单即可:

# kubectl delete -f manifests

# kubectl delete -f manifests/setup

感谢:linuxkaifa

<think>好的,我现在需要帮助用户解决kube-prometheus部署时遇到的镜像源缺失问题。首先,我要理解用户的问题。用户提到在部署kube-prometheus时,镜像源缺失,导致无法拉取所需的镜像,这可能是因为默认的镜像仓库访问受限或者需要特定的镜像仓库配置。 接下来,我需要回忆kube-prometheus的常见部署方式和可能出现的镜像问题。kube-prometheus通常通过Helm Chart或者直接使用manifest文件部署。而镜像源缺失可能是因为默认的仓库如gcr.io在国内无法访问,或者某些镜像被转移到了其他仓库。 接下来,我需要考虑可能的解决方案。通常处理这类问题的方法包括: 1. **替换镜像仓库地址**:将gcr.io的镜像替换为国内可访问的镜像源,比如阿里云或者中科大的镜像仓库。这需要修改部署文件中的镜像路径。 2. **手动拉取并重新打标签**:如果某些镜像无法直接拉取,可以手动从其他源下载,然后重新打标签为所需的镜像名称,再推送到私有仓库或直接使用。 3. **使用私有镜像仓库**:配置Kubernetes使用私有仓库,并在部署文件中指定私有仓库的镜像地址。 4. **检查kube-prometheus的配置**:查看是否在部署时有配置参数可以指定镜像仓库,比如Helm的values.yaml文件中的相关参数。 另外,用户提供的引用中有提到kube-apiserver和controller-manager的重启,这可能与镜像拉取失败后的组件状态有关,但主要问题还是镜像源不可达。用户还提到了删除Deployment的操作,这可能是在尝试清理旧的部署,但核心问题还是镜像源。 接下来,我需要验证这些解决方案是否可行。例如,替换镜像仓库为阿里云,可能需要查找对应的镜像是否存在于阿里云中。例如,将`k8s.gcr.io/prometheus-adapter/prometheus-adapter:v0.9.1`替换为`registry.cn-hangzhou.aliyuncs.com/google_containers/prometheus-adapter:v0.9.1`,但需要确认阿里云是否有该镜像的同步。 另外,用户可能需要编辑kube-prometheus的manifest文件,将所有的镜像地址替换为可访问的源。或者,如果使用Helm,可以通过设置values.yaml中的image.repository字段来覆盖默认的仓库地址。 还需要考虑镜像的版本是否正确,是否与kube-prometheus的版本兼容。如果用户使用的是较新版本的kube-prometheus,而镜像仓库中没有对应的版本,也可能导致问题。 最后,可能还需要检查Kubernetes集群的配置,比如是否配置了正确的imagePullSecrets,以访问需要认证的私有仓库。 总结可能的步骤: 1. 确定缺失的具体镜像名称和版本。 2. 查找可用的镜像源,如阿里云、中科大等。 3. 修改部署文件中的镜像地址,或者通过Helm参数覆盖。 4. 手动拉取镜像并重新打标签,适用于无法直接替换的情况。 5. 配置私有仓库和imagePullSecrets。 6. 部署并验证是否解决镜像拉取问题。 同时,用户可能需要具体的命令示例,比如如何替换镜像地址,如何打标签,如何配置Helm等。需要确保提供的步骤清晰且可操作。</think>### 解决kube-prometheus部署时镜像源缺失的方法 #### 1. 替换镜像仓库地址为国内源 kube-prometheus默认使用的镜像仓库(如`k8s.gcr.io`或`quay.io`)可能在国内无法访问。可以通过以下方式替换为国内镜像源: - **阿里云镜像仓库**:将镜像路径前缀替换为`registry.cn-hangzhou.aliyuncs.com/google_containers`。例如: ```yaml # 修改前 image: k8s.gcr.io/prometheus-adapter/prometheus-adapter:v0.9.1 # 修改后 image: registry.cn-hangzhou.aliyuncs.com/google_containers/prometheus-adapter:v0.9.1 ``` - **中科大镜像源**:部分镜像可通过`quay.mirrors.ustc.edu.cn`加速访问。 #### 2. 通过Helm参数覆盖镜像地址(推荐) 若使用Helm部署,可在`values.yaml`中指定镜像仓库和版本: ```yaml prometheus: prometheusSpec: image: repository: registry.cn-hangzhou.aliyuncs.com/google_containers/prometheus tag: v2.30.3 alertmanager: alertmanagerSpec: image: repository: registry.cn-hangzhou.aliyuncs.com/google_containers/alertmanager tag: v0.23.0 ``` #### 3. 手动拉取镜像并重新打标签 若镜像无法直接替换,可手动拉取后推送到私有仓库: ```bash # 从可访问的源拉取镜像 docker pull mirror.example.com/prometheus:v2.30.3 # 重新打标签为k8s.gcr.io的格式 docker tag mirror.example.com/prometheus:v2.30.3 k8s.gcr.io/prometheus:v2.30.3 # 推送到私有仓库(可选) docker push私有仓库地址/prometheus:v2.30.3 ``` #### 4. 配置私有仓库认证 若使用私有仓库,需在Kubernetes中配置`imagePullSecrets`: ```yaml apiVersion: v1 kind: Secret metadata: name: private-registry-secret data: .dockerconfigjson: <Base64编码的Docker配置> type: kubernetes.io/dockerconfigjson ``` 在Deployment中引用: ```yaml spec: template: spec: imagePullSecrets: - name: private-registry-secret ``` #### 5. 验证部署状态 检查Pod日志确认镜像拉取是否成功: ```bash kubectl get pods -n monitoring kubectl describe pod/prometheus-k8s-0 -n monitoring kubectl logs prometheus-operator-xxxxx -n monitoring ``` #### 6. 清理旧配置(如遇残留资源) 若之前部署失败,建议清理后重新部署[^2]: ```bash kubectl delete -f kube-prometheus-manifests/ ``` ### 相关问题 1. 如何查看Kubernetes集群中镜像拉取失败的具体原因? 2. Helm安装kube-prometheus时如何自定义所有组件的镜像版本? 3. Kubernetes如何配置多个镜像仓库的fallback策略?
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值