Kubernetes StatefulSets[1]自从在 1.5 中引入,并在 1.9 中变得稳定以来,已经被广泛用于运行有状态应用程序。它提供稳定的单元身份、持久的单元存储,以及有序的部署、扩展和滚动更新。你可以将 StatefulSet 视为运行复杂的有状态应用程序的原子构建块。随着 Kubernetes 的使用越来越多,需要 StatefulSets 的场景也越来越多。在你对 StatefulSets 使用 OrderedReady pod 管理策略的情况下,许多这样的场景需要比当前支持的一次一个 Pod 更新更快的滚动更新。
在《研发工程师玩转Kubernetes——利用Pod反亲和性控制一个Node上只能有一个Pod》一文中我们介绍了Pod的反亲和性应用。本节我们将使用亲和性做几个实验。 nginx Pod在每个Node上只能存在一个;alpine Pod在每个Node上只能存在一个,同时要求该Node上还要有nginx Pod。 实验分为3组:
在《研发工程师玩转Kubernetes——使用Node特性定向调度Pod》中,我们提到requiredDuringSchedulingIgnoredDuringExecution只有在规则被满足的时候才能执行调度。本节我们将测试几种边界情况,看看Kubernetes的行为。
我们在《Kubernetes工作负载管理》中主要介绍了无状态应用的管理,当时也有提到有状态应用,但是由于那时候还没有解释数据如何持久化就没有做深度的介绍,而在这章,我们会着重介绍如何进行有状态应用的管理。
实例之间的不等关系以及实例对外数据有依赖关系的应用,就被称为"有状态应用"。 所谓实例之间的不等关系即对分布式应用来说,各实例,各应用之间往往有比较大的依赖关系,比如某个应用必须先于其他应用启动,否则其他应用将不能启动等。 对外数据有依赖关系的应用,最显著的就是数据库应用,对于数据库应用,我们是需要持久化保存其数据的,如果是无状态应用,在数据库重启数据和应用就失去了联系,这显然是违背我们的初衷,不能投入生产的。
StatefulSet 旨在与有状态的应用及分布式系统一起使用。本节将通过使用 StatefulSet 部署一个简单的 Web 应用,来演示StatefulSet的常规操作,包括:
在《研发工程师玩转Kubernetes——Node失效后的Pod的调度实验》中我们看到Kubernetes会一直等待Node状态恢复。这节我们将做实验,看看Node恢复后Kubernetes的表现。 仍然借助《研发工程师玩转Kubernetes——Node失效后的Pod的调度实验》的实验过程。
Job 负责批量处理短暂的一次性任务 (short lived one-off tasks),即仅执行一次的任务,它保证批处理任务的一个或多个 Pod 成功结束。容器中的进程在正常运行结束后不会对其进行重启,而是将Pod对象置于"Completed"(完成)状态,若容器中的进程因错误而终止,则需要按照重启策略配置确定是否重启,未运行完成的Pod对象因其所在的节点故障而意外终止后会被调度。Job控制器的Pod对象的状态转换如下图所示:
DaemonSet 是K8s中相对特殊的一个控制器,即确保全部节点上运行一个 Pod 的副本。 当有节点加入集群时, 也会为他们新增一个 Pod 。 当有节点从集群移除时,这些Pod也会被回收。删除DaemonSet将会删除它创建的所有 Pod。即基于工作节点的单Pod实例,每个节点只跑一个pod
下面的清单包含Headless Service,Service,PodDisruptionBudget和StatefulSet。
Docker 是 Kubernetes Pod 中最常用的容器运行时,但 Pod 也能支持其他的容器运行,比如 rkt、podman等。
但是,单独的Pod并不能保障总是可用,比如我们创建一个nginx的Pod,因为某些原因,该Pod被意外删除,我们希望其能够自动新建一个同属性的Pod。很遗憾,单纯的Pod并不能满足需求。
在 Kubernetes 节点发生故障时,在 40 秒内(由 Controller Manager 的 --node-monitor-grace-period 参数指定),节点进入 NotReady 状态,经过 5 分钟(由 --pod-eviction-timeout 参数指定),Master 会开始尝试删除故障节点上的 Pod,然而由于节点已经失控,这些 Pod 会持续处于 Terminating 状态。
在Kubernetes中,Pod是最小的可部署对象,可以由一个或多个容器组成。在本文中,我们将介绍Pod的状态以及问题排查方法,帮助您更好地了解和管理Pod。
驱逐是指派给节点的Pod 被终止的过程。Kubernetes 中最常见的情况之一是Preemption,为了在资源有限的节点中调度新的 Pod,需要终止另一个 Pod 以释放资源。
本次演示环境,我是在本机 MAC OS 以及虚拟机 Linux Centos7 上操作,以下是安装的软件及版本:
[root@k8s-master ~]# kubectl create -f job.yaml
Pod是kubernetes的最小管理单元,在kubernetes中,按照pod的创建方式可以将其分为两类:
Kubernetes从1.2版本开始支持批处理类型的应用,我们可以通过Kubernetes Job资源对象来定义并启动一个批处理任务。
新手学习 K8s 最大的难度感觉是在起步动手实践的时候,Pod 没有正常启动起来,或者运行了一段时间 Pod 自己崩溃了。那么是什么问题导致了它没运行起来,又或者是什么因素导致了它的崩溃,这到底是道德的沦丧还是人性的扭曲。。。不好意思,拿错脚本了。
下面是一个简单的示例:在 node1 上加一个 Taint,该 Taint 的键为 key,值为 value,Taint 的效果是 NoSchedule。这意味着除非 pod 明确声明可以容忍这个 Taint,否则就不会被调度到 node1 上
取消注释,并修改成与前面kubeadm init的 --pod-network-cidr(10.244.0.0/16)指定的一样。
在《研发工程师玩转Kubernetes——Node失效后恢复的实验》中,有一次Pod被分配到Master Node——UbuntuA上。进一步的实验需要我们关闭其所在的Node,而Master Node又不能关闭,否则我们将无法对Kubernetes进行操作。这个时候我只能使用Pod调度技法来将其从Master Node上驱逐。
混沌工程是在分布式系统上进行实验的学科,目的是建立对系统抵御生产环境中失控条件的能力以及信心。
K8S是一个开源的,用于管理云平台中多个主机上的容器化应用,Kubernetes的目标是让部署容器化变得简单并且高效
除了deployment是v1的升级版,其他的基本都是v1。 # kubectl api-versions
参考:https://kubernetes.io/docs/tutorials/stateful-application/basic-stateful-set/
Kuberhealthy 是对 Prometheus 的一种补充监控方案,通过 Operator 来控制状态,你可以对 Kubernetes 的资源进行聚合监控,比如:
在mac上学习k8s,minikube 和docker for mac 是不错的选择,二者环境搭建相对简单,都是一个单节点的最小系统,方便大家快速学习。在https://mp.weixin.qq.com/s/0kOa1SXsUKoaYuCvlsli-w 中介绍了如何在mac(m1 也可以)上搭建docker for mac,下面我们学习下如何安装kubernetes-dashboard。
Banzai logging operator 已经出到了 v3 版本。这个项目以 Fluentd 为基础,使用 Operator 的实现模式,在 Kubernetes 上用 CRD 的形式,对日志的采集行为进行定制,并进行过滤、路由等操作,最终可以将日志输出到 Elasticsearch、Loki、S3、Kafka 等多种后端。
描述:在学习任何一门新技术总是免不了坑坑拌拌,当您学会了记录坑后然后将其记录当下次遇到,相同问题的时候可以第一时间进行处理;
通过 kubectl get pods -n kube-system 查看pods状态
1、部署Cluster DNS 1.1 原理:(看看吧,摘抄网上的↓) 通过前面对Kubernetes的讨论(Kubernetes核心概念总结).我们已经知道,每个Kubernetes service都绑定了一个虚拟IP 地址(ClusterIP),而且Kubernetes最初使用向pod中注入环境变量的方式实现服务发现,但这会带来环境变量泛滥等问题。故需要增加集群DNS服务为每个service映射一个域名。到Kubernetes v1.2版本时,DNS作为一个系统可选插件集成到Kubernetes集群中。
由于最近在学习微服务,所以就基于之前docker的基础上把玩一下k8s(Kubernetes),以了解基本概念和核心功能。
Horizontal Pod Autoscaler 可以根据CPU利用率自动伸缩 replication controller、deployment 和 replica set 中的Pod数量(除了 CPU 利用率)也可以 基于其他应程序提供的度量指标custom metrics。pod 自动缩放不适用于无法缩放的对象,比如 DaemonSets
大家在使用 Kubernetes 时,会遇到创建Pod失败,这时会分析什么原因导致创建Pod失败?
1 3个节点: k8s-master k8s-node1 k8s-node2 2 yum install -y docker 3 所有节点安装kubelet kubeadm kubectl 4 master执行:105为MASTER的IP,网络方案是flannel kubeadm init --apiserver-advertise-address 192.168.56.105 --pod-network-cidr=l0.244.0.0/16 5 master配置kubectl,不要用root用户 su - ubuntu mdkir -p xx/.kube sudo cp -i /etc/kubernetes/admin.conf xx/.kube/config sudo chown ubuntu:root xx/.kube/config echo "source <(kubectl completion bash)" >>~/.bashrc 6 master安装pod网络(使用flannel) kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml 7 查看token: kubeadm token list 8 两台node注册到master kubeadm join --token xxxxxx masterip:6443 9Master上查看node kubectl get nodes
StatefulSet副本启动顺序按照名称0,1,2,只有web-0完全启动之后才会启动web-1,web-1完全启动之后才会启动web-2
版权声明:本文为耕耘实录原创文章,各大自媒体平台同步更新。欢迎转载,转载请注明出处,谢谢
k3s 是由 Rancher Labs 于2019年年初推出的一款轻量级 Kubernetes 发行版,满足在边缘计算环境中运行在 x86、ARM64 和 ARMv7 处理器上的小型、易于管理的 Kubernetes 集群日益增长的需求。
Rancher是一套容器管理平台,它可以帮助组织在生产环境中轻松快捷的部署和管理容器。 Rancher可以轻松地管理各种环境的Kubernetes,满足IT需求并为DevOps团队提供支持。
容器实例服务(Container Instance Service , CIS)可以帮您在云上快捷、灵活的部署容器,让您专注于构建程序和使用容器而非管理设备上。无需预购 CVM,您就可以在几秒内启动一批容器来执行任务。您也可以通过 kubernetes API 把已有 kubernetes 集群的 pod 调度到 CIS 上以处理突增业务。CIS 根据您实际使用的资源计费,可以帮您节约计算成本。使用 CIS 可以极大降低您部署容器的门槛,降低您执行 batch 型任务或处理业务突增的成本。
问题描述:查看pod日志报错,Normal Killing 39s (x735 over 15h) kubelet, 10.179.80.31 Killing container with id docker://apigateway:Need to kill Pod,可能是磁盘满了,无法创建和删除 pod
上一篇文章中,我们讲了deployment的编排技术,也提到了这种编排技术只能编排无状态的pod。但是在我们实际生产环境中,系统复杂很多。比如分布式系统,pod之间往往有依赖关系。再比如mysql数据库,主从节点需要通过binlog同步数据,读写请可能要求发送到不同节点上。对这种有状态的应用,kubernete的解决方案是StatefulSet。
Pod是Kubernetes中能够创建和部署的最小单元,是Kubernetes集群中的一个应用实例,总是部署在同一个节点Node上。Pod中包含了一个或多个容器,还包括了存储、网络等各个容器共享的资源。Pod支持多种容器环境,Docker则是最流行的容器环境。
健康检查(Health Check)是让系统知道您的应用实例是否正常工作的简单方法。 如果您的应用实例不再工作,则其他服务不应访问该应用或向其发送请求。 相反,应该将请求发送到已准备好的应用程序实例,或稍后重试。 系统还应该能够使您的应用程序恢复健康状态。
领取专属 10元无门槛券
手把手带您无忧上云