CKA考试

CKA是什么?

K8s的专业技术认证主要有以下几种:

CKA(Kubernetes 管理员认证)
CKAD(Kubernetes 应用程序开发者认证)
CKS(Kubernetes 认证安全专家。预计2020年11月开放,须先通过CKA认证)

其中,知名度最高、应用范围最广的是CKA认证。

Kubernetes管理员认证(CKA)计划的目的是提供CKA管理员具有执行Kubernetes管理员职责的技能﹑知识和能力的保证。详细介绍:Kubernetes 管理员认证 (CKA)_认证荣誉_课程_THE LINUX FOUNDATION

CKA认证的含金量高吗?

CKA是目前唯一的 Kubernetes 官方认证考试。

CKA考试攻略

1、CKA认证考试报名

CKA目前已经推出中文考试服务,并且可以直接使用支付宝购买,并开具发票。

报名地址:https://training.linuxfoundation.cn/certificate/details/1

中文报名考试费用为2088元人民币。

CKA现有以下考试方式可供选择: 英文监考官–线上考试 (考试编号:CKA), 中文监考官–线上考试(考试编号:CKA-CN)。可选择远程或者是在考点进行考试(考点的网络情况也一般,并无太大区别)。

2、CKA认证考试准备

以中文考试为例,需要做好以下准备:

  • 先进行身份验证,准备身份证及有本人签名的信用卡(境内境外都可以)
  • 约考(有效期一年,注意时区问题。考试前24小时可修改
  • 环境检测(WebDelivery Compatibility Check需要科学上网、安装插件)等如下事项

所有准备项均通过后才可正式参加考试。

3、CKA认证考试系统要求

  1. 考试要求使用chrome或其他chromium内核的浏览器,安装innovactive exams screensharing插件,并打开第三方cookie。建议使用较新版本的chrome。
  2. 需要同步音频、视频和桌面,对网络带宽及稳定性有较高要求。建议科学上网。并且如果是共用网络,提前和他人打声招呼,不要看视频或者下载大文件。
  3. 提前准备好麦克风等设备,确保能采集到考试环境声音。笔记本电脑用自带的即可。
  4. 提前准备好摄像头等设备,确保能采集到考试环境画面,监考官会要求移动摄像头查看桌面、桌底以及周围环境。笔记本电脑用自带的即可。

4、CKA认证考试环境准备

  • 整洁的桌面
    • 桌面不能有纸、笔、电子设备或其他杂物。可以喝水,不能吃东西,饮用水不能有标识。
    • 桌底不能有纸、垃圾桶或其他杂物
  • 干净的墙壁
    • 墙壁上不能贴有纸或打印物。如果有在考试开始前会被要求移除
    • 可以有画作或者墙壁装饰
  • 光线
    • 要求光线充足,能看清考生的脸、手和周围环境
    • 考生身后没有明亮的灯光或者窗户
  • 其他
    • 考试期间考生必须留在摄像头范围内
    • 考试环境应尽可能安静,避免咖啡厅、开放式办公场所等

CKA考试注意事项

CKA认证考试报名后从哪可以进入考试?

CKA认证考试报名后可通过用户中心入口进入考试,在考试开始前15分钟才开放入口。
考生需提前15分钟进入考试系统, 以便给监考时间考察考试环境,避免占用考试时间。

CKA认证考试是如何进行的?

考试是在线进行的,时长3小时。如果遇到意外情况,监考官会适当延长考试时间。

监考官通过文字、语音(全程不需要语音交流,主要是方便监考官监视环境)、视频、屏幕共享进行监控。因此对网络环境有较高要求,对于中国内地考生需要科学上网。

考试时与监考官主要通过live chat文字交流。监考官如果发现有异常行为(如摄像头黑了、考生手挡住嘴巴),可能会暂停考试,通过live chat文字聊天提醒考生。

考试全程均为上机题。完成考试任务的方法可能不止一种,除非另有说明,否则只要产生的结果正确即可。考试以结果作为评价标准。

考试过程中考试可以请求暂停考试,但是时间不会停止。建议考试前先解决个人需求。

CKA认证考试的语言?

考试提供英文、简体中文、日文三种语言选择,可在页面自由切换。默认会根据浏览器选择进行切换,建议选择英语,减少翻译的时间以及翻译不准导致的理解偏差。

CKA认证考试时的要求?

  1. 考试前需通过摄像头向监考官展示护照等身份信息(需能清楚看到姓名、照片、有效期等)。
  2. 考试时除了考试平台页面,最多打开一个附加tab页面,可查询https://kubernetes.io/docs/, https://github.com/kubernetes/, https://kubernetes.io/blog/ 和他们其他语言的子页面 (如https://kubernetes.io/zh/docs/)。不能打开除以上网址之外的页面,包括https://discuss.kubernetes.io/。以上页面可能包含跳转到其他页面的链接,考生有责任识别,否则将视为作弊。
  3. 考试现场需保持安静,不许有他人进入。
  4. 考生禁止读题,禁止用手挡住嘴巴等。
  5. 考试时间结束后,由监考官判断是否需要延迟交卷。由监考官决定是否结束考试并自动交卷,不用考生主动交卷。

CKA认证考试及格及补考政策

2020年9月更新的CKA新版考试66分以上即可通过(原定72分),考试不通过有一次补考机会。

CKA认证考试何时可知道考试结果?

考试结束后会自动评分,36小时内会收到邮件告知考试结果是否通过。具体考试分数及证书需在linux基金会考试中心查询。

CKA认证有效期?

CKA认证有效期为3年。3年之后根据个人需要决定是否重考。

CKA考纲

考试一般选择最新版本的k8s,目前使用的是1.19版本。考纲会随着k8s版本更新而更新。

考纲详情:

集群架构,安装和配置:25%

• 管理基于角色的访问控制(RBAC)

• 使用Kubeadm安装基本集群

• 管理高可用性的Kubernetes集群

• 设置基础架构以部署Kubernetes集群

• 使用Kubeadm在Kubernetes集群上执行版本升级

• 实施etcd备份和还原

工作负载和调度:15%

• 了解部署以及如何执行滚动更新和回滚

• 使用ConfigMaps和Secrets配置应用程序

• 了解如何扩展应用程序

• 了解用于创建健壮的、自修复的应用程序部署的原语

• 了解资源限制如何影响Pod调度

• 了解清单管理和通用模板工具

服务和网络:20%

• 了解集群节点上的主机网络配置

• 理解Pods之间的连通性

• 了解ClusterIP、NodePort、LoadBalancer服务类型和端点

• 了解如何使用入口控制器和入口资源

• 了解如何配置和使用CoreDNS

• 选择适当的容器网络接口插件

存储:10%

• 了解存储类、持久卷

• 了解卷模式、访问模式和卷回收策略

• 理解持久容量声明原语

• 了解如何配置具有持久性存储的应用程序

故障排除:30%

• 评估集群和节点日志

• 了解如何监视应用程序

• 管理容器标准输出和标准错误日志

• 解决应用程序故障

• 对群集组件故障进行故障排除

• 排除网络故障

CKA考试页面布局

考试页面左边是题目,右边是终端。可以使用考试系统自带的笔记本,大小位置可以拖拽(大小通过拖拽笔记本边框的右边和下边实现)。
题目的变量点击即可复制(切换上下文的语句点完还是再点下复制)。

CKA考试答题策略

考试需要在3小时内完成24道题,全部都是上机题,熟练的可能1个小时就能答完。按照难度每道题分值从1~9分不等,覆盖pod、pv等对象的创建、部署及回滚、集群搭建、排错等范畴。题目普遍不难,但是细节上批改地非常严格,需要做题时仔细阅读题干。答题时需合理分布时间,可先跳过不熟悉的题目,通过考试系统自带的标记功能标记题目,也可将题号记在考试系统的笔记本上。

CKA备考及学习方法

  1. 官方学习资料
    证书考试预备课程:Kubernetes 基础课程 (LFS258)_课程_THE LINUX FOUNDATION
  2. 官方文档
    强烈建议熟读官方文档,最好跟着实操。考试时可以直接查看官方文档,熟悉文档能大大提高考试速度。考生手册:CNCF Certification Candidate Resources – Linux Foundation – Training
  3. 培训课程
    目前有许多专业的机构提供培训服务,收费在5000元-10000元左右,根据个人需求决定是否选择。如果缺少经验可以考虑报名,也可以看一看免费公开课,对课程有一些初步了解。
    Linux基金会中国区官方培训平台——Linux基金会开源软件大学每月都会进行免费公开课活动,为大家带来干货满满的K8s知识,目前已经进行了两期直播,观看地址如下:

“源来如此”开源技术公开课第一期_哔哩哔哩 (゜-゜)つロ 干杯~-bilibili​www.bilibili.com/video/BV1Hy4y1y7Wi“源来如此”开源技术公开课第二期:K8s 1.19实战讲解_哔哩哔哩 (゜-゜)つロ 干杯~-bilibili​www.bilibili.com/video/BV1m54y117jJ

Linux基金会开源软件大学的人才激励计划已经启动,申请通过后可免费进行考试及配套课程的学习,点击这里申请。

TIPS

  1. 考试系统的 Ctrl+C 、Ctrl+V的替代键为Ctrl+Insert、Shift+Insert。实际考试时可灵活利用
  2. 注意k8s上下文切换,每题可能不完全一样,尤其是后面的题目。建议直接复制题目中的语句执行,题目一开始会有提醒。
  3. 考试过程中可能会出现lost connection之类的情况,多半是网络原因,可以尝试切换VPN节点。
  4. 考试中断浪费的时间,可以向监考官申请延长考试结束时间,一般监考官会主动延长。
  5. 不小心违规了(如手挡住嘴巴),最好向监考官表达歉意,毕竟是不是作弊、考试延长多少时间都看监考官心情。
  6. 与考点相关的官方文档可以提前加入收藏夹。考试时直接根据考点快速查看,相当于建了个索引,能极大提高检索效率。
  7. 尽量从官网复制yaml文件而不是手打,能大大提高效率,也避免敲错浪费时间。
  8. 建议将命令、yaml文件先复制到记事本中,再复制到终端执行。
  9. 尽量使用命令创建deployment等对象,比写yaml要准确高效得多。
  10. 命令记得熟最好,不行就灵活利用-h。多练手,少把时间花在死记硬背上。
  11. kubeadm是考点,分值还不低。建议考试前结合文档自己亲自用kubeadm搭建集群,至少熟悉文档位置。
  12. 考试时注意ns、label等细节,尤其是在排序、查数类型的题目上。

原文链接:快速拿下CKA认证考试,这些要求和tips你得知道_zhengide的博客-CSDN博客

、如何报名

报考地址: https://www.cncf.io/certification/cka ,我是在做活动的时候买的,好像是可以打六折,还有培训课程,挺便宜的,大家可以关注一下黑色星期五呀,或者网购星期一等美国的活动。

  • 有效期一年。在一年内需要定好考试的时间。
  • 提前15分钟进入考试系统, 提前进入考试系统后并不是立马开始考试,而是预留给考官时间考察你的考试环境
  • 考试时间 ,注意报考的TimeZone。默认是UTC时间,请改成China Time。
  • 修改考试时间,考试前24小时且工作日内可更改。
  • 提前准备VISA功能的信用卡,和护照

小福利:报名优惠码(DCUBEOFFER),可以优惠16%,相当于300大洋人民币哦~

image-20200330134432188

二、考试大纲

考纲地址: https://github.com/cncf/curriculum

我们就拿最新的 1.17 版本来说,其实和版本关系也不太大,因为很多新版本的新功能官方并不考察,主要还是一些基本的用法。

5% – Scheduling

  • Use label selectors to schedule Pods.
  • Understand the role of DaemonSets.
  • Understand how resource limits can affect Pod scheduling.
  • Understand how to run multiple schedulers and how to configure Pods to use them.
  • Manually schedule a pod without a scheduler.
  • Display scheduler events.
  • Know how to configure the Kubernetes scheduler.

5% – Logging/Monitoring

  • Understand how to monitor all cluster components.
  • Understand how to monitor applications.
  • Manage cluster component logs.
  • Manage application logs.

8% – Application Lifecycle Management

  • Understand Deployments and how to per form rolling updates and rollbacks.
  • Know various ways to configure applications.
  • Know how to scale applications.
  • Understand the primitives necessary to create a self-healing application.

11% – Cluster Maintenance

  • Understand Kubernetes cluster upgrade process.
  • Facilitate operating system upgrades.
  • Implement backup and restore methodologies.

12% – Security

  • Know how to configure authentication and authorization.
  • Understand Kubernetes security primitives.
  • Know to configure network policies.
  • Create and manage TLS certificates for cluster components.
  • Work with images securely.
  • Define security contexts.
  • Secure persistent key value store.

7% – Storage

  • Understand persistent volumes and know how to create them.
  • Understand access modes for volumes.
  • Understand persistent volume claims primitive.
  • Understand Kubernetes storage objects.
  • Know how to configure applications with persistent storage.

10% – Troubleshooting

  • Troubleshoot application failure.
  • Troubleshoot control plane failure.
  • Troubleshoot worker node failure.
  • Troubleshoot networking.

19% – Core Concepts

  • Understand the Kubernetes API primitives.
  • Understand the Kubernetes cluster architecture.
  • Understand Services and other network primitives.

11% – Networking

  • Understand the networking configuration on the cluster nodes.
  • Understand Pod networking concepts.
  • Understand service networking.
  • Deploy and configure network load balancer.
  • Know how to use Ingress rules.
  • Know how to configure and use the cluster DNS.
  • Understand CNI.

12% – Installation, Configuration & Validation

  • Design a Kubernetes cluster.
  • Install Kubernetes masters and nodes.
  • Configure secure cluster communications.
  • Configure a Highly-Available Kubernetes cluster.
  • Know where to get the Kubernetes release binaries.
  • Provision underlying infrastructure to deploy a Kubernetes cluster.
  • Choose a network solution.
  • Choose your Kubernetes infrastructure configuration.
  • Run end-to-end tests on your cluster.
  • Analyse end-to-end tests results.
  • Run Node end-to-end tests.
  • Install and use kubeadm to install, configure, and manage Kubernetes clusters

三、考试注意事项

3.1、考试形式

  • 3个小时, 24道题目。 需要在封闭无人的房间进行, 要求桌面没有其他东西, 并且房间没有人进出
  • 在线考试, 需要网络环境十分稳定, 并且 *** 也需要稳定, 不然断线了的话会很麻烦
  • 考试全部都是实际操作题, 会给出多个 kubernetes 集群, 要求你完成指定的操作
  • 考试题目的分数按照操作的难度变化, 1~8分不等
  • 开始需要出示有英文名字的官方证件, 一般护照最好。 如果没有护照可以使用身份证+英文其他证明的方式
  • 考试中是可以查阅 kubernestes.io 的官网的, 并且可以使用事先定义好的书签, 来快速查找到自己之前查看过得内容
  • 考试题目普遍不难, 但是细节上批改地非常严格, 需要做题时仔细阅读题干
  • 如果笔记本的分辨率比较小,或者屏幕比较小,不方便操作,允许笔记本外接一个大的显示器进行考试
  • 在考试过程中, 考官需要你进行共享屏幕和共享摄像头, 并且摄像头需要完整地能够看到你的脸的

3.2、考试界面

image-20200330140831200
  • 在考试过程中,可以选择具体的语言, 我考试的时候记得有三种语言可选,中文,英文,日文。 但是中文翻译有时不是很准确, 因此需要对照进行
  • 考试过程中可以使用记事本,方便我们进行记录与修改,因为终端比较卡,我们可以先把命令写在记事本上,然后再复制到终端进行执行

3.3、参加考试

在我们预约好考试时间之后,我们会收到官方的邮件,点击里面的地址,等待考试的开始,在倒计时还剩余15分钟左右,我们就可以提前进入,以供监考老师检查我们的环境。

image-20200330144538507

3.4、应答技巧

  • 只允许打开多一个Chrome的 Tab,考生可以使用Chrome或Chromium浏览器打开一个新的标签页,以便访问  https://kubernetes.io/docs/ 及其子域、 https://github.com/kubernetes/ 及其子域或  https://kubernetes.io/blog/ 。 考试期间不能打开其他标签页,或浏览到其他站点。 以上允许的网站可能包含指向外部网站的链接,考生有责任不点击任何导致他们导航到不允许的域的链接。
  • 考生有义务甄别不是上述两个地址的网址,千万不要点开!
  • 建议平时多练习,总结kubectl的一些技巧;了解k8s资源yaml文件的结构,参考k8s的api文档学习里边相关参数的含义,可以按着官方文档把里边的例子搞一搞。
  • 可以事先把官方文档分类放到浏览器的收藏夹里(考试用的Google Chrome),这样遇到相关内容的考题就可以快速打开查看。
  • 考试的时候网络一定要好,毕竟是国外的考试。
  • 多多利用记事本功能。

3.5、答题技巧

1、审题:

审题一定要仔细再仔细。题目有中文翻译的版本,但标点符号特别少,断句可能会出现问题,建议切换成英文版本再看一遍。

其中有一题是关于 DNS 查询的,把查询结果写入指定的文件中,这里请注意,中文写入的文件和英文版本写入的文件不一样,中文的文件首字母变成了大写,所以答题完之后,在英文版本下检查一遍所有文件。

2、答题策略

整场考试总计24道题,分值高的题目花费的时间较多,我遇见的是集群故障排查、和 TLS Bootstraping,以及节点失联、一般较为靠后。但不是所有分值高的题目都在最后,(我的最后一题是创建 PV,2%)。合理规划答题策略。

3、网络问题

根据同行交流经验所得,CKA 考试普遍网络较慢,表现为考试系统 Lost Connection,终端反应较慢、无法进入终端的情况:

Lost Connection:在考试计时器停止后,考官会给你相应的额外时间。

无法进入终端:这种情况使用考试系统上的 reflash exam window 按钮。刷新后重新进入终端,此时会退出特权模式,需要重新使用 sudo -i 进入。且bash环境需要重新配置。(bash这块不确定,反正kubectl的自动补全我是执行了好几次)

终端反应慢:这块无解,只能重其他技巧节省时间。

不要刷新浏览器!不要刷新浏览器!不要刷新浏览器!刷新浏览器会导致考试被终止。

4、节省时间的技巧

  • 考试题目刷出来较慢,建议开考时,将考题列记录考试系统notepad里面,过一遍。
  • kubectl bash自动补全的命令一定要用,最好记录在notepad上。切换环境,关键时刻可以复制粘贴到终端内。
source <(kubectl completion bash)
  • 考试中的终端是可以复制黏贴的、无论如何请多使用终端内复制粘贴的功能(Windows下是Ctrl+Insect复制,Shift+Insect)。终端内复制粘贴一个yaml是毫无压力的,不要被Important Tip和考生手册给误导了,考试界面里面的记事本可以通过 Ctrl +C 复制,Ctrl + V 粘贴,把官方文档的内容复制过来的时候,是很方便的。
  • 尽量不要使用 kubectl explain 去查询 yaml 的结构,考题都比较简单,我们直接查看官方文档就行,最好是每个类型的题目都做个标签,放入收藏夹,考试的时候可以直接打开,方便查询。
  • 避免手敲yaml,能不手敲yaml的,就别手敲,尽量从文档上复制,手敲的效率太低了,碰上终端响应慢,那是时间的杀手!!
  • 尽量使用命令创建Pod、deployment、service

#创建Pod

kubectl run <podname> --image=<imagename> --generator=run-pod/v1

#创建Deployment

kubectl run <deploymentname> --image=<imagename> 

#暴露Service

kubectl expose <deploymentname> --port=<portNo.> --name=<svcname>
  • 养成使用--dry-runkubectl apply -fkubectl delete -f的习惯,同时将答案和 yaml 写入到文件里,方便根据命令模板修改 yaml,以及后面检查答案时重做题目。
  • 见到不懂或忘记的命令参数,甭管什么 kubectl,etcdctl 的命令,盘他 -h,-h是万能的。里面有示例
  • 最后,考试环境中一定要留意 k8s 环境和尤其是主机名和用户名,默认可以使用 ssh 进入 node, 进入node做完题目后记得退出,不然节点内是无法ssh到下一个题目的node当中去的,节点内终端一般显示
student@<worknodename>

3.6、与考官交流

考试全程与考官在Live Chat上英文交流(文字),考前考官会跟你提示注意事项。考验平时英语作文词汇量的时候到了。国外的考官都很人性化的,考试中有意外状况,询问考官,并向考官争取你应有的权益。

  • 一开始考官会让你展示你的证件,直接护照就可以,如果没有,可以是信用卡,护照的有效期也要展示出来。
  • 然后考官会让你拿摄像头环绕考试环境一周,记得桌子上不要放任何书本和电子产品。
  • 然后考官会让我们打开屏幕监控,把所有的屏幕都放在监控列表中,因为我接了显示器,所以我有两个屏幕
  • 最后考官会告诉我们一些注意事项,比如 记事本功能,以及可以查阅哪些网站资料等等

考试过程中,我们的头要始终在监控图像中,嘴要闭着,不然以为你在说话,脸部不要有什么小动作。

总体来说只要好好复习基本不难,

时间比较紧迫,要分配好时间,

多读文档,保证能迅速的找到需要的知识点,

常用的几个命令记熟了,

并没有太多的时间来犹豫,

考试的时候是可以访问官方文档的,

推荐把重要的知识点都分类保存到标签栏,

纸上谈来终是浅,

考过了也要多实践

kubernetes笔记

概要

  • 考试大纲
  • 题数:24問
  • 考试时间: 3小时
  • 价格:300刀
  • 打折 https://www.goodsearch.org/coupons/the-linux-foundation?open=53827629
  • 对于CKA考试,必须获得74%或以上的分数才能通过。
  • 比例
  • Application Lifecycle Management 8%
  • Installation, Configuration & Validation 12%
  • Core Concepts 19%
  • Networking 11%
  • Scheduling 5%
  • Security 12%
  • Cluster Maintenance 11%
  • Logging / Monitoring 5%
  • Storage 7%
  • Troubleshooting 10%

复习材料

技巧

  • 命令自动补全 source <(kubectl completion bash)
  • 刷新浏览器会导致考试被终止
  • 尽量使用命令创建Pod、deployment、service
  kubectl run podname --image=imagename --restart=Never -n namespace
  kubectl run <deploymentname> --image=<imagename> -n <namespace>
  kubectl expose <deploymentname> --port=<portNo.> --name=<svcname>
  • 使用–dry-run
  kubectl run <podname> --image=<imagename> --restart=Never --dry-run -o yaml > title.yaml

真题

  • 将所有pv按照name排序并输出结果到制定的文件中
  • kubectl get pv –sort-by=.metadata.name
  • DaemonSet
  • 启动一个包含nginx,redis,ubuntu的pod
  • kubectl run test –image=nginx –image=redis –image=ubutu
  • deployment的升级,主要使用rollout
  • deploy的扩容
  • kubectl scale deployment test –replicas=3
  • kubectl edit deploy test
  • 给pod front-app创建对应的service将它暴露出来
  • kubectl expose pod valid-pod –port=444 –name=frontend
  • 将deployment my-nginx绑定nodeport类型service,并且输出service和pod解析的dns日志
  • kubectl expose deployment my-nginx –type=NodePort –port=80 –target-port=80
  • kubectl exec -it busybox nslookup my-nginx
  • pod redis挂载一个volume,挂载到目录/data/redis下,要求目录是non-presist的
  • initcontainer
  • 将pod nginx调度到label为disk=ssd的节点上:nodeselector
  • 将节点node1不参与调度,并将他所有的pod分配到其他node上
  • kubectl drain node1 –ignore-daemonsets –delete-local-data
  • 统计集群中所有的可用节点,不包含不可调度的节点,将个数写到对应的文件中去
  • kubectl get nodes
  • kubectl describe nodename
  • 列出pod中log为file-not-found的行并且写入到指定文件中
  • kubectl logs podname | grep file-not-found > f1.txt
  • 找出service my-app对应的pod中使用cpu最高的pod,将pod名称写入到对应文件
  • kubectl get service -o wide
  • kubectl top node –selector=查出来的label
  • 创建一个sercert 叫my-secret,内容为username=test,分别将他挂载到pod1的/data/secret,设为pod2的环境变量AUTHUSER
  • vi tmd.txt username=test
  • kubectl create secret generic my-secret –from-file=tmd.txt
  • 使用etcd备份,将备份文件存放到指定路径,提供endpoints、ca、cert、key
  • 配置节点启动的静态pod保证修改是永久的
  • 解决节点启动不了的情况,并使改动是永久的
  • systemctl start kubelet
  • systemctl enable kubelet
  • 将一个节点加入集群
  • 解决集群中的问题
  • update node by drain/cordon
  • 必考
  • 日志挂载主机目录
  • deployment创建
  • deployment升级与回滚
  # 暂停
  kubectl rollout pause deployment/nginx-deployment
  # 恢复
  kubectl rollout resume deployment/nginx-deployment
  # 查询状态
  kubectl rollout status deployment/nginx-deployment
  # 查询历史
  kubectl rollout history deployment/nginx-deployment
  kubectl rollout history deployment/nginx-deployment  --revision=2
  # 回滚
  kubectl rollout undo deployment/nginx-deployment --to--revision=2
  • 创建service
    • kubectl create service clusterip my-svc –clusterip=’None’
    • kubectl expose deployment hello-nginx –type=ClusterIP –name=my-nginx –port=8090 –target-port=80
  • DNS
    • wget https://kubernetes.io/examples/admin/dns/busybox.yaml
    • kubectl exec -it busybox — nsloopup kubernetes.default

  • 1.列出pod并排序
kubectl get pod --sort-by .metadata.name

题目一般都是按名字排序
  • 2.找出pod中的错误日志
kubectl logs heapster-798fcd9949-lk9rc | grep error > xx.txt

要求是把错误内容输出到某个文件中,可以粘贴,也可以直接重定向文件
  • 3.创建一个pod ,并调度到某个节点上
命令行创建pod的方法可以参考攻略的pdf,主要参数是--restart=Never,否则就会是deployment

kubectl run nginx-pod --image=nginx --port=80 --restart=Never --dry-run -o yaml > pod.yaml

先导出一份示例yaml出来,记得保存好这份yaml,后面也要用的

在yaml的spec属性中增加 nodeName: xxx

创建pod:kubectl create -f pod.yaml
  • 4.列出正常节点的个数
kubectl get node 

如何判断正常节点:一般都是not ready

get或者describe node排查node信息,把可用数写到一个文件中,文件里写一个数字就行了,不要多写空格换行之类的,谨记
  • 5.pod中挂载volume
  直接使用这个文档的示例就行,不用改啥东西
  文档地址:https://kubernetes.io/docs/concepts/storage/volumes/
  • 6.提供一个pod,添加init-container ,在container中添加一个空文件,启动的时候。在另一个containre中检测是否有这个文件,否则退出

文档地址:https://kubernetes.io/docs/co…

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: nginx-pod
  name: nginx-pod
spec:
  containers:
  - image: nginx
    name: nginx-pod
    command: ['sh','-c','if [ -f "a.txt" ]; then  echo xx ;fi']
    ports:
    - containerPort: 80
    resources: {}
    volumeMounts:
    - name: workdir
      mountPath: /usr/nginx/html
  dnsPolicy: ClusterFirst
  initContainers:
  - image: busybox
    name: initcheck
    command: ['sh','-c','touch /tmp/index.html']
    volumeMounts:
    - name: workdir
      mountPath: /tmp
  volumes:
  - name: workdir
    emptyDir: {}
  • 7.创建pod,再创建一个service
pod的模板使用前几题留下的yaml,改下就行了

   service的nodePort类型:https://kubernetes.io/docs/concepts/services-networking/service/
   
   注意:校验nodePort是否通,不要在中控机上校验,登录到node去校验
   
   也有可能让你建cluster-ip类型
   
  • 8.在一个pod中创建2个容器,如redis+nginx
apiVersion: v1
kind: Pod
metadata:
  name: demo
spec:
  containers:
  - image: nginx
    name: nginx
  - image: redis
    name: redis
  • 9.找到指定service下的pod中,cpu利用率按高到底排序按selector查找
kubectl get pod --selector="run=demo" | awk '{ print $1}' | grep -v NAME | 

或者找到pod后,一个一个看
kubectl top pod | grep -v NAME | sort -k 3
  • 10.创建一个简单的daemonset
文档地址:https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/

文档中给的yaml内容太多了,volume都可以删掉

daemonset创建好后会发现pod数小于节点数,可以看下节点是不是打了taint
  • 11.deployment的扩容 ,scale命令
kubectl scale --replicas=4 deployment demo
  • 12 创建secret,有一个paasword字段(手动base64加密),创建两个pod引用该secret,一个用env ,一个用volume来调用
这个文档里面全都有,记住链接

https://kubernetes.io/docs/concepts/configuration/secret/
  • 13.先将nginx:1.9的deployment,升级到nginx:1.11,记录下来(—record),然后回滚到1.9

升级

kubectl set image deployments demo demo=nginx:1.11 --record

回滚

kubectl rollout undo deployment demo
  • 14.使用ns lookup 查看service 和pod的dns
service和pod的创建用之前的yaml
查看dns

kubectl run -it --image busybox:1.28.4  dnstest --rm /bin/sh


sevice:

nslookup svc-demo.kube-system.svc.cluster.local


pod:

nslookup 1-2-3-4.default.pod.cluster.local


查看pod ip时,要把1.2.3.4换成1-2-3-4,否则会报错

对应的文档:https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/
  • 15.etcdctl 来 备份etcd
ETCDCTL_API=3 etcdctl --endpoints ....snapshot save  xxx 根据-h提示写就行了

先声明环境变量ETCDCTL_API=3 ,不然etcdctl 是v2版本

这个文档:

文档地址:https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/
  • 16.static pod的使用
文档地址:https://kubernetes.io/docs/tasks/administer-cluster/static-pod/


找到--pod-manifest-path=/etc/kubelet.d/配置的位置,然后把pod的yaml放进去

apiVersion: v1
kind: Pod
metadata:
  name: static-web
  labels:
    role: myrole
spec:
  containers:
    - name: web
      image: nginx
      ports:
        - name: web
          containerPort: 80
          protocol: TCP
  • 17.在一个新的namespace创建pod先创建ns,在创建pod,和前面步骤类似
  • 18.pv 类型hostpath 位置在/data , 大小为1G , readonly模式
文档地址:

https://kubernetes.io/docs/concepts/storage/persistent-volumes/
  • 20.给pod创建service
  • 21.使用node selector,选择disk为ssd的机器调度
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  nodeSelector:
    disktype: ssd

22.排查apiserver连接不上问题:

用的kubeadmin安装的,是kubelet的配置中目录地址有问题
  • 23.把一个node弄成unavailable 并且把上边的pod重新调度去新的node上应该是直接drain,需要注意daemonset要强制删除,或者给节点打污点,taint,再去删掉
  • 24.tls bootstrap加入节点(题目超长,时间一般都是不够用的。可以选择性放弃,这题8分

TLS bootstrapping

In a Kubernetes cluster, the components on the worker nodes – kubelet and kube-proxy – need to communicate with Kubernetes control plane components, specifically kube-apiserver. In order to ensure that communication is kept private, not interfered with, and ensure that each component of the cluster is talking to another trusted component, we strongly recommend using client TLS certificates on nodes.

The normal process of bootstrapping these components, especially worker nodes that need certificates so they can communicate safely with kube-apiserver, can be a challenging process as it is often outside of the scope of Kubernetes and requires significant additional work. This in turn, can make it challenging to initialize or scale a cluster.

In order to simplify the process, beginning in version 1.4, Kubernetes introduced a certificate request and signing API. The proposal can be found here.

This document describes the process of node initialization, how to set up TLS client certificate bootstrapping for kubelets, and how it works.

Initialization Process

When a worker node starts up, the kubelet does the following:

  1. Look for its kubeconfig file
  2. Retrieve the URL of the API server and credentials, normally a TLS key and signed certificate from the kubeconfig file
  3. Attempt to communicate with the API server using the credentials.

Assuming that the kube-apiserver successfully validates the kubelet’s credentials, it will treat the kubelet as a valid node, and begin to assign pods to it.

Note that the above process depends upon:

  • Existence of a key and certificate on the local host in the kubeconfig
  • The certificate having been signed by a Certificate Authority (CA) trusted by the kube-apiserver

All of the following are responsibilities of whoever sets up and manages the cluster:

  1. Creating the CA key and certificate
  2. Distributing the CA certificate to the control plane nodes, where kube-apiserver is running
  3. Creating a key and certificate for each kubelet; strongly recommended to have a unique one, with a unique CN, for each kubelet
  4. Signing the kubelet certificate using the CA key
  5. Distributing the kubelet key and signed certificate to the specific node on which the kubelet is running

The TLS Bootstrapping described in this document is intended to simplify, and partially or even completely automate, steps 3 onwards, as these are the most common when initializing or scaling a cluster.

Bootstrap Initialization

In the bootstrap initialization process, the following occurs:

  1. kubelet begins
  2. kubelet sees that it does not have a kubeconfig file
  3. kubelet searches for and finds a bootstrap-kubeconfig file
  4. kubelet reads its bootstrap file, retrieving the URL of the API server and a limited usage “token”
  5. kubelet connects to the API server, authenticates using the token
  6. kubelet now has limited credentials to create and retrieve a certificate signing request (CSR)
  7. kubelet creates a CSR for itself with the signerName set to kubernetes.io/kube-apiserver-client-kubelet
  8. CSR is approved in one of two ways:
  • If configured, kube-controller-manager automatically approves the CSR
  • If configured, an outside process, possibly a person, approves the CSR using the Kubernetes API or via kubectl
  1. Certificate is created for the kubelet
  2. Certificate is issued to the kubelet
  3. kubelet retrieves the certificate
  4. kubelet creates a proper kubeconfig with the key and signed certificate
  5. kubelet begins normal operation
  6. Optional: if configured, kubelet automatically requests renewal of the certificate when it is close to expiry
  7. The renewed certificate is approved and issued, either automatically or manually, depending on configuration.

The rest of this document describes the necessary steps to configure TLS Bootstrapping, and its limitations.

Configuration

To configure for TLS bootstrapping and optional automatic approval, you must configure options on the following components:

  • kube-apiserver
  • kube-controller-manager
  • kubelet
  • in-cluster resources: ClusterRoleBinding and potentially ClusterRole

In addition, you need your Kubernetes Certificate Authority (CA).

Certificate Authority

As without bootstrapping, you will need a Certificate Authority (CA) key and certificate. As without bootstrapping, these will be used to sign the kubelet certificate. As before, it is your responsibility to distribute them to control plane nodes.

For the purposes of this document, we will assume these have been distributed to control plane nodes at /var/lib/kubernetes/ca.pem (certificate) and /var/lib/kubernetes/ca-key.pem (key). We will refer to these as “Kubernetes CA certificate and key”.

All Kubernetes components that use these certificates – kubelet, kube-apiserver, kube-controller-manager – assume the key and certificate to be PEM-encoded.

kube-apiserver configuration

The kube-apiserver has several requirements to enable TLS bootstrapping:

  • Recognizing CA that signs the client certificate
  • Authenticating the bootstrapping kubelet to the system:bootstrappers group
  • Authorize the bootstrapping kubelet to create a certificate signing request (CSR)

Recognizing client certificates

This is normal for all client certificate authentication. If not already set, add the --client-ca-file=FILENAME flag to the kube-apiserver command to enable client certificate authentication, referencing a certificate authority bundle containing the signing certificate, for example --client-ca-file=/var/lib/kubernetes/ca.pem.

Initial bootstrap authentication

In order for the bootstrapping kubelet to connect to kube-apiserver and request a certificate, it must first authenticate to the server. You can use any authenticator that can authenticate the kubelet.

While any authentication strategy can be used for the kubelet’s initial bootstrap credentials, the following two authenticators are recommended for ease of provisioning.

  1. Bootstrap Tokens
  2. Token authentication file

Bootstrap tokens are a simpler and more easily managed method to authenticate kubelets, and do not require any additional flags when starting kube-apiserver. Using bootstrap tokens is currently beta as of Kubernetes version 1.12.

Whichever method you choose, the requirement is that the kubelet be able to authenticate as a user with the rights to:

  1. create and retrieve CSRs
  2. be automatically approved to request node client certificates, if automatic approval is enabled.

A kubelet authenticating using bootstrap tokens is authenticated as a user in the group system:bootstrappers, which is the standard method to use.

As this feature matures, you should ensure tokens are bound to a Role Based Access Control (RBAC) policy which limits requests (using the bootstrap token) strictly to client requests related to certificate provisioning. With RBAC in place, scoping the tokens to a group allows for great flexibility. For example, you could disable a particular bootstrap group’s access when you are done provisioning the nodes.

Bootstrap tokens

Bootstrap tokens are described in detail here. These are tokens that are stored as secrets in the Kubernetes cluster, and then issued to the individual kubelet. You can use a single token for an entire cluster, or issue one per worker node.

The process is two-fold:

  1. Create a Kubernetes secret with the token ID, secret and scope(s).
  2. Issue the token to the kubelet

From the kubelet’s perspective, one token is like another and has no special meaning. From the kube-apiserver’s perspective, however, the bootstrap token is special. Due to its type, namespace and name, kube-apiserver recognizes it as a special token, and grants anyone authenticating with that token special bootstrap rights, notably treating them as a member of the system:bootstrappers group. This fulfills a basic requirement for TLS bootstrapping.

The details for creating the secret are available here.

If you want to use bootstrap tokens, you must enable it on kube-apiserver with the flag:

--enable-bootstrap-token-auth=true

Token authentication file

kube-apiserver has the ability to accept tokens as authentication. These tokens are arbitrary but should represent at least 128 bits of entropy derived from a secure random number generator (such as /dev/urandom on most modern Linux systems). There are multiple ways you can generate a token. For example:

head -c 16 /dev/urandom | od -An -t x | tr -d ' '

will generate tokens that look like 02b50b05283e98dd0fd71db496ef01e8.

The token file should look like the following example, where the first three values can be anything and the quoted group name should be as depicted:

02b50b05283e98dd0fd71db496ef01e8,kubelet-bootstrap,10001,"system:bootstrappers"

Add the --token-auth-file=FILENAME flag to the kube-apiserver command (in your systemd unit file perhaps) to enable the token file. See docs here for further details.

Authorize kubelet to create CSR

Now that the bootstrapping node is authenticated as part of the system:bootstrappers group, it needs to be authorized to create a certificate signing request (CSR) as well as retrieve it when done. Fortunately, Kubernetes ships with a ClusterRole with precisely these (and only these) permissions, system:node-bootstrapper.

To do this, you only need to create a ClusterRoleBinding that binds the system:bootstrappers group to the cluster role system:node-bootstrapper.

# enable bootstrapping nodes to create CSR
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: create-csrs-for-bootstrapping
subjects:
- kind: Group
  name: system:bootstrappers
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: system:node-bootstrapper
  apiGroup: rbac.authorization.k8s.io

kube-controller-manager configuration

While the apiserver receives the requests for certificates from the kubelet and authenticates those requests, the controller-manager is responsible for issuing actual signed certificates.

The controller-manager performs this function via a certificate-issuing control loop. This takes the form of a cfssl local signer using assets on disk. Currently, all certificates issued have one year validity and a default set of key usages.

In order for the controller-manager to sign certificates, it needs the following:

  • access to the “Kubernetes CA key and certificate” that you created and distributed
  • enabling CSR signing

Access to key and certificate

As described earlier, you need to create a Kubernetes CA key and certificate, and distribute it to the control plane nodes. These will be used by the controller-manager to sign the kubelet certificates.

Since these signed certificates will, in turn, be used by the kubelet to authenticate as a regular kubelet to kube-apiserver, it is important that the CA provided to the controller-manager at this stage also be trusted by kube-apiserver for authentication. This is provided to kube-apiserver with the flag --client-ca-file=FILENAME (for example, --client-ca-file=/var/lib/kubernetes/ca.pem), as described in the kube-apiserver configuration section.

To provide the Kubernetes CA key and certificate to kube-controller-manager, use the following flags:

--cluster-signing-cert-file="/etc/path/to/kubernetes/ca/ca.crt" --cluster-signing-key-file="/etc/path/to/kubernetes/ca/ca.key"

for example:

--cluster-signing-cert-file="/var/lib/kubernetes/ca.pem" --cluster-signing-key-file="/var/lib/kubernetes/ca-key.pem"

The validity duration of signed certificates can be configured with flag:

--cluster-signing-duration

Approval

In order to approve CSRs, you need to tell the controller-manager that it is acceptable to approve them. This is done by granting RBAC permissions to the correct group.

There are two distinct sets of permissions:

  • nodeclient: If a node is creating a new certificate for a node, then it does not have a certificate yet. It is authenticating using one of the tokens listed above, and thus is part of the group system:bootstrappers.
  • selfnodeclient: If a node is renewing its certificate, then it already has a certificate (by definition), which it uses continuously to authenticate as part of the group system:nodes.

To enable the kubelet to request and receive a new certificate, create a ClusterRoleBinding that binds the group in which the bootstrapping node is a member system:bootstrappers to the ClusterRole that grants it permission, system:certificates.k8s.io:certificatesigningrequests:nodeclient:

# Approve all CSRs for the group "system:bootstrappers"
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: auto-approve-csrs-for-group
subjects:
- kind: Group
  name: system:bootstrappers
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: system:certificates.k8s.io:certificatesigningrequests:nodeclient
  apiGroup: rbac.authorization.k8s.io

To enable the kubelet to renew its own client certificate, create a ClusterRoleBinding that binds the group in which the fully functioning node is a member system:nodes to the ClusterRole that grants it permission, system:certificates.k8s.io:certificatesigningrequests:selfnodeclient:

# Approve renewal CSRs for the group "system:nodes"
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: auto-approve-renewals-for-nodes
subjects:
- kind: Group
  name: system:nodes
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: system:certificates.k8s.io:certificatesigningrequests:selfnodeclient
  apiGroup: rbac.authorization.k8s.io

The csrapproving controller that ships as part of kube-controller-manager and is enabled by default. The controller uses the SubjectAccessReview API to determine if a given user is authorized to request a CSR, then approves based on the authorization outcome. To prevent conflicts with other approvers, the builtin approver doesn’t explicitly deny CSRs. It only ignores unauthorized requests. The controller also prunes expired certificates as part of garbage collection.

kubelet configuration

Finally, with the control plane nodes properly set up and all of the necessary authentication and authorization in place, we can configure the kubelet.

The kubelet requires the following configuration to bootstrap:

  • A path to store the key and certificate it generates (optional, can use default)
  • A path to a kubeconfig file that does not yet exist; it will place the bootstrapped config file here
  • A path to a bootstrap kubeconfig file to provide the URL for the server and bootstrap credentials, e.g. a bootstrap token
  • Optional: instructions to rotate certificates

The bootstrap kubeconfig should be in a path available to the kubelet, for example /var/lib/kubelet/bootstrap-kubeconfig.

Its format is identical to a normal kubeconfig file. A sample file might look as follows:

apiVersion: v1
kind: Config
clusters:
- cluster:
    certificate-authority: /var/lib/kubernetes/ca.pem
    server: https://my.server.example.com:6443
  name: bootstrap
contexts:
- context:
    cluster: bootstrap
    user: kubelet-bootstrap
  name: bootstrap
current-context: bootstrap
preferences: {}
users:
- name: kubelet-bootstrap
  user:
    token: 07401b.f395accd246ae52d

The important elements to note are:

  • certificate-authority: path to a CA file, used to validate the server certificate presented by kube-apiserver
  • server: URL to kube-apiserver
  • token: the token to use

The format of the token does not matter, as long as it matches what kube-apiserver expects. In the above example, we used a bootstrap token. As stated earlier, any valid authentication method can be used, not only tokens.

Because the bootstrap kubeconfig is a standard kubeconfig, you can use kubectl to generate it. To create the above example file:

kubectl config --kubeconfig=/var/lib/kubelet/bootstrap-kubeconfig set-cluster bootstrap --server='https://my.server.example.com:6443' --certificate-authority=/var/lib/kubernetes/ca.pem
kubectl config --kubeconfig=/var/lib/kubelet/bootstrap-kubeconfig set-credentials kubelet-bootstrap --token=07401b.f395accd246ae52d
kubectl config --kubeconfig=/var/lib/kubelet/bootstrap-kubeconfig set-context bootstrap --user=kubelet-bootstrap --cluster=bootstrap
kubectl config --kubeconfig=/var/lib/kubelet/bootstrap-kubeconfig use-context bootstrap

To indicate to the kubelet to use the bootstrap kubeconfig, use the following kubelet flag:

--bootstrap-kubeconfig="/var/lib/kubelet/bootstrap-kubeconfig" --kubeconfig="/var/lib/kubelet/kubeconfig"

When starting the kubelet, if the file specified via --kubeconfig does not exist, the bootstrap kubeconfig specified via --bootstrap-kubeconfig is used to request a client certificate from the API server. On approval of the certificate request and receipt back by the kubelet, a kubeconfig file referencing the generated key and obtained certificate is written to the path specified by --kubeconfig. The certificate and key file will be placed in the directory specified by --cert-dir.

Client and Serving Certificates

All of the above relate to kubelet client certificates, specifically, the certificates a kubelet uses to authenticate to kube-apiserver.

A kubelet also can use serving certificates. The kubelet itself exposes an https endpoint for certain features. To secure these, the kubelet can do one of:

  • use provided key and certificate, via the --tls-private-key-file and --tls-cert-file flags
  • create self-signed key and certificate, if a key and certificate are not provided
  • request serving certificates from the cluster server, via the CSR API

The client certificate provided by TLS bootstrapping is signed, by default, for client auth only, and thus cannot be used as serving certificates, or server auth.

However, you can enable its server certificate, at least partially, via certificate rotation.

Certificate Rotation

Kubernetes v1.8 and higher kubelet implements beta features for enabling rotation of its client and/or serving certificates. These can be enabled through the respective RotateKubeletClientCertificate and RotateKubeletServerCertificate feature flags on the kubelet and are enabled by default.

RotateKubeletClientCertificate causes the kubelet to rotate its client certificates by creating new CSRs as its existing credentials expire. To enable this feature pass the following flag to the kubelet:

--rotate-certificates

RotateKubeletServerCertificate causes the kubelet both to request a serving certificate after bootstrapping its client credentials and to rotate that certificate. To enable this feature pass the following flag to the kubelet:

--rotate-server-certificates

Note:

The CSR approving controllers implemented in core Kubernetes do not approve node serving certificates for security reasons. To use RotateKubeletServerCertificate operators need to run a custom approving controller, or manually approve the serving certificate requests.

A deployment-specific approval process for kubelet serving certificates should typically only approve CSRs which:

  1. are requested by nodes (ensure the spec.username field is of the form system:node:<nodeName> and spec.groups contains system:nodes)
  2. request usages for a serving certificate (ensure spec.usages contains server auth, optionally contains digital signature and key encipherment, and contains no other usages)
  3. only have IP and DNS subjectAltNames that belong to the requesting node, and have no URI and Email subjectAltNames (parse the x509 Certificate Signing Request in spec.request to verify subjectAltNames)

Other authenticating components

All of TLS bootstrapping described in this document relates to the kubelet. However, other components may need to communicate directly with kube-apiserver. Notable is kube-proxy, which is part of the Kubernetes control plane and runs on every node, but may also include other components such as monitoring or networking.

Like the kubelet, these other components also require a method of authenticating to kube-apiserver. You have several options for generating these credentials:

  • The old way: Create and distribute certificates the same way you did for kubelet before TLS bootstrapping
  • DaemonSet: Since the kubelet itself is loaded on each node, and is sufficient to start base services, you can run kube-proxy and other node-specific services not as a standalone process, but rather as a daemonset in the kube-system namespace. Since it will be in-cluster, you can give it a proper service account with appropriate permissions to perform its activities. This may be the simplest way to configure such services.

kubectl approval

CSRs can be approved outside of the approval flows builtin to the controller manager.

The signing controller does not immediately sign all certificate requests. Instead, it waits until they have been flagged with an “Approved” status by an appropriately-privileged user. This flow is intended to allow for automated approval handled by an external approval controller or the approval controller implemented in the core controller-manager. However cluster administrators can also manually approve certificate requests using kubectl. An administrator can list CSRs with kubectl get csr and describe one in detail with kubectl describe csr <name>. An administrator can approve or deny a CSR with kubectl certificate approve <name> and kubectl certificate deny <name>.

Leave a Reply

Your email address will not be published. Required fields are marked *