标签 Kubernetes 下的文章

大规模容器应用编排起步

通过《面向 Java 开发者的 Kubernetes》,学习基本的 Kubernetes 概念和自动部署、维护和扩展你的 Java 应用程序的机制。下载该电子书的免费副本

在 《Java 的容器化持续交付》 中,我们探索了在 Docker 容器内打包和部署 Java 应用程序的基本原理。这只是创建基于容器的生产级系统的第一步。在真实的环境中运行容器还需要一个容器编排和计划的平台,并且,现在已经存在了很多个这样的平台(如,Docker Swarm、Apach Mesos、AWS ECS),而最受欢迎的是 Kubernetes。Kubernetes 被用于很多组织的产品中,并且,它现在由原生云计算基金会(CNCF)所管理。在这篇文章中,我们将使用以前的一个简单的基于 Java 的电子商务商店,我们将它打包进 Docker 容器内,并且在 Kubernetes 上运行它。

“Docker Java Shopfront” 应用程序

我们将打包进容器,并且部署在 Kubernetes 上的 “Docker Java Shopfront” 应用程序的架构,如下面的图所示:

在我们开始去创建一个所需的 Kubernetes 部署配置文件之前,让我们先学习一下关于容器编排平台中的一些核心概念。

Kubernetes 101

Kubernetes 是一个最初由谷歌开发的开源的部署容器化应用程序的 编排器 orchestrator 。谷歌已经运行容器化应用程序很多年了,并且,由此产生了 Borg 容器编排器,它是应用于谷歌内部的,是 Kubernetes 创意的来源。如果你对这个技术不熟悉,一些出现的许多核心概念刚开始你会不理解,但是,实际上它们都很强大。首先, Kubernetes 采用了不可变的基础设施的原则。部署到容器中的内容(比如应用程序)是不可变的,不能通过登录到容器中做成改变。而是要以部署新的版本替代。第二,Kubernetes 内的任何东西都是 声明式 declaratively 配置。开发者或运维指定系统状态是通过部署描述符和配置文件进行的,并且,Kubernetes 是可以响应这些变化的——你不需要去提供命令,一步一步去进行。

不可变基础设施和声明式配置的这些原则有许多好处:它容易防止配置 偏移 drift ,或者 “ 雪花 snowflake ” 应用程序实例;声明部署配置可以保存在版本控制中,与代码在一起;并且, Kubernetes 大部分都可以自我修复,比如,如果系统经历失败,假如是一个底层的计算节点失败,系统可以重新构建,并且根据在声明配置中指定的状态去重新均衡应用程序。

Kubernetes 提供几个抽象概念和 API,使之可以更容易地去构建这些分布式的应用程序,比如,如下的这些基于微服务架构的:

  • 豆荚 Pod —— 这是 Kubernetes 中的最小部署单元,并且,它本质上是一组容器。 豆荚 Pod 可以让一个微服务应用程序容器与其它“挎斗” 容器,像日志、监视或通讯管理这样的系统服务一起被分组。在一个豆荚中的容器共享同一个文件系统和网络命名空间。注意,一个单个的容器也是可以被部署的,但是,通常的做法是部署在一个豆荚中。
  • 服务 —— Kubernetes 服务提供负载均衡、命名和发现,以将一个微服务与其它隔离。服务是通过复制控制器支持的,它反过来又负责维护在系统内运行期望数量的豆荚实例的相关细节。服务、复制控制器和豆荚在 Kubernetes 中通过使用“标签”连接到一起,并通过它进行命名和选择。

现在让我们来为我们的基于 Java 的微服务应用程序创建一个服务。

构建 Java 应用程序和容器镜像

在我们开始创建一个容器和相关的 Kubernetes 部署配置之前,我们必须首先确认,我们已经安装了下列必需的组件:

  • 适用于 Mac / Windows / Linux 的 Docker - 这允许你在本地机器上,在 Kubernetes 之外去构建、运行和测试 Docker 容器。
  • Minikube - 这是一个工具,它可以通过虚拟机,在你本地部署的机器上很容易地去运行一个单节点的 Kubernetes 测试集群。
  • 一个 GitHub 帐户和本地安装的 Git - 示例代码保存在 GitHub 上,并且通过使用本地的 Git,你可以复刻该仓库,并且去提交改变到该应用程序的你自己的副本中。
  • Docker Hub 帐户 - 如果你想跟着这篇教程进行,你将需要一个 Docker Hub 帐户,以便推送和保存你将在后面创建的容器镜像的拷贝。
  • Java 8 (或 9) SDK 和 Maven - 我们将使用 Maven 和附属的工具使用 Java 8 特性去构建代码。

从 GitHub 克隆项目库代码(可选,你可以 复刻 fork 这个库,并且克隆一个你个人的拷贝),找到 “shopfront” 微服务应用: https://github.com/danielbryantuk/oreilly-docker-java-shopping/

$ git clone [email protected]:danielbryantuk/oreilly-docker-java-shopping.git
$ cd oreilly-docker-java-shopping/shopfront

请加载 shopfront 代码到你选择的编辑器中,比如,IntelliJ IDE 或 Eclipse,并去研究它。让我们使用 Maven 来构建应用程序。最终生成包含该应用的可运行的 JAR 文件位于 ./target 的目录中。

$ mvn clean install
…
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 17.210 s
[INFO] Finished at: 2017-09-30T11:28:37+01:00
[INFO] Final Memory: 41M/328M
[INFO] ------------------------------------------------------------------------

现在,我们将构建 Docker 容器镜像。一个容器镜像的操作系统选择、配置和构建步骤,一般情况下是通过一个 Dockerfile 指定的。我们看一下,我们的示例中位于 shopfront 目录中的 Dockerfile:

FROM openjdk:8-jre
ADD target/shopfront-0.0.1-SNAPSHOT.jar app.jar
EXPOSE 8010
ENTRYPOINT ["java","-Djava.security.egd=file:/dev/./urandom","-jar","/app.jar"]

第一行指定了,我们的容器镜像将被 “ from ” 这个 openjdk:8-jre 基础镜像中创建。openjdk:8-jre 镜像是由 OpenJDK 团队维护的,并且包含了我们在 Docker 容器(就像一个安装和配置了 OpenJDK 8 JDK的操作系统)中运行 Java 8 应用程序所需要的一切东西。第二行是,将我们上面构建的可运行的 JAR “ 添加 add ” 到这个镜像。第三行指定了端口号是 8010,我们的应用程序将在这个端口号上监听,如果外部需要可以访问,必须要 “ 暴露 exposed ” 它,第四行指定 “ 入口 entrypoint ” ,即当容器初始化后去运行的命令。现在,我们来构建我们的容器:

$ docker build -t danielbryantuk/djshopfront:1.0 .
Successfully built 87b8c5aa5260
Successfully tagged danielbryantuk/djshopfront:1.0

现在,我们推送它到 Docker Hub。如果你没有通过命令行登入到 Docker Hub,现在去登入,输入你的用户名和密码:

$ docker login
Login with your Docker ID to push and pull images from Docker Hub. If you don't have a Docker ID, head over to https://hub.docker.com to create one.
Username:
Password:
Login Succeeded
$
$ docker push danielbryantuk/djshopfront:1.0
The push refers to a repository [docker.io/danielbryantuk/djshopfront]
9b19f75e8748: Pushed 
...
cf4ecb492384: Pushed 
1.0: digest: sha256:8a6b459b0210409e67bee29d25bb512344045bd84a262ede80777edfcff3d9a0 size: 2210

部署到 Kubernetes 上

现在,让我们在 Kubernetes 中运行这个容器。首先,切换到项目根目录的 kubernetes 目录:

$ cd ../kubernetes

打开 Kubernetes 部署文件 shopfront-service.yaml,并查看内容:

---
apiVersion: v1
kind: Service
metadata:
  name: shopfront
  labels:
    app: shopfront
spec:
  type: NodePort
  selector:
    app: shopfront
  ports:
  - protocol: TCP
    port: 8010
    name: http

---
apiVersion: v1
kind: ReplicationController
metadata:
  name: shopfront
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: shopfront
    spec:
      containers:
      - name: shopfront
        image: danielbryantuk/djshopfront:latest
        ports:
        - containerPort: 8010
        livenessProbe:
          httpGet:
            path: /health
            port: 8010
          initialDelaySeconds: 30
          timeoutSeconds: 1

这个 yaml 文件的第一节创建了一个名为 “shopfront” 的服务,它将到该服务(8010 端口)的 TCP 流量路由到标签为 “app: shopfront” 的豆荚中 。配置文件的第二节创建了一个 ReplicationController ,其通知 Kubernetes 去运行我们的 shopfront 容器的一个复制品(实例),它是我们标为 “app: shopfront” 的声明(spec)的一部分。我们也指定了暴露在我们的容器上的 8010 应用程序端口,并且声明了 “livenessProbe” (即健康检查),Kubernetes 可以用于去决定我们的容器应用程序是否正确运行并准备好接受流量。让我们来启动 minikube 并部署这个服务(注意,根据你部署的机器上的可用资源,你可能需要去修 minikube 中的指定使用的 CPU 和 内存 memory ):

$ minikube start --cpus 2 --memory 4096
Starting local Kubernetes v1.7.5 cluster...
Starting VM...
Getting VM IP address...
Moving files into cluster...
Setting up certs...
Connecting to cluster...
Setting up kubeconfig...
Starting cluster components...
Kubectl is now configured to use the cluster.
$ kubectl apply -f shopfront-service.yaml
service "shopfront" created
replicationcontroller "shopfront" created

你可以通过使用 kubectl get svc 命令查看 Kubernetes 中所有的服务。你也可以使用 kubectl get pods 命令去查看所有相关的豆荚(注意,你第一次执行 get pods 命令时,容器可能还没有创建完成,并被标记为未准备好):

$ kubectl get svc
NAME         CLUSTER-IP   EXTERNAL-IP   PORT(S)          AGE
kubernetes   10.0.0.1     <none>        443/TCP          18h
shopfront    10.0.0.216   <nodes>       8010:31208/TCP   12s
$ kubectl get pods
NAME              READY     STATUS              RESTARTS   AGE
shopfront-0w1js   0/1       ContainerCreating   0          18s
$ kubectl get pods
NAME              READY     STATUS    RESTARTS   AGE
shopfront-0w1js   1/1       Running   0          2m

我们现在已经成功地在 Kubernetes 中部署完成了我们的第一个服务。

是时候进行烟雾测试了

现在,让我们使用 curl 去看一下,我们是否可以从 shopfront 应用程序的健康检查端点中取得数据:

$ curl $(minikube service shopfront --url)/health
{"status":"UP"}

你可以从 curl 的结果中看到,应用的 health 端点是启用的,并且是运行中的,但是,在应用程序按我们预期那样运行之前,我们需要去部署剩下的微服务应用程序容器。

构建剩下的应用程序

现在,我们有一个容器已经运行,让我们来构建剩下的两个微服务应用程序和容器:

$ cd ..
$ cd productcatalogue/
$ mvn clean install
…
$ docker build -t danielbryantuk/djproductcatalogue:1.0 .
...
$ docker push danielbryantuk/djproductcatalogue:1.0
...
$ cd ..
$ cd stockmanager/
$ mvn clean install
...
$ docker build -t danielbryantuk/djstockmanager:1.0 .
...
$ docker push danielbryantuk/djstockmanager:1.0
...

