Recently I ran into this twice: a host had to be reinstalled because of a failure. In one case only a single Etcd node was left, and the whole cluster stayed down for half an hour before it recovered. This post mainly records the process of initializing a fresh Ubuntu

FailedCreatePodSandBox Error Error response from daemon: OCI runtime create failed: container_linux.go:380: starting container process caused: process_linux.go:402: getting the final child's pid from pipe caused: EOF: unknown Resolution Clear the cache 1 echo 3 > /proc/sys/vm/drop_caches Cause Too much memory fragmentation calico-node Keeps Restarting increase max user Error runtime: failed to

A record of repairing a cluster failure caused by an IP change. There are two clusters: one single-node (allinone) cluster, and one four-node cluster (3 masters, 1 node). 1. Update the Etcd Certificates [On every Etcd node] Back up the Etcd certificates 1 cp -R /etc/ssl/etcd/ssl /etc/ssl/etcd/ssl-bak View the domains

This article is translated from https://learnk8s.io/kubernetes-network-packets, not word for word, with some of my own understanding worked in. By reading this article, you can learn how packets are forwarded inside and outside Kubernetes, starting from the original web request all the way to the container hosting the application. Kubernetes Network Requirements Before diving into the details of how packets flow through a Kubernetes cluster, let’s first clarify Kubernetes’ requirements for networking.

1. Traffic Control Principles Under Linux By queuing packets, we can control how data packets are sent. This kind of control is called data shaping (shape the data), and it includes the following operations on data: Adding latency Dropping packets Reordering Duplicating, corrupting Rate control Under the qdisc-class-filter structure, controlling traffic requires three steps: