Kubernetes Sidecar设计模式
比如使用Sidebar容器处理日志，可以让应用不用关心日志发送到哪里，仅输出到stdout就可以。容器的输出会被同一Pod中的SideCar辅助容器截取，并发送到日志聚合平台如（ElasticSearch）。
这使得运行在Kubernetes中的微服务可以实现分布式链路跟踪（Distribute Tracing）等功能。

Operator模式
kubernetes管理无状态应用使用的就是一个简单的Operator模式。核心就是声明式表示对象预期值，控制器会根据预期值不断调整实际值使得预期值等于实际值。
处理有状态应用则比较复杂，需要自定义控制器来满足复杂的业务需求。

=====================================================================================================================================================

2、k8s 的 pause 容器有什么用。是否可以去掉。
每个Pod里运行着一个特殊的被称之为Pause的容器，其他容器则为业务容器，这些业务容器共享Pause容器的网络栈和Volume挂载卷，因此他们之间通信和数据交换更为高效，在设计时
我们可以充分利用这一特性将一组密切相关的服务进程放入同一个Pod中。同一个Pod里的容器之间仅需通过localhost就能互相通信。
kubernetes中的pause容器主要为每个业务容器提供以下功能：
PID命名空间：Pod中的不同应用程序可以看到其他应用程序的进程ID。
网络命名空间：Pod中的多个容器能够访问同一个IP和端口范围。
IPC命名空间：Pod中的多个容器能够使用SystemV IPC或POSIX消息队列进行通信。
UTS命名空间：Pod中的多个容器共享一个主机名；Volumes（共享存储卷）：
Pod中的各个容器可以访问在Pod级别定义的Volumes。

=====================================================================================================================================================

3、Kubernetes Pod 是什么?
Pod是Kubernetes中最小的可部署和管理单元。一个Pod可以包含多个容器，这些容器往往是紧耦合的。一个Pod中的多个容器代表需要运行在同一个服务器上的多个进程。
Pod就类似于一台服务器。比如，通过localhost每个容器可以访问它所在Pod中的其它容器。

为什么Kubernetes将Pod而不是单个容器作为最小可部署单元呢？
尽管直接部署单个容器也许会更容易，但增加Pod这个新的抽象层会带来新的好处。容器是一个真实存在的实体，它代表一个具体的东西。这个“东西”可以是一个Docker容器，
也可以是一个rkt容器。每种“东西”都有不同的用途。为了管理容器，Kubernetes需要更多的信息，比如重启策略（restart policy），它定义了当容器终止了时怎样重启容器；
还有活性检测（liveness probe），它定义了如何从应用视角去检测容器中的进程是否活着，比如Web服务器进程是否能响应HTTP请求。

=====================================================================================================================================================

4、一个经典 pod 的完整生命周期。
Pending：Pod 定义正确，提交到 Master，但其包含的容器镜像还未完全创建。通常处在 Master 对 Pod 的调度过程中。
ContainerCreating：Pod 的调度完成，被分配到指定 Node 上。处于容器创建的过程中。通常是在拉取镜像的过程中。
Running：Pod 包含的所有容器都已经成功创建，并且成功运行起来。
Successed：Pod 中所有容器都成功结束，且不会被重启。这是 Pod 的一种最终状态。
Failed：Pod 中所有容器都结束，但至少一个容器以失败状态结束。这也是 Pod 的一种最终状态。
Unknown：由于一些原因，Pod 的状态无法获取，通常是与 Pod 通信时出错导致的。

=====================================================================================================================================================

5、k8s 的 service 和 ep 是如何关联和相互影响的。
api-server创建service对象，与service绑定的pod地址：称之为endpoints
kube-proxy监控service后端endpoint的动态变化，并且维护service和endpoint的映射关系

=====================================================================================================================================================

6、详述kube-proxy原理，一个请求是如何经过层层转发落到某个pod上的整个过程。请求可能来自pod也可能来自外部。
kube-proxy为集群提供service功能，相同功能的pods对外抽象为service，service可以实现反向代理和服务发现。可以分为iptables、ipvs和userspace模式。

