kubernetes架构

  1. kubernetes cluster由master和node组成,节点上运行着若干kubernetes服务

  2. Master节点:

    1. master是kubernetes cluster的大脑,运行着的Daemon服务包括kube-apiserver,kube-scheduler,kube-controller-manager,etcd和Pod网络(如flannel)
    2. API Service(kube-apiserver):api server提供了HTTP/HTTPS RESTful API。即kubernetes API。API Server是kubernetes cluster的前端接口,各种客户端工具(cli或者ui)以及kubernetes其他组件可以通过他管理cluster的各种资源
    3. Scheduler(kube-scheduler):scheduler负责决定将pod放在哪个Node上运行,scheduler在调度时会充分考虑cluster的拓扑结构,当前各个节点的负载,以及应用对高可用,性能,数据亲和性的需求
    4. Controller Manager(kube-controller-manager):controller manager负责管理cluster各种资源,保证资源处于预期的状态,controller manager由多种controller组成,包括replication controller,endpoints controller,namespce controller,serviceaccounts controller等,不同的controller管理不同的资源,比如:replication controller管理Deployment,StatefulSet,DaemonSet的生命周期。namespace controller管理Namespace资源。
    5. etcd:etcd负责保存kubernetes cluster的配置信息和各种资源的状态信息,当数据发生变化时,etcd会快速地通知kubernetes相关组件
    6. Pod网络:Pod要能够相互通信,kubernetes cluster必须部署Pod网络,flannel是其中一个可选方案
  3. Node节点:

    1. Node是pod运行的地方,kubernetes支持Docker,rkt(Rocket)等容器运行时工具,Node上运行的kubernetes组件有kubelet,kube-poxy和pod网络(如:flannel)

    2. kubelet:kubelet是Node的agent,当Scheduler确定在某个Node上运行Pod后,会将Pod的具体的配置信息(image,volume等)发送给该节点的kubelet,kubelet根据这些信息创建和运行容器,并向Master报告运行状态

    3. kube-proxy:service在逻辑上代表了后端的多个pod,外界通过service访问pod,kube-proxy把service接收到的请求转发到Pod上。每个Node都会运行kube-proxy服务,他负责将访问service的TCP/UDP数据流转发到后端的容器,如果有多个副本,kube-proxy会实现负载均衡

    4. Pod网络:Pod要能够相互通信,kubernetes cluster必须部署Pod网络,如:flannel,Calico

    5. master上的kubelet和kube-proxy是因为:master上也可以运行应用,即master同时也是一个Node,几乎所有的kubernetes组件本身也运行在pod中,

    6. kubernetes的系统组件都被放到kube-system namespace中,kubelet是唯一没有以容器形式运行的kubernetes组件,他通过systemd服务运行,可以通过sudo systemctl status kubelet.service查看kubelet的状态

  4. 举例:

    1. 执行命令部署应用:kubectl run httpd-app --image=httpd --replicas=2:会看到deployment "httpd-app" created

    2. kubernetes部署了deployment httpd-app,有两个副本pod,分别运行在k8s-node1和k8s-node2

    3. 通过命令kubectl get deployment查看部署的应用,通过kubectl get pod -o wide查看具体的pod信息

    4. 部署流程:

      1. kubectl发送部署请求到API Server
      2. API Server通知controller manager创建一个deployment资源
      3. Scheduler执行调度任务,将两个副本Pod分发到k8s-node1和k8s-node2
      4. k8s-node1和k8s-node2上的kubectl在各自的节点上创建并运行pod
      5. 补充:1:应用的配置和当前状态信息保存在etcd中,执行kubectl get pod时API Server会从etcd中读取这些资源,2:flannel会为每个pod都分配IP,因为没有创建service,所以目前流程kube-proxy没有参与
相关推荐
木木学AI8 小时前
AI客服系统技术选型:Agentic架构与传统规则引擎的能力差异评估
人工智能·架构
蜀道山老天师11 小时前
K8s Secret 与 ConfigMap 配置管理及动态更新实战详解
云原生·容器·kubernetes
满意的星月13 小时前
基于微服务和Docker容器技术的PaaS云平台架构设计(微服务架构实施原理)
docker·微服务·架构
以和为贵14 小时前
前端也能搞懂 Agent:从 Function Calling 到自主编排
前端·人工智能·架构
会周易的程序员14 小时前
使用 pybind11 封装 C++ 日志库 microLog 为 Python 模块
java·c++·python·物联网·架构·日志·aiot
为自己_带盐14 小时前
.NET 项目集成可观测性:从架构思考到落地实践
架构
熊猫钓鱼>_>14 小时前
2026 前端的三场底层革命:当 Vue、React Native 和 Three.js 同时去掉中间层
前端·javascript·vue.js·react native·架构·webgl·three.js
bukeyiwanshui14 小时前
20260624 k8s pod命令
云原生·容器·kubernetes
网络研究院16 小时前
Brave浏览器放大招引入容器功能,实现多账户安全隔离
网络·安全·容器·浏览器·数据·隐私
OceanBase数据库官方博客16 小时前
OceanBase Lakebase 架构解析:独立部署与智能叠加层模式的技术实践
架构·oceanbase