【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,提供服务

集群外部访问:

参考

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

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

posted @ 2020-06-20 21:05  东北小狐狸  阅读(4844)  评论(0编辑  收藏  举报