Lance.Wu

使用etcdctl还原数据时，需要使用ca.crt、server.crt、server.key还原，集群会对证书加密的数据进行验证操作。一但证书被替换则无法通过验证。

为什么？

kubernetes集群机器泡水，新搭建的ETCD证书重新创建了，剩下的备份文件也没有用，无法进行还原操作。

如果我的kuberneters集群机器都泡水了，只剩备份文件，我能恢复吗？ 新搭建的集群去还原的话ip，node名什么的都变了，能行吗

在 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）

多谢，对于st模式的集群模式之前尝试过，应该是ok的，但我们现在要求用deployment+host主机映射，所以有了上述一些问题。

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网络组件有三种模式：

• User space 模式
• iptables 模式
• IPVS 模式

不细讲了，简单的解释就是你的service规则在iptable和ipvs可以看到相应的映射关系。你想了解自行Google吧。

这些规则相对是「静态」并且是底层的，所以影响实在是微乎其微。

创建serviceaccount

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

将ServicesAccount与ClusterRole绑定

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 小时 的时候主动轮换它。

参考文献

https://www.orchome.com/1315

https://www.orchome.com/1308

半兽人就是面试官。

kafka的顺序保证

先回答第一个问题：

尽管kafka服务器保证了消息的顺序，消息还是异步的发送给各个消费者，消费者收到消息的先后顺序不能保证了。这也意味着并行消费将不能保证消息的先后顺序。
来自：kafka入门介绍

核心意思是：虽然服务端保障了消息的顺序，但是多个消费者程序的能力参差不齐，也会而导致顺序的错乱。

所以只能1个分区对应1个消费者，并且只有这种可能。

再来，性能问题

1个分区注定只能有1个消费者（多个消费者就是上面说的，还是会导致错乱）。

我们来想象一下需要强一致性的业务，AB、AB顺序不能乱，举个话费充值的场景，先扣款再充值，如果顺序乱了，充值后再扣款，如果扣款不成功就会导致资损。

一个消费者

那么，我们来尝试一下，只有一个消费者的情况下如何来提高性能，顺序拿到消息后，多线程？ 很遗憾不行，多线程大家都明白是无序的（其实和多消费者一个道理）。

答案只有一个：顺序消费，一笔一笔的来。

将不同的业务发送到partition中？

不成立，那就是2个业务了，之间注定是没有耦合的，顺序根本谈不上了，所以也排除了。

根据业务时间戳？

也不行，因为你看不到整个消息的全貌，你怎么知道这条消息是最新的，也无法排序。

同一种业务再细分

将同一种业务，归类细分，比如手机号同一个地区的放到同一个分区里处理，这也是唯一能想到的基于业务拆分的性能提升方式了，kafka是做不到的。

最后

总接下来，通过kafka自身是无法做到的，只能在业务上动手脚（业务再细分），鱼和熊掌不可兼得。

你删除和加入权限的代码没有任何问题，这个主要是springboot的消费者加载问题。

1. java是静态语言，springboot第一次就初始化进行开始消费了。
2. 当你删除权限时，这个消费者组线程就结束了。

没有逻辑重新初始化这个消费者了，所以你需要重新启动这个微服务，进行重新初始化。

我个人觉得这个行为是非常正确的，权限一旦确认就不会反复修改，所以这个场景本身就非常非常少。

你想，什么情况下消费者组会脱离，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目录中获取资源读取的。