具体有iptables实现在反向代理方面，kube-proxy默认使用rr算法实现客户端流量分发到后端的pod

=====================================================================================================================================================
7、如何在 Kubernetes 中实现负载均衡？
Service会自带负载均衡的endpoint，ipvs或者iptables，ipvs的话性能好一点，iptables是概率的方式，不是很好用，

=====================================================================================================================================================

8、在生产中，你如何实现 Kubernetes 自动化？

使用jenkins开发流水线或者使用shell脚本

=====================================================================================================================================================

9、你如何扩展 Kubernetes 集群？

看安装方式如果是adm直接生成token以及就可以让node加入集群中，master的话需要把配置全部scp至新的node节点,然后起来kubelet和proxy以及网络插件以后master授权

=====================================================================================================================================================
10、你能解释 Deployment、ReplicaSets、StatefulSets、Pod、CronJob 的不同用途吗？
Cronjob跟linux的crtab是类似的可以做批处理
Deployment具有上线部署、副本设定、滚动升级、回滚等功能
RS的话他的功能被deployment包含了创建deployment控制器的时候他默认会自动来一个rs
Statefulset有状态的控制器一般是做有状态的应用部署比如redis以及mysql或者zk这种的

Pod是集群的最小单元，

=====================================================================================================================================================
11、Kubernetes 如何处理持久性？

可以使用pvc以及pv做持久化数据，可以自动也可以手动

就不用让pod做ssl会话了，service的Nodeport是不具备这个功能的，而且ingress可以加一些比如nginx他自身的参数，我们也知道nginx还是很强大的

Prometheus的自动发现功能还是很好用的，Secret的话一般是存储ssl证书的配置或者是存docker的镜像仓库凭证

=====================================================================================================================================================
14、Pod 亲和性作用是什么？

可以根据pod亲和来让pod指定运行在那个node节点上比如pod和pod亲和比如pod和node亲和

Init是初始化容器，为这个初始化一个环境，没有很用过这个

=====================================================================================================================================================

17、kubernetes包含几个组件。各个组件的功能是什么。组件之间是如何交互的。
kube-apiserver Kubernetes API，集群的统一入口，各组件协调者，以RESTful API提供接口服务，所有对象资源的增删改查和监听操作都交给APIServer处理
后再提交给Etcd存储。

kube-controller-manager 处理集群中常规后台任务，一个资源对应一个控制器，而ControllerManager 就是负责管理这些控制器的。

kube-scheduler 根据调度算法为新创建的Pod选择一个Node节点，可以任意部署,可以部署在同一个节点上,也可以部署在不同的节点上。

etcd 分布式键值存储系统。用于保存集群状态数据，比如Pod、Service等对象信息。

kubelet kubelet是Master在Node节点上的Agent，管理本机运行容器的生命周期，比如创建容器、Pod挂载数据卷、下载secret、获取容器和节点状态等工作。kubelet
将每个Pod转换成一组容器。这是一个代理服务，它在每个节点上运行，并使从服务器与主服务器通信。因此，Kubelet处理PodSpec中提供给它的容器的描述，并确保
PodSpec中描述的容器运行正常。

kube-proxy 在Node节点上实现Pod网络代理，维护网络规则和四层负载均衡工作。 docker或rocket 容器引擎，运行容器。

docker runtime

=====================================================================================================================================================

19.k8s中的pod内几个容器之间的关系是什么。

共享网络命名空间

=====================================================================================================================================================
20、rc/rs功能是怎么实现的。详述从API接收到-一个创建rc/rs的请求,到最终在节点上创建pod的全过程,尽可能详细。另外,当-个pod失效时，kubernetes是如何
发现并重启另一个pod的?
用户创建的请求跟api交互在认证授权通过之后，api会把数据写入etcd并联系scheduler，给他根据调度算法，查看每个节点状态确定往哪一个节点调度，

然后api与该节点的kubelet交互并把相关的数据写入etcd，kubelet调用底层的docker来根据配置清单创建容器

