k3s

job 主要用于负责**批量处理(一次要处理指定数量任务)短暂的一次性(每个任务仅运行一次就结束)**任务。Job特点如下： 当Job创建的pod执行成功结束时，Job将记录成功结束的pod数量 当成功结束的pod达到指定的数量时，Job将完成执行 关于重启策略设置的说明： 如果指定为OnFailure，则job会在pod出现故障时重启容器，而不是创建pod，failed次数不变 如果指定为Never，则job会在pod出现故障时创建新的pod，并且故障pod不会消失，也不会重启，failed次数加1 job.yaml 12345678910111213141516171819202122232425262728293031323334apiVersion: batch/v1kind: Jobmetadata: name: job labels: app: jobspec: # 允许使用selector(默认是false) manualSelector: true # 指定job在任一时刻应该并发运行Pods的数量。默认值: 1 ...

在describe或kubelet日志中没有明确记录错误原因，基本都是因为command命令不合法导致 命令和参数说明：command 和 args 分别对应于 Dockerfile 中的 ENTRYPOINT 和 CMD。command 表示要执行的命令，args 是传递给该命令的参数。 如果command和args均没有写，那么用Dockerfile的配置。如果command写了，但args没有写，那么Dockerfile默认的配置会被忽略，执行输入的command（不带任何参数，当然command中可自带参数）。如果command没写，但args写了，那么Dockerfile中配置的ENTRYPOINT的命令行会被执行，并且将args中填写的参数追加到ENTRYPOINT中。如果command和args都写了，那么Dockerfile的配置被忽略，执行command并追加上args参数。比如： command：/test.sh,p1,p2args:...

configmap简介 在生产环境中经常会遇到需要修改配置文件的情况，传统的修改方式不仅会影响到服务的正常运行，而且操作步骤也很繁琐。为了解决这个问题，kubernetes项目从1.2版本引入了ConfigMap功能，用于将应用的配置信息与程序的分离。 ConfigMap是一种API对象，用来将非加密数据保存到键值对中。可以用作环境变量、命令行参数或者存储卷中的配置文件。 ConfigMap不可以跨命名空间使用 ConfigMap必须要在pod/deployment创建之前就得存在 ConfigMap 在设计上不是用来保存大量数据的。在 ConfigMap 中保存的数据不可超过 1 MiB。如果你需要保存超出此尺寸限制的数据，你可能希望考虑挂载存储卷 或者使用独立的数据库或者文件服务。 ConfigMap创建通过文件创建configmap1kubectl create configmap my-config --from-file=key1=test1.txt ...

Secret介绍 k8s secrets用于存储和管理一些敏感数据，比如密码，token，密钥等敏感信息。它把 Pod 想要访问的加密数据存放到 Etcd 中。然后用户就可以通过在 Pod 的容器里挂载 Volume 的方式或者环境变量的方式访问到这些 Secret 里保存的信息了。 Secret有三种类型Opaque 1base64 编码格式的 Secret，用来存储密码、密钥等；但数据也可以通过base64 –decode解码得到原始数据，所有加密性很弱。 Service Account(暂时没用过) 1用来访问Kubernetes API，由Kubernetes自动创建，并且会自动挂载到Pod的 /run/secrets/kubernetes.io/serviceaccount 目录中。 kubernetes.io/dockerconfigjson 1用来拉取私有库镜像的认证信息(比如nexus或者habor等) Opaque类型 base64加密(--wrap=0表示不换行输出)echo -n 'xiaowu' | base64...

kubernetes组件一个kubernetes集群主要是由**控制节点(master)、工作节点(node)**构成，每个节点上都会安装不同的组件。 master：集群的控制平面，负责集群的决策 ( 管理 )ApiServer : 资源操作的唯一入口，接收用户输入的命令，提供认证、授权、API注册和发现等机制; 客户端与k8s群集及K8s内部组件的通信，都要通过Api Server这个组件；Scheduler : 负责集群资源调度，按照预定的调度策略将Pod调度到相应的node节点上。（算哪个节点）ControllerManager : 负责维护集群的状态，比如程序部署安排、故障检测、自动扩展、滚动更新等（部署和维护的）Etcd/节点信息存储 ：负责存储集群中各种资源对象的信息 **node：集群的数据平面，负责为容器提供运行环境 ( 干活 ) **Kubelet : 负责维护容器的生命周期，即通过控制docker/containerd，来创建、更新、销毁容器KubeProxy :...

cannot create resource ERROR: Job failed (system failure): pods is forbidden: User “system:serviceaccount:dev:default” cannot create resource “pods” in API group “” in the namespace “xxx” 权限不够, 可能后面还会跟个clusterrole at scope..., 需要创建一个clusterrolebindind进行授权 上面例子中, system:serviceaccount是什么类型的对象, dev是namespace, default是用户, 而API group是核心组 http error: ResponseCode: 503 loading OpenAPI spec for "v1beta1.metrics.k8s.io" failed with: failed to retrieve openAPI spec, http error:...

转自: https://help.aliyun.com/document_detail/188179.html?utm_content=g_1000230851&spm=5176.20966629.toubu.3.f2991ddcpxxvD1#title-b7y-d6a-bcy DNS原理和配置说明本文介绍Kubernetes集群中集群DNS服务原理，并针对不同场景介绍如何进行DNS策略配置。 背景信息K8S集群默认部署了一套DNS服务，通过kube-dns的服务名暴露DNS服务。你可执行以下命令查看kube-dns的服务详情。 1kubectl get svc kube-dns -n kube-system 预期输出： 12NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEkube-dns ClusterIP 172.24.0.10 <none> 53/UDP,53/TCP,9153/TCP ...

重启策略 一些rs对象：必须设置为Always，需要保证该容器持续运行。Job和CronJob：OnFailure或Never，确保容器执行完成后不再重启。 重启策略适用于pod对象中的所有容器，首次需要重启的容器，将在其需要时立即进行重启，随后再次需要重启的操作将由kubelet延迟一段时间后进行，且反复的重启操作的延迟时长为10s，20s，40s，80s，160s，300s。300s是最大延迟时长 健康检测 记: 在服务刚启动时也许会提示检查失败的警告 Warning Unhealthy 18s (x2 over 24s) kubelet Readiness probe failed: dial tcp 10.42.2.55:32000: connect: connection refused,这个时候需要结合pod的启动日志进行查看是否真的启动成功 容器进程返回值非零，Kubernetes则认为容器 发生故障，需要重启。有不少情况是发生了故障，但进程并不会退出。比如访问Web服务器时显示500内部错误，可能是系统超载，也...

同一个名称空间 k8s给每个内部微服务提供了一个内部使用的host，就是.。可以在代码中直接访问[http://.:],来达到访问另一个服务。如果是部署到默认namespace下的服务，namespace为“default”。 不同名称空间 无论是相同还是不同名称空间都可以通过{SERVICE_NAME}.{NAMESPACE_NAME}.svc.cluster.local或者{SERVICE_NAME}.{NAMESPACE_NAME}jinx访问 所以,Namespace是形成逻辑上的"组"，以方便不同的组的资源进行隔离使用和管理。 例子: "default.svc.cluster.local"。"default" 是我们正在操作的命名空间。 "svc" 表示这是一个 Service。"cluster.local" 是你的集群域，在你自己的集群中可能会有所不同。

摘自：https://blog.csdn.net/hancoder/article/details/118070296 访问控制概述 Kubernetes作为一个分布式集群的管理工具，保证集群的安全性是其一个重要的任务。所谓的安全性其实就是保证对Kubernetes的各种客户端进行认证和鉴权操作。 客户端 在Kubernetes集群中，客户端通常有两类： User Account：一般是独立于kubernetes之外的其他服务管理的用户账号。 Service Account：kubernetes管理的账号，用于为Pod中的服务进程在访问Kubernetes时提供身份标识。 认证、授权与准入控制 ApiServer是访问及管理资源对象的唯一入口。任何一个请求访问ApiServer，都要经过下面三个流程： Authentication（认证）：身份鉴别，只有正确的账号才能够通过认证 Authorization（授权）： 判断用户是否有权限对访问的资源执行特定的动作 Admission...