CKA怎么备考？

Posted 2023-03-30

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了CKA怎么备考？相关的知识，希望对你有一定的参考价值。

CKA全称Certified Kubernetes Administrator，是一门在线考试，全程需要向考官分享摄像头和屏幕，考试费用300美元。

考试时间3小时，总共24道实操题，不同的题目有不同的分数比重，74分通过，难度适中。

知识储备：

熟练的linux操作

系统化学习完kubernetes（考试会涉及daemonset、initcontainer、pv、taint、nodeselector、secret的环境变量使用、存储挂载、性能查看、静态pod和pod迁移等等）

英语阅读能力（四级就够，纯文字交流，需要与老外进行交流，比如我在考试的时候用摄像头环顾周围的时候护照放在了桌子上，被提醒不得把护照放在桌子上。还有考官会要求查看桌子底下有没有人）

考试环境准备：

护照（身份证不行、因为需要有姓名拼音的证件）

电脑（带摄像头那种，推荐笔记本，屏幕捕捉和摄像头监视是通过chrome插件，不越墙自然就不能加载谷歌chrome商店了）

密室（选择一个安静环境，锁上门，不得有其他人闯入）

干净的桌面（桌子上什么都不能有）

（需要有一台海外VPS搭建SS服务器实现越墙，SS客户端在任务管理器中需要是后台显示方式，因为考试期间考官会要求你关闭除了chrome以外所有应用，至于到底要不要越墙，我反正是搭了，因为考官检测完我的考试环境后考试系统进加载不进去了，然后我立马启用了全局代理）

注意事项：

考试需要提前15分钟准备考试环境并和考官沟通检查考试环境

参考技术A CKA是线上考试，难度中等，好好准备下容易就能考过的。
kubernetes已经成为容器编排领域的事实性标准，Kubernetes不仅使得应用交付更便捷、大规模的微服务部署更容易，同时让DevOps理念和敏捷IT更容易落地。Kubernetes将助力企业在数字化转型过程中实现弯道超车。
作为国内领先的全栈云原生技术服务提供商，时速云特别推出了Kubernetes培训课程，对于刚接触Kubernetes技术、企业计划使用容器及Kubernetes集群、以及计划考取CKA证书的人群会是一个不错的选择。

课程大纲：
第一部分

《Kubernetes解析及实践》

1.Kubernetes总览
1.1.Kubernetes及其生态
1.2.Kuberntees的基本架构
1.3.Kubernetes核心组件及工作原理
1.4.kubectl及KubernetesAPI等工具的使用

2.如何操作Kubernetes的资源对象
2.1.容器组Pod
2.2.Kubernetes主要控制器介绍
2.3.配置管理
2.4.任务/定时任务

第二部分

3.网络管理
3.1.Kubernetes的网络模式
3.2.网络插件（Calico、Flannel、Macvlan等网络模式，CNI、IPAM介绍）
3.3.常用的Ingress负载均衡及其工作原理

4.存储管理
4.1.Kubernetes中存储相关资源介绍
4.2.存储的供给方式
4.3.NFS使用方式
4.4.Ceph使用方式
4.5.本地存储使用方式
4.6.中间件集群结合存储的使用实践

5.日志管理
5.1.实时查看日志
5.2.理解K8s对节点上容器?志的处理?式
5.3.使?EFK进??志统?收集
5.4.如何收集容器内的应??志
5.5.大规模服务下日志的管理实践

6.监控、告警系统
6.1.Kubernetes的主要监控方案
6.2.相关开源组件Prometheus、alertmanager等使用方式
6.3.容器PaaS平台下服务、节点的监控告警实践

7.调度算法
7.1.Pod调度的相关概念
7.2.相关调度策略和算法
7.3.Node亲和性
7.4.Pod亲和性和反亲和性
7.5.如何使用污点和容忍

8.多可用区/多集群管理模式
8.1MultipleZone模式
8.2联邦集群
8.3.基本概念
8.4.主要架构
8.5.基本工作模式

9.基于Kubernetes的DevOps实践
9.1.基于Kubernetes构建原生CI/CD流水线
9.2.Kubernetes平台的日常运维管理以及多集群管理实践

10.Kubernetes扩展的利器Operator
10.1自定义资源CRD/Operator介绍
10.2如何开发一个简单的Operator
10.3基于Operator实现各种中间件的实践

