APISIX Ingress 如何使用 Cert Manager 管理证书
Apache APISIX Ingress Controller 是一款以 Apache APISIX 作为数据面的 Kubernetes Ingress Controller 开源工具,目前已经更新到 v1.3 版本,实现了如证书管理、负载均衡、金丝雀发布等功能。
长久以来,证书管理都不是一件简单的事情,虽然 Apache APISIX Ingress Controller 支持从 Kubernetes Secrets 资源中提取证书和私钥,并转换为 Apache APISIX 可识别的 SSL 对象,但这只是整个证书管理链中的一部分,证书的颁发、轮转、吊销逻辑依然需要管理员执行,尤其当证书数量比较多时,工作量往往并不小,因而会占用管理员不少的时间。
Cert Manager 是一款致力于在 Kubernetes 平台上简化证书管理的软件,它支持对接许多不同的证书源,如 Let's Encrypt 和 HashiCorp Vault。
如果你在使用 Apache APISIX Ingress Controller 时,遇到了证书管理的麻烦,那么使用 Cert Manager 将会是一个不错的选择,本文将介绍如何通过 Cert Manager 来创建证书并对接到 Apache APISIX Ingress Controller。
步骤一:环境准备
如果你希望按照本文的指导进行实际的操作,请确保以下环境和工具已准备就绪:
请注意,下文所有的操作都将在 ingress-apisix 命名空间中执行,因此需要先创建该命名空间:
kubectl create namespace ingress-apisix
步骤二:安装 Apache APISIX Ingress Controller
我们可以通过 Helm 来安装 Apache APISIX Ingress Controller,包括数据面的 Apache APISIX 和 etcd 集群。
helm repo add apisix https://charts.apiseven.com helm repo update helm install apisix apisix/apisix --set gateway.tls.enabled=true --set ingress-controller.enabled=true --namespace ingress-apisix
点击查看详细安装介绍。
步骤三:安装 Cert Manager
通过 Helm 来安装 Cert Manager,点击可查看详细安装介绍。
helm install cert-manager jetstack/cert-manager --namespace ingress-apisix --set prometheus.enabled=false --set installCRDs=true
安装完毕后请等待一会后查看组件的运行状态,确保所有组件都已正常运行,你可以通过如下命令进行查看。
kubectl get all -n ingress-apisix
返回结果如下所示,表示所有组件都已正常运行。
NAME READY STATUS RESTARTS AGE pod/apisix-5d99956d88-j68sj 1/1 Running 0 63s pod/apisix-69459554d4-btnwn 0/1 Terminating 0 57m pod/apisix-etcd-0 1/1 Running 0 57m pod/apisix-etcd-1 1/1 Running 0 57m pod/apisix-etcd-2 0/1 Running 0 50s pod/apisix-ingress-controller-7b5c767cc7-j62hb 1/1 Running 0 55m pod/cert-manager-5ffd4f6c89-q9f7m 1/1 Running 0 45m pod/cert-manager-cainjector-748dc889c5-nrvkh 1/1 Running 0 45m pod/cert-manager-startupapicheck-kmgxf 0/1 Completed 0 45m pod/cert-manager-webhook-bc964d98b-mkjj7 1/1 Running 0 45m NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/apisix-admin ClusterIP 10.96.16.25 <none> 9180/TCP 57m service/apisix-etcd ClusterIP 10.96.232.251 <none> 2379/TCP,2380/TCP 57m service/apisix-etcd-headless ClusterIP None <none> 2379/TCP,2380/TCP 57m service/apisix-gateway NodePort 10.96.118.75 <none> 80:32039/TCP,443:30107/TCP 57m service/apisix-ingress-controller ClusterIP 10.96.13.76 <none> 80/TCP 57m service/cert-manager-webhook ClusterIP 10.96.182.188 <none> 443/TCP 45m NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/apisix 1/1 1 1 57m deployment.apps/apisix-ingress-controller 1/1 1 1 57m deployment.apps/cert-manager 1/1 1 1 45m deployment.apps/cert-manager-cainjector 1/1 1 1 45m deployment.apps/cert-manager-webhook 1/1 1 1 45m NAME DESIRED CURRENT READY AGE replicaset.apps/apisix-5d99956d88 1 1 1 63s replicaset.apps/apisix-69459554d4 0 0 0 57m replicaset.apps/apisix-ingress-controller-74c6b5fbdd 0 0 0 57m replicaset.apps/apisix-ingress-controller-7b5c767cc7 1 1 1 55m replicaset.apps/apisix-ingress-controller-7d58db957c 0 0 0 55m replicaset.apps/cert-manager-5ffd4f6c89 1 1 1 45m replicaset.apps/cert-manager-cainjector-748dc889c5 1 1 1 45m replicaset.apps/cert-manager-webhook-bc964d98b 1 1 1 45m NAME READY AGE statefulset.apps/apisix-etcd 2/3 57m NAME COMPLETIONS DURATION AGE job.batch/cert-manager-startupapicheck 1/1 6m24s 45m
Kubernetes Controller Manager 的机制决定了 Pod 名称会有所不同。
步骤四:申请证书并测试
首先我们需要配置证书颁发对象。
# issuer.yaml apiVersion: cert-manager.io/v1 kind: Issuer metadata: name: issuer namespace: ingress-apisix spec: selfSigned: {}
并创建自签名证书颁发者。
kubectl apply -f issuer.yaml
请注意,自签名颁发对象不推荐使用在生产环境中!更多证书颁发对象的配置请参考这里。 然后为域名
httpbin.org
创建一张证书。
# httpbin-cert.yaml apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: httpbin namespace: ingress-apisix spec: secretName: httpbin duration: 2160h # 90d renewBefore: 360h # 15d subject: organizations: - foo commonName: httpbin.org isCA: false privateKey: algorithm: RSA encoding: PKCS1 size: 2048 usages: - server auth dnsNames: - "httpbin.org" - "*.httpbin.org" issuerRef: name: issuer kind: Issuer group: cert-manager.io kubectl apply -f httpbin-cert.yaml
此时需要查看对应 Secrets 是否已经被创建。
kubectl get secrets -n ingress-apisix httpbin NAME TYPE DATA AGE httpbin kubernetes.io/tls 3 2m5s
通过上述验证,该 Secrets 对象的创建事件已经被 Apache APISIX Ingress Controller 捕获到,我们尝试访问 Apache APISIX Ingress Controller 来验证证书是否生效,首先我们需要创建额外的路由对象。
# 创建后端 kubectl run httpbin --image kennethreitz/httpbin --namespace ingress-apisix kubectl expose pod httpbin -n ingress-apisix --port 80 # 定义 ApisixTls 对象 apiVersion: apisix.apache.org/v1 kind: ApisixTls metadata: name: httpbin namespace: ingress-apisix spec: hosts: - httpbin.org secret: name: httpbin namespace: ingress-apisix --- # 定义访问后端的路由 apiVersion: apisix.apache.org/v2beta1 kind: ApisixRoute metadata: name: httpbin namespace: ingress-apisix spec: http: - name: httpbin match: paths: - /* hosts: - httpbin.org backends: - serviceName: httpbin servicePort: 80
接下来访问服务 apisix-gateway
。注意,默认情况下该服务的类型为 NodePort
,你可以根据需要修改其类型,比如你的 Kubernetes 集群是云厂商托管的,则可以考虑将其修改为 LoadBalancer
类型,以获取一个外部可达的 IP。
这里我们通过端口转发的方式将服务映射到本地。
kubectl port-forward -n ingress-apisix svc/apisix-gateway 8443:443
然后开始配置访问。
curl https://httpbin.org:8443/json --resolve 'httpbin.org:8443:127.0.0.1' -sk { "slideshow": { "author": "Yours Truly", "date": "date of publication", "slides": [ { "title": "Wake up to WonderWidgets!", "type": "all" }, { "items": [ "Why <em>WonderWidgets</em> are great", "Who <em>buys</em> WonderWidgets" ], "title": "Overview", "type": "all" } ], "title": "Sample Slide Show" } }
经过上述操作,可以看到访问成功,说明证书已经生效。注意,由于证书是自签名的,这里需要加上 -k
选项来忽略证书的校验。
此外,如果你想要轮转证书,删除 httpbin
这一 Secret 对象即可,Cert Manager 会立刻创建一个新的 httpbin Secret 对象,并且包含新的证书。
总结
本文主要讲解了如何利用 Cert Manager 在 Apache APISIX Ingress Controller 中进行证书的创建和管理。想了解更多关于 Apache APISIX Ingress 的介绍与内容,可参考本篇文章 或者参与 Apache APISIX Ingress 项目每两周举行的线上讨论,分享当下项目进度、最佳实践及设计思路等多个话题,可查看具体 issue 了解更多。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
谈谈我工作中的23个设计模式
作者:闵大为(天未) 序 从基础的角度看,设计模式是研究类本身或者类与类之间的协作模式,是进行抽象归纳的一个很好的速成思路。后面阅读设计模式后,为了加深理解,对相关图片进行了描绘和微调。 从技术的角度已经有很多好的总结,本文会换一种角度思考,既然设计模式研究的是类与类的关系,我们作为工作的个体,一些工作中的策略是不是也可以进行类比,可以更好地去思考这些模式?答案是肯定的。 创建型模式 5 抽象工厂(Abstract Factory):多套方案 抽象工厂模式是对创建不同的产品类型的抽象。对应到工作中,我们的确应该具备提供多套方案的能力,这也是我们常说的,要提供选择题。当你有这样的前瞻意识,一般也会被打上思考较多的标签,但是内在来说,的确想问题更加全面了。 生成器(Builder):善于分解 生成器模式是对一个个体的创建过程进行细分,拆解为不同的创建部分。这个对应到工作中,作为一些项目管理人员或者团队管理者,需要将一个大泥球一样的事务,合理分解,让大家各司其职,充分发挥才能。同样,我们对日常的工作内容,也可以按照结构去进行划分,从而更有条理。 工厂方法(Factory Method):抽...
- 下一篇
百度官宣类 ChatGPT 大模型新项目:文心一言
在谷歌宣布推出与 ChatGPT 竞争的 AI 产品 Bard后,百度微信公众号今日也官宣介绍了该公司的大模型新项目 —— 文心一言(英文名 ERNIE Bot)。公告注释称: ①.百度在人工智能四层架构中,有全栈布局。包括底层的芯片、深度学习框架、大模型以及最上层的搜索等应用。文心一言,位于模型层。②.百度在人工智能领域深耕数十年,拥有产业级知识增强文心大模型 ERNIE ,具备跨模态、跨语言的深度语义理解与生成能力。 值得寻味的是,这不过百字的公告内容却有着四位责任编辑,且还都采用了统一的 ABB 命名格式:希加加、度晓晓、叶悠悠、林开开。对此网友纷纷猜测这些其实是数字人,更有甚者还提出这篇文章说不定就是采用文心一言写的。 据百度公司向澎湃科技确认称,文心一言计划于今年 3 月完成内测,面向公众开放。目前,文心一言在做上线前的冲刺。而按照谷歌和微软加快推出类 ChatGPT 服务的节奏,文心一言开放内测还有可能提前。“ChatGPT 是人工智能里程碑,更是分水岭,这意味着 AI 技术发展到临界点,企业需要尽早布局。”
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- Red5直播服务器,属于Java语言的直播服务器
- CentOS7设置SWAP分区,小内存服务器的救世主
- CentOS7安装Docker,走上虚拟化容器引擎之路
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- CentOS关闭SELinux安全模块
- CentOS7,CentOS8安装Elasticsearch6.8.6
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- Linux系统CentOS6、CentOS7手动修改IP地址
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16