标签 kubectl 下的文章

学习 kubectl,提升你与 Kubernetes 的互动方式。

 title=

Kubernetes 可以帮你编排运行有大量容器的软件。Kubernetes 不仅提供工具来管理(或者说 编排)运行的容器,还帮助这些容器根据需要进行扩展。有了 Kubernetes 作为你的中央 控制面板 control panel (或称 控制平面 control plane ),你需要一种方式来管理 Kubernetes,而这项工作的工具就是 kubectl。kubectl 命令让你控制、维护、分析和排查 Kubernetes 集群的故障。与许多使用 ctl(“控制”的缩写)后缀的工具一样,如 systemctl 和 sysctl,kubectl 拥有大量的功能和任务权限,所以如果你正在运行 Kubernetes,你肯定会经常使用它。它是一个拥有众多选项的命令,所以下面是 kubectl 中简单易用的五个常见任务。

1、列出并描述资源

按照设计,容器往往会成倍增加。在某些条件下,它们可以快速增加。如果你只能通过 podman ps或 docker ps 来查看正在运行的容器,这可能会让你不知所措。通过 kubectl get 和 kubectl describe,你可以列出正在运行的 吊舱 pod 以及它们正在处理的容器信息。更重要的是,你可以通过使用 --namespace 或 name 或 --selector等选项,只列出所需信息。

get 子命令不仅仅对吊舱和容器有用。它也有关于节点、命名空间、发布、服务和副本的信息。

2、创建资源

如果你只通过类似 OpenShift、OKD 或 Kubernetes 提供的 Web 用户界面(UI)创建过发布,但你想从 Linux 终端控制你的集群,那么可以使用 kubectl create。kubectl create 命令并不只是实例化一个新的应用发布。Kubernetes 中还有很多其他组件可以创建,比如服务、配额和 计划任务。

Kubernetes 中的计划任务可以创建一个临时的吊舱,用来在你选择的时间表上执行一些任务。它们并不难设置。下面是一个计划任务,让一个 BusyBox 镜像每分钟打印 “hello world”。

$ kubectl create cronjob \
    hello-world \
    --image=busybox \
    --schedule="*/1 * * * *" -- echo "hello world"

3、编辑文件

Kubernetes 中的对象都有相应的配置文件,但在文件系统中查找相应的文件较为麻烦。有了 kubectl edit,你可以把注意力放在对象上,而不是定义文件上。你可以通过 kubectl 找到并打开文件(通过 KUBE_EDITOR 环境变量,你可以设置成你喜欢的编辑器)。

$ KUBE_EDITOR=emacs \
    kubectl edit cronjob/hello-world

4、容器之间的传输文件

初次接触容器的人往往对无法直接访问的共享系统的概念感到困惑。他们可能会在容器引擎或 kubectl 中了解到 exec 选项,但当他们不能从容器中提取文件或将文件放入容器中时,容器仍然会显得不透明。使用 kubectl cp 命令,你可以把容器当做远程服务器,使主机和容器之间文件传输如 SSH 命令一样简单:

$ kubectl cp foo my-pod:/tmp

5、应用变更

对 Kubernetes 对象进行修改,可以通过 kubectl apply 命令完成。你所要做的就是将该命令指向一个配置文件:

$ kubectl apply -f ./mypod.json

类似于运行 Ansible 剧本或 Bash 脚本,apply 使得快速“导入”设置到运行中的 Kubernetes 实例很容易。例如,GitOps 工具 ArgoCD 由于 apply 子命令,安装起来出奇地简单:

$ kubectl create namespace argocd
$ kubectl apply -n argocd \
    -f https://raw.githubusercontent.com/argoproj/argo-cd/vx.y.z/manifests/install.yaml

使用 kubectl

Kubectl 是一个强大的工具,由于它是一个终端命令,它可以写成脚本,并能实现用众多 Web UI 无法实现的功能。学习 kubectl 是进一步了解 Kubernetes、容器、吊舱以及围绕这些重要的云计算创新技术的一个好方法。下载我们的 kubectl 速查表,以获得快速参考,其中包括命令示例,以帮助你学习,并在为你提供注意细节。


via: https://opensource.com/article/21/7/kubectl

