文章目录

  • Certificated Kubernetes Administrator
  • 模块一:Kubernetes核心概念 19%
  • 模块二:Kubernetes集群搭建、配置和验证 12%
  • 模块三:Kubernetes监控与日志管理 5%
  • 模块四:Kubernetes中应用程序生命周期管理 8%
  • 模块五:Kubernetes调度 5%
  • 模块六:Kubernetes网格 11%
  • 模块七:Kubernetes存储 7%
  • 模块八:Kubernetes安全 12%
  • 模块九:Kubernetes集群维护 11%
  • 模块十:Kubernetes故障排除 10%
  • 使用kubectl与集群交互
  • 题海
  • pod的增删改查
  • controler的增删改查
  • svc / ing的增删改查
  • pv/pvc的增删改查
  • rbac的增删改查
  • 集群的增删改查
  • troubleshooting

Certificated Kubernetes Administrator

声明:本文主要参考华为培训

  • 最全面的知识来自官网
  • 面向Kubernetes管理员的认证
  • 考核运维K8s集群所需的知识、技能,最重要是熟练度

模块一:Kubernetes核心概念 19%

  • 有了Docker,为什么还需要K8s:集群中多个容器怎么通信?多个相同的容器怎么一起提供服务?
  • K8s是什么:开源的容器集群编排框架
  • K8s集群架构与组件:CS架构 MASTER(apiserver/schedule/manager/etcd)+NODE(kubelet/kubeproxy)
  • fink 和spark 和ck 的对比 ck和fion_fink 和spark 和ck 的对比

  • fink 和spark 和ck 的对比 ck和fion_fink 和spark 和ck 的对比_02

  • K8s核心概念:
Pod:
  一组功能相关的Container的封装
  共享存储和Network Namespace
  K8s调度和作业运行的基本单位(Scheduler调度/Kubelet运行)
  容易“走失”,需要Workload和Service的“呵护”
Workloads(Deployment/StatefulSet/DaemonSet/Job...):
  一组功能相关的Pod的封装
Service:
  Pod "防失联"
  给一组pod设置反向代理
  • 熟悉官方文档

模块二:Kubernetes集群搭建、配置和验证 12%

  • 使用kubeadm快速部署一个K8s集群
  • K8s CNI 网络方案选择:Flannel Calico
  • 部署Web UI
  • 在搭建K8s集群过程中常见问题解析
  • kubectl 工具常用命令及使用技巧
  • kubectl 工具连接多集群(多集群环境切换)

模块三:Kubernetes监控与日志管理 5%

fink 和spark 和ck 的对比 ck和fion_nginx_03

  • 查看集群资源状况5个命令及使用技巧
  • Metrics Server 监控数据聚合器部署
  • 监控集群资源利用率
  • 管理K8s组件日志
  • fink 和spark 和ck 的对比 ck和fion_nginx_04

  • 管理K8s应用程序日志
  • fink 和spark 和ck 的对比 ck和fion_Pod_05

  • 容器日志输出形式及收集技巧

模块四:Kubernetes中应用程序生命周期管理 8%

  • 在K8s中部署应用的流程
  • Deployment控制器概述
  • 使用Deployment部署应用
  • 服务编排及编写技巧
  • 应用升级、弹性伸缩、回滚、删除
  • fink 和spark 和ck 的对比 ck和fion_增删改查_06

  • fink 和spark 和ck 的对比 ck和fion_增删改查_07

  • Pod对象:基本概念、存在意义、设计思想、应用自修复、容器分类、Init Container应用场景与使用、静态Pod

模块五:Kubernetes调度 5%

