当咱们在消费环境颁布运行时，必定要思索到以后系统还有用户正在经常使用的状况，所以尽量要求做到不停机发版。

所以在颁布环节中通常上之前的v1版本依然存在，必定得期待v2版本启动成功后再删除历史的v1版本。

滚动更新

这是咱们预期中的颁布流程，要在kubees经常使用该性能也十分便捷，只有要在spec下性能相关战略即可：

spec:strategy:rollingUpdate:maxSurge:25%maxUnavlable:25%type:RollingUpdate

这特性能的含意是：

这样一旦咱们更新了Pod的镜像时，kubernetes就会先创立一个新版本的Pod期待他启动成功后再逐渐更新剩下的Pod。

优雅停机

滚动更新环节中无法防止的又会碰到一个优雅停机的疑问，毕竟是要求停掉老的Pod。

这时咱们要求留意两种状况：

第一个疑问假设咱们经常使用的是Go，可以经常使用一个钩子来监听kubernetes收回的分开信号：

quit:=make(chanos.Signal)signal.Notify(quit,syscall.SIGHUP,syscall.SIGINT,syscall.SIGTERM,syscall.SIGQUIT,syscall.SIGPIPE)gofunc(){<-quitlog.Printf("quitsignalreceived,exitn")os.Exit(0)}()

在这里口头对应的资源监禁。

假设经常使用的是springboot也有对应的性能：

server:shutdown:"graceful"spring:lifecycle:timeout-per-shutdown-phase:"20s"

当运行收到分开信号后，springboot将不会再接纳新的恳求，并期待现有的恳求处置终了。

但kubernetes也不会有限期待运即将Pod将义务口头终了，咱们可以在Pod中性能

terminationGracePeriodSeconds:30

来定义要求期待多长期间，这里是超越30s之后就会强行killPod。

spec:containers:-name:example-containerimage:example-imagelifecycle:preStop:exec:command:["sh","-c","sleep10"]

同时咱们也可以性能preStop做一个sleep来确保kubernetes将预备删除的Pod在Iptable中曾经更新了之后再删除Pod。

这样可以防止第二种状况：曾经删除的Pod依然还有恳求路由上来。详细可以参考springboot文档：

回滚

回滚其实也可以看作是更新的一种，只是更新到了历史版本，在kubernetes中回滚运行十分便捷。

#回滚到上一个版本krolloutundodeployment/abc#回滚到指定版本krolloutundodaemonset/abc--to-revisinotallow=3

同时kubernetes也能保障是滚动回滚的。

优雅重启

在之前的如何优雅重启kubernetes的Pod那篇文章中写过，假构想要优雅重启Pod也可以经常使用rollout命令，它也也可以保障是滚动重启。

krolloutrestartdeployment/

经常使用kubernetes的滚动更新确实要比咱们以往的传统运维便捷许多，就几个命令的事件之前得写一些复杂的运维脚本能力成功。

K8S——Pod入门理解

1Pod的含义? 官方解释:在Kubernetes集群中，Pod是所有业务类型的基础，它是一个或多个容器的组合。 这些容器共享存储、网络和命名空间，以及如何运行的规范。 在Pod中，所有容器都被同一安排和调度，并运行在共享的上下文中。 对于具体应用而言，Pod是它们的逻辑主机，Pod包含业务相关的多个应用容器。 Kubernetes不只是支持Docker容器，它也支持其他容器。 个人理解:Pod是容器组的一个抽象，类似于一栋出租楼里面的房子，房子的其他小房间像容器，房间里的水，电充当应用服务。 出租屋内的小房间门跟容器端口差不多，出租屋大门像pod上的端口，整栋楼大门像service对外暴露的端口。 2使用Pod的原因? pod是K8s最小的运行，部署单位。 用K8s作容器管理，比如Mysql，Redis等服务运行需要创建Pod，才能对外提供服务。 3Pod操作相关命令 3.0 pod创建 kubectl run httpd--image=httpd -n 空间名 3.1 查看所有空间上的pod节点 kubectlget pods --all-namespaces 3.2 查看指定空间上的pod kubectlgetpod -n 空间名 3.3 查看pod详情 kubectlget pod -o wide -n 空间名kubectldescribe pod name 3.4 指定变更pod空间清单脚本 kubectledit pod pod名 -n 空间名 3.5 删除pod 删除某个空间下pod kubectldeleteall--all -n 空间名 删除默认空间 pod kubectldeletepodsname 删除指定空间下pod kubectldeletepodsname-n 空间名 3.6 登录Pod里面容器 (container-name 通过3.3 可以获取) kubectl exec -ti-c/bin/bash container-name 有多个是要指定 只有一个去掉 kubectl exec-cdate container-name 有多个是要指定 只有一个去掉 指定pod里面某个容器执行命令 3.7 查看Pod里面容器日志 kubectl logs -f-c 4脚本创建Pod apiVersion: v1 kind: Pod metadata:name: test-pd spec:containers:- image: tomcat:8.0 name: test-container ports: - containerPort: 8080protocol: TCP

