标签 Kubernetes 下的文章

Kubernetes 是一款生产级的开源系统,用于容器化应用程序的自动部署、扩展和管理。本文关于使用 Kubernetes 来管理容器。

“容器”已成为最新的流行语之一。但是,这个词到底意味着什么呢?说起“容器”,人们通常会把它和 Docker 联系起来,Docker 是一个被定义为软件的标准化单元容器。该容器将软件和运行软件所需的环境封装到一个易于交付的单元中。

容器是一个软件的标准单元,用它来打包代码及其所有依赖项,这样应用程序就可以从一个计算环境到另一个计算环境快速可靠地运行。容器通过创建类似于 ISO 镜像的方式来实现此目的。容器镜像是一个轻量级的、独立的、可执行的软件包,其中包含运行应用程序所需的所有信息,包括代码、运行时、系统工具、系统库和设置。

容器镜像在运行时变成容器,对于 Docker 容器,镜像在 Docker 引擎上运行时变成容器。容器将软件与环境隔离开来,确保不同环境下的实例,都可以正常运行。

什么是容器管理?

容器管理是组织、添加或替换大量软件容器的过程。容器管理使用软件来自动化创建、部署和扩展容器。这一过程就需要容器编排,容器编排是一个自动对基于容器的应用程序进行部署、管理、扩展、联网和提供可用性的工具。

Kubernetes

Kubernetes 是一个可移植的、可扩展的开源平台,用于管理容器化的工作负载和服务,它有助于配置和自动化。它最初由 Google 开发,拥有一个庞大且快速增长的生态系统。Kubernetes 的服务、技术支持和工具得到广泛应用。

Google 在 2014 年开源了 Kubernetes 项目。Kubernetes 建立在 Google 十五年大规模运行生产工作负载的经验基础上,并结合了社区中最好的想法和实践以及声明式句法的使用。

下面列出了与Kubernetes生态系统相关的一些常用术语。

Pod:Pod 是 Kubernetes 应用程序的基本执行单元,是你创建或部署的 Kubernetes 对象模型中的最小和最简单的单元。Pod 代表在 Kubernetes 集群上运行的进程。

Pod 将运行中的容器、存储、网络 IP(唯一)和控制容器应如何运行的命令封装起来。它代表 Kubernetes 生态系统内的单个部署单元,代表一个应用程序的单个实例,该程序可能包含一个或多个紧密耦合并共享资源的容器。

Kubernetes 集群中的 Pod 有两种主要的使用方式。第一种是运行单个容器。即“一个容器一个 Pod”,这种方式是最常见的。第二种是运行多个需要一起工作的容器。

Pod 可能封装一个由紧密关联且需要共享资源的多个同位容器组成的应用程序。

副本集 ReplicaSet :副本集的目的是维护在任何给定时间运行的一组稳定的副本容器集。 副本集包含有关一个特定 Pod 应该运行多少个副本的信息。为了创建多个 Pod 以匹配副本集条件,Kubernetes 使用 Pod 模板。副本集与其 Pod 的链接是通过后者的 metas.ownerReferences 字段实现,该字段指定哪个资源拥有当前对象。

服务 Services :服务是一种抽象,用来公开一组 Pod 功能。使用 Kubernetes,你无需修改应用程序即可使用陌生服务发现机制。Kubernetes 给 Pod 提供了其自己的 IP 地址和一组 Pod 的单个 DNS 名称,并且可以在它们之间负载平衡。

服务解决的一个主要问题是 Web 应用程序前端和后端的集成。由于 Kubernetes 将幕后的 IP 地址提供给 Pod,因此当 Pod 被杀死并复活时,IP 地址会更改。这给给定的后端 IP 地址连接到相应的前端 IP 地址带来一个大问题。服务通过在 Pod 上提供抽象来解决此问题,类似于负载均衡器。

Volumes : Kubernetes 卷具有明确的生命周期,与围绕它的 Pod 相同。 因此,卷超过了 Pod 中运行的任何容器的寿命,并且在容器重新启动后保留了数据。当然,当 Pod 不存在时,该卷也将不再存在。也许比这更重要的是 Kubernetes 支持多种类型的卷,并且 Pod 可以同时使用任意数量的卷。

卷的核心只是一个目录,其中可能包含一些数据,Pod 中的容器可以访问该目录。该目录是如何产生的,它后端基于什么存储介质,其中的数据内容是什么,这些都由使用的特定卷类型来决定的。

为什么选择 Kubernetes?

容器是捆绑和运行应用程序的好方法。在生产环境中,你需要管理运行应用程序的容器,并确保没有停机时间。例如,如果一个容器发生故障,则需要启动另一个容器。如果由系统自动实现这一操作,岂不是更好? Kubernetes 就是来解决这个问题的!Kubernetes 提供了一个框架来弹性运行分布式系统。该框架负责扩展需求、故障转移、部署模式等。例如,Kubernetes 可以轻松管理系统的金丝雀部署。

Kubernetes 为用户提供了:

  1. 服务发现和负载平衡
  2. 存储编排
  3. 自动退出和回退
  4. 自动打包
  5. 自我修复
  6. 秘密配置管理

Kubernetes 可以做什么?

在本文中,我们将会看到一些从头构建 Web 应用程序时如何使用 Kubernetes 的代码示例。我们将在 Python 中使用 Flask 创建一个简单的后端服务器。

