apiserver 补充限流认证以及mutating流程

apiserver是处理请求的一个restapi
进入apiserver首先是要认证，然后是鉴权，然后是admission准入，分为mutating(加入参数生成新的request)，validating，对生成的新的请求进行校验，以上几步都可以有hook来进行额外的操作，
最后持久化道etc
apiserver是挡在etcd之前的它会存在缓存，以减少etcd的压力

基于x509创建访问apiserver的user

。
1 生成对应的key
openssl genrsa -out myuser.key 2048
2. 生成csr certificate sign request
openssl req -new -key myuser.key -out myuser.csr
3. cat myuser.csr | base64 | tr -d “\n”
查看csr中的request 填入下方k8s csr对象中
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
name: myuser
spec:
request: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0KTUlJQzJ6Q0NBY01DQVFBdR4Q3pBSkJnTlZCQWdNQWtwVE1Rc3dDUVlEVlFRSApEQUp6YURFTU1Bb0dBMVVFQ2d3RGMyRndNUTh3RFFZRFZRUUxEQVp0ZVhWelpYSXhEekFOQmdOVkJBTU1CbTE1CmRYTmxjakVkTUJzR0NTcUdTSWIzRFFFSkFSWU9iWGwxYzJWeVFITmhjQzVqYjIwd2dnRWlNQTBHQ1NxR1NJYjMKRFFFQkFRVUFBNElCRHdBd2dnRUtBb0lCQVFDbUZoNkxRemF0bG9BWTZ4RTFnc1BrZnUrYTk2TnlKNW9oUVNSRApIbWJWQmZmb0pXUEZ5SHBMR3REaWs2SGpuR1VkdDFpSWR1T29EcGlsQ3lxMXMydDJWZHNOVUpCcmlQWE0zZUd0CjBqcDNXZzE1YUlXRERHQ25MZm5JRkVtSytGbFREMDVKM215bDY2T1NLL0hKOE1kYko2QS9TZjJpTlhDV0lJSWoKR01iL1pvTGMxd255SWk4M1VBb0tFeHlHTGNSU1ZRUTJ1OHdoQ1RRM3VSM3VNNVJvY3M4VFROSDI4V1BweXErbQpCQlpRcWF1ZUJtK3lFNkRyaUl0NlZ6b0ExazhKanQxd2gwTVB6bi9FaXN2ZEpKSHRTOHJTWlZIWk5sWHZKbFBnCitUZFZiME50MzlWL1U1TFoyME1RdkNjY1NHYVVMSTRnUXpzMFFuQW5MaGsxY2NyQkFnTUJBQUdnSURBZUJna3EKaGtpRzl3MEJDUWN4RVF3UGRHWm5hakU1T1RJd01UQXpWMWtxTUEwR0NTcUdTSWIzRFFFQkN3VUFBNElCQVFCdwpRcUcyNTA2L2pVU0lBVkJndkdEcWlIUzRwOG5jNGFoS3FOOHFWV0g4d1pwRXJmVzZ4MXkzb1hRSm44STVvVys1Ck5UYWRnSUwvdmQ3OStpK2NsZ0tNb0hHSmtCaXJDVTVKY01QNE5qdzJiMkhIbTIwMWd5SmdqRUJiUG1CcVh5VHkKcTk2WmQ4TlhTN081RzNrR0UzV2JGNEdxWVpLY3BycXZnSWMyN2hjbXBEdjUzL3FlbVd4dDVqMk1mZElyNk9ybwowbkljbWU1MzQvY3NONEZMK2VuTjk0WUZ3cnhpdWtVS0xYcXRENkphaFJnRTRWUVNlVm8rTmZpbzFDZTYyTkl5CkdjcFlKV2Ivc2VQV25acm8rRlhuMXZHUUUyQlRlUjRpTWZINjNaRUhQSXhwaXlGc2gycUlGNUJPcU4xeVJRa3kKdE5tZmh4QlJiWFJ1Vm9LYnFJY3QKLS0tLS1FTkQgQ0VSVElGSUNBVEUgUkVRVUVTVC0tLS0tCg==
signerName: kubernetes.io/kube-apiserver-client
expirationSeconds: 86400 # one day
usages:

client auth

创建csr对象

kubectl certificate approve myuser
创建role rolebinding 关联myuser
kubectl create role developer --verb=create --verb=get --verb=list --verb=update --verb=delete --resource=pods
kubectl create rolebinding developer-binding-myuser --role=developer --user=myuser
kubectl get pods --username=myuser

