云原生二十篇|Kubernetes基础知识

Kubernetes简称k8s，由于篇幅的原因，所以将k8s拆分为4篇文章：

• Kubernetes基础知识
• Kubernetes核心原理
• Kubernetes实践
• Kubernetes源码解析

先上一个k8s的总体架构图：

Kubernetes架构

1、为什么需要Kubernetes？

在了解为什么需要Kubernetes之前，先说说Kubernetes是什么？Kubernetes简称k8s，可以认为是Google的Borg开源版本，是大规模集群管理系统，基于容器技术，目的是实现资源管理的自动化，以及跨多个数据中心的资源利用率最大化。

为什么需要k8s？我总结大概有几个原因：

(1)当前云原生时代k8s能火的一个原因：这是一门看似美好的新技术(这个并非贬义，我这里是中性表达，毕竟现在很多人也吐槽k8s架构复杂，并未考虑到老的系统升级)，不过对一些大型公司而已，通过k8s的确统一了很多云上的资源，即使没有k8s，很多中大型公司都有自己的资源管理平台，不过k8s将这一技术架构统一了，虽然未能解决定制化问题，但是技术架构的确新，而且为后续扩展提供了多种可能。

(2)从运维和开发角度来说，使用k8s我们不再需要费心于负载均衡的选择和实施部署问题，不必再考虑引入复杂的服务治理框架，不需要再头疼于服务监控和故障处理模块的开发，总之是方便让开发者更加关注业务本身。

2、简单的样例

在开始样例之前，我们可以找一台centos机器执行如下命令：

# 关闭防火墙
systemctl disable firewalld
systemctl stop firewalld

# 安装etcd和kubernetes
yum install -y etcd kubernetes

# 启动服务
systemctl start etcd
systemctl start docker
systemctl start kube-apiserver
systemctl start kube-controller-manager
systemctl start kube-scheduler
systemctl start kubelet
systemctl start kube-proxy

# 查看k8s运行情况
kubectl version
# 输出结果
Client Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.2", GitCommit:"269f928217957e7126dc87e6adfa82242bfe5b1e", GitTreeState:"clean", BuildDate:"2017-07-03T15:31:10Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.2", GitCommit:"269f928217957e7126dc87e6adfa82242bfe5b1e", GitTreeState:"clean", BuildDate:"2017-07-03T15:31:10Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"}

# 解决k8s创建pod报错No API token found for service account "default", retry after the token is automatically
openssl genrsa -out /etc/kubernetes/serviceaccount.key 2048
# vim /etc/kubernetes/apiserver，添加如下内容：KUBE_API_ARGS="--service_account_key_file=/etc/kubernetes/serviceaccount.key"
# vim /etc/kubernetes/controller-manager，添加如下内容：KUBE_CONTROLLER_MANAGER_ARGS="--service_account_private_key_file=/etc/kubernetes/serviceaccount.key"
# 重启k8s
systemctl restart etcd kube-apiserver kube-controller-manager kube-scheduler

(1) 启动一个nginx的pod

创建文件nginx-pod.yaml文件如下：

apiVersion: v1 #必选 版本号
kind: ReplicationController #必选
metadata:   # 必选 元数据
    name: nginx  # 必选 Pod名称
    labels:   # 自定义标签
        app: nginx  # 自定义标签名称
spec:    # 必选 Pod中容器的详细定义
    containers:  # 必选 Pod中容器列表，一个pod里会有多个容器
        - name: nginx  # 必选 容器名称
        image: nginx  # 必选 容器的镜像名称
        imagePullPolicy: IfNotPresent # [Always | Never | IfNotPresent] 获取镜像的策略 Alawys表示下载镜像 IfnotPresent表示优先使用本地镜像，否则下载镜像，Nerver表示仅使用本地镜像 
       ports: # 需要暴露的端口库号列表
       - containerPort: 80 # 容器需要监听的端口号
restartPolicy: Always # [Always | Never | OnFailure] # Pod的重启策略，Always表示一旦不管以何种方式终止运行，kubelet都将重启，OnFailure表示只有Pod以非0退出码退出才重启，Nerver表示不再重启该Pod 

执行：

kubectl create -f nginx-pod.yaml

查看容器状态：