对于那些想从头开始构建 Web 应用程序的人,有一些前提条件,即:

  1. 对 Docker、Docker 容器和 Docker 镜像的基本了解。可以访问这里快速了解。
  2. 系统中应该安装 Docker。
  3. 系统中应该安装 Kubernetes,有关如何在本地计算机上安装的说明,请访问这里

现在,创建一个目录,如下代码片段所示:

mkdir flask-kubernetes/app && cd flask-kubernetes/app

接下来,在 flask-kubernetes/app 目录中,创建一个名为 main.py 的文件,如下面的代码片段所示:

touch main.py

在新创建的 main.py 文件中,粘贴下面代码:

from flask import Flask
app = Flask(__name__)
 
@app.route("/")
def hello():
    return "Hello from Kubernetes!"
 
if __name__ == "__main__":
    app.run(host='0.0.0.0')

使用下面命令在本地安装 Flask:

pip install Flask==0.10.1

Flask 安装后,执行下面的命令:

python app.py

应该在本地 5000 端口运行 Flask 服务器,这是 Flask 应用程序的默认端口,并且你可以在 http://localhost:5000 上看到输出 “Hello from Kubernetes!”。服务器在本地运行之后,我们创建一个供 Kubernetes 使用的 Docker 镜像。创建一个名为 Dockerfile 的文件,并将以下代码片段粘贴到其中:

FROM python:3.7
 
RUN mkdir /app
WORKDIR /app
ADD . /app/
RUN pip install -r requirements.txt
 
EXPOSE 5000
CMD ["python", "/app/main.py"]

Dockerfile 文件的说明如下:

  1. Docker 将从 DockerHub 获取 Python 3.7 镜像。
  2. 将在镜像中创建一个应用程序目录。
  3. 它将一个 /app 目录设置为工作目录。
  4. 将内容从主机中的应用程序目录复制到镜像应用程序目录。
  5. 发布端口 5000。
  6. 最后,它运行命令,启动 Flask 服务器。

接下来,我们将使用以下命令创建 Docker 镜像:

docker build -f Dockerfile -t flask-kubernetes:latest .

创建 Docker 镜像后,我们可以使用以下命令在本地运行该镜像进行测试:

docker run -p 5001:5000 flask-kubernetes

通过运行容器在本地完成测试之后,我们需要在 Kubernetes 中部署它。我们将首先使用 kubectl 命令验证 Kubernetes 是否正在运行。如果没有报错,则说明它正在工作。如果有报错,请参考该信息

接下来,我们创建一个部署文件。这是一个 Yaml 文件,其中包含有关 Kubernetes 的说明,该说明涉及如何以声明性的方式创建 Pod 和服务。因为我们有 Flask Web 应用程序,我们将创建一个 deployment.yaml 文件,并在其中包含 Pod 和服务声明。

创建一个名为 deployment.yaml 的文件并向其中添加以下内容,然后保存:

apiVersion: v1
kind: Service
metadata:
  name: flask-kubernetes -service
spec:
  selector:
    app: flask-kubernetes
  ports:
  - protocol: "TCP"
    port: 6000
    targetPort: 5000
  type: LoadBalancer

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: flask-kubernetes
spec:
  replicas: 4
  template:
    metadata:
      labels:
        app: flask-kubernetes
    spec:
      containers:
      - name: flask-kubernetes
        image: flask-kubernetes:latest
        imagePullPolicy: Never
        ports:
          - containerPort: 5000

使用以下命令将 yaml 文件发送到 Kubernetes:

kubectl apply -f deployment.yaml

如果执行以下命令,你会看到 Pod 正在运行:

kubectl get pods

现在,导航至 http://localhost:6000,你应该会看到 “Hello from Kubernetes!”消息。成功了! 该应用程序现在正在 Kubernetes 中运行!

Kubernetes 做不了什么?

Kubernetes 不是一个传统的,包罗万象的 PaaS(平台即服务)系统。 由于 Kubernetes 运行在容器级别而非硬件级别,因此它提供了 PaaS 产品共有的一些普遍适用功能,如部署、扩展、负载平衡、日志记录和监控。Kubernetes 为开发人员平台提供了构建块,但在重要的地方保留了用户的选择和灵活性。

  • Kubernetes 不限制所支持的应用程序的类型。如果应用程序可以在容器中运行,那么它应该可以在 Kubernetes 上更好地运行。
  • 它不部署和构建源代码。
  • 它不决定日志记录、监视或警报解决方案。
  • 它不提供或不要求配置语言/系统。它提供了一个声明式的 API 供所有人使用。
  • 它不提供或不采用任何全面的机器配置、维护、管理或自我修复系统。

via: https://opensourceforu.com/2019/11/demystifying-kubernetes/

作者:Abhinav Nath Gupta 选题:lujun9972 译者:Morisun029 校对:wxy

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

不仅可以部署简单的应用程序,还可以用 Kubernetes 运维器应对第 2 天运营。

