域名注册网站有哪些,大学网页制作选择题在哪搜,读经典做临床报名网站,企业年报网上申报流程一、kubernetes 架构
从宏观上来看 kubernetes 的整体架构#xff0c;包括 Master、Node 以及 Etcd。Master 即主节点#xff0c;负责控制整个 kubernetes 集群#xff0c;它包括 Api Server、Scheduler、Controller 等组成部分。它们都需要和 Etcd 进行交互以存储数据包括 Master、Node 以及 Etcd。Master 即主节点负责控制整个 kubernetes 集群它包括 Api Server、Scheduler、Controller 等组成部分。它们都需要和 Etcd 进行交互以存储数据 Api Server主要提供资源操作的统一入口这样就屏蔽了与 Etcd 的直接交互功能包括安全、注册与发现等。 Scheduler负责按照一定的调度规则将 Pod 调度到 Node 上。 Controller资源控制中心确保资源处于预期的工作状态。 Node 即工作节点为整个集群提供计算力是容器真正运行的地方包括运行容器、kubelet、kube-proxy kubelet 主要工作包括管理容器的生命周期、结合 cAdvisor 进行监控、健康检查以及定期上报节点状态。 kube-proxy : 主要利用 service 提供集群内部的服务发现和负载均衡同时监听 service/endpoints 变化并刷新负载均衡。 二、deployment
deployment 是用于编排 pod 的一种控制器资源以 deployment 为例来看看架构中的各组件在创建 deployment 资源的过程中都干了什么 首先是 kubectl 发起一个创建 deployment 的请求 apiserver 接收到创建 deployment 请求将相关资源写入 etcd之后所有组件与 apiserver/etcd 的交互都是类似的 deployment controller list/watch 资源变化并发起创建 replicaSet 请求 replicaSet controller list/watch 资源变化并发起创建 pod 请求 scheduler 检测到未绑定的 pod 资源通过一系列匹配以及过滤选择合适的 node 进行绑定 kubelet 发现自己 node 上需创建新 pod负责 pod 的创建及后续生命周期管理 kube-proxy 负责初始化 service 相关的资源包括服务发现、负载均衡等网络规则 至此经过 kubenetes 各组件的分工协调完成了从创建一个 deployment 请求开始到具体各 pod 正常运行的全过程。 三、Pod
在 kubernetes 众多的 api 资源中pod 是最重要和基础的是最小的部署单元。首先要考虑的问题是为什么需要 podpod 可以说是一种容器设计模式它为那些”超亲密”关系的容器而设计可以想象 servelet 容器部署 war 包、日志收集等场景这些容器之间往往需要共享网络、共享存储、共享配置因此有了 pod 这个概念。 对于 pod 来说不同 container 之间通过 infra container 的方式统一识别外部网络空间而通过挂载同一份 volume 就自然可以共享存储了比如它对应宿主机上的一个目录。
四、容器编排
容器编排是 kubernetes 的看家本领因此有必要了解一下。kubernetes 中有诸多编排相关的控制资源例如编排无状态应用的 deployment编排有状态应用的 statefulset编排守护进程 daemonset 以及编排离线业务的 job/cronjob 等。以应用最广泛的 deployment 为例deployment、replicatset、pod 之间的关系是一种层层控制的关系。简单来说replicaset 控制 pod 的数量而 deployment 控制 replicaset 的版本属性。这种设计模式也为两种最基本的编排动作实现了基础即数量控制的水平扩缩容、版本属性控制的更新/回滚。
五、水平扩缩容 水平扩缩容非常好理解我们只需修改 replicaset 控制的 pod 副本数量即可比如从 2 改到 3那么就完成了水平扩容这个动作反之即水平收缩。
六、更新/回滚
更新/回滚则体现了 replicaset 这个对象的存在必要性例如需要应用 3 个实例的版本从 v1 改到 v2那么 v1 版本 replicaset 控制的 pod 副本数会逐渐从 3 变到 0而 v2 版本 replicaset 控制的 pod 数会注解从 0 变到 3当 deployment 下只存在 v2 版本的 replicaset 时变完成了更新。回滚的动作与之相反。 七、滚动更新
可以发现在上述例子中更新应用pod 总是一个一个升级并且最小有 2 个 pod 处于可用状态最多有 4 个 pod 提供服务。这种”滚动更新”的好处是显而易见的一旦新的版本有了 bug那么剩下的 2 个 pod 仍然能够提供服务同时方便快速回滚。在实际应用中可以通过配置 RollingUpdateStrategy 来控制滚动更新策略maxSurge 表示 deployment 控制器还可以创建多少个新 Pod而 maxUnavailable 指的是deployment 控制器可以删除多少个旧 Pod。
八、kubernetes 中的网络
了解了容器编排是怎么完成的那么容器间的又是怎么通信的呢讲到网络通信kubernetes 首先得有”三通”基础 node 到 pod 之间可以通 node 的 pod 之间可以通 不同 node 之间的 pod 可以通。 简单来说不同 pod 之间通过 cni0/docker0 网桥实现了通信node 访问 pod 也是通过 cni0/docker0 网桥通信即可。而不同 node 之间的 pod 通信有很多种实现方案包括现在比较普遍的 flannel 的 vxlan/hostgw 模式等。flannel 通过 etcd 获知其他 node 的网络信息并会为本 node 创建路由表最终使得不同 node 间可以实现跨主机通信。
九、微服务 service
在了解接下来的内容之前得先了解一个很重要的资源对象service为什么需要 service 呢在微服务中pod 可以对应实例那么 service 对应的就是一个微服务。而在服务调用过程中service 的出现解决了两个问题 pod 的 ip 不是固定的利用非固定 ip 进行网络调用不现实 服务调用需要对不同 pod 进行负载均衡。 service 通过 label 选择器选取合适的 pod构建出一个 endpoints即 pod 负载均衡列表。实际运用中一般会为同一个微服务的 pod 实例都打上类似 appxxx 的标签同时为该微服务创建一个标签选择器为 appxxx 的 service。
十、kubernetes 中的服务发现与网络调用
在有了上述”三通”的网络基础后就可以开始微服务架构中的网络调用在 kubernetes 中是怎么实现的。
① 服务间调用
首先是东西向的流量调用即服务间调用。这部分主要包括两种调用方式即 clusterIp 模式以及 dns 模式。clusterIp 是 service 的一种类型在这种类型模式下kube-proxy 通过 iptables/ipvs 为 service 实现了一种 VIP(虚拟 ip)的形式。只需要访问该 VIP即可负载均衡地访问到 service 背后的 pod。如下是 clusterIp 的一种实现方式此外还包括 userSpace 代理模式基本不用以及 ipvs 模式性能更好 dns 模式很好理解对 clusterIp 模式的 service 来说它有一个 A 记录是 service-name.namespace-name.svc.cluster.local指向 clusterIp 地址。所以一般使用过程中直接调用 service-name 即可。
② 服务外访问 南北向的流量即外部请求访问 kubernetes 集群主要包括三种方式nodePort、loadbalancer、ingress。nodePort 同样是 service 的一种类型通过 iptables 赋予了调用宿主机上的特定 port 就能访问到背后 service 的能力。loadbalancer 则是另一种 service 类型通过公有云提供的负载均衡器实现。访问 100 个服务可能需要创建 100 个 nodePort/loadbalancer因此希望通过一个统一的外部接入层访问内部 kubernetes 集群这就是 ingress 的功能。ingress 提供了统一接入层通过路由规则的不同匹配到后端不同的 service 上。ingress 可以看做是”service 的 service”。ingress 在实现上往往结合 nodePort 以及 loadbalancer 完成功能。
