Shadowsocks Server And Client

Server

其中 config.json的配置如下:

Client

其中 config.json的配置如下:

 

Kubernetes: Killing container with id docker://xxxx: Need to kill Pod问题

当前Kubernetes版本 v1.9.7,当delete pod失败时,使用kubectl describe后发现这个pod有以下events信息:

这个问题是Kubernetes偶发的BUG,使用以下命令强制删除:

执行时会提示风险:

 

 

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

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

 

其中,在 resolv.conf 中的配置文件内容如下:

随后重启  coredns pod即可。

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

Linux 下 shadowsocks + polipo 客户端全局代理

shadowsocks

建立配置文件,例:服务器地址为 xxxx.com,端口号 52239,密码 SOME_PASSWORD,保存到 ~/shadowsocks.json Continue reading “Linux 下 shadowsocks + polipo 客户端全局代理”

ServiceMesh与Istio(一)

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

微服务的“痛点”

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

  • 服务注册与发现

  • 身份验证与授权

  • 服务的伸缩控制

  • 反向代理与负载均衡

  • 路由控制

  • 流量切换

  • 日志管理

  • 性能度量、监控与调优

  • 分布式跟踪

  • 过载保护

  • 服务降级

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

  • 错误处理

  • ……

 

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

使用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才可以。

修改Kafka Topic的分区副本数

说明

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

过程

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

查看该Topic。分区0的Leader是1,分区1的Leader是2:

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

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

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

Go继承的属性修改示例

执行后,输出结果为: