【K8s学习笔记】K8s是如何部署应用的？

本文内容

本文致力于介绍K8s一些基础概念与串联部署应用的主体流程，使用Minikube实操

基础架构概念回顾

温故而知新，上一节【K8S学习笔记】初识K8S 及架构组件 我们学习了K8s的发展历史、基础架构概念及用途，本节讲的内容建立在其上，有必要把之前的架构小节提出来回顾下：

K8s架构分为控制平台(位于的Master节点)与执行节点Node

控制平台包含：

• kube-apiserver（访问入口，接收命令）

• etcd（KV数据库，保存集群状态与数据）

• kube-scheduler（监控节点状态，调度容器部署）

• kube-controller-manager（监控集群状态，控制节点、副本、端点、账户与令牌）

• cloud-controller-manager（控制与云交互的节点、路由、服务、数据卷）

执行节点包含：

• kubelet（监控与实际操作容器）

• kube-proxy（每个节点上运行的网络代理，维护网络转发规则，实现了Service）

• 容器运行时环境CRI（支持多种实现K8s CRI的容器技术）

接下来需要引入 Pod 与 Service 的概念，这也是在上一篇文章中未给出的

Pod、Service与Label概念

Pod概念与结构

Pod 是 K8s最重要的基本概念，官网给出概念：Pod是Kubernates可调度的最小的、可部署的单元。怎么理解呢？最简单的理解是，Pod是一组容器。

再详细些，Pod是一组容器组成的概念，这些容器都有共同的特点：

• 都有一个特殊的被称为“根容器”的Pause容器。Pause容器镜像属于K8s平台的一部分
• 包含一个或多个紧密相关的用户业务容器。假设个场景：业务容器需要独立的redis提供服务，这里就可以将它们两个部署在同一Pod中。

下边是Pod的组成示意图：

为什么Kubernetes会设计出一个全新的概念与Pod会有这样特殊的结构呢？

• 原因之一：K8s需要将一组容器视为一个单元处理。当其中某些容器死亡了，此时无法判定这组容器的状态。而当成一个单元，只要其中有一个容器挂了，这个单元就判定挂了。
• 原因之二：通过Pause共享容器IP，共享Pause挂接的Volume，简化密切关联的业务容器之间的通信问题和文件共享问题

K8s为每个Pod都分配了唯一的IP地址，称为Pod IP，一个Pod里的多个容器共享Pod IP地址。需要牢记的一点是：在 kubernetes 里，一个 Pod 里的容器与另外主机上的 Pod 容器能够直接通信。

Pod的创建流程

当一个普通的Pod被创建，就会被放入etcd中存储，随后被 K8s Master节点调度到某个具体的Node上并进行绑定（Binding），随后该Pod被对应的Node上的kubelet进程实例化成一组相关的Docker容器并启动。

当Pod中有容器停止时，K8s 会自动检测到这个问题并重启这个 Pod（Pod里所有容器）；如果Pod所在的Node宕机，就会将这个Node上的所有Pod重新调度到其他节点上。

细心的读者是否发现：

当Pod越来越多，Pod IP 也越来越多，那是如何从茫茫IP地址中找到需要的服务呢？换句话来说，是否有一种提供唯一入口的机制，来完成对Pod的访问，而无需关心访问到具体是哪个Pod（who care :happy:）？

Kubernetes 提供了这种机制，称之为 Service。

Service概念

Service服务是Kubernetes里的核心资源对象之一，从名称上来看，理解其为一个”服务“也不为过，Service的作用是为相同标识的一系列Pod提供唯一的访问地址。

Service使用的唯一地址称为ClusterIP，仅当在集群内的容器才能通过此IP访问到Service

它具体实现对一系列Pod绑定，需要再引入Label的概念，才能做出解答。

Label概念

Kubernetes 提供了Label（标签）来对Pod、Service、RC、Node等进行标记。相当于打标签，Label可以是一组KV键值对，也可以是一个set

一个资源对象可以定义任意数量的Label，同一个Label可以添加到任意数量的资源对象上。通常由定义资源对象时添加，创建后亦可动态添加或删除。

Service如何动态绑定Pods？

原来，在定义 Pod 时，设置一系列 Label 标签，Service 创建时定义了 Label Selector（Label Selector 可以类比为对 Label 进行 SQL 的 where 查询），kube-proxy 进程通过 Service的Label Selector 来选择对应的 Pod，自动建立每个 Service 到对应 Pod 的请求转发路由表，从而实现 Service 的智能负载均衡机制。

