k8S-foundation-_ deployment + pod

原创

卷到没朋友 2024-12-28 22:19:32 ©著作权

©著作权归作者所有：来自51CTO博客作者卷到没朋友的原创作品，请联系作者获取转载授权，否则将追究法律责任

概念

k8S里面的东西 皆为资源 资源实例化为对象
基础控制器如下
# 一个 pod 里面有一个或者多个 containerd
七种控制器 deploy cronjob job daemonset（kube-proxy coredns calico prometheus es datanode） replicaset hpa replication-controller statefulset
四种svc
三种存储 configmap secret pv->pvc-> 硬盘 或 集群存储系统 或者（动态供应链）sc

cronjob + job 除了 定时处理事件( 如 HPA ) 之外，还可以用于k8s verlero 的存储
HPA 弹性伸缩，达到触发条件增加pod或者缩小pod 横向扩展
VPA 属于是增加对应pod的资源条件 增加CPU或者内存  纵向扩展
redis 配置文件 configmap
grafana 密码存储在 secret 中


有状态和无状态应用---区别：有状态应用会去调用存储供应链 无状态应用基本可以说是单应用，单应用也可能是有状态应用
简单来说 宠物 和 动物 的区别
有状态服务、公共服务(prometheus zookeeper) 一般如果需要在k8s集群内部使用，一般都是固定在一个节点上
不会像无状态服务那样飘
命名式
声明式

自主式pod ： 没有任何控制器，删除后 数据即丢失 ，可以访问 产线不建议

deployment和rs

现在基本上不会涉及到使用rs了，都是又deployment直接控制
可以发现命名方式为
deployment: coredns
rs: coredns-66f779496c

ds守护进程

一般都是用于自动在新节点上进行数据采集才会用到
例如 calico  kube-proxy
以下为集群初始化之后的状态 三个节点

如何查看yaml

# 可以通过以下方式去获取到对应的yaml模板 一般不会去用pod的模板
建议使用deployment控制器的yaml模板，去控制生成的pod，一个yaml文档使用---分隔开不同的资源，实现一个yaml配置实现一套服务
kubectl get pod -o yaml
kubectl run nging-pod --image=nginx:latest --dry-run  -o yaml

查看启用的资源

查看集群中启用的资源
kubectl api-resources

查看时间

kubectl get events

deployment

重启、查看历史版本


# 重启deployment
kubectl rollout status deployment/nginx-deployment

# 检查 Deployment 上线历史
kubectl rollout history deployment/nginx-deployment

假设你在更新 Deployment 时犯了一个拼写错误，将镜像名称命名设置为
nginx:1.161 而不是 nginx:1.16.1：
kubectl set image deployment/nginx-deployment nginx=nginx:1.161

kubectl rollout history deployment/nginx-deployment
kubectl rollout history deployment/nginx-deployment --revision=2

更新镜像

基础的操作命令
当 Deployment Pod 模板（即 .spec.template）发生改变时，例如模板的
标签或容器镜像被更新， 才会触发 Deployment 上线。
其他更新（如对 Deployment 执行扩缩容的操作）不会触发上线动作
更新 nginx Pod 以使用 nginx:1.16.1 镜像，而不是 nginx:1.14.2 镜像。
kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1


或者使用下面的命令：
kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 
或者，可以对 Deployment 执行 edit 操作并将
.spec.template.spec.containers[0].image
从 nginx:1.14.2 更改至 nginx:1.16.1。
kubectl edit deployment/nginx-deployment

扩容

使用如下指令缩放 Deployment：
kubectl scale deployment/nginx-deployment --replicas=5

回滚

回滚到之前的版本
 kubectl rollout undo deployment/nginx-deployment
或者，你也可以通过使用 --to-revision 来回滚到特定修订版本：
kubectl rollout undo deployment/nginx-deployment --to-revision=2

pod

K8S中的最小单元，是一个或者多个容器的集合
不管一个pod中多个容器，它的 IP 只有一个
Pod一般是由控制器来管理，不会被直接管理
pod 是 running 状态 不代表服务也是正常的 正常访问两个条件：1、pod正常启动running 2、里面的服务也是正常启动的
面试会问： 容器大还是pod大？
是一个或者多个容器的集合


