一、存储
1、StorageClass和volumeClaimTemplates
storageClass是PV的自动化实现，动态PV
volumeClaimTemplates是PVC的自动化实现，用在StatefulSet里
2、PV和PVC
PV和PVC是成对存在的。
PV默认会先和PVC进行绑定，再进行Pod的调度和创建。
PV可以通过StorageClass设置延时绑定，即Pod完成调度，再去和PVC绑定。
二、可观测性
1、 三种探针
readinessProbe（可以没有），就绪探针，失败就由kube-proxy拆除流量
livenessProbe（一定要有），存活探针，失败就由kubelet杀死重启
startupProbe(不一定要有，第一优先级)，解决启动慢的问题。
livenessProbe和readinessProbe可以一致，即服务假死就重启Pod。
startup探针优先级最高，readness和liveness在启动的时候可能是并行的。
2、 重启策略
默认Always，总是重启（包括正常退出0和异常退出）
Onfailure 异常失败才重启（非0状态，OOM等异常）
Never不重启
3、 远程调试service
port-forward 将集群中服务代理到本地，本地可以访问集群中服务（正向流量）
Telepresence 将本地服务代理到集群中，集群可以访问本地服务（反向流量）–swap-deployment （将本地的开发程序插入到kubernetes集群内部，包括DNS）
4、 调试node和pod
- 使用kubectl debug 附加一个Ephemeral Containers到pod中，可共享网络、磁盘，进程等。在pod不断重启、pod中不存在调试工具的时候，推荐使用。
二、Pod
1、静态Pod
1.1 概念
静态Pod直接由特定节点上的kubelet进程来管理，不通过master节点上的apiserver。无法与我们常用的控制器Deployment或者DaemonSet进行关联，它由kubelet进程自己来监控，当pod崩溃时重启该pod，kubelet也无法对他们进行健康检查。静态 pod 始终绑定在某一个kubelet，并且始终运行在同一个节点上。 kubelet会自动为每一个静态 pod 在 Kubernetes 的 apiserver 上创建一个镜像 Pod（Mirror Pod），因此我们可以在 apiserver 中查询到该 pod，但是不能通过 apiserver 进行控制（例如不能删除）
1.2 创建方式
配置文件：一般默认在
/etc/kubernetes/manifest/目录下存在yaml文件HTTP：kubelet 周期地从
–manifest-url=参数指定的地址下载文件，并且把它翻译成 JSON/YAML 格式的 pod。
1.3 其他
通过命令
systemctl status kubelet查看kubelet的配置文件路径为/etc/systemd/system/kubelet.service.d/10-kubeadm.conf，其中Environment="KUBELET_SYSTEM_PODS_ARGS=--pod-manifest-path=/etc/kubernetes/manifests参数代表了静态pod的目录。在master节点上可以看到
etcd.yaml kube-apiserver.yaml kube-controller-manager.yaml kube-scheduler.yamlmaster 节点上面的几个重要组件都是用静态 Pod 的方式运行的。这些Pod不会受到apiserver控制，同时防止误删除apiserver自己删除自己。
2、Pod更新策略
Deployment的更新策略：RollingUpdate和Recreate
StatefulSet的更新策略：RollingUpdate和OnDelete（禁止自动删除，必须手动删除才能出发更新重建。）
三、容器运行时
1、k8s的cgroup驱动
cgroupfs和systemd是linux系统cgroup的两种不同实现方式，systemd操作简单，且在一些发行版上默认支持使用。
K8s的cgroup驱动官方推荐选择systemd，和宿主机操作系统的cgroup、容器运行时的cgroup保持一致。
如果K8s和docker的cgroup驱动选择cgroupfs，而宿主机节点是systemd，在负载压力大的情况下，会导致k8s系统不稳定。
k8s和容器运行时要使用相同的cgroup驱动，最好和操作系统也一致，即systemd
四、调度
1、Taints和Toleration
节点亲和性是pod和node的亲和，pod被调度到特定的node上。
污点taints则相反，是一种洁癖，他排斥一类特定的Pod（不能容忍这个污点的Pod）。
容忍度Toleration是应用于Pod上的，如果Pod不容忍node的污点，则不能被调度到这个Node上
比如： kubectl taint nodes node1 key1=value1:NoSchedule 在说，我有洁癖，key1=value1且不能调度；如果一个pod 有tolerations:key: "key1" operator: "Equal" value: “value1” effect: "NoSchedule"
的容忍度标签，代表我接受key1=value1且效果为不能调度的洁癖，他就可以调度到node1上。当然也可以调度到其他没这个污点的node上。
污点的作用：专用节点（别人别和我抢）、我有特殊硬件（GPU）、基于污点的驱逐。
Pod的容忍度和node的污点要在KV和调度策略两方面都匹配才行。
五、安全
1、K8s API请求
用户通过kubectl请求api
pod等通过service account请求api
2、K8s支持的请求认证方式
Basic认证
X509证书认证–集群间组件通讯
JWT（Json Web Token）
Service Account
OpenID Connet
Webhooks
Kubernetes中的用户通常是通过请求凭证设置
- User=dahu
- Groups=[“tester”,“developer”]
service account 对用的token 会被装载到secret中
3、RBAC
Role：作用于指定的命名空间，定义在某个命名空间资源上可以进行的操作。
ClusterRole：作用于集群所有命名空间，定义针对所有命名空间的资源进行的操作。
RoleBinding和ClusterRoleBinding差别仅在于ns的有无。
默认ClusterRolebinding
system:basic-user，未认证用户组(group system:unauthenticated)的默认角色，不具备任何操作权限
cluster-admin，是system:master组默认的集群角色绑定，具体集群所有资源操作权限。
集群系统组件都有默认clusterrolebing，包括controller-manage、scheduler、kube-proxy等。
安全上下文
权限最小化原则
在pod或者container维度设置Security Context
开启PSP
4、多租安全加固
RBAC和基于namespace的软隔离是基本且必要的安全措施
使用PSP(Pod Security Policies)对Pod的安全参数进行校验，同时加固Pod运行时刻安全
使用Rerouce Quota & Limit Range限制租户的资源使用配额
敏感信息保护（secret encryption at REST）
在应用运行时刻遵循权限的最小化原则，尽可能缩小podn内容器的系统权限
使用NetworkPolicy进行业务应用间东西向网络流量的访问控制
Log everything（包括终端日志）
对接监控系统，实现容器应用维度的监控
转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 lxwno.1@163.com
