转载

JFrog 内部基于 Kubernetes 的实践

背景

Kubernetes 正在被大量的公司用于微服务应用的部署，快速搭建微服务的测试环境，应用的自动扩容等等场景，而 JFrog 也在 Kubernetes 的使用上进行了大量的实践，在最近召开的 JFrog SwampUp 用户大会上，JFrog 分享了内部的 Kubernetes 实践。

首先我们内部需要解决的问题是：

需要能够快速搭建全功能的测试环境，给开发，测试，技术支持，产品团队，解决方案团队等所有团队使用。
并且每个分支都提供流水线的支撑，让研发有独立的沙箱环境进行自测，这也是 Kubernetes 带来的最大价值点之一。
更好的利用现有的资源。
支撑 JFrog 产品的新交付方式。

JFrog 落地 Kubernetes 的实践和经验

基于上面的需求，我们进行了一些 Kubernetes 的实践。首先我们从很小的应用开始进行 Kubernetes 的部署。例如 Nginx，开始定义小的目标去将应用部署到 Kubernetes，确保我们对整个容器化的进程技术上可控。

JFrog 内部基于 Kubernetes 的实践

首先需要看看你的应用是否适合部署到 Kubernetes。对于日志的输出必须使用标准的规范，同时需要支持大量的日志。其次要考虑数据持久化的问题，什么样的数据需要被持久化？还要合理的处理重启操作，如何处理重启前遗留的临时数据？

JFrog 内部基于 Kubernetes 的实践

高可用是 JFrog 产品的默认功能，所以我们会有大量的高可用测试的需求。需要能够快速扩容支持大并发的请求，支持滚动升级（0宕机升级）的测试，破坏性测试，包括计划和非计划的 Node 宕机测试，集群缩容测试。

一旦你的应用准备好了，我们可以讨论下如何合理的配置你的 Kubernetes Pod。

JFrog 内部基于 Kubernetes 的实践

由于我们每个研发，每个分支都有独立的 Kubernetes 环境进行容器化的部署，一旦研发开始大规模的测试，资源必然会有出现瓶颈的时候。所以一定要对 Pod 进行资源的限制。同时，对 Pod 里的应用也需要进行限制，例如 Java 的内存限制，MQ 和 Mongo 的内存限制。

JFrog 内部基于 Kubernetes 的实践

每个应用都必须有可信的健康数据，来通知 Kubernetes 外部的系统知道该应用是否正常启动。Kubernetes 提供了 ReadinessProbe和 LivenessProbe 两种探针。ReadinessProbe 表示应用是否启动了，LivenessProbe 表示应用是否可以正常使用。它支持多种类型，对于 Exec，返回0表示成功。对于 Http 返回<400表示成功，对于 TCP 会监测是否在指定端口成功建立 Socket 通信。

JFrog 内部基于 Kubernetes 的实践

通常一个 Pod 里不能完成所有的事情，所以 Pod 通常会有多个容器。通常我们会配置 init 的容器，去配置存储和配置信息。同时会配置 Sidecar 容器去收集日志，监控和代理。

JFrog 内部基于 Kubernetes 的实践

我们在发布 Kubernetes 应用时，往往会发布多个组件，模块，从而对应了多个 Yaml 文件，而其中某个模块升级时，这些文件的关联关系就会变得错综复杂。同时，如何管理多个环境的 Yaml 文件里的配置信息？如何回滚到上一个稳定微服务架构应用的部署？

JFrog 内部基于 Kubernetes 的实践

Helm 是 Kubernetes 的官方包管理工具，我们使用 Helm 来解决上面提到的问题。你的应用所关联的所有模块都用一个文件进行描述- Helm Chart。每次部署的应用都会对于不同版本的 Chart，用于做灰度发布，回滚。Chart 里所有和环境，配置相关的信息都存储在 values.yaml 文件里，从而能够对于不同的环境，例如开发环境有 dev-values.yaml，对于生产环境有 prod-values.yaml。

JFrog 内部基于 Kubernetes 的实践

Helm 的使用方式及其简单，使用命令 Helm install Artifactory 即可部署一个 Artifactory 应用到 Kubernetes 里，也可以用同样的方式很多其他的应用，比如 Jenkins 等等。

JFrog 内部基于 Kubernetes 的实践

在应用监控这块，我们使用 EFK 进行所有 Pod 里日志的收集，索引，以及可视化。我们不给研发 SSH 到 Pod 里看日志的权限，而是必须通过我们的 EFK 平台进行日志检索，虽然对我们提出了很高的要求，但最终还是满足了大部分研发的需求，提升了研发的定位错误的能力。

JFrog 内部基于 Kubernetes 的实践

我们也使用 Jenkins Pipeline 进行我们的流水线。得益于 Artifactory 的全语言仓库，我们自身应用需要的 War 包，Tomcat，Docker 镜像都从 Artifactory 统一进行拉取，并且使用 Helm 仓库进行 Kubernetes 集群应用的部署。

JFrog 内部基于 Kubernetes 的实践

目前我们已经能够实现：

CI/CD 流水线直接对接到 Kubernetes 进行测试，均使用 Helm 进行部署。

1.每个研发的每个分支具备独立的测试沙箱环境，供研发进行自测。

2.每周100+不同产品线的任意版本组合部署，每次部署超过50种微服务。

对应 Kubernetes 的用户，我们提供 Helm Chart 帮助用户快速部署我们的产品线，包括 JFrog Artifactory，Xray，Mission Control 等等。

总结

JFrog 作为一家技术为本的公司不断在 CI/CD 的浪潮中进行探索，目前我们的 Artifactory 已经支持高可用的 Maven, Npm 私服，Docker 镜像仓库，Go 语言的仓库 VGo，Helm 仓库等全语言仓库，它会作为公司内部的 Kubernetes 注册中心，它能够描述 Docker 镜像的质量信息，比如是否经过单元测试，代码扫描，性能测试，漏洞扫描等等，描述 Docker 镜像的质量信息，能够为研发团队提供一站式的应用交付能力，而这些能力恰恰是你落地 DevOps 的最后一公里，也是最稀缺的能力。

参考资料：https://kubernetes.io/docs/concepts/cluster-administration/logging/#using-a-sidecar-container-with-the-logging-agent

JFrog 内部基于 Kubernetes 的实践