标签:请求转发 进程管理 cluster 更新 代理 应用 tar 寻址 fail
kubernetes中Service是真实应用的抽象,将用来代理Pod,对外提供固定IP作为访问入口,这样通过访问Service便能访问到相应的Pod,而对访问者来说只需知道Service的访问地址,而不需要感知Pod的变化;
Service是通过Label来关联Pod的,在Service的定义中,设置 .spec.selector为name=redis-master,将关联上Pod;
#kubectl get service redis-master
NAME CLUSTER_IP EXTERNAL_IP PORT(S) SELECTOR AGE
redis-master 10.254.233.212 <none> 6379/TCP 13s
Redis Master Service 的查询信息中的显示属性CLUSTER_IP为10.254.233.212, 属性PORT(S)为6379/TCP, 其中10.254.233.212是Kubernetes分配给Redis Master Service的属性IP,6379/TCP则是Service会转发的端口(通过Service定义文件中的.spec.ports[0].port指定),Kubernetes会将所有访问10.254.233.212:6379的TCP请求转发到Redis Master Pod中,目标端口是6379/TCP(通过Service定义文件中的spec.ports[0].targetPort指定)。
因为创建了Redis Master Service来代理Redis Master Pod,所以Redis Slave Pod通过Redis Master Service的虚拟IP 10.254.233.212就可以访问到Redis Master Pod,但是如果只是硬配置Service的虚拟IP到Redis Slave Pod中,这样还不是真正的服务发现,Kubernetes提供了两种发现Service的方法;
note: 如何在外部网络中访问Redis Master Service呢?
因为Service的虚拟IP是由k8s虚拟出来的内部网络,而外部网络是无法寻址的,这时候就需要增加一层网络转发,即外网到内网的转发。实现方式有很多种,我们这里采用一种叫作NodePort的方式来实现,即k8s将会在每个Node上设置端口,称为NodePort,通过NodePort端口可以访问到Pod。
当有新的Service创建时,就会自动生成一条DNS记录,以Redis Master Service为例,有一条DNS记录:
redis-master => 10.254.233.212
使用这种服务发现,k8s集群必须安装Cluster DNS
在Docker中,容器是最小处理单位,增删改查的对象是容器,容器是一种虚拟化技术,容器之间是隔离的,隔离是基于Linux Namespace实现的,Linux内核中提供了6中Linux Namespace隔离的系统调用,如下图:
在k8s中,Pod包含了一个或者多个相关的容器,Pod可以认为是容器的一种延伸扩展,一个Pod也是一个隔离体,而Pod包含一组容器优势共享的(当前共享的Linux Namespace 包括:PID, Network, IPC和UTS)。除此之外,Pod中的容器可以访问共同的数据卷来实现文件系统的共享,所以k8s中的数据卷是Pod级别的,而不是容器级别的;
Pod是容器的集合,容器是真正的执行体。相比原生的容器接口,Pod提供了更高层次的抽象,但是Pod的设计并不是为了运行同一个应用的多个实例,而是运行一个应用多个紧密联系的程序。而每个程序运行在单独的容器中,以Pod的形式组合成一个应用。相比于在单个容器中运行多个程序,这样的设计有以下好处:
Pod中的所有容器网络都是共享的,一个Pod中的所有容器中的网络是一致的,他们能够通过本地地址(localhost)访问其他用户容器的端口。
在k8s网络模型中,每一个Pod都拥有一个扁平化共享网络命名空间的IP,称为PodIP,通过PodIP,Pod就能够跨网络与其他物理机和容器进行通信;
Pod的生命周期可描述为:首先Pod被创建,Pod被调度到Node进行部署运行。Pod是十分忠诚的,一旦被分配到Node后,就不会离开这个Node,直到它被删除,生命周期完结;
标签:请求转发 进程管理 cluster 更新 代理 应用 tar 寻址 fail
原文地址:http://www.cnblogs.com/chris-cp/p/6720497.html