前言
docker解决了打包和隔离的问题，但是在docker集群中我们需要解决更多的问题，如调度（容器在哪运行）、生命周期及健康状况（确保容器在无错的情况下运行）、服务发现（容器所处位置，和容器通信）、监控（容器运行是否正常）、认证（谁能访问我的容器）、容器聚合（如何将多个关联的容器聚合一个工程），在集群中需要解决这么问题，但是docker并没有给出解决方案,kubenetes就是解决这些问题的。
kubernetes概述及使用
轻量级、简单，可以在公有云、私有云及混合云部署，模块化(mudular),可插拔化(pluggable)- 可以使第三方的用户很容易将自己的应用集成到kubenetesz中,可挂接(hookbale)-可以接收kubernetes产生的事件并做相应的处理，,可组合(composable)-你可以任意的选择kuberntes当中的一些功能，来组成一个完整的系统，自动恢复、自动重启、自动复制。
1、使用与kubernetes进行交互的命令接口kubernetes-kubernetes CLI
(1)在主节点查看所有的node节点
[root@k8s-master ~]# kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8s-master Ready master 6d5h v1.15.2
k8s-node1 Ready <none> 6d5h v1.15.2
k8s-node2 Ready <none> 6d5h v1.15.2
(2) 获取kubernetes集群发生的事件
kubectl get events
(3)Pods
创建、调度、及管理的最小单元,共存的一组容器集合,容器共享PID-容器共享了PID命名空间，它使同一个Pods内的容器可以看到彼此的进程,网络-共享了网络命名空间，可以使同一个Pods内的容器使用相同的ip地址及其端口，通过localhost来相互访问,IPC-同一个Pods内的容器可以使用systemvip或porstem的消息队列的方式来进行通信,UTS命名空间-同一个Pods内的容器使用了相同的主机名，同时同一个Pods中的容器还可以共享存储卷-kubernetes的设计,为了更好的资源共享及容器间的通信便于管理,短暂存在-就像我们的容器一样，Pods是一个短暂存在的对象，Pods的生命周期主要分为以下几个状态：
1、首先是一个pending的状态，它表示Pods已经被系统接受，但是一个或多个容器镜像还没有创建，这包括容器在被调度之前的时间以及下载镜像的时间
2、running它表示Pods已经被部署到一个节点上，并且所有的容器镜像都被创建了
3、successed表示Pods中的容器都被成功的停止了，并且不会被重启
4、failed，它表示Pods中的所有容器都被停止了，并且至少有一个容器在停止的时候出现了错误
2、k8s最佳实践
1、创建一个基本的Pod,kubectl create –f pod.yaml
apiVersion: v1
kind: Pod #表示yaml文件定义了一个pod对象，首字母需要大写
metadata: #表示这个对象需要的一些属性值
name: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
2、获取集群的Pods，kubectl get pods
[root@k8s-master opt]# kubectl get pods nginx
NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 20s
3、删除pod,kubectl delete pods podsName
[root@k8s-master opt]# kubectl delete pods nginx
pod "nginx" deleted
4、上面演示了一个创建pod的案例，并在pod中运行一个nginx的容器，我们知道容器中的文件是短暂存在的，当容器crash的时候，数据将会丢失，下面使用Volumes进行pod数据持久化
Volumes的作用及生命周期：
1、数据持久化
2、Pod中容器共享数据
3、生命周期(Volumes的周期和Pod定义的生命周期是一样的)，当一个Pods停止退出的时候Volumes也会停止退出，目前kubernetes支持的数据卷类型-emptyDir,hostpath,gcePersistentDisk,awsElasticBlockStore,nfs,iscsi,glusterfs,secrets
存储卷创建的几种方式
1、本地主机上创建的两种类型数据卷
1、emptyDir:当Pods被调度到一个节点的时候生成，只要Pods运行到当前节点上便一直存在，其初始是一个空文件夹，Pods内的容器可以读取此文件夹中的文件，当此Pods从此节点删除的时候，数据卷也会被相应的删除，我们需要注意容器crash的时候，数据卷是不会被删除的
2、hostpath:可以指明当前宿主机上的一个路径映射到我的Pods内
2、云端存储
gcePersistentDisk,awsElasticBlockStore
3、网络存储
nfs,iscsi,glusterfs
4、加密存储secrets
用于存储比较敏感的数据，如果用户密码
创建一个包含Volumes的Pods,kubectl create -f volumes.yaml
apiVersion: v1
kind: Pod
metadata:
name: redis
spec:
containers:
- name: redis
image: redis
volumeMounts:
- name: redis-persistent-storage
mountPath: /data/redis
volumes:
- name: redis-persistent-storage
emptyDir: {}
使用yaml格式查看redis Pod的详细信息，kubectl get pods redis -o yaml
Label的作用
用以表示对象(如Pod)的key/value对，组织并选择对象子集，Labels使用户可以使用松耦合的方式来映射自己应用的组织结构，而不需要存储这些映射表，那么与命名和uid不同的是，Label不需要提供唯一性，反而我们希望多个对象使用相同的Label,通过Label选择器用户可以指定一些对象子集来进行分组合并。
创建一个Labels的pod,kubectl create -f label.yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
查看带有label的Pod,kubectl get pods -l app=nginx-web
这个时候我们已经可以创建一个带labels并能够提供持久化的pod,但是当我们的节点出错或者需要维护的时候，我们如何确保我们的Pods能被调度到其他节点正常运行呢？在kubernets当中有一个replication controller的概念，我们简称它为RC
RC的概述
1、保证在任意时刻运行指定数量的Pod，比如说我要指定刚才创建的nginx在任意时候都要运行一个Pod,当我运行nginx的pod的节点出现错误时，那么我的这个RC确保这个Pod会被调度到另外可以工作正常的接点上，保证Pod正常运行
2、容器重新调度，可以把它当做守护进程，与之不同的是RC监控的事多个节点的多个Pod
3、规模调度，它使规模调度变得简单，你只需要修改指定Pod的数目，RC便会删除多余的容器和启动新的容器以达到指定的数目
4、在线升级，同时RC可以通过一个接一个替换Pod的方法实现在线升级，你可以增加一个新版本的Pod,然后删除一个旧的Pod,之后当旧版本的Pod数目为0的时候，你可以删除旧的RC,需要注意的是我们使用新版本的Pod和旧版本Pod的RC需要至少有一处不同label以标记不同版本的RC
5、多发布版本跟踪，在某一个时间段内运行多个版本的应用是可能的，这个多个版本的追踪也是可以通过设置不同的label,通过RC去实现
创建一个rc,kubectl create -f rc.yaml
apiVersion: v1
kind: ReplicationController
metadata:
name: nginx
spec:
replicas: 3 #创建nginx pod实例的数量
selector:
app: nginx
template:
metadata:
name: nginx
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
查看rc的信息，kubectl get rc,并查看创建的Pod
尝试删除其中一个Pod，验证RC是否重新创建一个,kubectl delete pods podName,可以看到重新创建了一个Pod，rc控制器始终保证了Pod的运行数量
每个Pods都有自己的ip地址，并且这些地址并不是固定的，这带来一个问题，如果一些Pods是被另外一些Pods提供服务的，那么它如何被发现呢，kubernetes为此提供了service的抽象去解决这个问题
Service的定义
1、抽象一系列Pod并定义访问规则
2、它为每一个服务提供了一个固定的虚拟的ip和dns域名
3、我们可以通过环境变量和DNS的方式发现服务
4、同时它还提供了非常简单的负载均衡
5、它定义了我们Pod的访问方式，目前有三种，首先是一个ClusterIP(它只能在当前集群内访问),type是NodePort的时候，那么它是使用了ClusterIP,同时它还会在集群的每一个节点上暴露一个服务的端口，你可以通过这个集群的某一个工作节点的ip地址以及这个端口来访问这个服务，如果你的云服务商提供支持外部负载均衡的话，那么你可以使用LoadBalancer这个类型,通过service的访问你并不需要Pods的ip,service的ip是一个固定的ip，并且你可以通过kubernetes提供的DNS服务进行查询
创建一个service,kubectl create -f service.yaml
apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
ports:
- port: 8000 # The port that this service should serve on the container on each pod to connect to,
#can be a name(eg,'www') or a number(eg,'80')
targetPort: 80
protocol: TCP
# # Just like the selector in the replication controller,but this time it identifies the set of pods load balance traffic to.
selector:
app: nginx
查看service的状态，kubectl get service
在节点上验证service暴露是否成功，cutrl http://ClusterIP:port
