引言
上一节遗留了一个问题，那就是Ingress未绑定到具体的IPAddress，导致无法外部访问。那如何处理呢？这一节就来解决该问题，并了解如何使用Cert-Manager自动颁发证书。
配置Nginx Ingress Controler
遇到问题的时候，首先要尝试找到问题的原因。由于GitLab 相关的站点都能正常工作，因此可以使用对比的方法来找到原因。依次打开gitlab命名空间下的gitlab-minio和我们自己aspnetcore-cicd-demo-4-development命名空间下的demos-aspnetcore-cicd-demo-ingress，然后使用对比工具进行对比，差异如下图所示：
从对比图可以看出，主要的差异在于annotations和spec:tls两个节点。其中cert-manager.io/issuer: gitlab-issuer是配置用来申请证书的，稍后。那和ingress相关的就剩下以下两个注解：
-
kubernetes.io/ingress.class: gitlab-nginx，该注解用来指定通过哪个Ingress Controller来实现当前Ingress。 -
kubernetes.io/ingress.provider: nginx，该注解用来指定当前Kubernetes Ingress Controller的提供者是Nginx。
下面尝试直接将以上两个注解添加到demos-aspnetcore-cicd-demo-ingress中，但并未生效，原因是gitlab-nginx限定了作用的命名空间。使用 Lens 编辑gitlab-nginxingress-controller Deployment，在spec:template:spce:containers:args节点，可以看到以下配置：
# gitlab-nginxingress-controller.yaml
spec:
template:
spec:
containers:
- args:
- /nginx-ingress-controller
- >-
--default-backend-service=$(POD_NAMESPACE)/gitlab-nginx-ingress-default-backend
- '--publish-service=$(POD_NAMESPACE)/gitlab-nginx-ingress-controller'
- '--election-id=ingress-controller-leader'
- '--ingress-class=gitlab-nginx'
- '--configmap=$(POD_NAMESPACE)/gitlab-nginx-ingress-controller'
- '--tcp-services-configmap=gitlab/gitlab-nginx-ingress-tcp'
- '--watch-namespace=$(POD_NAMESPACE)'
从参数中可以看出注解kubernetes.io/ingress.class: gitlab-nginx引用的就是上面参数：--ingress-class=gitlab-nginx中定义的。其中最后一行是问题的关键，也就是--watch-namespace=$(POD_NAMESPACE)限定了当前nginx-ingress-controller仅作用于gitlab命名空间。因此解决问题的关键就在于，放开命名空间的限制。而办法就是移除这一行。删除该行，保存。发现Pod无法成功创建，从Pod的运行日志中可以看到以下报错信息：services is forbidden: User "system:serviceaccount:gitlab:gitlab-nginx-ingress" cannot list resource "services" in API group at the cluster scope。简单理解就是gitlab命名空间的名为gitlab-nginx-ingress的ServiceAccount 没有集群权限。没有集群权限，那就分配集群权限就好，最简单的办法就是绑定集群cluster-admin角色。通过创建名为gitlab-nginx-cluster-admin的Cluster Role Bindings，建立gitlab-nginx-ingress和cluster-admin的绑定关系即可。具体操作如下图所示：
创建完成后，发现gitlab-nginx-ingress已成功更新。稍等片刻，再通过以下命令，得知已完成IpAddress的绑定：
PS C:\Users\shengjie> kubectl get ingress -n aspnetcore-cicd-demo-4-development
NAME CLASS HOSTS ADDRESS PORTS AGE
demos-aspnetcore-cicd-demo-ingress <none> demo.shengjie.dev 20.205.104.95 80 2d11h
使用Cert-Manager管理证书
完成IpAddress的绑定后，紧接着前往自己的域名提供商，进行DNS解析。完成解析后，打开浏览器访问，却提示失败，如下图所示。这是由于Nginx Ingress Controller 默认启用了HSTS(HTTP Strict Transport Security)，也就是强制https请求。因此解决该问题的关键在于申请https证书并绑定，那如何申请证书呢，可以借助Cert-Manager，其可以帮助我们自动管理证书，包括证书的申请和续期。
GitLab在安装之初，已经默认安装了Cert-Manager组件，因此直接使用即可，通过在ingress中添加注解并指定tls配置即可。但并不能直接使用cert-manager.io/issuer: gitlab-issuer注解，因为gitlab-issuer仅作用于gitlab命名空间。针对这个问题，有两种解决方案，一种是在当前应用所在的命名空间创建一个新的issuer，另一种创建一个集群级别的cluser-issuer。由于证书的管理一般都是通用的，因此为了方便起见，创建一个集群级别的cluster-issuer以方便复用。下面通过以下脚本创建一个名letsencrypt-prod的ClusterIssuer，借助免费的证书颁发机构：Let's Encrypt 进行证书申请。
apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
spec:
acme:
email: ysjshengjie@live.cn # 指定个人邮箱
preferredChain: ''
privateKeySecretRef:
name: letsencrypt-prod
server: 'https://acme-v02.api.letsencrypt.org/directory' # 使用letsencrypt免费证书颁发机构
solvers:
- http01:
ingress:
class: nginx</pre>
创建完毕后，删除旧的demos-aspnetcore-cicd-demo-ingress ingress，然后使用以下脚本重新创建：
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
cert-manager.io/cluster-issuer: letsencrypt-prod # 标记使用cluster-issuer进行证书颁发
acme.cert-manager.io/http01-edit-in-place: "true"
kubernetes.io/ingress.class: gitlab-nginx
kubernetes.io/ingress.provider: nginx
name: demos-aspnetcore-cicd-demo-ingress
namespace: aspnetcore-cicd-demo-4-development
spec:
tls:
- hosts:
- demo.shengjie.dev
secretName: demo-shengjie-tls # 指定申请的证书保存在哪个secret中
rules:
- host: demo.shengjie.dev
http:
paths:
- backend:
service:
name: demos-aspnetcore-cicd-demo-service
port:
number: 80
path: /
pathType: Prefix
创建完毕后，执行kubectl get certificate -n aspnetcore-cicd-demo-4-development -w命令，当证书处于Ready状态时，就可以使用浏览器访问https://demo.shengjie.dev，即可得到久违的Hello World!，通过点击浏览器的🔒形状图标，即可查看证书信息，如下图所示：
