K8S常用命令

Posted 2022-11-25 _雪辉_

常用namespace操作：
kubectl get namespace, 查询所有namespace
kubectl create namespace name，创建namespace
kubectl delete namespace name, 删除namespace

常用node操作：
kubectl get nodes，查询所有node
kubectl cordon name, 将node标志为不可调度
kubectl uncordon name, 将node标志为可调度
(污点)

常用taint命令如下：
kubectl taint node node0 key1=value1:NoShedule，为node0设置不可调度污点
kubectl taint node node0 key-，将node0上key值为key1的污点移除
kubectl taint node node1 node-role.kubernetes.io/master=:NoSchedule，为kube-master节点设置不可调度污点
kubectl taint node node1 node-role.kubernetes.io/master=PreferNoSchedule，为kube-master节点设置尽量不可调度污点


4、Service

Service是对一组提供相同功能的Pods的抽象，并为他们提供一个统一的入口，借助 Service 应用可以方便的实现服务发现与负载均衡，并实现应用的零宕机升级。Service通过标签(label)来选取后端Pod，一般配合ReplicaSet或者Deployment来保证后端容器的正常运行。
service 有如下四种类型，默认是ClusterIP：
ClusterIP: 默认类型，自动分配一个仅集群内部可以访问的虚拟IP
NodePort: 在ClusterIP基础上为Service在每台机器上绑定一个端口，这样就可以通过 NodeIP:NodePort 来访问该服务
LoadBalancer: 在NodePort的基础上，借助cloud provider创建一个外部的负载均衡器，并将请求转发到 NodeIP:NodePort
ExternalName: 将服务通过DNS CNAME记录方式转发到指定的域名
另外，也可以将已有的服务以Service的形式加入到Kubernetes集群中来，只需要在创建 Service 的时候不指定Label selector，而是在Service创建好后手动为其添加endpoint。

5、Volume 存储卷

默认情况下容器的数据是非持久化的，容器消亡以后数据也会跟着丢失，所以Docker提供了Volume机制以便将数据持久化存储。Kubernetes提供了更强大的Volume机制和插件，解决了容器数据持久化以及容器间共享数据的问题。
Kubernetes存储卷的生命周期与Pod绑定
容器挂掉后Kubelet再次重启容器时，Volume的数据依然还在
Pod删除时，Volume才会清理。数据是否丢失取决于具体的Volume类型，比如emptyDir的数据会丢失，而PV的数据则不会丢
目前Kubernetes主要支持以下Volume类型：
emptyDir：Pod存在，emptyDir就会存在，容器挂掉不会引起emptyDir目录下的数据丢失，但是pod被删除或者迁移，emptyDir也会被删除
hostPath：hostPath允许挂载Node上的文件系统到Pod里面去
NFS（Network File System）：网络文件系统，Kubernetes中通过简单地配置就可以挂载NFS到Pod中，而NFS中的数据是可以永久保存的，同时NFS支持同时写操作。
glusterfs：同NFS一样是一种网络文件系统，Kubernetes可以将glusterfs挂载到Pod中，并进行永久保存
cephfs：一种分布式网络文件系统，可以挂载到Pod中，并进行永久保存
subpath：Pod的多个容器使用同一个Volume时，会经常用到
secret：密钥管理，可以将敏感信息进行加密之后保存并挂载到Pod中
persistentVolumeClaim：用于将持久化存储（PersistentVolume）挂载到Pod中
...

6、PersistentVolume(PV) 持久化存储卷

PersistentVolume(PV)是集群之中的一块网络存储。跟 Node 一样，也是集群的资源。PersistentVolume (PV)和PersistentVolumeClaim (PVC)提供了方便的持久化卷: PV提供网络存储资源，而PVC请求存储资源并将其挂载到Pod中。
PV的访问模式(accessModes)有三种:
ReadWriteOnce(RWO):是最基本的方式，可读可写，但只支持被单个Pod挂载。
ReadOnlyMany(ROX):可以以只读的方式被多个Pod挂载。
ReadWriteMany(RWX):这种存储可以以读写的方式被多个Pod共享。
不是每一种存储都支持这三种方式，像共享方式，目前支持的还比较少，比较常用的是 NFS。在PVC绑定PV时通常根据两个条件来绑定，一个是存储的大小，另一个就是 访问模式。
PV的回收策略(persistentVolumeReclaimPolicy)也有三种
Retain，不清理保留Volume(需要手动清理)
Recycle，删除数据，即 rm -rf /thevolume/* (只有NFS和HostPath支持)
Delete，删除存储资源

7、Deployment 无状态应用

一般情况下我们不需要手动创建Pod实例，而是采用更高一层的抽象或定义来管理Pod，针对无状态类型的应用，Kubernetes使用Deloyment的Controller对象与之对应。其典型的应用场景包括：
定义Deployment来创建Pod和ReplicaSet
滚动升级和回滚应用
扩容和缩容
暂停和继续Deployment

常用的操作命令如下：
kubectl run www--image=10.0.0.183:5000/hanker/www:0.0.1--port=8080 生成一个Deployment对象
kubectlgetdeployment--all-namespaces 查找Deployment
kubectl describe deployment www 查看某个Deployment
kubectl edit deployment www 编辑Deployment定义
kubectldeletedeployment www 删除某Deployment
kubectl scale deployment/www--replicas=2 扩缩容操作，即修改Deployment下的Pod实例个数
kubectlsetimage deployment/nginx-deployment nginx=nginx:1.9.1更新镜像
kubectl rollout undo deployment/nginx-deployment 回滚操作
kubectl rollout status deployment/nginx-deployment 查看回滚进度
kubectl autoscale deployment nginx-deployment--min=10--max=15--cpu-percent=80 启用水平伸缩（HPA - horizontal pod autoscaling），设置最小、最大实例数量以及目标cpu使用率
kubectl rollout pause deployment/nginx-deployment 暂停更新Deployment
kubectl rollout resume deploy nginx 恢复更新Deployment

更新策略
.spec.strategy 指新的Pod替换旧的Pod的策略，有以下两种类型
RollingUpdate 滚动升级，可以保证应用在升级期间，对外正常提供服务。
Recreate 重建策略，在创建出新的Pod之前会先杀掉所有已存在的Pod。
Deployment和ReplicaSet两者之间的关系
使用Deployment来创建ReplicaSet。ReplicaSet在后台创建pod，检查启动状态，看它是成功还是失败。
当执行更新操作时，会创建一个新的ReplicaSet，Deployment会按照控制的速率将pod从旧的ReplicaSet移 动到新的ReplicaSet中

8、StatefulSet 有状态应用

Deployments和ReplicaSets是为无状态服务设计的，那么StatefulSet则是为了有状态服务而设计，其应用场景包括：
稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现
稳定的网络标志，即Pod重新调度后其PodName和HostName不变，基于Headless Service(即没有Cluster IP的Service)来实现
有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次进行操作(即从0到N-1，在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态)，基于init containers来实现
有序收缩，有序删除(即从N-1到0)

支持两种更新策略：
OnDelete:当 .spec.template更新时，并不立即删除旧的Pod，而是等待用户手动删除这些旧Pod后自动创建新Pod。这是默认的更新策略，兼容v1.6版本的行为
RollingUpdate:当 .spec.template 更新时，自动删除旧的Pod并创建新Pod替换。在更新时这些Pod是按逆序的方式进行，依次删除、创建并等待Pod变成Ready状态才进行下一个Pod的更新。

9、DaemonSet 守护进程集

DaemonSet保证在特定或所有Node节点上都运行一个Pod实例，常用来部署一些集群的日志采集、监控或者其他系统管理应用。典型的应用包括:
日志收集，比如fluentd，logstash等
系统监控，比如Prometheus Node Exporter，collectd等
系统程序，比如kube-proxy, kube-dns, glusterd, ceph，ingress-controller等
指定Node节点
DaemonSet会忽略Node的unschedulable状态，有两种方式来指定Pod只运行在指定的Node节点上:
nodeSelector:只调度到匹配指定label的Node上
nodeAffinity:功能更丰富的Node选择器，比如支持集合操作
podAffinity:调度到满足条件的Pod所在的Node上

目前支持两种策略
OnDelete: 默认策略，更新模板后，只有手动删除了旧的Pod后才会创建新的Pod
RollingUpdate: 更新DaemonSet模版后，自动删除旧的Pod并创建新的Pod

10、Ingress

Kubernetes中的负载均衡我们主要用到了以下两种机制：
Service：使用Service提供集群内部的负载均衡，Kube-proxy负责将service请求负载均衡到后端的Pod中
Ingress Controller：使用Ingress提供集群外部的负载均衡

Service和Pod的IP仅可在集群内部访问。集群外部的请求需要通过负载均衡转发到service所在节点暴露的端口上，然后再由kube-proxy通过边缘路由器将其转发到相关的Pod，Ingress可以给service提供集群外部访问的URL、负载均衡、HTTP路由等，为了配置这些Ingress规则，集群管理员需要部署一个Ingress Controller，它监听Ingress和service的变化，并根据规则配置负载均衡并提供访问入口。
常用的ingress controller：
nginx
traefik
Kong
Openresty

11、Job & CronJob 任务和定时任务

Job负责批量处理短暂的一次性任务 (short lived>CronJob即定时任务，就类似于Linux系统的crontab，在指定的时间周期运行指定的任务。

12、HPA（Horizontal Pod Autoscaling） 水平伸缩

Horizontal Pod Autoscaling可以根据CPU、内存使用率或应用自定义metrics自动扩展Pod数量 (支持replication controller、deployment和replica set)。
控制管理器默认每隔30s查询metrics的资源使用情况(可以通过 --horizontal-pod-autoscaler-sync-period 修改)
支持三种metrics类型
预定义metrics(比如Pod的CPU)以利用率的方式计算
自定义的Pod metrics，以原始值(raw value)的方式计算
自定义的object metrics
支持两种metrics查询方式:Heapster和自定义的REST API
支持多metrics

可以通过如下命令创建HPA：kubectl autoscale deployment php-apache--cpu-percent=50--min=1--max=10

13、Service Account

Service account是为了方便Pod里面的进程调用Kubernetes API或其他外部服务而设计的

授权
Service Account为服务提供了一种方便的认证机制，但它不关心授权的问题。可以配合RBAC(Role Based Access Control)来为Service Account鉴权，通过定义Role、RoleBinding、ClusterRole、ClusterRoleBinding来对sa进行授权。

14、Secret 密钥

Sercert-密钥解决了密码、token、密钥等敏感数据的配置问题，而不需要把这些敏感数据暴露到镜像或者Pod Spec中。Secret可以以Volume或者环境变量的方式使用。有如下三种类型：
Service Account:用来访问Kubernetes API，由Kubernetes自动创建，并且会自动挂载到Pod的 /run/secrets/kubernetes.io/serviceaccount 目录中;
Opaque:base64编码格式的Secret，用来存储密码、密钥等;
kubernetes.io/dockerconfigjson: 用来存储私有docker registry的认证信息。

15、ConfigMap 配置中心

ConfigMap用于保存配置数据的键值对，可以用来保存单个属性，也可以用来保存配置文件。ConfigMap跟secret很类似，但它可以更方便地处理不包含敏感信息的字符串。ConfigMap可以通过三种方式在Pod中使用，三种分别方式为:设置环境变量、设置容器命令行参数以及在Volume中直接挂载文件或目录。

可以使用 kubectl create configmap从文件、目录或者key-value字符串创建等创建 ConfigMap。也可以通过 kubectl create-f value.yaml 创建。

16、Resource Quotas 资源配额

资源配额(Resource Quotas)是用来限制用户资源用量的一种机制。
资源配额有如下类型：
计算资源，包括cpu和memory
cpu, limits.cpu, requests.cpu
memory, limits.memory, requests.memory
存储资源，包括存储资源的总量以及指定storage class的总量
requests.storage:存储资源总量，如500Gi
persistentvolumeclaims:pvc的个数
storageclass.storage.k8s.io/requests.storage
storageclass.storage.k8s.io/persistentvolumeclaims
对象数，即可创建的对象的个数
pods, replicationcontrollers, configmaps, secrets
resourcequotas, persistentvolumeclaims
services, services.loadbalancers, services.nodeports
它的工作原理为:
资源配额应用在Namespace上，并且每个Namespace最多只能有一个 ResourceQuota 对象
开启计算资源配额后，创建容器时必须配置计算资源请求或限制(也可以 用LimitRange设置默认值)，用户超额后禁止创建新的资源