Kubernetes(k8s)-创建永久(100年)证书

作者介绍:简历上没有一个精通的运维工程师。请点击上方的蓝色《运维小路》关注我,下面的思维导图也是预计更新的内容和当前进度(不定时更新)。

图片

我们上一章介绍了Docker基本情况,目前在规模较大的容器集群基本都是Kubernetes,但是Kubernetes涉及的东西和概念确实是太多了,而且随着版本迭代功能在还增加,笔者有些功能也确实没用过,所以只能按照我自己的理解来讲解。

我们上一小节虽然介绍了如何续期,但是有没有什么方法可以在创建集群的时候就提供更长的证书时间呢?很遗憾,kubeadm并没有给我们提供这样的参数,这个计算逻辑在Kubeadm的源代码里面,所以只能修改源代码来实现。下面的方法可供参考,里面会涉及到部分未讲解的知识可以忽略不记。

准备工作

1.服务器安装go环境

go环境需要大于1.17,否则会报错,我这里用的是1.23

cd /usr/local
wget https://golang.google.cn/dl/go1.23.4.linux-amd64.tar.gz
tar xvf go1.23.4.linux-amd64.tar.gz
vi /etc/profile

#添加下面2行到文件末尾
export PATH=$PATH:/usr/local/go/bin
export GOPATH=$HOME/go

#让环境变量生效
source /etc/profile

2.服务器安装git命令

yum -y install git

修改代码

1.下载代码​​​​​​​

git clone --depth 1 --branch v1.23.12 https://github.com/kubernetes/kubernetes.git
cd kubernetes

2.修改ca证书到100年​​​​​​​

#把代码里面的*10 换*100
vi ./staging/src/k8s.io/client-go/util/cert/cert.go

图片

3.修改生成的其他证书​​​​​​​

#把24*365 换成 24*365*100
vi ./cmd/kubeadm/app/constants/constants.go 

图片

4.编译代码

我这里是在一台临时存量服务器进行编译的,如果你是新机器则可能还需要安装gcc等包。

