Jessica Cherry 发布的文章

去杂货店“采购”这些命令,你需要用这些 Kubernetes 工具来入门。

最近,我丈夫告诉我他即将要去参加一个工作面试,面试时他需要在计算机上运行一些基本命令。他对这场面试感到焦虑,但是对于他来说,学习和记住事情的最好方法是将不了解的事物比喻为非常熟悉的事物。因为我们的谈话是在我逛杂货店试图决定当晚要烹饪的食物之后进行的,所以这启发我用一次去杂货店的行程来介绍 kubectlhelm 命令。

Helm(“舵轮”)是在 Kubernetes(来自希腊语,意思是“舵手” 或 “领航员”)中管理应用程序的工具。你可以轻松地使用你的应用程序信息来部署“ 海图 chart ”,从而可以在你的 Kubernetes 环境中几分钟之内让它们就绪并预配置好。在学习新知识时,查看示例的“海图”以了解其用法总是很有帮助的,因此,如果有时间,请查看这些成型的“海图”。(LCTT 译注:Kubernetes 生态中大量使用了和航海有关的比喻,因此本文在翻译时也采用了这些比喻)

kubectl 是与 Kubernetes 环境交互的命令行界面,允许你配置和管理集群。它需要一些配置才能在环境中工作,因此请仔细阅读其文档以了解你需要做什么。

我会在示例中使用命名空间,你可以在我的文章《Kubernetes 命名空间入门》中了解它。

现在我们已经准备好了,让我们开始 kubectlhelm 基本命令的购物之旅!

用 Helm 列出清单

你去商店之前要做的第一件事是什么?好吧,如果你做事有条理,会创建一个“清单”。同样,这是我将解释的第一个基本的 Helm 命令。

在一个用 Helm 部署的应用程序中,list 命令提供有关应用程序当前版本的详细信息。在此示例中,我有一个已部署的应用程序:Jenkins CI/CD 应用程序。运行基本的 list 命令总是会显示默认的命名空间。由于我没有在默认的命名空间中部署任何内容,因此不会显示任何内容:

$helm list
NAME    NAMESPACE    REVISION    UPDATED    STATUS    CHART    APP VERSION

但是,如果运行带有额外标志的命令,则会显示我的应用程序和信息:

$helm list --all-namespaces
NAME     NAMESPACE  REVISION  UPDATED                   STATUS      CHART           APP  VERSION
jenkins  jenkins        1         2020-01-18 16:18:07 EST   deployed    jenkins-1.9.4   lts

最后,我可以指示 list 命令只检查我想从中获取信息的命名空间:

$helm list --namespace jenkins
NAME     NAMESPACE  REVISION  UPDATED                   STATUS    CHART          APP VERSION
jenkins    jenkins      1              2020-01-18 16:18:07 EST  deployed  jenkins-1.9.4  lts    

现在我有了一个清单,并且知道该清单上有什么,我可以使用 get 命令来“获取”我的物品!我会从 Kubernetes 集群开始,看看我能从中获取到什么?

用 Kubectl 获取物品

kubectl get 命令提供了有关 Kubernetes 中许多事物的信息,包括“ 吊舱 Pod ”、节点和命名空间。同样,如果没有指定命名空间标志,就会使用默认的命名空间。首先,我获取集群中的命名空间以查看正在运行的命名空间:

$kubectl get namespaces
NAME             STATUS   AGE
default          Active   53m
jenkins          Active   44m
kube-node-lease  Active   53m
kube-public      Active   53m
kube-system      Active   53m

现在我已经知道了在我的环境中运行的有哪些命名空间了,接下来获取节点并查看有多少个节点正在运行:

$kubectl get nodes
NAME       STATUS   ROLES       AGE   VERSION
minikube   Ready    master  55m   v1.16.2

我有一个节点正在运行,这主要是因为我的 Minikube 运行在一台小型服务器上。要得到在我的这一个节点上运行的“吊舱”可以这样:

$kubectl get pods
No resources found in default namespace.

啊哦,它是空的。我将通过以下方式获取 Jenkins 命名空间中的内容:

$kubectl get pods --namespace jenkins
NAME                      READY  STATUS   RESTARTS  AGE
jenkins-7fc688c874-mh7gv  1/1    Running  0         40m

好消息!这里发现了一个“吊舱”,它还没有重新启动过,已运行了 40 分钟了。好的,如今我知道“吊舱”已经装好,所以我想看看用 Helm 命令可以得到什么。

用 Helm 获取信息

helm get 命令稍微复杂一点,因为这个“获取”命令所需要的不仅仅是一个应用程序名称,而且你可以从应用程序中请求多个内容。我会从获取用于制作该应用程序的值开始,然后展示“获取全部”的操作结果的片段,该操作将提供与该应用程序相关的所有数据。

$helm get values jenkins -n jenkins
USER-SUPPLIED VALUES:
null

由于我只安装了最小限度的稳定版,因此配置没有更改。如果我运行“获取全部”命令,我将得到所有的“海图”:

$helm get all jenkins -n jenkins

 title=

这会产生大量数据,因此我始终建议保留一份 Helm “海图”的副本,以便你可以查看“海图”中的模板。我还创建自己的值来了解自己所拥有的。

现在,我把所有的商品都放在购物车中了,我会检查一下“描述”它们包含什么的标签。这些示例仅与 kubectl 命令有关,它们描述了我通过 Helm 部署的内容。

用 kubectl 查看描述

正如我使用“获取”命令(该命令可以描述 Kubernetes 中的几乎所有内容)所做的那样,我将示例限定到命名空间、“吊舱”和节点上。由于我知道它们每一个是什么,因此这很容易。

$kubectl describe ns jenkins
Name:           jenkins
Labels:         <none>
Annotations:  <none>
Status:         Active
No resource quota.
No resource limits.

我可以看到我的命名空间的名称,并且它是活动的,没有资源或限额限制。

describe pods 命令会产生大量信息,因此我这里提供的是一小段输出。如果你在不使用“吊舱”名称的情况下运行该命令,它将返回名称空间中所有“吊舱”的信息,这可能会很麻烦。因此,请确保在此命令中始终包含“吊舱”名称。例如:

$kubectl describe pods jenkins-7fc688c874-mh7gv --namespace jenkins

 title=

这会提供容器的状态、管理方式、标签以及“吊舱”中所使用的镜像(还有很多其它信息)。没有在这个简化过的输出中包括的数据有:在 Helm 配置值文件中应用的各种条件下的资源请求和限制、初始化容器和存储卷信息。如果你的应用程序由于资源不足而崩溃,或者是一个需要运行前置脚本进行配置的初始配置容器,或者生成不应该存储于纯文本 YAML 文件中的隐藏密码,则此数据很有用。

最后,我将使用 describe node 命令,当然,它是用来描述节点的。由于本示例只有一个名为 Minikube 的示例,因此我将使用这个名字。如果你的环境中有多个节点,则必须包含你想查找的的节点名称。

与“吊舱”一样,这个节点的命令会产生大量数据,因此我将仅包括输出片段。

$kubectl describe node minikube

 title=

注意,describe node 是更重要的基本命令之一。如此图所示,该命令返回统计信息,该信息指示节点何时资源用尽,并且该数据非常适合在需要扩展时(如果你的环境中没有自动扩展)向你发出警报。此输出片段中未包含的其它内容包括:对所有资源和限制的请求所占的百分比,以及资源的使用期限和分配(例如,对于我的应用程序而言)。

买单

使用这些命令,我完成了“购物”并得到了我想要的一切。希望这些基本命令也能在你使用 Kubernetes 的日常工作中提供帮助。

我鼓励你经常使用命令行并学习“帮助”部分中的速记标志,你可以通过运行以下命令来查看这些标志:

$helm --help

$kubectl -h

花生酱和果冻

