StatefulSet 旨在与有状态的应用及分布式系统一起使用。本节将通过使用 StatefulSet 部署一个简单的 Web 应用，来演示StatefulSet的常规操作，包括：
Kubernetes StatefulSets[1]自从在 1.5 中引入，并在 1.9 中变得稳定以来，已经被广泛用于运行有状态应用程序。它提供稳定的单元身份、持久的单元存储，以及有序的部署、扩展和滚动更新。你可以将 StatefulSet 视为运行复杂的有状态应用程序的原子构建块。随着 Kubernetes 的使用越来越多，需要 StatefulSets 的场景也越来越多。在你对 StatefulSets 使用 OrderedReady pod 管理策略的情况下，许多这样的场景需要比当前支持的一次一个 Pod 更新更快的滚动更新。
在节点处于“NotReady”状态时，deployment控制器会迁移节点上的容器实例，并将节点上运行的pod置为“Terminating”状态。待节点恢复后，处于“Terminating”状态的pod会自动删除。偶现部分pod（实例）一直处于“Terminating ”状态，发现这部分的pod没有得到重新调度，不能提供服务。
参考：https://kubernetes.io/docs/tutorials/stateful-application/basic-stateful-set/
Author: xidianwangtao@gmail.com PodGC Controller配置 关于PodGC Controller的相关配置（kube-controller-manager配置），一共只有两个： flagdefault valuecomments --controllers stringSlice*这里配置需要enable的controlllers列表，podgc当然也可以在这里设置是都要enable or disable，默认podgc是在enable列表中的。 --
一句话，本质是API Server虽然标记了对象的删除，但是作为实际清理的控制器kubelet， 并不能关停Pod或相关资源, 因而没能通知API Server做实际对象的清理。
我们在《Kubernetes工作负载管理》中主要介绍了无状态应用的管理，当时也有提到有状态应用，但是由于那时候还没有解释数据如何持久化就没有做深度的介绍，而在这章，我们会着重介绍如何进行有状态应用的管理。
问卷链接（https://www.wjx.cn/jq/97146486.aspx）
在《研发工程师玩转Kubernetes——使用Node特性定向调度Pod》中，我们提到requiredDuringSchedulingIgnoredDuringExecution只有在规则被满足的时候才能执行调度。本节我们将测试几种边界情况，看看Kubernetes的行为。
比如现在我有一个更新策略为 Recreate 的应用，然后执行删除命令，如下所示：
K8S是一个开源的，用于管理云平台中多个主机上的容器化应用，Kubernetes的目标是让部署容器化变得简单并且高效
StatefulSet副本启动顺序按照名称0，1，2，只有web-0完全启动之后才会启动web-1，web-1完全启动之后才会启动web-2
最近在看client-go源码最基础的部分，client-go的四类客户端，RestClient、ClientSet、DynamicClient、DiscoveryClient。其中RestClient是最基础的客户端，它对Http进行了封装，支持JSON和protobuf格式数据。其它三类客户端都是通过在REStClient基础上再次封装而得来。不过我对ClientSet和DynamicClient傻傻分不清，虽然很多资料上说它两最大区别是，ClientSet能够使用预先生成的Api和ApiServer进行通信；而DynamicClient更加强大，不仅仅能够调用预先生成的Api，还能够对一些CRD资源通过结构化嵌套类型跟ApiServer进行通信。意思大致明白前者能够调用Kubernetes本地资源类型，后者还可以调用一些自定资源，那么他们究竟是如何跟ApiServer进行交互、Pod的增删改查呢？
在《研发工程师玩转Kubernetes——Node失效后的Pod的调度实验》中我们看到Kubernetes会一直等待Node状态恢复。这节我们将做实验，看看Node恢复后Kubernetes的表现。 仍然借助《研发工程师玩转Kubernetes——Node失效后的Pod的调度实验》的实验过程。
对每个人而言，真正的职责只有一个：找到自我。然后在心中坚守其一生，全心全意，永不停息。所有其它的路都是不完整的，是人的逃避方式，是对大众理想的懦弱回归，是随波逐流，是对内心的恐惧 ——赫尔曼·黑塞《德米安》
下面的清单包含Headless Service,Service,PodDisruptionBudget和StatefulSet。
岳家瑞，腾讯云后台开发工程师，日常负责K8s生态和运行时相关工作，包括K8s插件开发和运行时问题排查。
这里简单说明：kubernetes-bootcamp为实例名，–image指定docker镜像，–port指定对外提供的端口
在上一篇中，讲解了容器持久化存储，从中我们知道什么是PV和PVC，这一篇我们讲通过StatefulSet来使用它们。
容器实例服务（Container Instance Service , CIS）可以帮您在云上快捷、灵活的部署容器，让您专注于构建程序和使用容器而非管理设备上。无需预购 CVM，您就可以在几秒内启动一批容器来执行任务。您也可以通过 kubernetes API 把已有 kubernetes 集群的 pod 调度到 CIS 上以处理突增业务。CIS 根据您实际使用的资源计费，可以帮您节约计算成本。使用 CIS 可以极大降低您部署容器的门槛，降低您执行 batch 型任务或处理业务突增的成本。
但是，单独的Pod并不能保障总是可用，比如我们创建一个nginx的Pod，因为某些原因，该Pod被意外删除，我们希望其能够自动新建一个同属性的Pod。很遗憾，单纯的Pod并不能满足需求。
Kubless 的自动伸缩功能基于 Kubernetes 的 HPA（HorizontalPodAutoscaler）功能实现。
现象：某个Node频繁出现“PLEG is not healthy: pleg was last seen active 3m46.752815514s ago; threshold is 3m0s”错误，频率在5-10分钟就会出现一次。
在《研发工程师玩转Kubernetes——Node失效后恢复的实验》中，有一次Pod被分配到Master Node——UbuntuA上。进一步的实验需要我们关闭其所在的Node，而Master Node又不能关闭，否则我们将无法对Kubernetes进行操作。这个时候我只能使用Pod调度技法来将其从Master Node上驱逐。
只有1个版本的时候，流量100%进入该版本。update一个新的版本，这时候有两个版本，默认latest版本流量100%，可以通过配置设定不同版本的流量百分比。
版权声明：本文为博主原创文章，未经博主允许不得转载。博客地址：http://blog.csdn.net/huqigang，内容如有错误，欢迎留言指出，谢谢！ https://blog.csdn.net/huqigang/article/details/87855331
Kubernetes v1.26 包括网络流量工程方面的重大进步，其中两个功能（服务内部流量策略支持和 EndpointSlice 终止条件）升级为 GA，第三个功能（代理终止端点 Proxy terminating endpoints）升级为测试版。这些增强功能的组合旨在解决当今人们在 traffic 工程中面临的缺点，并为未来解锁新功能。
kubernetes中涉及很多概念，包含云生态社区中各类技术，学习成本比较高，k8s中通常以编写yaml文件完成资源的部署，对于较多入门的人来说是个较高的门坎，本文以命令行的形式带领大家快速入门，俯瞰kubernetes核心概念，快速入门。
作者： Kevin Hannon (G-Research), Michał Woźniak (Google)
除了deployment是v1的升级版，其他的基本都是v1。 # kubectl api-versions
软件世界的发展比以往任何时候都快，为了保持竞争力需要尽快推出新的软件版本，而又不影响在线的用户。许多企业已将工作负载迁移到了 Kubernetes 集群，Kubernetes 集群本身就考虑到了一些生产环境的实践，但是要让 Kubernetes 实现真正的零停机不中断或丢失请求，我们还需要做一些额外的操作才行。
statefulset 旨在与有状态的应用及分布式系统一起使用，statefulset 中的每个 pod 拥有一个唯一的身份标识，并且所有 pod 名都是按照 {0..N-1} 的顺序进行编号。本文会主要分析 statefulset controller 的设计与实现，在分析源码前先介绍一下 statefulset 的基本使用。
Pod是kubernetes的最小管理单元，在kubernetes中，按照pod的创建方式可以将其分为两类：
作者：Kevin Hannon (G-Research), Michał Woźniak (Google)
在应用程序的整个生命周期中，正在运行的 pod 会由于多种原因而终止。在某些情况下，Kubernetes 会因用户输入（例如更新或删除 Deployment 时）而终止 pod。在其他情况下，Kubernetes 需要释放给定节点上的资源时会终止 pod。无论哪种情况，Kubernetes 都允许在 pod 中运行的容器在可配置的时间内正常关闭。
默认情况下，Kubernetes 的 Deployment 是具有滚动更新的策略来进行 Pod 更新的，该策略可以在任何时间点更新应用的时候保证某些实例依然可以正常运行来防止应用 down 掉，当新部署的 Pod 启动并可以处理流量之后，才会去杀掉旧的 Pod。
上一篇文章中，我们讲了deployment的编排技术，也提到了这种编排技术只能编排无状态的pod。但是在我们实际生产环境中，系统复杂很多。比如分布式系统，pod之间往往有依赖关系。再比如mysql数据库，主从节点需要通过binlog同步数据，读写请可能要求发送到不同节点上。对这种有状态的应用，kubernete的解决方案是StatefulSet。
一、 kubectl --help 详解 1、基础命令 create 创建资源 expose 使用 replication controller, service, deployment 或者 pod 并暴露它作为一个 新的 Kubernetes Service 主要是暴露端口 run 在集群中运行一个指定的镜像 set 为 objects 设置一个指定的特征 做
简介： 在有状态应用中，MySQL是我们最常见也是最常用的。本文我们将实战部署一个一组多从的MySQL集群。
前面已经分析了 kube-scheduler 的代码逻辑以及 predicates 与 priorities 算法，本节会继续讲 scheduler 中的一个重要机制，pod 优先级与抢占机制(Pod Priority and Preemption)，该功能是在 v1.8 中引入的，v1.11 中该功能为 beta 版本且默认启用了，v1.14 为 stable 版本。
在《研发工程师玩转Kubernetes——多Worker Node部署》中，我们创建了Master Node: UbunutA，以及四个Worker Node:UbunutB、UbunutC、UbunutD和UbunutE。本节我们将使用Deployment创建只含有一个nginx的Pod，然后关掉它所在的主机以模拟Node失效，观察kubernetes在这种情况下的表现。
在 Kubernetes 节点发生故障时，在 40 秒内（由 Controller Manager 的 --node-monitor-grace-period 参数指定），节点进入 NotReady 状态，经过 5 分钟（由 --pod-eviction-timeout 参数指定），Master 会开始尝试删除故障节点上的 Pod，然而由于节点已经失控，这些 Pod 会持续处于 Terminating 状态。
由于 Pod 所代表的是在集群中节点上运行的进程，当不再需要这些进程时允许其体面地终止。
Docker 是 Kubernetes Pod 中最常用的容器运行时，但 Pod 也能支持其他的容器运行，比如 rkt、podman等。
简括：首先kubectl向 API 接口发送指令，随后kube-api 会调度到我们的kubelet,这个调度过程是由我们的etcd完成的存储，随后kubelet操作CRI ,由CRI完成容器环境的初始化。在初始化的过程中会先启动一个pause的基础容器（谷歌制作的一个非常简洁的一个容器），pause容器负责pod中容器的网络已经存心卷共享的。随后，pause进行一个或者多个或者没有 init C 的初始化。init初始化完成了。会正常退出。退出码为0，如果非零为不正常，会再根据我们的重定策略去判断是否继续重新执行。多个初始化的容器做完了之后，会进入到主容器main C .main C 在刚运行的时候，我们可以允许它启动一条命令，或者执行一个脚本都可以。main C 在结束的时候也会执行一个STOP的命令，交代一下后事，这个过程中会有readiness和liveness的参与，readiness只有成功检测了。pod的状态才会ready或者running。当我们的主容器里面的进程和liveness中检测不一致时候，那么就可以执行对应的重启命令，或者删除。
Pod 水平自动扩缩全名是Horizontal Pod Autoscaler简称HPA。它可以基于 CPU 利用率或其他指标自动扩缩 ReplicationController、Deployment 和 ReplicaSet 中的 Pod 数量。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
即时通信 IM
