Lance.Wu
这个家伙很懒，一点也没有编辑。
这个家伙很懒，一点也没有编辑。
这个家伙很懒，一点也没有编辑。
这个家伙很懒，一点也没有编辑。
通过配置初始化配置文件的方式指定 --cri-socket=--cri-socket=unix:///var/run/cri-dockerd.sock
1.生成kubeadm config文件
cat <<EOF > kubeadm-init-config
apiVersion: kubeadm.k8s.io/v1beta3
kind: InitConfiguration
nodeRegistration:
criSocket: /var/run/cri-dockerd.sock #选择你所运行的CRI
EOF
2.通过配置文件的方式生成密钥kubeadm init phase upload-certs --upload-certs --config kubeadm-init-config
root@node01:~# kubeadm init phase upload-certs --upload-certs --config kubeadm-init-config
W0307 10:09:21.070099 1497994 initconfiguration.go:119] Usage of CRI endpoints without URL scheme is deprecated and can cause kubelet errors in the future. Automatically prepending scheme "unix" to the "criSocket" with value "/var/run/cri-dockerd.sock". Please update your configuration!
I0307 10:09:22.176557 1497994 version.go:256] remote version is much newer: v1.29.2; falling back to: stable-1.25
[upload-certs] Storing the certificates in Secret "kubeadm-certs" in the "kube-system" Namespace
[upload-certs] Using certificate key:
e6ac58fc026702302a3562fd1056be091c9ab87edd4cccd83a4c8a457e8ce9d8 # 此处是新的密钥
3.通过新的密钥添加管理节点
kubeadm join xx.xx.xx.xxx:6443 \
--token ********* \
--discovery-token-ca-cert-hash sha256:********* \
--control-plane \
--certificate-key e6ac58fc026702302a3562fd1056be091c9ab87edd4cccd83a4c8a457e8ce9d8 \
--cri-socket unix:///var/run/cri-dockerd.sock
在初始环境化节点安装系统环境准备未关闭防火墙，会出现您的错误提示。
为了更有效的解决问题，你可以参考连接 [https://www.orchome.com/16602] ，更好的帮助你解决问题。
使用etcdctl还原数据时，需要使用ca.crt、server.crt、server.key还原，集群会对证书加密的数据进行验证操作。一但证书被替换则无法通过验证。
kubernetes集群机器泡水，新搭建的ETCD证书重新创建了，剩下的备份文件也没有用，无法进行还原操作。
在 Kubernetes 中，CPU 资源以毫核或 milliCPU 为单位衡量，它表示 CPU 核的千分之一。例如，如果一个容器请求 500m（或 0.5）CPU，它意味着它需要半个 CPU 核。同样地，如果一个容器请求 1000m（或 1）CPU，它意味着它需要一个完整的 CPU 核。
毫核单位用于将 CPU 资源分配给运行在节点上的容器，它允许对每个容器使用的 CPU 进行细粒度的控制。当一个容器请求 CPU 资源时，Kubernetes 将调度容器在有可用 CPU 资源的节点上运行，并将限制容器的 CPU 使用量到所请求的数量。
值得注意的是，Kubernetes 中的 CPU 资源并不等同于节点上的物理 CPU。Kubernetes 使用 CPU 调度程序来管理节点上运行的所有容器的 CPU 资源，它可以根据容器的使用模式和资源请求动态地分配 CPU 资源给容器。
1核 = 1000毫核（m）
1毫核 = 1000微核（μ）
1微核 = 1000纳核（n）
BlockSize=26，也就是说一个IPBlock包含64个IP，而目前每台节点的Pod数量限制是默认的110，所以会生成2个Block。
如果你想每台node只存在一个段：
BlockSize=25，128个ip。BlockSize=24，256个ip。默认每台节点pod数量限制是110，将BlockSize调整25就涵盖了。如果改过每台节点的Pod数量限制，改为24，256个ip，该C类地址都给你用。
你使用的非官方的CSI镜像，该镜像未实现自动扩容接口，修改的PVC只是针对k8s进行了修改操作，但未对ceph和本地挂载进行扩容操作。
通过查询pv获取ceph的pool和镜像内容：
kubectl get pv pvc-ef145c0b-d9ee-4a99-9821-8ca69ea12515 -o yaml
...
rbd:
fsType: xfs
image: kubernetes-dynamic-pvc-ef145c0b-d9ee-4a99-9821-8ca69ea12515
...
pool: k8s-rbd
...
进入ceph的管理节点。
查看
rbd info k8s-rbd/kubernetes-dynamic-pvc-ef145c0b-d9ee-4a99-9821-8ca69ea12515
手动扩容ceph的镜像大小：
rbd resize k8s-rbd/kubernetes-dynamic-pvc-ef145c0b-d9ee-4a99-9821-8ca69ea12515 --size 5G
查看Pod所在的宿主机，找到对应挂的磁盘 /dev/rbd6 根据不同的文件类型执行下列命令。
# 类型为：xfs
xfs_growfs /dev/rbd6
# 其它类型使用
resize2fs /dev/rbd6
在查看pod内的大小，已经生效了。
你通过ip route命令，查看路由规则，你就能确认是通过路由直接映射的pod了。
kube-proxy网络组件有三种模式：
不细讲了，简单的解释就是你的service规则在iptable和ipvs可以看到相应的映射关系。你想了解自行Google吧。
这些规则相对是「静态」并且是底层的，所以影响实在是微乎其微。
apiVersion: v1
kind: ServiceAccount
metadata:
name: sa-all
namespace: test-namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
annotations:
rbac.authorization.kubernetes.io/autoupdate: "true"
labels:
kubernetes.io/bootstrapping: rbac-defaults
name: cluster-role-all
rules:
- apiGroups:
- '*'
resources:
- '*'
verbs:
- '*'
- nonResourceURLs:
- '*'
verbs:
- '*'
*代表所有。
verbs包括 ["get", "list", "watch", "create", "update", "patch", "delete"]权限。
你也可以设置部份权限和资源，如下
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: monitoring-endpoints
labels:
rbac.example.com/aggregate-to-monitoring: "true"
# 当你创建 "monitoring-endpoints" ClusterRole 时，
# 下面的规则会被添加到 "monitoring" ClusterRole 中
rules:
- apiGroups: [""]
resources: ["services", "endpoints", "pods"]
verbs: ["get", "list", "watch"]
通过kubectl api-resources命令可以查看kubernetes当前版本apiGroups和resources。
NAME SHORTNAMES APIGROUP NAMESPACED KIND
bindings true Binding
componentstatuses cs false ComponentStatus
configmaps cm true ConfigMap
endpoints ep true Endpoints
events ev true Event
limitranges limits true LimitRange
namespaces ns false Namespace
nodes no false Node
persistentvolumeclaims pvc true PersistentVolumeClaim
persistentvolumes pv false PersistentVolume
pods po true Pod
podtemplates true PodTemplate
replicationcontrollers rc true ReplicationController
resourcequotas quota true ResourceQuota
secrets true Secret
serviceaccounts sa true ServiceAccount
services svc true Service
mutatingwebhookconfigurations admissionregistration.k8s.io false MutatingWebhookConfiguration
validatingwebhookconfigurations admissionregistration.k8s.io false ValidatingWebhookConfiguration
customresourcedefinitions crd,crds apiextensions.k8s.io false CustomResourceDefinition
apiservices apiregistration.k8s.io false APIService
applications app.k8s.io true Application
controllerrevisions apps true ControllerRevision
daemonsets ds apps true DaemonSet
deployments deploy apps true Deployment
replicasets rs apps true ReplicaSet
statefulsets sts apps true StatefulSet
workflows wf argoproj.io true Workflow
tokenreviews authentication.k8s.io false TokenReview
localsubjectaccessreviews authorization.k8s.io true LocalSubjectAccessReview
selfsubjectaccessreviews authorization.k8s.io false SelfSubjectAccessReview
selfsubjectrulesreviews authorization.k8s.io false SelfSubjectRulesReview
subjectaccessreviews authorization.k8s.io false SubjectAccessReview
horizontalpodautoscalers hpa autoscaling true HorizontalPodAutoscaler
cronjobs cj batch true CronJob
jobs batch true Job
certificatesigningrequests csr certificates.k8s.io false CertificateSigningRequest
leases coordination.k8s.io true Lease
events ev events.k8s.io true Event
daemonsets ds extensions true DaemonSet
deployments deploy extensions true Deployment
ingresses ing extensions true Ingress
networkpolicies netpol extensions true NetworkPolicy
podsecuritypolicies psp extensions false PodSecurityPolicy
replicasets rs extensions true ReplicaSet
pytorchjobs kubeflow.org true PyTorchJob
scheduledworkflows swf kubeflow.org true ScheduledWorkflow
studyjobs kubeflow.org true StudyJob
tfjobs kubeflow.org true TFJob
compositecontrollers cc,cctl metacontroller.k8s.io false CompositeController
controllerrevisions metacontroller.k8s.io true ControllerRevision
decoratorcontrollers dec,decorators metacontroller.k8s.io false DecoratorController
alertmanagers monitoring.coreos.com true Alertmanager
prometheuses monitoring.coreos.com true Prometheus
prometheusrules monitoring.coreos.com true PrometheusRule
servicemonitors monitoring.coreos.com true ServiceMonitor
networkpolicies netpol networking.k8s.io true NetworkPolicy
poddisruptionbudgets pdb policy true PodDisruptionBudget
podsecuritypolicies psp policy false PodSecurityPolicy
clusterrolebindings rbac.authorization.k8s.io false ClusterRoleBinding
clusterroles rbac.authorization.k8s.io false ClusterRole
rolebindings rbac.authorization.k8s.io true RoleBinding
roles rbac.authorization.k8s.io true Role
priorityclasses pc scheduling.k8s.io false PriorityClass
storageclasses sc storage.k8s.io false StorageClass
volumeattachments storage.k8s.io false VolumeAttachment
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
annotations:
rbac.authorization.kubernetes.io/autoupdate: "true"
labels:
kubernetes.io/bootstrapping: rbac-defaults
name: cluster-role-all-binding
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-role-all
subjects:
- kind: ServiceAccount
name: sa-all
namespace: test-namespace
在你使用的test-namespace命名空间中的所有的工作负载当中都可以使用ServiceAccount。
在Pod当中使用
如果当前工作负载未绑定ServiceAccount，则会自动绑定
defaultServiceAccount。
apiVersion: v1
kind: Pod
metadata:
name: test-pod
namespace: test-namespace
spec:
serviceAccountName: sa-all
automountServiceAccountToken: false
...
另外一种方式，还可以通过文件卷挂载的方式使用
apiVersion: v1
kind: Pod
metadata:
name: test-pod
namespace: test-namespace
spec:
containers:
- image: nginx
name: nginx
volumeMounts:
- mountPath: /var/run/secrets/tokens
name: vault-token
serviceAccountName: sa-all
volumes:
- name: vault-token
projected:
sources:
- serviceAccountToken:
path: vault-token
expirationSeconds: 7200 # 过期时间
audience: vault
kubernetes会替 Pod 请求令牌并将其保存起来，通过将令牌存储到一个可配置的 路径使之在 Pod 内可用，并在令牌快要到期的时候刷新它。 kubelet 会在令牌存在期达到其 TTL 的 80% 的时候或者令牌生命期超过 24 小时 的时候主动轮换它。
先回答第一个问题：
尽管kafka服务器保证了消息的顺序，消息还是异步的发送给各个消费者，消费者收到消息的先后顺序不能保证了。这也意味着并行消费将不能保证消息的先后顺序。
来自：kafka入门介绍
核心意思是：虽然服务端保障了消息的顺序，但是多个消费者程序的能力参差不齐，也会而导致顺序的错乱。
所以只能1个分区对应1个消费者，并且只有这种可能。
1个分区注定只能有1个消费者（多个消费者就是上面说的，还是会导致错乱）。
我们来想象一下需要强一致性的业务，AB、AB顺序不能乱，举个话费充值的场景，先扣款再充值，如果顺序乱了，充值后再扣款，如果扣款不成功就会导致资损。
那么，我们来尝试一下，只有一个消费者的情况下如何来提高性能，顺序拿到消息后，多线程？ 很遗憾不行，多线程大家都明白是无序的（其实和多消费者一个道理）。
答案只有一个：顺序消费，一笔一笔的来。
不成立，那就是2个业务了，之间注定是没有耦合的，顺序根本谈不上了，所以也排除了。
也不行，因为你看不到整个消息的全貌，你怎么知道这条消息是最新的，也无法排序。
将同一种业务，归类细分，比如手机号同一个地区的放到同一个分区里处理，这也是唯一能想到的基于业务拆分的性能提升方式了，kafka是做不到的。
总接下来，通过kafka自身是无法做到的，只能在业务上动手脚（业务再细分），鱼和熊掌不可兼得。
你删除和加入权限的代码没有任何问题，这个主要是springboot的消费者加载问题。
没有逻辑重新初始化这个消费者了，所以你需要重新启动这个微服务，进行重新初始化。
我个人觉得这个行为是非常正确的，权限一旦确认就不会反复修改，所以这个场景本身就非常非常少。
你想，什么情况下消费者组会脱离，oom或微服务宕机的时候才会脱离，本身就与进程共存亡的。所以也没有人去专门写个逻辑，去维护你这个场景。一直去尝试加入消费者试错权限才是最大的灾难。
你如果是使用FileInputStream去读取文件，它是绝对路径获取文件，
java.io.FileNotFoundException: file:/xxxx/target/docker-demo.jar!/BOOT-INF/classes!/com/shenyue/collectionpro/kafka_client_jaas.conf (No such file or directory)
使用Jar的时候启动运行，系统不是认这个路径的。
你可以读取文件的时候使用
ClassPathResource classPathResource = new ClassPathResource("com/shenyue/collectionpro/kafka_client_jaas.conf");
他是直接去classes目录中获取资源读取的。