=====================================================================================================================================================

22、k8s日志收集
日志采集的两种模式
容器日志采集模式现在流行的方式有 SideCar模式和 Node模式，SideCar模式会占用大量资源，而Node模式需要智能的 logging agent 配合，而 log-pilot
就是那个智能的agent
log-pilot+elsearch+kibana

1、k8s使用daemonset类型的副本集，使每个节点运行一个 log-pilot 来收集日志，该日志会含有 k8s_container_name、k8s_pod、k8s_node_name、
k8s_pod_namespace 等打标数据，输出到相应的 logstash 来做索引
2、运行docker微服务的主机上运行一个 log-pilot 来收集日志，该日志会含有 docker_container、topic、index 等打标数据，输出到相应的 logstash 来做索引
3、普通非容器程序的日志可以采用 filebeat 收集，日志中可以自定义标签和字段，输出到对应的 logstash 来做索引

1、k8s日志收集的三种方式（推荐使用第一种）
1.1、在Node节点上部署loging agent(Daemonset)，将日志文件转发到后端存贮起来,kubectl logs 可以使用
1.2、启动一个sidecar辅助容器，将日志文件重新输入到sidecar容器的stdout和sdterr上，不过这种方式默认kubectl logs 不可以使用，而且保存两份日志文件非常消耗硬盘资源
1.3、通过一个sidecar辅助容器，直接把容器日志发送到远端的存储，部署简单，而且对主机访问友好，不过sidecar容易非常消耗资源，甚至会拖垮业务容器，而kubectl logs 不可以使用

2、docker日志量大的时候，这么去收集？
日志量大的时候，直接输出到容器的stdout、stderr，容易吧日志的配额用满，最终导致日志被吞掉，解决办法是增加日志配额，一个是容器加上存储，把日志放到存储上。

=====================================================================================================================================================

23、基于k8s的CI/CD

=====================================================================================================================================================

24、ingress-nginx
ingress暴露从集群外到集群内服务的HTTP或HTTPS路由。定义在ingress资源上的规则控制流量的路由。

必须具有 Ingress 控制器才能满足 Ingress 的要求。仅创建 Ingress 资源本身没有任何效果。
你可能需要部署 Ingress 控制器，例如 ingress-nginx。你可以从许多 Ingress 控制器中进行选择。

一个ingress可以配置用于提供外部可访问的服务url、负载均衡流量、SSL终端和提供虚拟主机名配置。
ingress controller负责实现通常使用负载均衡器(loadbalancer)入口（ingress）。但是它也可以配置你的边缘路由器或额外的前端来帮助处理流量。
ingress不暴露任何端口或协议。将HTTP和HTTPS之外的服务公开到因特网通常使用类型是NodePort或loadbalance的service。

Ingress 配置为服务提供外部可访问的 URL、负载均衡流量、终止 SSL/TLS，以及提供基于名称的虚拟主机等能力。
Ingress-controller 控制器通常负责通过负载均衡器来实现Ingress，尽管它也可以配置边缘路由器或其他前端来帮助处理流量。
Ingress 不会公开任意端口或协议。将HTTP和HTTPS以外的服务公开到Internet时，通常使用Service.Type=NodePort或Service.Type=LoadBalancer类型的服务。

Ingress 规则
1、可选的 host
2、路径列表 paths
路径类型：
2.1.ImplementationSpecific：对于这种路径类型，匹配方法取决于 IngressClass
2.2.Exact：精确匹配 URL 路径，且区分大小写
2.3.Prefix：基于以 / 分隔的 URL 路径前缀匹配。匹配区分大小写，并且对路径中的元素逐个完成
3、backend服务

=====================================================================================================================================================

25、Kubernetes之网络策略(Network Policy)
如果希望在 IP 地址或端口层面（OSI 第 3 层或第 4 层）控制网络流量，则你可以考虑为集群中特定应用使用 Kubernetes 网络策略（NetworkPolicy）。
NetworkPolicy 是一种以应用为中心的结构，允许你设置如何允许 Pod 与网络上的各类网络“实体” （我们这里使用实体以避免过度使用诸如“端点”和“服务”这类常用术语，
这些术语在 Kubernetes 中有特定含义）通信。

