目录
3.4.2、查看命名空间kube-public中的pod信息
1、更新deployment的版本,并配置暂停deployment

kubernetes 集群管理集群资源的唯一入口是通过相应的方法调用 apiserver 的接口
kubectl 是官方的 CLI 命令行工具,用于与 apiserver 进行通信,将用户在命令行输入的命令,组织并转化为apiserver 能识别的信息,进而实现管理 k8s 各种资源的一种有效途径
kubectl 的命令大全
kubectl --help
k8s官方中文文档:http://docs.kubernetes.org.cn/683.html
对资源的增、删、查操作比较容易,但对改的操作就不容易了
kubectl version

kubectl get nodes

kubectl api-resources

kubectl cluster-info

- source <(kubectl completion bash)
- 注意:此时命令补全功能切换环境后是不生效的,如果要使切换环境后也生效需要配置全局环境变量
-
- 可通过TAB键实现命令补全,建议将其写入 /etc/profile


- journalctl -u kubelet -f
-
- 或者直接查看日志
-
- cat /var/log/messages

- kubectl get <resource> [-o wide | json | yaml] [-n namespace]
-
- 获取资源的相关信息,-n指定命名空间,-o指定输出格式
- resource可以是具体资源名称,如"pod nhinx-xxx";也可以是资源类型,
- 如“pod,node,svc,deploy”多种资源使用逗号间隔;或者all(仅展示几种核心资源,并不完整)
-
- –all-namespaces或-A:表示显示所有命名空间
- –show-labels:显示所有标签
- -l app:仅显示标签为app的资源
- -l app=nginx:仅显示包含app标签,且值为nginx的资源
- kubectl get componentstatuses
-
- #componentstatues可以缩写成cs
- kubectl get cs

- kubectl get namespace
-
- #namespace可以缩写成ns
- kubectl get ns

- kubectl get all [-n default]
-
- 由于deafult为缺省空间,当不指定命名空间时默认查看default命名空间

- kubectl create ns test
-
- kubectl get ns

kubectl delete ns test

在命名空间kube-public创建副本控制器(deployment)来启动Pod(nginx-test)
kubectl create deployment nginx-test --image=nginx -n kube-public

kubectl describe deployment nginx-test -n kube-public

- kubectl get pods -A
-
-
- kubectl describe pod nginx-test-795d659f45-6kqbw -n kube-public

kubectl get pods -n kube-public

- kubectl exec 可以跨主机登录容器,docker exec 只能在容器所在主机登录
-
- kubectl exec -it nginx-test-795d659f45-6kqbw -n kube-public bash

- 由于存在 deployment/rc 之类的副本控制器,删除 pod 也会重新拉起来
-
- kubectl delete pod nginx-test-795d659f45-6kqbw -n kube-public
- kubectl get pod -n kube-public

若无法删除,总是处于terminate状态,则要强行删除pod
- kubectl delete pod [] -n [] --force --grace-period=0
-
- grace-period表示过渡存活期,默认30s,在删除pod之前允许pod慢慢终止其上的容器进程,
- 从而优雅的退出,0表示立即终止pod

kubectl scale deployment nginx-test --replicas=3 -n kube-public

kubectl scale deployment nginx-test --replicas=1 -n kube-public

kubectl delete deployment nginx-test -n kube-public

kubectl label deploy nginx-test version=nginx1.14

kubectl label deploy nginx-test version-

适合于对资源的修改操作
声明式资源管理方法依赖于资源配置清明文件对资源进行管理
资源配置清单文件有两种格式:yaml(人性化,易读),json(易于api接口解析)
对资源的观念里,是通过实现定义在同一资源配置清单内,再通过陈述式命令应用到k8s集群里
语法格式:kubectl create/apply/delete -f -o yaml
kubectl get deploy/nginx-test -o yaml

kubectl get service nginx-service -o yaml

kubectl explain deployment.metadata

修改yaml文件
- 修改yaml文件:并用kubectl apply -f xxxx.yaml文件使之生效
- 注意:当apply不生效时,先使用delete清除资源,再apply创建资源
-
-
- kubectl get service nginx-service -o yaml > nginx-svc.yaml

kubectl delete -f nginx-svc.yaml

kubectl apply -f nginx-svc.yaml

kubectl get svc

- 直接使用kubectl edit service nginx-service在线编辑配置资源清单并保存退出即时生效
-
- PS:此修改方式不会对yaml文件内容修改
-
- kubectl edit service nginx-service

