K8S概念及k8s Python SDK

0914_h

已于 2023-12-19 14:20:04 修改

阅读量1.7k

点赞数

分类专栏：虚拟化技术文章标签：容器 k8s

于 2022-01-14 16:37:20 首次发布

本文链接：https://blog.csdn.net/huanhuanq1209/article/details/122497587

版权

虚拟化技术专栏收录该内容

6 篇文章 0 订阅

订阅专栏

1.Service:

服务 | Kubernetes

2.生成token

https://jimmysong.io/kubernetes-handbook/guide/auth-with-kubeconfig-or-token.html

知识点：

指定命名空间查看：token(secret)--->serviceaccount（有绑定secrets）-->ClusterRoleBinding/RoleBinding-->ClusterRole/Role

kubectl describe secret -n mesh-demo secret的名字（比如：httpbin-token-gpkww）；#有token和Serviceaccount的对应关系；

kubectl describe serviceaccounts -n 命名空间 Serviceaccount的名字；#有token和Serviceaccount的对应关系；

kubectl describe clusterrolebindings.rbac.authorization.k8s.io -n 命名空间角色绑定名称 #看关联的角色名字；

kubectl describe clusterrole -n 命名空间角色名字 # 查看角色和rule的权限；

2.1secret里面的token和ca.crt是如何确定的???

在 Kubernetes 中，特殊类型的 Secret，如 ServiceAccount tokens 和 TLS 证书，被系统自动创建和管理。例如：

当您创建一个 ServiceAccount（服务帐户）时，系统会自动为该帐户创建一个关联的 Secret，其中包含了一个 JWT token。这个 token 可以用来代表该 ServiceAccount 对 Kubernetes API 的身份验证。
当您使用 Kubernetes 的内置证书管理功能创建一个 CertificateSigningRequest（证书签名请求）时，系统会自动为您创建一个包含签名证书的 Secret。

在这两种情况下，token 和 ca.crt 的值都由 Kubernetes 自动确定。

如果您需要手动创建包含 token 和 ca.crt 的 Secret，那么这些值通常取决于您的具体需求。例如：

token 可以是任何形式的身份验证令牌，如 JWT token 或 OAuth2 token，取决于您的应用程序或服务如何使用它。
ca.crt 通常是一个证书颁发机构（CA）的公钥证书，用于验证服务器或客户端证书的签名。这个值取决于您的网络或安全基础设施。

在创建这类 Secret 时，您需要确保 token 和 ca.crt 的值是 base64 编码的，如前面的回答所述。

3.curl 访问k8s api

如何使用curl访问k8s的apiserver_阿里云云栖号-CSDN博客_k8s 查看apiserver

https://kubernetes.io/zh/docs/tasks/administer-cluster/access-cluster-api/

TOKEN和APISERVER的值按上述链接获取

curl -H "Authorization: Bearer $TOKEN" $APISERVER/apis/networking.istio.io/v1alpha3/namespaces/mesh-demo/sidecars --insecure

或者

curl -H "Authorization: Bearer $TOKEN" $APISERVER/apis/networking.istio.io/v1alpha3/namespaces/命名空间名/serviceentries --insecure | jq

获取某个集群的所有sidecars列表：

curl -H "Authorization: Bearer $TOKEN" $APISERVER/apis/networking.istio.io/v1alpha3/sidecars --insecure | jq

4.用Python访问k8s api:

Python requests 移除SSL认证，verify=False，取消控制台输出的InsecureRequestWarning警告_May女子の博客-CSDN博客_verify

method='get'

api_url='https://apiserver_ip:6443/apis/networking.istio.io/v1alpha3/namespaces/命名空间/sidecars'

authorization='Bearer TOKEN的值'

headers={'authorization':authorization}

import requests

requests.packages.urllib3.disable_warnings()

查询某crd对象列表：reps=requests.request(method, api_url, headers=headers, data=None,params=None,verify=False,timeout=10)

获取响应头：reps.headers.get('Content-Type')

获取响应内容：reps.text等价于上面的curl的结果；

5.sidecar对象：

Istio / Sidecar

6.k8s开放api，获取某service信息：