第三部分
1.CKA考试准备须知及注意事项分享
1）技术、非技术准备
2）考试心得本回答被提问者采纳参考技术B 1.
用初始密码登录系统。
2.
修改初始密码。 ICF要求,一定要修改初始密码,所以,在这里建议大家要记录一下自己的密码,免得因为考试中关闭页面或断网、断电等意外导致的系统退出和重新登录时忘记密码,而且密码找回会比较费劲。
3.
报考位置。这里缺了一张系统截图,我就文字描述一下了。这个页面是一些新闻和信息
4.
功能菜单页面。参考技术C 。使初始密码录修改初始密码。要必须改初始密码。因此，建议您自己记录密码，以免考程中因关闭页面或断或断电等意外关机而退出重新录时忘记密码

[CKA备考实验][Pod]2.2 Pod的探针类型及其功能演示

0. 三种探针的作用综述

startup probe

有些容器启动可能比较久，为了防止容器在启动过程被误杀，采取了主动探测容器启动状态的方法，而不是被动等待，好处是如果探针检测到pod已启动则马上结束探测进程，避免愚蠢而被动的等待比如延时计时器。

检测期间pod的状态是0/1，也就是运行但未就绪。

liveness probe

顾名思义就是检测pod是否还活着，每隔一段时间探针就要去问一下pod的存活状态，因此可想而知这个询问动作将贯穿pod的整个生命周期。确定启动成功的那一刻，这个询问就开始了，当然你也可以延迟第一次的询问时间点(没有startup probe时期的历史产物)，不过既然startup probe帮你确认了就可以不用再等待了，可以在startup结束的那一刻开始liveness的检测。

需要验证liveness独立工作时是否会出现0/1这个状态，毕竟如果偶然检测失败一次就判定为未就绪的话就太影响容器的工作了，毕竟这个探针只管你的死活，不管你的情绪好坏，只要发现死亡信号打到限定次数则采取拯救措施(心肺复苏)。

readiness probe

这个探针周期性地检测你有没有做好战斗准备，有些容器虽然也运行起来了，但是内部某些必要进程还没有启动完毕或发生异常，则探针就可以按照规则判断容器不健康，无法参与战斗，被标记为未就绪，到并不会被kill掉。

检测未失败之前pod会是什么状态呢，是1/1吗？只有在失败上限达到之后才会变成0/1吗？

探针的五种属性

下面是Kubernetes官网对几个探针参数的说明

Probe 有很多配置字段，可以使用这些字段精确地控制活跃和就绪检测的行为：

initialDelaySeconds：容器启动后要等待多少秒后才启动存活和就绪探针，默认是 0 秒，最小值是 0。
periodSeconds：执行探测的时间间隔（单位是秒）。默认是 10 秒。最小值是 1。
timeoutSeconds：探测的超时后等待多少秒。默认值是 1 秒。最小值是 1。
successThreshold：探针在失败后，被视为成功的最小连续成功数。默认值是 1。存活和启动探测的这个值必须是 1。最小值是 1。
failureThreshold：当探测失败时，Kubernetes 的重试次数。对存活探测而言，放弃就意味着重新启动容器。对就绪探测而言，放弃意味着 Pod 会被打上未就绪的标签。默认值是 3。最小值是 1。

如果一个容器将被判失败，我们一般等待的标准时间为periodSeconds * failureThreashold

至于timeoutSeconds会对等待时间有什么影响还没法验证

1. httpget检测方式

1.1 配置文件概览

配置文件中在原有的Pod配置下增加了3个探针配置，分别为startupProbe, livenessProbe和readinessProbe

apiVersion: v1
kind: Pod
metadata:
  name: probe-httpget
  namespace: default
  labels:
    name: probe-httpget
  annotations:
    name: probe-httpget
spec:
  restartPolicy: Always
  dnsPolicy: Default
  containers:
  - name: nginx
    image: nginx:1.23
    imagePullPolicy: IfNotPresent
    startupProbe: 
      periodSeconds: 10
      timeoutSeconds: 1
      successThreshold: 1
      failureThreshold: 3
      httpGet:
        httpHeaders:
          - name: Host
            value: "www.example.com"
        path: /
        port: 80
        scheme: HTTP
    livenessProbe: 
      periodSeconds: 10
      timeoutSeconds: 1
      successThreshold: 1
      failureThreshold: 3
      httpGet:
        httpHeaders:
          - name: Host
            value: "www.example.com"
        path: /
        port: 80
        scheme: HTTP
    readinessProbe: 
      periodSeconds: 1
      timeoutSeconds: 1
      successThreshold: 1
      failureThreshold: 3
      httpGet:
        httpHeaders:
          - name: Host
            value: "www.example.com"
        path: /
        port: 80
        scheme: HTTP

