轻量应用服务器搭建k8s

① 请问公司起步建立k8s，需要什么样的服务器配置，多少台服务器每台怎样的配置要求

服务器按自己预算买就行，vCenter HA cluster 的建议是最少三台服务器。这样可以实现一个host维护或有问题的时候另一台马上能补上。k8s就在vcenter里用vm实现。 ⌄这样的好处是以后有需求的话可以随意增加服务器到vcenter里扩展cpu或者存储能力。
蓝海大脑水冷工作站具有高性能，高密度、扩展性强等特点。液冷GPU服务器产品支持1~20块 GPU卡，还可以选择。芯片主要采用龙芯、飞腾、申威、海光、英伟达、Intel、AMD。完全定制啊，敲开心。适配多个存储卡，适用于深度学习训练及推理、生命科学、医药研发、虚拟仿真等场景，覆盖服务器、静音工作站、数据中心等多种产品形态，量身定制，满足客户全场景需求。

② 腾讯轻量云服务器搭建k8s环境

4C4G机器设置为k8smaster节点，另外一台机器设置为k8snode节点

分别进入两台的 /ect/hosts 目录，设置r如下host

由于k8s内部节点之间的通讯使用的是内网ip，我们需要把内网ip的重定向到公网ip上

由于两台机器是处于公网环境，且k8s节点之间需要通讯，所以需要开放一些端口，端口配置可以直接进到腾讯云控制台进行配置

以下是官网要求的master节点的端口配置

可以进入腾讯云服务器的防火墙配置开放相应端口，端口可以限定来源，只允许node节点(192.168.2.2)访问

以下是官网要求的node节点的端口配置

同理，也设置node节点的端口

master节点需要安装

node节点需要安装

添加安装源(所有节点)

安装命令

设置开机启动

修改docker配置（所有节点）

组件安装完成后就可以启动了，首先启动master节点，然后让node节点加入master几点即可。

在master节点使用kubeadm初始化集群

这里需要保存token，token是用于node节点加入maste节点的凭证

node节点加入master节点

安装网络插件，否则node是NotReady状态（主节点跑）

kubectl get nodes

③ 企业级k8s集群部署

二进制包

注：推荐用二进制包部署Kubernetes集群，虽手动部署麻烦，但可以学习很多工作原理利于后期维护。

环境

可以使用VMware虚拟机，宿主机必须8G内存以上

• 服务器可以访问外网，有从网上拉取镜像的需求

单Master服务器规划：（ 注：部署时候根据具体环境进行IP地址调整即可 ）

这里使用3台组建集群，可容忍1台机器故障，当然，你也可以使用5台组建集群

etcd1： 192.168.3.110 etcd2： 192.168.3.112 etcd3： 192.168.3.113

cfssl是一个开源的证书管理工具，使用json文件生成证书，相比openssl更方便使用。

找任意一台服务器操作，这里用Master节点。

创建工作目录：

自签CA：

生成证书：

会生成ca.pem和ca-key.pem文件。

创建证书申请文件：

注：上述文件hosts字段中IP为所有etcd节点的集群内部通信IP，一个都不能少！为了方便后期扩容可以多写几个预留的IP。

生成证书：

会生成etcd.pem和etcd-key.pem文件。

https://github.com/etcd-io/etcd/releases/download/v3.5.1/ etcd-v3.5.1-linux-amd64.tar.gz

以下在节点1上操作，然后将文件拷贝到其他集群机器

把刚才生成的证书拷贝到配置文件中的路径：

注意修改节点2和节点3分别etcd.conf配置，按照下面提示的修改

启动各节点的etcd服务

如果输出上面信息，就说明集群部署成功。

如果有问题看日志：/var/log/message

docker二进制下载地址：

https://download.docker.com/linux/static/stable/x86_64/docker-19.03.9.tgz

注：使用yum安装也行

集群所有机器都安装docker

生成证书：

会生成ca.pem和ca-key.pem文件。

创建证书申请文件：

生成证书：

会生成k8s.pem和k8s-key.pem文件。

下载地址参考：

https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md

https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#downloads-for-v12013

Wget https://dl.k8s.io/v1.20.13/kubernetes-server-linux-amd64.tar.gz

把刚才生成的证书拷贝到配置文件中的路径：

TLS Bootstrapping 机制，对work-node加入进行自签证书用

创建上述配置文件中token文件：

token 可以自行生产，网络下怎么生产

kube-apiserver服务

生成kube-controller-manager证书：

生成kubeconfig文件（以下是shell命令，直接在终端执行）：

