preface
We must build up the environment, see is not to solve the problem, must be actual combat.
Kubernetes series:
- Kubernetes is introduced
- Kubernetes environment setup
- Kubernetes – kubectl is introduced
- Introduce Kubernetes – Pod (-)
- Kubernetes-pod introduction (2)- Life cycle
- Kubernetes-pod introduction (3) -POD scheduling
- Introduction to Kubernetes-POD (4)-Deployment
- Kubernetes-service (kubernetes-service
- Kubernetes-service -Service Discovery
What needs Ingress
Service is based on layer 4 TCP and UDP, while Ingress can be based on layer 7 HTTP and HTTPS. It can be divided into finer granularity by domain name and path, as shown in the following figure:
Ingress Request process
The Ingress Controller searches for the corresponding Service according to the routing rules of the Ingress, queries the Pod IP address through the Endpoint, and forwards the request to the Pod.
Ingress and Ingress Controller
In simple terms, the Ingress Controller is the component responsible for specific forwarding. It is exposed to the cluster entrance in various ways, and external requests to the cluster will be sent to the Ingress Controller first. The Ingress object is used to tell the Ingress Controller how to forward requests, such as which domain names and which paths to forward to which services, etc.
Ingress Controller
Ingress Controller is not a built-in component of Kubernetes. In fact, Ingress Controller is just a general name. Users can choose different implementations of Ingress Controller. There are only two Ingress Controllers maintained by Kubernetes, Google GCE and Ingress Nginx. There are many other Ingress controllers maintained by third parties. However, regardless of the Ingress Controller, the implementation mechanism is basically the same, only the specific configuration is different. Typically, Ingress controllers take the form of a Pod with daemons and reverse agents running inside. Daemons monitor cluster changes, generate configurations based on Ingress objects and apply new configurations to reverse proxies. For example, Nginx Ingress dynamically generates Nginx configurations, updates upstreams and reloads new configurations when needed.
Ingress
Ingress is an API object, like any other object, configured through a YAML file. Ingress exposes cluster internal services through Http or Https, providing external urls, load balancing, SSL/TLS capabilities, and host-based proxies to the Service.
Ingress of deployment
Deployment+ Service in LoadBalancer mode
If you want to deploy Ingress in the public cloud, this is the way to go. Deploy the Ingress Controller in Deployment and associate this Pod group with a Service of type LoadBalancer. Most public clouds automatically create a LoadBalancer for the LoadBalancer Service, usually with a public address bound. As long as the domain name resolution is directed to this address, the cluster service is exposed. This solution identifies the need to deploy on the public cloud.
Service in Deployment+NodePort mode
Deploy the Ingress Controller in Deployment mode and create the corresponding service, but type is NodePort. In this way, the Ingress is exposed to specific ports of the cluster node IP. Because Nodeport is a random port, a load balancer is built in front of it to forward requests. This method is generally used when the host is relatively fixed IP address.
Disadvantages:
- Although NodePort is simple and convenient to expose Ingress, NodePort has a layer of forwarding, which may affect performance when the request magnitude is large.
- The request node will be something like www.a.com:3008, where 3008 is the Nodeport exposed by Ingress Nginx’s SVC, which looks less professional;
DaemonSet + HostNetwork + NodeSelector mode
DaemonSet and Nodeselector were used to deploy the Ingress Controller on a specific Node. Then HostNetwork was used to connect the Pod directly to the network of the host Node, and the service could be accessed directly through the 80/433 port of the host. The Node where the Ingress Controller resides is the entry point.
advantages
In this way, the whole request link is the simplest, and the performance is better than that of NodePort because the layer forwarding is reduced.
disadvantages
Only one POD of the Ingress Controller can be deployed on a Node, since the network and ports of the host Node are directly utilized.
Deployment of actual combat
Note the following about versioning:
This article uses ingress-Nginx V1.0.0, the latest version of v1.0.0 for Kubernetes v1.19+;
Kubernetes-v1.22+ requires ingress-nginx>=1.0 because networking. K8s. IO /v1beta has been removed;
Deployment + NodePort mode
- Use wget to download deploy.yaml for v1.0.0. You can download the deploy.yaml file in step 2.
wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.0.0/deploy/static/provider/baremetal/deploy.yam lCopy the code
- Next we need to modify the image file in deploy.yaml. Since all images related to k8s.gcr. IO are blocked in China, I download the image file from docker official. IO /ingress-nginx/ Controller :v1.0.0 and k8s.gcr. IO /ingress-nginx/kube-webhook-certgen:v1.0 images need to be replaced with WillDockerHub/inGRE Ss-nginx-controller :v1.0.0; Jettech/Kube-webhook-certgen :v1.5.2; Yaml (deploy-0.0-without-class =true); yaml (deploy-0.0-without-class =true);
- Deployed nginx ingress – controller;
Kubectl apply -f v1.0.0 - deploy. YamlCopy the code
- The nginx-ingress-controller Service is a NodePort and is randomly assigned two ports (32368 and 32577).
Check pod status
kubectl get pods -n ingress-nginx -owide
# to check the service
kubectl get service -n ingress-nginx
Copy the code
- Nginx-deployment. yaml and nginx-service.yaml;
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
selector:
matchLabels:
app: backend
replicas: 3
template:
metadata:
labels:
app: backend
spec:
containers:
- name: nginx
image: nginx:latest
resources:
limits:
memory: "128Mi"
cpu: "128m"
ports:
- containerPort: 80
Copy the code
apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
# Backend = app=backend
selector:
app: backend
ports:
# service port number
- port: 80
# Port number of pod
targetPort: 80
Copy the code
kubectl apply -f nginx-service.yaml
kubectl apply -f nginx-nodeport-service.yaml
Copy the code
- Verify that the Service has been created and can be accessed from the Service address;
Check service status
kubectl get svc
# access serviceThe curl http://10.96.45.195Copy the code
- Create the ingress policy nodeport-ingress.yaml and create the corresponding resource.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: nodeport-ingress
namespace: default
spec:
rules:
- host: aa.bb.cc
http:
paths:
- pathType: Prefix
path: /
backend:
service:
name: nginx-service
port:
number: 80
Copy the code
# create ingress resource
kubectl apply -f nodeport-ingress.yaml
# Check ingress resources
kubectl get ingress
Copy the code
- Check resource access, here using nginx-ingress-controller exposed port 32368 access service information;
The first option is to set the host file on the corresponding Node
echo '172.21.122.231 aa, bb. Cc' >> /etc/hosts
curl aa.bb.cc:32368
# CurlThe curl -v http://172.21.122.231:32368 - H'host: aa.bb.cc'
Copy the code
DaemonSet + HostNetwork + nodeSelector mode
- Clear resources;
Yaml kubectl delete -f nginx-nodeport-service.yaml kubectl delete -f deploy nodeport-ingress.yamlCopy the code
- Label the Node as ingress=nginx;
kubectl label nodes demo-work-1 ingress=nginx
Copy the code
- Yaml, find the deployment section, change kind to DaemonSet, nodeSelector nodeSelector to ingress = nginx, add network to hostNetwork = true, –watch — ingress-without-class — args –watch — ingress-without-class — arGS –watch — ingress-without-class — args — ingress — without-class
apiVersion: apps/v1
kind: DaemonSet
metadata:
labels:
helm.sh/chart: Ingress - nginx - 4.0.1
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/version: 1.0. 0
app.kubernetes.io/managed-by: Helm
app.kubernetes.io/component: controller
name: ingress-nginx-controller
namespace: ingress-nginx
spec:
selector:
matchLabels:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/component: controller
revisionHistoryLimit: 10
minReadySeconds: 0
template:
metadata:
labels:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/component: controller
spec:
dnsPolicy: ClusterFirst
containers:
- name: controller
image: Willdockerhub/ingress - nginx - controller: v1.0.0
imagePullPolicy: IfNotPresent
lifecycle:
preStop:
exec:
command:
- /wait-shutdown
args:
- /nginx-ingress-controller
- --election-id=ingress-controller-leader
- --controller-class=k8s.io/ingress-nginx
- --configmap=$(POD_NAMESPACE)/ingress-nginx-controller
- --validating-webhook=:8443
- --validating-webhook-certificate=/usr/local/certificates/cert
- --validating-webhook-key=/usr/local/certificates/key
- --watch-ingress-without-class=true # new
securityContext:
capabilities:
drop:
- ALL
add:
- NET_BIND_SERVICE
runAsUser: 101
allowPrivilegeEscalation: true
env:
- name: POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: POD_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
- name: LD_PRELOAD
value: /usr/local/lib/libmimalloc.so
livenessProbe:
failureThreshold: 5
httpGet:
path: /healthz
port: 10254
scheme: HTTP
initialDelaySeconds: 10
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 1
readinessProbe:
failureThreshold: 3
httpGet:
path: /healthz
port: 10254
scheme: HTTP
initialDelaySeconds: 10
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 1
ports:
- name: http
containerPort: 80
protocol: TCP
- name: https
containerPort: 443
protocol: TCP
- name: webhook
containerPort: 8443
protocol: TCP
volumeMounts:
- name: webhook-cert
mountPath: /usr/local/certificates/
readOnly: true
resources:
requests:
cpu: 100m
memory: 90Mi
nodeSelector:
ingress: nginx
hostNetwork: true
serviceAccountName: ingress-nginx
terminationGracePeriodSeconds: 300
volumes:
- name: webhook-cert
secret:
secretName: ingress-nginx-admission
Copy the code
- Deploy and check ingress-nginx;
# deployment ingress - nginxKubectl apply -f v1.0.0 - deploy. YamlCheck pod status
kubectl get pods -n ingress-nginx -owide
# to check the service
kubectl get service -n ingress-nginx
Copy the code
- Create nginx-service.yaml and change the mode to ClusterIP.
apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
# Backend = app=backend
selector:
app: backend
ports:
# service port number
- port: 80
# Port number of pod
targetPort: 80
Copy the code
- Create nginx-service and check resource status.
# to create nginx - service
kubectl apply -f nginx-service.yaml
Check resource status
kubectl get svc
# Resource binding
kubectl describe service nginx-service
# curl AccessThe curl 10.96.53.148Copy the code
- Create hostnetwork-ingress.yaml file;
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: nodeport-ingress
namespace: default
spec:
rules:
- host: aa.bb.cc
http:
paths:
- pathType: Prefix
path: /
backend:
service:
name: nginx-service
port:
number: 80
Copy the code
- Create the ingress resource.
# to create ingress
kubectl apply -f hostnetwork-ingress.yaml
# Check ingress resources
kubectl get ingress
Copy the code
- Check access to resources;
The curl -v http://172.21.122.231 - H'host: aa.bb.cc'
Copy the code
The end of the
Welcome everyone little attention, little praise!