陈述式删除
kubectl delete service nginx-service
声明式删除
kubectl delete -f nginx-svc.yaml
Kubectl是管理k8s集群的命令行工具,通过生成的json格式传递给apiserver进行创建、查看、管理的操作。
- //帮助信息
- [root@localhost bin]# kubectl --help
- kubectl controls the Kubernetes cluster manager.
-
- Find more information at: https://kubernetes.io/docs/reference/kubectl/overview/
-
- Basic Commands (Beginner):
- create Create a resource from a file or from stdin.
- expose 使用 replication controller, service, deployment 或者 pod
- 并暴露它作为一个 新的 Kubernetes Service
- run 在集群中运行一个指定的镜像
- set 为 objects 设置一个指定的特征
-
- Basic Commands (Intermediate):
- explain 查看资源的文档
- get 显示一个或更多 resources
- edit 在服务器上编辑一个资源
- delete Delete resources by filenames, stdin, resources and names, or by resources and
- label selector
-
- Deploy Commands:
- rollout Manage the rollout of a resource
- scale 为 Deployment, ReplicaSet, Replication Controller 或者 Job
- 设置一个新的副本数量
- autoscale 自动调整一个 Deployment, ReplicaSet, 或者 ReplicationController
- 的副本数量
-
- Cluster Management Commands:
- certificate 修改 certificate 资源.
- cluster-info 显示集群信息
- top Display Resource (CPU/Memory/Storage) usage.
- cordon 标记 node 为 unschedulable
- uncordon 标记 node 为 schedulable
- drain Drain node in preparation for maintenance
- taint 更新一个或者多个 node 上的 taints
-
- Troubleshooting and Debugging Commands:
- describe 显示一个指定 resource 或者 group 的 resources 详情
- logs 输出容器在 pod 中的日志
- attach Attach 到一个运行中的 container
- exec 在一个 container 中执行一个命令
- port-forward Forward one or more local ports to a pod
- proxy 运行一个 proxy 到 Kubernetes API server
- cp 复制 files 和 directories 到 containers 和从容器中复制 files 和
- directories.
- auth Inspect authorization
-

创建–>发布–>更新–>回滚–>删除
创建并运行一个或多个容器镜像
创建一个deployment或job来管理容器
kubectl run --help查看使用帮助
启动nginx实例,暴露容器端口80,设置副本数3
kubectl run nginx-deployment --image=nginx:1.14 --port=80 --replicas=3

使用run报错
k8sv1.18.0以后的版本, --replicas以后弃用该命令,推荐使用deployment创建pods
我这里用的是1.21.3版本
想创建多个实例时可以使用:kubectl create deployment pg102 --image=pg:12
–port=5432 --replicas=3 来进行创建;
查看pod: kubectl get pod,用来查看使用命令创建的所有实例
查看deploy:kubectl get deploy,用来查看实例所创建的数量;
高于1.17版本的建议以后直接使用create deployment创建pod管理器方式创建pod;
kubectl create deployment nginx --image=nginx:1.14 --port=80 --replicas=3


将资源暴露为新的Service
为Deployment的nginx创建Service,并通过Service的80端口转发至容器的80端口上,Service的名称为nginx-service,类型为NodePort
kubectl expose deployment nginx2 --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。
ClusterIP:提供一个集群内部的虚拟IP以供Pod访问(Service默认类型)
NodePort:在每个Node上打开一个端口以供外部访问,Kubernetes将会在每个Node上打开一个端口并且每个Node的端口都是一样的,通过NodeIP:NodePort的方式
LoadBalancer:通过外部的负载均衡器来访问,通常在云平台部署LoadBalancer还需要额外的费用。
kubectl get pods,svc -o wide

kubectl get endpoints

kubectl describe svc nginx

curl 10.96.83.182

- kubectl describe svc nginx | grep NodePort
- curl 192.168.58.22:31979


更改现有应用资源一些信息。
kubectl set --help查看使用帮助
kubectl set image --help获取

curl -I 192.168.58.22:31979

kubectl set image deployment/nginx2 nginx=nginx:1.15

处于动态监听pod状态,由于使用的是滚动更新方式,所以会先生成一个新的pod,然后删除一个旧的pod,往后以此类推
kubectl get pods -w

注:更新规则可通过“kubetl describe deployment nginx”的“RollingUpdateStrategy”查看,默认配置为“25% max unavailable, 25% max surge”,即按照25%的比例进行滚动更新。

kubectl get pod -o wide

kubectl rollout --help查看使用帮助
kubectl rollout history deployment/nginx2

- kubectl rollout undo deployment/nginx2
- kubectl get pods -o wide

查看nginx当前版本

查看历史版本

回到revison2,即1.15版本
kubectl rollout undo deployment/nginx2 --to-revision=2

查看当前nginx版本

kubectl rollout status deployment/nginx

kubectl delete deployment/nginx-test

kubectl delete svc/nginx-service

金丝雀发布/灰度发布(Canary Release)
Deployment控制器支持自定义控制更新过程中的滚动节奏,如“暂停(pause)”或“继续(resume)”更新操作。比如等待第一批新的Pod资源创建完成后立即暂停更新过程,此时,仅存在一部分新版本的应用,主体部分还是旧的版本。然后,在筛选一小部分的用户请求路由到新版本的Pod应用,继续观察能否稳定地按期望的方式运行。确定没问题之后再继续完成余下的Pod资源滚动更新,否则立即回滚更新操作。这就是所谓的金丝雀发布。
- kubectl create deployment nginx-test --image=nginx:1.14 --replicas=3
- kubectl get pods,deploy -o wide