生成kube-scheler证书：

生成kubeconfig文件：

生成kubeconfig文件：

通过kubectl工具查看当前集群组件状态：

在所有worker node创建工作目录：

从master节点拷贝：

注：由于网络插件还没有部署，节点会没有准备就绪 NotReady

二进制包下载地址：https://github.com/containernetworking/plugins/releases

确保kubelet启用CNI：

在Master执行：

应用场景：例如kubectl logs

在Master节点将Worker Node涉及文件拷贝到新节点192.168.3.112/113

注：这几个文件是证书申请审批后自动生成的，每个Node不同，必须删除

Node2（192.168.3.113 ）节点同上。记得修改主机名！

访问地址：https://NodeIP:30001

创建service account并绑定默认cluster-admin管理员集群角色：

使用输出的token登录Dashboard。

CoreDNS用于集群内部Service名称解析。

DNS解析测试：

这样 单Master集群就搭建完成了

④ 如何在本地快速启动一个k8s集群小技巧，学到了

最近在阅读《每天5分钟玩转Kubernetes》 这本书，个人感觉是一本不错的 K8S 的入门书籍。

我们在刚开始学习一项技术的时候，不论是通过官方文档、书籍，亦或是视频的形式，如果仅仅是去看，而不去练习实践的话，那么是很难将其真正应用起来的。

然而当我开始准备实践的时候，发现要想在本地将 K8S 跑起来，并不像我们想象的那么容易。存在以下几点“问题”：

那么有没有什么方案可以更优雅更轻量更快速搭建一个 K8S 集群呢？答案就是 k3d。

其实有很多种方式可以在本地运行 k8s，比如：

当然了，如果只是学习 k8s 的使用，那么以上方案均可以使用。

k3s 包括以下一些组件：

k3s 是一种模块化的发行版，可以很方便的替换上面的组件。

在 Mac 下，使用 Homebrew 可以很方便的安装 k3d： brew install k3d。

顺手安装一下 kubectl 和 kubecm：

我们通过 k3d 的命令可以轻易的在本地启动一个或 N 个 k8s 集群。

首先我们尝试创建一个 1主2从 的集群：

初次创建可能会比较慢，因为会从 Docker 仓库拉取最新的 rancher/k3s 镜像。

当出现下面的日志时，k8s 集群就创建成功了

此时，我们按照日志提示，运行 kubectl cluster-info 查看下当前集群的信息：

运行 kubectl get nodes 查看下当前集群的节点情况：

注意，这里的“节点”其实是本机 Docker 运行的容器，通过 docker ps 查看下当前本机运行的容器吧

解释一下我们创建集群时配置的端口映射：

现在我们集群和主机的网络通信是这样子的：

创建一个 nginx 的 Deployment

创建一个 Service 通过 ClusterIP 的方式暴露服务

创建一个 Ingress，k3s 默认安装的是 traefik 1.x 作为 Ingress Controller

此时，打开浏览器，访问 http://localhost:8080/ 就可以看到熟悉的 nginx 默认页。

这是不是太酷了~

当使用 Helm Chart 安装 Rancher 时，可能会出现如下错误日志：

要创建一个 k8s 版本号为 v1.19.8-k3s1 的 k8s 集群，可以在创建集群的命令后面加 --image 参数，指定版本号：k3d cluster create first-cluster xxxxx --image rancher/k3s:v1.19.8-k3s1

还记得在第二步顺手安装的 kubecm 吗？

当我们在本地使用 k3d 创建了多个集群之后，我们可以通过 kubecm 快速切换 context。

⑤ Gitlab+Jenkins+Docker+Harbor+K8s集群搭建CICD平台

上帝借由各种途径使人变得孤独，好让我们可以走向自己。 ——赫尔曼·黑塞《德米安》

CI即为 持续集成(Continue Integration,简称CI) ，用通俗的话讲，就是 持续的整合版本库代码编译后制作应用镜像 。建立有效的持续集成环境可以减少开发过程中一些不必要的问题、 提高代码质量、快速迭代 等,

Jenkins :基于Java开发的一种持续集成工具,用于监控持续重复的工作,旨在提供一个开放易用的软件平台,使软件的持续集成变成可能。
Bamboo : 是一个企业级商用软件,可以部署在大规模生产环境中。

CD即持续交付Continuous Delivery和持续部署Continuous Deployment，用通俗的话说，即可以持续的部署到生产环境给客户使用，这里分为两个阶段，持续交付我理解为满足上线条件的过程，但是没有上线，持续部署，即为上线应用的过程

