KUBERNETES资源对象POD、REPLICASET、DEPLOYMENT、SERVICE之间的关系

Pod、ReplicaSet、Deployment、Service之间的关系如下图

KUBERNETES资源对象POD、REPLICASET、DEPLOYMENT、SERVICE之间的关系_第1张图片

Pod:

Pod是一个或多个容器的组合,这些容器共享存储、网络和命名空间,以及如何运行的规范。Pod是Kubernetes的最小可部署单元。Pod的中文译词是豌豆荚,docker容器就像是豆子运行在豌豆荚内。

ReplicaSet:
先说下Replication Controller。Replication Controller的作用是确保Pod以指定的副本个数运行。
ReplicaSet是Replication Controller升级版。ReplicaSet和Replication Controller之间的唯一区别是对选择器支持。Replication Controller只支持基于等式的selector(env=dev或environment!=qa),但ReplicaSet还支持新的,基于集合的selector(version in (v1.0,v2.0)或env notin (dev, qa))。
在yaml文件中通过spec.replicas声明pod的副本数。

Deployment:
Deployment用于管理Pod、ReplicaSet,可实现滚动升级和回滚应用、扩容和缩容。

Service:
试想一个问题,ReplicaSet定义了pod的数量是2,当一个pod由于某种原因停止了,ReplicaSet会新建一个pod,以确保运行中的pod数量始终是2。但每个pod都有自己的ip,前端请求不知道这个新pod的ip是什么,那前端的请求如何发送到新pod中呢?
答案是使用Service
k8s的Service定义了一个服务的访问入口地址,前端的应用通过这个入口地址访问其背后的一组由Pod副本组成的集群实例,来自外部的访问请求被负载均衡到后端的各个容器应用上。Service与其后端Pod副本集群之间则是通过Label Selector实现关联。
请说人话:前端请求不是直接发送给Pod,而是发送到Service,Service再将请求转发给pod。

总结一下:Pod被ReplicaSet管理,ReplicaSet控制pod的数量;ReplicaSet被Deployment管理,Deployment控制pod应用的升级、回滚,当然也能控制pod的数量。Service提供一个统一固定入口,负责将前端请求转发给Pod。

实践环节

定义一个myapp.yaml文件

apiVersion: apps/v1
# 声明一个Deployment资源对象
kind: Deployment
metadata:
  name: deployment-myapp
spec:
# 通过replicas声明pod个数是2  
  replicas: 2
# 通过标签选择被控制的pod    
  selector:
    matchLabels:
      app: myapp
# 在template中定义pod      
  template:
    metadata:
# 给pod打上标签app=myapp    
      labels:
        app: myapp
    spec:
      containers:
# 声明容器名称,注意不是pod名称,pod名称应该定义在metadata中
      - name: myapp
        image: ikubernetes/myapp:v1
        ports:
        - name: http
          containerPort: 80
# 在一个yaml文件中通过---分割多个资源对象          
---
apiVersion: v1
# 声明一个Service资源对象
kind: Service
metadata:
  name: service-myapp
spec:
# service-myapp将选择标签包含app=myapp的pod
  selector:
    app: myapp
  ports:
  - name: http
# Service监听端口  
    port: 80
# 转发到后端Pod的端口号   
    targetPort: 80

部署这个资源清单 

kubectl apply -f myapp.yaml

先看一个很有意思的图片

KUBERNETES资源对象POD、REPLICASET、DEPLOYMENT、SERVICE之间的关系_第2张图片

myapp.yaml文件声明了deployment的名称,没声明ReplicaSet、Pod的名称。但kubernetes会自动给ReplicaSet、Pod起名称。

Deployment名称是deployment-myapp

ReplicaSet名称是deployment-myapp-5fdb5f69f,实际上是Deployment名称加上pod-template的hash值

Pod名称是deployment-myapp-5fdb5f69f-njrb6、deployment-myapp-5fdb5f69f-whpwg,实际上是ReplicaSet的名称加上一个hash值。

使用  kubectl describe svc service-myapp   命令看下service-myapp的详细信息。

KUBERNETES资源对象POD、REPLICASET、DEPLOYMENT、SERVICE之间的关系_第3张图片

可以看到service-myapp的ip地址是10.97.41.88。发送到10.97.41.88:80的请求会被转发给10.244.1.5:80或10.244.2.2:80

看下图:

KUBERNETES资源对象POD、REPLICASET、DEPLOYMENT、SERVICE之间的关系_第4张图片

先直接请求pod,获取pod的hostname

curl 10.244.1.5:80/hostname.html

curl 10.244.2.2:80/hostname.html

然后请求service-myapp,service-myapp会把请求负载给后端的pod

curl 10.97.41.88:80/hostname.html

还有一个很有意思的事情。pod能ping通,但是servic却ping不通

KUBERNETES资源对象POD、REPLICASET、DEPLOYMENT、SERVICE之间的关系_第5张图片

这是为什么呢?

答案:因为Service其实是iptables或ipvs的转发规则,这规则不支持ICMP协议,所以就ping不通咯。

你可能感兴趣的:(自动化运维,容器技术,kubernetes,容器,云原生)