- kubectl expose deploy nginx-test --port=80 --target-port=80 --name=nginx-service --type=NodePort
- kubectl get svc -o wide

- curl -I 192.168.58.22:32624
- kubectl describe deployment nginx-test | grep Image

在不定义CHANGE-CAUSE的情况下,缺省值为,当历史版本较多时,不便于咱们回滚时辨认版本号。因此,建议定义CHANGE-CAUSE为服务版本以帮助咱们辨认当前服务。
kubectl rollout history deploy/nginx-test

一般通过修改配置的方式定义change-cause
- [root@master ~]# kubectl edit deploy/nginx-test
-
- ......
- kind: Deployment
- metadata:
- annotations:
- #下行可定义历史版本revision
- deployment.kubernetes.io/revision: "1"
- #在Deployment的matadata项下的annotations中如下行定义change-cause
- kubernetes.io/change-cause: "nginx1.14"
- ......
-
kubectl rollout history deploy/nginx-test

kubectl set image deploy/nginx-test nginx=nginx:1.15 && kubectl rollout pause deploy/nginx-test

可以看到已经新增了一个pod,但是并未按照预期的状态去删除一个旧的资源,就是因为使用了pause暂停命令
kubectl get pods -w

kubectl get pod -o wide

kubectl rollout history deploy/nginx-test

- [root@master ~]# kubectl edit deploy/nginx-test
-
- kind: Deployment
- metadata:
- annotations:
- #下行的revison自动更新为2
- deployment.kubernetes.io/revision: "2"
- #修改下行的change-cause为nginx1.15
- kubernetes.io/change-cause: nginx1.15
-


测试新版本没问题继续更新
- kubectl rollout resume deploy/nginx-test
- kubectl get pods -w

- ●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
Kubernetes支持YAML和JSON格式创建资源对象
JSON格式用于接口之间消息的传递
YAML格式用于配置和管理
YAML的配置参数格式比较清晰

- kubectl apply -f nginx-deploy.yaml
- 发布 nginx pod -f 调用yaml 文件
- Apply 会检测yaml 文件区别,有没有更新,有更新会重新创建,替换


将yaml 文件中nginx 版本修改为1.12
Apply 会检测yaml 文件区别,有没有更新,有更新会重新创建,替换

修改完之后重新发布yaml 文件,发现有更新


- 第二种方式
- kubectl get pod -o wide
- kubectl edit pod nginx-deployment-f77774fc5-sd975 -n default
- 进入指定的pod 的yaml 文件





删除修改的pod 进行验证



- kubectl get all -A |grep nginx-deployment
-
- 当不知道yaml 文件在哪时,过滤出控制器

进入pod 的yaml 文件




调度器通过kubernetes的list-watch机制来发现集群中新创建且尚未被调度到Node上的Pod。调度器会将发现的每一个未调度的Pod调度到一个合适的Node上来运行。
kube-scheduler是Kubernetes集群的默认调度器,并且是集群控制面的一部分。如果你真的希望或者有这方面的需求,kube-scheduler在设计上是允许你自己写一个调度组件并替换原有的kube-scheduler。
在做调度决定时需要考虑的因素包括:单独和整体的资源请求、硬件/软件/策略限制、亲和以及反亲和要求、数据局域性、负载间的干扰等等。
K8s 每个节点上都可以应用一个或多个 taint ,这表示对于那些不能容忍这些 taint 的 pod,是不会被该节点接受的。如果将 toleration 应用于 pod 上,则表示这些 pod 可以(但不要求)被调度到具有相应 taint 的节点上。
如果一个节点被标记为有污点,那么意味着不允许pod调度到该节点,除非pod也被标记为可以容忍污点节点。
在使用kubeadm部署的k8s集群的时候应该会发现,通常情况下,应用是不会调度到master节点的。因为kubeadm部署的k8s集群默认给master节点加了Taints(污点)。
每个污点有一个key和value作为污点的标签,其中value可以为空,effect描述污点的作用。
污点有三种策略:
PreferNoSchedule:NoSchedule的软策略版本,表示尽量不调度到污点节点上去。
NoExecute:该选项意味着一旦Taint生效,如该节点内正在运行的Pod没有对应容忍(Tolerate)设置,则会直接被逐出。
NoSchedule:表示k8s将不会将Pod调度到具有该污点的Node上
设置了污点的Node将根据taint的effect:NoSchedule、PreferNoSchedule、NoExecute和Pod之间产生互斥的关系,Pod将在一定程度上不会被调度到Node上。 但我们可以在Pod上设置容忍(Toleration),意思是设置了容忍的Pod将可以容忍污点的存在,可以被调度到存在污点的Node上。