码迷,mamicode.com
首页 > 其他好文 > 详细

k8s实战读书笔记

时间:2017-04-17 00:11:44      阅读:237      评论:0      收藏:0      [点我收藏+]

标签:请求转发   进程管理   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。

二、k8s服务发现

  • 环境变量  ---  存在局限性
  • DNS    

    当有新的Service创建时,就会自动生成一条DNS记录,以Redis Master Service为例,有一条DNS记录:

      redis-master   => 10.254.233.212

    使用这种服务发现,k8s集群必须安装Cluster DNS

三、Pod与容器

  在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的网络

  Pod中的所有容器网络都是共享的,一个Pod中的所有容器中的网络是一致的,他们能够通过本地地址(localhost)访问其他用户容器的端口。

  在k8s网络模型中,每一个Pod都拥有一个扁平化共享网络命名空间的IP,称为PodIP,通过PodIP,Pod就能够跨网络与其他物理机和容器进行通信;

五、Pod的生命周期

  Pod的生命周期可描述为:首先Pod被创建,Pod被调度到Node进行部署运行。Pod是十分忠诚的,一旦被分配到Node后,就不会离开这个Node,直到它被删除,生命周期完结;

  • Pending: Pod已经被创建,但是一个或者多个容器还未创建,这包括Pod调度阶段,以及容器image下载过程;
  • Running:Pod已经被调度到Node,所有容器已经创建,并且至少一个容器在运行或者重启;
  • Succeeded:Pod中石油容器正常退出;
  • Failed: Pod中所有容器退出,至少有一个容器是一次退出的。  

 

k8s实战读书笔记

标签:请求转发   进程管理   cluster   更新   代理   应用   tar   寻址   fail   

原文地址:http://www.cnblogs.com/chris-cp/p/6720497.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!