简介

云原生应用: 基于微服务原理而开发的应用, 以容器方式打包, 在运行时, 容器由运行于云基础设施之上的平台进行调度, 应用开发采用持续交付与DevOps实践.

  • 面向微服务架构
  • 在开发时即考虑容器云部署

K8S架构

image.png
K8S架构:

  • 典型的master-slave架构
  • master节点, 采用多节点部署, 最终做调度只有一个节点(有选主过程)
    • etcd是基于k-v的高可用分布式存储机制, 底层采用raft协议, k8s底层的状态数据包括配置, 节点等最终存在etcd中
    • API server, 对外提供操作和获取k8s集群资源的api, 唯一操作etcd的组件
    • Scheduler, k8s的大脑, 做调度决策, 比如对于新的应用发布请求, scheduler决策相应的POD分布在哪儿
    • Controller Manager, 集群状态的协调者, 观察集群的实际状态与etcd的预期状态进行比对, 不一致则对资源进行协调操作, 让实际状态与预期状态最终一致, 所以k8s采用最终一致性, 这种特性支持自愈, 无论节点还是集群挂了, 只要etcd预期状态还在, k8s即可恢复到最终状态
  • worker节点
    • Container Runtime, 下载镜像和运行容器的组件
    • POD, 对容器的包装, 是k8s的基本调度单位, 一个节点可以启动一个或多个pod, 一个应用的pod也可分布在多个节点上
    • kubulet, 负责管理worker节点上的组件, 相当于agent角色, 和master节点的API Server进行交互
    • kube-proxy, 负责对POD进行寻址和负载均衡的组件, 是实现service和服务抽象的关键, 底层操作iptable规则
  • 用户操作k8s主要通过kubectl, dashboard或api的sdk

image.png

K8S基本概念

K8S集群(Cluster)

集群可以由多个节点组成, 可以按需增减

容器(Container)

k8s是容器调度平台

POD

  • k8s没有直接调度容器, 而是在外层封装了一层POD的概念, POD是k8s调度的基本单位
  • 一个POD中可以跑一个或多个容器, 共享POD的文件系统以及网络, 每个POD有独立IP, 大部分情况下一个POD只跑一个应用容器

image.png

副本集

image.png

服务

service屏蔽了应用的IP寻址和LB等细节, 消费方可以通过服务名访问目标服务
image.png

发布

deployment用于管理replicaset, 实现蓝绿和滚动等高级发布机制
image.png

发布和服务总结

  • service和deployment是最重要的概念, 发布应用的yaml或json的配置主要是配这两个的
  • 发布应用时, deployment会创建replicaSet, replicaSet根据规范创建应用的POD实例, 并且维护和保证实例的数量
  • 升级时, deployment会创建实现新的replicaSet, 调度实现滚动发布, 发布回退等功能
  • serivce是服务间路由和寻址的概念, k8s内部和外部的client都是通过service间接访问目标应用的POD

image.png

ConfigMap/Secret

  • ConfigMap是k8s的配置支持, 会将配置以环境变量的形式注入到POD中
  • ConfigMap也支持以持久卷volume的形式挂载到POD中, POD中的应用即可以本地配置文件的形式访问配置
  • k8s通过secret来支持敏感数据的配置, secret提供能安全的存储和访问配置的机制

image.png

DaemonSet

可以在每个节点上部署一个守护进程POD, 并且保证每个节点上有且仅有一个, 以支持日志, 监控等
image.png

其他

  • Volume, 存储卷抽象, 可以是本地也可以是远程存储, 挂载之后, Volume成为POD的一部分, POD销毁, Volume也销毁(支持Volume的存储还存在)
  • PersistentVolume, 持久卷存储, 可以对接云存储, 如果采用PV存储, 则应用重启, 数据还在
  • PersistentVolumeClaims, 应用申请PV时需要填写的规范, 包括磁盘大小等
  • StatefulSet, 支持有状态应用的发布机制(replicaSet支持无状态应用)
  • job, 单次任务
  • cornjob, 周期性任务

image.png

  • Label, 给POD打标签, 比如标识前后端, 环境, 版本等
  • Selector, 通过标签查询定位POD的机制
  • Namespace, 逻辑性隔离机制, 可以实现租户, 团队等隔离
  • Readiness Probe(就绪探针), 判断POD是否就绪, 可以接入流量
  • Liveness Probe(活跃探针), 判断POD是否存活

image.png

概念总结

image.png
image.png

K8S网络

听不懂
有兴趣再看文章: https://blog.csdn.net/yang75108/article/details/101101384
image.png

K8S的ServiceDiscovery

  • 类似springcloud的eureka体系, 服务注册表主要由Master Node的Api Server来承担, 客户端代理主要通过kube-proxy以及netfilter机制来实现
  • netfilter是linux内核的代理机制, 可以修改iptables来实现包过滤和转发
  • kube-proxy有两种模式, 一种是用户空间代理模式, 用户请求直接由它转发, netfilter只负责修改iptables以及转发用户请求到kube-proxy

image.png

  • 1.25版本以后采用优化后的iptables/ipvs模式来提升性能, 请求经由netfilter后直接修改iptables进行转发, 不走kube-proxy, kube-proxy仅将服务信息同步给netfilter

image.png

NodePort vs LoadBalancer vs Ingress

上面的serviceDiscovery是内部寻址, 外部流量是通过在kube-proxy代理转发的
image.png
将K8S服务暴露在节点网络上的机制叫做NodePort, NodePort底层原理是在每个节点的相同位置暴露一个相同的端口, 端口背后是kube-proxy转发服务, 这两者使节点网络能够访问k8s内部的service
image.png

image.png
作者理解, Ingress相当于网关或反向代理
image.png

总结

image.png