1. K8s诞生背景
回顾应用的部署,经历了以下几个阶段:
传统部署
:物理服务器上运行应用程序。虚拟机部署
:物理服务器上安装虚拟机,在虚拟机上运行应用程序。容器部署
:物理服务器上安装容器运行时(如docker),使用容器运行应用程序。
但容器主要解决的是单个应用程序的部署,实际工作中大家要面对的是成百服务、上千机器的规模部署问题,包括但不限于:
- 跨机器和跨地区的集群调度
- 实例的扩容和收缩
- 负载均衡和服务发现
- 无状态服务和有状态服务
- 存储支持
- 网络支持
- ……
这些不是单单靠一个容器能解决的,所以诞生了Kubernetes,它是一个容器集群管理系统,用于自动化部署、扩展和管理容器化应用程序。
2. K8s架构
K8s由主节点(Master)和工作节点(Node)组成,如下图所示。
主节点Master
负责管理集群的状态和配置,包含以下核心组件:
- apiserver 提供了资源操作的唯一入口,并提供认证、授权、访问控制、API 注册和发现等机制;
- scheduler 负责资源的调度,按照预定的调度策略将 Pod 调度到相应的机器上;
- controller manager 负责维护集群的状态,比如故障检测、自动扩展、滚动更新等;
- etcd 一个高可用的键值对存储系统,保存了整个集群的配置和状态;
工作节点Node
是一个个独立的主机或虚拟机,用于运行容器化应用程序,每个工作节点上都运行着以下核心组件:
- kubelet 通过API Server与主节点通信的代理,负责维护节点上容器的生命周期,同时也负责 Volume(CVI)和网络(CNI)的管理;
- kube-proxy 负责为 Service 提供 Cluster 内部的服务发现和负载均衡,确保容器间的网络通信;
- container runtime 负责镜像管理以及容器的真正运行(CRI),例如Docker;
K8s在设计时做了高度的抽象,这让它并不依赖具体某一项技术,下面是它的几个核心组件的抽象:
- CRI: Container Runtime Interface,抽象出的一套容器运行时核心操作的远程调用接口,屏蔽了不同容器运行时实现的差异
- CNI: Container networking interface, 是对网络插件的抽象接口定义
- CVI: Container Volume interface, 是对存储插件的抽象接口定义
除了核心组件,还有一些推荐的插件 :
- kube-dns 负责为整个集群提供 DNS 服务
- Ingress Controller 为服务提供外部入口
- Metric Server 提供资源监控
- Dashboard 提供 Web UI
- Federation 提供跨可用区的集群
详细组件参考另一篇文章:k8s资源组件介绍
3. 请求流转
K8s 的服务要想被其他服务或外部访问,通常有如下方式:
- service clusterIp:虚拟集群IP,仅在集群内使用,dns → service;
- ingress controller:网关插件,ingress → (service) → pod;
3.1 kube-dns
kube-dns 是 K8s 核心扩展组件,目前采用的实现是 CoreDNS。kube-dns 用来支撑集群内服务发现及灵活可配置的 DNS 代理。
kind: ConfigMap # 创建的资源类型为ConfigMap
apiVersion: v1
data:Corefile: | # 定义了一个键值对,键为Corefile,值为多行文本。.:53 { # 指定监听的端口为53,即DNS服务的默认端口,{}内为CoreDNS的配置项errors # 启用错误日志记录health # 启用健康检查# CoreDNS使用配置的这些域名来处理对应的域名解析请求# > kubernetes:这是一个域名,用来解析k8s中的服务和Pod的域名# > cluster.local:这是k8s的默认域名后缀,用于解析集群内部域名# > in-addr.arpa: 用于ipv4地址的反向解析,从IP地址到域名# > ip6.arpa:用于ipv6地址的反向解析,从IP地址到域名kubernetes cluster.local in-addr.arpa ip6.arpa prometheus :9153 # 配置了与Prometheus监控系统的集成,监听端口为9153。forward . 10.90.221.174 10.70.103.23 # 内置的上游DNS服务器,将所有未匹配的域名请求转发到10.90.221.174和10.70.103.23两个IP地址。cache 30 # 启用缓存,并设置缓存的过期时间为30秒}
3.2 集群内互访
K8s Service 类似于 微服务 概念,每个服务可以选择注册为集群内的一个服务,有灵活唯一的服务域名,格式:服务名.命名空间.集群域名
。举例如下:
- loginserver.bee.cluster.local: 跨命名空间访问
- loginserver.bee: 跨命名空间访问
- loginserver: 同命名空间访问
集群内的其他服务只需访问其服务名即可找到对应的服务,而无需关注服务的部署情况。如同下面配置:
login_domain=http://loginserver:8061
3.3 集群外互访
访问路径为:从外部反向代理 → ingress 集群 → 服务 pod。如下图所求:
4. 常用命令
# 获取节点列表
kubectl get node
#查看所有命名空间
kubectl get ns
#获取指定命名空间meeting下的服务
kubectl get svc -n meeting# 获取pod列表,-A 查看所有
kubectl get pod -A -o wide
# -n 指定命名空间
kubectl get pod -n meeting
# -o wide 显示成员状态,包括pod ip和node ip
kubectl get pod -o wide -n meeting#查看命名空间下deployment状态
kubectl get deploy -n meeting
#查看指定容器的实时日志
kubectl logs -f pc3joinmeeting-c9cbcd4b6-9n98c -n meeting#使用yaml文件创建pod
kubectl create -f YAML_FILE.yaml
#使用yaml文件删除pod
kubectl delete -f YAML_FILE.yaml
#即安装/更新 部署服务
kubectl apply -f service-deploy.yaml
#进入指定容器
kubectl exec -it -n default pre-live-web-5ddbbc68d-j25sv -- /bin/bash
#指定名称删除pod
kubectl delete pod pod-status-test -n meeting#查看所有节点存在的标签
kubectl get nodes --show-labels
#查看命名空间test下的ingress规则
kubectl get ing -n test -o wide
#查看命名空间test下所有pod的资源使用情况
kubectl top pod -n test
#获取命名空间test下的HPA使用情况
kubectl get hpa -n test
#集群调度信息的事件, 例如扩縮容
kubectl get event -n test
参考阅读
- k8s学习笔记之资源组件篇:https://blog.csdn.net/xiaojia1001/article/details/134225099
- CoreDNS 官网:https://coredns.io/plugins/