[root@VM-0-11-centos ~]# kubectl get pods
NAME      READY     STATUS              RESTARTS   AGE
nginx     0/1       ContainerCreating   0          2m

(2) 启动一个nginx的service

创建文件nginx-svc.yaml文件如下：

apiVersion: v1   # 必选 版本号
kind: Service       # 必选
metadata:   # 必选 元数据
    name: service-hello  # 必选 Pod名称
    labels:   # 自定义标签
        name: service-hello # 自定义标签名称
spec:    # 必选 Pod中容器的详细定义
    type: NodePort # 这里代表是NodePort类型的,另外还有ingress,LoadBalancer 
    ports: 
    - port: 80 # 这里的端口和clusterIP(kubectl describe service service-hello中的IP的port)对应，即在集群中所有机器上curl clusterIP:80可访问发布的应用服务
     targetPort: 8080 # 端口一定要和contrainer暴露出来的端口对应，nodejs暴露出来的端口是8080
     protocol: TCP
     nodePort: 31111 # 所有的节点都会开发此端口30000~32767，此端口供外部调用
    selector:
     run: hello  # 这里选择器一定要选择容器的标签

执行：

kubectl create -f nginx-svc.yaml

查看service状态：

[root@VM-0-11-centos ~]# kubectl get service
NAME            CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
kubernetes      10.254.0.1       <none>        443/TCP        37m
service-hello   10.254.251.205   <nodes>       80:31111/TCP   30s

(3) 访问服务

可以通过curl -i 'http://{服务器IP}:31111'访问对应的服务。

3、资源对象

k8s的资源对象包括Node，Pod，Controller，Service等，下面来介绍一下这些相关的资源对象。

(1) Master

Master在k8s中是集群控制节点，基本上所有的控制命令都会发给master节点，所以也需要考虑高可用，通常是多台Master组成一个高可用集群。

Master节点上运行一些服务，如下：

• API Server：提供HTTP接口，负责操作集群的增删改查
• Controller Manager：自动化控制中心，通过循环监听事件，统一处理各个资源对象
• Scheduler：负责Pod的调度
• etcd：相当于k8s的数据库，保存所有的资源信息

(2) Node

Node节点可以认为是工作节点，一般是物理主机或者虚拟机的形式存在，统一由k8s的Master节点管理，当某个Node不可用或者退出当前集群时，master都会感知其状态，从而重新调度Node，Master是如何感知这些Node呢？需要借助Node上的几个服务：

• kublet：负责Pod的生命周期，同时将各个信息上报给Master
• kube-proxy：实现k8s中的service代理的角色，主要是提供服务负载均衡

可以通过命令查看node状态等信息：

kubectl get nodes # 查看信息
kubectl describe node # 查看详情

(3) Pod

Pod对于使用过k8s的开发应该不陌生，这个是最基础的调度单元，为什么需要有Pod存在？

首选在前面容器的文章中介绍过容器，理论上容器应该是最小调度单元才对吧？不对，容器应该是单个进程部署(当然也有开发将容器当虚拟机用，部署多个进程)，那么一个业务只有一个进程么，显然不一定，在微服务架构中的一个服务可能是包含多个进程组件，这些进程组件理应打包为一个大的服务单元，所以以Pod的方式更好管理；

其次如果一个服务中的某个组件挂了，认为这个服务是可用还是不可用呢？最保守的做法是不可用，所以将这些服务放在一个Pod单元中，如果某个服务挂了，那么可以认为这个Pod不可用；

最后以Pod为单位的所有容器服务，共享网络，Volume等，更简化了架构设计；

说回Pod，Pod相关的概念有哪些呢？

Pod组成

• Pause：初始化容器，主要为Pod提供共享网络，Volume等，同时pause容器的生命周期就是Pod的生命周期
• containerPort：暴露Pod对集群内的端口，其中Pod是按照每个Pod都会有一个IP，这个IP只能是在相同的k8s集群内才能使用
• Requests：Pod作为容器调度的最小单元，当然就需要有对应的资源限定，其中Requests就是一个Pod最小运行的在Node上分配的资源，比如0.5核512M等
• Limits：Pod有最小运行单元，当然也就有最大运行限制，其中Limits就是限制CPU和内存的使用，这里要注意的是这个是一个预期值，当Node资源够的情况下可以超过限制，但是当Node节点资源调度不过来的时候，超过Limits的情况下，Pod有可能会被kill调重新调度
• Volume：挂载的存储卷，能够被多个容器访问的共享目录，Volume生命周期Volume与Pod的生命周期相同，但与容器的生命周期不相关，当容器终止或者重启时，Volume中的数据也不会丢失

