基础重要的服务介绍
Master 上运行的服务
- etcd 服务：
k8s 内部关系图：
image
| k8s内对象名字 | 作用 |
|---|---|
| daemonSet | 用来描述每个宿主机上必须且只能运行一个副本的守护进程服务 |
| Job | 用来描述一次性运行的 Pod（比如，大数据任务） |
| CronJob | 用于描述定时任务 |
==Kubernetes 项目如何启动一个容器化任务呢？==
实例：NGINX 负载
- 定义一个 deployment yaml文件
apiVersion: apps/v1
kind: Deployment #yaml类型名
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
- 创建这个yaml
$ kubectl create -f nginx-deployment.yaml
这样就创建了两个 NGINX 的 部署
kubeadm 集群构建命令：
# 创建一个 Master 节点
$ kubeadm init
# 将一个 Node 节点加入到当前集群中
$ kubeadm join <Master 节点的 IP 和端口 >
==部署 kubeadm master 节点==
- 安装 kubeadm
$ apt-get install kubeadm
- 初始化master 节点
kubeadm init
static pod 的简介
[图片上传失败...(image-228f2-1541571599035)]
apiVersion: v1
kind: Pod
metadata:
annotations:
scheduler.alpha.kubernetes.io/critical-pod: ""
creationTimestamp: null
labels:
component: kube-apiserver
tier: control-plane
name: kube-apiserver
namespace: kube-system
spec:
containers:
- command:
- kube-apiserver
- --authorization-mode=Node,RBAC
- --runtime-config=api/all=true
- --advertise-address=10.168.0.2
...
- --tls-cert-file=/etc/kubernetes/pki/apiserver.crt
- --tls-private-key-file=/etc/kubernetes/pki/apiserver.key
image: k8s.gcr.io/kube-apiserver-amd64:v1.11.1
imagePullPolicy: IfNotPresent
livenessProbe:
...
name: kube-apiserver
resources:
requests:
cpu: 250m
volumeMounts:
- mountPath: /usr/share/ca-certificates
name: usr-share-ca-certificates
readOnly: true
...
hostNetwork: true
priorityClassName: system-cluster-critical
volumes:
- hostPath:
path: /etc/ca-certificates
type: DirectoryOrCreate
name: etc-ca-certificates
...
==PV &PVC==
目的：实现存储的持久化，在k8s中并非绑定宿主机的目录即为存储持久化
PV &PVC 的关联：
PVC 如果想要和pod结合起来需要与PV结合起来才能被使用
==创建PV==-->==开发声明PVC对象==--> ==确认PV的大小与PVC的spec字段，对比== --> ==storageClassName 字段要一致== -->绑定
创建PV示例 （示例为NFS网络存储类示例）
apiVersion: v1
kind: PersistentVolume
metadata:
name: nfs
spec:
storageClassName: manual
capacity:
storage: 1Gi
accessModes:
- ReadWriteMany
nfs:
server: 10.244.1.4
path: "/"
创建PVCyaml示例：
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: nfs
spec:
accessModes:
- ReadWriteMany
storageClassName: manual
resources:
requests:
storage: 1Gi
pod 绑定PVC 示例
apiVersion: v1
kind: Pod
metadata:
labels:
role: web-frontend
spec:
containers:
- name: web
image: nginx
ports:
- name: web
containerPort: 80
volumeMounts:
- name: nfs
mountPath: "/usr/share/nginx/html"
volumes:
- name: nfs
persistentVolumeClaim: ## <--这字段
claimName: nfs
问题点：创建 Pod 的时候，系统里并没有合适的 PV 跟它定义的PVC绑定
所以就引进了k8s的 Volume Controller
==PersistentVolumeController== ：不断的查看当前每个PVC，确认他们是否处于bond状态，如果不是会遍历所有的PV并尝试将PVC与合适的PV进行绑定
PV生效阶段：
二段式：
- attach： 即将块存储于宿主机进行接入
- mount：将存储挂载至宿主机的某个目录用于容器进行映射持久化使用
这些二段式准备阶段在k8s中是依赖kubelet的主控制循环来实现的，分别是：
==AtttachDetachController(检查pod对应的宿主机与该pod的PV 的挂载情况)==
==VolumeManagerReconciler()==
==StorageClass==
就是创建PV的模板，包含两部分内容：PV属性 & 创建此PV所需要的插件
示例：Volume 的类型是GCE 的persistent DISK：
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: block-service
provisioner: kubernetes.io/gce-pd #k8s内置的GCE PD 存储插件的名字
parameters: # PV参数字段
type: pd-ssd ##PV的类型，这里的类型是 SSD格式的GCE远程磁盘。
创建StorageClass 的命令：
$ kubectl create -f sc.yaml
接下来可以创建所需要的PVC ：
PVC 的yaml文件内容：
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: claim1
spec:
accessModes:
- ReadWriteOnce
storageClassName: block-service ## 这个名字就是上面所创建的StorageClass的名字
resources:
requests:
storage: 30Gi
创建PVC 的命令(示例)：
$ kubectl create -f pvc.yaml
$ kubectl describe pvc claim1
Name: claim1
Namespace: default
StorageClass: block-service
Status: Bound
Volume: pvc-e5578707-c626-11e6-baf6-08002729a32b ## 由storageClass创建的PV
Labels: <none>
Capacity: 30Gi
Access Modes: RWO
No Events.
$ kubectl describe pv pvc-e5578707-c626-11e6-baf6-08002729a32b
Name: pvc-e5578707-c626-11e6-baf6-08002729a32b
Labels: <none>
StorageClass: block-service
Status: Bound
Claim: default/claim1
Reclaim Policy: Delete
Access Modes: RWO
Capacity: 30Gi
...
No events.
==疑问：创建的PV 具体位置在哪？实现存储的持久化 莫非需要PVC的名字一个pod唯一对应一个PVC？==
有了Dynamic Provisioning 机制，只需要在k8S中创建出数量有限的StoreageClass 的对象就可以了。当提交包含StorageClass 字段的PVC之后，k8s会根据这个StoreageClass 字段来创建出相应的PV
注意：开头的PV PVC 示例中都声明了StoreageClassName=manual 的yaml, 这样做的，并不是集群中有一个名字叫manual的SC，而这个时候是k8s进行了 Static Provisioning ，这样做的好处就是 PV 与PVC 的关系掌控在自己手中。
PV、PVC 、 StorageClass 的关系：
[图片上传失败...(image-b2dfa1-1541571599035)]
如图关系：
- PVC：Pod 想要使用的持久化存储的属性，比如存储的大小、读写权限等。
- PV：一个具体volume 的属性，比如 volume的类型、挂载目录、远程存储服务地址等。
- StorageClass 的作用是：只有同属于一个StorageClass的PV和PVC才能绑定在一起。
心得：
==PV & PVC 关联有两种方式：静态&动态 静态的缺点是如果PVC需求的不存在需要人工确认==
==疑问：创建新的PV?还是如果有旧的StoreageClass de PV会进行绑定？==
==疑问：如何跟AWS 的块存储关联起来？（参照下面博客）==
==什么存储介质可以用作PV？（NFS、AWS的EBS）==
Local Persistent Volume
即node节点上、宿主机自身的存储，类似于 docker 映射。
优点： 读写速度快
缺点：节点宕机且不能恢复时则存储消失。
