(三)Kubernetes 快速入门

 Kubernetes的核心对象

API Server提供了RESTful风格的编程接口,其管理的资源是Kubernetes API中的端点,用于存储某种API对象的集合,例如,内置Pod资源是包含了所有Pod对象的集合。资源对象是用于表现集群状态的实体,常用于描述应于哪个节点进行容器化应用、需要为其配置什么资源以及应用程序的管理策略等,例如,重启、升级及容错机制。另外,一个对象也是一种“意向记录“——一旦创建,Kubernetes就需要一直确保对象始终存在。PodDeploymentService等都是最常用的核心对象。

Pod资源对象

Pod资源对象是一种集合了一到多个应用容器、存储资源、专用IP及支撑容器运行的其他选项的逻辑组件,如图所示。Pod代表着Kubernetes的部署单元及原子运行单元,即一个应用程序的单一运行实例,它通常由共享资源且关系紧密的一个或多个应用容器组成。

Kubernetes的网络模型要求其各Pod对象的IP地址位于同一网络平面内(同一IP网段),各Pod之间可使用其IP地址直接进行通信,无论它们运行于集群内的哪个工作节点上,这些Pod对象都像运行于同一局域网中的多个主机。

不过,Pod对象中的各进程均运行于彼此隔离的容器中,并于容器间共享两种关键资源:网络存储卷

  • 网络:每个Pod对象都会被分配一个集群内专用的IP地址,也称为Pod IP,同一Pod内部的所有容器共享Pod对象的NetworkUTS名称空间,其中包括主机名、IP地址和端口等。因此,这些容器间的通信可以基于本地回环接口lo进行,而与Pod外的其他组件的通信则需要使用Service资源对象的ClusterIP及相应的端口完成。

  • 存储卷:用户可以为Pod对象配置一组“存储卷”资源,这些资源可以共享给其内部的所有容器使用,从而完成容器间数据的共享。存储卷还可以确保在容器终止后重启,甚至是被删除后也能确保数据不会丢失,从而保证了生命周期内的Pod对象数据的持久化存储。

一个Pod对象代表某个应用程序的一个特定实例,如果需要扩展应用程序,则意味着为此应用程序同时创建多个Pod实例,每个实例均代表应用程序的一个运行的“副本”(replica)。这些副本化的Pod对象的创建和管理通常由另一组称为“控制器”(Controller)的对象实现,例如,Deployment控制器对象。

创建Pod时,还可以使用Pod Preset对象为Pod注入特定的信息,如ConfigMapSecret、存储卷、挂载卷和环境变量等。有了Pod Preset对象,Pod模板的创建者就无须为每个模板显示提供所有信息,因此,也就无须事先了解需要配置的每个应用的细节即可完成模板定义。

基于期望的目标状态和各节点的资源可用性,Master会将Pod对象调度至某选定的工作节点运行,工作节点于指向的镜像仓库(image register)下载镜像,并于本地的容器运行时环境中启动容器。Master会将整个集群的状态保存于etcd中,并通过API Server共享给集群的各组件及客户端。

Controller

Kubernetes集群的设计中,Pod是有生命周期的对象。通过手动创建或由Controller(控制器)直接创建的Pod对象会被“调度器”(Scheduler)调度至集群中的某工作节点运行,待到容器应用进程运行结束之后正常终止,随后就会被删除。另外,节点资源耗尽或故障也会导致Pod对象被回收。

Pod对象本身并不具有“自愈”功能,若是因为工作节点甚至是调度器自身导致了运行失败,那么它将会被删除;同样,资源耗尽或节点故障导致的回收操作也会删除相关的Pod对象。在设计上,Kubernetes使用”控制器“实现对一次性的(用后即弃)Pod对象的管理操作,例如,要确保部署的应用程序的Pod副本数量严格反映用户期望的数目,以及基于Pod模板来创建Pod对象等,从而实现Pod对象的扩缩容、滚动更新和自愈能力等。例如,某节点发生故障时,相关的控制器会将此节点上运行的Pod对象重新调度到其他节点进行重建。

控制器本身也是一种资源类型,它有着多种实现,其中与工作负载相关的实现如Replication ControllerDeploymentStatefulSetDaemonSetJobs等,也可统称它们为Pod控制器。

Pod控制器的定义通常由期望的副本数量、Pod模板和标签选择器(Label Selector)组成。Pod控制器会根据标签选择器对Pod对象的标签进行匹配检查,所有满足选择条件的Pod对象都将受控于当前控制器并计入其副本总数,并确保此数目能够精确反映期望的副本数。

Service

尽管Pod对象可以拥有IP地址,但此地址无法确保在Pod对象重启或被重建后保持不变,这会为集群中的Pod应用间依赖关系的维护带来麻烦:前端Pod应用(依赖方)无法基于固定地址持续跟踪后端Pod应用(被依赖方)。于是,Service资源被用于在被访问的Pod对象中添加一个有这固定IP地址的中间层,客户端向此地址发起访问请求后由相关的Service资源调度并代理至后端的Pod对象。

换言之,Service是“微服务”的一种实现,事实上它是一种抽象:通过规则定义出由多个Pod对象组合而成的逻辑集合,并附带访问这组Pod对象的策略。Service对象挑选、关联Pod对象的方式同Pod控制器一样,都是要基于Label Selector进行定义,其示意图如下

Service IP是一种虚拟IP,也称为Cluster IP,它专用于集群内通信,通常使用专用的地址段,如“10.96.0.0/12”网络,各Service对象的IP地址在此范围内由系统动态分配。

集群内的Pod对象可直接请求此类的Cluster IP,例如,图中来自Pod client的访问请求即可以ServiceCluster IP作为目标地址,但集群网络属于私有网络地址,它们仅在集群内部可达。将集群外部的访问流量引入集群内部的常用方法是通过节点网络进行,实现方法是通过工作节点的IP地址和某端口(NodePort)接入请求并将其代理至相应的Service对象的Cluster IP上的服务端口,而后由Service对象将请求代理至后端的Pod对象的Pod IP及应用程序监听的端口。因此,图中的External Clients这种来自集群外部的客户端无法直接请求此Service提供的服务,而是需要事先经由某一个工作节点(如NodeY)的IP地址进行,这类请求需要两次转发才能到达目标Pod对象,因此在通信效率上必然存在负面影响。

事实上,NodePort会部署于集群中的每一个节点,这就意味着,集群外部的客户端通过任何一个工作节点的IP地址来访问定义好的NodePort都可以到达相应的Service对象。此种场景下,如果存在集群外部的一个负载均衡器,即可将用户请求负载均衡至集群中的部分或者所有节点。这是一种称为“LoadBalancer”类型的Service,它通常是由Cloud Provider自动创建并提供的软件负载均衡器,不过,也可以是有管理员手工配置的诸如F5一类的硬件设备。

简单来说,Service主要有三种常用类型:第一种是仅用于集群内部通信的ClusterIP类型;第二种是接入集群外部请求的NodePort类型,它工作与每个节点的主机IP之上;第三种是LoadBalancer类型,它可以把外部请求负载均衡至多个Node的主机IPNodePort之上。此三种类型中,每一种都以其前一种为基础才能实现,而且第三种类型中的LoadBalancer需要协同集群外部的组件才能实现,并且此外部组件并不接受Kubernetes的管理。

命令式容器应用编排

部署应用Pod

Kubernetes集群上自主运行的Pod对象在非计划内终止后,其生命周期即告结束,用户需要再次手动创建类似的Pod对象才能确保其容器中的依然可得。对于Pod数量众多的场景,尤其是对微服务业务来说,用户必将疲于应付此类需求。Kubernetes的工作负载(workload)类型的控制器能够自动确保由其管控的Pod对象按用户期望的方式运行,因此,Pod的创建和管理大多会通过这种类型的控制器来进行,包括DeploymentReplicasSetReplicationController等。

1)创建Deployment控制器对象

kubectl run命令可用于命令行直接创建Deployment控制器,并以 --image选项指定的镜像运行Pod中的容器,--dry-run选项可以用于命令的测试,但并不真正执行资源对象的创建过程。

1# 创建一个名字叫做nginx的deployment控制器,并指定pod镜像使用nginx:1.12版本,并暴露容器内的80端口,并指定副本数量为1个,并先通过--dry-run测试命令是否错误。 2[root@k8s-master ~]# kubectl run nginx --image=nginx:1.12 --port=80 --replicas=1 --dry-run=true 3[root@k8s-master ~]# kubectl run nginx --image=nginx:1.12 --port=80 --replicas=1 4deployment.apps/nginx created 5 6[root@k8s-master ~]# kubectl get pods #查看所有pod对象 7NAME READY STATUS RESTARTS AGE 8nginx-685cc95cd4-9z4f4 1/1 Running 0 89s 9 10 11###参数说明: 12--image 指定需要使用到的镜像。 13--port 指定容器需要暴露的端口。 14--replicas 指定目标控制器对象要自动创建Pod对象的副本数量。

2)打印资源对象的相关信息

kubectl get 命令可用来获取各种资源对象的相关信息,它既能显示对象类型特有格式的简要信息,也能按照指定格式为YAMLJSON的详细信息,或者使用Go模板自定义要显示的属性及信息等。

1[root@k8s-master ~]# kubectl get deployment #查看所有deployment控制器对象 2NAME READY UP-TO-DATE AVAILABLE AGE 3nginx 1/1 1 1 66s 4 5###字段说明: 6NAME 资源对象名称 7READY 期望由当前控制器管理的Pod对象副本数及当前已有的Pod对象副本数 8UP-TO-DATE 更新到最新版本定义的Pod对象的副本数量,在控制器的滚动更新模式下,表示已经完成版本更新的Pod对象的副本数量 9AVAILABLE 当前处于可用状态的Pod对象的副本数量,即可正常提供服务的副本数。 10AGE Pod的存在时长 11 12说明:Deployment资源对象通过ReplicaSet控制器实例完成对Pod对象的控制,而非直接控制。另外,通过控制器创建的Pod对象都会被自动附加一个标签。格式为“run=<Controller_Name>”。 13[root@k8s-master ~]# kubectl get deployment -o wide #查看deployment控制器对象的详细信息 14NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR 15nginx 1/1 1 1 69m nginx nginx:1.12 run=nginx 16 17 18[root@k8s-master ~]# kubectl get pods #查看pod资源 19NAME READY STATUS RESTARTS AGE 20nginx-685cc95cd4-9z4f4 1/1 Running 0 72m 21 22[root@k8s-master ~]# kubectl get pods -o wide 23NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES 24nginx-685cc95cd4-9z4f4 1/1 Running 0 73m 10.244.1.12 k8s-node1 <none> <none> 25 26###字段说明: 27NAME pode资源对象名称 28READY pod中容器进程初始化完成并能够正常提供服务时即为就绪状态,此字段用于记录处于就绪状态的容器数量 29STATUS pod的当前状态,其值有Pending、Running、Succeeded、Failed和Unknown等其中之一 30RESTARTS Pod重启的次数 31IP pod的IP地址,通常由网络插件自动分配 32NODE pod被分配的节点。

3)访问Pod对象

这里部署的是pod是运行的为nginx程序,所以我们可以访问是否ok,在kubernetes集群中的任意一个节点上都可以直接访问PodIP地址。

1[root@k8s-master ~]# kubectl get pods -o wide #查看pod详细信息 2NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES 3nginx-685cc95cd4-9z4f4 1/1 Running 0 88m 10.244.1.12 k8s-node1 <none> <none> 4 5[root@k8s-master ~]# curl 10.244.1.12 #kubernetes集群的master节点上访问 6<!DOCTYPE html> 7<html> 8<head> 9<title>Welcome to nginx!</title> 10<style> 11 body { 12 width: 35em; 13 margin: 0 auto; 14 font-family: Tahoma, Verdana, Arial, sans-serif; 15 } 16</style> 17</head> 18<body> 19<h1>Welcome to nginx!</h1> 20<p>If you see this page, the nginx web server is successfully installed and 21working. Further configuration is required.</p> 22 23<p>For online documentation and support please refer to 24<a href="http://nginx.org/">nginx.org</a>.<br/> 25Commercial support is available at 26<a href="http://nginx.com/">nginx.com</a>.</p> 27 28<p><em>Thank you for using nginx.</em></p> 29</body> 30</html> 31 32 33[root@k8s-node2 ~]# curl 10.244.1.12 #kubernetes集群的node节点上访问 34<!DOCTYPE html> 35<html> 36<head> 37<title>Welcome to nginx!</title> 38<style> 39 body { 40 width: 35em; 41 margin: 0 auto; 42 font-family: Tahoma, Verdana, Arial, sans-serif; 43 } 44</style> 45</head> 46<body> 47<h1>Welcome to nginx!</h1> 48<p>If you see this page, the nginx web server is successfully installed and 49working. Further configuration is required.</p> 50 51<p>For online documentation and support please refer to 52<a href="http://nginx.org/">nginx.org</a>.<br/> 53Commercial support is available at 54<a href="http://nginx.com/">nginx.com</a>.</p> 55 56<p><em>Thank you for using nginx.</em></p> 57</body> 58</html>

上面访问是基于一个pod的情况下,但是,当这个pod由于某种原因意外挂掉了,或者所在的节点挂掉了,那么deployment控制器会立即创建一个新的pod,这时候再去访问这个IP就访问不到了,而我们不可能每次去到节点上看到IP再进行访问。测试如下:

1[root@k8s-master ~]# kubectl get pods -o wide 2NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES 3nginx-685cc95cd4-9z4f4 1/1 Running 0 99m 10.244.1.12 k8s-node1 <none> <none> 4 5[root@k8s-master ~]# kubectl delete pods nginx-685cc95cd4-9z4f4 #删除上面的pod 6pod "nginx-685cc95cd4-9z4f4" deleted 7 8[root@k8s-master ~]# kubectl get pods -o wide #可以看出,当上面pod刚删除,接着deployment控制器又马上创建了一个新的pod,且这次分配在k8s-node2节点上了。 9NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES 10nginx-685cc95cd4-z5z9p 1/1 Running 0 89s 10.244.2.14 k8s-node2 <none> <none> 11 12 13[root@k8s-master ~]# curl 10.244.1.12 #访问之前的pod,可以看到已经不能访问 14curl: (7) Failed connect to 10.244.1.12:80; 没有到主机的路由 15[root@k8s-master ~]# 16[root@k8s-master ~]# curl 10.244.2.14 #访问新的pod,可以正常访问 17<!DOCTYPE html> 18<html> 19<head> 20<title>Welcome to nginx!</title> 21<style> 22 body { 23 width: 35em; 24 margin: 0 auto; 25 font-family: Tahoma, Verdana, Arial, sans-serif; 26 } 27</style> 28</head> 29<body> 30<h1>Welcome to nginx!</h1> 31<p>If you see this page, the nginx web server is successfully installed and 32working. Further configuration is required.</p> 33 34<p>For online documentation and support please refer to 35<a href="http://nginx.org/">nginx.org</a>.<br/> 36Commercial support is available at 37<a href="http://nginx.com/">nginx.com</a>.</p> 38 39<p><em>Thank you for using nginx.</em></p> 40</body> 41</html>

部署Service对象

简单来说,一个Service对象可视作通过其标签选择器过滤出的一组Pod对象,并能够为此组Pod对象监听的套接字提供端口代理及调度服务。就好比上面做的测试,如果没有Service,那么每次都得去访问pod对象自己的地址等。且那还只是创建了一个pod对象,如果是多个。那么该如何是好?故使用Service解决此问题。

1)创建Service对象(将Service端口代理至Pod端口示例)

"kubectl expose"命令可用于创建Service对象以将应用程序“暴露”(expose)于网络中。

1#方法一 2[root@k8s-master ~]# kubectl expose deployment nginx --name=nginx-svc --port=80 --target-port=80 --protocol=TCP #为deployment的nginx创建service,取名叫nginx-svc,并通过service的80端口转发至容器的80端口上。 3service/nginx-svc exposed 4#方法二 5[root@k8s-master ~]# kubectl expose deployment/nginx --name=nginx-svc --port=80 --target-port=80 --protocol=TCP 6service/nginx-svc exposed 7 8###参数说明: 9--name 指定service对象的名称 10--port 指定service对象的端口 11--target-port 指定pod对象容器的端口 12--protocol 指定协议 13 14[root@k8s-master ~]# kubectl get svc #查看service对象。或者kubectl get service 15NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE 16kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 25h 17nginx-svc ClusterIP 10.109.54.136 <none> 80/TCP 41s

这时候可以在kubernetes集群上所有节点上直接访问nginx-svccluster-ip及可访问到名为deployment控制器下nginxpod。并且,集群中的别的新建的pod都可以直接访问这个IP或者这个service名称即可访问到名为deployment控制器下nginxpod。示例:

1# master节点上通过ServiceIP进行访问 2[root@k8s-master ~]# curl 10.109.54.136 3<!DOCTYPE html> 4<html> 5<head> 6<title>Welcome to nginx!</title> 7<style> 8 body { 9 width: 35em; 10 margin: 0 auto; 11 font-family: Tahoma, Verdana, Arial, sans-serif; 12 } 13</style> 14</head> 15<body> 16<h1>Welcome to nginx!</h1> 17<p>If you see this page, the nginx web server is successfully installed and 18working. Further configuration is required.</p> 19 20<p>For online documentation and support please refer to 21<a href="http://nginx.org/">nginx.org</a>.<br/> 22Commercial support is available at 23<a href="http://nginx.com/">nginx.com</a>.</p> 24 25<p><em>Thank you for using nginx.</em></p> 26</body> 27</html> 28 29 30#新建一个客户端pod进行访问,这里这个客户端使用busybox镜像,且pod副本数量为1个,-it表示进入终端模式。--restart=Never,表示从不重启。 31[root@k8s-master ~]# kubectl run client --image=busybox --replicas=1 -it --restart=Never 32If you don't see a command prompt, try pressing enter. 33/ # wget -O - -q 10.109.54.136 #访问上面创建的(service)nginx-svc的IP 34<!DOCTYPE html> 35<html> 36<head> 37<title>Welcome to nginx!</title> 38...... 39/ # 40/ # wget -O - -q nginx-svc #访问上面创建的(service)名称nginx-svc 41<!DOCTYPE html> 42<html> 43<head> 44<title>Welcome to nginx!</title>

2)创建Service对象(将创建的Pod对象使用“NodePort”类型的服务暴露到集群外部)

1[root@k8s-master ~]# kubectl run mynginx --image=nginx:1.12 --port=80 --replicas=2 #创建一个deployments控制器并使用nginx镜像作为容器运行的应用。 2[root@k8s-master ~]# kubectl get pods #查看创建的pod 3NAME READY STATUS RESTARTS AGE 4client 1/1 Running 0 15h 5mynginx-68676f64-28fm7 1/1 Running 0 24s 6mynginx-68676f64-9q8dj 1/1 Running 0 24s 7nginx-685cc95cd4-z5z9p 1/1 Running 0 16h 8[root@k8s-master ~]# 9[root@k8s-master ~]# kubectl expose deployments/mynginx --type="NodePort" --port=80 --name=mynginx-svc #创建一个service对象,并将mynginx创建的pod对象使用NodePort类型暴露到集群外部。 10service/mynginx-svc exposed 11[root@k8s-master ~]# 12[root@k8s-master ~]# kubectl get svc #查看service 13NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE 14kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 41h 15mynginx-svc NodePort 10.111.89.58 <none> 80:30884/TCP 10s 16nginx-svc ClusterIP 10.109.54.136 <none> 80/TCP 15h 17 18###字段说明: 19PORT(S) 这里的mynginx-svc对象可以看出,集群中各工作节点会捕获发往本地的目标端口为30884的流量,并将其代理至当前service对象的80端口。于是集群外部的用户可以使用当前集群中任一节点的此端口来请求Service对象上的服务。 20 21[root@k8s-master ~]# 22[root@k8s-master ~]# netstat -nlutp |grep 30884 #查看master节点上是否有监听上面的30884端口 23tcp6 0 0 :::30884 :::* LISTEN 7340/kube-proxy 24[root@k8s-node1 ~]# 25[root@k8s-node1 ~]# netstat -nlutp |grep 30884 #查看node节点是否有监听上面的30884端口 26tcp6 0 0 :::30884 :::* LISTEN 2537/kube-proxy

客户端访问kubernetes集群的30884端口

3)Service资源对象的描述

“kuberctl describe services”命令用于打印Service对象的详细信息,它通常包括Service对象的Cluster IP,关联Pod对象使用的标签选择器及关联到的Pod资源的端点等。示例

1[root@k8s-master ~]# kubectl describe service mynginx-svc 2Name: mynginx-svc 3Namespace: default 4Labels: run=mynginx 5Annotations: <none> 6Selector: run=mynginx 7Type: NodePort 8IP: 10.111.89.58 9Port: <unset> 80/TCP 10TargetPort: 80/TCP 11NodePort: <unset> 30884/TCP 12Endpoints: 10.244.1.14:80,10.244.2.15:80 13Session Affinity: None 14External Traffic Policy: Cluster 15Events: <none> 16 17###字段说明: 18Selector 当前Service对象使用的标签选择器,用于选择关联的Pod对象 19Type 即Service的类型,其值可以是ClusterIP、NodePort和LoadBalancer等其中之一 20IP 当前Service对象的ClusterIP 21Port 暴露的端口,即当前Service用于接收并响应的端口 22TargetPort 容器中的用于暴露的目标端口,由Service Port路由请求至此端口 23NodePort 当前Service的NodePort,它是否存在有效值与Type字段中的类型相关 24Endpoints 后端端点,即被当前Service的Selector挑中的所有Pod的IP及其端口 25Session Affinity 是否启用会话粘性 26External Traffic Policy 外部流量的调度策略

扩容和缩容

所谓的“伸缩(Scaling)”就是指改变特定控制器上Pod副本数量的操作,“扩容(scaling up)”即为增加副本数量,而“缩容(scaling down)"则指缩减副本数量。不过,不论是扩容还是缩容,其数量都需要由用户明确给出。

Service对象内建的负载均衡机制可在其后端副本数量不止一个时自动进行流量分发,它还会自动监控关联到的Pod的健康状态,以确保将请求流量分发至可用的后端Pod对象。若某Deployment控制器管理包含多个Pod实例,则必要时用户还可以为其使用“滚动更新”机制将其容器镜像升级到新的版本或变更那些支持动态修改的Pod属性。

使用kubect run命令创建Deployment对象时,“--replicas=”选项能够指定由该对象创建或管理的Pod对象副本的数量,且其数量支持运行时进行修改,并立即生效。“kubectl scale”命令就是专用于变动控制器应用规模的命令,它支持对Deployment资源对象的扩容和缩容操作。

上面示例中创建的Deployment对象nginx仅创建了一个Pod对象,其所能够承载的访问请求数量即受限于这单个Pod对象的服务容量。请求流量上升到接近或超出其容量之前,可以通过kubernetes的“扩容机制”来扩招Pod的副本数量,从而提升其服务容量。

扩容示例

1[root@k8s-master ~]# kubectl get pods -l run=nginx #查看标签run=nginx的pod 2NAME READY STATUS RESTARTS AGE 3nginx-685cc95cd4-z5z9p 1/1 Running 0 17h 4[root@k8s-master ~]# 5[root@k8s-master ~]# kubectl scale deployments/nginx --replicas=3 #将其扩容到36deployment.extensions/nginx scaled 7[root@k8s-master ~]# 8[root@k8s-master ~]# kubectl get pods -l run=nginx #再次查看 9NAME READY STATUS RESTARTS AGE 10nginx-685cc95cd4-f2cwb 1/1 Running 0 5s 11nginx-685cc95cd4-pz9dk 1/1 Running 0 5s 12nginx-685cc95cd4-z5z9p 1/1 Running 0 17h 13[root@k8s-master ~]# 14[root@k8s-master ~]# kubectl describe deployments/nginx #查看Deployment对象nginx详细信息 15Name: nginx 16Namespace: default 17CreationTimestamp: Thu, 29 Aug 2019 15:29:31 +0800 18Labels: run=nginx 19Annotations: deployment.kubernetes.io/revision: 1 20Selector: run=nginx 21Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable 22StrategyType: RollingUpdate 23... 24 25#由nginx自动创建的pod资源全部拥有同一个标签选择器“run=nginx”,因此,前面创建的Service资源对象nginx-svc的后端端点也已经通过标签选择器自动扩展到了这3个Pod对象相关的端点 26[root@k8s-master ~]# kubectl describe service/nginx-svc 27Name: nginx-svc 28Namespace: default 29Labels: run=nginx 30Annotations: <none> 31Selector: run=nginx 32Type: ClusterIP 33IP: 10.109.54.136 34Port: <unset> 80/TCP 35TargetPort: 80/TCP 36Endpoints: 10.244.1.15:80,10.244.2.14:80,10.244.2.16:80 37Session Affinity: None 38Events: <none>

缩容示例

缩容的方式和扩容相似,只不过是将Pod副本的数量调至比原来小的数字即可。例如将nginxpod副本缩减至2个

1[root@k8s-master ~]# kubectl scale deployments/nginx --replicas=2 2deployment.extensions/nginx scaled 3[root@k8s-master ~]# 4[root@k8s-master ~]# kubectl get pods -l run=nginx 5NAME READY STATUS RESTARTS AGE 6nginx-685cc95cd4-pz9dk 1/1 Running 0 10m 7nginx-685cc95cd4-z5z9p 1/1 Running 0 17h

删除对象

有一些不再有价值的活动对象可使用“kubectl delete”命令予以删除,需要删除Service对象nginx-svc时,即可使用下面命令完成:

1[root@k8s-master ~]# kubectl get services #查看当前所有的service对象 2NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE 3kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 43h 4mynginx-svc NodePort 10.111.89.58 <none> 80:30884/TCP 96m 5nginx-svc ClusterIP 10.109.54.136 <none> 80/TCP 17h 6[root@k8s-master ~]# kubectl delete service nginx-svc #删除service对象nginx-svc

有时候要清空某一类型下的所有对象,只需要将上面的命令对象的名称缓存“--all”选项便能实现。例如,删除默认名称空间中所有的Deployment控制器的命令如下:

1[root@k8s-master ~]# kubectl delete deployment --all 2deployment.extensions "mynginx" deleted

注意:受控于控制器的Pod对象在删除后会被重建,删除此类对象需要直接删除其控制器对象。不过,删除控制器时若不想删除其Pod对象,可在删除命令上使用“--cascade=false“选项。

虽然直接命令式管理的相关功能强大且适合用于操纵Kubernetes资源对象,但其明显的缺点是缺乏操作行为以及待运行对象的可信源。另外,直接命令式管理资源对象存在较大的局限性,它们在设置资源对象属性方面提供的配置能力相当有限,而且还有不少资源并不支持命令操作进行创建,例如,用户无法创建带有多个容器的Pod对象,也无法为Pod对象创建存储卷。因此,管理资源对象更有效的方式是基于保存有对象配置信息的配置清单来进行。

点赞
收藏

评论区

加载中...

相关推荐

MySQL:[Err] 1292 - Incorrect datetime value: ‘0000-00-00 00:00:00‘ for column ‘CREATE_TIME‘ at row 1

文章目录问题用navicat导入数据时,报错:原因这是因为当前的MySQL不支持datetime为0的情况。解决修改sql\mode:sql\mode:SQLMode定义了MySQL应支持的SQL语法、数据校验等,这样可以更容易地在不同的环境中使用MySQL。全局s

Oracle 分组与拼接字符串同时使用

SELECTT.,ROWNUMIDFROM(SELECTT.EMPLID,T.NAME,T.BU,T.REALDEPART,T.FORMATDATE,SUM(T.S0)S0,MAX(UPDATETIME)CREATETIME,LISTAGG(TOCHAR(

MySQL部分从库上面因为大量的临时表tmp_table造成慢查询

背景描述Time:20190124T00:08:14.70572408:00User@Host:@Id:Schema:sentrymetaLast_errno:0Killed:0Query_time:0.315758Lock_

皕杰报表之UUID

​在我们用皕杰报表工具设计填报报表时,如何在新增行里自动增加id呢?能新增整数排序id吗?目前可以在新增行里自动增加id,但只能用uuid函数增加UUID编码,不能新增整数排序id。uuid函数说明:获取一个UUID,可以在填报表中用来创建数据ID语法:uuid()或uuid(sep)参数说明:sep布尔值,生成的uuid中是否包含分隔符'',缺省为

手写Java HashMap源码

HashMap的使用教程HashMap的使用教程HashMap的使用教程HashMap的使用教程HashMap的使用教程22

2020年前端实用代码段,为你的工作保驾护航

有空的时候,自己总结了几个代码段,在开发中也经常使用,谢谢。1、使用解构获取json数据let jsonData  id: 1,status: "OK",data: 'a', 'b';let  id, status, data: number   jsonData;console.log(id, status, number )