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

本文涉及的产品
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
.cn 域名,1个 12个月
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
简介: 云原生|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搭建和管理企业级网站应用
目录
相关文章
|
5天前
|
Kubernetes Cloud Native Docker
云原生时代的容器化实践:Docker和Kubernetes入门
【10月更文挑战第37天】在数字化转型的浪潮中,云原生技术成为企业提升敏捷性和效率的关键。本篇文章将引导读者了解如何利用Docker进行容器化打包及部署,以及Kubernetes集群管理的基础操作,帮助初学者快速入门云原生的世界。通过实际案例分析,我们将深入探讨这些技术在现代IT架构中的应用与影响。
23 2
|
5天前
|
Kubernetes 监控 负载均衡
深入云原生:Kubernetes 集群部署与管理实践
【10月更文挑战第37天】在数字化转型的浪潮中,云原生技术以其弹性、可扩展性成为企业IT架构的首选。本文将引导你了解如何部署和管理一个Kubernetes集群,包括环境准备、安装步骤和日常维护技巧。我们将通过实际代码示例,探索云原生世界的秘密,并分享如何高效运用这一技术以适应快速变化的业务需求。
23 1
|
9天前
|
运维 Kubernetes Cloud Native
Kubernetes云原生架构深度解析与实践指南####
本文深入探讨了Kubernetes作为领先的云原生应用编排平台,其设计理念、核心组件及高级特性。通过剖析Kubernetes的工作原理,结合具体案例分析,为读者呈现如何在实际项目中高效部署、管理和扩展容器化应用的策略与技巧。文章还涵盖了服务发现、负载均衡、配置管理、自动化伸缩等关键议题,旨在帮助开发者和运维人员掌握利用Kubernetes构建健壮、可伸缩的云原生生态系统的能力。 ####
|
10天前
|
存储 运维 Kubernetes
云原生之旅:Kubernetes的弹性与可扩展性探索
【10月更文挑战第32天】在云计算的浪潮中,云原生技术以其独特的魅力成为开发者的新宠。本文将深入探讨Kubernetes如何通过其弹性和可扩展性,助力应用在复杂环境中稳健运行。我们将从基础架构出发,逐步揭示Kubernetes集群管理、服务发现、存储机制及自动扩缩容等核心功能,旨在为读者呈现一个全景式的云原生平台视图。
23 1
|
15天前
|
Kubernetes 负载均衡 Cloud Native
云原生应用:Kubernetes在容器编排中的实践与挑战
【10月更文挑战第27天】Kubernetes(简称K8s)是云原生应用的核心容器编排平台,提供自动化、扩展和管理容器化应用的能力。本文介绍Kubernetes的基本概念、安装配置、核心组件(如Pod和Deployment)、服务发现与负载均衡、网络配置及安全性挑战,帮助读者理解和实践Kubernetes在容器编排中的应用。
47 4
|
16天前
|
Kubernetes 监控 Cloud Native
云原生应用:Kubernetes在容器编排中的实践与挑战
【10月更文挑战第26天】随着云计算技术的发展,容器化成为现代应用部署的核心趋势。Kubernetes(K8s)作为容器编排领域的佼佼者,以其强大的可扩展性和自动化能力,为开发者提供了高效管理和部署容器化应用的平台。本文将详细介绍Kubernetes的基本概念、核心组件、实践过程及面临的挑战,帮助读者更好地理解和应用这一技术。
48 3
|
10天前
|
监控 Cloud Native 微服务
云端漫步:探索云原生应用的构建与部署
【10月更文挑战第32天】在数字时代的浪潮中,云原生技术如同一艘航船,承载着企业的梦想驶向未知的海洋。本文将带你领略云原生应用的魅力,从基础概念到实战操作,我们将一步步揭开云原生的神秘面纱,体验它如何简化开发、加速部署,并提升系统的可扩展性与可靠性。让我们一起启航,探索云原生的世界!
|
3天前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
|
5天前
|
运维 Kubernetes Cloud Native
云原生技术:容器化与微服务架构的完美结合
【10月更文挑战第37天】在数字化转型的浪潮中,云原生技术以其灵活性和高效性成为企业的新宠。本文将深入探讨云原生的核心概念,包括容器化技术和微服务架构,以及它们如何共同推动现代应用的发展。我们将通过实际代码示例,展示如何在Kubernetes集群上部署一个简单的微服务,揭示云原生技术的强大能力和未来潜力。
|
6天前
|
消息中间件 存储 Cloud Native
云原生架构下的数据一致性挑战与应对策略####
本文探讨了在云原生环境中,面对微服务架构的广泛应用,数据一致性问题成为系统设计的核心挑战之一。通过分析云原生环境的特点,阐述了数据不一致性的常见场景及其对业务的影响,并深入讨论了解决这些问题的策略,包括采用分布式事务、事件驱动架构、补偿机制以及利用云平台提供的托管服务等。文章旨在为开发者提供一套系统性的解决方案框架,以应对在动态、分布式的云原生应用中保持数据一致性的复杂性。 ####