k8s学习之路 | Day11 k8s 对象（一）

已于 2023-02-20 16:07:18 修改
阅读量296 收藏
点赞数 1
分类专栏： Kubernetes 文章标签： kubernetes 学习 运维 云原生 容器
于 2023-02-20 16:00:18 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/whale0306/article/details/129126036
版权

文章目录


官方阅读文档：https://kubernetes.io/zh-cn/docs/concepts/overview/working-with-objects/kubernetes-objects/

k8s 对象

  • k8s 里面操作的资源实体，就是 k8s 的对象

    • 可以使用 yaml来声明
    • 可以直接使用kubectl命令来创建
    • 比如 pod、service、deploy、node…

  • 操作 k8s 对象，无论是什么操作（创建、修改、删除），都是需要使用 kubetnetes API

    • kubectl也是调用的必要的kubernetes API
    • 也可以在程序中使用客户端库来直接调用kubernetes API

  • 在 Kubernetes 系统中，Kubernetes 对象 是持久化的实体。 Kubernetes 使用这些实体去表示整个集群的状态。 比较特别地是，它们描述了如下信息：

    • 哪些容器化应用正在运行（以及在哪些节点上运行）
    • 可以被应用使用的资源
    • 关于应用运行时表现的策略，比如重启策略、升级策略以及容错策略

  • Kubernetes 对象是“目标性记录” —— 一旦创建该对象，Kubernetes 系统将不断工作以确保该对象存在。 通过创建对象，你就是在告知 Kubernetes 系统，你想要的集群工作负载状态看起来应是什么样子的， 这就是 Kubernetes 集群所谓的 期望状态（Desired State）

对象规约（Spec）与状态（Status）

每一个 k8s 对象几乎都包含了2个嵌套的对象字段，他们负责管理对象的配置

  • 对象spec（规约）：必须在创建对象时设置其内容，描述你所希望对象的期望状态
#比如你要运行一个pod,通过kubectl run 来操作的
#这个时候对于 nginx-demo 这个pod来说，你的期望状态就是运行一个pod，利用镜像nginx
kubectl run nginx-demo --image=nginx:1.21-alpine
  • 对象status（状态）：描述了当前对象的当前状态，是由系统组件设置并随时更新的，在任何时刻，k8s 的控制平面都会一直积极地管理着对象的实际状态，并让它达到期望状态（spec）
  • kubelet就是做一件事情：对象的spec和status最终一致性

描述 k8s 对象

创建 Kubernetes 对象时，必须提供对象的 spec，用来描述该对象的期望状态， 以及关于对象的一些基本信息（例如名称）等

  • 推荐使用yaml文件来描述 k8s 对象
  • kubectl 在发起 API 请求时，会将文件信息转换成 JSON 格式

获取具体对象的yaml文件

如何获取已存在的 k8s 对象的 yaml描述文件呢？从下面这个例子能看到

  • spec: 当前pod对象的期望状态
  • status: 当前pod对象的当前状态
[root@k8s-01 ~]# kubectl get pod -oyaml nginx-demo
apiVersion: v1
kind: Pod
metadata:
  annotations:
    cni.projectcalico.org/podIP: 192.168.0.31/32
    cni.projectcalico.org/podIPs: 192.168.0.31/32
  creationTimestamp: "2023-02-20T04:29:18Z"
  labels:
    run: nginx-demo
  name: nginx-demo
  namespace: default
  resourceVersion: "77219"
  uid: 94ffbebd-0ac1-40bf-a890-ce08e827d024
spec:
  containers:
  - image: nginx:1.21-alpine
    imagePullPolicy: IfNotPresent
    name: nginx-demo
    resources: {}
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-api-access-b48j8
      readOnly: true
  dnsPolicy: ClusterFirst
  enableServiceLinks: true
  nodeName: k8s-03
  preemptionPolicy: PreemptLowerPriority
  priority: 0
  restartPolicy: Always
  schedulerName: default-scheduler
  securityContext: {}
  serviceAccount: default
  serviceAccountName: default
  terminationGracePeriodSeconds: 30
  tolerations:
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
    tolerationSeconds: 300
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 300
  volumes:
  - name: kube-api-access-b48j8
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          expirationSeconds: 3607
          path: token
      - configMap:
          items:
          - key: ca.crt
            path: ca.crt
          name: kube-root-ca.crt
      - downwardAPI:
          items:
          - fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
            path: namespace
