(1). Pod
Docker鼓励:一个容器一个进程(也对应着一个应用)(one process per container),不建议一个容器内部N个进程.为什么这样设计? 因为:每一个Docker容器创建时,所运行的第一个应用,它的PID为1,而,在这个容器内运行的其它应用,属于PID为1的子进程, 如果PID为1的父进程出现问题(Carsh),那么相应的子程进也会Carsh.
那么问题就来了,我们要是有相关的应用,它们之间有联系怎么办?比如:nginx用来提供服务,flume用来采集nginx日志.这两个应用之间需要共享存储. 所以,K8S才会设计Pod的存在,让相关密切的容器运行在同一个Pod内,它们共享存储和网络空间.
总结:
- Pod是K8S的最小部署单元.它可以由一组容器的集合.
- 在一个Pod中的容器共享网络命名空间,也可以共享存储.
(2). Controller
Controller存在的意义是为了更高层次的部署和管理Pod.
ReplicaSet : 确保预期的Pod副本数量.
Deployment : 无状态应用部署.
StatefulSet : 有状态应用部署.
DaemonSet : 确保在所有的Node运行一个Pod(比如:Ingress/logstash…).
Job : 一次性任务.
Cronjob : 定时任务.(3). Service
当你向K8S部署一个应用(App)时(配置replicas大于1时),应用会部署在多个Pod上(Pod有可能会随着环境运行情况失联,或重建,IP发生变化).
如果要访问Pod中的应用服务,那么该怎么办呢?
所以:就诞生了:Service.通过Service来提供对Pod的控制(访问).
Service有点类似于Nginx,它能动态感知一组Pod的信息(nginx upstream),并提供请求路由和负载均衡.
Service是如何与Pod进行关联:
Service通过selector.app的value(hello-world)与Pod中的template.metadata.labels.app的value(hello-world)进行关联.
(4). Label
标签,附加到某个资源上,用于关联对象,查询和筛选(过滤).
(5). Namespace
命名空间,将集群上的资源从逻辑上隔离.