准入控制

配额管理

资源是有限的
方案：
定义ns的resourcequota，把spec保存为configmap
定义每个用户可以创建多少个pod
QosPod
BestEffortPod
用户可以创建多少个service ingress serviceVIP

ResourceQuator Controller
监控ns创建事件，限制创建的service ingress等个数
apiVersion: v1
kind: ResourceQuota
metadata:
name: object-counts
namespace: default
spec:
hard:
configmaps: “1”
service: “30”
ingress: “20”

limitRanger插件为pod设置默认资源请求和限制，需要在ns中创建LimitRange对象

namespacelifecycle: ns被删除后不接受创建请求
kube-apiserver --enable-admission-plugins=NamespaceLifecycle,LimitRanger

准入支持webhook

admission
mutating webhook 变形插件
有了mutating webhook对象

 apiVersion: admissionregistration.k8s.io/v1kind: MutatingWebhookConfigurationmetadata:name: ns-mutating.webhook.iowebhooks:- clientConfig:caBundle: {{.serverca_base64}} #caBundle 是一个 PEM 编码的 CA 包，将用于验证 Webhook 的服务证书。如果未指定，则使用 apiserver 上的系统信任根。url: https://admission.local.tess.io/api/admission.k8s.io/v1alpha1/ns-mutatingfailurePolicy: Failname: ns-mutating.webhook.ionamespaceSelector: {}rules:- apiGroups:- ""apiVersions:- '*'operations:- CREATEresources:- nodessideEffects: Unknown

它这个webhook需要一个service，一个deployment，一个后台，相当于是截获的流量到你的service负载均衡到后台，然后对request进行二次加工。

validating webhook 校验插件

validating webhook对象类似

apiserver 限流
全局限流 maxinflightlimit #最大并发处理的请求个数
maxrequestflightlimit #最大处理修改的请求个数

    然后接下来就是走到flowschema，它会分不同的流，然后到queue中，通过shaffhsading到算法，使得不会被某个大用户把队列沾满proorityLevelConfiguration 它下面有queue set，相当于是一个queue的集合，一个flow过来只能到几个queue里面

flowschema

root@iZwz9b6ehvw4yhz5f1wa4uZ:~/101/module6/mutatingwebhook/admission-controller-webhook-demo/deployment# kubectl get flowschemas.flowcontrol.apiserver.k8s.io system-nodes  -oyaml
apiVersion: flowcontrol.apiserver.k8s.io/v1beta1
kind: FlowSchema
metadata:annotations:apf.kubernetes.io/autoupdate-spec: "true"creationTimestamp: "2022-10-13T07:53:51Z"generation: 1name: system-nodes. # name+ type确定一个flowresourceVersion: "60"uid: 9cc4d1b0-b0d8-4be8-b08e-4ce0d97ec6ed
spec:distinguisherMethod:type: ByUsermatchingPrecedence: 500。#规则的优先级越小等级越高priorityLevelConfiguration: #对应的优先级队列name: systemrules:- nonResourceRules:- nonResourceURLs:- '*'verbs:- '*'resourceRules:- apiGroups:- '*'clusterScope: truenamespaces:- '*'resources:- '*'verbs:- '*'subjects:- group:name: system:nodeskind: Group
status:conditions:- lastTransitionTime: "2022-10-13T07:53:51Z"message: This FlowSchema references the PriorityLevelConfiguration object named"system" and it existsreason: Foundstatus: "False"type: Dangling

apiVersion: flowcontrol.apiserver.k8s.io/v1beta1
kind: PriorityLevelConfiguration
metadata:annotations:apf.kubernetes.io/autoupdate-spec: "true"creationTimestamp: "2022-10-13T07:53:51Z"generation: 1name: systemresourceVersion: "59"uid: b97d04de-e3f3-420b-9e3a-ce62a24e4316
spec:limited:assuredConcurrencyShares: 30limitResponse:queuing:handSize: 6queueLengthLimit: 50queues: 64type: Queuetype: Limited
status: {}

调试
优先级当前状态
kubectl get --raw /debug/api_priority_and_fairness/dump_priority_levels
所有队列当前状态列表
kubectl get --raw /debug/api-priority_and_fairness/dump_queues
当前正在等待的请求
kubectl get --raw /debug/api-priority_and_fairness/dump_reqeust