云原生|kubernetes|ingress-nginx插件部署以及简单的应用(修订版)(二)

简介: 云原生|kubernetes|ingress-nginx插件部署以及简单的应用(修订版)

二,编写ingress资源清单文件


vim ingress-http.yaml

(两个自定义域名nginx.test.com和tomcat.test.com 绑定到了nginx-service和tomcat-service 这两服务上了)

这里要注意了,为什么两个servicePort都是80了,因为上面的ingress-nginx-controller是80端口嘛,由于我的kubernetes版本是1.18,因此还是使用注解方式。

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress-http
  namespace: dev
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: nginx.test.com
    http:
      paths:
      - path: /
        backend:
          serviceName: nginx-service
          servicePort: 80
  - host: tomcat.test.com
    http:
      paths:
      - path: /
        backend:
          serviceName: tomcat-service
          servicePort: 80

此文件执行过后,ingress的情况如下:

可以看到此ingress是绑定到了192.168.217.18也就是node2节点了,绑定了两个域名,ADDRESS是node2节点的IP。

[root@master ~]# k get ing -A
NAMESPACE   NAME           CLASS    HOSTS                            ADDRESS          PORTS   AGE
dev         ingress-http   <none>   nginx.test.com,tomcat.test.com   192.168.217.18   80      3h23m

建立namespace:

[root@master ~]# cat tomcat-nginx-ns.yaml 
apiVersion: v1
kind: Namespace
metadata:
  name: dev
---

vim tomcat-nginx.yaml

建立两个deployment的pod,可提供web功能的,一个nginx 一个tomcat,两个都做了node选择,和ingress-nginx-controller处于同一个节点。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  namespace: dev
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx-pod
  template:
    metadata:
      labels:
        app: nginx-pod
    spec:
      containers:
      - name: nginx
        image: nginx:1.17.1
        ports:
        - containerPort: 80
      nodeName: k8s-node2
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: tomcat-deployment
  namespace: dev
spec:
  replicas: 1
  selector:
    matchLabels:
      app: tomcat-pod
  template:
    metadata:
      labels:
        app: tomcat-pod
    spec:
      containers:
      - name: tomcat
        image: tomcat:8.5-jre10-slim
        ports:
        - containerPort: 8080
      nodeName: k8s-node2

vim tomcat-nginx-svc.yaml

这里又需要注意了,两个service一个无头service,一个普通的clusterip,一会使用了ingress清单文件就可以将这两个服务发布到集群外了。

---
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
  namespace: dev
spec:
  ports:
    - port: 80
      name: nginx
  clusterIP: None
  selector:
    app: nginx-pod
---
apiVersion: v1
kind: Service
metadata:
  name: tomcat-service
  namespace: dev
spec:
  selector:
    app: tomcat-pod
  type: ClusterIP
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

三,OK,以上文件都apply后,就可以看结果了


宿主机做hosts域名解析:

image.png

27def25cf48943dbae54634f42aead24.png

610359eacbaa49d9b8566d728ae2f317.png

OK,如果nginx部署到node1节点会怎么样呢?

报错504

68b267a01c284102851bc689ece05527.png

这就说明一个问题,kubectl get ingress -A 查询出来的那个IP地址也就是ingress的节点和要发布的service对应的pod要在同一个节点下,和service的类型没有关系,即使service是无头的也是OK的,ingress-nginx-controller会帮我们自己处理好的。并且多个service都是通过同一个端口发不出来的,只是域名不同而已。

四,改造成https也就是使用ssl的域名(实验性质,当然还是使用自签的证书,实际生产环境肯定是使用备案过的证书哦)


a,生成自签证书


openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/CN=tomcat.test.com/ST=BeiJing/L=BeiJing/O=devops/OU=unicorn"

可以看到,生成了这么两个玩意

1. [root@master ~]# ls tls*
2. tls.crt  tls.key

b,生成secret,证书存放到secret里


