什么是Kubernetes（容器化和部署指南） _容器化

不久前, 我们使用了整体式Web应用程序：巨大的代码库不断增加新的功能和特性, 直到它们变成庞大, 运行缓慢, 难以管理的巨人。现在, 越来越多的开发人员, 架构师和DevOps专家开始认为, 使用微服务比使用巨型组件要好。通常, 使用基于微服务的体系结构意味着将你的整体分成至少两个应用程序：前端应用程序和后端应用程序(API)。在决定使用微服务后, 出现一个问题：在哪种环境下运行微服务更好？我应该选择什么来使我的服务稳定以及易于管理和部署？简短的答案是：使用Docker！
在本文中, 我将向你介绍容器, 解释Kubernetes, 并教你如何使用CircleCI将应用容器化并将其部署到Kubernetes集群。
Docker？什么是Docker？
Docker是一种旨在简化DevOps(以及你的生活)的工具。使用Docker, 开发人员可以在容器中创建, 部署和运行应用程序。容器使开发人员可以将应用程序所需的所有部分(如库和其他依赖项)打包在一起, 并将其全部打包为一个包。

文章图片
比较部署到主机的应用程序与打包在容器中的应用程序
使用容器, 开发人员可以轻松地将映像重新部署到任何操作系统。只需安装Docker, 执行命令, 你的应用程序即可启动并运行。哦, 不用担心与主机操作系统中新版本库的任何不一致。此外, 你可以在同一主机上启动更多容器-是同一应用程序还是其他应用程序？没关系
似乎Docker是一个了不起的工具。但是, 我应该如何以及在哪里启动容器？
有许多关于如何以及在何处运行容器的选项：AWS Elastic Container Service(AWS Fargate或具有水平和垂直自动缩放功能的保留实例)；在Azure或Google Cloud中具有预定义Docker映像的云实例(具有模板, 实例组和自动缩放)；使用Docker在你自己的服务器上; 或者, 当然是Kubernetes！ Kubernetes是2014年由Google的工程师专门为虚拟化和容器创建的。
Kubernetes？那是什么？
Kubernetes是一个开放源代码系统, 可让你运行容器, 对其进行管理, 自动化部署, 扩展部署, 创建和配置入口, 部署无状态或有状态的应用程序以及许多其他东西。基本上, 你可以启动一个或多个实例并安装Kubernetes以将其作为Kubernetes集群进行操作。然后获取Kubernetes集群的API端点, 配置kubectl(用于管理Kubernetes集群的工具), 并且Kubernetes准备就绪。
那我为什么要使用它呢？
使用Kubernetes, 你可以最大程度地利用计算资源。使用Kubernetes, 你将成为Kubernetes充任风帆的船长(基础设施)。使用Kubernetes, 你的服务将是HA。最重要的是, 使用Kubernetes, 你将节省很多钱。
看起来很有希望！特别是如果它可以省钱！让我们再说吧！
Kubernetes日益流行。让我们更深入地研究引擎盖下的内容。
幕后花絮：什么是Kubernetes？

文章图片
组成Kubernetes的组件
Kubernetes是整个系统的名称, 但是就像你的汽车一样, 有许多小零件可以完美协调地协同工作以使Kubernetes发挥作用。让我们了解它们是什么。
主节点-用于整个Kubernetes集群的控制面板。主服务器的组件可以在群集中的任何节点上运行。关键组件是：

API服务器：所有REST命令的入口点, 是用户可访问的主节点的唯一组件。
数据存储：Kubernetes集群使用的强大, 一致且高度可用的键值存储。
调度程序：监视新创建的Pod, 并将其分配给节点。由于调度程序, 将Pod和服务部署到节点上。
控制器管理器：运行所有处理集群中例行任务的控制器。
工作节点：主节点代理, 也称为奴才节点。豆荚在这里运行。工作节点包含所有必需的服务, 以管理容器之间的联网, 与主节点通信以及为计划的容器分配资源。
Docker：在每个工作节点上运行, 并下载映像和启动容器。
Kubelet：监视容器的状态, 并确保容器已启动并正在运行。它还与数据存储通信, 获取有关服务的信息并编写有关新创建的服务的详细信息。
Kube-proxy：单个工作节点上服务的网络代理和负载平衡器。它负责流量路由。
Kubectl：一个CLI工具, 供用户与Kubernetes API服务器通信。

什么是吊舱和服务？
豆荚是Kubernetes集群中最小的单元, 就像一堵巨大建筑物墙壁中的一块砖。容器是一组需要一起运行并且可以共享资源(Linux名称空间, cgroup, IP地址)的容器。豆荚不宜长寿。
服务是许多Pod之上的抽象, 通常需要最上面的代理才能使其他服务通过虚拟IP地址与其通信。
简单部署示例

