Reference:

• Series: Deploying ASP.NET Core applications to Kubernetes

Book connection kubernetes practice record - building k8s clusters on ubuntu This time, one will be deployed on the kubernetes cluster installed last time Baget Application. In fact, it is to learn some basic concepts in kubernetes by deploying Baget, including node, pod deployment, service progress

This article only records your own practice process. Please correct or discuss if there are any mistakes or inadequacies

Node

A node is a physical server or virtual machine in a kubernetes cluster. The node can be roughly divided into a master node and other nodes. The master node is mainly responsible for providing a series of management interfaces to facilitate cluster management. Other nodes are generally scheduled to execute workload, Generally speaking, the pod runs on these other nodes. Of course, you can also let the master node run the specified pod through configuration. Usually, this may be done during local development. At this time, the master node is equivalent to being tainted

Pod and Deployment

If we want to run our own applications in kubernetes, we need to build a pod first. A pod can contain one or more (usually one) containers

Pod is the smallest scheduling unit in kubernetes. When pod starts or stops, the containers in pod will start or stop together

Origin of the name Pod: as we all know, the Docker icon is a whale, and pod actually means a group of whales

What's the relationship between Deployment and Pod? Through Deployment, we can build a Pod, configure the container in the Pod and the hardware resources used by the container

For example, if we want to deploy a Baget application, we need to create a baget-deployment.yaml file, which defines a Deployment resource, and then execute kubectl apply - F baget-deployment.yaml. Kubernetes will help us create a pod. You can view the running pods in the current kubernetes cluster through kubectl get pods -- all namespaces

Click to view the baget-deployment.yaml file

apiVersion: apps/v1
kind: Deployment
metadata:
  name: baget
  namespace: baget
  labels:
    app: baget
spec:
  selector:
    matchLabels:
      app: baget
  replicas: 1
  strategy:
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 2
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: baget
    spec:
      containers:
      - name: baget
        image: loicsharma/baget:latest
        resources:
          requests:
            cpu: 100m
            memory: 100Mi
          limits:
            cpu: 100m
            memory: 100Mi
        livenessProbe:
          httpGet:
            path: /v3/index.json
            port: 80
          initialDelaySeconds: 30
          timeoutSeconds: 30
          successThreshold: 1
          failureThreshold: 3
          periodSeconds: 30
        envFrom:
          - configMapRef:
              name: baget-config
        ports:
        - containerPort: 80
          protocol: TCP
        volumeMounts:
        - name: baget-data
          mountPath: /var/baget
      volumes:
        - name: baget-data
          hostPath:
            path: /laplus/data/baget
      restartPolicy: Always

This is a configuration file in yaml format. The top layer includes apiVersion kind metadata spec. almost every kubernetes configuration file has apiVersion kind metadata;
apiVersion is used to describe the kubernetes api applicable to this configuration file;

apiVersion: apps/v1

kind indicates the type of this resource, here is Deployment;

kind: Deployment

Metadata represents the metadata of resources. It usually has two attributes: name and labels. I also define an additional namespace here

metadata:
  name: baget
  namespace: baget
  labels:
    app: baget

Focus on the paragraph. spec.template.spec

spec:
    containers:
    - name: baget
      image: loicsharma/baget:latest
      resources:
          requests:
          cpu: 100m
          memory: 100Mi
          limits:
          cpu: 100m
          memory: 100Mi
      livenessProbe:
          httpGet:
          path: /v3/index.json
          port: 80
          initialDelaySeconds: 30
          timeoutSeconds: 30
          successThreshold: 1
          failureThreshold: 3
          periodSeconds: 30
      envFrom:
          - configMapRef:
              name: baget-config
      ports:
      - containerPort: 80
          protocol: TCP
      volumeMounts:
      - name: baget-data
          mountPath: /var/baget
    volumes:
    - name: baget-data
        hostPath:
        path: /laplus/data/baget

In this paragraph, we define the image of the container, the limitation of hardware resources that the container can schedule, the health check of the container, environment variables, disk mounting, etc

Finally, execute kubectl apply -f baget-deployment.yaml to let kubernetes create the resources defined by us. Execute kubectl get pods -n baget to list all pod s under the baget namespace

NAME                     READY   STATUS    RESTARTS   AGE
baget-5576d6fc79-n8k2s   1/1     Running   0          20h

Use Service to forward requests to the specified pod within the cluster

With a pod, containerized applications can run in the pod. Next, we will expose the applications in the pod within the cluster through Service

A Service is equivalent to the load balancer within the cluster. After the Service is created, other pods in kubernetes can pass through http://baget/v3/index.json Access the newly created pod called Baget

apiVersion: v1
kind: Service
metadata:
  name: baget
  namespace: baget
  labels: 
    app: baget
spec:
  type: ClusterIP
  selector:
    app: baget
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP

The. spec.type in the above Service configuration list indicates the Service type. In addition to the ClusterIP used, there are LoadBalancer,NodePort, etc; If you use NodePort, you can directly expose applications outside the cluster, that is, you can directly use the host ip + nodePort port to access applications. For example, I can use it here http://192.168.124.66: < NodePort port > / V3 / index.json access the deployed Baget application

Load balancing external requests with Ingress

Ingress can be understood as an external load balancer and a reverse proxy server in kubernetes. It is usually deployed on the edge node of the cluster and is responsible for processing requests from outside kubernetes cluster and forwarding requests to specified services

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: baget
  namespace: baget
  annotations: 
    kubernetes.io/ingress.class: nginx
spec:
  tls:
  - hosts:
    - "baget.inner.laplus.com"
  rules:
  - host: "baget.inner.laplus.com"
    http:
      paths:
      - path: "/"
        pathType: Prefix
        backend:
          service:
            name: baget
            port:
              number: 80

After kubectl apply -f baget-ingress.yaml deploys the above configuration list, locally resolve the domain name baget.inner.laplus.com to the edge server ip with nginx-ingress installed

192.168.124.66 baget.inner.laplus.com

Then access it with a browser https://baget.inner.laplus.com You can visit Baget's home page

Summary

After understanding the related concepts of pod development service progress, it is actually quite easy to deploy a container web application on kubernetes

Some pits are encountered mainly because the firewall ports are not fully open. According to https://www.cnblogs.com/laggage/p/install-kubernetes-on-ubuntu.html#%E9%98%B2%E7%81%AB%E5%A2%99 Just configure the firewall and open the port inside