在我的第一篇文章 为什么说 Kubernetes 是一辆翻斗车 中,我谈到了 Kubernetes 如何在定义、分享和运行应用程序方面很出色,类似于翻斗车在移动垃圾方面很出色。在第二篇中,如何跨越 Kubernetes 学习曲线,我解释了 Kubernetes 的学习曲线实际上与运行任何生产环境中的应用程序的学习曲线相同,这确实比学习所有传统组件要容易(如负载均衡器、路由器、防火墙、交换机、集群软件、集群文件系统等)。这是 DevOps,是开发人员和运维人员之间的合作,用于指定事物在生产环境中的运行方式,这意味着双方都需要学习。在第三篇 Kubernetes 基础:首先学习如何使用 中,我重新设计了 Kubernetes 的学习框架,重点是驾驶翻斗车而不是制造或装备翻斗车。在第四篇文章 帮助你驾驭 Kubernetes 的 4 个工具 中,我分享了我喜爱的工具,这些工具可帮助你在 Kubernetes 中构建应用程序(驾驶翻斗车)。

在这最后一篇文章中,我会分享我为什么对在 Kubernetes 上运行应用程序的未来如此兴奋的原因。

从一开始,Kubernetes 就能够很好地运行基于 Web 的工作负载(容器化的)。Web 服务器、Java 和相关的应用程序服务器(PHP、Python等)之类的工作负载都可以正常工作。该平台处理诸如 DNS、负载平衡和 SSH(由 kubectl exec 取代)之类的支持服务。在我的职业生涯的大部分时间里,这些都是我在生产环境中运行的工作负载,因此,我立即意识到,除了 DevOps 之外,除了敏捷之外,使用 Kubernetes 运行生产环境工作负载的强大功能。即使是我们几乎不改变我们的文化习惯,也可以提高效率。调试和退役变得非常容易,而这对于传统 IT 来说是极为困难的。因此,从早期开始,Kubernetes 就用一种单一的配置语言(Kube YAML/Json)为我提供了对生产环境工作负载进行建模所需的所有基本原语。

但是,如果你需要运行具有复制功能的多主 MySQL,会发生什么情况?使用 Galera 的冗余数据呢?你如何进行快照和备份?那么像 SAP 这样复杂的工作呢?使用 Kubernetes,简单的应用程序(Web 服务器等)的第 0 天(部署)相当简单,但是没有解决第 2 天的运营和工作负载。这并不是说,具有复杂工作负载的第 2 天运营要比传统 IT 难解决,而是使用 Kubernetes 并没有使它们变得更容易。每个用户都要设计自己的天才想法来解决这些问题,这基本上是当今的现状。在过去的五年中,我遇到的第一类问题是复杂工作负载的第 2 天操作。(LCTT 译注:在软件生命周期中,第 0 天是指软件的设计阶段;第 1 天是指软件的开发和部署阶段;第 2 天是指生产环境中的软件运维阶段。)

值得庆幸的是,随着 Kubernetes 运维器 Operator 的出现,这种情况正在改变。随着运维器的出现,我们现在有了一个框架,可以将第 2 天的运维知识汇总到平台中。现在,我们可以应用我在 Kubernetes 基础:首先学习如何使用 中描述的相同的定义状态、实际状态的方法,现在我们可以定义、自动化和维护各种各样的系统管理任务。

(LCTT 译注: Operator 是 Kubernetes 中的一种可以完成运维工程师的特定工作的组件,业界大多没有翻译这个名词,此处仿运维工程师例首倡翻译为“运维器”。)

我经常将运维器称为“系统管理机器人”,因为它们实质上是在第 2 天的工作中整理出一堆运维知识,该知识涉及 主题专家 Subject Matter Expert (SME、例如数据库管理员或系统管理员)针对的工作负载类型(数据库、Web 服务器等),通常会记录在 Wiki 中的某个地方。这些知识放在 Wiki 中的问题是,为了将该知识应用于解决问题,我们需要:

  1. 生成事件,通常监控系统会发现故障,然后我们创建故障单
  2. SME 人员必须对此问题进行调查,即使这是我们之前见过几百万次的问题
  3. SME 人员必须执行该知识(执行备份/还原、配置 Galera 或事务复制等)

通过运维器,所有这些 SME 知识都可以嵌入到单独的容器镜像中,该镜像在有实际工作负荷之前就已部署。 我们部署运维器容器,然后运维器部署和管理一个或多个工作负载实例。然后,我们使用“运维器生命周期管理器”(Katacoda 教程)之类的方法来管理运维器。

因此,随着我们进一步使用 Kubernetes,我们不仅简化了应用程序的部署,而且简化了整个生命周期的管理。运维器还为我们提供了工具,可以管理具有深层配置要求(群集、复制、修复、备份/还原)的非常复杂的有状态应用程序。而且,最好的地方是,构建容器的人员可能是做第 2 天运维的主题专家,因此现在他们可以将这些知识嵌入到操作环境中。

本系列的总结

Kubernetes 的未来是光明的,就像之前的虚拟化一样,工作负载的扩展是不可避免的。学习如何驾驭 Kubernetes 可能是开发人员或系统管理员可以对自己的职业发展做出的最大投资。随着工作负载的增多,职业机会也将增加。因此,这是驾驶一辆令人惊叹的 在移动垃圾时非常优雅的翻斗车……

你可能想在 Twitter 上关注我,我在 @fatherlinux 上分享有关此主题的很多内容。


via: https://opensource.com/article/19/6/kubernetes-potential-run-anything

作者:Scott McCarty 选题:lujun9972 译者:wxy 校对:wxy

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

Kubernetes 绝对是满足复杂 web 应用程序需求的最简单、最容易的方法。

 title=

