十、Kubernetes 进阶之核心组件篇

2020-05-04 本文已影响0人 Suny____

在K8S章节刚开始我们就介绍了里面的核心组件与架构图，但对于它们只是有一个很浅的认知，只知道它是干嘛的，对于它们都做了哪些事情比较模糊，本章节就对几个核心组件做个梳理介绍！

1、Master和Node

在正式梳理组件之前，再次回顾下Master节点和Node节点的功能，以及组件分配。

架构图
image.png

Master
- Master节点是K8S集群中的控制节点，负责整个集群的管理和控制，可以做成高可用，防止节点挂掉导致集群不可用。
- 其中有一些关键的组件：比如API Server，Controller Manager，Scheduler等
Node
- Node会被Master分配一些工作负载，当某个Node不可用时，会将工作负载转移到其他Node节点上。
- Node上有一些关键的组件：kubelet，kube-proxy，docker等

2、 Kubeadm

搭建K8S有很多种方式，Kubeadm只是其中一种方式，适合个人搭建集群使用，这里要介绍的也就是Kubeadm的工作流程。

Kubeadm分为2个步骤：

kubeadm init
- 用于初始化K8S集群中的Master节点
- 工作流程
  image.png
- 流程说明
  - preflight
    - 进行一系列检查[init之前的检查]，以确定这台机器可以部署kubernetes
    - kubeadm版本与要安装的kubernetes版本的检查
    - kubernetes安装的系统需求检查[centos版本、cgroup、docker等]
    - 用户权限、主机环境、端口是否开放、swap是否关闭等
  - certs
    - 生成kubernetes对外提供服务所需要的各种证书可对应目录，也就是生成私钥和数字证书。证书目录：/etc/kubernetes/pki/
    - 自建ca，生成ca.key和ca.crt
    - apiserver的私钥与公钥证书
    - apiserver访问kubelet使用的客户端私钥与证书
    - sa.key和sa.pub
    - etcd相关私钥和数字证书
  - kubeconfig
    - 为其他组件生成访问kube-ApiServer所需的配置文件 xxx.conf，配置目录：/etc/kubernetes/
      image.png

  + init完成之后我们还需要创建 .kube 文件夹，复制一个配置文件到该目录下，这个步骤就是让当前节点拥有与apiServer打交道的权限。
  + kubeconfig中包含了cluster、user和context信息。通过kubectl config view查看

+ control-plane

  + 为master生成Pod配置文件，这些组件会被master节点上的kubelet读取到，并且自动创建对应资源，Pod的文件目录：/etc/kubernetes/manifests/
  + 这些pod由kubelet直接管理，是静态pod，直接使用主机网络
  + kubelet读取manifests目录并管理各控制平台组件pod的启动与停止
    + 一旦这些 YAML 文件出现在被 kubelet 监视的/etc/kubernetes/manifests/目录下，kubelet就会自动创建这些yaml文件定义的pod，即master组件的容器。master容器启动后，kubeadm会通过检查localhost:6443/healthz这个master组件的健康状态检查URL，等待master组件完全运行起来
  + 要想修改这些pod，直接修改manifests下的yaml文件即可
  + 这个步骤会下载镜像，我们前面已经通过手动下载国内镜像然后打Tag的方式下载好了，所以这个步骤会进行的很快，否则直接从国外地址下会很慢

+ upload-config

  + 将ca.crt等 Master节点的重要信息，通过ConfigMap的方式保存在etcd中，供后续部署node节点使用

+ bootstrap-token

  + 为集群生成一个bootstrap token，设定当前node为master，master节点将不承担工作负载，当然也可以调整让Master承担工作负载。

+ addons

  + 安装默认插件，kubernetes默认kube-proxy和DNS两个插件是必须安装的，dns插件安装了会出于pending状态，要等网络插件安装完成，比如calico
    + 通过kubectl get daemonset -n kube-system
    + 可以看到kube-proxy和calico[或者其他网络插件]

kubeadm join
- 用于将worker节点加入K8S集群中
image.png

流程说明

通过discovery-token-ca-cert-hash验证master身份

# 可以计算出来，在worker节点上执行
openssl x509 -in /etc/kubernetes/pki/ca.crt -noout -pubkey | openssl rsa -pubin -
outform DER 2>/dev/null | sha256sum | cut -d' ' -f1
# 最终hash的值
909adc03d6e4bd676cfc4e04b864530dd19927d8ed9d84e224101ef38ed0bb96

通过token让master可以验证node

# 在master上节点上，可以查看对应的token
kubectl get secret -n kube-system | grep bootstrap-token
# 得到token的值
kubectl get secret/bootstrap-token-kggzhc -n kube-system -o yaml
# 对token的值进行解码
echo NHRzZHp0Y2RidDRmd2U5dw== | base64 -d
# 最终token的值
kggzhc.4tsdztcdbt4fwe9w

因为kubeadm的 join 信息是有时效的，又或者忘了join信息，也可以重新生成

# 重新生成 join 信息，默认有效期24小时,若想久一些可以结合--ttl参数,设为0则用不过期
kubeadm token create --print-join-command

3、kubectl

kubectl 是一个命令行接口，用于对 Kubernetes 集群运行命令。

kubectl 会在 $HOME/.kube 目录中寻找一个名为 config 的文件，通过它就可以与apiServer打交道了。

3.1 kubectl 语法

kubectl [command] [TYPE] [NAME] [flags]

其中 command、TYPE、NAME 和 flags 分别是：

command：指定要对一个或多个资源执行的操作，例如 create、get、describe、delete。
TYPE：指定资源类型。资源类型不区分大小写，可以指定单数、复数或缩写形式。例如，以下命令输出相同的结果:
```
kubectl get pod <pod_name>
kubectl get pods <pod_name>
kubectl get po <pod_name>
```
NAME：指定资源的名称。名称区分大小写。如果省略名称，则显示所有资源的详细信息 kubectl get pods。

在对多个资源执行操作时，可以按类型和名称指定每个资源，或指定一个或多个文件：

要按类型和名称指定资源：
- 要对所有类型相同的资源进行分组，请执行以下操作：TYPE1 name1 name2 name<#>。
  例子：kubectl get pod example-pod1 example-pod2
- 分别指定多个资源类型：TYPE1/name1 TYPE1/name2 TYPE2/name3 TYPE<#>/name<#>。
  例子：kubectl get pod/example-pod1 replicationcontroller/example-rc1
用一个或多个文件指定资源：-f file1 -f file2 -f file<#>
- 使用 YAML 而不是 JSON 因为 YAML 更容易使用，特别是用于配置文件时。
  例子：kubectl get pod -f ./pod.yaml
flags: 指定可选的参数。例如，可以使用 -s 或 -server 参数指定 Kubernetes API 服务器的地址和端口。
- 指定参数会覆盖默认值和任何相应的环境变量。

4、ApiServer

API Server 为 api 对象验证并配置数据，包括 pods、 services、 replicationcontrollers 和其它 api 对象。API Server 提供 REST 操作和到集群共享状态的前端，是集群内各个功能模块之间数据交互和通信的中心枢纽，是整个系统的数据总线和数据中心。所有其他组件通过它进行交互。

API Server通过kube-apiserver的进程提供服务，运行在master节点上

4.1 REST API设计

K8S交互实际是使用 REST API 进行的，kubectl 命令底层实际也是通过这种方式调用。

image.png

如果想要用 http 的方式调用 K8S 的服务，需要进行如下操作：

启用端口
- kubeadm安装方式
  - 其他安装方式怎么启用我也没查过
默认情况下，insecure-port=0，表示不启用
image.png

应用修改

