k8s 陈述式资源管理

命令行：kubectl命令行工具

优点：90%以上的场景都可以满足

对资源的增，删，查比较方便，对改不是很友好

缺点：

命令比较冗长，复杂难记

声明式：

k8s当中的yaml文件来实现资源管理----声明式

GUI：图形化工具的管理。

1，kubectl命令的详解：

查：

部署：

查看pod的情况（详细信息，日志，发布和回滚）

Kubernetes kubectl 命令表 _ Kubernetes(K8S)中文文档_Kubernetes中文社区 kubu命令大全的网站

查看版本信息

kubectl version

Client Version 是指 kubectl 命令行工具的版本

Server Version 是指 Kubernetes 集群的版本

查看所有资源的简写（有的有简写，有的只有全称）

kubectl api-resources

查看k8s的集群信息

kubectl cluster-info

自动补齐的命令

source <(kubectl completion bash)

通过get的命令

基本信息查看

查看master节点的状态

kubectl get cs

查看node节点的状态，

查看默认命名空间内的pod信息

kubectl get pod

查看当前集群所有的命名空间

kubectl get ns

查看指定命名空间的pod信息

kubectl get pod -n chen

要查看指定命名空间内的pod需要加-n命名空间的名称

查看默认命名空间内pod的详细情况

kubectl get pod -o wide

练习：查看chen命名看见没的详细信息。

kubectl get pod -o wide -n chen

查询节点的信息和状态

查看node节点的详细信息。

kubectl get node -o wide

查看pod的详细信息。

查看已经部署好的pod的详细信息。

kubectl describe pod nginx-6799fc88d8-lrvkt

练习：

-n指定命名空间

如何查看pod的日志：

静态：

kubectl logs nginx-6799fc88d8-lrvkt

动态：

kubectl logs -f nginx-6799fc88d8-lrvkt

也默认的命名空间

查看指定命名空间

创建命名空间

kubectl create ns chen

删除命名空间

kubectl delete ns chen

删除pod

kubectl delete pod nginx-6799fc88d8-lrvkt

并没有删除，只是重启了

先声明动作: create delete get desvribe

对象: ns pod service

对象的名称guoqi nginx- 6799fc88d8 - f9c8g

nginx1 nginx2 -n命名空间。

对pod进行部署

deployment的部署pod：

陈述式部署：命令行

声明式：yaml文件进行部署

滚动更新：不是一次性的把所有pod全部不是，而是一个一个来。pod的更新时使用。逐步的引入新的pod。逐步的减少旧的pod。

自我修复：如果有pod节点发送故障，deploment会自动启动新的pod来进行代替

回滚：如果更新有问题，deployment会提供还原点，可以手动还原到未更新的状态。

扩容和缩容：deplayment可以随时调整pod的数量，以适用流量的变化。

上述的功能必须是基于deployment创建的访问才可以。绝大多数的pod都是由deployment创建的。

还有通过daemonsetcj创建的

daemonset:不能通过命令行创建。只能在yaml文件当中定义这种创建方式。

后台运行创建，在每个节点上都创建一个相同方式的，相同版本的容器运行的pod。

一般都是依赖环境和重要组件，一般也不会对执行资源进行操作。

用deployment命令行的方式创建pod

查看通过deployments创建的命名空间：

命名空间内的pod名称不能重复。

在指定命名空间创建pod

kubectl create deployment nginx1 --image=nginx --replicas=3 -n chen

删除pod删不掉。

kubectl delete pod myapp-test-777fc9d77b-2ngdk

删除马上又拉起来一个。

如果是基于deployment方式创建的pod,或者是daemonset方式创建的pod，是由控制器创建的pod。适用delete删除是删不掉的，相当于重启pod。

基于deployment方式创建pod.一 旦删除deployment,基于这个deployment创建的pod都会被删除。慎用

kubectl delete deployments.apps myapp-test

delete用于重启。不是running，基于控制器创建的。

不是基于控制器创建，会被直接删除。

只要是基于控制器创建的，删除要先删除控制器，根据控制器创建的pod就自动删除了。

一般不要动。要先查看，是不是deployment创建。

远程进入节点容器：

进入容器：

kubectl exec -it nginx-6799fc88d8-fz9mp bash

docker的exec只能在本机内部使用,不能跨主机，kubectlexec可以跨主机进入容器。

不同命名空间

kubectl create ns chen

kubectl create deployment nginxcc --image=nginx -n chen

kubectl get pod -n chen

kubectl exec -it nginxcc-98c959b58-5jzrc -n chen bash

快速删除pod中的容器的命令：

kubectl delete pod nginx1-b97c459f7-r8xrq --force --grace-period=0

grace-period：表示过度的存活期，默认是30秒。可以让pod优雅的结束容器内的进程,然后退出pod =0，表示立刻停止pod。必须要加--force

但是pod还在

主要是用于结束卡在销毁状态的pod.一般用delete就行了，但要等一会。

如何对deployment创建的pod进行扩容和缩容

扩容

kubectl scale deployment nginx1 --replicas=3

缩容：

kubectl scale deployment nginx1 --replicas=1

创建pod时并没有指定副本数，后续也可以对他的副本数进行修改

只有基于deployment才能扩缩容。

如何把服务的service进行发布：

ubectl create deployment nginx --image=nginx:1.10 --replicas=3

如何定义他的service

service的类型：

查看默认命名空间的service

删除：

kubectl delete svc nginx-service

查看不同命名空间的service

kubectl get svc -n chen

type类型：

ClusterIP：创建service的默认类型，通过一个集群内部的虚拟ip地址，这是service的默认类型，通过这个虚拟ip可以服务pod的资源，无法对外提供访问。

NodePort：会在每一个node节点上都开放一个相同的端口。外部可以通过node的本机ip+端口，访问pod资源，集群外部访问service资源的一种方式。四层代理方式。

nodeip:nodeport

随机指派，也可以指定 30000-32767

基于deployment创建的pod，可以使用的方式；

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

--port=80 service集群的端口

--target port=80 pod内部容器的端口

类型是NodePort

10.96.232.240集群内部的ip地址，外部是不可以访问这个ip地址的。

80:对应的是内部的service的端口

32436:和内部的service的80端口做映射。

pod内部容器的端口是固定的（可以进去改）不能随机指定。

--port是service和容器内部的端口做映射。

NodePort的端口是随机生成的。范围是： 30000-32767

访问地址，进行负载均衡。

一个是内部

负载均衡靠的就是kube-proxy

可以改外端访问端口

范围只能是30000-32767

LoadBalancer：如果service的类型设定为loadBalancer，映射地址（云平台提供LoadBalancer的地址）这种用法仅用于公有云服务供应商在云平台上设置service的场景。外部来访问。实现负载均衡。LoadBalancer这个地址是要付费的。

创建好了service，指定类型为LoadBalancer。会给你提供一个地址来带代理pod内部的ip地址。

只能等代地址分配。

内部可以访问。

ExternalName：DNS映射，给service分配一个域名，提供域名来访问后端pod资源。ExternalName的service类型，不能提供负载均衡，

必须要设置一个LoadBalancer地址池。

改一个

还要做映射，不能负载均衡。

更新和回滚以及发布的方式：

项目的生命周期

创建------发布------更新------回滚-----删除

对版本进行更新：

滚动更新：

如何回滚：

查看回滚点：

kubectl rollout history deployment nginx

数字的大小决定了距离上次操作的远近，数字越大，就是你最近的一次操作。

更新时添加标识。

kubectl set image deployment nginx nginx=nginx:1.15 --record

--record 加上

回滚：

kubectl rollout undo deployment nginx --to-revision=1

查看回滚的状态：

kubectl rollout status deployment nginx

动态的查看回滚情况：

kubectl get pod -w

每更新一次都会生成一个还原度

查看当前命名空间内的所有信息。

所有的详细信息。

指定命名空间。

三种常见的项目发布方式：

蓝绿发布

金丝雀发布（灰布发布）

滚动发布

应用程序升级，面临的最大的问题是新旧业务之间的切换。

立项---定稿---需求发布---开发---测试---发布，

测试之后上线，再完美有会有问题。为了不让发送的问题影响所有用户，上述的三种发布方式。

蓝绿发布：

把应用服务集群标记为两个组，蓝组和绿组，先升级蓝组，要把蓝组从负载均衡当中移除，绿组继续提供服务。

蓝组升级完毕，在把绿组从负载均衡当中移除，绿组升级，然后都加入回负载均衡当中去，完成对外服务。

对硬件资源要求很高，但是有了云计算和微服务，现在的成本也大大降低了

蓝绿发布的特点：

1，一旦出现问题，问题的影响范围很大

2，发布策略简单

3，基于现在的云计算和微服务，用户无感知。

4，升级和回滚都比较方便。

缺点：

在发布升级的过程中，只有一部分集群在对外提供服务，可能会使集群的负载能力下降，响应变慢，需要注意给集群增加负载能力(一般来说没什么特殊需要。）

短时间内可能会浪费一定资源成本。

金丝雀发布（灰布发布）：

deployment控制器创建的服务，才可以使用这种发布方式。滚动更新，暂停。发布的过程中暂时停止，只有一部分的pod先升级，

其他的pod还是处于老的版本，绝大多数用户还是在老版本。确定无问题之后，在把剩下的老版本，升级成新的版本,把暂停取消,继续发布。如果有问题，可以立即回滚，暂停不是回滚, 一旦取消暂停只能全部升级完毕之后，再回滚。

实验：

查看回滚点：

kubectl rollout history deployment nginx

当前版本：1.21.5

执行这个命令之后会有pod中会有一个容器升级

kubectl set image deployment nginx nginx=nginx:1.24 --record && kubectl rollout pause deployment nginx

正在创建：

kubectl rollout status deployment nginx

查看状态：

一个新的，3个旧的

只有一个是1.24

继续，就全部更新：

kubectl rollout resume deployment nginx

动态的查看创建的状态

kubectl get pod -w

全部都是升级完毕。

查看回滚点：

kubectl rollout history deployment nginx

回滚：

kubectl rollout undo deployment nginx --to-revision=1

灰布发布的特点：

面试时：不要说金丝雀发布。

1，自动化的要求比较高，对运维人员的要求比较高

2，方便问题，即使解决。影响范围比较小。

3，用户无感知，平滑过度。节约资源。

4、发布策略比较复杂。

5、不易回滚，必须要全部发布

滚动更新：

deployment的默认更新方式。

面试题：

三个

说灰布发布：

一般情况下滚动

特殊情况：灰布发布。