标签：kubectl 副本 service -- 陈述 Pod pod K8S 资源管理

K8S 陈述式资源管理方法

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

 

 

 

 

 

 

 #将33改为35，保存并退出

 

 

 #node节点查看日志

 

 

 基本信息查看

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 create deployment demo-ky33 --image=soscscs/myapp:v1 --port=80 --replicas=3

 

 

 

kubectl create deployment demo-ky33 --image=soscscs/myapp:v1 --port=80 --replicas=3 -n=ky33

 

 #删除ky33空间两个服务

 

 #还是会自动拉取两个服务，因为规定的是3个，所以控制器有个期待值，如低于期待值就会自动拉取跟期待值一样数量的服务

 

 

 #在命名空间kube-public 创建副本控制器（deployment）来启动Pod（nginx-yr）

 

kubectl exec可以跨主机登录容器

 #查看命名空间kube-public 中的pod 信息

 

 #查看相信信息，看在哪个节点上工作

 

 

 

 #在hanbao这个命名空间里创建几个服务，kubectl run  独立创建

 

 #五个服务一起无差别删除

 pod无法删除，总是处于terminate状态，则要强行删除pod

 

kubectl delete pod cks-5fdb44b57-9r47k -n ky33 --force --grace-period=0

#grace-period表示过渡存活期，默认30s，在删除pod之前允许pod慢慢终止其上的容器进程，从而优雅退出，0表示立即终止pod

 

 

kubectl scale deployment nginx-yr --replicas=2 -n kube-public

 

 

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

kubectl get all -n kube-public 

 

 

kubectl delete deployments nginx-yr -n kube-public

 

 

创建 kubectl create命令

项目的生命周期：创建-->发布-->更新-->回滚-->删除

●创建并运行一个或多个容器镜像。
●创建一个deployment 或job 来管理容器。
kubectl create --help

 

 

kubectl create deployment nginx --image=nginx:1.14 --port=80 --replicas=3

 

 

发布 kubectl expose命令

●将资源暴露为新的 Service。
kubectl expose --help

 

 

kubectl expose deployment nginx --port=80 --target-port=80 --name=nginx-service --type=NodePort

为deployment的nginx创建service，并通过Service的80端口转发至容器的80端口上，Service的名称为nginx-service，类型为NodePort

Kubernetes 之所以需要 Service，一方面是因为 Pod 的 IP 不是固定的（Pod可能会重建），另一方面则是因为一组 Pod 实例之间总会有负载均衡的需求。
Service 通过 Label Selector 实现的对一组的 Pod 的访问。
对于容器应用而言，Kubernetes 提供了基于 VIP（虚拟IP） 的网桥的方式访问 Service，再由 Service 重定向到相应的 Pod。

service 的 type 类型：
●ClusterIP：提供一个集群内部的虚拟IP以供Pod访问（service默认类型)

●NodePort：在每个Node上打开一个端口以供外部访问，Kubernetes将会在每个Node上打开一个端口并且每个Node的端口都是一样的，通过 NodeIp:NodePort 的方式Kubernetes集群外部的程序可以访问Service。
每个端口只能是一种服务，端口范围只能是 30000-32767。

●LoadBalancer：通过设置LoadBalancer映射到云服务商提供的LoadBalancer地址。这种用法仅用于在公有云服务提供商的云平台上设置Service的场景。通过外部的负载均衡器来访问，通常在云平台部署LoadBalancer还需要额外的费用。
在service提交后，Kubernetes就会调用CloudProvider在公有云上为你创建一个负载均衡服务，并且把被代理的Pod的IP地址配置给负载均衡服务做后端。

●externalName：将service名称映射到一个DNS域名上，相当于DNS服务的CNAME记录，用于让Pod去访问集群外部的资源，它本身没有绑定任何的资源。

 查看pod网络状态详细信息和 Service暴露的端口

 

 

 

 

 

 

 

 

 

 

更新 kubectl set

●更改现有应用资源一些信息。
kubectl set --help

 

 

 获取修改模板

 

 #将nginx 版本更新为 1.15 版本

处于动态监听 pod 状态，由于使用的是滚动更新方式，所以会先生成一个新的pod，然后删除一个旧的pod，往后依次类推

 #查看nginx版本号

 

#滚动更新详解：
kubectl get all
DESIRED：表示期望的状态是 10 个 READY 的副本
CURRENT：表示当前副本的总数: 即8 个日副本 + 5 个新副本
UP_TO-DATE：表示当前已经完成更新的副本数: 即 5个新副本
AVAILABLE：表示当前处于 READY 状态的副本数: 即8个日副本。

kubectl describe deployment/nginx
滚动更新通过参数 maxSurge 和 maxUnavailable 来控制副本替换的数量
maxSurge：此参数控制滚动更新过程中副本总数的超过 DESIRED 的上限。maxSurge 可以是具体的整数（比如 3），也可以是百分百，向上取整。maxSurge 默认值为 25%。
例如，DESIRED 为 10，那么副本总数的最大值为 10 + 10 * 25% = 13，即 CURRENT 为 13。

maxUnavailable：此参数控制滚动更新过程中，不可用的副本相占 DESIRED 的最大比例。maxUnavailable 可以是具体的整数（比如 3），也可以是百分百，向下取整。 maxUnavailable 默认值为 25%。
例如，DESIRED 为 10，那么可用的副本数至少要为 10 - 10 * 25% = 8，即 AVAILABLE 为 8。

因此 maxSurge 值越大，初始创建的新副本数量就越多；maxUnavailable 值越大，初始销毁的旧副本数量就越多。

理想情况下，DESIRED 为 10 的滚动更新的过程应该是这样的：
首先创建 3 个新副本使副本总数达到 13 个。
然后销毁 2 个旧副本使可用的副本数降到 8 个。
当这 2 个旧副本成功销毁后，可再创建 2 个新副本，使副本总数保持为 13 个。
当新副本通过 Readiness 探测后，会使可用副本数增加，超过 8。
进而可以继续销毁更多的旧副本，使可用副本数回到 8。
旧副本的销毁使副本总数低于 13，这样就允许创建更多的新副本。
这个过程会持续进行，最终所有的旧副本都会被新副本替换，滚动更新完成。

 

 #版本修改之前的podIP

 

 #版本修改之后的podIP，发生改变

 

 

 

 

 

 

kubectl rollout undo deployment/nginx

 

 

kubectl rollout undo deployment/nginx --to-revision=2

 

 

删除 kubectl delete

 

 

 

 

 

 

 

kubectl delete svc $(kubectl get svc | awk 'NR>=2{print $1}'|grep -v -w  kubernetes)

 

总结

kubect 命令格式管理K8S
1）陈述式管理方式(可理解成使用一条kubectl命令以及参数选项来事先资源对象的管理操作)
kubectl get   -n <命名空间>  <资源类型/all> [资源类型] [-o wide/yaml/json/  --show-labels -i 标签key=value]   #<> 里代表必选，[]代表可选，all包含pod控制器，[pod、service资源]
kubectl create  -n <命名空间>  <资源类型> <资源名称> [选项]
如创建控制器  资源类型[deploymet]   选项[--image 容器镜像  --port 容器端口 --replicas Pod副本数]
kubectl run <Pod资源名称>  --image 容器镜像  --port 容器端口  #创建独立的pod
kubectl delete -n <命名空间>  <资源类型> <资源名称> | --all 删除命名空间下所有指定的资源  |--force --grace-period=0 立即终止Pod容器并强制删除

kubectl describe -n <命名空间>  <资源类型> <资源名称> #查看资源的详细信息
kubectl exec -n <命名空间> -it <Pod资源名称> [-c 容器名称] -- sh|bash|Linux命令
kubectl logs -n <命名空间> <Podi资源名称> [-c 容器名称] [-f 实时查看] [-p #查看容器重启前的日志信息]
kubectl scale -n <命名空间> <Pod控制器资源类型 如:deployment|statefulset> <资源名称> --replaicas=Pod副本数

kubectl expose -n <命名空间> deployment <资源名称> --name <svc资源名称> --type <svc类型> --port <clusterIP的端口> --target-port <容器端口>

kubectl create svc <service类型> <service资源名称> --tcp=<clusterIP的端口:容器端口>

kubectl set image <Pod控制器资源类型，常用:deployment|daemonset> <资源名称> <容器名>=<容器镜像>

kubectl set selector <资源类型 service > <资源名称> '标签key=value'

kubectl rollout history <Pod控制器资源类型 有:deployment|daemonset|statefulset> <资源名称>

kubectl rollout undo <Pod控制器资源类型> <资源名称> #回滚



#service四种的基本类型:
ClusterIP: 默认的service资源的类型，可提供clusterIP:port供K8S集群内部访问
NodePort: 会在每个node节点上都开启相同的端口，K8S集群外部或内部的用户都可以通过nodeIP:nodeport来访问service及其关联的pod
LoadBalancer: 使用云负载设备和service做映射，外部用户通过访问云负载设备即可将请求转发到K8Snode节点，再通过nodeIP:nodeport来访问service及其关联的pod
ExternalName: 相当于给一个外部地址(域名或IP)作别名，K8S集群内的Pod可以通过这个service访问相关的外部服务

# service是通过 标签选择器 来关联Pod的标签 来自动发现Pod的端点(PodIP:containerport)


#service 的端口
port: service的clusterIP使用的端口，只能在K8S集群内部被访问到。K8S集群内部的客户端可以通过clusterIP:port来访问service

nodeport: 在NodePort类型的service使用的端口，会在每个node节点上都开启相同的端口，也就是nodeIP使用的端口(默认范围: 30000~32767)、K8S集群外部的客户端通过NodeIP:nodeport来访问service

targetport: pod容器使用的端口。service会将发送给port或nodeport的请求转发给pod容器，配置要与containerport一致

Pod容器的端口
containerport: 创建Pod时锁指定的容器端口

#查看service关联的Port端口
kubectl describe svc <资源名称>
kubectl get endpoints [svc的资源名称]
kubectl describe endpoints <资源名称>

deployment 控制器更新Pod的方式是 RollingUpdate(滚动更新)
RollingUpdateStrategy(滚动更新策略): 25% max unavailable,25% max surge

Rrplicas: 3 desired  控制器的期望副本数
25% max surge  滚动更新时允许创建的最大副本数比列，向上取整
25% max unavailable  滚动更新时允许销毁的最大副本数比列，向下取整

假设期望的副本数是3，那么滚动更新时能够创建的副本数时 3 * 25% = 0.075 向上取整为 1，更新时能够销毁的副本数是 0

假设期望的副本数是10, 10 * 0.25 = 2.5 向上取整为 3  向上取整为 2. 整个滚动更新过程中Pod副本数始终处在 (10-2) <= Pod副本数 <= (10+3) 之间

 

标签：kubectl,副本,service,--,陈述,Pod,pod,K8S,资源管理
From： https://www.cnblogs.com/yanrui07/p/18034739