Kubernetes 是一个软件系统, 使你在数以万计的电脑节点上运行软件时就像 所有节点是以单个大节点一样, 它将底层基础设施抽象, 这样做同时简化了应用开发, 部署, 以及对开发和运维团队的管理.
Kubernetes 集群架构
Kubernetes 集群由很多节点组成, 分为两大类:
主节点 承载 Kubernetes 控制和管理整个集群系统的控制面板
工作节点 运行实际部署的应用
控制面板
控制集群并使它工作, 包含多个组件(组件单节点或通过副本分别部署到多个主节点以确保高可用)
Kubernetes API Server: 客户端 Kubectl, 控制面板其他组件和 worker 节点都需要和它通信
Scheduler: 调度应用
Controller Manager: 执行集群级别功能, 如复制组件, 持续跟踪工作节点, 处理节点失败等
etcd: 可靠的分布式数据库存储, 能持久化集群配置
工作节点
运行容器化应用的机器, 运行, 监控, 管理应用服务的任务由下组件完成:
Docker,rtk 或其他容器类型
Kubelet 与 API Server 通信, 并管理它所在节点容器
Kube-Proxy: 负责组件之间负载均衡网络流量
MiniKube 环境 & 核心概念
本处 window10+Hyper-V 搭建 minikube 本地集群
这台虚拟机既作为 master, 又作为 worker,Kubectl 从集群外部发起管理和控制.
- # 因国内极差的网络环境, 建议使用阿里云的镜像地址:
- minikube start --image-mirror-country=cn --image-repository=http://registry.aliyuncs.com/google_containers --registry-mirror=https://aq32bn7a.mirror.aliyuncs.com
以管理员权限执行 CMD 命令:
kubectl: 发送 Restful API 控制 Kubernetes 集群管理器
Minikube 是一个 CLI 工具, 配置, 管理 (已针对开发流程优化) 的单节点 Kubernetes 集群
列举 4 个核心概念
1. API
Kubernetes API 作为声明式配置方案的基石, API 文档中定义了 API 端点, 资源, kubectl 命令行工具可操作 API 对象, 对象的序列化对象存储在 etcd 中, 各组件也是通过 API 交互.
2. k8s 对象
Kubernetes 对象代表系统中持久化的实体, 下面的实体都作为对象:
哪些容器化应用正在运行
这些应用程序可用的资源
与这些应用程序有关的行为 & 策略: 重新启动策略, 升级和容错
Kubernetes 对象是期望状态, 创建对象之后, 你就通知了 K8s 你希望集群这样运作.
大多数 K8s 对象由 spec 和 status 组成:
spec:[由你]提供资源的特征描述
status: [系统自行控制] 描述对象当前状态, 由 K8s 系统组件设置和更新, K8s 控制面板持续管理对象的实际状态去匹配你设定的期望状态
当你创建 k8s 对象, 你需要提供对象 spec 来描述预期状态. 当使用 k8s API(或者 kubectl), 在 API 请求的 body 包含 JSON 信息; 大多数时给 kubectl 提供. YAML 文件来代替 JSON,kubectl 会将 YAML 文件中信息转换为 JSON 再发起 API 请求.
下面的 kubia-rs.YAML 文件: ReplicaSet 对象启动 3 个 Node.JS 应用, [spec]定义了此次 ReplicaSet 的规格
- apiVersion: apps/v1
- kind: ReplicaSet
- metadata:
- name: kubia-rs
- spec:
- replicas: 3
- selector:
- matchLabels:
- App: kubia
- template:
- metadata:
- labels:
- App: kubia
- spec:
- containers:
- - name: kubia
- image: luksa/kubia
- ports:
- - containerPort: 8080
- # 对于 ReplicaSet 啰嗦两句: 新一代的 ReplicationController; 通常不会直接创建 ReplicaSet, 而是在创建更高级的 Deployment 资源时自动创建它们.
- 3. Pod
Kubernetes Pod 是创建 / 部署 k8s 对象中最小最简单的单元:
由于不能将多个进程聚集在一个单独容器, 需要另外一种高级结构将容器绑定在一起, 作为一个单元管理, 这就是 Pod 背后根本原理, 一个 pod 中容器共享相同 ip 和端口空间.
4. Controller
k8s 控制器是一个 control loop(监控集群状态, 在被需要时或主动请求时更新集群), 每个控制器都试图将当前集群状态移动到期望状态.
在机器人和自动化, control loop 是一个非终止回路, 用于调节系统状态, 例如房间的空调.
控制器自身可以执行操作, 但一般情况下, 控制器会将引起连锁反应的消息发往 API server.
Kubernetes 内置了一些控制器: ReplicaSet,Deployment,StatefulSets,DaemonSet,Job...
- # k8s deployment 检查容器健康状态, 保证容器数量, 还具备部署相关的特性, deployment 是管理和缩放容器的推荐控制器
- kubectl create deployment hello-kubia --iamge=luksa/kubia
这 4 个概念连起来就是:
K8s 已经定义了 API 元数据, Controller 调度 K8s 系统到指定的 预期状态(这个预期状态以 K8s 对象提现), 在落地形式上以创建 / 调度 Pod 来承载应用. (此 4 个概念还不包含 NetWork 相关)
开启 Kubernetes 之旅
创建 3 实例 Node.JS 应用,
使用上面的 K8s 对象定义文件: kubia-rs.YAML 文件:
- \> kubectl create -f kubia-rs.YAML
- \> kubectl get pod --show-labels=true
- NAME READY STATUS RESTARTS AGE LABELS
- kubia-rs-96ncq 1/1 Running 0 3m40s App=kubia
- kubia-rs-h5ppz 1/1 Running 0 3m41s App=kubia
- kubia-rs-x5578 1/1 Running 0 3m40s App=kubia
注意: Pod 控制器中使用标签选择器来指定哪些 Pod 属于同一组(服务也使用同样机制).
以上有多个 Pod, 创建服务对后端 Pod 形成负载均衡
[集群内访问]: ClusterIP
[提供集群外访问]
nodeport: 把 service 的 port 映射到集群节点的一个端口上
LoadBalancer: 负载均衡器会单独分配一个 ip 地址并监听后端服务的指定端口, 请求的流量会通过指定的端口转发到后端对应的服务.
Ingress (minikube addons 先启用 ingress, 智能路由)
4 种网络方式的 YAML 代码如下: 请通过 kubectl create -f ...ymal 命令生成对应的服务(ingress 不是服务)
LoadBalancer 是服务暴露到集群外或者公网上的标准方式;
Ingress 这个服务类型跟我们前面的三种服务类型不一样, 它实际上不是一种服务类型, 而是类似一种集群服务入口的存在, 它可以基于你配置的不同路径或者子域名把流量路由到对应的后端服务, 更像是一个 "智能路由" 服务.
访问 3 Pod 实例的 Node.JS 应用
ClusterIP 只能在集群内访问, minikube SSH 进入集群, 或者 Hyper-V 进入 VM: curl 10.100.166.197 访问
nodePort,Loadbalancer 需要使用 minikube 获取本地集群 url
ingress 是复杂网络应用的常规做法
(1) hosts 文件添加 host 到 IP 地址的映射
(2) 通过 ingress 路由访问 pod
上面输出差异体现了随机 Pod(即使连接来自同一个客户端),SessionAffinity 亲和力属性值 (ClientIP) 可让单子一客户端请求都指向一个 Pod.
总结
本文从 K8s 全局架构讲起, 力求先在你头脑中构筑宏观思维导图;
提出核心概念帮助全流程理解;
通过一个常见的多实例 Node.JS 应用来实践 k8s 核心功能.
本文的所有代码: https://github.com/zaozaoniao/k8s-example.git
来源: https://www.cnblogs.com/JulianHuang/p/12791071.html