云原生|kubernetes|kubeadm部署的集群的100年证书

简介: 云原生|kubernetes|kubeadm部署的集群的100年证书

前言:

首先,先看看minikube这样的开发或者测试使用的kubernetes集群的证书时间:

[root@node3 ~]# 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'
[check-expiration] Error reading configuration from the Cluster. Falling back to default configuration
CERTIFICATE                EXPIRES                  RESIDUAL TIME   CERTIFICATE AUTHORITY   EXTERNALLY MANAGED
admin.conf                 Dec 04, 2023 12:07 UTC   363d            ca                      no      
apiserver                  Dec 03, 2025 12:02 UTC   2y              ca                      no      
apiserver-etcd-client      Dec 04, 2023 12:07 UTC   363d            etcd-ca                 no      
apiserver-kubelet-client   Dec 04, 2023 12:07 UTC   363d            ca                      no      
controller-manager.conf    Dec 04, 2023 13:00 UTC   363d            ca                      no      
etcd-healthcheck-client    Dec 04, 2023 12:07 UTC   363d            etcd-ca                 no      
etcd-peer                  Dec 04, 2023 12:07 UTC   363d            etcd-ca                 no      
etcd-server                Dec 04, 2023 12:07 UTC   363d            etcd-ca                 no      
front-proxy-client         Dec 04, 2023 12:07 UTC   363d            front-proxy-ca          no      
scheduler.conf             Dec 04, 2023 13:00 UTC   363d            ca                      no      
CERTIFICATE AUTHORITY   EXPIRES                  RESIDUAL TIME   EXTERNALLY MANAGED
ca                      Dec 01, 2032 12:02 UTC   9y              no      
etcd-ca                 Dec 01, 2032 12:07 UTC   9y              no      
front-proxy-ca          Dec 01, 2032 12:07 UTC   9y              no      

OK,我们可以看到,这些证书的时间大部分都是一年期的。对于minikube这样的集群,无所谓喽,集群本来就是测试性质的,大不了重新部署了,也是非常快的,但,在生产环境下,我们追求的是稳定高效,当然可以使用kubeadm certs renew all来续订证书,但是证书更新了那些服务如果要重启就很麻烦,并且如果不是一个集群的证书要续订,而是有N个集群的证书续订,那可就有得忙了。

因此,我们在生产环境部署集群的时候,如果提前就把证书的时间修改为10年或者更长的100年,会规避掉一些麻烦,也算是提前解决一个可能会对生产造成影响的问题。

那么,如何在部署阶段就修改证书的时间呢?

其实也比较简单,在部署前就利用kubernetes的源码编译出一个新的kubeadm即可了。

实操:

工具原材料:

1,kubernetes的源码

2,go语言环境

目标:

假设生产环境使用的kubernetes版本是1.23.12版本,通过go语言环境,利用kubernetes-1.23.12的源码,重新编译出一个新的kubeadm程序,在kubeadm init 初始化前,用新的kubeadm替换原有的kubeadm,使得kubernetes的证书期限是100年。

一,

go语言环境的安装部署

首先申明,其它版本的编译安装没有试过,反正1.23.12版本的kubernetes需要go-1.17版本以上,否则不能正常编译,会报错:

[root@node4 kubernetes-1.23.12]# make all WHAT=cmd/kubeadm GOFLAGS=-v
Detected go version: go version go1.16.12 linux/amd64.
Kubernetes requires go1.17.0 or greater.
Please install go1.17.0 or later.
!!! [1205 23:21:50] Call tree:
!!! [1205 23:21:50]  1: hack/run-in-gopath.sh:31 kube::golang::setup_env(...)
Detected go version: go version go1.16.12 linux/amd64.
Kubernetes requires go1.17.0 or greater.
Please install go1.17.0 or later.
!!! [1205 23:21:50] Call tree:
!!! [1205 23:21:50]  1: /root/kubernetes-1.23.12/hack/lib/golang.sh:794 kube::golang::setup_env(...)
!!! [1205 23:21:50]  2: hack/make-rules/build.sh:27 kube::golang::build_binaries(...)
!!! [1205 23:21:50] Call tree:
!!! [1205 23:21:50]  1: hack/make-rules/build.sh:27 kube::golang::build_binaries(...)
make[1]: *** [_output/bin/prerelease-lifecycle-gen] Error 1
make: *** [generated_files] Error 2

