前言: 本文主要参考张磊大神的深入剖析 kubernetes,文章很有深度,把阅读笔记整理下来。
基本概念
kubernetes是用于方便管理容器的编排操作的平台。解决了处理大规模集群中各种任务之间的复杂关系的问题。
所以说,Kubernetes 项目的本质,是为用户提供一个具有普遍意义的容器编排工具。
可以看出kubernetes的项目架构与Borg相似,都是由master与node组成,分别负责控制与计算。
其中 master 节点,由三个独立组件组合而成:
- apisever: API 服务
- scheduler: 服务调度
- controller-manager: 容器编排
在计算节点(node)上最核心的部分为kubelet组件
kubelet 主要负责与容器(Docker)的交互
( => ) 只表示具有依赖关系,无方向性
kubelet => CRI (Container Runtime Interface)
CRI : 定义了容器运行时的各项核心操作,比如: 启动容器需要的所有参数
CRI => OCI
OCI : 容器运行时规范,把CRI翻译成对Linux操作系统的调用,(操作 Linux Namespace 和 Cgroups 等)。
kubelet => gRPC => Device Plugin
Device Plugin: 用来管理GPU等宿主机物理设备的主要组件,也是基于 Kubernetes 项目进行机器学习训练、高性能作业支持等工作必须关注的功能。
CNI (Container Networking Interface) => kubelete => CSI (Container Storage Interface)
CNI: 网络插件,为容器提供网络
CSI: 存储插件,为容器提供持久化存储
Kubernetes 的设计思想是,从宏观的角度,以统一的方式,定义任务之间的关系,为将来支持更多种类的关系留有余地。
Pod
比如:一些应用之间需要频繁的访问、交互 。又或者,他们会直接通过本地文件进行信息交换。
这类情况在常规的环境中,都会被部署在同一台机器中,并通过Localhost通信,通过本地磁盘目录交换文件。
而在kubernetes中,这些容器被划分在一个"pod" 中,在这个pod中,这些容器同时共享同一个Network Namespace、同一组数据卷,从而高效的交换信息。
Service
另一种常见的需求:比如Web应用与数据库之间的访问关系
像这样的两个服务,往往是不会部署在同一个机器上的,而且我们知道容器的 IP 不是固定的,那么我们该如何让Web 应用找到数据库的 pod 呢?
在kubernetes中提供了“Service“ 的服务,给 pod 绑定一个 service 服务,而service 服务声明的 IP 是固定的、始终不变。
Service 服务的作用就是作为 pod 的代理入口,为pod 提供一个对外的暴露固定IP地址
按照上图我们可以看出,当遇到容器间紧密协作的关系难题时,就是使用了Pod ,有了Pod之后,我们希望一次可以启动多个应用实例,于是就用上了Deployment 这个多实例管理器,而有了这样一组相同的pod后,我们有需要Service 来提供固定的IP与端口用于负载均衡访问。
Secret
当两个容器之间,不单单只是访问关系时,而且还要在访问时,提供授权信息,像是数据库访问时的Credential(用户名和密码) 那么又该怎么做?
我们可以使用Secret 的对象,它其实是保存在 Etcd 中的键值对数据,这样当我们把Credential的信息以Secret的方式存入Etcd 时,kubernetes就会在我们指定的pod启动时将数据以Volumes的方式挂载到容器里,这样就可以实现加密认证访问了。
其他概念
除了应用之间的关系外,应用的运行形态是影响"如何容器化"的重要因素
所以kubernetes中有很多pod改进后的对象,像是Job,用来描述一次性运行的pod(比如:大数据任务),还有DaemonSet,用于描述每个宿主机必须且只能运行一个副本的守护进程,再如CronJob,用于描述定时任务。
在kubernetes中推崇的使用方式:
- 首先,通过一个"编排对象",如Pod,Job,CronJob等,用于描述你试图管理的应用。
- 然后,再为他定义一些"服务对象",如Service、Secret、Horizontal Pod Autoscaler (自动水平拓展器)等。
这种使用方式,就是所谓的声明式API。这种API对应的"编排对象"和"服务对象", 都是kubernetes中的API对象(API Object)
试一试
在kubernetes 中需要使用yaml来定义(比如:nginx-deployment.yaml)
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
在上面这个 YAML 文件中,我们定义了一个 Deployment 对象,它的主体部分(spec.template 部分)是一个使用 Nginx 镜像的 Pod,而这个 Pod 的副本数是 2(replicas=2)。
启动:
kubectl create -f nginx-deployment.yaml
总体架构图
kubernetes架构图_2参考文章:https://time.geekbang.org/column/article/23132
欢迎大佬们写下留言,谈谈你对k8s的理解。 _(:з」∠) _
网友评论