一个是k8s是什么，怎么用的，都有哪些组件，组件的作用，组件的流量是怎么样的，另一个是k8s自带的/支持的资源对象都有哪些，字段可以先不用看，然后那些对象的作用或者怎么使用的，然后一个服务是如何运行的，以什么方式，由什么管理?
1）功能：
服务发现和负载均衡，存储编排，自动部署和回滚，自动二进制打包，自我修复，密钥与配置管理。不支持日志记录、监视和报警，这些需要普罗米修斯。
2）集群架构：
Master：
负责管理集群，部署集群所需组件etcd，apiserver，controller manager，scheduler。master 协调集群中的所有活动，例如调度应用程序、维护应用程序的所需状态、扩展应用程序和滚动更新。
Node：
节点是 Kubernetes 集群中的工作节点，用于托管正在运行的应用程序，可以是物理机或虚拟机。 每个工作节点都有一个 kubelet和kube-proxy，它是管理节点并与 Kubernetes Master 节点进行通信的代理。节点上还应具有处理容器操作的容器运行时，例如 Docker 或 rkt。一个 Kubernetes 工作集群至少有三个节点。
参考文献：https://kuboard.cn/
| Master组件：集群的控制平台。 | |
|---|---|
| etcd | 保存了集群的状态信息，高可用的键值存储，保证一致性。 |
| api server | 提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制。 |
| controller manager | 负责维护集群的状态，如故障检测、自动扩展、滚动更新等 |
| scheduler | 负责资源的调度，按照预定的调度策略将pod调度到相应的机器上。 |
| Node组件:运行在每一个节点上，包括master和worker节点，负责维护运行中的pod并提供k8s运行时环境。 | |
| kubelet | 负责维护容器的生命周期，同时负责volume(CVI)和网络(CNI)的管理。 |
| container runtime | 负责镜像管理以及pod和容器的真正运行（CRI）。 |
| Kube-proxy | 负责为service提供cluster集群内部的服务发现和负载均衡。 |
| 插件： | |
| kube-dns | 为整个集群提供DNS服务。 |
| Ingress controller | 为服务提供外网入口。 |
| Heapster | 提供资源监控。 |
| Dashboard | 提供GUI。 |
| Federation | 提供跨可用去的集群。 |
| Fluented-elasticsearch | 提供集群日志采集、存储与查询。 |
各个组件运行的流程：
1.用户通过kubectl提交需要运行的docker容器(pod)
2.api server把请求存储在etcd里面
3.schedule进行扫描，分配工作节点
4.kubelet找到自己需要跑的容器，在本机上运行
Kubernetes对象指的是Kubernetes系统的持久化实体，所有这些对象合起来，代表了你集群的实际情况。常规的应用里，我们把应用程序的数据存储在数据库中，Kubernetes将其数据以Kubernetes对象的形式通过 api server存储在 etcd 中。
操作 Kubernetes 对象（创建、修改、删除）的方法主要有：
kubectl 命令行工具
kuboard 图形界面工具
kubectl、kuboard 最终都通过调用 kubernetes API 来实现对 Kubernetes 对象的操作。
[root@k8s-master1 ~]# kubectl --help
#将资源对象以什么格式输出：
# Kubectl get -o json/yaml 资源对象 资源对象名
资源清单文件格式：
1）每个对象包含两个嵌套的字段：对象spec（必须由您来提供，对象的期望状态）、对象status（只能由 Kubernetes 系统来修改，对象在系统中的实际状态）
2）通过yaml文件创建对象：
考虑是否做副本，不做副本就以pod方式部署应用；做副本就需要以deployment方式部署应用，而且还需要部署一个service
a.编写yaml文件
[root@dev-k8s-master1 k8s]# cat deployment.yaml
apiVersion: apps/v1 #创建该对象所使用的 Kubernetes API 的版本
kind: Deployment #想要创建的对象的类型
metadata: #帮助识别对象唯一性的数据，包括一个 name 字符串、UID 和可选的 namespace
name: nginx-deployment #对象名
spec:
selector:
matchLabels:
app: nginx
replicas: 2 # 运行 2 个容器化应用程序副本
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
# kind:这里我们创建的是一个Pod，当然根据你的实际情况,这里的资源类型可以是 Deployment,Job,ngress,Service等.
# metadata: 包含了我们定义的Pod的一些meta信息，比如名称namespace、标签等等信息.
# spec:包括一些containers,storage,volumes,或者其他Kubernetes需要知道的参数,以及诸如是否 在容器失败时重新启动容器的属性,
b.创建该 .yaml 文件中的对象：
[root@dev-k8s-master1 k8s]# kubectl apply -f deployment.yaml
deployment.apps/nginx-deployment created
删除该yaml文件中的对象：
[root@dev-k8s-master1 k8s]# kubectl delete -f deployment.yaml
deployment.apps "nginx-deployment" deleted
3）资源对象：Pod、ReplicaSet、ReplicationController、Deployment、StatefulSet、DaemonSet、Job、CronJob、 HorizontalPodAutoscaling、Node、Namespace、Service、Ingress、Label、CustomResourceDefinition
名称空间的用途是，为不同团队的用户（或项目）提供虚拟的集群空间，也可以用来区分开发环境/测试环境、准上线环境/生产环境。
名称空间为 名称 提供了作用域。名称空间内部的同类型对象不能重名，但是跨名称空间可以有同名同类型对象。名称空间不可以嵌套，任何一个Kubernetes对象只能在一个名称空间中。
注：当KUbernetes对象之间的差异不大时，无需使用名称空间来区分，例如，同一个软件的不同版本，只需要使用 labels 来区分即可。
1）查看名称空间：
[root@dev-k8s-master1 k8s]# kubectl get ns
NAME STATUS AGE
default Active 251d #默认名称空间，如果 Kubernetes 对象中不定义 metadata.namespace 字段，该对象将放在此名称空间下
kube-system Active 251d #系统创建的对象放在此名称空间下
kube-public Active 251d #此名称空间自动在安装集群是自动创建，并且所有用户都是可以读取的（即使是那些未登录的用户）。主要是为集群预留的。
#查看某个名称空间的详细信息：
[root@dev-k8s-master1 k8s]# kubectl describe namespaces default
名称空间可能有两种状态（phase）：
Active 名称空间正在使用中
Termining 名称空间正在被删除，不能再向其中创建新的对象
2）创建或者删除名称空间：通过yaml文件或者命令行
#1.编写yaml文件
[root@dev-k8s-master1 k8s]# cat my-namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
name: my-namespace
#2.使用kubectl create -f xxx.yaml命令创建
[root@dev-k8s-master1 k8s]# kubectl create -f my-namespace.yaml
namespace/my-namespace created
#1.直接使用命令创建：kubectl create namespace 名称空间名
[root@dev-k8s-master1 k8s]# kubectl create namespace my-namespace2
namespace/my-namespace2 created
#1.在查询别的时候条件为名称空间
kubectl run nginx --image=nginx --namespace=<您的名称空间>
kubectl get pods --namespace=<您的名称空间>
[root@dev-k8s-master1 ~]# kubectl get pod --namespace fleet-system
NAME READY STATUS RESTARTS AGE
fleet-agent-8474f99d8b-f5qws 1/1 Running 2 97d
#1.删除某个名称空间
[root@dev-k8s-master1 k8s]# kubectl delete namespaces my-namespace
namespace "my-namespace" deleted
非命名空间资源/命名空间资源：大多数资源都在命名空间，而那些底层资源并不在命名空间：节点/持久化卷
# 位于名字空间中的资源
kubectl api-resources --namespaced=true
# 不在名字空间中的资源
kubectl api-resources --namespaced=false
pod创建的大体流程：
注：有两个特殊的控制器：MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook。 它们根据 API 中的配置，分别执行变更和验证 准入控制 webhook。
注：准入控制器可以执行 “验证（Validating）” 和/或 “变更（Mutating）” 操作。 变更（mutating）控制器可以修改被其接受的对象；验证（validating）控制器则不行。
启动一个pod时，至少会有两个容器，pod容器和业务容器，多个业务容器会共享一个pod容器（一组容器的集合），那么一个Pod中的容器共享网络命名空间，
pod代表着集群中运行的进程。Pod封装着应用的容器、存储、独立的网络IP，管理容器如何运行的策略选项。
两种使用方式：
a.一个pod中运行一个容器，k8s管理的是pod而不是直接管理容器。
b.一个pod同时运行多个容器，他们之间共享资源（网络和存储），总是被同时调度，这些在同一个Pod中的容器可以互相协作成为一个service单位。同一个pod被自动分配到同一个node上。
每个pod会被分配一个唯一的IP地址。可以为一个pod指定多个共享的volume。
1）Pod容器分类
Infrastructure Container：基础容器，维护整个Pod网络空间
InitContainers：初始化容器，先于业务容器开始执行
Containers：业务容器，并行启动
2）Pod存在的意义：为亲密性应用而存在
两个应用之间发生文件交互
两个应用需要通过127.0.0.1或socker通信
两个应用需要发生频繁的调用
3）pod基本操作：
# 指定yaml文件创建pod
kubectl create -f [yaml文件路径]
#查看pod基本信息
kubectl get pods
Kubectl get -f xxx.yaml
#创建pod：命令行/sdk/YAML文件 kubectl create -f xxx.yaml
# 查看pod详细信息
kubectl describe pod [pod名]
# 更新pod（修改了yaml内容）
kubectl apply -f [yaml文件路径]
# 删除指定pod
kubectl delete pod [pod名]
使用清单文件删除：kubectl delete -f xxx.yml
# 强制删除指定pod
kubectl delete pod [pod名] --foce --grace-period=0
获取pod安全策略：kubectl get psp
修改pod安全策略：kubectl edit psp 策略名
删除pod安全策略：kubectl delete psp 策略名
默认情况下pod名会以rc名+随机值组成
4）Pod与controllers的关系
controllers：在集群上管理和运行容器的对象
通过label-selector相关联
Pod通过控制器实现应用的运维，如伸缩，滚动升级等。
5）Pod的常用属性定义
除了上文定义的一些属性字段，我们常用的属性还有以下字段定义：
**NodeSelector：**是一个供用户将 Pod 与 Node 进行绑定的字段
ImagePullPolicy：[Always | Never | IfNotPresent] # 【String】 每次都尝试重新拉取镜像 | 仅使用本地镜像 | 如果本地有镜像则使用，没有则拉取
Volume：volume是Pod中多个容器访问的共享目录volume被定义在pod上，被这个pod的多个容器挂载到相同或不同的路径下。一般volume被用于持久化pod产生的数据。Kubernetes提供了众多的volume类型，包括emptyDir、hostPath、nfs、glusterfs、cephfs、ceph rbd等。
NodeName：一旦 Pod 的这个字段被赋值，Kubernetes 项目就会被认为这个 Pod 已经经过了调度，调度的结果就是赋值的节点名字。所以，这个字段一般由调度器负责设置，但用户也可以设置它来“骗过”调度器，当然这个做法一般是在测试或者调试的时候才会用到。
HostAliases：定义了 Pod 的 hosts 文件（比如 /etc/hosts）里的内容。
6）Service account是为了方便Pod里面的进程调用Kubernetes API或其他外部服务。sa仅限在ns
运行在pod里的进程需要调用Kubernetes API以及非Kubernetes API的其它服务。Service Account它并不是给kubernetes集群的用户使用的，而是给pod里面的进程使用的，它为pod提供必要的身份认证。
（1）每个Pod在创建后都会自动设置spec.serviceAccount为default（除非指定了其他ServiceAccout）；
（2）每个container启动后都会挂载对应的token和ca.crt到/var/run/secrets/kubernetes.io/serviceaccount/。
禁止pod调度到该节点上：kubectl cordon <node>
驱逐该节点还是那个所有的pod：kubectl drain <node>
#会删除节点上的所有pod，在其他node上重新启动它们，一般用于维护该节点时，因为在使用该命令等于使用了kubectl corden <node>,等节点维护完成后，启动kubelet后再使用kubectl uncorden <node>,这样就可将该节点添加到集群中。
常见pod控制器：
注：因为ReplicaSet不⽀持rolling-update但Deployment⽀持。
Replication Controller 副本控制器，应用托管在Kubernetes之后,Kubernetes需要保证应用能够持续运行，这是RC的工作内容，它会确保任何时间Kubernetes中都有指定数量的Pod正在运行。在此基础上，RC还提供了一些高级的特性，比如滚动升级、升级回滚等。
ReplicationController⽤来确保容器应⽤的副本数始终保持在⽤户定义的副本数，即如果有容器异常退出，会⾃动创建 新的Pod来替代；⽽如果异常多出来的容器也会⾃动回收。
a.创建一个rc:
[root@dev-k8s-master1 k8s]# cat myweb.yaml
apiVersion: v1
kind: ReplicationController
metadata:
name: myweb
spec:
replicas: 2
selector:
app: myweb
template:
metadata:
labels:
app: myweb
spec:
containers:
- name: nginx01
image: reg.betensh.com/docker_case/nginx:1.13
ports:
- containerPort: 80
[root@dev-k8s-master1 k8s]# kubectl create -f myweb.yaml
replicationcontroller/myweb created
[root@dev-k8s-master1 k8s]# kubectl get pods
NAME READY STATUS RESTARTS AGE
myweb-225sr 0/1 ImagePullBackOff 0 11s
myweb-ljlg9 0/1 ErrImagePull 0 11s
默认情况下pod名会以rc名+随机值组成
RC通过标签选择器（labels）来控制pod，RC名称必须要和标签选择器名称一致
[root@dev-k8s-master1 k8s]# kubectl get rc -o wide
NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR
myweb 2 2 0 66s nginx01 reg.betensh.com/docker_case/nginx:1.13 app=myweb
Deployment 实际控制的是ReplicaSet对象，由ReplicaSet来管理Pod：
你只需要在Deployment中描述您想要的目标状态是什么，Deployment controller就会帮您将Pod和ReplicaSet的实际状态改变到您的目标状态。您可以定义一个全新的Deployment来,创建ReplicaSet或者删除已有的 Deployment并创建一个新的来替换。也就是说Deployment是可以管理多个ReplicaSet的。
典型的应⽤场景包括：
定义Deployment来创建Pod和ReplicaSet
滚动升级和回滚应⽤
扩容和缩容
暂停和继续Deployment
问：deployment也是保证pod高可用的一种方式，明明有RC为何还要引入deployment呢？
答：因为deployment解决了RC的一个痛点，当使用RC升级容器版本后，标签会发生变化，那么svc的标签还是原来的，这样就需要手动修改svc配置文件。
Deployment 在⽣命周期中有多种状态。在创建⼀个新的 ReplicaSet 的时候它可以是 progressing 状态， complete 状 态，或者 fail to progress 状态。
a.进⾏中的 Deployment Kubernetes :progressing
Deployment 正在创建新的ReplicaSet过程中。
Deployment 正在扩容⼀个已有的 ReplicaSet。
Deployment 正在缩容⼀个已有的 ReplicaSet。
有新的可⽤的 pod 出现。
b.完成的 Deployment Kubernetes:complete
Deployment 最⼩可⽤。最⼩可⽤意味着 Deployment 的可⽤ replica 个数等于或者超过 Deployment 策略中的期望 个数。
所有与该 Deployment 相关的replica都被更新到了您指定版本，也就说更新完成。
该 Deployment 中没有旧的 Pod 存在。
注：⽤ kubectl rollout status 命令查看 Deployment 是否完成。如果 rollout 成功完成， kubectl rollout status 将返回 ⼀个0值的 Exit Code。
c.失败的 Deployment：fail to progress： Deployment 在尝试部署新的 ReplicaSet 的时候可能卡住，永远也不会完成。
⽆效的引⽤
不可读的 probe failure
镜像拉取错误
权限不够
范围限制
程序运⾏时配置错误
a.创建deployment
[root@dev-k8s-master1 k8s]# cat deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
selector:
matchLabels:
app: nginx
replicas: 2 # 运行 2 个容器化应用程序副本
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
[root@dev-k8s-master1 k8s]# kubectl create -f deployment.yaml
查看deployment启动状态：deployment会先启动一个rs，而后在启动pod
[root@dev-k8s-master1 k8s]# kubectl get deployment
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 2/2 2 2 22h
[root@dev-k8s-master1 k8s]# kubectl get all
NAME READY STATUS RESTARTS AGE
pod/nginx-deployment-5bf87f5f59-h75x8 1/1 Running 0 22h
pod/nginx-deployment-5bf87f5f59-xbhhd 1/1 Running 0 22h
b.关联service
[root@dev-k8s-master1 k8s]# kubectl expose deployment nginx-deployment --port=80 --type=NodePort
service/nginx-deployment exposed
查看svc:
[root@dev-k8s-master1 k8s]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 21.0.0.1 <none> 443/TCP 252d
nginx-deployment NodePort 21.0.87.194 <none> 80:21575/TCP 14s
c.deployment升级
#直接编辑对应deployment，并修改镜像版本
kubectl edit deployment nginx-deployment
#通过 set image 发布新的镜像
kubectl set image deploy nginx-deployment nginx-deployment=nginx:1.17
d.deployment回滚
#回滚到上一级版本
kubectl rollout undo deployment nginx-deployment
#回滚到指定版本
kubectl rollout undo deployment nginx-deployment --to-revision=1
#查看当前deploy历史版本
kubectl rollout history deployment nginx-deployment
首先Deployment只是用于无状态服务,无差别并且没有顺序的Pod，而StatefulSet支持多个Pod之间的顺序性，用于 每个Pod中有自己的编号，需要互相访问，以及持久存储区分
DaemonSet能够让所有（或者一些特定）的Node节点仅运行一份Pod。当节点加入到kubernetes集群中，Pod会被（DaemonSet）调度到该节点上运行，当节点从kubernetes集群中被移除，被（DaemonSet）调度的Pod会被移除，如果删除DaemonSet，所有跟这个DaemonSet相关的pods都会被删除。
使⽤ DaemonSet 的⼀些典型⽤法：
运⾏集群存储 daemon，例如在每个 Node 上运⾏ glusterd 、 ceph 。
在每个 Node 上运⾏⽇志收集 daemon，例如 fluentd 、 logstash 。
在每个 Node 上运⾏监控 daemon，例如 Prometheus Node Exporter、 collectd 、Datadog 代理、New Relic 代 理，或 Ganglia gmond 。
⼀个简单的⽤法是，在所有的 Node 上都存在⼀个 DaemonSet，将被作为每种类型的 daemon 使⽤。 ⼀个稍微复杂的 ⽤法可能是，对单独的每种类型的 daemon 使⽤多个 DaemonSet，但具有不同的标志，和/或对不同硬件类型具有不同 的内存、CPU要求。
即： 在给定时间点只运⾏⼀次 或者周期性地在给定时间点运⾏ 。
⼀个 CronJob 对象类似于 crontab （cron table）⽂件中的⼀⾏。它根据指定的预定计划周期性地运⾏⼀个 Job，格式 可以参考 Cron 。
a.创建一个cronjob:命令行或者yaml文件
kubectl run hello --schedule="*/1 * * * *" --restart=OnFailure --image=busybox -- /bin/sh -c "date; echo Hello from the Ku bernetes cluster"
$ kubectl get cronjob
NAME SCHEDULE SUSPEND ACTIVE LAST-SCHEDULE
hello */1 * * * * False 0 <none>
$ kubectl get jobs
NAME DESIRED SUCCESSFUL AGE
hello-1202039034 1 1 49s
# 注意，删除 cronjob 的时候不会⾃动删除 job，这些 job 可以⽤ kubectl delete job 来删除
$ kubectl delete cronjob
hello cronjob "hello" deleted
通过Service为pod客户端提供访问pod方法，即客户端访问pod入口Service通过Pod标签与Pod进行关联
1) Service类型
ClusterIP：默认，分配一个集群内部可以访问的虚拟IP
NodePort：在每个Node上分配一个端口作为外部访问入口
LoadBalancer：工作在特定的Cloud Provider上，例如Google Cloud，AWS，OpenStack
ExternalName：表示把集群外部的服务引入到集群内部中来，即实现了集群内部pod和集群外部
的服务进行通信
2) Service参数
port ：访问service使用的端口
targetPort ：Pod中容器端口
NodePort ：通过Node实现外网用户访问k8s集群内service
PV 的全称是：PersistentVolume（持久化卷），是对底层的共享存储的一种抽象，PV 由管理员进行创建和配置，它和具体的底层的共享存储技术的实现方式有关，比如 Ceph、GlusterFS、NFS 等，都是通过插件机制完成与共享存储的对接。
PVC 的全称是：PersistentVolumeClaim（持久化卷声明），PVC 是用户存储的一种声明，PVC 和 Pod 比较类似，Pod 消耗的是节点，PVC 消耗的是 PV 资源，Pod 可以请求 CPU 和内存，而 PVC 可以请求特定的存储空间和访问模式。对于真正使用存储的用户不需要关心底层的存储实现细节，只需要直接使用 PVC 即可。