45

K8s常用运维命令

 5 years ago
source link: https://blog.csdn.net/Kim_Weir/article/details/88767392?amp%3Butm_medium=referral
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

一. 查看集群信息

[root@k8s-master ~] # kubectl cluster-info

Kubernetes master is running at http://localhost:8080

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

[root@k8s-master ~] # kubectl cluster-info dump

 

二. 查看各组件状态

[root@k8s-master ~] # kubectl -s http://localhost:8080 get componentstatuses

Vn6nAbz.png!web     

或者

[root@k8s-master ~] # kubectl -s http://172.16.60.220:8080 get componentstatuses

7vaYFvZ.png!web

三. GET信息

1) 查看节点 (k8s-master 对应的是 172.18.41.205的主机名)

[root@k8s-master ~] # kubectl get node                                #将命令中的node变为nodes也是可以的

BBnYraa.png!web

 

[root@k8s-master ~] # kubectl -s http://k8s-master:8080 get node    #将命令中的node变为nodes也是可以的

YrYnA3J.png!web

 

2) 查看pods清单

[root@k8s-master ~] # kubectl get pod                          

  #将命令中的pod变为pods也是可以的                 

qUVjaum.png!web

 

3) 查看service清单

[root@k8s-master ~]# kubectl get service                                          

#将命令中的service变为services也是可以的

RBBBRb2.png!web

 

或者  (后面的 sed 表示 打印奇数行)

[root@k8s-master ~] # kubectl get services -o json|grep '"name":'|sed -n '1~2p'

   BbaaUvj.png!web

 

4) 查看replicationControllers清单 (同理可以将命令中的replicationControllers变为replicationController也是可以的)

[root@k8s-master ~] # kubectl get replicationControllers

2U3AFji.png!web

 

5) 查看rc和namespace

[root@k8s-master ~] # kubectl get rc,namespace

QnQ3Qvi.png!web

 

6) 查看pod和svc(和service一样)

[root@k8s-master ~] # kubectl get pods,svc

ya6RVr2.png!web

 

7) 以jison格式输出pod的详细信息.

[root@k8s-master ~] # kubectl get pods

iu63mmu.png!web

 

注意下面命令中的pods的名称可以通过上面命令查看

[root@k8s-master ~]# kubectl get po nginx-controller-djd1b -o json

{

    "apiVersion": "v1",

    "kind": "Pod",

    "metadata": {

        "annotations": {

            "kubernetes.io/created-by": "{\"kind\":\"SerializedReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"ReplicationController\",\"namespace\":\"default\",\"name\":\"nginx-controller\",\"uid\":\"50a16131-4d52-11e9-99f2-00163e0e3c31\",\"apiVersion\":\"v1\",\"resourceVersion\":\"3860\"}}\n"

        },

        "creationTimestamp": "2019-03-23T11:03:18Z",

        "generateName": "nginx-controller-",

        "labels": {

            "name": "nginx"

        },

        "name": "nginx-controller-djd1b",

        "namespace": "default",

        "ownerReferences": [

            {

                "apiVersion": "v1",

                "controller": true,

                "kind": "ReplicationController",

                "name": "nginx-controller",

                "uid": "50a16131-4d52-11e9-99f2-00163e0e3c31"

            }

        ],

        "resourceVersion": "8369",

        "selfLink": "/api/v1/namespaces/default/pods/nginx-controller-djd1b",

        "uid": "4387cd87-4d5b-11e9-99f2-00163e0e3c31"

    },

    "spec": {

        "containers": [

            {

                "image": "172.18.41.206:5000/nginx",

                "imagePullPolicy": "Always",

                "name": "nginx",

                "ports": [

                    {

                        "containerPort": 80,

                        "protocol": "TCP"

                    }

                ],

                "resources": {},

                "terminationMessagePath": "/dev/termination-log"

            }

        ],

        "dnsPolicy": "ClusterFirst",

        "nodeName": "172.18.41.207",

        "restartPolicy": "Always",

        "securityContext": {},

        "terminationGracePeriodSeconds": 30

    },

    "status": {

        "conditions": [

            {

                "lastProbeTime": null,

                "lastTransitionTime": "2019-03-23T11:03:18Z",

                "status": "True",

                "type": "Initialized"

            },

            {

                "lastProbeTime": null,

                "lastTransitionTime": "2019-03-23T11:03:18Z",

                "status": "True",

                "type": "Ready"

            },

            {

                "lastProbeTime": null,

                "lastTransitionTime": "2019-03-23T11:03:18Z",

                "status": "True",

                "type": "PodScheduled"

            }

        ],

        "containerStatuses": [

            {

                "containerID": "docker://ca97dceebc3f5a3619b2e83d6d50357eb5beb1abc677a5056442fe6a63b30967",

                "image": "172.18.41.206:5000/nginx",

                "imageID": "docker-pullable://172.18.41.206:5000/nginx@sha256:7734a210432278817f8097acf2f72d20e2ccc7402a0509810c44b3a8bfe0094a",

                "lastState": {},

                "name": "nginx",

                "ready": true,

                "restartCount": 0,

                "state": {

                    "running": {

                        "startedAt": "2019-03-23T11:03:18Z"

                    }

                }

            }

        ],

        "hostIP": "172.18.41.207",

        "phase": "Running",

        "podIP": "192.168.44.3",

        "startTime": "2019-03-23T11:03:18Z"

    }

}

 

