dengfengling999的博客

认证管理。

pvc3是没有来绑定成功的。

node1创建了目录：检测日志：访问： 检测出现了日志：容器删除： 日志还会存在 master：

开启ipvs修改每个显示的内容。

deployment和servie是为了产生pod，并且对pod产生对外的接口。这个软件安装成功后，也是一个Pod，在kub-system下卖弄。type=NodePod 是集群外的ip也可以访问，run命令会产生deployment和pod。我们先使用postman进行发送请求：模拟压测。deploymen检测的pod发生了变化。6个pod任务，允许3个pod并行执行。检测的pod，运行完变成0了。检测deployment。先执行3个，再执行3个。查看node的资源情况。pod又还原成原样了。

修改配置文件 使用命令修改：过一会： 使用命令：通过命令行的方式：编辑脚本： 更新镜像 实时监控： 重建更新，他是先停止全部pod，然后在运行pod实时监控： 更新镜像： 滚动更新：他是启动一个，停一个...不断的更新 --record：会记录更新信息监听rs：监听pod 更新镜像新创建的pod会新建出来一个rs来发现rs，新的rs中Pod在增加，老的rs在减少会多一个rs，老的rs没有pod了，都跑到新的里面了 查看历史记录： 查看状态：正在等待更新继续更新：

node3不存在修改成不存在的标签：详情。

因为只有一个80端口，没有8080，所以会重启。发现没有进行重启： 最后变成完成状态。探针，探出问题超过3次后，停止容器。因为没有hello.txt文件。修改成：/ 放文根目录。因为没有/hello。

改大：10g。

查看版本：查看类型,这里加s跟不加s没啥区别，可加可不加。

假设在某一个瞬间，某一个pod被干掉了，因为pod控制器deploymen的存在，当这个pod被干掉之后，会立即重建一个pod，重建之后原来的ip地址是不能访问的，ip地址已经发生了改变。Selector run=nginx 标签选择：会找pod打的标签。执行删除之后，pod也会删除，Terminating正在删除。如果想要访问其中的一个pod借助：IP地址+端口号访问。

使用配置文件：name：nginx就是pod的名称，不是pod控制器的名称，用命令行的时候，没有办法单独起一个pod，用yaml运行的起的是单独的一个pod。通过pod的ip，使用curl进行访问，这个ip地址会随着pod的重新创建而变化。查看dev下面的pod控制器，要想真正的删掉pod，删掉pod控制器，就可以了。run nginx：nginx是pod控制器的名称，不是pod的名称。查看 dev下面的pod，第二个pod处于容器创建的状态。启动一个不存在的镜像：pod。

本章节主要介绍yaml语法和kubernetes的资源管理方式dev下删除了pod，之后发现还有pod，把原来的pod删除了，重新启动了一个。

我们用18.06.3这个版本，这个版本比较稳定，已经把参数做了初始化，不需要额外的去配参数，验证集群是否安装成功，我们让集群跑一个nginx程序，看是否能够跑起来。查看pod：pod是集群的最小单元，程序在容器里，容器在pod里。此时节点状态还是NotReady为准备状态，需要执行下面。控制面板，master已经安装成功了。

软件选择选择 基础设施服务器，这样安装系统完毕之后，会有很多软件我们可以直接使用了。ip地址的设置：要跟虚拟网络编辑器，Net模式下的子网ip的网段。系统点开，点一下完成。

应用部署方式经历了从物理机到虚拟机，再到容器化的演变，容器化技术因其轻量、快速和一致性成为主流。Kubernetes（简称K8s）是一个开源的容器编排平台，用于自动化部署、扩展和管理容器化应用。其核心组件包括API Server、etcd、Controller Manager、Scheduler、Kubelet和Kube-proxy，分别负责集群管理、存储、控制、调度、节点管理和网络通信。Kubernetes的核心概念包括Pod（最小部署单元）、Service（服务发现与负载均衡）、Deployment（应

