九师兄

Prometheus Query Language（PromQL）是用于查询和分析Prometheus监控数据的查询语言。它是Prometheus系统的一部分，被设计用于从时间序列数据库中提取和处理指标数据。

KubeSphere 为日志收集、查询和管理提供了一个强大的、全面的、易于使用的日志系统。它涵盖了不同层级的日志，包括租户、基础设施资源和应用。用户可以从项目、工作负载、容器组和关键字等不同维度对日志进行搜索。这些组件设计成了可插拔式，您可以在安装之前或之后启用它们。与Kibana 相比，KubeSphere 基于租户的日志系统中，每个租户只能查看自己的日志，从而可以在租户之问提供更好的隔离性和安全性。除了 Kubesphere 白身的日志系统，该容器平。不同的可插拔组件部署在不同的命名空问中。

服务网格是用于处理服务间通信的专用基础设施层，它负责通过包含现代云原生应用程序的复杂服务拓扑来可靠地传递请求。实际上，服务网格通常通过一组轻量级网络代理来实现，这些代理与应用程序代码一起部署，而不需要感知应用程序本身。

Helm是Kuberetes的包管理器。类似于Ubuntu的arit-get, Centos的yum，用于管理Charts。Helm Chart是用来封装Kubernetes应用程序的一系列YAML文件在上下载二进制文件。

目的本课程通过定向调度策略将应用部署在指定的宿主机上。场景在实际环境中，不同的服务会对资源有不同的要求，根据实际需求，我们需要将这些应用部署到特定的服务器，从而提升服务性能和服务器资源使用率。

在实际工作中，可能某个 Worker 节点需要维护、迁移，我们需要平滑的停止、启动该节点，尽量减少启停中对集群、业务造成的影响。本章节通过演示停止、启动 Master 节点的过程，说明 Master 节点启停过程和注意事项，便于日常节点维护或资源回收。在实际工作中，可能某个 Master 节点需要维护、迁移，我们需要平滑的停止、启动该节点，尽量减少启停中对集群造成的影响。摘除 Worker 节点操作中，该Worker 节点上的工作负载将被驱逐到其他节点上，请确保集群资源充定。到节点上启动相关的服务。

可以看到证书过期还有364天，如果证书过期了，我们该怎么处理呢？集群证书默认位置，我们只需要把证书放到这个位置就好了。

比如原先我们有2个节点，现在我们要新增一个节点，那么只需要在配置文件中添加一行就好了。可以看到新的节点就出来了。

上节课我们根据kubekey创建了2种集群，我们是修改了配置文件的。本章主要讲解这个配置文件。下面这个是负载均衡配置的两种模式，具体可以参考domain就是域名，这个要写到/etc/hosts文件中的。然后下面就是k8s版本配置，以及网络配置，这里我们使用calico就可以了下面是镜像的私有配置这个命令其实可以一键把KubeSphere也部署起来的，使用如下命令会生成k8s和KubeSphere的配置文件这是配置的一小部分截图在中有更加详细的配置。

单机和多机部署模式Kubernetes 高可用集群部署有2种方式我们知道k8s集群可以部署在物理机、虚拟机、云环境，下图是k8s的基本架构图这里包含控制平面就是master节点，然后worker节点，以及Etcd。在Control Plane需要部署是哪个基本服务，然后在Worker节点也要部署一些基本服务。除此之外，我们可能需要部署一些外部服务，比如LoadBalancer可以给我们提供负载均衡的能力。

因为Mongodb 是与状态服务，所以他是有存储卷的。本次我们使用新的部署方式。可以关掉账号密码的访问。可以看到相关的访问信息。然后我们就能远程连接了。

这个镜像docker hub上面可能没有，因此我们可以自己推上去。后面什么都不要选，直接下一步，下一步就好了。我们可以创建一个服务验证一下。

首先我们看一下我们的微服务，里面有我们的nacos配置，需要都改一下，改成线上的。

在上一节我们把RuoYi-Cloud 项目都打包成镜像了，并且保存了，怎么把镜像放到阿里云呢?这里注意4个星号要换成我们的用户名，然后输入密码就好了。下面是案例，可以看到改名后名称不一样，id是相同的。这里第二个步骤是修改名称，因为要符合别人的规范。然后我们就可以推送镜像了。然后选择个人实例，不要选企业，企业是收费的。然后我们可以专门为本次创建一个命名空间。登录阿里云，找到阿里云容器镜像服务。因为是阿里云，所以我们需要登录。开通之后我们首先有命名空间。推送完成后就有了我们的镜像。

在上一篇文章中我们跑通了项目。但是却是本地的，如果我们想在云上该怎么办呢？那么我们需要思考几个点？首先要思考，我们有多少个中间件，因为中间件是有状态的服务，需要数据的初始化。然后是我们的微服务，我们要以无状态的服务去部署，并且要自己制作镜像。然后是微服务的访问地址等，怎么固定下来，防止pod重建导致服务无法连接。最后是配置。

相比单节点配置，nacos集群配置多了一个，配置集群配置文件在nacos的解压目录nacos/的conf目录下，有配置文件cluster.conf，请每行配置成ip:port。（请配置3个或3个以上节点）但是这样最大的问题来了，一旦我们上云，上云后我们部署了3个Pod，假设我们有10台机器，然后某一天pod挂了，然后转移到其他机器，一旦发生故障转移，那么pod地址可能就变化了，所以我们要部署有状态服务，然后ip地址变化无所谓，但是域名要是不变化的。所以到时候我们写的不是域名是，固定的域名。

例如，使用 Kafka 的命令行工具之一，如 kafka-console-producer 或 kafka-console-consumer，来尝试连接到 Kafka 服务。如果上述步骤中仍然无法解决问题，你可能需要检查防火墙设置、网络策略（Network Policies）、以及 Kubernetes 集群的网络配置，确保流量可以流通到你的 Kafka 服务。我有一个kubernetes集群，然后里面有三个kafka节点，现在我想本地远程连接Kafka测试，因此需要我打开远程端口。

最开始我们使用的是微服务的形式提供服务，每个组织负责一小块功能。每个组织都有自己的管理单元。都有相关的数据，项目是内聚的。团队层面：內聚,独立开发业务,没有依赖产品层面：服务彼此独立,独立部署,没有依赖大规模微服务网络层面必将成为致命短板比如我们的服务规模超大，哪个这个拓扑图就很复杂。

Keepalived是一个基于VRRP协议来实现的服务高可用方案。VRRP协议(虛拟路由冗余协议–Virtual Router Redundancy Protocol， 简称VRRP），是由IETF提出的解决局域网中配置静态网关出现单点失效现象的路由协议，1998年已推出正式的RFC2338协议标准。VRRP广泛应用在边缘网络中，它的设计目标是支持特定情况下IP数据流量失败转移不会引起混乱，允许主机使用单路由器，以及即使在实际第一跳路由器使用失败的情形下仍能够维护路由器间的连通性。

下载完毕后如下系统模块。

我以前使用docker安装ElasticSearch的时候，指定端口、名称、日志目录、数据目录、配置文件、密码信息等信息首先是环境变量配置，因为这个key是有点的，比较特殊，因此需要双引号引起来，设置Elasticsearch的发现类型为单节点。这意味着Elasticsearch将作为单节点运行。第二个是java环境变量这个是数据配置，将一个名为es-config的卷挂载到容器中的/usr/share/elasticsearch/config目录。这是用来存储Elasticsearch的配置文件的。

我以前使用docker安装Redis的试试，指定端口、名称、日志目录、数据目录、配置文件、密码信息登。

我们如果想做配置，可以在下面的地方创建配置，然后内容是以key 和value的形式展示，这个key是文件名称,value是整个文件内容。首先是Pod，然后Pod里面是我们的MySQL 官方镜像，然后在容器内指定一个环境变量是MYSQL的密码。相比于docker部署MySQL，如果我们使用KubeSphere部署MySQL，那么应该是这样的？MySQL的数据我们以PVC的方式挂在出来，然后配置文件可以以ConfigMap的方式提供。首先我们要想清楚，如果我们在云上部署应用，那么我们的应用应该以什么模式部署？

这里我们可以参考官网来进行安装，准备三台服务器设置三台机器的hostname。

centos7.9；防火墙放行 30000~32767；指定hostname。这里我们可以参考官网。这里我们可以使用这种。

首先我们要初始化我们的机器，使其扩容。具体要求如下我们先把主节点升级到4核8G然后同理将其他节点调整成 8核16G，替换完成后如图。

Kubernetes 中的 Secret 对象类型用于存储和管理敏感信息，如密码、API 密钥和其他敏感数据。Secret 对象提供了一种安全地存储和传递这些敏感信息的方式，以供 Pod 使用。总的来说，Kubernetes 中的 Secret 对象为处理敏感信息提供了一种安全可靠的机制，帮助用户管理和使用与应用程序相关的私密数据。

ConfigMap可以实现抽取应用配置，并且自动更新在Kubernetes中，ConfigMap是一种用于存储非机密性配置数据的API对象。它可以用来存储配置信息，例如环境变量、命令行参数、配置文件等。ConfigMap提供了一种将配置数据与应用程序代码分离的方式，使得应用程序更加灵活和可配置。适合什么场景ConfigMap适用于需要将配置信息与应用程序代码解耦的场景，特别是在容器化的环境中。

PV：持久卷Persistent Vvolume），将应用需要特久化的数据保存到指定位置【相当于真正存储位置】PVC：持久卷申明 Persistent Volume Claim ），中明需要使用的持久卷规格【相当于存储的申请说明书，比如1M空间】在 Kubernetes 中，PV（Persistent Volume）和 PVC（Persistent Volume Claim）是用于持久化存储的两个重要概念。它们允许你在容器化应用中使用持久化存储，使数据在 Pod 重启或迁移时仍然可用。

我们想做抽象存储案例，但是却需要先装一个NFS网络文件系统，因此本章我们来装NFS网络文件系统。

但是这个会面临一个严重的问题，如果某个pod挂了，那么k8s会自动重新再其他机器创建这个pod，然后我们的数据就对不上了，比如我在nodeA创建了一个本地文件aa.txt,然后pod挂掉之后，k8s在nodeB创建了新的Pod，此时新的Pod本地是没有aa.txt文件了。我们把所有的凌乱的东西都统一起来，这就是存储层，存储层的主要功能就是将所有的Pod与存储关联起来，就算Pod重建后，指向的仍然是一个存储地址。所以我们一般情况下，会把pod的存储挂到外面，比如下面的图示。新的Pod本地是没有数据的。

Ingress是Service的统一入口。

这个是每个机器都开了一个端口30948，这意味这我们访问每一台都是可以的。service给我们开通的ip是10.96.109.130，端口是30948。在上一篇文章中我们学会了在容器之间如何暴露端口，但是外网是不能访问的，pod之间是可以访问的。然后我们使用这些ip发现可以远程访问，而且还会自动的负载均衡，也说明走了service。我们先查看我们的云服务器ip信息如下。下面我们准备暴露这个端口，这里注意我们指定了。因为我们使用的是云机器，所以我们要开通安全组。我们先看看我们之前的设置如下。

我们可以访问看看,但是这三个Nginx的首页都是一样的，不好区分，为了方便后面的测试，修改下三台nginx的index.html页面（三台修改的IP地址不一致）可以看到这里有个ip信息,然后我们访问这个，可以看到每次的的主页信息都不一致，这是因为默认做了轮训处理。现在我们暴露这个service端口和ip,这里暴露访问外面的8000，就是访问我们的80端口。下面我们给三个nginx的主页都换成一下。这里可以看到我们刚刚暴露的service。可以看到我们的标签是nginx。查看我们的nginx。

总的来说，Deployment用于无状态应用程序的部署，StatefulSet用于有状态应用程序的部署，DaemonSet用于在每个节点上运行Pod，Job用于一次性或短暂性任务，而CronJob用于定期执行任务。在Kubernetes中，Deployment、StatefulSet、DaemonSet、Job和CronJob都是不同类型的控制器（Controller），它们用于管理Pod的生命周期，但它们有不同的用途和行为。用途： 用于确保集群中的每个节点运行一个Pod的场景，如日志收集或网络代理。

假设你有一个 Deployment，它运行了一个叫做 myapp 的容器，使用的是 myapp-image:old 的镜像。现在你想要将它更新到新版本的 myapp-image:new。在 Kubernetes 中，滚动更新是通过逐步替换旧版本的 Pod 为新版本来实现的。这是一个简单的滚动更新案例。在实际生产环境中，你可能还需要考虑一些其他因素，例如滚动更新的策略、健康检查、回滚策略等，以确保更新的顺利进行。这将显示滚动更新的状态，包括当前的 ReplicaSet 和更新进度。

Kubernetes 中的扩容和缩容通常是通过调整 Deployment 中的副本数量来实现的。下面是一个简单的案例，演示如何在 Kubernetes 中进行扩容和缩容。创建一个deploy-nginx.yaml 文件使用这个命令使其生效可以看到我们现在有2个节点运行我们的pod。因为我们初始副本数量为 2。

1.背景mac安装Kubernetes后登录报错 【Docker】Mac下Docker启动Kubernetes给匿名用户授权即可解决，测试环境可用此快速解决(base) lcc@lcc kubernetes$ kubectl create clusterrolebinding test:anonymous --clusterrole=cluster-admin --user=system:anonymousclusterrolebinding.rbac.authorization.k8s.io/.

在 Kubernetes 中，创建 Pod 时可以通过 YAML 配置文件或者命令行参数指定所属的 Namespace。如果你是通过命令行使用 kubectl 来创建 Pod，可以使用 -n 或 --namespace 参数来指定 Namespace。在 Pod 的 YAML 配置文件中，你可以通过 metadata.namespace 字段指定所属的 Namespace。在上述的 YAML 文件中，Pod 将会被创建在 mynamespace 这个 Namespace 中。

在上一篇文章中我们进行了集群的购买初始化等工作。本章节我们进行kubernetes集群化安装。