k8s部署nginx并使用nginx反代paas应用

最新推荐文章于 2025-11-03 10:25:28 发布

原创最新推荐文章于 2025-11-03 10:25:28 发布 · 2.1k 阅读

2 ·

CC 4.0 BY-SA版权

文章标签：

#kubernetes #nginx #paas

文章详细阐述了如何在Kubernetes(k8s)环境中通过Nginx实现反向代理，包括创建configmap以配置Nginx服务器，部署svc（service）并利用deployment进行滚动更新。重点涉及了configmap的使用以及Nginx反代配置文件的编写，同时提到了deployment的滚动升级策略及其注意事项。

通过部署在k8s里的nginx反代先前部署到paas的应用(主要涉及deployment/svc/configmap)

其中，反代是指反向代理（Reverse Proxy），是指以代理服务器来接受 internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给 internet 上请求连接的客户端，此时代理服务器对外就表现为一个反向代理服务器。简单来说就是真实的服务器不能直接被外部网络访问，所以需要一台代理服务器，而nginx就是这里的代理服务，主要是实现网络转发。

步骤一：编写configmap的yaml文件，并创建configmap资源

编写defualt.conf文件，用于监听nginx的server，文件如下:

server {
    listen 80;
    server_name localhost;
    location / {
        root /usr/share/nginx/html;
        index index.html index.xml;
    }
    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   html;
    }
}
server {
    listen       80;
    server_name hxy.te.com;
    location / {
        proxy_set_header  Host $host;
        proxy_pass http://10.101.17.40;
    }
    error_page 500  502 504 503  /50x.html;
    location = /50x.html {
        root   html;
    }
}

创建configmap资源

##创建一个名为nginx-config的configmap资源
kubectl create configmap nginx-config --from-file=./default.conf
##查看nginx-config资源
kubectl get configmap nginx-config -o yaml

configMap是K8s中用于数据持久化和共享的资源，其本质就是一个键/值对的映射(键名必须是合法的DNS字段，由数字、字母、破折号、下划线以及圆点构成，值可以是短字面量，也可以是完整的配置文件)。一般包含多个映射条目，其映射条目可以是短字面量，也可以是文件和文件夹。

使用时需要注意：

1.pod在创建时,若有一个容器使用的configmap不存在则该容器会创建失败，其余的容器成功创建，当使用的configmap创建之后，失败的容器则会自动启动可通过设置configMapKeyRef.optional：true字段避免该情况
2.若configmap中环境变量条目的键名不合法，则在创建环境变量时不会将其作为环境变量去创建，会自动忽略错误键名的条目

创建configmap：

kubectl create configmap nginx-html --from-file=./index.html

步骤二：部署svc

利用deployment资源类型去部署nodeport类型的service

deployment可以同时管理多个pod版本，是一种更高阶的资源，创建一个deployment时会创建一个ReplicaSet资源，并由创建的ReplicaSet去管理集群中的pod。因此模式为deployment管理ReplicaSet，ReplicaSet管理Pod。由于deployment直接管理rs，且每一次的应用版本都会对应一个rs，因此deployment对于应用版本的升级和回滚操作非常简单方便

deployment有两种升级策略，分别是rollingpdate和recreate。且deployment的升级是由master处理的，不再是kubectl客户端执行，由kubernetes的控制器管理升级会使升级更加可靠

1.rollingupdate是默认的升级策略，为滚动升级，即创建一个新的pod，删除一个旧的pod
2.recreate会一次性地删除所有旧的pod，然后一次性的创建所有新pod

但是使用deployment时需要注意：

若deployment中pod的模板引用了一个configMap资源，那么更改configmap资源不会触发升级操作，若想要修改应用程序的配置并触发更新的话，则应该创建一个新的configmap，并且修改pod模板引用新的configmap来触发滚动升级

yaml文件如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginxsvcdp
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 3
  minReadySeconds: 1 #指定最小的成功运行时间
  strategy:     #设置滚动升级的策略
      rollingUpdate:
          maxSurge: 1   #设置允许超过副本运行的pod数，默认是25%，即若dp中的副本数为4，那么dp中最多允许5个pod同时运行
          maxUnavailable: 0   #设置允许副本最多不可用的pod数，默认为25%，即若dp中的副本数为4，那么dp中最多有1个pod处于不可用的状态
      type: RollingUpdate    #设置滚动升级策略的类型
  template:   #指定创建pod的模板
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
        readinessProbe:  #设置就绪探针的时间,可以避免服务发布但是不能正常提供应用的情况
            exec:    ##指定使用exec类型的就绪探针
                command:
                -  curl
                -  http://localhost:80
        volumeMounts:
        -  mountPath: /etc/nginx/conf.d
           name: config
        -  mountPath: /usr/share/nginx/html
           name: data
      volumes:
        -  name: data
           configMap:
              name: nginx-html
              items:
              -  key: index.html
                 path: ./index.html
        -  name: config
           configMap:
              name: nginx-config
              items:
              -  key: default.conf
                 path: ./default.conf
 
---   #资源类型分隔符，用于在一个文件中定义多种类型的资源
apiVersion: v1
kind: Service
metadata:
    name: nginxdpsvc
spec:
    type: NodePort
    selector:
        app: nginx
    ports:
    -  port: 80
       targetPort: 80