创建Pod，里面的两个容器都正常运行。（3）Pod详解-端口设置。（1）Pod详解-启动命令。（2）Pod详解-环境变量。（3）Pod详解-端口设置。（4）Pod详解-资源配额。不满足条件是不能正常启动。

一级属性有下面这些：前两个属性是字符串，上面有定义 kind：Pod version：v1。通过这种形式可以遍历所有属性，我们只要掌握需要经常用的属性就可以了。创建跟查看pod：创建有问题，发现有容器一直在重启。修改拉取镜像策略：本地有使用本地没有进行远端拉取。查看pod的详细，以yaml的形式查看。还可以继续查看子属性：二级属性。（3）Pod详解-镜像拉取策略。（1）Pod详解-结构和定义。（1）Pod详解-结构和定义。可以查看pod创建的详细信息。（2）Pod详解-基本配置。

k8s中pod是最小的控制单元，但是很少直接的控制pod，比如说创建，销毁等等，一般都是通过pod控制器来完成的，pod控制器就是用于pod的管理，确保pod始终保持在正常的状态，出现问题进行重启或者重建。使用kubectl run nginx（pod控制器名称）...使用这种方式创建的pod底层创建一个nginx的pod控制器 replicas=3指定创建pod的数量，默认创建一个。有一瞬间，一个pod被删除，pod控制器会重新创建一个pod，它的ip地址也会发生改变。查看：pod 和pod控制器。

kubectl describe pod 可以查看pod的详细信息，最后还可以查看启动过程。查看系统组件的命名空间中的Pod：他们就是master节点上要运行的4个组件。kubernets：系统创建的资源在这个命名空间里 ，集群组件资源。pod的ip地址会随着pod的重新创建而变化，不稳定的。kubrnets组件也是以pod的形式运行的。（1）实战入门-Namespace。通过ip：端口号进行访问：pod。删除Pod控制器：就是删除Pod。通过配置文件创建的就是Pod。（2）入门实战-Pod。

命令式对象配置可以写很多命令，增删改查都能做，而声明式 对象配置只能写apply，只能做新增和更新。用describe描述容器的详细信息：包括ip啊，镜像啊，端口啊，容器启动经历的历程。再次运行配置文件，它会进行提示有没有更新，更新后发显示重新配置了。查询的时候加上命名空间，默认查询的是default下面的。删除pod：pod控制器它会重新启动一个pod。在master节点上执行 ：复制到node节点。（3）资源管理方式3。（1）资源管理方式1。（2）资源管理方式2。（3）资源管理方式3。

kubernetes中所有东西都是抽象为资源对象的，比如pod，service 等等，我们学习kubernetes的重点就是学习这些资源对象的管理，它提供了这几种方式管理对象。Pod想要让外部访问需要通过Service代理，外部访问Service，就能访问内部的Pod。Pod控制器的作用，就是为了最终产生各种各样的Pod，Pod里面运行容器，容器里面运行程序。程序需要数据持久化，可以用数据存储卷来存储。命令式对象管理：一般用来查看的场景。（2）yaml语言介绍。（3）资源管理方式介绍。

容器部署容易出现编排问题，为了解决就出现了大量的编排软件，这里将的是K8S编排问题的解决佼佼者。弹性伸缩：当流量从1000变为1200可以，自动开启一个新的nginx。（1）应用部署方式转变。（1）应用部署方式转变。

我们测试以下集群安装是否成功，我们在集群上跑一个nginx程序，看是否能够了跑起来。我们的程序在容器里，容器在Pod里，pod是正常运行的，程序跟容器也应该是正常的。可以看到状态是NotReday，由于网络插件没有安装，各个节点此时还不能通信的。能够正常访问说明nginx在正常工作了，集群也是可以正常访问的，30518是暴露给外边的端口：可以通过ip+端口访问nginx。下载完成之后：查看一下镜像，名字也已经改成了k8s的名字。集群初始化只在master节点上运行，（1）环境搭建-集群安装。