小结：Pod是K8s最小的执行单元，包含一个Pause容器与多个业务容器，每个Pod中容器共享Pod IP，容器之间可直接作用Pod IP通信；Label是一种标签，它将标签打在Pod上时，Service可以通过定义Label Selector(Label查询规则)来选择Pod，具体实现路由表建立的是kube-proxy

部署应用实践（Minikube）

安装kubectl需要安装成本地服务，这里是debian10，更多参考https://developer.aliyun.com/mirror/kubernetes

sudo su -
apt-get update && apt-get install -y apt-transport-https
curl https://mirrors.aliyun.com/kubernetes/apt/doc/apt-key.gpg | apt-key add - 
cat <<EOF >/etc/apt/sources.list.d/kubernetes.list
deb https://mirrors.aliyun.com/kubernetes/apt/ kubernetes-xenial main
EOF  
apt-get update
apt-get install -y kubelet kubectl
exit

下载安装Minikube（阿里云修改版）：

curl -Lo minikube-linux-amd64-1.11.0-aliyuncs http://kubernetes.oss-cn-hangzhou.aliyuncs.com/minikube/releases/v1.11.0/minikube-linux-amd64
sudo install minikube-linux-amd64-1.11.0-aliyuncs /usr/local/bin/minikube

使用魔改版是因为官方代码里有些地方写死了地址，而国内无法访问

部署k8s集群：

minikube start --driver docker --image-repository registry.cn-hangzhou.aliyuncs.com/google_containers --kubernetes-version v1.18.3

本地有docker时使用此driver，其他可选的虚拟化技术参考https://minikube.sigs.k8s.io/docs/drivers/ 选择

#部署一个Pod，Pod的deployment是一种默认的无状态多备份的部署类型
kubectl create deployment hello-minikube --image=registry.cn-hangzhou.aliyuncs.com/google_containers/echoserver:1.4
#查看集群中当前的Pod列表
kubectl get pods
#创建的NodePort类型Service，将所有Node开放一个端口号，通过这个端口将流量转发到Service以及下游Pods
kubectl expose deployment hello-minikube --type=NodePort --port=8080
#获取暴露 Service 的 URL 以查看 Service 的详细信息：
minikube service hello-minikube --url
#minikube提供的特色功能，直接通过浏览器打开刚才创建的Service的外部访问地址
minikube service hello-minikube

自动打开浏览器访问服务（Minikube特色功能）

提示：这张图中的request-uri的解释是不正确的，但是与 <minikube这个唯一Node的IP>:<NodePort> 与 <Service的ClusterIP>:<ServicePort>都不是完全匹配的，不大理解这块提示，有缘人希望可解我所惑，在此先行感谢

查看Pod的描述信息

kubectl describe pod hello-minikube

最下方可以清楚得看到K8s集群default-scheduler成功指派我们要求的Pod在节点minikube上创建，kubelet收到信息后，拉取镜像并启动了容器

部署流程原理简述

初始化，kubelet、kube-scheduler-manager、kube-controller-manager、kube-proxy向注册kube-apiserver自身信息，监听kube-apiserver的watch接口

1. kubectl 发送创建 deployment 类型、名为hello-minikube的Pod 请求到 kube-apiserver
2. kube-apiserver 将这条描述信息存到 etcd，再将事件发送给kube-scheduler
3. kube-scheduler收到事件，调用kube-apiserver的API ，监测Node负载情况，创建Pod部署描述信息到etcd，kube-apiserver返回此事件给kubelet
4. 待部署Node的kubelet收到kube-apiserver的事件，获得Pod信息，取出信息并拉取业务镜像，创建pause容器与业务容器（此时集群外部无法访问）
5. kubectl 执行expose命令，将请求发送到kube-apiserver，将创建Service与NodePort信息存到etcd中
6. 各节点kube-proxy收到事件，创建逻辑上的Service与路由信息，开辟NodePort
7. 当请求到达<任意Node节点IP>:<NodePort> 时，根据路由表转发到指定的Service上，负载均衡到Pod，提供服务

集群外部访问：

参考

• https://kubernetes.io/docs/concepts/workloads/pods/pod-overview/
• https://kubernetes.io/docs/concepts/services-networking/
• https://minikube.sigs.k8s.io/docs/start/
• https://minikube.sigs.k8s.io/docs/handbook/controls/
• 《Kubernetes权威指南》第 4 版

行文过程中难免出现错误，还请读者评论帮忙改正，大家共同进步，在此感谢

转载请注明出处，文章中概念引入《Kubernetes权威指南》很多，侵权改。