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个nodejs应用, [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实例nodejs应用
- 使用上面的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 *file*.yaml命令生成对应的服务(ingress不是服务)
LoadBalancer是服务暴露到集群外或者公网上的标准方式；
Ingress 这个服务类型跟我们前面的三种服务类型不一样，它实际上不是一种服务类型，而是类似一种集群服务入口的存在，它可以基于你配置的不同路径或者子域名把流量路由到对应的后端服务，更像是一个“智能路由”服务。
- 访问3 Pod实例的nodejs应用
- 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全局架构讲起，力求先在你头脑中构筑宏观思维导图；
提出核心概念帮助全流程理解；
通过一个常见的多实例nodejs应用来实践k8s核心功能。