在 90 年代末和 2000 年代初,在大型网站工作很有趣。我的经历让我想起了 American Greetings Interactive,在情人节那天,我们拥有了互联网上排名前 10 位之一的网站(以网络访问量衡量)。我们为 AmericanGreetings.comBlueMountain.com 等公司提供了电子贺卡,并为 MSN 和 AOL 等合作伙伴提供了电子贺卡。该组织的老员工仍然深切地记得与 Hallmark 等其它电子贺卡网站进行大战的史诗般的故事。顺便说一句,我还为 Holly Hobbie、Care Bears 和 Strawberry Shortcake 运营过大型网站。

我记得那就像是昨天发生的一样,这是我们第一次遇到真正的问题。通常,我们的前门(路由器、防火墙和负载均衡器)有大约 200Mbps 的流量进入。但是,突然之间,Multi Router Traffic Grapher(MRTG)图示突然在几分钟内飙升至 2Gbps。我疯了似地东奔西跑。我了解了我们的整个技术堆栈,从路由器、交换机、防火墙和负载平衡器,到 Linux/Apache web 服务器,到我们的 Python 堆栈(FastCGI 的元版本),以及网络文件系统(NFS)服务器。我知道所有配置文件在哪里,我可以访问所有管理界面,并且我是一位经验丰富的,打过硬仗的系统管理员,具有多年解决复杂问题的经验。

但是,我无法弄清楚发生了什么……

当你在一千个 Linux 服务器上疯狂地键入命令时,五分钟的感觉就像是永恒。我知道站点可能会在任何时候崩溃,因为当它被划分成更小的集群时,压垮上千个节点的集群是那么的容易。

我迅速跑到老板的办公桌前,解释了情况。他几乎没有从电子邮件中抬起头来,这使我感到沮丧。他抬头看了看,笑了笑,说道:“是的,市场营销可能会开展广告活动。有时会发生这种情况。”他告诉我在应用程序中设置一个特殊标志,以减轻 Akamai 的访问量。我跑回我的办公桌,在上千台 web 服务器上设置了标志,几分钟后,站点恢复正常。灾难也就被避免了。

我可以再分享 50 个类似的故事,但你脑海中可能会有一点好奇:“这种运维方式将走向何方?”

关键是,我们遇到了业务问题。当技术问题使你无法开展业务时,它们就变成了业务问题。换句话说,如果你的网站无法访问,你就不能处理客户交易。

那么,所有这些与 Kubernetes 有什么关系?一切!世界已经改变。早在 90 年代末和 00 年代初,只有大型网站才出现大型的、 规模级 web-scale 的问题。现在,有了微服务和数字化转型,每个企业都面临着一个大型的、规模级的问题——可能是多个大型的、规模级的问题。

你的企业需要能够通过许多不同的人构建的许多不同的、通常是复杂的服务来管理复杂的规模级的网站。你的网站需要动态地处理流量,并且它们必须是安全的。这些属性需要在所有层(从基础结构到应用程序层)上由 API 驱动。

进入 Kubernetes

Kubernetes 并不复杂;你的业务问题才复杂。当你想在生产环境中运行应用程序时,要满足性能(伸缩性、性能抖动等)和安全性要求,就需要最低程度的复杂性。诸如高可用性(HA)、容量要求(N+1、N+2、N+100)以及保证最终一致性的数据技术等就会成为必需。这些是每家进行数字化转型的公司的生产要求,而不仅仅是 Google、Facebook 和 Twitter 这样的大型网站。

在旧时代,我还在 American Greetings 任职时,每次我们加入一个新的服务,它看起来像这样:所有这些都是由网站运营团队来处理的,没有一个是通过订单系统转移给其他团队来处理的。这是在 DevOps 出现之前的 DevOps:

  1. 配置 DNS(通常是内部服务层和面向公众的外部)
  2. 配置负载均衡器(通常是内部服务和面向公众的)
  3. 配置对文件的共享访问(大型 NFS 服务器、群集文件系统等)
  4. 配置集群软件(数据库、服务层等)
  5. 配置 web 服务器群集(可以是 10 或 50 个服务器)

大多数配置是通过配置管理自动完成的,但是配置仍然很复杂,因为每个系统和服务都有不同的配置文件,而且格式完全不同。我们研究了像 Augeas 这样的工具来简化它,但是我们认为使用转换器来尝试和标准化一堆不同的配置文件是一种反模式。

如今,借助 Kubernetes,启动一项新服务本质上看起来如下:

  1. 配置 Kubernetes YAML/JSON。
  2. 提交给 Kubernetes API(kubectl create -f service.yaml)。

Kubernetes 大大简化了服务的启动和管理。服务所有者(无论是系统管理员、开发人员还是架构师)都可以创建 Kubernetes 格式的 YAML/JSON 文件。使用 Kubernetes,每个系统和每个用户都说相同的语言。所有用户都可以在同一 Git 存储库中提交这些文件,从而启用 GitOps。

而且,可以弃用和删除服务。从历史上看,删除 DNS 条目、负载平衡器条目和 Web 服务器的配置等是非常可怕的,因为你几乎肯定会破坏某些东西。使用 Kubernetes,所有内容都处于命名空间下,因此可以通过单个命令删除整个服务。尽管你仍然需要确保其它应用程序不使用它(微服务和函数即服务 [FaaS] 的缺点),但你可以更加确信:删除服务不会破坏基础架构环境。

