三、Kubernetes 核心概念

3.1、kubernetes 集群命令行工具 kubectl

3.1.1、kubectl 概述

kubectl 是 Kubernetes 集群的命令行工具，通过 kubectl 能够对集群本身进行管理，并能够在集群上进行容器化应用的安装和部署。

3.1.2、kubectl 命令格式

kubectl [command] [type] [name] [flags]

参数：

• command：指定要对资源执行的操作，例如 create、get、describe、delete
• type：指定资源类型，资源类型是大小写敏感的，开发者能够以单数 、复数 和 缩略的形式

kubectl get pod pod1
kubectl get pods pod1
kubectl get po pod1

• name：指定资源的名称，名称也是大小写敏感的，如果省略名称，则会显示所有的资源，例如

kubectl get pods

• flags：指定可选的参数，例如，可用 -s 或者 -server 参数指定 Kubernetes API server 的地址和端口

3.1.3、kubectl 基础命令

命令	介绍
create	通过文件名或标准输入创建资源
expose	将一个资源公开为一个新的 Service
run	在集群中运行一个特定的镜像
set	在对象上设置特定的功能
get	显示一个或多个资源
explain	文档参考资料
edit	使用默认的编辑器编辑一个资源
delete	通过文件名，标准输入，资源名称或标签来删除资源

3.1.4、kubectl 部署命令

命令	介绍
rollout	管理资源的发布
rolling-update	对给定的复制控制器滚动更新
scale	扩容或缩容 Pod 数量，Deployment、ReplicaSet、RC 或 Job
autoscale	创建一个自动选择扩容或缩容并设置 Pod 数量

3.1.5、kubectl 集群管理命令

命令	介绍
certificate	修改证书资源
cluster-info	显示集群信息
top	显示资源 (CPU/M)
cordon	标记节点不可调度
uncordon	标记节点可被调度
drain	驱逐节点上的应用，准备下线维护
taint	修改节点 taint 标记

3.1.6、kubectl 故障和调试命令

命令	介绍
describe	显示特定资源或资源组的详细信息
logs	在一个 Pod 中打印一个容器日志，如果 Pod 只有一个容器，容器名称是可选的
attach	附加到一个运行的容器
exec	执行命令到容器
port-forward	转发一个或多个
proxy	运行一个 proxy 到 Kubernetes API Server
cp	拷贝文件或目录到容器中
auth	检查授权

3.1.7、kubectl 其它命令

命令	介绍
apply	通过文件名或标准输入对资源应用配置
patch	使用补丁修改、更新资源的字段
replace	通过文件名或标准输入替换一个资源
convert	不同的 API 版本之间转换配置文件
label	更新资源上的标签
annotate	更新资源上的注释
completion	用于实现 kubectl 工具自动补全
api-versions	打印受支持的 API 版本
config	修改 kubeconfig 文件（用于访问 API，比如配置认证信息）
help	所有命令帮助
plugin	运行一个命令行插件
version	打印客户端和服务版本信息

3.2、Kubernetes 集群 YAML 文件详解

3.2.1、组成部分

主要分为了两部分，一个是控制器的定义 和 被控制的对象。

在一个 YAML 文件的控制器定义中，有很多属性名称

属性名称	介绍
apiVersion	API 版本
kind	资源类型
metadata	资源元数据
spec	资源规格
replicas	副本数量
selector	标签选择器
template	Pod 模板
metadata	Pod 元数据
spec	Pod 规格
containers	容器配置

3.2.2、YAML 快速编写

一般来说，我们很少自己手写 YAML 文件，因为这里面涉及到了很多内容，我们一般都会借助工具来创建

3.2.2.1、使用 kubectl create 命令

这种方式一般用于资源没有部署的时候，我们可以直接创建一个 YAML 配置文件

# 尝试运行，并不会真正的创建镜像
kubectl create deployment web --image=nginx -o yaml --dry-run

或者我们可以输出到一个文件中

kubectl create deployment web --image=nginx -o yaml --dry-run > hello.yaml

然后我们就在文件中直接修改即可

3.2.2.2、使用 kubectl get 命令导出 yaml 文件

可以首先查看一个目前已经部署的镜像

kubectl get deploy

然后我们导出 nginx 的配置

kubectl get deploy nginx -o=yaml --export > nginx.yaml

然后会生成一个 nginx.yaml 的配置文件

3.3 Pod

3.3.1、Pod 基本概念

最小部署的单元

Pod 里面是由一个或多个容器组成【一组容器的集合】

一个 pod 中的容器是共享网络命名空间

Pod 是短暂的

每个 Pod 包含一个或多个紧密相关的用户业务容器

3.3.2、Pod 存在的意义

创建容器使用 docker，一个 docker 对应一个容器，一个容器运行一个应用进程

Pod 是多进程设计，运用多个应用程序，也就是一个 Pod 里面有多个容器，而一个容器里面运行一个应用程序

Pod 的存在是为了亲密性应用

两个应用之间进行交互

网络之间的调用【通过 127.0.0.1 或 socket】

两个应用之间需要频繁调用

3.3.3、 Pod 实现机制

Pod 主要有以下两大机制：共享网络 和 共享存储。

