394 lines
27 KiB
Markdown
394 lines
27 KiB
Markdown
# docker网络模式
|
||
Docker使用了Linux的Namespaces技术来进行资源隔离，如PID Namespace隔离进程，Mount Namespace隔离文件系统，Network Namespace隔离网络等。一个Network Namespace提供了一份独立的网络环境，包括网卡、路由、Iptable规则等都与其他的Network Namespace隔离。一个Docker容器一般会分配一个独立的Network Namespace
|
||
### host模式，使用--net=host指定
|
||
容器将不会获得一个独立的Network Namespace，而是和宿主机共用一个Network Namespace。容器将不会虚拟出自己的网卡，配置自己的IP等，而是使用宿主机的IP和端口.文件系统等隔离，但网络不隔离。
|
||
|
||
### container模式，使用--net=container:NAME_or_ID指定
|
||
新创建的容器和已经存在的一个容器共享一个Network Namespace，而不是和宿主机共享。新创建的容器不会创建自己的网卡，配置自己的IP，而是和一个指定的容器共享IP、端口范围等。同样，两个容器除了网络方面，其他的如文件系统、进程列表等还是隔离的。两个容器的进程可以通过lo网卡设备通信。
|
||
|
||
### none模式，使用--net=none指定
|
||
Docker容器拥有自己的Network Namespace，但是，并不为Docker容器进行任何网络配置。也就是说，这个Docker容器没有网卡、IP、路由等信息。需要我们自己为Docker容器添加网卡、配置IP等
|
||
|
||
### bridge模式，使用--net=bridge指定。默认模式
|
||
为每一个容器分配、设置IP等，并将容器连接到一个docker0虚拟网桥，通过docker0网桥以及Iptables nat表配置与宿主机通信
|
||
|
||
|
||
# docker swarm与k8s的区别
|
||
swarm是docker公司开发的集群编排工具，k8s是google开发的运用十年的borg的开源版本
|
||
1、docker swarm架构简单，部署成本低，但是集群健壮性比较差，k8s部署比较复杂，健壮性比较强
|
||
2、swarm与k8s有很高的扩展性，扩展速度也很快。但k8s扩展速度很快
|
||
3、swarm可以在不同容器中自动实现负载均衡，k8s需要手动在不同pod的不同容器间配置负载
|
||
4、都可以滚动更新，但是swarm不能自动回滚
|
||
5、k8s数据卷只能同一个pod中不同容器共享，但是swarm可以与其它容器共享
|
||
|
||
|
||
# 如何在 Kubernetes 中实现负载均衡？
|
||
kube-proxy实现4层负载均衡（ipvs哟很多调度算法），负责把service请求转发到后台的pod
|
||
ingress实现7层负载均衡，负责把内部服务暴露到外网访问
|
||
|
||
# 在生产中，你如何实现 Kubernetes 自动化？
|
||
### 日志
|
||
使用efk、promethuse等日志收集与监控套件，过滤与标记异常
|
||
### 自我修复
|
||
k8s定期检测pod与容器的健康状况，立即采取措施处理，pod状态（podstatus和containerstatus）。容器探针（readinessProbe和livenessProbe），readiness探针很重要，容器可能是运行状态，但是未就绪，并不传送任何流量
|
||
### 弹性测试
|
||
需要使用贪心测试工具kube-monkey等（**不懂**）
|
||
### 例行审计
|
||
需要工具
|
||
### 自动扩展
|
||
扩展pod，扩展节点（node）
|
||
扩展pod主要看heapster的度量标准执行，确认是否需要创建新pod。hpa（horizontal pod autoscaler）自动扩展
|
||
扩展node需要iaas支持
|
||
|
||
### 资源配额
|
||
限制k8s中的namespace，确保某个应用程序不会占用所有资源
|
||
|
||
### 容器资源约束
|
||
限制容器的内存与cpu等
|
||
|
||
|
||
# 你如何扩展 Kubernetes 集群？
|
||
|
||
---
|
||
|
||
# 你能解释 Deployment、ReplicaSet、DaemonSet、StatefulSet、Pod、Job、CronJob 的不同用途吗？
|
||
Deployment、ReplicaSet等对应的服务是service，而statefulSet使用的是headless service。无头服务（headless serviece）与service不同的地方是无头服务没有设置clusterIP，访问它的时候，直接访问的是无头服务后面对应的pod
|
||
### Deployment
|
||
Deployment为Pod和Replica Set提供声明式更新。
|
||
只需要在 Deployment 中描述想要的目标状态是什么，Deployment controller 就会帮您将 Pod 和ReplicaSet 的实际状态改变到您的目标状态。您可以定义一个全新的 Deployment 来创建 ReplicaSet 或者删除已有的 Deployment 并创建一个新的来替换
|
||
|
||
Deployment实际上是通过ReplicaSet实现滚动更新
|
||
Deployment控制ReplicaSet，ReplicaSet控制Pod
|
||
|
||
### ReplicaSet
|
||
ReplicaSet是为了替换ReplicationController，rc只支持灯饰的selector，如version=v1等，但rs支持集合形式的selector，如vsersion in (v1,v2),或version not in (v1,v2)
|
||
|
||
### DaemonSet
|
||
DaemonSet 确保全部（或者一些）Node 上运行一个 Pod 的副本。当有 Node 加入集群时，也会为他们新增一个 Pod 。当有 Node 从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod
|
||
典型用途：
|
||
运行集群存储 daemon，例如在每个 Node 上运行 glusterd、ceph。
|
||
日志收集，比如fluentd，logstash等
|
||
系统监控，比如Prometheus Node Exporter，collectd，New Relic agent，Ganglia gmond等
|
||
系统程序，比如kube-proxy, kube-dns, glusterd, ceph等
|
||
|
||
### StatefulSet
|
||
面向有状态的服务，管理的pod有固定的名称、起停顺序等，还要保持数据一致性，需要用到持久化存储（PersistentVolumeClaim）
|
||
|
||
### Pod
|
||
pod是k8s集群管理中的最小单位.是一个或多个容器的集合。同一个pod中的容器共享网络，存储、命名空间等
|
||
|
||
### Job
|
||
用于批处理一次性任务，并保证一个或多个任务成功结束
|
||
|
||
### CronJob
|
||
在Job基础上，加上时间调度，执行周期性任务
|
||
|
||
# Kubernetes 如何处理持久性？
|
||
pv和pvc。pv是集群中的一块存储空间，由集群管理员或者存储类（Storage Class）管理，pv是一个资源对象
|
||
pvc（PersistentVolueClaim）代表应用使用存储的请求，pvc通过与pv绑定使用。满足的条件是pv与pvc spec字段匹配，例如pvc申请的字段必须要小于等于pv大小，pv与pvc的StorageClassName必须一样
|
||
# service和 ingress 的作用是什么？
|
||
负载均衡，提供k8s集群外部访问的入口。ingres接收到来自外部的请求，会根据规则转发到service，service后有多个pod，转发一个pod中，这个pod处理请求
|
||
Service是通过规则定义出由多个Pod对象组合而成的逻辑组合以及访问这组Pod的策略。Service资源为此类Pod对象提供了一个固定、统一的访问入口及负载均衡的能力，并支持借助于新一代DNS系统的服务发现功能，解决客户端发现并访问容器化应用的难题
|
||
service并不是直接与pod连接，service与pod之间还有一个中间层-endpoints资源第项，它是由ip与端口组成的列表，一般情况下，service创建以后，关联的endpoints也会自动创建
|
||
|
||
# 你何时会使用像 ConfigMap 或 secret 这样的东西？
|
||
configmap 核心作用是让配置信息和镜像解耦，pod使用configMap中的配置信息，如果后端pod配置文件有变化，只需要修改configMap就好了，pod会动态改变配置信息
|
||
ConfigMap对像是一系列配置的集合，k8s会将这一集合注入到对应的Pod中，并为容器成功启动使用。注入的方式一般有两种，一种是挂载存储卷，一种是传递变量。ConfigMap被引用之前必须存在，属于名称空间级别，不能跨名称空间使用，内容明文显示。ConfigMap内容修改后，对应的pod必须重启或者重新加载配置。
|
||
|
||
secret与configmap类似，存储的信息使用base64编码，一般用于docker-registry（docker仓库使用），tls（证书，比如说https证书）和一般generic
|
||
|
||
# Pod 亲和性作用是什么？
|
||
pod的亲和性主要用来解决pod可以和哪些pod部署在同一个集群里面，即拓扑域（由node组成的集群）里面；而pod的反亲和性是为了解决pod不能和哪些pod部署在一起的问题，二者都是为了解决pod之间部署问题。需要注意的是，Pod 间亲和与反亲和需要大量的处理，这可能会显著减慢大规模集群中的调度，不建议在具有几百个节点的集群中使用，而且Pod 反亲和需要对节点进行一致的标记，即集群中的每个节点必须具有适当的标签能够匹配 topologyKey。如果某些或所有节点缺少指定的 topologyKey 标签，可能会导致意外行为
|
||
Pod亲和性调度需要各相关的Pod对象运行于“同一位置”， 而反亲和性调度则要求它们不能运行于“同一位置” 。同一位置取决于节点的位置拓扑， 拓扑的方式不同
|
||
如果以基于各节点的kubernetes.io/hostname标签作为评判标准，那么很显然，“同一位置” 意味着同一个节点，不同节点即不同的位置， 如图所示
|
||
如果是基于所划分的故障转移域来进行评判，同一位置， 而server2和server3属于另一个意义上的同一位置
|
||
因此，在定义Pod对象的亲和性与反亲和性时，需要借助于标签选择器来选择被依赖的Pod对象，并根据选出的Pod对象所在节点的标签来判定“同一位置”的具体意义
|
||
|
||
# 你能举例说明何时使用 Init Container 么？
|
||
初始化容器，顾名思义容器启动的时候，会先启动可一个或多个容器，如果有多个，那么这几个Init Container按照定义的顺序依次执行，一个执行成功，才能执行下一个，只有所有的Init Container执行完后，主容器才会启动。由于一个Pod里的存储卷是共享的，所以Init Container里产生的数据可以被主容器使用到。
|
||
|
||
Init Container可以在多种K8S资源里被使用到如Deployment、Daemon Set、StatefulSet、Job等，但归根结底都是在Pod启动时，在主容器启动前执行，做初始化工作。
|
||
|
||
Init 容器支持应用容器的全部字段和特性，包括资源限制、数据卷和安全设置。然而，Init 容器不支持 Readiness Probe，因为它们必须在 Pod 就绪之前运行完成；在资源限制、调度方面也会略有不同。
|
||
|
||
|
||
**等待其它模块Ready**：比如有一个应用里面有两个容器化的服务，一个是Web Server，另一个是数据库。其中Web Server需要访问数据库。但是当我们启动这个应用的时候，并不能保证数据库服务先启动起来，所以可能出现在一段时间内Web Server连接数据库错误。为了解决这个问题，我们可以在运行Web Server服务的Pod里使用一个InitContainer，去检查数据库是否准备好，直到数据库可以连接，Init Container才结束退出，然后Web Server容器被启动，发起正式的数据库连接请求。
|
||
**初始化配置**：比如集群里检测所有已经存在的成员节点，为主容器准备好集群的配置信息，这样主容器起来后就能用这个配置信息加入集群；目前在容器化，初始化集群配置文件时经常用到；
|
||
**提供一种阻塞容器启动的方式**：必须在initContainer容器启动成功后，才会运行下一个容器，保证了一组条件运行成功的方式；
|
||
**其它使用场景**：将pod注册到一个中央数据库、下载应用依赖等。
|
||
|
||
# 什么是 sidecar 容器？你能给出一个用例，说明你为什么要使用它么？
|
||
|
||
# 在构建和管理生产集群时遇到的主要问题是什么？
|
||
# 为什么你会建议公司在云中构建自己的 K8S 集群而不是使用托管服务？
|
||
# 什么是 Istio 和 Linkerd？
|
||
Istio和Linkerd都支持以主流的外挂（Sidecar）模式部署。在这种模式下，每个微服务都被分配一个单独的代理。微服务间的通信并不直接进行，而是通过自身的代理转发。代理会将请求路由到目标微服务的代理，该代理再将请求转发到目标微服务。所有这些服务代理构成了数据层。在服务网格的架构下，数据层由控制层（control plane）来进行配置和监控，控制层一般另行独立部署。
|
||
Istio 提供一种简单的方式来为已部署的服务建立网络，该网络具有负载均衡、服务间认证、监控等功能，而不需要对服务的代码做任何改动。
|
||
|
||
# 什么是 Kubernetes Operator？
|
||
operator旨在简化负载的有状态应用管理的框架。是一个用于感知应用状态的控制器，通过扩展k8s api来创建、管理配置应用
|
||
operator通过扩展k8s定义custom controllor，观察情况并根据运行情况自定义任务。管理自定义cr（custom resource）
|
||
Operator是一个感知应用状态的控制器，所以实现一个Operator最关键的就是把管理应用状态的所有操作封装到配置资源和控制器中。通常来说Operator需要包括以下功能：
|
||
|
||
Operator自身以deployment的方式部署
|
||
Operator自动创建一个Third Party Resources资源类型，用户可以用该类型创建应用实例
|
||
Operator应该利用Kubernetes内置的Serivce/ReplicaSet等管理应用
|
||
Operator应该向后兼容，并且在Operator自身退出或删除时不影响应用的状态
|
||
|
||
Operator应该支持应用版本更新
|
||
|
||
Operator应该测试Pod失效、配置错误、网络错误等异常情况
|
||
|
||
# kubernetes包含几个组件。 各个组件的功能是什么。组件之间是如何交互的。
|
||
c/s架构
|
||
### kube-controller-manager
|
||
负责维护集群的状态，比如故障检测、自动扩展、滚动更新等
|
||
|
||
### kube-scheduler
|
||
负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上
|
||
|
||
### etcd
|
||
etcd 是兼具一致性和高可用性的键值数据库，可以作为保存 Kubernetes 所有集群数据的后台数据库。
|
||
存储集群状态等
|
||
|
||
### kube-apiserver
|
||
外部管理k8s集群的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制。通过apiserver完成对k8s集群管理交互，如pod的增删改查等
|
||
|
||
### kubectl
|
||
k8s集群的命令行工具，使用该工具与apiserver交互，完成对k8s的管理
|
||
|
||
### kubelet
|
||
负责维护容器的生命周期，同时也负责Volume（CVI）和网络（CNI）的管理
|
||
|
||
### kube-proxy
|
||
负责为Service提供cluster内部的服务发现和负载均衡
|
||
|
||
### ingress-controller
|
||
为外部提供集群内部应用访问入口
|
||
|
||
### dns
|
||
负责为整个集群提供DNS服务
|
||
|
||
### heapter
|
||
监控
|
||
|
||
### dashboard
|
||
gui
|
||
|
||
# k8s的pause容器有什么用。是否可以去掉。
|
||
pause是k8s基础容器，很稳定。pod中的所有容器都与pause 共享namespace。pid=1负责处理僵尸进程。
|
||
# k8s中的pod内几个容器之间的关系是什么。
|
||
共享各种namespace，通过localhost通信
|
||
# 一个经典pod的完整生命周期。
|
||
初始化容器 initc
|
||
启动后
|
||
存活探针livenessProbe
|
||
就绪探针readinessProbe
|
||
结束前
|
||
pod创建过程总可能有pending（创建但未调度完成），running（容器被创建，至少一个容器正常运行），succeeded（所有容器都正常停止），failed（至少一个容器非正常退出），unknown（未知原因无法知道pod状态）状态
|
||
# k8s的service和endpoint是如何关联和相互影响的。
|
||
service与pod关联，需要通过endpoint。endpoint是在service创建的时候，由k8s自动创建
|
||
service要动态感知后端IP的变化，得介入一个endpoints控制器，也就是每个service都有对应一个endpoints控制器，endpoints帮它关联后端的pod，service 通过selector标签选择器关联pod, 具体实现动态IP变化由endpoints来实现
|
||
|
||
# 详述kube-proxy原理, 一个请求是如何经过层层转发落到某个pod上的整个过程。请求可能来自pod也可能来自外部。
|
||
|
||
# deployment/rs有什么区别。 其使用方式使用条件和原理是什么。
|
||
# cgroup中的cpu有哪几种限制方式。 k8s是如何使用实现request和limit的。
|
||
|
||
# rc/rs 功能是怎么实现的。详述从 API 接收到一个创建 rc/rs 的请求，到最终在节点上创建 pod 的全过程，尽可能详细。另外，当一个 pod 失效时，kubernetes 是如何发现并重启另一个 pod 的？
|
||
|
||
# 设想一个一千台物理机，上万规模的容器的 kubernetes 集群，请详述使用 kubernetes 时需要注意哪些问题？应该怎样解决？（提示可以从高可用，高性能等方向，覆盖到从镜像中心到 kubernetes 各个组件等）
|
||
# 设想 kubernetes 集群管理从一千台节点到五千台节点，可能会遇到什么样的瓶颈。应该如何解决。
|
||
# kubernetes 的运营中有哪些注意的要点。
|
||
# 集群发生雪崩的条件，以及预防手段。
|
||
# 设计一种可以替代 kube-proxy 的实现。
|
||
# sidecar 的设计模式如何在 k8s 中进行应用。有什么意义。
|
||
# 灰度发布是什么。如何使用 k8s 现有的资源实现灰度发布。
|
||
# 介绍 k8s 实践中踩过的比较大的一个坑和解决方式。
|
||
# 什么是k8s
|
||
Kubernetes是一个开源容器管理工具，负责容器部署，容器扩缩容以及负载平衡。作为Google的创意之作，它提供了出色的社区，并与所有云提供商合作。因此，我们可以说Kubernetes不是一个容器化平台，而是一个多容器管理解决方案
|
||
|
||
# docker与k8s的关系
|
||
docker是一种容器，提供容器生命周期管理，但是本身不具备自愈，负载均衡的功能，而且不同容器(包括不同主机容器)，若要互相通信，需要比较繁琐的配置
|
||
|
||
k8s专门用于容器编排组织，提供docker 缺少的功能
|
||
|
||
# 主机和容器上部署应用的区别
|
||
主机上部署的应用共享系统的资源，静态库等，更新与配置比较麻烦，在新系统上部署的话，还需要配置环境，很容易出问题。
|
||
容器部署应用，各应用资源隔离，应用本身可以快速迭代开发，一次部署，可以导出在其他地方运行，节约了环境配置时间。
|
||
|
||
# 什么是容器编排
|
||
组成应用的一组容器，需要组织起来，协同合作，使应用按照既定的设计运行，这种组织流程就是容器编排
|
||
|
||
# 容器编排需要什么能力
|
||
1、负载均衡
|
||
2、自动伸缩
|
||
3、故障转移
|
||
4、监控状态
|
||
5、自动恢复（自愈）
|
||
6、回滚
|
||
7、自动调度
|
||
|
||
# k8s特点
|
||
1、自动调度
|
||
2、自愈
|
||
3、自动更新与回滚
|
||
4、自动伸缩
|
||
5、负载均衡
|
||
|
||
# k8s如何简化容器化部署
|
||
k8s可以在不同主机，不同机房或云提供商上部署，需要负载均衡，网络配置，自动伸缩，监控等
|
||
|
||
# 对k8s集群了解多少
|
||
# 什么是heapster
|
||
Heapster是容器集群监控和性能分析工具，收集监控数据。heapster首相从master获取所有的node信息，然后通过这些node上的kubelet获取有用数据，，而kubelet的数据从cAdvisor得到，所有获取到的数据都被推送到heapster配置的后端存储中。
|
||
# 什么是minikube
|
||
单节点运行的k8s
|
||
|
||
# 什么是kubelet
|
||
负责维护容器的生命周期，同时也负责Volume（CVI）和网络（CNI）的管理
|
||
监控pod状态并通知给其他组件
|
||
监控node并汇报给master
|
||
负责为pod准备运行环境
|
||
周期性执行pod中定义的指针
|
||
|
||
# 什么是kubectl
|
||
k8s集群的命令行工具。可用通过kubectl完成对集群的管理（最后通过api-server）
|
||
|
||
# 对k8s一个节点有什么了解
|
||
1、可以是物理机或虚拟机
|
||
2、提供pod的运行环境
|
||
3、被matser管理
|
||
4、需要安装容器、kubelet、kube-proxy
|
||
|
||
# Kubernetes Architecture的不同组件有哪些
|
||
|
||
# 你对Kube-proxy有什么了解
|
||
在k8s每个节点上运行，完成service与内部pod之间的数据转发，提供4层负载均衡
|
||
|
||
# 您能否介绍一下Kubernetes中主节点的工作情况
|
||
# kube-apiserver和kube-scheduler的作用是什么
|
||
kube-apiserver是外部管理集群的唯一入口，完成认证、授权、访问控制，api注册和发现等机制
|
||
|
||
kube-scheduler负责资源调度，安装预定的调度规则，把pod调度到相应的机器上
|
||
|
||
# 你能简要介绍一下Kubernetes控制管理器吗？
|
||
负责维护集群状态，Kubernetes 自带的控制器例子包括副本控制器、节点控制器、命名空间控制器和服务账号控制器等
|
||
# 什么是ETCD
|
||
兼具一致性与高可用的键值数据库，用于存储k8s的集群状态
|
||
# Kubernetes有哪些不同类型的service
|
||
ClusterIP， NodePort，Load Balancer，External Name（外部Cname）
|
||
# 你对Kubernetes的负载均衡器有什么了解
|
||
两种分法，内部与外部，4层（kube-proxy）与7层（ingress）
|
||
# 什么是Ingress网络，它是如何工作的
|
||
Ingress定义了一组规则，是外部访问集群内部服务的入口，提供ssl，负载均衡等服务
|
||
# 您对云控制器管理器有何了解
|
||
# 什么是Container资源监控
|
||
用户需要了解容器的性能及资源使用情况。就需要对容器，pod，服务，集群等各层级进行管理。heapster，influxdb
|
||
|
||
# Replica Set 和 Replication Controller之间有什么区别
|
||
基本相同，但是rs可以支持集合的selector，rc支持基于等式的selector
|
||
|
||
# 什么是Headless Service
|
||
与普通service不同的地方在于，没有ClusterIP，通过它直接访问后端的pod，中间没有代理，一般用于有状态服务
|
||
# 使用Kubernetes时可以采取哪些最佳安全措施
|
||
# 什么是集群联邦
|
||
多个集群当成一个集群进行管理
|
||
# cni
|
||
container network interface，容器网络接口，是一个标准的，通用的接口。现在容器平台：docker，kubernetes，mesos，容器网络解决方案：flannel，calico，weave。只要提供一个标准的接口，就能为同样满足该协议的所有容器平台提供网络功能，而CNI正是这样的一个标准接口协议。
|
||
CNI用于连接容器管理系统和网络插件。提供一个容器所在的network namespace，将network interface插入该network namespace中（比如veth的一端），并且在宿主机做一些必要的配置（例如将veth的另一端加入bridge中），最后对namespace中的interface进行IP和路由的配置。
|
||
|
||
CNI的工作是从容器管理系统处获取运行时信息，包括network namespace的路径，容器ID以及network interface name，再从容器网络的配置文件中加载网络配置信息，再将这些信息传递给对应的插件，由插件进行具体的网络配置工作，并将配置的结果再返回到容器管理系统中。
|
||
# runc
|
||
RunC 是一个轻量级的工具，它是用来运行容器的，只用来做这一件事，并且这一件事要做好。我们可以认为它就是个命令行小工具，可以不用通过 docker 引擎，直接运行容器。事实上，runC 是标准化的产物，它根据 OCI 标准来创建和运行容器
|
||
Docker就是基于runC创建的，简单地说，runC是Docker中最为核心的部分，容器的创建，运行，销毁等等操作最终都将通过调用runC完成
|
||
|
||
# k8s控制器类型
|
||
rs，deployment，daemonSet，statefulSet，service，pod，job，cronjob
|
||
# k8s调度过程
|
||
# 为什么要用systemd替换cgroup
|
||
控制组用来约束分配给进程的资源。
|
||
|
||
当某个 Linux 系统发行版使用 systemd 作为其初始化系统时，初始化进程会生成并使用一个 root 控制组 (cgroup), 并充当 cgroup 管理器。 Systemd 与 cgroup 集成紧密，并将为每个 systemd 单元分配一个 cgroup。 你也可以配置容器运行时和 kubelet 使用 cgroupfs。 连同 systemd 一起使用 cgroupfs 意味着将有两个不同的 cgroup 管理器。
|
||
|
||
单个 cgroup 管理器将简化分配资源的视图，并且默认情况下将对可用资源和使用中的资源具有更一致的视图。 当有两个管理器共存于一个系统中时，最终将对这些资源产生两种视图。 在此领域人们已经报告过一些案例，某些节点配置让 kubelet 和 docker 使用 cgroupfs，而节点上运行的其余进程则使用 systemd; 这类节点在资源压力下会变得不稳定。
|
||
|
||
更改设置，令容器运行时和 kubelet 使用 systemd 作为 cgroup 驱动，以此使系统更为稳定。 对于 Docker, 设置 native.cgroupdriver=systemd 选项。
|
||
|
||
注意：非常 不 建议更改已加入集群的节点的 cgroup 驱动。 如果 kubelet 已经使用某 cgroup 驱动的语义创建了 pod，更改运行时以使用别的 cgroup 驱动，当为现有 Pods 重新创建 PodSandbox 时会产生错误。重启 kubelet 也可能无法解决此类问题。 如果你有切实可行的自动化方案，使用其他已更新配置的节点来替换该节点，或者使用自动化方案来重新安装
|
||
|
||
# k8s网络插件
|
||
flannel，calico，cannel
|
||
|
||
# k8s三种认证方式
|
||
token方式：比如新增node节点
|
||
证书认证
|
||
serviceaccount
|
||
|
||
# etcd备份恢复
|
||
# pod，rs，deployment，svc，ingress如何关联
|
||
|
||
# 亲和性与反亲和性使用
|
||
调度器默认情况下会优先选择资源充足，负载平均的节点进行调度。比如说，内部的代码服务器，不希望与其他应用服务共用节点，但是有时两个pod通信比较频繁，又会希望他们在同一个节点上，这就需要亲和性与反亲和性
|
||
节点亲和性是指定pod在node上调度的约束。requiredDuringSchedulingIgnoredDuringExecution和preferredDuringSchedulingIgnoredDuringExecution，可以认为前一种是必须满足，如果不满足则不进行调度，后一种是倾向满足，不满足的情况下会调度到不符合条件的Node上。IgnoreDuringExecution表示如果在Pod运行期间Node的标签发生变化，导致亲和性策略不能满足，则继续运行当前的Pod。
|
||
|
||
pod亲和性，允许用户通过已经运行的Pod上的标签来决定调度策略，用文字描述就是“如果Node X上运行了一个或多个满足Y条件的Pod，那么这个Pod在Node应该运行在Pod X”，因为Node没有命名空间，Pod有命名空间，这样就允许管理员在配置的时候指定这个亲和性策略适用于哪个命名空间，可以通过topologyKey来指定。topology是一个范围的概念，可以是一个Node、一个机柜、一个机房或者是一个区域（如北美、亚洲）等，实际上对应的还是Node上的标签。
|
||
|
||
有两种类型
|
||
|
||
requiredDuringSchedulingIgnoredDuringExecution，刚性要求，必须精确匹配
|
||
preferredDuringSchedulingIgnoredDuringExecution，软性要求
|
||
|
||
|
||
反亲和性的应用，举例说明pod反亲和性，如果一个node上已经有了具有相同标签的pod，那么新node就不在上面部署，避免了节点故障导致的服务不可用
|
||
node反亲和性，就是应用不部署在相应的服务器上。比如说这个应用可能产生很大流量，这个小出水口的服务器，明显不能满足需要，就不调度到这些节点上
|
||
|
||
# 污点，污点容忍场景
|
||
当节点标记Taint时，除非Pod也被识别为可以容忍（Toleration）有污点的节点,否则默认情况下Kubernetes scheduler不会将Pod调度到有污点的节点上
|
||
Taint 和 toleration 相互配合，可以用来避免pod被分配到不合适的节点上。每个节点上都可以应用一个或多个taint，这表示对于那些不能容忍这些taint的 pod，是不会被该节点接受的。如果将toleration应用于pod上，则表示这些pod可以（但不要求）被调度到具有相应taint的节点上
|
||
|
||
# pv与pvc
|
||
|
||
|
||
# flannel三种模式，具体流程
|
||
host-gw
|
||
vxlan
|
||
|
||
udp。默认udp
|
||
|
||
|
||
# 封包与解包是怎样的
|
||
|
||
# vxlan与hostgw区别
|
||
|
||
# calico三种模式，具体流程
|
||
|
||
# calico路由模式
|
||
|
||
# 怎么跨路由
|
||
|
||
# 多集群多租户如何管理
|
||
|
||
# 怎么理解crd
|
||
custom resource defination
|
||
|
||
# 怎么理解operator
|
||
|
||
# service mesh
|
||
|
||
# istio osm nginx-service-mesh
|
||
|
||
# helm
|
||
类似yum的，别人已经编辑好的
|
||
|
||
# traefic
|
||
# harbor
|
||
本地仓库
|
||
|
||
# promethues怎么监控k8s
|
||
|
||
# efk日志采集优缺点
|
||
|
||
# jenkins pipe
|
||
|
||
# sonarqube
|