有些东西像花生酱和果冻一样混在一起。Helm 和 kubectl 就有点像那样交错在一起。

我经常在自己的环境中使用这些工具。因为它们在很多地方都有很多相似之处,所以在使用其中一个之后,我通常需要跟进另一个。例如,我可以进行 Helm 部署,并使用 kubectl 观察它是否失败。一起试试它们,看看它们能为你做什么。


via: https://opensource.com/article/20/2/kubectl-helm-commands

作者:Jessica Cherry 选题:lujun9972 译者:wxy 校对:wxy

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

随着企业期望实现无缝、灵活和可扩展的部署,持续集成和持续部署成为 2019 年的关键主题。

 title=

对于 CI/CD 和 DevOps 来说,2019 年是非常棒的一年。Opensource.com 的作者分享了他们专注于无缝、灵活和可扩展部署时是如何朝着敏捷和 scrum 方向发展的。以下是我们 2019 年发布的 CI/CD 文章中的一些重要文章。

学习和提高你的 CI/CD 技能

我们最喜欢的一些文章集中在 CI/CD 的实操经验上,并涵盖了许多方面。通常以 Jenkins 管道开始,Bryant Son 的文章《用 Jenkins 构建 CI/CD 管道》将为你提供足够的经验,以开始构建你的第一个管道。Daniel Oh 在《用 DevOps 管道进行自动验收测试》一文中,提供了有关验收测试的重要信息,包括可用于自行测试的各种 CI/CD 应用程序。我写的《安全扫描 DevOps 管道》非常简短,其中简要介绍了如何使用 Jenkins 平台在管道中设置安全性。

交付工作流程

正如 Jithin Emmanuel 在《Screwdriver:一个用于持续交付的可扩展构建平台》中分享的,在学习如何使用和提高你的 CI/CD 技能方面,工作流程很重要,特别是当涉及到管道时。Emily Burns 在《为什么 Spinnaker 对 CI/CD 很重要》中解释了灵活地使用 CI/CD 工作流程准确构建所需内容的原因。Willy-Peter Schaub 还盛赞了为所有产品创建统一管道的想法,以便《在一个 CI/CD 管道中一致地构建每个产品》。这些文章将让你很好地了解在团队成员加入工作流程后会发生什么情况。

CI/CD 如何影响企业

2019 年也是认识到 CI/CD 的业务影响以及它是如何影响日常运营的一年。Agnieszka Gancarczyk 分享了 Red Hat 《小型 Scrum vs. 大型 Scrum》的调查结果, 包括受访者对 Scrum、敏捷运动及对团队的影响的不同看法。Will Kelly 的《持续部署如何影响整个组织》,也提及了开放式沟通的重要性。Daniel Oh 也在《DevOps 团队必备的 3 种指标仪表板》中强调了指标和可观测性的重要性。最后是 Ann Marie Fred 的精彩文章《不在生产环境中测试?要在生产环境中测试!》详细说明了在验收测试前在生产环境中测试的重要性。

感谢许多贡献者在 2019 年与 Opensource 的读者分享他们的见解,我期望在 2020 年里从他们那里了解更多有关 CI/CD 发展的信息。


via: https://opensource.com/article/19/12/cicd-resources

作者:Jessica Cherry 选题:lujun9972 译者:Morisun029 校对:wxy

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

命名空间是什么?你为什么需要它?

kubernetes 命名空间 namespace 是什么?正如 Shakespeare 以前写过的,我们所谓的命名空间,或者任何其他名字,就是虚拟集群。通过虚拟集群,意味着 kubernetes 可以在单个集群上提供多个 kubernetes 的集群,类似一个在其主机抽象出来的虚拟机。kubernetes 文档 中的解释:

kubernetes 在一个物理集群上提供了多个虚拟集群。这些虚拟集群被称为命名空间。

你为什么需要命名空间?一言以蔽之:隔离。

