美文网首页
K8S资源配置清单1

K8S资源配置清单1

作者: 强出头 | 来源:发表于2022-01-26 11:52 被阅读0次
  • API server 接受和返回的所有 JSON 对象都遵循同一个模式,它们都具有 "kind" 和 "apiVersion" 字段,用于标识对象所属的资源类型、API 的群组及相关版本

  • 大多数的对象或列表类型的资源还需要具有三个嵌套型的字段 metadata、spec 和 status

  • metadata 字段为资源提供元数据信息,例如名称、隶属的名称空间和标签等

  • spec 用于定义用户期望的状态,不同的资源类型,其状态的意义各有不同,例如 Pod 资源最为核心的功能在于运行容器;

  • status 则记录着活动独享的当前状态信息,它由 Kubernetes 系统自行维护,对用户来说为只读字段;

  • "kubectl api-resources" 命令可以获取集群支持使用的所有资源类型

image image image image

<pre data-language="plain" id="88a19dad" class="ne-codeblock language-plain" style="border: 1px solid #e8e8e8; border-radius: 2px; background: #f9f9f9; padding: 16px; font-size: 13px; color: #595959">#使用陈述式对象配置

创建一个名称空间

~]# kubectl create -f develop-n.yaml
namespace/develop created
~]# cat develop-n.yaml
apiVersion: v1
kind: Namespace
metadata:
name: develop

使用声明式对象配置

创建一个名称空间

~]# kubectl delete ns develop
namespace "develop" deleted
~]# kubectl apply -f develop-n.yaml
namespace/develop created
~]# cat develop-n.yaml
apiVersion: v1
kind: Namespace
metadata:
name: develop

声明式可以更改配置文件后直接重新执行

~]# cat develop-n.yaml
apiVersion: v1
kind: Namespace
metadata:
name: test
~]# kubectl get ns
NAME STATUS AGE
default Active 13h
develop Active 112s
kube-node-lease Active 13h
kube-public Active 13h
kube-system Active 13h
~]# kubectl apply -f develop-n.yaml
namespace/test created
~]# kubectl get ns
NAME STATUS AGE
default Active 13h
develop Active 118s
kube-node-lease Active 13h
kube-public Active 13h
kube-system Active 13h
test Active 2s</pre>

pod yaml官方写法

https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.16/#pod-v1-core

