您好,登录后才能下订单哦!
本篇内容介绍了“K8S中kubectl命令怎么使用”的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让小编带领大家学习一下如何处理这些情况吧!希望大家仔细阅读,能够学有所成!
kubernetes集群管理集群资源的唯一入口是通过相应的方法调用apiserver的接口
kubectl 是官方的CLI命令行工具,用于与apiserver 进行通信,将用户在命令行输入的命令,组织并转化为apiserver能识别的信息,进而实现管理k8s 各种资源的一种有效途径
kubectl 的命令大全
kubectl --help
对资源的增、删、查操作比较方便,但对改的操作就不容易
kubectl version
kubectl api-resources
kubectl cluster-info
source <(kubectl completion bash)
注意:此时命令补全功能切换环境后是不生效的,如果要使切换环境后也生效需要配置全局环境变量
vim /etc/bashrc ..... source <(kubectl completion bash) #在底部添加
journalctl -u kubelet -f 或者直接查看日志 cat /var/log/messages
kubectl get <resource> [-o wide | json | yaml] [-n namespace]
获取资源的相关信息, -n指定命令空间, -o指定输出格式
resource可以是具体资源名称,如pod nginx -xxx;也可以是资源类型,如pod; 或者all (仅展示几种核心资源,并不完整)
--all-namespaces 或-A :表示显示所有命令空间,
--show-labels :显示所有标签
-l app:仅显示标签为app的资源
-l app=nginx :仅显示包含app标签, 且值为nginx的资源
kubectl get componentstatuseskubectl get cs
命令空间的作用:用于允许不同 命令空间的相同类型的资源重名
kubectl get name space kubectl get ns
kubectl get all [-n default]
kubectl create ns app kubectl get ns
kubectl delete namespace app kubectl get ns
例:在命名空间kube-public 创建副本控制器( deployment) 来启动Pod (nginx-cc)
kubectl create deployment nginx-cc --image=nginx -n kube-public
描述某个资源的详细信息
kubectl describe deployment nginx-cc -n kube-public kubectl describe pod nginx-cc-5d7d5c6b54 -n kube-public
kubectl get pods -n kube-public
kubectl exec可以跨主机登录容器,docker exec 只能在容器所在主机上登录
kubectl exec -it nginx-cc-df5946cf-6k8rf bash -n kube-public
由于存在deployment/rc之类的副本控制器,删除pod也会重新拉起来
kubectl delete pod nginx-cc-xxxxx -n kube-public
若pod无法删除,总是处于terminate状态, 则要强行删除pod
kubectl delete pod <pod-name> -n <namespace> --force --grace-period=0 #grace-period表示过渡存活期,默认30s,在删除pod之前允许POD慢慢终止其上的容器进程, 从而优雅退出,0表示立即终止pod
kubectl scale deployment nginx-cc --replicas=3 -n kube-public #扩容 kubectl scale deployment nginx-cc --replicas=1 -n kube-public #缩容
kubectl delete deployment nginx-cc -n kube-public kubectl delete deployment/nginx-cc -n kube-public
创建–>发布–>更新–>回滚–>删除
创建并运行一个或多个容器镜像
创建一个 deployment 或 job 来管理容器
kubectl run --help
##启动 nginx 实例,暴露容器端口80,设置副本数 3 kubectl run nginx --image=nginx:1.14 --port=80 【--replicas=3】 注:【--replicas=3】 只是用老版本的k8s ,现在的新版本不能使用 kubectl get pods kubectl get all
将资源暴露为新的Service
kubectl expose --help
为deployment(无状态部署)的nginx创建service, 并通过Service的80端口转发至容器的80端口上,Service的名称为nginx-service, 类型为NodePort
kubectl expose pod nginx --port=80 --target-port=80 --name=nginx-service --type=NodePort
Kubernetes之所以需要Service, 一方面是因为Pod的IP 不是固定的(Pod可能会重建),另一方面则是因为一组Pod实例之间总会有负载均衡的需求。
Service通过label Selector实现的对一组的Pod的访问。
对于容器应用而言,Kubernetes 提供了基于VIP (虚拟IP)的网桥的方式访问 Service, 再由Service 重定向到相应的Pod。
service的类型:1、ClusterIP:提供一个集群内部的虚拟IP以供Pod访问( service默认类型
2、NodePort:在每个Node.上打开一个端口以供外部访问,Kubernetes将会在每个Node.上打开一个端口并且每个Node的端口都是一样的,通过NodeIp:NodePort的方式Kubernetes集群外部的程序可以访问Service。
注:每个端口只能是一种服务,端口范围只能是30000-32767
3、LoadBalancer:通过外部的负载均衡器来访问,通常在云平台部署LoadBalancer还需要额外的费用。
kubectl get pods,svc -o wide
kubectl get endpoints
kubect1 describe svc nginx
更改现有应用资源一些信息
kubectl set --help
kubectl set image --help
curl -I http://192.168.111.20:31828 curl -I http://192.168.111.30:31828
kubectl set image pod/nginx-deployment nginx=nginx:1.15
处于动态监听pod状态,由于使用的是滚动更新方式,所以会先生成--个新的pod,然后删除--个旧的pod,往后依次类推(动态更新的)
kubectl get pods -o wide
kubectl rollout --help
kubectl rollout history deployment/nginx-test01 -n app
kubectl rollout undo deployment.apps/nginx-test01 -n app
kubectl rollout undo deployment.apps/nginx-test01 --to-revision=3 -n app
kubectl rollout status deployment/nginx
//删除副本控制器 [root@master ~]# kubectl delete deployment/nginx deployment.extensions "nginx" deleted //删除service [root@master ~]# kubectl delete svc/nginx-service service "nginx-service" deleted [root@master ~]# kubectl get all NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 15h service/nginx NodePort 10.96.59.53 <none> 80:31670/TCP 15h
Deployment控制器支持自定义控制更新过程中的滚动节奏,如“暂停(pause)”或“继续(resume)”更新操作。比如等待第一批新的Pod资源创
建完成后立即暂停更新过程,此时,仅存在一部分新版本的应用,主体部分还是旧的版本。然后,再筛选一小部分的用户请求路由到新版本的Pod应用,继续观察能否稳定地按期望的方式运行。确定没问题之后再继续完成余下的Pod资源滚动更新,否则立即回滚更新操作。这就是所谓的金丝雀发布。
(1)更新deployment的版本,并配置暂停deployment kubectl set image deployment/nginx nginx=nginx:1.14 && kubectl rollout pause deployment/nginx kubectl rollout status deployment/nginx #观察更新状态 (2)监控更新的过程,可以看到已经新增了一个资源,但是并未按照预期的状态去删除一个旧的资源, 就是因为使用了pause暂停命令 kubectl get pods -W curl [-I] 10.0.0.189 curl [-I] 192.168.111.20:44847 (3)确保更新的pod没问题了,继续更新 kubectl rollout resume deployment/nginx (4)查看最后的更新情况 kubectl get pods -W curl [-I] 10.0.0.189 curl [-I] 192.168.111.20:44847
适合于对资源的修改操作
声明式资源管理方法依赖于资源配置清单文件对资源进行管理
资源配置清单文件有两种格式: yaml(人性化,易读),json(易于api接口解析)
对资源的管理,是通过事先定义在统一资源配置清单内,再通过陈述式命令应用到k8s集群里
语法格式: kubectl create/apply/delete -f xxxx. yaml
YAML,即 YAML Ain’t a Markup Language(YAML 不是一种标记语言)的递归缩写。YAML 其实意思是 Yet Another Markup Language(仍是一种标记语言)。它主要强度这种语言是以数据为中心,而不是以标记为中心,而像 XML 语言就使用了大量的标记。
YAML 可读性高,易于理解,用来表达数据序列化的格式。它的语法和其他高级语言类似,还可以简单表达数组、散列表,标量等数据形态。它使用空白符号缩进和大量依赖外观的特色,特别适合用来表达或编辑数据结构、各种配置文件。
YAML 配置文件后缀为.yml,例如application.yml。
yaml 和 json 的主要区别:
YAML 使用空格缩进,这是 Python 开发人员熟悉的领域。
JavaScript 开发人员喜欢 JSON,因为它是 JavaScript 的一个子集,可以直接在 JavaScript 中解释和编写,同时使用简写方式声明 JSON,在使用没有空格的典型变量名时,不需要键中的双引号。
有很多解析器在 YAML 和 JSON 的所有语言中都能很好地工作。
在许多情况下,YAML 的空白格式可以更容易查看,因为格式化需要更人性化的方法。
如果您的编辑器中没有空格可见或缩进线指示符,那么 YAML 的空白虽然更紧凑,更容易查看,但可能难以手动编辑。
JSON 的序列化和反序列化要快得多,因为要检查的功能明显少于 YAML,这使得更小更轻的代码能够处理 JSON。
一个常见的误解是 YAML 需要较少的标点符号并且比 JSON 更紧凑,但这完全是错误的。空格是不可见的,所以看起来字符较少,但是如果你计算实际的空格是必要的,以便正确解释 YAML 以及正确的缩进,你会发现 YAML 实际上需要比 JSON 更多的字符。JSON 不使用空格来表示层次结构或分组,并且可以通过删除不必要的空格来轻松展平,以实现更紧凑的传输。
Kubernetes支持YAML和JSON 格式管理资源对象
JSON格式:主要用于api接口之间消息的传递
YAML格式:用于配置和管理,YAML的配置参数格式比较清晰
语法格式:
大小写敏感
以空格的方式缩进标识层级关系
通常开头缩进两个空格(统一层级对应即可)
不支持制表符“tab”缩进,只使用空格缩进
关键词字符后缩进一个空格,比如冒号,逗号后面需要缩进一个字符
“---”表示YAML格式,一个文件的开始支持以“#”表示注释
控制器定义
被控制对象
字段说明:
apiVersion | API版本 |
kind | 资源类型 |
metadata | 资源元数据 |
spec | 资源规格 |
replicas | 副本数量 |
selector | 标签选择器 |
template | Pod模板 |
metadata | Pod元数据 |
spec | Pod规格 |
container | 容器配置 |
K8S---apiVersion对照表:点击这里
kubectl api-versions
如果是业务场景,一般首选使用 apps/v1(apps/v1 从 v1.9 版本开始提供 API)。
在 k8s v1.16 版本之前使用的是 extensions/v1beta1,extensions/v1beta1 从 v1.20 版本开始不再提供 Ingress 资源。
带有 beta 字样的代表的是测试版本,不用在生产环境中。
mkdir /opt/demo cd /opt/demo/ 参考模板: vim nginx-deployment.yaml apiVersion: apps/v1 #指定api版本标签 kind: Deployment #定义资源的类型/角色,deployment 为副本控制器, 此处资源类型可以是Deployment、Job、 Ingress、 Service等 metadata: #定义资源的元数据信息,比如资源的名称、namespace、标签等信息 name: nginx-deployment #定义资源的名称,在同一个namespace空间中必须是唯一的 labels: #定义资源标签(Pod的标签) app: nginx spec: #定义deployment资源需要的参数属性,诸如是否在容器失败时重新启动容器的属性 replicas: 3 #定义副本数量 selector : #定义标签选择器 matchLabels: #定义匹配标签 app: nginx #匹配上面的标签,需与上面的标签定义的app保持一致 template: #定义业务模板,如果有多个副本,所有副本的属性会按照模板的相关配置进行匹配 metadata: labels: app: nginx spec: containers: #定义容器属性 - name: nginx #定义一个容器名,一个- name: 定义一个容器 image: nginx:1.15.4 #定义容器使用的镜像以及版本 ports: - containerPort: 80 #定义容器的对外的端口 实例: vim nginx-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment namespace: kube-public labels: name: nginx-deployment spec: replicas: 3 selector: matchLabels: app: nginx-demo1 template: metadata: labels: app: nginx-demo1 spec: containers: - name: nginx image: nginx:1.15.4 ports: - name: http containerPort: 80
kubectl create -f nginx-deployment.yaml 或者 kubectl apply -f nginx-deployment.yaml
kubectl get pods -o wide -n kube-public kubectl get deploy -n kube-public
apiVersion: v1 kind: Service metadata: name: nginx-demo1 namespace: kube-public labels: name: nginx-demo1 spec: type: NodePort ports: - port: 8080 targetPort: 80 nodePort: 31333 selector: app: nginx-demo1
kubectl apply -f nginx-server.yaml kubectl get svc -n kube-public
在浏览器输入 nodeIP: nodePort 即可访问 http://192.168.111.20:31333 http://192.168.111.30:31333
●port
port是k8s集群内部访问service的端口,即通过clusterIP: port可以从Pod所在的Node. 上访问到service
●nodePort
nodePort是外部访问k8s集群中service的端口,通过nodeIP: nodePort 可以从外部访问到某个service。
●targetPort
targetPort是Pod的端口,从port或nodePort来的流量经过kube-proxy 反向代理负载均衡转发到后端Pod的targetPort上,最后进入容器。
●containerPort
containerPort是Pod内部容器的端口,targetPort 映射到containerPort
kubectl run --dry-run 打印相应的API 对象 而不执行创建
--dry-run
:试运行
kubectl run nginx-test --image=nginx --port=80 --replicas=3 --dry-run
--dry-run
表示试运行,不真正执行命令(测试命令是否正确),即并不会真的创建出 pod 和 deployment 实例,去掉该参数后即可真正执行命令。
使用--dry-run
试运行可不触发生成命令,然后通过-o yaml
可实现对其 yaml 资源配置清单的查看
kubectl run nginx-test --image=nginx --port=80 --replicas=3 --dry-run -o yaml
可通过 -o json 查看该命令产生的 json 配置清单
kubectl run nginx-test --image=nginx --port=80 --replicas=3 --dry-run -o json
kubectl run nginx-test --image=nginx --port=80 --replicas=3 --dry-run -o yaml > nginx-test.yaml
模板: vim nginx-test.yaml apiVersion: apps/v1betal #api 版本改成 api/v1 kind: Deployment metadata: creationTimestamp: null #删除 labels: run: nginx-test name: nginx-test spec: replicas: 3 selector: matchLabels: run: nginx-test strategy: {} #删除 template: metadata: creationTimestamp: null #删除 labels: run: nginx-test spec: containers: - image: nginx name: nginx-test ports: - containerPort: 80 resources: {} #删除 status: {} #删除 例: apiVersion: v1 kind: Service metadata: labels: name: nginx-demo2 name: nginx-demo2 namespace: kube-public spec: ports: - port: 8044 protocol: TCP targetPort: 80 selector: run: nginx-demo2 type: NodePort
kubectl apply -f nginx-test.yaml kubectl get svc -n kube-public
kubectl get pod/nginx-deployment-6f9f6d866c-2w9gz -o yaml -n kube-public ###注现在最新版本的kubctl get 不支持 --export 参数
kubectl get deployment.apps/nginx-deployment -o yaml -n kube-public > my-deploy.yaml
explain 可一层层的查看相关资源对象的帮助信息
kubectl explain deployments.spec.template.spec.containers 或 kubectl explain pods.spec.containers
没有相关资源,使用run或者create命令--dry-run
选项,后期可以修改yaml文件。
kubectl run my-deploy --image=nginx --dry-run -o yaml > my-deploy.yaml
已有相关资源,使用get命令 【--export
选项 :适用老版本的kubectl】
kubectl get deploy/nginx-deployment -o=yaml -n kube-public > new.yaml
yaml文件的学习方法
(1)多看别人(官方)写的,能读懂
(2)能照着现场的文件改着用
(3)遇到不懂的,善用kubectl explain ...命令查
“K8S中kubectl命令怎么使用”的内容就介绍到这里了,感谢大家的阅读。如果想了解更多行业相关的知识可以关注亿速云网站,小编将为大家输出更多高质量的实用文章!
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。