定义

全局的、为了代理不同后端 Service 而设置的负载均衡服务，就是 Kubernetes 里的Ingress 服务。

所以，Ingress 的功能其实很容易理解：所谓 Ingress，就是 Service 的“Service”。

假如我现在有这样一个站点：https://cafe.example.com，其中https://cafe.example.com/coffee对应的是“咖啡点餐系统”，而https://cafe.example.com/tea对应的是茶水点餐系统，这两个系统，分别由名叫coffee和tea两个Deployment来提供服。

那么，我如何能使用 Kubernetes 的 Ingress 来创建一个统一的负载均衡器，从而实现当用户访问不同的域名时，能够访问到不同的 Deployment 呢？
上述功能，在 Kubernetes 里就需要通过 Ingress 对象来描述：

Kubernetes网络模型

Kubernetes 是通过一个叫作 CNI 的接口，维护了一个单独的网桥来代替 docker0。
这个网桥的名字就叫作：CNI 网桥，它在宿主机上的设备名称默认是：cni0。

在这里，Kubernetes 为 Flannel 分配的子网范围是 10.244.0.0/16。
这个参数可以在部署的时候指定，比如：

1

kubeadm init --pod-network-cidr=10.244.0.0/16

注：也可以在部署完成后，通过修改 kube-controller-manager 的配置文件来指定。

Flannel介绍

要理解容器“跨主通信”的原理，就一定要先从Flannel这个项目开始。

Flannel 项目是 CoreOS 公司主推的容器网络方案。事实上，Flannel 项目本身只是一个框架，真正为我们提供容器网络功能的，是 Flannel 的后端实现。目前，Flannel 支持三种后端实现（种容器跨主网络的主流实现方法。），分别是：

• VXLAN
• host-gw
• UDP

UDP模式

概念

网络栈

包括了：网卡（Network Interface）、回环设备（Loopback Device）、路由表（Routing Table）和 iptables 规则。对于一个进程来说，这些要素，其实就构成了它发起和响应网络请求的基本环境。

注意：作为一个容器，它可以声明直接使用宿主机的网络栈（–net=host），即：不开启 Network Namespace，比如：

1
2

# 容器启动后，直接监听的就是宿主机的 80 端口。
docker run –d –net=host --name nginx-host nginx

关于本地持久化存储

用户希望 Kubernetes 能够直接使用宿主机上的本地磁盘目录，而不依赖于远程存储服务，来提供“持久化”的容器Volume。

这样做的好处就是：由于这个Volume直接使用的是本地磁盘，尤其是SSD盘，它的读
写性能相比于大多数远程存储来说，要好得多。

Local PV的设计难点

如何把本地磁盘抽象成PV

PV和PVC

PV是持久化存储数据卷。

这个API对象主要定义的是一个持久化存储在宿主机上的目录，比如一个NFS的挂载目录。

下面来定义一个NFS类型的PV：

1
2
3
4
5
6
7
8
9
10
11
12
13

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs
spec:
  storageClassName: manual
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteMany
  nfs:
    server: 10.244.1.4
    path: "/"

Job

API对象定义：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    spec:
      containers:
      - name: pi
        image: resouer/ubuntu-bc
        # scale=10000 意思是 计算出的结果取小数点后 10000位
        command: ["sh","-c","echo 'scale=10000; 4*a(1)' | bc -l "]
      restartPolicy: Never # 离线计算的Pod永远不应该被重启
  backoffLimit: 4

在这个模板中，我们定义了一个Ubuntu镜像的容器，他运行计算π的程序，所以，这是一个计算π的容器。

创建成功后，查看一下这个Job对象：
//TODO:
可以看到，在这个Job对象创建后，它的Pod模板被自动加上了一个controller-uid=<一个随机字符串>这样的Label。从而保证了Job与它所管理的Pod之间的匹配关系。

DaemonSet特征

DaemonSet的主要作用是在Kubernetes集群里运行一个Daemon Pod时，这个Pod具有3个特征：

• 1，每个Pod在Kubernetes集群里的每一个节点上运行；
• 2，每个节点上只有一个这样的Pod实例；
• 3，当有新节点加入Kubernetes集群后，该Pod会自动地在新节点上被创建出来；而当旧节点被删除后，它上面的Pod也会相应地被回收。

DaemonSet工作原理

API对象定义：

什么是StatefulSet

在分布式应用中，它的多个实例之间往往有依赖关系，比如主从关系、主备关系；还有数据存储类应用，它的多个实例往往会在本地磁盘上保存一份数据，而这些实例一旦被结束，即便重建出来，实例与数据之间的对应关系也已经丢失，从而导致应用失败。

所以，这种实例之间有不对等关系，以及实例对外部数据有依赖关系的应用，就称为有状态应用（stateful application）。

得益于控制器模式的设计思想，Kubernetes项目在Deployment基础上扩展出了对有状态应用的初步支持。这个编排功能就是StatefulSet。

拓扑状态

本文讲解Kubernetes中第一个控制器模式的完整实现：Deployment。它实现了Kubernetes项目中非常重要的功能：Pod的水平扩展/收缩。

例如，如果你更新了Deployment的Pod模板，那么Deployment就需要遵循一种叫作滚动更新rolling update的方式来升级现有容器。而这个能力的实现依赖Kubernetes项目中一个非常重要的概念（API对象）：ReplicaSet。

ReplicaSet

一个ReplicaSet对象是由副本数目的定义和一个Pod模板组成的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

apiVersion: v1
kind: ReplicaSet
metadata:
  name: nginx-set
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9