-
序言
-
云原生(Cloud Native)的定义
-
云原生的设计哲学
-
Play with Kubernetes
-
快速部署一个云原生本地实验环境
-
使用Rancher在阿里云上部署Kubenretes集群
-
Kubernetes与云原生应用概览
-
云原生应用之路——从Kubernetes到Cloud Native
- 云原生编程语言
-
云原生的未来
- Kubernetes架构
- Kubernetes中的网络
-
资源对象与基本概念解析
- Pod状态与生命周期管理
- 集群资源管理
- 控制器
- 服务发现
- 身份与权限控制
- 存储
- 集群扩展
- 资源调度
-
用户指南
- 资源对象配置
- 命令使用
- 集群安全性管理
- 访问Kubernetes集群
- 在Kubernetes中开发部署应用
-
最佳实践概览
- 在CentOS上部署Kubernetes集群
- 生产级的Kubernetes简化管理工具kubeadm
- 服务发现与负载均衡
- 运维管理
- 存储管理
- 集群与应用监控
- 分布式跟踪
- 服务编排管理
- 持续集成与发布
- 更新与升级
-
领域应用概览
- 微服务架构
- Service Mesh 服务网格
- 大数据
- Serverless架构
-
边缘计算
-
人工智能
-
开发指南概览
-
SIG和工作组
- 开发环境搭建
-
单元测试和集成测试
-
client-go示例
- Operator
-
kubebuilder
-
高级开发指南
-
社区贡献
-
Minikube
-
CNCF - 云原生计算基金会简介
-
CNCF章程
-
CNCF特别兴趣小组(SIG)说明
-
开源项目加入CNCF Sandbox的要求
-
CNCF中的项目治理
-
CNCF Ambassador
-
附录说明
-
Kubernetes中的应用故障排查
-
Kubernetes相关资讯和情报链接
-
Docker最佳实践
-
使用技巧
-
问题记录
- Kubernetes版本更新日志
- Kubernetes及云原生年度总结及展望
- CNCF年度报告解读
-
Kubernetes认证服务提供商(KCSP)说明
-
认证Kubernetes管理员(CKA)说明
持续集成与发布
持续集成与发布,简称CI/CD,是微服务构建的重要环节,也是DevOps中推崇的方法论。如何在kubernetes中使用持续构建与发布工具?可以既可以与企业内部原有的持续构建集成,例如Jenkins,也可以在kubernetes中部署一套新的持续构建与发布工具,例如Drone。
众所周知Kubernetes并不提供代码构建、发布和部署,所有的这些工作都是由CI/CD工作流完成的,最近TheNewStack又出了本小册子(117页)介绍了Kubernetes中CI/CD的现状。下载本书的PDF请访问:https://thenewstack.io/ebooks/kubernetes/ci-cd-with-kubernetes/
本书的作者有:
- Rob Scott:ReactiveOps公司的SRE
- Janakiram MSV:Janakiram & Associates 的首席分析师
- Craig Martin:Kenzan的高级副总裁
- Container Solutions
这本小册子里主要主要介绍了以下几点:
- DevOps模式
- 云原生应用模式
- 使用Spinnaker做持续交付
- 云原生时代的监控
DevOps模式
这一章从一些流行的自动化运维工具讲起,比如Chef、Puppet等,引申出CI/CD流水线,进而引出Docker和DevOps,将容器如何解除开发和运维之间的隔阂,但同时也带来了一些挑战,比如频繁的发布变更如何控制,如何控制容器集群的行为,如何拆分应用到容器之中等。这是一个专门用于容器编排调度的工具呼之欲出,Kubernetes的出现彻底改变了局面,可以说它直接改变了应用的基础架构。
Kubernetes细化的应用程序的分解粒度,同时将服务发现、配置管理、负载均衡和健康检查等作为基础设施的功能,简化了应用程序的开发。
而Kubernetes这种声明式配置尤其适合CI/CD流程,况且现在还有如Helm、Draft、Spinnaker、Skaffold等开源工具可以帮助我们发布Kuberentes应用。
有了基于Kubernetes的CI/CD流程后,又诞生了GitOps(https://www.weave.works的博客中有很多相关文章)和SecOps(Security Operation)。
云原生应用模式
云原生是通过构建团队、文化和技术,利用自动化和架构来管理系统的复杂性和解放生产力。——Joe Beda,Heotio CTO,联合创始人
这一章的重点是给出了云原生应用的10条关键属性。
- 使用轻量级的容器打包
- 使用最合适的语言和框架开发
- 以松耦合的微服务方式设计
- 以API为中心的交互和协作
- 无状态和有状态服务在架构上界限清晰
- 不依赖于底层操作系统和服务器
- 部署在自服务、弹性的云基础设施上
- 通过敏捷的DevOps流程管理
- 自动化能力
- 通过定义和策略驱动的资源分配
作者然后将应用程序架构中的不同组件映射到云原生的工作负载中,如下图所示:
这也是DevOps需要关注的部分,如何将云原生的组件映射为Kubernetes的原语(即Kubernetes里的各种资源对象和概念组合)呢?如下图所示。
总结概括为以下10条:
- 不要直接部署裸的Pod。
- 为工作负载选择合适的Controller。
- 使用Init容器确保应用程序被正确的初始化。
- 在应用程序工作负载启动之前先启动service。
- 使用Deployment history来回滚到历史版本。
- 使用ConfigMap和Secret来存储配置。
- 在Pod里增加Readiness和Liveness探针。
- 给Pod这只CPU和内存资源限额。
- 定义多个namespace来限制默认service范围的可视性。
- 配置HPA来动态扩展无状态工作负载。
使用Spinnaker进行持续交付
作者首先讲到了Spinnaker的各种特性,比如面向微服务啦,云原生的交付工具啦,可视化的交付和基础设施啦,支持多个region,支持容器和Kubernetes等等,不一而足,感兴趣大家可以自己看下报告或者登陆Spinnaker官网https://www.spinnaker.io查看。
下图是Spinnaker中的组件和角色的交互关系。
下图是Spinnaker的几种不同环境的流水线。
总之作者就是想说Spinnaker很好很强大啦,足以满足您对云原生应用CI/CD的需求。
云原生时代的监控
监控是为了实现系统的可观察性,不要以为监控就是简单的出个监控页面,监控其实包括以下部分:
- 日志收集
- 监控和指标度量
- 追踪
- 告警和可视化
要把其中任何一个方面做好都不容器。
作者主要讲述的Prometheus和Grafana的开源监控方案。
这一章我不详述,感兴趣大家可以查看报告原文。