构建、管理和使用 Kubernetes

太多的人专注于构建和管理 Kubernetes 而不是使用它(详见 Kubernetes 是一辆翻斗车)。

在单个节点上构建一个简单的 Kubernetes 环境并不比安装 LAMP 堆栈复杂得多,但是我们无休止地争论着构建与购买的问题。不是 Kubernetes 很难;它以高可用性大规模运行应用程序。建立一个复杂的、高可用性的 Kubernetes 集群很困难,因为要建立如此规模的任何集群都是很困难的。它需要规划和大量软件。建造一辆简单的翻斗车并不复杂,但是建造一辆可以运载 10 吨垃圾并能以 200 迈的速度稳定行驶的卡车则很复杂。

管理 Kubernetes 可能很复杂,因为管理大型的、规模级的集群可能很复杂。有时,管理此基础架构很有意义;而有时不是。由于 Kubernetes 是一个社区驱动的开源项目,它使行业能够以多种不同方式对其进行管理。供应商可以出售托管版本,而用户可以根据需要自行决定对其进行管理。(但是你应该质疑是否确实需要。)

使用 Kubernetes 是迄今为止运行大规模网站的最简单方法。Kubernetes 正在普及运行一组大型、复杂的 Web 服务的能力——就像当年 Linux 在 Web 1.0 中所做的那样。

由于时间和金钱是一个零和游戏,因此我建议将重点放在使用 Kubernetes 上。将你的时间和金钱花费在掌握 Kubernetes 原语或处理活跃度和就绪性探针的最佳方法上(表明大型、复杂的服务很难的另一个例子)。不要专注于构建和管理 Kubernetes。(在构建和管理上)许多供应商可以为你提供帮助。

结论

我记得对无数的问题进行了故障排除,比如我在这篇文章的开头所描述的问题——当时 Linux 内核中的 NFS、我们自产的 CFEngine、仅在某些 Web 服务器上出现的重定向问题等)。开发人员无法帮助我解决所有这些问题。实际上,除非开发人员具备高级系统管理员的技能,否则他们甚至不可能进入系统并作为第二双眼睛提供帮助。没有带有图形或“可观察性”的控制台——可观察性在我和其他系统管理员的大脑中。如今,有了 Kubernetes、Prometheus、Grafana 等,一切都改变了。

关键是:

  1. 时代不一样了。现在,所有 Web 应用程序都是大型的分布式系统。就像 AmericanGreetings.com 过去一样复杂,现在每个网站都有扩展性和 HA 的要求。
  2. 运行大型的分布式系统是很困难的。绝对是。这是业务的需求,不是 Kubernetes 的问题。使用更简单的编排系统并不是解决方案。

Kubernetes 绝对是满足复杂 Web 应用程序需求的最简单,最容易的方法。这是我们生活的时代,而 Kubernetes 擅长于此。你可以讨论是否应该自己构建或管理 Kubernetes。有很多供应商可以帮助你构建和管理它,但是很难否认这是大规模运行复杂 Web 应用程序的最简单方法。


via: https://opensource.com/article/19/10/kubernetes-complex-business-problem

作者:Scott McCarty 选题:lujun9972 译者:laingke 校对:wxy

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

开源社区和行业趋势的每周总览。

 title=

作为我在具有开源开发模型的企业软件公司担任高级产品营销经理的角色的一部分,我为产品营销人员、经理和其他影响者定期发布有关开源社区,市场和行业趋势的定期更新。以下是该更新中我和他们最喜欢的五篇文章。

OpenStack Train 中最令人兴奋的功能

考虑到 Train 版本必须提供的所有技术优势(你可以在此处查看版本亮点),你可能会对 Red Hat 认为这些将使我们的电信和企业客户受益的顶级功能及其用例感到好奇。以下我们对该版本最兴奋的功能的概述。

影响:OpenStack 对我来说就像 Shia LaBeouf:它在几年前达到了炒作的顶峰,然后继续产出了好的作品。Train 版本看起来是又一次令人难以置信的创新下降。

以 Ansible 原生的方式构建 Kubernetes 操作器

操作器简化了 Kubernetes 上复杂应用程序的管理。它们通常是用 Go 语言编写的,并且需要懂得 Kubernetes 内部的专业知识。但是,还有另一种进入门槛较低的选择。Ansible 是操作器 SDK 中的一等公民。使用 Ansible 可以释放应用程序工程师的精力,最大限度地利用时间来自动化和协调你的应用程序,并使用一种简单的语言在新的和现有的平台上进行操作。在这里我们可以看到如何做。

影响:这就像你发现可以用搅拌器和冷冻香蕉制作出不错的冰淇淋一样:Ansible(通常被认为很容易掌握)可以使你比你想象的更容易地做一些令人印象深刻的操作器魔术。

Kubernetes 网络:幕后花絮

尽管围绕该主题有很多很好的资源(链接在这里),但我找不到一个示例,可以将所有的点与网络工程师喜欢和讨厌的命令输出连接起来,以显示背后实际发生的情况。因此,我决定从许多不同的来源收集这些信息,以期帮助你更好地了解事物之间的联系。

影响:这是一篇对复杂主题(带有图片)阐述的很好的作品。保证可以使 Kubenetes 网络的混乱程度降低 10%。

保护容器供应链

随着容器、软件即服务和函数即服务的出现,人们开始着眼于在使用现有服务、函数和容器映像的过程中寻求新的价值。Red Hat 的容器首席产品经理 Scott McCarty 表示,关注这个重点既有优点也有缺点。“它使我们能够集中精力编写满足我们需求的新应用程序代码,同时将对基础架构的关注转移给其他人身上,”McCarty 说,“容器处于一个最佳位置,提供了足够的控制,而卸去了许多繁琐的基础架构工作。”但是,容器也会带来与安全性相关的劣势。

影响:我在一个由大约十位安全人员组成的小组中,可以肯定地说,整天要考虑软件安全性需要一定的倾向。当你长时间凝视深渊时,它也凝视着你。如果你不是如此倾向的软件开发人员,请听取 Scott 的建议并确保你的供应商考虑安全。

15 岁的 Fedora:为何 Matthew Miller 看到 Linux 发行版的光明前景

在 TechRepublic 的一个大范围采访中,Fedora 项目负责人 Matthew Miller 讨论了过去的经验教训、软件容器的普遍采用和竞争性标准、Fedora 的潜在变化以及包括 systemd 在内的热门话题。

影响:我喜欢 Fedora 项目的原因是它的清晰度;该项目知道它代表什么。像 Matt 这样的人就是为什么能看到光明前景的原因。

我希望你喜欢这张上周让我印象深刻的列表,并在下周一回来了解更多的开放源码社区、市场和行业趋势。


via: https://opensource.com/article/19/10/kubernetes-openstack-and-more-industry-trends

作者:Tim Hildred 选题:lujun9972 译者:wxy 校对:wxy

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

学习如何驾驭 Kubernetes 比如何建造它更重要,这些工具可以帮助你更快上路。

 title=

在本系列的第三篇文章中,Kubernetes 基础:首先学习如何使用,我强调你应该学会使用 Kubernetes,而不是建造它。我还解释说,在 Kubernetes 中,你必须学习最小的一组原语来建模应用程序。我想强调这一点:你需要学习的这组原语是最简单的原语集,你可以通过它们学习如何实现生产级的应用程序部署(即高可用性 [HA]、多容器、多应用程序)。换句话说,学习 Kubernetes 内置的原语集比学习集群软件、集群文件系统、负载平衡器、让人发疯的 Apache 和 Nginx 的配置、路由器、交换机、防火墙和存储后端更容易 —— 这些是你在传统的 IT 环境(虚拟机或裸机)中建模简单的 HA 应用程序所需要的东西。

在这第四篇文章中,我将分享一些有助于你学习快速驾驭 Kubernetes 的工具。

1、Katacoda

无疑,Katacoda 是试驾 Kubernetes 集群的最简单方法。只需单击一下,五秒钟后就可以将基于 Web 的终端直接连接到正在运行的 Kubernetes 集群中。这对于使用和学习来说非常棒。我甚至将它用于演示和测试新想法。Katacoda 提供了一个完整的临时环境,在你使用完毕后可以回收利用。

 title=

OpenShift Playground

 title=

Kubernetes Playground

Katacoda 提供了一个临时的环境和更深入的实验室环境。例如,我最近三四年主讲的 Linux Container Internals Lab 是在 Katacoda 中构建的。

Katacoda 在其主站点上维护了若干 Kubernetes 和云教程并与 Red Hat 合作以支持了一个 OpenShift 的专用学习门户。了解一下,它们是极好的学习资源。

当你第一次学习驾驶翻斗车时,最好先观察一下其他人的驾驶方式。

2、Podman generate kube

podman generate kube 命令是一个很棒的子命令,可以帮助用户自然地从运行简单容器的简单容器引擎转换到运行许多容器的集群用例(正如我在上篇文章中所描述的那样)。Podman 通过让你启动一个新的容器,然后导出这个可工作的 Kube YAML,并在 Kubernetes 中启动它来实现这一点。看看这个(你可以在 Katacoda lab 中运行它,它已经有了 Podman 和 OpenShift)。

首先,请注意运行容器的语法与 Docker 非常相似:

podman run -dtn two-pizza quay.io/fatherlinux/two-pizza

不过这个是其它容器引擎所没有的:

podman generate kube two-pizza

输出:

# Generation of Kubernetes YAML is still under development!
#
# Save the output of this file and use kubectl create -f to import
# it into Kubernetes.
#
# Created with podman-1.3.1
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: "2019-06-07T08:08:12Z"
  labels:
    app: two-pizza
  name: two-pizza
spec:
  containers:
  - command:
    - /bin/sh
    - -c
    - bash -c 'while true; do /usr/bin/nc -l -p 3306 < /srv/hello.txt; done'
    env:
    - name: PATH
      value: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
    - name: TERM
      value: xterm
    - name: HOSTNAME
    - name: container
      value: oci
    image: quay.io/fatherlinux/two-pizza:latest
    name: two-pizza
    resources: {}
    securityContext:
      allowPrivilegeEscalation: true
      capabilities: {}
      privileged: false
      readOnlyRootFilesystem: false
    tty: true
    workingDir: /
status: {}
---
apiVersion: v1
kind: Service
metadata:
  creationTimestamp: "2019-06-07T08:08:12Z"
  labels:
    app: two-pizza
  name: two-pizza
