Kubernetes

1. Kubernetes介绍

基本概念

• Pod 
  Pod是Kubernetes的基本操作单元，把相关的一个或多个容器构成一个Pod，通常Pod里的容器运行相同的应用。Pod包含的容器运行在同一个Node(Host)上，看作一个统一管理单元，共享相同的volumes和network namespace/IP和Port空间。
• Replication Controller 
  Replication Controller确保任何时候Kubernetes集群中有指定数量的pod副本(replicas)在运行， 如果少于指定数量的pod副本(replicas)，Replication Controller会启动新的Container，反之会杀死多余的以保证数量不变。Replication Controller使用预先定义的pod模板创建pods，一旦创建成功，pod 模板和创建的pods没有任何关联，可以修改pod 模板而不会对已创建pods有任何影响，也可以直接更新通过Replication Controller创建的pods。对于利用pod 模板创建的pods，Replication Controller根据label selector来关联，通过修改pods的label可以删除对应的pods。
• Service 
  Service也是Kubernetes的基本操作单元，是真实应用服务的抽象，每一个服务后面都有很多对应的容器来支持，通过Proxy的port和服务selector决定服务请求传递给后端提供服务的容器，对外表现为一个单一访问接口，外部不需要了解后端如何运行，这给扩展或维护后端带来很大的好处。
• Label 
  Label是用于区分Pod、Service、Replication Controller的key/value键值对，Pod、Service、 Replication Controller可以有多个label，但是每个label的key只能对应一个value。Labels是Service和Replication Controller运行的基础，为了将访问Service的请求转发给后端提供服务的多个容器，正是通过标识容器的labels来选择正确的容器。同样，Replication Controller也使用labels来管理通过pod 模板创建的一组容器，这样Replication Controller可以更加容易，方便地管理多个容器，无论有多少容器。

架构

Kubernets属于主从的分布式集群架构，包含Master和Node：

1. Master作为控制节点，调度管理整个系统，包含以下组件：组件构成，包括Master节点上的kube-apiserver、kube-scheduler、kube-controller-manager、控制组件kubectl、状态存储etcd、Slave节点上的kubelet、kube-proxy，以及底层的网络支持（可以用Flannel、OpenVSwitch、Weave等）

   • API Server作为kubernetes系统的入口，封装了核心对象的增删改查操作，以RESTFul接口方式提供给外部客户和内部组件调用。它维护的REST对象将持久化到etcd(一个分布式强一致性的key/value存储)。
   • Scheduler：负责集群的资源调度，为新建的pod分配机器。这部分工作分出来变成一个组件，意味着可以很方便地替换成其他的调度器。
   • Controller Manager：负责执行各种控制器，目前有两类：（1）Endpoint Controller：定期关联service和pod(关联信息由endpoint对象维护)，保证service到pod的映射总是最新的。（2）Replication Controller：定期关联replicationController和pod，保证replicationController定义的复制数量与实际运行pod的数量总是一致的。

2. Node是运行节点，运行业务容器，包含以下组件：

   • Kubelet：责管控docker容器，如启动/停止、监控运行状态等。它会定期从etcd获取分配到本机的pod，并根据pod信息启动或停止相应的容器。同时，它也会接收apiserver的HTTP请求，汇报pod的运行状态。
   • Kube Proxy：负责为pod提供代理。它会定期从etcd获取所有的service，并根据service信息创建代理。当某个客户pod要访问其他pod时，访问请求会经过本机proxy做转发。

   Kubernets使用Etcd作为存储和通信中间件，实现Master和Node的一致性，这是目前比较常见的做法，典型的SOA架构，解耦Master和Node。

3.  

   工作流

   　　上文已经提到了Kubernetes中最基本的三个操作对象：pod, replicationController及service。 下面分别从它们的对象创建出发，通过时序图来描述Kubernetes各个组件之间的交互及其工作流。

   　　

   

    

