cka从入门到放弃
无数次想放弃，最后选择了坚持
监控pod日志
监控名为 foobar 的 Pod 的日志，并过滤出具有 unable-access-website 信息的行，然后将
写入到 /opt/KUTR00101/foobar
# 解析
监控pod的日志，使用kubectl logs pod-name
kubectl logs foobar | grep unable-access-website > /opt/KUTR00101/foobar
监控pod度量指标
找出具有 name=cpu-user 的 Pod，并过滤出使用 CPU 最高的 Pod，然后把它的名字写在已
经存在的/opt/KUTR00401/KUTR00401.txt 文件里（注意他没有说指定 namespace。所以需要使
用-A 指定所以 namespace）
# 解析
过滤cpu最高，使用top命令
kubectl top pod -A -l name=cpu-user
echo x >> /opt/KUTR00401/KUTR00401.txt
deployment扩缩容
扩容名字为 loadbalancer 的 deployment 的副本数为 6
# 解析
kubectl scale --replicas=6 deployment loadbancer
检查Node节点的健康状态
检查集群中有多少节点为 Ready 状态，并且去除包含 NoSchedule 污点的节点。之后将数字
写到/opt/KUSC00402/kusc00402.txt
# 解析
查看节点ready状态，只需要get直接查就行
而要查调度，就要使用describe来查
kubectl get node | grep -i Ready
kubectl describe node | grep Taint | grep NoSchedule
echo x > /opt/KUSC00402/kusc00402.txt
节点维护
将 ek8s-node-1 节点设置为不可用，然后重新调度该节点上的所有 Pod
设置不可用，就是将节点设置不可调度，使用cordon
kubectl cordon ek8s-node-1
重新调度
指定节点部署
创建一个 Pod，名字为 nginx-kusc00401，镜像地址是 nginx，调度到具有 disk=spinning 标
签 的 节 点 上
# 解析
vim pod-ns.yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx-kusc00401
labels:
role: nginx-kusc00401
spec:
nodeSelector:
disk: spinning
containers:
- name: nginx
image: nginx
一个pod多个容器
创建一个 Pod ， 名 字 为 kucc1 ，这个 Pod 可能包含 1-4 容 器 ， 该 题 为 四 个 ：
nginx+redis+memcached+consul
apiVersion: v1
kind: Pod
metadata:
name: kucc1
spec:
containers:
- image: nginx
name: nginx
- image: redis
name: redis
- image: memcached
name: memcached
- image: consul
name: consul
Service
重新配置一个已经存在的 deployment front-end，在名字为 nginx 的容器里面添加一个端口
配置，名字为 http，暴露端口号为 80，然后创建一个 service，名字为 front-end-svc，暴露该
deployment 的 http 端口，并且 service 的类型为 NodePort。
# 查看已存在的deployment
kubectl get deployment
# 编辑deployment
kubectl edit deploy nginx
# 打开之后找到nginx容器
ports:
- containerPort: 80
name: http
protocol: TCP
# 暴露service
kubectl expose deploy nginx --name=front-end-svc --port=80 --target-port=http --type=NodePort
# 查看svc
kubectl get svc
curl 192.168.0.100:30214
ingress
在 ing-internal 命名空间下创建一个 ingress，名字为 pong，代理的 service hi，端口为 5678，
配置路径/hi。
验证：访问 curl -kL
kubectl get svc -n ing-internal
1.19之前不需要关注资源，之后需要
vim set paste粘贴模式
address是不是空不影响
address=internal-ip
Sidecar
添加一个名为 busybox 且镜像为 busybox 的 sidecar 到一个已经存在的名为 legacy-app 的
Pod 上，这个 sidecar 的启动命令为/bin/sh, -c, ‘tail -n+1 -f /var/log/legacy-app.log’。
并且这个 sidecar 和原有的镜像挂载一个名为 logs 的 volume，挂载的目录为/var/log/
RBAC
创建一个名为deployment-clusterrole的 clusterrole，该clusterrole只允许创建Deployments,Daemonset,Statefulset的create操作
在名字为app-team1的namespace下创建一个名为cicd-token的serviceAccount，并且将上一步创建的clusterrole的权限绑定到该serviceAccount
# 创建clusterrole
apiVersion:rbac.authorization.k8s.io/v1
kind:ClusterRole
metadata:
name: deployment-clusterrole
rules:
-apiGroups:["apps"]
resources:["deployments","statefulsets","daemonsets"]
verbs:["create"]
# 创建serviceaccount
kubectl create sa cicd-token -n app-team1
# 绑定权限
kubecdtl creare rolebinding deployment-rolebinding --clusterrole=deployment-clusterrole --serviceaccount=app-team1:cicd-token -n app-team1
PersistentVolume
创建一个 pv，名字为 app-config，大小为 2Gi，访问权限为 ReadWriteMany。Volume 的类
型为 hostPath，路径为/srv/app-config
apiVersion: v1
kind: PersistentVolume
metadata:
name: app-config
labels:
type: local
spec:
storageClassName: manual
capacity:
storage:2Gi
accessModes:
- ReadWriteMany
hostPath:
path: "/srv/app-config"
单题目
监控pod日志
监控名为 foobar 的 Pod 的日志，并过滤出具有 unable-access-website 信息的行，然后将
写入到 /opt/KUTR00101/foobar
监控pod度量指标
找出具有 name=cpu-user 的 Pod，并过滤出使用 CPU 最高的 Pod，然后把它的名字写在已
经存在的/opt/KUTR00401/KUTR00401.txt 文件里（注意他没有说指定 namespace。所以需要使
用-A 指定所以 namespace）
deployment扩缩容
扩容名字为 loadbalancer 的 deployment 的副本数为 6
检查node节点的健康状态
检查集群中有多少节点为 Ready 状态，并且去除包含 NoSchedule 污点的节点。之后将数字
写到/opt/KUSC00402/kusc00402.txt
节点维护
将 ek8s-node-1 节点设置为不可用，然后重新调度该节点上的所有 Pod
指定节点部署
创建一个 Pod，名字为 nginx-kusc00401，镜像地址是 nginx，调度到具有 disk=spinning 标
签 的 节 点 上
一个pod多个容器
创建一个 Pod ， 名 字 为 kucc1 ，这个 Pod 可能包含 1-4 容 器 ， 该 题 为 四 个 ：
nginx+redis+memcached+consul
Service
重新配置一个已经存在的 deployment front-end，在名字为 nginx 的容器里面添加一个端口
配置，名字为 http，暴露端口号为 80，然后创建一个 service，名字为 front-end-svc，暴露该
deployment 的 http 端口，并且 service 的类型为 NodePort。
ports:
-containerPort: 80
name: http
protocol: TCP
kubectl expose service --name=front-end-svc --target-port=http --type=NodePort
kubectl expose deployment front-end – name=front-end-svc --port=80 --target-port=http --type=NodePort
ingress
在 ing-internal 命名空间下创建一个 ingress，名字为 pong，代理的 service hi，端口为 5678，
配置路径/hi。
验证：访问 curl -kL
Sidecar
添加一个名为 busybox 且镜像为 busybox 的 sidecar 到一个已经存在的名为 legacy-app 的
Pod 上，这个 sidecar 的启动命令为/bin/sh, -c, ‘tail -n+1 -f /var/log/legacy-app.log’。
并且这个 sidecar 和原有的镜像挂载一个名为 logs 的 volume，挂载的目录为/var/log/
RBAC
创建一个名为deployment-clusterrole的 clusterrole，该clusterrole只允许创建Deployments,Daemonset,Statefulset的create操作
在名字为app-team1的namespace下创建一个名为cicd-token的serviceAccount，并且将上一步创建的clusterrole的权限绑定到该serviceAccount
PersistentVolume
创建一个 pv，名字为 app-config，大小为 2Gi，访问权限为 ReadWriteMany。Volume 的类
型为 hostPath，路径为/srv/app-config
kubectl练习
logs
打印pod或指定资源中容器的日志
如果pod只有一个容器，则容器名称是可选的
# 仅使用一个容器从pod nginx返回快照日志
kubectl logs nginx
# 使用多容器从pod nginx 返回快照日志
kubectl logs nginx --all-containers=true
# 从标签app=nginx定义的pod中的所有pod容器返回快照日志
kubectl logs -l app=nginx --all-containers=true
# 从pod web-1返回以前终止的ruby容器日志的快照
kubectl logs -p -c ruby web-1
# 开始从标签app=nginx定义的pod中的所有容器流式传输日志
kubectl logs -f -l app=nginx --all-containers=true
# 在pod nginx中显示最近的20行
kubectl logs --tail=20 nginx
# 显示过去一小时内写入的pod nginx中的所有日志
kubectl logs --since=1h nginx
# 显示服务证书已过期的kubelet中的日志
kubectl logs --insecure-skip-tls-verify-backend nginx
# 从名为hello的作业的第一个容器返回快照日志
kubectl logs job/hello
# 从名为nginx的部署的容器nginx-1返回快照日志
kubectl logs deployment/nginx -c nginx-1
top
显示资源使用情况
运行查看node或pod的资源情况
前置条件：需要正确配置metrics server在服务器上工作
node
# 获取所有node
kubectl top node
# 查看指定节点指标
kubectl top node node-name
pod
# 显示默认命名空间的pod指标
kubectl top pod
# 显示指定命名空间的所有pod指标
kubectl top pod --namespace=namespacename
# 显示更定pod及其容器的指标
kubectl top pod pod-name --containers
# 显示name=mylabel定义的pod的指标
kubectl top pod -l name=mylabel
scale
部署 deployment,replicaset replication controller,statefulset
如果指定了 --current-replicas或 --resource-version，则在尝试缩放之前对其进行验证，并保证在将缩放发送到服务器时条件成立
# 将replicaset缩放3
kubectl scale --replicas=3 rs/foo
# 将foo.yaml中缩放为3
kubectl scale --replicas=3 -f foo.yaml
# 如果名为Mysql的当前为2，变为3
kubectl scale --current-replicas=2 --replicas=3 deployment/mysql
# 扩展多个rc
kubectl scale --replicas=5 rc/foo rc/bar rc/baz
# 扩展statefulset为3
kubectl scale --replicas=3 statefulset/web
cordon
将节点标记为不可调度，node级别
kubectl cordon foo
drain
排空节点准备维护
expose
将资源公开为新的kubernetes服务
按名称查找deployment,service,replica set, replication controller,pod
并将该资源的选择器用作指定端口上新服务的选择器
仅当deployment,replicaset的选择器可转换为服务支持的选择器的时候
当选择器是match labels组件时，deployment,replicaset才会公开为服务
如果未通过–port指定端口，并且公开的资源具有多个端口，则新服务重用所有端口
如果未指定标签，新服务将重用其公开资源中的标签
kubectl expose deoloyment front-end --name=front-end-svc --port=80 --target-port=http --type=NodePort
–name:新创建对象的名称
–port：服务应在其上提供服务的端口，从公开的资源复制（如果未指定）
–target-port：服务应将流量定向到容器上的端口名称或编号
–type：此服务的类型为:clusertIP,NodePort,LoadBalancer,ExternalName，默认值为ClusterIP
容忍（taint）和污点（toleration）
taint和toleration
taint在一类服务器上打上污点，让不能容忍这个污点的pod不能部署在打了污点的服务器上
toleration是让pod容忍节点上配置的污点，可以让一些需要特殊配置的pod能够调用到具有污点和特殊配置的节点上
污点像锁node级别，容忍像钥匙pod级别
taint配置解析
创建一个污点
kubectl taint nodes node-name taint_key=taint_value:effect
kubectl taint nodes k8s-node01 ssd=true:prefernoschedule
NoSchedule：禁止调度到该节点，已经在该节点上的pod不受影响
NoExecute：禁止调度到该节点，如果不符合这个污点，会立马被驱逐(或在一段时间后)
PreferNoSchedule：尽量避免将pod调度到指定的节点上，如果没有更合适的节点，可以部署到该节点
将pod指派给节点
与节点标签匹配的nodeSelector
亲和性和反亲和性
nodeName字段
Pod拓扑分布约束
ingress
ingress是对集群中服务的外部访问进行管理的API对象，典型的访问方式是HTTP
ingress可以提供负载均衡，SSL终结和基于名称的虚拟托管
node：kubernetes集群中的一台工作机器，是集群的一部分
cluster：一组运行容器化应用程序的Node，用kubernetes管理
集群中的节点都不在公共网络中
edge router：边缘路由器，在集群中强制执行防火墙策略的路由器
可以由云提供商管理的网关，也可以是物理硬件
cluster Network：集群网络，一组逻辑的或物理的连结
基于kubernetes网络模型实现集群内的通信
service：kubernetes服务，使用标签选择算符selectors来选择一组pod
假定service具有只能在集群网络内路由的虚拟ip
ingress是什么
ingress提供从集群外部到集群内服务的http和https路由
流量路由由ingress资源所定义的规则来控制
将所有流量都发送到同一service
ingress可为service提供外部可访问的url，对其流量作负载均衡，终止ssl/tls
以及基于名称的虚拟托管等能力
ingress控制器负责完成ingress的工作
具体实现上通常会使用某个负载均衡器
ingress不会随意公开端口或协议，
将HTTP和HTTPS以外的服务开放到internet时，通常使用Service.Type=NodePort或Service.Type=LoadBalancer类型的service
环境准备
必须拥有一个Ingress控制器才能满足ingress的要求
仅创建ingress资源本身没有任何效果
apiVersion:networking.k8s.io/v1
kind: Ingress
metadata:
name: minimal-ingress
annotations:
nginx.ingress.kubernetes.ip/rewrite-target:/
spec:
ingressClassName: nginx-example
rules:
- http:
paths:
- path:/testpath
pathType:Prefix
backend:
service:
name:test
port:
number:80
ingress经常使用annotations来配置一些选项，具体取决于Ingress控制器
日志架构
应用日志可以了解应用内部的运行状况
日志对调试问题和监控集群活动非常有用
集群中，日志应该具有独立的存储，并且其生命周期与节点，pod或容器的生命周期相独立
集群级日志：具有独立的存储，其生命周期与node,pod或container的生命周期相独立
集群级日志架构需要一个独立的后端来存储，分析和查询日志
kubernetes并不为日志数据提供原生的存储解决方案
pod和容器日志
kubernetes从正在运行的pod中捕捉每个容器的日志
容器每秒将文本写入标准输出一次
# 一个容器的pod清单，每秒将文本写入标准输出一次
apiVersion: v1
kind: Pod
metadata:
name: counter
spec:
containers:
-name: count
image: busybox:1.28
args: [/bin/sh,-c,
'i=0; while true; do echo "$i: $(date)"; i=$((i+1)); sleep 1; done']
系统组件日志
容器中运行的组件
kubelet和容器运行时不在容器中运行
kubelet运行你的容器(一起按pod分组)
直接参与容器运行的组件
kubernetes调度器，控制器管理器和api服务器在pod中运行（通常是静态Pod）
etcd组件在控制平面中运行，最常见的也是作为静态pod
集群中使用kube-proxy，通常作为daemonset运行
对于在pod中运行的kubernetes集群组件，日志会写入/var/log目录中的文件
绕过默认的日志机制（组件不会写入sytemd日志）
可以使用kubernetes的存储机制将持久存储映射到运行该组件的容器中
集群级日志架构
使用在每个节点上运行的节点级日志记录代理
在应用程序的pod中，包含专门记录日志的sidecar容器
将日志直接从应用程序中推送到日志记录后端
使用sidecar容器运行日志代理
sidecar容器将应用程序日志传送到自己的标准输出
sidecar运行一个日志代理，配置该日志代理以便从应用容器收集日志
使用RBAC鉴权
基于角色role的访问控制rbac是一种基于组织用户的角色来控制对计算机或网络资源的访问的方法
RBAC鉴权机制使用rbac.authorization.k8s.ioAPI组来驱动鉴权决定，运行你通过kubernetesAPI动态配置策略
启动RBAC,在启动API服务器时将–authorization-mode参数设置为一个逗号分隔的列表并确保其中包含rbac
API对象
RBAC API声明了四种kubernetes对象：role,clusterRole,rolebinding和clusterRoleBinding
role和clusterRole
RBAC的Role或ClusterRole中包含一组代表相关权限的规则
这些权限是纯粹累加的
Role总是用来在某个名字空间内设置访问权限，在创建role时，必须指定role所属的名字空间
clusterRole是一个集群作用域的资源
kubernetes对象要么是名字空间作用域的，要么是集群作用域的
clusterrole
定义对某名字空间域对象的访问权限，并将在个别名字空间内被授予访问权限
为名字空间作用域的对象设置访问权限，并被授予跨所有名字空间的访问权限
为集群作用域的资源定义访问权限
role：在名字空间内定义角色
clusterrole：定义集群范围的角色
role实例
# 在位于default名字空间的role实例，用来授予对pod的读访问权限
apiVersion:rbac.authorization.k8s.io/v1
kind:Role
metadata:
namespace:default
name:pod-reader
rules:
- apiGroups:[] # 标明core api组
resources:["pods"]
verbs:["get","watch","list"]
clusterrole实例
clusterrole同样可以用于授予role能够授予的权限
clusterrole属于集群范围
集群范围资源
非资源端点
跨名字空间访问的名字空间作用域的资源
# 为任一特定名字空间中的Secret授予读访问权限，或者跨名字空间的访问权限
apiVersion:rbac.authorization.k8s.io/v1
kind:ClusterRole
metadata:
name:secret-reader
rules:
-apiGroups:[""]
resources:["secrets"]
verbs:["get","watch","list"]
RoleBinding和ClusterRoleBinding
角色绑定是将角色中定义的权限赋予一个或者一组用户
包含若干主体的列表和对这些主体所获得的角色的引用
rolebinding在指定的名字空间中执行授权
clusterRoleBinding在集群范围执行授权
一个roleBinding可以引用同一名字空间中的任何Role
一个RoleBinding可以引用某CluseterRole并将该clusterRole绑定到RoleBinding所在的名字空间
希望将某clusterRole绑定到集群中所有名字空间，使用clusterrolebinding
rolebinding或clusterrolebinding对象的名称必须是合法的路径分段名称
roleBinding实例
RoleBinding将pod-reader,Role授予在default名字空间中的用户jane
这样jane就具有了读取default名字空间中所有pod的权限
apiVersion:rbac.authorization.k8s.io/v1
kind:RoleBinding
metadata:
name:read-pods
namespace:default
subjects:
-kind:user
name: jane
apiGroup:rbac.authorization.k8s.io
roleRef:
# rpleref指定与某role或clusterrole的绑定关系
kind:Role
name:pod-reader
apiGroup:rbac.authorization.k8s.io