文章图片
不同的利益相关者如何与Kubernetes支持的应用程序交互
我将使用一个简单的Ruby on Rails应用程序和GKE作为运行Kubernetes的平台。实际上, 你可以在AWS或Azure中使用Kubernetes, 甚至可以在自己的硬件中创建集群, 或者使用minikube在本地运行Kubernetes, 这是你在此页面上找到的所有选项。
该应用程序的源文件可以在此GitHub存储库中找到。
要创建一个新的Rails应用程序, 执行：

rails new blog

【什么是Kubernetes（容器化和部署指南）】要在config / database.yml文件中配置用于生产的MySQL连接：

production: adapter: mysql2 encoding: utf8 pool: 5 port: 3306 database: < %= ENV['DATABASE_NAME'] %> host: 127.0.0.1 username: < %= ENV['DATABASE_USERNAME'] %> password: < %= ENV['DATABASE_PASSWORD'] %>

要创建Article模型, 控制器, 视图和迁移, 请执行：

rails g scaffold Article title:string description:text

要将宝石添加到Gemfile中：

gem 'mysql2', '< 0.6.0', '> = 0.4.4' gem 'health_check'

要创建Docker映像, 请获取我的Dockerfile并执行：

docker build -t REPO_NAME/IMAGE_NAME:TAG . & & docker push REPO_NAME/IMAGE_NAME:TAG

现在该创建Kubernetes集群了。打开GKE页面并创建Kubernetes集群。创建集群后, 单击” 连接按钮” 并复制命令-确保已安装并配置了gCloud CLI工具(方法)以及kubectl。在你的PC上执行复制的命令, 并检查与Kubernetes集群的连接；执行kubectl cluster-info。
该应用程序已准备好部署到k8s集群。让我们创建一个MySQL数据库。在gCloud控制台中打开SQL页面, 然后为该应用程序创建一个MySQL数据库实例。实例准备好后, 创建用户和数据库并复制实例连接名称。
另外, 我们需要在” API和服务” 页面中创建一个服务帐户密钥, 以便从sidecar容器访问MySQL数据库。你可以在此处找到有关该过程的更多信息。将下载的文件重命名为service-account.json。稍后我们将返回该文件。
我们已经准备好将应用程序部署到Kubernetes, 但是首先, 我们应该为我们的应用程序创建机密-Kubernetes中的一个秘密对象, 用于存储敏感数据。上载先前下载的service-account.json文件：

kubectl create secret generic mysql-instance-credentials \ --from-file=credentials.json=service-account.json

为应用程序创建机密：

kubectl create secret generic simple-app-secrets \ --from-literal=username=$MYSQL_PASSWORD \ --from-literal=password=$MYSQL_PASSWORD \ --from-literal=database-name=$MYSQL_DB_NAME \ --from-literal=secretkey=$SECRET_RAILS_KEY

不要忘记用值替换值或设置环境变量。
在创建部署之前, 让我们看一下部署文件。我将三个文件合并为一个。第一部分是服务, 它将公开端口80, 并将所有连接到端口80的连接转发到3000。该服务具有选择器, 服务使用该选择器知道应将其转发到哪些Pod。
文件的下一部分是部署, 它描述了部署策略-将在容器内启动的容器, 环境变量, 资源, 探测器, 每个容器的安装以及其他信息。
最后一部分是Horizo??ntal Pod Autoscaler。 HPA具有非常简单的配置。请记住, 如果你没有在” 部署” 部分中为容器设置资源, 则HPA将无法使用。
你可以在GKE编辑页面中为Kubernetes集群配置Vertical Autoscaler。它还具有非常简单的配置。
现在是时候将其运送到GKE集群了！首先, 我们应该通过作业进行迁移。执行：
kubectl apply -f rake-tasks-job.yaml –此作业对CI / CD进程很有用。
kubectl apply -f deployment.yaml –创建服务, 部署和HPA。
然后通过执行以下命令来检查你的pod：kubectl get pods -w

NAMEREADYSTATUSRESTARTSAGE sample-799bf9fd9c-86cqf2/2Running01m sample-799bf9fd9c-887vv2/2Running01m sample-799bf9fd9c-pkscp2/2Running01m

现在, 为应用程序创建一个入口：

创建一个静态IP：gcloud计算地址创建sample-ip – global
创建入口(文件)：kubectl apply -f ingress.yaml
检查是否已创建入口并获取IP：kubectl get ingress -w
为你的应用程序创建域/子域。

