FLGB

1、进入到 Jenkins 的插件管理页面，搜索下载 DingTalk 插件，安装完毕插件记得重启 Jenkins。开发频繁发布代码，和测试没有及时沟通，导致测试返工、bug漏测等。Jenkins 集成DingDing机器人，在构建时触发推送。2、点击群右上角设置，点击【智能群助手】在job配置页，选择配置的钉钉机器人名称。1、在钉钉电脑端建立群聊。重启完成后，在系统管理页。注意配置的换行等格式，可。

【代码】Docker 容器指标搜集工具cAdvisor。

配置好git地址、账号凭证、远程执行token、打通jinkens服务器到目标服务器免密传输 等。

配置后可以支持远程触发jenkins构建（比如自建的CICD自动化发布平台），不需要远程构建的可以不配置。// 服务的地址+8090 根据nginx配置对应转发到真实的ip中。选择部署运行的节点标签，dev标签对应开发环境。在项目package.json同级目录下创建。

v /docker/mysql/data:/var/lib/mysql \ 将日志文件夹挂载到主机。-v /docker/mysql/log:/var/log/mysql \ 将配置文件夹挂载到主机。-v /docker/mysql/conf:/etc/mysql \ 将配置文件夹挂载到主机。-e MYSQL_ROOT_PASSWORD=123 \ 初始化root的密码。-p 3306:3306 将容器的端口号3306映射到主机的3306端口号。–name 镜像命名。

检查节点的网络连接，确保它能正常访问控制平面和其他节点。确保控制平面的关键组件（如 API Server、Controller Manager、Scheduler）正常运行，因为这些组件的问题也可能导致节点状态异常。状态可能是由于多种原因引起的，尤其是在资源过量分配（overcommitment）时，常见的原因包括节点资源（CPU、内存）不足、关键组件失败、磁盘压力等。首先，检查节点的资源使用情况，以确定是否由于资源过度使用导致节点不可用。可以看到节点内存、磁盘等信息状态都是未知的，初步怀疑节点状态已经。

使用上述命令生成的自签名证书 k8s.test.crt 和私钥 k8s.test.key 是自签名的证书，其安全性在开发或测试环境中通常是可以接受的，但不会被主流浏览器（如Chrome、Firefox、Edge等）视为安全，因为它们未经公共颁发机构（CA）的认证和签名。在开发或测试环境中，可以使用这样的自签名证书来进行测试和开发工作。它生成的是一个 X509 格式的证书，有效期 365 天，私钥是 RSA2048 位，摘要算法是 SHA256，签发的网站是“k8s.test”。

Ingress 使用的是 HTTP 路由规则，用 IP 地址访问是无效的，所以在集群外的主机上必须能够识别我们的“wp.test”域名，也就是说要把域名“wp.test”解析到 Ingress Controller 所在的节点上。Mac，那就修改 /etc/hosts；【wp连接db配置】

当它发现目标的 CPU 使用率超过了预定的 5% 后，就会以 2 的倍数开始扩容，一直到数量上限，然后持续监控一段时间，如果 CPU 使用率回落，就会再缩容到最小值。Metrics Server 是一个专门用来收集 Kubernetes 核心资源指标（metrics）的工具，它定时从所有节点的 kubelet 里采集信息，但是对集群的整体性能影响极小，每个节点只大约会占用 1m 的 CPU 和 2MB 的内存，所以性价比非常高。”，简称是“hpa”。

它可以把集群切分成一个个彼此独立的区域，然后我们把对象放到这些区域里，就实现了类似容器技术里 namespace 的隔离效果，应用只能在自己的名字空间里分配资源和运行，不会干扰到其他名字空间里的应用。它设置了每个容器默认申请 0.2 的 CPU 和 50MB 内存，容器的资源上限是 0.5 的 CPU 和 100MB 内存，每个 Pod 的最大使用量是 0.8 的 CPU 和 200MB 内存。有了名称空间，就可以像管理容器一样，给名字空间设定配额，把整个集群的计算资源分割成不同的大小，按需分配使用。

就意味着 Pod 对运行的资源要求“既没有下限，也没有上限”，Kubernetes 不用管 CPU 和内存是否足够，可以把 Pod 调度到任意的节点上，而且后续 Pod 运行时也可以无限制地使用 CPU 和内存。Kubernetes 为了能更细致地监控 Pod 的状态，除了保证崩溃重启，还必须要能够探查到 Pod 的内部运行状态，定时给应用做“体检”，让应用时刻保持“健康”，能够满负荷稳定工作。配置用于设置容器的资源请求和限制，以确保集群中的资源（如 CPU 和内存）得到合理分配和使用。