authorization='Bearer TOKEN的值'

headers={'authorization':authorization}

api_url='https://api-server地址/api/v1/namespaces/命名空间/services/Service名字'

命名空间的API = "/api/v1/"
部署组的API = "/apis/apps/v1/"
服务、pod、事件、node的API = "/api/v1/"
istio的API= 同上

7.Python K8S SDK的使用：

连接集群是通过token的方式：Kubernetes Python Client - 肖祥 - 博客园

连接集群通过kubeconfig方式：https://github.com/kubernetes-client/python

from kubernetes import client, config, watch
config.load_kube_config("{}/xxx.config".format(CUR_DIR))# 指定配置文件所在的目录；

example:python/deployment_crud.py at master · kubernetes-client/python · GitHub

8.statefulset类型的有状态服务：

kind: Service
apiVersion: v1
metadata:
  name: statefulset
spec:
  ports:
    - name: statefulset-80
      protocol: TCP
      port: 80
      targetPort: 80
  selector:
    app: statefulset-test
  clusterIP: None
  type: ClusterIP
  sessionAffinity: None
status:
  loadBalancer: {}

{
    "apiVersion":"apps/v1",
    "kind":"StatefulSet",
    "metadata":{
        "name":"statefulset-test",
        "namespace":"namespaces-test",
        "labels":{
            "app":"statefulset-test"
        }
    },
    "spec":{
        "replicas":1,
        "serviceName":"statefulset",
        "selector":{
            "matchLabels":{
                "app":"statefulset-test"
            }
        },
        "template":{
            "metadata":{
                "labels":{
                    "app":"statefulset-test"
                }
            },
            "spec":{
                "containers":[
                    {
                        "imagePullPolicy":"Always",
                        "securityContext":{
                            "privileged":false
                        },
                        "name":"nginx",
                        "image":"nginx:latest",
                        "resources":{
                            "limits":{
                                "cpu":"100m",
                                "memory":"20Mi"
                            },
                            "requests":{
                                "cpu":"100m",
                                "memory":"20Mi"
                            }
                        }
                    }
                ]
            }
        }
    }
}

List_stateful_set_for_all_namespaces #1718 - Github LabList_stateful_set_for_all_namespaces issue from python/kubernetes-client github repository.https://githublab.com/repository/issues/kubernetes-client/python/1718

用最新版本（23.3.0）存在的问题；

9.亲和性和反亲和性

https://www.cnblogs.com/lnlvinso/p/13599102.html

10.configmap

https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/

配置 Pod 使用 ConfigMap | Kubernetes

K8S进阶实践之 ConfigMap配置文件挂载的使用场景_51CTO博客_k8s中的configmap

10.1 如下配置，volume形式挂载至pod里面，修改configmap，不用重启pod，会动态更新，但需要等待

configmap配置：

pod配置：

修改configmap后，预计4~5s，pod文件内容更新生效

当挂载到空目录时，会生成新的文件；当挂载到非空目录时，会清空此目录下的内容；

10.2 env变量形式，更改configmap，pod不会实时更新；

pod里面的内容：

10.3 envFrom批量导入变量，修改configmap，pod不会实时更新；

configmap的内容：

pod里面的内容：

10.4 volumes.name.configmap.items，pod将被挂载的目录下，将删除原有的非相关文件，修改configmap，pod会动态更新；一般items.path与items.key一致

10.5 子路径挂载（只替换或上传文件，不删除原有目录内容），但修改configmap，pod不会动态更新

kubernetes的configMap文件挂载不同的路径且不覆盖目录的解决方法 · zhangguanzhang's Blog

当没有subpath时，items中的path路径，不起作用，目测

Kubernetes ConfigMap挂载导致容器目录覆盖的问题解决_k8s 挂载而不是覆盖_富士康质检员张全蛋的博客-CSDN博客

11.job任务：

https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/job/

12.pv，pvc

5.简单懂点K8S的存储(Volume/PV/PVC/StorageClass)_哔哩哔哩_bilibili

摘自上述视频：管理员给创建的pv，用户创建pvc，与pv进行绑定就可以了！这样比较麻烦，所以有了storageclass

