喜剧片《美丽老师2在观整有限中字》手机高清免费在线...
去康复机构,不仅需要费用,还需要人力陪同,并且老母亲还说要跟着去。
2024年12月22日,她准备了不少做冷饮的材料存放在冰箱里面,再加上会自己做饭,买的蔬菜水果有一些也放在冰箱里面。
喜剧片《美丽老师2在观整有限中字》手机高清免费在线...
藏獒学名西藏獒犬是一种原产于中国青藏高原的大型犬种拥有悠久的历史可追溯至数千年之前它们体型庞大肩高可达70厘米以上体重可超过70公斤毛色多样以黑、棕、铁包金等为主藏獒最为人称道的是其对主人及其领地的极度忠诚与保护欲它们能够不畏严寒与野兽成为牧民家庭和羊群最坚实的守护者藏獒性格独立、勇敢、自信但对陌生人保持高度警惕这使得它们既是优秀的守卫犬也是难以驯服的挑战
Apache Pulsar学习笔记14: 使用Helm在Kubernetes集群中部署Pulsar原创2021-12-31 18:22·架构小白时间过得比较久了,在开始今天的学习之前先回顾一下前面已经学习的13节的内容。0.阶段复习Pulsar是一个支持多租户的、高性能的、分布式的Pub-Sub消息系统。了解Pulsar的架构。Pulsar提供了一个比Cluster更高级别的抽象Instance。一个Pulsar Instance由多个Pulsar Cluster组成一个Instance中的Cluster之间可以相互跨地域复制数据单个Pulsar集群由以下部分组成:Pulsar Proxy: 是无状态的,Proxy作为集群的智能路由层,是负责Pulsar客户端与Pulsar集群交互的统一网关Pulsar Brokers: 也是无状态的,是集群的服务层,Proxy会将客户端的访问请求转发到正确的Broker上。Broker作为服务层与Pulsar的存储层进行交互Bookies: 一个集群有多个Bookie节点(组成Bookeeper集群)负责消息的持久化存储Zookeeper: 用于集群级别的配置和协调,并存储Pulsar集群的所有元数据以docker容器运行单机Pulsar学习使用命令行工具pulsar-admin创建tenant、namespace、topic了解Pulsar Admin REST APItenant、namespace、topic的基本概念Pulsar基于租户、命名空间、主题的逻辑层次结构支持多租户分区Topic的概念Topic URL格式持久化Topic和非持久化Topic的概念生产者和消费者、订阅和订阅模式Pulsar支持: exclusive(独占), failover(故障转移/灾备), shared(共享), key-shared(基于key的共享模式) 4中订阅模式使用命令行工具pulsar-client进行生产者和消费者测试使用Pulsar Java客户端库创建生产者、消费者、Reader消费者端可以使用"同步接收消息", "异步接收消息", "MessageListener接收" 3种模式,其中MessageListener自带线程池创建消费者时可以设置消费者的批量接收策略多主题订阅: 设置单个消费者订阅多个主题消费异常处理可以使用"无限重试", "捕获并忽略异常", "死信主题(Dead Letter Topic)"三种方式使用消息Reader可以由用户自己手动在Topic中定位,读取想要读取的消息使用Pulsar Go客户端库消费者端支持consumer.Receive()和consumer.Chan()两种方式消费消息。前者对channel关闭和context cancel的情况做了封装,后者要我们自己处理和channel的交互,但也提供了最大的灵活性。多主题订阅死信策略和死信主题使用消息Reader使用Pulsar Schema管理消息数据的类型安全性Web图形化管理工具Pulsar Manager延迟消息投递特性指定多长时间后投递deliverAfter指定在将来某个时间点投递deliverAt分区Topic和路由模式认证和授权开启JWT身份认证授权和权限管理前面的学习一直是基于以docker容器启动的单机Pulsar。今天将学习使用Helm在Kubernetes集群中部署Pulsar集群。1.环境准备这里使用的Kubernetes集群的版本是1.22.4,Helm的版本是3.7.1。1.1 Pulsar集群组件和K8S Node节点规划下面做一下Pulsar集群各个组件部署节点的规划。使用Pulsar官方的Helm Chart部署时,可选择部署各个组件。 在后边的配置中将禁用监控相关的组件(promethues, grafana等),我们这里选择以后尝试使用外部的全局Prometheus实现对Pulsar集群的监控。本节选择部署的集群组件如下:proxy: 无状态, 但pulsar的helm chart使用StatefulSet部署broker: 无状态, 但pulsar的helm chart使用StatefulSet部署bookie: 有状态, pulsar的helm chart使用StatefulSet部署zookeeper: 有状态, pulsar的helm chart使用StatefulSet部署recovery: 无状态, 但pulsar的helm chart使用StatefulSet部署toolset: 无状态, 但pulsar的helm chart使用StatefulSet部署pulsar-manager: 无状态, pulsar的helm chart使用Deployment部署注意, pulsar-managers虽然是无状态的,但因为它需要使用PostgreSQL数据库,pulsar-managers的docker镜像中内置一个PostgreSQL, 这个我们在后边的配置中将改为使用集群外部的PostgreSQL。下面说一下以上各个组件的部署节点选择。对于proxy, broker, recovery, toolset, pulsar-manager这5个无状态组件,可以让k8s将其调度到任意节点上。对于bookie, zookeeper这2个有状态组件,需要我们根据其存储卷的类型,将其规划到合适的k8s节点。我们在线上环境对于有状态服务的部署,在存储卷的选择上,为了更好的性能,一般都是选择Local Persistent Volumes 在。因此,如果你在规划一个线上版本的Pulsar集群部署的话,对于bookie和zookeeper肯定需要单独的独立的k8s节点,并使用这些节点上创建的Local PV。 例如,一个线上生产可用的Pulsar集群可能规划如下:pulsar zookeeper集群至少需要3个独立的k8s节点, 在这些节点上创建zookeeper的local pvpulsar bookeeper集群(bookie节点组成)根据规划的容量需要N个独立的k8s节点, 在这些节点上创建bookie的local pv。如果后续需要扩容增加bookie节点时,只需要有新的创建好local pv的k8s节点,并对bookie的StatefulSet扩容即可。pulsar proxy, broker等无状态服务,只需要有足够的数量的k8s节点,并在需要时按需扩容即可因本文这里用于实验的k8s集群资源有限,所以尽量将上面各组件在3个k8s节点上混部,将一个用于测试环境的的Pulsar集群规划如下:k8s节点部署pulsar组件备注node1zookeeper-0, bookie-0, broker-0, proxy-0线上环境bookie和zookeeper一定要在单独的节点上node2zookeeper-1, bookie-1, broker-1, proxy-1线上环境bookie和zookeeper一定要在单独的节点上node3zookeeper-2, bookie-2, broker-2, proxy-2线上环境bookie和zookeeper一定要在单独的节点上node1或node2或node3recovery-0, toolset-0, pulsar-manager基于上面测试环境的规划,我们将node1~node3三个节点打上Label和Taint:kubectl label node node1 node-role.kubernetes.io/pulsar=pulsarkubectl label node node2 node-role.kubernetes.io/pulsar=pulsarkubectl label node node3 node-role.kubernetes.io/pulsar=pulsarkubectl taint nodes node1 dedicated=pulsar:NoSchedulekubectl taint nodes node2 dedicated=pulsar:NoSchedulekubectl taint nodes node3 dedicated=pulsar:NoScheduleLabel node-role.kubernetes.io/pulsar=pulsar用于标记节点是专门用于运行pulsar集群组件的k8s节点。Taint dedicated=pulsar:NoSchedule被打到节点上后,默认配置下k8s集群中的其他不属于pulsar集群组件的pod将不会被调度到这3个节点上,而后边我们将要部署的pulsar组件上将会使用Toleration配置允许dedicated=pulsar:NoSchedule的Taint。注意这里只是根据测试环境Pulsar集群的规划,做了上面的Label和Taint的设置,如果是生产环境,这里的Label和Taint应该做更合理和细粒度的规划,确保实现上面生产可用Pulsar集群的Node节点规划1.2 Pulsar集群组件容器镜像准备前面我们选择要部署Pulsar集群的proxy, broker, bookie, zookeeper, recovery, toolset, pulsar-manager 7大组件。其中proxy, broker, bookie, zookeeper, recovery, toolset的官方容器镜像都是apachepulsar/pulsar-all。 pulsar-manager的官方镜像是apachepulsar/pulsar-manager。本文使用的pulsar官方的helm chart https://github.com/apache/pulsar-helm-chart/releases。pulsar-helm-chart的版本为2.7.7,该版本中pulsar的版本为2.7.4, pulsar-manager版本为v0.1.0:apachepulsar/pulsar-all:2.7.4apachepulsar/pulsar-manager:v0.1.0注意因为pulsar-manager:v0.1.0有这个ISSUE https://github.com/apache/pulsar-helm-chart/issues/133中描述的问题,所以在后边的部署将镜像pulsar-manager:v0.1.0更换成了pulsar-manager:v0.2.0。为了提高效率,这里将apachepulsar/pulsar-all:2.7.4和apachepulsar/pulsar-manager:v0.2.0这两个镜像转存到了k8s集群所使用的私有镜像仓库中,例如:harbor.example.com/library/apachepulsar/pulsar-all:2.7.4harbor.example.com/library/apachepulsar/pulsar-manager:v0.2.01.3 创建JWT认证所需的K8S Secret这里部署的Pulsar集群需要在安全上开通JWT认证。根据前面学习的内容,JWT支持通过两种不同的秘钥生成和验证Token:对称秘钥:使用单个Secret key来生成和验证Token非对称秘钥:包含由私钥和公钥组成的一对密钥使用Private key生成Token使用Public key验证Token推荐使用非对称密钥的方式,需要先生成密钥对,再用秘钥生成token。因为Pulsar被部署在K8S集群中,在K8S集群中存储这些秘钥和Token的最好的方式是使用K8S的Secret。pulsar-helm-chart专门提供了一个prepare_helm_release.sh脚本,可以用来生成这些Secret。下面我们将pulsar-helm-chart的源码clone到K8S的控制节点上(kubectl和helm可用的节点):git clone -b pulsar-2.7.7 --depth 1 https://github.com/apache/pulsar-helm-chart.gitcd pulsar-helm-chart/执行下面的命令生成秘钥对和Token的Secret的Manifest:./scripts/pulsar/prepare_helm_release.sh \ -n pulsar \ -k pulsar \ -l上面的命令中:-n指定的生成Secret Manifest中安装的命名空间,这里我是将其部署到K8S中的pulsar namespace中,所以指定为pulsar,当然也可以指定部署到其他的namespace中。-k指定的是使用helm部署时的helm release名称,这里指定为pulsar。-l指定只将生成的内容输出达到本地,而不会自动部署到K8S中。比较喜欢这种手动的方式,因为一切比较可控。注意这个脚本还有一个-s,--symmetric参数,如果给这个参数的话,JWT认证将使用对称秘钥的方式,这里没有给这个参数,就使用非对称秘钥的方式。执行上面的脚本会输出以下内容:generate the token keys for the pulsar cluster---The private key and public key are generated to ... successfully.apiVersion: v1data: PRIVATEKEY: <...> PUBLICKEY: <...>kind: Secretmetadata: creationTimestamp: null name: pulsar-token-asymmetric-key namespace: pulsargenerate the tokens for the super-users: proxy-admin,broker-admin,admingenerate the token for proxy-admin---pulsar-token-asymmetric-keyapiVersion: v1data: TOKEN: <...> TYPE: YXN5bW1ldHJpYw==kind: Secretmetadata: creationTimestamp: null name: pulsar-token-proxy-admin namespace: pulsargenerate the token for broker-admin---pulsar-token-asymmetric-keyapiVersion: v1data: TOKEN: <...> TYPE: YXN5bW1ldHJpYw==kind: Secretmetadata: creationTimestamp: null name: pulsar-token-broker-admin namespace: pulsargenerate the token for admin---pulsar-token-asymmetric-keyapiVersion: v1data: TOKEN: <...> TYPE: YXN5bW1ldHJpYw==kind: Secretmetadata: creationTimestamp: null name: pulsar-token-admin namespace: pulsar-------------------------------------The jwt token secret keys are generated under: - 'pulsar-token-asymmetric-key'The jwt tokens for superusers are generated and stored as below: - 'proxy-admin':secret('pulsar-token-proxy-admin') - 'broker-admin':secret('pulsar-token-broker-admin') - 'admin':secret('pulsar-token-admin')从输出可以看出,该脚本生成了4个K8S Secret的Manifest:pulsar-token-asymmetric-key这个Secret中是用于生成Token和验证Token的私钥和公钥pulsar-token-proxy-admin这个Secret中是用于proxy的超级用户角色Tokenpulsar-token-broker-admin这个Secret中是用于broker的超级用户角色Tokenpulsar-token-admin这个Secret中是用于管理客户端的超级用户角色Token接下来手动将这4个Secret使用kubectl apply创建到K8S的pulsar命名空间中。 创建完成后,可以使用kubectl找到它们:kubectl get secret -n pulsar | grep pulsar-tokenpulsar-token-admin Opaque 2 5mpulsar-token-asymmetric-key Opaque 2 5mpulsar-token-broker-admin Opaque 2 5mpulsar-token-proxy-admin Opaque 2 5m1.4 创建Zookeeper和Bookie的Local PV根据部署Pulsar的K8S节点的规划,下面需要为zookeeper, bookie所在的节点在K8S上创建Local Persistent Volume。注意每个zookeeper节点需要一个data的local volume,每个bookie节点需要journal和ledgers共两个local volume。在创建Local PV之前,需要确认一下k8s中存在StorageClasslocal-storage,如果没有可以使用下面的manifest创建。apiVersion: storage.k8s.io/v1kind: StorageClassmetadata: name: local-storageprovisioner: kubernetes.io/no-provisionervolumeBindingMode: WaitForFirstConsumerreclaimPolicy: Retain注意现在的K8S中不在直接提供local volume的provisioner,这里也没有使用provisioner,因此后续对local volume的创建和管理都是需要K8S集群管理员的手动进行。 也是说目前Kubernetes核心中不包含对对本地卷进行动态发放和管理的provisioner,如果想要体验动态发放和管理的功能,可以试一下由Rancher提供的Local Path Provisioner。我这里依然使用手动管理的方式,即通过手动在K8S节点上创建Local Volume,手动绑定Local Volume与Pulsar Zookeeper和Bookie的PVC(PersistentVolumeClaim)之间的关系。下面,先手动在node1, node2, node3上创建local volume对应的数据目录:mkdir -p /home/puslar/data/zookeeper-datamkdir -p /home/puslar/data/bookie-data/ledgersmkdir -p /home/puslar/data/bookie-data/journalzookeeper data的local pv的manifest如下:---apiVersion: v1kind: PersistentVolumemetadata: name: pulsar-zookeeper-data-pulsar-zookeeper-0spec: capacity: storage: 20Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain storageClassName: local-storage local: path: /home/puslar/data/zookeeper-data claimRef: name: pulsar-zookeeper-data-pulsar-zookeeper-0 namespace: pulsar nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - node1---apiVersion: v1kind: PersistentVolumemetadata: name: pulsar-zookeeper-data-pulsar-zookeeper-1spec: capacity: storage: 20Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain storageClassName: local-storage local: path: /home/puslar/data/zookeeper-data claimRef: name: pulsar-zookeeper-data-pulsar-zookeeper-1 namespace: pulsar nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - node2---apiVersion: v1kind: PersistentVolumemetadata: name: pulsar-zookeeper-data-pulsar-zookeeper-2spec: capacity: storage: 20Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain storageClassName: local-storage local: path: /home/puslar/data/zookeeper-data claimRef: name: pulsar-zookeeper-data-pulsar-zookeeper-2 namespace: pulsar nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - node3上面的manifest仍中将3个Local PV通过nodeAffinity创建并关联到到node1~node3上,同时使用claimRef将这3个Local PV与即将在K8S集群中部署的zookeeper SatefulSet中的PVC绑定。 使用kubectl apply创建上面的manifest。bookie ledgers和journal的local pv的manifest如下:---apiVersion: v1kind: PersistentVolumemetadata: name: pulsar-bookie-ledgers-pulsar-bookie-0spec: capacity: storage: 50Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain storageClassName: local-storage local: path: /home/puslar/data/bookie-data/ledgers claimRef: name: pulsar-bookie-ledgers-pulsar-bookie-0 namespace: pulsar nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - node1---apiVersion: v1kind: PersistentVolumemetadata: name: pulsar-bookie-journal-pulsar-bookie-0spec: capacity: storage: 50Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain storageClassName: local-storage local: path: /home/puslar/data/bookie-data/journal claimRef: name: pulsar-bookie-journal-pulsar-bookie-0 namespace: pulsar nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - node1---apiVersion: v1kind: PersistentVolumemetadata: name: pulsar-bookie-ledgers-pulsar-bookie-1spec: capacity: storage: 50Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain storageClassName: local-storage local: path: /home/puslar/data/bookie-data/ledgers claimRef: name: pulsar-bookie-ledgers-pulsar-bookie-1 namespace: pulsar nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - node2---apiVersion: v1kind: PersistentVolumemetadata: name: pulsar-bookie-journal-pulsar-bookie-1spec: capacity: storage: 50Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain storageClassName: local-storage local: path: /home/puslar/data/bookie-data/journal claimRef: name: pulsar-bookie-journal-pulsar-bookie-1 namespace: pulsar nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - node2---apiVersion: v1kind: PersistentVolumemetadata: name: pulsar-bookie-ledgers-pulsar-bookie-2spec: capacity: storage: 50Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain storageClassName: local-storage local: path: /home/puslar/data/bookie-data/ledgers claimRef: name: pulsar-bookie-ledgers-pulsar-bookie-2 namespace: pulsar nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - node3---apiVersion: v1kind: PersistentVolumemetadata: name: pulsar-bookie-journal-pulsar-bookie-2spec: capacity: storage: 50Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain storageClassName: local-storage local: path: /home/puslar/data/bookie-data/journal claimRef: name: pulsar-bookie-journal-pulsar-bookie-2 namespace: pulsar nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - node3上面的manifest仍中将6个Local PV通过nodeAffinity创建并关联到到node1~node3上,同时使用claimRef将这3个Local PV与即将在K8S集群中部署的zookeeper SatefulSet中的PVC绑定。 使用kubectl apply创建上面的manifest。1.5 准备Pulsar Manager的PostgreSQL数据库这里准备让Pulsar Manager使用外部数据库,需要提前在外部的PostgreSQL中创建好用户和数据库表结构。创建数据库和用户:CREATE USER pulsar_manager WITH PASSWORD '