kubectl rollout undo 的操作过程其实和 kubectl apply 是一样的，执行的仍然是“滚动更新”，只不过使用的是旧版本 Pod 模板，把新版本 Pod 数量收缩到 0，同时把老版本 Pod 扩展到指定值。可以看到，Pod 名字里的那串随机数“6796……”是没有变化的，变化的是数字后面的pod编号的随机字符。在 Kubernetes 里应用都是以 Pod 的形式运行的，而 Pod 通常又会被 Deployment 等对象来管理，所以应用的“版本更新”实际上更新的是整个 Pod。

在 StatefulSet 里的这两个 Pod 都有了各自的域名，也就是稳定的网络标识。那么接下来，外部的客户端只要知道了 StatefulSet 对象，就可以用固定的编号去访问某个具体的实例了，虽然 Pod 的 IP 地址可能会变，但这个有编号的域名由 Service 对象维护，是稳定不变的。PVC 的命名，不是随机的，是有规律的，用的是 PVC 名字加上 StatefulSet 的名字组合而成，所以即使 Pod 被销毁，因为它的名字不变，还能够找到这个 PVC，再次绑定使用之前存储的数据。

PV/PVC 里指定了 storageClassName 是 nfs，节点上也安装了 NFS 客户端，所以 Kubernetes 就会自动执行 NFS 挂载动作，把 NFS 的共享目录 /tmp/nfs/1g-pv 挂载到 Pod 里的 /tmp，完全不需要去手动管理。在 NFS 服务器的 /tmp/nfs 目录里又创建了一个新的目录 1g-pv，表示分配了 1GB 的可用存储空间，相应的，PV 里的 capacity 也要设置成同样的数值，也就是 1Gi。

给 NFS 指定一个存储位置，也就是网络共享目录。NFS 服务器，检查共享目录 /tmp/nfs，应该会看到也出现了一个同样的文件 x.yml,说明 NFS 安装成功了。在节点上可以用 showmount 检查 NFS 能否正常挂载，注意 IP 地址要写成 NFS 服务器的地址。

作为存储的抽象，PV 实际上就是一些存储设备、文件系统，比如 Ceph、GlusterFS、NFS，甚至是本地磁盘，管理它们已经超出了 Kubernetes 的能力范围，所以，一般会由系统管理员单独维护，然后再在 Kubernetes 里创建对应的 PV。PVC 是给 Pod 使用的对象，它相当于是 Pod 的代理，代表 Pod 向系统申请 PV。Pod 里的容器是由镜像产生的，而镜像文件本身是只读的，进程要读写磁盘只能用一个临时的存储空间，一旦 Pod 销毁，临时存储也就会立即回收释放，数据也就丢失了。

Ingress 使用的是 HTTP 路由规则，用 IP 地址访问是无效的，所以在集群外的主机上必须能够识别我们的“wp.test”域名，也就是说要把域名“wp.test”解析到 Ingress Controller 所在的节点上。WordPress 是中间的应用服务器，使用 MariaDB 来存储数据，它的端口是 80；因为 WordPress 的 Service 对象是 NodePort 类型的，我们可以在集群的每个节点上访问 WordPress 服务。比如一个节点的 IP 地址是。

同样的，Ingress 也只是一些 HTTP 路由规则的集合，相当于一份静态的描述文件，真正要把这些规则在集群里实施运行，还需要有另外一个东西，这就是 Ingress Controller，它的作用就相当于 Service 的 kube-proxy，能够读取、应用 Ingress 规则，处理、调度流量。Service 比较适合代理集群内部的服务。和Service 对比，虽然都是把请求转发到了集群内部的 Pod，但 Ingress 的路由规则不再是 IP 地址，而是 HTTP 协议里的域名、URI 等要素。

kubectl scale 是命令式操作，扩容和缩容只是临时的措施，如果应用需要长时间保持一个确定的 Pod 数量，最好还是编辑 Deployment 的 YAML 文件，改动“replicas”，再以声明式的 kubectl apply 修改对象的状态。这些业务如果用 Deployment 来部署就不太合适了，因为 Deployment 所管理的 Pod 数量是固定的，而且可能会在集群里“漂移”，但，实际的需求却是要在集群里的每个节点上都运行 Pod，也就是说 Pod 的数量与节点数量保持同步。

指定了 Pod 的地址段是“10.244.0.0/16”，service的地址是 10.96.0.0/12 ，apiserver 的服务地址是“自己机器的ip”，Kubernetes 的版本号是“1.23.3”minikube 还是太“迷你”了，方便的同时也隐藏了很多细节，离真正生产环境里的计算集群有一些差距，毕竟许多需求、任务只有在多节点的大集群里才能够遇到，相比起来，minikube 真的只能算是一个“玩具”。完成之后，最好记得重启一下系统，然后给虚拟机拍个快照做备份，避免后续的操作失误导致重复劳动。

对于明文配置数据， COUNT、GREETING 引用的是 ConfigMap 对象，所以使用字段“configMapKeyRef”，里面的“name”是 ConfigMap 对象的名字，也就是之前我们创建的“info”，而“key”字段分别是“info”对象里的 count 和 greeting。Volume 的定义之后，就可以在容器里挂载了，这要用到“volumeMounts”字段，正如它的字面含义，可以把定义好的 Volume 挂载到容器里的某个路径下，所以需要在里面用“

YAML（YAML Ain’t Markup Language）是一种可读的数据序列化语言，通常用于配置文件、数据序列化和交换格式。YAML 的设计目标是易读易写，并且能够映射到动态语言中的数据结构YA加粗样式ML 是JSON的超集，支持整数、浮点数、布尔、字符串、数组和对象等数据类型。也就是说，任何合法的 JSON 文档也都是 YAML 文档使用空白与缩进表示层次（有点类似 Python），可以不使用花括号和方括号。可以使用书写注释，比起 JSON 是很大的改进。

当集群的规模较小，工作负载较少的时候，Master 也可以承担 Node 的工作，就像我们搭建的 minikube 环境，它就只有一个节点，这个节点既是 Master 又是 Node。是 Master 节点——同时也是整个 Kubernetes 系统的唯一入口，它对外公开了一系列的 RESTful API，并且加上了验证、授权等功能，所有其他组件都只能和它直接通信，可以说是 Kubernetes 里的联络员。的数量非常多，构成了一个资源池，Kubernetes 就在这个池里分配资源，调度应用。

它就会把与当前 Kubernetes 版本匹配的 kubectl 下载下来，存放在内部目录（例如 .minikube/cache/linux/arm64/v1.23.3），然后我们就可以使用它来对 Kubernetes“发号施令”了。kubectl 的作用有点类似“docker”，它也是一个命令行工具，是与 Kubernetes 后台服务通信，把我们的命令转发给 Kubernetes，实现容器和集群的管理功能。起码要2核4g的机器。

通过将这两个目录添加到 PATH 中，可以方便地在命令行中直接执行 nginx 命令来启动或管理 Nginx 服务器，而不必输入完整的路径。.log 路径下的日志文件，用于收集 Spring Boot Admin 应用的日志；如果要采集nginx的日志的话需要设置nginx日志格式。在**filebeat.inputs:**新增一个log。设置命令行中执行 Nginx 相关的命令时不输入完整路径。在**indices:**下新增一个index。安装docker容器。

如果说容器就是“小板房”，镜像就是“样板间”。那么，要造出这个“样板间”，就必然要有一个“施工图纸”，由它来规定如何建造地基、铺设水电、开窗搭门等动作。这个“施工图纸”就是“Dockerfile”。比起容器、镜像来说，Dockerfile非常普通，它就是一个纯文本，里面记录了一系列的构建指令，比如选择基础镜像、拷贝文件、运行脚本等等，每个指令都会生成一个 Layer，而 Docker 顺序执行这个文件里的所有步骤，最后就会创建出一个新的镜像出来。

每个 server 块都配置了独立的 SSL 证书，并将请求代理到不同的服务端口。例如，假设你有两个服务，一个服务运行在 6087 端口，另一个服务运行在 6088 端口，并且你希望分别使用 service1.example.com 和 service2.example.com 来访问它们，你可以这样配置。需要注意的是，所有的 server 块都监听了相同的端口（443），但每个 server 块的 server_name 不同，因此 Nginx 可以根据请求的域名来选择匹配的 server 块进行处理。

docker运行nginx镜像时，设置端口映射，则只有该映射端口起作用，nginx配置的其他端口无效。所以想要多个端口起效果，启动时要用–net host （先删除容器后重新生成），并且修改配置文件中的root路径，再次访问成功加载首页。docker下的nginx只能读到挂载路径下面的文件（到对应目录下查看文件已经存在了（划红线的）删除成功后，重新生成容器并进行目录挂载映射。我们拉去1.24.0的nginx镜像。在对应挂在目录下创建监听文件。

yum 是一个包管理器，用于在基于 RPM 包管理系统的 Linux 发行版上安装、升级和移除软件包。上面命令是在系统中移除 podman 和 buildah 这两个软件包。podman 是一个用于管理容器和容器镜像的工具，类似于 Docker。(有client和service两部分表示docker安装启动都成功了)buildah 是一个用于构建容器镜像的工具，也类似于 Docker。erase 是 yum 命令的一个操作选项，表示移除指定的软件包。执行如下命令，一路y即可。

注意文件命名(如果命名Dockerfile，构建时是不需要制定名称的，docker会默认加载此名称的文件)=“nginx” 和 ARG IMAGE_TAG=“1.21-alpine”：定义了两个构建参数，用于指定基础镜像的名称和标签。FROMIMAGEBASEIMAGEB​ASE{IMAGE_TAG}：使用 FROM 指令指定了基础镜像，${IMAGE_BASE} 和 ${IMAGE_TAG} 是在构建过程中根据构建参数动态替换的变量。