网站平台建设实训心得体会,wordpress文章入口设置,网站用品网店进货渠道,烟台网站建设托管一、三个容器管理器平台
Apache MESOS 开源的分布式资源管理框架#xff0c;被推特选为基础平台#xff0c;2019年推特换位k8s#xff0c;MESOS最新版可以在MESOS上管理k8sDOCKER SWARM docker总部发行的#xff0c;实现docker的集群方案#xff0c;和docker捆版一起被推特选为基础平台2019年推特换位k8sMESOS最新版可以在MESOS上管理k8sDOCKER SWARM docker总部发行的实现docker的集群方案和docker捆版一起比较轻量功能少但是大规划话实现非常好对docker实现好Kubernetes Goolge研发 由borg采用go语言开发资源消耗少弹性伸缩开源负载均衡 二、kubernetes组件
1️⃣ 服务的分类
有状态服务数据库管理系统DBMS无状态服务lvs APACHE
2️⃣ borg架构 3️⃣ k8s架构
replication controller 简称rc 控制器维护副本数目副本数量如果达不到数量值控制器就会去申请副本以便于达到数量值也就是删除对应的pod和删除对应的podkubectl 命令行管理工具web UI web界面Scheduler调度器负载介绍任务选择合适的节点进行分配任务api server 所有服务访问统一入口kubetet负责维护容器的生命周期同时也复制Volume和网络的管理kube proxy负责为Service提供集群内部的服务发现和负载均衡
⭐️ 看上图就可以看见以上所有服务都要以api server 交互所以看起来会很繁忙但是每个服务都会在服务本身产生一定的缓存并不是每件事都要到api server里面去请求 组件一: Etcd
⭐️ etcd的官方将它定位成一个可信赖的分布式键值存储服务它能够为整个分布式集群存储一些关键数据协助分布式集群的正常运转天生支持集群不需要中间件可以保存一些配置文件
⭐️ etcd 是 CoreOS 团队于 2013 年 6月发起的开源项目它的目标是构建一个高可用的分布式键值(key-value)数据库。etcd 内部采用raft协议作为一致性算法etcd 基于 Go 语言实现。
⭐️ etcd 的特点
简单安装配置简单而且提供了HTTP API进行交互使用也很简单安全支持SSL证书验证快速根据官方提供的benchmark数据单实例支持每秒2k读操作可靠采用raft算法实现分布式系统数据的可用性和一致性
⭐️ 为了保证数据的强一致性etcd 集群中所有的数据流向都是一个方向从 Leader 主节点流向 Follower也就是所有 Follower 的数据必须与 Leader 保持一致如果不一致会被覆盖。
⭐️ 用户对于 etcd 集群所有节点进行读写
读取由于集群所有节点数据是强一致性的读取可以从集群中随便哪个节点进行读取数据写入etcd 集群有 leader如果写入往 leader 写入可以直接写入然后然后Leader节点会把写入分发给所有 Follower如果往 follower 写入然后Leader节点会把写入分发给所有 Follower ⭐️ etcd目前有两个版本一个是v3 一个是v2v2版是将数据写入到内存中v3是把数据写入到本地数据卷的库中但是推荐使用v3v2以及被弃用
⚠️ 需要注意的是在kubernetes1.11版本前的是不支持v3版本的
⭐️ETCD的内部架构图
1️⃣使用的模式是C/S的构建服务 k8也是用http协议支持C/S C/SClinet-Server服务器负责数据库的管理客户机负责完成与用户的交互。ETCD就是采用这种模式kubernetes也是。Raft存储读写信息WAL预写日志 其他插件
CoreDNS可以为集群中的SVC创建一个域名IP的对应关系解析。、
Dashboardk8s集群提供B/S结构 ps B/S 浏览器/服务器模式 Ingress controller 官方只能实现四层代理ingress实现7层代理
Federation可以提供一个可以夸集群中心多K8s统一管理的功能
Prometheus普罗米修斯提供K8s集群的监控能力
ELK提供k8s的集群日志统一分析接入平台 三、Pod
自主式Pod不是被控制器管理的Pod死了以后不会被控制器“复活”也不会创建一个和他期望值一样的Pod控制器管理的Pod: 被控制器管理的Pod和自助式Pod是反着来的
⭐️ 在同一个容器里面他们的网络存储都是共享的因此不能发生端口冲突。 1️⃣ReplicationController ReplicaSet Deployment ReplicationController用来确保容器应用的副本数始终保持在用户定义的副本数即如果有容器异常退出会自动创建新的Pod来替代;而如果异常多出来的容器也会自动回收。在新版本的Kubernetes 中建议使用ReplicaSet 来取代ReplicationControlle ReplicaSet跟ReplicationController没有本质的不同只是名字不一样并且ReplicaSet支持集合式的selector通过labels 来操作 虽然ReplicaSet可以独立使用但-般还是建议使用Deployment 来自动管理ReplicaSet这样就无需担心跟其他机制的不兼容问题(比如ReplicaSet 不支持rolling- update但Deployment 支持)
⭐️selector搜索标签搜索rc不支持集合式搜索rs支持就是创建Pod的时候会给Pod打上标签可以直接搜索标签或者一组标签
⭐️rolling-update滚动更新也就是你需要把一个或者一组Pod更新成最新版本它就会给你先生成一个新版的Pod在给你删除你旧版的Pod
⭐️ 回滚和更新类似只不过式反着来的
2️⃣ Deployment (ReplicaSet )
⭐️ Deployment为Pod 和ReplicaSet 提供了一个声明式定义(declarative) 方法用来替代以前的ReplicationController 来方便的管理应用。典型的应用场景包括:
定义Deployment 来创建Pod和ReplicaSet滚动升级和回滚应用扩容和缩容暂停和继续Deployment 命令式编程: 它侧重于如何实现程序就像我们刚接触编程的时候那样我们需要把程序的实现过程按照逻辑结果一步步写下来 声明式编程: 它侧重于定义想要什么然后告诉计算机/引擎让他帮你去实现 3️⃣ HPA (HorizontalPodAutoScale)
⭐️ Horizontal Pod Autoscaling 仅适用于Deployment和ReplicaSet 在V1版本中仅支持根据Pod的CPU利用率扩所容在v1alpha 版本中支持根据内存和用户自定义的metric 扩缩容. 4️⃣ StatefulSet
⭐️ StatefulSet是为了解决有状态服务的问题(对应Deployments 和ReplicaSets 是为无状态服务而设计)其应用场景包括:
稳定的持久化存储即Pod重新调度后还是能访问到相同的持久化数据基于PVC来实现稳定的网络标志即Pod重新调度后其PodName 和HostName 不变基于Headless Service(即没有Cluster IP的Service )来实现有序部署有序扩展即Pod是有顺序的在部署或者扩展的时候要依据定义的顺序依次依次进行(即从0到N-1,在下-一个Pod运行之前所有之前的Pod必须都是Running 和Ready 状态) ,基于init containers 来实现有序收缩有序删除(即从N-1到0)
5️⃣ Service
⭐️ Kubernetes中一个应用服务会有一个或多个实例Pod,每个实例Pod的IP地址由网络插件动态随机分配Pod重启后IP地址会改变。为屏蔽这些后端实例的动态变化和对多实例的负载均衡引入了Service这个资源对象 ClusterIP 默认方式。根据是否生成ClusterIP又可分为普通Service和Headless Service两类 普通Service通过为Kubernetes的Service分配一个集群内部可访问的固定虚拟IPCluster IP实现集群内的访问。为最常见的方式。 Headless Service该服务不会分配Cluster IP也不通过kube-proxy做反向代理和负载均衡。而是通过DNS提供稳定的网络ID来访问DNS会将headless service的后端直接解析为podIP列表。主要供StatefulSet使用。 NodePort除了使用Cluster IP之外还通过将service的port映射到集群内每个节点的相同一个端口实现通过nodeIP:nodePort从集群外访问服务。 LoadBalancer和nodePort类似不过除了使用一个Cluster IP和nodePort之外还会向所使用的公有云申请一个负载均衡器(负载均衡器后端映射到各节点的nodePort)实现从集群外通过LB访问服务。 ExternalName是 Service 的特例。此模式主要面向运行在集群外部的服务通过它可以将外部服务映射进k8s集群且具备k8s内服务的一些特征如具备namespace等属性来为集群内部提供服务。此模式要求kube-dns的版本为1.7或以上。这种模式和前三种模式除headless service最大的不同是重定向依赖的是dns层次而不是通过kube-proxy。
6️⃣ DaemonSet
⭐️ DaemonSet确保全部(或者一些) Node上运行 一个Pod的副本。当有Node 加入集群时也会为他们新增一个Pod。当有Node从集群移除时这些Pod也会被回收。删除DaemonSet将会删除它创建的所有Pod
使用DaemonSet 的一些典型用法:运行集群存储daemon, 例如在每个Node . 上运行glusterd、 ceph。在每个Node.上运行 日志收集daemon, 例如fluentd、 logstash。在每个Node . 上运行监控daemon, 例如Prometheus Node Exporter
为什么会有一些呢因为我们可以在创建Pod的时候打上一个污点这些被打上污点的就不会在被创建副本了
7️⃣ Job, Cron job
⭐️ Job负责批处理任务即仅执行一次的任务它保证批处理任务的-一个或多个Pod 成功结束
打个比方就比如你运行一个脚本job就会判断你是不是正常退出如果不是正常退出他就会在去执行那个脚本直到正常退出为止
⭐️ Cron Job 管理基于时间的Job, 在特定达到时间循环创建job 即:
在给定时间点只运行一次周期性地在给定时间点运行 四、服务发现 1️⃣client向service发送请求这个请求会带有标签service就通过标签来寻找对应Pod
2️⃣ 客户端向访问一组pod但是pod和pod之间都不相干的时不可以通过service统一代理的但是如果时同一个rc创建的或者有同一个标签就就可以访问代理 五、网络通讯方式
⭐️ Kubernetes的网络模型假定了所有Pod都在一一个可以直接连通的扁平的网络空间中这在GCE (Google Compute Engine)里面是现成的网络模型Kubernetes 假定这个网络已经存在。而在私有云里搭建Kubernetes 集群就不能假定这个网络已经存在了。我们需要自己实现这个网络假设将不同节点上的Docker容器之间的互相访问先打通然后运行Kubernetes
1️⃣同一个Pod内的多个容器之间通过lo回环通讯
2️⃣各个Pod之间通过Overlay Network来通讯
同节点通过cni网桥转发数据包不同节点的pod需要通过网络插件来支持通讯
3️⃣ Pod与Servicer之间的通讯就要通过各节点的Iptables
1️⃣Flannel
⭐️ Flannel是Core0S 团队针对Kubernetes设计的一一个网络规划服务简单来说它的功能是让集群中的不同节点主机创建的Docker 容器都具有全集群唯一- 的虚拟IP地址。而且它还能在这些IP地址之间建立-一个覆盖网络(Overlay Network)通过这个覆盖网络将数据包原封不动地传递到目标容器内 ⭐️Flannel首先创建了一个名为flannel0的网桥而且这个网桥的一端连接docker0的网桥另一端连接一个名为flanneld的服务进程。
⭐️ Flanneld进程并不简单它首先上连etcd利用etcd来管理可分配的IP地址段资源同时监控etcd中每个Pod的实际地址并在内存中建立了一个Pod节点路由表然后下连docker0和物理网络使用内存中的Pod节点路由表将docker0发给它的数据包包装起来利用物理网络的连接将数据包投递到目标flanneld上从而完成pod到pod之间的直接的地址通信。
⭐️ Flannel之间的底层通信协议的可选余地有很多比如UDP、VXlan、AWS VPC等等。只要能通到对端的Flannel就可以了。源Flannel封包目标Flannel解包最终docker0看到的就是原始的数据非常透明根本感觉不到中间Flannel的存在。
2️⃣ETCD和Flannel
⭐️ 存储管理Flannel可分配的IP地址段资源,监控ETCD中每个Pod的实际地址并在内存中建立委会Pod节点路由表
⭐️ 同一Pod内的网络通信。在同一个Pod内的容器共享同一个网络命名空间共享同一个Linux协议栈。所以对于网络的各类操作就和它们在同一台机器上一样它们可以用localhost地址直接访问彼此的端口。其实这和传统的一组普通程序运行的环境是完全一样的传统的程序不需要针对网络做特别的修改就可以移植了。这样做的结果是简单、安全和高效也能减少将已经存在的程序从物理机或者虚拟机移植到容器下运行的难度。
⭐️Pod1到Pod2的网络分两种情况。Pod1与Pod2不在同一台主机与Pod1与Pod2在同一台主机。 不在同一主机Pod的地址是与docker0在同一个网段的但docker0网段与宿主机网卡是两个完全不同的IP网段并且不同Node之间的通信只能通过宿主机的物理网卡进行。将Pod的IP和所在Node的IP关联起来通过这个关联让Pod可以互相访问。 在同一主机Pod1和Pod2在同一台主机的话由Docker0网桥直接转发请求到Pod2不需要经过Flannel。
⭐️ Pod到Service的网络。创建一个Service时相应会创建一个指向这个Service的域名域名规则为{服务名}.{namespace}.svc.{集群名称}。之前Service IP的转发由iptables和kube-proxy负责目前基于性能考虑全部为iptables维护和转发。iptables则由kubelet维护。Service仅支持UDP和TCP协议所以像ping的ICMP协议是用不了的所以无法ping通Service IP。
⭐️ Pod到外网。Pod向外网发送请求查找路由表, 转发数据包到宿主机的网卡宿主网卡完成路由选择后iptables执行Masquerade把源IP更改为宿主网卡的IP然后向外网服务器发送请求。
⭐️ 集群外部访问Pod或Service
