other
# 资源限制
## Resource
limits：表示 Pod 能够使用的资源上限。
- memory: 1Gi：表示 Pod 的内存限制为 1GB。
- cpu: 1：表示 Pod 的 CPU 使用上限为 1 核。
requests：表示 Pod 请求的资源量，也可以理解为 Pod 启动时所需的最小资源。
- memory: 256Mi：表示 Pod 启动时请求的内存为 256MB。
- cpu: 100m：表示 Pod 启动时请求的 CPU 为 0.1 核（100 毫核）。
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
resources:
limits:
memory: 1Gi
cpu: 1
requests:
memory: 256Mi
cpu: 100m
```
## ResourceQuota
```yaml
apiVersion: v1
kind: ResourceQuota # 资源类型为 ResourceQuota
metadata:
name: example-resource-quota # 资源名称为 example-resource-quota
spec:
hard:
pods: "10" # 允许的最大 Pod 数量
requests.cpu: "2" # CPU 请求的最大数量
requests.memory: 1Gi # 内存请求的最大数量
limits.cpu: "4" # CPU 限制的最大数量
limits.memory: 2Gi # 内存限制的最大数量
services.loadbalancers: "2" # 负载均衡服务的最大数量
services.nodeports: "5" # NodePort 服务的最大数量
persistentvolumeclaims: "20" # 持久卷声明的最大数量
count/openshift.io/deploymentconfigs: "5" # OpenShift 部署配置的最大数量
count/deployment.apps: "10" # Deployment 应用的最大数量
count/apps/v1/replicasets: "15" # ReplicaSet 的最大数量
```
以上示例定义了一个 ResourceQuota 资源，它限制了在该命名空间下可以使用的资源的数量。其中 spec.hard 字段指定了各种类型资源的硬性限制（即最大限制）。这个示例中包括了对 Pod、CPU 和内存请求/限制、服务、持久卷声明以及不同类型的控制器对象数量的限制。
## LimitRange
```yaml
apiVersion: v1
kind: Namespace
metadata:
name: myapp
---
apiVersion: v1
kind: LimitRange
metadata:
name: resource-limits
namespace: myapp
spec:
limits:
- default:
memory: 512Mi
cpu: 500m
defaultRequest:
memory: 256Mi
cpu: 100m
type: Container
```
LimitRange 和 ResourceQuota 都是 Kubernetes 中用于限制资源使用的对象，但它们的作用和范围有所不同。
**LimitRange：**
- 作用范围：限制单个 Pod 内容器的资源请求和限制范围。
- 适用对象：适用于单个 Pod 内容器级别的资源限制和请求设置。
- 示例用途：可以用于确保单个 Pod 中的容器在创建时符合特定命名空间中定义的资源限制规范。
**ResourceQuota：**
- 作用范围：限制命名空间下所有资源对象的总量。
- 适用对象：适用于限制命名空间中所有资源对象（如 Pod、Service、PersistentVolume 等）的总量，包括CPU、内存、持久卷等。
- 示例用途：可以用于确保命名空间中所有资源对象的总量不超过预先定义的限额，从而控制整个命名空间的资源使用。
因此，可以看出 LimitRange 主要用于对单个 Pod 内容器的资源进行限制，而 ResourceQuota 则用于对整个命名空间中的资源对象总量进行限制。两者在 Kubernetes 中起着不同但互补的作用，可以根据具体情况分别使用以实现资源的精细化管理。
# PodPreset
## PodPreset 的作⽤
将⼀些公⽤的参数设置到pod中去，例如 时区统⼀设置为东⼋区等
## API Server 开启PodPreset
- 编辑⽂件 /etc/kubernetes/manifests/kube-apiserver.yaml，添加配置 --runtime-config=settings.k8s.io/v1alpha1=true，添加PodPreset到--admission-control(新版本是--enable-admission-plugins)
- 重启kubelet服务，sudo systemctl restart kubelet
## 部署统⼀时区的PodPreset
```yaml
apiVersion: settings.k8s.io/v1alpha1
kind: PodPreset
metadata:
name: setting-timezone
spec:
selector:
matchLabels:
env:
- name: TZ
value: Asia/Shanghai
```
其中 selector、matchLabels是必须的，不写任何的值就代表全局启⽤。
## 禁⽤PodPreset
在⼀些情况下，⽤户不希望 Pod 被 Pod Preset 所改动，这时，⽤户可以在 Pod spec 中添加形如
podpreset.admission.kubernetes.io/exclude: "true" 的注解。
# ConfigMap
```sh
cat game.properties
#configmap from file
kubectl create configmap game-config --from-file=game.properties
#这条命令是从文件中创建 ConfigMap，其中 game.properties 是一个文件名。
#ConfigMap 中的数据会从 game.properties 文件中读取，文件中的内容将作为键值对存储在 ConfigMap 中。
#每一行数据会被解释为一个键值对，以等号（=）分隔键和值。
kubectl create configmap game-env-config --from-env-file=game.properties
#这条命令是从环境变量文件中创建 ConfigMap，也就是说 game.properties 文件中包含了环境变量的定义。
#ConfigMap 中的数据会从 game.properties 文件中读取，文件中每一行都会被解释为一个环境变量。
#每一行的格式通常是 KEY=VALUE，其中等号（=）左侧是环境变量的键，右侧是对应的值。
kubectl get configmap -oyaml game-config
```
## ConfigMap from literal
```sh
kubectl create configmap special-config --from-literal=special.how=very --from-literal=special.type=charm
#这条命令 kubectl create configmap special-config --from-literal=special.how=very --from-literal=special.type=charm 是通过 --from-literal 参数直接指定键值对来创建一个 ConfigMap，其中 special.how=very 和 special.type=charm 分别是两个键值对的设置。
#具体解释如下：
# special-config：新创建的 ConfigMap 的名称。
# --from-literal=special.how=very：表示将 special.how 键的值设置为 very。
#--from-literal=special.type=charm：表示将 special.type 键的值设置为 charm。
#这种方式适用于在创建 ConfigMap 时直接指定少量的键值对，不需要从文件或环境变量中读取。通过 --from-literal 参数可以快速而简单地创建包含特定键值对的 ConfigMap。
```
# 备注
```
⑥configmap和secret作用，区别
解决环境变量中敏感信息带来的安全隐患
为什么要统一管理环境变量
- 环境变量中有很多敏感的信息，比如账号密码，直接暴漏在yaml文件中存在安全性问题
- 团队内部一般存在多个项目，这些项目直接存在配置相同环境变量的情况，因此可以统一维护管理
- 对于开发、测试、生产环境，由于配置均不同，每套环境部署的时候都要修改yaml，带来额外的开销
k8s提供两类资源，configMap和Secret，可以用来实现业务配置的统一管理， 允许将配置文件与镜像文件分离，
以使容器化的应用程序具有可移植性 。
configMap，通常用来管理应用的配置文件或者环境变量
Secret，管理敏感类的信息，默认会base64编码存储，有三种类型
- Service Account ：用来访问Kubernetes API，由Kubernetes自动创建，
并且会自动挂载到Pod的/run/secrets/kubernetes.io/serviceaccount目录中；
创建ServiceAccount后，Pod中指定serviceAccount后，自动创建该ServiceAccount对应的secret；
- Opaque ： base64编码格式的Secret，用来存储密码、密钥等；
- kubernetes.io/dockerconfigjson ：用来存储私有docker registry的认证信息。
⑦说说k8s workload（工作负载）
控制器又称工作负载是用于实现管理pod的中间层，确保pod资源符合预期的状态，pod的资源出现故障时，
会尝试 进行重启，当根据重启策略无效，则会重新新建pod的资源。
- ReplicaSet: 代用户创建指定数量的pod副本数量，确保pod副本数量符合预期状态，并且支持滚动式自动扩容和缩容功能
- Deployment：工作在ReplicaSet之上，用于管理无状态应用，目前来说最好的控制器。支持滚动更新和回滚功能，还提供声明式配置
- DaemonSet：用于确保集群中的每一个节点只运行特定的pod副本，通常用于实现系统级后台任务。比如ELK服务
- Job：只要完成就立即退出，不需要重启或重建
- Cronjob：周期性任务控制，不需要持续后台运行
- StatefulSet：管理有状态应用
⑧k8s扩容机制
⑨service怎么找到pod？
service是一组pod的服务抽象，相当于一组pod的LB，负责将请求分发给对应的pod。service会为这个LB提供一个IP，
一般称为cluster IP。使用Service对象，通过selector进行标签选择，找到对应的Pod。
service对象创建的同时，会创建同名的endpoints对象，若服务设置了readinessProbe, 当readinessProbe检测失败时，
endpoints列表中会剔除掉对应的pod_ip，这样流量就不会分发到健康检测失败的Pod中
⑩用过无头svc吗
`https://blog.csdn.net/zjz5740/article/details/115652274`
11>外部如何访问k8s内应用
12>k8s数据采集的方式有哪些
13>k8s的日志管理方式
14>k8s网络通信
a.容器间通信:同一个pod内的多个容器间的通信,通过lo即可实现;
b.pod之间的通信:pod ip <---> pod ip,pod和pod之间不经过任何转换即可通信;
c.pod和service通信:pod ip <----> cluster ip(即service ip)<---->pod ip,它们通过iptables或ipvs实现通信,ipvs取代不了iptables,因为ipvs只能做负载均衡,而做不了nat转换;
d.Service与集群外部客户端的通信.
kubectl get configmap -n kube-system
kubectl get configmap kube-proxy -o yaml -n kube-system
看到mode是空的,把它改为ipvs就可以,k8s靠CNI接口接入其他插件来实现网络通讯.目前比较流行的插件有flannel、callco、canel.
使用PV+PVC连接分布式存储解决方案
- ceph
- glusterfs
- nfs
###### 如何编写资源yaml
1. 拿来主义，从机器中已有的资源中拿
```powershell
$ kubectl -n kube-system get po,deployment,ds
```
2. 学会在官网查找， https://kubernetes.io/docs/home/
3. 从kubernetes-api文档中查找， https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.16/#pod-v1-core
4. kubectl explain 查看具体字段含义
```