这个时候, 我们已经构建了所有我们的微服务和相关的 Docker 镜像,也推送镜像到 Docker Hub 上。现在,我们去在 Kubernetes 中部署 productcataloguestockmanager 服务。

在 Kubernetes 中部署整个 Java 应用程序

与我们上面部署 shopfront 服务时类似的方式去处理它,我们现在可以在 Kubernetes 中部署剩下的两个微服务:

$ cd ..
$ cd kubernetes/
$ kubectl apply -f productcatalogue-service.yaml
service "productcatalogue" created
replicationcontroller "productcatalogue" created
$ kubectl apply -f stockmanager-service.yaml
service "stockmanager" created
replicationcontroller "stockmanager" created
$ kubectl get svc
NAME               CLUSTER-IP   EXTERNAL-IP   PORT(S)          AGE

kubernetes         10.0.0.1     <none>        443/TCP          19h
productcatalogue   10.0.0.37    <nodes>       8020:31803/TCP   42s
shopfront          10.0.0.216   <nodes>       8010:31208/TCP   13m
stockmanager       10.0.0.149   <nodes>       8030:30723/TCP   16s
$ kubectl get pods
NAME                     READY     STATUS    RESTARTS   AGE
productcatalogue-79qn4   1/1       Running   0          55s
shopfront-0w1js          1/1       Running   0          13m
stockmanager-lmgj9       1/1       Running   0          29s

取决于你执行 “kubectl get pods” 命令的速度,你或许会看到所有都处于不再运行状态的豆荚。在转到这篇文章的下一节之前,我们要等着这个命令展示出所有豆荚都运行起来(或许,这个时候应该来杯咖啡!)

查看完整的应用程序

在所有的微服务部署完成并且所有相关的豆荚都正常运行后,我们现在将去通过 shopfront 服务的 GUI 去访问我们完整的应用程序。我们可以通过执行 minikube 命令在默认浏览器中打开这个服务:

$ minikube service shopfront

如果一切正常,你将在浏览器中看到如下的页面:

结论

在这篇文章中,我们已经完成了由三个 Java Spring Boot 和 Dropwizard 微服务组成的应用程序,并且将它部署到 Kubernetes 上。未来,我们需要考虑的事还很多,比如,调试服务(或许是通过工具,像 TelepresenceSysdig),通过一个像 JenkinsSpinnaker 这样的可持续交付的过程去测试和部署,并且观察我们的系统运行。


本文是与 NGINX 协作创建的。 查看我们的编辑独立性声明.


作者简介:

Daniel Bryant 是一名独立技术顾问,他是 SpectoLabs 的 CTO。他目前关注于通过识别价值流、创建构建过程、和实施有效的测试策略,从而在组织内部实现持续交付。Daniel 擅长并关注于“DevOps”工具、云/容器平台和微服务实现。他也贡献了几个开源项目,并定期为 InfoQ、 O’Reilly、和 Voxxed 撰稿...


via: https://www.oreilly.com/ideas/how-to-manage-docker-containers-in-kubernetes-with-java

作者:Daniel Bryant 译者:qhwdw 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

开放容器计划(OCI)和原生云计算基金会(CNCF)的代表说,Kubernetes 和容器可以在降低程序员和系统管理成本的同时加速部署进程,从被忽视的 Kubernetes 特性(比如命令空间)开始,去利用 Kubernetes 和它的相关工具运行一个原生云架构。

Kubernetes 不止是一个云容器管理器。正如 Steve Pousty,他是 Red Hat 支持的 OpenShift 的首席开发者,在 Linux 基金会开源峰会上的讲演中解释的那样,Kubernetes 提供了一个 “使用容器进行原生云计算的通用操作平台”。

Pousty 的意思是什么?先让我们复习一下基础知识。

开源容器计划(OCI)和 原生云计算基金会 (CNCF)的执行董事 Chris Aniszczyk 的解释是,“原生云计算使用开源软件栈将应用程序部署为微服务,打包每一个部分到其容器中,并且动态地编排这些容器以优化资源使用”。Kubernetes 一直在关注着原生云计算的最新要素。这将最终将导致 IT 中很大的一部分发生转变,如从服务器到虚拟机,从 构建包 buildpack 到现在的 容器

会议主持人表示,数据中心的演变将节省相当可观的成本,部分原因是它需要更少的专职员工。例如,据 Aniszczyk 说,通过使用 Kubernetes,谷歌每 10000 台机器仅需要一个网站可靠性工程师(LCTT 译注:即 SRE)。

实际上,系统管理员可以利用新的 Kubernetes 相关的工具的优势,并了解那些被低估的功能。

构建一个原生云平台

Pousty 解释说,“对于 Red Hat 来说,Kubernetes 是云 Linux 的内核。它是每个人都可以构建于其上的基础设施”。

例如,假如你在一个容器镜像中有一个应用程序。你怎么知道它是安全的呢? Red Hat 和其它的公司使用 OpenSCAP,它是基于 安全内容自动化协议 Security Content Automation Protocol (SCAP)的,是使用标准化的方式表达和操作安全数据的一个规范。OpenSCAP 项目提供了一个开源的强化指南和配置基准。选择一个合适的安全策略,然后,使用 OpenSCAP 认可的安全工具去使某些由 Kubernetes 控制的容器中的程序遵守这些定制的安全标准。

Red Hat 将使用 原子扫描 Atomic Scan 来自动处理这个过程;它借助 OpenSCAP 提供者 provider 来扫描容器镜像中已知的安全漏洞和策略配置问题。原子扫描会以只读方式加载文件系统。这些通过扫描的容器,会在一个可写入的目录存放扫描器的输出。

Pousty 指出,这种方法有几个好处,主要是,“你可以扫描一个容器镜像而不用实际运行它”。因此,如果在容器中有糟糕的代码或有缺陷的安全策略,它不会影响到你的系统。

