前两章的目的是为了快速搭建Kubernetes集群，并跑起来。后续便是慢慢抽丝剥茧，一点点的学习消化

1. 简介

1.1 什么是Kubernetes

首先，它是一个全新的基于容器技术的分布式架构领先方案，基于谷歌集群管理系统(Borg)而诞生，Borg是谷歌的一个久负盛名的内部使用的大规模集群管理系统，它基于容器技术，目的是实现资源管理的自动化，以及跨多个数据中心的资源利用率的最大化。十几年以来，谷歌一直通过Borg系统管理着数量庞大的应用程序集群。

其次，它是一个开放的开发平台。与J2EE不同，它不局限于任何一种语言，没有限定任何编程接口，所以不论是用Java、Go、C++还是用Python编写的服务，都可以被映射为Kubernetes的Service（服务），并通过标准的TCP通信协议进行交互。

此外，Kubernetes平台对现有的编程语言、编程框架、中间件没有任何侵入性，因此现有的系统也很容易改造升级并迁移到Kubernetes平台上。

1.2 Kubernetes发展史

  • 2003-2004, Borg 系统的诞生: Borg 系统是一个大规模的内部集群管理系统，它可以运行数千个不同应用程序
    中的数十万个遍布多个集群的作业，每个集群拥有多达数万台机器。

  • 2014 年中,Google 推出 Kubernetes: Google 推出 Kubernetes （作为 Borg 的开源版本）。

  • 2014.6.7,初始版本发布: Kubernetes 在 GitHub 上第一次被提交。

  • 2014.7.10,重要成员加入: 微软、RedHat、IBM、Docker 加入 Kubernetes 社区。

  • 2015.7.21,Kubernetes v1.0 发布: 随后，谷歌与 Linux 基金会合作组建了云原生计算基金会（CNCF）。CNCF 旨在建立可持续的生态系统，并围绕一系列高质量项目建立一个社区。

  • 2016: Kubernetes 在这一年成为主流

    • 2016.2.23,Helm 发布：Kubernetes 软件包管理系统 Helm 首次发布。

    • 2016.7.11,Minikube 正式发布：它是一个可以让Kubernetes 在本地运行的工具。

    • 2016.9.8,Kops 面世：一个管理生产级 Kubernetes 集群的官方 Kubernetes 项目。

    • 2016.9.26,kubeadm 诞生：Kubernetes 1.4 推出了一种新工具 kubeadm，有助于提高 Kubernetes 的可安装性。 此版本提供了更简单的设置，支持集成 Helm 的状态应用以及新的跨集群联合功能。

    • 2016.12.21,Windows服务器支持K8s： Kubernetes 1.5 发布，Kubernetes 得到Windows服务器的支持。

    • 2016.12.23，Kubernetes 支持 OpenAPI: 允许 API 提供商定义他们的操作和模型，开发人员可以自动化他们的工具。

  • 2017: 企业采用和支持的一年

    • 2017.5.24，istio面世：Google 与 IBM 发布了一项开放式技术 Istio，它提供了一种对任何平台、来源或是供应商都能无缝连接、管理和保护不同微服务网络的方法。
    • 2017.8.16: GitHub 开始在 Kubernetes 上运行。所有 Web 和 API 请求都由在 metal cloud 上部署的 Kubernetes 集群中运行的容器提供服务。
    • 2017.9.11： CNCF 宣布推出首批 Kubernetes 认证服务供应商，有超过 22 家供应商获得首批 Kubernetes 认证。
    • 2017.9.13： Oracle 以白金会员的身份加入了 CNCF，并在 Oracle Linux 上发布了 Kubernetes。
    • 2017.10： Docker 和 Kubernetes全面合作。
    • 2017.10.24： 微软推出 AKS 预览版 — AKS 具有 Azure 托管控制平面，并能自动升级、自我修复、易于扩展以及为开发人员和集群运营商提供简单的用户体验。
    • 2017.11.29：亚马逊宣布为 Kubernetes 提供弹性容器服务，可在 AWS 上使用 Kubernetes 进行部署、管理和扩展容器化应用程序。
    • 2017.12.21：Kubeflow首发 ，一个为 Kubernetes 构建的可组合、便携、可扩展的机器学习堆栈。

….

2. 架构介绍

一个典型的Kubernetes集群由多个工作节点（worker node）和一个集群控制平面（control plane，即Master），以及一个集群状态存储系统（etcd）组成。

Master节点： 负责整个集群的管理工作，为集群提供管理接口，并监控和编排集群中的各个工作节点。

Work node 节点：负责以Pod的形式运行容器。

2.1 节点组件图

2.2 Master节点组件

Master是Kubernetes Cluster的大脑，运行着的Daemon服务包括kube-apiserver、kube-scheduler、kube-controller-manager、etcd和Pod网络。

a. API Server（kube-apiserver）

API Server提供HTTP/HTTPS RESTful API，即Kubernetes API。API Server是Kubernetes Cluster的前端接口，各种客户端工具（CLI或UI）以及Kubernetes其他组件可以通过它管理Cluster的各种资源。

b. Scheduler(调度器)

在API Server收到Pod对象的创建请求之后,Scheduler会根据集群内各节点的可用资源状态，决定Pod在哪个Node上运行。Kubernetes也支持用户自定义调度器。

c. Controller Manager(控制器管理器)

Controller Manager负责管理Cluster各种资源，保证资源处于预期的状态。

Controller Manager由多种controller组成，包括replication controller、endpoints controller、namespace controller、serviceaccounts controller等。

不同的controller管理不同的资源。例如，replication controller管理Deployment、StatefulSet、DaemonSet的生命周期，namespace controller管理Namespace资源。

d. Etcd

etcd负责保存Kubernetes Cluster的配置信息和各种资源的状态信息。当数据发生变化时，etcd会快速地通知Kubernetes相关组件。需要注意的是: etcd是独立的服务组件，并不隶属于Kubernetes集群自身。生产环境中应该以etcd集群的方式运行以确保其服务可用性。

etcd不仅能够提供键值数据存储，而且还为其提供了监听（watch）机制，用于监听和推送变更。Kubernetes集群系统中，etcd中的键值发生变化时会通知到API Server，并由其通过watch API向客户端输出。基于watch机制，Kubernetes集群的各组件实现了高效协同。

e. Pod网络

Pod相当于Kubernetes云平台所提供的虚拟机，是Kubernetes基本的调度单位。Pod网络就是能保证Kubernetes集群中所有的Pod，无论是否同一节点上，能够互相通信，逻辑上在同一个网络内。

目前比较流行CNI网络插件有: Flannel、Calico、Weave 和 Canal

2.3 Node节点组件

Node负责提供运行容器的各种依赖环境，并接受Master的管理。每个Node主要由以下几个组件构成。

a. kubelet(Node的核心代理程序)

kubelet是Node的agent，当Scheduler确定在某个Node上运行Pod后，会将Pod的具体配置信息（image、volume 等）发送给该节点的kubelet，kubelet根据这些信息创建和运行容器，并向Master报告运行状态。

b.kube-proxy

service在逻辑上代表了后端的多个Pod，外界通过service访问Pod。service接收到的请求是如何转发到Pod的呢？

这就是kube-proxy要完成的工作。每个Node都会运行kube-proxy服务，它负责将访问service的TCP/UPD数据流转发到后端的容器。如果有多个副本，kube-proxy会实现负载均衡。

c. Container Runtime(容器运行时)

Kubelet需要一个容器运行时（container runtime）来执行依赖容器才能执行的任务，例如拉取镜像并启动或停止容器。

在早期的版本中，Kubernetes原生支持了少量容器运行时，例如Docker。而在最近的版本中，Kubernetes将其迁移到了一个叫作容器运行时接口（CRI）的模块当中。从整体上来看，CRI屏蔽了Kubernetes内部运行机制，并向第三方容器运行时提供了文档化接口来接入。

Kubernetes目前支持丰富的容器运行时。一个非常著名的例子就是cri-containerd。这是一个开源的、社区维护的项目，将CNCF运行时通过CRI接口接入Kubernetes。该项目得到了广泛的支持，在很多Kubernetes场景中已经替代Docker成为当前最流行的容器运行时。

d. Pod网络