默认情况下，Pod 是非隔离的，它们接受任何来源的流量。
Pod 在被某 NetworkPolicy 选中时进入被隔离状态。一旦名字空间中有 NetworkPolicy 选择了特定的 Pod，该 Pod 会拒绝该 NetworkPolicy 所不允许的连接。

必需字段：
与所有其他的 Kubernetes 配置一样，NetworkPolicy 需要 apiVersion、 kind 和 metadata 字段。

spec：
NetworkPolicy 规约中包含了在一个名字空间中定义特定网络策略所需的所有信息。
podSelector：每个 NetworkPolicy 都包括一个 podSelector，它对该策略所适用的一组 Pod 进行选择。示例中的策略选择带有 “role=db” 标签的 Pod。
空的 podSelector 选择名字空间下的所有 Pod。
policyTypes: 每个 NetworkPolicy 都包含一个 policyTypes 列表，其中包含 Ingress 或 Egress 或两者兼具。policyTypes 字段表示给定的策略是应用于
进入所选 Pod 的入站流量还是来自所选 Pod 的出站流量，或两者兼有。如果 NetworkPolicy 未指定 policyTypes 则默认情况下始终设置 Ingress；如果
NetworkPolicy 有任何出口规则的话则设置 Egress。

ingress:
每个 NetworkPolicy 可包含一个 ingress 规则的白名单列表。每个规则都允许同时匹配 from 和 ports 部分的流量。示例策略中包含一条简单的规则：
它匹配某个特定端口，来自三个来源中的一个，第一个通过 ipBlock 指定，第二个通过 namespaceSelector 指定，第三个通过 podSelector 指定。

egress:
每个 NetworkPolicy 可包含一个 egress 规则的白名单列表。每个规则都允许匹配 to 和 port 部分的流量。该示例策略包含一条规则，该规则将指定端口上

的流量匹配到 10.0.0.0/24 中的任何目的地。

=====================================================================================================================================================
26、k8s监控prometheus——grafa
pull抓取metrice监控指标数据(Daemonset 部署Node Exporter工具)，保存到TSDB（influxDB或者OpenTSDB）
pushgateWay允许被监控对象已push的方式向prometheus推送监控指标数据
altermanager可以根据metrice信息灵活的设置短信，邮件告警
grafana对外暴露和配置展现监控数据的可视化界面

matric数据包含
1、宿主机的监控数据
2、k8s组件的监控数据
3、

promotheus获取监控数据的有pull和push两种模式
1、pull拉取的数据时效性比push客户端推送差，采集到的监控数据没有及时得到更新，容易造成监控数据的丢失
2、push模式增加服务实现的复杂度，不支持metrics数据采集自定义，比如高峰时间减少数据采集。

=====================================================================================================================================================

27、dockerfile的基本指令
from 制定基础镜像
run 执行的指令
workdir制定了当前目录
cmd 指定容器的进程，这个是容器制作时运行的
entrypoint 与cmd相同，这个hi容器运行时运行的
env 容器的环境变量

add 吧外部的资源添加到容器镜像，类似copy

=====================================================================================================================================================
28、docker基本知识
docker容器只是一个特殊进程，通过namespace 资源隔离，cgroup资源限定，rootfs操作系统包含的文件，配置和目录,并不包含内核，所以同一台服务器上的所有容器上面都是共享宿
主机的内核，自己本身没有内核
namespace;
IPC PID MNT user UTS

docker在镜像设计，引入层的概念，这个层就是用户dockerfile文件的每一行指令，也是每一个增量的rootfs文件，rootfs包含三层
1、只读层
2、init层 /etc/hosts /etc/resolv.conf
3、可读写层

容器最主要的两部分
1、静态容器镜像images
2、动态容器运行时runtimes

