理解Kubernetes编排架构
作者：互联网
01常见的业务场景
假设有两个服务A和B，他们之间相互调用，且同时对外提供，如下图所示
- 服务A和B之间必须互通
- 服务A和B都需要访问各种需要的基础设施，如数据库、消息队列等
- 服务A和B都对外暴露API
- 服务需要高可用，自动扩缩容
我们暂且不讨论这个架构设计是否合理，假设场景就是如此，正常线上情况往往比这个复杂的多。
»02 回顾一下Docker
这里不再对Docker的内容展开详细介绍，本文默认你已经熟悉Docker相关的知识。
»03 一步一步理解K8S
服务自身所处的环境：Container
服务存在于容器中，容器之间，互相隔离。每个容器分别需要挂载一个磁盘
为了方便管理，我们将多个容器组合在一起，同时为其配套一个相同的环境上下文，就形成了容器的逻辑主机：POD
K8S的逻辑主机：Pod
Pod是K8S的最小管理单位，一个服务的一个副本一般是一个Pod，同个Pod中的所有容器网络互通，有相同的挂载以及Pod IP等。
服务往往需要高可用，就需要扩容成多个副本，并通过负载均衡的方式，让外部流量均匀地流入到每个Pod上，此时K8S的副本管理器承担了这个职责，可以将Pod复制出来，并进行负载均衡。同时可以将Pod创建到指定的物理节点上。
副本控制器：ReplicationController
节点选择器：NodeSelector
副本集：ReplicationSet
此时，我们的服务就有了NodeIP和PodIP。
同时对于一些不同的服务，场景还可能不一样。比如对于MySQL，WebSocket等基于TCP协议长连接的服务，不适合频繁变换PodIP(因为一旦变原本客户端的连接池连接就失效了)。所以对于不同的服务，K8S支持了不同的类型。
有状态容器：StatefulSet
无状态容器：Deployment
守护进程容器：DaemonSet
到目前为止，都是将服务部署起来，都没有说如何访问这些服务。在K8S中，部署和访问是相互独立的，部署我们称之Deployment，而访问需要靠Service来定义。我们称这种由Service转发端口到Pod的方式为NodePort模式
Deployment: 定义如何创建Pod，创建多少个Pod
Service: 定义如何从外部访问服务
Deployment为Pod和ReplicaSet提供了一个声明式定义(declarative)方法，用来替代以前的ReplicationController来方便的管理应用。而Service抽象了对Pod的访问。
现在，可以通过service暴露出来的端口，从集群外部访问Pod了。一般此时外层再对接统一的API网关，绑定域名，即可进行反向代理，通过域名访问相关服务。
以上，就是将一个服务部署在K8S上的全部基本流程了。所以，是不是理解起来K8S其实也挺好理解的呢？当然，本文只是面向K8S小白，从白盒的角度理解K8S，如果从K8S的架构角度上看，实际上K8S的组件和架构比本文描述的要复杂的多。
»04 K8S架构简介
- ETCD：负责维护集群内所有服务的状态信息，也用于服务注册和发现
- ApiServer：提供了资源操作的唯一入口，同时提供鉴权等功能
- Scheduler：负责将Pod调度到某个机器节点上
- ControllerManager：负责将Pod跑起来，同时维护故障检测、滚动更新等
- Kubelet：每个Node上的守护进程，负责维护容器的生命周期
- Kube-Proxy：负责为Service提供cluster内部的服务发现和负载均衡
- kube-DNS：负责为整个集群提供DNS服务
- Ingress Controller为服务提供外网入口
标签：容器,服务,Service,Kubernetes,访问,编排,架构,Pod,K8S 来源： https://www.cnblogs.com/lidabo/p/16423562.html