原子扫描比手动运行 OpenSCAP 快很多。 因为容器从启用到消毁可能就在几分钟或几小时内,原子扫描允许 Kubernetes 用户在(很快的)容器生命期间保持容器安全,而不是在更缓慢的系统管理时间跨度里进行。

关于工具

帮助系统管理员和 DevOps 管理大部分 Kubernetes 操作的另一个工具是 CRI-O。这是一个基于 OCI 实现的 Kubernetes 容器运行时接口。CRI-O 是一个守护进程, Kubernetes 可以用于运行存储在 Docker 仓库中的容器镜像,Dan Walsh 解释说,他是 Red Hat 的顾问工程师和 SELinux 项目领导者。它允许你直接从 Kubernetes 中启动容器镜像,而不用花费时间和 CPU 处理时间在 Docker 引擎 上启动。并且它的镜像格式是与容器无关的。

在 Kubernetes 中, kubelet 管理 pod(容器集群)。使用 CRI-O,Kubernetes 及其 kubelet 可以管理容器的整个生命周期。这个工具也不是和 Docker 镜像捆绑在一起的。你也可以使用新的 OCI 镜像格式CoreOS 的 rkt 容器镜像。

同时,这些工具正在成为一个 Kubernetes 栈:编排系统、容器运行时接口 (CRI)和 CRI-O。Kubernetes 首席工程师 Kelsey Hightower 说,“我们实际上不需要这么多的容器运行时——无论它是 Docker 还是 rkt。只需要给我们一个到内核的 API 就行”,这个结果是这些技术人员的承诺,是推动容器比以往更快发展的强大动力。

Kubernetes 也可以加速构建容器镜像。目前为止,有三种方法来构建容器。第一种方法是通过一个 Docker 或者 CoreOS 去构建容器。第二种方法是注入定制代码到一个预构建镜像中。最后一种方法是, 资产生成管道 Asset Generation Pipeline 使用容器去编译那些 资产 asset ,然后其被包含到使用 Docker 的 多阶段构建 Multi-Stage Build 所构建的随后镜像中。

现在,还有一个 Kubernetes 原生的方法:Red Hat 的 Buildah, 这是一个脚本化的 shell 工具 用于快速、高效地构建 OCI 兼容的镜像和容器。Buildah 降低了容器环境的学习曲线,简化了创建、构建和更新镜像的难度。Pousty 说。你可以使用它和 Kubernetes 一起基于应用程序的调用来自动创建和使用容器。Buildah 也更节省系统资源,因为它不需要容器运行时守护进程。

因此,比起真实地引导一个容器和在容器内按步骤操作,Pousty 说,“挂载该文件系统,就如同它是一个常规的文件系统一样做一些正常操作,并且在最后提交”。

这意味着你可以从一个仓库中拉取一个镜像,创建它所匹配的容器,并且优化它。然后,你可以使用 Kubernetes 中的 Buildah 在你需要时去创建一个新的运行镜像。最终结果是,他说,运行 Kubernetes 管理的容器化应用程序比以往速度更快,需要的资源更少。

你所不知道的 Kubernetes 拥有的特性

你不需要在其它地方寻找工具。Kubernetes 有几个被低估的特性。

根据谷歌云全球产品经理 Allan Naim 的说法,其中一个是 Kubernetes 命名空间。Naim 在开源峰会上谈及 “Kubernetes 最佳实践”,他说,“很少有人使用命名空间,这是一个失误。”

“命名空间是将一个单个的 Kubernetes 集群分成多个虚拟集群的方法”,Naim 说。例如,“你可以认为命名空间就是 姓氏 family name ”,因此,假如说 “Simth” 用来标识一个家族,如果有个成员 Steve Smith,他的名字就是 “Steve”,但是,家族范围之外的,它就是 “Steve Smith” 或称 “来自 Chicago 的 Steve Smith”。

严格来说,“命名空间是一个逻辑分区技术,它允许一个 Kubernetes 集群被多个用户、用户团队或者一个用户的多个不能混淆的应用程序所使用。Naim 解释说,“每个用户、用户团队、或者应用程序都可以存在于它的命名空间中,与集群中的其他用户是隔离的,并且可以像你是这个集群的唯一用户一样操作它。”

Practically 说,你可以使用命名空间去构建一个企业的多个业务/技术的实体进入 Kubernetes。例如,云架构可以通过映射产品、地点、团队和成本中心为命名空间,从而定义公司的命名空间策略。

Naim 建议的另外的方法是,去使用命名空间将软件开发 流程 pipeline 划分到分离的命名空间中,如测试、质量保证、 预演 staging 和成品等常见阶段。或者命名空间也可以用于管理单独的客户。例如,你可以为每个客户、客户项目、或者客户业务单元去创建一个单独的命名空间。它可以更容易地区分项目,避免重用相同名字的资源。

然而,Kubernetes 现在还没有提供一个跨命名空间访问的控制机制。因此,Naim 建议你不要使用这种方法去对外公开程序。还要注意的是,命名空间也不是一个管理的“万能药”。例如,你不能将命名空间嵌套在另一个命名空间中。另外,也没有跨命名空间的强制安全机制。

尽管如此,小心地使用命名空间,还是很有用的。

以人为中心的建议

从谈论较深奥的技术换到项目管理。Pousty 建议,在转移到原生云和微服务架构时,在你的团队中要有一个微服务操作人员。“如果你去做微服务,你的团队最终做的就是 Ops-y。并且,不去使用已经知道这种操作的人是愚蠢的行为”,他说。“你需要一个正确的团队核心能力。我不想开发人员重新打造运维的轮子”。

而是,将你的工作流彻底地改造成一个能够使用容器和云的过程,对此,Kubernetes 是很适用的。