关于 CD环境 ，我们使用以前搭建好的 K8s集群 ，K8s集群可以实现应用的 健康 检测，动态扩容，滚动更新 等优点，关于K8s集群的搭建，小伙伴可以看看我的其他文章

拉取镜像，启动并设置开机自启

配置docker加速器

GitLab 不多介绍。一个基于Git的版本控制平台，,提供了Git仓库管理、代码审查、问题跟踪、活动反馈和wiki，当然同时也提供了

切记:这里的端口要设置成80，要不push项目会提示没有报错，如果宿主机端口被占用，需要把这个端口腾出来

external_url 'http://192.168.26.55’

gitlab_rails[‘gitlab_ssh_host’] = 餘.168.26.55’

gitlab_rails[gitlab_shell_ssh_port] = 222

修改完配置文件之后。直接启动容器

相关的git命令

下面我们要配置私有的docker镜像仓库，用到的机器为：

这里仓库我们选择 harbor ，因为有web页面，当然也可以使用 registry

首先需要设置selinux、防火墙

安装并启动docker并安装docker-compose，关于docker-compose，这里不用了解太多，一个轻量的docker编排工具

解压harbor 安装包：harbor-offline-installer-v2.0.6.tgz，导入相关镜像

修改配置文件

harbor.yml：设置IP和用户名密码

./prepare && ./install.sh

查看相关的镜像

访问测试

这里因为我们要在192.168.26.55(CI服务器)上push镜像到192.168.26.56(私仓)，所有需要修改CI服务器上的Docker配置。添加仓库地址

修改后的配置文件

加载使其生效

CI机器简单测试一下

push一个镜像，可以在私仓的web页面查看

镜像jenkins拉取

这里为什么要改成 1000，是因为容器里是以 jenkins 用户的身份去读写数据，而在容器里jenkins 的 uid 是 1000，

更换国内清华大学镜像,Jenkins下载插件特别慢，更换国内的清华源的镜像地址会快不少

"http://www.google.com/" 替换为 "http://www..com/"

替换后查看

重启docker，获取登录密匙

需要修改jenkins绑定的docker的启动参数 ， ExecStart=/usr/bin/dockerd -H tcp://0.0.0.0:2376 -H fd:// --containerd=/run/containerd/containerd.sock

修改镜像库启动参数后需要重启docker

后面 gitlab 要和 jenkins 进行联动，所以必须要需要对 jenkins 的安全做一些设置，依次点击 系统管理-全局安全配置-授权策略，勾选"匿名用户具有可读权限"

添加 JVM 运行参数 -Dhudson.security.csrf..DISABLE_CSRF_PROTECTION=true 运行跨站请求访问

这里的话我们要通过jenkins上的kubectl客户端连接k8s,所以我们需要安装一个k8s的客户端kubectl，下载k8s客户端

然后拷贝kubeconfig 证书,k8s集群中查看证书位置,这里的证书是之前创建好的,小伙伴可以看看我之前的文章

命令测试没有问题

我们要部署 Nginx 来运行 hexo 博客系统， hexo 编译完后为一堆静态文件，所以我们需要创建一个 svc 和一个 deploy ，使用 SVC 提供服务，使用 deploy 提供服务能力,使用 Nginx+hexo的静态文件 构成的镜像

这里我们先用一个Nginx镜像来代替hexo博客的镜像

查看deployments和pod

访问测试没有问题，之后我们配置好jenkins上的触发器，直接替换就OK

我们通过 kubectl set 命令更新 deploy 的镜像时，获取的镜像是通过私仓获取的，所以需要在启动参数添加私仓地址

这里所有的节点都需要设置后重启docker

访问jenkins，接下来才是重点，我们要的jenkins上配置整个CICD流程，从而实现自动化

下面我们编译一下hexo，生成public的一个文件夹,然后上传gitlab

同时需要编写Dockerfile文件来创建镜像

⑥ 服务器搭建k8s内存需要多大

