Shulou(Shulou.com)06/03 Report--

1. Understanding Pod Objects 1.Pod Container Classification · Infrastructure Container ·Maintains the entire Pod cyberspace InitContainers: Initialize containers ·Start execution before business containers Containers: Business containers ·Parallel startup 2. mirror pull strategy · IfNotPresent: default value, pulled only when mirror does not exist on host Always: Every time a Pod is created, it will pull a mirror again. Never: Pod will never actively pull this image 3. resource constraints Resource requests and limits for Pods and Containers: · spec.containers[].resources.limits.cpu · spec.containers[].resources.limits.memory · spec.containers[].resources.requests.cpu · spec.containers[].resources.requests.memory Request can be understood as pre-allocation, that is, judging the existing resources of the cluster. Limit is similar to docker resource limit. 4. Restart Policy Always: Always restart the container after it terminates, default policy. · OnFailure: Restart the container only when the container exits abnormally (exit status code is not 0). Never: Never restart the container when it terminates. 5. Health Check (Probe) There are two types of probes: livenessProbe If the check fails, the container will be killed, acting according to the Pod's restart policy. readinessProbe If the check fails, Kubernetes removes the Pod from service endpoints. Probe supports the following three inspection methods:

httpGet

Send HTTP request and return status code in the range of 200-400 as success.

exec

Execution of Shell command returns status code 0 as success.

tcpSocket

TCP Socket successfully established.

Reference website: kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/

6. scheduling constraint

nodeName is used to dispatch a Pod to a specified Node name

nodeSelector is used to dispatch Pods to nodes matching Labels

7. troubleshooting

2. Deployment of common controllers for applications 1.Relationship between pods and controllers controllers: objects that manage and run containers on a cluster ·Correlation via label-selector · Pod implements application operation and maintenance through controller, such as scaling, rolling upgrade, etc. 2.Deployment ·Deploying stateless applications ·Manage Pods and ReplicaSets ·On-line deployment, copy setting, rolling upgrade, rollback and other functions ·Provide declarative updates, such as updating only one new Image Application scenarios: Web services, microservices 3.DaemonSet ·Run a Pod on each Node A newly added Node will also automatically run a Pod. Application scenario: Agent https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/ 4.Job Job is divided into ordinary tasks (Job) and scheduled tasks (CronJob) ·One-time execution Application scenarios: offline data processing, video decoding and other services https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/ 5.CronJob Timed tasks, like Linux Crontab. ·Timed tasks Scenario: Notification, Backup https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/ 6.Statefulset Deploying stateful apps requires network ID and storage considerations Such as mysql jenkins, etc. 3. Service-unified entrance access application

1. Introduction to service

·Prevent Pod Disconnection (Service Discovery)

·Define an access policy for a group of pods (Load Balancer)

·Supports ClusterIP, NodePort and LoadBalancer

·The underlying implementation of Service mainly includes iptables and ipvs two network modes

2. Relationship between Pod and Service Load Balancer (TCP/UDP Layer 4) of Pod via Service ClusterIP: Assign an internal cluster IP address, which can only be accessed within the cluster (pods within the same Namespace), default ServiceType. What the ClusterIP model Service provides you with is a stable IP address of a Pod, i.e. VIP. NodePort: Assign an internal cluster IP address and enable a port on each node to expose services that can be accessed outside the cluster. Access address: : LoadBalancer: Assign an internal cluster IP address and enable a port on each node to expose services. In addition, Kubernetes requests the Load Balancer on the underlying cloud platform to add each Node ([NodeIP]:[NodePort]) as a backend. Generally supported by cloud service providers, self-built clusters do not support this type. 4. Service proxy mode Iptables VS IPVS Iptables：

·Flexible and powerful

·Rule traversal matches and updates with linear delay

·Scalability

IPVS：

·Works in kernel mode with better performance

·Rich scheduling algorithms: rr, wrr, lc, wlc, ip hash...

The default is iptables mode, if you need to use ipvs, you need to modify configmap (kubeadm deployment, if it is binary, modify kube-proxy configuration file), the server enables ipvs.

5.DNS DNS service monitors Kubernetes API and creates DNS records for each Service for domain name resolution. ClusterIP A record format: .. svc.cluster.local Example: my-svc.my-namespace.svc.cluster.local

Summary:

NodePort is used to expose applications to the outside world, and an LB is added in front to achieve unified access. IPVS proxy mode is used first. DNS name is used for applications in clusters.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.