标签：中继日志 zook 键值 请求响应 队列 iptable jin k8s point
最近面试被问到的几个问题，于是整理收集如下：
Master节点上面主要由四个模块组成：etcd、api server、controller manager、scheduler
api server：顾名思义提供API，通过rest接口实现各自的功能。如controller通过api来实时监控各个资源状态。
etcd：提供一个键值数据库，用于保存集群网络配置和资源对象的状态信息。数据变更都是通过api server进行。
系统中一共有两个服务需要用到etcd用来协同和存储配置，分别是：
1）网络插件flannel，其它网络插件也需要用到etcd存储网络的配置信息；
2）kubernetes本身，包括各种资源对象的状态和元信息配置。
scheduler：监听新建pod副本信息，并通过调度算法为该pod选择一个最合适的Node节点。会检索到所有符合该pod要求的Node节点，执行pod调度逻辑。调度成功之后，会将pod信息绑定到目标节点上，同时将信息写入到etcd中。一旦绑定，就由Node上的kubelet接手pod的接下来的生命周期管理。如果把scheduler看成一个黑匣子，那么它的输入是pod和由多个Node组成的列表，输出是pod和一个Node的绑定，即将这个pod部署到这个Node上。Kubernetes目前提供了调度算法，但是同样也保留了接口，用户可以根据自己的需求定义自己的调度算法。
controller manager：负责维护集群的状态，比如故障检测、自动扩展、滚动更新等。每个资源一般都对应有一个控制器，这些controller通过api server实时监控各个资源的状态，controller manager就是负责管理这些控制器的。当有资源因为故障导致状态变化，controller就会尝试将系统由“现有状态”恢复到“期待状态”，保证其下每一个controller所对应的资源始终处于期望状态。比如我们通过api server创建一个pod，当这个pod创建成功后，api server的任务就算完成了。而后面保证pod的状态始终和我们预期的一样的重任就由controller manager去保证了。
controller manager 包括运行管理控制器（kube-controller-manager）和云管理控制器（cloud-controller-manager）
----
Node节点，包括kubelet、kube-proxy、container runtime(docker)
kubelet 会监视已分配给节点的pod，负责pod的生命周期管理，同时与Master密切协作，维护和管理该Node上面的所有容器，实现集群管理的基本功能。即Node节点通过kubelet与master组件交互，可以理解为kubelet是Master在每个Node节点上面的agent。本质上，它负责使Pod的运行状态与期望的状态一致。
kube-proxy 是实现service的通信与负载均衡机制的重要组件，将到service的请求转发到后端的pod上。
Container runtime：容器运行环境，目前Kubernetes支持docker和rkt两种容器。
----
参考链接：
https://blog.csdn.net/weixin_38645718/article/details/85931795
https://www.cnblogs.com/linuxk/p/10291178.html
官方推荐组件flannel，由它统一分配pod的ip
会在网卡上创建一个虚拟网卡flannel0，桥接
首先k8s里面容器是存在于pod里面的，所以容器之间通讯，一般分为三种类型：
1. pod内部容器之间
这种情况下容器通讯比较简单，因为k8s pod内部容器是共享网络空间的，所以容器直接可以使用localhost访问其他容器。
k8s在启动容器的时候会先启动一个pause容器，这个容器就是实现这个功能的。
2. pod 与 pod 之间
这种类型又可以分为两种情况：
1) 两个pod在一台主机上面
针对第一种情况，就比较简单了，就是docker默认的docker网桥互连容器。
2) 两个pod分布在不同主机之上
第二种情况需要更为复杂的网络模型了，k8s官方推荐的是使用flannel组建一个大二层扁平网络，pod的ip分配由flannel统一分配，通讯过程也是走flannel的网桥。
每个node上面都会创建一个flannel0虚拟网卡，用于跨node之间通讯。所以也可以直接使用pod id进行通讯。
**跨节点通讯时，发送端数据会从docker0路由到flannel0虚拟网卡，接收端数据会从flannel0路由到docker0，这是因为flannel会添加一个路由**
3. pod 访问service服务
这里涉及到k8s里面一个重要的概念service。它是一个服务的抽象，通过label（k8s会根据service和pod直接的关系创建endpoint，可以通过kubectl get ep查看）关联到后端的pod容器。
Service分配的ip叫cluster ip是一个虚拟ip（相对固定，除非删除service），这个ip只能在k8s集群内部使用，如果service需要对外提供，只能使用Nodeport方式映射到主机上，使用主机的ip和端口对外提供服务。（另外还可以使用LoadBalance方式，但这种方式是在gce这样的云环境里面使用的 ）。
节点上面有个kube-proxy进程，这个进程从master apiserver获取信息，感知service和endpoint的创建，然后做两个事：
1. 为每个service 在集群中每个节点上面创建一个随机端口，任何该端口上面的连接会代理到相应的pod
2. 集群中每个节点安装iptables规则，用于clusterip + port路由到上一步定义的随机端口上面，所以集群中每个node上面都有service的转发规则：
----
参考链接：
https://www.cnblogs.com/linyouyi/p/11557771.html
https://blog.csdn.net/nangonghen/article/details/102024843
https://blog.csdn.net/weixin_29115985/article/details/78963125
无状态服务
1. 是指该服务运行的实例不会在本地存储需要持久化的数据，并且多个实例对于同一个请求响应的结果是完全一致的。
2. 多个实例可以共享相同的持久化数据。例如：nginx实例，tomcat实例等
3. 相关的k8s资源有：ReplicaSet、ReplicationController、Deployment等，由于是无状态服务，所以这些控制器创建的pod序号都是随机值。并且在缩容的时候并不会明确缩容某一个pod，而是随机的，因为所有实例得到的返回值都是一样，所以缩容任何一个pod都可以。
有状态服务
1. 有状态服务可以说是 需要数据存储功能的服务、或者指多线程类型的服务，队列等。（mysql数据库、kafka、zookeeper等）
2. 每个实例都需要有自己独立的持久化存储，并且在k8s中是通过申明模板来进行定义。持久卷申明模板在创建pod之前创建，绑定到pod中，模板可以定义多个。
参考链接：
https://www.jianshu.com/p/dd47a3cde390
cgi协议。
简单的用户请求流程：
用户访问域名->域名进行DNS解析->请求到对应IP服务器和端口->nginx监听到对应端口的请求->nginx对url进行location匹配->执行匹配location下的规则->nginx转发请求给php->php-fpm的master进程监听到nginx请求->master进程将请求分配给其中一个闲置的worker进程->worker进程执行请求->worker进程返回执行结果给nginx->nginx返回结果给用户
参考链接：
https://blog.csdn.net/u010433704/article/details/93050655
https://segmentfault.com/a/1190000018265488
MySQL主从复制涉及到三个线程。主服务器(I/O dump thread)，从服务器有(I/O thread和SQL thread)。
主库把接收的SQL请求记录到自己binlog日志中，从库的I/O thread去请求主库的binlog日志，并将binlog日志写到中继日志(relay log)中，然后SQL线程负责读取relay log中的内容，最终保证主从数据的一致性。
主库通过I/O dump thread给从库I/O thread传送binlog日志。
相关参考：
https://www.cnblogs.com/fengff/p/11011702.html
1.1 定位高负载进程
1.2 定位具体的异常业务
1.3 定位异常线程及具体代码行
相关参考：
https://www.cnblogs.com/linuxprobe-sarah/p/10013150.html
如果不是服务器性能问题，就需要排查程序方面。
1.日志追踪。
2.pstack跟踪进程栈。方便排查进程问题，比如发现一个服务一直处于work状态(如假死/死循环/死锁)，使用这个命令能定位问题所在。
参考链接：
https://www.cnblogs.com/kongzhongqijing/articles/7685699.html
TCP的优点：可靠，稳定。TCP的可靠体现在TCP在传递数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制，在数据传完后，还会断开连接用来节约系统资源。
TCP的缺点：慢，效率低，占用系统资源高，易被攻击TCP在传递数据之前，要先建连接，这会消耗时间，而且在数据传递时，确认机制、重传机制、拥塞控制机制等都会消耗大量的时间，而且要在每台设备上维护所有的传输连接，事实上，每个连接都会占用系统的CPU、内存等硬件资源。而且，因为TCP有确认机制、三次握手机制，这些也导致TCP容易被人利用，实现DOS、DDOS、CC等攻击。
UDP的优点：快，比TCP稍安全UDP没有TCP的握手、确认、窗口、重传、拥塞控制等机制，UDP是一个无状态的传输协议，所以它在传递数据时非常快。没有TCP的这些机制，UDP较TCP被攻击者利用的漏洞就要少一些。但UDP也是无法避免攻击的，比如：UDP Flood攻击……
UDP的缺点：不可靠，不稳定。因为UDP没有TCP那些可靠的机制，在数据传递时，如果网络质量不好，就会很容易丢包。基于上面的优缺点，那么：什么时候应该使用TCP：当对网络通讯质量有要求的时候，比如：整个数据要准确无误的传递给对方，这往往用于一些要求可靠的应用，比如HTTP、HTTPS、FTP等传输文件的协议，POP、SMTP等邮件传输的协议。在日常生活中，常见使用TCP协议的应用如下：浏览器，用的HTTP FlashFXP，用的FTP Outlook，用的POP、SMTP Putty，用的Telnet、SSH QQ文件传输………… 什么时候应该使用UDP：当对网络通讯质量要求不高的时候，要求网络通讯速度能尽量的快，这时就可以使用UDP。比如，日常生活中，常见使用UDP协议的应用如下： QQ语音 QQ视频 TFTP ……
有些应用场景对可靠性要求不高会用到UPD，比如长视频，要求速率
相关参考：
https://www.cnblogs.com/williamjie/p/9390164.html
502 Bad Gateway：作为网关或者代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应。
504 Gateway Timeout：作为网关或者代理工作的服务器尝试执行请求时，未能及时从上游服务器（URI标识出的服务器，例如HTTP、FTP、LDAP）或者辅助服务器（例如DNS）收到响应。
500 Internal Server Error：服务器遭遇异常阻止了当前请求的执行，一般为程序错误。
403 Forbidden：服务器接受请求，但是被拒绝处理。
404 Not Found：服务器未找到任何匹配Request-URI的资源。
标签：中继日志 zook 键值 请求响应 队列 iptable jin k8s point
原文地址：https://www.cnblogs.com/jiba/p/12578637.html
