zoukankan      html  css  js  c++  java
  • Kubernetes管理员手边必备的9个kubectl命令

    导语:将这9个关键的kubectl命令放在手边,它们可以帮您快速排除故障并管理Kubernetes集群。

    Kubernetes是当今基础架构的主导技术,这意味着系统管理员需要熟悉其管理。多年来,笔者一直坚持每天管理Kubernetes集群,并且总结了一些技巧,希望可以帮助其他人简化他们的管理。

    笔者在这里分享9个有关kubectl的命令,主要说明笔者每天用来管理Kubernetes集群的正常运行的命令。笔者将它们分为几部分,以帮助读者确定是否应将它们用于某些任务。笔者还以长号和简写形式包含了一些标志,以帮助读者更快地使用它们。

    1. 使用Kubectl获取(get)、创建(create)、编辑(edit)和删除(delete)资源

    从命令行实用程序开始,最安全的地方是提问(读操作)而不是发出命令(写操作)。有用的get命令可以使您滚动起来。

    命令1:Kubectl get

    使用get可以获取集群中当前拥有的资源列表。您可以获得的资源类型包括:

    Namespace

    Pod

    Node

    Deployment

    Service

    ReplicaSets

    每个选项都提供有关群集中可用资源的详细信息。例如,这是get nodes命令的输出,该命令提供了Kubernetes的用法和状态版本。

    $kubectl get nodesNAME      STATUS   ROLES        AGE   VERSIONminikube  Ready        master   9d        v1.18.0

    这些命令大多数都有缩减版。要获取命名空间,可以运行kubectl get namespaces或kubectl get ns:

    $ kubectl get nsNAME              STATUS   AGEcharts            Active8ddefaultActive9dkube-node-lease   Active9dkube-public       Active9dkube-system       Active9d

    每个get命令都可以使用–namespace或-n标志集中于给定的命名空间。当您想要查看kube-system中的Pod时,笔者会特别提供帮助,这是运行Kubernetes本身所需的服务。

    $ kubectl get pods -n kube-systemNAME                               READY   STATUS    RESTARTS   AGEcoredns-66bff467f8-mjptx1/1Running29dcoredns-66bff467f8-t2xcz1/1Running29detcd-minikube1/1Running19dkube-apiserver-minikube1/1Running19dkube-controller-manager-minikube1/1Running29dkube-proxy-rpc9d1/1Running19dkube-scheduler-minikube1/1Running29dstorage-provisioner1/1Running19d

    命令2:Kubectl create

    使用kubectl,您几乎可以在集群中创建任何类型的资源。其中一些资源确实需要配置文件和命名空间来设置资源以及名称。您可以创建的资源包括:

    service

    cronjob

    deployment

    job

    namespace (ns)

    因此,创建create namespace需要另一个参数来命名命名空间。

    $kubectl create ns hello-therenamespace/hello-there created

    我们也可以使用cron命令来连续创建运行作业,就像许多Linux朋友会熟悉的那样。在这里,我们使用cronjob命令每五秒钟回显一次“ hello”。

    $kubectl create cronjob my-cron --image=busybox --schedule="*/5 * * * *"--echohellocronjob.batch/my-namespaced-cron created

    您也可以使用简化版的命令cj而不是cronjob。

    $kubectl create cj my-existing-cron --image=busybox --schedule="*/15 * * * *"--echohellocronjob.batch/my-existing-cron created

    命令3:Kubectl edit

    那么,当笔者们创建某些东西并想要更新时会发生什么呢?这就是kubectl edit的作用。

    运行此命令时,可以编辑集群中的任何资源。它将打开您的默认文本编辑器。因此,我们将编辑现有的cronjob,我们可以运行:

    $kubectl edit cronjob/my-existing-cron

    这显示了我们要编辑的配置。

    # Please edit the object below. Lines beginning with a '#' will be ignored,# and an empty file will abort the edit. If an error occurs while saving this file will be# reopened with the relevant failures.#apiVersion: batch/v1beta1kind: CronJobmetadata:creationTimestamp:"2020-04-19T16:06:06Z"  managedFields:  - apiVersion: batch/v1beta1    fieldsType: FieldsV1    fieldsV1:      f:spec:        f:concurrencyPolicy: {}        f:failedJobsHistoryLimit: {}        f:jobTemplate:          f:metadata:            f:name: {}          f:spec:            f:template:              f:spec:                f:containers:k:{"name":"my-new-cron"}:                    .: {}                    f:command: {}                    f:image: {}                    f:imagePullPolicy: {}

    这个计划设置为每15秒一次:

     

    我们将其更改为每25秒写入一次资源:

     

    编写完成后,我们可以看到它已更改。

    $ kubectl edit cronjob/my-existing-croncronjob.batch/my-existing-cron edited

    如果要使用其他编辑器,可以使用此KUBE_EDITOR语法添加来覆盖它。

    $ KUBE_EDITOR="nano"kubectl edit cronjob/my-existing-cron

    命令4:Kubectl delete

    到目前为止,除了将其完全删除之外,我们已经做了所有事情,这就是我们下一步要做的。我们刚刚编辑的cronjob是两个cronjobs之一,因此现在我们将删除整个资源。

    $ kubectldeletecronjobmy-existing-croncronjob.batch"my-existing-cron"deleted

    作为警告,切勿删除你所不知道的所有相关信息的内容。一旦资源被删除,就无法恢复。您将不得不重新创建它,因此在运行此命令之前请三思。

    命令5:Kubectl apply

    之前,笔者提到过某些命令将需要配置文件。该apply命令允许您在集群内通过文件应用配置资源。这也可以通过命令行standard in (STDIN)来完成此操作,但是建议始终是按文件进行。

    笔者认为该命令有些高级,因为您需要知道如何使用群集以及要应用哪种配置文件。对于此示例,笔者曾经使用来自Helm的基于角色访问控制(RBAC)配置用于一个服务帐户。

    $kubectl apply -f commands.yamlserviceaccount/tiller createdclusterrolebinding.rbac.authorization.k8s.io/tiller created

    您可以应用几乎任何所需的配置,但是始终需要确定要应用的配置,否则可能会看到意想不到的结果。

    2. 使用Kubectl对Kubernetes进行故障排除

    命令6:Kubectl describe

    Describe显示您正在查看的资源的详细信息。最常见的用例是描述一个pod或节点,以检查事件中是否有错误,或者资源是否太有限而无法使用。

    您可以描述的资源包括:

    Nodes

    Pods

    Services

    Deployments

    Replica sets

    Cronjobs

    在此示例中,我们可以从前面的示例中describe集群中当前的cronjob。

    $ kubectldescribecronjob my-cron片段:Name:                         my-cronNamespace:defaultLabels:                       Annotations:                  Schedule:                     */5* * * *ConcurrencyPolicy:AllowSuspend:FalseSuccessful Job HistoryLimit:3FailedJob HistoryLimit:1StartingDeadlineSeconds:    Selector:                     <unset>Parallelism:                  <unset>Completions:                  <unset>PodTemplate:Labels:   Containers:   my-cron:    Image:     busyboxPort:      Host Port: 

    命令7:Kubectl logs

    虽然describe命令提供pod内应用程序发生的事件,但logs提供了与pod相关的Kubernetes内发生的事件详细信息。理解这一区别可以帮助您解决应用程序内部和Kubernetes内部发生的问题,因为它们都是不被允许发生的相同问题。

    $kubectl logs cherry-chart-88d49478c-dmcfv -n charts

    片段:

    172.17.0.1- - [19/Apr/2020:16:01:15+0000]"GET / HTTP/1.1"200612"-""kube-probe/1.18""-"172.17.0.1- - [19/Apr/2020:16:01:20+0000]"GET / HTTP/1.1"200612"-""kube-probe/1.18""-"172.17.0.1- - [19/Apr/2020:16:01:25+0000]"GET / HTTP/1.1"200612"-""kube-probe/1.18""-"172.17.0.1- - [19/Apr/2020:16:01:30+0000]"GET / HTTP/1.1"200612"-""kube-probe/1.18""-"172.17.0.1- - [19/Apr/2020:16:01:35+0000]"GET / HTTP/1.1"200612"-""kube-probe/1.18""-"172.17.0.1- - [19/Apr/2020:16:01:40+0000]"GET / HTTP/1.1"200612"-""kube-probe/1.18""-"172.17.0.1- - [19/Apr/2020:16:01:45+0000]"GET / HTTP/1.1"200612"-""kube-probe/1.18""-"172.17.0.1- - [19/Apr/2020:16:01:50+0000]"GET / HTTP/1.1"200612"-""kube-probe/1.18""-"172.17.0.1- - [19/Apr/2020:16:01:55+0000]"GET / HTTP/1.1"200612"-""kube-probe/1.18""-"

    您还可以通过使用grep命令来消除额外的噪音或寻找其他事件。该kube-probe可能有噪音,让我们用grep命令过滤出来。

    $ kubectl logs cherry-chart-88d49478c-dmcfv -n charts |grep-vie kube-probe127.0.0.1- - [10/Apr /2020:23:01:55+0000]"GET / HTTP/1.1"200612"-""Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0"“-”

    由于某些部署在一个pod中有多个容器,您还可以对日志使用-c<container name>,从而只在一个特定容器中查找日志。

    命令8:Kubectl exec

    与docker exec命令非常相似,您也可以执行到容器中以直接对应用程序进行故障排除。当Pod中的日志没有为您提供可能要调试的问题的答案时,此功能很有用。使用exec命令时,该行的末尾必须始终提供您在pod内使用的shell。

    $ kubectl exec -it cherry-chart-88d49478c-dmcfv -n charts --/bin/bashroot@cherry-chart-88d49478c-dmcfv:/#

    命令9:Kubectl cp

    该命令用于在容器之间复制文件和目录,就像Linux cp命令一样。它不是您每天都会使用的东西,但是它是笔者个人最喜欢的,用于在自动化失败时在紧急情况下提取或还原备份。

    这是将本地文件复制到容器的示例。语法遵循kubectl cp <filename> <namespace/podname:/path/tofile> 格式:

    $ kubectl cp commands_copy.txt charts/cherry-chart-88d49478c-dmcfv:commands.txt$ kubectl exec -it cherry-chart-88d49478c-dmcfv -n charts --/bin/bashroot@cherry-chart-88d49478c-dmcfv:/# lsbin  boot  commands.txt  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

    这是另一个示例,但是这次是从容器中将文件提取我们的本地计算机上。语法为kubectl cp 格式:

    $kubectl cp charts/cherry-chart-88d49478c-dmcfv:commands.txt commands_copy.txt$lscommands_copy.txt

  • 相关阅读:
    Java Spring Boot VS .NetCore (十) Java Interceptor vs .NetCore Interceptor
    Java Spring Boot VS .NetCore (九) Spring Security vs .NetCore Security
    IdentityServer4 And AspNetCore.Identity Get AccessToken 问题
    Java Spring Boot VS .NetCore (八) Java 注解 vs .NetCore Attribute
    Java Spring Boot VS .NetCore (七) 配置文件
    Java Spring Boot VS .NetCore (六) UI thymeleaf vs cshtml
    Java Spring Boot VS .NetCore (五)MyBatis vs EFCore
    Java Spring Boot VS .NetCore (四)数据库操作 Spring Data JPA vs EFCore
    Java Spring Boot VS .NetCore (三)Ioc容器处理
    Java Spring Boot VS .NetCore (二)实现一个过滤器Filter
  • 原文地址:https://www.cnblogs.com/datapipeline/p/12891337.html
Copyright © 2011-2022 走看看