Kubernetes入门——Kubernetes工作原理及使用

作者简介:

星龙                                      

百度基础架构部研发工程师

负责混部调度系统研发

 

本文基于百度云原生团队『云原生基础知识概述及实践』系列视频课程——『Kubernetes入门—Kubernetes工作原理』梳理。

视频课程可点击https://cloud.baidu.com/video-center/video.html?id=607进行学习。

导读

在上一节课我们学习了Docker的相关基础知识。(Kubernetes入门——深入浅出讲Docker)Docker解决了应用之间的隔离问题,但是在架构上,Docker仍然是一个单机的引擎。在真实的生产环境,我们可能拥有着海量的机器。那么如何管理、调度、编排这些分布在不同机器上的容器,就成为了新的问题。在这个时候,Kubernetes就应运而生了。

本节课将带领大家初步探索容器领域的编排引擎:Kubernetes。

课程主要分为以下三大部分:

第一部分:Kubernetes架构剖析

                  对Kubernetes核心组件分析。

第二部分:快速搭建Kubernetes集群

                   使用Kubeadm搭建Kubernetes环境

第三部分:Demo

                  演示如何操作一个Pod

在单机上,我们通常会把某个应用程序打包并部署在Docker容器当中。但在真实的环境中,问题往往比这复杂很多。我们需要解决服务的高可用问题、服务之间的依赖问题。

所以说Kubernetes不仅考虑的是容器级别的部署和编排,更多面向的是更高层面(比如应用层)的编排和部署引擎。

Kubernetes的前身其实是Google的Ball, 在2013年开源之后,发展至今。目前已经为开源事件部署引擎的事实标准了。

01  Kubernetes核心组件分析

核心概念Pod

  • Pod由一组容器组成,这些容器共享网络,存储以及相关的声明。    

  • Pod是Kubernetes 中最小的可部署的计算单元

  • 这样的一组容器被“打包”到一起组成了一个Pod 并接受Kubernetes 的调度,编排等控制逻辑。

为了让大家更好的理解“一组容器“的概念,接下来为大家详细剖析Pod的内部架构。

Pod的内部架构

图示清晰的阐述了Pod 的内部是什么样子的。蓝色部分代表的是整个Pod。其中右上角的net namespace 是Pod 级别的namespace,它代表了Pod中的所有容器。
图中有4个Container(即:PauseContainer/Container A/Container B/Container C/),他们在创建的时候都被加入到了namespace 当中。

那么,Pod级别的Container 是从哪里来的呢?我们从图中可以看到,真正工作的Container我们把它标注为A,B,C。Pause Container 的作用相当于一个占位符。当我们创建Pod的时候,会首先创建一个Pause Container。该容器创建出来的namespace,就相当于整个Pod的namespace。然后后面的容器再创建出来(比如说Container A/B/C)这些容器在创建出来的时候,就都会选择加入到PauseContainer创建出来的net namespace当中。

当然,也不是所有的namespace都是不隔离的。Container左侧是一个image,每一个container都有一个镜像,每一个镜像又相当于一个容器的Root ffs。既然每个容器的Root ffs是不相同的,那么显而易见,mnt namespace就是隔离的。

这样我们就可以清楚的看到,什么叫做有些namespce在Pod当中是互相隔离的,而有些是在Pod级别当中共享的。

Pod在Kubernetes中的展现形式

通常,我们习惯用Yaml来描述Kubernetes里的资源。Yaml中的内容其实就是我们对资源参数的描述。

我们先看Pod在Yaml中的前四行。这四行是资源在Yaml中的通用字段。ApiVersion/kind用于表示Kubernetes的资源类型是什么。通过metadata来声明资源的源数据。Spec字段和资源类型是强相关的了。不同的资源会有不同的spec定义。那在Pod资源当中,最核心的是关于容器的定义了。

下面几行,关于容器的定义,是一个数组类型的,这也符合我们对Pod的定义:即它是由一组容器形成的。这些字段包含:声明容器镜像,启动容器的命令,容器镜像的拉取方式,以及容器的名称。

