K8s的一些概念 Service工作方式和类型

K8s的一些概念 Service工作方式和类型

---

master组件

• apiserver
  • 集群统一入口，以restful方式，交给etcd存储
• scheduler
  • 节点调度，选择node节点应用部署
• controller-manager
  • 处理集群中常规后台任务，一个资源对应一个控制器
• etcd
  • 存储系统，用于保存集群相关的数据

---

node组件

• kubelet
  • 管理本地容器操作
• kube-proxy
  • 网络代理，负载均衡

---

K8s核心概念

• Pod
  • 最小部署单元
  • 一组容器的集合
  • 共享网络
  • 生命周期是短暂的 跟Inf容器同生死 维护Pod内的Network Namespace
• Controller
  • 无状态应用部署 Deployment
  • 有状态应用部署 Statuful
  • 确保所有node运行同一个Pod DaemonSet
  • 一次性任务 Job
  • 定时任务 CronJob
• Service
  • 定义一组Pod的访问规则

---

Service有三种工作方式

• Userspace
  • Client Pod要访问Server Pod时，它先将请求发给本机内核空间中的Service规则，由它再将请求转给监听在指定套接字上的Kube-proxy,kube-proxy处理完请求，并分发请求到指定Server Pod后，再将请求递交给内核空间中的service,由service将请求转给指定的Server Pod
  • 由于这种方式需要来回在用户空间和内核空间交互通信，效率很差所以就有了第二种方式
• iptables
  • 直接由内核中的iptables规则，接受Client Pod请求，并处理完成后，直接转发给指定ServerPod
• ipvs
  • 直接有内核中的ipvs规则来接受Client Pod请求，并处理该请求，再有内核封包后，直接发给指定的Server Pod

以上三种方式中，kube-proxy通过Watch方式监控kube-Apiserver写入etcd中的Pod信息，一旦Pod资源删除或新建，就会立即修改iptables或Ipvs中 避免出现Clinet Pod请求到Server Pod时找不到Server Pod的情况

K8s 1.1版本以前默认为userspace 之后默认是ipvs 如果ipvs没有被激活，则降级使用iptables

---

Service四种类型

• ExternalName
  • 用于将集群外部的服务引入到集群内部，在集群内部可直接访问来获取服务
  • 值必须是FQDN，是集群内部的FQDN
  • ServiceName.Namespace.Domain.LTD
  • CoreDNS接受该FQDN后，能解析出一个CNAME记录，该别名记录为真正互联网上的域名
• ClusterIP
  • 用于为集群内Pod访问时，提供的固定访问地址，默认是自动分配地址，可使用ClusterIP关键字指定固定IP
• NodePort
  • 用于为集群外部访问Service后面Pod提供访问接入端口
  • 工作流程为 Clinet-------> NodeIP:NodePort ----->ClusterIP:ServicePort-------->PodIP:ContainerPort
• LoadBalancer
  • 用于当K8s运行在一个云环境内时，若该云环境支持LBaaS,则此类型可自动触发创建一个软件负载均衡器用于对Service做负载均衡调度，外部所有Client都访问一个NodeIP,该结点的压力就会很大，所以LoadBalancer可以通过动态监测后端Node是否被移除或新增，然后动态更新调度的节点数来解决