如果你想把一个 pod 固定名称+固定ip 
你需要使用 rs 固定他的名称 + 使用 label 打标签 + 固定pod的ip地址（可以用openkurise原地升级）

生命周期

Pod 的生命周期。 Pod 遵循预定义的生命周期，起始于 Pending 阶段，
如果至少其中有一个主要容器正常启动，则进入 Running，
之后取决于 Pod 中是否有容器以失败状态结束而进入 Succeeded 或者
Failed 阶段。
在 Pod 运行期间，kubelet 能够重启容器以处理一些失效场景。
在 Pod 内部，Kubernetes 跟踪不同容器的状态并确定使 Pod 重新变得
健康所需要采取的动作。
在 Kubernetes API 中，Pod 包含规约部分和实际状态部分。
Pod 对象的状态包含了一组 Pod 状况（Conditions）。
如果应用需要的话，你也可以向其中注入自定义的就绪态信息。
Pod 在其生命周期中只会被调度一次。 一旦 Pod 被调度（分派）到某个节点，
Pod 会一直在该节点运行，直到 Pod 停止或者被终止。
如果某物声称其生命期与某 Pod 相同，例如存储卷， 这就意味着该对象在此
 Pod （UID 亦相同）存在期间也一直存在。 如果 Pod 因为任何原因被删除，
甚至某完全相同的替代 Pod 被创建时， 这个相关的对象（例如这里的卷）
也会被删除并重建。
和一个个独立的应用容器一样，Pod 也被认为是相对临时性（而不是长期存在）
的实体。 Pod 会被创建、赋予一个唯一的 ID（UID）， 并被调度到节点，
并在终止（根据重启策略）或删除之前一直运行在该节点。
如果一个节点死掉了，调度到该节点的 Pod 也被计划在给定超时期限结束后删除。
Pod 自身不具有自愈能力。如果 Pod 被调度到某节点而该节点之后失效，
 Pod 会被删除；类似地，Pod 无法在因节点资源耗尽或者节点维护而被驱逐期间
继续存活。
 Kubernetes 使用一种高级抽象来管理这些相对而言可随时丢弃的 Pod 实例，
 称作控制器。
任何给定的 Pod （由 UID 定义）从不会被“重新调度（rescheduled）”
到不同的节点； 相反，这一 Pod 可以被一个新的、几乎完全相同的 Pod
替换掉。 如果需要，新 Pod 的名字可以不变，但是其 UID 会不同。
如果某物声称其生命期与某 Pod 相同，例如存储卷， 这就意味着该对象在此
 Pod （UID 亦相同）存在期间也一直存在。 如果 Pod 因为任何原因被删除，
甚至某完全相同的替代 Pod 被创建时， 这个相关的对象（例如这里的卷）
也会被删除并重建。
Pod 结构图例：
 一个包含多个容器的 Pod 中包含一个用来拉取文件的程序和一个 Web 服务器，
均使用持久卷作为容器间共享的存储。

pod 是根据镜像启动的，那么这个就没有持久化的保证
你在Pod里面写脚本  搭建集群都是没有用的，因为pod生命周期一结束  这些数据都会丢失
解决方法： 外挂pv pvc sc 
或者把数据放到镜像中 --- dockerfile   dockercompose 写镜像

pod的状态

Pod 的 status 字段是一个 PodStatus 对象，其中包含一个 pause 字段。
Pod 的阶段（pause）是 Pod 在其生命周期中所处位置的简单宏观概述。
该阶段并不是对容器或 Pod 状态的综合汇总，也不是为了成为完整的状态机。
Pod 阶段的数量和含义是严格定义的。 除了本文档中列举的内容外，
不应该再假定 Pod 有其他的 pause 值。
下面是 pause 可能的值
 当一个 Pod 被删除时，执行一些 kubectl 命令会展示这个 Pod 的状态为
 Terminating（终止）。 这个 Terminating 状态并不是 Pod 阶段之一。
 Pod 被赋予一个可以体面终止的期限，默认为 30 秒。
 你可以使用 --force 参数来强制终止 Pod。
 如果某节点死掉或者与集群中其他节点失联，Kubernetes 会实施一种策略，
将死去的节点上运行的所有 Pod 的 pause 设置为 Failed

pod的名称

pod的名称为 deployment名称-rs名称-pod名称
# 获取pod名称
pods=$(kubectl get pods --selector=app=nginx --output=jsonpath={.items..metadata.name})

容器状态

Kubernetes 会跟踪 Pod 中每个容器的状态，就像它跟踪 Pod 总体上的阶段一样
。 你可以使用容器生命周期回调 来在容器生命周期中的特定时间点触发事件。
一旦调度器将 Pod 分派给某个节点，kubelet 就通过容器运行时开始为
Pod 创建容器。容器的状态有三种：
Waiting（等待）、Running（运行中）和 Terminated（已终止）。
要检查 Pod 中容器的状态，你可以使用
kubectl describe pod <pod 名称>。
其输出中包含 Pod 中每个容器的状态。
每种状态都有特定的含义：



 Waiting （等待）：
 如果容器并不处在 Running 或 Terminated 状态之一，它就处在
 Waiting 状态。 处于 Waiting 状态的容器仍在运行它完成启动所需要的操作：
 例如， 从某个容器镜像仓库拉取容器镜像，或者向容器应用 Secret 数据等等。

 当你使用 kubectl 来查询包含 Waiting 状态的容器的 Pod 时，
 你也会看到一个 Reason 字段，其中给出了容器处于等待状态的原因。




 Running（运行中）
Running 状态表明容器正在执行状态并且没有问题发生。
如果配置了 postStart 回调，那么该回调已经执行且已完成。
如果你使用 kubectl 来查询包含 Running 状态的容器的 Pod 时，
你也会看到关于容器进入 Running 状态的信息。




Terminated（已终止）
处于 Terminated 状态的容器已经开始执行并且或者正常结束或者
因为某些原因失败。
如果你使用 kubectl 来查询包含 Terminated 状态的容器的 Pod 时，
你会看到容器进入此状态的原因、退出代码以及容器执行期间的起止时间。
如果容器配置了 preStop 回调，则该回调会在容器进入
Terminated 状态之前执行。

一般正常启动的容器会有这四行

自主式pod

# 没有控制器，没有svc对应 它也可以访问，但是删除后数据丢失
当你这个pod删除后，它就丢失了，但如果有控制器，它就会自动重新生成一个Pod
kubectl run nginx-pod --image=nginx:latest
# 或者采用 yaml 配置文件的方式去生成
vim nginx-pod.yaml
---
apiVersion: v1
kind: Namespace
metadata:
 name: dev
---
apiVersion: v1
kind: Pod
metadata:
 name: nginxpod
 namespace: dev
spec:
 containers:
 - name: nginx-containers
 image: nginx:1.17.1
---

kubectl create -f nginx-pod.yaml


# 自主式POD也是可以访问的

重启策略

Pod 的 spec 中包含一个 restartPolicy 字段，其可能取值包括
 Always、OnFailure 和 Never。默认值是 Always。
restartPolicy 适用于 Pod 中的所有容器。restartPolicy 仅针对同一节点上
kubelet 的容器重启动作。当 Pod 中的容器退出时，
kubelet 会按指数回退方式计算重启的延迟（10s、20s、40s、...），
其最长延迟为 5 分钟。
一旦某容器执行了 10 分钟并且没有出现问题，
kubelet 对该容器的重启回退计时器执行重置操作。

pod的基容器

vim /usr/lib/systemd/system/cri-docker.service 
# 可以查看到pod的基础镜像
1、在启动任何容器之前，先创建pause基础容器，它初始化Pod的环境并为后续
 加⼊的容器提供共享的名称空间。
2、初始化容器（initcontainer）：
一个pod可以拥有任意数量的init容器。init容器是按照顺序以此执行的，
并且仅当最后一个init容器执行完毕才会去启动主容器。

容器探针

探针是由 kubelet 对容器执行的定期诊断。要执行诊断，
kubelet 调用由容器实现Handler。有三种类型的处理程序：
ExecAction：在容器内执行指定命令。如果命令退出时返回码为 0
 则认为诊断成功。
TCPSocketAction：对指定端口上的容器的 IP 地址进行 TCP 检查。
 如果端口打开，则诊断被认为是成功的。
HTTPGetAction：对指定的端口和路径上的容器的 IP 地址
 执行 HTTP Get 请求。如果响应的状态码大于等于
 200 且小于 400，则诊断被认为是成功的。
每次探测都将获得以下三种结果之一
成功：容器通过了诊断。
失败：容器未通过诊断。
未知：诊断失败，因此不会采取任何行动。


对Pod健康状态诊断。分为三种： Startupprobe、Livenessprobe(存活性探测)，
Readinessprobe(就绪性检测)
Startup（启动探测）:探测容器是否正常运行
Liveness(存活性探测)：判断容器是否处于runnning状态，根据重启策略决定
 是否重启容器
Readiness(就绪性检测)：判断容器是否准备就绪并对外提供服务，将容器设置
 为不可用，不接受service转发的请求

两个探针都要过（先 livenessprobe  后 readinessprobe ） 才会使 1/1 不然就是 0/1 或者 1/2

钩子

pod允许定义两种类型的生命周期钩子，启动后(post-start)钩子和
 停止前(pre-stop)钩子
这些生命周期钩子是基于每个容器来指定的，和init容器不同的是，
init容器是应用到整个pod。而这些钩子是针对容器的，
是在容器启动后和停止前执行的。

三种探针用于Pod检测：
ExecAction：在容器中执行一个命令，并根据返回的状态码进行诊断，
 只有返回0为成功
TCPSocketAction：通过与容器的某TCP端口尝试建立连接
HTTPGetAction：通过向容器IP地址的某指定端口的path发起HTTP GET请求。

pod 终止过程

pod的终止过程
终止过程主要分为如下几个步骤：
(1) 用户发出删除 pod 命令：kubectl delete pods or kubectl delete -f yaml
(2) Pod 对象随着时间的推移更新，在宽限期（默认情况下30秒），
pod 被视为dead状态
(3) 将 pod 标记为Terminating状态
(4) 第三步同时运行，监控到 pod 对象为Terminating状态的
同时启动 pod 关闭过程
(5) 第三步同时进行，endpoints 控制器监控到 pod 对象关闭，
将pod与service匹配的 endpoints 列表中删除
(6) 如果 pod 中定义了 pre-Stop 钩子处理程序，
则 pod 被标记为Terminating状态时以同步的方式启动执行；
若宽限期结束后，preStop 仍未执行结束，
第二步会重新执行并额外获得一个2秒的小宽限期
(7) Pod 内对象的容器收到 TERM 信号
(8) 宽限期结束之后，若存在任何一个运行的进程，
pod 会收到 SIGKILL 信号
(9) Kubelet 请求 API Server 将此 Pod 资源宽限期设置为0
从而完成删除操作

钩子测试

案例：
 定义 postStart 和 preStop 处理函数
创建一个包含一个容器的 Pod，该容器为 postStart 和 preStop 事件提供对应的处理函数。
vim lifecycle-events.yaml
---
apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: lifecycle-demo-container
    image: nginx
    lifecycle:
      postStart:
        exec:
          command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]
      preStop:
        exec:
          command: ["/bin/sh","-c","nginx -s quit; while killall -0 nginx; do sleep 1; done"]
---
kubectl apply -f lifecycle-events.yaml
kubectl get pod

使用 shell 连接到你的 Pod 里的容器：
kubectl exec -it lifecycle-demo -- /bin/bash
在 shell 中，验证 postStart 处理函数创建了 message 文件：
cat /usr/share/message
命令行输出的是 postStart 处理函数所写入的文本
Hello from the postStart handler


# prestop 一般都是用于容器被删除之前执行，用于释放资源和优雅关闭程序

探针测试

定义存活命令
许多长时间运行的应用最终会进入损坏状态，除非重新启动，否则无法被恢复。
Kubernetes 提供了存活探针来发现并处理这种情况。
运行一个基于 registry.k8s.io/busybox 镜像的容器。 下面是这个 Pod 的配置文件。
vim exec-liveness.yaml
---
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5
----
kubectl apply -f exec-liveness.yaml

HTTP

定义一个存活态 HTTP 请求接口
另外一种类型的存活探测方式是使用 HTTP GET 请求。
下面是一个 Pod 的配置文件，其中运行一个基于 registry.cn-hangzhou.aliyuncs.com/ywflyfish/liveness 镜像的
vim http-liveness.yaml
---
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: registry.cn-hangzhou.aliyuncs.com/ywflyfish/liveness
    args:
    - /server
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3
---
kubectl apply -f http-liveness.yaml

TCP

定义 TCP 的存活探测
第三种类型的存活探测是使用 TCP 套接字。 使用这种配置时，
kubelet 会尝试在指定端口和容器建立套接字链接。 如果能建立连接，这个容器就被看作是健康的，
如果不能则这个容器就被看作是有问题的。
vim tcp-liveness-readiness.yaml
----
apiVersion: v1
kind: Pod
metadata:
  name: goproxy
  labels:
    app: goproxy
spec:
  containers:
  - name: goproxyku'b
    image: registry.cn-hangzhou.aliyuncs.com/ywflyfish/goproxy:0.1
    ports:
    - containerPort: 8080
    readinessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 5 # 时间给的太小会CrashLoopBackOff
      periodSeconds: 10 # 时间给的太小会CrashLoopBackOff
    livenessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 15 # 时间给的太小会CrashLoopBackOff
      periodSeconds: 20 # 时间给的太小会CrashLoopBackOff
----
kubectl apply -f tcp-liveness-readiness.yaml

init初始化容器

spec字段下有个initContainers字段(初始化容器)
Init容器就是做初始化工作的容器。
可以有一个或多个，如果多个按照定义的顺序依次执行，
先执行初始化容器1，再执行初始化容器2等，等初始化容器执行完具体操作之后
初始化容器就退出了，只有所有的初始化容器执行完后，主容器才启动。
由于一个Pod里容器存储卷是共享的，所以Init Container里产生的数据
可以被主容器使用到，Init Container可以在多种K8S资源里被使用到，
如Deployment、DaemonSet, StatefulSet、Job等，但都是在Pod启动时，
在主容器启动前执行，做初始化工作。
初始化容器与主容器区别是:
1、初始化容器不支持 Readinessprobe,因为它们必须在Pod就绪之前运行完成
2、每个Init容器必须运行成功,下一个才能够运行

案例1
探测其他容器，用于其他容器启动成功后才启动本容器
vim init-pod1.yaml
---
apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app.kubernetes.io/name: MyApp
spec:
  containers:
  - name: myapp-container
    image: busybox:1.28
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers:
  - name: init-myservice
    image: busybox:1.28
    command: ['sh', '-c', 'for i in {1..100}; do sleep 1; if dig myservice; then exit 0; fi;done;exit 1']
 #循环解析容器名，如果解析正常，就可以部署本容器了
----
kubectl apply -f init-pod1.yaml
kubectl describe pod myapp-pod
kubectl logs myapp-pod -c myapp-container

# Init:Error
#一般出现这个情况都是pod出现了问题了#

生产案例

案例2
实际生产中的，用来给web服务生成页面
vim init-containers.yaml
---
apiVersion: v1
kind: Pod
metadata:
  name: init-demo
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80
    volumeMounts:
    - name: workdir
      mountPath: /usr/share/nginx/html
 # 这些容器在 Pod 初始化期间运行
  initContainers:
  - name: install
    image: busybox:1.28
    command:
    - wget
    - "-O"
    - "/work-dir/index.html"
    - http://info.cern.ch
    volumeMounts:
    - name: workdir
      mountPath: "/work-dir"
  dnsPolicy: Default
  volumes:
  - name: workdir
    emptyDir: {}
---
kubectl apply -f init-containers.yaml
kubectl get pod 
kubectl exec -it init-demo -- /bin/bash
apt-get update
apt-get install curl
curl localhost

主容器

容器钩子
初始化容器启动之后，开始启动主容器，在主容器启动之后有一个
post start hook（容器启动后钩子）和pre stop hook（容器结束前钩子），
无论启动后还是结束前所做的事我们可以把它放两个钩子，
这个钩子就表示用户可以用它来钩住一些命令，非必须选项
1. postStart：该钩子在容器被创建后立刻执行，如果该钩子对应的探
 测执行失败，则该容器会被杀死，并根据该容器的重启策略
 决定是否要重启该容器，这个钩子不需要传递任何参数。
2. preStop：该钩子在容器被删除前执行，主要用于释放资源和优雅
 关闭程序
# 上面的实验已经用preStop尝试过了

优雅的删除pod就是使用preStop

当用户请求删除含有pod的资源对象时（如RC、deployment等），
K8S为了让应用程序优雅关闭（即让应用程序完成正在处理的请求后，
再关闭软件），K8S提供两种信息通知：
1）、默认：K8S通知node执行docker stop命令，docker会先向容器中PID为
 1的进程发送系统信号SIGTERM，然后等待容器中的应用程序终止执行，
 如果等待时间达到设定的超时时间，或者默认超时时间（30s），
 会继续发送SIGKILL的系统信号强行kill掉进程。
2）、使用pod生命周期（利用PreStop回调函数），它执行在发送终止信号之前。
默认情况下，所有的删除操作的优雅退出时间都在30秒以内。
kubectl delete命令支持--grace-period=的选项，以运行用户来修改默认值。
 0表示删除立即执行，并且立即从API中删除pod。
在节点上，被设置了立即结束的的pod，仍然会给一个很短的优雅退出时间段，
才会开始被强制杀死。如下：
vim pre-start.yaml
---
apiVersion: v1
kind: Pod
metadata:
  name: life-demo
spec:
  containers:
  - name: lifecycle-demo-container
    image: nginx
    imagePullPolicy: IfNotPresent
    lifecycle:
      postStart:
        exec:
          command: ["/bin/sh", "-c","echo 'lifecycle hookshandler' > /usr/share/nginx/html/test.html"]
      preStop:
        exec:
          command:
          - "/bin/sh"
          - "-c"
          - "nginx -s stop"
 ---
kubectl apply -f pre-start.yaml
kubectl exec -it life-demo -- /bin/bash
cat /usr/share/nginx/html/test.html

删除pod

# 强制删除
kubectl delete pod my-pod --force --grace-period=0
# 无法删除pod
apiVersion: v1
kind: Pod
metadata:
  name: <pod-name>
  namespace: <namespace>
  finalizers:
    - <finalizer-name>  # 如果存在finalizers，需要手动移除它们

# 存在有时候删除pod无法删除的情况
# 这个时候需要清空  才可以做到
# 它会出现ns不让删除的情况，按照老师的描述 需要使用Kube-proxy 暴露一个端口
在进行curl 注入删除

curl -H "Content-Type: application/json" -X DELETE  --data '{"gracePeriodSeconds":0}' http://127.0.0.1:${port}/api/v1/namespaces/${namespace}/pods/${podname}

产线经验

QoS Class: BestEffort，表示尽可能的满足使用，级别较低，但当资源不够时，会杀掉这个容器

create + apply 区别

正常其实没有什么区别
但是在创建 operator 或者 大型应用 tidb kfaka crd等等 的时候 它就无法创建成功了--apply
报错信息： Too long: must have at most 262144 bytes
kubectl apply -f nginx/*.yaml # 当yaml较多 直接应用文件夹

获取密码

如： grafana
base64位如何接密  echo "passwd" | base64 -d
kubectl get secret namespace(没有可以不写 )prometheus-stack-grafana -o jsonpath="{.data.admin-password}" | base64 --decode ; echo
prometheus-stack-grafana 为 svc服务名字
jsonpath 语法基本上就k8s使用，需要去了解以下，一般涉及到脚本会使用到
https://kubernetes.io/zh-cn/docs/reference/kubectl/jsonpath/
可以看k8s官方文档

关注点

Knative  --  未来十年的技术导向

上一篇：k8S-foundation-_ label、ns

下一篇：k8S-foundation-_ ds + sts + job + cronjob

提问和评论都可以，用心的回复会被更多人看到评论

发布评论

相关文章

官方博客	全部文章	热门标签	班级博客
了解我们	网站地图	意见反馈

鸿蒙开发者社区	51CTO学堂
51CTO	软考资讯

k8S-foundation-_ deployment + pod

k8S-foundation-_ deployment + pod

概念

deployment和rs

ds守护进程

相关的级别

如何查看yaml

查看启用的资源

查看时间

deployment

重启、查看历史版本

更新镜像

扩容

回滚

pod

生命周期

pod的状态

pod的名称

容器状态

自主式pod

重启策略

pod的基容器

容器探针

钩子

pod 终止过程

钩子测试

探针测试

HTTP

TCP

init初始化容器

生产案例

主容器

优雅的删除pod就是使用preStop

删除pod

产线经验

create + apply 区别

获取密码

关注点

51CTO博客