磁盘1T，管理员会给磁盘创建个storageclass，用户想用5G的存储，则在pvc中可以指明，也会标明前面的storageclass，存储管理器发现有一个pvc创建了，会找存储管理器管理的存储，找相应的storageclass，根据storageclass和pvc，自动创建个pv，最后实现pv和pvc的绑定。

kubectl get storageclasses.storage.k8s.io

定义pvc删除后，pv是保留数据还是删除，是否允许扩容（比如pvc申请的5G，能否扩容到10个G，取决于磁盘是否支持扩容功能）以及pvc和pv是否立刻绑定，还是说pod来消费pvc的时候，才会绑定pv？

13.如何区分动态和静态 PV 方式

静态 PV 和动态 PV 是 Kubernetes 持久卷的两种创建方式，基于存储的预存在与否以及是否需要动态以使用的方式创建存储。

以下是几种区分它们的方法：

1. 预创建的 PV 称为静态 PV。静态 PV 在 Pod 请求存储之前已经存在。管理员需要事先创建好 PV，并通过 API server 将其加入到 Kubernetes 集群。静态 PV 一旦创建，具有固定的大小，无法改变。静态 PVs 没有关联的 StorageClass。不过，它们可以有一个特殊的 storageClassName 属性值“No”, 表示它们实际上是静态的。

2. 相比之下，动态 PV 是根据 Persistent Volume Claim (PVC) 的请求动态创建的。当不存在与 PVC 匹配的 PV 时，根据 PVC 指定的 StorageClass，存储类型可以动态创建。换句话说，StorageClass 在这里起着 Provisioner 的作用，从而将存储后端分配给 Pod。因此，在 PVC 中定义了 StorageClass 通常表明使用的是动态 PV。

有时，为了满足特定的存储需求，可以在 PVC 中设置 storageClassName 为空字符串（""），这将选择静态的 PV 来满足该需求。同时，设置 storageClassName 为 "default" 会将 PVC 绑定到集群的默认 StorageClass。

14.当创建一个deployment时，k8s的架构是如何运转的，以及与webhook是怎么连贯起来走的?

当你在 Kubernetes 中创建一个 Deployment 时，以下是大致的工作流程：

1. 使用命令行工具（如kubectl）创建一个 Deployment 对象，并通过 API 服务器发布到集群。

2. Kubernetes 的 API 服务器接收到创建 Deployment 的请求。在存储到 etcd 数据库中之前，该请求会被发送到一系列的准入控制器。

3. 如果你配置了相应的 webhook（如 ValidatingAdmissionWebhook 或 MutatingAdmissionWebhook），那么在这个阶段，请求会被发送到 webhook。Webhook 可以修改请求中的对象（如果是 Mutating 类型的 webhook），或决定是否接受该请求（如果是 Validating 类型的 webhook）。

4. 如果请求通过了所有的准入控制器（包括 webhook），则 Deployment 对象会被存储在 etcd 中。

5. 持续控制器（Deployment controller）会监视新创建的 Deployment，并根据 Deployment 描述创建一个 ReplicaSet。

6. ReplicaSet 控制器会注意到需要创建新的 Pod 以满足其需求，并开始创建新的 Pod。

7. 调度器会将创建出的 Pod 调度到可用的节点。

8. 然后，kubelet（在每个节点上运行的代理）会接收到分配给它的 Pod，并开始创建容器。

9. 容器运行时（如 Docker 或 containerd）开始运行和管理 Pod 中的容器。

10. 在 Pod 成功运行后，Service 和 Ingress 对象（如果有的话）会处理来自或发送到该 Pod 的所有网络流量。

在整个过程中，webhook 能提供一个在请求通过 Kubernetes API 服务器时进行拦截的机会。这使得开发人员可以编写自定义逻辑，例如验证传入对象的某些字段，或自动添加或修改传入对象的某些内容。这种拦截机制使得 Kubernetes 在默认操作基础上有了更多的扩展性。

15.通过prestophook执行sleep卡在terminating ，prestophook是什么?

preStopHook 是 Kubernetes 的生命周期钩子之一，用于在 Pod 的容器终止之前运行一些特定的命令或操作。它可以方便地让你在容器停止之前做一些清理或者准备工作。