CI / CD
让我们使用CircleCI创建CI / CD管道。实际上, 使用CircleCI创建CI / CD管道很容易, 但是请记住, 快速而肮脏的全自动部署过程无需进行这样的测试就可以用于小型项目, 但是对于严重的事情请不要这样做, 因为, 如果任何新代码在生产中出现问题, 你将蒙受损失。这就是为什么你应该考虑设计一个健壮的部署过程, 在全面推出之前启动Canary任务, 在Canary启动后检查日志中的错误等等。
目前, 我们有一个小型的简单项目, 因此让我们创建一个完全自动化的, 无需测试的CI / CD部署过程。首先, 你应该将CircleCI与你的存储库集成-你可以在此处找到所有说明。然后, 我们应该创建一个带有CircleCI系统说明的配置文件。配置看起来很简单。要点是, GitHub存储库中有两个分支：master和production。

master分支用于开发, 用于新代码。当有人将新代码推送到master分支时, CircleCI启动master分支的工作流程-构建和测试代码。
生产分支用于将新版本部署到生产环境。生产分支的工作流程如下：将新代码(甚至更好的是, 从主分支推送PR到生产)以触发新的构建和部署过程；在构建期间, CircleCI创建新的Docker映像, 将其推送到GCR并为部署创建新的部署；如果推出失败, CircleCI将触发回退过程。

在运行任何构建之前, 你应该在CircleCI中配置项目。在API和GCloud中的服务页面上创建具有以下角色的新服务帐户：完全访问GCR和GKE, 打开下载的JSON文件并复制内容, 然后在CircleCI的项目设置中使用名称创建新的环境变量GCLOUD_SERVICE_KEY并将服务帐户文件的内容粘贴为一个值。另外, 你需要创建下一个环境变量：GOOGLE_PROJECT_ID(你可以在GCloud控制台主页上找到它), GOOGLE_COMPUTE_ZONE(你的GKE群集的区域)和GOOGLE_CLUSTER_NAME(GKE群集名称)。
CircleCI的最后一步(部署)如下所示：

kubectl patch deployment sample -p '{"spec":{"template":{"spec":{"containers":[{"name":"sample", "image":"gcr.io/test-d6bf8/simple:'"$CIRCLE_SHA1"'"}]}}}}' if ! kubectl rollout status deploy/sample; then echo "DEPLOY FAILED, ROLLING BACK TO PREVIOUS" kubectl rollout undo deploy/sample # Deploy failed -> notify slack else echo "Deploy succeeded, current version: ${CIRCLE_SHA1}" # Deploy succeeded -> notify slack fi deployment.extensions/sample patched Waiting for deployment "sample" rollout to finish: 2 out of 3 new replicas have been updated... Waiting for deployment "sample" rollout to finish: 2 out of 3 new replicas have been updated... Waiting for deployment "sample" rollout to finish: 2 out of 3 new replicas have been updated... Waiting for deployment "sample" rollout to finish: 1 old replicas are pending termination... Waiting for deployment "sample" rollout to finish: 1 old replicas are pending termination... Waiting for deployment "sample" rollout to finish: 1 old replicas are pending termination... Waiting for deployment "sample" rollout to finish: 2 of 3 updated replicas are available... Waiting for deployment "sample" rollout to finish: 2 of 3 updated replicas are available... deployment "sample" successfully rolled out Deploy succeeded, current version: 512eabb11c463c5431a1af4ed0b9ebd23597edd9

总结
看起来创建新Kubernetes集群的过程并不难！ CI / CD的过程真的很棒！
是! Kubernetes很棒！使用Kubernetes, 你的系统将变得更加稳定, 易于管理, 并使你成为系统的队长。更不用说, Kubernetes对系统进行一点游戏化, 并且可以为你的营销提供+100积分！
现在你已掌握了基础知识, 可以继续进行操作, 并将其转变为更高级的配置。我计划在以后的文章中介绍更多内容, 但与此同时, 这是一个挑战：为你的应用程序创建一个健壮的Kubernetes集群, 并在集群中放置一个有状态的DB(包括用于进行备份的Sidecar Pod), 在其中安装Jenkins。相同的Kubernetes集群用于CI / CD管道, 并让Jenkins使用Pod作为构建的奴隶。使用certmanager为你的入口添加/获取SSL证书。使用Stackdriver为你的应用程序创建监视和警报系统。
Kubernetes之所以出色, 是因为它易于扩展, 没有厂商锁定, 而且由于你是为实例付费, 因此可以节省资金。但是, 并不是每个人都是Kubernetes专家, 还是不是有时间建立新的集群-从另一个角度来看, srcminier的Amin Shah Gilani提出了使用Heroku, GitLab CI和他已经弄清楚的大量自动化的理由。为了在” 如何建立有效的初始部署管道” 中编写更多代码并减少操作量。
相关：数学：使用Orchestrators自动扩展微服务应用程序