[root@master-kubeadm-k8s ~]# kubectl apply -f /etc/kubernetes/manifests/kube-apiserver.yaml
pod/kube-apiserver created

# 可以看到8088端口已经开始监听
[root@master-kubeadm-k8s ~]# lsof -i tcp:8088
COMMAND     PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
kube-apis 30427 root    3u  IPv4 285948      0t0  TCP master-kubeadm-k8s:radan-http (LISTEN)

测试

可以一个一个去试试看

curl localhost:8088
curl localhost:8088/api
curl localhost:8088/api/v1
curl localhost:8088/api/v1/pods
curl localhost:8088/api/v1/services
image.png

4.2 集群安全机制

对于k8s集群的访问操作，都是通过api server的rest api来实现的，难道所有的操作都允许吗？当然不行，这里就涉及到认证、授权和准入控制等操作。

请求到达 API 服务器后会经过几个阶段，具体说明如图：

image.png

4.2.1 传输层安全

在典型的 Kubernetes 集群中，API 通过 443 端口提供服务。 API 服务器会提供一份证书。该证书一般是自签名的，所以用户机器上的 $USER/.kube/config 目录通常包含该 API 服务器证书的根证书，用来代替系统默认根证书。当用户使用 kube-up.sh 创建集群时，该证书通常会被自动写入用户的 $USER/.kube/config。如果集群中存在多个用户，则创建者需要与其他用户共享证书。

4.2.2 认证(Authentication)

说白了，就是如何来识别客户端的身份，

认证可以分为两个维度来说

第一个维度

K8s集群提供了3种识别客户端身份的方式

HTTPS证书认证
- 基于CA根证书签名的双向数字证书认证方式
HTTP Token认证
- 通过一个Token来识别合法用户
HTTP Base认证
- 通过用户名+密码的方式认证

第二个维度

系统组件要想和apiServer进行认证

Service Account
- 创建service Account会再默认的自动创建一个secret，这个secret会被自动加入到系统中的Pod，上一章我们也演示过了

4.2.3 授权(Authorization)

Kubernetes 使用 API 服务器授权 API 请求。它根据所有策略评估所有请求属性来决定允许或拒绝请求。一个 API 请求的所有部分必须被某些策略允许才能继续。这意味着默认情况下拒绝权限。

4.2.3.1 授权方式

Node
- 一个专用授权程序，根据计划运行的 pod 为 kubelet 授予权限
ABAC
- 基于属性的访问控制（ABAC）定义了一种访问控制范例，通过使用将属性组合在一起的策略，将访问权限授予用户。
- 策略可以使用任何类型的属性（用户属性，资源属性，对象，环境属性等）
RBAC
- 基于角色的访问控制（RBAC）是一种基于企业内个人用户的角色来管理对计算机或网络资源的访问的方法。
- 在此上下文中，权限是单个用户执行特定任务的能力，例如查看，创建或修改文件。
- 当指定的 RBAC（基于角色的访问控制）使用 rbac.authorization.k8s.io API 组来驱动授权决策时，允许管理员通过 Kubernetes API 动态配置权限策略。
- 要启用 RBAC，使用 --authorization-mode = RBAC 启动 apiserver 。
Webhook
- WebHook 是一个 HTTP 回调：发生某些事情时调用的 HTTP POST；通过 HTTP POST 进行简单的事件通知。
- 实现 WebHook 的 Web 应用程序会在发生某些事情时将消息发布到 URL。

我们主要看看最常用的 RBAC 授权方式即可

4.2.3.2 RBAC授权

资源分类
- Role和ClusterRole
  - 在 RBAC API 中，一个角色包含一组相关权限的规则。
  - 权限是纯粹累加的（不存在拒绝某操作的规则）。
  - 角色可以用 Role 来定义到某个命名空间上，或者用 ClusterRole 来定义到整个集群作用域。
