k8s常见问题（3）

1，Pod的重启策略及应用场景

Pod的restartPolicy定义了Pod内容器退出时kubelet的重启行为，它应用于Pod中的所有容器。该策略有三种可选值：

Always：只要容器终止退出，，kubelet都会自动重启它。这是默认策略。适用场景：需要持续运行/高可用的服务，数据库，API后端等

OnFailure：仅在容器异常退出时才会重启。适用场景：批处理任务，定时作业等，确保任务在失败后能自动重试，直至成功

Never：容器退出后，kubelet永远不会自动重启它。适用场景：一次性执行的任务，例数据导出，测试等，只需要运行一次即可

2，简述命名空间怎样实现资源隔离

命名空间在kubernetes中主要提供了逻辑上的隔离，它并不是一个像虚拟机那样有强边界隔离的实体，而是帮助我们将集群划分为不同的"分组"或"项目"，从而实现更清晰的管理

其核心作用可以概括为以下三点：

1，资源隔离与组织：这是最基本的功能。不同的团队或项目可以使用独立的命名空间，其中的资源可以重名而互不干扰。这特别适用于划分不同的环境，例如开发/测试和生产

2，资源配额管理：通过resourceQuota对象，管理员可以限制一个命名空间所能使用的总计算资源和对象数量，防止某个命名空间耗尽整个集群的资源

3，访问控制的基础：命名空间是RBAC权限控制的最小作用域之一，为实施"最小权限原则：提供了基础。

3，简述kube-proxy的iptables模式

监听与同步：kube-proxy持续监听kubernetes API Server，得到Service和Endpoints的变化

规则生成：当创建或更新一个Service时，kube-proxy会在本节点上生成一系列iptables规则。这些规则主要位于NAT表中

流量转发：

1，当数据包的目标IP是Service的ClusterIP时，会匹配到预设的规则链

2，规则链会进一步将流量跳转到另一个与特定Service对应的链

3，在这个最终链中，会设置多条规则，每条规则以随机的概率匹配，并指向一个具体的后端Pod

负载均衡：通过这种基于概率的随机规则，iptables实现了将请求随机分发到后端多个Pod的效果

4，简述kube-proxy的ipvs模式

IPVS模式是专为大规模负载均衡设计的，其核心优势在于性能和可扩展性。

底层数据结构：

iptables使用线性的规则链。当Service和Pod数量巨大时，规则列表会非常长，匹配查询的时间复杂度为O，性能会显著下降

IPVS使用高效的哈希表来管理服务和后端服务器，查询时间复杂度为O。这意味着即使服务数量增加到数千上万个，其转发效率也几乎不受影响

负载均衡算法：

iptables仅支持随即平等的算法

IPVS支持更丰富的调度算法，如轮询，加权轮询，最少连接等，能更好的满足复杂场景下的流量管理需求

规则同步：IPVS使用增量式更新，而iptables在更新规则时需要全量更新，IPVS方式对性能影响更小

5，简述Service的适用范围

|------------------|------|-----------------------------------|--------------------------------------------------|
| 类型 | 访问范围 | 实现机制 | 核心特点 |
| ClusterIP | 集群内部 | 分配一个仅在集群内可路由的虚拟IP | 默认类型，提供稳定的内部服务发现端点。安全，外部无法直接访问 |
| NodePort | 集群外部 | 在ClusterIP基础上，在每个节点上开启一个静态端口 | 外部客户端可通过任意节点IP：NodePort访问服务。无需特殊云服务，但节点IP变动需手动维护 |
| LoadBalancer | 互联网 | 在NodePort基础上，集成云厂商的负载均衡器 | 云平台自动分配公网IP，提供高可用，高性能的对外服务入口，是暴露服务到公网的标准生产级方式 |
| Headless Service | 集群内部 | 通过设置ClusterIP:None来声明，没有ClusterIP | DNS查询会直接返回后端所有Pod的IP地址列表，而非service的VIP，不提供负载均衡 |
| ExternalName | 集群内部 | 通过DNS CNAME记录映射到外部域名 | 将集群内部服务映射到集群外部的服务，是一种特殊的Service类型 |

6，简述普通用户和服务账号的差别

|------|--------------------------------|-----------------------------------------------------------------------|
| 特征 | 普通用户 | 服务账号 |
| 管理方式 | Kubernetes不直接管理用户对象，其身份由外部系统固定 | 由Kubernetes直接创建和管理的对象 |
| 作用范围 | 通常代表集群外部的管理员，开发或操作人员，权限是集群范围的 | 旨在为运行在Pod中的应用程序或进程提供身份，是命名空间范围的 |
| 主要用途 | 人员通过kubectl或API管理集群 | Pod内的应用于Kubernetes API通信 |
| 身份格式 | 有认证方式决定，知证书的CN字段作为用户名 | 用户名格式指定为Lsystem serviceaccount：<namespace>:<service-account name> |

8，简述NetworkPolicy怎样限制出入站流量

默认行为：如果某个命名空间中没有任何NetworkPolicy，那么该命名空间中所有Pod的所有入方向和出方向流量都是被允许的。这是一个"允许所有"的宽松模式。

实现"默认拒绝所有入站流量"：为了增强安全性，我们通常需要适时"最小权限原则"，即默认拒绝所有流量，只显示允许必要的通信。要在一个命名空间中实现"默认拒绝所有入站流量"，可以创建如下策略：

bash 复制代码

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all-ingress
  namespace: your-namespace
spec:
  podselector: {}
policyTypes: 
  - Ingress

此策略会选中命名空间内所有Pod，并因为制定了PolicyTypes： - Ingress却未定义任何具体的ingress允许规则，从而导致所有入站流量被拒绝。出站流量则不受此策略影响

9，怎么用NetworkPolicy限定所有流量仅允许80号端口通过

bash 复制代码

apiVersion : networking.k8s.io/v1
kind: NetworkPolicy
metadata: 
  name: allow-frontend-to-backend-api
  namespace: default
spec: 
  PodSelector: 
    matchLabels:
      app: api-backend
  policyTypes:
  - ingress: 
  ingress: 
  - from:
    - podSelector:
        matchLabel:
          app: frontend
    ports:
    - protocol: TCP
      port: 80

10,简述HPA扩缩容的工作原理

HPA是应用层面的弹性伸缩器。它的工作原理是一个控制循环：

监控：HPA控制器默认每隔30秒通过Metrics Server等监控组件获取目标Pod的制定指标

计算：根据获取到的当前指标值与设定的目标值进行比较，通过公式计算期望的副本数：期望副本数=ceil[当前副本数x(当前指标值。目标指标值）]

执行：HPA直接修改其管理的Deployment或StatefulSet的副本数，从而增加或减少Pod的数量

11，简述k8s之内的不同限制

|-----------|------|-----------|------------------------------------------------------|
| 步骤 | 核心组件 | 要解决的问题 | 关键机制与示例 |
| 1，身份确认 | 认证 | "你是谁" | 确认访问者身份支持多种方式如X509客户端证书，ServiceAccount令牌，OIDC等 |
| 2，权限检查 | 授权 | "你能干什么" | 判断已认证的身份是否有权限执行操作，最常用的是RBAC机制 |
| 3，请求拦截与修改 | 准入控制 | "你的操作合规吗" | 对需求进行更精细的拦截，验证甚至修改，里Podsecurity策略，ResourceQuota资源配额等 |