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实战读书笔记的主要内容,如果未能解决你的问题,请参考以下文章
《Effective Objective-C 2.0》读书/实战笔记 三
k8s 读书笔记 - kubernetes 基本概念和术语(上)