使用 Kubernetes 的原生云计算:领导者的课程

  • 迅速扩大的原生云生态系统。寻找可以扩展你使用容器的方法的工具。
  • 探索鲜为人知的 Kubernetes 特性,如命名空间。它们可以改善你的组织和自动化程度。
  • 确保部署到容器的开发团队有一个 Ops 人员参与。否则,冲突将不可避免。

作者简介:

Steven J. Vaughan-Nichols, Vaughan-Nichols & Associates 的 CEO

Steven J. Vaughan-Nichols,即 sjvn,是一个技术方面的作家,从 CP/M-80 还是前沿技术、PC 操作系统、300bps 是非常快的因特网连接、WordStar 是最先进的文字处理程序的那个时候开始,一直从事于商业技术的写作,而且喜欢它。他的作品已经发布在了从高科技出版物(IEEE Computer、ACM Network、 Byte)到商业出版物(eWEEK、 InformationWeek、ZDNet),从大众科技(Computer Shopper、PC Magazine、PC World)再到主流出版商(Washington Post、San Francisco Chronicle、BusinessWeek) 等媒体之上。


via: https://insights.hpe.com/articles/how-to-implement-cloud-native-computing-with-kubernetes-1710.html

作者:Steven J. Vaughan-Nichols 译者:qhwdw 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

Google 开发的这个容器管理系统很快成为开源历史上最成功的案例之一。

Kubernetes 是一个在过去几年中快速蹿升起来的开源的容器管理系统。它被众多行业中最大的企业用于关键任务,已成为开源方面最成功的案例之一。这是怎么发生的?该如何解释 Kubernetes 的广泛应用呢?

Kubernetes 的背景:起源于 Google 的 Borg 系统

随着计算世界变得更加分布式、更加基于网络、以及更多的云计算,我们看到了大型的 独石 monolithic 应用慢慢地转化为多个敏捷微服务。这些微服务能让用户单独缩放应用程序的关键功能,以处理数百万客户。除此之外,我们还看到像 Docker 这样的容器等技术出现在企业中,为用户快速构建这些微服务创造了一致的、可移植的、便捷的方式。

随着 Docker 继续蓬勃发展,管理这些微服务器和容器成为最重要的要求。这时已经运行基于容器的基础设施已经多年的 Google 大胆地决定开源一个名为 Borg 的项目。Borg 系统是运行诸如 Google 搜索和 Gmail 这样的 Google 服务的关键。谷歌决定开源其基础设施为世界上任何一家公司创造了一种像顶尖公司一样运行其基础架构的方式。

最大的开源社区之一

在开源之后,Kubernetes 发现自己在与其他容器管理系统竞争,即 Docker Swarm 和 Apache Mesos。Kubernetes 近几个月来超过这些其他系统的原因之一得益于社区和系统背后的支持:它是最大的开源社区之一(GitHub 上超过 27,000 多个星标),有来自上千个组织(1,409 个贡献者)的贡献,并且被集中在一个大型、中立的开源基金会里,即原生云计算基金会(CNCF)。

CNCF 也是更大的 Linux 基金会的一部分,拥有一些顶级企业成员,其中包括微软、谷歌和亚马逊。此外,CNCF 的企业成员队伍持续增长,SAP 和 Oracle 在过去几个月内加入白金会员。这些加入 CNCF 的公司,其中 Kubernetes 项目是前沿和中心的,这证明了有多少企业投注于社区来实现云计算战略的一部分。

Kubernetes 外围的企业社区也在激增,供应商提供了带有更多的安全性、可管理性和支持的企业版。Red Hat、CoreOS 和 Platform 9 是少数几个使企业级 Kubernetes 成为战略前进的关键因素,并投入巨资以确保开源项目继续得到维护的公司。

混合云带来的好处

企业以这样一个飞速的方式采用 Kubernetes 的另一个原因是 Kubernetes 可以在任何云端工作。大多数企业在现有的内部数据中心和公共云之间共享资产,对混合云技术的需求至关重要。

Kubernetes 可以部署在公司先前存在的数据中心内、任意一个公共云环境、甚至可以作为服务运行。由于 Kubernetes 抽象了底层基础架构层,开发人员可以专注于构建应用程序,然后将它们部署到任何这些环境中。这有助于加速公司的 Kubernetes 采用,因为它可以在内部运行 Kubernetes,同时继续构建云战略。

现实世界的案例

Kubernetes 继续增长的另一个原因是,大型公司正在利用这项技术来解决业界最大的挑战。Capital One、Pearson Education 和 Ancestry.com 只是少数几家公布了 Kubernetes 使用案例的公司。

Pokemon Go 是最流行的宣传 Kubernetes 能力的使用案例。在它发布之前,人们都觉得在线多人游戏会相当的得到追捧。但当它一旦发布,就像火箭一样起飞,达到了预期流量的 50 倍。通过使用 Kubernetes 作为 Google Cloud 之上的基础设施层,Pokemon Go 可以大规模扩展以满足意想不到的需求。

最初作为来自 Google 的开源项目,背后有 Google 15 年的服务经验和来自 Borg 的继承- Kubernetes 现在是有许多企业成员的大型基金会(CNCF)的一部分。它继续受到欢迎,并被广泛应用于金融、大型多人在线游戏(如 Pokemon Go)以及教育公司和传统企业 IT 的关键任务中。考虑到所有,所有的迹象表明,Kubernetes 将继续更加流行,并仍然是开源中最大的成功案例之一。


作者简介:

Anurag Gupta - Anurag Gupta 是推动统一日志层 Fluentd Enterprise 发展的 Treasure Data 的产品经理。 Anurag 致力于大型数据技术,包括 Azure Log Analytics 和如 Microsoft System Center 的企业 IT 服务。


