文章目录
六、Kubernetes Workloads(Kubernetes 作业管理)
1.Pod
1.1 容器设计模式
设计模式
在程序设计领域,面向对象设计和面向对象语言是大家最为熟悉和强大的工具,而面向对象除了其强大的核心特性之外,还有人们通过实践总结出来的一系列设计模式,可以用来解决实际应用设计中的一些复杂问题。
云原生应用运行的环境都是复杂的分布式环境,在这种情况下,一些有用的设计模式可以起到四两拨千斤的作用,而K8s社区推出的容器设计模式,则是结合了K8s集群的微服务模型提出的一系列可重用的解决典型分布式系统问题的模式。目前K8s社区推出的容器设计模式主要分为三大类
1.1.1 单容器管理模式
单容器微服务
kubectl run nginx --image=nginx
1.1.2 单节点多容器模式
1.1.2 (1)挎斗模式(sidecar pattern)
通过在Pod里定义专门容器,来执行主业务容器需要的辅助功能
-
- 案例:WAR 包与 Web 服务器
有一个 Java Web 应用的 WAR 包,它需要被放在 Tomcat 的 webapps 目录下运行起来。
方法1
把WAR包和Tomcat打包进一个镜像
无论是WAR更新和Tomcat更新都需要重新制作镜像
方法2
镜像里只打包Tomcat,用数据卷在宿主机上将WAR包挂载进Tomcat容器
pod解决
apiVersion: v1
kind: Pod
metadata:
name: javaweb-2
spec:
initContainers:
- image: sample:v2
name: war
command: ["cp", "/sample.war", "/app"]
volumeMounts:
- mountPath: /app
name: app-volume
containers:
- image: tomcat:7.0
name: tomcat
command: ["sh","-c","/root/apache-tomcat-7.0.42-v2/bin/start.sh"]
volumeMounts:
- mountPath: /root/apache-tomcat-7.0.42-v2/webapps
name: app-volume
ports:
- containerPort: 8080
hostPort: 8001
volumes:
- name: app-volume
emptyDir: {}
其中:
initContainers
-
InitContainer会比spec.containers定义的用户容器先执行,并且严格按照定义的顺序依次执行
-
/app是个Volumn
-
Tomcat容器同样挂载了该Volumn到自己的webapps目录下
-
当Tomcat容器启动时,它的webapp目录下就一定会有sample.war
-
- 案例:容器的日志收集
现在有一个应用,需要不断地把日志文件输出到容器的 /var/log 目录中,怎么实现
-
业务容器将日志写在Volume里
-
日志容器共享该Volumn从而将日志转发到远程存储当中
Fluentd等
1.1.2 (2)外交官模式(Ambassador pattern)
-
这种模式主要利用同一Pod中的容器可以共享网络地址空间的特性。
-
- 案例:基于外交官模式的Redis访问案例
1.1.2 (3)适配器模式(Adapter pattern)
这种模式对于监控和管理分布式系统尤为重要。对分布式系统的一种理想设计目标,就是能够实现“分布地执行和存储,统一的监控和管理”。要想实现“统一的监控和管理”,应用和监控管理交互的接口需要是统一的,而且其接口是依照“统一的监控服务”的接口模式来实现。这和面向对象设计模式中的“适配器模式”也非常相似。
-
- 案例:prometheus监控组件
1.1.3 多节点多容器模式
1.1.3 (1)选举模式(Election pattern)
是一种多节点组合服务模式。一个可重用的选举器容器跟应用容器组合起来,提供为在分布式系统中的多个应用实例选举主控节点的问题。
1.1.3 (2)工作队列模式(Work queue pattern)
是一种多节点组合服务模式。应用容器跟可重用的队列消息处理器,共同工作,可以并行地处理队列中海量的同类型并行计算业务。
1.1.3 (3)分散收集模式(Scatter/gather pattern)
是一种多节点组合服务模式,通过先将大任务分割成诸多小任务处理,在收集汇总合并产生最终结果的模式,支持复杂任务的分布式计算。
1.2 pod的实现原理
Pod 里的所有容器,共享的是同一个 Network 、UTS、IPC、USER Namespace,并且可以声明共享同一个 Volume。
docker run --net=B --volumes-from=B --name=A image-A …
参考文章:https://www.cnblogs.com/rexcheny/p/11017146.html
- infra/pause容器
- k8s.gcr.io/pause
Pod 的实现需要使用一个中间容器,这个容器叫作 Infra 容器。在这个 Pod 中,Infra 容器永远都是第一个被创建的容器,而其他用户定义的容器,则通过 Join Network Namespace 的方式,与 Infra 容器关联在一起。
1.3 引入Pod的目的
-
可管理型
有些容器天生就是需要紧密联系,一起工作。Pod提供了比容器更高层次的抽象,将他们封装到一个部署单元中。Kubernetes以Pod为最小单位进行调度、扩展、共享资源、管理生命周期
-
通信和资源共享
Pod中的所有容器共享同一个网络namespace,即相同的IP和Port空间,他们可以直接使用localhost来通信,同样,这些容器可以共享存储,当k8s挂载volume到pod实质是把volume挂载到Pod的所有容器中。
1.4 Pod两种运行方式
-
单一容器
一个pod一个容器
-
多个容器
一个pod多个容器
1.5 问题
-
哪些容器应该放到一个Pod中?
这些容器联系紧密,而且需要直接共享资源
例如
File Server + Web Server
-
File Server定期拉取文件到volume
-
Web Server从Volume读取文件响应Clinet请求