注意,这里要指定namespace,要不ingress controller找不到证书

kubectl create secret tls tls-secret --key=tls.key --cert tls.crt -n dev

c,编写ingress文件


vim ingress-https.yaml

主要就是添加了tls相关,域名还是不变的以及一个注解,并且引用了前面打入的证书

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: test-ingress3
  namespace: dev
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    kubernetes.io/ingress.class: nginx
#    nginx.ingress.kubernetes.io/backend-protocol: HTTPS
    nginx.ingress.kubernetes.io/ssl-redirect: 'true'
#    #    nginx.ingress.kubernetes.io/use-regex: 'true'
spec:
  tls:
    - hosts:
      - tomcat.test.com
      secretName: tls-secret
  rules:
  - host: tomcat.test.com
    http:
      paths:
      - path: /
        backend:
          serviceName: tomcat-service
          servicePort: 80

查看ingress,可以看到多了一个443,还是绑定的node2节点(ingress 控制器前面部署的时候搞错了,就部署在了一个节点,daemonset没有使用的。)

[root@master ~]# k get ing -A
NAMESPACE   NAME            CLASS    HOSTS                            ADDRESS          PORTS     AGE
dev         ingress-http    <none>   nginx.test.com,tomcat.test.com   192.168.217.18   80        11h
dev         test-ingress3   <none>   tomcat.test.com                  192.168.217.18   80, 443   4m16s

d,验证;


需要先查询一哈ingress的service提供的端口,查询出端口是31675

[root@master ~]# vim ingress-https.yaml
[root@master ~]# k get svc -A
NAMESPACE       NAME                                 TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)                      AGE
default         kubernetes                           ClusterIP   10.0.0.1     <none>        443/TCP                      37d
dev             nginx-service                        ClusterIP   None         <none>        80/TCP                       16h
dev             tomcat-service                       ClusterIP   10.0.92.37   <none>        80/TCP                       16h
ingress-nginx   ingress-nginx-controller             NodePort    10.0.0.102   <none>        80:31702/TCP,443:31675/TCP   4d14h
ingress-nginx   ingress-nginx-controller-admission   ClusterIP   10.0.0.12    <none>        443/TCP                      4d14h
kube-system     coredns                              ClusterIP   10.0.0.2     <none>        53/UDP,53/TCP                36d

1047bfe4eb68456eba81c2608cd01d6c.png

image.png

OK,https证书启用成功,此网站的证书只是没有注册的自产证书,但功能是完好的。

总结:


那么现在这个ingress controller插件是可以使用的,ingress统一了要发布服务的端口,可以看到即使多个门户,也可以简单的以域名来区分,端口是统一的31702(http)或者31675(https),从而达到了服务治理的目的(其它功能,比如黑白名单,重定向,二级域名跳转等等留待以后研究哈):

[root@master ~]# k get ing -A
NAMESPACE   NAME            CLASS    HOSTS                            ADDRESS          PORTS     AGE
dev         ingress-http    <none>   nginx.test.com,tomcat.test.com   192.168.217.18   80        11h
dev         test-ingress3   <none>   tomcat.test.com                  192.168.217.18   80, 443   4m16s

ingress-nginx-controller截取的部分日志:

192.168.217.18 - - [03/Oct/2022:09:03:03 +0000] "GET /favicon.ico HTTP/1.1" 404 555 "http://nginx.test.com:31702/" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.71 Safari/537.36 Core/1.94.175.400 QQBrowser/11.1.5155.400" 423 0.001 [dev-nginx-service-80] [] 10.244.36.97:80 555 0.001 404 3b851fa39d2268e5fbd230fc5f8d1d59
192.168.217.18 - - [03/Oct/2022:09:03:05 +0000] "GET / HTTP/1.1" 304 0 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.71 Safari/537.36 Core/1.94.175.400 QQBrowser/11.1.5155.400" 581 0.001 [dev-nginx-service-80] [] 10.244.36.97:80 0 0.001 304 21366d34e3103a50236738d6b1dd00e7
192.168.217.18 - - [03/Oct/2022:09:03:07 +0000] "GET / HTTP/1.1" 304 0 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.71 Safari/537.36 Core/1.94.175.400 QQBrowser/11.1.5155.400" 581 0.002 [dev-nginx-service-80] [] 10.244.36.97:80 0 0.002 304 69bcb2182681ea3be696fe3b449e286c
192.168.217.18 - - [03/Oct/2022:09:03:09 +0000] "GET / HTTP/1.1" 304 0 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.71 Safari/537.36 Core/1.94.175.400 QQBrowser/11.1.5155.400" 581 0.001 [dev-nginx-service-80] [] 10.244.36.97:80 0 0.000 304 3622a7bf35abbdf08c43084c89fd0110
192.168.217.18 - - [03/Oct/2022:09:06:15 +0000] "GET / HTTP/1.1" 200 612 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.71 Safari/537.36 Core/1.94.175.400 QQBrowser/11.1.5155.400" 500 0.003 [dev-nginx-service-80] [] 10.244.36.97:80 612 0.003 200 5f6ba8d7070c9b7984acf2012fa57a5b
192.168.217.18 - - [03/Oct/2022:09:06:17 +0000] "GET / HTTP/1.1" 304 0 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.71 Safari/537.36 Core/1.94.175.400 QQBrowser/11.1.5155.400" 581 0.002 [dev-nginx-service-80] [] 10.244.36.97:80 0 0.001 304 12d114732628f18df5988661bf79fc83
192.168.217.18 - - [03/Oct/2022:09:16:42 +0000] "GET / HTTP/1.1" 200 612 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36" 460 0.001 [dev-nginx-service-80] [] 10.244.36.97:80 612 0.001 200 298738d5c747741af42d8f13fb4c4566

可以看到我是使用的QQ浏览器(也用了谷歌105版本),192.168.217.18:31702 代理了10.244.36.97:80