fink 和spark 和ck 的对比 ck和fion_Pod_08

  • 创建一个Pod的工作流程
  • fink 和spark 和ck 的对比 ck和fion_fink 和spark 和ck 的对比_09

  • Pod中影响调度的主要属性
  • 资源限制对Pod的影响
  • fink 和spark 和ck 的对比 ck和fion_fink 和spark 和ck 的对比_10

  • 在这里插入图片描述
  • nodeSelector & nodeAffinity
  • fink 和spark 和ck 的对比 ck和fion_nginx_11

    fink 和spark 和ck 的对比 ck和fion_nginx_12

  • fink 和spark 和ck 的对比 ck和fion_fink 和spark 和ck 的对比_13

  • fink 和spark 和ck 的对比 ck和fion_增删改查_14

  • fink 和spark 和ck 的对比 ck和fion_Pod_15

  • Taints & Tolerations
  • fink 和spark 和ck 的对比 ck和fion_nginx_16

  • fink 和spark 和ck 的对比 ck和fion_fink 和spark 和ck 的对比_17

  • nodeName
  • DaemonSet控制器
  • fink 和spark 和ck 的对比 ck和fion_Pod_18

  • 调度失败原因分析

模块六:Kubernetes网格 11%

fink 和spark 和ck 的对比 ck和fion_Pod_19

fink 和spark 和ck 的对比 ck和fion_fink 和spark 和ck 的对比_20

fink 和spark 和ck 的对比 ck和fion_增删改查_21

  • Service 存在的意义
  • fink 和spark 和ck 的对比 ck和fion_Pod_22

  • Service 三种类型
  • Service 代理模式Iptables与IPVS
  • Iptables 和 IPVS选择及优缺点
  • Service DNS 名称访问: CoreDNS
  • fink 和spark 和ck 的对比 ck和fion_Pod_23

  • Ingress 介绍
  • 部署 Ingress Controller
  • 使用 Ingress 发布HTTP/HTTPS网站

模块七:Kubernetes存储 7%

  • 为什么需要存储卷?
  • fink 和spark 和ck 的对比 ck和fion_Pod_24

  • 数据卷概述
  • 临时存储卷、节点存储卷、网络存储卷
  • fink 和spark 和ck 的对比 ck和fion_Pod_25

  • 持久卷概述 - PV/PVC
  • fink 和spark 和ck 的对比 ck和fion_nginx_26

  • PV 生命周期
  • PV 静态供给
  • fink 和spark 和ck 的对比 ck和fion_增删改查_27

  • PV 动态供给 - StorageClass
  • fink 和spark 和ck 的对比 ck和fion_fink 和spark 和ck 的对比_28

  • 应用程序使用持久卷存储数据
  • fink 和spark 和ck 的对比 ck和fion_fink 和spark 和ck 的对比_29

  • fink 和spark 和ck 的对比 ck和fion_nginx_30

  • 有状态应用部署: Statefulset控制器
  • 应用程序配置文件存储: ConfigMap
  • 敏感数据存储: Secret

模块八:Kubernetes安全 12%

  • K8s 安全框架
  • 基于角色的权限访问控制:RBAC
  • 为指定用户授权访问不同命名空间权限
  • 为什么需要网络隔离
  • 网络策略概述
  • 对项目Pod出入流量访问控制

模块九:Kubernetes集群维护 11%

fink 和spark 和ck 的对比 ck和fion_增删改查_31

  • kubeadm的管理方式
  • fink 和spark 和ck 的对比 ck和fion_增删改查_32

  • fink 和spark 和ck 的对比 ck和fion_Pod_33

  • fink 和spark 和ck 的对比 ck和fion_Pod_34

  • Bootstrap Token方式增加Node
  • fink 和spark 和ck 的对比 ck和fion_增删改查_35

  • K8s 集群证书续签
  • K8s 数据库 Etcd 备份和恢复

模块十:Kubernetes故障排除 10%

fink 和spark 和ck 的对比 ck和fion_增删改查_36

  • 应用程序故障排查
  • fink 和spark 和ck 的对比 ck和fion_增删改查_37

  • 管理节点异常原因排查
  • fink 和spark 和ck 的对比 ck和fion_fink 和spark 和ck 的对比_38

  • 工作节点异常原因排查
  • fink 和spark 和ck 的对比 ck和fion_增删改查_39

  • Service 访问异常排查

使用kubectl与集群交互

  • Basic Commands (Beginner):
