查看k8s的etcd pod中的数据

本文介绍如何在Kubernetes环境下查看etcd存储的数据,包括查看所有etcd的key、特定key的内容及节点信息,通过实战演示etcdctl工具的使用。

查看k8s的etcd数据

kubernetes的API对象的数据都保存在etcd中,本文实战如何查看这些数据。

环境信息

实战环境的版本信息如下,请确保以下软件都已运行正常:

操作系统 :Ubuntu 16.04.6 LTS
Kubernetes:1.15

查看etcd版本号:

root@k8s-master:~# cat /etc/kubernetes/manifests/etcd.yaml | grep image:
    image: k8s.gcr.io/etcd:3.3.15-0
root@k8s-master:~#

准备工作

  1. 下载etcd,地址是:https://github.com/etcd-io/etcd/releases ,选3.3.15版本,如下图:
  2. 解压后找到etcdctl文件,将其放入/usr/local/bin目录,记得执行chown命令给予可执行权限;
    现在准备工作已经完成,接下来试试etcdctl工具查看etcd数据;

查看etcd数据的实际操作

执行查询时前缀是固定的,如下所示,使用这个前缀再加上etcd的查找命令即可成功查询:

ETCDCTL_API=3 /usr/local/bin/etcdctl --endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt \
--key=/etc/kubernetes/pki/etcd/healthcheck-client.key

命令行太长了,不容易记住,使用alias命令用来设置指令的别名。

alias etcdctl="ETCDCTL_API=3 /usr/local/bin/etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt --key=/etc/kubernetes/pki/etcd/healthcheck-client.key"

1. 查看所有etcd的所有key,执行以下命令:

root@k8s-master:~# etcdctl get / --prefix --keys-only
。。。

/registry/services/specs/kube-system/kube-dns

/registry/services/specs/kube-system/tiller-deploy

/registry/services/specs/manually/sleep

/registry/validatingwebhookconfigurations/istio-galley

root@k8s-master:~# 

2. 查看指定key的内容,如果您的系统用的是flannel网络插件,可以执行以下命令查看相关数据:

root@k8s-master:~# etcdctl get /registry/configmaps/kube-system/kube-flannel-cfg
/registry/configmaps/kube-system/kube-flannel-cfg
k8s

v1      ConfigMap       
¬ 
kube-flannel-cfg 
                kube-system"*$2a0899cc-5dd7-42d6-9302-dbda856997532뫐Z
appflannelZ

tiernodeb²
0kubectl.kubernetes.io/last-applied-configuration񡠰iVersion":"v1","data":{"cni-conf.json":"{\n  \"name\": \"cbr0\",\n  \"cniVersion\": \"0.3.1\",\n  \"plugins\": [\n    {\n      \"type\": \"flannel\",\n      \"delegate\": {\n        \"hairpinMode\": true,\n        \"isDefaultGateway\": true\n      }\n    },\n    {\n      \"type\": \"portmap\",\n      \"capabilities\": {\n        \"portMappings\": true\n      }\n    }\n  ]\n}\n","net-conf.json":"{\n  \"Network\": \"10.244.0.0/16\",\n  \"Backend\": {\n    \"Type\": \"vxlan\"\n  }\n}\n"},"kind":"ConfigMap","metadata":{"annotations":{},"labels":{"app":"flannel","tier":"node"},"name":"kube-flannel-cfg","namespace":"kube-system"}}
z¶ 
cni-conf.json¤{
  "name": "cbr0",
  "cniVersion": "0.3.1",
  "plugins": [
    {
      "type": "flannel",
      "delegate": {
        "hairpinMode": true,
        "isDefaultGateway": true
      }
    },
    {
      "type": "portmap",
      "capabilities": {
        "portMappings": true
      }
    }
  ]
}
Z
net-conf.jsonI{
  "Network": "10.244.0.0/16",
  "Backend": {
    "Type": "vxlan"
  }
}
"
XshellXshellroot@k8s-master:~#

如上所示,有少量不可见字符,这是因为etcd中存储的并不是json的原文,而是protocol buffer序列化后的数据,不过还是有部分内容是可读的;
3. 查看节点信息,如下所示,当前环境有master和node0两个节点:

root@k8s-master:~# etcdctl get /registry/minions/ --prefix --keys-only
/registry/minions/k8s-master

/registry/minions/k8s-node

root@k8s-master:~#
  1. 执行以下命令可以查看node0节点的信息,由于结果中有很多序列化之后的不可读字符,就不把结果贴出来了:
etcdctl get /registry/minions/k8s-node

etcd中的key及其含义

关于kubernetes的etcd中有哪些key以及它们的含义,可以这篇文章中有更详细的说明:https://jakubbujny.com/2018/09/02/what-stores-kubernetes-in-etcd/

至此,kubernetes环境下如何查看etcd存储的数据的实战就完成了,希望能够帮助您快速查。

参考

https://jakubbujny.com/2018/09/02/what-stores-kubernetes-in-etcd/

https://blog.youkuaiyun.com/boling_cavalry/article/details/88958242

https://www.huweihuang.com/kubernetes-notes/etcd/etcdctl-v3.html

 

