K8s Service网络详解(二)

这篇具有很好参考价值的文章主要介绍了K8s Service网络详解(二)。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

Kube Proxy

Kubernetes 在设计之初就充分考虑了针对容器的服务发现负载均衡机制。 Service 资源,可以通过 kube-proxy 配合 cloud provider 来适应不同的应用场景。

Service相关的事情都由Node节点上的 kube-proxy处理。在Service创建时Kubernetes会分配IP给Service,同时通过API Server通知所有kube-proxy有新Service创建了,kube-proxy收到通知后通过 Iptables/IPVS 记录 Service和IP/端口 对应的关系,从而让Service在节点上可以被查询到。

kube-proxy还会监控Service和 Endpoint的变化,从而保证Pod重建后仍然能通过Service访问到Pod。

kube-proxy存在于各个node节点上

kube-proxy老版本默认使用的是 iptables模式,通过各个node节点上的iptables规则来实现service的负载均衡,但是随着service数量的增大,iptables模式由于线性查找匹配、全量更新等特点,其性能会显著下降

从k8s的1.8版本开始,kube-proxy引入了IPVS模式,IPVS模式与iptables同样基于Netfilter,但是采用的hash表,因此当service数量达到一定规模时,hash查表的速度优势就会显现出来,从而提高service的服务性能。

目前,kubernetes 中的负载均衡大致可以分为以下几种机制,每种机制都有其特定的应用场景:

Service:直接用 Service 提供 cluster 内部的负载均衡,并借助 cloud provider 提供的 LB 提供外部访问

Ingress Controller:还是用 Service 提供 cluster 内部的负载均衡,但是通过自定义 Ingress Controller 提供外部访问

Service Load Balancer:把 load balancer 直接跑在容器中,实现 Bare Metal 的 Service Load Balancer

Custom Load Balancer:自定义负载均衡,并替代 kube-proxy,一般在物理部署 Kubernetes 时使用,方便接入公司已有的外部服务

Service 与 Endpoints和 Pod的关系

K8s Service网络详解(二),kubernetes,网络,容器,云原生

调度模式

基于Linux下的kube-proxy支持的3种调度模式

  • 用户空间(Userspace) k8s 1.1版本前

  • iptables k8s 1.10版本以前

  • IPVS k8s 1.11版本之后,如果没有开启ipvs,则自动降级为iptables

Windows 上的 kube-proxy 只有一种模式可用:

  • kernelspace

kube-proxy 在 Windows 内核中配置数据包转发规则的一种模式

ipvs和iptables都是基于netfilter的,两者差别如下:

  • ipvs 为大型集群提供了更好的可扩展性和性能

  • ipvs 支持比 iptables 更复杂的负载均衡算法(最小负载、最少连接、加权等等)

  • ipvs 支持服务器健康检查和连接重试等功能

K8s Service网络详解(二),kubernetes,网络,容器,云原生

Kube-proxy Iptables

kube-proxy监听Kubernetes API Server,一旦Service 和 EndpointSlice 对象有变化(service创建删除和修改, pod的扩张与缩小),就将需要新增的规则添加到 iptables中。

kube-proxy只是作为controller,而不是server,真正服务的是内核的netfilter,体现在用户态则是iptables。

kube-proxy的 iptables方式支持的负载分发策略:

  • RoundRobin(默认模式)

  • SessionAffinity

kubernetes只操作了filter和nat表

Filter表中:一个基本原则是只过滤数据包而不修改他们

​ filter table的优势是小而快,可以hook到input,output和forward。这意味着针对任何给定的数据包,只有可能有一个地方可以过滤它。

NAT表:主要作用是在 PREROUTINGPOSTROUNTING的钩子中,修改目标地址源地址

​ 与filter表稍有不同的是,该表中只有新连接的第一个包会被修改,修改的结果会自动apply到同一连接的后续包中。

kube-proxy 对 iptables 的链 进行了扩充:自定义了 KUBE-SERVICESKUBE-NODEPORTSKUBE-POSTROUTINGKUBE-MARK-MASQKUBE-MARK-DROP 五个链,并主要通过为KUBE-SERVICES chain 增加 规则(rule) 来配制traffic routing 规则。

查看nat表的OUTPUT链,存在kube-proxy创建的KUBE-SERVICE链

iptables -nvL OUTPUT -t nat
iptables -nvL KUBE-SERVICES -t nat |grep service-demo