- RoleBinding和ClusterRoleBinding
  - 角色绑定（RoleBinding）是将角色中定义的权限赋予一个或者一组用户。
  - 它包含若干主体（用户，组和服务账户）的列表和对这些主体所获得的角色的引用。
  - 可以使用 RoleBinding在指定的命名空间中执行授权，或者在集群范围的命名空间使用 ClusterRoleBinding 来执行授权。
图解说明
- subjects可以理解为是一个用户
- RoleBinding、ClusterBinding是用户与Role、ClusterRole直接的关联关系
- Role、ClusterRole又会关联到资源以及权限
- 整张图理解下来就是：一个用户绑定了什么角色，这个角色可以操作哪些资源

image.png

Role和RoleBinding

一个 Role 只可以用来对某一命名空间中的资源赋予访问权限
一个 RoleBinding 可以引用同一的命名空间中的 Role

通过之前章节中的 NFS 插件的 rbac.yaml 文件来说明

下面的例子中就表示

将名称为：leader-locking-nfs-provisioner 的 Role 绑定到名为：nfs-provisioner 的ServiceAccount 资源上，这样，ServiceAccount就拥有了对 ‘endpoints’ 资源的操作权限

apiVersion: rbac.authorization.k8s.io/v1  # rbac版本
kind: Role                                    # 资源类型为 Role
metadata:
  # 此处的 "namespace" 被省略掉是因为使用的 default 命名空间
  name: leader-locking-nfs-provisioner        # Role资源名称
rules:                                        # 配置权限
  - apiGroups: [""]                           # k8s 的 api 太多了，因此分 group, "" 表示指定核心 API 组
    resources: ["endpoints"]              # 表示当前Role绑定的资源是什么
    verbs: ["get", "list", "watch", "create", "update", "patch"] # 表示对endpoints拥有什么样的操作权限, 根据自己的需要来确定如何填写，全部操作支持用 ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding                         # 绑定角色的资源
metadata:
  name: leader-locking-nfs-provisioner        # 资源名称
subjects:
  - kind: ServiceAccount                  # 使用该角色的资源类型
    name: nfs-provisioner                 # 资源类型名称
    namespace: default
roleRef:                                  # 引用绑定的角色
  kind: Role                              # 资源类型
  name: leader-locking-nfs-provisioner        # Role资源的名称
  apiGroup: rbac.authorization.k8s.io     # 指定api组

RoleBinding 也可以引用 ClusterRole，对 ClusterRole 所定义的、位于 RoleBinding 命名空间内的资源授权。这样开发者就可以在整个集群中定义一组通用的角色，然后在多个命名空间中重用它们。

ClusterRole和ClusterRoleBinding

ClusterRole 可以授予的权限和 Role 相同，但是因为 ClusterRole 属于集群范围，所以它也可以授予以下访问权限：
- 集群范围资源（比如 nodes）
- 非资源端点（比如 “/healthz”）
- 跨命名空间访问的有命名空间作用域的资源（如 Pods），比如运行命令kubectl get pods --all-namespaces 时需要此能力
ClusterRoleBinding 可用来在集群级别或对所有命名空间执行授权

同样通过NFS的rbac.yaml文件说明

下面的例子就表示

将名称为：nfs-provisioner-runner 的ClusterRole 绑定到名称为：nfs-provisioner 的 ServiceAccount 资源上，这样，ServiceAccount 资源就拥有了操作任意命名空间中下面定义的资源的权限

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # 此处的 "namespace" 被省略掉是因为 ClusterRoles 是没有命名空间的。
  name: nfs-provisioner-runner
