K8s学习笔记——认识理解篇

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 代理。

yaml 复制代码

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: 同命名空间访问

集群内的其他服务只需访问其服务名即可找到对应的服务，而无需关注服务的部署情况。如同下面配置：

bash 复制代码

login_domain=http://loginserver:8061

3.3 集群外互访

访问路径为：从外部反向代理 → ingress 集群 → 服务 pod。如下图所求：

4. 常用命令

config 复制代码

# 获取节点列表
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/