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没有参与
相关推荐
deephub2 小时前
Tokenformer:基于参数标记化的高效可扩展Transformer架构
人工智能·python·深度学习·架构·transformer
景天科技苑3 小时前
【云原生开发】K8S多集群资源管理平台架构设计
云原生·容器·kubernetes·k8s·云原生开发·k8s管理系统
架构师那点事儿3 小时前
golang 用unsafe 无所畏惧,但使用不得到会panic
架构·go·掘金技术征文
wclass-zhengge3 小时前
K8S篇(基本介绍)
云原生·容器·kubernetes
颜淡慕潇3 小时前
【K8S问题系列 |1 】Kubernetes 中 NodePort 类型的 Service 无法访问【已解决】
后端·云原生·容器·kubernetes·问题解决
川石课堂软件测试5 小时前
性能测试|docker容器下搭建JMeter+Grafana+Influxdb监控可视化平台
运维·javascript·深度学习·jmeter·docker·容器·grafana
W Y6 小时前
【架构-37】Spark和Flink
架构·flink·spark
Gemini19956 小时前
分布式和微服务的区别
分布式·微服务·架构
昌sit!11 小时前
K8S node节点没有相应的pod镜像运行故障处理办法
云原生·容器·kubernetes
A ?Charis14 小时前
Gitlab-runner running on Kubernetes - hostAliases
容器·kubernetes·gitlab