作者:Alan Smithee 选题:lujun9972 译者:geekpi 校对:turbokernel

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

开始探索 kubectl、容器、吊舱等,接着下载我们的免费的速查表,这样你就可以随时掌握关键的命令了。

 title=

云计算主要是在 Kubernetes 上运行,Kubernetes 主要是在 Linux 上运行,而 Linux 在有熟练的系统管理员控制时运行得最好。无论你认为自己是云计算架构师还是只是一个保守的系统管理员,现代互联网都需要了解如何在容器中创建应用和服务,按需扩展,按需扩展以及如何明智地进行监视和管理。

进入勇敢的容器世界的第一步是学习 Kubernetes 和它的基本命令:kubectl。

安装 kubectl

kubectl 命令允许你在 Kubernetes 集群上运行命令。你使用 kubectl 来部署应用、查看日志、检查和管理集群资源,并在出现问题时进行故障排除。kubectl(以及整个 Kubernetes)的典型“问题”是,要对集群运行命令,你首先需要一个集群。然而,有一些简单的解决方案。

首先,你可以创建自己的 Kubernetes 集群,只需买三块树莓派板和相关外围设备(主要是电源)。当你获得了硬件,阅读 Chris Collins 的 使用树莓派构建 Kubernetes 集群,你就会拥有自己的安装有 kubectl 的集群。

另一种获得集群的方法是使用 Minikube,这是一个 Kubernetes 的实践环境。在所有建立和运行集群的方法中,这是最简单的。

还有更多的选择;例如,你可以参加一个关于 Kubernetes 的课程,以获得一个运行集群的实验室,或者你可以在云上购买时间。只要你有一个 Kubernetes 环境来练习,如何获得集群并不重要。

当你你能访问一个集群,你就可以开始探索 kubectl 命令。

了解吊舱和容器

容器是一个轻量级的、部分的 Linux 系统,专门用于运行一个应用或服务。容器受到 内核命名空间 的限制,这使它能够访问其主机(运行容器的计算机)上的重要系统组件,同时防止它向其主机发送数据。容器以容器镜像(或简称 镜像)的形式保存,并由称为 Containerfile 或 Dockerfile 的文本文件定义。

吊舱 Pod 是容器的正式集合,也是管理员扩展、监控和维护任何数量的容器的一种简单方法。

这些一起就像 Kubernetes 的“应用程序”。创建或获取容器镜像是你在云上运行服务的方式。

运行一个吊舱

容器镜像的两个可靠的仓库是 Docker Hub 和 Quay。你可以在仓库中搜索可用的镜像列表。通常有由项目提供的大型项目的官方镜像,也有专门的、定制的或特殊项目的社区镜像。最简单和最小的镜像之一是 BusyBox 容器,它提供了一个最小的 shell 环境和一些常用命令。

无论你是从仓库中拉取镜像,还是自己编写镜像定义并从 Git 仓库中拉取到集群中,其工作流程都是一样的。当你想在 Kubernetes 中启动一个吊舱时:

  1. 在 Docker Hub 或 Quay 上找到一个你想使用的镜像
  2. 拉取镜像
  3. 创建一个吊舱
  4. 部署吊舱

以 BusyBox 容器为例子,你可以用一条命令完成最后三个步骤:

$ kubectl create deployment my-busybox --image=busybox

等待 kubectl 完成这个过程,最后你就有了一个正在运行的 BusyBox 实例。这个吊舱并没有暴露给其他人。它只是在后台安静地在你的集群上运行。

要看你的集群上有哪些吊舱在运行:

$ kubectl get pods --all-namespaces

你也可以获得关于吊舱部署的信息:

$ kubectl describe deployment my-busybox

与吊舱互动

容器通常包含使其自动化的配置文件。例如,将 Nginx httpd 服务器作为容器安装,应该不需要你的互动。你开始运行容器,它就会工作。对于你添加到吊舱中的第一个容器和之后的每个容器都是如此。

Kubernetes 模型的优点之一是,你可以根据需要扩展你的服务。如果你的网络服务被意外的流量淹没,你可以在你的云中启动一个相同的容器(使用 scale 或 autoscale 子命令),使你的服务处理传入请求的能力增加一倍。

