大家好，感谢你们今天来到swampp，很高兴你们能来。首先，让我自我介绍一下。我是来自JFrog的Tsofia Tsuriel，我已经在JFrog工作超过3年了。我的职业生涯是从配置管理工程师开始的，这是我们今天所说的DevOps工程师的前身。在那之后，我做了几年的C实时软件开发人员，然后加入JFrog。从我在JFrog的第一天起，我就一直在从事Kubernetes项目，2018年我们开始为JFrog SaaS应用程序开发基于Kubernetes的解决方案。
我很自豪地说，我是公司这个项目的一部分，我认为它把JFrog SaaS解决方案带到了一个全新的高度，它是基于Kubernetes平台的新一代SaaS解决方案的一个很好的例子。今天，我在这里向你们讲述我们在Kubernetes世界中的旅程，以及将其作为JFrog SaaS基础设施平台的旅程。我将和你们谈谈我们必须解决的问题，我们是如何使用Kubernetes解决这些问题的，我们在整个过程中学到了什么，所以你们也可以从我们的经验中学习。
我相信不同的公司和不同的团体可能会有不同的经历，但基本上我认为我们想要解决的问题对很多公司来说都是共同的，使用Kubernetes来解决这些问题可能是一个非常好的，如果不是最好的，现有的解决方案。在这节课中，我将尝试给出真实的例子，在这节课中，我将能够在聊天窗口中回答你的问题，所以你可以自由地问任何你想问的问题。首先，我们讨论为什么要使用Kubernetes ?Kubernetes解决了实际问题。Stack Overflow上最近发布的一篇博客文章提到了Kubernetes如此受欢迎的几个原因。首先，基础设施即数据。所需的资源在K2022世界杯阿根廷预选赛赛程ubernetes中以一种非常简单的方式表示，使用YAML文件。在YAML文件中定义所有内容，可以选择在版本控制下管理它们，比如Git，而且从可伸缩性的角度来看也非常容易，因为在YAML文件中可以轻松更改和更新所有内容。年代
兴起,可扩展性。现有的资源有很多，比如有状态集、配置映射、秘密、cron作业等2022世界杯阿根廷预选赛赛程等，用户可以根据自己的需要添加更多类型。第三,创新。在过去的几年里，每年都有3到4个带有许多新特性和变化的主要发布，而且看起来，这不会放缓。第四,社区。Kubernetes以其强大的社区和CNCF的支持而闻名。KubeCon是世界上有史以来最大的开源活动。2019年GitHub年度调查显示，Kubernetes是贡献者最受欢迎的十大开源项目之一，Kubernetes包管理器Helm是贡献者增长最快的十大开源项目之一。在过去的两年里，在stack overflow的年度调查中，Kubernetes与Linux和Docker一起成为最受开发人员喜爱的三大平台之一。在JFrog中，我们找到了一些使用Kubernetes的理由。 First, I need a running environment. NOW! Developers as well as production need high velocity of creating environments for their daily work. This is something that can be easily reached using Kubernetes. Second, branch integration environment with other products’ branches. For example, Artifactory developer wants to set up an environment to test his branch with other applications’ versions. In the past, they had to set up a VM, install an OS, set network configuration, etc. This takes a lot of time.
同样，使用Kubernetes可以很容易地做到这一点。三是提高开发生产资源利用水平2022世界杯阿根廷预选赛赛程。在Kubernetes中，应用程序可以以较低的CPU和内存量启动，并根据消耗增加到特定的限制。它使管理员可以很容易地管理他们的资源并节省成本。2022世界杯阿根廷预选赛赛程我在后面的演讲中还会讲到这个。第四，支持JFrog产品的新分销。hth华体会最新官方网站如前所述，Kubernetes是一个非常受欢迎的平台，所以JFrog必须为我们的客户和社区提供其产品在Kubernetes上的安装。hth华体会最新官方网站
第五，将我们的集装箱产品投入生产。hth华体会最新官方网站换句话说，开发环境必须尽可能类似于生产环境。在Docker中有一个应用程序是很好的，但我们需要的远远不止这些，这就是像Kubernetes这样的完整解决方案平台所能提供的。第六，尽可能不了解供应商。由于我们必须能够在主要的云供应商上部署我们的所有产品，我们最好有一个API, Khth华体会最新官方网站ubernetes提供了一个基于供应商的抽象概念。七、应用程序的自动缩放和自动修复。这些都是Kubernetes的亮点，这些特性使得几乎每个人都想使用Kubernetes。事实上，它们是提高应用程序可靠性的重要特性。为了便于管理应用程序在Kubernetes上的部署，我们决定使用Helm。Helm是一个管理Kubernetes包的工具，称为图表。 Like RPM or Centos or Red Hat. Helm charts helping, defining, installing, and upgrading Kubernetes applications.
JFrog在Helm应用中发布并维护其所有产品的官方Helm图表，供我们的客户、社区使用，当然还有我们的SaaS解决方案。hth华体会最新官方网站那么我们如何在内部环境中使用Kubernetes呢?出于开发目的，我们有一个CI/CD流程，在Kubernetes上安装JFrog产品。hth华体会最新官方网站根据需要，开发人员可以启动这个过程，并指定要安装的分支版本，而不需要应用程序的主版本或分支版本。
部署过程使用JFrog官方Helm图表，结果是一个独立的Kubernetes名称空间，其中安装了所有应用程序。在这里，您可以看到Jenkin的管道作业的输出，包括各种安装步骤，最后，开发人员可以运行他的专用JFrog平台。为了进行阶段和生产前的目的，我们有几个管理集群，每个云供应商至少有一个，我们正在运行JFrog产品安装的完整CI/CD流程，以及Kubernetes基础设施和工具，以便在升级我们的生产环境之前运行测试并发现错误。三年前，我们调查了在AWS、GCP和Azure中自我管理Kubernetes集群的几个选项。我们发现，对我们来说，最简单、最直接的方法是使用由云供应商EKS、GKE和AKS提供的托管Kubernetes解决方案。我们明白，自己管理集群需要大量我们不具备的资源和技能，我们最好专注于我们擅长的事情。2022世界杯阿根廷预选赛赛程
在过去的10年里，我们的生产环境在不同的地区使用相同的API运行EKS、GKE和AKS。我们仍然需要处理云供应商的特定服务，如日志平衡器、数据库等。转向使用Kubernetes减少了我们需要管理的特定于供应商的api的数量。一个新的客户部署，现在是一个自助服务和完全自动化的过程。不需要DevOps工程师的干预。该环境可在几分钟内在任何受支持的云区域上使用。免提自动化。谈论在生产系统中使用Kubernetes对一些人来说可能听起来很浪漫，你只是简单地运行一两个命令，所有东西都在它的地方运行。你有应用程序自动愈合和自动缩放，所以现在你可以自由地航行到日落更好的一杯红酒在你的手中。很快，你就会发现事实并非如此。 You find your ship in the middle of the storming sea, struggling big waves, breathing to drowning. And find yourself helpless and terrified. I know this sounds a little bit dramatic but this is not far from the feeling you have the first time you’re facing a service downtime with your new Kubernetes system. Once you pull yourself together, you’re starting to understand there is work to do to stabilize your ship and make it stronger and resistant. So next time, and of course there will be some of them, it faces high waves and big storms the shock will be smaller and the durability will be better. Let’s now discuss the things we learned and found as important during our process to stabilize our Kubernetes production ship. Visibility.
我们学到的第一件事是，由于Kubernetes作为平台的复杂性，我们需要看到系统中正在发生的事情。无论是给开发人员、团队、DevOps还是其他任何人使用。不再用SSH连接到服务器和“给我日志”。开发人员不应该需要_访问来调试他们的应用程序，而且Docker映像上没有基本的Linux _。因此，我们明白我们需要详细的日志记录和监控工具来持续地在集群上运行，收集矩阵中的所有日志，并为我们提供系统状态的可靠可见性，以及开发人员和支持团队调试应用程序所需的所有信息，实时和历史。起初，我们从本地ELK和Prometheus开始，但很快，随着规模的增长，我们发现就像托管的Kubernetes集群一样，我们应该使用专业的管理解决方案来进行日志记录和监控。这样就不需要管理监控和记录系统的规模，这对我们来说是非常耗时和消耗资源的。开发=阶段=生产。我们注意到，很多时候，当我们部署一个产品的新版本时，各种功能和性能问题只在生产中发现。hth华体会最新官方网站
这总是导致我们匆忙发布修复版本，就像之前提到的那样，我们有3个环境，我们知道我们必须尽可能减少这些环境之间的差异。在类似产品的环境中测试的能力使我们可以选择在开发时运行测试和检查，并可以最大限度地减少我们的发布时间、风险和_。今天，开发人员可以部署一个分支来评估与生产环境相同的环境，用它来进行专业和非专业测试。了解自己的极限。我们学到的一件重要的事情是我们必须了解我们的应用程序。这意味着您需要学习和理解应用程序如何在资源使用、内存、CPU、数据库、永久存储(如果需要的话)以及应用程序所需的任何方面工作，以便以最小的代价高效地执行和运行。2022世界杯阿根廷预选赛赛程在高利用率和高性能之间总是有一个平衡。你可以给你的应用程序大量的资源，这样它会运行得非常快，没有_，但这些资源可能是空闲的，有时会花2022世界杯阿根廷预选赛赛程费你很多钱，你需要找到一个平衡，正确的比例，让你的应用程序正常有效地运行。
类关闭也是如此，它定义了大小并编码了特定的CPU内存数量。还有Kubernetes调度程序，它确保_本身有足够的资源来解决所有的bug。2022世界杯阿根廷预选赛赛程但是你必须快速计算和理解你要运行多少_，他们需要什么资源，基于这个计划，集群大小和节点大小。2022世界杯阿根廷预选赛赛程别忘了，系统_和组件，如Kubelet, Kube代理，容器引擎和所有进程也需要资源。2022世界杯阿根廷预选赛赛程每个供应商对系统服务都有自己的定义，在您的计划和计算中必须考虑到这些定义。
Pod优先级和Pod服务质量。关于豆荚驱逐的有趣故事是，有一天，在最开始的时候，我们在驱逐模式中发现了几十个相同应用程序的豆荚，我们很恐慌，因为很难看到有一个豆荚，它可能会出错。那时我们才知道豆荚驱逐状态的存在。多亏了自动修复和自动缩放功能，客户没有经历停机时间。关于前一张幻灯片中提到的资源限制，应用程2022世界杯阿根廷预选赛赛程序的一个主要问题是它们正在使用的资源，Kubernetes的调度程序是一个组件，它负责在考虑资源需求的情况下，找到pod运行的最佳注释。Kubernetes中有3个服务质量等级。第一个，我保证。所有pods容器都为CPU请求和限制以及内存请求和限制指定了相同的值。这个选项是最安全的，因为Kubernetes承诺将它安排在一个具有所有所需资源的笔记中，并在笔记内存不足的情况下保护笔记不被删除。2022世界杯阿根廷预选赛赛程另一方面，如果在未进行初步调优的情况下设置请求和限制，就节点资源而言可能存在风险。2022世界杯阿根廷预选赛赛程
第二种是爆裂的。pod不能保证，但它的容器中至少有一个指定了内存或CPU请求。Burstable对大多数的pod都是好的，但它不是完全安全的，因为你的pod在某些情况下可能会被Kubernetes驱逐。最后一点是全力以赴。Pod不指定任何CPU和内存请求和限制。应该避免这种pod，因为它是第一个被驱逐的pod，并且可能非常危险，因为CPU和内存可以无限制地增长。我们发现，在非常早期的设置阶段，当你想稳定你的系统，然后你了解你的应用程序和它的需求时，有保证的选项是最好的，但它是最昂贵的选项。一段时间后，当你优化你的应用程序，做优化和重置资源，然后你可以开始使用最高优先级机制，它定义了什么是最重要的应用程序，当有一个驱逐过程。2022世界杯阿根廷预选赛赛程例如，当我们开始时，我们加载了很多应用程序，它们都没有定义pod优先级，我们发现Artifactory是许多pod所依赖的所有服务的核心，应该有更高的优先级，而日志采集器pod可以在_之后从同一位置停止和启动。另一个通过使用pod优先级来提高服务可用性的好例子是RabbitMQ。 When RabbitMQ runs on a cluster in Kubernetes there’s some interesting faults that happen as a result of RabbitMQ leaving and joining the cluster frequently.
一旦我们为RabbitMQ增加了pod优先级，它就变得非常稳定，并极大地减少了RabbitMQ集群相关的故障。零停机升级。作为SaaS，我们的目标应该是尽量减少由于任何原因导致的服务停机时间。应用程序版本升级应该能够在我们想要的任何时候运行。例如，客户的生产环境必须紧急安装Artifactory的安全补丁，我们不能拖延或等待维护会议。让应用程序在几个低平衡pod中以高可用性模式运行可以消除升级环境时停机的风险。使用Kubernetes，您可以选择滚动更新。所以，在特定的时间，只有一个吊舱下去进行升级，其他的仍在运行，他们将在他们的回合升级。需要提到的重要一点是，您的应用程序必须具有HA能力，可以顺利地添加或删除服务pod，并且再次强调，为此您必须了解您的应用程序，并相应地更改所需的内容以支持它。
此外，还有Kubernetes版本升级、云供应商升级或工具升级，这些升级必须在不中断应用程序可用性的情况下运行。Kubernetes中的一个很好的机制是探测，它可以帮助您确保应用程序确实是正常的，如果不是，请重新启动它。准备就绪探测是一种自动机制，用于了解容器何时准备好开始接受流量。活探测知道什么时候重新启动容器。而对于升级过程，例如，如果您正在升级RDS并且需要重新连接到数据库，活动探测将识别应用程序的故障状态并重新启动它，因此重新连接将自动完成。安全。在JFrog，我们喜欢吃自己的狗粮，并在日常工作和加工中使用我们的产品。hth华体会最新官方网站
话虽如此，很明显，管理Docker映像和Helm图表的最佳方法是使用Artifactory。我们使用一个内部Artifactory服务器作为Docker回购和Helm回购，在部署过程中，部署所需的一切都从Artifactory获取。因此，我们可以完全控制和可见在开发和生产Kubernetes集群中运行的内容。最重要的是，Xray运行并扫描存储在Artifactory中的所有第三方Docker图像，因此只有扫描和批准的图像才能进入Kubernetes的集群。这确保没有未经批准的代码在我们的集群上运行。持续学习。这是我希望你们从这次演讲中得到的主要信息之一。了解Kubernetes本身和您的系统的学习过程永远不会结束。Kubernetes作为一项技术对几乎所有人来说都是新的，开发人员和运维团队必须学习它是如何工作的，如何使用它，学习网络上可用的最佳实践和建议。了解如何在指标中寻找循环，以及如何获得调试应用程序所需的信息，您应该始终继续优化基础设施和应用程序及其行为。 Reviewing metrics from the past is very important you must check how your application behaves over periods of time. Take a specific process of behavior that hurts your system, such as bad performance process or high-network perception process and investigate it over a day, a week two weeks, a month, etc.
例如，在我们的一个主动检查中，我们发现CPU在几周内不断增加，这揭示了它导致CPU日志问题和内存错误。这是你在回顾一天或一周时无法发现的。要知道，今天也有很棒的机器学习和APM工具可以帮助您发现这类问题，甚至更好的是，根据预定义的规则提醒您。不要把过去的选择视为理所当然。考虑到在你做决定的时候，你不知道你现在知道的事情，你甚至经历过一两件事，现在你在一个需要处理的系统下有了更好的知识和信心。不断问自己这样做是否有意义，如果需要，不要害怕改变。最后，我想回顾一下我在这次演讲中提到的要点。如果这对你来说是最好的，使用管理Kubernetes，并始终专注于你擅长的事情。可见性，可见性，还是可见性。调试和控制系统的关键。 Don’t be afraid to use manage solutions. All environments should be similar as much as possible to reduce risks and potential bugs in production.
了解自己的极限。了解您的应用程序，并相应地设置资源和优先级。2022世界杯阿根廷预选赛赛程采取行动，以便有一个0停机升级。将应用程序更改为真正的HA。运行滚动升级并使用Kubernetes探测器。考虑安全性，尽量减少Docker映像可能带来的潜在风险。预期的失败。为他们做好心理准备，尽可能积极主动。不要忘记，您总是必须继续学习您的系统，调整您的配置和指标，并重新验证您的选择。我希望你们每一个人都能找到一两个与你们的组织相关的经验教训，并把它带回去改善你们的Kubernetes生产体验。 The Kubernetes journey probably never ends. but I hope that this talk convinced you that Kubernetes in production is actually not that hard. It is possible, it is fun and as we always say in the Swamp once you leap forward, you can’t go back.