因此,go语言版本选择的是1.17.1,部署步骤如下;

1,

下载go语言安装包

wget https://studygolang.com/dl/golang/go1.17.1.linux-amd64.tar.gz

2,

解压,解压后的文件移动到/usr/local/目录下:

tar zxf go1.17.1.linux-amd64.tar.gz
mv go /usr/local/

3,

设置环境变量并激活变量

编辑/etc/profile 文件,在末尾添加如下内容:

export GOROOT=/usr/local/go
export PATH=$PATH:/usr/local/go/bin
export GOPATH=/go

激活环境变量:

source /etc/profile

4,

验证go语言环境

[root@node3 ~]# go version
go version go1.17.1 linux/amd64

二,

下载kubernetes-1.23.12源码

https://codeload.github.com/kubernetes/kubernetes/zip/refs/tags/v1.23.12

下载下来的文件上传到服务器解压后,进入解压目录:

[root@node3 kubernetes-1.23.12]# pwd
/root/kubernetes-1.23.12
[root@node3 kubernetes-1.23.12]# ls
api    CHANGELOG     cluster  code-of-conduct.md  docs    go.sum  LICENSE   logo      Makefile.generated_files  OWNERS          pkg     README.md          staging     test         vendor
build  CHANGELOG.md  cmd      CONTRIBUTING.md     go.mod  hack    LICENSES  Makefile  _output                   OWNERS_ALIASES  plugin  SECURITY_CONTACTS  SUPPORT.md  third_party

三,

修改源码的证书相关文件(两个文件):

vim cmd/kubeadm/app/constants/constants.go

以关键字time.Hour 搜索,修改成如下(加个100,原来是只有time.Hour * 24 * 365):

        // CertificateValidity defines the validity for all the signed certificates generated by kubeadm
        CertificateValidity = time.Hour * 24 * 365 * 100
vim staging/src/k8s.io/client-go/util/cert/cert.go

以关键字KeyUsageDigitalSignatur 搜索,修改成如下(10改成100,原来是now.Add(duration365d * 10)):

