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的分区副本数”

JWT简介

JWT是一种用于双方之间传递安全信息的简洁的、URL安全的表述性声明规范。JWT作为一个开放的标准(RFC 7519),定义了一种简洁的,自包含的方法用于通信双方之间以Json对象的形式安全的传递信息。因为数字签名的存在,这些信息是可信的,JWT可以使用HMAC算法或者是RSA的公私秘钥对进行签名。简洁(Compact): 可以通过URL,POST参数或者在HTTP header发送,因为数据量小,传输速度也很快
自包含(Self-contained):负载中包含了所有用户所需要的信息,避免了多次查询数据库。

Continue reading “JWT简介”

etcd: 从应用场景到实现原理的全方位解读

随着CoreOS和Kubernetes等项目在开源社区日益火热,它们项目中都用到的etcd组件作为一个高可用强一致性的服务发现存储仓库,渐渐为开发人员所关注。在云计算时代,如何让服务快速透明地接入到计算集群中,如何让共享配置信息快速被集群中的所有机器发现,更为重要的是,如何构建这样一套高可用、安全、易于部署以及响应快速的服务集群,已经成为了迫切需要解决的问题。etcd为解决这类问题带来了福音,本文将从etcd的应用场景开始,深入解读etcd的实现方式,以供开发者们更为充分地享用etcd所带来的便利。 Continue reading “etcd: 从应用场景到实现原理的全方位解读”