初识k8s

简介：

Kubernetes 简称k8s。是用于自动部署，扩展和管理容器化应用程序的开源系统。
中文官网：https://kubernetes.io/zh/
中文社区：https://www.kubernetes.org.cn/
官方文档：https://kubernetes.io/zh/docs/home/
社区文档：http://docs.kubernetes.org.cn/

部署方式的进化

https://kubernetes.io/zh/docs/concepts/overview/

功能

架构

整体主从方式

Master 节点架构

kube-apiserver

对外暴露K8S 的api 接口，是外界进行资源操作的唯一入口。

提供认证、授权、访问控制、API 注册和发现等机制。

etcd

etcd 是兼具一致性和高可用性的键值数据库，可以作为保存Kubernetes 所有集
群数据的后台数据库。
Kubernetes 集群的etcd 数据库通常需要有个备份计划

kube-scheduler

主节点上的组件，该组件监视那些新创建的未指定运行节点的Pod，并选择节点
让Pod 在上面运行。
所有对k8s 的集群操作，都必须经过主节点进行调度

kube-controller-manager

在主节点上运行控制器的组件
这些控制器包括:
节点控制器（Node Controller）: 负责在节点出现故障时进行通知和响应。
副本控制器（Replication Controller）: 负责为系统中的每个副本控制器对象维
护正确数量的Pod。
端点控制器（Endpoints Controller）: 填充端点(Endpoints)对象(即加入Service
与Pod)。
服务帐户和令牌控制器（Service Account & Token Controllers）: 为新的命名
空间创建默认帐户和API 访问令牌

Node 节点架构

kubelet

一个在集群中每个节点上运行的代理。它保证容器都运行在Pod 中。
负责维护容器的生命周期，同时也负责Volume（CSI）和网络（CNI）的管理；

kube-proxy

负责为Service 提供cluster 内部的服务发现和负载均衡；

容器运行环境(Container Runtime)

容器运行环境是负责运行容器的软件。
Kubernetes 支持多个容器运行环境: Docker、containerd、cri-o、rktlet 以及任
何实现Kubernetes CRI (容器运行环境接口)。

fluentd

是一个守护进程，它有助于提供集群层面日志集群层面的日志

概念

Container：容器，可以是docker 启动的一个容器

Pod：

k8s 使用Pod 来组织一组容器
一个Pod 中的所有容器共享同一网络。
Pod 是k8s 中的最小部署单元

Volume

声明在Pod 容器中可访问的文件目录
可以被挂载在Pod 中一个或多个容器指定路径下
支持多种后端存储抽象(本地存储，分布式存储，云存
储…)

Controllers：更高层次对象，部署和管理Pod；

ReplicaSet：确保预期的Pod 副本数量
Deplotment：无状态应用部署
StatefulSet：有状态应用部署
DaemonSet：确保所有Node 都运行一个指定Pod
Job：一次性任务
Cronjob：定时任务

Deployment：

定义一组Pod 的副本数目、版本等
通过控制器（Controller）维持Pod 数目(自动回
复失败的Pod)
通过控制器以指定的策略控制版本（滚动升级，回滚等）

Service

定义一组Pod 的访问策略
Pod 的负载均衡，提供一个或者多个Pod 的稳定访问地址

支持多种方式（ClusterIP、NodePort、LoadBalance）

Label：标签，用于对象资源的查询，筛选

Namespace：命名空间，逻辑隔离

一个集群内部的逻辑隔离机制（鉴权，资源）

每个资源都属于一个namespace

同一个namespace 所有资源名不能重复

不同namespace 可以资源名重复

API

我们通过kubernetes 的API 来操作整个集群。
可以通过kubectl、ui、curl 最终发送http+json/yaml 方式的请求给API Server，然后控制k8s集群。

注意

k8s 里的所有的资源对象都可以采用yaml 或JSON 格式的文件定义或描述

流程叙述

1、通过Kubectl 提交一个创建RC（Replication Controller）的请求，该请求通过APIServer
被写入etcd 中
2、此时Controller Manager 通过API Server 的监听资源变化的接口监听到此RC 事件

3、分析之后，发现当前集群中还没有它所对应的Pod 实例，
4、于是根据RC 里的Pod 模板定义生成一个Pod 对象，通过APIServer 写入etcd
5、此事件被Scheduler 发现，它立即执行一个复杂的调度流程，为这个新Pod 选定一
个落户的Node，然后通过API Server 讲这一结果写入到etcd 中，
6、目标Node 上运行的Kubelet 进程通过APIServer 监测到这个“新生的”Pod，并按照它
的定义，启动该Pod 并任劳任怨地负责它的下半生，直到Pod 的生命结束。
7、随后，我们通过Kubectl 提交一个新的映射到该Pod 的Service 的创建请求
8、ControllerManager 通过Label 标签查询到关联的Pod 实例，然后生成Service 的
Endpoints 信息，并通过APIServer 写入到etcd 中，
9、接下来，所有Node 上运行的Proxy 进程通过APIServer 查询并监听Service 对象与
其对应的Endpoints 信息，建立一个软件方式的负载均衡器来实现Service 访问到后端
Pod 的流量转发功能。

k8s 里的所有的资源对象都可以采用yaml 或JSON 格式的文件定义或描述