Kubernetes Service、Ingress、Ingress Controller

2023-05-16

Kubernetes 网络模型

K8S 是一种容器编排系统,可以方便地管理和部署容器应用程序。它支持通过四层负载和七层负载向容器集群中的应用程序提供负载均衡。

四层负载是一种基于传输层协议(例如TCP、UDP)的负载均衡方式,可以将来自客户端的请求均匀地分配给多个容器实例,以实现应用程序的高可用性和可伸缩性。K8S 中的四层负载均衡是通过内置的 kube-proxy 实现的,它可以将请求路由到不同的容器实例中,以实现负载均衡和故障转移。

七层负载是一种基于应用层协议(例如HTTP、HTTPS)的负载均衡方式,可以在不同的应用层流量之间进行智能路由,以提高应用程序的性能和可用性。K8S 中的七层负载均衡通常使用 Ingress Controller 实现,它可以监控集群中的 Ingress 资源,并自动配置负载均衡器来路由流量。 Ingress Controller 可以支持多种负载均衡算法(例如轮询、加权轮询、ip_hash等),也可以支持SSL终止、Websocket等高级功能

Kubernetes 对网络设施的基本要求

Pod 能够与所有其它节点上的 Pod 相互通信, 且不需要网络地址转译(NAT)
节点上的代理(比如:系统守护进程、kubelet)可以和节点上的所有 Pod 相互通信

Kubernetes 网络解决四方面的问题

Pod中的容器之间可以通过本地回路(loopback)相互通信
集群网络在不同 Pod 之间提供通信
Service API 允许向外暴露 Pod 中运行的应用, 以支持来自于集群外部的访问
Ingress 提供专门用于暴露 HTTP 应用程序、网站和 API 的额外功能

Service

  • K8S 可以保证任意 Pod 挂掉时自动从任意节点启动一个新的Pod进行代替,以及某个Pod超负载时动态对Pod进行扩容。每当 Pod 发生变化时其 IP地址也会发生变化,且Pod只有在K8S集群内部才可以被访问,为了解决Pod发生变化导致其IP动态变化以及对外无法访问的问题,K8S引进了 Service 的概念

  • K8S 使用 Service 来管理同一组标签下的 Pod ,当外界需要访问 Pod 中的容器时,只需要访问 Service 的这个虚拟 IP 和端口,由 Service 把外界的请求转发给它背后的Pod

Service暴露服务类型

1、ClusterIP(默认)

  • 自动为当前Service分配虚拟IP,在不重启Service前提下该IP是不会改变的,只能在集群内部访问

2、NodePort

  • 需要在K8S集群的所有 Node 节点上开放特定的端口【30000-32767】,通过(公网ip : 端口)访问Service服务。缺点:每个端口只能挂载一个Service,从安全角度讲开放更多的端口是存在一定风险的,从维护角度讲开放的端口越多维护的成本越大
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: NodePort
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    # 默认情况下,为了方便起见,`targetPort` 被设置为与 `port` 字段相同的值。
    - port: 80
      targetPort: 80
      # 可选字段
      # 默认情况下,为了方便起见,Kubernetes 控制平面会从某个范围内分配一个端口号(默认:30000-32767)
      nodePort: 30007

3、LoadBalancer

  • 和Nodeport相似,目的都是向外暴露一个端口,但 LoadBalancer 模式需要开发者在K8S集群外部的公有云服务器上做一个负载均衡设备(当前主流的阿里云、腾讯云、华为云、微软云等等厂商都有提供相关收费的服务),外部服务发送到公有云服务上的请求都会被负载并转发到K8S集群中LoadBalancer服务上

  • 如果要在私网环境下测试LoadBalancer,必须要创建一个MetalLB, MetalLB相当于一个负载均衡器的角色

  • LoadBalancer原理:外部请求首先被转发到外部LB负载设备,再通过匹配规则转发到k8s集群的任意node节点上,最终通过Service资源找到对应的pod

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376
  clusterIP: 10.0.171.239
  type: LoadBalancer
status:
  loadBalancer:
    ingress:
    - ip: 192.0.2.127

4、ExternalName

  • 通过返回 CNAME 记录和对应值,可以将服务映射到 externalName 字段的内容(例如:foo.bar.example.com),无需创建任何类型代理
    注意:需要使用 kube-dns 1.7 及以上版本或者 CoreDNS 0.0.8 及以上版本才能使用 ExternalName 类型
apiVersion: v1
kind: Service
metadata:
  name: my-service
  namespace: prod
spec:
  type: ExternalName
  externalName: my.database.example.com

Service代理模式

Service 创建成功后会通过 api-server 向 etcd 中写入相关配置信息,kube-proxy会监听创建好的配置信息并将最新的service配置信息转化成对应的访问规则,最终实现外网对Pod的访问。常见的service访问规则有:iptables 和 ipvs

1、iptables

kube-proxy 为 service 后端的每个Pod创建对应的iptables规则,当用户访问ClusterIP时,直接将发送到ClusterIP的请求重定向到Pod
缺点:kube-proxy 不承担四层路由转发的角色,只负责创建iptables规则,无法实现LB策略

2、ipvs(性能高于iptables)

kube-proxy 监控Pod的变化并创建相应的ipvs规则,当用户访问ClusterIP时,直接将发送到ClusterIP的请求重定向到Pod
相比于iptables,支持LB策略

3、切换到IPVS模式

  • 查询当前代理模式
kubectl get pod -o wide -n kube-system | grep kube-proxy # 查新kube-proxy有关的pod

在这里插入图片描述

kubectl logs -n kube-system kube-proxy-7bst7

在这里插入图片描述

  • ipvs 安装(K8S集群的所有节点安装)
# yum install -y ipvsadm.x86_64   # Centos
apt install -y ipvsadm ipset # Debian
ipvsadm -Ln # 查看ipvs模式开启状态

在这里插入图片描述

  • 切换Sevice代理模式为ipvs(K8S集群的Master节点修改)
kubectl edit configmap kube-proxy -n kube-system # 编辑configmap将mode改为ipvs 

在这里插入图片描述

  • 删除指定Pod
kubectl get pod -o wide -n kube-system | grep kube-proxy

在这里插入图片描述

kubectl delete pod kube-proxy-7bst7 -n kube-system # 删除pod后自动创建新的Pod
kubectl delete pod kube-proxy-9l7qr -n kube-system # 删除pod后自动创建新的Pod
kubectl delete pod kube-proxy-cqht2 -n kube-system # 删除pod后自动创建新的Pod
kubectl delete pod kube-proxy-h8znm -n kube-system # 删除pod后自动创建新的Pod
kubectl delete pod kube-proxy-l4p42 -n kube-system # 删除pod后自动创建新的Pod
kubectl delete pod kube-proxy-xlqtg -n kube-system # 删除pod后自动创建新的Pod

在这里插入图片描述

4、验证IPVS

# kubectl get service -o wide -n kube-system # 查询Service
#
NAME           TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)                  AGE   SELECTOR
calico-typha   ClusterIP   10.96.26.184   <none>        5473/TCP                 13d   k8s-app=calico-typha
kube-dns       ClusterIP   10.96.0.2      <none>        53/UDP,53/TCP,9153/TCP   13d   k8s-app=kube-dns
# ipvsadm -Ln
#
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  10.96.0.1:443 rr
  -> 192.168.111.30:6443          Masq    1      1          0
  -> 192.168.111.31:6443          Masq    1      1          0
  -> 192.168.111.32:6443          Masq    1      1          0
  
TCP  10.96.0.2:53 rr
  -> 10.244.166.141:53            Masq    1      0          0
UDP  10.96.0.2:53 rr
  -> 10.244.166.141:53            Masq    1      0          0
  
TCP  10.96.0.2:9153 rr
  -> 10.244.166.141:9153          Masq    1      0          0
  
TCP  10.96.26.184:5473 rr
  -> 192.168.111.40:5473          Masq    1      0          0

Service - 部署Nginx应用并对外访问

方式1:创建deployment并将其显示为Service

# kubectl create deployment <deployment名称> --image=<镜像> --replicas=<pod副本数量> -n <命名空间名称>
# kubectl expose deployment <deployment名称> --name=<Service名称> --type=<Service服务类型> --port=<service端口> --target-port=<容器端口> -n <命名空间名称>
#
# 强制删除Pod
# kubectl delete ns <命名空间名称> --force --grace-period=0 
# kubectl delete deployment <deployment名称> -n <命名空间名称> --force --grace-period=0
# kubectl delete pod <pod名称> -n <命名空间名称> --force --grace-period=0
kubectl create ns dev && kubectl get ns dev
kubectl create deployment nginx --image=nginx --replicas=1 -n dev
# 暴露 Deployment 为 Service 服务(将Service的8080端口转发至容器的80端口)
kubectl expose deployment nginx --name=nginx --type=NodePort --port=8080 --target-port=80 -n dev
kubectl get deployment,pods,service -n dev -o wide # 查看创建的Deployment和Pod信息
kubectl logs -n dev nginx-748c667d99-phdxv # 查看Pod创建的日志
kubectl describe -n dev pod nginx-748c667d99-phdxv # 查看Pod创建的详细信息

方式2:创建Service(yaml文件)

注意:基于Kubernetes Pod和工作负载文章已创建好的资源进行演示

  • 创建 Service
vi service-nginx.yaml # 在线编辑文件
apiVersion: v1
kind: Service
metadata:
  namespace: dev
  name: nginx
  labels: 
    app: nginx
spec: 
  selector: # 标签选择器,指定对哪些deployment的Pod进行暴露
    app: nginx # deployment名称
  # type: NodePort # Service暴露服务的类型(如果需要通过公网访问请开启)
  ports:
  - protocol: TCP # 通讯协议
    # nodePort: 30000 # Node端口,结合 type: NodePort 使用
    port: 8080 # service端口
    targetPort: 80 # pod端口
kubectl create -f service-nginx.yaml
kubectl delete -f service-nginx.yaml
  • 查看已创建的资源
kubectl get deployment,replicaSet,pods,service -n dev -o wide --show-labels

在这里插入图片描述

curl 10.244.104.10:80 # 任意Node节点,通过Pod的IP访问nginx
curl 10.244.166.157:80 # 任意Node节点,通过Pod的IP访问nginx
curl 10.96.73.217:8080 # 任意Node节点,通过Service的IP访问Nginx
http://192.168.111.40:30000 # 浏览器通过任意Node节点访问nginx
http://192.168.111.41:30000 # 浏览器通过任意Node节点访问nginx
http://192.168.111.42:30000 # 浏览器通过任意Node节点访问nginx

Ingress

ingress是k8s集群的请求入口,可以理解为对多个service的二次抽象,一般包括ingress资源对象及ingress-controller两部分

Ingress(k8s内置的资源对象)

  • Ingress 是 k8s 的资源对象,用于定义外部的(HTTP 和 HTTPS)请求如何转发到 Service 服务的规则
    在这里插入图片描述

ingress-controller(需要单独安装)

  • ingress-controller 不是 k8s 自带的组件,只是一个统称,可以选择不同的 ingress-controller 实现对 service 的反向代理及负载均衡,常用的 ingress-controller 产品有:F5 Networks、Kong、Traefik、NGINXHaProxyIstio

  • ingress-controller 本质是一个 pod,内部运行了 daemon 程序反向代理程序。daemon程序通过 K8S API 不断监控集群的变化,对 ingress 定义的规则进行解析并刷新配置到反向代理程序
    在这里插入图片描述

Ingress 暴露服务的方式

模式1、Deployment + NodePort 的 Service 模式

1、基于 Deployment 部署 ingress-controller 并创建对应的 Service 服务(type为NodePort),将ingress暴露在集群节点ip的特定端口上
2、一般适用于宿主机ip地址相对固定不变的场景,由于 Nodeport 暴露的端口是随机端口,一般会在前面再搭建一套负载均衡器来转发请求,NodePort方式暴露 ingress 虽然简单,但多了一层NAT,在请求量级很大时对性能会有一定影响

模式2、Deployment + LoadBalancer 的 Service 模式

1、基于 Deployment 部署 ingress-controller 并创建对应的 Service 服务(type为 LoadBalancer)
2、此模式需要将 ingress 部署在公有云,大部分公有云都会为 LoadBalancer 的 service 自动创建一个负载均衡器,通常还绑定了公网地址,只要把域名解析指向该公网地址就实现了集群服务的对外暴露

模式3、DaemonSet + HostNetwork + nodeSelector 的 Service 模式【推荐】

1、基于 DaemonSet 结合 NodeSelector 来部署 ingress-controller 到特定的 node 上,再通过 HostNetwork 把该 pod 与宿主机 node 的网络打通,通过宿主机的80/433端口访问服务,此时的ingress-controller所在的node节点就类似传统架构的边缘节点(房入口的nginx服务器)
2、该方式相对NodePort模式的性能更好,缺点:由于直接利用宿主机节点的网络和端口,一个node节点只能部署一个ingress-controller,适合大并发的生产环境使用

Ingress 安装

注意:不同的暴露服务方式对应的安装方式是不一样的
安装教程

【模式3】Ingress - 部署 httpd 应用并对外访问

创建 Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: dev
  name: httpd
  labels:
    app: httpd
spec: 
  selector: # Pod标签选择器,指定当前控制器管理哪些Pod
    matchLabels:
      app: httpd
    matchExpressions:
      - { key: app, operator: In, values: [httpd] }
  replicas: 1 # 默认Pod副本数量
  template: 
      metadata:
        labels: 
          app: httpd
      spec:
        #hostNetwork: true # 开启后,可以直接通过宿主机的80/433端口访问
        nodeName: node2 # 将Pod调度到Node2工作节点
        containers:
        - name: httpd
          image: httpd
          imagePullPolicy: IfNotPresent
          ports: 
          - name: httpd 
            protocol: TCP
            containerPort: 80 # Pod下的容器端口

创建 Service

apiVersion: v1
kind: Service
metadata:
  namespace: dev
  name: httpd
spec: 
  selector: # deployment标签选择器,指定当前Service管理哪些控制器
    app: httpd
  #type: NodePort # Service暴露服务的类型,默认ClusterIP类型
  ports:
  - protocol: TCP # 通讯协议
    #nodePort: 30000 # 集群上所有Node节点端口
    port: 8080 # Service端口
    targetPort: 80 # Pod端口

创建 Ingress

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  namespace: dev
  name: ingress-httpd-http
  annotations:
    nginx.ingress.kubernetes.io/use-regex: "true"
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  rules:
    - host: www.lixing40.com # 通过Node1节点访问,默认Ingress-Nginx-Controller部署在Node1节点
      http:
        paths:
          - pathType: Prefix
            path: /httpd
            backend:
              service:
                name: httpd # Service名称
                port:
                  number: 8080 # Service端口
创建Ingress过程中如果报如下错误:
“Error from server (InternalError): error when creating “ingress-srv.yaml”: Internal error occurred: failed calling webhook “validate.nginx.ingress.kubernetes.io”: Post “https://ingress-nginx-controller-admission.ingress-nginx.svc:443/networking/v1/ingresses?timeout=10s”: dial tcp 10.102.20.133:443: connect: connection refused
#
原因:
删除nginx-ingress不彻底(没有删除ValidatingWebhookConfiguration ingress-nginx-admission),当我再次安装nginx-ingress之后,创建自定义的ingress就会报这个错误
#
请按照如下操作:
kubectl get ValidatingWebhookConfiguration
kubectl delete -A ValidatingWebhookConfiguration ingress-nginx-admission

查看dev命名空间下的资源对象

kubectl get deployment,replicaSet,pods,service,ingress -n dev -o wide

在这里插入图片描述

  • 任意工作节点上通过Pod访问httpd服务
curl 10.244.104.14
  • 任意工作节点上通过Service访问httpd服务
curl 10.96.170.140:8080

查看ingress-nginx命名空间下的资源对象

kubectl get deployment,replicaSet,pods,service,ingress -n ingress-nginx -o wide

在这里插入图片描述

[HTTP]各节点通过域名访问httpd服务

  • 修改 Node1节点的host文件
vi /etc/hosts # 编辑Host文件,添加当前节点的ip和自定义域名
	192.168.111.40 www.lixing40.com
# 在Node1节点上访问:
curl http://www.lixing40.com/httpd
  • 修改win11本地的host文件
# k8s主节点ip    自定义域名
192.168.111.40 www.lixing40.com
# 在win11本地浏览器访问
http://www.lixing40.com/httpd

[HTTPS]各节点通过域名访问httpd服务

对于ingress TSL的基本要求是有TSL/SSL证书,每个TLS证书都有一个过期日期,必须在证书过期前跟新证书,一般我们可以通过下面几种方法获得证书:
1、自签名的证书:用我们自己的CA(证书颁发机构)来创建和签名TLS证书。这种方法非常适合开发环境,你可以把根证书分享给团队,方便浏览器信任自签名的证书。参考这篇博客create self-signed certificate来创建你自己的证书
2、购买一个TLS证书:从浏览器和操作系统信任的知名CA(证书颁发机构)购买TLS证书
3、使用Letsencrpt证书:Letsencrpt是一家非盈利的可信证书颁发机构,他们提供免费的TLS证书
SSL是由ingress controller来处理的,而不是ingress。把TLS证书作为kubernetes sercet添加到ingress里面时,ingress controller就能获取到它,并使其变为自己的配置信息
  • 创建kubernetes TLS sercet(Master1节点操作)
# 创建证书文件夹
mkdir -p /etc/certs/ingress
# 生成TLS证书
# openssl req -x509 -nodes -days <证书有效天数> -newkey rsa:2048 -keyout <tls.key保存路径> -out <tls.crt保存路径> -subj "/CN=<名称>/O=<名称>"
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/certs/ingress/tls.key -out /etc/certs/ingress/tls.crt -subj "/CN=www.lixing40.com/O=www.lixing40.com"
# 根据生成的TLS证书文件创建集群的secret
# kubectl create secret tls <名称> --key <tls.key路径> --cert <tls.crt路径> -n <命名空间>
kubectl create secret tls tls-ingress-httpd --key /etc/certs/ingress/tls.key --cert /etc/certs/ingress/tls.crt -n dev
# 查看新建TLS证书配置
kubectl get secret tls-ingress-httpd -n dev
  • 创建 Ingress
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  namespace: dev
  name: ingress-httpd-https
  annotations:
    nginx.ingress.kubernetes.io/use-regex: "true"
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - www.lixing40.com
    secretName: tls-ingress-httpd # 根据生成的TLS证书文件创建集群的secret
  rules:
    - host: www.lixing40.com # 通过Node1节点访问,默认Ingress-Nginx-Controller部署在Node1节点
      http:
        paths:
          - pathType: Prefix
            path: /httpd
            backend:
              service:
                name: httpd # Service名称
                port:
                  number: 8080 # Service端口
# 在win11本地浏览器访问
http://www.lixing40.com/httpd
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)

Kubernetes Service、Ingress、Ingress Controller 的相关文章

随机推荐

  • shell脚本自动部署Springboot项目到云服务器

    如何用shell脚本自动部署Springboot项目 在开发Springboot项目时 xff0c 我们可能需要经常更新服务器上的代码 xff0c 并把项目部署在服务器上 xff0c 而每次都需要输入一连串的命令 xff0c 这样效率实在不
  • lubuntu操作及桌面配置(1)

    lubuntu操作及桌面配置 xff08 1 xff09 1 桌面环境 xff1a LXDE 特点 xff1a LXDE的资源占用更小 xff0c 适合在配置比较低的电脑上工作 它有很多特点 xff0c 如程序间无相依性 2 LXDE桌面环
  • 不可思议的OOM

    作者 xff1a 陶菜菜 链接 xff1a http www jianshu com p e574f0ffdb42 來源 xff1a 简书 著作权归作者所有 商业转载请联系作者获得授权 xff0c 非商业转载请注明出处 摘要 本文发现了一类
  • Linux防火墙firewalld不生效,无法拦截Docker映射端口

    今天出现了一个奇怪的现象 xff0c centos服务器上的防火墙 firewall 没有开放8103端口 xff0c 但是依然可以访问 服务器开放的端口如下 xff1a 可以看出并没有开放8103端口 开放的服务如下 xff1a 也没有开
  • java各种集合类区别

    最近面试经常遇到java集合类的问题 xff0c 上网搜了一下 xff0c 做个笔记 百度的图 集合类 型主要有3种 xff1a set 集 xff09 list 列表 xff09 和map 映射 集合接口 分为 xff1a Collect
  • windows10下wsl2、Ubuntu20.04、中文设置、Rust、vscode、chrome谷歌浏览器安装配置总结

    1 Microsoft Store 中安装 windows Terminal 2 更新 wsl 或 Microsoft Store 中安装 wsl2 wsl span class token parameter variable versi
  • 【python算法】图的遍历与最小路径

    数据结构中 xff0c 图的应用场景非常广泛 xff0c 与我们的生活息息相关 xff0c 在基于图做的应用中 xff0c 比较典型的有 xff1a 在交通规划中的最小生成树 xff0c 用于导航的最短路径等 比如下图 这里 xff0c 我
  • 安装react-devtools时npm install失败解决方法

    网上的所有教程基本都是把v3zip下载下来后淘宝镜像安装依赖 xff1a npm registry https registry npm taobao org install 但按照这种方法会出现如下报错 npm ERR code 1 np
  • java -虹软Caused by: java.lang.UnsatisfiedLinkError: Can‘t load library: **\WIN64\libarcsoft_face.dll

    错误详情 Caused by java lang UnsatisfiedLinkError Can t load library F code WIN64 libarcsoft face dll 如图 xff1a 错误原因 一般遇到问题 x
  • Fragment的使用(Android实现底部导航栏)

    xfeff xfeff xfeff xfeff 一 布局页面添加 1 添加四个切换页面的布局 xff08 1 xff09 四个切换页面的布局 四个页面相同 xff09 xff1a lt xml version 61 34 1 0 34 en
  • Java 线程安全

    引入1 xff1a 计算机内存模型 span class token number 1 span 因为向主内存中读写数据的速度要远远小于 span class token constant CPU span 处理数据的速度 xff0c 所有
  • Debian11安装MySql8

    下载地址点击这里 官方安装文档点击这里 Installing MySQL on Linux Using Debian Packages from Oracle xff09 安装 span class token comment 安装依赖 s
  • 消息队列技术的介绍和原理(MQ)

    最近要做一个项目准备用分布式消息队列 xff0c 花点时间看了下 消息队列技术是分布式应用间交换信息的一种技术 消息队列可驻留在内存或磁盘上 队列存储消息直到它们被应用程序读走 通过消息队列 xff0c 应用程序可独立地执行 它们不需要知道
  • win10如何修改C盘User下的用户名

    温馨提示 仅供参考 xff0c 不建议小白在本机测试 xff0c 不然会有需要 重装 的风险 建议操作前设置还原点 重要数据备份 xff01 xff01 xff01 然后Win11就别尝试了 xff0c 而且一旦失败的话 xff0c 就只能
  • 极狐Gitlab操作手册

    用户管理 普通用户可以访问他们的群组和项目 用户可以无限制地访问所有群组 项目 用户和功能 群组管理 项目管理 创建项目 为项目添加成员 其它设置 为当前用户配置SSH密钥 本地生成SSH密钥 提交本地项目到gitlab span clas
  • WIN11之RocketMQ5.0安装

    官网地址 xff1a https rocketmq apache org docs quick start 下载地址 xff1a https rocketmq apache org dowloading 下载 系统要求 span class
  • Kubernetes 对象

    什么是对象 K8s集群中创建的任何东西都可以被视为对象 xff1a Deployment Pod Service等等 对象类型 kubectl api resources span class token comment 查询所有type
  • K8S DashBoard控制台

    前言 Dashboard 是基于网页的 Kubernetes 用户界面 你可以使用 Dashboard 将容器应用部署到 Kubernetes 集群中 xff0c 也可以对容器应用排错 xff0c 还能管理集群资源 你可以使用 Dashbo
  • Debian11之基于二进制安装K8S(v1.26.x) 集群

    官网地址 xff1a https kubernetes io zh cn docs home supported doc versions 资源列表 主机IP主机名称主机角色软件192 168 111 30master1主节点1kube a
  • Kubernetes Service、Ingress、Ingress Controller

    Kubernetes 网络模型 K8S 是一种容器编排系统 xff0c 可以方便地管理和部署容器应用程序 它支持通过四层负载和七层负载向容器集群中的应用程序提供负载均衡 四层负载是一种基于传输层协议 xff08 例如TCP UDP xff0