1.2 启动探针 startupProbe

我们关注的四个参数：

periodSeconds：每隔一段时间探针就检测一次
timeoutSeconds：Pod如果对探针请求不知可否，则探针将在超时时间过后判定探测失败
successThreshold：如果检测Pod为活动状态则记一次成功，如果成功次数达到阈值则判定Pod启动成功
failureThreshold：如果检测Pod超时则记一次失败，如果失败次数达到阈值则判定Pod启动失败，需要杀死Pod执行重启

在以下这个配置实例中，我们配置启动探针每10秒检测一次，检测成功1则判定pod启动成功，失败次数达到3次则判定pod启动失败则执行pod重启

最坏的预测：容器因某种原因，每次都会在超时时间过后也不做回应，那么将在Pod创建10秒后的检测中因收到>=400的返回码而记一次失败，在第20秒开始的第二次检测中再次判为启动失败，记录第2次失败，此时已经过去20秒，再过10秒后执行第三次检测，判定第3次失败，pod将被强制重启，此时已经经过了30秒钟。

    startupProbe:
      periodSeconds: 10
      timeoutSeconds: 1
      successThreshold: 1
      failureThreshold: 3
      httpGet:
        httpHeaders:
          - name: Host
            value: "www.example.com"
        path: /
        port: 80
        scheme: HTTP

我们做一次破坏性试验，实验的配置文件如下，基于该配置，我预测Pod将在30秒后被强制重启

    startupProbe:
      periodSeconds: 10
      timeoutSeconds: 1
      successThreshold: 1
      failureThreshold: 3
      httpGet:
        httpHeaders:
          - name: Host
            value: "www.example.com"
        path: /abc    # 该配置相当于访问一个不存在的页面，返回值将为404
        port: 80
        scheme: HTTP

1.2.1 startupProbe探针测试

观测点1：查看pod是否在预测时刻发生重启

pod在30秒时发生一次重启

观测点2：查看重启前后Pod的就绪状态

Pod在重启前后都处于未就绪状态

# 第30秒pod的重启次数为0
# 就绪状态为0/1，也就是这个pod未就绪
root@node-1:~/pod# kubectl get pods
NAME                       READY   STATUS    RESTARTS        AGE
probe-httpget              0/1     Running   0               30s

# 第32秒pod的重启次数为1，此时Pod的Age为32秒，重启发生在2秒前，我们就可以判断重启发生在第30秒后
# 就绪状态为0/1，也就是这个pod未就绪
root@node-1:~/pod# kubectl get pods
NAME                       READY   STATUS    RESTARTS        AGE
probe-httpget              0/1     Running   1 (2s ago)      32s

观测点3：查看重启后Pod的事件

通过描述信息中的Evnets，我们可以获得信息，启动探针失败原因时收到了状态码404，随即该Pod便被kill掉了，kill和第三次探测失败同时发生，这一点可以在图中标红的两个Events的Age值中发现

Events的Age下面会显示4s (x3 over 24s)，这想要表达的内容是，这条Events表示3次检测发生在最近的24秒，但是由于该Events本身已经是4秒前产生的了，因此我们得知这3次检测是在20秒内完成的。

root@node-1:~/pod# kubectl describe pod probe-httpget

1.3 存活探针 livenessProbe

在以下这个配置实例中，我们配置存活探针每10秒检测一次，检测成功1次则判定pod还活着，失败次数达到3次则判定pod已死，则执行pod重启

最坏的预测：容器因某种原因进程会死掉，那么将在Pod创建10秒后的检测中因收到>=400的返回码而记一次失败，在第20秒开始的第二次检测中再次判为探测失败，记录第2次失败，此时已经过去20秒，再过10秒后执行第三次检测，判定第3次失败，pod将被强制重启，此时已经经过了30秒钟。

    livenessProbe: 
      periodSeconds: 10
      timeoutSeconds: 1
      successThreshold: 1
      failureThreshold: 3
      httpGet:
        httpHeaders:
          - name: Host
            value: "www.example.com"
        path: /
        port: 80
        scheme: HTTP

我们做一次破坏性试验，实验的配置文件如下，基于该配置，我预测Pod将在40秒后被强制重启（别忘了最佳情况下还要算上启动探针的10秒）

    livenessProbe: 
      periodSeconds: 10
      timeoutSeconds: 1
      successThreshold: 1
      failureThreshold: 3
      httpGet:
        httpHeaders:
          - name: Host
            value: "www.example.com"
        path: /abc    # 该配置相当于访问一个不存在的页面，返回值将为404
        port: 80
        scheme: HTTP