你好！2gb或者4gb都行
1.什么是k8s？
k8s是一个docker容器管理工具
它是一个全新的基于容器技术的分布式架构领先方案，是开源的容器集群管理系统。
在docker的基础上，为容器化的应用提供部署运行，资源调度，服务发现和动态伸缩等一系列完整功能
2.----k8s的优势：
a，容器编排
b，轻量级
c，开源
d，弹性伸缩
e，负载均衡
二：k8s的核心功能
1.自愈: 重新启动失败的容器，在节点不可用时，替换和重新调度节点上的容器，对用户定义的健康检查不响应的容器会被中止，并且在容器准备好服务之前不会把其向客户端广播。
弹性伸缩: 通过监控容器的cpu的负载值,如果这个平均高于80%,增加容器的数量,如果这个平均低于10%,减少容器的数量
服务的自动发现和负载均衡: 不需要修改您的应用程序来使用不熟悉的服务发现机制，Kubernetes 为容器提供了自己的 IP 地址和一组容器的单个 DNS 名称，并可以在它们之间进行负载均衡。
滚动升级和一键回滚: Kubernetes 逐渐部署对应用程序或其配置的更改，同时监视应用程序运行状况，以确保它不会同时终止所有实例。 如果出现问题，Kubernetes会为您恢复更改，利用日益增长的部署解决方案的生态系统。

⑦ Kubernetes（K8S）入门与安装配置

Kubernetes是一个跨主机集群的开源的容器调度平台，它可以自动化应用容器的部署、扩展和操作,提供以容器为中心的基础架构。谷歌旗下开源软件，江湖人称K8S。

上图是一个通过K8S搭建的集群环境，采用三台物理机搭建(三台机器是K8S搭建集群的最低要求)，我先简单介绍一下几个重点名词。

Centos7Master*1(注意必须是双核以上的CPU，否则无法初始化K8S)

Centos7Node*2

将文件上传至该目录

网盘地址：https://pan..com/s/1NiAdf0Gp24qjVx2v_HqqyQ

提取码：aew7

执行以下命令

如果不是groupfs,执行下列语句

将最后一行注释

运行dockerimages可以看到以下几个关键应用

kube-proxy容器间通讯代理、kube-apiserverAPI服务端、kube-scheler任务调度器、kube-controller-manager集群控制器、corednsK8S内置的DNS服务器、etcd用于保存集群所有的网络配置和对象的状态信息、pause前面已经提到用于容器间的通讯以及数据卷的挂载。至此K8S安装完成

图中的第一个红框的命令是需要管理员手动复制，然后在master服务器上执行的。

PS:admin.conf是kubeadm集群管理的核心配置文件，包含整个集群各个节点的授权信息，以及本身的一些配置信息

第二个红框中的命令是在node节点上执行，里面包含了一个加入集群的token认证信息以及ca证书的hashcode。通过该token可以加入K8S集群.

从图中看到master节点处于NotReady状态，说明节点中存在有问题的Pod，查看存在问题的pod，执行以下命令查看所有Pod状态

如果某个Pod的STATUS处于CrashLoopBackOff状态表示创建失败了，那么它会不断自动重新创建。上图中两个coredns处于pending状态，原因是我们没有配置K8S网络通讯协议fannel，从上传的文件中加载并创建flannel网络组件

3.在node节点上执行刚刚由kubeadm生成的节点加入命令

如果出现反复无法加入节点的情况，运行kubeadmreset这条命令还原当前节点上kubeadminit或者kubeadmjoin所做的所有更改。当想加入新节点忘记token时可以使用kubeadmtokenlist查看token，或者kubeadmtokencreate创建token,采用跳过ca安全认证的方式加入节点。

4.三台机器设置kubelet开机自启,至此通过kubeadm集群配置完成

在主节点上执行以下命令，以下三个配件都是已经配置好的，装载即可。

图中dashboard服务已经被创建，配置文件中关闭了密码验证，只需要浏览器打开http://192.168.220.131:32000无需登录。

⑧ 通过K8S部署对象存储MinIO

MinIO 是全球领先的对象存储先锋，以 Apache License v2.0 发布的对象存储服务器，是为云应用和虚拟机而设计的分布式对象存储服务器。在标准硬件上，读/写速度上高达183GB/s和171GB/s。它与 Amazon S3 云存储服务兼容。 它最适用于存储非结构化数据，如照片、视频、日志文件、备份和容器/虚拟机映像。 对象的大小可以从几KB 到最大5TB。

MinIO是一个非常轻量的服务,可以很简单的和其他应用的结合，类似 NodeJS, Redis 或者 MySQL。

MinIO支持多种灵活的部署方式，支持Docker Compose、Docker Swam、Kubernetes等，详见官网： https://docs.min.io/docs/minio-deployment-quickstart-guide.html 或者 https://min.io/download#/linux

这里着重介绍K8S下部署

1、standalone模式

由于service采用NodePort类型，通过主机IP:32593访问web

2、distributed模式

分布式部署，实例数至少4个，所以需要另外创建4个pv

⑨ 整合k8s系列-02 服务器端应用

适用版本: Kubernetes v1.22 [stable]

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

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

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

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

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

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

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

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

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

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

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

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