k8s五分钟快速入门

k8s是谷歌开源的容器集群管理系统，是谷歌多年大规模容器管理技术Borg的开源版本，主要功能包括：

从功能上讲Kubernetes是一种综合的基于容器构建分布式系统的基础架构环境，它不仅能够实现基本的拉取用户镜像、运行容器，还可以提供路由网关、水平扩展、监控、备份、灾难恢复等一系列运维能力，而更重要的是Kubernetes可以按照用户的意愿和整个系统的规则，高度自动化的处理好容器之间的各种关系实现“编排”能力。

简单概括，提供创建应用>应用部署>提供服务>动态伸缩>应用更新一系列服务。

k8s主要由以下几个核心组件：

一个kubernetes集群由分布式存储etcd、控制节点controller以及服务节点Node组成。

如上图所示，Kubernetes在架构上主要由Master和Node两种类型的节点组成，这两种节点分别对应着控制节点和计算节点。其中Master即控制节点，是整个Kubernetes集群的大脑，负责整个集群的管理，比如容器的调度、维护资源的状态、自动扩展以及滚动更新等，并能根据集群系统资源的整体使用情况将作业任务自动分发到可用Node计算节点。

看Master节点主要由三个紧密协作的独立组件组合而成。 需要说明的是，上述组件在工作状态下还会产生许多需要进行持久化的数据，这些数据会通过kube-apiserver处理后统一保存到Etcd存储服务中。 所以从这个角度看kube-apiserver不仅是外部访问Kubernetes集群的入口，也是维护整个Kubernetes集群状态的信息中枢。

而在Kubernetes计算节点中，除了上述3个系统组件外，其他基本与Master节点相同，而其中最核心的部分就是kubelet组件。它的核心功能具如下：

在Kubernetes中kubelet会通过CRI接口同容器运行时进行交互，而容器运行时则通过叫做OCI容器运行时规范与底层Linux操作系统进行交互(涉及对Namespace、Cgroups等资源的操作，具体可以了解下Docker的技术原理)。需要强调的是，这里所说的容器运行时并不仅仅指Docker，而是所有实现了CRI接口规范的容器项目都可以作为Kubernetes的容器运行时存在。这是因为Kubernetes从设计之初就没有把Docker作为整个架构的核心，而只是将其作为最底层的一个容器运行时来实现。

况且从Kubernetes架构设计上看，Kubernetes并没有打算重复造轮子而对已有的容器技术进行替代，它更关注的是对运行在大规模集群中的各种任务根据其关系进行作业编排及管理，所以任何实现了CRI、CNI、CSI等协议标准的容器技术都可以无缝地与Kubernetes集成。从这个角度看，Docker与Kubernetes的关系并不是替代的关系，而是平台与组件的关系，Kubernetes可以利用现有的Docker容器运行时技术，但却并不完全依赖Docker。而这也正是Kubernetes为什么被称作容器编排技术而不仅仅只是容器技术的原因。

[1]Kubernetes和Docker的关系是什么？ [2] 《k8s入门指南》这是一个博主写的书