yum -y install gcc
    make all WHAT=cmd/kubeadm GOFLAGS=-v

    编译完成以后,获取对应的kubeadm二进制包。​​​​​​​

    [root@localhost kubernetes]# ls _output/bin/kubeadm
    _output/bin/kubeadm

    重新安装集群

    参考Kubernetes(k8s)-k8s安装(docker版)

    这里需要使用我们手工编译的kubeadm二进制文件替换掉yum安装的kubeadm文件,文件路径是/usr/bin/kubeadm。然后使用进行集群的创建。

    检查证书

    可以看到,无论是ca证书,还是其他业务使用的证书都是100年,包括kubelet证书也是100年,这样我们的集群就不用在考虑证书到期的问题。​​​​​​​

    [root@node02 ~]# kubeadm certs check-expiration
    [check-expiration] Reading configuration from the cluster...
    [check-expiration] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
    
    CERTIFICATE                EXPIRES                  RESIDUAL TIME   CERTIFICATE AUTHORITY   EXTERNALLY MANAGED
    admin.conf                 Dec 22, 2124 03:28 UTC   99y             ca                      no      
    apiserver                  Dec 22, 2124 03:28 UTC   99y             ca                      no      
    apiserver-etcd-client      Dec 22, 2124 03:28 UTC   99y             etcd-ca                 no      
    apiserver-kubelet-client   Dec 22, 2124 03:28 UTC   99y             ca                      no      
    controller-manager.conf    Dec 22, 2124 03:28 UTC   99y             ca                      no      
    etcd-healthcheck-client    Dec 22, 2124 03:28 UTC   99y             etcd-ca                 no      
    etcd-peer                  Dec 22, 2124 03:28 UTC   99y             etcd-ca                 no      
    etcd-server                Dec 22, 2124 03:28 UTC   99y             etcd-ca                 no      
    front-proxy-client         Dec 22, 2124 03:28 UTC   99y             front-proxy-ca          no      
    scheduler.conf             Dec 22, 2124 03:28 UTC   99y             ca                      no      
    
    CERTIFICATE AUTHORITY   EXPIRES                  RESIDUAL TIME   EXTERNALLY MANAGED
    ca                      Dec 22, 2124 03:28 UTC   99y             no      
    etcd-ca                 Dec 22, 2124 03:28 UTC   99y             no      
    front-proxy-ca          Dec 22, 2124 03:28 UTC   99y             no   
    #kubelet证书也是100年
    [root@node02 pki]#  openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -noout -text |grep Validity -A2
            Validity
                Not Before: Jan 15 03:28:50 2025 GMT
                Not After : Dec 22 03:28:51 2124 GMT

    ​​​​​​​

    这样我们就实现了永久证书,再也不用考虑证书问题。

    运维小路

    一个不会开发的运维!一个要学开发的运维!一个学不会开发的运维!欢迎大家骚扰的运维!

    关注微信公众号《运维小路》获取更多内容。

    <think>好的,用户提供了一段日志信息,需要帮忙分析问题。首先,我需要仔细看一下日志内容。时间戳显示的是2025,不过这可能是因为系统时间设置错误或者日志记录的配置有问题,不过暂时先不管这个,先看错误信息。 日志里提到有INFO、WARNING和ERROR级别的消息。首先是INFO记录了一个GET请求到http://es01:9200/,状态是N/A,持续了3.987秒。这说明应用尝试访问Elasticsearch节点es01:9200,但请求失败了,状态N/A可能表示没有收到响应。 接下来是WARNING,说节点Urllib3HttpNode失败了一次,被设置了1秒的超时。然后尝试重试,重试次数0次,总共3次。之后出现了Traceback,抛出了ConnectionError,具体原因是NameResolutionError,无法解析主机名'es01',错误信息是“Name or service not known”。这说明应用在尝试解析es01这个主机名时失败了,导致无法建立连接。 然后,又出现了类似的WARNING,节点失败次数增加,超时时间可能增加,但问题根源还是主机名解析失败。 用户的问题是“这是什么问题啊”,需要解释日志中的错误原因,并给出解决方案。根据错误信息,最直接的问题是DNS解析失败,无法找到es01这个主机名。可能的原因有几个方面: 1. 主机名配置问题:es01可能没有在DNS服务器中正确注册,或者在运行应用的机器上的hosts文件中没有对应的条目。 2. 网络连接问题:机器可能无法访问DNS服务器,或者有防火墙阻止了DNS查询。 3. 应用配置错误:应用可能错误地配置了Elasticsearch的主机名,应该是正确的地址,比如IP或者正确的主机名。 4. 容器环境问题:如果是在DockerKubernetes环境中运行,es01可能是一个服务名,需要确保网络配置正确,服务发现正常。 接下来需要验证这些可能性。首先检查应用所在环境是否能解析es01。可以在机器上执行nslookup es01或者ping es01,看看是否能解析出IP地址。如果解析失败,就需要配置DNS或者在hosts文件中添加条目。例如,在hosts文件中添加一行:192.168.1.100 es01,假设Elasticsearch运行在192.168.1.100。 另外,如果是容器环境,比如Docker Compose,需要确保服务名称正确,并且容器在同一个网络中。检查Docker Compose文件中的服务定义和网络配置是否正确。例如,服务名是否确实是es01,端口是否正确映射,网络是否被其他服务正确加入。 还有可能应用配置的Elasticsearch地址错误,比如应该是http://localhost:9200,但错误地配置成了es01。这时候需要检查应用的配置文件,确认主机名是否正确。 此外,检查Elasticsearch是否确实在运行,并且监听在9200端口。可以使用curl或者telnet检查端口是否可达。如果Elasticsearch没有运行,或者防火墙阻止了访问,也会导致连接问题。 总结一下,解决方案包括检查主机名解析、检查网络连接、验证Elasticsearch配置和状态,以及确保容器(如果有使用)的网络设置正确。用户可能需要根据他们的具体环境来调整这些步骤。</think>以下是对该日志问题的逐步分析: --- ### 一、核心问题定位 从日志中可见关键错误: $$ \text{NameResolutionError: Failed to resolve 'es01'} $$ **本质原因**:应用程序无法通过DNS解析主机名`es01`,导致无法连接Elasticsearch服务。 --- ### 二、错误链分析 1. **请求阶段** ```log GET http://es01:9200/ [status:N/A duration:3.987s] ``` - 尝试访问`es01:9200`但未收到响应(`status:N/A`) - 耗时3.987秒后超时 2. **重试机制触发** ```log Node failed for 1 times...putting on 1 second timeout Retrying request after failure (attempt 0 of 3) ``` - 客户端启动重试机制(最多3次) 3. **根本错误暴露** ```log NameResolutionError: Failed to resolve 'es01' ``` - 明确显示DNS解析失败 --- ### 三、可能原因排查 #### 场景1:DNS配置错误 - **检查项** - 目标机器是否配置了正确的DNS服务器 - 域名`es01`是否在DNS服务器中注册 - 本地`/etc/hosts`文件是否包含`es01`的IP映射 - **验证命令** ```bash nslookup es01 # DNS解析测试 ping es01 # 检查基本连通性 cat /etc/hosts # 查看本地hosts配置 ``` #### 场景2:容器网络问题(常见于Docker/K8s环境) - **检查项** - 容器是否与Elasticsearch服务在同一个网络 - 容器内DNS配置是否正确 - 服务名称`es01`是否与容器服务命名一致 - **Docker示例修复** ```yaml # docker-compose.yml services: app: networks: - es_network # 必须与ES服务共享网络 elasticsearch: image: elasticsearch:8.5.0 container_name: es01 # 必须与代码中配置的主机名一致 networks: - es_network ``` #### 场景3:应用配置错误 - **检查项** - 代码/配置文件中Elasticsearch的地址是否正确 - 是否应该使用IP地址替代主机名 - **修正示例** ```python # 错误配置 ES_HOST = "http://es01:9200" # 依赖DNS解析 # 正确配置(直接使用IP) ES_HOST = "http://192.168.1.100:9200" ``` --- ### 四、紧急修复步骤 1. **临时解决方案** 在主机或容器的`/etc/hosts`中添加解析: ```bash echo "192.168.1.100 es01" >> /etc/hosts # 替换为实际ES服务器IP ``` 2. **永久解决方案** - 在DNS服务器中添加`es01`的A记录 - 或改用静态IP连接Elasticsearch 3. **环境验证** ```bash curl http://es01:9200 # 测试ES连通性 telnet es01 9200 # 测试端口可达性 ``` --- ### 五、附加排查建议 1. **防火墙检查** ```bash iptables -L -n | grep 9200 # 检查端口是否开放 ``` 2. **Elasticsearch服务状态** ```bash systemctl status elasticsearch # 确认服务正在运行 ``` 3. **查看ES日志** ```bash journalctl -u elasticsearch # 检查ES自身是否有异常 ``` --- ### 六、典型错误对比 | 错误类型 | 表现特征 | 解决方案 | |------------------------|----------------------------|-------------------------| | DNS解析失败 | `NameResolutionError` | 配置DNS/hosts文件 | | 连接拒绝 | `ConnectionRefusedError` | 检查ES服务状态和防火墙 | | 证书错误 | `SSLError` | 更新证书或禁用SSL验证 | | 认证失败 | `AuthenticationException` | 检查用户名/密码或API密钥 | --- 通过上述步骤,可系统性解决因`es01`解析失败导致的Elasticsearch连接问题。
    评论
    添加红包

    请填写红包祝福语或标题

    红包个数最小为10个

    红包金额最低5元

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

    抵扣说明:

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

    余额充值