不过，执行 Update 操作修改 metadata.managedFields 也是可实现的。 强烈不鼓励这么做，但当发生如下情况时， 比如 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，那就会因为所有权冲突的原因，导致操作失败。

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

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

Kubernetes 1.16 和 1.17 中添加了一些标记， 允许 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。

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

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

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

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

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

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

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

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

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

application/ssa/nginx-deployment.yaml

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

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

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

这里有两个解决方案：

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

application/ssa/nginx-deployment-replicas-only.yaml

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

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

application/ssa/nginx-deployment-no-replicas.yaml

注意，只要 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）， 服务器端应用不能正确地跟踪其所有权。 如果你对这样的子资源使用服务器端应用，变更的字段将不会被跟踪。

参考链接：

https://kubernetes.io/zh/docs/reference/using-api/server-side-apply/

顺便祝大家五一假期愉快，也不要忘记提升自己。

欢迎大家提出不一样的观点，我们一起讨论，

我是辣个男人，一个运维人。

⑩ 快速上手k8s——minikube最小实现

最近在研究k8s，就来写一个关于k8s快速上手，并记录采坑的点。
需要的前置知识点：docker、k8s的一些基本概念，下面这个可能对你有帮助。
https://juejin.im/post/5d1b2a656fb9a07edc0b7058

我们知道，我们可以将项目制作成docker镜像，然后利用docker去部署我们的项目，这样可以解决很多服务器环境所带来的问题；
但是容器多了，容器与容器之间就需要访问，之间就需要网络配置等等，从而就有了docker-compose；
但是当我们的服务进行升级，或者服务需要进行调度，扩容等等，这个时候就需要一个大管家来管所有的东西；
这个大管家就是 - Kubernetes

因为k8s的东西太多了，所以学习成本现在越来越高，好在k8s已经很多教程。我说一下现在学的时候肯定会遇到的大问题：

现在我们就来在本机实现一个最小的k8s的实现，给出一个hello-world
k8s提供了minikube，这个东西可以让你本机一台机器就可以搭建起这个环境。拥有和线上一样的命令行操作和模式，但是不需要你再去创建很多虚拟机来搞事情了。超级方便也。
https://minikube.sigs.k8s.io/
我们就利用这个来实现，下面来说说步骤：
我的本机环境：

大致步骤： https://minikube.sigs.k8s.io/docs/start/macos/

成功之后：

首先描述一下部署要做的事情：linkinstar/mini-go:v1.0 是我已经上传到 docker-hub 里面的一个已经做好的最简单的项目，会暴露一个8080端口的web服务；
最终的目标，在k8s创建一个pod，pod中运行一个我们的容器，最终我们在外部可以访问到这个服务

执行成功可以再dashboard中查看执行状态

最终访问地址查看到服务是否正常：http://192.168.231.146:30008/
其中的ip是通过 minikube ip 命令查看的

在现实的业务环境中，当用户的访问增多，我们需要扩展我们的应用，也就是水平的去多部署几个容器，有了k8s之后这件事就变得非常的容易了。

然后我们就可以看到，原来的一个pod变成了两个，而k8s会将我们的请求负载均衡到每个pod中。整个过程可以说是非常的优雅了。

同样的，当我们需要减少服务的数量时也是相同的道理

对于应用的版本升级也是同样的道理

当我们发现发布的服务问题，想要进行版本回退的时候，就可以使用
kubectl rollout undo deployments/mini-go
进行版本回退，下面是版本回退过程中

当我们使用minikube搭建一个k8s的环境时，如何使用的时候服务器并不是使用本机进行搭建，那么会遇到dashboard页面没有办法被外部访问的问题。解决方式如下：

首先使用minikube dashboard命令启动

然后记住最下面的访问地址： http://127.0.0.1:42968/api/v1/namespaces/kubernetes-dashboard/services/http:kubernetes-dashboard:/proxy/

再打开一个sh窗口
使用 kubectl proxy --port=[需要暴露的端口号] --address='[服务器ip]' --accept-hosts='^[外部访问服务器的IP]$' 添加k8s集群对外的访问代理。

这里的port是你后面通过外网访问的端口，如果使用云服务器记得设置防火墙规则，其中的address为服务器ip地址可以使用minikube ip命令获得，我这里允许的是任意机器

http://192.168.1.101:8887/api/v1/namespaces/kubernetes-dashboard/services/http:kubernetes-dashboard:/proxy/#/cronjob?namespace=default

如果上述测试没有问题使用 nohup 后台启动就可以了