读书笔记 | Kubernetes in Action

微信扫一扫,分享到朋友圈

读书笔记 | Kubernetes in Action

1 Kubernetes介绍

Kubernetes(以下简称K8s) 是一个部署和管理容器化应用的软件系统。它将底层基础设施抽象,简化了应用的开发、部署,以及对开发和运维团队的管理。

K8s由一个主节点和若干工作节点组成。开发者把应用描述提交到主节点,K8s会将描述中包含的容器镜像部署到集群的工作节点,开发者可以指定某些应用必须在一个工作节点一起运行(例如上图五边形和三角形应用),否则将被分散部署到集群中。

2 在K8s中运行应用

2.1 运行容器

pod

K8s处理应用描述时,会指示容器运行时(例如Docker)拉取所需的镜像并运行容器。但是,K8s并不直接处理单个容器,它的基本构建模块称为pod。

一个pod是一组紧密相关的容器,总是一起运行在同一个工作节点上。使用这种方式,可以让每个应用进程运行与自己的容器中,不相关的应用互相隔离,而密切相关的进程又可以作为一个单元进行管理。

pod的YAML描述文件类似如下:

可以使用命令 kubectl create -f kubia-manual.yaml 创建一个pod。

下面是一些常用命令:

kubectl get po kubia-manual  –o  yaml	 #查看描述
kubectl get pods 	#列出pod
kubectl logs kubia-manual 	#查看日志
kubectl delete po kubia-manual 	#删除pod

Job

一般pod都是持续运行的,即使容器内的进程执行结束,也会被调度重启,永远没有完成状态。而Job用于运行完成工作后就终止的情况。

Job会创建一种pod,该pod在内部进程成功结束时,不重启容器,pod将处于完成状态。由Job管理的pod,如果在节点上异常退出,会一直被重新安排,直到它完成任务。因此,需要保证任务是幂等的。

Job的YAML描述文件类似如下:

下面是一些常用描述:

  • restartPolicy——需要明确设置重启策略为OnFailure或Never(默认为Alwayse);
  • completions——需要一个Job运行的次数;
  • parallelism——同一Job并行运行的pod数量;
  • activeDeadlineSeconds——限制pod运行时间,超过将尝试终止pod,并将pod标记为失败;
  • backoffLimit——标记为失败前可重试次数,默认为6;

下面是一些常用命令:

kubectl get jobs 	#列出Job

CronJob

CronJob是一种特殊的Job,用于在特定时间执行任务,或者在指定的时间间隔内重复运行。

CronJob的YAML描述文件类似如下:

下面是一些常用描述:

  • restartPolicy——cron表达式;
  • jobTemplate——创建任务资源;
  • startingDeadlineSeconds——指定最迟必须在预定时间多少秒后开始运行,如未运行,任务将不会运行,并将显示为Failed;

2.2 保持容器运行

Probe

一旦程序运行起来,K8s定期对pod进行状态诊断,监控应用是否停止了工作,这种机制称为探针(Probe)。

有三种探针:

initialDelaySeconds

livenessProbe的YAML描述文件类似如下:

每种探针有三种探测机制:

  • httpGet——对指定的端口和路径执行HTTP GET 请求,如果响应状态码不是2xx和3xx则探测失败;
  • tcpSocket——与指定端口建立TCP连接,如果连接失败则探测失败;
  • exec——在容器内执行任意命令,如果命令的退出状态码不是0则探测失败;

ReplicaSet

如果pod停止工作,K8s会重新启动它们,但是如果工作节点故障,那么节点上的pod将会丢失。

ReplicaSet通常用来保证给定数量的、完全相同的 pod 的可用性,K8s会持续监控由ReplicaSet创建的正在运行的pod列表,并保证相应类型的pod的数目与期望相符。

ReplicaSet的YAML描述文件类似如下:

下面是一些常用描述:

  • replicas——指定pod实例的目标数目;
  • selector.matchLabels——匹配pod的标签,还可以用matchExpressions属性重写选择器;

下面是一些常用命令:

kubectl get rs 	#列出ReplicaSet
kubectl describe rs 	#描述ReplicaSet

Deployment

当需要更新运行在pod的应用程序时,如何保证一组pod的实例正常运行?答案就是Deployment。

Deployment用于部署应用程序并以声明的方式升级应用。Deployment由ReplicaSet组成,并由它接管Deployment的pod。使用Deployment可以直接定义单个Deployment资源需要达到的状态,并让K8s处理中间的状态。

Deployment的YAML描述文件类似如下:

升级需要做的就是在pod模板中修改镜像的tag,K8s会收敛系统,匹配期望的状态。

下面是一些常用描述:

  • maxSurge——期望的副本数之外,最多允许超出的pod实例数量;
  • maxUnavailable——相对于期望副本数,能够允许有多少pod实例处于不可用状态;
  • minReadySeconds——指定新创建的pod至少要运行多久之后,才能将其视为可用;
  • progressDeadlineSeconds——判定滚动升级失败的超时时间;

2.3 迁移容器

Service

容器可能会重启,或者增加、停止pod副本,如果容器需要给集群中的其他容器或外部客户端提供使用,如何让客户端发现正确的pod并与之通信?

K8s服务是一种为一组功能相同的pod提供单一不变的接入点的资源。当服务存在时,它的IP地址和端口不会改变。

客户端不需要知道单独pod的地址,始终通过服务的IP地址和端口号建立连接。

Service的YAML描述文件类似如下:

下面是一些常用描述:

  • sessionAffinity——设置成ClientIP让特定客户端产生的请求每次都指向同一个pod;

K8s为客户端提供了多种服务发现方式:

  • 环境变量——创建了kubia服务,环境变量中有KUBIA_SERVICE_HOST和 KUBIA_SERVICE_PORT ,分别代表了 kubia 服务的 IP 地址和端口号;
  • 将服务类型设为NodePort——每个集群节点都会打开一个端口;
  • 将服务类型设为LoadBalance——通过一个专用的负载均衡器访问;
  • 创建Ingress资源——它运行在HTTP层,可以将不同的服务映射到相同主机的不同路径;

requests和limits

开发人员通常不关心应用程序运行在哪台服务器上,只要服务器能够为应用程序提供足够的系统资源。

可以指定容器对CPU和内存的资源请求量(requests)和资源限制量(limits),确保pod公平地使用K8s集群资源,同时也影响着整个集群pod的调度方式。

requests的YAML描述文件类似如下:

调度器只关注节点上部署的所有pod的资源requests之和,并不关注实际使用量。另外,CPU requests不仅仅在调度时起作用,也决定了未使用的CPU时间在容器之间会按照CPU requests比例分配。

limits的YAML描述文件类似如下:

所有limits的总和可以超过节点资源的总量的100%——即超卖。如果节点使用量超过100%,一些容器将被杀掉。

在一个超卖的系统,QoS等级决定了哪个容器第一个被杀掉(BestEffort->Burstable->Guaranteed)。

HPA

指望靠人工干预来处理不可预测的流量增长不太现实,K8s可以检测CPU使用率或其他度量增长时自动对它扩容。

HorizontalpodAutoscaler (HPA)资源启用和配置Horizontal控制器,该控制器周期性检查pod度量, 计算满足HPA资源所配置的目标数值所需的副本数量, 进而调整目标资源的replicas字段。

HPA的YAML描述文件类似如下:

微信扫一扫,分享到朋友圈

读书笔记 | Kubernetes in Action

猜猜 Netflix 是怎么拍《三体》的?

上一篇

Vaex :突破pandas,快速分析100G大数据量

下一篇

你也可能喜欢

读书笔记 | Kubernetes in Action

长按储存图像,分享给朋友