深圳住房和建设局网站认租申请,佛山市品牌网站建设哪家好,四川做网站公司,广州冼村是什么地方创建 Pod的主要流程? 客户端提交 Pod 的配置信息(可以是 yaml 文件定义的信息)到 kube-apiserver. Apiserver 收到指令后,通知 controllr-manager 创建一个资源对象 controller-manager 通过 apiserver 将 pod 的配置信息存储到 ETCD 数据中薪心中 kube-scheduler 检查到 p…创建 Pod的主要流程? 客户端提交 Pod 的配置信息(可以是 yaml 文件定义的信息)到 kube-apiserver. Apiserver 收到指令后,通知 controllr-manager 创建一个资源对象 controller-manager 通过 apiserver 将 pod 的配置信息存储到 ETCD 数据中薪心中 kube-scheduler 检查到 pod 信息会开始调度预选,会先过滤不符合 Pod 资源配置要求的节点,然后开始调度调优,主要是挑选出更适合运行的 pod 节点,然后将 pod 的资源配置单发送到 node 节点上的 kubelet 组件上 kubelet 根据 scheduler 发来的资源配置单运行 pod,运行成功后,将 pod 的运行的信息返回 scheduler, scheduler 将返回的 pod 运行状况的信息存储到 etcd 数据中信
Pod 的重启策略 Pod 重启策略(RestartPolicy)应用于 Pod 内的所有容器,并且仅再 Pod 所处的 Node 上由 Kubelet 进行判断和重启操作.当某个容器异常退出或健康检查失败时,kubele 将根据 RestartPolicy 的设置来进行相应操作 pod 的重启策略包括 Always,OnFaliure 和 Never,默认值为 Always Always: 当容器失效时由 kubelet 自动重启该容器 OnFailure:当容器终止运行且退出不为 0 时,yo 由 kubelet 自动重启该容器 Nerve: 不论容器运行状态如何,kubelet 都不会重启该容器 同时 pod 的容器策略与控制方式关联,当前可用于管理 Pod 的控制器包括 RelicatonController
Pod 的健康检查方式 LivenessProbe探针用于判断容器是否存活running状态如果LivenessProbe探针探测到容器不健康则kubelet将杀掉该容器并根据容器的重启策略做相应处理。若一个容器不包含LivenessProbe探针kubelet认为该容器的LivenessProbe探针返回值用于是“Success”。 ReadineeProbe探针用于判断容器是否启动完成ready状态。如果ReadinessProbe探针探测到失败则Pod的状态将被修改。Endpoint Controller将从Service的Endpoint中删除包含该容器所在Pod的Eenpoint。 startupProbe探针启动检查机制应用一些启动缓慢的业务避免业务长时间启动而被上面两类探针kill掉。
Pod 探针常见方式 ExecAction在容器内执行一个命令若返回码为0则表明容器健康。 TCPSocketAction通过容器的IP地址和端口号执行TCP检查若能建立TCP连接则表明容器健康。 HTTPGetAction通过容器的IP地址、端口号及路径调用HTTP Get方法若响应的状态码大于等于200且小于400则表明容器健康。
Pod 常见的调度方式 Deployment或RC该调度策略主要功能就是自动部署一个容器应用的多份副本以及持续监控副本的数量在集群内始终维持用户指定的副本数量。 NodeSelector定向调度当需要手动指定将Pod调度到特定Node上可以通过Node的标签Label和Pod的nodeSelector属性相匹配。 NodeAffinity亲和性调度亲和性调度机制极大的扩展了Pod的调度能力目前有两种节点亲和力表达 requiredDuringSchedulingIgnoredDuringExecution硬规则必须满足指定的规则调度器才可以调度Pod至Node上类似nodeSelector语法不同。 preferredDuringSchedulingIgnoredDuringExecution软规则优先调度至满足的Node的节点但不强求多个优先级规则还可以设置权重值。 Taints和Tolerations污点和容忍 Taint使Node拒绝特定Pod运行 Toleration为Pod的属性表示Pod能容忍运行标注了Taint的Node。
deployment升级策略? 在Deployment的定义中可以通过spec.strategy指定Pod更新的策略目前支持两种策略Recreate重建和RollingUpdate滚动更新默认值为RollingUpdate。 Recreate设置spec.strategy.typeRecreate表示Deployment在更新Pod时会先杀掉所有正在运行的Pod然后创建新的Pod。 RollingUpdate设置spec.strategy.typeRollingUpdate表示Deployment会以滚动更新的方式来逐个更新Pod。同时可以通过设置spec.strategy.rollingUpdate下的两个参数maxUnavailable和maxSurge来控制滚动更新的过程
Kubernetes Service类型?
通过创建Service可以为一组具有相同功能的容器应用提供一个统一的入口地址并且将请求负载分发到后端的各个容器应用上。其主要类型有 ClusterIP虚拟的服务IP地址该地址用于Kubernetes集群内部的Pod访问在Node上kube-proxy通过设置的iptables规则进行转发 NodePort使用宿主机的端口使能够访问各Node的外部客户端通过Node的IP地址和端口号就能访问服务 LoadBalancer使用外接负载均衡器完成到服务的负载分发需要在spec.status.loadBalancer字段指定外部负载均衡器的IP地址通常用于公有云。
Service分发后端的策略?
Service负载分发的策略有RoundRobin和SessionAffinity RoundRobin默认为轮询模式即轮询将请求转发到后端的各个Pod上。 SessionAffinity基于客户端IP地址进行会话保持的模式即第1次将某个客户端发起的请求转发到后端的某个Pod上之后从相同的客户端发起的请求都将被转发到后端相同的Pod上。
Kubernetes外部如何访问集群内的服务? 映射Pod到物理机将Pod端口号映射到宿主机即在Pod中采用hostPort方式以使客户端应用能够通过物理机访问容器应用。 映射Service到物理机将Service端口号映射到宿主机即在Service中采用nodePort方式以使客户端应用能够通过物理机访问容器应用。 映射Sercie到LoadBalancer通过设置LoadBalancer映射到云服务商提供的LoadBalancer地址。这种用法仅用于在公有云服务提供商的云平台上设置Service的场景。
Kubernetes ingress? Kubernetes的Ingress资源对象用于将不同URL的访问请求转发到后端不同的Service以实现HTTP层的业务路由机制。 Kubernetes使用了Ingress策略和Ingress Controller两者结合并实现了一个完整的Ingress负载均衡器。使用Ingress进行负载分发时Ingress Controller基于Ingress规则将客户端请求直接转发到Service对应的后端EndpointPod上从而跳过kube-proxy的转发功能kube-proxy不再起作用全过程为ingress controller ingress 规则 ---- services。 同时当Ingress Controller提供的是对外服务则实际上实现的是边缘路由器的功能。
Kubernetes镜像的下载策略?
K8s的镜像下载策略有三种Always、Never、IFNotPresent。 Always镜像标签为latest时总是从指定的仓库中获取镜像。 Never禁止从仓库中下载镜像也就是说只能使用本地镜像。 IfNotPresent仅当本地没有对应镜像时才从目标仓库中下载。
默认的镜像下载策略是当镜像标签是latest时默认策略是Always当镜像标签是自定义时也就是标签不是latest那么默认策略是IfNotPresent。
Kubernetes kubelet的作用? 在Kubernetes集群中在每个Node又称Worker上都会启动一个kubelet服务进程。该进程用于处理Master下发到本节点的任务管理Pod及Pod中的容器。每个kubelet进程都会在API Server上注册节点自身的信息定期向Master汇报节点资源的使用情况并通过cAdvisor监控容器和节点资源。
Secret有哪些使用方式? 创建完secret之后可通过如下三种方式使用 在创建Pod时通过为Pod指定Service Account来自动使用该Secret。 通过挂载该Secret到Pod来使用它。 在Docker镜像下载时使用通过指定Pod的spc.ImagePullSecrets来引用它。
Kubernetes CNI模型? CNI提供了一种应用容器的插件化网络解决方案定义对容器网络进行操作和配置的规范通过插件的形式对CNI接口进行实现。CNI仅关注在创建容器时分配网络资源和在销毁容器时删除网络资源。在CNI模型中只涉及两个概念容器和网络。 容器Container是拥有独立Linux网络命名空间的环境例如使用Docker或rkt创建的容器。容器需要拥有自己的Linux网络命名空间这是加入网络的必要条件。 网络Network表示可以互连的一组实体这些实体拥有各自独立、唯一的IP地址可以是容器、物理机或者其他网络设备比如路由器等。 对容器网络的设置和操作都通过插件Plugin进行具体实现CNI插件包括两种类型CNI Plugin和IPAMIP Address ManagementPlugin。CNI Plugin负责为容器配置网络资源IPAM Plugin负责对容器的IP地址进行分配和管理。IPAM Plugin作为CNI Plugin的一部分与CNI Plugin协同工作。
Kubernetes PV和PVC? PV是对底层网络共享存储的抽象将共享存储定义为一种“资源”。 PVC则是用户对存储资源的一个“申请”。
PV生命周期内的阶段?
某个PV在生命周期中可能处于以下4个阶段Phaes之一。 Available可用状态还未与某个PVC绑定。 Bound已与某个PVC绑定。 Released绑定的PVC已经删除资源已释放但没有被集群回收。 Failed自动资源回收失败。
calico 网络模式
模式数据包封包优点缺点vxlan封包 在vxlan设备上将pod发来的数据包源、目的mac替换为本机vxlan网卡和对端节点vxlan网卡的mac。外层udp目的ip地址根据路由和对端vxlan的mac查fdb表获取只要k8s节点间三层互通 可以跨网段 对主机网关路由没有特殊要求。各个node节点通过vxlan设备实现基于三层的”二层”互通, 三层即vxlan包封装在udp数据包中 要求udp在k8s节点间三层可达二层即vxlan封包的源mac地址和目的mac地址是自己的vxlan设备mac和对端vxlan设备mac。需要进行vxlan的数据包封包和解包会存在一定的性能损耗ipip封包在tunl0设备上将pod发来的数据包的mac层去掉留下ip层封包。 外层数据包目的ip地址根据路由得到。只要k8s节点间三层互通 可以跨网段 对主机网关路由没有特殊要求。需要进行ipip的数据包封包和解包会存在一定的性能损耗bgp不需要进行数据包封包不用封包解包通过bgp协议可实现pod网络在主机间的三层可达 k8s节点不跨网段时和flannel的host-gw相似支持跨网段 满足复杂的网络架构跨网段时需要主机网关路由也充当BGP Speaker能够学习到pod子网路由并实现pod子网路由的转发
fannel三种模式
fannel三种模式效率calico 模式UDP性能较差封包解包涉及到多次用户态和内核态交互类似 IPIPVXLAN性能较好封包解包在内核态实现内核转发数据flanneld负责动态配置ARP和FDB转发数据库表项更新类似VXLANhost-gw性能最好不需要再次封包正常发包目的容器所在的主机充当网关flanneld 负责主机上路由表的刷新类似 BGP
你知道的几种CNI网络插件并详述其工作原理。K8s常用的CNI网络插件 calico flannel简述一下它们的工作原理和区别。 calico根据iptables规则进行路由转发并没有进行封包解包的过程这和flannel比起来效率就会快多 calico包括如下重要组件FelixetcdBGP ClientBGP Route Reflector。下面分别说明一下这些组件。
Felix主要负责路由配置以及ACLS规则的配置以及下发它存在在每个node节点上。 etcd分布式键值存储主要负责网络元数据一致性确保Calico网络状态的准确性可以与kubernetes共用 BGPClient(BIRD), 主要负责把 Felix写入 kernel的路由信息分发到当前 Calico网络确保 workload间的通信的有效性 BGPRoute Reflector(BIRD), 大规模部署时使用摒弃所有节点互联的mesh模式通过一个或者多个 BGPRoute Reflector 来完成集中式的路由分发 通过将整个互联网的可扩展 IP网络原则压缩到数据中心级别Calico在每一个计算节点利用 Linuxkernel 实现了一个高效的 vRouter来负责数据转发而每个vRouter通过 BGP协议负责把自己上运行的 workload的路由信息向整个Calico网络内传播小规模部署可以直接互联大规模下可通过指定的BGProute reflector 来完成。这样保证最终所有的workload之间的数据流量都是通过 IP包的方式完成互联的。 Flannel的工作原理 Flannel实质上是一种“覆盖网络(overlay network)”也就是将TCP数据包装在另一种网络包里面进行路由转发和通信目前已经支持UDP、VxLAN、AWS VPC和GCE路由等数据转发方式。
默认的节点间数据通信方式是UDP转发。 工作原理 数据从源容器中发出后经由所在主机的docker0虚拟网卡转发到flannel0虚拟网卡先可以不经过docker0网卡使用cni模式这是个P2P的虚拟网卡flanneld服务监听在网卡的另外一端。 Flannel通过Etcd服务维护了一张节点间的路由表详细记录了各节点子网网段 。 源主机的flanneld服务将原本的数据内容UDP封装后根据自己的路由表投递给目的节点的flanneld服务数据到达以后被解包然后直接进入目的节点的flannel0虚拟网卡然后被转发到目的主机的docker0虚拟网卡最后就像本机容器通信一下的有docker0路由到达目标容器。 flannel在进行路由转发的基础上进行了封包解包的操作这样浪费了CPU的计算资源。
Worker节点宕机简述Pods驱逐流程。 在 Kubernetes 集群中当节点由于某些原因网络、宕机等不能正常工作时会被认定为不可用状态Unknown 或者 False 状态当时间超过了 pod-eviction-timeout 值时那么节点上的所有 Pod 都会被节点控制器计划删除。 Kubernetes 集群中有一个节点生命周期控制器node_lifecycle_controller.go。它会与每一个节点上的 kubelet 进行通信以收集各个节点已经节点上容器的相关状态信息。当超出一定时间后不能与 kubelet 通信那么就会标记该节点为 Unknown 状态。并且节点生命周期控制器会自动创建代表状况的污点用于防止调度器调度 pod 到该节点。 那么 Unknown 状态的节点上已经运行的 pod 会怎么处理呢节点上的所有 Pod 都会被污点管理器taint_manager.go计划删除。而在节点被认定为不可用状态到删除节点上的 Pod 之间是有一段时间的这段时间被称为容忍度。如果在不配置的情况下Kubernetes 会自动给 Pod 添加一个 key 为 node.kubernetes.io/not-ready 的容忍度 并配置 tolerationSeconds300同样Kubernetes 会给 Pod 添加一个 key 为 node.kubernetes.io/unreachable 的容忍度 并配置 tolerationSeconds300。 当到了删除 Pod 时污点管理器会创建污点标记事件然后驱逐 pod 。这里需要注意的是由于已经不能与 kubelet 通信所以该节点上的 Pod 在管理后台看到的是处于灰色标记但是此时如果去获取 pod 的状态其实还是处于 Running 状态。每种类型的资源都有相应的资源控制器Controller例如deployment_controller.go、stateful_set_control.go。每种控制器都在监听资源变化从而做出相应的动作执行。deployment 控制器在监听到 Pod 被驱逐后会创建一个新的 Pod 出来但是 Statefulset 控制器并不会创建出新的 Pod原因是因为它可能会违反 StatefulSet 固有的至多一个的语义可能出现具有相同身份的多个成员这将可能是灾难性的并且可能导致数据丢失。
你知道的K8s中几种Controller控制器并详述其工作原理 deployment适合无状态的服务部署 适合部署无状态的应用服务用来管理pod和replicaset具有上线部署、副本设定、滚动更新、回滚等功能还可提供声明式更新例如只更新一个新的Image 编写yaml文件并创建nginx服务pod资源。 StatefullSet适合有状态的服务部署 适合部署有状态应用解决Pod的独立生命周期保持Pod启动顺序和唯一性。 稳定唯一的网络标识符持久存储例如etcd配置文件节点地址发生变化将无法使用 有序优雅的部署和扩展、删除和终止例如mysql主从关系先启动主再启动从有序滚动更新 应用场景例如数据库
无状态服务的特点 deployment 认为所有的pod都是一样的 不用考虑顺序的要求 不用考虑在哪个node节点上运行 可以随意扩容和缩容
有状态服务的特点 实例之间有差别每个实例都有自己的独特性元数据不同例如etcdzookeeper 实例之间不对等的关系以及依靠外部存储的应用 常规的service服务和无头服务的区别 service一组Pod访问策略提供cluster-IP群集之间通讯还提供负载均衡和服务发现 Headless service 无头服务不需要cluster-IP直接绑定具体的Pod的IP无头服务经常用于statefulset的有状态部署 创建无头服务的service资源和dns资源由于有状态服务的IP地址是动态的所以使用无头服务的时候要绑定dns服务 DaemonSet一次部署所有的node节点都会部署例如一些典型的应用场景 运行集群存储 daemon例如在每个Node上运行 glusterd、ceph • 在每个Node上运行日志收集 daemon例如 fluentd、 logstash • 在每个Node上运行监控 daemon例如 Prometheus Node Exporter • 在每一个Node上运行一个Pod • 新加入的Node也同样会自动运行一个Pod • 应用场景监控分布式存储日志收集等 Job一次性的执行任务 • 一次性执行任务类似Linux中的job • 应用场景如离线数据处理视频解码等业务 Cronjob周期性的执行任务 • 周期性任务像Linux的Crontab一样 • 应用场景如通知备份等 • 使用cronjob要慎重用完之后要删掉不然会占用很多资源
ingress-controller的工作机制
通常情况下service和pod的IP仅可在集群内部访问 • k8s提供了service方式NodePort 来提供对外的服务外部的服务可以通过访问Node节点ipNodePort端口来访问集群内部的资源外部的请求先到达service所选中的节点上然后负载均衡到每一个节点上。
NodePort虽然提供了对外的方式但也有很大弊端 • 由于service的实现方式user_space 、iptebles、 3 ipvs、方式这三种方式只支持在4层协议通信不支持7层协议因此NodePort不能代理https服务。 • NodePort 需要暴露service所属每个node节点上端口当需求越来越多端口数量过多导致维护成本过高并且集群不好管理。
原理 • Ingress也是Kubernetes API的标准资源类型之一它其实就是一组基于DNS名称host或URL路径把请求转发到指定的Service资源的规则。用于将集群外部的请求流量转发到集群内部完成的服务发布。我们需要明白的是Ingress资源自身不能进行“流量穿透”仅仅是一组规则的集合这些集合规则还需要其他功能的辅助比如监听某套接字然后根据这些规则的匹配进行路由转发这些能够为Ingress资源监听套接字并将流量转发的组件就是Ingress Controller。 • Ingress 控制器不同于Deployment 等pod控制器的是Ingress控制器不直接运行为kube-controller-manager的一部分它仅仅是Kubernetes集群的一个附件类似于CoreDNS需要在集群上单独部署。 • ingress controller通过监视api server获取相关ingress、service、endpoint、secret、node、configmap对象并在程序内部不断循环监视相关service是否有新的endpoints变化一旦发生变化则自动更新nginx.conf模板配置并产生新的配置文件进行reload
k8s的调度机制
Scheduler工作原理 请求及Scheduler调度步骤 • 节点预选(Predicate)排除完全不满足条件的节点如内存大小端口等条件不满足。 • 节点优先级排序(Priority)根据优先级选出最佳节点 • 节点择优(Select)根据优先级选定节点
具体步骤 • 首先用户通过 Kubernetes 客户端 Kubectl 提交创建 Pod 的 Yaml 的文件向Kubernetes 系统发起资源请求该资源请求被提交到 • Kubernetes 系统中用户通过命令行工具 Kubectl 向 Kubernetes 集群即 APIServer 用 的方式发送“POST”请求即创建 Pod 的请求。 • APIServer 接收到请求后把创建 Pod 的信息存储到 Etcd 中从集群运行那一刻起资源调度系统 Scheduler 就会定时去监控 APIServer • 通过 APIServer 得到创建 Pod 的信息Scheduler 采用 watch 机制一旦 Etcd 存储 Pod 信息成功便会立即通知APIServer • APIServer会立即把Pod创建的消息通知SchedulerScheduler发现 Pod 的属性中 Dest Node 为空时Dest Node””便会立即触发调度流程进行调度。 • 而这一个创建Pod对象在调度的过程当中有3个阶段节点预选、节点优选、节点选定从而筛选出最佳的节点 • 节点预选基于一系列的预选规则对每个节点进行检查将那些不符合条件的节点过滤从而完成节点的预选 • 节点优选对预选出的节点进行优先级排序以便选出最合适运行Pod对象的节点 • 节点选定从优先级排序结果中挑选出优先级最高的节点运行Pod当这类节点多于1个时则进行随机选择
k8s的调用工作方式 • Kubernetes调度器作为集群的大脑在如何提高集群的资源利用率、保证集群中服务的稳定运行中也会变得越来越重要Kubernetes的资源分为两种属性。 • 可压缩资源例如CPU循环Disk I/O带宽都是可以被限制和被回收的对于一个Pod来说可以降低这些资源的使用量而不去杀掉Pod。 • 不可压缩资源例如内存、硬盘空间一般来说不杀掉Pod就没法回收。未来Kubernetes会加入更多资源如网络带宽存储IOPS的支持。
kube-proxy的三种工作模式和原理
userspace 模式 • 该模式下kube-proxy会为每一个Service创建一个监听端口。发向Cluster IP的请求被Iptables规则重定向到Kube-proxy监听的端口上Kube-proxy根据LB算法选择一个提供服务的Pod并和其建立链接以将请求转发到Pod上。 • 该模式下Kube-proxy充当了一个四层Load balancer的角色。由于kube-proxy运行在userspace中在进行转发处理时会增加两次内核和用户空间之间的数据拷贝效率较另外两种模式低一些好处是当后端的Pod不可用时kube-proxy可以重试其他Pod。
iptables 模式 • 为了避免增加内核和用户空间的数据拷贝操作提高转发效率Kube-proxy提供了iptables模式。在该模式下Kube-proxy为service后端的每个Pod创建对应的iptables规则直接将发向Cluster IP的请求重定向到一个Pod IP。 • 该模式下Kube-proxy不承担四层代理的角色只负责创建iptables规则。该模式的优点是较userspace模式效率更高但不能提供灵活的LB策略当后端Pod不可用时也无法进行重试。
该模式和iptables类似kube-proxy监控Pod的变化并创建相应的ipvs rules。ipvs也是在kernel模式下通过netfilter实现的但采用了hash table来存储规则因此在规则较多的情况下Ipvs相对iptables转发效率更高。除此以外ipvs支持更多的LB算法。如果要设置kube-proxy为ipvs模式必须在操作系统中安装IPVS内核模块。
