技术志

Kubernetes API Server是整个Kubernetes集群的核心，我们不仅有从集群外部访问API Server的需求，有时，我们还需要从Pod的内部访问API Server。 然而，在生产环境中，Kubernetes API Server都是“设防”的。在《Kubernetes集群的安全配置》一文中，我提到过：Kubernetes通过client cert、static token、basic auth等方法对客户端请求进行身份验证。对于运行于Pod中的Process而言，有些时候这些方法是适合的，但有些时候，像client cert、static token或basic auth这些信息是不便于暴露给Pod中的Process的。并且通过这些方法通过API Server验证后的请求是具有全部授权的，可以任意操作Kubernetes cluster，这显然是不能满足安全要求的。为此，Kubernetes更推荐大家使用service account这种方案的。本文就带大家详细说说如何通过service account从一个Pod中访问API Server的。 ...

Kubernetes集群搭建起来后，一直跑得很稳定。之前的关注点更多集中在安装、配置、组件调试方面，一些细枝末节被忽略了。Pod中时区的设置就是其中之一。今天腾出功夫打算解决一下这个问题。 一、问题现象 在我的Kubernetes 1.3.7集群的Master Node上，我们执行： # date Mon Feb 20 11:49:20 CST 2017 之后，在该Node上随意找到一个Pod中的Container，通过docker exec切入到容器内执行： ...

所有涉及到存储的地方都是极易出现“坑”的地方，Kubernetes也不例外。 一、问题起因 问题始于昨天升级一个stateful service的操作。该service下的Pod挂载了使用ceph RBD提供的一个Persistent Volume。该Pod是用普通deployment部署的，并没有使用处于alpha状态的PetSet。改动仅仅是image的版本发生了变化。我执行的操作如下： ...

在移动互联网时代，消费者的消费行为已经“全天候化”，为此，商家的业务系统也要保持7×24小时不间断地提供服务以满足消费者的需求。很难想像如今还会有以“中断业务”为前提的服务系统更新升级。如果微信官方发布公告说：每周六晚23:00~次日凌晨2:00进行例行系统升级，不能提供服务，作为用户的你会怎么想、怎么做呢？因此，各个平台在最初设计时就要考虑到服务的更新升级问题，部署在Kubernetes集群中的Service也不例外。 ...

首先，我不得不承认这篇文章有些标题党的味道^0^，但文章还是要继续写下去，备忘也好，能帮助到一些人也好。 在2016小结的时候，我说过：2017年要了解一些有关机器学习和人工智能(以下简称AI)方面的技术。如果有童鞋问：Why？我会告诉你：跟风。作为技术人，关注和紧跟业界最前沿的技术总是没错的。 2016年被业界普遍认为是AI这一波高速发展的元年，当然DeepMind的AlphaGo在这方面所起到的作用是功不可没的。不过人工智能并未仅仅停留在实验室，目前可以说人工智能已经深入到我们生活中的方方面面，比如：电商的精准个性化商品推荐、手机上安装的科大讯飞的中文语音识别引擎以及大名鼎鼎的Apple的siri等。只是普通老百姓并没有意识到这一点，或者说当前AI的存在和运行形式与大家传统思想中的“AI”还未到形似的地步，再或者当前AI的智能程度还未让人们感觉到AI时代的到来。 ...

在已经过去的2016年，Go语言继在2009年之后再次成为编程语言界的明星- 问鼎TIOBE 2016年度语言。这与Go team、Go community和全世界的Gophers的努力是分不开的。按计划在这个2月份，Go team将正式发布Go 1.8版本(截至目前，Go的最新版本是Go 1.8rc3)。在这里我们一起来看一下在Go 1.8版本中都有哪些值得Gopher们关注的变化。 ...

当前手上有两个Kubernetes cluster，一个是采用kube-up.sh安装的k8s 1.3.7版本，另外一个则是采用kubeadm安装的k8s 1.5.1版本。由于1.3.7版本安装在前，并且目前它也是承载了我们PaaS平台的环境，因此对于这个版本的Kubernetes安装环境、配置操作、日志查看、集群操作等相对较为熟悉。而Kubeadm安装的1.5.1版本K8s集群在组件部署、配置、日志等诸多方面与1.3.7版本有了较大差异。刚上手的时候，你会发现你原来所熟知的1.3.7的东西都不在原先的位置上了。估计很多和我一样，采用kubeadm将集群升级到1.5.1版本的朋友们都会遇到这类问题，于是这里打算对Kubeadm方式安装的Kubernetes集群进行一些小小的探索，把一些变动较大的点列出来，供大家参考。 一、环境 这里使用的依然是文章《使用Kubeadm安装Kubernetes》中安装完毕的Kubernetes 1.5.1集群环境，底层是阿里云ECS，操作系统是Ubuntu 16.04.1。网络用的是weave network。 ...

默认安装后的Kubernetes dashboard如下图所示，是无法图形化展现集群度量指标信息的： 图形化展示度量指标的实现需要集成k8s的另外一个Addons组件：Heapster。 Heapster原生支持K8s(v1.0.6及以后版本)和CoreOS，并且支持多种存储后端，比如：InfluxDB、ElasticSearch、Kafka等，这个风格和k8s的确很像：功能先不管完善与否，先让自己在各个平台能用起来再说^0^。这里我们使用的数据存储后端是InfluxDB。 ...

第一次利用kube-up.sh脚本方式安装Kubernetes 1.3.7集群时，我就已经顺利地将kubernetes dashboard addon安装ok了。至今在这个环境下运行十分稳定。但是毕竟是一个试验环境，有些配置是无法满足生产环境要求的，比如：安全问题。今天有时间对Dashboard的配置进行一些调整，顺带将之前Dashboard插件的安装和配置过程也记录下来，供大家参考。 ...

第一次采用kube-up.sh脚本方式安装的Kubernetes cluster目前运行良好，master node上的组件状态也始终是“没毛病”： # kubectl get cs NAME STATUS MESSAGE ERROR controller-manager Healthy ok scheduler Healthy ok etcd-0 Healthy {"health": "true"} 不过在第二次尝试用kubeadm安装和初始化Kubernetes cluster时遇到的各种网络问题还是让我“心有余悸”。于是趁上个周末，对Kubernetes的网络原理进行了一些针对性的学习。这里把对Kubernetes网络的理解记录一下和大家一起分享。 ...