k8s的pod分类、核心组件、网络模型、kubectl常用命令

本文详细介绍了Kubernetes中Pod的分类,包括自主式和控制器管理的Pod,以及核心组件如HPA和Service。讨论了Kubernetes网络模型,包括节点网络、Service集群网络和Pod网络,并阐述了Pod间的通信方式。此外,还概述了kubectl常用命令的使用,如create、run、get、expose和delete。
摘要由CSDN通过智能技术生成

k8s的pod分类

pod分为两类:自主式pod与控制器管理的pod

自主式pod由k8s管理器进行管理,而static pod由kubelet进行创建与管理

自主式pod

​ 自主式pod总是在前台运行,同时接受k8s管理与调度,当集群当中的pod因为某种原因停止,k8s会根据其副本的数量,重新的生成对应的pod

​ 自我管理的pod,创建以后仍然需要提交给apiserver,由apiserver接收以后借助于调度器将其调度至指定的node节点,由node启动此pod
​ 如果此pod出现故障,需要重启容器则由kubelet来完成
​ 如果node节点故障了,那么此pod将会消失。其无法实现全局调度。所以不推荐使用此种pod

控制器管理的pod

​ 常见的pod控制器:

​ ReplicationController:当启动一个pod时。这个pod如果不够用可以再启个副本,而后由控制器来管理同一类pod的各种副本与对象。一旦副本少了就会自动增加。采取多退少补的规则,精确符合我们所定义的期望。支持滚动更新

​ ReplicaSet:由一个名叫Deployment的声明式更新的控制器来管理

​ Deployment:Deployment只能管理无状态的应用

​ StateFulSet:有状态副本集,可以管理有状态的应用

​ DaemonSet:如果需要在每个node上运行一个副本的时候可以用DaemonSet

核心主键

HPA

​ Deployment还支持二级控制器,HPA(HorizontalPodAutoscaler,水平pod自动伸缩控制器),一般情况下我们可以确保一个node上有2个pod在运行,万一用户访问流量增加,2个pod不足以承载这么多访问量怎么办?此时我们就应该要增加pod资源,那么到底应该加几个?

​ HPA控制器可自动监控pod、自动进行扩展。
在这里插入图片描述

service

​ 假如有2个pod,pod有其生命周期,万一pod所在的节点宕机了,那么此pod将应该要在其他的节点上重建,而重建完的pod与原来的pod已经不是同一个pod了,只是两者都是运行的同一个服务而已。且每个容器都有其IP地址,重建的pod中的容器其IP地址与之前的pod中容器的IP地址是不一样的,如此一来就会存在一个问题,客户端如何访问这些pod中的容器呢?(会转换到另一个节点去运行)

​ 用于做服务发现,pod是有生命周期的,一个pod随时都有可能离去,随时都有可能会有其他内pod加进来,假如它们提供的是同一种服务,客户端是无法通过固定的手段来访问这些pod的,因为pod本身是不固定的,它们随时可能被替换掉,无论使用主机名还是IP地址,都随时会被替换掉。

​ 为了尽可能的降低客户端与pod间协调的复杂度,k8s为每一组提供同类服务的pod和其客户端之间添加了一个中间层,这个中间层是固定的,这个中间层就叫service。

​ service只要不被删除,其地址与名称皆是固定的,当客户端需要在其配置文件中写上访问某个服务时,它不再需要自动发现,只需要在配置文件中写明service的名称即可,而这个service是个调度器,其不但能够提供一个稳定的访问入口,还可以做反向代理,当service接收到客户端的请求后,会将其代理到后端的pod之上,一旦pod宕机了会立即新建一个pod,这个新建的pod会立即被service关联上,作为service后端的可用pod之一

​ 客户端程序访问服务都是通过IP+端口或者主机名+端口的方式来实现的。而service关联后端的pod不是靠它的IP和主机名,而是靠pod的标签选择器。只要创建的pod的label是统一的,无论IP地址和主机如何改变,其都能被service所识别。如此一来,只要pod属于标签选择器,只要其在service的管理范围之内,则其就会被关联到service中,当这个动态的pod关联到service中之后,再进行动态的探测此pod的IP地址、端口,再将其作为自己后端可调度的可用服务蒂王机为象。因此,客户端的请求发送到service,然后由service代理到后端真实的pod中的容器进行响应。

​ service不是一个程序,也不是一个组件,它只是一个iptables的dnat规则,service作为k8s的对象,有其自身的名称,而service的名称相当于服务的名称,而这个名称可以被解析。
在这里插入图片描述

​ AddOns附件

​ dns pod:装完k8s后第一件事就需要在k8s集群上部署一个dns pod,以确保各service的名称能够被解析可以动态改变,包括动态创建、动态删除、动态修改,比如把service的名称改了,dnspod会自动触发,将dns解析记录中的名称也给改掉;假如我们手动把service的ip地址给改了,改完以后会自动触发,将dns服务中的解析记录给改掉。如此一来,客户端去访问pod资源的时候可以直接访问service的名称,然后由集群中专用的dns服务来负责解析。

​ 这种pod是k8s自身的服务就需要用到的pod,所以我们把它称为基础性的系统架构级的pod对象,而且它们也被称为集群附件

Kubernetes网络模型

k8s的三种网络模型分别属于三个网段,分别是:

  • 节点网络
  • service集群网络
  • pod网络

同一pod内的多个容器间如何通信
​ lo网卡

​ 各pod之间如何通信?

​ 1.物理桥桥接,规模大的情况下会产生广播风暴

​ 2.Overlay Network,通过隧道的方式转发报文

同节点Pod之间的通信

在容器启动前,会为容器创建一个虚拟Ethernet接口对,这个接口对类似于管道的两端,其中一端在主机命名空间中,另外一端在容器命名空间中,并命名为eth0。在主机命名空间的接口会绑定到网桥。网桥的地址段会取IP赋值给容器的eth0接口。

不同节点上的Pod通信

我们已经知道一个节点上的容器都会连接到同一网桥,因此要让运行在不同节点上的容器之间能够通信,这些节点的网桥就需要以某种方式连接起来。
跨整个集群的Pod的IP地址必须是唯一的,所有跨节点的网桥必须使用不重叠的网络地址段,以防止不同节点上的Pod拿到同一IP地址,即确保没有IP地址冲突。

发送到B节点上的容器时,报文会先通过veth接口对到网桥,再由网桥到A节点的物理适配器,再通过网线传输到B节点的物理适配器,再通过B的网桥,经过接口对到达目标容器。

注意:上述情形仅在节点连接到相同网关,之间没有任何路由设备时有效。否则,路由设备会因为IP私有产生丢包现象,除非设置路由规则。但随着节点的增加,路由的配置会变得非常困难。因此我们使用SDN(软件定义网络)技术来简化此类问题,SDN可以忽略底层网络拓扑,使其就像连接到同一网关。

Pod与Service

在不同节点上的Pod通信中,我们知道了Pod是以IP地址进行通信,但Kubernetes 的集群中, Pod 可能

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值