<pre data-language="plain" id="32fa4b62" class="ne-codeblock language-plain" style="border: 1px solid #e8e8e8; border-radius: 2px; background: #f9f9f9; padding: 16px; font-size: 13px; color: #595959">#可以查看启动的pod作为模板
~]# kubectl get pods ngx-dep-d554574bd-fq6kq -o yaml --export
Flag --export has been deprecated, This flag is deprecated and will be removed in future.
apiVersion: v1 #api版本一般不变
kind: Pod #类型为Pod
metadata: #标准对象的元数据。
creationTimestamp: null #CreationTimestamp是表示创建此对象时服务器时间的时间戳。不能保证在单独的操作中按事前发生的顺序进行设置。客户可能未设置此值。它以RFC3339形式表示且采用UTC。由系统填充。
generateName: ngx-dep-d554574bd- #仅当未提供“名称”字段时,GenerateName是服务器使用的可选前缀,用于生成唯一名称。如果使用此字段,则返回给客户端的名称将与传递的名称不同。该值还将与一个唯一的后缀结合在一起。提供的值具有与“名称”字段相同的验证规则,并且可能会被截短以使该值在服务器上唯一所需的后缀长度。如果指定了此字段并且生成的名称存在,则服务器将不会返回409-而是将返回201 Created或500,且Reason ServerTimeout指示在分配的时间内找不到唯一名称,客户端应重试。
labels: #字符串键和值的映射,可用于组织和分类(范围和选择)对象。可以匹配复制控制器和Service的选择器。
app: ngx-dep
pod-template-hash: d554574bd
ownerReferences: #该对象所依赖的对象列表。 如果已删除列表中的所有对象,则将垃圾回收该对象。 如果此对象由控制器管理,则此列表中的条目将指向该控制器,并且控制器字段设置为true。 最多只能有一个管理控制器。

  • apiVersion: apps/v1
    blockOwnerDeletion: true #如果为true,并且拥有者具有“ foregroundDeletion”终结器,则只有在删除此引用之前,才能从键值存储中删除拥有者。 默认为false。 要设置此字段,用户需要所有者的“删除”权限,否则将返回422(不可处理实体)。
    controller: true #如果为true,则此引用指向管理控制器。
    kind: ReplicaSet #所指对象的种类。
    name: ngx-dep-d554574bd #引用对象的名称。
    uid: eaa5bc36-c7d8-4073-b703-3ece6e58deb3 #参考对象的UID。
    selfLink: /api/v1/namespaces/default/pods/ngx-dep-d554574bd-fq6kq
    spec: #指定cron作业的期望行为,包括时间表。控制器期望的状态。
    containers: #属于该容器的容器列表。 当前无法添加或删除容器。 容器中必须至少有一个容器。 无法更新。
  • image: nginx:1.14-alpine #Docker映像名称。
    imagePullPolicy: IfNotPresent #镜像拉动策略。 Always,Never, IfNotPresent。 Always:永远从远端拉取最新的镜像使用。Nerver:只从本都拉取,如果没有就不启动。ifNotPresent:如果本地没有就从远端拉取。
    name: nginx #指定为DNS_LABEL的临时容器的名称。 该名称在所有容器,初始化容器和临时容器中必须唯一。
    resources: {} #临时容器不允许使用资源。 临时容器使用已分配给容器的备用资源。
    terminationMessagePath: /dev/termination-log #可选:要将容器终止消息写入的文件的路径安装到容器的文件系统中。 编写的消息旨在成为简短的最终状态,例如断言失败消息。 如果大于4096个字节,将被节点截断。 所有容器上的总消息长度将限制为12kb。 默认为/ dev / termination-log。 无法更新。
    terminationMessagePolicy: File #指示如何填充终止消息。 文件将使用TerminationMessagePath的内容来填充成功和失败时的容器状态消息。 如果终止消息文件为空并且容器退出并出现错误,FallbackToLogsOnError将使用容器日志输出的最后一块。 日志输出限制为2048字节或80行,以较小者为准。 默认为文件。 无法更新。
    volumeMounts: #Pod卷挂载到容器的文件系统中。 无法更新。
    • mountPath: /var/run/secrets/kubernetes.io/serviceaccount #容器内应安装卷的路径。 不得包含“:”。
      name: default-token-9frr5 #这必须与卷名匹配。
      readOnly: true #如果为true,则安装为只读,否则为读写(false或未指定)。 默认为false。
      dnsPolicy: ClusterFirst #设置Pod的DNS策略。 默认为“ ClusterFirst”。 有效值为“ ClusterFirstWithHostNet”,“ ClusterFirst”,“默认”或“无”。 DNSConfig中提供的DNS参数将与通过DNSPolicy选择的策略合并。 要与hostNetwork一起设置DNS选项,必须将DNS策略明确指定为'ClusterFirstWithHostNet'。
      enableServiceLinks: true #EnableServiceLinks指示是否应将与服务相关的信息注入到pod的环境变量中,以匹配Docker链接的语法。 可选:默认为true。
      nodeName: node1 #NodeName是将此pod调度到特定节点上的请求。 如果它是非空的,则调度程序会简单地将此Pod调度到该节点上,前提是它符合资源需求。
      priority: 0 #优先级值。 各种系统组件都使用此字段来查找窗格的优先级。 启用优先录入控制器后,它将阻止用户设置此字段。 准入控制器从PriorityClassName填充此字段。 值越高,优先级越高。
      restartPolicy: Always #重新启动容器中所有容器的策略。 永远,失败,永不失败之一。 默认为始终。
      schedulerName: default-scheduler #如果指定,则将由指定的调度程序调度pod。 如果未指定,则默认调度程序将调度pod。
      securityContext: {} #SecurityContext拥有Pod级安全属性和通用容器设置。 可选:默认为空。 有关每个字段的默认值,请参见类型说明。
      serviceAccount: default #DeprecatedServiceAccount是ServiceAccountName的已贬值别名。 不推荐使用:改为使用serviceAccountName。
      serviceAccountName: default #ServiceAccountName是用于运行此pod的ServiceAccount的名称。
      terminationGracePeriodSeconds: 30 #Pod需要正常终止的可选持续时间(以秒为单位)。 在删除请求中可能会减少。 值必须是非负整数。 零值表示立即删除。 如果此值为nil,则将使用默认宽限期。 宽限期是指在Pod中运行的进程被发送终止信号后的持续时间(以秒为单位),以及进程被终止信号强制终止的时间。 将此值设置为比您的进程的预期清除时间长。 默认为30秒。
      tolerations: #如果指定,则为吊舱的公差。
  • effect: NoExecute #需要。 异味对不容许异味的豆荚的影响。 有效效果是NoSchedule,PreferNoSchedule和NoExecute。
    key: node.kubernetes.io/not-ready #必须的。要应用于使节点破坏的。
    operator: Exists #运算符表示键与值的关系。 有效运算符为“存在”和“等于”。 默认为相等。 存在与值的通配符等效,因此窗格可以容忍特定类别的所有污点。
    tolerationSeconds: 300 #TolerationSeconds表示公差(该效果必须为NoExecute,否则将忽略此字段)允许污点的时间段。 默认情况下,它没有设置,这意味着永远容忍异味(不要撤离)。 零和负值将被系统视为0(立即退出)。
  • effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 300
    volumes:
  • name: default-token-9frr5
    secret:
    defaultMode: 420
    secretName: default-token-9frr5
    status: # 计划任务的当前状态。
    phase: Pending #Pod的阶段是Pod在其生命周期中所处位置的简单概括。条件数组,原因和消息字段以及各个容器状态数组包含有关容器状态的更多详细信息。可能有五个相位值:待处理:Kubernetes系统已接受Pod,但尚未创建一个或多个容器映像。这包括计划之前的时间以及通过网络下载图像所花费的时间,这可能需要一段时间。运行:吊舱已绑定到节点,并且所有容器均已创建。至少一个容器仍在运行,或者正在启动或重新启动。成功:容器中的所有容器已成功终止,并且不会重新启动。失败:容器中的所有容器均已终止,并且至少一个容器因故障而终止。容器以非零状态退出或被系统终止。未知:由于某种原因,无法获得Pod的状态,通常是由于与Pod的主机通信时出错。
    qosClass: BestEffort #根据资源需求分配给Pod的服务质量(QOS)分类,请参阅PodQOSClass类型以获取可用的QOS类。</pre>

