Scert-manager certificate controller for Kubernetes (automatic certificate issuance)

cert-manager certificate controller

The cert-manager runs in a Kubernetes cluster as a series of deployment resources. It is CustomResourceDefinitionsused to configure the certification authority and the certificate request.

It uses a regular YAML manifest for deployment, just like any other application on Kubernetes.

After deploying the certificate manager, you must configure Issueror ClusterIssuerrepresent the resources of the certificate authority. For Issuermore information on the different types of configurations , please refer to their respective configuration guides .

Note: Starting from cert-manager v0.14.0, the minimum supported version of Kubernetes is v1.11.0. v1.10Users who are still running Kubernetes or lower should upgrade to a supported version before installing cert-manager.

Warning : You should not install multiple instances of cert-manager on a single cluster. This will lead to indeterminate behavior and you may be banned by providers such as "Let's Encrypt".

Install the certificate controller

All resources ( CustomResourceDefinitions, cert-manager, namespace and webhook components) are contained in a single YAML manifest file:

Note : If you are using the kubectlfollowing versions v1.19.0-rc.1, you will encounter problems when updating the CRD. For more information, see the v0.16 upgrade instructions

Installation CustomResourceDefinitionsand cert-manager itself:

# Kubernetes 1.16+
kubectl create namespace cert-manager
kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v1.0.3/cert-manager.yaml

Note : If you are using the Kubernetes version below v1.15, you need to install the old version of the manifest. There is no API version conversion for this version, only cert-manager.io/v1API resources are supported .

Note : If you are running Kubernetes v1.15.4or earlier, you need the top --validate=falseof the kubectl applyflag a command, or you will receive x-kubernetes-preserve-unknown-fieldscert-manager CustomResourceDefinitionvalidation errors resource-related fields. This is a benign error that kubectloccurs due to the way the resource verification is performed.

Note : When running on GKE (Google Kubernetes Engine), you may encounter a "Permission Denied" error when creating some of these resources. This is a way of handling the nuances of GKE and IAM RBAC permissions, so in running the above command before , should their privileges "upgrade" for the "cluster-admin" privileges. If you have already run the above commands, you should run them again after elevated privileges:

  kubectl create clusterrolebinding cluster-admin-binding \
    --clusterrole=cluster-admin \
    --user=$(gcloud config get-value core/account)

Note : By default, cert-manager will be installed in the cert-managernamespace. Although you need to modify the deployment manifest, you can run cert-manager in other namespaces.

verification

kubectl get pods --namespace cert-manager

NAME                                       READY   STATUS    RESTARTS   AGE
cert-manager-5c6866597-zw7kh               1/1     Running   0          2m
cert-manager-cainjector-577f6d9fd7-tr77l   1/1     Running   0          2m
cert-manager-webhook-787858fcdb-nlzsq      1/1     Running   0          2m

Create a CA cluster certificate issuer

The certificate manager requires Issuer or ClusterIssuer resources to issue certificates. Both Kubernetes functionally identical resources, the difference is Issuerapplied to a single namespace, and ClusterIssuerapply to all namespaces. See the certificate manager issuer documentation for details .

Use the following sample checklist to create a cluster certificate issuer, for example cluster-issuer.yaml. Update the email address to a valid address provided by the organization:

apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
metadata:
  name: letsencrypt
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: MY_EMAIL_ADDRESS
    privateKeySecretRef:
      name: letsencrypt
    solvers:
    - http01:
        ingress:
          class: nginx
          podTemplate:
            spec:
              nodeSelector:
                "kubernetes.io/os": linux

To create the certificate issuer, use the kubectl applycommand.

kubectl apply -f cluster-issuer.yaml

Deploy the Ingress entry route

---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
  #指定ca证书颁发者
    cert-manager.io/cluster-issuer: letsencrypt
    k8s.kuboard.cn/workload: web-phpipam
  labels:
    k8s.kuboard.cn/layer: web
    k8s.kuboard.cn/name: web-phpipam
  name: web-phpipam
  namespace: ingress-basic
spec:
  rules:
    - host: phpipam.www.trusit.net
      http:
        paths:
          - backend:
              serviceName: web-phpipam
              servicePort: 80
            path: /
# 配置证书名称            
  tls:
    - hosts:
        - phpipam.www.trusit.net
      secretName: tls-secret

Use kubectl applycommand to create entry resources.

kubectl apply -f hello-world-ingress.yaml --namespace ingress-basic

Verify that the certificate object has been created

Next, a certificate resource must be created. The certificate resource defines the required X.509 certificate. For more information, see Certificate Manager Certificate . The certificate manager has used ingress-shim (automatically deployed with the certificate manager since v0.2.2) to automatically create a certificate object for you. For details, refer to the ingress-shim documentation .

To verify whether the certificate has been successfully created, use the kubectl get certificate --namespace ingress-basiccommand, and verify that READY whether True , it may take several minutes

$ kubectl get certificate --namespace ingress-basic

NAME         READY   SECRET       AGE
tls-secret   True    tls-secret   11m

Test entry configuration

Open the web browser to hello-world-ingress.MY_CUSTOM_DOMAIN of the Kubernetes ingress controller . Please note that the system will redirect you to use HTTPS. The certificate is trusted and the demo application is displayed in the web browser. Add the path and notice that the second demo application with a custom title is displayed.

Clean up resources

This article uses Helm to install portal components, certificates, and sample applications. When the Helm chart is deployed, several Kubernetes resources are created. These resources include pods, deployments, and services. To clean up these resources, you can delete the entire example namespace, or you can delete individual resources.

Delete the example namespace and all resources

To remove the entire example of a namespace, use the kubectl deletecommand and specify the namespace name. All resources in the namespace will be deleted.

Console copy

kubectl delete namespace ingress-basic

Delete resources individually

You can also use a more detailed method to delete a single created resource. First, delete the cluster issuer resource:

Console copy

kubectl delete -f cluster-issuer.yaml --namespace ingress-basic

Use helm listcommand to list Helm version. Look for the graphs named "nginx" and "cert-manager", as shown in the following sample output:

copy

$ helm list --namespace ingress-basic

NAME                    NAMESPACE       REVISION        UPDATED                                 STATUS          CHART                   APP VERSION
cert-manager            ingress-basic   1               2020-01-15 10:23:36.515514 -0600 CST    deployed        cert-manager-v0.13.0    v0.13.0    
nginx                   ingress-basic   1               2020-01-15 10:09:45.982693 -0600 CST    deployed        nginx-ingress-1.29.1    0.27.0  

Use helm uninstallthe command uninstall these versions. The following example will uninstall the NGINX portal and certificate manager deployment.

copy

$ helm uninstall cert-manager nginx --namespace ingress-basic

release "cert-manager" uninstalled
release "nginx" uninstalled

Next, delete the two sample applications:

Console copy

kubectl delete -f aks-helloworld-one.yaml --namespace ingress-basic
kubectl delete -f aks-helloworld-two.yaml --namespace ingress-basic

Delete the ingress route that directs traffic to the sample application:

Console copy

kubectl delete -f hello-world-ingress.yaml --namespace ingress-basic

Finally, you can delete your own namespace. Use kubectl deletethe command and specify the namespace name.

Console copy

kubectl delete namespace ingress-basic

Guess you like

Origin blog.csdn.net/weixin_43357497/article/details/111188191