(4) Label

先来一个例子：

spec:
    name: myweb
    labels:
        app: myweb

• Label主要方便kube-scheduler定向调度到指定标签上的pod
• kube-proxy通过Service的Label选择对应的Pod，实现对应的路由转发

(5) Deployment

为了更好地解决服务编排的问题，k8s在V1.2版本开始，引入了deployment控制器，值得一提的是，这种控制器并不直接管理pod，而是通过管理replicaset来间接管理pod，即：deployment管理replicaset，replicaset管理pod，所以deployment比replicaset的功能更强大，其关系如下：

Deployment

deployment的主要功能有下面几个：

• 支持replicaset的所有功能
• 支持发布的停止、继续
• 支持版本的滚动更新和版本回退

查看deployments命令：

kubectl get deployments

(6) HPA

为了实现集群自动化，扩缩容在k8s肯定是需要得到支持，其中Horizontal Pod Autoscaler(HPA)就是通过跟踪Pod的负载变化，动态调整目标Pod的副本数(当高于阈值就扩容，低于阈值就缩容)，当前Pod的度量指标有两种方式：

• CPU利用率的平均值，这里计算的所有Pod的平均值，如果负载不均出现某个Pod很高，但是平均值不高，也不出触发HPA进行扩容
• 程序自定义的度量指标，这里自定义指标可以通过Prometheus和Prometheus-Adapter来实现的，Prometheus用于监控应用的负载和集群本身的各种指标，Prometheus Adapter可以使用Prometheus收集的指标并使用它们来制定扩展策略，这些指标都是通过APIServer暴露

自定义扩容样例，比如nginx_http_requests的值到达10的情况，执行扩容：

apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-custom-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx-exporter
  minReplicas: 2
  maxReplicas: 5
  metrics:
  - type: Pods
    pods:
      metricName: nginx_http_requests
      targetAverageValue: 10

(7) StatefulSet

我们从上面的介绍中知道每个Pod都会有对应IP和Volume，这些生命周期都会和Pod保持一致，所以服务看上去都是无状态的，但是面对有状态的服务在k8s是怎么处理的呢？StatefulSet就是为了解决这个问题，有如下特性：

• StatefulSet的Pod都是固定的标志，比如nginx-0，nginx-1，nginx-2...
• StatefulSet的Pod的启动是有顺序的，一般按照固定标识的0~n的顺序启动
• StatefulSet的Pod的存储卷通过PV/PVC实现，删除Pod默认不会删除与StatefulSet相关的存储卷
• 这里注意的是在有的云厂商提供IP固定的StatefulSet，但是这个在官方StatefulSet是没有保证IP不变的功能

(8) Service

Service是k8s经常被使用的功能，为服务提供了入口，其在k8s中的角色如下图：

Service

前端应用通过Service访问部署在Pod中的业务逻辑，其中Label Selector是选择对应的Pod，那么其中有几个组件：

• kube-proxy：每个Node上都有一个kube-proxy，主要是负责均衡，负责Service到Pod之间的转发
• Cluster IP：Service的全局唯一虚拟IP，在Service生命周期内，Cluster IP是不变的，但是这个IP并非一个实体，在k8s集群外是没法访问，只能在k8s的集群内访问
• Node IP：Node节点的IP地址，一般是物理IP
• Pod IP：Pod的IP地址，生命周期与Pod相同
• NodePort：前面提到了Service的Cluster IP能在k8s集群内的访问，但是无法被k8s集群外的其他服务访问，如何解决？通过在每个Node上开一个NodePort端口，然后与Service的port组成映射关系，那么每个Node IP+NodePort就能进入Service，从而进入k8s集群内访问

获取Cluster IP如下：

[root@VM-0-11-centos ~]# kubectl get svc service-hello
NAME            CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
service-hello   10.254.251.205   <nodes>       80:31111/TCP   1d