当 Kubernetes 收到一个停止容器的请求时，首先会运行 preStopHook 中定义的命令，然后等待一段时间，该时间由 Pod Spec 中的 `terminationGracePeriodSeconds` 字段指定。然后，Kubernetes 会发送 SIGTERM 信号到容器中主进程，然后过一段时间后（默认为30秒，除非你在 pod spec 中指定），容器就会被强制停止。

可能你在删除 pod 时发现它卡在了 `Terminating` 状态，这可能是因为 preStopHook 中的命令运行时间过长或者出错。这时，最好的办法是检查一下在 preStopHook 中运行的什么命令，然后确认是否有错误或者是否运行时间过长。

例如，如果你运行的是 "sleep" 命令，容器可能会在 `Terminating` 状态停止一段时间。比如，如果你运行 "sleep 60"，Kubernetes 就会等待 60 秒才会发送 SIGTERM 信号以关闭容器。因此，这可能是导致 Pod 陷入 `Terminating` 状态的原因之一。

16.如何设置preStopHook 中运行的命令？

在Kubernetes中，你可以在Pod的配置文件中，为指定的容器设置`preStop`生命周期钩子。

下面的例子展示了一个`preStop`钩子，它在容器停止前会运行`/bin/bash`脚本：

```yaml
apiVersion: v1
kind: Pod
metadata:
name: lifecycle-demo
spec:
containers:
- name: lifecycle-demo-container
image: nginx
lifecycle:
preStop:
exec:
command: ["/bin/bash","-c","<your-command>"]
```

在这个例子里，`<your-command>`是在Pod停止前你想要运行的命令，你需要用你真实的命令替换过来。

Lifecycle的`preStop`钩子可以让你在Pod停止前有机会做一些清理工作，比如关闭打开的连接，保存状态到持久化存储，发送通知等等。

注意：
- `preStop`钩子不会阻止容器停止，只能延缓一段时间。当Kubernetes发送停止容器请求后，首先会调用`preStop`钩子，然后再等待一段时间（可配置）。然后再真正停止容器。
- 如果Pod的`terminationGracePeriodSeconds`设置过小，可能会在`preStop`钩子还没完成时，容器就被Kubernetes强制停止。所以，你应该根据`preStop`钩子需要的时间，适当设置`terminationGracePeriodSeconds`的值。
- `preStop`钩子和容器的主进程是并行运行的，也就是说，`preStop`钩子不会等待容器的主进程结束再开始运行。
- 如果`preStop`和容器主进程，都在`terminationGracePeriodSeconds`时间结束前没完成，都会被Kubernetes强制终止。

17.terminationGracePeriodSeconds跟prestophook有关系吗？

是的，`terminationGracePeriodSeconds`和`preStop`钩子的运行是有关联的。

当你试图终止一个 Pod 的时候，Kubernetes 首先会运行你在 Pod 配置中设定的 `preStop` 钩子。在 `preStop` 钩子的命令运行完成后，Kubernetes 会等待 `terminationGracePeriodSeconds` 这个设定的时间，然后才真正停止容器。

`terminationGracePeriodSeconds` 这个周期允许容器在接收到终止信号后进行清理工作。这个值默认是30秒。

这意味着如果 `preStop` 钩子的命令运行时间过长，并且超过了 `terminationGracePeriodSeconds` 的设定值，那么 Kubernetes 不会等待 `preStop` 钩子完全执行完，而会在设定的时间后立即停止容器。同样的，若容器的主进程在接收到 SIGTERM 信号后未在 `terminationGracePeriodSeconds` 内结束，也会被 Kubelet 用 SIGKILL 信号强制终止。

如果你的 Pod 配置了 `preStop` 钩子，并且需要一些时间来运行，你可能需要增加 `terminationGracePeriodSeconds` 的值，以确保 `preStop` 钩子有足够的时间来执行。

18.针对pytorchjob的任务，如何增加 terminationGracePeriodSeconds 的值？

