在k8s中,客户端访问服务的链路流程,ingress--->service--->deployment--->pod--->container

ingress是一个API资源。

其核心作用是nginx网页服务器。

当客户端访问服务器不同的url时,

用不同的location提供服务。

在k8s之外,nginx的配置一般如下:

复制代码
http {
    server {
        listen       80;
        server_name  localhost;
        location / {
            root   html;             # 网页文件根目录
            index  index.html index.htm;    #默认首页
#设置默认首页为index.html,当用户在浏览器地址栏中只写域名或IP,不说访问什么页面时,服务器会把默认首页index.html返回给用户
        }

        location ~ \.php$ {          
 # "~"匹配正则表达式,
 # 当用户访问以.php结尾的网页文件时,服务器按照此模块的定义,提供动态网页服务
            root           html;                 
            fastcgi_pass   127.0.0.1:9000;
            fastcgi_index  index.php;
            include        fastcgi.conf;
       }
    }

在k8s平台,ingress调用nginx的服务,来实现不同的url对应不同的location.

用命令行创建ingress资源文件模版时,需要指定两个参数,

一个是--class=

另一个是--rule=

--class是控制器的类,表明ingress要调用哪个控制器的类作为ingress资源的控制器,

可选nginx和haproxy,一般用nginx

--rule是控制器提供服务的规则,

相当于平常写的location,

在k8s,用命令行创建ingress资源文件的模版时,

一般用--rule="/path=svc:port"来实现"location"的功能。

比如--rule="/hello=hello:3579"

当用户访问/hello路径时,ingress提供名为"hello"的服务,hello服务使3579端口

资源文件如下:

bash 复制代码
spec:
  ingressClassName: nginx
  rules:
  - http:
      paths:
      - pathType: Prefix
        path: /hello
        backend:
          service:
            name: hello
            port:
              number: 3579

path对应backend:

backend是service,也就是服务

服务名为hello,端口号为3579

定义一个服务名为hello,端口号为3579的后端服务。ingress就能连接到这个服务了。

资源文件如下,是一个nodeport类型的服务(service):

bash 复制代码
---
kind: Service
apiVersion: v1
metadata:
  name: hello
spec:
  type: NodePort
  selector:
    app: website
  ports:
  - name: web
    protocol: TCP
    port: 3579
    targetPort: http

nodeport是个端口转发类型的服务,

当服务请求到达一个计算节点时,

这个服务将被转发到一个后端端口,

图中的例子,后端端口是http.

而这个http实际上,

就是deployment管理的pod中的容器,所监听的端口名。

在deployment的资源文件中,

定义了一组以http为监听端口名的pod

资源文件如下:

bash 复制代码
---
kind: Deployment          
apiVersion: apps/v1       
metadata:                 
  name: deployabc          
spec:                     
  replicas: 3             
  selector:               
    matchLabels:          
      app: deploy-web     # deployment通过这个标签来确定哪个Pod由它来管理
  template:               # 定义用来创建 Pod 的模板,以下为 Pod 定义
    metadata:
      labels:
        app: deploy-web
    spec:
      containers:
      - name: apache
        image: myos:httpd       
        ports:       
        - name: http            # pod中,容器监听的端口名
          protocol: TCP         # pod中,容器监听的端口的协议
          containerPort: 80     # pod中,容器监听的端口号


        

那么服务请求就会到达pod中的容器。

其实步骤也可以概括为,

客户端---> ingress---> service---->depolyment

因为deployment的具体运作,前面的步骤是可以不用关心的。

deployment定义好其管理的pod的模版的详细情况,包括pod中的容器的信息。

根据这个pod的模版,deployment就可以实时的调整pod的数量

按照需求,来进行弹性管理。

来提供一个自动化管理的pod的集群。

相关推荐
叮咚侠1 分钟前
将已创建的Elasticsearch 8.12.0的docker容器中的数据挂载到宿主机操作步骤
运维·elasticsearch·docker·容器·kibana
wuxingge19 分钟前
docker设置代理,通过代理服务器拉取镜像
docker·容器
SZ17011023125 分钟前
K8s 部署所需的配置文件
云原生·容器·kubernetes
小池先生30 分钟前
docker 安装gitlab
docker·容器·gitlab
赫尔·普莱蒂科萨·帕塔31 分钟前
Kurator 分布式云原生环境技术深度分析与实践指南
分布式·云原生
永亮同学35 分钟前
【探索实战】从“工具堆叠”到“平台治理”:基于 Kurator 构建统一分布式云原生管理底座的实践与思考
分布式·云原生
rchmin38 分钟前
云原生概念与技术详解
云原生
A-刘晨阳1 小时前
【探索实战】基于Kubernetes部署Kurator
运维·云原生·容器·kubernetes·kurator
晨欣1 小时前
[eBPF硬核] Gemini阿吉学习笔记:Tetragon企业版两类核心日志 & 冷热数据分流架构设计 & 学习资源推荐
笔记·学习·云原生·云安全·ebpf·谷歌gemini
橙 子_1 小时前
在 Amazon Bedrock 中推出 Claude Sonnet 4.5:Anthropic 最智能的模型,最适合编码和复杂代理
人工智能·python·云原生·html