接着是查看这条链,以1/3的概率跳转到其中一条
iptables -nvL KUBE-SVC-EJUV4ZBKPDWOZNF4 -t nat

最后KUBE-SEP-BTFJGISFGMEBGVUF链终于找到了DNAT规则
iptables -nvL KUBE-SEP-BTFJGISFGMEBGVUF -t nat

Kube-proxy IPVS

IPVS 模式在工作时,当我们创建了前面的 Service 之后,kube-proxy 首先会在宿主机上创建一个虚拟网卡kube-ipvs0,并为它分配 Service VIP 作为 IP 地址。

接着kube-proxy通过Linux的IPVS模块为这个 IP 地址添加三个 IPVS 虚拟主机,并设置这三个虚拟主机之间使用轮询模式 来作为负载均衡策略。

kube-proxy监听API Server中service和endpoint的变化情况,调用netlink 接口创建相应的ipvs 规则,并定期将ipvs规则与 Services和 Endpoints同步。

IPVS代理模式基于netfilter hook函数,该函数类似于iptables模式,但使用hash表作为底层数据结构,在内核空间中工作。这意味着IPVS模式下的kube-proxy使用更低的重定向流量。其同步规则的效率和网络吞吐量也更高。

IPVS 模式支持更多的负载均衡策略

  • 轮询(Round Robin,RR):依次将请求分配到后端服务器,循环往复。
  • 加权轮询(Weighted Round Robin,WRR):根据服务器的权重分配请求,权重越高的服务器被分配到的请求越多。
  • 最少连接(Least Connections,LC):将请求分配到当前连接数最少的服务器。
  • 源地址哈希(Source Hashing,SH):根据请求来源的 IP 地址进行散列,将相同 IP 地址的请求分配到同一台后端服务器上。
  • 永不排队(never queue)

Service Selector

Service 通过标签来选取服务后端,一般配合 Replication Controller 或者 Deployment 来保证后端容器的正常运行。这些匹配标签的 Pod IP 和端口列表组成 endpoints,由 kube-proxy 负责将服务 IP 负载均衡到这些 endpoints 上。

在Kubernetes中,Selector是用于标识一组资源的标签选择器。这些资源可以是Pod、Service或者其他Kubernetes对象,通过在资源上定义标签,可以将它们组织成为相互关联的逻辑单元。Selector是访问这些逻辑单元的关键方式。 Selector的语法形式类似于CSS选择器,在Kubernetes中,我们可以通过使用逗号运算符和括号运算符对多个Selector进行组合,以实现更加复杂的选择方式。

如何使用Selector?

在Kubernetes中,Selector常被用于指定需要操作的对象,例如在创建Service时,需要通过Selector指定它所要代理的Pod。

以下是一个Service的例子,它通过Selector选择标签键为"app",值为"nginx"的Pod:

apiVersion: v1 
kind: Service 
metadata: 
name: nginx-service 
	spec: 
	selector: 
		app: nginx 
		ports: - 
			protocol: TCP 
			port: 80 
			targetPort: 80 

在以上的配置文件中,selector字段用于指定Service所要代理的Pod。在这个例子中,Service将会代理所有标签键为"app",值为"nginx"的Pod,并将它们对外暴露在端口80上。

Pod DNS

种常见的 DNS 服务

  • kube-dns 也是(Cluster DNS)
  • CoreDNS

在 Kubernetes 1.11 及其以后版本中,推荐使用 CoreDNS

Kube-DNS

GitHub项目地址:https://github.com/kubernetes/dns

K8s Service网络详解(二),kubernetes,网络,容器,云原生

kube-dns 的 pod 中包含了 3 个容器

  • kube-dns
  • dns-dnsmasq
  • dns-sidecar

各个容器功能:

kube-dns容器功能

  • 提供service name域名的解析(用于k8s集群内部的域名解析),监视k8s Service资源并更新DNS记录
  • 替换etcd,使用TreeCache数据结构保存DNS记录并实现SkyDNS的Backend接口
  • 接入SkyDNS,对dnsmasq提供DNS查询服务

dnsmasq容器功能

  • 对集群提供DNS查询服务
  • 设置kubedns为upstream
  • 提供DNS缓存,降低kubedns负载,提高性能

dns-sidecar容器功能

定期检查kubedns和dnsmasq的健康状态
为k8s活性检测提供HTTP API

CoreDNS

项目官网:https://coredns.io/

CoreDNS使用Go语言编写。What is CoreDNS?

CoreDNS实现非常灵活,几乎所有功能,都是以插件的方式实现,插件可以是独立使用,也可以协同完成 “DNS 功能”。

有一些插件与Kubernetes通信以提供服务发现,这些插件可以从文件或数据库中读取数据。

Miek Gieben 在 2016 年编写了 CoreDNS 的初始版本,在此之前他还写过一个叫作 SkyDNS 的 DNS 服务器,以及一个用 Go 语言写的 DNS 函数库 Go DNS。

可以通过维护 Corefile,即 CoreDNS 配置文件, 来配置 CoreDNS 服务器。与 BIND 的配置文件的语法相比,CoreDNS 的 Corefile 使用起来非常简单。作为一个集群管理员,你可以修改 CoreDNS Corefile 的 ConfigMap, 以更改 DNS 服务发现针对该集群的工作方式。

CoreDNS的限制

目前 CoreDNS 仍然有一些特别的限制,使得它并不适合所有的 DNS 服务器场景。其中最主要的是,CoreDNS 不支持完整的递归(recursion)功能;即,CoreDNS 不能从根 DNS 命名空间开始处理查询。查询根 DNS 服务器并跟踪引用直到从某个权威 DNS 服务器返回最终结果,需要依赖其他 DNS 服务器(通常称为转发器(forwarder))来实现。

Corefile 配置

在 Kubernetes 中,CoreDNS 安装时使用如下默认 Corefile 配置:

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
        errors
        health {
            lameduck 5s
        }
        ready
        kubernetes cluster.local in-addr.arpa ip6.arpa {
            pods insecure
            fallthrough in-addr.arpa ip6.arpa
            ttl 30
        }
        prometheus :9153
        forward . /etc/resolv.conf
        cache 30
        loop
        reload
        loadbalance
    }    

Corefile 配置包括以下 CoreDNS 插件:

  • errors:错误记录到标准输出。

  • health:在 http://localhost:8080/health 处提供 CoreDNS 的健康报告。 在这个扩展语法中,lameduck 会使此进程不健康,等待 5 秒后进程被关闭。

  • ready:在端口 8181 上提供的一个 HTTP 端点, 当所有能够表达自身就绪的插件都已就绪时,在此端点返回 200 OK。

  • kubernetes:CoreDNS 将基于服务和 Pod 的 IP 来应答 DNS 查询。 你可以在 CoreDNS 网站找到有关此插件的更多细节。

    • 你可以使用 ttl 来定制响应的 TTL。默认值是 5 秒钟。TTL 的最小值可以是 0 秒钟, 最大值为 3600 秒。将 TTL 设置为 0 可以禁止对 DNS 记录进行缓存。

    • pods insecure 选项是为了与 kube-dns 向后兼容。

    • 你可以使用 pods verified 选项,该选项使得仅在相同名字空间中存在具有匹配 IP 的 Pod 时才返回 A 记录。

    • 如果你不使用 Pod 记录,则可以使用 pods disabled 选项。

  • prometheus:CoreDNS 的度量指标值以 Prometheus 格式(也称为 OpenMetrics)在 http://localhost:9153/metrics 上提供。

  • forward: 不在 Kubernetes 集群域内的任何查询都将转发到预定义的解析器 (/etc/resolv.conf)。

  • cache:启用前端缓存。

  • loop:检测简单的转发环,如果发现死循环,则中止 CoreDNS 进程。

  • reload:允许自动重新加载已更改的 Corefile。 编辑 ConfigMap 配置后,请等待两分钟,以使更改生效。

  • loadbalance:这是一个轮转式 DNS 负载均衡器, 它在应答中随机分配 A、AAAA 和 MX 记录的顺序。

DNS 记录

DNS 记录 Service

A/AAAA 记录

普通Service 和 没有集群 IP 的Headless Service 都会被赋予一个形如 my-svc.my-namespace.svc.cluster-domain.example 的 DNS A 和/或 AAAA 记录

与普通 Service 不同,无头Service(Headless Service)的DNS记录会被解析成对应 Service 所选择的 Pod IP 的集合。 客户端要能够使用这组 IP,或者使用标准的轮转策略从这组 IP 中进行选择。

SRV 记录

Kubernetes 根据 Service(普通 Service 或无头 Service 均可) 中的命名端口创建 SRV 记录。每个命名端口, SRV 记录格式为 _port-name._port-protocol.my-svc.my-namespace.svc.cluster-domain.example

普通 Service,该记录会被解析成端口号和域名:my-svc.my-namespace.svc.cluster-domain.example

无头 Service,该记录会被解析成多个结果,及该服务的每个后端 Pod 各一个 SRV 记录, 其中包含 Pod 端口号和格式为 hostname.my-svc.my-namespace.svc.cluster-domain.example 的域名。

DNS 记录 Pod

A/AAAA 记录

一般而言,Pod 会对应如下 DNS 名字解析:

pod-ip-address.my-namespace.pod.cluster-domain.example

例如,对于一个位于 default 名字空间,IP 地址为 172.17.0.3 的 Pod, 如果集群的域名为 cluster.local,则 Pod 会对应 DNS 名称:

172-17-0-3.default.pod.cluster.local

通过 Service 暴露出来的所有 Pod 都会有如下 DNS 解析名称可用:

pod-ip-address.service-name.my-namespace.svc.cluster-domain.example

DNS 配置策略

参阅:Pod 的 DNS 策略

每个Pod所使用的DNS策略,是通过pod.spec.dnsPolicy字段设置的,共有4种DNS策略:

  • ClusterFirst:默认策略,表示使用集群内部的CoreDNS来做域名解析,Pod内/etc/resolv.conf文件中配置的nameserver是集群的DNS服务器,即kube-dns的地址。
  • Default:“Default” 不是默认的 DNS 策略。Pod直接继承集群node节点的域名解析配置,也就是,Pod会直接使用宿主机上的/etc/resolv.conf文件内容。
  • None:忽略k8s集群环境中的DNS设置,Pod会使用其dnsConfig字段所提供的DNS配置,dnsConfig字段的内容要在创建Pod时手动设置好。
  • ClusterFirstWithHostNet:宿主机与 Kubernetes 共存,这种情况下的POD,既能用宿主机的DNS服务,又能使用kube-dns的Dns服务,需要将hostNetwork打开。

ClusterFirst

apiVersion: v1
kind: Pod
metadata:
   name: mypod
   labels:
      app: mypod
spec:
   containers:
     - name: mynginx
       image: mynginx:v1
   dnsPolicy: ClusterFirst       # 字段设置为ClusterFirst(该值为默认值,不设置也是该值)

# namserver指向kube-dns service地址
$ kubectl exec mypod -- cat /etc/resolv.conf 
nameserver 241.254.0.10
search default.svc.cluster.local svc.cluster.local cluster.local localdomain
options ndots:5

Default

apiVersion: v1
kind: Pod
metadata:
   name: mypod
   labels:
      app: mypod
spec:
   containers:
     - name: mynginx
       image: mynginx:v1
   dnsPolicy: Default

# pod内的resolv.conf与宿主机的resolv.conf一致
$ kubectl exec mypod -- cat /etc/resolv.conf 
nameserver 192.168.234.2
search localdomain

$ cat /etc/resolv.conf 
search localdomain
nameserver 192.168.234.2

None

apiVersion: v1
kind: Pod
metadata:
   name: mypod
   labels:
      app: mypod
spec:
   containers:
     - name: mynginx
       image: mynginx:v1
   dnsPolicy: None
   dnsConfig:
     nameservers: ["192.168.234.1","192.168.234.2"]  # 最多可指定3个IP,当Pod的dnsPolicy设置为None时,列表必须至少包含一个IP地址
     searches:                                       # Pod中主机名查找的DNS搜索域列表
       - default.svc.cluster.local
       - svc.cluster.local
       - cluster.local
     options:
       - name: ndots
         value: "5"
kubectl exec mypod -- cat /etc/resolv.conf 
nameserver 192.168.234.1
nameserver 192.168.234.2
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

ClusterFirstWithHostNet

apiVersion: v1
kind: Pod
metadata:
   name: mypod
   labels:
      app: mypod
spec:
   containers:
     - name: mynginx
       image: mynginx:v1
   hostNetwork: true   		# hostNetwork为true时,表示与宿主机共享网络空间
   dnsPolicy: ClusterFirst  # 即使dnsPolicy设置为集群优先,由于hostNetwork: true也会强制将dnsPolicy设置为Default
# 所以Pod内resolv.conf与宿主机相同
$ kubectl exec mypod -- cat /etc/resolv.conf 
nameserver 192.168.234.2
search localdomain

对于以 hostNetwork 方式运行的 Pod,应将其 DNS 策略显式设置为 “ClusterFirstWithHostNet”。否则,以 hostNetwork 方式和 "ClusterFirst" 策略运行的 Pod 将会做出回退至 "Default" 策略的行为。

apiVersion: v1
kind: Pod
metadata:
   name: mypod
   labels:
      app: mypod
spec:
   containers:
     - name: mynginx
       image: mynginx:v1
   hostNetwork: true
   dnsPolicy: ClusterFirstWithHostNet
#只有dnsPolicy: ClusterFirstWithHostNet,此时pod既可以使用宿主机网络也可以使用kube-dns网络
$ kubectl exec -it mypod -- cat /etc/resolv.conf 
nameserver 241.254.0.10
search default.svc.cluster.local svc.cluster.local cluster.local localdomain
options ndots:5

Pod 的主机名设置优先级

Pod 规约中包含一个可选的 hostname 字段,可以用来指定一个不同的主机名。当这个字段被设置时,它将优先于 Pod 的名字成为该 Pod 的主机名(同样是从 Pod 内部观察)。

例如:给定一个 spec.hostname 设置为 “my-host” 的 Pod, 该 Pod 的主机名将被设置为 “my-host”

Pod的子域名

Pod 规约还有一个可选的 subdomain 字段,可以用来表明该 Pod 是名字空间的子组的一部分。

例如:某 Pod 的 spec.hostname 设置为 “foo”spec.subdomain 设置为 “bar”, 在名字空间 “my-namespace” 中,主机名称被设置成 “foo” 并且对应的完全限定域名(FQDN)为 “foo.bar.my-namespace.svc.cluster-domain.example”(还是从 Pod 内部观察)。

Ingress

Service是基于四层TCP和UDP协议转发的,而Ingress可以基于七层的HTTP和HTTPS协议转发,可以通过域名和路径做到更细粒度的划分,如下图所示。

K8s Service网络详解(二),kubernetes,网络,容器,云原生

https://kubernetes.io/zh-cn/docs/concepts/services-networking/ingress/

Ingress 是对集群中服务的外部访问进行管理的 API 对象

Ingress 可以提供负载均衡、SSL 终结和基于名称的虚拟托管。

K8s Service网络详解(二),kubernetes,网络,容器,云原生

Ingress工作机制

要想使用Ingress功能,必须在Kubernetes集群上安装Ingress Controller。Ingress Controller有很多种实现,最常见的就是Kubernetes官方维护的NGINX Ingress Controller

对于所有 Kubernetes API,一旦它们被正式发布(GA),就有一个创建、维护和最终弃用它们的过程。Ingress-NGINX 将拥有独立的分支和发布版本来支持这个模型,与 Kubernetes 项目流程相一致。 Ingress-NGINX 项目的未来版本将跟踪和支持最新版本的 Kubernetes。

团队目前正在升级 Ingress-NGINX 以支持向 v1 的迁移, 你可以在此处跟踪进度。

同时,团队会确保没有兼容性问题:

  • 更新到最新的 Ingress-NGINX 版本, 目前是 controller-v1.8.1。

  • Kubernetes 1.22 发布后,请确保使用的是支持 Ingress 和 IngressClass 稳定 API 的最新版本的 Ingress-NGINX。

  • 使用集群版本 >= 1.19 测试 Ingress-NGINX 版本 v1.0.0-alpha.2,并将任何问题报告给项目 GitHub 页面。

外部请求首先到达Ingress Controller,Ingress Controller根据Ingress的路由规则,查找到对应的Service,进而通过Endpoint查询到Pod的IP地址,然后将请求转发给Pod。

参阅:

k8s中的endpoint

k8s 理解Service工作原理

K8s 核心组件讲解——kube-proxy

详解k8s 4种类型Service

kubernetes集群内部DNS解析原理、域名解析超时问题记录

CoreDNS简介

Kubernetes网络

Service文章来源地址https://www.toymoban.com/news/detail-607704.html

