k8s学习笔记

master里有四个组件，分别是apiserver，etcd，scheduler，controller-manager。

worker里有三个组件，分别是kubelet，kube-proxy，container-runtime。

Declarative，声明式，不关心具体的过程，更注重结果。我们不需要“教”计算机该怎么做，只要告诉它一个目标状态，它自己就会想办法去完成任务，相比起来自动化、智能化程度更高。

命名空间“kube-system”就包含了 apiserver、etcd 等核心组件的 Pod。

Shell 脚本和 Dockerfile属于命令式，yaml属于声明式。

在使用 kubectl 命令的时候，加上一个参数 --v=9，会显示出详细的命令执行过程，清楚地看到发出的 HTTP 请求。

“header”包含的是 API 对象的基本信息，有三个字段：apiVersion、kind、metadata。

使用参数 --dry-run=client -o yaml 可以生成对象的 YAML 模板，简化编写工作。

API 对象 Job 和 CronJob，它们代表了生产环境中的离线业务，通过对 Pod 的包装，向 Pod 添加控制字段，实现了基于 Pod 运行临时任务和定时任务的功能。

DaemonSet 的目标是为集群里的每个节点部署唯一的 Pod，常用于监控、日志等业务。

Service，它是集群内部的负载均衡机制，用来解决服务发现的关键问题。

Service 本质上就是一个由 kube-proxy 控制的四层负载均衡，在 TCP/IP 协议栈上转发流量

Service 本身是没有服务能力的，它只是一些 iptables 规则，真正配置、应用这些规则的实际上是节点里的 kube-proxy 组件。如果没有 kube-proxy，Service 定义得再完善也没有用。

Service 用一个静态 IP 地址代理了两个 Pod 的动态 IP 地址

Ingress 的路由规则是 HTTP 协议，所以就不能用 IP 地址的方式访问，必须要用域名、URI。

Service 对象的 IP 地址还有一个特点，它是一个“虚地址”，不存在实体，只能用来转发流量。

Service 的 IP 地址是“虚”的，只用于转发流量，所以 ping 无法得到回应数据包，也就失败了。

HTTP 协议用 80、HTTPS 用 443、Redis 是 6379、MySQL 是 3306

而所谓“网络栈”，就包括了：网卡（Network Interface）、回环设备（Loopback Device）、路由表（Routing Table）和 iptables 规则。对于一个进程来说，这些要素，其实就构成了它发起和响应网络请求的基本环境。

如果你想要实现两台主机之间的通信，最直接的办法，就是把它们用一根网线连接起来；而如果你想要实现多台主机之间的通信，那就需要用网线，把它们连接在一台交换机上。在 Linux 中，能够起到虚拟交换机作用的网络设备，是网桥（Bridge）。它是一个工作在数据链路层（Data Link）的设备，主要功能是根据 MAC 地址学习来将数据包转发到网桥的不同端口（Port）上。

Docker 会创建一个名字叫“docker0”的网桥，默认是私有网段“172.17.0.0/16”。每个容器都会创建一个虚拟网卡对（veth pair），两个虚拟网卡分别“插”在容器和网桥上，这样容器之间就可以互联互通了。

执行 docker logs 命令，查看容器的日志。加上 -f 参数，表示跟踪容器的最新日志输出。

调用 Docker 的 API，查询容器的状态、退出码以及错误信息，然后确定容器退出的原因。这些可以通过 docker inspect 命令来完成

ARP（Address Resolution Protocol），是通过三层的 IP 地址找到对应的二层 MAC 地址的协议。