使用kubeadm搭建高可用的K8S集群（2022年1月亲测有效）

kubeadm是官方社区推出的一个用于快速部署kubernetes集群的工具。

这个工具能通过两条指令完成一个kubernetes集群的部署：

在开始之前，部署Kubernetes集群机器需要满足以下几个条件：

31 安装相关包和keepalived

32配置master节点

master1节点配置

master2节点配置

33 启动和检查

在两台master节点都执行

启动后查看master1的网卡信息

41 安装

42 配置

两台master节点的配置均相同，配置中声明了后端代理的两个master节点服务器，指定了haproxy运行的端口为16443等，因此16443端口为集群的入口

43 启动和检查

两台master都启动

检查端口

Kubernetes默认CRI（容器运行时）为Docker，因此先安装Docker。

51 安装Docker

52 添加阿里云YUM软件源

53 安装kubeadm，kubelet和kubectl

由于版本更新频繁，这里指定版本号部署：

61 创建kubeadm配置文件

在具有vip的master上 *** 作，这里为master1

62 在master1节点执行

按照提示保存以下内容，一会要使用（kubeadm init中的回显内容）：

按照提示配置环境变量，使用kubectl工具：

查看集群状态

创建kube-flannelyml，在master1上执行

安装flannel网络

检查

81 复制密钥及相关文件

从master1复制密钥及相关文件到master2

82 master2加入集群

执行在master1上init后输出的join命令,需要带上参数--control-plane表示把master控制节点加入集群（之前kubeadm init回显内容）

检查状态（master1上执行）

在node1上执行

向集群添加新节点，执行在kubeadm init输出的kubeadm join命令（之前kubeadm init回显内容，注意不加--control-plane）：

集群网络重新安装，因为添加了新的node节点（在master1上执行）

检查状态（在master1上执行）

在Kubernetes集群中创建一个pod，验证是否正常运行：

访问地址：>

> 提取码: 4r9r

> 提取码: eqj1

sudo ktctl connect --method=

kubelet 是在每个 Node 节点上运行的主要 “节点代理”。它可以使用以下之一向 apiserver 注册： 主机名（hostname）；覆盖主机名的参数；某云驱动的特定逻辑。

kubelet 是基于 PodSpec 来工作的。每个 PodSpec 是一个描述 Pod 的 YAML 或 JSON 对象。 kubelet 接受通过各种机制（主要是通过 apiserver）提供的一组 PodSpec，并确保这些 PodSpec 中描述的容器处于运行状态且运行状况良好。 kubelet 不管理不是由 Kubernetes 创建的容器。

在hdss01-221hostcom和hdss01-222hostcom:主机上 *** 作：

签发kubelet证书：

在运维主机hdss01-200hostcom上：

创建生成证书签名请求（csr）的json配置文件：

hosts：要把使用和可能使用的ip地址都写上。（ 一定要先规划好 ）

~]# cd /opt/certs/

certs]# vi kubelet-csrjson

{

"CN": "k8s-kubelet",

"hosts": [

"127001",

"10411210",

"10411221",

"10411222",

"10411223",

"10411224",

"10411225",

"10411226",

"10411227",

"10411228"

],

"key": {

"algo": "rsa",

"size": 2048

},

"names": [

{

"C": "CN",

"ST": "henan",

"L": "zhengzhou",

"O": "jx",

"OU": "xxzx"

}

]

}

certs]# cfssl gencert -ca=capem -ca-key=ca-keypem -config=ca-configjson -profile=server kubelet-csrjson |cfssl-json -bare kubelet

把证书复制到运算节点hdss01-221hostcom和hdss01-222hostcom上：

cd /opt/kubernetes/server/bin/cert

scp hdss01-200:/opt/certs/kubeletpem

scp hdss01-200:/opt/certs/kubelet-keypem

创建配置kubeletkubeconfig：

只做一次，最后生成的 kubeletkubeconfig 拷贝至其他节点

conf]# cd /opt/kubernetes/server/bin/conf

set-cluster：

kubectl config set-cluster myk8s

--certificate-authority=/opt/kubernetes/server/bin/cert/capem

--embed-certs=true

--server=>pod 是 kubernetes 中最小的编排单位，通常由一个容器组成 (有时候会有多个容器组成)

nginx-podyaml
将配置apply到k8s

kubectl apply -f nginxyaml
校验部署状态，此时 STATUS 为 Running 表明部署成功

获取 Pod 部署的状态，特别是 IP ,  -o wide 列出IP/Node等更多信息 

kubectl get pods nginx -o wide
获取更加详细的信息

kubectl describe pod nginx
使用 kubectl exec 进入 Pod 的内部容器。如果 Pod 中有多个容器，使用 kubectl exec -c 指定容器

kubectl exec -it nginx sh

在 Pod 容器中执行命令，校验其中的 socket 情况以及 nginx 服务
netstat -tan

wget -q -O - localhost

二、Deployment

在 k8s 中编排应用可以更好地做d性扩容，负载均衡。既然要均衡，一个 Pod 肯定不能均衡，自然要部署多个 Pod

docker-compose 可以简单地通过 docker-compose scale 来扩容，现在用k8s扩容

在k8s中管理 Pod 的称作 Controller，我们可以使用 Deployment 这种 Controller 来为 Pod 进行扩容，当然它还可以滚动升级，回滚，金丝雀等等关于部署的事情

我们编写一个 Deployment 的资源配置文件
我们使用 kubectl apply 部署生效后查看 Pod 以及 Deployment 状态

kubectl get pods -o wide -l 'app=nginx'
三、 Service 

Service 做服务发现 指定 Deployment 或者特定集合 Pod 的网络层抽象
创建NodePort service时，用户可以指定范围为30000-32767的端口，对该端口的访问就能通过 kube-proxy 代理到service后端的pod中

我们使用 kubectl apply 部署生效后查看 Service 状态

kubectl get svc nginx-service -o wide
curl >文章摘自： >本文讲解kubernetes内的dns服务。

每个集群内的service都分配得有一个dns 名称，默认情况下一个客户端POD的DNS搜索将会包含POD自己名称空间以及CLUSTER默认域名。如：

A record通常是一个域名指向一个IP地址。

命名端口需要SRV记录，这些端口正常是service 或者是headless services的一部分，SRV格式记录如： _my-port-name_my-port-protocolmy-svcmy-namespacesvccluster-domainexample

当前，创建 Pod 后，它的主机名是该 Pod 的 metadataname 值。可以通过设置hostname 来重新主机名，此外还可以设置subdomain来指定pod的子域名。
如：Pod 的主机名 annotation 设置为 “foo”，子域名 annotation 设置为 “bar”，在 Namespace “my-namespace” 中对应的 FQDN 为 “foobarmy-namespacesvcclusterlocal”。

例：

如果 Headless Service 与 Pod 在同一个 Namespace 中，它们具有相同的子域名，集群的 KubeDNS 服务器也会为该 Pod 的完整合法主机名返回 A 记录。 例如，在同一个 Namespace 中，给定一个主机名为 “busybox-1” 的 Pod，子域名设置为 “default-subdomain”，名称为 “default-subdomain” 的 Headless Service ，Pod 将看到自己的 FQDN 为 “busybox-1default-subdomainmy-namespacesvcclusterlocal”。 DNS 会为那个名字提供一个 A 记录，指向该 Pod 的 IP。 “busybox1” 和 “busybox2” 这两个 Pod 分别具有它们自己的 A 记录。

spring boot 应用以容器的方式运行在 k8s 集群上面是非常方便的，但是不同的环境需要不同的配置文件，我们可以使用外部的配置中心，比如 nacos 、 apollo 。 k8s 也提供了 configMap 用来将环境配置信息和容器镜像解耦，便于应用配置的修改。本文主要从以下几个方面介绍 spring boot 使用 k8s 的 configMap 作为外部配置的使用方法：

当应用程序启动时，Spring Boot 会自动从以下位置查找并加载 applicationproperties 和 applicationyaml 文件。

配置文件优先级从高到底的顺序如下：

高优先级配置会覆盖低优先级配置

如果我们运行时想指定运行哪个环境的配置文件，可以有三种方式：

ConfigMap 是一种 API 对象，用来将非机密性的数据保存到键值对中。使用时 pod 可以将其用作环境变量、命令行参数或者存储卷中的配置文件。

创建 configMap 的几种方式：

从前面的介绍我们可以知道，spring boot 加载配置文件的最高优先级是 项目根路径下的 /config 子目录 ，所以可以将 configMap 中的配置文件挂载到容器中的项目根路径下的 config 子目录中。

当卷中使用的 configMap 被更新时，所投射的键最终也会被更新。 kubelet 组件会在每次周期性同步时检查所挂载的 configMap 是否为最新。 不过，kubelet 使用的是其本地的高速缓存来获得 configMap 的当前值。 高速缓存的类型可以通过 KubeletConfiguration 结构 的 ConfigMapAndSecretChangeDetectionStrategy 字段来配置。

configMap 既可以通过 watch *** 作实现内容传播（默认形式），也可实现基于 TTL 的缓存，还可以直接经过所有请求重定向到 API 服务器。 因此，从 configMap 被更新的那一刻算起，到新的主键被投射到 Pod 中去，这一 时间跨度可能与 kubelet 的同步周期加上高速缓存的传播延迟相等。 这里的传播延迟取决于所选的高速缓存类型 （分别对应 watch *** 作的传播延迟、高速缓存的 TTL 时长或者 0）。

以环境变量方式使用的 configMap 数据不会被自动更新，更新这些数据需要重新启动 Pod。

参考文档：

k8s 官网

spring boot 官网

适用版本: Kubernetes v122 [stable]

一个完整描述的目标并不是一个完整的对象，仅包括能体现用户意图的字段和值。 该目标（intent）可以用来创建一个新对象， 也可以通过服务器来实现与现有对象的合并。

系统支持多个应用者（appliers）在同一个对象上开展协作。

“字段管理（field management）”机制追踪对象字段的变化。 当一个字段值改变时，其所有权从当前管理器（manager）转移到施加变更的管理器。 当尝试将新配置应用到一个对象时，如果字段有不同的值，且由其他管理器管理， 将会引发冲突。 冲突引发警告信号：此 *** 作可能抹掉其他协作者的修改。 冲突可以被刻意忽略，这种情况下，值将会被改写，所有权也会发生转移。

当你从配置文件中删除一个字段，然后应用这个配置文件， 这将触发服务端应用检查此字段是否还被其他字段管理器拥有。 如果没有，那就从活动对象中删除该字段；如果有，那就重置为默认值。 该规则同样适用于 list 或 map 项目。

服务器端应用既是原有 kubectl apply 的替代品， 也是控制器发布自身变化的一个简化机制。

如果你启用了服务器端应用，控制平面就会跟踪被所有新创建对象管理的字段。

用户管理字段这件事，在服务器端应用的场景中，意味着用户依赖并期望字段的值不要改变。 最后一次对字段值做出断言的用户将被记录到当前字段管理器。 这可以通过发送 POST、 PUT、 或非应用（non-apply）方式的 PATCH 等命令来修改字段值的方式实现， 或通过把字段放在配置文件中，然后发送到服务器端应用的服务端点的方式实现。 当使用服务器端应用，尝试着去改变一个被其他人管理的字段， 会导致请求被拒绝（在没有设置强制执行时，参见冲突）。

如果两个或以上的应用者均把同一个字段设置为相同值，他们将共享此字段的所有权。 后续任何改变共享字段值的尝试，不管由那个应用者发起，都会导致冲突。 共享字段的所有者可以放弃字段的所有权，这只需从配置文件中删除该字段即可。

字段管理的信息存储在 managedFields 字段中，该字段是对象的 metadata 中的一部分。

服务器端应用创建对象的简单示例如下：

上述对象在 metadatamanagedFields 中包含了唯一的管理器。 管理器由管理实体自身的基本信息组成，比如 *** 作类型、API 版本、以及它管理的字段。

Note: 该字段由 API 服务器管理，用户不应该改动它。

不过，执行 Update *** 作修改 metadatamanagedFields 也是可实现的。 强烈不鼓励这么做，但当发生如下情况时， 比如 managedFields 进入不一致的状态（显然不应该发生这种情况）， 这么做也是一个合理的尝试。

managedFields 的格式在 API 文档中描述。

管理器识别出正在修改对象的工作流程（在冲突时尤其有用）, 管理器可以通过修改请求的参数 fieldManager 指定。 虽然 kubectl 默认发往 kubectl 服务端点，但它则请求到应用的服务端点（apply endpoint）。 对于其他的更新，它默认的是从用户代理计算得来。

此特性涉及两类 *** 作，分别是 Apply （内容类型为 application/apply-patch+yaml 的 PATCH 请求） 和 Update （所有修改对象的其他 *** 作）。 这两类 *** 作都会更新字段 managedFields，但行为表现有一点不同。

Note:

不管你提交的是 JSON 数据还是 YAML 数据， 都要使用 application/apply-patch+yaml 作为 Content-Type 的值。

所有的 JSON 文档 都是合法的 YAML。

例如，在冲突发生的时候，只有 apply *** 作失败，而 update 则不会。 此外，apply *** 作必须通过提供一个 fieldManager 查询参数来标识自身， 而此查询参数对于 update *** 作则是可选的。 最后，当使用 apply 命令时，你不能在应用中的对象中持有 managedFields。

一个包含多个管理器的对象，示例如下：

在这个例子中， 第二个 *** 作被管理器 kube-controller-manager 以 Update 的方式运行。 此 update 更改 data 字段的值， 并使得字段管理器被改为 kube-controller-manager。

如果把 update *** 作改为 Apply，那就会因为所有权冲突的原因，导致 *** 作失败。

由服务器端应用实现的合并策略，提供了一个总体更稳定的对象生命周期。 服务器端应用试图依据负责管理它们的主体来合并字段，而不是根据值来否决。 这么做是为了多个主体可以更新同一个对象，且不会引起意外的相互干扰。

当用户发送一个“完整描述的目标”对象到服务器端应用的服务端点， 服务器会将它和活动对象做一次合并，如果两者中有重复定义的值，那就以配置文件的为准。 如果配置文件中的项目集合不是此用户上一次 *** 作项目的超集， 所有缺少的、没有其他应用者管理的项目会被删除。 关于合并时用来做决策的对象规格的更多信息，参见 sigsk8sio/structured-merge-diff

Kubernetes 116 和 117 中添加了一些标记， 允许 API 开发人员描述由 list、map、和 structs 支持的合并策略。 这些标记可应用到相应类型的对象，在 Go 文件或在 CRD 的 OpenAPI 的模式中定义：

若未指定 listType，API 服务器将 patchMergeStrategy=merge 标记解释为 listType=map 并且视对应的 patchMergeKey 标记为 listMapKey 取值。

atomic 列表类型是递归的。

这些标记都是用源代码注释的方式给出的，不必作为字段标签（tag）再重复。

在极少的情况下，CRD 或者内置类型的作者可能希望更改其资源中的某个字段的 拓扑配置，同时又不提升版本号。 通过升级集群或者更新 CRD 来更改类型的拓扑信息与更新现有对象的结果不同。 变更的类型有两种：一种是将字段从 map/set/granular 更改为 atomic， 另一种是做逆向改变。

当 listType、mapType 或 structType 从 map/set/granular 改为 atomic 时，现有对象的整个列表、映射或结构的属主都会变为这些类型的 元素之一的属主。这意味着，对这些对象的进一步变更会引发冲突。

当一个列表、映射或结构从 atomic 改为 map/set/granular 之一 时，API 服务器无法推导这些字段的新的属主。因此，当对象的这些字段 再次被更新时不会引发冲突。出于这一原因，不建议将某类型从 atomic 改为 map/set/granular。

以下面的自定义资源为例：

在 specdata 从 atomic 改为 granular 之前，manager-one 是 specdata 字段及其所包含字段（key1 和 key2）的属主。 当对应的 CRD 被更改，使得 specdata 变为 granular 拓扑时， manager-one 继续拥有顶层字段 specdata（这意味着其他管理者想 删除名为 data 的映射而不引起冲突是不可能的），但不再拥有 key1 和 key2。因此，其他管理者可以在不引起冲突的情况下更改 或删除这些字段。

默认情况下，服务器端应用把自定义资源看做非结构化数据。 所有的键值（keys）就像 struct 的字段一样被处理， 所有的 list 被认为是原子性的。

如果自定义资源定义（Custom Resource Definition，CRD）定义了一个 模式， 它包含类似以前“合并策略”章节中定义过的注解， 这些注解将在合并此类型的对象时使用。

控制器的开发人员可以把服务器端应用作为简化控制器的更新逻辑的方式。 读-改-写 和/或 patch 的主要区别如下所示：

强烈推荐：设置控制器在冲突时强制执行，这是因为冲突发生时，它们没有其他解决方案或措施。

除了通过冲突解决方案提供的并发控制， 服务器端应用提供了一些协作方式来将字段所有权从用户转移到控制器。

最好通过例子来说明这一点。 让我们来看看，在使用 Horizo ntalPodAutoscaler 资源和与之配套的控制器， 且开启了 Deployment 的自动水平扩展功能之后， 怎么安全的将 replicas 字段的所有权从用户转移到控制器。

假设用户定义了 Deployment，且 replicas 字段已经设置为期望的值：

application/ssa/nginx-deploymentyaml

并且，用户使用服务器端应用，像这样创建 Deployment：

然后，为 Deployment 启用 HPA，例如：

现在，用户希望从他们的配置中删除 replicas，所以他们总是和 HPA 控制器冲突。 然而，这里存在一个竟态： 在 HPA 需要调整 replicas 之前会有一个时间窗口， 如果在 HPA 写入字段成为所有者之前，用户删除了replicas， 那 API 服务器就会把 replicas 的值设为 1， 也就是默认值。 这不是用户希望发生的事情，即使是暂时的。

这里有两个解决方案：

首先，用户新定义一个只包含 replicas 字段的配置文件：

application/ssa/nginx-deployment-replicas-onlyyaml

用户使用名为 handover-to-hpa 的字段管理器，应用此配置文件。

在此时间点，用户可以从配置文件中删除 replicas 。

application/ssa/nginx-deployment-no-replicasyaml

注意，只要 HPA 控制器为 replicas 设置了一个新值， 该临时字段管理器将不再拥有任何字段，会被自动删除。 这里不需要执行清理工作。

通过在配置文件中把一个字段设置为相同的值，用户可以在他们之间转移字段的所有权， 从而共享了字段的所有权。 当用户共享了字段的所有权，任何一个用户可以从他的配置文件中删除该字段， 并应用该变更，从而放弃所有权，并实现了所有权向其他用户的转移。

由服务器端应用实现的冲突检测和解决方案的一个结果就是， 应用者总是可以在本地状态中得到最新的字段值。 如果得不到最新值，下次执行应用 *** 作时就会发生冲突。 解决冲突三个选项的任意一个都会保证：此应用过的配置文件是服务器上对象字段的最新子集。

这和客户端应用（Client Side Apply） 不同，如果有其他用户覆盖了此值， 过期的值被留在了应用者本地的配置文件中。 除非用户更新了特定字段，此字段才会准确， 应用者没有途径去了解下一次应用 *** 作是否会覆盖其他用户的修改。

另一个区别是使用客户端应用的应用者不能改变他们正在使用的 API 版本，但服务器端应用支持这个场景。

客户端应用方式时，用户使用 kubectl apply 管理资源， 可以通过使用下面标记切换为使用服务器端应用。

默认情况下，对象的字段管理从客户端应用方式迁移到 kubectl 触发的服务器端应用时，不会发生冲突。

Caution:

保持注解 last-applied-configuration 是最新的。 从注解能推断出字段是由客户端应用管理的。 任何没有被客户端应用管理的字段将引发冲突。

举例说明，比如你在客户端应用之后， 使用 kubectl scale 去更新 replicas 字段， 可是该字段并没有被客户端应用所拥有， 在执行 kubectl apply --server-side 时就会产生冲突。

此 *** 作以 kubectl 作为字段管理器来应用到服务器端应用。 作为例外，可以指定一个不同的、非默认字段管理器停止的这种行为，如下面的例子所示。 对于 kubectl 触发的服务器端应用，默认的字段管理器是 kubectl。

如果你用 kubectl apply --server-side 管理一个资源， 可以直接用 kubectl apply 命令将其降级为客户端应用。

降级之所以可行，这是因为 kubectl server-side apply 会保存最新的 last-applied-configuration 注解。

此 *** 作以 kubectl 作为字段管理器应用到服务器端应用。 作为例外，可以指定一个不同的、非默认字段管理器停止这种行为，如下面的例子所示。 对于 kubectl 触发的服务器端应用，默认的字段管理器是 kubectl。

启用了服务器端应用特性之后， PATCH 服务端点接受额外的内容类型 application/apply-patch+yaml。 服务器端应用的用户就可以把 YAMl 格式的 部分定义对象（partially specified objects）发送到此端点。 当一个配置文件被应用时，它应该包含所有体现你意图的字段。

可以从对象中剥离所有 managedField， 实现方法是通过使用 MergePatch、 StrategicMergePatch、 JSONPatch、 Update、以及所有的非应用方式的 *** 作来覆盖它。 这可以通过用空条目覆盖 managedFields 字段的方式实现。以下是两个示例：

这一 *** 作将用只包含一个空条目的列表覆写 managedFields， 来实现从对象中整个的去除 managedFields。 注意，只把 managedFields 设置为空列表并不会重置字段。 这么做是有目的的，所以 managedFields 将永远不会被与该字段无关的客户删除。

在重置 *** 作结合 managedFields 以外其他字段更改的场景中， 将导致 managedFields 首先被重置，其他改变被押后处理。 其结果是，应用者取得了同一个请求中所有字段的所有权。

Caution: 对于不接受资源对象类型的子资源（sub-resources）， 服务器端应用不能正确地跟踪其所有权。 如果你对这样的子资源使用服务器端应用，变更的字段将不会被跟踪。

参考链接：

>