via: https://opensource.com/article/17/10/why-kubernetes-so-popular

作者:Anurag Gupta 译者:geekpi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

去年,Kubernetes 项目推出了 容器运行时接口 Container Runtime Interface (CRI):这是一个插件接口,它让 kubelet(用于创建 pod 和启动容器的集群节点代理)有使用不同的兼容 OCI 的容器运行时的能力,而不需要重新编译 Kubernetes。在这项工作的基础上,CRI-O 项目(原名 OCID)准备为 Kubernetes 提供轻量级的运行时。

那么这个真正的是什么意思?

CRI-O 允许你直接从 Kubernetes 运行容器,而不需要任何不必要的代码或工具。只要容器符合 OCI 标准,CRI-O 就可以运行它,去除外来的工具,并让容器做其擅长的事情:加速你的新一代原生云程序。

在引入 CRI 之前,Kubernetes 通过“一个内部的易失性接口”与特定的容器运行时相关联。这导致了上游 Kubernetes 社区以及在编排平台之上构建解决方案的供应商的大量维护开销。

使用 CRI,Kubernetes 可以与容器运行时无关。容器运行时的提供者不需要实现 Kubernetes 已经提供的功能。这是社区的胜利,因为它让项目独立进行,同时仍然可以共同工作。

在大多数情况下,我们不认为 Kubernetes 的用户(或 Kubernetes 的发行版,如 OpenShift)真的关心容器运行时。他们希望它工作,但他们不希望考虑太多。就像你(通常)不关心机器上是否有 GNU Bash、Korn、Zsh 或其它符合 POSIX 标准 shell。你只是要一个标准的方式来运行你的脚本或程序而已。

CRI-O:Kubernetes 的轻量级容器运行时

这就是 CRI-O 提供的。该名称来自 CRI 和开放容器计划(OCI),因为 CRI-O 严格关注兼容 OCI 的运行时和容器镜像。

现在,CRI-O 支持 runc 和 Clear Container 运行时,尽管它应该支持任何遵循 OCI 的运行时。它可以从任何容器仓库中拉取镜像,并使用 容器网络接口 Container Network Interface (CNI)处理网络,以便任何兼容 CNI 的网络插件可与该项目一起使用。

当 Kubernetes 需要运行容器时,它会与 CRI-O 进行通信,CRI-O 守护程序与 runc(或另一个符合 OCI 标准的运行时)一起启动容器。当 Kubernetes 需要停止容器时,CRI-O 会来处理。这没什么令人兴奋的,它只是在幕后管理 Linux 容器,以便用户不需要担心这个关键的容器编排。

 title=

CRI-O 不是什么

值得花一点时间了解下 CRI-O 不是什么。CRI-O 的范围是与 Kubernetes 一起工作来管理和运行 OCI 容器。这不是一个面向开发人员的工具,尽管该项目确实有一些面向用户的工具进行故障排除。

例如,构建镜像超出了 CRI-O 的范围,这些留给像 Docker 的构建命令、 BuildahOpenShift 的 Source-to-Image(S2I)这样的工具。一旦构建完镜像,CRI-O 将乐意运行它,但构建镜像留给其他工具。

虽然 CRI-O 包含命令行界面 (CLI),但它主要用于测试 CRI-O,而不是真正用于在生产环境中管理容器的方法。

下一步

现在 CRI-O 1.0 发布了,我们希望看到它作为一个稳定功能在下一个 Kubernetes 版本中发布。1.0 版本将与 Kubernetes 1.7.x 系列一起使用,即将发布的 CRI-O 1.8-rc1 适合 Kubernetes 1.8.x。

我们邀请您加入我们,以促进开源 CRI-O 项目的开发,并感谢我们目前的贡献者为达成这一里程碑而提供的帮助。如果你想贡献或者关注开发,就去 CRI-O 项目的 GitHub 仓库,然后关注 CRI-O 博客


via: https://www.redhat.com/en/blog/introducing-cri-o-10

作者:Joe Brockmeier 译者:geekpi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

在开发和部署云原生应用程序时,运行容器化负载的 Kubernetes 平台起到了重大作用。

自然而然的,开发和部署云原生应用程序已经变得非常受欢迎。对于一个允许快速部署和连续交付的 bug 修复和新功能的流程来说,它有明显的优势,但是没有人会谈到鸡和鸡蛋问题:怎样才能达成这样的目的呢?从头开始构建基础设施和开发流程来开发和维护云原生应用程序是个不简单的、耗时的任务。

Kubernetes 是一个相对较新的运行容器化负载的平台,它解决了这些问题。它原本是 Google 内部的一个项目,Kubernetes 在 2015 年被捐赠给了云原生计算基金会,并吸引了来自世界各地开源社区的开发人员。 Kubernetes 的设计基于 Google 15 年的在生产和开发环境运维的经验。由于它是开源的,任何人都可以下载并使用它,并实现其带来的优势。

那么为什么 Kubernetes 会有这么大的惊喜呢?我认为它在像 OpenStack 这样的基础架构即服务(IaaS)和完整的平台即服务 (PaaS)的资源之间达到了最佳平衡,它的底层运行时实现完全由供应商控制。Kubernetes 提供了两个优势:对管理基础设施的抽象,以及深入裸机进行故障排除的工具和功能。

IaaS 与 PaaS

OpenStack 被大多数人归类为 IaaS 解决方案,其中物理资源池(如处理器、网络和存储)在不同用户之间分配和共享。它使用传统的基于硬件的虚拟化实现用户之间的隔离。

OpenStack 的 REST API 允许使用代码自动创建基础架构,但是这就是问题所在。IaaS 产品输出的也是基础设施。其创建后,支持和管理那些更多的基础设施的服务方式并不多。在一定程度上,OpenStack 生产的底层基础架构(如服务器和 IP 地址)成为管理工作的重中之重。一个众所周知的结果是虚拟机(VM)的无序蔓延,而同样的情况也出现于网络、加密密钥和存储卷方面。这样,开发人员建立和维护应用程序的时间就更少了。