1.3.1 livenessProbe探针测试

观测点1：查看pod是否在预测时刻发生重启

pod在40秒时发生一次重启，注意此时启动探针配置正确，需要10秒的检测，检测通过后开启livenessProbe，30秒后判定容器失活，容器重启时一共经历了40秒

观测点2：查看重启前后Pod的就绪状态

Pod在重启前后都处于未就绪状态

root@node-1:~/pod# kubectl get pods -A
NAMESPACE       NAME                                        READY   STATUS      RESTARTS         AGE
default         probe-httpget                               0/1     Running     1 (3s ago)       43s

观测点3：查看重启后Pod的事件

通过描述信息中的Evnets，我们可以获得信息，存活探针失败原因是收到了状态码404，随即该Pod便被kill掉了，kill和第三次探测失败同时发生，这一点可以在图中标红的两个Events的Age值中发现

Events的Age下面会显示4s (x3 over 25s)，这想要表达的内容是，这条Events表示3次检测发生在最近的25秒，但是由于该Events本身已经是5秒前产生的了，因此我们得知这3次检测是在20秒内完成的。

root@node-1:~/pod# kubectl describe pod probe-httpget

从实验结果来看，存活探针的行为跟启动探针基本一致

1.4 就绪探针 readinessProbe

该探针跟存活探针都是伴随这pod的整个生命周期的。就绪探针的检测周期为1秒，这个频率很高，当检测到3次失败时pod将被标记为未就绪，但是不会被重启，这一点和前两个探针不同。该探针的意义在于防止运行中的容器虽然没死但是无法响应请求（未就绪）而影响业务的情况发生，因此一旦确定容器未就绪，就立即停止对该容器的访问，保证业务的正常。试想一下因为一个容器未就绪，某个请求刚好到达该问题容器，这个请求就会一直无法被正常响应，这对用户体验来讲是很糟糕的。

    readinessProbe: 
      periodSeconds: 1
      timeoutSeconds: 1
      successThreshold: 1
      failureThreshold: 3
      httpGet:
        httpHeaders:
          - name: Host
            value: "www.example.com"
        path: /
        port: 80
        scheme: HTTP

我们做一次破坏性试验，实验的配置文件如下，基于该配置，我预测容器将在10秒启动完成后，提示就绪探针失败

    readinessProbe: 
      periodSeconds: 1
      timeoutSeconds: 1
      successThreshold: 1
      failureThreshold: 3
      httpGet:
        httpHeaders:
          - name: Host
            value: "www.example.com"
        path: /abc    # 该配置相当于访问一个不存在的页面，返回值将为404
        port: 80
        scheme: HTTP

1.4.1 readinessProbe探针测试

观测点1：查看pod是否在启动后一直处于未就绪状态

Pod在经过了54秒后任然没有就绪，而且没有重启动作发生

root@node-1:~/pod# kubectl get pod
NAME                       READY   STATUS    RESTARTS      AGE
probe-httpget              0/1     Running   0             54s

观测点2：查看重启后Pod的事件

在Events中查看到了就绪探针失败的告警，但是没有任何重启的动作，符合我们的预期。直到能够探测到容器就绪，否则Pod将一直保持未就绪状态

root@node-1:~/pod# kubectl describe pod probe-httpget

2. TCP检测方式

这里的区别在于原先的httpGet模式被替换成了tcpSocket，其工作原理基本一致，不再赘述

apiVersion: v1
kind: Pod
metadata:
  name: probe-tcp
  namespace: default
  labels:
    name: probe-tcp
  annotations:
    name: probe-tcp
spec:
  restartPolicy: Always
  dnsPolicy: Default
  containers:
  - name: nginx
    image: nginx:1.23
    imagePullPolicy: IfNotPresent
    startupProbe: 
      periodSeconds: 10
      timeoutSeconds: 1
      successThreshold: 1
      failureThreshold: 3
      tcpSocket:
        port: 80
    livenessProbe: 
      periodSeconds: 10
      timeoutSeconds: 1
      successThreshold: 1
      failureThreshold: 3
      tcpSocket:
        port: 80
    readinessProbe: 
      periodSeconds: 1
      timeoutSeconds: 1
      successThreshold: 1
      failureThreshold: 3
      tcpSocket:
        port: 80