隔离有很多优点,如它提供了安全和干净的环境。如果你是基础设施的所属者,并且要为开发者提供环境,隔离就相当重要。你最不需要的就是,一个不熟悉你集群是如何搭建的人去修改系统配置 —— 这可能导致所有人都无法登录。

初始命名空间

一个集群的三个初始命名空间:defaultkube-systemkube-public。虽然技术上你可以用这三个命名空间作部署,但我还是推荐你把这三个命名空间留作系统配置用,而不是你的项目。

  • Default 用于某些没有指明命名空间的部署,这是一种快速创建混乱的做法,如果你在没有正确信息的情况下做了很多部署,将很难清理。我不会去动它,因为它只有这一个用途,而且在不止一种情况下误导过我。
  • Kube-system 是 Kubernetes 系统相关的所有对象组成的命名空间。任何对此命名空间的部署都可能是危险的操作,可能对系统本身造成不可挽回的破坏。没错,我试过;所以我不推荐。
  • Kube-public 所有人可读,但是这个命名空间是为系统保留的。

用命名空间来实现隔离

我用了多种方式通过命名空间来实现隔离。我经常用命名空间来把多个用户项目分割到不同的环境。这种方式可以有效防止跨项目的污染,因为命名空间提供了独立的环境。例如,用户可以安装不同版本的 Jenkins,如果它们的环境变量是在不同的命名空间,就不会冲突。

这种隔离对于清理也很有帮助。如果开发小组的多个项目突然被废弃,你可以用命令 kubectl delete ns <$NAMESPACENAME> 一键删除命名空间,清理命名空间内的所有东西。(请确认被删除的是正确的命名空间。我曾经在生产环境删除了错误的命名空间,这很不好。)

如果你是基础设施所有者,请谨慎操作,因为这可能会引发其他团队的的故障或引发其他问题。例如,如果你创建了一个特定的命名空间,里面有特殊的额外安全的 DNS 功能,但是其他人删除了它,那么命名空间内的所有 pod 和它们运行的应用都会被清空。所有的删除操作在真正实施之前都应该由同事(通过 GitOps)评审一下。

虽然官方文档不建议 10 人以下团队 使用多个命名空间,但出于架构需要,在我自己的集群上还是用了多个命名空间。集群越干净越好。

关于命名空间管理员应该知道的

首先,命名空间不能嵌套。部署只能在一个命名空间中进行。对于版本化项目,你不一定要用命名空间,你可以使用标签来区分有相同名字的版本化应用。命名空间使用配额来为不同的用户划分资源;例如,某个命名空间最多能有 x 个节点。最后,所有的命名空间对于该资源类型只能使用一个独一无二的名字。

命名空间命令操作

你需要安装 MinikubeHelmkubectl 命令行,才能使用下面的命名空间命令。我的文章《安全扫描你的 DevOps 流水线》中有它们的安装教程,你也可以去每个项目的官方主页去找安装教程。我使用的是最新的 Minikube。手动安装很快,第一次就能成功运行。

获取你的第一组命名空间:

jess@Athena:~$ kubectl get namespace
NAME            STATUS   AGE
default         Active   5m23s
kube-public     Active   5m24s
kube-system     Active   5m24s

创建一个命名空间:

jess@Athena:~$ kubectl create namespace athena
namespace/athena created

现在开发者可以部署到你创建的命名空间了;例如,这里是一个简短的 Helm chart:

jess@Athena:~$ helm install teset-deploy stable/redis --namespace athena
NAME: teset-deploy
LAST DEPLOYED: Sat Nov 23 13:47:43 2019
NAMESPACE: athena
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
` Please be patient while the chart is being deployed `
Redis can be accessed via port 6379 on the following DNS names from within your cluster:

teset-deploy-redis-master.athena.svc.cluster.local for read/write operations
teset-deploy-redis-slave.athena.svc.cluster.local for read-only operations

获取你的密码:

export REDIS_PASSWORD=$(kubectl get secret --namespace athena teset-deploy-redis -o jsonpath="{.data.redis-password}" | base64 --decode)

