k8s实战读书笔记

Posted 阳台

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了k8s实战读书笔记相关的知识,希望对你有一定的参考价值。

一、概述

  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中所有容器退出,至少有一个容器是一次退出的。  

 六、RC —— ReplicationController

  RC和Pod的关联就是通过Label实现的,Label机制是k8s中很重要的一个设计,通过Label进行对象的弱关联,可以灵活地进行分类和选择。

  对于Pod,需要设置Label来进行标示,Label是一系列的Key/Value对, Pod(或者Pod模板)的定义中通过.metadata.labels设置:

    labels:

      key1: value1

      key2: value2

  对于Replication Controller来说就是通过Label Selector来匹配Pod的Label,从而实现关联关系。在RC的定义中通过.spec.selector来设置Label Selector;

  弹性伸缩:

    #kubectl get replicationcontroller my-nginx
    #kubectl get pod --selector app=nginx
    #kubectl scale replicationcontroller my-nginx --replicas=3
    #kubectl scale replicationcontroller my-nginx [--current-replicas=2] --replicas=1
    #kubectl scale replicationcontroller my-nginx --replicas=0

  自动伸缩:

    在k8s中通过Horizontal Pod Autoscaler来实现Pod的自动伸缩, Horizontal Pod Autoscaler同Replication Controller是一一对应的;Horizontal Pod Autoscaler将定时从平台监控系统中获取Replication Controller关联Pod的整体资源使用情况。当策略匹配的时候,通过Replication Controller来调整Pod的副本数,实现自动伸缩。

  滚动升级:

    #kubectl rolling-update my-web-v1 -f my-web-v2-rc.yaml --update-period=10s 

    #kubectl rolling-update my-web-v1 -f my-web-v2-rc.yaml --update-period=10s  --rollback   #升级回滚

七、Deployment  

    k8s提供了一种更加简单的更新Replication Controller 和 Pod 的机制,叫做Deployment

八、Job  

  RC创建的Pod都是长时运行服务,相应的,k8s提供了另一种机制, Job来管理一次性任务的Pod; ----------  两者在yaml的最大区别是关于Pod的重启策略;

以上是关于k8s实战读书笔记的主要内容,如果未能解决你的问题,请参考以下文章

《SpringBoot实战派》读书笔记

《Effective Objective-C 2.0》读书/实战笔记 三

k8s 读书笔记 - kubernetes 基本概念和术语(上)

k8s 读书笔记 - kubernetes 基本概念和术语(下)

读书笔记——《Maven实战》

k8s 读书笔记 - kubectl 命令行工具用法详解