rules:                                        # 这里让当前ClusterRole拥有多个资源的操作权限
  - apiGroups: [""]
    resources: ["persistentvolumes"]
    verbs: ["get", "list", "watch", "create", "delete"]
  - apiGroups: [""]
    resources: ["persistentvolumeclaims"]
    verbs: ["get", "list", "watch", "update"]
  - apiGroups: ["storage.k8s.io"]
    resources: ["storageclasses"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["events"]
    verbs: ["create", "update", "patch"]
  - apiGroups: [""]
    resources: ["services", "endpoints"]
    verbs: ["get"]
  - apiGroups: ["extensions"]
    resources: ["podsecuritypolicies"]
    resourceNames: ["nfs-provisioner"]
    verbs: ["use"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: run-nfs-provisioner
subjects:
  - kind: ServiceAccount
    name: nfs-provisioner
    namespace: default
roleRef:
  kind: ClusterRole
  name: nfs-provisioner-runner
  apiGroup: rbac.authorization.k8s.io

注意
- 不能修改绑定对象所引用的 Role 或 ClusterRole ，改变 roleRef 会导致验证错误。
- 想要改变现有绑定对象中 roleRef 字段的内容，必须删除并重新创建绑定对象。
- 这种限制有两个主要原因：
  - 关于不同角色的绑定是完全不一样的。更改 roleRef 需要删除/重建绑定，确保要赋予绑定的完整主体列表是新的角色（而不是只是启用修改 roleRef 在不验证所有现有主体的情况下的，应该授予新角色对应的权限）。
  - 使得 roleRef 不可以改变现有绑定主体用户的 update 权限，可以让它们能够管理主体列表，而不能更改授予这些主体相关的角色。

4.2.4 准入控制(Admission Control)

准入控制是能够修改或拒绝请求的软件模块。作为授权模块的补充，准入控制模块会访问被创建或更新的对象的内容。它们作用于对象的创建，删除，更新和连接（proxy）阶段，但不包括对象的读取。可以同时配置多个准入控制器，它们会按顺序依次被调用。

除了拒绝请求外，准入控制器还可以为对象设置复杂的默认值。

与认证和授权模块不同的是，如果任一个准入控制器拒绝请求，那么整个请求会立即被拒绝。

4.2.4.1 准入控制插件

准入控制器是一段代码，它会在请求通过认证和授权之后、对象被持久化之前拦截到达 API 服务器的请求。

准入控制器可以执行 “验证” 和/或 “变更” 操作。变更（mutating）控制器可以修改被其接受的对象；验证（validating）控制器则不行。

准入控制过程分为两个阶段。第一阶段，运行变更准入控制器。第二阶段，运行验证准入控制器。

准入控制模块
- AlwaysPullImages
  - 该准入控制器会修改每一个新创建的 Pod 的镜像拉取策略为 Always
- DefaultStorageClass
  - 该准入控制器监测没有请求任何特定存储类的 PersistentVolumeClaim 对象的创建，并自动向其添加默认存储类
- AlwaysAdmit
  - 该准入控制器会允许所有的 pod 接入集群。在 Kubernetes v1.13 已废弃
- AlwaysDeny
  - 拒绝所有的请求。由于没有实际意义，在 Kubernetes v1.13 已废弃
- ....

5、Scheduler

Scheduler通过 kubernetes 的 watch 机制来发现集群中新创建且尚未被调度到 Node 上的 Pod。

Scheduler会将发现的每一个未调度的 Pod 调度到一个合适的 Node 上来运行。

对每一个新创建的 Pod 或者是未被调度的 Pod，kube-scheduler 会选择一个最优的 Node 去运行这个 Pod。然而，Pod 内的每一个容器对资源都有不同的需求，而且 Pod 本身也有不同的资源需求。所以Pod 在被调度到 Node 上之前，会根据这些特定的资源调度需求，需要对集群中的 Node 进行一次过滤。

5.1 kube-scheduler 调度流程

kube-scheduler 给一个 pod 做调度选择包含两个步骤：

过滤
- 过滤阶段会将所有满足 Pod 调度需求的 Node 选出来。
- 在过滤之后，得出一个 Node 列表，里面包含了所有可调度节点
- 通常情况下，这个 Node 列表包含不止一个 Node。如果是空的，代表这个 Pod 不可调度。
打分
- 在打分阶段，调度器会为 Pod 从所有可调度节点中选取一个最合适的 Node。根据当前启用的打分规则，调度器会给每一个可调度节点进行打分。
- 最后，kube-scheduler 会将 Pod 调度到得分最高的 Node 上。
- 如果存在多个得分最高的 Node，kube-scheduler 会从中随机选取一个。

5.2 Scheduler结构图

image.png

scheduler会监听ApiServer是否有Pod相关的请求，若有则会获取请求到Pod等待队列中
Node相关的请求是无法通过ApiServer监听到的，但是当Node加入集群后会将自身信息存到ETCD中，所以scheduler也可以获取到。
scheduler会通过预选策略筛选和优选策略打分，找到最合适的Node

5.3 预选策略（Predicates）

预选策略会进行初步筛选，找出符合条件的节点

PodFitsHostPorts:检查一个节点是否有Pod所需且空闲的端口(网络协议类型) 。
PodFitsHost:检查一个Pod是否指定了一个特定的节点的主机名。
PodFitsResources:检查节点是否有空闲的资源(比如CPU和内存) 以满足Pod的要求。
PodMatchNodeSelector: 检查节点是否有Pod所指定的标签
........

5.4 优选策略（Priorities）

NodeAffinityPriority：优先选择亲和性高的节点。
ImageLocalityPriority：优先选择本地已经有镜像存在的。
BalancedResourceAllocation：以平衡节点的资源使用情况为优先。
.......

5.5 演示

不修改策略的情况

准备YAML文件

base-scheduler-node.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: scheduler-node
spec:
  selector:
    matchLabels:
      app: scheduler-node
  replicas: 1
  template:
    metadata:
      labels:
        app: scheduler-node
    spec:
      containers:
      - name: scheduler-node
        image: nginx
        ports:
        - containerPort: 80

创建资源

[root@master-kubeadm-k8s scheduler]# kubectl apply -f base-scheduler-node.yaml
deployment.apps/scheduler-node created

查看资源

正常是可以直接创建的，但无法得知它会分配到哪个节点

[root@master-kubeadm-k8s scheduler]# kubectl get pods
NAME                              READY   STATUS    RESTARTS   AGE
scheduler-node-58474cbbb7-m57xm   1/1     Running   0          23s

使用调度策略的情况

准备YAML文件

scheduler-node.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: scheduler-node
spec:
  selector:
    matchLabels:
      app: scheduler-node
  replicas: 1
  template:
    metadata:
      labels:
        app: scheduler-node
    spec:
      containers:
      - name: scheduler-node
        image: nginx
        ports:
        - containerPort: 80
      affinity:                     # 根据亲和性筛选,亲和性就是更愿意运行在什么样的环境下
        nodeAffinity:               # 根据节点的亲和性筛选
          requiredDuringSchedulingIgnoredDuringExecution:   # required表示必须满足的条件
            nodeSelectorTerms:      # 表示节点的标签必须要有 beta.kubernetes.io/arch:amd641
            - matchExpressions:
              - key: beta.kubernetes.io/arch
                operator: In
                values:
                - amd641
          preferredDuringSchedulingIgnoredDuringExecution:  # preferred表示更愿意选择的条件,但不强制要求
          - weight: 1
            preference:
              matchExpressions:
              - key: disktype
                operator: NotIn
                values:
                - ssd

部署资源前先查看node信息

节点中只有标签 beta.kubernetes.io/arch=amd64的，没有值为amd641的，所以如果按上面的YAML文件配置，它是无法部署成功的
image.png

创建资源

[root@master-kubeadm-k8s scheduler]# kubectl apply -f scheduler-node.yaml
deployment.apps/scheduler-node created

查看资源

# 发现是Pending状态
[root@master-kubeadm-k8s scheduler]# kubectl get pods
NAME                              READY   STATUS      RESTARTS   AGE
scheduler-node-795b7f967f-fxr2r   0/1     Pending     0          17s

image.png

> 这里说没用匹配到，因为没有满足我们条件的节点

修改YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: scheduler-node
spec:
  selector:
    matchLabels:
      app: scheduler-node
  replicas: 1
  template:
    metadata:
      labels:
        app: scheduler-node
    spec:
      containers:
      - name: scheduler-node
        image: nginx
        ports:
        - containerPort: 80
      affinity: 
        nodeAffinity: 
          requiredDuringSchedulingIgnoredDuringExecution: 
            nodeSelectorTerms: 
            - matchExpressions:
              - key: beta.kubernetes.io/arch
                operator: In
                values:
                - amd64             # 将这里改成amd64,节点的标签是有这个值的
          preferredDuringSchedulingIgnoredDuringExecution: 
          - weight: 1
            preference:
              matchExpressions:
              - key: disktype
                operator: NotIn
                values:
                - ssd

重新创建资源并查看

[root@master-kubeadm-k8s scheduler]# kubectl apply -f scheduler-node.yaml
deployment.apps/scheduler-node created

# 发现已经正常创建了
[root@master-kubeadm-k8s scheduler]# kubectl get pods
NAME                              READY   STATUS    RESTARTS   AGE
scheduler-node-64574dd96d-x77h9   1/1     Running   0          15s

更多的内容可以到官网查看，这里不深入了

6、kubelet

kubelet 是在每个 Node 节点上运行的主要 “节点代理”。用于处理master节点下发到本节点的任务。
它可以使用主机名（hostname）向 apiserver 注册节点；可以提供用于覆盖主机名的参数；还可以执行特定于某云服务商的逻辑。
kubelet 是基于 PodSpec 来工作的。每个 PodSpec 是一个描述 Pod 的 YAML 或 JSON 对象。
kubelet 通过接受各种机制（主要是通过 apiserver）提供的一组 PodSpec，并确保这些 PodSpec 中描述的容器处于运行状态且运行状况良好。
每个kubelet进程会在API Server上注册节点自身信息，定期向Master节点汇报节点资源的使用情况，并通过cAdvisor监控容器和节点资源。
kubelet 不管理不是由 Kubernetes 创建的容器。
在k8s集群中，每个Node上都会启动一个kubelet服务进程，

7、kube-proxy

Kubernetes proxy在每个节点上运行。

proxy反映了每个节点上 Kubernetes API 中定义的服务，并且可以执行简单的 TCP、UDP 和 SCTP 流转发，或者在一组后端进行循环 TCP、UDP 和 SCTP 转发。

它是Service的透明代理兼负载均衡器，核心功能是将某个Service的访问请求转发到后端的多个Pod实例上

8、kube-controller-manager

Kubernetes 控制器管理器是一个守护进程，嵌入了 Kubernetes 附带的核心控制循环。控制回路是一个永不休止的循环，用于调节系统状态。

它通过 apiserver 监视集群的共享状态，并尝试进行更改以将当前状态转为所需状态。现今，Kubernetes 自带的控制器包括副本控制器，节点控制器，命名空间控制器和serviceaccounts 控制器。

十、Kubernetes 进阶之核心组件篇

1、Master和Node

2、 Kubeadm

3、kubectl

3.1 kubectl 语法

4、ApiServer

4.1 REST API设计

4.2 集群安全机制

4.2.1 传输层安全

4.2.2 认证(Authentication)

4.2.3 授权(Authorization)

4.2.3.1 授权方式

4.2.3.2 RBAC授权

4.2.4 准入控制(Admission Control)

4.2.4.1 准入控制插件

5、Scheduler

5.1 kube-scheduler 调度流程

5.2 Scheduler结构图

5.3 预选策略（Predicates）

5.4 优选策略（Priorities）

5.5 演示

6、kubelet

7、kube-proxy

8、kube-controller-manager

猜你喜欢

热点阅读