前言
在上篇文章中我给大家简单介绍了k8s是干嘛的，包括各个组件的简单介绍。今天给大家详细介绍一下更深层次的东西（其实就是怎么管理和使用），但是我不是像网上那样直接CV一大堆命令，而是使用从一个节点出发，在我们遇到什么问题的时候就使用什么命令，并且简单介绍一下这个命令的思路，和大家一起看看k8s基本使用！
节点
在上篇文章中我们知道了什么是一个节点，简而言之就是一台机器，可以是一个虚拟机或者服务器都行。那当我们初次搭建一个k8s的集群的时候(如果不会的可以查看官网或者去网上查看一些资料)，肯定做过这一步
kubeadm join --token 这里是一大串token
因为我们一开始肯定在一台节点上搭建集群，那么这个节点就是默认的工作节点()，也就是代表了这个集群（毕竟只有一个节点），那其他的节点想要加入一个集群肯定要得到集群的认可（就像是上梁山你得大当家的答应），而这个token就是相当于令牌，任何一个节点拿着这个令牌就可以加入这个集群，这就是加入集群的方法。这个token只有管理节点才可以生成，是用
kubeadm token create [token]
命令生成的，详细的可以看一下官网
这里多说一点，一开始加入的默认都是从节点，但是可以升级是主节点（就是你上梁山后，自己比较优秀就被提拔成二当家的一样）
在执行过这个命令之后，这个节点就是集群的一员了，那首先我们肯定想看看我们加入的东西，所以我们可以通过kubectl这个工具来查看关于这个节点的信息，同时也可以操作这个节点
比如，使用kubectl get nodes可以查看该集群的所有node的信息
[root@k8smaster ~]# k get nodes
NAME STATUS ROLES AGE VERSION
k8smaster Ready master 27d v1.18.0
k8snode1 Ready <none> 26d v1.18.0
k8snode2 Ready <none> 26d v1.18.0
NAME就是节点的名字，只要是唯一的就行，
STATUS是节点的状态
| 节点状况 | 描述 |
|---|---|
Ready | 如节点是健康的并已经准备好接收 Pod 则为 True；False 表示节点不健康而且不能接收 Pod；Unknown 表示节点控制器在最近 node-monitor-grace-period 期间（默认 40 秒）没有收到节点的消息 |
DiskPressure | True 表示节点存在磁盘空间压力，即磁盘可用量低, 否则为 False |
MemoryPressure | True 表示节点存在内存压力，即节点内存可用量低，否则为 False |
PIDPressure | True 表示节点存在进程压力，即节点上进程过多；否则为 False |
NetworkUnavailable | True 表示节点网络配置不正确；否则为 False |
ROLES就是这个节点的角色标签，除了管理节点默认打上了master标签，其他的都是<none>,你可以通过命令来设置一个标签，这样可以用于区分一些节点的工作内容等
AGE就是指着节点运行了多久
上面介绍了增加和查看，那必定有删除
kubectl delete nodes k8snode1
这样就可以删除一个节点。
前面介绍了节点，那么我有多个节点我就是一个集群了吗？其实不然，节点的多少和是不是一个集群关系不大，三个节点也可以是一个集群，那么什么样才算真正的集群呢？或者说一个集群到底在干什么呢？因为我们前面只知道集群是运行在node上的.
其实一个集群就是在运行一大堆的容器。那管理这些容器就成了重中之重，想要管理，就必须划分成一个个单元去管理，就像是领军打仗一样，容器就是一个个兵，军队有班长，排长，连长，营长，师长等，所以军队中最小的单位就是班长了，那么k8s也是这样，需要一个最小的单位，目前看来节点是最好的选择，一个节点作为一个单位。但是有个问题，就是我们的容器是跑在一个节点上的，要是节点一点除了什么问题，是不是就会数据丢失，而且节点的多少是k8s没法控制的，万一某个集群就3个节点，那操作起来就会太过于耦合。这是不好的。所以k8s自己就设计了一个最小单位-----Pod
pod
前面我们介绍了，pod是k8s最小的单元，换句话说就是很多管理节点的命令都是下发到pod的，然后pod去下发到每个容器，就像是军队的命令是下发到班，班长再下发到个人。这个pod更像是一个概念上的划分，就是将一定量的容器划分成一个pod，所以这个概念理解起来可能没有节点这样的概念好理解。但是大家把他理解成一个班就好多了，班这个概念也是这样，看不见摸不着，但是一看到某个士兵就知道他是哪个班的了。
Pod分为两类：
- 静态pod
- 控制器管理的Pod 使pod成为有生命周期的对象
-
- ReplicationController （现在官方已经不推荐使用，推荐用ReplicaSet代替它）
- ReplicaSet replicaset不直接使用，它有一个声明式更新的控制器--deployment来负责管理，但是deployment只能管理无状态的
- Deployment 管理无状态的，使用最多的
- StatefulSet 管理有状态的
- DaemonSet
- Job, Cronjob
静态pod是一个比较特殊的pod，正常情况下Pod是在Master上统一管理，指定，分配。所谓静态Pod就是不接受Master的管理，在指定的node上当 kubelet 启动时，会自动启动所有定义的静态Pod。
静态pod的启动方式有两种，一是配置文件，二是http方式，至于怎么创建静态的pod在实际使用中比较少，所以这里不做详细介绍，感兴趣的同学可以去网上搜索一下
至于为什么要有静态pod，是因为我们一般创建的pod都可以通过kubectl这个命令去做增删改查，但是为了防止一个比较核心的组件应用被误操作，所以有了静态的pod，换句话说就是静态pod比较重要，一般操作不能”误伤“静态pod。
至于控制器管理的Pod,首先解释一下为了有控制器呢？
因为一个pod自身是不具有自愈能力，也就是一旦挂了就挂了，那这样必定会增加运维的工作。而且Pod 被调度到某节点后 而该节点之后失效，Pod 会被删除，为了让pod可以更加强大一些，Kubernetes 使用一种高级抽象 来管理这些相对而言可随时丢弃的 Pod 实例，称作 控制器。
那为什么控制器管理的pod有上面的几个类型，那为什么又这么多类型呢？主要是为了做到分工明确,大家稍微了解军队的知道，虽然军队常见是班，但是有些班与班之间的功能是不一样，比如有作战班，有狙击手班，有坦克班啥的。那么k8s也是这样，根据不同的功能，将pod分成不同的类型的pod，而deployment就是其中一种类型，他的中译是部署的意思，也就是说这个类型的pod就是我们用于部署容器的。
ReplicaSet
这个是为我们建立副本的，官方的描述是
ReplicaSet 的目的是维护一组在任何时候都处于运行状态的 Pod 副本的稳定集合
怎么理解这句话呢？我们都知道每个pod都是运行在节点上的，但是我们也知道，节点是最容易出事的，万一宕机了，就会造成原本运行在这个节点的pod都不工作了，那么为了解决这个问题，一般会为pod运行多个副本，就是容器的复制版本，他们的数据都是一样的，万一某一个宕机了，k8s是立即将副本顶替运行，这样就不会造成服务不可用了。
什么？你问万一副本的节点都宕机了？不用担心，k8s集群会智能将每个副本运行在不同的节点上，（你也可以自定义，也就是后面的亲合度以及污点和污点容忍度的概念）这样就减少了服务不可用的概率。
deployment
首先让我们创建一个deployment：
kubectl create deployment mynginx --image=nginx
对于上面的命令我解释一下:
首先kubectl就不用解释了，
create是这个命令的command,至少官方是这么叫的，其实就是这个命令是主要是做什么的，比如想创建什么东西就是create,想删除什么东西就是delete,等，一共就5个还有三个是get展示什么数据信息、expose导出端口什么的、run运行什么东西
mynginx是这个pod的名字
image就是指pod的镜像，是一个nginx的镜像
deployment是一个比较高级的概念，它管理着ReplicaSet,并向 Pod 提供声明式的更新以及许多其他有用的功能。因此，在大多数的情况下，我们创建Deployment就可以实现ReplicaSet的功能，还可以实现其他功能
但是Deployment创建的pod是无状态的。那什么是无状态呢？
无状态服务不会在本地存储持久化数据.多个服务实例对于同一个用户请求的响应结果是完全一致的.这种多服务实例之间是没有依赖关系,比如web应用,在k8s控制器 中动态启停无状态服务的pod并不会对其它的pod产生影响.
也就是Deployment各个实例之间是一模一样的，就像是多胞胎一样。Deployment之间是可以相互顶替的，这也是增加了Deployment的高可用性。同时，在部署的时候，Deployment之间没有部署的先后顺序。
那既然有无状态，自然也有有状态应用
StatefulSet
stateful中译就是状态丰富的，有状态的,StatefulSet 是用来管理有状态应用的工作负载 API 对象。
有状态服务需要在本地存储持久化数据,典型的是分布式数据库的应用,分布式节点实例之间有依赖的拓扑关系.比如,主从关系. 如果K8S停止分布式集群中任 一实例pod,就可能会导致数据丢失或者集群的crash.
比如我们现在不熟一个主从关系的数据库在k8s上，那么我们知道主从是有区别的，先有主，再有从，所以在部署的时候，就要优先部署主的数据库实例，这就是有状态pod的一个例子。
DaemonSet
这是守护进程的pod，
DaemonSet 确保全部（或者某些）节点上运行一个 Pod 的副本。 当有节点加入集群时， 也会为他们新增一个 Pod 。 当有节点从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。
有些时候，有些pod我们希望每个节点都运行且只运行一个副本，比如我们的日志和监控等，也就是上面说的确保全部（或者某些）节点上运行一个 Pod 的副本，同时后面也说了，这个是智能的，有节点加入还会自动新增pod，不用担心节点的扩容后还要在部署一遍的问题。也可以统一回收，非常好用。
Job, Cronjob
job字面意思是任务，所以就像是特种兵一样，完成某个任务即可。Job 会创建一个或者多个 Pod，并将继续重试 Pod 的执行，直到指定数量的 Pod 成功终止，也就是job是一次性的，不达目的不罢休的那种。一旦达成目的就会终止。一般用于执行一次性任务
而CronJob则是定时任务，这个应该相对Job比较好理解，就是会一直重复做某些事情。
总结
上面介绍了节点和pod，我们在实际的工作中可以按照自己的需求来创建不同类型的pod，那么pod创建多了，我们应该怎么处理pod之间的网络处理呢？pod之间怎么通信呢？pod的数据怎么持久化存储呢？大话k8s（三）将会为大家解答
