关于本地持久化存储

用户希望 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

首先，我们以之前实践过的nginx-deployment.yaml文件为例：

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

apiVersion: apps/v1
kind: Deployment # API对象的类型
metadata: 
  name: nginx-deployment 
spec: 
  selector: 
    matchLabels: # 过滤规则的定义
      app: nginx
  replicas: 2 # 定义Pod副本个数为2
 template: 
   metadata: labels: # 元数据
     app: nginx # labels，一组键值对的标签
   spec: 
     containers: 
     - name: nginx 
       image: nginx:1.7.9 
       ports: 
       - containerPort: 80

这个Deployment定义的编排动作是：请确保携带了app:nginx标签的Pod的个数永远等于spec.replicas指定的个数-> 2。

这就意味着，如果在这个集群中，携带app:nginx标签的Pod个数大于等于2，就会有旧的Pod被删除；反之就会有新的Pod被创建。

那么，究竟是Kubernetes项目的哪个组件在执行这些操作呢？——kube-controller-manager组件。

本文将开始系统学习Kubernetes的编排原理，因此先从最重要最基本的Pod开始。

为什么需要Pod

首先需要记住：

• Pod是Kubernetes项目的院子调度单位；
• Namespace做隔离，Cgroups做限制，rootfs做文件系统
• 容器的本质是进程，Kubernetes的本质是操作系统。

Pod的实现原理

本文将以创建一个nginx的deployment为例体验Kubernetes的基础使用

Kubernetes跟Docker等很多项目最大的不同是：它不推荐你使用命令行方式的方式直接运行容器，而是希望你用YAML文件的方式，即把容器的定义、参数、配置都记录在一个YAML文件中，然后用

1

# kubectl create -f test.yml

运行起来。

这么做最直接的好处就是，会有一个文件记录下Kubernetes到底运行了什么。

因为某些原因，需要卸载kubernetes集群，本文将分享完整卸载kubernetes的方法。

默认是root用户操作

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

# 首先清理运行到k8s群集中的pod
kubectl delete node --all

# 停止所有k8s相关服务
for service in kube-apiserver kube-controller-manager kubectl kubelet kube-proxy kube-scheduler;
do
      systemctl stop $service
done

# 重置集群
kubeadm reset -f

# 删除相关的配置文件
rm -rf ~/.kube/

rm -rf /etc/kubernetes/

rm -rf /etc/systemd/system/kubelet.service.d

rm -rf /etc/systemd/system/kubelet.service
# 删除kubenetes有关的可执行文件
rm -rf /usr/bin/kube*

rm -rf /etc/cni

rm -rf /opt/cni

rm -rf /var/lib/etcd

rm -rf /var/etcd

apt clean all

apt remove kube*