K8S概念及k8s Python SDK

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的权限；

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",""]
```

在这个例子里，``是在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 在被删除时需要更长的时间。所以除非你确实需要更长的时间来清理，否则不建议随意增加这个值。