create  从文件或stdin创建资源
  expose  为deployment,pod创建Service
  run     Run a particular image on the cluster
  set     Set specific features on objects
  • (Intermediate):
get     最基本的查询命令 eg:kubectl get rs/deploy/svc/...
  explain 查看资源定义 eg:kubectl explain replicaset
  edit    使用系统编辑器编辑资源 eg:kubectl edit deploy/foo
  delete  删除指定资源,支持文件名、资源名、label selector eg:kubectl delete po -l foo=bar
  • Deploy Commands:
rollout         Deployment、Daemonset的升级过程管理(查看状态、操作历史、暂停升级、恢复升级、回滚等)
  rolling-update  滚动升级,仅限ReplicationController
  scale           修改Deployment、ReplicaSet、ReplicationController、Job的实例数
  autoscale       为Deply、RS、RC配置自动伸缩规则(依赖hpa)
  • Cluster Management Commands:
certificate   Modify certificate resources
  cluster-info  查看集群信息
  top           查看资源占用率
  cordon        标记节点为unschedulable
  uncordon      标记节点为schedulable
  drain         驱逐节点上的应用,下线维护
  taint         修改节点taint标记
  • Troubleshooting and Debugging Commands:
describe     查看资源详情
  logs         查看pod内容器的日志
  attach       Attach到pod内的一个容器
  exec         在指定容器内执行命令
  port-forward 为pod创建本地端口映射
  proxy        为Kubernetes API server创建代理
  cp           容器内外/容器间文件拷贝
  • Advanced Commands:
apply        从文件或stdin创建/更新资源
  patch        使用strategic merge patch语法更新对象的某些字段
  replace      从文件或stdin更新资源
  convert      在不同API版本之间转换对象定义
  • Settings Commands:
label        给资源设置label
  annotate     给资源设置annotation
  completion   获取shell自动补全脚本-bash/zsh
  • Other Commands:
api-versions Print the supported API version on the server, in the form of "group/version"
  config       修改kubectl配置-kubeconfig, eg: context
  help         Help about any command
  version      查看客户端和Server端K8s版本

题海

pod的增删改查

  • 创建pod并挂载secret/configmap/volume

Name: super-secret Credential: alice or username:bob Create a Pod named pod-secrets-via-file using the redis image which mounts a secret named super-secret at /secrets Create a second Pod named pod-secrets-via-env using the redis image, which exports credential as TOPSECRET #echo -n ‘bob’ | base64

Name: non-persistent-redis Container image: redis Named-volume with name: cache-control Mount path: /data/redis It should launch in the pre-prod namespace and the volume MUST NOT be persistent.

  • 创建多容器的 pod

Create a pod named kucc1 with a single app container for each of the following images running inside (there may be between 1 and 4 images specified): nginx + redis #kubectl run kucc1 --image=nginx --dry-run=client -o yaml #复制几行,加个container

  • 调度 pod 到指定节点

Schedule a pod as follows: Name:nginx-kusc00401; Image:nginx; Node selector: disk=sdd

  • 添加 sidecar 容器并输出日志

Add a sidecar container named sidecar, using the busybox image, to the existing Pod 11-factor-app. The new sidecar container has to run the following command: /bin/sh -c tail -n+1 -f /var/log/11-factor-app.log Monitor the logs of pod foobar and Extract log lines corresponding to error ‘unable-to-access-wevsite’. Write them to /opt/KUTR00101/foobar 切换 context kubectl logs foobar | grep unable-to-access-website > /opt/KUTR00101/foobar

  • initContainer

Set configuration context Perform the following tasks Add an init container to lumpy-koala(which has been defined in spec file /opt/kucc00100/pod-sepc-KUCC00100.yaml) The init container should create an empty file named /workdir/calm.txt if /workdir/calm.txt is note be detected, the Pod should exit. Once the spec file has been updated the init container definion, the Pod should be created

  • 配置网络策略 NetworkPolicy

