k8s(四)

​

组件

kubelet

kubelet 是运行在每个节点上的主要的"节点代理"，每个节点都会启动 kubelet进程，用来处理 Master 节点下发到本节点的任务，按照 PodSpec 描述来管理Pod 和其中的容器（PodSpec 是用来描述一个 pod 的 YAML 或者 JSON 对象）。

kubelet 通过各种机制（主要通过 apiserver ）获取一组 PodSpec 并保证在这些 PodSpec 中描述的容器健康运行。

kubelet 默认监听四个端口，分别为 10250 、10255、10248、4194。

LISTEN 0 128 *:10250 *:* users:(("kubelet",pid=48500,fd=28))    
LISTEN 0 128 *:10255 *:* users:(("kubelet",pid=48500,fd=26))
LISTEN 0 128 *:4194 *:* users:(("kubelet",pid=48500,fd=13))
LISTEN 0 128 127.0.0.1:10248 *:* users:(("kubelet",pid=48500,fd=23))

10250（kubelet API）：kubelet server 与 apiserver 通信的端口，定期请求 apiserver 获取自己所应当处理的任务，通过该端口可以访问获取 node 资源以及状态。

10248（健康检查端口）：通过访问该端口可以判断 kubelet 是否正常工作, 通过 kubelet 的启动参数 --healthz-port 和 --healthz-bind-address 来指定监听的地址和端口。

4194（cAdvisor 监听）：kublet 通过该端口可以获取到该节点的环境信息以及 node 上运行的容器状态等内容，访问 http://localhost:4194 可以看到 cAdvisor 的管理界面,通过 kubelet 的启动参数 --cadvisor-port 可以指定启动的端口。

10255 （readonly API）：提供了 pod 和 node 的信息，接口以只读形式暴露出去，访问该端口不需要认证和鉴权。

kubelet 主要功能：

• pod 管理：kubelet 定期从所监听的数据源获取节点上 pod/container 的期望状态（运行什么容器、运行的副本数量、网络或者存储如何配置等等），并调用对应的容器平台接口达到这个状态。
• 容器健康检查：kubelet 创建了容器之后还要查看容器是否正常运行，如果容器运行出错，就要根据 pod 设置的重启策略进行处理。
• 容器监控：kubelet 会监控所在节点的资源使用情况，并定时向 master 报告，资源使用数据都是通过 cAdvisor 获取的。知道整个集群所有节点的资源情况，对于 pod 的调度和正常运行至关重要。

kubelet 组件中的模块

1、PLEG(Pod Lifecycle Event Generator） PLEG 是 kubelet 的核心模块,PLEG 会一直调用 container runtime 获取本节点 containers/sandboxes 的信息，并与自身维护的 pods cache 信息进行对比，生成对应的 PodLifecycleEvent，然后输出到 eventChannel 中，通过 eventChannel 发送到 kubelet syncLoop 进行消费，然后由 kubelet syncPod 来触发 pod 同步处理过程，最终达到用户的期望状态。

2、cAdvisor cAdvisor（https://github.com/google/cadvisor）是 google 开发的容器监控工具，集成在 kubelet 中，起到收集本节点和容器的监控信息，大部分公司对容器的监控数据都是从 cAdvisor 中获取的 ，cAvisor 模块对外提供了 interface 接口，该接口也被 imageManager，OOMWatcher，containerManager 等所使用。

3、OOMWatcher 系统 OOM 的监听器，会与 cadvisor 模块之间建立 SystemOOM,通过 Watch方式从 cadvisor 那里收到的 OOM 信号，并产生相关事件。

4、probeManager probeManager 依赖于 statusManager,livenessManager,containerRefManager，会定时去监控 pod 中容器的健康状况，当前支持两种类型的探针：livenessProbe 和readinessProbe。 livenessProbe：用于判断容器是否存活，如果探测失败，kubelet 会 kill 掉该容器，并根据容器的重启策略做相应的处理。 readinessProbe：用于判断容器是否启动完成，将探测成功的容器加入到该 pod 所在 service 的 endpoints 中，反之则移除。readinessProbe 和 livenessProbe 有三种实现方式：http、tcp 以及 cmd。

5、statusManager statusManager 负责维护状态信息，并把 pod 状态更新到 apiserver，但是它并不负责监控 pod 状态的变化，而是提供对应的接口供其他组件调用，比如 probeManager。

6、containerRefManager 容器引用的管理，相对简单的Manager，用来报告容器的创建，失败等事件，通过定义 map 来实现了 containerID 与 v1.ObjectReferece 容器引用的映射。

7、evictionManager 当节点的内存、磁盘或 inode 等资源不足时，达到了配置的 evict 策略， node 会变为 pressure 状态，此时 kubelet 会按照 qosClass 顺序来驱赶 pod，以此来保证节点的稳定性。可以通过配置 kubelet 启动参数 --eviction-hard= 来决定 evict 的策略值。

8、imageGC imageGC 负责 node 节点的镜像回收，当本地的存放镜像的本地磁盘空间达到某阈值的时候，会触发镜像的回收，删除掉不被 pod 所使用的镜像，回收镜像的阈值可以通过 kubelet 的启动参数 --image-gc-high-threshold 和 --image-gc-low-threshold 来设置。

9、containerGC containerGC 负责清理 node 节点上已消亡的 container，具体的 GC 操作由runtime 来实现。

10、imageManager 调用 kubecontainer 提供的PullImage/GetImageRef/ListImages/RemoveImage/ImageStates 方法来保证pod 运行所需要的镜像。

11、volumeManager 负责 node 节点上 pod 所使用 volume 的管理，volume 与 pod 的生命周期关联，负责 pod 创建删除过程中 volume 的 mount/umount/attach/detach 流程，kubernetes 采用 volume Plugins 的方式，实现存储卷的挂载等操作，内置几十种存储插件。

12、containerManager 负责 node 节点上运行的容器的 cgroup 配置信息，kubelet 启动参数如果指定 --cgroups-per-qos 的时候，kubelet 会启动 goroutine 来周期性的更新 pod 的 cgroup 信息，维护其正确性，该参数默认为 true，实现了 pod 的Guaranteed/BestEffort/Burstable 三种级别的 Qos。

13、runtimeManager containerRuntime 负责 kubelet 与不同的 runtime 实现进行对接，实现对于底层 container 的操作，初始化之后得到的 runtime 实例将会被之前描述的组件所使用。可以通过 kubelet 的启动参数 --container-runtime 来定义是使用docker 还是 rkt，默认是 docker。

14、podManager podManager 提供了接口来存储和访问 pod 的信息，维持 static pod 和 mirror pods 的关系，podManager 会被statusManager/volumeManager/runtimeManager 所调用，podManager 的接口处理流程里面会调用 secretManager 以及 configMapManager。

Kustomize

Kustomize CLI 命令参考。

Kustomize 是一个用来定制 Kubernetes 配置的工具。它提供以下功能特性来管理应用配置文件：

• 从其他来源生成资源
• 为资源设置贯穿性（Cross-Cutting）字段
• 组织和定制资源集合

Kustomize 提供一个插件框架，允许用户开发自己的 生成器 和 转化器。

通过插件，实现 [generatorOptions] 和 [transformerconfigs] 无法满足的需求。

• generator 插件生成 k8s 资源，比如 helm chart inflator 是一个 generator 插件，基于少量自由变量生成一个 12-factor 应用所包含的全部组件 deployment，service，scaler，ingress 等）也是一个 generator 插件。
• transformer 插件转化（修改）k8s 资源，比如可能会执行对特殊容器命令行的编辑，或为其他内置转换器（namePrefix、commonLabels 等）无法转换的内容提供转换。

kubectl kustomize <kustomization_directory>

ConfigMap 和 Secret 包含其他 Kubernetes 对象（如 Pod）所需要的配置或敏感数据。 ConfigMap 或 Secret 中数据的来源往往是集群外部，例如某个 .properties 文件或者 SSH 密钥文件。 Kustomize 提供 secretGenerator 和 configMapGenerator，可以基于文件或字面值来生成 Secret 和 ConfigMap

要基于文件来生成 ConfigMap，可以在 configMapGenerator 的 files 列表中添加表项。

ConfigMap 也可基于字面的键值偶对来生成。要基于键值偶对来生成 ConfigMap， 在 configMapGenerator 的 literals 列表中添加表项

Kustomize 支持组合不同的资源。kustomization.yaml 文件的 resources 字段定义配置中要包含的资源列表。 你可以将 resources 列表中的路径设置为资源配置文件的路径。

并非所有资源或者字段都支持策略性合并补丁。为了支持对任何资源的任何字段进行修改， Kustomize 提供通过 patchesJson6902 来应用 JSON 补丁的能力。 为了给 JSON 补丁找到正确的资源，需要在 kustomization.yaml 文件中指定资源的组（group）、 版本（version）、类别（kind）和名称（name）

Kustomize 中有 基准（bases） 和 覆盖（overlays） 的概念区分。 基准 是包含 kustomization.yaml 文件的一个目录，其中包含一组资源及其相关的定制。 基准可以是本地目录或者来自远程仓库的目录，只要其中存在 kustomization.yaml 文件即可。 覆盖 也是一个目录，其中包含将其他 kustomization 目录当做 bases 来引用的 kustomization.yaml 文件。 基准不了解覆盖的存在，且可被多个覆盖所使用。 覆盖则可以有多个基准，且可针对所有基准中的资源执行组织操作，还可以在其上执行定制

# 创建一个包含基准的目录 
mkdir base
# 创建 base/deployment.yaml
cat <<EOF > base/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  selector:
    matchLabels:
      run: my-nginx
  replicas: 2
  template:
    metadata:
      labels:
        run: my-nginx
    spec:
      containers:
      - name: my-nginx
        image: nginx
EOF

# 创建 base/service.yaml 文件
cat <<EOF > base/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: my-nginx
  labels:
    run: my-nginx
spec:
  ports:
  - port: 80
    protocol: TCP
  selector:
    run: my-nginx
EOF

# 创建 base/kustomization.yaml
cat <<EOF > base/kustomization.yaml
resources:
- deployment.yaml
- service.yaml
EOF

K8s健康检查

k8s健康检测主要分为以下三种

存活性探测（Liveness probes） :主要是探测应用是否还活着。如果检测到应用没有存活就杀掉当前pod并重启。

就绪性探测（Readiness probes）:只要是探测应用是否准备好接受请求访问，如果检测应用准备好了，就把请求流量放进来；反之，则把应用节点从注册中心拿掉。

启动探测（Startup Probes）：对于旧应用需要更长的启动时间，这时候既不想重启应用也不想让请求访问进来，可以设置启动探测给足够的启动时间保证应用启动成功。

initialDelaySeconds 表示延迟30S开始第一次探测，默认值是0，最小值是0
timeoutSeconds 表示每次探测的超时时间，35S后如果没返回结果就认为超时失败，默认值是1，最小值是1
successThreshold 表示在探测失败后，最小的连续成功被认为是成功的，默认值是1，最小值是1
failureThreshold 表示当探测失败时，Kubernetes将在认为失败前尝试failureThreshold次数。默认值是3，最小值是1;Liveness认为失败的操作是重启pod，而readiness认为失败的操作是把pod标记为 Unready
periodSeconds 表示多久进行一次探测，默认是10S，最小值是1

成功：容器通过了探测
失败：容器未通过探测
未知：容器探测失败，不采取任何操作

配置管理configMap和secret

k8s中的secret和configmap是为了让POD和配置解耦，使得从集群外部可以想容器内部注入配置信息、环境变量等功能 ConfigMap扮演了K8S集群中配置中心的角色，ConfigMap定义了Pod的配置信息，可以以存储卷的形式挂载至Pod中的应用程序配置文件目录，从ConfigMap中读取配置信息 ConfigMap是明文保存的，如果用来保存数据库账号密码这类信息可以使用通过secret来保存，secret的功能和ConfigMap一样，不过secret是通过Base64的编码机制保存配置信息 可以通过命令行的方式来创建configmap，

kubectl create configmap nginx-config --from-literal=nginx_server_port=8080 --from-literal=nginx_server_name=www.sulao.cn
configmap/my-config created

亦可以通过调用配置文件的方式来创建configmap，yaml文件内容如下

vi vhost.conf
server {
  listen 8080;
  server_name www.sulao.cn;
  root /data/www;
}
kubectl create configmap nginx-config --from-file=./vhost.conf
vi nginx-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers: 
  - name: nginx
    image: nginx
    volumeMounts :              #定义容器使用存储卷挂载
    - name: config              #使用存储卷的名称
      mountPath: /etc/nginx/conf.d/
volumes:
- name: config                  #存储卷名称
  configMap:                    #存储卷类型：这里为configmap而不是nfs其他的文件系统，可以指定configmap资源为存储卷
    name: nginx-config          #configmap名称，这里为我们刚才创建的cm名称
    items :                     #使用cm中的key
    - key: vhost.conf           #key名称
      path: sulao.cn.conf   #表示映射为文件时文件名是什么

--from-file=./vhost.conf #利用文件来传递参数，没有给key名称默认为文件名称为key，这里所以文件名就是vhost.conf，文件内容为vhost.conf文件内的内容，当然也可以指定文件名，那么我们创建configmap是需要这样命名