到了这里,关于K8s Service网络详解(二)的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • K8s Service网络详解(二)

    Kubernetes 在设计之初就充分考虑了针对容器的 服务发现 与 负载均衡 机制。 Service 资源,可以通过 kube-proxy 配合 cloud provider 来适应不同的应用场景。 Service相关的事情都由Node节点上的 kube-proxy处理。在Service创建时Kubernetes会分配IP给Service,同时通过API Server通知所有kube-proxy有新

    2024年02月15日
    浏览(53)
  • 【云原生 | Kubernetes 系列】K8s 实战 管理 Secret 详解

    Secret 是一种包含少量敏感信息例如密码、令牌或密钥的对象。 这样的信息可能会被放在 Pod 规约中或者镜像中。 用户可以创建 Secret,同时系统也创建了一些 Secret。 一个 Secret 可以包含 Pod 访问数据库所需的用户凭证。 例如,由用户名和密码组成的数据库连接字符串。 你可

    2024年02月02日
    浏览(59)
  • 【云原生 | Kubernetes 系列】K8s 实战 如何给应用注入数据 II 将pod数据传递给容器

    在上一篇文章中,我们学习了针对容器设置启动时要执行的命令和参数、定义相互依赖的环境变量、为容器设置环境变量,三种设置方式,本篇文章,我们将继续学习数据的传递。 有两种方式可以将 Pod 和 Container 字段传递给运行中的容器: 环境变量 卷文件 这两种呈现 Pod

    2024年01月25日
    浏览(123)
  • 详解K8S网络模型(包含Service讲解)

    无意中翻阅官方文档,看到了Kubernetes中的网络模型, 于是,开始学习,分享如下。 官方文档: 网络模型https://kubernetes.io/docs/concepts/services-networking/ Servicehttps://kubernetes.io/docs/concepts/services-networking/service/ 集群中的每个Pod会在集群范围内获取自己唯一的IP地址。 因此,Pod间不需

    2024年02月07日
    浏览(38)
  • 【Kubernetes】k8s中容器之间、pod之间如何进行网络通信?

    首先来回顾一下Pod: Pod 是用于构建应用程序的最小可部署对象。单个 Pod 代表集群中正在运行的工作负载,并 封装一个或多个 Docker 容器、任何所需的存储以及唯一的 IP 地址 。 集群中每一个 Pod 都会获得自己的、 独一无二的 IP 地址。一个Pod里的一组容器共享相同的IP地址。

    2024年04月28日
    浏览(69)
  • 云原生Kubernetes:K8S集群实现容器运行时迁移(docker → containerd) 与 版本升级(v1.23.14 → v1.24.1)

    目录 一、理论 1.K8S集群升级 2.环境 3.升级策略 4.master1节点迁移容器运行时(docker → containerd)  5.master2节点迁移容器运行时(docker → containerd)  6.node1节点容器运行时迁移(docker → containerd)  7.升级集群计划(v1.23.14 → v1.24.1) 8.升级master1节点版本(v1.24.1) 9.升级master2节点版本

    2024年02月03日
    浏览(66)
  • 云上攻防-云原生篇&;Kubernetes&;K8s安全&;API&;Kubelet未授权访问&;容器执行

    curl -XPOST -k “https://192.168.139.132:10250/run///” -d “cmd=id” 执行的命令是test03容器里的命令,需要进行容器逃逸。 1、攻击8080端口:API Server(Master)未授权访问 旧版本的k8s的API Server默认会开启两个端口:8080和6443。 6443是安全端口,安全端口使用TLS加密;但是8080端口无需认证,

    2024年04月22日
    浏览(73)
  • Kubernetes(k8s):网络插件之Calico安装与详解

    💖The Begin💖点点关注,收藏不迷路💖 在Kubernetes集群中,网络插件对于容器间的通信以及与外部网络的连接至关重要。Calico是一个流行的Kubernetes网络插件,它提供了高性能的网络和安全解决方案,适用于各种部署场景。 Calico是一个开源的网络和安全解决方案,旨在简化和增

    2024年04月11日
    浏览(70)
  • Kubernetes技术--k8s核心技术Service服务

    1.service概述         Service 是 Kubernetes 最核心概念, 通过创建 Service,可以为一组具有相同功能的容器应用提供一个统一的入口地址,并且将请求负载分发到后端的各个容器应用上 。 2.service存在的意义 -1: 防止pod失联(服务发现) 我们先说一下什么叫pod失联。     -2:

    2024年02月10日
    浏览(43)
  • Kubernetes(k8s)服务service:service的发现和service的发布

    目录 一.系统环境 二.前言 三.Kubernetes service简介 四.使用hostPort向外界暴露应用程序 4.1 创建deploy 4.2 使用hostPort向外界暴露pod的端口 五.使用service服务向外界暴露应用程序 5.1 使用service服务向外界暴露pod 5.1.1 创建service服务 5.1.2 测试svc的负载均衡 六.service服务的发现 6.1 使用

    2024年02月08日
    浏览(54)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包