即便如此,有时还是很高兴看到一些证明吊舱正在按预期运行的证据,或者能够对似乎无法正常运行的某些问题进行故障排除。为此,你可以在一个容器中运行任意的命令:

$ kubectl exec my-busybox -- echo "hello cloud"

另外,你可以在你的容器中打开一个 shell,用管道将你的标准输入输入到其中,并将其输出到终端的标准输出:

$ kubectl exec --stdin --tty my-busybox -- /bin/sh

暴露服务

默认情况下,吊舱在创建时不会暴露给外界,这样你就有时间在上线前进行测试和验证。假设你想把 Nginx Web 服务器作为一个吊舱安装和部署在你的集群上,并使其可以访问。与任何服务一样,你必须将你的吊舱指向服务器上的一个端口。kubectl 子命令 expose 可以为你做到这点:

$ kubectl create deployment \
  my-nginx --image=nginx
$ kubectl expose deployment \
  my-nginx --type=LoadBalancer --port=8080

只要你的集群可以从互联网上访问,你就可以通过打开浏览器并导航到你的公共 IP 地址来测试你的新 Web 服务器的可访问性。

不仅仅是吊舱

Kubernetes 提供了很多东西,而不仅仅是存储普通服务的镜像。除了作为一个 容器编排 系统,它还是一个云开发的平台。你可以编写和部署应用,管理和监控性能和流量,实施智能负载平衡策略等。

Kubernetes 是一个强大的系统,它已经迅速成为各种云的基础,最主要的是 开放混合云。今天就开始学习 Kubernetes 吧。随着你对 Kubernetes 的进一步了解,你会需要一些关于其主要概念和一般语法的快速提醒,所以 下载我们的 Kubernetes 速查表 并将它放在身边。


via: https://opensource.com/article/21/5/kubernetes-cheat-sheet

作者:Seth Kenlon 选题:lujun9972 译者:geekpi 校对:wxy

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

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

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

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

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

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

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

用 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中国 荣誉推出

一个使用 tmux 的 kubectl 插件可以使 Kubernetes 疑难问题变得更简单。

Kubernetes 是一个活跃的开源容器管理平台,它提供了可扩展性、高可用性、健壮性和富有弹性的应用程序管理。它的众多特性之一是支持通过其主要的二进制客户端 kubectl 运行定制脚本或可执行程序,kubectl 很强大的,允许用户在 Kubernetes 集群上用它直接做很多事情。

使用别名进行 Kubernetes 的故障排查

使用 Kubernetes 进行容器编排的人都知道由于设计上原因带来了其功能的复杂性。举例说,迫切需要以更快的速度并且几乎不需要手动干预的方式来简化 Kubernetes 中的故障排除(除过特殊情况)。

在故障排查功能方面,有很多场景需要考虑。在一种场景下,你知道你需要运行什么,但是这个命令的语法(即使作为一个单独的命令运行)过于复杂,或需要一、两次交互才能起作用。

例如,如果你需要经常进入一个系统命名空间中运行的容器,你可能发现自己在重复地键入:

kubectl --namespace=kube-system exec -i -t <your-pod-name>

为了简化故障排查,你可以用这些指令的命令行别名。比如,你可以增加下面命令到你的隐藏配置文件(.bashrc 或 .zshrc):

alias ksysex='kubectl --namespace=kube-system exec -i -t'

这是来自于 Kubernetes 常见别名存储库的一个例子,它展示了一种简化 kubectl 中的功能的方法。像这种场景下的简单情形,使用别名很有用。

切换到 kubectl 插件

更复杂的故障排查场景是需要一个一个的执行很多命令,调查环境,最后得出结论。仅仅用别名方法是不能解决这种情况的;你需要知道你所部署的 Kubernetes 之间逻辑和相关性,你真正需要的是自动化,以在更短的时间内输出你想要的。

考虑到你的集群有 10 ~ 20 或 50 ~ 100 个命名空间来提供不同的微服务。一般在进行故障排查时,什么对你有帮助?

  • 你需要能够快速分辨出抛出错误的是哪个 命名空间的哪个 Pod 的东西。
  • 你需要一些可监视一个命名空间的所有 Pod 日志的东西。
  • 你可能也需要监视特定命名空间的出现错误的某个 Pod 的日志。