像其它基于集群的解决方案一样,Kubernetes 以单个服务器级别的方式运行,以实现水平缩放。它可以轻松添加新的服务器,并立即在新硬件上安排负载。类似地,当服务器没有被有效利用或需要维护时,可以从集群中删除服务器。其它 Kubernetes 可以自动处理的其他任务是编排活动,如工作调度、健康监测和维护高可用性。

网络是另一个可能难以在 IaaS 环境中可靠编排的领域。微服务之间通过 IP 地址通信可能是很棘手的。Kubernetes 实现了 IP 地址管理、负载均衡、服务发现和 DNS 名称注册,以在集群内提供无痛、透明的网络环境。

专为部署而设计

一旦创建了运行应用程序的环境,部署就是一件小事了。可靠地部署一个应用程序是说起来容易做起来难的任务 —— 它并不是最简单的。Kubernetes 相对其他环境的巨大优势是,部署是一等公民。

使用一个单独的 Kubernetes 命令行界面(CLI)的命令,可以描述应用程序并将其安装在群集上。Kubernetes 从初始部署、推出新版本以及(当一个关键功能出现问题时)进行回滚,实现了应用程序的整个生命周期。运行中的部署也可以暂停和恢复。拥有现成的、内置的工具和支持应用程序部署,而不用自己构建部署系统,这是不容小觑的优点。Kubernetes 用户既不必重新发明应用程序部署的轮子,也不会发现这是一项艰巨的任务。

Kubernetes 还可以监控运行中的部署的状态。虽然你可以在 IaaS 环境中像编写部署过程一样编写这个功能,但这是一个非常困难的任务,而这样的情况还比比皆是。

专为 DevOps 而设计

随着你在开发和部署 Kubernetes 应用程序方面获得更多经验,你将沿着与 Google 和其他前行者相同的路径前行。你将发现有几种 Kubernetes 功能对于多服务应用程序的有效开发和故障排除是非常重要的。

首先,Kubernetes 能够通过日志或 SSH(安全 shell)轻松检查正在运行的服务的能力非常重要。通过一条命令行调用,管理员可以检查在 Kubernetes 下运行的服务的日志。这可能听起来像一个简单的任务,但在 IaaS 环境中,除非你已经做了一些工作,否则这并不容易。大型应用程序通常具有专门用于日志收集和分析的硬件和人员。在Kubernetes 中的日志可能不能替代完整功能的日志和指标解决方案,但它足以提供基本的故障排除。

第二,Kubernetes 提供内置的密钥管理。从头开发过自己的部署系统的团队知道的另一个问题是,将敏感数据(如密码和 API 令牌)安全地部署到虚拟机上很困难。通过将密钥管理变成一等公民,Kubernetes 可以避免你的团队发明自己的不安全的、错误的密钥分发系统或在部署脚本中硬编码凭据。

最后,Kubernetes 有一些用于自动进行缩放、负载均衡和重新启动应用程序的功能。同样,这些功能是开发人员在使用 IaaS 或裸机时要自己编写的。你的 Kubernetes 应用程序的缩放和运行状况检查在服务定义中进行声明,而 Kubernetes 会确保正确数量的实例健康运行。

总结

IaaS 和 PaaS 系统之间的差异是巨大的,包括 PaaS 可以节省大量的开发和调试时间。作为一种 PaaS,Kubernetes 实现了强大而有效的功能,可帮助你开发、部署和调试云原生应用程序。它的架构和设计代表了数十年的难得的经验,而你的团队能够免费获得该优势。

(题图:squarespace.com)


作者简介:

Tim Potter - Tim 是 Hewlett Packard Enterprise 的高级软件工程师。近二十年来,他一直致力于自由和开源软件的开发工作,其中包括 Samba、Wireshark、OpenPegasus 和 Docker 等多个项目。Tim 博客在 https://elegantinfrastructure.com/ ,关于 Docker、Kubernetes 和其他基础设施相关主题。


via: https://opensource.com/article/17/6/introducing-kubernetes

作者:Tim Potter 译者:geekpi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

作为一名开发者,我会尝试留意那些我可能不会每天使用的技术的进步。了解这些技术至关重要,因为它们可能会间接影响到我的工作。比如由 Docker 推动的、近期正在兴起的容器化技术,可用于上规模地托管 Web 应用。从技术层面来讲,我并不是一个 DevOps,但当我每天构建 Web 应用时,多去留意这些技术如何去发展,会对我有所裨益。

这种进步的一个绝佳的例子,是近一段时间高速发展的容器编排平台。它允许你轻松地部署、管理容器化应用,并对它们的规模进行调整。目前看来,容器编排的流行工具有 Kubernetes (来自 Google)Docker SwarmApache Mesos。如果你想较好的了解上面那些技术以及它们的区别,我推荐你看一下这篇文章

在这篇文章中,我们将会从一些简单的操作开始,了解一下 Kubernetes 平台,看看如何将一个 WordPress 网站部署在本地机器上的一个单节点集群中。

安装 Kubernetes

Kubernetes 文档中有一个很好的互动教程,涵盖了很多东西。但出于本文的目的,我只会介绍在 MacOS 中 Kuberentes 的安装和使用。

我们要做的第一件事是在你的本地主机中安装 Kubernetes。我们将使用一个叫做 MiniKube 的工具,它专门用于在你的机器上方便地设置一个用于测试的 Kubernetes 集群。

根据 Minikube 文档,在我们开始之前,有一些先决条件。首先要保证你已经安装了一个 Hypervisor (我将会使用 Virtualbox)。接下来,我们需要安装 Kubernetes 命令行工具(也就是 kubectl)。如果你在用 Homebrew,这一步非常简单,只需要运行命令:

$ brew install kubectl

现在我们可以真正 安装 Minikube 了:

$ curl -Lo minikube https://storage.googleapis.com/minikube/releases/v0.21.0/minikube-darwin-amd64 && chmod +x minikube && sudo mv minikube /usr/local/bin/

最后,我们要启动 Minicube 创建一个虚拟机,来作为我们的单节点 Kubernetes 集群。现在我要说一点:尽管我们在本文中只在本地运行它,但是在真正的服务器上运行 Kubernetes 集群时,后面提到的大多数概念都会适用。在多节点集群上,“主节点”将负责管理其它工作节点(虚拟机或物理服务器),并且 Kubernetes 将会在集群中自动进行容器的分发和调度。

$ minikube start --vm-driver=virtualbox

安装 Helm

现在,本机中应该有一个正在运行的(单节点)Kubernetes 集群了。我们现在可以用任何方式来与 Kubernetes 交互。如果你想现在可以体验一下,我觉得 kubernetesbyexample.com 可以很好地向你介绍 Kubernetes 的概念和术语。

虽然我们可以手动配置这些东西,但实际上我们将会使用另外的工具,来将我们的 WordPress 应用部署到 Kubernetes 集群中。Helm 被称为“Kubernetes 的包管理工具”,它可以让你轻松地在你的集群中部署预构建的软件包,也就是“ 图表 chart ”。你可以把图表看做一组专为特定应用(如 WordPress)而设计的容器定义和配置。首先我们在本地主机上安装 Helm:

$ brew install kubernetes-helm

然后我们需要在集群中安装 Helm。 幸运的是,只需要运行下面的命令就好:

$ helm init

安装 WordPress

现在 Helm 已经在我们的集群中运行了,我们可以安装 WordPress 图表。运行:

$ helm install --namespace wordpress --name wordpress --set serviceType=NodePort stable/wordpress  

这条命令将会在容器中安装并运行 WordPress,并在容器中运行 MariaDB 作为数据库。它在 Kubernetes 中被称为“Pod”。一个 Pod 基本上可视为一个或多个应用程序容器和这些容器的一些共享资源(例如存储卷,网络等)的组合的抽象。

我们需要给这个部署一个名字和一个命名空间,以将它们组织起来并便于查找。我们同样会将 serviceType 设置为 NodePort 。这一步非常重要,因为在默认设置中,服务类型会被设置为 LoadBalancer。由于我们的集群现在没有负载均衡器,所以我们将无法在集群外访问我们的 WordPress 站点。

在输出数据的最后一部分,你会注意到一些关于访问你的 WordPress 站点的有用的命令。运行那些命令,你可以获取到我们的 WordPress 站点的外部 IP 地址和端口:

$ export NODE_PORT=$(kubectl get --namespace wordpress -o jsonpath="{.spec.ports[0].nodePort}" services wordpress-wordpress)
$ export NODE_IP=$(kubectl get nodes --namespace wordpress -o jsonpath="{.items[0].status.addresses[0].address}")
$ echo http://$NODE_IP:$NODE_PORT/admin

你现在访问刚刚生成的 URL(忽略 /admin 部分),就可以看到 WordPress 已经在你的 Kubernetes 集群中运行了!

扩展 WordPress

Kubernetes 等服务编排平台的一个伟大之处,在于它将应用的扩展和管理变得易如反掌。我们看一下应用的部署状态:

$ kubectl get deployments --namespace=wordpress

kubectl get deployments

可以看到,我们有两个部署,一个是 Mariadb 数据库,一个是 WordPress 本身。现在,我们假设你的 WordPress 开始承载大量的流量,所以我们想将这些负载分摊在多个实例上。我们可以通过一个简单的命令来扩展 wordpress-wordpress 部署:

$ kubectl scale --replicas 2 deployments wordpress-wordpress --namespace=wordpress

再次运行 kubectl get deployments,我们现在应该会看到下面的场景:

kubectl get deployments

你刚刚扩大了你的 WordPress 站点规模!超级简单,对不对?现在我们有了多个 WordPress 容器,可以在它们之中对流量进行负载均衡。想了解 Kubernetes 扩展的更多信息,参见这篇指南

高可用

Kubernetes 等平台的的另一大特色在于,它不单单能进行方便的扩展,还可以通过自愈组件来提供高可用性。假设我们的一个 WordPress 部署因为某些原因失效了,那 Kubernetes 会立刻自动替换掉这个部署。我们可以通过删除我们 WordPress 部署的一个 pod 来模拟这个过程。

首先运行命令,获取 pod 列表:

$ kubectl get pods --namespace=wordpress

kubectl get pods

然后删除其中一个 pod:

$ kubectl delete pod wordpress-wordpress-876183909-jqc8s --namespace=wordpress

如果你再次运行 kubectl get pods 命令,应该会看到 Kubernetes 立刻换上了新的 pod (3l167)。

kubectl get pods

更进一步

我们只是简单了解了 Kubernetes 能完成工作的表面。如果你想深入研究,我建议你查看以下功能:

你在容器平台上运行过 WordPress 吗?有没有使用过 Kubernetes(或其它容器编排平台),有没有什么好的技巧?你通常会怎么扩展你的 WordPress 站点?请在评论中告诉我们。


作者简介:

Gilbert 喜欢构建软件。从 jQuery 脚本到 WordPress 插件,再到完整的 SaaS 应用程序,Gilbert 一直在创造优雅的软件。 他粗昂做的最有名的的产品,应该是 Nivo Slider.


via: https://deliciousbrains.com/running-wordpress-kubernetes-cluster/

作者:Gilbert Pellegrom 译者:StdioA 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出