标签：容器 服务 Service Kubernetes 访问 编排 架构 Pod K8S
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
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。