status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: "2023-02-20T04:29:18Z"
    status: "True"
    type: Initialized
  - lastProbeTime: null
    lastTransitionTime: "2023-02-20T04:29:20Z"
    status: "True"
    type: Ready
  - lastProbeTime: null
    lastTransitionTime: "2023-02-20T04:29:20Z"
    status: "True"
    type: ContainersReady
  - lastProbeTime: null
    lastTransitionTime: "2023-02-20T04:29:18Z"
    status: "True"
    type: PodScheduled
  containerStatuses:
  - containerID: docker://feaa5652cb9a820627fc37b182345e08bc5f0b0224ec5393b715c9fcba6aa2ae
    image: nginx:1.21-alpine
    imageID: docker-pullable://nginx@sha256:eb05700fe7baa6890b74278e39b66b2ed1326831f9ec3ed4bdc6361a4ac2f333
    lastState: {}
    name: nginx-demo
    ready: true
    restartCount: 0
    started: true
    state:
      running:
        startedAt: "2023-02-20T04:29:19Z"
  hostIP: 192.168.204.55
  phase: Running
  podIP: 192.168.0.31
  podIPs:
  - ip: 192.168.0.31
  qosClass: BestEffort
  startTime: "2023-02-20T04:29:18Z"

一个 k8s 对象示例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2 # 告知 Deployment 运行 2 个与该模板匹配的 Pod
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2 # 镜像的标签信息
        ports:
        - containerPort: 80

如何使用yaml文件

kubectl apply -f test.yaml
kubectl delete -f test.yaml

image-20230220125823173

描述对象文件的必要字段信息

  • apiVersion - 创建该对象所使用的 Kubernetes API 的版本
  • kind - 想要创建的对象的类别
  • metadata - 帮助唯一标识对象的一些数据，包括一个 name 字符串、UID 和可选的 namespace
  • spec - 你所期望的该对象的状态

Kubernetes API 参考

如何编写任意资源的 yaml 文件？

通过任意存在的对 象资源反向推理yaml文件

  1. 比如我通过kubectl run创建了一个 pod 资源
##这个操作就会最终启动一个pod
kubectl run tomcat --image=tomcat

image-20230220130751307

  1. 随便在集群里面找一个 pod，将yaml输出出来，只需要除了status状态的内容，比如我将上面的pod通过yaml输出出来
###将集群中的任意一个pod通过yaml输出
kubectl get pod tomcat -o yaml

###得到内容
apiVersion: v1
kind: Pod
metadata:
  annotations:
    cni.projectcalico.org/podIP: 192.168.0.33/32
    cni.projectcalico.org/podIPs: 192.168.0.33/32
  creationTimestamp: "2023-02-20T05:07:04Z"
  labels:
    run: tomcat
  name: tomcat
  namespace: default
  resourceVersion: "80605"
  uid: eceea838-23c9-4cd8-b175-834f5ca034ec
spec:
  containers:
  - image: tomcat
    imagePullPolicy: Always
    name: tomcat
    resources: {}
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-api-access-xfngv
      readOnly: true
  dnsPolicy: ClusterFirst
  enableServiceLinks: true
  nodeName: k8s-03
  preemptionPolicy: PreemptLowerPriority
  priority: 0
  restartPolicy: Always
  schedulerName: default-scheduler
  securityContext: {}
  serviceAccount: default
  serviceAccountName: default
  terminationGracePeriodSeconds: 30
  tolerations:
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
    tolerationSeconds: 300
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 300
  volumes:
  - name: kube-api-access-xfngv
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          expirationSeconds: 3607
          path: token
      - configMap: 
          items:
          - key: ca.crt
            path: ca.crt
          name: kube-root-ca.crt
      - downwardAPI:
          items:
          - fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
            path: namespace
  1. 将上面输出出来的yaml修改一下镜像和说明信息，就可以直接拿来用了，
