自动化运维 ·

kubernetes 概念性问题

1.kubernetes是什么

  • Kubernetes是容器集群管理系统,是一个开源的平台,可以实现容器集群的自动化部署、自动扩缩容、维护等功能

2.kubernetes好处

  • 快速部署应用
  • 快速扩展应用
  • 无缝对接新的应用功能
  • 节省资源,优化硬件资源的使用

3.kubernetes特点

  • 可移植: 支持公有云,私有云,混合云,多重云(multi-cloud)
  • 可扩展: 模块化, 插件化, 可挂载, 可组合
  • 自动化: 自动部署,自动重启,自动复制,自动伸缩/扩展

4.kubernetes能做啥

  • 可以在物理或虚拟机的Kubernetes集群上运行容器化应用,Kubernetes能提供一个以“容器为中心的基础架构”,满足在生产环境中运行应用的一些常见需求
  • 应用健康检测 负载均衡 滚动更新 资源监控 提供认证和授权

5.kubernetes组成

  • 一个kubernetes集群由分布式存储etcd、node、master组成,状态都存在etcd中
  • master组件: apiserver kubecontrollermanager scheduler docker
  • node组件: docker kubelet kube-proxy

6.kubernetes各组件作用

  • etcd保存了整个集群的状态
  • apiserver提供了资源操作的唯一入口,并提供认证、授权、访问控制、API注册和发现等机制
  • controller manager负责维护集群的状态,比如故障检测、自动扩展、滚动更新等
  • scheduler负责资源的调度,按照预定的调度策略将Pod调度到相应的机器上
  • kubelet负责维护容器的生命周期,同时也负责Volume(CVI)和网络(CNI)的管理
  • Container runtime负责镜像管理以及Pod和容器的真正运行(CRI)
  • kube-proxy负责为Service提供cluster内部的服务发现和负载均衡
  • 各组件之间相互合作来保证几群的正常运行

7.kubernetes与docker的关系

  • Docker是一个开源的应用容器引擎,让开发者可以打包它们的应用以及依赖包到一个可移植的镜像中,然后发布到任何流行的Linux或Windows机器上,也可以实现虚拟化
  • K8S是一套自动化部署工具,可全生命周期管理Dockers容器

8.kubernetes与docker的比较

  • 单一的docker部署环境,可能面临镜像代码的升级,而k8s支持滚动升级
  • 单一的docker部署时,当部署的容器较多时,难以查询状态,而k8s支持etcd状态查询
  • 单一的docker部署时,可能面临运行环境崩溃,而k8s支持容器重启
  • 更重要的一点是对于生产环境而言可以解决负载均衡的问题

9.emptyDir和hostPath在功能上的异同分析

  • 二者都是node节点的本地存储卷方式
  • emptyDir可以选择把数据存到tmpfs类型的本地文件系统中去,hostPath并不支持这一点
  • hostPath除了支持挂载目录外,还支持File、Socket、CharDevice和BlockDevice,既支持把已有的文件和目录挂载到容器中,也提供了“如果文件或目录不存在,就创建一个”的功能;
  • emptyDir是临时存储空间,完全不提供持久化支持;hostPath的卷数据是持久化在node节点的文件系统中的,即便pod已经被删除了,volume卷中的数据还会留存在node节点上

10.说明何时使用 Init Container


当我们在运用一个服务之前,通常会做一些初始化的工作,而这些工作一般只需要运行一次,成功后就不再运行。
特点:仅运行一次,成功后就会退出。
每个容器必须在成功执行完成后,系统才能继续执行下一个容器。 如果Init Container运行失败,kubernetes 将会重复重启Pod,直到Init Container 成功运行,
但是如果 Pod的重启策略(restartPolicy)设置为Never,则Pod不会重启。 Init Container支持普通应用Container的所有参数,包括资源限制,挂载卷,安全设置等。
但是Init Container 在资源的申请和限制上略有不同,同时,由于Init Container必须在Pod ready之前完成并退出,所以它不支持 readiness 探针。 Init Container 通常有如下应用方式:
处于安全的考虑,可以将自定义的代码和工具使用Init Container运行,而不必添加到 应用 容器的镜像中;
应用程序映像的构建和部署者角色可以彼此独立,无需共同构建单个应用程序映像;
使用不同的Linux命名空间,可以使它们具有来自应用容器的不同文件系统权限。
因此,Init Container可以获得应用程序容器无法访问的Secrets;Init Container在任何应用程序容器启动之前运行完毕,而应用程序容器通常是并行运行的,
因此初始容器提供了一种简单的方法来阻止或延迟应用程序容器的启动,直到满足一些前提条件。