示例

<pre data-language="plain" id="314bd789" class="ne-codeblock language-plain" style="border: 1px solid #e8e8e8; border-radius: 2px; background: #f9f9f9; padding: 16px; font-size: 13px; color: #595959">~]# cat pod-demo.yaml
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
name: pod-demo
namespace: develop
spec:
containers:

  • image: ikubernetes/myapp:v1
    imagePullPolicy: IfNotPresent
    name: myapp
    resources: {}
    dnsPolicy: ClusterFirst
    enableServiceLinks: true
    priority: 0
    restartPolicy: Always
    schedulerName: default-scheduler
    securityContext: {}
    status:
    phase: Pending
    qosClass: BestEffort

~]# kubectl get pods -n develop
NAME READY STATUS RESTARTS AGE
pod-demo 1/1 Running 0 89s

~]# cat pod-demo-2.yaml
apiVersion: v1
kind: Pod
metadata:
name: mypod
namespace: default
spec:
containers:

  • name: myapp
    image: ikubernetes/myapp:v1
    ports:
    • protocol: TCP
      containerPort: 80
      name: http
      hostPort: 8080
      ~]# cat pod-demo-1.yaml
      apiVersion: v1
      kind: Pod
      metadata:
      name: pod-demo
      namespace: prod
      spec:
      containers:
  • name: myapp
    image: ikubernetes/myapp:v1
  • name: bbox
    image: busybox:latest
    imagePullPolicy: IfNotPresent
    command: ["/bin/sh","-c","sleep 86400"]

查看Pod中的定义

~]# kubectl explain Pods.spec

进入Pod中的容器

~]# kubectl exec -it pod-demo -c nginx -n prod -- sh

查看Pod中容器日志

~]# kubectl logs pod-demo -c myapp -n prod
10.244.0.0 - - [05/Oct/2019:08:15:16 +0000] "GET / HTTP/1.1" 200 65 "-" "curl/7.29.0" "-"
10.244.0.0 - - [05/Oct/2019:08:15:31 +0000] "GET /hostname.html HTTP/1.1" 200 9 "-" "curl/7.29.0" "-"

hostNetwork: true #表示共享宿主机名称空间,一般使用Port映射</pre>

管理Pod对象的容器

  • 镜像获取策略:imagePullPolicy

  • 定义暴露的端口:ports

  • 自定义运行的容器命令:command和args

  • 环境变量:env

  • 共享节点的网络名称空间:hostNetwork

  • 安全上下文:securityContext

  • Pod中有一个以上容器,各容器共享网络名称空间

  • Node Network:与外部网络接口

  • Service Network:链路层的网络,做路由和调度

  • Pod Network:Pod内部网络

  • Service:

  • NodePort:随机映射Node端口

  • HostPort:

  • HostNetwork

标签(Label)

  • 标签就是“键值”类型的数据,它们可于资源创建时直接指定,也可随时按需添加于活动对象,而后即可由标签选择器进行匹配度检查从而完成资源挑选

  • 一个对象可拥有不止一个标签,而同一个标签也可被添加至多个资源之上

  • 实践中,可以为资源附加多个不同纬度的标签以实现灵活的资源分组管理功能,例如版本标签、环境标签、分层架构标签等,用于交叉标识同一个资源所属的不同版本、环境及架构层级等

  • 标签中的键名称通常由键前缀和键名组成,其中键前缀可选,其格式形如 "KEY-PREFIX/KEY_NAME"

  • 键名至多能使用63个字符,可使用字母、数字、连接号(-)、下划线(_)、点号(.)等字符,且只能以字母或数字开头

  • 键前缀必须为DNS子域名格式,且不能超过253个字符。省略键前缀时,键将被视为用户的私有数据,不过由Kubernetes系统组件或第三方组件自动为用户资源添加的键必须使用键前缀,而'kubernetes.io/'前缀预留给kubernetes的核心组件使用

  • 标签中的键值必须不能多于63个字符,它要么为空,要么是以字母或数字开头及结尾,且仅适用字母、数字、连接号(-)、下划线(_)、点号(.)等字符的数据

image

标签选择器(Label Slector)

  • 标签选择器用于表达标签的查询条件或选择标准,Kubernetes API目前支持两个选择器:

  • 基于等值关系(equality—based )

  • 操作符有 = 、== 和 != 三种,其中前两个意义相同,都表示"等值"关系,最后一个表示"不等"关系

  • 基于集合关系(set-based)

  • KEY in (VALUE 1,VALUE2,…)

  • KEY not in (VALUE1 ,VALUE2,…)

  • KEY:所有存在此键名标签的资源;

  • !KEY:所有不存在此键名标签的资源。

  • 使用标签选择器时还将遵循以下逻辑:

  • 同时指定的多个选择器之间的逻辑关系为“与"操作;

  • 使用空值的标签选择器意味着每个资源对象都将被选中;

  • 空的标签选择器将无法选出任何资源。