###将上面输出的yaml文件稍微修改一下
apiVersion: v1
kind: Pod
metadata:
  annotations:
    cni.projectcalico.org/podIP: 192.168.0.33/32
    cni.projectcalico.org/podIPs: 192.168.0.33/32
  creationTimestamp: "2023-02-20T05:07:04Z"
  labels:
    run: nginx
  name: nginx
  namespace: default
  resourceVersion: "80605"
  uid: 3808fb74-f56e-4969-b74c-52a8ceb6ea9d
spec:
  containers:
  - image: nginx
    imagePullPolicy: Always
    name: nginx
    resources: {}
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-api-access-xfngv
      readOnly: true
  dnsPolicy: ClusterFirst
  enableServiceLinks: true
  nodeName: k8s-03
  preemptionPolicy: PreemptLowerPriority
  priority: 0
  restartPolicy: Always
  schedulerName: default-scheduler
  securityContext: {}
  serviceAccount: default
  serviceAccountName: default
  terminationGracePeriodSeconds: 30
  tolerations:
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
    tolerationSeconds: 300
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 300
  volumes:
  - name: kube-api-access-xfngv
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          expirationSeconds: 3607
          path: token
      - configMap: 
          items:
          - key: ca.crt
            path: ca.crt
          name: kube-root-ca.crt
      - downwardAPI:
          items:
          - fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
            path: namespace
## 尝试一下行不行
kubectl apply -f test.yaml

##这种方法是可行的，但是不知道其他字段信息与其他资源有重复，会不会有问题，这个后面深究一下

image-20230220132646979

干跑一遍对象资源输出为yaml文件

  1. 不会实际产生k8s资源对象
##比如我要deploy一次
kubectl create deploy my-nginx --image=nginx --dry-run -oyaml

##然后形成了yaml文件
apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: my-nginx
  name: my-nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-nginx
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: my-nginx
    spec:
      containers:
      - image: nginx
        name: nginx
        resources: {}
##k8s集群环境中也不会正式生成该资源对象信息
##这个方法挺靠谱一点

image-20230220133301071

  1. 尝试修改一下上面的yaml文件
apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: tomcat
  name: tomcat
spec:
  replicas: 1
  selector:
    matchLabels:
      app: tomcat
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: tomcat
    spec:
      containers:
      - image: tomcat
        name: tomcat
        resources: {}
        
##部署一下
kubectl apply -f test.yaml

image-20230220133740967

能够描述的资源类型

kubectl api-resources的KIND字段

image-20230220133835727

apiVersion: apps/v1			## 同一资源多个版本（kubectl api-resources 中的APIVERSION字段）
kind: Deployment			## 资源类型 kubectl api-resources
metadata:					## 每一个资源定义一些元数据信息
  creationTimestamp: null
  labels:
    app: tomcat
  name: tomcat
spec:						## 资源的规约（期望状态：自定义）：镜像名称、版本、环境变量等
  replicas: 1
  selector:
    matchLabels:
      app: tomcat
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: tomcat
    spec:
      containers:
      - image: tomcat
        name: tomcat
        resources: {}

k8s 对象 yaml 的构成

image-20230220134455795

typeMeta

  1. 对于 kind，通过kubectl api-resources字段中的KIND字段，要写什么？比如pod
kubectl api-resources | grep -E 'pod|KIND'

image-20230220134800908

  1. 所以对于pod来说，我们自己写的话，前段部分的内容就可以写成
kind: Pod
apiVersion: v1

metadata

元数据信息，这个地方到底能写一些什么元数据信息呢？

##比如给这次pod写上一个名字
metadata:
  name: nginx-demo-pod

spec

容器的期望状态

spec:	# 指定期望状态
  containers:	# 指定要启动一个什么样的容器
  - image: nginx	# 指定镜像
    name: nginx-demo-pod	# 指定容器名称

status

这段信息是 k8s 集群自己实时更新的信息，不需要我们来指定，只要资源变化，kubelet 会请求 api-server 保存最新的资源状态信息。

最简单的一个描述文件

kind: Pod
apiVersion: v1
metadata:
  name: nginx-demo-pod
spec:	# 指定期望状态
  containers:	# 指定要启动一个什么样的容器
  - image: nginx	# 指定镜像
    name: nginx-demo-pod	# 指定容器名称

image-20230220140108592

管理 k8s 对象

管理技术作用于建议的环境支持的写者学习难度
指令式命令活跃对象（kubectl 命令系列 ）开发项目1+最低
指令式对象配置单个文件（单个yaml文件）生产项目1中等
声明式对象配置文件目录（多个yaml文件的多个目录kustomize）生产项目1+最高
  • 同一个资源对象应该只使用一种方式管理，否则可能会出现不可预期的结果

指令式命令

使用指令式命令时，用户可以在集群中的活动对象上进行操作。用户将操作传给 kubectl 命令作为参数或标志。

  • 例如
kubectl create deployment nginx --image nginx

与对象配置相比的优点：

  • 命令用单个动词表示。
  • 命令仅需一步即可对集群进行更改。

与对象配置相比的缺点：

  • 命令不与变更审查流程集成。
  • 命令不提供与更改关联的审核跟踪。
  • 除了实时内容外，命令不提供记录源。
  • 命令不提供用于创建新对象的模板。

指令式对象配置

在指令式对象配置中，kubectl 命令指定操作（创建，替换等），可选标志和至少一个文件名。指定的文件必须包含 YAML 或 JSON 格式的对象的完整定义。

  • 例如
kubectl create -f nginx.yaml
kubectl delete -f nginx.yaml -f redis.yaml
kubectl replace -f nginx.yaml

与指令式命令相比的优点：

  • 对象配置可以存储在源控制系统中，比如 Git。
  • 对象配置可以与流程集成，例如在推送和审计之前检查更新。
  • 对象配置提供了用于创建新对象的模板。

与指令式命令相比的缺点：

  • 对象配置需要对对象架构有基本的了解。
  • 对象配置需要额外的步骤来编写 YAML 文件。

与声明式对象配置相比的优点：

  • 指令式对象配置行为更加简单易懂。
  • 从 Kubernetes 1.5 版本开始，指令对象配置更加成熟。

与声明式对象配置相比的缺点：

  • 指令式对象配置更适合文件，而非目录。
  • 对活动对象的更新必须反映在配置文件中，否则会在下一次替换时丢失。

声明式对象配置

使用声明式对象配置时，用户对本地存储的对象配置文件进行操作，但是用户未定义要对该文件执行的操作。 kubectl 会自动检测每个文件的创建、更新和删除操作。 这使得配置可以在目录上工作，根据目录中配置文件对不同的对象执行不同的操作。

  • 例如
kubectl diff -f configs/
kubectl apply -f configs/
kubectl diff -R -f configs/
kubectl apply -R -f configs/

  • 与指令式对象配置相比的优点：

    • 对活动对象所做的更改即使未合并到配置文件中，也会被保留下来。
    • 声明性对象配置更好地支持对目录进行操作并自动检测每个文件的操作类型（创建，修补，删除）。

  • 与指令式对象配置相比的缺点：

    • 声明式对象配置难于调试并且出现异常时结果难以理解。
    • 使用 diff 产生的部分更新会创建复杂的合并和补丁操作。

对象名称

  • 集群中的每一个对象都有一个名称来标识在同类资源中的唯一性

  • 每个 Kubernetes 对象也有一个 UID 来标识在整个集群中的唯一性

  • 在同一个名称空间 中只能有一个名为 myapp-1234 的 Pod，但是可以命名一个 Pod 和一个 Deployment 同为 myapp-1234

  • 对于用户提供的非唯一性的属性，Kubernetes 提供了标签（Label）和 注解（Annotation）机制

名称规则

  1. 依据命名规则，Kubernetes对象的名字应该：

  2. 最长不超过 253个字符

  3. 必须由小写字母、数字、减号 - 、小数点 . 组成

  4. 某些资源类型有更具体的要求

UID

UID 是由 Kubernetes 系统生成的，唯一标识某个 Kubernetes 对象的字符串。Kubernetes集群中，每创建一个对象，都有一个唯一的 UID。用于区分多次创建的同名对象（如前所述，按照名字删除对象后，重新再创建同名对象时，两次创建的对象 name 相同，但是 UID 不同。）

名称空间

在 Kubernetes 中，名称空间（Namespace） 提供一种机制，将同一集群中的资源划分为相互隔离的组。 同一名称空间内的资源名称要唯一，但跨名称空间时没有这个要求。 名称空间作用域仅针对带有名称空间的对象，例如 Deployment、Service 等， 这种作用域对集群访问的对象不适用，例如 StorageClass、Node、PersistentVolume 等。

默认的名称空间

[root@k8s-01 ~]# kubectl get namespace
NAME                   STATUS   AGE
default                Active   8d
kube-node-lease        Active   8d
kube-public            Active   8d
kube-system            Active   8d
kubernetes-dashboard   Active   4d21h
[root@k8s-01 ~]#
  • default ：默认名称空间，如果 Kubernetes 对象中不定义 metadata.namespace 字段，该对象将放
    在此名称空间下
  • kube-system ：Kubernetes系统创建的对象放在此名称空间下
  • kube-public ：此名称空间自动在安装集群是自动创建，并且所有用户都是可以读取的（即使是那些
    未登录的用户）。主要是为集群预留的，例如，某些情况下，某些Kubernetes对象应该被所有集群
    用户看到。

如何使用名称空间

  1. 基于环境的隔离，（开发环境？测试环境？生产环境？）

  2. 基于产品线的名称空间隔离，（安卓？ios？）

  3. 基于团队的隔离

如何创建？

老办法了

  1. kubectl create namespace test1 --dry-run=client -oyaml

  2. 得到输出内容

apiVersion: v1
kind: Namespace
metadata:
  creationTimestamp: null
  name: test1
spec: {}
  1. 根据内容创建2个名称空间
##第一个
apiVersion: v1
kind: Namespace
metadata:
  creationTimestamp: null
  name: test1
spec: {}

##第二个
apiVersion: v1
kind: Namespace
metadata:
  creationTimestamp: null
  name: test2
spec: {}

##创建
kubectl apply -f test1.yaml
kubectl apply -f test2.yaml

image-20230220145202736

  1. 分别在这2个名称空间部署一次
## test1
kind: Pod
apiVersion: v1
metadata:
  name: nginx-demo-pod
  namespace: test1	#不写就是default
spec:	# 指定期望状态
  containers:	# 指定要启动一个什么样的容器
  - image: nginx	# 指定镜像
    name: nginx-demo-pod	# 指定容器名称
    
## test2
kind: Pod
apiVersion: v1
metadata:
  name: nginx-demo-pod
  namespace: test2	#不写就是default
spec:	# 指定期望状态
  containers:	# 指定要启动一个什么样的容器
  - image: nginx	# 指定镜像
    name: nginx-demo-pod	# 指定容器名称
    
##分别部署
kubectl apply -f test1.yaml
kubectl apply -f test2.yaml

image-20230220154615836

测试不同名称空间的网络互通情况

  • pod 之间应该是可以互通的

image-20230220155155413

查询k8s 资源是否存在名称空间

# 存在名称空间的资源输出
kubectl api-resources --namespaced=true

# 不存在名称空间的资源输出
kubectl api-resources --namespaced=false
  • 其实就是kubectl api-resources 的【NAMESPACED】字段为：true/false
小鲸鱼大梦想
关注
  • 1
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
k8s容器管理工具视频教程.zip
02-19
k8s-day1 01-k8s集群的安装.mp4 02-为什么要使用k8s.mp4 03-k8s的功能特性和基础架构.mp4 04-k8s的基础单元pod.mp4 k8s-day2 01-副本控制器rc.mp4 02-新副本控制器deployment.mp4 03-容器的网络访问service.mp4 04-...
一周撸完K8S基础概念 Day2
m0_51078839的博客
05-31 70
创建K8S对象的时候必须提供对象的spec用来描述对象的期望状态，以及对象的 一些基本信息（name kind），当时用API创建独享的时候，API在请求主体中应该包含JSON格式的数据，大部分情况下我们提供的是。字段，用于引用其属主对象，一个有效的属主引用，包含与属主对象同在一个命名空间下的对象名称和一个UID，K8S自动为一些对象的附属资源设置属主引用的值，这些对象包含了。元数据围绕应用的概念进行组织，K8S不是平台即服服务，应用程序是非正式的，并且使用元数据进行描述，应用程序包含的定义应该是送伞的。
【K8S 系列】k8s 核心概念
最新发布
m0_73901077的博客
12-10 1387
（2）副本(replicas)：一个 Pod 可以被复制成多份，每一份可被称之为一个“副本”，这些“副本”除了一些描述性的信息（Pod 的名字、uid 等）不一样以外，其它信息都是一样的，譬如 Pod 内部的容器、容器数量、容器里面运行的应用等的这些信息都是一样的，这些副本提供同样的功能。（3）downwardAPI 这个模式和其他模式不一样的地方在于它不是为了存放容器的数据也不是用来进行容器和宿主机的数据交换的，而是让 pod 里的容器能够直接获取到这个 pod 对象本身的一些信息。
k8s-Pod介绍及状态与生命周期管理
Mclaughling的博客
10-28 2413
Pod介绍及状态与生命周期管理 Pod介绍 Pod是kubernetes中可以创建和部署的最小单位。Pod代表着集群中运行的进程。 Pod的设计理念是支持多个容器在一个Pod中共享网络地址和文件系统，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。 Pod中封装着应用的容器（有的情况下是好几个容器），存储、独立的网络IP，管理容器如何运行的策略选项。Pod代表着部署的一个单位：kubernetes中应用的一个实例，可能由一个或者多个容器组合在一起共享资源。 Docker是kubernetes中最
k8s Pod调度失败（NoExecute）排查及分析
热门推荐
u012516914的专栏
11-23 1万+
问题背景k8s集群，总共5个节点，信息如下所示：集群污点k8s版本系统版本master无1.14Centos 7.1work1有1.14Centos 7.1work2无1.14Cento...
k8s部署文件
努力学习，努力爱你！
08-11 364
#k8s部署文件 以及 service暴露文件在项目deploy下创建prod/prod.yaml。
k8s关于pod的metadata、spec.containers、spec.volumes的属性介绍（yaml格式）
树下一少年的博客
11-12 1743
一.metadata常用属性 二.spec.containers子属性介绍 explain pod.spec.containers给出的参考 1.command示例 2.env和envFrom示例 3.ports部分详解 4.resources部分详解 5.startupProbe格式 6.terminationMessagePath和terminationMessagePolicy格式 7.volumeDevices格式 8.volumeMounts格式 三.spec.volumes子属性介绍
云原生k8s部署流水线
09-22
云原生k8s部署流水线
k8s-day01.docx
10-25
k8s-day01.docx
k8s-day-orange:Kubernetes东西的游乐场
05-01
K8s日 在GCP上设置k8。 笔记 设置容器 cd webserver docker build . 代理到远程控制平面 kubectl proxy 部署控制器令牌 kubectl -n kube-system describe secret $( kubectl -n kube-system get secret ) 日志 ...
K8s云原生部署中间件
09-21
在现代企业IT环境中，云原生（Cloud Native）已经成为一种重要的技术趋势，它强调利用容器化、微服务、持续交付和...对于想要深入学习这一领域的读者，可以参考01_笔记中的详细内容，进一步了解K8s在实践中的应用。
k8s之无状态服务Deployment1
m0_58292366的博客
08-03 669
用于部署无状态的服务，这个最常用的控制器。一般用于管理维护企业内部无状态的微服务，比如configserver、zuul、springboot。他可以管理多个副本的Pod实现无缝迁移、自动扩容缩容、自动灾难恢复、一键回滚等功能。UP-TO-DATE:已经达到期望状态的被更新的副本数。READY:Pod的状态，已经Ready的个数。AVALABLE:已经可以用的副本数。SELECTOR:管理的Pod的标签。3、deployment状态解析。2、Deployment创建方式。IMAGES:容器的镜像。...
k8s 污点和容忍
看，未来的博客
09-25 3478
在 Kubernetes 中，节点亲和性 NodeAffinity 是 Pod 上定义的一种属性，能够使 Pod 按我们的要求调度到某个节点上，而 Taints(污点) 则恰恰相反，它是 Node 上的一个属性，可以让 Pod 不能调度到带污点的节点上，甚至会对带污点节点上已有的 Pod 进行驱逐。当然，对应的 Kubernetes 可以给 Pod 设置 Tolerations(容忍) 属性来让 Pod 能够容忍节点上设置的污点，这样在调度时就会忽略节点上设置的污点，将 Pod 调度到该节点。
记k8s节点重启后node状态变成NotReady解决过程
hellozhijian的博客
11-01 3702
问题发现：节后回来有个同事报k8s某个节点的服务异常。 问题排查：去其中一个主节点查看了下节点状态，显示有2个污点node.kubernetes.io/unreachable:NoSchedule，node.kubernetes.io/unreachable:NoExecute。 显然这2个污点是k8s监听到该节点异常才打上去的，接下来看看节点为何异常： 1、资源。通过查看节点资源使用情况一切正常(后面运维同事说节点有重启过) 2、kubelet服务情况，通过日志追踪命令： sudo journ
K8s调度之污点与容忍
shura1014的博客
12-23 3264
前面介绍了节点亲和性调度，它可以使得我们的Pod调度到指定的Node节点上，而污点（Taints）与之相反，它可以让Node拒绝Pod的运行，甚至驱逐已经在该Node上运行的Pod
【Kubernetes】Pod学习（九）Pod调度：Taints和Tolerations
山高人为峰
12-17 949
此文为学习《Kubernetes权威指南》的相关笔记 学习笔记： 不论是nodeSelector调度方案还是亲和性调度方案，都是为Pod在创建时提供了选择Node的主动性，但是在很多场景中，Node同样需要具备选择自身可部署Pod属性的主动性，Taints和Tolerations（污点和容忍）机制使Node能够主动选择（设置Taints）具备某种属性（带有Tolerations）的Pod，也具...
kubectl describe pod 里边没有看到events问题解决【详细步骤】
marlinlm的博客
12-25 9767
解决kubectl describe pod 里边没有看到events问题。
K8s入门-K8s节点notReady状态解决
weixin_43169156的博客
04-01 6549
K8s节点notReady状态解决 挂掉原因：我想要通过externalIP来发布一个service，同时要删除旧的pod，删除命令执行后，节点就不可用了。 错误操作复现 创建externalIP类型的service 将已有的deployments/demo的节点置为0（这一步有大问题） 删除已有的pod节点（直接卡死，之后node节点全部断掉了） [root@k8s-master01 ~]# kubectl apply -f services-externalip-demo.yaml service
k8s 污点和容忍度
包泽旭
09-21 430
污点taints是定义在节点之上的键值型属性数据，用于让节点拒绝将Pod调度运行于其上， 除非该Pod对象具有接纳节点污点的容忍度。而容忍度tolerations是定义在 Pod对象上的键值型属性数据，用于配置其可容忍的节点污点，而且调度器仅能将Pod对象调度至其能够容忍该节点污点的节点之上，如图所示 节点选择器nodeSelector和节点亲和性nodeAffinity两种调度方式都是通过在...
微博在线机器学习平台的K8S实战与挑战
K8S是一个强大的容器编排系统，能够提供弹性的计算能力，适应机器学习任务对算力的动态需求。通过K8S，微博可以快速地部署和扩展模型，应对业务迭代速度慢、资源与成本有限的挑战。同时，K8S支持自动化运维，简化了...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值