Linux学习 day15之k8s资源类型

最新推荐文章于 2024-10-04 22:38:01 发布

跃上青空

最新推荐文章于 2024-10-04 22:38:01 发布

阅读量156

点赞数

分类专栏： Linux 文章标签： kubernetes

本文链接：https://blog.csdn.net/wuzeipero/article/details/111083367

版权

Linux 专栏收录该内容

15 篇文章 1 订阅

订阅专栏

资源分类，一切皆资源，但需要分类

资源对象

`pod`最小单元，底层工人

创建`Pod`经历阶段

apiservice >> etcd >> statefulset(调度) >>node节点
pod生命周期的重要行为：

初始化容器
容器探测：
- liveness 探测容器是否处于存活
- readiness 探测容器中的程序是否正常提供服务

`pod`重启策略

restartPolicy
- Always 默认
- OnFailure 非正常关闭重启
- Never 从不重启

`init` 容器

功能：在业务容器启动之前，阻塞住，直到业务容器启动条件满足

pause 容器

功能：
- 在pod中担任linux命名空间共享的基础
- 启用pid命名空间，开启init进程
- 在pod内部所有容器间共享volume存储等
定义方式：
- kubectl pod_infra_container=-pod-infra-container-image=gcr.io/google_containers/pause-amd64:3.0

容器生命周期

Pod的状态status信息保存在podstatus的phase字段内
- 挂起pending
- 运行ing running
- 成功succeeded
- 失败failed
- 位置unknown
Podconditions
- lastProbeTime
- lastTransitionTime
- message
- reason
- status
  - PodScheduled: Pod被调度到node
  - Ready:Pod可以提供服务，可以加入负载均衡
  - Initialized：init容器指向完毕
  - Unschedulable: 比如资源不足
  - ContainersReady: 所有容器都准备好了
容器探针
- 定义：容器的探针是由kubelet对容器执行的定期检查，要执行诊断，kubelet调用由容器实现的Handler
- 三种类型的处理程序
  - ExecAction:在容器内执行指定命令，如果命令退出时返回码为0，则认为诊断成功
  - TCPSccketAction: 对指定端口上的容器的ip进行tcp检查，如果端口打开，则诊断被认为时成功的
  - HTTPGetAction:对指定的端口和路径上的容器的ip地址执行HTTPget请求，如果响应的状态码大于等于200且小于400，则诊断成功
- 每次探测的结果之一
  - 成功
  - 失败
  - 未知不会采取任何行动
- kubelet可以选择是否执行在容器上运行的两种探针执行和做出反应
  - livenessProbe ：指示容器是否正在运行。存活探测
    - 探测结果失败 kubelet会杀死容器，容器会受到重启策略的影响
    - 容器未提供探针，默认未success
  - readinessProbe ：指示容器是否准备号服务请求。就绪探针
    - 探测失败，端点控制器将从与pod匹配的所有service的端点中删除该pod的ip地址，初始延迟之前的就绪状态默认未failure
    - 容器不提供
  - 使用场景
    - 不一定需要存活探针
      - 容器中的进程能够在遇到问题或不健康的情况下自行崩解，由重启策略执行正确的操作
    - 需要存活探针
      - 如果希望容器在探测失败时被杀死并重新启动，那么就指定一个存活探针，并指定restartPolicy为Always或OnFailure
    - 需要就绪探针
      - 如果需要

`pod hook`测试

`Ingress Controller` ：独立运行一个或一组`pod`资源，通常就是一个应用程序，该程序拥有7c层代理能力，

可选择：Haproxy，nginx ，envoy, treafik (适合微服务)

`deployment` 部署

部署表示用户kubernetes集群的依次更新操作
部署是一个比RS应用模式更广的api对象，可以是创建一个新的服务，更新一个新的服务

Service 服务

RC,RS和deployment只是保证可支撑服务的微服务pod的数量，但是没有解决如何访问这瞎服务的问题，一个pod是一个运行服务的实例
客户端需要访问的服务就是service对象，每个service对应一个集群内部有效的虚拟ip，集群内部通过虚拟ip访问一个服务，在kubernetes集群中微服务的负载均衡，是由kube-proxy实现的
kube-proxy是一个分布式代理服务器，在kubernetes的每个节点上都有一个。提现了它的伸缩性优势，需要访问服务的节点越多，提供负载均衡能力的kube-proxy就越多，高可用节点也随着增多
- 解决了一般服务器做反向代理做负载均衡，还需要进一步解决反向代理的负载均衡和高可用问题

`replicaSet`：副本集作为`deployment`参数

代用户创建指定的pod数，保存不变的个数

`ReplicationController`：副本控制器 `rs`代替

`StatefulSet`，有状态服务集

管理有状态应用，每个应用单独管理，拥有独有标识，独有数据记忆，一旦节点故障，添加新的节点会重新初始化操作
无状态；
有状态：stateful,pet,having name,non-disposable
- 特定：每个pod的名字都是事先确定的不能更改，名字关联与该pod对应的状态
- 场景：mysql,postgre sql ,zk,etcd

`DaemonSet` , 后台支撑服务集

用于确保集群的每个节点只运行一个特定的pod，通常用来实现系统及，的托管任务
场景：存储，日志，监控。。。

`Job` ：任务

按照用户指定的pod数量启动pod，当pod任务完成后才pod才不会重启
场景：一次性任务使用

`Cronjob`：在`job`的基础上周期性完成任务。只能管控无状态群体

`HorizontalPodAutoscaling` 水平自动扩展

`RBAC` 访问授权

Attribute-based Access Control & ABAC 基于属性的访问控制，k8s集群内的访问策略只能根用户直接关联
Role-based Access Control & RBAC 基于角色的访问控制
- 访问策略可以根某个角色关联，具体的用户根角色关联类似于组的概念