11.k8s 的 pause 容器有什么用

  • 每个Pod里运行着一个特殊的容器被称之为Pause的容器,其他容器则为业务容器,这些业务容器共享Pause容器的网络栈和Volume挂载卷,因此他们之间通信和数据交换更为高效,在设计时我们可以充分利用这一特性将一组密切相关的服务进程放入同一个Pod中。同一个Pod里的容器之间仅需通过localhost就能互相通信

12.k8s 的 service 和 ep 是如何关联和相互影响

  • k8s会根据service关联到pod的podIP信息组合成一个endpoint。若service定义中没有selector字段,service被创建时,endpoint controller不会自动创建endpoint

13.service和 ingress 的作用

  • Service 是后端真实服务的抽象,一个 Service 可以代表多个相同的后端服务
  • Ingress 是反向代理规则,用来规定 HTTP/S 请求应该被转发到哪个 Service 上,比如根据请求中不同的 Host 和 url 路径让请求落到不同的 Service 上
  • Ingress Controller 就是一个反向代理程序,它负责解析 Ingress 的反向代理规则,如果 Ingress 有增删改的变动,所有的 Ingress Controller 都会及时更新自己相应的转发规则,当 Ingress Controller 收到请求后就会根据这些规则将请求转发到对应的 Service

14.cgroup 中的 cpu 有哪几种限制方式。k8s 是如何使用实现 request 和 limit

  • 在cgroup里面,跟CPU相关的子系统有cpusets、cpuacct和cpu。cpu.cfs_period_us & cpu.cfs_quota_us cpu.shares cpu.stat.
  • 目前CPU支持设置request和limit,memory只支持设置request, limit必须强制等于request。limits.cpu会被转换成docker的–cpu-quota参数,limits.memory会被转换成docker的–memory参数

15.rc/rs 功能是怎么实现的

  • ReplicaSet和 Replication Controller之间的唯一区别是现在的选择器支持。Replication Controller只支持基于等式的selector(env=dev或environment!=qa),但ReplicaSet还支持新的,基于集合的selector(version in (v1.0, v2.0)或env notin (dev, qa))。在试用时官方推荐ReplicaSet

16.deployment/rs 有什么区别

  • rs是更高级的rc,既可以支持基于等式又支持基于集合的标签选择
  • rs功能:确保Pod数量 确保Pod健康 弹性伸缩 滚动升级
  • dep功能有:
  • Deployment具备上面描述的RC的全部功能
  • 事件和状态查看:可以查看Deployment的升级详细进度和状态
  • 回滚:当升级Pod的时候如果出现问题,可以使用回滚操作回滚到之前的任一版本
  • 版本记录:每一次对Deployment的操作,都能够保存下来,这也是保证可以回滚到任一版本的基础
  • 暂停和启动:对于每一次升级都能够随时暂停和启动

17.pv pvc

  • pv与pvc遵循以下生命周期:Provisioning ——-> Binding ——–>Using——>Releasing——>Recycling
  • pv状态: Available Bound(卷已经被绑定到claim了) Released(claim被删除,卷处于释放状态,但未被集群回收) Failed(卷自动回收失败)
  • 三种回收策略:保留策略:允许人工处理保留的数据 删除策略:将删除pv和外部关联的存储资源,需要插件支持 回收策略:将执行清除操作,之后可以被新的pvc使用,需要插件支持

18.docker可配置网络

  • host
  • bridge
  • none
  • container

19.pod生命周期

  • Pending 系统已经接受pod实例的创建,但其中所包含容器的一个或者多个image还没有创建成功。Pending包含调度计算与通过网络创建image,所以此phase的时间可能会有点长
  • Running Pod已经被调度到某个node上,pod包含的所有容器已经创建完成,至少有一个容器正常运行或者处于启动与重启动过程
  • Succeeded Pod中的所有容器正常终止,并且不会再次启动
  • Failed Pod中所有容器已终止运行,至少有一个容器非正常结束,比如退出码非零,被系统强制杀死等
  • Unknow 无法取得pod状态,一般是网络问题引起

