这是实现「 Kubernetes 集群零停机时间更新」系列文章的第三部分。在本系列的第二部分中,我们通过利用 Pod 生命周期钩子实现了应用程序Pod的正常终止,从而减轻了由于 Pod 未处理完已存请求而直接关机而导致的停机时间。但是,我们还了解到,在启动关闭序列后,Pod 会拒绝为新到来的流量提供服务,但实际情况是 Pod 仍然可能会继续接收到新流量。这意味着最终客户端可能会收到错误消息,因为它们的请求被路由到了不再能为流量提供服务的Pod。理想情况下,我们希望 Pod 在启动关闭后立即停止接收流量。为了减轻这种情况,我们必须首先了解为什么会发生Pod开始关闭时仍然会接收到新流量这个问题。
非级联删除是指在删除StatefulSet时,Kubernetes只删除StatefulSet本身,而不删除相关的Pod和存储卷。这种删除方式适用于用户需要保留有状态应用程序的数据并在以后重新创建StatefulSet的情况。
之前的文章我们介绍了HPA(Horizontal Pod Autoscaler)的实现,HPA一般被称为横向扩展,与HPA不同的Vertical Pod Autoscaler ( VPA ) 会自动调整 Pod 的 CPU 和内存属性,被称为纵向扩展。VPA可以给出服务运行所适合的CPU和内存配置,省去估计服务占用资源的时间,更合理的使用资源。当然,VPA也可根据资源的使用情况“调整”pod的资源。这里的调整我们用了双引号,因为他的实现机制是重建而不是动态增加。下面是一个实际的例子:假设我的memory limits是100Mi,但是现在已经用到了98Mi,如果再大的话就oom了,此时vpa会在垂直方向上提升你的memory limits的大小。这种vpa比较适合一些资源消耗比较大的应用,例如es,你给大了资源浪费,给小了,又不够。所以vpa就派上用场了。当然,vpa不像hpa默认集成在k8s里面的,需要你自己去配置的。
Replication Controller为Kubernetes的一个核心内容,应用托管到Kubernetes之后,需要保证应用能够持续的运行,Replication Controller就是这个保证的key,主要的功能如下:
在学习StatefulSet之前, 我们先看下什么是有状态应用, 什么是无状态应用。
Kubernetes 1.26 引入了 Pod 的一个新特性:scheduling gates。在 Kubernetes 中,调度门是告诉调度程序何时准备好考虑调度 Pod 的 keys。
原文: https://thenewstack.io/deleting-production-in-a-few-easy-steps-and-how-to-fix-it/
Kubernetes中的调度是将待处理的pod绑定到节点的过程,由Kubernetes的一个名为kube-scheduler的组件执行。调度程序的决定,无论是否可以或不能调度容器,都由其可配置策略指导,该策略包括一组规则,称为谓词和优先级。调度程序的决定受到其在第一次调度时出现新pod时的Kubernetes集群视图的影响。由于Kubernetes集群非常动态且状态随时间而变化,因此可能需要将已经运行的pod重新调试到其它节点上,已达到节点使用资源平衡。
Deployment并不能满足所有的应用场景,因为它默认对应用做了一个简化假设处理,认为一个应用的所有Pod是完全一样的,但往往在实际应用中,多个实例相互间是存在依赖关系的,比如:主从关系,主备关系,实例与数据之间的关系等。
kubernetes 中使用 Job 和 CronJob 两个资源分别提供了一次性任务和定时任务的特性,这两种对象也使用控制器模型来实现资源的管理。
基于主机安装或基于Kubernetes安装的 Rainbond 集群(均使用默认参数安装),默认使用的共享文件存储是 NFS ,以 Pod 方式运行在 Kubernetes 中,但这种方式也有一些无法避免的问题,比如:NFS 的 SVC 无法通信时集群无法挂载存储则导致不能使用、服务器关机时卡在 umount 导致不能正常关机等等。
数据局部性设置(data locality setting)旨在在以下情况下启用:只要有可能,至少应在与使用该卷的 pod 相同的节点上调度 Longhorn 卷的一个副本。我们将拥有本地副本的特性称为具有 data locality。
首先,StatefulSet 的控制器直接管理的是 Pod。这是因为,StatefulSet 里的不同 Pod 实例,不再像 ReplicaSet 中那样都是完全一样的,而是有了细微区别的。比如,每个 Pod 的 hostname、名字等都是不同的、携带了编号的。而 StatefulSet 区分这些实例的方式,就是通过在 Pod 的名字里加上事先约定好的编号。
多种升级方案:Recreate:删除所有已存在的pod,重新创建新的; RollingUpdate:滚动升级,逐步替换的策略,同时滚动升级时,支持更多的附加参数,例如设置最大不可用pod数量,最小升级间隔时间等等。
最新版本v1.18已经发布,其包含了38项功能增强,其中15项为稳定版功能、11项beta版功能以及12项alpha版功能。在本文中,我们将探索其中一些功能,希望能帮助你决定是否需要升级。那么,我们现在开始吧!
您是否害怕将集群升级到更新的 Kubernetes 版本?有几个原因可能会促使您升级。也许您想要执行以下操作之一:
Master节点是Kubernetes集群的控制节点,每个Kubernetes集群里至少有一个Master节点,它负责整个集群的决策(如调度),发现和响应集群的事件。一个集群通常运行多个Master控制节点,提供容错性和高可用性。Master节点可以运行在集群中的任意一个节点上,但是最好将Master节点作为一个独立节点,不在该节点上创建容器,因为如果该节点出现问题导致宕机或不可用,整个集群的管理就会失效。
Rancher 2.2.2 发布了。Rancher 是一个开源的企业级 Kubernetes 平台,可以管理所有云上、所有发行版、所有 Kubernetes 集群,解决了生产环境中企业用户可能面临的基础设施不同的困境,改善 Kubernetes 原生 UI 易用性不佳以及学习曲线陡峭的问题。
一、什么是K8S(Kubernetes)? 1.k8s全称kubernetes,这个名字大家应该都不陌生,k8s是为容器服务而生的一个可移植容器的编排管理工具,越来越多的公司正在拥抱k8s,并且当前k8s已经主导了云业务流程,推动了微服务架构等热门技术的普及和落地,正在如火如荼的发展。那么称霸容器领域的k8s究竟是有什么魔力呢? 2.首先,我们从容器技术谈起,在容器技术之前,大家开发用虚拟机比较多,比如vmware和openstack,我们可以使用虚拟机在我们的操作系统中模拟出多台子电脑(Linux),子电脑之间是相互隔离的,但是虚拟机对于开发和运维人员而言,存在启动慢,占用空间大,不易迁移的缺点。举一个我亲身经历过的场景吧,之前在vmware中开发了一个线下平台,为了保证每次能够顺利使用,我们就把这个虚拟机导出为OVF,然后随身携带,用的时候在服务器中部署,这里就充分体现了虚拟机的缺点。 接着,容器化技术应运而生,它不需要虚拟出整个操作系统,只需要虚拟一个小规模的环境即可,而且启动速度很快,除了运行其中应用以外,基本不消耗额外的系统资源。Docker是应用最为广泛的容器技术,通过打包镜像,启动容器来创建一个服务。但是随着应用越来越复杂,容器的数量也越来越多,由此衍生了管理运维容器的重大问题,而且随着云计算的发展,云端最大的挑战,容器在漂移。在此业务驱动下,k8s问世,提出了一套全新的基于容器技术的分布式架构领先方案,在整个容器技术领域的发展是一个重大突破与创新。 那么,K8S实现了什么? 从架构设计层面,我们关注的可用性,伸缩性都可以结合k8s得到很好的解决,如果你想使用微服务架构,搭配k8s,真的是完美,再从部署运维层面,服务部署,服务监控,应用扩容和故障处理,k8s都提供了很好的解决方案。 总而言之,k8s可以使我们应用的部署和运维更加方便。 二、kubernetes特性 1.自我修复 在节点故障时可以删除失效容器,重新创建新的容器,替换和重新部署,保证预期的副本数量,kill掉健康检查失败的容器,并且在容器未准备好之前不会处理客户端情况,确保线上服务不会中断 2.弹性伸缩 使用命令、UI或者k8s基于cpu使用情况自动快速扩容和缩容应用程序实例,保证应用业务高峰并发时的高可用性,业务低峰时回收资源,以最小成本运行服务 3.自动部署和回滚 k8s采用滚动更新策略更新应用,一次更新一个pod,而不是同时删除所有pod,如果更新过程中出现问题,将回滚恢复,确保升级不影响业务 4.服务发现和负载均衡 k8s为多个容器提供一个统一访问入口(内部IP地址和一个dns名称)并且负载均衡关联的所有容器,使得用户无需考虑容器IP问题 5.机密和配置管理 管理机密数据和应用程序配置,而不需要把敏感数据暴露在径向力,提高敏感数据安全性,并可以将一些常用的配置存储在k8s中,方便应用程序调用 6.存储编排 挂载外部存储系统,无论时来自本地存储、公有云(aws)、还是网络存储(nfs、GFS、ceph),都作为集群资源的一部分使用,极大提高存储使用灵活性 7.批处理 提供一次性任务,定时任务:满足批量数据处理和分析的场景 三、kubernetes集群架构与组件 kubernetes集群架构拓补图
这是关于如何加固kubernetes集群安全的文章[1]。在测试环境下使用默认的users和service accounts的默认授权创建pods并没有问题,但是在生产环境下,这可能会导致不可预料的灾难。Kubernetes提供pod security policy用来限制users和service account的权限。
Longhorn 通过 NFSv4 服务器(share-manager)公开常规 Longhorn 卷,原生支持 RWX 工作负载。
问卷链接(https://www.wjx.cn/jq/97146486.aspx)
Kube-scheduler是Kubernetes中的一个重要组件,它负责将新创建的Pod分配到合适的Node上。在Kubernetes中,Pod是最小的可部署对象,它可以包含一个或多个容器。kube-scheduler的作用是从Kubernetes集群中可用的Node中选择一个最适合的Node来运行一个新的Pod。
如果你使用像 Gmail 这样的在线服务或者大型社交媒介和电子商务平台,你可能从来都没有遇到过哪个页面会提示你“请等待我们的应用更新完成”。
作为一个后端工程师,因为负责的大部分项目都是Web服务这类的“无状态应用”,在平时工作中接触到的最常用的Kubernetes控制器是Deployment,但是Deployment只适合于编排“无状态应用”,它会假设一个应用的所有 Pod是完全一样的,互相之间也没有顺序依赖,也无所谓运行在哪台宿主机上。正因为每个Pod都一样,在需要的时候可以水平扩/缩,增加和删除Pod。
使用Kubernetes的主要好处之一是它具有管理和维护集群中容器的能力,几乎可以提供服务零停机时间的保障。在创建一个Pod资源后,Kubernetes会为它选择worker节点,然后将其调度到节点上运行Pod里的容器。Kubernetes强大的功能可使应用程序的容器保持连续运行,还可以根据需求的增长自动扩展系统。除此之外在Pod或容器出现故障时Kubernetes还可以让系统实现"自愈"。在本文中,我们将介绍如何使用Kubernetes内置的livenessProbe和readinessProbe来管理和控制应用程序的运行状况。
kubectl debug 是 Kubernetes 中的一个命令,主要用于故障排查。这个命令允许你创建一个临时的容器,这个容器与目标容器在相同的命名空间中,这样你可以在这个临时的容器中执行各种命令,以帮助你排查问题。
版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
在上一篇中,讲解了容器持久化存储,从中我们知道什么是PV和PVC,这一篇我们讲通过StatefulSet来使用它们。
statefulset 旨在与有状态的应用及分布式系统一起使用,statefulset 中的每个 pod 拥有一个唯一的身份标识,并且所有 pod 名都是按照 {0..N-1} 的顺序进行编号。本文会主要分析 statefulset controller 的设计与实现,在分析源码前先介绍一下 statefulset 的基本使用。
本文将提供 Kubernetes 的简化视图,从高处观察其中的重要组件,以及他们的关联。
对于kubernetes集群访问,用户可以使用kubectl、客户端库或构造 REST 请求,经过kubernetes的API Server组件,访问集群资源。当请求到达 API 时,它会经历多个阶段,包括认证、鉴权和准入控制,如下图所示:
在学习k8s工作流程之前,我们得再次认识一下上篇k8s架构与组件详解中提到的kube-controller-manager一个k8s中许多控制器的进程的集合。
一般来说,智能系统和自动系统通常会通过一个“控制系统”来不断修正系统的工作状态。在Kubernetes集群中,每个Controller都是这样的一个“控制系统”,它们通过API Server提供的(List-Watch)接口实时监控集群中特定资源的状态变化,当发生各种故障导致某资源对象的状态发生变化时,Controller会尝试将其状态调整为期望的状态。
replication controller Replication Controller为Kubernetes的一个核心内容,应用托管到Kubernetes之后,需要保证应用能够持续的运行,Replication Controller就是这个保证的key,主要的功能如下: 确保pod数量:它会确保Kubernetes中有指定数量的Pod在运行。如果少于指定数量的pod,Replication Controller会创建新的,反之则会删除掉多余的以保证Pod数量不变。 确保pod健康:当pod不健康,运行出
译自 Key takeaways from the Wiz 2023 Kubernetes Security Report 。
kubernates上部署应用之后,发现删除了pod之后,还会建该pod...记录下怎么做的吧!
实例之间的不等关系以及实例对外数据有依赖关系的应用,就被称为"有状态应用"。 所谓实例之间的不等关系即对分布式应用来说,各实例,各应用之间往往有比较大的依赖关系,比如某个应用必须先于其他应用启动,否则其他应用将不能启动等。 对外数据有依赖关系的应用,最显著的就是数据库应用,对于数据库应用,我们是需要持久化保存其数据的,如果是无状态应用,在数据库重启数据和应用就失去了联系,这显然是违背我们的初衷,不能投入生产的。
我们在《Kubernetes工作负载管理》中主要介绍了无状态应用的管理,当时也有提到有状态应用,但是由于那时候还没有解释数据如何持久化就没有做深度的介绍,而在这章,我们会着重介绍如何进行有状态应用的管理。
ConfigMap Reloader 是一个 Kubernetes 的控制器,它可以监视 ConfigMap 的更改并自动更新与之关联的 Pod。当 ConfigMap 更改时,ConfigMap Reloader 将删除与之相关联的 Pod 中的卷,并重新创建一个新的 Pod,从而使应用程序使用新的配置文件。这种方法的好处是可以自动更新 Pod,无需手动更新或重启它们。
kubernetes 的出现极大的简化了应用更新和扩容的流程,在部署工作负载波动较大的应用时,我们时常会遇到几个问题:
在本文[1]中,我们将学习使用 Kubernetes 容器编排系统部署容器时的部署策略。在本文的最后,我们将学习如何在 Kubernetes 集群中使用不同的方式进行部署。如果您觉得这个话题很有趣,请继续阅读!本教程的代码可在 Github上找到[2]
Kubernetes 也称为 K8s,是用于自动部署、扩缩和管理容器化应用程序的开源系统。Kubernetes 是一个可移植、可扩展的开源平台,用于管理容器化的工作负载和服务,可促进声明式配置和自动化。Kubernetes 拥有一个庞大且快速增长的生态,其服务、支持和工具的使用范围相当广泛。Kubernetes 这个名字源于希腊语,意为“舵手”或“飞行员”。k8s 这个缩写是因为 k 和 s 之间有八个字符的关系。Google 在 2014 年开源了 Kubernetes 项目。Kubernetes 建立在 Google 大规模运行生产工作负载十几年经验的基础上, 结合了社区中最优秀的想法和实践。
在 Kubernetes 节点发生故障时,在 40 秒内(由 Controller Manager 的 --node-monitor-grace-period 参数指定),节点进入 NotReady 状态,经过 5 分钟(由 --pod-eviction-timeout 参数指定),Master 会开始尝试删除故障节点上的 Pod,然而由于节点已经失控,这些 Pod 会持续处于 Terminating 状态。
在Kubernetes PVC+PV体系下通过CSI实现的volume plugins动态创建pv到pv可被pod使用有哪些组件需要参与?
在Kubernetes中,每个容器都有自己的标准输出和标准错误输出,我们可以使用容器运行时提供的工具来采集这些输出,并将其重定向到日志文件中。例如,我们可以使用Docker提供的“docker logs”命令来查看容器的日志输出:
GitOps 是为云原生应用程序实施持续部署的推荐方式。它通过在部署应用程序时最大限度地减少手动错误来帮助组织,因为 Git 将是唯一的真实来源。因此,可以轻松地跨团队跟踪更改。
领取专属 10元无门槛券
手把手带您无忧上云