在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的集群。

相关推荐
吴声子夜歌15 分钟前
Kubernetes权威指南——深入掌握Pod(使用StatefulSet搭建MongoDB集群)
容器·kubernetes
fb_1234523 分钟前
K8s动态卷供应实战_StorageClass与LocalPath_NFS双Provisioner
云原生·容器·kubernetes
大囚长31 分钟前
Kubernetes 的资源开销、适用边界,以及游戏与有状态负载的工程现实
游戏·容器·kubernetes
RuoyiOffice1 小时前
Hyper-V+Kubernetes 搭建实战:保留 Windows,构建三节点 Linux 容器集群
linux·spring boot·kubernetes·containerd·hyper-v·微服务部署·ruoyi office
fb_123451 小时前
K8s StatefulSet五大有状态集群实战_Nginx_Etcd_Redis_Cassandra_MySQL
nginx·kubernetes·etcd
时间售卖铺1 小时前
Docker私有仓库搭建与实战指南
运维·docker·云原生·容器
分布式存储与RustFS2 小时前
Kafka 分层存储落地指南:冷 Segment 自动落到 RustFS 对象存储
运维·云原生·开源·对象存储·分布式存储·s3·性能基准
Z21-X2 小时前
云原生运维实战笔记:华为云计算与网络类服务全景解析
运维·笔记·学习·云原生·华为云
mengge.cloud3 小时前
10-29-Kubernetes动态卷供应StatefulSet与ETCD
容器·kubernetes·etcd
小哈里3 小时前
【推理】NVIDIA DLI培训:大规模部署与优化 AI 推理(推理原理,K8S,网关层,pd分离,MoE,Dynamo)
人工智能·容器·kubernetes·nvidia·推理