20.nginx与traefik区别

  • nginx: C开发 需要一个controller 拥有强大的Annotate配置,可以为service提供丰富的个性化配置 支持的算法更多
  • traefik: golang开发 能够直接与kubernetes API交互,实时感知后端变化,反应速度更加快速 拥有一个UI 支持两三中算法

21.schuler调度流程

  • 1.预选策略(predicate) 遍历nodelist,选择出符合要求的候选节点,Kubernetes内置了多种预选规则供用户选择。
  • 2.优选策略(priority) 在选择出符合要求的候选节点中,采用优选规则计算出每个节点的积分,最后选择得分最高的。
  • 3.选定(select) 如果最高得分有好几个节点,select就会从中随机选择一个节点。

22.flannel与calico区别

flannel
  • 原理上来说:flannel在进行路由转发的基础上进行了封包解包的操作,这样浪费了CPU的计算资源;calico则不需要封包解包,更为快速
  • 与其他方案相比,Flannel相对容易安装和配置。它被打包为单个二进制文件FlannelD,许多常见的Kubernetes集群部署 工具 和许多Kubernetes发行版都可以默认安装Flannel。Flannel可以使用Kubernetes集群的现有etcd集群来使用API存储其状态信息,因此不需要专用的数据存储
  • Flannel配置第3层IPv4 Overlay网络。它会创建一个大型内部网络,跨越集群中每个节点。在此Overlay网络中,每个节点都有一个子网,用于在内部分配IP地址。在配置Pod时,每个节点上的Docker桥接口都会为每个新容器分配一个地址。同一主机中的Pod可以使用Docker桥接进行通信,而不同主机上的pod会使用flanneld将其流量封装在UDP数据包中,以便路由到适当的目标
  • Flannel有几种不同类型的后端可用于封装和路由。默认和推荐的方法是使用VXLAN,因为VXLAN性能更良好并且需要的手动干预更少
calico
  • Calico以其性能、灵活性而闻名。Calico的功能更为全面,不仅提供主机和pod之间的网络连接,还涉及网络安全和管理。Calico CNI插件在CNI框架内封装了Calico的功能
  • Calico配置第3层网络,该网络使用BGP路由协议在主机之间路由数据包。这意味着在主机之间移动时,不需要将数据包包装在额外的封装层中。BGP路由机制可以本地引导数据包,而无需额外在流量层中打包流量
  • Calico还可以与服务网格Istio集成,以便在服务网格层和网络基础架构层中解释和实施集群内工作负载的策略。这意味着用户可以配置强大的规则,描述Pod应如何发送和接受流量,提高安全性并控制网络环境
  • Calico是提供商业支持
容器虚拟网络方案
  • 基于隧道和基于路由
  • 基于隧道:flannel的vxlan calico的ipip
  • 基于路由: calico的bgp
  • 基于隧道:1.封包解包 2.消耗带宽
  • 基于路由:1.要求宿主机处于同一个2层网络下,也就是连在一台交换机上,这样才能基于MAC通讯 2.路由表膨胀导致性能降低,因为宿主机上每个容器需要在本机添加一条路由规则,而不同宿主机之间需要广播自己的网段路由规则

23.pod创建流程


创建Pod的流程:
1.用户通过REST API创建一个pod
2.apiserver将其写入etcd
3.scheduler检测到有未绑定node的pod,开始调度并更新pod的node绑定
4.kubelet检测到有新的pod调度过来,通过container Runtime运行该pod
5.kubelet通过container Runtime 取到pod状态,并更新到apiserver中

24.cni作用

  • 保证每个Pod拥有一个集群内唯一的IP地址
  • 保证不同节点的IP地址划分不会重复
  • 保证垮节点的Pod可以互相通信
  • 保证不同节点的Pod可以与垮节点的主机互相通信

25.docker容器状态

  • 运行 已暂停 重新启动 已退出

评论已关闭