还可以输出其它格式和方法(kubectl get -h查看帮助)

[root@k8s-master ~] # kubectl get -h

 

8) 查看指定pod跑在哪个node上

[root@k8s-master ~]# kubectl get po nginx-controller-djd1b -o wide   

ZFJNf2i.png!web

9) describe方法

describe类似于get,同样用于获取resource的相关信息。不同的是,get获得的是更详细的resource个性的详细信息,describe获得的是resource集群相关的信息。

describe命令同get类似,但是describe不支持-o选项,对于同一类型resource,describe输出的信息格式,内容域相同。

 

需要注意:  如果发现是查询某个resource的信息,使用get命令能够获取更加详尽的信息。但是如果想要查询某个resource的状态,如某个pod并不是在running状态,

这时需要获取更详尽的状态信息时,就应该使用describe命令。

 

[root@k8s-master ~]# kubectl describe po nginx-controller-djd1b

Name:           nginx-controller-djd1b

Namespace:      default

Node:           172.18.41.207/172.18.41.207

Start Time:     Sat, 23 Mar 2019 19:03:18 +0800

Labels:         name=nginx

Status:         Running

IP:             192.168.44.3

Controllers:    ReplicationController/nginx-controller

Containers:

  nginx:

    Container ID:               docker://ca97dceebc3f5a3619b2e83d6d50357eb5beb1abc677a5056442fe6a63b30967

    Image:                      172.18.41.206:5000/nginx

    Image ID:                   docker-pullable://172.18.41.206:5000/nginx@sha256:7734a210432278817f8097acf2f72d20e2ccc7402a0509810c44b3a8bfe0094a

    Port:                       80/TCP

    State:                      Running

      Started:                  Sat, 23 Mar 2019 19:03:18 +0800

    Ready:                      True

    Restart Count:              0

    Volume Mounts:              <none>

    Environment Variables:      <none>

Conditions:

  Type          Status

  Initialized   True 

  Ready         True 

  PodScheduled  True 

No volumes.

QoS Class:      BestEffort

Tolerations:    <none>

No events.

 

11) create创建

kubectl命令用于根据文件或输入创建集群resource。如果已经定义了相应resource的yaml或son文件,直接kubectl create -f filename即可创建文件内定义的

resource。也可以直接只用子命令[namespace /secret/configmap/serviceaccount ]等直接创建相应的resource。从追踪和维护的角度出发,建议使用json或

yaml的方式定义资源。

 

命令格式:

# kubectl create -f 文件名

 

12) replace更新替换资源

replace命令用于对已有资源进行更新、替换。如前面create中创建的nginx,当我们需要更新resource的一些属性的时候,如果修改副本数量,增加、修改label,

更改image版本,修改端口等。都可以直接修改原yaml文件,然后执行replace命令。

 

需要注意: 名字不能被更更新。另外,如果是更新label,原有标签的pod将会与更新label后的rc断开联系,有新label的rc将会创建指定副本数的新的pod,但是默认

并不会删除原来的pod。所以此时如果使用get po将会发现pod数翻倍,进一步check会发现原来的pod已经不会被新rc控制,此处只介绍命令不详谈此问题,好奇者可自行实验。

 

命令格式:

# kubectl replace -f nginx-rc.yaml

 

13) patch

如果一个容器已经在运行,这时需要对一些容器属性进行修改,又不想删除容器,或不方便通过replace的方式进行更新。kubernetes还提供了一种在容器运行时,直接

对容器进行修改的方式,就是patch命令。 如创建pod的label是app=nginx-2,如果在运行过程中,需要把其label改为app=nginx-3。

这个patch命令如下:

[root@k8s-master ~]# kubectl patch pod nginx-controller-djd1b -p '{"metadata":{"labels":{"app":"nginx-3"}}}'

"nginx-controller-djd1b" patched

 

14) edit

edit提供了另一种更新resource源的操作,通过edit能够灵活的在一个common的resource基础上,发展出更过的significant resource。

例如,使用edit直接更新前面创建的pod的命令为:

# kubectl edit po nginx-controller-djd1b

 

上面命令的效果等效于:

# kubectl get po nginx-controller-djd1b -o yaml >> /tmp/nginx-tmp.yaml

# vim /tmp/nginx-tmp.yaml             // 这此文件里做一些修改

# kubectl replace -f /tmp/nginx-tmp.yaml

 

15) Delete

根据resource名或label删除resource。

# kubectl delete -f nginx-rc.yaml

# kubectl delete po nginx-controller-djd1b

 

16) apply

apply命令提供了比patch,edit等更严格的更新resource的方式。通过apply,用户可以将resource的configuration使用 source control的方式维护在版本库中。

每次有更新时,将配置文件push到server,然后使用kubectl apply将更新应用到resource。kubernetes会在引用更新前将当前配置文件中的配置同已经应用的配置

做比较,并只更新更改的部分,而不会主动更改任何用户未指定的部分。

 

apply命令的使用方式同replace相同,不同的是,apply不会删除原有resource,然后创建新的。apply直接在原有resource的基础上进行更新。同时kubectl apply

还会resource中添加一条注释,标记当前的apply。类似于git操作。

 

17) logs

logs命令用于显示pod运行中,容器内程序输出到标准输出的内容。跟docker的logs命令类似。如果要获得 tail -f 的方式,也可以使用-f选项。

# kubectl logs nginx-controller-djd1b

 

18) rolling-update

rolling-update是一个非常重要的命令,对于已经部署并且正在运行的业务,rolling-update提供了不中断业务的更新方式。rolling-update每次起一个新的pod,

等新pod完全起来后删除一个旧的pod,然后再起一个新的pod替换旧的pod,直到替换掉所有的pod。

 

rolling-update需要确保新的版本有不同的name,Version和label,否则会报错 。

# kubectl rolling-update nginx-controller -f nginx-rc.yaml

 

如果在升级过程中,发现有问题还可以中途停止update,并回滚到前面版本

# kubectl rolling-update nginx-controller --rollback

 

rolling-update还有很多其他选项提供丰富的功能,如--update-period指定间隔周期,使用时可以使用-h查看help信息.

 

19) scale  (注意下面的nginx-controller 是在nginx-rc.yaml文件中定义的name名称)

scale用于程序在负载加重或缩小时副本进行扩容或缩小,如前面创建的nginx有两个副本,可以轻松的使用scale命令对副本数进行扩展或缩小。

扩展副本数到4:

# kubectl scale rc nginx-controller --replicas=4

 

重新缩减副本数到2:

# kubectl scale rc nginx-controller --replicas=2

 

20) autoscale

scale虽然能够很方便的对副本数进行扩展或缩小,但是仍然需要人工介入,不能实时自动的根据系统负载对副本数进行扩、缩。autoscale命令提供了自动根据pod负载

对其副本进行扩缩的功能。

 

autoscale命令会给一个rc指定一个副本数的范围,在实际运行中根据pod中运行的程序的负载自动在指定的范围内对pod进行扩容或缩容。如前面创建的nginx,可以用

如下命令指定副本范围在1~4

# kubectl autoscale rc nginx-controller --min=1 --max=4

 

21) attach

attach命令类似于docker的attach命令,可以直接查看容器中以daemon形式运行的进程的输出,效果类似于logs -f,退出查看使用ctrl-c。如果一个pod中有多个容器,

要查看具体的某个容器的的输出,需要在pod名后使用-c containers name指定运行的容器。如下示例的命令为查看kube-system namespace中的kube-dns-v9-rcfuk pod

中的skydns容器的输出。

# kubectl attach kube-dns-v9-rcfuk -c skydns --namespace=kube-system

 

22)  exec

exec 命令同样类似于docker的 exec 命令,为在一个已经运行的容器中执行一条shell命令,如果一个pod容器中,有多个容器,需要使用-c选项指定容器。

 

23) run

类似于docker的run命令,直接运行一个image。

 

24) cordon, drain, uncordon

这三个命令是正式release的1.2新加入的命令,三个命令一起介绍,是因为三个命令配合使用可以实现节点的维护。在1.2之前,因为没有相应的命令支持,如果要维护一个