核心概念Kubelet

Kubelet 是Kubernetes 集群的“节点代理”。也可以说是Kubernetes 部署在每个节点的agent。

Kubelet 启动后会向Kubernetes 集群注册自己,并上报节点的相关信息。此时在Kubernetes 集群中就增加了一台新的可用的Node 节点(可能是一个物理机,也可能是一个虚拟机,甚至是一个容器)。

Kubelet 发现有属于自己节点的Pod 符合创建条件后,会按照Pod声明的配置去启动容器。

Kubernetes控制面的相关组件

下面把这张图分为3个部分介绍。

1. 下半部分:也就是之前介绍过的Kubelet/Pod。

2. 左上角:Kubectl。也就是Kubernetes 的命令行工具。可以通过Kubectl来提交资源的Yaml 给Kubernetes 集群。也可以进行一系列的运维操作。

3. 右面:Master 节点。也就是Kubernetes 控制面的相关组件了。其中,API Sever是Kubernetes 中所有源数据的集成入口。也是整个Kubernetes 集群的中枢组件。其他组件(包括Controller, Scheduler等)在获取数据都需要和API Sever 打交道。API Sever 也会接受这些组件的协入请求,并最终将数据写入ETCD 当中。同时,API Sever 也会缓存所有的源数据。当其他组件发起“读”请求时,就会将数据直接从内存中发给对方。尽量避免ETCD 成为系统的瓶颈。除了源数据存储功能,API Server 还提供了一个Watch 机制。能够主动推送某种资源的变化。而Scheduler会向API Sever 注册并且监听Pod 的资源变更事件。Scheduler 整体的调度逻辑可以简化并概括为两个:过滤、打分。

每次对Pod进行调度的时候,首先将不符合条件的Node(如:机器上已经没有资源了,不符合某些标签,选择器的要求等)过滤掉。过滤完成后我们得到一个符合要求的Node列表,Scheduler  会通过打分算法,来计算每一个Node 的分数。最终选择一个得分最高的节点做为Pod 需要绑定的节点。最终Scheduler 会将结果回写到API Sever 当中。

编排组件:Controller。Controller 通过几种固定的workload。通过控制器的方式,来完成运行时服务器的编排工作。

02  快速搭建Kubernetes集群

搭建工具:Kubeadm简介

Kubeadm 是Kubernetes 官方提供的用于快速安装Kubernetes 集群的工具。

下图是Kubeadm 的配置文件

在配置文件当中,我们指定了dns的类型,ETCD存储目录以及要创建的Kubernetes的版本以及相关的参数。

搭建环境

初始Master节点

Kubeadm init—config kubeadm.conf

安装flannel cni

https://raw.githusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

03  Demo  ——演示如何操作一个Pod

创建一个Namespace​​​​​​​

 

Kubectl create namespace demo

创建Pod

 

Kubectl apply –f pod.yaml

查看Pod 运行状态

Kubectl describe pods demo-pod–n demo

 

查看Pod 输出日志  

Kubectl logs demo-pod –n demo

查看Pods 列表​​​​​​​

Kubectl get pods-n demo

 

删除Pod​​​​​​​

Kubectl delete-f pod.yaml

 

(创建Deomo的详细过程欢迎大家观看课程的视频回放。)

MoreCommand

Basic Commands: create,expose, run, setBasic Commands: explain, get,edit,deleteDeploy Commands: rollout,scale,autoscale

04  总结

本节课作为K8s入门系列课程第二节。重点介绍了Kubernetes 出现的背景和作用、Kubernetes 的特点和核心架构、Kubernetes 每一个模块承担的作用以及实现的功能。并演示了如何搭建一个单节点的Kubernetes  环境以及如何使用来操作相关的资源。希望对大家有所帮助。

更多精彩课程欢迎关注百度开发者中心公众号。

​​​​​​​

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章