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的重启策略；