Lance.Wu
这个家伙很懒，一点也没有编辑。
这个家伙很懒，一点也没有编辑。
这个家伙很懒，一点也没有编辑。
这个家伙很懒，一点也没有编辑。
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类地址都给你用。
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内的大小，已经生效了。
你使用的非官方的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内的大小，已经生效了。
是的，我这台机器有docker和contaienrd，用上面的方法指定其中一个可以，也可以卸载其中一个。
kubeadm init --apiserver-advertise-address=1.1.1.1 --image-repository registry.aliyuncs.com/google_containers --pod-network-cidr=192.168.0.0/16
--cri-socket=unix:///var/run/cri-dockerd.sock
或者
kubeadm init --apiserver-advertise-address=1.1.1.1 --image-repository registry.aliyuncs.com/google_containers --pod-network-cidr=192.168.0.0/16
--cri-socket= unix:///var/run/containerd/containerd.sock
你通过ip route命令，查看路由规则，你就能确认是通过路由直接映射的pod了。
kube-proxy网络组件有三种模式：
不细讲了，简单的解释就是你的service规则在iptable和ipvs可以看到相应的映射关系。你想了解自行Google吧。
这些规则相对是「静态」并且是底层的，所以影响实在是微乎其微。
rdb resize命令 在 ceph节点执行rbd resize --size 9192 kube/pvc-6a06fa0f-c0a5-401b-83bf-d44c1dd20d80
rbd info --pool kube pvc-6a06fa0f-c0a5-401b-83bf-d44c1dd20d80
执行命令：resize2fs
如: resize2fs /dev/rbd1
Df -h
[root@jituan-xiaofei-docker01 ~]# resize2fs /dev/rbd1
resize2fs 1.42.9 (28-Dec-2013)
resize2fs: Bad magic number in super-block while trying to open /dev/centos/root
Couldn't find valid filesystem superblock.
由于系统为centos7系统，文件格式为xfs
所以需要使用以下命令刷新lv
xfs_growfs /dev/rbd1
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目录中获取资源读取的。