`terminationGracePeriodSeconds` 是在 Kubernetes 的 Pod 规格中设置的。对于 PyTorchJob，其实际上创建了一组相关的 Pod 来执行 PyTorch 任务，因此你需要在 PyTorchJob 规格中对每个 Pod 配置适当的 `terminationGracePeriodSeconds`。

下面是 PyTorchJob 中设置 `terminationGracePeriodSeconds` 的一个示例：

```yaml
apiVersion: "kubeflow.org/v1"
kind: "PyTorchJob"
metadata:
  name: "pytorchjob-example"
spec:
  pytorchReplicaSpecs:
    Master:
      replicas: 1
      template:
        spec:
          terminationGracePeriodSeconds: 60
          containers:
            - name: pytorch
              image: pytorch/pytorch:1.0-cpu
    Worker:
      replicas: 2
      template:
        spec:
          terminationGracePeriodSeconds: 60
          containers:
            - name: pytorch
              image: pytorch/pytorch:1.0-cpu
```

在这个示例中，对于 PyTorchJob 中的 Master 和 Worker pod，我们都设置了 `terminationGracePeriodSeconds` 为 60 秒。这样在 Master 和 Worker pod 结束运行时，它们将有最多 60 秒的时间来运行任何 `preStop` 钩子并优雅地终止。

不过需要注意的是，增加 `terminationGracePeriodSeconds` 会使得 Pod 在被删除时需要更长的时间。所以除非你确实需要更长的时间来清理，否则不建议随意增加这个值。

19.kubectl logs原理

kubectl logs原理 · 个人笔记

20、k8s中MutatingWebhookConfiguration webhook和webhook进程的关系是什么，以volcano的pod mutate和admission为例进行解释

在 Kubernetes 中，MutatingWebhookConfiguration 是一种 API 资源，用于配置 mutator webhook。Mutator webhook 是一种 HTTP 回调，它会在 API 请求到达 apiserver，但在对象持久化之前接收到请求。这允许 webhook 对即将创建或更新的对象进行修改。

Webhook 进程是运行在 Kubernetes 集群内或外的一个 HTTP 服务，它实现了 webhook 的逻辑。当 Kubernetes apiserver 收到一个 API 请求并需要调用 webhook 时，它会向 webhook 进程发送一个 HTTP 请求，包含有关即将创建或更新的对象的信息。

以 Volcano 的 Pod mutate webhook 为例，Volcano 是一个 Kubernetes 原生批处理系统，它提供了 Pod mutator webhook 用于修改 Job 中的 Pod。当用户创建一个 Volcano Job 时，会先创建一个包含 Job 信息的 Pod。在 Pod 被持久化到 etcd 之前，apiserver 会将 Pod 发送给 Volcano 的 Pod mutator webhook。这个 webhook 运行在 Volcano 的 admission controller 中，它会根据 Job 的需求修改 Pod，例如添加或修改容器，设置资源需求等，然后返回修改后的 Pod 给 apiserver。

在这个过程中，MutatingWebhookConfiguration 是定义 webhook 如何与 apiserver 交互的配置，而 webhook 进程（Volcano 的 admission controller）则实现了 webhook 的具体逻辑。

21、若webhook的进程挂掉了admission controller，则webhook会有效吗？failurePolicy: ignore会变成fail吗？

如果 webhook 进程挂掉（即 Kubernetes apiserver 无法访问 webhook 服务），webhook 将无法执行预期功能。但是，webhook 是否仍然允许请求通过，取决于 failurePolicy 的配置。

failurePolicy 字段决定了当 webhook 出现故障（例如网络问题，webhook 服务不可用等）时，应该如何处理请求。它有两个可能的值：Ignore 和 Fail。

Ignore：表示即使 webhook 出现故障，请求仍然应该被允许。也就是说，如果 webhook 服务挂掉，而 failurePolicy 设置为 Ignore，那么请求仍会被允许，但 webhook 将无法修改或拒绝请求。
Fail：表示如果 webhook 出现故障，请求应该被拒绝。也就是说，如果 webhook 服务挂掉，而 failurePolicy 设置为 Fail，那么请求将会被拒绝。

所以，如果 webhook 进程挂掉，failurePolicy: Ignore 不会变成 Fail，仍然会按照 Ignore 的策略处理，即允许请求通过。