NAMESPACE       NAME                                       READY   STATUS      RESTARTS   AGE     IP                NODE         NOMINATED NODE   READINESS GATES
dev             nginx-deployment-b785b4498-5r8jn           1/1     Running     0          16m     10.244.36.97      k8s-node1    <none>           <none>
相关实践学习
深入解析Docker容器化技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。Docker是世界领先的软件容器平台。开发人员利用Docker可以消除协作编码时“在我的机器上可正常工作”的问题。运维人员利用Docker可以在隔离容器中并行运行和管理应用,获得更好的计算密度。企业利用Docker可以构建敏捷的软件交付管道,以更快的速度、更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能。 在本套课程中,我们将全面的讲解Docker技术栈,从环境安装到容器、镜像操作以及生产环境如何部署开发的微服务应用。本课程由黑马程序员提供。 &nbsp; &nbsp; 相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
目录
相关文章
|
10月前
|
应用服务中间件 网络安全 nginx
手把手教你使用 Docker 部署 Nginx 教程
本文详解Nginx核心功能与Docker部署优势,涵盖镜像拉取、容器化部署(快速、挂载、Compose)、HTTPS配置及常见问题处理,助力高效搭建稳定Web服务。
4289 4
|
应用服务中间件 PHP nginx
今日小结通过aliyun的本地容器镜像部署我的nginx和php环境
简介: 本教程介绍如何基于 Dragonwell 的 Ubuntu 镜像创建一个运行 Nginx 的 Docker 容器。首先从阿里云容器镜像服务拉取基础镜像,然后编写 Dockerfile 确保 Nginx 作为主进程运行,并暴露 80 端口。最后,在包含 Dockerfile 的目录下构建自定义镜像并启动容器,确保 Nginx 在前台运行,避免容器启动后立即退出。通过 `docker build` 和 `docker run` 命令完成整个流程。
681 25
今日小结通过aliyun的本地容器镜像部署我的nginx和php环境
|
10月前
|
应用服务中间件 Linux nginx
在虚拟机Docker环境下部署Nginx的步骤。
以上就是在Docker环境下部署Nginx的步骤。需要注意,Docker和Nginix都有很多高级用法和细节需要掌握,以上只是一个基础入门级别的教程。如果你想要更深入地学习和使用它们,请参考官方文档或者其他专业书籍。
485 5
|
运维 Dubbo Cloud Native
Dubbo 云原生重构出击:更快部署、更强控制台、更智能运维
Apache Dubbo 最新升级支持云原生,提供一键部署微服务集群与全新可视化控制台,提升全生命周期管理体验,助力企业高效构建云原生应用。
1582 25
|
应用服务中间件 Linux 网络安全
技术指南:如何把docsify项目部署到基于CentOS系统的Nginx中。
总结 与其他部署方法相比,将docsify项目部署到基于CentOS系统的Nginx中比较简单。以上步骤应当帮助你在不花费太多时间的情况下,将你的项目顺利部署到Nginx中。迈出第一步,开始部署你的docsify项目吧!
530 14
|
存储 缓存 应用服务中间件
Nginx 响应头 Vary 的介绍与应用
`Vary` 头部字段在Web开发中扮演着重要角色,通过合理使用 `Vary`,可以优化缓存策略,提升Web应用的性能和响应速度。本文介绍了 `Vary` 头部字段的基本概念、作用、常见使用场景及其在Nginx中的配置方法。通过这些内容,希望读者能够更好地理解和应用 `Vary` 头部字段,提高Web应用的缓存效率和用户体验。
652 10
|
Cloud Native 安全 Serverless
云原生应用实战:基于阿里云Serverless的API服务开发与部署
随着云计算的发展,Serverless架构日益流行。阿里云函数计算(Function Compute)作为Serverless服务,让开发者无需管理服务器即可运行代码,按需付费,简化开发运维流程。本文从零开始,介绍如何使用阿里云函数计算开发简单的API服务,并探讨其核心优势与最佳实践。通过Python示例,演示创建、部署及优化API的过程,涵盖环境准备、代码实现、性能优化和安全管理等内容,帮助读者快速上手Serverless开发。
|
人工智能 缓存 异构计算
云原生AI加速生成式人工智能应用的部署构建
本文探讨了云原生技术背景下,尤其是Kubernetes和容器技术的发展,对模型推理服务带来的挑战与优化策略。文中详细介绍了Knative的弹性扩展机制,包括HPA和CronHPA,以及针对传统弹性扩展“滞后”问题提出的AHPA(高级弹性预测)。此外,文章重点介绍了Fluid项目,它通过分布式缓存优化了模型加载的I/O操作,显著缩短了推理服务的冷启动时间,特别是在处理大规模并发请求时表现出色。通过实际案例,展示了Fluid在vLLM和Qwen模型推理中的应用效果,证明了其在提高模型推理效率和响应速度方面的优势。
云原生AI加速生成式人工智能应用的部署构建
|
Kubernetes Cloud Native 微服务
云原生入门与实践:Kubernetes的简易部署
云原生技术正改变着现代应用的开发和部署方式。本文将引导你了解云原生的基础概念,并重点介绍如何使用Kubernetes进行容器编排。我们将通过一个简易的示例来展示如何快速启动一个Kubernetes集群,并在其上运行一个简单的应用。无论你是云原生新手还是希望扩展现有知识,本文都将为你提供实用的信息和启发性的见解。
|
敏捷开发 Kubernetes Cloud Native
阿里云云原生技术为企业提供了一套高效、灵活的解决方案,支持跨云部署与管理
在多云环境中,阿里云云原生技术为企业提供了一套高效、灵活的解决方案,支持跨云部署与管理。通过容器化、服务网格等技术,实现了应用的一致性与可移植性,简化了多云环境下的资源管理和服务治理,帮助企业应对复杂的云环境挑战,加速数字化转型。
465 5