spec:
  selector:
    app: two-pizza
  type: NodePort
status:
  loadBalancer: {}

你现在有了一些可以的工作 Kubernetes YAML,你可以用它作为练习的起点来学习、调整等等。-s 标志可以为你创造一项服务。Brent Baude 甚至致力于添加卷/持久卷断言等新功能。如果想进一步深入,请在 Brent 的博客文章《Podman 现在可以轻松过渡到 Kubernetes 和 CRI-O》中了解他的工作。

3、oc new-app

oc new-app 命令非常强大。它是特定于 OpenShift 的,所以它在默认的 Kubernetes 中不可用,但是当你开始学习 Kubernetes 时它非常有用。让我们从快速命令开始创建一个相当复杂的应用程序:

oc new-project -n example
oc new-app -f https://raw.githubusercontent.com/openshift/origin/master/examples/quickstarts/cakephp-mysql.json

使用 oc new-app,你可以从 OpenShift 开发人员那里偷取模板,并在开发原语来描述你自己的应用程序时拥有一个已知良好的起点。运行上述命令后,你的 Kubernetes 命名空间(在 OpenShift 中)将由若干新的已定义资源填充。

oc get all

输出:

NAME                                READY     STATUS      RESTARTS   AGE
pod/cakephp-mysql-example-1-build   0/1       Completed   0          4m
pod/cakephp-mysql-example-1-gz65l   1/1       Running     0          1m
pod/mysql-1-nkhqn                   1/1       Running     0          4m

NAME                                            DESIRED   CURRENT   READY     AGE
replicationcontroller/cakephp-mysql-example-1   1         1         1         1m
replicationcontroller/mysql-1                   1         1         1         4m

NAME                            TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
service/cakephp-mysql-example   ClusterIP   172.30.234.135   <none>        8080/TCP   4m
service/mysql                   ClusterIP   172.30.13.195    <none>        3306/TCP   4m

NAME                                                       REVISION   DESIRED   CURRENT   TRIGGERED BY
deploymentconfig.apps.openshift.io/cakephp-mysql-example   1          1         1         config,image(cakephp-mysql-example:latest)
deploymentconfig.apps.openshift.io/mysql                   1          1         1         config,image(mysql:5.7)

NAME                                                   TYPE      FROM      LATEST
buildconfig.build.openshift.io/cakephp-mysql-example   Source    Git       1

NAME                                               TYPE      FROM          STATUS     STARTED         DURATION
build.build.openshift.io/cakephp-mysql-example-1   Source    Git@47a951e   Complete   4 minutes ago   2m27s

NAME                                                   DOCKER REPO                                                      TAGS      UPDATED
imagestream.image.openshift.io/cakephp-mysql-example   docker-registry.default.svc:5000/example/cakephp-mysql-example   latest    About aminute ago

NAME                                             HOST/PORT                                                                         PATH   SERVICES                PORT      TERMINATION   WILDCARD
route.route.openshift.io/cakephp-mysql-example   cakephp-mysql-example-example.2886795271-80-rhsummit1.environments.katacoda.com   cakephp-mysql-example   <all>                   None

这样做的好处是你可以删除 Pod,观察复制控制器如何重新创建它们,缩放 Pod 等等。你可以使用模板并将其更改为其他应用程序(这是我第一次启动时所做的)。

4、Visual Studio Code

我把我最喜欢的放在最后。我的大部分工作都使用 vi,但我从来没有为 Kubernetes 找到一个好的语法高亮器和代码补完插件(如果有的话,请告诉我)。相反,我发现微软的 VS Code 有一套杀手级的插件,可以完成 Kubernetes 资源的创建并提供样板。

 title=

首先,安装上图中显示的 Kubernetes 和 YAML 插件。

 title=

然后,你可以从头开始创建新的 YAML 文件,并自动补完 Kubernetes 资源。上面的示例显示了一个服务。

 title=

当你使用自动补完并选择服务资源时,它会填充该对象的一些模板。当你第一次学习使用 Kubernetes 时,这非常棒。你可以构建 Pod、服务、复制控制器、部署等。当你从头开始构建这些文件甚至修改你使用 podman generate kube 创建的文件时,这是一个非常好的功能。

总结

这四个工具(如果算上两个插件,则为六个)将帮助你学习驾驭 Kubernetes,而不是构造或装备它。在本系列的最后一篇文章中,我将讨论为什么 Kubernetes 如此适合运行这么多不同的工作负载。


via: https://opensource.com/article/19/6/tools-drive-kubernetes

作者:Scott McCarty 选题:lujun9972 译者:wxy 校对:wxy

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

Mac 用户可使用 MicroK8s 运行 Kubernetes 环境,进而开发、测试应用。通过下面的步骤可轻松搭建此环境。

MicroK8s 是一个 Ubuntu 推出的一个本地的 Kubernetes 版本。它是一个轻量级的 snap 应用,可安装到 PC 上作为一个单节点集群使用。尽管 MicroK8s 仅针对 Linux 构建,但是也可以在 Mac 上启动 Ubuntu VM 来实现。

MicroK8s 可在 Ubuntu 和任意支持 snap 的 OS 上运行全部原生的 K8s 服务。这对于开发应用,创建简单的 K8s 集群和本地微服务开发非常有帮助,所有的开发工作最终都还是需要部署的。

