门户网站有哪些类型,北京专业网站改版公司,做泥水上哪个网站找事做,网站刷链接怎么做的戳蓝字“CSDN云计算”关注我们哦#xff01;作者 | 木鱼 on基础保障责编 | 阿秃一、背景我们为什么选择 Kubernetes#xff1f;因为 Kubernetes 几乎支持所有的容器业务类型#xff0c;包括无状态应用、有状态应用、任务型和 Daemonset#xff0c;Kubernetes 也逐渐成为容… 戳蓝字“CSDN云计算”关注我们哦作者 | 木鱼 on基础保障责编 | 阿秃一、背景我们为什么选择 Kubernetes因为 Kubernetes 几乎支持所有的容器业务类型包括无状态应用、有状态应用、任务型和 DaemonsetKubernetes 也逐渐成为容器编排领域不争的事实标准。同时从资源利用率开发测试运维和 DevOps 三方面出发会极大的提升人和机器的效率。二、方案整体架构Kubernetes 在整个系统中处于偏底层负责容器的编排。我们开发了一套 Web 的运维平台能够完成开发者绝大部分的日常开发操作功能其中包括了应用发布、伸缩容、回滚、灰度蓝绿发布、CI/CD 流水线、日志和监控的查看等。集群部署为了实现集群的高可用平台提供多个 IDC 部署应用可以同时部署到不同 IDC 的 Kubernetes 集群同时我们在一个 IDC 同时部署了两个集群应用可以部署到同机房的两个集群这样可以解决跨机房调用问题也可以防止 Kubernetes 集群过大导致的调度性能问题。同时在同一个 IDC 内集群可以选择自建和云提供商的集群在双十一这种情况下可以利用云的弹性快速扩容集群来满足资源的需求。在同个 IDC 部署多个集群的出发点是我们没有使用 Kubernetes 的 Ingress自研了 k8s-sync 组件会在发布时自动将容器的 IP 同步到我们的统一接入中为了避免 k8s-sync 出错如果在一个集群中 IP 同步不一致会快速失败而不会影响其他的集群和现有的服务。Master 高可用Master 节点是 Kubernetes 中最重要的部分生产中必须要保障它的高可用。etcd 是 Kubernetes 当中唯一带状态的服务集群中所有的数据都保存在 etcd 中。Kubernetes 选用 etcd 作为它的后端数据存储仓库正是看重了其使用分布式架构没有单点故障的特性。一是使用独立的 etcd 集群使用 3 台或者5台服务器只运行etcd独立维护和升级。甚至可以使用 CoreOS 的 update-engine 和locksmith让服务器完全自主地完成升级。这个 etcd 集群将作为基石用于构建整个集群。采用这项策略的主要动机是 etcd 集群的节点增减都需要显式的通知集群保证 etcd 集群节点稳定可以更方便地用程序完成集群滚动升级减轻维护负担。kube-apiserver 高可用apiserver 本身是一个无状态服务要实现其高可用相对要容易一些前端部署了负载均衡其他组件都通过这个负载均衡去访问 apiserver。kube-controller-manager 与 kube-scheduler 高可用这两项服务是 Master 节点的一部分他们的高可用相对容易仅需要运行多份实例即可。这些实例会通过向 apiserver 中的 Endpoint 加锁的方式来进行leader election 当目前拿到 leader 的实例无法正常工作时别的实例会拿到锁变为新的 leader。日志针对日志采集在有赞主要分为两类对于输出到 stdout 和 stderr 的日志会使用 filebeat 进行采集写入到 kafaka 中做后续的存储和处理。对于 Java 类应用在虚拟机时代就已经自研了一套日志处理方案在容器中我们沿袭了这套方案通过 agent 采集走。集群监控对于集群的监控主要分为两种对于节点的监控还是沿袭了虚拟机时代的方案继续使用 open-falcon使用 Kubernetes 后我们使用了 cadvisor 和 kube-state-metrics用于采集容器和 Kubernetes 中一些资源对象的数据同时对于 Kubernetes 中的组件kubelet、kube-apiserver、kube-controller-manager 和 kube-scheduler各自都暴露了 metrics 接口吐出了自身的运行时的监控数据。这些数据都被集群的 prometheus 全部拉取然后展示在 Grafana 和运维平台上。应用监控在运维平台中对于应用开发者来说最关心的是应用层面的监控数据。目前我们结合 cadvisor 和 kube-state-metrics 提供了 CPU、内存、磁盘 IO、网络 IO 这四个监控项。同时我们针对容器重启销毁拉取镜像失败孤儿 Pod 等事件做了监控和报警。服务暴露Kubernetes 中服务的暴露是一个比较重要的问题同时也有很多开源的方案。刚开始我们调研了 traefik 但是很多地方满足不了我们的需求所以沿用了内部的接入层 yz7为了适配 Kubernetes自研了 k8s-syc。k8s-sync 会 watch 集群中的 endpoints然后将 IP 同步到 yz7 中。对于 RPC 服务由于我们内部采用了 macvlan 这种调用和虚拟机时代保持了一致。镜像镜像的构建主要分 3 层OS 层、Runtime 层和业务应用层。有赞内部每种应用类型会有严格的端口规范每种应用类型接入容器发布时要符合端口规范。对于 Python 和 NodeJS 应用接入容器发布时比较简单只需要在应用 repo 的根路径下添加 app.yaml 文件这个文件定义了应用的镜像的构成包括 OS、runtime 和 entrypoint。例如下面是一个 Python 应用的 app.yaml 示例文件。stack: youzanyun-centos6
runtime: python-2.7
entrypoint: gunicorn -c gunicorn_config.py wsgi:application标签为了便于运维管理和亲和性的需求我们给 Pod 打上了很多标签例如应用名称、集群名称、环境、机房、灰度蓝绿等。目前我们还没有使用亲和性来实现更复杂的高可用后续会基于这些标签来规划应用的亲和性和反亲和性。Lifecycle Hooks我们使用了 Kubernetes 的 poststart 和 prestop 的钩子。容器启动时会调用定义的 preload 和 online 脚本该脚本会对应用程序进行健康检查健康检查通过后再执行 online 脚本对应用进行上线动作。容器销毁时会调用 offline 和 stop 脚本和启动时相反容器销毁时会先进行下线动作然后再执行 stop 脚本。持续交付在有赞CI/CD 的实现是通过项目环境来实现的。每个标准环境的部署是部署在不同的 Kubernetes 集群中的每个集群中通过不同的 namespace 来区分各自的环境。多集群管理目前我们的生产环境的集群包括了自建集群和公有云集群其他环境也有很多套集群。为了便于进行集群管理我们自研了集群管理平台。集群管理员可以在平台上对进行操作包括创建集群、添加节点、维护节点、给节点打标签和查询集群及节点的水位状态。遇到的问题在容器化的过程中还是碰到了不少的问题主要有下面这些和大家分享下1.CPU 核数不准我们使用了 lxcfs 进行了一些隔离但是对于 Java 程序来说获取到的 CPU 核数还是不准的前期我们使用了 hack 的方案后续升级了 jdk 避免了这个问题。2.有问题时的排查针对发布时应用程序发布起来出现 CrashLoopbackoff 的情况时我们提供了调试模式发布这时会移除 Pod 的健康检查和 lifecycle hook保证可以发布起来。针对线上运行时出现了问题我们提供了隔离的功能给 Pod 打上特殊的标签让其脱离 Deployment 的控制同时会执行程序的下线流程保证不再有流量进来这样就保留了有问题时的现场供开发人员进行现场问题排查。3.Pod 中 Container 的依赖通常在 Pod 里除了业务容器还有其他的 sidecar 容器在我们这里特殊的是业务容器还依赖了 sidecar 容器但是 Pod 的启动实际是无序的所以我们目前使用了富容器辅助程序和业务程序放在了一起启动时控制了它们的启动次序。目前社区里也有相应的讨论已经在实现中。三、未来展望未来我们期望能开始使用 operator 来优化和改进 Kubernetes 的使用并使用它去优化一些应用程序的交付希望可以开始使用 HPA 和 VPA来实现自动化的伸缩容实现更精细化的调度提供集群的利用率。早鸟票倒计时最后2天扫码购票立减2600元2019 中国大数据技术大会BDTC再度来袭豪华主席阵容及百位技术专家齐聚15 场精选专题技术和行业论坛超强干货技术剖析行业实践立体解读深入解析热门技术在行业中的实践落地。福利扫描添加小编微信备注“姓名公司职位”入驻【CSDN博客】加入【云计算学习交流群】和志同道合的朋友们共同打卡学习推荐阅读【小白集合】详解服务器内存和显存基础知识【忽悠面试官就靠它了】『Spring事务管理器』源码阅读梳理如何破解焦虑成为技术大牛资深技术 Leader 肺腑忠告快手王华彦端上视觉技术的极致效率及其短视频应用实践 | AI ProCon 2019每个新手程序员都应该知道的Python开发技巧5G来了智能手机们还能拼什么揭秘“链上FBI”Chainalysis如何追踪暗网交易真香朕在看了
