在Dockone在线分享二三一期中，我分享了如何使用KT Connect实现本地与Kubernetes集群内服务的双向联调，以实现面向Kubernetes的高效的本地开发测试体验。之后我们继续迭代了10+小版本后为KT Connect带来了一些新的变化。
Windows环境下如何在本地IDEA中联调Kubernetes集群中的服务
本地将介绍如何在Idea中使用KT Connect: https://github.com/alibaba/kt-connect 项目实现本地与集群中服务的联调开发
Kubernetes服务发现之ClusterIP
在《Flannel网络以及在阿里云下的实现解析》中说过在Kubernetes中网络中，主要包含两种IP，分别是Pod IP和Cluster IP。 Pod IP是实际存在于网卡之上（如VETH的虚拟网卡），而Cluster IP则是一个虚拟的IP地址，该虚拟机IP由kube-proxy进行维护，kube-proxy目前提供了两种实现方式，包括默认的ip tables实现以及在K8S 1.8之后开始支持的ipvs实现。文章中以阿里云Kubernetes集群为例，从Pod IP的角度介绍了Pod和Pod之间是如何通讯的。这篇文章，笔者将解释基于ClusterIP的服务发现是个什么鬼。
使用Helm优化Kubernetes下的研发体验：实现持续交付流水线
接着上一篇《使用Helm优化Kubernetes下的研发体验：基础设施即代码》中笔者介绍了如何在项目中使用Helm，在项目源码中，我们通过Dockerfile定义了项目是如何构建的，使用Helm定义了项目是如何部署的。 团队中的任何人员(角色）在获取源码的同时就已经具备了一键构建，一键部署的能力。
使用Helm优化Kubernetes下的研发体验：基础设施即代码
容器即进程，Kubernetes则解决了如何部署和运行应用的问题。对于任何一个部署在Kubernetes得应用而言，通常都可以由几个固定的部分组成：Ingress,Service,Deployment等。直接使用Kubernetes原生的YAML定义服务，虽然能一定程度上简化应用的部署，但是对于大部分研发人员来说编写和使用YAML依然是一件相对痛苦的事情。HELM应允而生，Helm作为Kubernetes下的包管理工具，对原生服务定义过程进行了增强，通过模板化，参数化的形式大大简化用户部署Kubernetes应用的复杂度。
在本文中笔者，将以一个Spring Boot程序为例，介绍如何在软件研发端到端过程中是使用Helm。本文中所使用的示例代码可以通过Github下载。
Flannel网络以及在阿里云下的实现解析
在Kubernetes中网络中，主要包含两种IP，分别是Pod IP和Cluster IP。 Pod IP是实际存在于网卡之上（如VETH的虚拟网卡），而Cluster IP则是一个虚拟的IP地址，该虚拟机IP由kube-proxy进行维护，kube-proxy目前提供了两种实现方式，包括默认的ip tables实现以及在K8S 1.8之后开始支持的ipvs实现。
Tips:解决Consul中服务实例重复注册的问题
为了提升系统核心服务的问题性，避免由于K8S网络导致服务间调用的稳定性。目前将系统核心服务的部署方式从Pod Network切换到了Host Network。 Host Network限制了Pod的部署数量，最大情况下只能和主机数量保持一致。因此需要在Deployment中设置一些反亲和性的调度策略。 确保Pod不会被反复注册到相同主机上。
监控MySQL运行状态
MySQL是一个关系型数据库管理系统，由瑞典MySQL AB公司开发，目前属于Oracle旗下的产品。 MySQL是最流行的关系型数据库管理系统之一。数据库的稳定运行时保证业务可用性的关键因素之一。这一小节当中将介绍如何使用Prometheus提供的MySQLD Exporter实现对MySQL数据库性能以及资源利用率的监控和度量。