JFrog 高欣 Kubernetes上的DevSecOps ——JFrog的Kubernetes之旅

CodeWarrior

2019/07/08 发布于 编程 分类

GIAC2019 

文字内容
1. 面向Kubernetes的DevSecOps ——JFrog的Kubernetes之旅 高欣 JFrog 架构师
3. 讲师简介 高欣 • 博士 • JFrog架构师 • 前IBMer • 敏捷、DevOps、。。。 • 软件产品/云服务 研发、测试、运维、服务、。。。
4. 演讲大纲 JFrog内部的Kubernetes实践 o 我们正在做的: ➢ JFrog的应用和服务全面Kubernetes化 ➢ 内部的研发和测试环境全面Kubernetes化 o 我们要分享的: ➢ 实践中积累的教训和经验
5. 背景介绍 要解决的问题 o用户安装部署JFrog产品复杂 o无法快速搭建JFrog产品的全功能测试环境 ➢无法实现按需使用:开发、测试、技术支持、产品、解决方案。。。任意团队 o 无法为每个分支提供独立的CI/CD流水线支撑 ➢无法让研发有独立的沙箱环境进行自测 ➢CI/CD流程混乱
6. 背景介绍 Kubernetes is hard!
7. 案例成果 实践的成果 o 为客户提供全产品线的Helm Charts交付方式 ➢Helm install stable/Artifactory-ha o 云端服务Kubernetes化 ➢GoCenter: http://gocenter.io o产品的CI/CD直接对接到Kubernetes环境 ➢每周部署100+不同产品线、任意版本组合的测试环境,每次部署超过50种 微服务 ➢为每个研发、每个分支,按需提供完全独立的测试环境
8. 成功要点 o 起步:熟悉Kubernetes o 规划:面向Kubernetes的改造 o 编排:Helm Charts o 部署:自动、监测 o 安全:DevSecOps
9. 起步:熟悉Kubernetes —— 从小处入手 o第一个Kubernetes环境 ➢自己探索:Kubernetes The Hard Way,Kelsey Hightower (https://github.com/kelseyhightower/kubernetes-the-hard-way) ➢公有服务:AKS、EKS、GKE、阿里、腾讯、。。。 ➢私有部署:miniKube、Rancher、。。。 o 第一个Kubernetes应用 ➢从小的示例应用开始,如Nginx ➢每次只设定一个小的、具体的目标 ➢充分利用现有的教程和演示
10. 规划:面向Kubernetes的改造 The Twelve-Factor App ( https://12factor.net/zh_cn/ ) I. 基准代码:一份基准代码,多份部署 VII. 端口绑定:通过端口绑定提供服务 II. 依赖:显式声明依赖关系 VIII.并发:通过进程模型进行扩展 III. 配置:在环境中存储配置 IX.易处理:快速启动和优雅终止可最大化健壮性 IV. 后端服务:把后端服务当作附加资源 X.开发环境与线上环境等价:尽可能的保持开发, V. 构建,发布,运行:严格分离构建和运行 预发布,线上环境相同 XI.日志:把日志当作事件流 VI. 进程:以一个或多个无状态进程运行应用 XII.管理进程:后台管理任务当作一次性进程运行
11. 规划:应用的Kubernetes改造 仅仅把应用装进Docker是远远不够的 o 日志 ➢STDOUT/STDERR ➢处理足够多的日志文件 o 持久化数据 ➢哪些数据需要持久化存储? o 合理地处理SIGTERM信号 ➢ Shutdown必须是受控的 ➢ Recovery必须是容易的 o 重启 ➢ 如何处理上一次运行的遗留数据?
12. 规划:应用的Kubernetes改造 高可用将是新的标准配置 o 保证良好的持久性和可用性 o 不停机的滚动升级 ➢ 保证向后兼容 o 支持同时运行多个应用实例 o K8s调整中的0宕机 ➢支持负载均衡 ➢ Cluster Scale-up、Scale-down ➢Scale-up、Scale-down必须是顺畅的 ➢ 计划中的Node维护 ➢ 非计划的Node宕机
13. 规划:配置的Kubernetes改造 运行环境的资源使用必须是受限的 o Pod的资源限制! o 应用本身也需要资源限制 … resources: requests: memory: "1Gi" cpu: "100m" limits: memory: "2Gi" cpu: "250m" ... o 改造 ➢requests/limits ➢跨Node的HA ➢Out Of Resource Handling (https://kubernetes.io/docs/tasks/administer-cluster/out-of-resource/) ➢Pod Priority and Preemption (https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/)
14. 规划:配置的Kubernetes改造 应用的运行状态必须有可信的健康数据 o readinessProbe o livenessProbe o 探针类型 ➢Http - return < 400 on success ➢Tcp - succeed to open a socket on a given port ➢Exec - return 0 on success
15. 规划:配置的Kubernetes改造 Application pod example. … Pod里只有应用的容器是不够的 o init容器 —— 在应用容器启动前运行 ➢准备存储 ➢初始化设置 resources: Multiple artifactory logs forwarded by a Fluentbit requests: container to a log aggregator. memory: "1Gi" cpu: "100m" limits: memory: "2Gi" Pod cpu: "250m" ... Application container o sidecar容器 —— 和应用容器同时运行 ➢维护 ➢日志收集 ➢监测 ➢代理 Log collector Fluentbit container Logs
16. 编排:Kubernetes原生 — kubectl + yaml 利用yaml文件编排已经足够好了吗? o 多个组件、模块,对应多个yaml文件 o 应用的版本化怎么管理? … resources: requests: memory: "1Gi" cpu: "100m" limits: memory: "2Gi" cpu: "250m" ... ➢怎么管理多个yaml文件的版本组合? o 配置数据怎么管理? ➢怎么部署到多个目标环境? 自测、开发、测试、产品。。。 o怎么回滚到之前的特定版本?
17. 编排: Helm Charts Helm —— 容器云应用的安装部署工具 o https://helm.sh o Helm Hub ➢https://hub.helm.sh … resources: requests: memory: "1Gi" cpu: "100m" limits: memory: "2Gi" cpu: "250m" ...
18. 编排: Helm Charts 版本化管理 oHelm Chart ➢一个包包含了所有模块 ——templates/ oChart的版本化管理 ➢Chart.yaml o运行态的版本化管理 ➢Release … resources: requests: memory: "1Gi" cpu: "100m" limits: memory: "2Gi" cpu: "250m" ...
19. 编排: Helm Charts 配置数据分离 o缺省配置 ➢values.yaml o目标环境配置 ➢values-test.yaml ➢values-prod.yaml
20. 编排: Helm Charts 共享、依赖 orequirements.yaml ocharts/
21. 流程:自动、复用
22. 流程:制品的统一管理
23. 流程:信息的统一管理
24. 流程:持续交付
25. 流程:分级持续交付 周期 weeks days app-bundle-1.0 Micro-A-bundle-1.0 Micro-B-bundle-2.0 Metadata: app-1.0.qa.test.result = OK App-pipeline UAT -> Pre-Prod->Prod 分级Metadata Micro-A—bundle-1.0 SIT - > UAT -> Pre-Prod->Prod Front-1.0.tar Backend-2.0.jar 分级Metadata Metadata: micro-a-1.0.qa.test.result = OK Micro-A-pipeline … Hours Backend-A-pipeline … Local -> Dev backend-1.0.jar Metadata: qa.test.result = OK qa.code.result = OK project.revision = ASDASSAC binary.config.path=backend/dev/1.0 deploy.pre-prod.result=OK
26. 流程:应用监测 需要新的监测手段 ossh不管用了 o直接用kubectl调试也是不合适的 oDev/Ops应该能方便地访问可信的数据 ➢监视 ➢日志 o基于可控的OOB(Out-of-Band)工具 o微服务监测的基本原则 ( https://thenewstack.io/five-principles-monitoring-microservices)
27. 流程:应用监测 监视 oPrometheus oGraphana
28. 流程:应用监测 日志 oEFK
29. 安全:DevSecOps
30. 安全:DevSecOps 你的应用 你的代码
31. 安全:DevSecOps
32. 安全:外部依赖的安全漏洞 oDocker ➢ 30%的DockerHub上的镜像有安全漏洞 oNPM ➢ 14%的NPM包有安全漏洞 oMaven ➢ 59%的已知安全漏洞还没有解决 ➢ MTTR(平均修复时间):290天 ➢ CVSS10: 265天
33. 安全:DevOpsSec Commit Build Image/ Helm Chart Test (Automated/Manual) Security Scanning Deploy Upload Artifact to Artifactory Monitor
34. 安全:DevOpsSec 扫描、定位、分析
35. 安全:DevOpsSec 安全检查左移 Visual Stadio Eclipse IDEA
36. 案例启示 Kubernetes尚未成功。。。 o 起步:熟悉Kubernetes o 规划:面向Kubernetes的改造 o 编排:Helm Charts o 部署:自动、监测 o 安全:DevSecOps
37. 关注msup微信公众账号 关注高可用架构公众账号 获取更多技术实践干货 改变互联网的构建方式