Pod相当于Kubernetes云平台所提供的虚拟机，是Kubernetes基本的调度单位。Pod网络就是能保证Kubernetes集群中所有的Pod，无论是否同一节点上，能够互相通信，逻辑上在同一个网络内。

问：为什么master节点有kubelet和kube-proxy呢？

答: 这是因为Master上也可以运行应用，即Master同时也是一个Node。

3. 实例分析

为了帮助大家更好地理解Kubernetes架构，我们部署一个应用来演示各个组件之间是如何协作的。

3.1 配置文件

cat <<EOF >  /usr/local/kubernetes/deployment/httpd.yaml
apiVersion: apps/v1 # 配置格式版本
kind: Deployment   #资源类型，我们使用的是 Deployment
metadata: 
  name: httpd-deployment #Deployment 的名称
spec: 
  replicas: 2   # 副本数量
  selector:   #标签选择器，与上面的标签共同作用，目前不需要理解
    matchLabels: #选择包含标签app:httpd_server的资源
      app: httpd_server
  template:     #这是选择或创建的Pod的模板
    metadata:   
      labels:   #Pod的标签
        app: httpd_server
    spec: 
      containers: 
      - name: httpd-app #container的名称
        image: httpd #使用镜像httpd
        ports:
        - containerPort: 8080
EOF

3.2 创建资源

# 使用kubectl apply创建资源
$ kubectl apply -f /usr/local/kubernetes/deployment/httpd.yaml
deployment.apps/httpd-deployment created

3.3 查看资源

# 查看 deployment
$ kubectl get deployment -o wide
NAME               READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS   IMAGES   SELECTOR
httpd-deployment   2/2     2            2           45s   httpd-app    httpd    app=httpd_server
# 查看pod分布情况
$ kubectl get pod -o wide
NAME                                READY   STATUS    RESTARTS   AGE   IP               NODE    NOMINATED NODE   READINESS GATES
httpd-deployment-5bcbffbddf-mv85v   1/1     Running   0          70s   10.244.104.4     node2   <none>           <none>
httpd-deployment-5bcbffbddf-v6pbb   1/1     Running   0          70s   10.244.166.135   node1   <none>           <none>

3.4 过程分析

  1. kubectl发送创建资源请求到API Server。
  2. API Server通知Controller Manager创建一个deployment资源。
  3. Scheduler执行调度任务，将两个副本Pod分发到node1和node2。
  4. node1和node2上的kubectl在各自的节点上创建并运行Pod。

补充两点:

  • 应用的配置和当前状态信息保存在etcd中，执行kubectl get pod时API Server会从etcd中读取这些数据。
  • Pod网络会为每个Pod分配IP。因为没有创建service，所以目前kube-proxy还没参与进来。

4. 核心附件

Kubernetes集群，除了有 Master与Node节点组件外,还依赖于一组称为附件(add-ons)的组件以提供完整的功能。它们通常是由第三方提供的特定应用程序，且托管运行于Kubernetes集群之上。

4.1 KubeDNS

KubeDNS是在Kubernetes集群中调度运行提供DNS服务的Pod，同一集群中的其他Pod 可使用此DNS服务解决主机名。

Kubernetes自1.11版本开始默认使用CoreDNS项目为集群提供服务注册和服务发现的动态名称解析服务，之前的版本中用到的是kube-dns项目，而SkyDNS则是更早一代的项目。

4.2 Kubernetes Dashboard

Kubernetes集群的全部功能都要基于Web的UI，来管理集群中的应用甚至是集群自身。

4.3 Heapster

容器和节点的性能监控与分析系统，它收集并解析多种指标数据，如资源利用率、生命周期事件等。新版本的Kubernetes中，其功能会逐渐由Prometheus结合其他组件所取代。

4.4 Ingress Controller

Service是一种工作于传统层的负载均衡器，而Ingress是在应用层实现的HTTP（s）负载均衡机制。不过，Ingress资源自身并不能进行“流量穿透”，它仅是一组路由规则的集合，这些规则需要通过Ingress控制器（Ingress Controller）发挥作用。目前，此类的可用项目有Nginx、Traefik、Envoy及HAProxy等。