目录
3.4.2、查看命名空间kube-public中的pod信息
1、更新deployment的版本，并配置暂停deployment
一、陈述式管理
1、陈述式资源管理方法
kubernetes 集群管理集群资源的唯一入口是通过相应的方法调用 apiserver 的接口
kubectl 是官方的 CLI 命令行工具，用于与 apiserver 进行通信，将用户在命令行输入的命令，组织并转化为apiserver 能识别的信息，进而实现管理 k8s 各种资源的一种有效途径
kubectl 的命令大全
kubectl --help
k8s官方中文文档：http://docs.kubernetes.org.cn/683.html对资源的增、删、查操作比较容易，但对改的操作就不容易了
2、k8s相关信息查看
2.1、查看版本信息
kubectl version
2.2、查看节点信息
kubectl get nodes
2.3、查看资源对象简写
kubectl api-resources
2.4、查看集群信息
kubectl cluster-info
2.5、配置kubectl自动补全
source <(kubectl completion bash)
注意：此时命令补全功能切换环境后是不生效的，如果要使切换环境后也生效需要配置全局环境变量
可通过TAB键实现命令补全，建议将其写入 /etc/profile
2.6、master节点查看日志
journalctl -u kubelet -f
或者直接查看日志
cat /var/log/messages
3、基本信息查看
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的资源3.1、查看master节点状态
kubectl get componentstatuses
#componentstatues可以缩写成cs
kubectl get cs
3.2、查看命名空间
kubectl get namespace
#namespace可以缩写成ns
kubectl get ns
3.3、命名空间操作
3.3.1、查看default命名空间的所有资源
kubectl get all [-n default]
由于deafult为缺省空间，当不指定命名空间时默认查看default命名空间
3.3.2、创建命名空间
kubectl create ns test
kubectl get ns
3.3.3、删除命名空间
kubectl delete ns test
3.4、deployment/pod操作
在命名空间kube-public创建副本控制器（deployment）来启动Pod（nginx-test）
kubectl create deployment nginx-test --image=nginx -n kube-public
3.4.1、查看某个资源的详细信息
kubectl describe deployment nginx-test -n kube-public
kubectl get pods -A
kubectl describe pod nginx-test-795d659f45-6kqbw -n kube-public
3.4.2、查看命名空间kube-public中的pod信息
kubectl get pods -n kube-public
4、登录容器
kubectl exec 可以跨主机登录容器，docker exec 只能在容器所在主机登录
kubectl exec -it nginx-test-795d659f45-6kqbw -n kube-public bash
4.1、删除（重启）pod资源
由于存在 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
5、扩缩容
5.1、扩容
kubectl scale deployment nginx-test --replicas=3 -n kube-public
5.2、缩容
kubectl scale deployment nginx-test --replicas=1 -n kube-public
6、删除副本控制器
kubectl delete deployment nginx-test -n kube-public
7、增加/删除label
7.1、增加label
kubectl label deploy nginx-test version=nginx1.14
7.2、删除label
kubectl label deploy nginx-test version-
二、声明式管理
1、声明式管理方法
适合于对资源的修改操作
声明式资源管理方法依赖于资源配置清明文件对资源进行管理
资源配置清单文件有两种格式：yaml（人性化，易读），json（易于api接口解析）
对资源的观念里，是通过实现定义在同一资源配置清单内，再通过陈述式命令应用到k8s集群里
语法格式：kubectl create/apply/delete -f -o yaml
2、查看资源配置清单
kubectl get deploy/nginx-test -o yaml
kubectl get service nginx-service -o yaml
2.1、解释资源配置清单
kubectl explain deployment.metadata
3、修改资源配置清单并应用
3.1、离线修改
修改yaml文件
修改yaml文件：并用kubectl apply -f xxxx.yaml文件使之生效
注意：当apply不生效时，先使用delete清除资源，再apply创建资源
kubectl get service nginx-service -o yaml > nginx-svc.yaml
3.2、删除资源
kubectl delete -f nginx-svc.yaml
3.3、新建资源
kubectl apply -f nginx-svc.yaml
3.4、查看service资源
kubectl get svc
3.5、在线修改
直接使用kubectl edit service nginx-service在线编辑配置资源清单并保存退出即时生效
PS：此修改方式不会对yaml文件内容修改
kubectl edit service nginx-service
3.6、删除资源配置清单
陈述式删除
kubectl delete service nginx-service
声明式删除
kubectl delete -f nginx-svc.yaml
三、K8S模拟项目
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
1、项目的生命周期
创建–>发布–>更新–>回滚–>删除
2、创建kubectl run命令
创建并运行一个或多个容器镜像
创建一个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
3、发布kubectl expose命令
将资源暴露为新的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
3.1、Service的作用
Kubernetes之所以需要Service，一方面是因为Pod的IP不是固定的（Pod可能会重建），另一方面是因为一组Pod实例之间总会有负载均衡的需求。
Service通过Label Selector实现的对一组的Pod的访问。
对于容器应用而言，Kubernetes提供了基于VIP（虚拟IP）的网桥的方式访问Service，再由Service重定向到相应的Pod。
3.2、Service的类型
ClusterIP:提供一个集群内部的虚拟IP以供Pod访问（Service默认类型）
NodePort:在每个Node上打开一个端口以供外部访问，Kubernetes将会在每个Node上打开一个端口并且每个Node的端口都是一样的，通过NodeIP:NodePort的方式
LoadBalancer:通过外部的负载均衡器来访问，通常在云平台部署LoadBalancer还需要额外的费用。
3.3、查看Pod网络状态详细信息和Service暴露端口
kubectl get pods,svc -o wide
3.4、查看关联后端的节点
kubectl get endpoints
3.5、查看service的描述信息
kubectl describe svc nginx
3.6、访问查看
curl 10.96.83.182
kubectl describe svc nginx | grep NodePort
curl 192.168.58.22:31979
3.7、查看访问日志
4、更新kubectl set
更改现有应用资源一些信息。
kubectl set --help查看使用帮助
4.1、获取修改模板
kubectl set image --help获取
4.2、查看当前nginx的版本号
curl -I 192.168.58.22:31979
4.3、将nginx版本更新为1.15
kubectl set image deployment/nginx2 nginx=nginx:1.15
4.4、监听pod状态
处于动态监听pod状态，由于使用的是滚动更新方式，所以会先生成一个新的pod，然后删除一个旧的pod，往后以此类推
kubectl get pods -w
注：更新规则可通过“kubetl describe deployment nginx”的“RollingUpdateStrategy”查看，默认配置为“25% max unavailable, 25% max surge”，即按照25%的比例进行滚动更新。
4.5、查看pod的ip变化
kubectl get pod -o wide
5、回滚kubectl rollout
- 对资源进行回滚管理
kubectl rollout --help查看使用帮助
5.1、查看历史回滚
kubectl rollout history deployment/nginx2
5.2、执行回滚到上一个版本
kubectl rollout undo deployment/nginx2
kubectl get pods -o wide
查看nginx当前版本
5.3、执行回滚到指定版本
查看历史版本
回到revison2，即1.15版本
kubectl rollout undo deployment/nginx2 --to-revision=2
查看当前nginx版本
5.4、检查回滚状态
kubectl rollout status deployment/nginx
6、删除kubectl delete
6.1、删除副本控制器
kubectl delete deployment/nginx-test
6.2、删除service
kubectl delete svc/nginx-service
四、金丝雀发布简介
金丝雀发布/灰度发布（Canary Release）
Deployment控制器支持自定义控制更新过程中的滚动节奏，如“暂停（pause）”或“继续（resume）”更新操作。比如等待第一批新的Pod资源创建完成后立即暂停更新过程，此时，仅存在一部分新版本的应用，主体部分还是旧的版本。然后，在筛选一小部分的用户请求路由到新版本的Pod应用，继续观察能否稳定地按期望的方式运行。确定没问题之后再继续完成余下的Pod资源滚动更新，否则立即回滚更新操作。这就是所谓的金丝雀发布。
1、更新deployment的版本，并配置暂停deployment
1.1、创建pod
kubectl create deployment nginx-test --image=nginx:1.14 --replicas=3
kubectl get pods,deploy -o wide
1.2、发布服务
kubectl expose deploy nginx-test --port=80 --target-port=80 --name=nginx-service --type=NodePort
kubectl get svc -o wide
1.3、查看nginx版本
curl -I 192.168.58.22：32624
kubectl describe deployment nginx-test | grep Image
2、定义版本change-cause
2.1、查看历史版本
在不定义CHANGE-CAUSE的情况下，缺省值为，当历史版本较多时，不便于咱们回滚时辨认版本号。因此，建议定义CHANGE-CAUSE为服务版本以帮助咱们辨认当前服务。
kubectl rollout history deploy/nginx-test
2.2、定义版本
一般通过修改配置的方式定义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"
......
2.3、再次查看历史版本
kubectl rollout history deploy/nginx-test
2.4、更新nginx版本为1.15并配置暂停
kubectl set image deploy/nginx-test nginx=nginx:1.15 && kubectl rollout pause deploy/nginx-test
2.5、观察更新状态
可以看到已经新增了一个pod，但是并未按照预期的状态去删除一个旧的资源，就是因为使用了pause暂停命令
kubectl get pods -w
2.6、查看nginx版本
kubectl get pod -o wide
2.7、查看并更新历史版本change-cause
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
2.8、resume继续更新
测试新版本没问题继续更新
kubectl rollout resume deploy/nginx-test
kubectl get pods -w
五、k8s中的port概述
●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
5.1、创建yaml文件模板
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 文件
六、K8s调度
调度器通过kubernetes的list-watch机制来发现集群中新创建且尚未被调度到Node上的Pod。调度器会将发现的每一个未调度的Pod调度到一个合适的Node上来运行。
kube-scheduler是Kubernetes集群的默认调度器，并且是集群控制面的一部分。如果你真的希望或者有这方面的需求，kube-scheduler在设计上是允许你自己写一个调度组件并替换原有的kube-scheduler。
在做调度决定时需要考虑的因素包括：单独和整体的资源请求、硬件/软件/策略限制、亲和以及反亲和要求、数据局域性、负载间的干扰等等。
6.1、污点与容忍
K8s 每个节点上都可以应用一个或多个 taint ，这表示对于那些不能容忍这些 taint 的 pod，是不会被该节点接受的。如果将 toleration 应用于 pod 上，则表示这些 pod 可以（但不要求）被调度到具有相应 taint 的节点上。
6.1.1、污点（Taint）
如果一个节点被标记为有污点，那么意味着不允许pod调度到该节点，除非pod也被标记为可以容忍污点节点。
在使用kubeadm部署的k8s集群的时候应该会发现，通常情况下，应用是不会调度到master节点的。因为kubeadm部署的k8s集群默认给master节点加了Taints（污点）。
每个污点有一个key和value作为污点的标签，其中value可以为空，effect描述污点的作用。
污点有三种策略：
PreferNoSchedule:NoSchedule的软策略版本，表示尽量不调度到污点节点上去。
NoExecute:该选项意味着一旦Taint生效，如该节点内正在运行的Pod没有对应容忍（Tolerate）设置，则会直接被逐出。
NoSchedule：表示k8s将不会将Pod调度到具有该污点的Node上
6.1.2、容忍（Tolerations）
设置了污点的Node将根据taint的effect：NoSchedule、PreferNoSchedule、NoExecute和Pod之间产生互斥的关系，Pod将在一定程度上不会被调度到Node上。 但我们可以在Pod上设置容忍(Toleration)，意思是设置了容忍的Pod将可以容忍污点的存在，可以被调度到存在污点的Node上。
原文链接：https://blog.csdn.net/weixin_56270746/article/details/126086760
此处评论已关闭