容器编排的三种工具
1、单机docker-compose，部署harbor使用，而且在测试环境里也使用nginx——tomcat——mysql的时候使用过，
2、docker公司自己的swarm，没有接触，一般学主流
3、谷歌公司的k8s，是一个管理和编排容器的工具，而docker只是它最底层的一个容器运行时的实现

=====================================================================================================================================================

29、k8s的架构
master
kube-apiserver 入口
kube-scheduler 负责调度
kube-controller 负责容器编排
etcd

node
组件包括 kubelet、容器运行时以及 kube-proxy。

kubelet 负责通过CRI接口同容器运行时打交道，另外一个重要的功能是网络插件CNI和存储插件CSI为容器配置网络和持久化存储
同一个po里面的容器共享一个网络命名空间，mount挂载数据卷，从而达到了高效交换信息的目的。

=====================================================================================================================================================

30、网络概念
1、Linux网络名词解释：
1.1、网络的命名空间：
Linux在网络栈中引入网络命名空间，将独立的网络协议栈隔离到不同的命令空间中，彼此间无法通信；docker利用这一特性，实现不容器间的网络隔离。

1.2、Veth设备对：
Veth设备对的引入是为了实现在不同网络命名空间的通信。

1.3、Iptables/Netfilter：
Netfilter负责在内核中执行各种挂接的规则(过滤、修改、丢弃等)，运行在内核模式中；
Iptables模式是在用户模式下运行的进程，负责协助维护内核中Netfilter的各种规则表；
通过二者的配合来实现整个Linux网络协议栈中灵活的数据包处理机制。

1.4、网桥：
网桥是一个二层网络设备,通过网桥可以将linux支持的不同的端口连接起来,并实现类似交换机那样的多对多的通信。

1.5、路由：
Linux系统包含一个完整的路由功能，当IP层在处理数据发送或转发的时候，会使用路由表来决定发往哪里
在Kubernetes网络中存在两种IP（Pod IP和Service Cluster IP），Pod IP地址是实际存在于某个网卡(可以是虚拟设备)上的，Service Cluster IP它是一个虚拟IP
是由kube-proxy使用Iptables/ipvs规则重新定向到其本地端口，再均衡到后端Pod的。

2、kubernetes网络模型
2.1. 基础原则
每个Pod都拥有一个独立的IP地址，而且假定所有Pod都在一个可以直接连通的、扁平的网络空间中，不管是否运行在同一Node上都可以通过Pod的IP来访问。
k8s中Pod的IP是最小粒度IP。同一个Pod内所有的容器共享一个网络堆栈，该模型称为IP-per-Pod模型。
Pod由docker0实际分配的IP，Pod内部看到的IP地址和端口与外部保持一致。同一个Pod内的不同容器共享网络，可以通过localhost来访问对方的端口，类似同一个VM内的不同进程。
IP-per-Pod模型从端口分配、域名解析、服务发现、负载均衡、应用配置等角度看，Pod可以看作是一台独立的VM或物理机。

2.2. k8s对集群的网络要求
所有容器都可以不用NAT的方式同别的容器通信。
所有节点都可以在不同NAT的方式下同所有容器通信，反之亦然。
容器的地址和别人看到的地址是同一个地址。

学习参考文档：https://www.cnblogs.com/centos-python/articles/10869210.html

=====================================================================================================================================================
31、k8s之网络插件flannel及基于Calico的网络策略
1.k8s网络通信
1.1.容器间通信:
同一个pod内的多个容器间的通信,通过lo即可实现;
1.2.pod之间的通信:
pod ip <---> pod ip,pod和pod之间不经过任何转换即可通信;
1.3.pod和service通信:
pod ip <----> cluster ip(即service ip)<---->pod ip,它们通过iptables或ipvs实现通信,ipvs取代不了iptables,因为ipvs只能做负载均衡,而做不了nat转换;
.Service与集群外部客户端的通信.

