Posted on

minikube [FATAL] plugin/loop: Seen "HINFO IN xxx." more than twice, loop detected

修改kubelet的配置文件，加上--resovf-conf标志：

配置文件位置：/etc/systemd/system/kubelet.service.d/10-kubeadm.conf

[Unit]
Wants=docker.socket

[Service]
ExecStart=
ExecStart=/usr/bin/kubelet --hostname-override=minikube --cluster-dns=10.96.0.10 --cluster-domain=cluster.local --fail-swap-on=false --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --pod-manifest-path=/etc/kubernetes/manifests --allow-privileged=true --authorization-mode=Webhook --client-ca-file=/var/lib/minikube/certs/ca.crt --cadvisor-port=0 --cgroup-driver=cgroupfs --kubeconfig=/etc/kubernetes/kubelet.conf --resolv-conf=/etc/resolv.conf
[Install]

使用 systemctl daemon-reload 命令重新读取配置，使用 service kubelet restart 重启kubelet 。

 

其中，在 resolv.conf 中的配置文件内容如下：

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
#nameserver 127.0.0.1
nameserver 8.8.8.8

随后重启 coredns pod即可。

Continue reading "minikube [FATAL] plugin/loop: Seen "HINFO IN xxx." more than twice, loop detected"

Posted on

ServiceMesh与Istio（一）

近两年微服务架构流行，主流互联网厂商内部都已经微服务化，初创企业虽然技术积淀不行，但也通过各种开源工具拥抱微服务。再加上容器技术赋能，Kubernetes又添了一把火，微服务架构已然成为当前软件架构设计的首选。但微服务化易弄，服务治理难搞！ 

微服务的“痛点”

微服务化没有统一标准，多数是进行业务领域垂直切分，业务按一定的粒度划分职责，并形成清晰、职责单一的服务接口，这样每一块规划为一个微服务。微服务之间的通信方案相对成熟，开源领域选择较多的有RPC或RESTful API方案，比如：gRPC、Apache Thrift等。这些方案多偏重于数据如何打包、传输与解包，对服务治理的内容涉及甚少。
微服务治理是头疼的事，也是微服务架构中的痛点。治理这个词有多元含义，很难下达一个精确定义，这里可以像小学二年级学生那样列出治理的诸多近义词：管理、控制、规则、掌控、监督、支配、规定、统治等。对于微服务而言，治理体现在以下诸多方面：

  • 服务注册与发现

  • 身份验证与授权

  • 服务的伸缩控制

  • 反向代理与负载均衡

  • 路由控制

  • 流量切换

  • 日志管理

  • 性能度量、监控与调优

  • 分布式跟踪

  • 过载保护

  • 服务降级

  • 服务部署与版本升级策略支持

  • 错误处理

  • ……

 

从微服务治理角度来说，微服务其实是一个“大系统”，要想将这个大系统全部落地，绝非易事，尤其是之前尚没有一种特别优雅的技术方案。多数方案（比如：Dubbo、go-kit等）都或多或少地对应用逻辑有一定的侵入性，让业务开发人员不能只focus到业务本身，还要关心那些“治理”逻辑。并且市面上内置了微服务治理逻辑的框架较少，且很多编程语言相关。这种情况下，大厂多选择自研或基于某个框架改造，小厂一般只能“东拼西凑”一些“半成品”凑合着使用，就这样微服务也走过了若干年。 Continue reading "ServiceMesh与Istio（一）"

Posted on

使用kubernetes PodPreset给Pod自动注入信息

参考官方介绍：

https://kubernetes.io/docs/concepts/workloads/pods/podpreset/

https://kubernetes.io/docs/tasks/inject-data-application/podpreset/

激活Pod Preset

Pod Preset目前还是alpha阶段，默认是没有激活的，所以需要通过以下步骤激活:

以阿里云的Kubernetes服务为例，阿里云的Kubernetes服务的master组件（API Server, Scheduler, Controller）都是通过Static Pod的方式用Kubelet启动，所以需要更改对应的yaml来激活Pod Preset:

编辑/etc/kubernetes/manifests/kube-apiserver.yaml，

  • 在 -runtime-config 增加 settings.k8s.io/v1alpha1=true
  • 在 --admission-control 增加  - PodPreset

保存后kubelet会自动重启kube-apiserver组件，我们需要同时更改3台机器的master才可以。

Posted on

修改Kafka Topic的分区副本数

说明

Kafka提供了一个工具，用于调整Topic中各个分区的复本数据。工具名称叫 kafka-reassign-partitions.sh 。

过程

创建一个Topic，共2个分区，副本数为2(共2份,含原始数据):

/opt/kafka/bin/kafka-topics.sh --zookeeper data01:2181,data02:2181,data03:2181/kafka --create --replication-factor 2 --partitions 2 --topic testTopic1

查看该Topic。分区0的Leader是1，分区1的Leader是2：

[root@data01 bin]# /opt/kafka/bin/kafka-topics.sh --describe --zookeeper data01:2181,data02:2181,data03:2181/kafka --topic testTopic1
Topic:testTopic1    PartitionCount:2    ReplicationFactor:2    Configs:
    Topic: testTopic1    Partition: 0    Leader: 1    Replicas: 1,2    Isr: 1,2
    Topic: testTopic1    Partition: 1    Leader: 2    Replicas: 2,3    Isr: 2,3
[root@data01 bin]#

准备一些数据，放在data.file中，然后将数据灌入Kakfa Topic：

/opt/kafka/bin/kafka-console-producer.sh --broker-list data01:9092,data02:9092,data03:9092 --topic testTopic1 < data.file

在各broker的数据目录下，可以看到当前对应的Topic分区目录：

[root@cheyo tmp]# dsh -g kafka -c "du -sh /opt/kafka/kafka-logs/testTopic*"
data01: 44K    /opt/kafka/kafka-logs/testTopic1-0
data02: 44K    /opt/kafka/kafka-logs/testTopic1-0
data02: 4.0K    /opt/kafka/kafka-logs/testTopic1-1
data03: 4.0K    /opt/kafka/kafka-logs/testTopic1-1
[root@cheyo tmp]#

调整副本数据的配置是以json文件描述的，然后json文件作为参数传递给相关工具。json文件中描述了各个分区的复本如何放置。这里，我们分别为testTopic1的两个分区在原来的基础上新增加了第3个分区。 Continue reading "修改Kafka Topic的分区副本数"