(9) Volume

Volume是能被Pod中多个容器访问的共享目录，其样例如下：

apiVersion: v1
kind: Pod   # 资源类型是pod
metadata:
  name: vol1
spec:
  containers:  # 创建两个容器
  - image: busyboxplus
    name: vm1
    command: ["sleep", "300"]
    volumeMounts:
    - mountPath: /cache  # 容器vm1挂载的目录
      name: cache-volume
  - name: vm2
    image: nginx
    volumeMounts:
    - mountPath: /usr/share/nginx/html  # 容器vm2挂载的目录
      name: cache-volume
  volumes:
  - name: cache-volume
    emptyDir:   # 创建empty卷
      medium: Memory # 基于内存
      sizeLimit: 100Mi # 限制大小100M6

其中Volume有几个资源类型：

• emptyDir：临时目录，生命周期是在Pod在当前Node被移除时候清理，其中存储类型由medium决定
• hostPath：挂载在宿主机上的目录或者文件

除了Volume这种随着Pod生命周期变化的存储外，还有一种是PersistentVolume(PV)，是对存储资源的抽象，将存储定义为一种容器应用可以使用的资源，PV由管理员创建和配置，它与存储提供商的具体实现直接相关，例如：GlusterFS、iSCSI、RBD或GCE和AWS公有云提供的共享存储，通过插件式的机制进行管理，供应用访问和使用。

PersistentVolumeClaim(PVC)是用户对存储资源的一个申请，就像Pod消耗Node的资源一样，PVC消耗PV的资源，PVC可以申请存储空间的大小(Size)和访问模式(例如ReadWriteOnce、ReadOnlyMany或ReadWriteMany)。

PV

(10) Namespace

Namespace是为多租户隔离提供逻辑分组，以便于不同的分组在同一个集群内共享资源同时能被分别管理，如果不加命名空间，其默认是default。

查看可以通过kubectl get namepsaces，如果需要定义并使用Namespace，可以参考如下yaml文件：

apiVersion: v1
kind: Namespace
metadata:
  name: dev

apiVersion: v1
kind: Pod
metadata:
  namespace: dev # 将当前部署的pod分组到dev
  ...

4、其他

(1) Pod健康检查

当一个Pod启动的时候，在提供对外服务之前，k8s是无法确定知道当前服务是由就绪或者进程还在，但是服务已经不可用了，所以提供了探针功能：

• exec：执行一段命令
• http：检测某个http请求
• tcpSocket：使用此配置，kubelet将尝试在指定端口上打开容器的套接字，如果可以建立连接，容器被认为是健康的，如果不能就认为是失败的

探针也包含两种类型：

• readiness probe：就绪探测，可以在Pod启动过程中使用
• liveness probe：Pod生命周期内使用，如果服务探测不通，会被自动拉起来

(2) Job任务

k8s提供了Job任务功能，表示服务运行完成不需要再被调度，主要用于一些临时任务，可以通过kubectl get jobs查看任务，也可以通过kubectl logs {容器名}查看运行期间的日志。

当然任务往往有多类型，Job提供如下功能：

顺序运行

apiVersion: batch/v1
kind: Job
metadata:
  creationTimestamp: null
  name: job2
spec:
  backoffLimit: 4
  completions: 6
  ...

• backoffLimit：如果job失败，则重试几次
• completions：需要成功运行的Pod个数，在没有其他配置的情况下，是每次运行一个，运行完成一个接着运行第二个，直到达到上线

并行运行

apiVersion: batch/v1
kind: Job
metadata:
  creationTimestamp: null
  name: job2
spec:
  backoffLimit: 4
  completions: 6
  parallelism: 2
  ...

• parallelism：每次同时运行的Pod个数，直到达到completions设置的值

CronJob

apiVersion: batch/v1
kind: CronJob
metadata:
  creationTimestamp: null
  name: job3
spec:        
  schedule: '*/1 * * * *'
...

CronJob和linux的crontab类似，提供 分 小时 日 月 周 指定的运行周期，配置方式也是相同的，这里就不介绍了，其中查看任务命令可以如下：

[root@master job]# kubectl get cj
NAME   SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
mycj   */1 * * * *   False     0        <none>          6s