基础设施即代码(Infrastructure as Code)是一种将基础设施的配置和管理过程自动化的方法。它借鉴了软件开发中的一些实践,如版本控制、自动化测试和持续集成,将基础设施的配置和管理过程描述为可执行的代码。 通过使用基础设施即代码,开发团队可以将基础设施的配置和管理过程存储为代码,并将其纳入版本控制系统中。这样一来,团队成员可以对基础设施进行版本控制、进行代码审查和合并,并且可以使用自动化工具来验证和部署基础设施的更新。
kubernetes负载感知调度
背景
kubernetes 的原生调度器只能通过资源请求来调度 pod,这很容易造成一系列负载不均的问题,
并且很多情况下业务方都是超额申请资源,因此在原生调度器时代我们针对业务的特性以及评估等级来设置 Requests/Limit 比例来提升资源利用效率。
在这种场景下依然存在很多问题:
- 节点负载不均:原生 Kubernetes Scheduler 根据 Requests 和节点可分配总量来调度 Pod,既不考虑实时负载,也不估计使用量,这种纯静态的调度导致节点资源利用率分配不均。
在流量波动性业务的场景下,在流量高峰时,部分节点利用率突破安全阈值,但是很多节点的利用率特别点,节点利用率相差特别大 - 业务周期性:在离线集群分离,在线集群底峰存在巨大资源浪费
koordinator混部系统
koordinator 是一个基于 qos 的 kubernetes 混合工作负载调度系统。它旨在提高对延迟敏感的工作负载和批处理作业的运行时效率和可靠性,简化与资源相关的配置调整的复杂性,并增加 pod 部署密度以提高资源利用率。
如何优雅的脚踏多朵云
背景
现在越来越多的企业会选择将自己的业务上云,一方面是因为云厂商越来越稳定完善,上云可以获得更稳定省心的IaaS层,另一方面是相比较于自建,可以节省成本。如果企业追求更极致的SLA,往往会更近一步,选择多云,毕竟鸡蛋放两个篮子里可以更安全些。
好处当然是显然易见,但是问题也随之而来
多云带来的问题
多云会带来很多问题,比如多云之间的网络专线费用,多云之间的流量隔离(故障容灾),以及他们之前不通的技术栈所带来的运维层面的屏蔽。我们这里着重谈论多云带来的云资源交付的问题:
- 资源交付自动化的过程中需要对接多云的文档或者SDK,体力活,并且会有持续的增量开发
- 产品层面建模屏蔽云厂商的差异,用户不需要感知云厂商,也不应该感知云厂商的存在,因为IaaS层应该可以随时从一个云迁移到另外一个云,只有具备这种能力,才具备与云厂商的议价权(企业用户折扣真的可以很大)
- 每个云上都有产品,难道我们真的要每个产品都对应去建模,如果不建模该怎么办
- 容器化大潮,如何相对统一的交付资源
Terraform管理云资源实践
初识Terraform
StackStorm(事件驱动的自动化引擎)
概念
StackStorm是一个功能强大的开源自动化平台,可将所有应用程序,服务和工作流程连接起来。 它具有可扩展性,灵活性, 设计中包含了对DevOps和ChatOps的热爱。它可以将您现有的基础架构和应用程序环境联系在一起,以便您可以更轻松地自动化操作该环境。它特别专注于针对事件采取行动。
便利的故障排除 - 触发由监控系统捕获的系统故障,在物理节点、OpenStack或Amazon实例和应用程序组件上运行一系列诊断检查,并将结果发布到共享通信环境中,如HipChat或JIRA。
自动修复 - 识别和验证OpenStack计算节点上的硬件故障,正确隔离实例并向管理员发送关于潜在停机时间的电子邮件,但如果出现任何问题 - 暂停工作流程并呼叫人员。
持续部署 - 与Jenkins一起构建和测试,配置新的AWS群集,基于NewRelic的应用程序性能数据,打开负载均衡器的一些流量,以及前滚或回滚