云原生|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>
相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
相关文章
|
6天前
|
存储 Kubernetes 对象存储
部署DeepSeek但GPU不足,ACK One注册集群助力解决IDC GPU资源不足
借助阿里云ACK One注册集群,充分利用阿里云强大ACS GPU算力,实现DeepSeek推理模型高效部署。
|
8天前
|
Cloud Native Serverless 数据中心
阿里云ACK One:注册集群支持ACS算力——云原生时代的计算新引擎
ACK One注册集群已正式支持ACS(容器计算服务)算力,为企业的容器化工作负载提供更多选择和更强大的计算能力。
|
11天前
|
存储 Kubernetes 测试技术
企业级LLM推理部署新范式:基于ACK的DeepSeek蒸馏模型生产环境落地指南
本教程演示如何在ACK中使用vLLM框架快速部署DeepSeek R1模型推理服务。
|
12天前
|
存储 人工智能 弹性计算
NVIDIA NIM on ACK:优化生成式AI模型的部署与管理
本文结合NVIDIA NIM和阿里云容器服务,提出了基于ACK的完整服务化管理方案,用于优化生成式AI模型的部署和管理。
|
1天前
|
Kubernetes 持续交付 数据库
阿里云ACK+GitLab企业级部署实战教程
GitLab 是一个功能强大的基于 Web 的 DevOps 生命周期平台,整合了源代码管理、持续集成/持续部署(CI/CD)、项目管理等多种工具。其一体化设计使得开发团队能够在同一平台上进行代码协作、自动化构建与部署及全面的项目监控,极大提升了开发效率和项目透明度。 GitLab 的优势在于其作为一体化平台减少了工具切换,高度可定制以满足不同项目需求,并拥有活跃的开源社区和企业级功能,如高级权限管理和专业的技术支持。借助这些优势,GitLab 成为许多开发团队首选的 DevOps 工具,实现从代码编写到生产部署的全流程自动化和优化。
|
6天前
|
人工智能 Kubernetes 异构计算
大道至简-基于ACK的Deepseek满血版分布式推理部署实战
本教程演示如何在ACK中多机分布式部署DeepSeek R1满血版。
|
2月前
|
运维 Cloud Native 持续交付
深入理解云原生架构及其在现代企业中的应用
随着数字化转型的浪潮席卷全球,企业正面临着前所未有的挑战与机遇。云计算技术的迅猛发展,特别是云原生架构的兴起,正在重塑企业的IT基础设施和软件开发模式。本文将深入探讨云原生的核心概念、关键技术以及如何在企业中实施云原生策略,以实现更高效的资源利用和更快的市场响应速度。通过分析云原生架构的优势和面临的挑战,我们将揭示它如何助力企业在激烈的市场竞争中保持领先地位。
|
2月前
|
Kubernetes Cloud Native 微服务
探索云原生技术:容器化与微服务架构的融合之旅
本文将带领读者深入了解云原生技术的核心概念,特别是容器化和微服务架构如何相辅相成,共同构建现代软件系统。我们将通过实际代码示例,探讨如何在云平台上部署和管理微服务,以及如何使用容器编排工具来自动化这一过程。文章旨在为开发者和技术决策者提供实用的指导,帮助他们在云原生时代中更好地设计、部署和维护应用。
|
3月前
|
Cloud Native Devops 云计算
云计算的未来:云原生架构与微服务的革命####
【10月更文挑战第21天】 随着企业数字化转型的加速,云原生技术正迅速成为IT行业的新宠。本文深入探讨了云原生架构的核心理念、关键技术如容器化和微服务的优势,以及如何通过这些技术实现高效、灵活且可扩展的现代应用开发。我们将揭示云原生如何重塑软件开发流程,提升业务敏捷性,并探索其对企业IT架构的深远影响。 ####
83 3
|
3月前
|
Cloud Native 持续交付 云计算
云原生架构的演进与挑战
随着云计算技术的不断发展,云原生架构已成为企业数字化转型的重要支撑。本文深入探讨了云原生架构的概念、发展历程、核心技术以及面临的挑战,旨在为读者提供一个全面了解云原生架构的视角。通过分析Kubernetes、Docker等关键技术的应用,以及微服务、持续集成/持续部署(CI/CD)等实践案例,本文揭示了云原生架构在提高应用开发效率、降低运维成本、增强系统可扩展性等方面的显著优势。同时,也指出了云原生架构在安全性、复杂性管理等方面所面临的挑战,并提出了相应的解决策略。