1、共享网络【容器通过 namespace 和 group 进行隔离】
Pod 中容器通信 过程：
同一个 namespace 下
在 Pod 中创建一个根容器： pause 容器
在 Pod 中创建业务容器 【nginx，redis 等】【创建时会添加到 pause 容器 中】
在 pause 容器 中会独立出 ip 地址，mac 地址，port 等信息，然后实现网络的共享

2、共享存储【Pod 持久化数据，专门存储到某个地方中，使用 Volumn 数据卷进行共享存储】

3.3.4、 Pod 镜像拉取策略

我们以具体实例来说，拉取策略就是imagePullPolicy

拉取策略主要分为了以下几种：

• IfNotPresent：默认值，镜像在宿主机上不存在才拉取
• Always：每次创建 Pod 都会重新拉取一次镜像
• Never：Pod 永远不会主动拉取这个镜像

3.3.5、 Pod 资源限制

也就是我们 Pod 在进行调度的时候，可以对调度的资源进行限制
例如我们限制 Pod 调度是使用的资源是 2C4G，那么在调度对应的 node 节点时，只会占用对应的资源，对于不满足资源的节点，将不会进行调度。

这里分了两个部分：

• request：表示调度所需的资源
• limits：表示最大所占用的资源

3.3.6、 Pod 重启机制

因为 Pod 中包含了很多个容器，假设某个容器出现问题了，那么就会触发 Pod 重启机制

重启策略主要分为以下三种：

• Always：当容器终止退出后，总是重启容器，默认策略 【nginx 等，需要不断提供服务】
• OnFailure：当容器异常退出（退出状态码非 0）时，才重启容器。
• Never：当容器终止退出，从不重启容器 【批量任务】

3.3.7、 Pod 健康检查

1、通过容器检查

kubectl get pod

2、通过应用检查

# 存活检查，如果检查失败，将杀死容器，根据 Pod 的 restartPolicy【重启策略】来操作
livenessProbe

# 就绪检查，如果检查失败，Kubernetes 会把 Pod 从 Service endpoints 中剔除
readinessProbe

Probe 支持以下三种检查方式

• http Get：发送 HTTP 请求，返回 200 - 400 范围状态码为成功
• exec：执行 Shell 命令返回状态码是 0 为成功
• tcpSocket：发起 TCP Socket 建立成功

3.3.8、 Pod 调度策略

创建 Pod 流程：

• 首先创建一个 pod，然后创建一个 API Server 和 Etcd【把创建出来的信息存储在 etcd 中】
• 然后创建 Scheduler，监控 API Server 是否有新的 Pod，如果有的话，会通过调度算法，把 pod 调度某个 node 上
• 在 node 节点，会通过 kubelet – apiserver 读取 etcd 拿到分配在当前 node 节点上的 pod，然后通过 docker 创建容器
  

3.4、Controller

3.4.1、Controller 概述

Controller 是集群上管理和运行容器的对象

• Controller 是实际存在的
• Pod 是虚拟机的

3.4.2、Pod 和 Controller 的关系

Pod 是通过 Controller 实现应用的运维，比如弹性收缩，滚动升级。

Pod 和 Controller 之间是通过 label 标签建立关系，同时 Controller 又被称为控制器工作负载。

• Controller【控制器】【工作负载】selector: app:nginx
• Pod【容器】labels: app:nginx

3.4.3、Deployment 控制器应用

Deployment 表示用户对 K8S 集群的一次更新操作。

Deployment 控制器可以部署无状态应用

• 管理 Pod 和 ReplicaSet
• 部署，滚动升级等功能
• 应用场景：web 服务，微服务

3.4.4、Deployment 部署应用

使用 Deploment 部署应用

kubectrl create deployment web --image=nginx

使用 YAML 文件进行配置：【快速编写 YAML 文件】

kubectl create deployment web --image=nginx -o yaml --dry-run > nginx.yaml

nginx.yaml:【selector 和 label 就是我们 Pod 和 Controller 之间建立关系的桥梁】

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  # Pod
  labels:
    app: web
  name: web
spec:
  replicas: 1
  # Controller
  selector:
    matchLabels:
      app: web
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: web
    spec:
      containers:
      - image: nginx
        name: nginx
        resources: {}
status: {}

现在，使用nginx.yaml文件创建镜像：

kubectl apply -f nginx.yaml

然后，对外暴露端口：

kubectl expose deployment web --port=80 --type=NodePort --target-port=80 --name=web1

# 参数说明
# --port：就是我们内部的端口号
# --target-port：就是暴露外面访问的端口号
# --name：名称
# --type：类型

3.4.5、升级回滚和弹性收缩

3.4.5.1、应用升级

kubectl set image deployment web nginx=nginx:1.15

首先是开始的 nginx 1.14 版本的 Pod 在运行，然后 1.15 版本的在创建
然后在 1.15 版本创建完成后，就会暂停 1.14 版本
最后把 1.14 版本的 Pod 移除，完成我们的升级
这么做的好处就是：升级可以保证服务不中断

3.4.5.2、查看升级状态

kubectl rollout status deployment web

3.4.5.3、查看升级状态

kubectl rollout history deployment web

3.4.5.4、应用回滚

# 查看历史版本
kubectl rollout history deployment web

# 回滚到上一版本
kubectl rollout undo deployment web

# 回滚到指定版本
kubectl rollout undo deployment web --to-revision=2

3.4.5.5、弹性伸缩

# 通过命令创建多个副本
kubectl scale deployment web --replicas=10