2、k8s靠CNI接口接入其他插件来实现网络通讯.目前比较流行的插件有flannet、callco、canel.这些插件使用的解决方案有如下方式:
2.1.虚拟网桥:虚拟网卡,多个容器共用一个虚拟网卡进行通信;
2.2.多路复用:MacVLAN,多个容器共用一个物理网卡进行通信;
2.3.硬件交换:SR-LOV,一个物理网卡可以虚拟出多个接口,这个性能最好.

3、CNI插件存放位置 cat /etc/cni/net.d/10-flannel.conflist
3.1、flanel只支持网络通讯,但是不支持网络策略;
3.2、callco网络通讯和网络策略都支持;canel:flanel+callco
3.3、可以部署flanel提供网络通讯,再部署一个callco只提供网络策略,而不用canel.
3.4、mtu:是指一种通信协议的某一层上面所能通过的最大数据包大小.

学习参考地址：https://www.cnblogs.com/fawaikuangtu123/p/11296382.html

=====================================================================================================================================================
32、K8s Service原理
1、Service的工作方式有三种:
1.1、Userspace
Client Pod要访问Server Pod时,它先将请求发给本机内核空间中的service规则，由它再将请求,转给监听在指定套接字上的kube-proxy，kube-proxy处理完请求，
并分发请求到指定Server Pod后,再将请求递交给内核空间中的service,由service将请求转给指定的Server Pod。
由于其需要来回在用户空间和内核空间交互通信，因此效率很差，接着就有了第二种方式.

1.2、iptables
　此工作方式是直接由内核中的iptables规则，接受Client Pod的请求，并处理完成后，直接转发给指定ServerPod.

1.3、ipvs
　它是直接有内核中的ipvs规则来接受Client Pod请求，并处理该请求,再有内核封包后，直接发给指定的Server Pod。

以上不论哪种，kube-proxy都通过watch的方式监控着kube-APIServer写入etcd中关于Pod的最新状态信息,它一旦检查到一个Pod资源被删除了或新建，它将立即将这些变化，
反应再iptables 或 ipvs规则中，以便iptables和ipvs在调度Clinet Pod请求到Server Pod时，不会出现Server Pod不存在的情况。自k8s1.1以后,service默认使用ipvs规则，
若ipvs没有被激活，则降级使用iptables规则. 但在1.1以前，service使用的模式默认为userspace.

2、service的类型有四种:
2.1、ExternalName: 用于将集群外部的服务引入到集群内部，在集群内部可直接访问来获取服务。
　Pod—->SVC[externalName]——[SNAT]—–>宿主机的物理网卡——>物理网关—–>Internat上提供服务的服务器.
　　　注意: Service是externelName类型时, externalName必须是域名,而且此域名必须能被CoreDNS或CoreDNS能通过互联网上的根DNS解析出A记录.

2.2、ClusterIP：用于为集群内Pod访问时,提供的固定访问地址,默认是自动分配地址,可使用ClusterIP关键字指定固定IP。
2.3、NodePort: 用于为集群外部访问Service后面Pod提供访问接入端口.
　　　　这种类型的service工作流程为:Client—–>NodeIP:NodePort—–>ClusterIP:ServicePort—–>PodIP:ContainerPort
LoadBalancer: 用于当K8s运行在一个云环境内时,若该云环境支持LBaaS,则此类型可自动触发创建一个软件负载均衡器用于对Service做负载均衡调度.
　　　　因为外部所有Client都访问一个NodeIP,该节点的压力将会很大, 而LoadBalancer则可解决这个问题。
　　　　而且它还直接动态监测后端Node是否被移除或新增了，然后动态更新调度的节点数。

3、什么是Headless Service？
所谓headless service指: 没有ClusterIP的service, 它仅有一个service name.这个服务名解析得到的不是service的集群IP，而是Pod的IP,当其它人访问该service时，
将直接获得Pod的IP,进行直接访问。Headless Service类似于“普通”服务，但没有群集IP。此服务使您可以直接访问pod，而无需通过代理访问它。

学习参考文档：https://www.cnblogs.com/wn1m/p/11288131.html

=====================================================================================================================================================

感谢观哥