一、查看
1、查看集群状态
# 查看客户端及服务端程序版本信息
kubectl version --short=true
# 查看集群信息
kubectl cluster-info
2、查看资源对象
# 查看命名空间
kubectl get namespace
# 查看所有 pod 列表, -n 后跟 namespace, 查看指定的命名空间，-o wide 查看详细信息
kubectl get pod
kubectl get pod -n kube
kubectl get pod -o wide
# -l 标签选择器(多个的话是与逻辑)
kubectl get pods -l app=example
# -w 监视资源变动信息
kubectl get pod -w
# 以yaml格式查看Pod详细信息
kubectl get pod <pod-name> -o yaml
# 以json格式查看Pod详细信息
kubectl get pod <pod-name> -o json
# 查看deployment下pod列表
kubectl get pod -n xxx | grep ${deploymentName}
通用格式：kubectl get {$sourceType} --all-namespaces
常用的资源类型（{$resourceType}）有：
node (节点)
po（pod）
ns（命名空间namespace）
instance（实例）
svc（service服务）：定义了一个 Pod 的逻辑分组，一种可以访问它们的策略（微服务）
cm（configMap）：存储全局配置变量的，将分布式系统中不同模块的环境变量统一到一个对象中管理
ds（deamonSet）：在每台计算节点上运行一个守护进程（如日志采集等）,有时pod处于pending可能是因为某个deamonSet没起来
deploy（deployment）：用于启动（上线/部署）一个Pod或者ReplicaSet。这个如果有问题，那么其他依赖它来部署的资源就肯定不会正常了
ingress : 通过http或https暴露集群内部service，给service提供外部URL、负载均衡、SSL/TLS能力以及基于host的方向代理
# 查看 endpoint 列表 kubectl get endpoints
pv：存储卷
pvc: 存储卷消费者
3、查看详情
describe类似于get，同样用于获取resource的相关信息。不同的是，get获得的是更详细的resource个性的详细信息，describe获得的是resource集群相关的信息。
describe命令同get类似，但是describe不支持-o选项，对于同一类型resource，describe输出的信息格式，内容域相同。
注：如果发现是查询某个resource的信息，使用get命令能够获取更加详尽的信息。但是如果想要查询某个resource的状态，
如某个pod并不是在running状态，这时需要获取更详尽的状态信息时，就应该使用describe命令。
# 显示 Pod 的详细信息, 特别是查看 Pod 无法创建的时候的日志、Pod的运行事件，比如镜像有没有拉取，容器有没有创建
kubectl describe pod <Pod Name>
kubectl describe deployment <Deployment Name>
kubectl describe service <Service Name>
# 显示 Node 的详细信息
kubectl describe node [node ip]
# 显示由deployment管理的Pod的信息
kubectl describe pods <Deployment Name>
# 查看pod中所有容器的信息
kubectl describe pod/{pod_name} -n {namespace}
4、查看日志
# 实时查看日志
kubectl logs -f <pod_name>
# 若 pod 有多个容器，加 -c 指定容器
kubectl logs -f <pod_name> -c <container_name>
# kubectl attach <pod_name> -c <container_name>
类似于docker attach的功能，用于取得实时的类似于kubectl logs的信息
5、查看kubernetes配置
6、查看资源对象拥有的字段
kubectl explain pod
kubectl explain pod.apiVersion
7、查看节点标签
kubectl get node --show-labels
为kubernetes集群的resource打标签，如前面实例中提到的为rc打标签对rc分组。还可以对nodes打标签，这样在编排容器时，
可以为容器指定nodeSelector将容器调度到指定lable的机器上，如如果集群中有IO密集型，计算密集型的机器分组，可以将不同的机器打上不同标签，
然后将不同特征的容器调度到不同分组上。在1.2之前的版本中，使用kubectl get nodes则可以列出所有节点的信息，包括节点标签，
1.2版本中不再列出节点的标签信息，如果需要查看节点被打了哪些标签，需要使用describe查看节点的信息。
8、文件交换
kubectl cp 用于pod和外部的文件交换，比如如下示例了如何在进行内外文件交换
在pod中创建一个文件message.log
[[email protected] tmp]# kubectl exec -it mysql-478535978-1dnm2 sh
# pwd
/
# cd /tmp
# echo "this is a message from `hostname`" >message.log
# cat message.log
this is a message from mysql-478535978-1dnm2
# exit
拷贝出来并确认
[[email protected]-1 tmp]# kubectl cp mysql-478535978-1dnm2:/tmp/message.log message.log
tar: Removing leading `/' from member names
[[email protected]-1 tmp]# cat message.log
this is a message from mysql-478535978-1dnm2
更改message.log并拷贝回pod
[[email protected]-1 tmp]# echo "information added in `hostname`" >>message.log
[[email protected]-1 tmp]# cat message.log
this is a message from mysql-478535978-1dnm2
information added in ku8-1
[[email protected]-1 tmp]# kubectl cp message.log mysql-478535978-1dnm2:/tmp/message.log
确认更改后的信息
[[email protected]-1 tmp]# kubectl exec mysql-478535978-1dnm2 cat /tmp/message.log
this is a message from mysql-478535978-1dnm2
information added in ku8-1
二、创建/修改资源
1、kubectl create/apply
# 以标准输入创建资源
kubectl create deployment nginx --image=nginx:1.14
# 以文件创建资源
kubectl create -f my-nginx.yaml # create 创建一次
kubectl apply -f my-nginx.yaml # apply 可创建多次
2、kubectl replace/patch
用于对已有资源进行更新、替换。如前面create中创建的nginx，当我们需要更新resource的一些属性的时候，
如修改副本数量，增加、修改label，更改image版本，修改端口等。都可以直接修改原yaml文件，然后执行replace命令（删除原有资源然后重新构建资源）
kubectl replace -f <yaml_file>
注意：yaml文件里的metadata的name不能修改（是按照name作为资源的唯一标识）
# 如对正在运行的容器的属性进行在线修改（不删除容器），比如修改pod的label等
kubectl patch pod rc-nginx-2-kpiqt -p '{"metadata":{"labels":{"app":"nginx-3"}}}'
3、kubectl edit
# edit提供了另一种更新resource源的操作，通过edit能够灵活的在一个common的resource基础上，发展出更过的significant resource。
例如，使用edit直接更新前面创建的pod的命令为：
[root@master1 ~]# kubectl edit po rc-nginx-btv4j
上面命令的效果等效于：
kubectl get po rc-nginx-btv4j -o yaml >> /tmp/nginx-tmp.yaml
vim /tmp/nginx-tmp.yaml
/*do some changes here */
kubectl replace -f /tmp/nginx-tmp.yaml
4、kubectl set
# kubectl set resources 用于设置资源的一些范围限制
资源对象中的Pod可以指定计算资源需求（CPU-单位m、内存-单位Mi），即使用的最小资源请求（Requests），
限制（Limits）的最大资源需求，Pod将保证使用在设置的资源数量范围。
对于每个Pod资源，如果指定了Limits（限制）值，并省略了Requests（请求），则Requests默认为Limits的值。
可用资源对象包括(支持大小写)：replicationcontroller、deployment、daemonset、job、replicaset。
例如：
# 将deployment的nginx容器cpu限制为“200m”，将内存设置为“512Mi”
$ kubectl set resources deployment nginx -c=nginx --limits=cpu=200m,memory=512Mi
# 设置所有nginx容器中 Requests和Limits
$ kubectl set resources deployment nginx --limits=cpu=200m,memory=512Mi --requests=cpu=100m,memory=256Mi
# 删除nginx中容器的计算资源值
$ kubectl set resources deployment nginx --limits=cpu=0,memory=0 --requests=cpu=0,memory=0
# kubectl set image 用于更新现有资源的容器镜像
# 将deployment中的nginx容器镜像设置为“nginx：1.9.1”
$ kubectl set image deployment/nginx busybox=busybox nginx=nginx:1.9.1
# 所有deployment和rc的nginx容器镜像更新为“nginx：1.9.1”
$ kubectl set image deployments,rc nginx=nginx:1.9.1 --all
# 将daemonset abc的所有容器镜像更新为“nginx：1.9.1”
$ kubectl set image daemonset abc *=nginx:1.9.1
# 从本地文件中更新nginx容器镜像
$ kubectl set image -f path/to/file.yaml nginx=nginx:1.9.1 --local -o yaml
5、kubectl label、annotate
label命令: 用于更新（增加、修改或删除）资源上的 label（标签）
label 必须以字母或数字开头，可以使用字母、数字、连字符、点和下划线，最长63个字符。
如果 --overwrite 为 true，则可以覆盖已有的label，否则尝试覆盖label将会报错。
如果指定了--resource-version，则更新将使用此资源版本，否则将使用现有的资源版本。
语法：label [--overwrite] (-f FILENAME | TYPE NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--resource-version=version]
例：
# 给名为foo的Pod添加label unhealthy=true
$ kubectl label pods foo unhealthy=true
# 给名为foo的Pod修改label 为 'status' / value 'unhealthy'，且覆盖现有的value
$ kubectl label --overwrite pods foo status=unhealthy
# 给 namespace 中的所有 pod 添加 label
$ kubectl label pods --all status=unhealthy
# 仅当resource-version=1时才更新 名为foo的Pod上的label
$ kubectl label pods foo status=unhealthy --resource-version=1
# 删除名为“bar”的label 。（使用“ - ”减号相连）
$ kubectl label pods foo bar-
annotate命令：更新一个或多个资源的Annotations信息。也就是注解信息，可以方便的查看做了哪些操作。
Annotations由key/value组成。
Annotations的目的是存储辅助数据，特别是通过工具和系统扩展操作的数据，更多介绍在这里。
如果--overwrite为true，现有的annotations可以被覆盖，否则试图覆盖annotations将会报错。
如果设置了--resource-version，则更新将使用此resource version，否则将使用原有的resource version。
语法：annotate [--overwrite] (-f FILENAME | TYPE NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--resource-version=version]
例：
# 更新Pod“foo”，设置annotation “description”的value “my frontend”，如果同一个annotation多次设置，则只使用最后设置的value值
$ kubectl annotate pods foo description='my frontend'
# 根据“pod.json”中的type和name更新pod的annotation
$ kubectl annotate -f pod.json description='my frontend'
# 更新Pod"foo"，设置annotation“description”的value“my frontend running nginx”，覆盖现有的值
$ kubectl annotate --overwrite pods foo description='my frontend running nginx'
# 更新 namespace中的所有pod
$ kubectl annotate pods --all description='my frontend running nginx'
# 只有当resource-version为1时，才更新pod 'foo'
$ kubectl annotate pods foo description='my frontend running nginx' --resource-version=1
# 通过删除名为“description”的annotations来更新pod 'foo'。
# 不需要 -overwrite flag。
$ kubectl annotate pods foo description-
三、启动Pod
# 在集群中创建、启动一个指定的镜像
[root@ku8-1 tmp] # kubectl run nginx --image=nginx:1.16 --port=80 --replicas=1
deployment "nginx" created
[root@ku8-1 tmp] #
从提示看到创建了一个deployment
kubernetes将镜像运行在pod中以方便实施卷和网络共享等管理，使用get pods可以清楚的看到生成了一个pod
[root@ku8-1 tmp] # kubectl get pods
NAME READY STATUS RESTARTS AGE
sonarqube-1880671902-s3fdq 1/1 Running 0 6m
[root@ku8-1 tmp] #
内容来源于网络如有侵权请私信删除
文章来源: 博客园
- 还没有人评论，欢迎说说您的想法！
客服
