1, Creating external services using ingress
In the figure of "configuring service access through ingress", we can see that an svc needs to be created to expose services using ingress, so we first create one with the following content. It will forward the services on pod kubia port 8080 to its own 8080. The pods it controls are those created at the beginning of our article.
kubia-svc.yaml
apiVersion: v1
kind: Service
metadata:
name: kubia
spec:
ports:
- port: 8080
targetPort: 8080
selector:
app: kubia
Then use kubectl create - F kubia svc Yaml creates the svc, and then we create an ingress. Ingress supports the creation of HTTP and HTTPS services. Next, let's create an HTTP service:
Create access to HTTP protocol
The access of http protocol is relatively simple. You can directly create the following configuration file. Through this ingress configuration file, nginx ingress controller will know how to develop services externally.
kubia-http-ingress.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: kubia
spec:
rules:
# Map the service to the domain name
- host: kubia.example.com
http:
paths:
# The service can be accessed via / path
- path: /
# The name and port number of the back-end svc of the service
backend:
serviceName: kubia
servicePort: 8080
Then use kubectl create - F kubia HTTP ingress Yaml can create ingress. We can use kubectl describe address kubia to view his introduction:
root@master1:~# k describe ingress kubia Name: kubia Namespace: default Address: Default backend: default-http-backend:80 (<none>) Rules: Host Path Backends ---- ---- -------- kubia.example.com / kubia:8080 (10.244.1.59:8080,10.244.2.31:8080,10.244.3.30:8080) Annotations: Events: <none>
ok, now we can pass http://kubia.example.com/ To visit the target svc, you may wonder, I don't have this domain name? It doesn't matter. Configure it in the hosts file of the system and map the domain name to the ip address of nginx ingress controller. See the following for details:
Configure domain name to ip address
First, get the IP address of nginx ingress controller, execute the following command, press Tab to complete the name, and then find the corresponding IP in the IP column.
kubectl describe pod -n ingress-nginx nginx-ingress-controller-
My ip address is 192.168.56.22. Execute vi /etc/hosts and enter the following:
192.168.56.22 kubia.example.com
After modification, we can access it and execute curl http://kubia.example.com/ , you can see the response from svc kubia.
root@master1:~# curl http://kubia.example.com/ You've hit kubia-m68bq root@master1:~# curl http://kubia.example.com/ You've hit kubia-8r2cg root@master1:~# curl http://kubia.example.com/ You've hit kubia-flg8w
Create access to HTTPS protocol
https access here means that the connection between the client and the ingress controller is encrypted, while the connection between the controller and the back-end svc and pod is still http, as shown below:
To enable ingress to provide https services, we first need to have a certificate and private key. Here we create them first:
openssl genrsa -out tls.key 2048 openssl req -new -x509 \ -key tls.key \ -out tls.cert \ -days 360 \ -subj /CN=kubia.example.com
After execution, you can find two files in the current folder, TLS Cert and TLS key. Because this secret key is sensitive and not suitable for direct attachment to the pod, you can use the secret resource provided by k8s for providing sensitive data to store it. Let's create a new secret resource called TLS secret first:
kubectl create secret tls tls-secret --cert=tls.cert --key=tls.key
What is a secret resource?
Secret is used to store some sensitive configuration information, such as password and key. You can understand it as a more secure ConfigMap resource. k8s provides many types of secrets. For example, kubectl create secret tls above is a commonly used secret.
Then we can modify kubia - HTTP - ingress Yaml, mount this secret:
kubia-https-ingress.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: kubia
spec:
# Add tls field to enable https
tls:
- hosts:
# https enabled domain name
- kubia.example.com
# The certificate and key assigned to it require k8s secret resources of tls type
secretName: tls-secret
rules:
- host: kubia.example.com
http:
paths:
- path: /
backend:
serviceName: kubia
servicePort: 8080
Then we can use the following command to upgrade the http service just created to https. kubectl apply relies on the data in the kind and metadata fields to find the resources to be modified, so changing the name will not have any impact:
kubectl apply -f kubia-https-ingress.yaml
Then enter curl -k -v https://kubia.example.com , you can find the enabled HTTPS connection of our service:
root@master1:~# curl -k -v https://kubia.example.com ... * successfully set certificate verify locations: * CAfile: /etc/ssl/certs/ca-certificates.crt ... * Server certificate: * subject: CN=kubia.example.com ... You've hit kubia-flg8w
Expose multiple services using ingress
In kubia ingress As can be seen from yaml file, rules and paths are arrays, so we can expose multiple services through them, as follows:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: kubia
spec:
rules:
- host: foo.example.com
http:
paths:
# Access different services by specifying different paths
- path: /foo
backend:
serviceName: foo-svc
servicePort: 8080
- path: /bar
backend:
serviceName: bar-svc
servicePort: 8080
# You can also configure different hosts by specifying multiple hosts
- host: foo.example.com
http:
paths:
- path: /kubia
backend:
serviceName: kubia
servicePort: 8080
However, even if multiple rules can be configured in one file, it is still recommended to create a unique ingress for each svc, which will be more clear and convenient for future management