func NewSelfSignedCACert(cfg Config, key crypto.Signer) (*x509.Certificate, error) {
        now := time.Now()
        tmpl := x509.Certificate{
                SerialNumber: new(big.Int).SetInt64(0),
                Subject: pkix.Name{
                        CommonName:   cfg.CommonName,
                        Organization: cfg.Organization,
                },
                DNSNames:              []string{cfg.CommonName},
                NotBefore:             now.UTC(),
                NotAfter:              now.Add(duration365d * 100).UTC(),
                KeyUsage:              x509.KeyUsageKeyEncipherment | x509.KeyUsageDigitalSignature | x509.KeyUsageCertSign,
                BasicConstraintsValid: true,
                IsCA:                  true,
        }

以上修改请务必以关键字准确定位。

四,

重新编译kubeadm

make all WHAT=cmd/kubeadm GOFLAGS=-v

输出如下:

k8s.io/kubernetes/vendor/github.com/spf13/pflag
k8s.io/kubernetes/hack/make-rules/helpers/go2make
+++ [1205 23:50:42] Building go targets for linux/amd64:
    ./vendor/k8s.io/code-generator/cmd/prerelease-lifecycle-gen
> non-static build: k8s.io/kubernetes/./vendor/k8s.io/code-generator/cmd/prerelease-lifecycle-gen
k8s.io/kubernetes/vendor/golang.org/x/mod/semver
k8s.io/kubernetes/vendor/golang.org/x/sys/execabs
k8s.io/kubernetes/vendor/golang.org/x/tools/internal/event/label
k8s.io/kubernetes/vendor/golang.org/x/xerrors/internal
k8s.io/kubernetes/vendor/golang.org/x/tools/internal/event/keys
k8s.io/kubernetes/vendor/golang.org/x/xerrors
k8s.io/kubernetes/vendor/golang.org/x/mod/module
k8s.io/kubernetes/vendor/golang.org/x/tools/internal/event/core
k8s.io/kubernetes/vendor/golang.org/x/tools/internal/event
k8s.io/kubernetes/vendor/golang.org/x/tools/internal/gocommand
k8s.io/kubernetes/vendor/golang.org/x/tools/internal/typeparams
k8s.io/kubernetes/vendor/golang.org/x/tools/go/ast/astutil
k8s.io/kubernetes/vendor/golang.org/x/tools/internal/fastwalk
k8s.io/kubernetes/vendor/golang.org/x/tools/internal/gopathwalk
k8s.io/kubernetes/vendor/k8s.io/gengo/types
k8s.io/kubernetes/vendor/k8s.io/gengo/namer
k8s.io/kubernetes/vendor/golang.org/x/tools/internal/imports
k8s.io/kubernetes/vendor/github.com/go-logr/logr
k8s.io/kubernetes/vendor/k8s.io/klog/v2
k8s.io/kubernetes/vendor/k8s.io/gengo/parser
k8s.io/kubernetes/vendor/k8s.io/gengo/examples/set-gen/sets
k8s.io/kubernetes/vendor/golang.org/x/tools/imports
k8s.io/kubernetes/vendor/golang.org/x/tools/go/internal/gcimporter
k8s.io/kubernetes/vendor/k8s.io/gengo/generator
k8s.io/kubernetes/vendor/k8s.io/gengo/args
k8s.io/kubernetes/vendor/k8s.io/code-generator/cmd/prerelease-lifecycle-gen/prerelease-lifecycle-generators
k8s.io/kubernetes/vendor/k8s.io/code-generator/cmd/prerelease-lifecycle-gen/args
k8s.io/kubernetes/vendor/golang.org/x/tools/go/internal/packagesdriver
k8s.io/kubernetes/vendor/golang.org/x/tools/internal/packagesinternal
k8s.io/kubernetes/vendor/golang.org/x/tools/internal/typesinternal
k8s.io/kubernetes/vendor/golang.org/x/tools/go/gcexportdata
k8s.io/kubernetes/vendor/golang.org/x/tools/go/packages
k8s.io/kubernetes/vendor/k8s.io/code-generator/pkg/util
k8s.io/kubernetes/vendor/k8s.io/code-generator/cmd/prerelease-lifecycle-gen
Generating prerelease lifecycle code for 28 targets
+++ [1205 23:50:52] Building go targets for linux/amd64:
    ./vendor/k8s.io/code-generator/cmd/deepcopy-gen
后面的略略略

这个编译还是比较快的,等编译完成后,echo $? 看看有没有报错,如果是0,表示编译完成了。

那么,编译出的kubeadm在 _output/bin 目录下:

/root/kubernetes-1.23.12/_output/bin
[root@node4 bin]# ll
total 79020
-rwxr-xr-x 1 root root  6270976 Dec  5 23:51 conversion-gen
-rwxr-xr-x 1 root root  5996544 Dec  5 23:50 deepcopy-gen
-rwxr-xr-x 1 root root  6000640 Dec  5 23:51 defaulter-gen
-rwxr-xr-x 1 root root  3375951 Dec  5 23:50 go2make
-rwxr-xr-x 1 root root 45191168 Dec  5 23:56 kubeadm
-rwxr-xr-x 1 root root  8114176 Dec  5 23:52 openapi-gen
-rwxr-xr-x 1 root root  5963776 Dec  5 23:50 prerelease-lifecycle-gen

五,

测试编程出来的kubeadm 初始化集群,集群的证书是否变为了100年

将以上生成的kubeadm文件拷贝到一个新的服务器上,随便怎么拷贝吧,scp也好,直接lsrzs也可以。

添加yum源,安装kubeadm:

 cat >/etc/yum.repos.d/kubernetes.repo <<EOF
[kubernetes]
name=Kubernetes
baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=0
repo_gpgcheck=0
gpgkey=https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg https://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg
EOF

安装命令:

yum install kubeadm-1.23.12 kubelet-1.23.12 kubectl-1.23.12 -y

安装完毕后,将原来的kubeadm备份一哈;

cp /usr/bin/kubeadm{,.bak}

将新的kubeadm拷贝到/usr/bin/下:

cp -f kubeadm /usr/bin/

因为是测试性质,因此,随便初始化一下:

 kubeadm init \
--image-repository registry.aliyuncs.com/google_containers  \
--apiserver-advertise-address=192.168.217.24  \
--service-cidr=10.96.0.0/16   \
--pod-network-cidr=10.244.0.0/16  \
--kubernetes-version=1.23.12

等待初始化完成后,再次查看证书期限:

[root@node4 yum.repos.d]# 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                 Nov 11, 2122 14:48 UTC   99y             ca                      no      
apiserver                  Nov 11, 2122 14:48 UTC   99y             ca                      no      
apiserver-etcd-client      Nov 11, 2122 14:48 UTC   99y             etcd-ca                 no      
apiserver-kubelet-client   Nov 11, 2122 14:48 UTC   99y             ca                      no      
controller-manager.conf    Nov 11, 2122 14:48 UTC   99y             ca                      no      
etcd-healthcheck-client    Nov 11, 2122 14:48 UTC   99y             etcd-ca                 no      
etcd-peer                  Nov 11, 2122 14:48 UTC   99y             etcd-ca                 no      
etcd-server                Nov 11, 2122 14:48 UTC   99y             etcd-ca                 no      
front-proxy-client         Nov 11, 2122 14:48 UTC   99y             front-proxy-ca          no      
scheduler.conf             Nov 11, 2122 14:48 UTC   99y             ca                      no      
CERTIFICATE AUTHORITY   EXPIRES                  RESIDUAL TIME   EXTERNALLY MANAGED
ca                      Nov 11, 2122 14:48 UTC   99y             no      
etcd-ca                 Nov 11, 2122 14:48 UTC   99y             no      
front-proxy-ca          Nov 11, 2122 14:48 UTC   99y             no      

OK,证书的过期时间都是100年了,说明前面的编译工作是有效果的,可行的。

如果是在生产上,在也不用担心证书过期的问题了,也算是提前解决了一个暴雷问题。

相关实践学习
深入解析Docker容器化技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。Docker是世界领先的软件容器平台。开发人员利用Docker可以消除协作编码时“在我的机器上可正常工作”的问题。运维人员利用Docker可以在隔离容器中并行运行和管理应用,获得更好的计算密度。企业利用Docker可以构建敏捷的软件交付管道,以更快的速度、更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能。 在本套课程中,我们将全面的讲解Docker技术栈,从环境安装到容器、镜像操作以及生产环境如何部署开发的微服务应用。本课程由黑马程序员提供。 &nbsp; &nbsp; 相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
目录
相关文章
|
Cloud Native 关系型数据库 分布式数据库
登顶TPC-C|云原生数据库PolarDB技术揭秘:Limitless集群和分布式扩展篇
阿里云PolarDB云原生数据库在TPC-C基准测试中以20.55亿tpmC的成绩刷新世界纪录,展现卓越性能与性价比。其轻量版满足国产化需求,兼具高性能与低成本,适用于多种场景,推动数据库技术革新与发展。
|
10月前
|
运维 Dubbo Cloud Native
Dubbo 云原生重构出击:更快部署、更强控制台、更智能运维
Apache Dubbo 最新升级支持云原生,提供一键部署微服务集群与全新可视化控制台,提升全生命周期管理体验,助力企业高效构建云原生应用。
1338 25
|
Cloud Native 关系型数据库 分布式数据库
登顶TPC-C|云原生数据库PolarDB技术揭秘:Limitless集群和分布式扩展篇
云原生数据库PolarDB技术揭秘:Limitless集群和分布式扩展篇
|
12月前
|
Cloud Native 关系型数据库 分布式数据库
客户说|知乎基于阿里云PolarDB,实现最大数据库集群云原生升级
近日,知乎最大的风控业务数据库集群,基于阿里云瑶池数据库完成了云原生技术架构的升级。此次升级不仅显著提升了系统的高可用性和性能上限,还大幅降低了底层资源成本。
|
Cloud Native 安全 Serverless
云原生应用实战:基于阿里云Serverless的API服务开发与部署
随着云计算的发展,Serverless架构日益流行。阿里云函数计算(Function Compute)作为Serverless服务,让开发者无需管理服务器即可运行代码,按需付费,简化开发运维流程。本文从零开始,介绍如何使用阿里云函数计算开发简单的API服务,并探讨其核心优势与最佳实践。通过Python示例,演示创建、部署及优化API的过程,涵盖环境准备、代码实现、性能优化和安全管理等内容,帮助读者快速上手Serverless开发。
|
存储 Kubernetes 开发者
容器化时代的领航者:Docker 和 Kubernetes 云原生时代的黄金搭档
Docker 是一种开源的应用容器引擎,允许开发者将应用程序及其依赖打包成可移植的镜像,并在任何支持 Docker 的平台上运行。其核心概念包括镜像、容器和仓库。镜像是只读的文件系统,容器是镜像的运行实例,仓库用于存储和分发镜像。Kubernetes(k8s)则是容器集群管理系统,提供自动化部署、扩展和维护等功能,支持服务发现、负载均衡、自动伸缩等特性。两者结合使用,可以实现高效的容器化应用管理和运维。Docker 主要用于单主机上的容器管理,而 Kubernetes 则专注于跨多主机的容器编排与调度。尽管 k8s 逐渐减少了对 Docker 作为容器运行时的支持,但 Doc
833 5
容器化时代的领航者:Docker 和 Kubernetes 云原生时代的黄金搭档
|
人工智能 缓存 异构计算
云原生AI加速生成式人工智能应用的部署构建
本文探讨了云原生技术背景下,尤其是Kubernetes和容器技术的发展,对模型推理服务带来的挑战与优化策略。文中详细介绍了Knative的弹性扩展机制,包括HPA和CronHPA,以及针对传统弹性扩展“滞后”问题提出的AHPA(高级弹性预测)。此外,文章重点介绍了Fluid项目,它通过分布式缓存优化了模型加载的I/O操作,显著缩短了推理服务的冷启动时间,特别是在处理大规模并发请求时表现出色。通过实际案例,展示了Fluid在vLLM和Qwen模型推理中的应用效果,证明了其在提高模型推理效率和响应速度方面的优势。
云原生AI加速生成式人工智能应用的部署构建
|
运维 Cloud Native 开发工具
智能运维:云原生大规模集群GitOps实践
智能运维:云原生大规模集群GitOps实践,由阿里云运维专家钟炯恩分享。内容涵盖云原生运维挑战、管理实践、GitOps实践及智能运维体系。通过OAM模型和GitOps优化方案,解决大规模集群的发布效率与稳定性问题,推动智能运维工程演进。适用于云原生环境下的高效运维管理。
613 8
|
Kubernetes Cloud Native 微服务
云原生入门与实践:Kubernetes的简易部署
云原生技术正改变着现代应用的开发和部署方式。本文将引导你了解云原生的基础概念,并重点介绍如何使用Kubernetes进行容器编排。我们将通过一个简易的示例来展示如何快速启动一个Kubernetes集群,并在其上运行一个简单的应用。无论你是云原生新手还是希望扩展现有知识,本文都将为你提供实用的信息和启发性的见解。

热门文章

最新文章