Carroll的博客

Kubernetes 本身，实际上是不会为你做容器日志收集工作的，所以为了实现上述 cluster-level-logging，你需要在部署集群的时候，提前对具体的日志方案进行规划。

kubelet 的工作核心，就是一个控制循环，即：SyncLoop 。而驱动这个控制循环运行的事件，包括四种：Pod 更新事件；Pod 生命周期变化；kubelet 本身设置的执行周期；定时的清理事件。所以，跟其他控制器类似，kubelet 启动的时候，要做的第一件事情，就是设置 Listers，也就是注册它所关心的各种事件的 Informer。这些 Informer，就是 SyncLoop 需要处理的数据的来源。

在实际的使用中，强烈建议你将 DaemonSet 的 Pod 都设置为 Guaranteed 的 QoS 类型。否则，一旦 DaemonSet 的 Pod 被回收，它又会立即在原宿主机上被重建出来，这就使得前面资源回收的动作，完全没有意义了。

Kubernetes 调度器里其实还有一些默认不会开启的策略。你可以通过为 kube-scheduler 指定一个配置文件或者创建一个 ConfigMap ，来配置哪些规则需要开启、哪些规则需要关闭。并且，你可以通过为 Priorities 设置权重，来控制调度器的调度行为。当开始调度一个 Pod 时，Kubernetes 调度器会同时启动 16 个 Goroutine，来并发地为集群里的所有 Node 计算 Predicates，最后返回可以运行这个 Pod 的宿主机列表。

【代码】深入剖析Kubernetes之基于角色的权限控制(RBAC)

举个例子，假如现在有这样一个站点：https://cafe.example.com。其中，https://cafe.example.com/coffee，对应的是“咖啡点餐系统”。而，https://cafe.example.com/tea，对应的则是“茶水点餐系统”。然后，通过我访问的 URL，把请求转发给不同的后端 Service。所以，Ingress 的功能其实很容易理解：所谓 Ingress，就是 Service 的“Service”。

可以看到，这幅示意图中，IP 包“一进一出”的两条路径上，有几个关键的“检查点”，它们正是 Netfilter 设置“防火墙”的地方。在 Linux 内核的实现里，所谓“检查点”实际上就是内核网络协议栈代码里的 Hook（比如，在执行路由判断的代码之前，内核会先调用 PREROUTING 的 Hook）。host-gw 模式的工作原理，其实就是将每个 Flannel 子网（Flannel Subnet，比如：10.244.1.0/24）的“下一跳”，设置成了该子网对应的宿主机的 IP 地址。

而网络插件则在宿主机上创建了一个特殊的设备（UDP 模式创建的是 TUN 设备，VXLAN 模式创建的则是 VTEP 设备），docker0 与这个设备之间，通过 IP 转发（路由表）进行协作。网络插件真正要做的事情，则是通过某种方法，把不同宿主机上的特殊设备连通，从而达到容器跨主机通信的目的。Flannel UDP 模式提供的其实是一个三层的 Overlay 网络，即：它首先对发出端的 IP 包进行 UDP 封装，然后在接收端进行解封装拿到原始的 IP 包，进而把这个 IP 包转发给目标容器。

Kubernetes 项目中一个重要的设计思想：控制器模式。

这个 Volume Controller 维护着多个控制循环，其中有一个循环，扮演的就是撮合 PV 和 PVC 的“红娘”的角色。PVC 可以理解为持久化存储的“接口”，它提供了对某种持久化存储的描述，但不提供具体的实现；而这个持久化存储的实现部分则由 PV 负责完成。Kubernetes 只会将 StorageClass 相同的 PVC 和 PV 绑定起来。Kubernetes 中，存在着一个专门处理持久化存储的控制器，叫作。PVC 和 PV 的设计，其实跟“面向对象”的思想完全一致。

首先，所谓“声明式”，指的就是我只需要提交一个定义好的 API 对象来“声明”，我所期望的状态是什么样子。其次，“声明式 API”允许有多个 API 写端，以 PATCH 的方式对 API 对象进行修改，而无需关心本地原始 YAML 文件的内容。最后，也是最重要的，有了上述两个能力，Kubernetes 项目才可以基于对 API 对象的增、删、改、查，在完全无需外界干预的情况下，完成对“实际状态”和“期望状态”的调谐（Reconcile）过程。

Deployment、StatefulSet，以及 DaemonSet 这三个编排概念。它们主要编排的对象，都是“在线业务”，即：Long Running Task（长作业）。比如，常用的 Nginx、Tomcat，以及 MySQL 等等。这些应用一旦运行起来，除非出错或者停止，它的容器进程会一直保持在 Running 状态。而在 Deployment 对象里，restartPolicy 则只允许被设置为 Always。

在 Kubernetes 项目里，ControllerRevision 其实是一个通用的版本管理对象。这样，Kubernetes 项目就巧妙地避免了每种控制器都要维护一套冗余的代码和逻辑的问题。DaemonSet 其实是一个非常简单的控制器。在它的控制循环中，只需要遍历所有节点，然后根据节点上是否有被管理 Pod 的情况，来决定是否要创建或者删除一个 Pod。

得益于“控制器模式”的设计思想，Kubernetes 项目很早就在 Deployment 的基础上，扩展出了对“有状态应用”的初步支持。这个编排功能，就是：StatefulSet。StatefulSet 的设计其实非常容易理解。它把真实世界里的应用状态，抽象为了两种情况：拓扑状态。这种情况意味着，应用的多个实例之间不是完全对等的关系。这些应用实例，必须按照某些顺序启动，比如应用的主节点 A 要先于从节点 B 启动。

而一个应用的版本，对应的正是一个 ReplicaSet；这个版本应用的 Pod 数量，则由 ReplicaSet 通过它自己的控制器（ReplicaSet Controller）来保证。通过这样的多个 ReplicaSet 对象，Kubernetes 项目就实现了对多个“应用版本”的描述。将一个集群中正在运行的多个 Pod 版本，交替地逐一升级的过程，就是“滚动更新”。

把 Kubernetes 客户端以容器的方式运行在集群里，然后使用 default Service Account 自动授权的方式，被称作“InClusterConfig”，也是最推荐的进行 Kubernetes API 编程的授权方式。Kubernetes 项目的 Projected Volume 其实只有三种，因为第四种 ServiceAccountToken，只是一种特殊的 Secret 而已。认真体会Kubernetes“一切皆对象”的设计思想。

Pod 对象的 Status 字段，还可以再细分出一组 Conditions。这些细分状态的值包括：PodScheduled、Ready、Initialized，以及 Unschedulable。Pod 的这些状态信息，是我们判断应用运行情况的重要标准，尤其是 Pod 进入了非“Running”状态后，一定要能迅速做出反应，根据它所代表的异常情况开始跟踪和定位。Pod 生命周期的变化，主要体现在 Pod API 对象的Status 部分，这是它除了 Metadata 和 Spec 之外的第三个重要字段。

容器，就是未来云计算系统中的进程；容器镜像就是这个系统里的“.exe”安装包。那么 Kubernetes 呢？Kubernetes 就是操作系统！pstree -g这条命令的作用，是展示当前系统中正在运行的进程的树状结构。它的返回结果如下所示：在一个真正的操作系统里，进程并不是“孤苦伶仃”地独自运行的，而是以进程组的方式，“有原则地”组织在一起。比如，这里有一个叫作 rsyslogd 的程序，它负责的是 Linux 操作系统里的日志处理。

Kubernetes 项目所擅长的，是按照用户的意愿和整个系统的规则，完全自动化地处理好容器之间的各种关系。Kubernetes 项目要着重解决的问题：运行在大规模集群中的各种任务之间，实际上存在着各种各样的关系。Kubernetes 项目在 Borg 体系的指导下，体现出了一种独有的“先进性”与“完备性”，而这些特质才是一个基础设施领域开源项目赖以生存的核心价值。除了应用与应用之间的关系外，应用运行的形态是影响“如何容器化这个应用”的第二个重要因素。，用来描述一次性运行的 Pod（比如，大数据任务）；

容器其实是一种沙盒技术。顾名思义，沙盒就是能够像一个集装箱一样，把你的应用“装”起来的技术。这样，应用与应用之间，就因为有了边界而不至于相互干扰；而被装进集装箱的应用，也可以被方便地搬来搬去，这不就是 PaaS 最理想的状态嘛。

Docker Volume就像是汽车的油箱, 如果把容器间内的io数据流比喻成汽油,Docker container(容器)类似于汽车的零部件，Docker Swarm(或者K8s)就是交通枢纽。Docker Registry可以看作是4s店，Docker image(镜像)就是汽车样板，用户才是项目和技术的衣食父母，脱离群众要不得.Docker Compose就像老司机,Dockerfile相当于汽车蓝图，Docker好比汽车引擎，

流水线的五个阶段：拉取源码 -> 构建源码 -> 构建镜像->推送镜像 -> 部署项目在图形编辑面板上，从类型下拉列表中选择 node，从 Label 下拉列表中选择 maven。请点击左侧的加号图标来添加阶段。点击添加步骤上方的文本框，然后在右侧的名称字段中为该阶段设置名称。点击添加步骤。在列表中选择 git，以从 GitLab 拉取项目代码。在弹出的对话框中，填写必需的字段。点击确定完成操作。下面两条命令参考上面命令依次添加输入。VUE前端你知道的越多，你不知道的越多。

具体步骤：微服务架构图拉取仓库代码编译代码编写gateway服务的DockerFile，制作镜像编写完成的DockerFile放置的文件位置之前本地部署的镜像仓库Harbor: ，如果没有可拿docker-hub注册一个账号。登录仓库其他模块编写k8s yaml文件参考gateway模块部署基础环境这一步暂时省略，后续补充…在K8s中部署Nacos集群（注册和配置中心）在k8s中部署Seata分布式事务在linux部署mysql,redis,rabbitmq,

KubeSphere 是在 Kubernetes 之上构建的面向云原生应用的分布式操作系统，完全开源，支持多云与多集群管理，提供全栈的 IT 自动化运维能力，简化企业的 DevOps 工作流。它的架构可以非常方便地使第三方应用与云原生生态组件进行即插即用 (plug-and-play) 的集成。作为全栈的多租户容器平台，KubeSphere 提供了运维友好的向导式操作界面，帮助企业快速构建一个强大和功能丰富的容器云平台。

StorageClass 为管理员提供了描述存储 “类” 的方法。不同的类型可能会映射到不同的服务质量等级或备份策略，或是由集群管理员制定的任意策略。Kubernetes 本身并不清楚各种类代表的什么。这个类的概念在其他存储系统中有时被称为 “配置文件”。查看Kubernetes集群中的默认存储类。

Ingress 公开从集群外部到集群内服务的 HTTP 和 HTTPS 路由。流量路由由 Ingress 资源上定义的规则控制。Kubernetes 通过 kube-proxy 服务实现了 Service 的对外发布及负载均衡，它的各种方式都是基于传输层实现的。在实际的互联网应用场景中，不仅要实现单纯的转发，还有更加细致的策略需求，如果使用真正的负载均衡器更会增加操作的灵活性和转发性能。

本次环境搭建需要三台CentOS服务器（一主二从），然后在每台服务器中分别安装Docker（20.10.0）、kubeadm（1.21.10）、kubectl（1.21.10）和kubelet（1.21.10）。在kubernetes中service有两种代理模型，一种是基于iptables，另一种是基于ipvs的。SELinux(Security-Enhanced Linux) 是美国国家安全局（NSA）对于强制访问控制的实现，是 Linux历史上最杰出的新安全子系统。本文基于kubeadm安装。