Create a new NetworkPolicy allow-port-from-namespace in the existing namespace fubar. Ensure that the new NetworkPolicy allows Pods in namespace my-app to connect to port 80 of Pods in namespace fubar. Further ensures that the new NetworkPolicy: does not allow access to Pods, which don’t listen on port 80; does not allow acess from Pods, which are not in namespace my-app. 注意:需要 查看my-app的labels,然后在 namespaceSelector 中添加对应的labels

  • 查看CPU使用率最高的pod

From the pod label name=cpu-loader, find pods running high CPU workloads and write the name of the pod consuming most CPU to the file /opt/KUTR00401/KUTR00401.txt #kubectl top pod -l name=cpu-utilizer --all-namespaces --sort-by=cpu > /opt/cpu.txt

  • 根据label查看pod

Create a file /opt/KUCC00302/kucc00302.txt that lists all pods that implement Service foo in Namespace production. The format of the file should be one pod name per line. #kubectl -n production describe svc foo #kubectl -n production get po -l run=foo | awk ‘{print $1}’ | grep -v NAME > /opt/KUCC00302/kucc00302.txt

controler的增删改查

  • 扩容 deployment

Scale the deployment guestbook to 6 pods

  • 滚动升级

Name: nginx-app; Using container nginx with version 1.10.2-alpine; The deployment should contain 3 replicas Next, deploy the app with new version 1.13.0-alpine by performing a rolling update and record that update. Finally, rollback that update to the previous version 1.10.2-alpine #kubectl create deployment nginx-app --image=nginx:1.10.2-alpine kubectl set image deployment/nginx-app nginx=nginx:1.13.0-alpine --record kubectl rollout status deployment/nginx-app kubectl rollout history deployment.v1.apps/nginx-app kubectl rollout undo deployment nginx-app

  • 创建daemonset

Ensure a single instance of Pod nginx is running on each node of the kubernetes cluster where nginx also represents the image name which has to be used. Do no override any taints currently in place. Use Daemonsets to complete this task and use ds.kusc00201 as Daemonset name. #思路都是一样的,利用–dry-run 和 -o yaml 导出后,进一步修改 第一步,kubectl create deployment ds.kusc00201 --image=nginx -o yaml --dry-run=client

svc / ing的增删改查

  • 创建 Ingress 资源

Create a new nginx Ingress resource as follows: Name:ping; NameSpace:ing-internal;Exposing service hello on path /hello using service port 5678

  • 创建 service

Reconfigure the existing deployment front-end and add a port specification named http exposing port 80/tcp of the existing container nginx. Create a nw service named front-end-svc exposing the container port http. Configure the new service to also expose the individual pods via a NodePort on the nodes on which they are shceduled. kubectl expose deployment front-end --type=NodePort --port=80 --traget-port=80 --name=front-end-svc

Name: nginx-dns Exposed via a service: nginx-dns Ensure that the service & pod are accessible via their respective DNS records The container(s) within any Pod(s) running as a part of this deployment should use the nginx image Next, use the utility nslookup to look up the DNS records of the service & pod and write the output to /opt/service.dns and /opt/pod.dns respectively. Ensure you use the busybox:1.28 image(or earlier) for any testing, an the latest release has an unpstream bug which impacts thd use of nslookup. #kubectl create deployment nginx-dns --image=nginx #kubectl expose deployment nginx-dns --target-port=80 --port=80 #kubectl run test --image=busybox:1.28 --command – sleep 3600000 #kubectl exec -it test-7785f75955-j6rsp – nslookup 10.96.24.23 > /opt/service.dns #kubectl exec -it test-7785f75955-j6rsp – nslookup 192.168.196.168 > /opt/pod.dns 或者 #kubectl create deployment nginx-dnss --image=registry.local/nginx -o yaml --dry-run > nginx-dns.yml #kubectl expose deployment nginx-dns --target-port=80 --port=80 --dry-run -o yaml > nginx-svc.yml

pv/pvc的增删改查

  • 创建 PV