涵盖这些要点的解决方案对于定位生产环境的问题有很大的帮助,以及在开发和测试环节中也很有用。

你可以用 kubectl 插件创建比简单的别名更强大的功能。插件类似于其它用任何语言编写的独立脚本,但被设计为可以扩充 Kubernetes 管理员的主要命令。

创建一个插件,你必须用 kubectl-<your-plugin-name> 的正确的语法来拷贝这个脚本到 $PATH 中的导出目录之一,并需要为其赋予可执行权限(chmod +x)。

创建插件之后将其移动到路径中,你可以立即运行它。例如,我的路径下有一个 kubectl-krawl 和 kubectl-kmux:

$ kubectl plugin list
The following compatible plugins are available:

/usr/local/bin/kubectl-krawl
/usr/local/bin/kubectl-kmux

$ kubectl kmux

现在让我们见识下带有 tmux 的 Kubernetes 的有多强大。

驾驭强大的 tmux

Tmux 是一个非常强大的工具,许多管理员和运维团队都依赖它来解决与易操作性相关的问题:通过将窗口分成多个窗格以便在多台计算机上运行并行的调试来监视日志。它的主要的优点是可在命令行或自动化脚本中使用。

我创建一个 kubectl 插件,使用 tmux 使故障排查更加简单。我将通过注释来解析插件背后的逻辑(插件的完整代码留待给你实现):

# NAMESPACE 是要监控的名字空间
# POD 是 Pod 名称
# Containers 是容器名称

# 初始化一个计数器 n 以计算循环计数的数量,
# 之后 tmux 使用它来拆分窗格。
n=0;

# 在 Pod 和容器列表上开始循环
while IFS=' ' read -r POD CONTAINERS
do
    # tmux 为每个 Pod 创建一个新窗口
    tmux neww $COMMAND -n $POD 2>/dev/null
    # 对运行中的 Pod 中 的所有容器启动循环
    for CONTAINER in ${CONTAINERS//,/ }
    do
        if [ x$POD = x -o x$CONTAINER = x ]; then
            # 如果任何值为 null,则退出。
                     warn "Looks like there is a problem getting pods data."
            break
        fi
           
        # 设置要执行的命令
        COMMAND=”kubectl logs -f $POD -c $CONTAINER -n $NAMESPACE”
        # 检查 tmux 会话
        if tmux has-session -t <会话名> 2>/dev/null;
        then
            <设置会话退出>
        else
            <创建会话>
        fi
        # 在当前窗口为每个容器切分窗格
        tmux selectp -t $n \; \
        splitw $COMMAND \; \
        select-layout tiled \;
        # 终止容器循环
    done
    
    # 用 Pod 名称重命名窗口以识别
    tmux renamew $POD 2>/dev/null
    
    # 增加计数器
    ((n+=1))

# 终止 Pod 循环
done<<(<从 kubernetes  集群获取 Pod 和容器的列表>)

# 最后选择窗口并附加会话
tmux selectw -t <会话名>:1 \; \
attach-session -t <会话名>\;

运行插件脚本后,将产生类似于下图的输出。每个 Pod 有一个自己的窗口,每个容器(如果有多个)被分割到其窗口中 Pod 窗格中,并在日志到达时输出。Tmux 之美如下可见;通过正确的配置,你甚至会看到哪个窗口正处于激活运行状态(可看到标签是白色的)。

总结

别名是在 Kubernetes 环境下常见的也有用的简易故障排查方法。当环境变得复杂,用高级脚本生成的kubectl 插件是一个更强大的方法。至于用哪个编程语言来编写 kubectl 插件是没有限制。唯一的要求是该名字在路径中是可执行的,并且不能与已知的 kubectl 命令重复。

要阅读完整的插件源码,或试试我创建的插件,请查看我的 kube-plugins-github 存储库。欢迎提交提案和补丁。


via: https://opensource.com/article/20/2/kubernetes-tmux-kubectl

作者:Abhishek Tamrakar 选题:lujun9972 译者:guevaraya 校对:wxy

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