连接你的 redis 服务:

  1. 运行一个你可以作为客户端用的 Redis pod:
kubectl run --namespace athena teset-deploy-redis-client --rm --tty -i --restart='Never' \
       --env REDIS_PASSWORD=$REDIS_PASSWORD \
       --image docker.io/bitnami/redis:5.0.7-debian-9-r0 -- bash 
  1. 使用 Redis CLI 连接:
redis-cli -h teset-deploy-redis-master -a $REDIS_PASSWORD
redis-cli -h teset-deploy-redis-slave -a $REDIS_PASSWORD

从集群外连接你的数据库:

kubectl port-forward --namespace athena svc/teset-deploy-redis-master 6379:6379 &
redis-cli -h 127.0.0.1 -p 6379 -a $REDIS_PASSWORD

现在这一套部署已经完成了,你有一个在命名空间 test-deploy 中部署的 chart。

查看你的命名空间中有哪些 pod:

jess@Athena:~$ kubectl get pods --namespace athena
NAME                            READY   STATUS  RESTARTS   AGE
teset-deploy-redis-master-0   1/1       Running   0             2m38s
teset-deploy-redis-slave-0      1/1     Running   0             2m38s
teset-deploy-redis-slave-1      1/1     Running   0             90s

现在,你已经正式把你的应用隔离到了一个命名空间,创建了一个只在内部通信的虚拟集群。

一键删除所有东西:

jess@Athena:~$ kubectl delete namespace athena
namespace "athena" deleted

因为这会删除应用的所有内部配置,所以这个删除操作可能会持续一段时间,持续时间取决于你的部署到底有多大。

再次检查一下所有东西是否被删除了:

jess@Athena:~$ kubectl get pods --all-namespaces
NAMESPACE       NAME                            READY   STATUS  RESTARTS   AGE
kube-system   coredns-5644d7b6d9-4vxv6          1/1     Running   0             32m
kube-system   coredns-5644d7b6d9-t5wn7          1/1     Running   0             32m
kube-system   etcd-minikube                     1/1     Running   0             31m
kube-system   kube-addon-manager-minikube       1/1     Running   0             32m
kube-system   kube-apiserver-minikube           1/1     Running   0             31m
kube-system   kube-controller-manager-minikube  1/1     Running   0             31m
kube-system   kube-proxy-5tdmh                  1/1     Running   0             32m
kube-system   kube-scheduler-minikube           1/1     Running   0             31m
kube-system   storage-provisioner               1/1     Running   0             27m

这是一个所有 pod 及它们存在于的已知命名空间的列表。你可以看到,之前创建的应用和命名空间现在已经不在了。

命名空间实践

当前我是出于安全考虑才使用命名空间,如限制用户的权限。你可以限制所有的东西 —— 从哪些角色可以访问命名空间,到命名空间可使用的集群资源(CPU 等)的配额等级。例如,我通过资源配额和 基于角色的访问控制 role-based access control (RBAC)配置来确保只有允许的服务账号可以访问命名空间。

对于隔离方面的安全,我不希望我的私人 Jenkins 应用可以通过一个信任的本地网络被当做一个有公共 IP 地址的安全镜像来访问(我不得不假定,可能会被侵袭)。

如果你很难提前计算出到底要在你的云平台上部署多少节点(或者,就我而言,是在搞崩我的家庭服务器之前我能部署多少个),那么命名空间在预算方面也很有用。虽然这超出了本文的讨论范围,而且很复杂,但值得你去调研和使用来防止你的集群过分扩展。

总结

命名空间是一个很好的隔离项目和应用的方法。本文仅是一个关于命名空间的简短介绍,所以我建议你更深入地研究下命名空间,在你的实践中更多地去使用它们。


via: https://opensource.com/article/19/12/kubernetes-namespaces

作者:Jessica Cherry 选题:lujun9972 译者:lxbwolf 校对:wxy

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