MicroK8s 提供另一个级别的可靠性因为它提供了与当前 Kubernetes(以下简称 Kubernetes 为 K8s)版本一致的开发环境。 在最新的上游 K8s 发布后的一周内,在 Ubuntu 上即可使用。

在 Mac 上配置 Kubernetes

K8s 和 MicroK8s 都需要一个 Linux 内核来工作,因此二者都需要 Ubuntu 环境。Mac 用户可使用 Multipass,此工具被设计为方便用户在 Mac、Windows、Linux 上开启 Ubuntu VM(虚拟)环境。

下面的教程将介绍在 Mac 上配置 Multipass 和运行 K8s。

步骤1:使用 Multipass 为 Mac 安装一个 VM

最新的 Multipass 的程序包可在 GitHub 上找到,双击 .pkg 即可安装。用 MicroK8s 来启动一个 VM:

multipass launch --name microk8s-vm --mem 4G --disk 40G  
multipass exec microk8s-vm -- sudo snap install microk8s --classic       
multipass exec microk8s-vm -- sudo iptables -P FORWARD ACCEPT       

确保为主机保留足够的资源。上述命令表示我们创建了一个名字为 microk8s-vm 的 VM,分配了 4GB 内存和 40GB 硬盘。

使用以下命令来查看 VM 分配的 IP 地址:(记一下下面的 IP,我们将从此开始)

multipass list  
Name         State     IPv4            Release     
microk8s-vm  RUNNING   192.168.64.1   Ubuntu 18.04 LTS                                                              

步骤2:在 VM 上与 MicroK8s 互动

可使用以下 3 种方式:

命令行,用 Multipass 的 shell 提示符:

multipass shell microk8s-vm                                                                                     

multipass exec 来执行一个命令(输入后无提示):

multipass exec microk8s-vm -- /snap/bin/microk8s.status                             

调用运行在 VM 的 K8s API 服务器,这里使用 MicroK8s 的 kubeconfig 文件和一个本地的安装的 kubectl 来访问 VM 内的 K8s,运行以下命令:

multipass exec microk8s-vm -- /snap/bin/microk8s.config > kubeconfig     

下一步,在本地主机安装 kubectl,然后使用 kubeconfig:

kubectl --kubeconfig=kubeconfig get all --all-namespaces            
NAMESPACE  NAME  TYPE  CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE          
Default service/kubernetes ClusterIP 10.152.183.1 <none> 443/TCP 3m12s

步骤 3:用 Mutlpass 服务访问 VM 并开启 MicroK8s 组件

配置基础的 MicroK8s 组件是开启 Grafana 仪表,下面我们将展示一步开启 Grafana,监视和分析一个 MicroK8s 实例。可执行以下命令:

multipass exec microk8s-vm -- /snap/bin/microk8s.enable dns dashboard  
Enabling DNS  
Applying manifest  
service/kube-dns created  
serviceaccount/kube-dns created  
configmap/kube-dns created  
deployment.extensions/kube-dns created  
Restarting kubelet  
DNS is enabled  
Enabling dashboard  
secret/kubernetes-dashboard-certs created  
serviceaccount/kubernetes-dashboard created  
deployment.apps/kubernetes-dashboard created  
service/kubernetes-dashboard created  
service/monitoring-grafana created  
service/monitoring-influxdb created  
service/heapster created  
deployment.extensions/monitoring-influxdb-grafana-v4 created  
serviceaccount/heapster created  
configmap/heapster-config created  
configmap/eventer-config created  
deployment.extesions/heapster-v1.5.2 created  
dashboard enabled

接下来,用下面命令检查部署进程:

multipass exec microk8s-vm -- /snap/bin/microk8s.kubectl get all --all-namespaces                                                                                                                        

返回信息如下:

一旦所有的必要服务已开启,接下来使用以下的链接访问仪表。命令如下:

multipass exec microk8s-vm -- /snap/bin/microk8s.kubectl cluster-info    
Kubernetes master is running at https://127.0.0.1:16443  
Heapster is running at https://127.0.0.1:16443/api/v1/namespaces/kube-system/services/heapster/proxy  
KubeDNS is running at https://127.0.0.1:16443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy  
Grafana is running at https://127.0.0.1:16443/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy  
InfluxDB is running at https://127.0.0.1:16443/api/v1/namespaces/kube-system/services/monitoring-influxdb:http/proxy  
  
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

如果我们在 VM 内,可以用此链接来访问 Grafana 仪表。不过,我们可以通过代理在主机上访问。

multipass exec microk8s-vm -- /snap/bin/microk8s.kubectl proxy --address='0.0.0.0' --accept-hosts='.*'   
Starting to serve on [::][::]:8001

保持终端运行状态,记一下端口号(8001),我们在下一步需要用到。要访问 Grafana 仪表,我们需要修改 VM 内仪表的链接:

  • 使用 VM 的 IP 替换 127.0.0.1(multipass info microk8s-vm
  • 将端口(16443)替换为代理端口 8001。
  • 在浏览器内输入这个链接地址:https://127.0.0.1:8001/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy,你将看到 Grafana 仪表,如下图:

总结

使用 MicroK8s 在本地开发和测试应用,将使得团队在部署上更快,这对于开发者和 DevOp 团队来说是非常有价值和意义的。