定义标签选择器的方式

  • kubernetes的诸多资源对象必须以标签选择器的方式关联到Pod资源对象,例如Service、Deployment和ReplicaSet类型的资源等,它们在spec字段中嵌套使用嵌套的"selector"字段,通过"matchLabels"来指定标签选择器,有的甚至还支持使用"matchExpressions",构造复杂的标签选择机制

  • matchLabels:通过直接给定键值对指定标签选择器;

  • matchExpressions:基于表达式指定的标签选择器列表,每个选择器形如"{key: KEY_NAME, operator: OPERATOR, values:[VALUEl,VALUE2,...]}" 选择器列表间为"逻辑与"关系;

  • 使用In或NotIn操作符时,其values非必须为非空的字符串列表,而使用Exists 或DostNotExist时,其values必须为空。

<pre data-language="plain" id="bab7e13d" class="ne-codeblock language-plain" style="border: 1px solid #e8e8e8; border-radius: 2px; background: #f9f9f9; padding: 16px; font-size: 13px; color: #595959"># 创建时指定标签
~]# cat pod-demo-1.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-demo
namespace: prod
labels:
app: pod-demo
rel: stable
spec:
containers:

  • name: myapp
    image: ikubernetes/myapp:v1
  • name: bbox
    image: busybox:latest
    imagePullPolicy: IfNotPresent
    command: ["/bin/sh","-c","sleep 86400"]
    ~]# kubectl apply -f pod-demo-1.yaml
    ~]# kubectl get pods -n prod --show-labels
    NAME READY STATUS RESTARTS AGE LABELS
    pod-demo 2/2 Running 0 13s app=pod-demo,rel=stable

使用label命令来添加标签

~]# kubectl label pods pod-demo -n prod tier=frontend
pod/pod-demo labeled
~]# kubectl get pods -n prod --show-labels
NAME READY STATUS RESTARTS AGE LABELS
pod-demo 2/2 Running 0 4m23s app=pod-demo,rel=stable,tier=frontend
basic]# kubectl get pods -n prod --show-labels
NAME READY STATUS RESTARTS AGE LABELS
pod-demo 2/2 Running 0 4m23s app=pod-demo,rel=stable,tier=frontend

使用label命令来重写标签

~]# kubectl label --overwrite pods pod-demo -n prod tier=test
pod/pod-demo labeled
~]# kubectl get pods -n prod --show-labels
NAME READY STATUS RESTARTS AGE LABELS
pod-demo 2/2 Running 0 5m47s app=pod-demo,rel=stable,tier=test

使用label命令来删除标签

~]# kubectl label pods pod-demo -n prod tier-
pod/pod-demo labeled
~]# kubectl get pods -n prod --show-labels
NAME READY STATUS RESTARTS AGE LABELS
pod-demo 2/2 Running 0 7m18s app=pod-demo,rel=stable

使用Kubectl -l 过滤标签

~]# kubectl get pods --show-labels -l app=myapp
NAME READY STATUS RESTARTS AGE LABELS
myapp-5c6976696c-7p7dp 1/1 Running 0 8d app=myapp,pod-template-hash=5c6976696c
myapp-5c6976696c-czp6d 1/1 Running 0 8d app=myapp,pod-template-hash=5c6976696c
myapp-5c6976696c-rr5v4 1/1 Running 0 8d app=myapp,pod-template-hash=5c6976696c
~]# kubectl get pods --show-labels -l app!=myapp
NAME READY STATUS RESTARTS AGE LABELS
mypod 1/1 Running 0 3d5h <none>
ngx-dep-d554574bd-fq6kq 1/1 Running 0 8d app=ngx-dep,pod-template-hash=d554574bd
~]# kubectl get pods --show-labels -l "app in (myapp,ngx-dep)"
NAME READY STATUS RESTARTS AGE LABELS
myapp-5c6976696c-7p7dp 1/1 Running 0 8d app=myapp,pod-template-hash=5c6976696c
myapp-5c6976696c-czp6d 1/1 Running 0 8d app=myapp,pod-template-hash=5c6976696c
myapp-5c6976696c-rr5v4 1/1 Running 0 8d app=myapp,pod-template-hash=5c6976696c
ngx-dep-d554574bd-fq6kq 1/1 Running 0 8d app=ngx-dep,pod-template-hash=d554574bd
~]# kubectl get pods --show-labels -l "app notin (ngx-dep)"
NAME READY STATUS RESTARTS AGE LABELS
myapp-5c6976696c-7p7dp 1/1 Running 0 8d app=myapp,pod-template-hash=5c6976696c
myapp-5c6976696c-czp6d 1/1 Running 0 8d app=myapp,pod-template-hash=5c6976696c
myapp-5c6976696c-rr5v4 1/1 Running 0 8d app=myapp,pod-template-hash=5c6976696c
mypod 1/1 Running 0 3d5h <none>
~]# kubectl get pods --show-labels -l '!app'
NAME READY STATUS RESTARTS AGE LABELS
mypod 1/1 Running 0 3d5h <none>
~]# kubectl get pods --show-labels -l 'app'
NAME READY STATUS RESTARTS AGE LABELS
myapp-5c6976696c-7p7dp 1/1 Running 0 8d app=myapp,pod-template-hash=5c6976696c
myapp-5c6976696c-czp6d 1/1 Running 0 8d app=myapp,pod-template-hash=5c6976696c
myapp-5c6976696c-rr5v4 1/1 Running 0 8d app=myapp,pod-template-hash=5c6976696c
ngx-dep-d554574bd-fq6kq 1/1 Running 0 8d app=ngx-dep,pod-template-hash=d554574bd</pre>

资源注解(annotation)

  • 注解也是“键值”类型的数据,不过它不能用于标签及挑选kubernetes对象,仅用于为资源提供“元数据"信息

  • 注解中的元数据不受字符数量的限制,它可大可小,可以为结构化或非结构化形式,也支持使用在标签中禁止使用的其他字符

  • 在kubernetes的新版本中(Alpha或Beta阶段)为某资源引入新字段时, 常以注解方式提供以避免其增删等变动给用户带去困扰,一旦确定支持使用它们,这些新增字段再引入到资源中并淘汰相关的注解

<pre data-language="plain" id="2d7865e9" class="ne-codeblock language-plain" style="border: 1px solid #e8e8e8; border-radius: 2px; background: #f9f9f9; padding: 16px; font-size: 13px; color: #595959"># 添加及查看注解,apply就是通过比较注解来添加新的资源
~]# cat pod-demo-1.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-demo
namespace: prod
labels:
app: pod-demo
rel: stable
annotations:
ik8s.io/project: test-info
spec:
containers:

  • name: myapp
    image: ikubernetes/myapp:v1
  • name: bbox
    image: busybox:latest
    imagePullPolicy: IfNotPresent
    command: ["/bin/sh","-c","sleep 86400"]
    ~]# kubectl apply -f pod-demo-1.yaml
    ~]# kubectl describe pods -n prod pod-demo
    Name: pod-demo
    Namespace: prod
    Priority: 0
    Node: node2/10.8.250.21
    Start Time: Tue, 08 Oct 2019 22:01:55 +0800
    Labels: app=pod-demo
    rel=stable
    Annotations: ik8s.io/project: test-info
    kubectl.kubernetes.io/last-applied-configuration:
    {"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{"ik8s.io/project":"test-info"},"labels":{"app":"pod-demo","rel":"stable"},"name...
    Status: Running
    IP: 10.244.3.6</pre>

Pod的生命周期

  • 第一阶段:init container

  • 第二阶段:main container

  • 第一阶段:post start hook(容器启动前的自定义操作)

  • 第二阶段:livenessProbe、readinessProbe(存活及就绪检测)

  • 第三阶段:pre stop hook(容器停止前的自定义操作)

livenessProbe(健康状态监测可以重启容器)

readinessProbe(就绪状态监测不可以重启容器)

<pre data-language="plain" id="51dc924a" class="ne-codeblock language-plain" style="border: 1px solid #e8e8e8; border-radius: 2px; background: #f9f9f9; padding: 16px; font-size: 13px; color: #595959"># lifecycle具体使用查看使用方法
~]# kubectl explain pods.spec.containers.lifecycle

hook的使用示例

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"]</pre>

<pre data-language="plain" id="ceb73371" class="ne-codeblock language-plain" style="border: 1px solid #e8e8e8; border-radius: 2px; background: #f9f9f9; padding: 16px; font-size: 13px; color: #595959"># livenessProbe健康状态监测具体使用查看使用方法
~]# kubectl explain pods.spec.containers.livenessProbe

livenessProbe使用示例

apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-http
spec:
containers:

  • args:
    • /server
      image: k8s.gcr.io/liveness
      ports:
      • name: http
        containerPort: 80
        lifecycle:
        postStart:
        exec:
        command:
        - /bin/sh
        - -c
        - 'echo Healthy > /usr/share/nginx/html/healthz'
        livenessProbe:
        httpGet:

        当没有定义 "host" 时,使用 "PodIP"

        host: my-host

        当没有定义 "scheme" 时,使用 "HTTP" scheme 只允许 "HTTP" 和 "HTTPS"

        scheme: HTTPS

        path: /healthz
        port: 8080
        httpHeaders:
        • name: X-Custom-Header
          value: Awesome
          initialDelaySeconds: 15
          timeoutSeconds: 1
          name: liveness</pre>

<pre data-language="plain" id="bcf59432" class="ne-codeblock language-plain" style="border: 1px solid #e8e8e8; border-radius: 2px; background: #f9f9f9; padding: 16px; font-size: 13px; color: #595959"># readinessProbe就绪状态监测具体使用查看使用方法
~]# kubectl explain pods.spec.containers.readinessProbe

readinessProbe示例

apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-http
spec:
containers:

  • args:
    • /server
      image: k8s.gcr.io/liveness
      readinessProbe:
      exec:
      command: ["test","-e","/tmp/ready"]
      initalDelaySeconds: 5
      name: liveness

主要体现在READY状态上,就绪监测同样为周期监测。只要为0就不会被service所引用。

