Nginx ingress controller
Kubernetes about the service exposure is mainly through the Nodeport way, through the binding minion host of a port, then the pod request forwarding and load balancing, but this way the defect is
- The service may have many, if each is bound to a node host port, the host needs to open the perimeter of a heap of ports to make services calls, management confusion
- Cannot apply firewall rules required by many companies
Ingress nginx kubernetes
The ideal way is through an external load balancer, binding fixed port, such as 80, and then according to the domain name or service name to the back of the services IP forwarding, nginx very good solution to this demand, but the problem is if there is a new service to join, how to modify Nginx configuration, and load these configurations? The solution given by Kubernetes is that ingress,ingress contains two main pieces ingress controller and INGRESS.
- Ingress solves the problem of the domain name and service after the new service is added, basically a ingress object, which is loaded by creating and updating with Yaml.
- Ingress Controller is to ingress this change to generate a nginx configuration, and then this configuration through the Kubernetes API written to the Nginx pod, and then Reload.
Nginx ingress controller kubernetes
The specific implementation is as Follows:
Nginx ingress controller setup
1. Generate a default backend and forward to the default backend page if you encounter a URL that cannot be resolved
[email protected] ingress]# Catdefault-Backend.yaml apiversion:extensions/v1beta1kind:Deploymentmetadata:name:default-http-Backend labels:k8s-app:default-http-Backendnamespace: kube-systemspec:replicas:1template:metadata:labels:k8s-app:default-http-Backend Spec:terminationgraceperiodseconds: -containers:-name:default-http-Backend # any image isPermissable as Long as: # 1. It serves a404Page at/ # 2. It serves $On a/Healthz Endpoint Image:gcr.io/google_containers/defaultbackend:1.0LivenessProbe:httpGet:path:/Healthz port:8080scheme:http initialdelayseconds: -timeoutseconds:5ports:-containerport:8080resources:limits:cpu:10m memory:20mi requests:cpu:10m Memory:20mi---apiVersion:v1kind:Servicemetadata:name:default-http-Backendnamespace: kube-system labels:k8s-app:default-http-backendspec:ports:-port: thetargetport:8080selector:k8s-app:default-http-backend
Kubernetes ingress nginx master
2. Deploying Ingress Controller
Specific documents can refer to the official
Https://github.com/kubernetes/ingress/blob/master/examples/daemonset/nginx/nginx-ingress-daemonset.yaml
Put one of mine here.
[email protected] ingress]# Cat nginx-ingress-Controller.yaml ApiVersion:v1kind:ReplicationControllermetadata:name:nginx-ingress-lb Labels:name:nginx-ingress-lbnamespace: kube-systemspec:replicas:1Template:metadata:labels:name:nginx-ingress-lb Annotations:prometheus.io/port:'10254'Prometheus.io/scrape:'true'spec:terminationgraceperiodseconds: -hostnetwork:truecontainers:-image:gcr.io/google_containers/nginx-ingress-controller:0.9.0-beta.7Name:nginx-ingress-lb ReadinessProbe:httpGet:path:/Healthz port:10254scheme:http livenessProbe:httpGet:path:/Healthz port:10254scheme:http initialdelayseconds:Tentimeoutseconds:1ports:-containerport: thehostport: the-containerport:443hostport:443Env:-name:pod_name ValueFrom:fieldRef:fieldPath:metadata.name-name:pod_namespace ValueFrom:fieldRef:fieldPath:metadata.namespace-Name:kubernetes_master value:http://192.168.0.105:8080args:-/nginx-ingress-Controller- --default-backend-service=$ (pod_namespace)/default-http-Backend---apiserver-host=http://192.168.0.105:8080
The problem that has arisen is that the pod is always in the Crashloopback state after launch, and by logs it is found that Nginx-ingress-controller's boot is always connected to the 443 port of the Apiserver internal cluster ip. Cause the security problem not to let start, later added in args
---apiserver-host=http://192.168.0.105:8080
After the successful Start.
3. Configure ingress
Configured as follows
[email protected] ingress]# cat dashboard-weblogic.yaml apiversion:extensions/v1beta1kind: Ingressmetadata: name:dashboard-weblogic-ingress namespace: kube-systemspec: rules: - host:helloworld.eric http: paths: -path:/console backend: serviceName: Helloworldsvc 7001 -path:/ backend: servicename:kubernetes- Dashboard the
Understand the Following:
- Host refers to the virtual domain name, the specific address (i understand that the Ingress-controller pod is located in the Host's Address) should be added to/etc/hosts, so that all requests to helloworld.eric will be sent to Nginx
- Path:/console match the following application path
- Serviceport is primarily the port that defines the service, not the Nodeport.
- path:/ Matches the path of the dashboard application, which was previously accessed through the master node 8080/ui into dashboard, but dashboard is actually deployed in the Minion node and is actually forwarded through a routed Statement. Dashboard the True path is as Follows:
And the Yaml file is
[email protected] ~]# Cat kubernetes-Dashboard.yaml apiversion:extensions/v1beta1kind:deploymentmetadata:# Keep the nameinchsync with image version and# GCE/coreos/kube-manifests/addons/Dashboard counterparts Name:kubernetes-dashboard-Latestnamespace: kube-systemspec:replicas:1template:metadata:labels:k8s-app:kubernetes-Dashboard Version:latest Kubernetes.io/cluster-service:"true"spec:containers:-name:kubernetes-Dashboard Image:gcr.io/google_containers/kubernetes-dashboard-amd64:v1.5.1Resources: # Keep Request= Limit to keep thisContainerinchGuaranteedclasslimits:cpu:100m memory:50mi requests:cpu:100m Memo Ry:50mi ports:-containerport:9090args:---apiserver-host=http://192.168.0.105:8080LivenessProbe:httpGet:path:/port:9090initialdelayseconds: -timeoutseconds: ----kind:Servicemetadata:name:kubernetes-Dashboardnamespace: kube-system labels:k8s-app:kubernetes-Dashboard Kubernetes.io/cluster-service:"true"spec:selector:k8s-app:kubernetes-Dashboard Ports:-port: thetargetport:9090
So access to the 192.168.51.5:9090 port will appear dashboard
4. Testing
Ok, Everything's Ready.
Visit http://helloworld.eric/console
Access Http://helloword.eric/appears Dashboard
5. Configure TLS SSL Access
The configuration of TLS is equivalent to the configuration of the certificate in weblogic, and the configuration process is as follows
# Generate CA self-visa mkdir cert&&CD Certopenssl Genrsa- outCa-key.pem2048OpenSSL req-x509-New-nodes-key ca-key.pem-days10000- outCa.pem-subj"/cn=kube-ca"# Edit OpenSSL configuration cp/etc/pki/tls/openssl.cnf. vim openssl.cnf# is mainly modified as follows [req]req_extensions=V3_req # The default comment in this line closes the comment out # The following configuration is new [v3_req]basicconstraints=Ca:falsekeyusage=nonrepudiation, digitalsignature, keyenciphermentsubjectaltname=@alt_names [alt_names]dns.1=Helloworld.eric#dns.2=kibana.mritd.me# Generating certificate OpenSSL genrsa- outIngress-key.pem2048OpenSSL req-New-key ingress-key.pem- outIngress.csr-subj"/cn=helloworld.eric"-config Openssl.cnfopenssl x509-req-inchIngress.csr-ca Ca.pem-cakey ca-key.pem-cacreateserial- outIngress.pem-days365-extensions V3_req-extfile openssl.cnf
It is important to note that DNS needs to be modified to its own host name, and then the domain name or access name needs to be brought into the SUBJ when configuring the CSR certificate request, such as
KUBECTL Create secret TLS ingress-secret--namespace
- To modify a ingress file to enable a certificate
[email protected] ingress]# Cat tls-Weblogic.yaml apiversion:extensions/V1beta1kind:Ingressmetadata:name:dashboard-weblogic-Ingressnamespace: kube-systemspec:tls:-hosts:-helloworld.eric secretname:ingress-Secret Rules:-host:helloworld.eric http:paths:-path:/Console backend:serviceName:helloworldsvc serviceport:7001-path:/backend:serviceName:kubernetes-Dashboard Serviceport: the
Then access the helloworld.eric/console, automatically go to the HTTPS page, while viewing the certificate and join the credit list, visible
Visit helloworld.eric
Kubernetes load Balancing problem (Nginx Ingress)