4.  

    Kubernetes的主要特性

   会从网络、服务发现、负载均衡、资源管理、高可用、存储、安全、监控等方面向大家简单介绍Kubernetes的这些主要特性 -> 由于时间有限，只能简单一些了。
   
   另外，对于服务发现、高可用和监控的一些更详细的介绍，感兴趣的朋友可以通过这篇文章了解。
   

   1）网络

   Kubernetes的网络方式主要解决以下几个问题：
   
   a. 紧耦合的容器之间通信，通过 Pod 和 localhost 访问解决。
   b. Pod之间通信，建立通信子网，比如隧道、路由，Flannel、Open vSwitch、Weave。
   c. Pod和Service，以及外部系统和Service的通信，引入Service解决。
   
   Kubernetes的网络会给每个Pod分配一个IP地址，不需要在Pod之间建立链接，也基本不需要去处理容器和主机之间的端口映射。
   
   注意：Pod重建后，IP会被重新分配，所以内网通信不要依赖Pod IP；通过Service环境变量或者DNS解决。
   

   2） 服务发现及负载均衡

   kube-proxy和DNS， 在v1之前，Service含有字段portalip 和publicIPs， 分别指定了服务的虚拟ip和服务的出口机ip，publicIPs可任意指定成集群中任意包含kube-proxy的节点，可多个。portalIp 通过NAT的方式跳转到container的内网地址。在v1版本中，publicIPS被约定废除，标记为deprecatedPublicIPs，仅用作向后兼容，portalIp也改为ClusterIp, 而在service port 定义列表里，增加了nodePort项，即对应node上映射的服务端口。
   
   DNS服务以addon的方式，需要安装skydns和kube2dns。kube2dns会通过读取Kubernetes API获取服务的clusterIP和port信息，同时以watch的方式检查service的变动，及时收集变动信息，并将对于的ip信息提交给etcd存档，而skydns通过etcd内的DNS记录信息，开启53端口对外提供服务。大概的DNS的域名记录是servicename.namespace.tenx.domain, "tenx.domain"是提前设置的主域名。
   
   

   注意：kube-proxy 在集群规模较大以后，可能会有访问的性能问题，可以考虑用其他方式替换，比如HAProxy，直接导流到Service 的endpints 或者 Pods上。Kubernetes官方也在修复这个问题。

   3）资源管理

   有3 个层次的资源限制方式，分别在Container、Pod、Namespace 层次。Container层次主要利用容器本身的支持，比如Docker 对CPU、内存、磁盘、网络等的支持；Pod方面可以限制系统内创建Pod的资源范围，比如最大或者最小的CPU、memory需求；Namespace层次就是对用户级别的资源限额了，包括CPU、内存，还可以限定Pod、rc、service的数量。
   
   资源管理模型 －》 简单、通用、准确，并可扩展
   
   目前的资源分配计算也相对简单，没有什么资源抢占之类的强大功能，通过每个节点上的资源总量、以及已经使用的各种资源加权和，来计算某个Pod优先非配到哪些节点，还没有加入对节点实际可用资源的评估，需要自己的scheduler plugin来支持。其实kubelet已经可以拿到节点的资源，只要进行收集计算即可，相信Kubernetes的后续版本会有支持。
   

   4）高可用

   主要是指Master节点的 HA方式 官方推荐 利用etcd实现master 选举，从多个Master中得到一个kube-apiserver 保证至少有一个master可用，实现high availability。对外以loadbalancer的方式提供入口。这种方式可以用作ha，但仍未成熟，据了解，未来会更新升级ha的功能。
   
   一张图帮助大家理解：
   
   
   
   也就是在etcd集群背景下，存在多个kube-apiserver，并用pod-master保证仅是主master可用。同时kube-sheduller和kube-controller-manager也存在多个，而且伴随着kube-apiserver 同一时间只能有一套运行。
   

   5） rolling upgrade

   RC 在开始的设计就是让rolling upgrade变的更容易，通过一个一个替换Pod来更新service，实现服务中断时间的最小化。基本思路是创建一个复本为1的新的rc，并逐步减少老的rc的复本、增加新的rc的复本，在老的rc数量为0时将其删除。
   
   通过kubectl提供，可以指定更新的镜像、替换pod的时间间隔，也可以rollback 当前正在执行的upgrade操作。
   
   同样， Kuberntes也支持多版本同时部署，并通过lable来进行区分，在service不变的情况下，调整支撑服务的Pod，测试、监控新Pod的工作情况。
   
   
   
   

   6）存储

   大家都知道容器本身一般不会对数据进行持久化处理，在Kubernetes中，容器异常退出，kubelet也只是简单的基于原有镜像重启一个新的容器。另外，如果我们在同一个Pod中运行多个容器，经常会需要在这些容器之间进行共享一些数据。Kuberenetes 的 Volume就是主要来解决上面两个基础问题的。
   
   Docker 也有Volume的概念，但是相对简单，而且目前的支持很有限，Kubernetes对Volume则有着清晰定义和广泛的支持。其中最核心的理念：Volume只是一个目录，并可以被在同一个Pod中的所有容器访问。而这个目录会是什么样，后端用什么介质和里面的内容则由使用的特定Volume类型决定。
   
   创建一个带Volume的Pod：
   
   
   
   spec.volumes 指定这个Pod需要的volume信息 spec.containers.volumeMounts 指定哪些container需要用到这个Volume Kubernetes对Volume的支持非常广泛，有很多贡献者为其添加不同的存储支持，也反映出Kubernetes社区的活跃程度。
   
   • emptyDir 随Pod删除，适用于临时存储、灾难恢复、共享运行时数据，支持 RAM-backed filesystemhostPath 类似于Docker的本地Volume 用于访问一些本地资源（比如本地Docker）。
   • gcePersistentDisk GCE disk - 只有在 Google Cloud Engine 平台上可用。
   • awsElasticBlockStore 类似于GCE disk 节点必须是 AWS EC2的实例 nfs - 支持网络文件系统。
   • rbd - Rados Block Device - Ceph
   • secret 用来通过Kubernetes API 向Pod 传递敏感信息，使用 tmpfs （a RAM-backed filesystem）
   • persistentVolumeClaim - 从抽象的PV中申请资源，而无需关心存储的提供方
   • glusterfs
   • iscsi
   • gitRepo
   
   根据自己的需求选择合适的存储类型，反正支持的够多，总用一款适合的 :)
   

   7）安全

   一些主要原则：
   
   1. 基础设施模块应该通过API server交换数据、修改系统状态，而且只有API server可以访问后端存储（etcd）。
   2. 把用户分为不同的角色：Developers/Project Admins/Administrators。
   3. 允许Developers定义secrets 对象，并在pod启动时关联到相关容器。
   
   以secret 为例，如果kubelet要去pull 私有镜像，那么Kubernetes支持以下方式：
   
   1. 通过docker login 生成 .dockercfg 文件，进行全局授权。
   2. 通过在每个namespace上创建用户的secret对象，在创建Pod时指定 imagePullSecrets 属性（也可以统一设置在serviceAcouunt 上），进行授权。
   
   认证 （Authentication）
   API server 支持证书、token、和基本信息三种认证方式。
   
   授权 （Authorization）
   通过apiserver的安全端口，authorization会应用到所有http的请求上
   AlwaysDeny、AlwaysAllow、ABAC三种模式，其他需求可以自己实现Authorizer接口。
   

   8）监控

   比较老的版本Kubernetes需要外接cadvisor主要功能是将node主机的container metrics抓取出来。在较新的版本里，cadvior功能被集成到了kubelet组件中，kubelet在与docker交互的同时，对外提供监控服务。
   
   Kubernetes集群范围内的监控主要由kubelet、heapster和storage backend（如influxdb）构建。Heapster可以在集群范围获取metrics和事件数据。它可以以pod的方式运行在k8s平台里，也可以单独运行以standalone的方式。
   
   注意： heapster目前未到1.0版本，对于小规模的集群监控比较方便。但对于较大规模的集群，heapster目前的cache方式会吃掉大量内存。因为要定时获取整个集群的容器信息，信息在内存的临时存储成为问题，再加上heaspter要支持api获取临时metrics，如果将heapster以pod方式运行，很容易出现OOM。所以目前建议关掉cache并以standalone的方式独立出k8s平台。

http://blog.csdn.net/qq_28703581/article/details/51142723