节点,只能stop该节点上的kubelet将该节点退出集群,是集群不在将新的pod调度到该节点上。如果该节点上本生就没有pod在运行,则不会对业务有任何影响。如果该节

点上有pod正在运行,kubelet停止后,master会发现该节点不可达,而将该节点标记为notReady状态,不会将新的节点调度到该节点上。同时,会在其他节点上创建新的

pod替换该节点上的pod。这种方式虽然能够保证集群的健壮性,但是任然有些暴力,如果业务只有一个副本,而且该副本正好运行在被维护节点上的话,可能仍然会造成业

务的短暂中断。

 

1.2中新加入的这3个命令可以保证维护节点时,平滑的将被维护节点上的业务迁移到其他节点上,保证业务不受影响。如下图所示是一个整个的节点维护的流程(为了方便

demo增加了一些查看节点信息的操作):

1- 首先查看当前集群所有节点状态,可以看到共四个节点都处于ready状态;

2- 查看当前nginx两个副本分别运行在d-node1和k-node2两个节点上;

3- 使用cordon命令将d-node1标记为不可调度;

4- 再使用kubectl get nodes查看节点状态,发现d-node1虽然还处于Ready状态,但是同时还被禁能了调度,这意味着新的pod将不会被调度到d-node1上。

5- 再查看nginx状态,没有任何变化,两个副本仍运行在d-node1和k-node2上;

6- 执行drain命令,将运行在d-node1上运行的pod平滑的赶到其他节点上;

7- 再查看nginx的状态发现,d-node1上的副本已经被迁移到k-node1上;这时候就可以对d-node1进行一些节点维护的操作,如升级内核,升级Docker等;

8- 节点维护完后,使用uncordon命令解锁d-node1,使其重新变得可调度;8)检查节点状态,发现d-node1重新变回Ready状态

 

# kubectl get nodes

# kubectl get po -o wide

# kubectl cordon d-node1

# kubectl get nodes

# kubectl get po -o wide

# kubectl drain d-node1

# kubectl get po -o wide

# kubectl uncordon

# kubectl uncordon d-node1

# kubectl get nodes

=====================================================================

常用命令

kubectl get pods

kubectl get rc

kubectl get service

kubectl get componentstatuses

kubectl get endpoints

kubectl cluster-info

kubectl create -f redis-master-controller.yaml

kubectl delete -f redis-master-controller.yaml

kubectl delete pod nginx-772ai

kubectl logs -f pods/heapster-xxxxx -n kube-system                     #查看日志

kubectl scale rc redis-slave --replicas=3                                     #修改RC的副本数量,来实现Pod的动态缩放

etcdctl cluster-health                                                                  #检查网络集群健康状态

etcdctl --endpoints=http://172.16.60.220:2379 cluster-health     #带有安全认证检查网络集群健康状态

etcdctl member list

etcdctl set /k8s/network/config '{ "Network": "10.1.0.0/16" }'

etcdctl get /k8s/network/config

基础进阶

kubectl get services kubernetes-dashboard -n kube-system  #查看所有service

kubectl get deployment kubernetes-dashboard -n kube-system  #查看所有发布

kubectl get pods --all-namespaces             #查看所有pod

kubectl get pods -o wide --all-namespaces      #查看所有pod的IP及节点

kubectl get pods -n kube-system | grep dashboard

kubectl describe service/kubernetes-dashboard --namespace="kube-system"

kubectl describe pods/kubernetes-dashboard-349859023-g6q8c --namespace="kube-system" #指定类型查看

kubectl describe pod nginx-772ai        #查看pod详细信息

kubectl scale rc nginx --replicas=5      # 动态伸缩

kubectl scale deployment redis-slave --replicas=5          #动态伸缩

kubectl scale --replicas=2 -f redis-slave-deployment.yaml   #动态伸缩

kubectl exec -it tomcat-controller-35kzb /bin/bash       #进入容器

kubectl label nodes k8s-node01 zone=north                #增加节点lable值 spec.nodeSelector: zone: north, 指定pod在哪个节点

kubectl get nodes -lzone                          #获取zone的节点

kubectl label pod tomcat-controller-35kzb role=master   #增加lable值 [key]=[value]

kubectl label pod tomcat-controller-35kzb role-                       #删除lable值

kubectl label pod tomcat-controller-35kzb role=backend --overwrite    #修改lable值

kubectl rolling-update redis-master -f redis-master-controller-v2.yaml      #配置文件滚动升级

kubectl rolling-update redis-master --image=redis-master:2.0                #命令升级

kubectl rolling-update redis-master --image=redis-master:1.0 --rollback     #pod版本回滚


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK