K8s 资源管理资源管理的方法1、命令法kubectl xxxxxx执行的命令缺点就是太长只适合在测试环境2、指令对象kubectl apply -f xxx.yaml支持幂等有文件写入没文件创建并写入如果需要反复执行复杂任务就编写一个 YAML 文件清单文件在这里面写命令内容ps降低写文件难度—— kubectl get pod找一个系统里官方的 YAML 文件-o yaml a.yaml vim a.yaml 导出为 YAML 格式文件自己在上面修改YAML 清单文件——缩进严格要求、有键和对应的值这里暂时先把 Pod 理解成容器3、资源常见的五个顶级字段apiVersion版本号固定kubectl api-resources 可查看 kind类型叫什么名字固定查看方法同上metadata放了一些重要的元数据比如说他的容器名基础属性。spec表示规格用户自定义期望实现的属性用户控制、具体属性status目前的实际状态只读4、名称空间名称空间自己也是一种资源kubectl api-resources 可详细查看 不同于docker的内核名称空间无法改动,系统自带k8s的是用户命名空间可以由用户自己改动这里可以看到哪些资源允许放到名称空间里。就像是逻辑上的一种分类。创建一个名称空间kubectl create namespace 名字 --dry-runclient 后面这段表示测试运行不代表真实创建如果这个后面加上 -o yaml 就是把这个命令的所有的清单文件展示出来看删除名称空间kubectl delete ns这个就是namespace的缩写在kubectl api-resources上查看每个资源的缩写名字不要随便删名称空间哦里面的东西也会全部删除查看资源kubectl get 双tab键查看支持以此方式查看的资源由此可以看出名称空间可以分类隔离资源便捷高效。 这也是名称空间的主要作用5、 pod资源很重要哦,下面会详细说pod是在k8s中可管理创建和的最小单元类似于docker中的容器。pod相当于多个容器的结合pod是豆荚壳容器就是里面的豆米。这些豆米容器共享存储和网络下图表示了这些豆米容器哪些资源是共享的哪些是独立的。pod也细分容器pod里面有两种容器pause和业务容器。 这里把pod比做成家庭容器相当于个人pause——必须有的基础容器相当于户主就负责基础环境的管理上图中共享的资源环境服务于业务容器的秘书功能有限且固定k8s自动给每个pod分配。业务容器——老板如果你想要一些高级功能可以再增加一种高级秘书容器——用户自定义sidecar容器后面会讲查看pod可以看到同一个node节点上运行着两个不同的pod。我们在101这台机器上docker ps 就至少看到四个容器一个pod至少一个pause和业务容器创建pod自主式pod创建kubectl run NAME --imageimage 这个镜像对应的是业务容器的镜像有一个缺陷——不具备故障自愈功能所以用的比较少。基于controller管控的pod人——》controller——》pod 相当于把这件事外包给控制器控制器来创建监控修复pod静态pod一些核心组件的pod就是开始就有的那些pod基于Kubelet创建。有一个系统文件夹/etc/kubernetes/manifeste/里面有pod的清单文件。启动k8sKubelet就会读取这些清单文件并且创建。之所以叫静态pod是因为这是人为的把文件放到文件夹里不是k8s自己读取创建的。删除就把他从文件夹里移走就行。平常不用这个是用来创建核心组件的。删除podkubectl delete pod 名字。静态pod除外要移走-n 指定命名空间更新pod更改pod对应的清单文件再apply一下就可以 或者在线更改——kubectl edit pod 名字存在风险查看pod信息最常规的kubectl get pod 名字kubectl describe pod 名字 比较重要的是event中的message可以看到pod出故障的信息kubectl logs 名字 查看日志也可看错误信息创建定制的pod在启动或者创建容器的时候可以–env 定制环境。例如kubectl run mysql -n m64 --env“MYSQL_ROOT_PASSWORD123456” --image 镜像。清单文件中加一个env字段在下面写。pod工作流程k8s组件一个pod的创建流程运维工程师使用kubectl创建一个podapiserver收到请求把这个请求给etcd存储起来etcd返回给apiserver一个已经接收的信息apiserver接收到请求后返回给用户“pod已创建”的信息但此时并未实际创建没这么快。这是后apiserver给调度器scheduler发送创建信息scheduler接受信息后通过计算决定在哪一个节点上创建pod最好这里比如说在node上创建。然后scheduler把信息告诉apiserver在哪创建的pod。api把这个信息存到etcd里。APIServer接收到scheduler的信息给对应节点的Kubelet发送创建信息Kubelet使用容器进行时dockercontainerd创建容器创建好后返回APIServer同时APIServer把信息存储到etcd中。一个pod就创建成功了。pod的生命周期1、创建pod除了pause和业务容器可能还会有一个init初始化容器用来准备环境在业务容器启动前启动完成环境配置任务就结束在业务容器开始前会有两个hook在启动的hook用来设置开机自启动等功能最后的hook用来执行比方说容器销毁后删除数据等任务。还有三个probe(探针)用来检测容器的健康分别是启动探针存活探针就绪探针2、删除pod类比创建流程这里不详细讲解。3、两种钩子启动前钩子poststart。在容器创建完成后立即启动。在清单文件的上图字段中进行配置与pod启动的命令同时执行。容器退出后钩子prestop。在容器退出之前执行在下图字段中配置。由于容器退出后数据会删除所以可以在清单文件中配置将容器目录挂载到宿主机目录上数据持久化。类似于docker -v /tmp:/tmp4、健康状态检测三种探针startup probe 启动检测探针类似于入职体检在容器创建后检查一下健康状态。 检测失败直接重新创建podliveness probe存活探针。若是检测失败和启动探针一样重新创建pod。readiness probe就绪探针。用户访问pod靠着service间接访问pod因为pod相关地址不固定通过service帮我们找到pod。service有一个后端列表里面有可用的pod当就绪探针检测失败他会在列表中把该pod去掉service不再把请求转发到该pod用其他好的pod。该过程不会删除重新创建pod当就绪状态坏了的pod被修复后service会把他重新加回来。5、配置探针在清单文件里加字段probe有很多配置字段可以使用这些字段精确的控制这些探针行为。接下来介绍几个常用探针initialdelayseconds:容器启动后要等待多少秒启动探针。periodseconds:执行检测的时间间隔单位是秒。默认10秒最小值是1.timeoutseconds探测的超时后等待多少秒successthreshold探针在失败后被视为成功的最新连续成功数。默认值是1.存活和启动探测的这个值必选是1.最小值是1。failurethreshold当探测失败时k8s的重试次数。对存活探针而言放弃就意味着重新启动容器。对就绪探针而言。放弃意味着pod会被打上未就绪的标签。默认值是3最小值是1。6、检测实现探针的三种方式exec直接执行指定的命令根据命令结果的状态码$?判断是否成功成功则返回表示探测成功。tcpsocket根据相应TCP套接字连接建立状态判断如果端口能正常打开即成功。httpget根据指定http、https服务URL的响应码结果判断当2**或者3的响应码表示成功。pod状态可以多掌握一点terminating正在被删除状态running正常状态pending创建pod时所有工作节点都不能用没有合适节点调度其中一种原因重点pod重启策略always只要退出就重启onfailure只要失败就重启never无论什么情况都重启