我们用18.06.3这个版本，因为这个版本比较稳定，在做的时候把一些参数做了初始化，不需要我们二外的配很多参数，如果选择了其他版本可能需要配置其他的参数。Centos的版本是有要求的必须是7.5或以上，否则安装出来的集群是有问题的Node节点可能加入不到集群中来。2.主机名解析，方便节点之间的调用，这里是测试环境中的用法，在企业中真实环境推荐使用内部DNS服务器做解析。注释：/dev/mapper/centos-swap。1.同时连接三台服务器：查看一下版本 是否正确。（2）集群所需组件的安装。

K8S是通过控制pod来控制容器进而控制程序的。点击创建新的虚拟机：自定义，下一步。点击编辑虚拟机：选择一个镜像去安装。使用虚拟机，来虚拟三台服务器。确定之后，就可以开启虚拟机了。（2）环境搭建-环境规划。（3）环境搭建-主机安装。稍后安装操作系统，下一步。

目录：（1）镜像结构（2）自定义镜像-Dockerfile（3）DockerCompose-初始化Compose（4）DockerCompose-部署微服务集群（5）Docker镜像仓库（1）镜像结构 前面学习的镜像都是docker官方帮我们创建的镜像，将来我们自己的微服务，需要我们自己创建镜像 镜像是由以上组成的，结构去看怎么样去组合，这些组成有没有依赖关系顺序呢？如果没有底层的系统函数库，文件系统怎么样去完成环境的配置，如果没有配置环境变量怎么去 做依赖的安转，如果没有依赖安装如何去完成应用的安装，如果

时，docker会帮我们创建数据卷对应的目录，数据卷指向这个目录，docker挂载时，只需要挂载这个卷上就可以了，不需要关心卷在哪里，这种方式是全全交给docker去处理了，我们不需要去操心，缺点是这个目录不是我们创建的，在哪里创建的我们不知道，想去找比较麻烦。目录挂载：目录使我们自己创建的，我知道这个目录在哪里，挂载的时候直接挂载上就行了，将来可以快速的定位文件在哪里，缺点是：需要我们自己去管理这个目录。停止：是把进程杀死，容器所占的内存回收，保留下来只剩下文件系统了，静态的东西，一旦停止，不能恢复。

虚拟机：是在一个系统运行另外一个系统，Hypervisor技术可以模拟出各种计算机的各种硬件CPU、内存等等 ，在模拟的计算机上就可以安装你想要的操作系统了，就可以安装你想要的任何依赖啊函数库啊应用啊，这样就可以实现跨系统应用部署，虚拟机是在一个系统装了另外的系统,因此应用运行时会以为在真实的系统上，会先调用内置的系统再与Hypervisor交互，然后再把信息传给外部系统，然后再调用计算机硬件，经过了层层的传递，性能较差一点。所有Linux的系统可以分为两层，一层是内核，不同的是上层的系统应用不同。

如果没有做持久化,然后就...该模式非常适合非持久化队列,只有该队列是非持久化的,客户端才能重新连接到集群中的其他节点,并且重新创建队列,如果该队列是持久化的,那么唯一的办法就是将故障节点恢复起来.,而不会在consumer取数据时临时拉取.该模式带来的副作用也很明显,除了降低系统性能意外,如果镜像队列过多,加之有大量的消息进入,集群内部的网络带宽将会被这种同步通讯大大消耗掉,所以在对可靠性要求较高的场合中适用.运行启动类：发现对类中消息的数目total1,1,3根接收的规则是一样的。

这种场景下就可以用 MQ ，在下单的主流程（比如扣减库存、生成相应单据）完成之后发送一条消息到 MQ 让主流程快速完结，而由另外的单独线程拉取MQ的消息（或者由 MQ 推送消息），当发现 MQ 中有发红包或发短信之类的消息时，执行相应的业务逻辑。在这种模式下生产者只面向 Exchange 发布消息，消费者只面向 Queue 消费消息，Exchange 定义了消息路由到 Queue 的规则，将各个层面的消息传递隔离开，使每一层只需要关心自己面向的下一层，降低了整体的耦合度。它是完全匹配、单播的模式。