<think>嗯,用户遇到了KubernetesEtcd Pod启动时权限被拒绝的问题,具体是访问/bitnami/etcd/data目录时出现权限问题。我需要仔细分析可能的原因,并提供可行的解决方案。 首先,用户提到数据目录的权限问题。这可能是因为PodEtcd进程的用户没有足够的权限访问该目录。Etcd容器可能以非root用户运行,而宿主机上的数据目录权限没有正确设置,导致容器内的用户无法读写。 接下来,我需要考虑几个可能的原因和对应的解决方法。第一个可能性是数据目录的权限和所有权不正确。在宿主机上,如果数据目录的权限过于严格,比如只有root用户有访问权限,而容器内的用户(比如uid 1001)没有,就会导致权限被拒绝。解决方法是通过initContainer来调整目录权限,或者修改PersistentVolume的配置,确保目录有正确的权限。 第二个可能性是SecurityContext的设置不正确。Kubernetes中的SecurityContext可以指定用户和组ID,以及文件系统的权限。如果容器运行时使用的用户ID与数据目录的所有权不匹配,就会出现问题。因此,检查Pod的SecurityContext,设置正确的fsGroup和runAsUser可能会有帮助。 第三个可能性是存储类的配置问题。某些存储类可能默认以root用户挂载卷,导致容器内的非root用户无法访问。在这种情况下,可以配置StorageClass的fsGroup参数,或者在PersistentVolumeClaim中指定fsGroupChangePolicy,确保文件权限正确应用。 另外,用户可能在PersistentVolume中使用了特定配置,比如nfs或者hostPath,这些存储类型可能需要额外的权限设置。例如,使用hostPath时,需要确保宿主机上的目录权限允许容器用户访问。 需要参考用户提供的引用内容,特别是引用[5]中提到的Helm安装Etcd集群的配置,其中提到了设置persistence.enabled=true,可能涉及到持久化存储的配置。如果用户使用类似配置,可能需要检查PersistentVolumeClaim的设置是否正确,以及存储后端(如NFS、本地存储)的权限是否合适。 可能的解决方案步骤包括: 1. 使用initContainer修改数据目录权限,确保容器用户有访问权。 2. 在Pod的SecurityContext中设置fsGroup和runAsUser,调整用户组权限。 3. 检查持久化存储配置,确保StorageClass和PersistentVolume正确设置文件权限。 4. 手动调整宿主机上的数据目录权限,确保容器用户有读写权限。 需要验证这些步骤的有效性,并建议用户根据具体的环境和存储后端选择合适的方法。例如,如果使用NFS,可能需要不同的权限配置;而本地存储则需要关注宿主机目录的权限。同时,需要注意Kubernetes的安全策略,比如Pod Security Policies,可能会限制以root用户运行容器,因此推荐以非root用户运行,并正确配置权限。</think>### 解决方案:K8S etcd Pod 启动时权限被拒绝 `/bitnami/etcd/data` 的修复方法 #### 1. **检查数据目录权限与所有权** **问题根源**: etcd 容器默认以非 root 用户(如 `uid=1001`)运行,若宿主机数据目录 `/bitnami/etcd/data` 的权限或所有权未正确配置,容器用户将无法读写该目录。 **修复步骤**: - **方法一:通过 initContainer 修正权限** 在 Pod 定义中添加 initContainer,以 root 权限临时修改目录所有权: ```yaml spec: initContainers: - name: fix-permissions image: busybox command: ["chown", "-R", "1001:1001", "/bitnami/etcd/data"] volumeMounts: - name: data mountPath: /bitnami/etcd/data ``` - **方法二:手动调整宿主机目录权限** 在宿主机执行: ```bash chmod -R 777 /bitnami/etcd/data # 临时放宽权限(测试用) chown -R 1001:1001 /bitnami/etcd/data # 更安全的长期方案 ``` #### 2. **配置 SecurityContext 强制权限** **作用**: 通过 Kubernetes 的 `securityContext` 明确声明用户/组权限,确保容器进程与文件系统权限匹配。 **实现方式**: ```yaml spec: securityContext: fsGroup: 1001 # 确保挂载卷的组权限为1001 runAsUser: 1001 # 指定容器运行用户 containers: - name: etcd securityContext: allowPrivilegeEscalation: false ``` #### 3. **验证持久化存储配置** **针对不同存储类型**: - **hostPath 存储**:确保宿主机目录权限与容器用户匹配。 - **NFS/云存储**:检查挂载选项(如 `no_root_squash`)是否允许容器用户访问。 - **动态存储类**:在 `StorageClass` 中配置 `allowedTopologies` 或 `mountOptions`。 **示例 PV/PVC 配置**: ```yaml apiVersion: v1 kind: PersistentVolume metadata: name: etcd-data-pv spec: capacity: storage: 8Gi accessModes: - ReadWriteOnce hostPath: path: /bitnami/etcd/data type: DirectoryOrCreate storageClassName: etcd-storage ``` #### 4. **检查 SELinux/AppArmor 限制** **特殊场景**: 若节点启用 SELinux 或 AppArmor,可能需添加策略放行: ```bash # 临时禁用 SELinux(仅用于测试) setenforce 0 # 永久调整策略 semanage fcontext -a -t container_file_t "/bitnami/etcd/data(/.*)?" restorecon -Rv /bitnami/etcd/data ``` #### 5. **验证 Helm 部署参数** **若通过 Helm 部署**: 参考引用[5]中的配置,显式声明权限参数: ```bash helm install etcd-cluster bitnami/etcd \ --set persistence.enabled=true \ --set persistence.existingClaim=etcd-pvc \ --set securityContext.enabled=true \ --set securityContext.fsGroup=1001 \ --set securityContext.runAsUser=1001 ``` --- ### 典型错误日志与排查 - **错误示例**: `mkdir: cannot create directory '/bitnami/etcd/data': Permission denied` - **排查工具**: ```bash # 检查 Pod 描述 kubectl describe pod etcd-0 # 查看容器日志 kubectl logs etcd-0 -c etcd # 进入容器验证权限 kubectl exec -it etcd-0 -- ls -ld /bitnami/etcd/data ``` ---
评论 1
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值