~]# kubectl get pods -w
NAME READY STATUS RESTARTS AGE
myapp-5c6976696c-7p7dp 0/1 Running 0 9d</pre>

Pod对象的相位

  • Pod对象总是应该处于其生命进程中以下几个相位(phase)之一

  • Pending: API Server创建了Pod资源对象并已存入etcd中,但它尚未被调度完成,或仍处于从仓库中下载镜像的过程中;

  • Running: Pod已经被调度至某节点,并且所有容器都已经被kubelet创建完成;

  • Succeeded: Pod中的所有容器都已经成功终止并且不会被重启;

  • Failed:所有容器都已经终止,但至少有一个容器终止失败,即容器返回了非0值的退出状态或已经被系统终止;

  • Unknown: API Server无法正常获取到Pod对象的状态信息,通常是由于其无法与所在工作节点的kubelet®信所致。

Pod对象的创建过程

image

容1

  • Pod对象因容器程序崩溃或容器申请超出限制的资源等原因都可能导致其被终止,此时是否应该重建此它则取决于其重启策略(restartPolicy)属性的定义

  • Always:但凡Pod对象终止就将其重启,此为默认设定;

  • OnFailure:仅在Pod对象出现错误时方才将其重启;

  • Never:从不重启;

Pod的终止过程

image

Pod Security安全

  • 两个级别

  • pods.spec.securityContext

  • pods.spec.containers.[].securityContext

  • capabilities #添加删除内核能力

<pre data-language="plain" id="f03c6481" class="ne-codeblock language-plain" style="border: 1px solid #e8e8e8; border-radius: 2px; background: #f9f9f9; padding: 16px; font-size: 13px; color: #595959">apiVersion: v1
kind: Pod
metadata:
name: security-context-demo
spec:
securityContext:
runAsUser: 1000
runAsGroup: 3000
fsGroup: 2000
volumes:

  • name: sec-ctx-vol
    emptyDir: {}
    containers:
  • name: sec-ctx-demo
    image: busybox
    command: [ "sh", "-c", "sleep 1h" ]
    volumeMounts:
    • name: sec-ctx-vol
      mountPath: /data/demo
      securityContext:
      allowPrivilegeEscalation: false

在配置文件中,该runAsUser字段指定对于Pod中的任何容器,所有进程都以用户ID 1000运行。

该runAsGroup字段为Pod中的任何容器中的所有进程指定主组ID 3000。如果省略此字段,则容器的主要组ID将为root(0)。

runAsGroup指定时,用户1000和组3000也将拥有所有创建的文件。由于fsGroup指定了字段,因此容器的所有进程也是补充组ID 2000的一部分。

卷的所有者/data/demo和在该卷中创建的任何文件都将是组ID 2000。</pre>

资源需求及资源限制

  • 容器的计算资源配额

  • CPU属于可压缩(compressible)型资源,即资源额度可按需收缩,而内存(当前)则是不可压缩型资源,对其执行收缩操作可能会导致某种程度的问题

  • CPU资源的计量方式

  • 一个核心相当于1000个微核心,即1=1000m,0.5=500m

  • 内存资源的计量方式

  • 默认单位为字节,也可以使用E、P、T、G、M和K后缀单位,或Ei、Pi、Ti、Gi、Mi和Ki形式的单位后缀 image

<pre data-language="plain" id="be3a36f2" class="ne-codeblock language-plain" style="border: 1px solid #e8e8e8; border-radius: 2px; background: #f9f9f9; padding: 16px; font-size: 13px; color: #595959">#以下 Pod 有两个容器。每个容器的请求为 0.25 cpu 和 64MiB(226 字节)内存,每个容器的限制为 0.5 cpu 和 128MiB 内存。

你可以认为该 Pod 请求 0.5 cpu 和 128 MiB 的内存,限制为 1 cpu 和 256MiB 的内存。

requests:下限,不满足则不启动。limits:上限

apiVersion: v1
kind: Pod
metadata:
name: frontend
spec:
containers:

  • name: db
    image: mysql
    env:
    • name: MYSQL_ROOT_PASSWORD
      value: "password"
      resources:
      requests:
      memory: "64Mi"
      cpu: "250m"
      limits:
      memory: "128Mi"
      cpu: "500m"
  • name: wp
    image: wordpress
    resources:
    requests:
    memory: "64Mi"
    cpu: "250m"
    limits:
    memory: "128Mi"
    cpu: "500m"</pre>

Pod服务质量类别

  • 根据Pod对象的requests和llimits属性, Kubernetes把Pod对象归类到BestEffort、 Burstable和Guaranteed三个服务质量类别(Quality of Service,QoS)类别下

  • Guaranteed:每个容器都为CPU资源设置了具有相同值的requests和limits属性, 以及每个容器都为内存资源设置了具有相同值的requests和limits属性的pod资源会自动归属此类别,这类pod资源具有最高优先级

  • Burstable: 至少有一个容器设置了CPU或内存资源的requests属性,但不满足Guaranteed类别要求的pod资源自动归属此类别,它们具有中等优先级

  • BestEffort:未为任何一个容器设置requests或limits属性的pod资源自动归属此类别,它们的优先级为最低级别

<pre data-language="plain" id="039e6e76" class="ne-codeblock language-plain" style="border: 1px solid #e8e8e8; border-radius: 2px; background: #f9f9f9; padding: 16px; font-size: 13px; color: #595959">#在Qos中显示
~]# kubectl describe pods mypod
...
QoS Class: BestEffort
Node-Selectors: <none>
...</pre>

Pod Controller

Pod就是一种资源,资源代表一种类型

创建出来的具体的Pod就是对象,对象代表一种实力

  • 在机器人技术和自动化应用中,控制回路是调节系统状态的非终止回路。

  • 在Kubernetes中,控制器是一个控制回路,它通过API服务器监视集群的共享状态,并进行更改,试图将当前状态移动到所需状态。

  • Kubernetes运行一组控制器,负责日常任务,以确保集群的期望状态与观察到的状态匹配。

  • 基本上,每个控制器负责Kubernetes世界的特定资源。

  • 对于用户管理其集群,重要的是用户了解Kubernetes中每个控制器的角色。


  • 控制器是Kubernetes的重要组成部分

  • 他们是资源背后的“大脑”。

  • 例如,Kubernetes的部署资源负责确保有一定数量的pod在运行,节点控制器查找服务器的状态,并在服务器停机时做出响应

image
  • Informer/SharedInformer监视Kubernetes对象的当前状态的更改,并将事件发送到Workqueue,然后由worker弹出事件进行处理。
image

kube-controller-manager

  • 为了减少复杂性,所有控制器都封装在一个名为Kube -Manager管理器的守护程序中。

  • Kubernetes控制器管理器是一个守护进程,它嵌入了K ubernetes附带的核心控制循环。

  • --controllers选项用于指定要启用的控制器

  • "*"在默认情况下启用所有控制器,"foo"启用名为"foo"的控制器,"--foo"禁用名为"foo"的控制器。

  • 所有控制器: attachdetach, bootstrapsigner, clusterrole aggregation, cronjob, csrapproving,csrcleaner, csrsigning, daemonset, deployment, disruption, endpoint, garbagecollector,horizontalpodautoscaling, job, namespace, nodeipam, nodelifecycle, persistentvolume一binder,persistentvolume expander, podgc, pv- protection, pvc- protection, replicaset, replicationcontroller,resourcequota, route, service, serviceaccount, serviceaccount token, statefulset, tokencleaner, ttl

  • 默认禁用控制器:bootstrapsigner、tokencleaner

kube-controller-manager

  • 控制器本身也是标准得Kubernetes资源类型,它们可以被实例化出具体的对象负责具体任务;控制器资源对象自身也会存在相应的管理操作;

  • 例如一个特定的Deployment控制器对象负责管理由标签选择器匹配到得Pod资源对象;

  • 控制器资源对象自身的创建、更新及删除操作由控制器进程负责,这些进程统一打包了kube-controller-manager之中;

  • 而kube-controller-manager自身的运行正常与否的状况则需要通过冗余的方式设置;

<pre data-language="plain" id="5ec7e5f0" class="ne-codeblock language-plain" style="border: 1px solid #e8e8e8; border-radius: 2px; background: #f9f9f9; padding: 16px; font-size: 13px; color: #595959">#更改kube-controller-manager的yaml位置,更改后k8s会自动识别并重新启动kube-controller-manager
/etc/kubernetes/manifests/kube-controller-manager.yaml</pre>

Pod Controllers

  • 自助式Pod

  • Node: kubelet

  • 早期版本: ReplicationController

  • 应用程序可划分为多种类型:

  • 守护进程型:

  • 无状态:

  • 非系统级:Deployment,ReplicaSet

  • 系统级:DaemonSet(比如监控)

  • 有状态: StatefulSet

  • 非守护进程型:

  • Job

  • CronJob

  • ReplicaSet

  • 复制集

  • Label Selector

  • Label

ReplicaSet

  • ReplicaSet 确保在任何指定时间运行指定数量的Pod副本。

  • Pod 规格

  • Pod 模板

  • Pod 选择器

  • 副本集

  • 使用ReplicaSets

  • 删除 ReplicaSets 及其 Pod

  • 仅删除一个ReplicaSet

  • 从 ReplicaSet 隔离Pod

  • 缩放 ReplicaSet

<pre data-language="plain" id="t20sr" class="ne-codeblock language-plain" style="border: 1px solid #e8e8e8; border-radius: 2px; background: #f9f9f9; padding: 16px; font-size: 13px; color: #595959">kubectl explain rs
kubectl api-versions

matchLabels 和 template 的 labels 必须匹配

标签选择器一旦选中,必须删除控制器才能更改

root@k8s-master:/data/k8s-learn# cat rs-example.yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: myapp-rs
namespace: prod
spec:
replicas: 2
selector:
matchLabels:
app: myapp-pod
template:
metadata:
labels:
app: myapp-pod
spec:
containers:
- name: myapp
image: ikubernetes/myapp:v1
ports:
- name: http
containerPort: 80

通过修改pod的标签也会对副本数量产生影响,只认标签

kubectl label --overwrite pod myapp-rs-p92pg -n prod app=test

查看标签

kubectl get pods -n prod --show-labels

主要使用 Deployment ,Deployment 会自动创建 ReplicaSet 且名称最后带模板哈希

maxSurge为最多允许多出的pod数量,maxUnavailable为最多不可用pod数量

比如当前副本集为4,对多可多出1,先加1个,当前副本集为5,最多不可用为1(这里是以加上maxSurge后的副本数5为基准)

所以这里是加1,减1,加1,减1

root@k8s-master:/data/k8s-learn# cat de-example.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
namespace: prod
spec:
replicas: 4
minReadySeconds: 10
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
type: RollingUpdate
selector:
matchLabels:
app: myapp-ng
environment: production
template:
metadata:
labels:
app: myapp-ng
environment: production
spec:
containers:
- name: myapp
image: ikubernetes/myapp:v1
ports:
- name: http
containerPort: 80
readinessProbe:
periodSeconds: 1
httpGet:
path: /
port: http

root@k8s-master:/data/k8s-learn# kubectl apply -f de-example.yaml --record=true
deployment.apps/myapp created
root@k8s-master:/data/k8s-learn# kubectl get rs -n prod
NAME DESIRED CURRENT READY AGE
myapp-b97bcbcc9 4 4 4 7s
root@k8s-master:/data/k8s-learn# kubectl get pods -n prod --show-labels
NAME READY STATUS RESTARTS AGE LABELS
myapp-b97bcbcc9-k4d7w 1/1 Running 0 12s app=myapp-ng,environment=production,pod-template-hash=b97bcbcc9
myapp-b97bcbcc9-qk5xk 1/1 Running 0 12s app=myapp-ng,environment=production,pod-template-hash=b97bcbcc9
myapp-b97bcbcc9-stz5b 1/1 Running 0 12s app=myapp-ng,environment=production,pod-template-hash=b97bcbcc9
myapp-b97bcbcc9-xxwcq 1/1 Running 0 12s app=myapp-ng,environment=production,pod-template-hash=b97bcbcc9

查看回滚历史

root@k8s-master:/data/k8s-learn# kubectl rollout history deployment/myapp -n prod
deployment.apps/myapp
REVISION CHANGE-CAUSE
1 <none>
2 <none>
3 kubectl apply --filename=de-example.yaml --record=tru

回滚,默认向前回滚1

root@k8s-master:/data/k8s-learn# kubectl rollout history deployment/myapp -nprod
deployment.apps/myapp
REVISION CHANGE-CAUSE
1 <none>
2 <none>
3 kubectl apply --filename=de-example.yaml --record=true

--to-revision=0: The revision to rollback to. Default to 0 (last revision).

root@k8s-master:/data/k8s-learn# kubectl rollout history deployment/myapp -n prod
deployment.apps/myapp
REVISION CHANGE-CAUSE
1 <none>
2 <none>
3 kubectl apply --filename=de-example.yaml --record=true

root@k8s-master:/data/k8s-learn# kubectl rollout status deployment/myapp -n prod
deployment "myapp" successfully rolled out
root@k8s-master:/data/k8s-learn# kubectl rollout undo deployment/myapp -n prod
deployment.apps/myapp rolled back
root@k8s-master:/data/k8s-learn# kubectl rollout history deployment/myapp -n prod
deployment.apps/myapp
REVISION CHANGE-CAUSE
1 <none>
3 kubectl apply --filename=de-example.yaml --record=true
4 <none>

</pre>

相关文章

  • K8S资源配置清单1

    API server 接受和返回的所有 JSON 对象都遵循同一个模式,它们都具有 "kind" 和 "apiVe...

  • k8s环境搭建

    k8s环境搭建 文档介绍在Docker for mac中的k8s如何把环境搭建好。 清单: docker for ...

  • k8s-02-常见资源

    1.创建pod资源 pod是最小资源单位.任何的一个k8s资源都可以由yml清单文件来定义 k8s yaml的主要...

  • 0331晨读感悟

    一、关于资源配置 1、资源配置集中的地方就会形成企业的价值观选择, 2、战略改变,资源配置也要改变 3...

  • 1.0-前期准备所需资料目录

    一.资源配置 1.阿里云资源配置网站:http://mirrors.aliyun.com 二.关于Linux系统相...

  • 12使用kubernetes搭建ELFK收集容器日志

    一、创建一个新的命名空间 二、部署elasticSearch 创建yaml存放目录 资源配置清单 三、部署logs...

  • nginx动静分离

    1、准备环境准备一个nginx代理 两个http 分别处理动态和静态。 静态资源配置 动态资源配置:

  • 230期-G7-李春彪-宁波与人交互清单190512

    需要见面清单: * 谈重要项目; * 以资源配置者身份出现时; * 以第三者身份介绍双方认识。 见面的情境: * ...

  • 2017-03-31晨读

    1.战略与资源配置密切相关,再好的战略计划如果资源配置跟不上了,也是镜中月,水中花,战略的实行离不开“人,物,财”...

  • 部署单点k8s集群(非翻墙)

    基础环境:centos7当前k8s版本: v1.13集群清单: 1. 准备工作 创建服务器的时候,系统盘不要小于5...

网友评论

      本文标题:K8S资源配置清单1

      本文链接:https://www.haomeiwen.com/subject/dllnhrtx.html