Create a persistent volume with name app-config, of capacity 2Gi and access mode ReadWriteMany. The type of volume is hostPath and its location is /srv/app-config.

  • 创建和使用 PVC

Create a new PersistentVolumeClaim: Name: pv-volume; Class: csi-hostpath-sc; Capacity: 10Mi Create a new Pod which mounts the PersistentVolumeClain as a volume: Name: web-server; Image: nginx; Mount path: /usr/share/ngin/html Configure the new Pod to have ReadWriteOnce access on the volume. Finally, using kubectl edit or kubectl patch expand the PersistentVolumeClaim to a capacity of 70Mi and record that change

  • 根据label/排序

List all PVs sorted by name saving the full kubectl output to /opt/KUCC0010/my_volumes . Use kubectl’s own functionally for sorting the output, and do not manipulate it any further. #kubectl get pv --sort-by=.metadata.name > /opt/KUCC0010/my_volumes

rbac的增删改查

  • 权限控制RBAC

Create a new ClusterRole named deployment-clusterrole, which only allows to create the following resource types: Deployment StatefulSet DaemonSet Create a new ServiceAccount named cicd-token in the existing namespace app-team1. Bind the new ClusterRole deployment-clusterrole to the new ServiceAccount cicd-token, limited to the namespace app-team1. 切换 context kubectl create ns app-team1 kubectl create serviceaccount cicd-token -n app-team1 kubectl create clusterrole deployment-clusterrole --verb=create --resource=deployment,statefulset,daemonset kubectl create rolebinding cicd-clusterrole --clusterrole=deployment-clusterrole --serviceaccount=app-team1

集群的增删改查

  • 统计 ready 状态节点数量

Check to see how many nodes are ready (not including nodes tainted NoSchedule) and write the number to /opt/KUSC00402/KUSC00402.txt

  • 备份还原 etcd

First,create a snapshot of the existing etcd instance running at https:127.0.0.1:2379, saving the snapshot to /var/lib/backup/etcd-snampshot.db Next, restore an existing previous snapshot located at /data/bancup/etcd-snampshot-previous.db 备份: ETCDCTL_API=3 etcdctl --endpoints https://172.0.0.1:2379 --cacert=/opt/xxx/ca.crt --cert=/opt/xxx/etcd-client.crt --key=/opt/xxx/etcd-client.key snapshot save /var/lib/backup/etcd-snapshot.db 还原: ETCDCTL_API=3 etcdctl --endpoints https://172.0.0.1:2379 --cacert=/opt/xxx/ca.crt --cert=/opt/xxx/etcd-client.crt --key=/opt/xxx/etcd-client.key snapshot restore /var/lib/backup/etcd-snapshot-previous.db

  • 升级 kubeadm

Given an exiting Kubernetes cluster running version 1.20.0, upgrade all of the kubernetes control plane and node components on the master node only to version 1.20.1. Be sure to drain the master node before upgrading it and uncordon it after the ungrade. You are also expected to upgrade kubectl and kublet on the master node

  • 设置节点不可用

Set the node named ek8s-node-1 as unavailable and reschedule all the pods running on it 切换context kubectl cordon ek8s-node-1 kubectl drain ek8s-node-1 --ingnore-daemonsets --delete-local-data --force

  • kueblet管理pod配置,而systemd管理kubelet

Configure the kubelet systemd managed service, on the node labelled with name=wk8s-node-1, to launch a Pod containing a single container of image nginx named myservice automatically. Any spec files required should be placed in the /etc/kubernetes/manifests directory on the node. Hints: You can ssh to the failed node using $ ssh wk8s-node-1 You can assume elevated privileges on the node with the following command $ sudo -i

troubleshooting

  • 排查集群中故障节点

A Kubernetes worker node, named wk8s-node-0 is in state NoteReady. Investigate why this is the case, and perform any appropriate steps to bring the node to a Ready state, ensuring tha any changes are made permanent. #ssh wk8s-node-0 systemctl restart kubelet.service systemctl enable kubelet.service

Extract log lines corresponding to error file-not-found Write them to /opt/KULM00201/foobar