Kubernetes(K8S)中文文档_Kubernetes中文社区
kubeadm快速部署K8s集群的工具，如：
创建master node：kubeadm init
将worker node加入到集群中：kubeadm join
kubectl是K8s的命令行工具，可以对集群本身进行管理，也能在集群中对容器化应用程序进行安装部署。
kubelet是master node派到worker node的代表，管理本机容器
- 一个集群中每个节点上运行的代理，它保证容器都运行在Pod中
- 负责维护容器的生命周期，同时也负责Volume(CSI) 和 网络(CNI)的管理
一、理解Kubernetes是由哪些组件构成，以及各组件的功能
组件
1、控制平面组件control plane components（Master Node）
控制平面组件为集群做出全局决策，如资源的调度，以及检测和响应集群事件。
（1）Kube-apiserver
K8s的请求入口服务。负责公开K8s的API，负责处理接受请求的工作，是K8s的前端。可以运行多个Kube-apiserver的实例，并在这些实例之间平衡流量。
API Server 负责接收 K8S 所有请求（来自 UI 界面或者 CLI 命令行工 具），然后，API Server 根据用户的具体请求，去通知其他组件干活。
（2）键值存储的后台数据库etcd
K8s的存储服务。一致且高可用的键值存储，用作K8s所有集群数据的后台数据库。（注意数据备份）。
etcd 存储了 K8S 的关键配置和用户配置，K8S 中仅 API Server 才具备读写权限，其 他组件必须通过 API Server 的接口才能读写数据。
（3）调度器kube-scheduler
K8s所有工作节点的调度器。负责监视新创建的、未指定运行节点的Pods，并选择节点来让Pod在上面运行。
当用户要部署服务时，Scheduler 会选择最合适的 Worker Node（服务器）来部署。
调度决策考虑的因素包括单个Pod及Pod集合的资源需求、软硬件及策略约束、亲和性和反亲和性规范、数据位置、工作负载间对的干扰及最后时限。
（4）控制器管理器kube-controller-manager
K8s所有工作节点的监视器。 负责运行控制器进程。如节点控制器、任务控制器、端点分片控制器、服务账号控制器等。
Controller 负责监控和调整在 Worker Node 上部署的服务的状态，比如用户要求 A 服务部署 2 个副本，那么当其中一个服务挂了的时候， Controller 会马上调整，让 Scheduler 再选择一个 Worker Node 重新部署服务。
（5）云控制器管理器cloud-controller-manager
嵌入了特定于云平台的控制逻辑。该管理器允许将集群连接到云提供商的API之上，并将与该云平台交互的组件同与你的集群交互的组件分离开来。
2、Node节点组件
节点组件在每个节点上运行，负责维护运行的Pod并提供K8s运行环境。
（1）kubelet
工作节点的监视器，主节点的通讯器。
kubelet会在集群中每个节点上运行。它保证容器都运行在Pod中。
kubelet接收一组通过各类机制提供给它的PodSpec，确保这些PodSpec中描述的容器处于运行状态且健康。
Kubelet 是 Master Node 派到Worker Node 上的“代表”，它会定期向 Master Node 汇报自己 Node 上运行的服务的状态，并接受来自 Master Node 的指示采取调整措施。负责控制所有容器的启动停止，保证节点工作正常。
（2）kubelet-proxy
K8s的网络代理。kubelet-proxy是集群中每个节点上所运行的网络代理，实现K8s中service概念的一部分。kubelet-proxy维护节点上的一些网络规则，这些规则运行从集群内部或外部的网络会话与Pod进行网络通信。
（3）容器运行时contariner runtime
Worker Node 的运行环境，即安装了容器化所需的软件环境确保容器化程序能够跑起
3、插件Addons
插件使用K8s资源（DaemonSet，Deployment等）实现集群功能。插件提供集群级别的功能，插件中命名空间域的资源属于kube-system命名空间。下面是常见的插件。
（1） DNS
集群DNS是一个DNS服务器，和环境中的其他DNS服务器一起工作，它为K8s服务提供DNS记录。
（2）仪表盘Web界面Dashboard
Dashboard是K8s集群的通用、基于web的用户界面。用于管理集群中运行的应用程序以及集群本身，并进行故障排除。
（3）容器资源监控
将关于容器的一些常见的时间序列度量值保存到一个集中的数据库中，并提供浏览这些数据的界面。
（4）集群层面日志
负责将容器的日志数据保存到一个集中的日志存储中，集中日志存储提供搜索和浏览接口。
（5）网络插件
实现容器网络接口CNI（container network interface）规范的软件组件，负责为Pod分配IP地址，并使用这些Pod能在集群内部相互通信。
二、Pod是什么，他和容器有什么关系
（1）Cluster——>（n）Node——>（n）Pod——>（n）Container——>（1/n）Application
容器放入Pod，Pod运行在节点上，节点可能是虚拟机或物理机。节点由Master Node控制面管理。
Pod和容器是包含关系，Pod包含容器。
Pod表示包含一个或多个应用容器（如Docker），以及这些容器一些共享资源的一个集合。
Pod中若干个应用容器共享的资源包括：共享存储、网络（作为唯一的集群IP地址）、有关每个容器如何运行的信息（如容器镜像版本或端口）。
Pod可以包含若干个相对紧耦合的应用容器。例如一个Pod包含两个应用容器，一个应用容器是Node.js应用，另一个是提供Node.js应用服务器要发布的数据的应用。
Pod中的若干个应用容器共享IP地址和端口，始终位于同一位置并且共享调度，并在同一节点上的共享上下文中运行。
Pod是K8s集群中创建、管理和调度的最小单位，即原子单位。当在K8s中创建Deployment时，会创建包含容器的Pod，而不是直接创建容器。每个Pod与调度它的Node节点绑定，并保持在那里，直到终止或删除。如果节点发生故障，则会在集群中的其他可用节点上调度相同的Pod。
三、Deployment是什么，他为什么适合无状态服务
kubernetes-Deployment部署无状态服务的原理详解（二十五） - Andya_net - 博客园 (cnblogs.com)
无状态服务VS有状态服务
- 无状态服务
无状态服务不会在本地存储持久化数据。多个服务实例对于同一个用户请求的响应结果是完全一致的。这种多服务实例之间是没有依赖关系，比如web应用，在k8s控制器 中动态启停无状态服务的pod并不会对其它的pod产生影响。
- 有状态服务
有状态服务需要在本地存储持久化数据。典型的是分布式数据库的应用，分布式节点实例之间有依赖的拓扑关系。比如，主从关系，如果K8S停止分布式集群中任 一实例pod，就可能会导致数据丢失或者集群的crash。
ReplicaSet
ReplicaSet 的目的是维护一组在任何时候都处于运行状态的 Pod 副本的稳定集合。 因此，它通常用来保证给定数量的、完全相同的 Pod 的可用性。ReplicaSet 主要用途是提供给 Deployment 作为编排 Pod 创建、删除和更新的一种机制。
Deployment
创建了K8s集群后，就可以在其上面部署容器化应用程序。先创建K8s Deployment配置，以指挥K8s创建和更新应用程序的实例。创建Deployment后，Master Node将应用程序实例调度到集群中的各个Worker Node上。Deployment控制器会持续监视这些实例。若节点关闭或被删除，则Deployment控制器会将应用程序实例替换为集群中另一个节点上的实例（自我修复机制以解决机器故障维护问题）。
一个 Deployment 为 Pod 和 ReplicaSet 提供声明式的更新能力。
• 部署无状态应用
• 管理Pod和ReplicaSet（副本控制、更新回滚）
• 具有上线部署、副本设定、滚动升级、回滚等功能
• 提供声明式更新，例如只更新一个新的Image
Deployment被设计用来管理无状态服务的pod，每个pod完全一致：
•无状态服务内的多个Pod创建的顺序是没有顺序的；
•无状态服务内的多个Pod的名称是随机的。p0d被重新启动调度后，它的名称与P都会发生变化；
•无状态服务内的多个Pod背后是共享存储的。
Deployment可以管理多个副本的Pod实现无缝迁移、自动扩容缩容、自动灾难恢复、一键回滚等功能。
Deployment组件是为无状态服务而设计的，其中的Pod名称、主机名、存储都是随机、不稳定的，并且Pod的创建与销毁也是无序的。这个设计决定了无状态服务并不适合数据库领域的应用。
如果应用程序不需要任何稳定的标识符或有序的部署、删除或扩缩， 则应该使用由一组无状态的副本控制器提供的工作负载来部署应用程序，比如 Deployment 或者 ReplicaSet。
四、StatusfulSet是什么，他为什么适合有状态服务，他有什么特性
概念
StatefulSet 是用来管理有状态应用的工作负载 API 对象。
StatefulSet 用来管理某 Pod 集合的部署和扩缩， 并为这些 Pod 提供持久存储和持久标识符。
特征
Stateful管理有状态的应用，它的Pod有如下特征：
•唯一性：每个Pod会被分配一个唯一序号；
•顺序性：Pod启动，更新，销毁是按顺序进行；
•稳定的网络标识：Pod主机名，DNS地址不会随着Pod被重新调度而发生变化；
•稳定的持久化存储：Pod被重新调度后，仍然能挂载原有的PV,从而保证了数据的完整性和一致性。
五、DaemonSet概念及其特性
概念
DaemonSet：守护进程集，缩写为ds，在所有节点或者是匹配的节点上都部署一个Pod。
DaemonSet使用场景
• 运行集群存储的daemon，比如ceph或者glusterd
•节点的CNI网络插件，calico
•节点日志的收集：fluentd或者是filebeat
•节点的监控：node exporter
• 服务暴露：部署一个ingress nginx
DaemonSet 确保全部（或者某些）节点上运行一个 Pod 的副本。 当有节点加入集群时， 也会为他们新增一个 Pod 。 当有节点从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。
DaemonSet 的一些典型用法：
- 在每个节点上运行集群守护进程
- 在每个节点上运行日志收集守护进程
- 在每个节点上运行监控守护进程
六、Service：通过网络暴露 Pod 组合
使用 Service 暴露你的应用 | Kubernetes
Service服务用于对外部暴露应用。
Service 允许应用程序接收流量。
Service API 是 Kubernetes 的组成部分，它是一种抽象，帮助你通过网络暴露 Pod 组合。 每个 Service 对象定义一个逻辑组的端点（通常这些端点是 Pod）以及如何才能访问这些 Pod 的策略。
七、阐述ClusterIP、NodePort、Headless、Ingress、LoadBalance等Service的区别
k8s 之如何从集群外部访问内部服务的三种方法 - 春光牛牛 - 博客园 (cnblogs.com)
深入了解Kubernetes服务类型：ClusterIP、NodePort、LoadBalancer和ExternalName - 掘金 (juejin.cn)
Kubernetes的集群外部访问方式：NodePort、LoadBalancer和Ingress。
Kubernetes的集群内部访问方式：ClusterIP
ClusterIP
ClusterIP 服务是 Kubernetes 的默认服务，是K8s系统自动分配的虚拟IP，只能在集群内部访问。它给你一个集群内的服务，集群内的其它应用都可以访问该服务。集群外部无法访问它，但是可以通过在cluster里提供proxy代理方式访问，kubectl proxy。如Dashboard的访问。
当您创建一个Service资源对象而没有指定服务类型时，默认会被设置为ClusterIP类型。ClusterIP只能通过内部DNS进行访问，因此它适合处理内部流量。
ClusterIP根据是否生成ClusterIP又可分为普通Service和Headless Service
Service两类：
- 普通Service：为Kubernetes的Service分配一个集群内部可访问的固定虚拟IP(Cluster IP), 实现集群内的访问。（service name解析为cluster ip,然后cluster ip对应到后面的Pod Ip）
- Headless Service： 该服务不会分配Cluster IP, 也不通过kube-proxy做反向代理和负载均衡。而是通过DNS提供稳定的网络ID来访问，DNS会将headless service的后端直接解析为Pod Ip列表。（无头服务：service name 直接解析为后面的Pod Ip）
使用 Kubernetes 的 proxy 模式来访问你的服务的场景：
- 由于某些原因，你需要调试你的服务，或者需要直接通过笔记本电脑去访问它们。
- 容许内部通信，展示内部仪表盘等。
这种方式要求运行 kubectl 作为一个未认证的用户，因此不能用这种方式把服务暴露到 internet 或者在生产环境使用。
NodePort
将Service通过指定的Node上的端口暴露给外部，通过此方法，就可以在集群外部访问服务。(在每个Node上分配一个端口作为外部访问入口)。
NodePort 服务是引导外部流量到你的服务的最原始方式。NodePort，在所有节点（虚拟机）上开放一个特定端口，任何发送到该端口的流量都被转发到对应服务。
使用场景：
- 这种方法有许多缺点；
- 每个端口只能是一种服务；
- 端口范围只能是 30000-32767
如果运行的服务不要求一直可用，或者对成本比较敏感，可以使用这种方法。这样的应用的最佳例子是 demo 应用，或者某些临时应用。
LoadBalancer
LoadBalancer服务类型是一种Kubernetes扩展，它可以通过云提供商支持的负载均衡器来暴露服务。这种类型的服务适用于处理公共流量，并且需要在外部进行访问。
LoadBalancer 服务是暴露服务到 internet 的标准方式。在 GKE 上，这种方式会启动一个 Network Load Balancer，它将给一个单独的 IP 地址，转发所有流量到服务。
工作在特定的Cloud Provider上，例如Google Cloud，AWS，OpenStack。
如果想要直接暴露服务，这就是默认方式。所有通往指定的端口的流量都会被转发到对应的服务。它没有过滤条件，没有路由等。这意味着几乎可以发送任何种类的流量到该服务，像 HTTP，TCP，UDP，Websocket，gRPC 或其它任意种类。
这个方式的最大缺点是每一个用 LoadBalancer 暴露的服务都会有它自己的 IP 地址，每个用到的 LoadBalancer 都需要付费，这将是非常昂贵的。
Ingress
Ingress 公开从集群外部到集群内服务的 HTTP 和 HTTPS 路由。
一个将所有流量都发送到同一 Service 的简单 Ingress 示例：
有别于以上所有例子，Ingress 事实上不是一种服务类型。相反，它处于多个服务的前端，扮演着“智能路由”或者集群入口的角色。
使用Ingress可以做很多事情，不同类型的Ingress控制器有不同的功能。
默认的GKE ingress控制器会启动一个 HTTP(S) Load Balancer，可以通过基于路径或者是基于子域名的方式路由到后端服务。例如，可以通过foo.yourdomain.com 发送任何东西到foo服务，或者是发送yourdomain.com/bar/路径下的任何东西到bar服务。
八、FQDN概念及其使用场景
FQDN：Fully Qualified Domain Name，完全限定域名。
FQDN = Hostname + DomainName，主机+域名。
例如申请了域名comp.com，有一台主机名为web，则可以使用web.comp.com得到这个主机IP。
若还有两台提供邮件和OA服务的主机cmail，oa，则这时候可以用以下FQDN：
cmail.comp.com
oa.comp.com
如果希望跨名字空间访问，则需要使用完全限定域名（FQDN）。
九、如何挂载文件，如果挂载本地文件
https://www.cnblogs.com/limeiyang/p/16575628.html
kubernetes学习总结之文件挂载_helm 挂载文件_望长安于日下的博客-CSDN博客
一个运行中的容器，缺省情况下，对文件系统的写入，都是发生在其分层文件系统的可写层的，一旦容器运行结束，所有写入都会被丢弃。因此需要对持久化支持。Kubernetes 中通过 Volume 的方式提供对存储的支持。
十、如何配置节点调度策略，有几种方式，各有什么区别
调度 是指将 Pod 放置到合适的节点上，以便对应节点上的 Kubelet 能够运行这些 Pod。
十一、边车实现的原理
https://blog.csdn.net/knight_zhou/article/details/126241319
k8s总结之边车模式sidecar – 云原生之路 (361way.com)
边车模式sidecar是在不改变原有container功能的情况下，在同一个pod下增加其他container来增加对应的功能。
因为在同一个Pod下的容是共享一个namespace空间的，所以对应的网络、存储等资源也是同一个空间下的，这就可以很方便的进行两个containers之间交互。
十二、如何使用Init容器初始化环境
快速理解initContainer概念、用法、使用场景_initcontainers_[shenhonglei]的博客-CSDN博客
k8s中初始化容器（init container）的作用及其使用方法 - 安大 - 博客园 (cnblogs.com)
在容器的部署过程中，有的时候需要在容器运行之前进行一些预配置的工作，比如下载配置，判断某些服务是否启动，修改配置等一些准备的工作，想要实现这些功能，在k8s中可以使用初始化容器，在应用容器运行之前进行一些预处理的工作。
Init 容器是一种特殊容器，在 Pod 内的应用容器启动之前运行。Init 容器可以包括一些应用镜像中不存在的实用工具和安装脚本。
使用 Init 容器
因为 Init 容器具有与应用容器分离的单独镜像，其启动相关代码具有如下优势：
-
Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。 例如，没有必要仅为了在安装过程中使用类似
sed、awk、python或dig这样的工具而去FROM一个镜像来生成一个新的镜像。 -
应用镜像的创建者和部署者可以各自独立工作，而没有必要联合构建一个单独的应用镜像。
-
与同一 Pod 中的多个应用容器相比，Init 容器能以不同的文件系统视图运行。因此，Init 容器可以被赋予访问应用容器不能访问的 Secret 的权限。
-
由于 Init 容器必须在应用容器启动之前运行完成，因此 Init 容器提供了一种机制来阻塞或延迟应用容器的启动，直到满足了一组先决条件。 一旦前置条件满足，Pod 内的所有的应用容器会并行启动。
-
Init 容器可以安全地运行实用程序或自定义代码，而在其他方式下运行这些实用程序或自定义代码可能会降低应用容器镜像的安全性。 通过将不必要的工具分开，你可以限制应用容器镜像的被攻击范围。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
