A box of chocolate

使用kubernetes/cluster/kube-up.sh脚本在装有Ubuntu操作系统的bare metal上搭建的Kubernetes集群并不安全，甚至可以说是“完全不设防的”，这是因为Kubernetes集群的核心组件：kube-apiserver启用了insecure-port。insecure-port背后的api server默认完全信任访问该端口的流量，内部无任何安全机制。并且监听insecure-port的api server bind的insecure-address为0.0.0.0。也就是说任何内外部请求，都可以通过insecure-port端口任意操作Kubernetes集群。我们的平台虽小，但“裸奔”的k8s集群也并不是我们想看到的，适当的安全配置是需要的。 在本文中，我将和大家一起学习一下Kubernetes提供的安全机制，并通过安全配置调整，实现K8s集群的“有限”安全。 一、集群现状 我们先来“回顾”一下集群现状，为后续配置调整提供一个可回溯和可比对的“基线”。 1、Nodes 集群基本信息： # kubectl cluster-info Kubernetes master is running at http://10.47.136.60:8080 KubeDNS is running at http://10.47.136.60:8080/api/v1/proxy/namespaces/kube-system/services/kube-dns To...

话接上文，在《使用go-ceph管理Ceph RBD映像》一文中我们提到了，我们需要自建一个ceph rbd api service用于给我的产品控制台提供RESTful API服务接口。这个服务我也是打算放在kubernetes集群中作为一个Service运行的。这两天完成了这个服务开发，并编写完Service的Dockerfile，将镜像build, tag并push到了我们在阿里云的私有镜像库。但在通过kubectl创建这个Service时，我们遇到了 ErrImagePull、ImagePullBackOff等Pod status，通过kubectl describe pod/{MyPod}命令查看，发现下面错误提示： 23s 5s 2 {kubelet 10.57.136.60} spec.containers{rbd-rest-api} Warning Failed Failed to pull image "registry.cn-hangzhou.aliyuncs.com/xxxx/rbd-rest-api:latest": image...

此文为《使用Kubeadm安装Kubernetes》的第二部分。文章第一部分在这里可以看到。 五、weave network for pod 经过上面那么多次尝试，结果是令人扫兴的。Weave network似乎是最后一颗救命稻草了。有了前面的铺垫，这里就不详细列出各种命令的输出细节了。Weave network也有专门的官方文档用于指导如何与kubernetes集群集成，我们主要也是参考它。 1、安装weave network add-on 在kubeadm reset后，我们重新初始化了集群。接下来我们安装weave network add-on： # kubectl apply -f https://git.io/weave-kube daemonset "weave-net" created 前面无论是Flannel还是calico，在安装pod network...

http://tonybai.com/2016/12/27/when-docker-meets-systemd/ 近期在做Kubernetes集群的升级的相关试验，即从原先的K8s 1.3.7版本升级到最新的K8s 1.5.1版本。k8s自1.4版本开始引入kubeadm，试图简化K8s的安装和使用门槛，提升开发者体验。但kubeadm仅支持16.04及以上的Ubuntu版本，于是我们在升级K8s集群前会遇到另外一个问题：Ubuntu 16.04已经由Upstart初始化系统换成了systemd初始化系统，Ubuntu 16.04上的Docker engine的使用和配置方法与以前在Ubuntu 14.04上将有所不同。Docker是K8s支持的容器引擎之一，也是目前最主流的容器引擎，弄清楚Docker的配置和使用也是后续用好K8s的前提之一。于是这里打算记录一下Docker与Systemd是如何相生共存的^0^。 一、Ubuntu 16.04安装Docker Aliyun目前上没有提供官方Ubuntu 16.04 ECS，最高仅支持到Ubuntu 14.04.4。因此在Aliyun ECS上用16.04需要手工upgrade到16.04（不过建议在upgrade前做个snapshot，一旦upgrade失败，好恢复）。升级后的Ubuntu环境信息如下： Ubuntu 16.04.1 LTS (GNU/Linux 4.4.0-58-generic x86_64) kubeadm文档中认为Docker 1.11.2版本与之更配哟，不过对于更新的版本似乎配合起来也没有什么大问题。我们这里安装目前可以找到的最新stable release: docker...

http://tonybai.com/2016/10/18/learn-how-to-install-kubernetes-on-ubuntu/   由于之前在阿里云上部署的Docker 1.12.2的Swarm集群没能正常展示出其所宣称的Routing mesh和VIP等功能，为了满足项目需要，我们只能转向另外一种容器集群管理和服务编排工具Kubernetes。 注：之前Docker1.12集群的Routing mesh和VIP功能失效的问题，经过在github上与Docker开发人员的沟通，目前已经将问题原因缩小在阿里云的网络上面，目前看是用于承载vxlan数据通信的节点4789 UDP端口不通的问题，针对这个问题，我正在通过阿里云售后工程师做进一步沟通，希望能找出真因。 Kubernetes(以下称k8s)是Google开源的一款容器集群管理工具，是Google内部工具Borg的“开源版”。背靠Google这个高大上的亲爹，k8s一出生就吸引了足够的眼球，并得到了诸多知名IT公司的支持。至于Google开源k8s的初衷，美好的说法是Google希望通过输出自己在容器领域长达10多年的丰富经验，帮助容器领域的开发人员和客户提升开发效率和容器管理的档次。但任何一种公司行为都会有其背后的短期或长期的商业目的，Google作为一个商业公司也不会例外。Google推出k8s到底为啥呢？众说纷纭。一种说法是Google通过k8s输出其容器工具的操作和使用方法、API标准等，为全世界的开发人员使用其公有容器预热并提供“零门槛”体验。 k8s目前是公认的最先进的容器集群管理工具，在1.0版本发布后，k8s的发展速度更加迅猛，并且得到了容器生态圈厂商的全力支持，这包括coreos、rancher等，诸多提供公有云服务的厂商在提供容器服务时也都基于k8s做二次开发来提供基础设施层的支撑，比如华为。可以说k8s也是Docker进军容器集群管理和服务编排领域最为强劲的竞争对手。 不过和已经原生集成了集群管理工具swarmkit的Docker相比，k8s在文档、安装和集群管理方面的体验还有很大的提升空间。k8s最新发布的1.4版本就是一个着重在这些方面进行改善的版本。比如1.4版本对于Linux主要发行版本Ubuntu Xenial和Red Hat centos7的用户，可以使用熟悉的apt-get和yum来直接安装Kubernetes。再比如，1.4版本引入了kubeadm命令，将集群启动简化为两条命令，不需要再使用复杂的kube-up脚本。 但对于1.4版本以前的1.3.x版本来说，安装起来的赶脚用最近流行的网络词汇来形容就是“蓝瘦，香菇”，但有些时候我们还不得不去挑战这个过程，本文要带大家了解的就是利用阿里云国内区的ECS主机，在Ubuntu 14.04.4操作系统上安装k8s 1.3.7版本的方法和安装过程。 零、心理建设 由于k8s是Google出品，很多组件与google是“打断了骨头还连着筋”，因此在国内网络中安装k8s是需要先进行心理建设的^_^，因为和文档中宣称的k8s 1.4版的安装或docker 1.12.x的安装相比，k8s 1.3.7版本的安装简直就是“灾难级”的。 要想让这一过程适当顺利一些，我们必须准备一个“加速器（你懂的）”。利用加速器应对三件事：慢、断和无法连接。 慢：国内从github或其他国外公有云上下东西简直太慢了，稍大一些的文件，通常都是几个小时或是10几个小时。 断：你说慢就算了，还总断。断了之后，遇到不支持断点续传的，一切还得重来。动不动就上G的文件，重来的时间成本是我们无法承受的。...

Project Harbor is an enterprise-class registry server, which extends the open source Docker Registry server by adding the functionality usually required by an enterprise, such...

Introduction SSH, or secure shell, is a secure protocol and the most common way of safely administering remote servers. Using a number of encryption technologies,...

步骤: 1.第一步需要安装PPTP，以用来提供VPN服务. sudo apt-get install pptpd 如果有问题的话比如提示找不到之类的，apt-get update 一下应该就可以了，然后再来一次就会自动完成安装。 2.装好了之后我们需要进行配置一下以让它可以使用. sudo vi /etc/pptpd.conf 取消掉以下 2 行的注释并修改为自己设置的vpn网段： localip 219.224.167.201 remoteip 192.168.150.234-238 分别是通过VPN连接后主机和客户端所使用的IP，可以自行修改。注意这个IP在下面还会用的到。 3.然后我们需要分配账号给自己使用. sudo vi /etc/ppp/chap-secrets...

Editor’s note: Today’s post is by the Infrastructure Platform Department team at JD.com about their transition from OpenStack to Kubernetes. JD.com is one of China’s...

背景介绍 2016年底，京东新一代容器引擎平台JDOS2.0上线，京东从OpenStack切换到Kubernetes。到目前为止，JDOS2.0集群2w+Pod稳定运行，业务按IDC分布分批迁移到新平台，目前已迁移20%，计划Q2全部切换到Kubernetes上，业务研发人员逐渐适应从基于自动部署上线切换到以镜像为中心的上线方式。JDOS2.0统一提供京东业务，大数据实时离线，机器学习（GPU）计算集群。从OpenStack切换到Kubernetes，这中间又有哪些经验值得借鉴呢？ 本文将为读者介绍京东商城研发基础平台部如何从0到JDOS1.0再到JDOS2.0的发展历程和经验总结，主要包括： 如何找准痛点作为基础平台系统业务切入点； 如何一边实践一边保持技术视野； 如何运维大规模容器平台； 如何把容器技术与软件定义数据中心结合。 集群建设历史 物理机时代（2004-2014） 在2014年之前，公司的应用直接部署在物理机上。在物理机时代，应用上线从申请资源到最终分配物理机时间平均为一周。应用混合部署在一起，没有隔离的应用混部难免互相影响。为减少负面影响，在混部的比例平均每台物理机低于9个不同应用的Tomcat实例，因此造成了物理机资源浪费严重，而且调度极不灵活。物理机失效导致的应用实例迁移时间以小时计，自动化的弹性伸缩也难于实现。为提升应用部署效率，公司开发了诸如编译打包、自动部署、日志收集、资源监控等多个配套工具系统。 容器化时代（2014-2016） 2014年第三季度，公司首席架构师刘海锋带领基础平台团队对于集群建设进行重新设计规划，Docker容器是主要的选型方案。当时Docker虽然已经逐渐兴起，但是功能略显单薄，而且缺乏生产环境，特别是大规模生产环境的实践。团队对于Docker进行了反复测试，特别是进行了大规模长时间的压力和稳定性测试。根据测试结果，对于Docker进行了定制开发，修复了Device Mapper导致crash、Linux内核等问题，并增加了外挂盘限速、容量管理、镜像构建层级合并等功能。 对于容器的集群管理，团队选择了OpenStack＋nova-docker的架构，用管理虚拟机的方式管理容器，并定义为京东第一代容器引擎平台JDOS1.0（JD DataCenter OS）。JDOS1.0的主要工作是实现了基础设施容器化，应用上线统一使用容器代替原来的物理机。在应用的运维方面，兼用了之前的配套工具系统。研发上线申请计算资源由之前的一周缩短到分钟级，不管是1台容器还是1千台容器，在经过计算资源池化后可实现秒级供应。同时，应用容器之间的资源使用也得到了有效的隔离，平均部署应用密度提升3倍，物理机使用率提升3倍，带来极大的经济收益。 我们采用多IDC部署方式，使用统一的全局API开放对接到上线系统，支撑业务跨IDC部署。单个OpenStack集群最大是1万台物理计算节点，最小是4K台计算节点，第一代容器引擎平台成功地支撑了2015和2016年的618和双十一的促销活动。至2016年11月，已经有15W+的容器在稳定运行。 在完成的第一代容器引擎落地实践中，团队推动了业务从物理机上迁移到容器中来。在JDOS1.0中，我们使用的IaaS的方式，即使用管理虚拟机的方式来管理容器，因此应用的部署仍然严重依赖于物理机时代的编译打包、自动部署等工具系统。但是JDOS1.0的实践是非常有意义的，其意义在于完成了业务应用的容器化，将容器的网络、存储都逐渐磨合成熟，而这些都为我们后面基于1.0的经验，开发一个全新的应用容器引擎打下了坚实的基础。 新一代应用容器引擎（JDOS 2.0） 1.0的痛点 JDOS1.0解决了应用容器化的问题，但是依然存在很多不足。 首先是编译打包、自动部署等工具脱胎于物理机时代，与容器的开箱即用理念格格不入，容器启动之后仍然需要配套工具系统为其分发配置、部署应用等等，应用启动的速度受到了制约。 其次，线上线下环境仍然存在不一致的情况，应用运行的操作环境，依赖的软件栈在线下自测时仍然需要进行单独搭建。线上线下环境不一致也造成了一些线上问题难于在线下复现，更无法达到镜像的“一次构建，随处运行”的理想状态。 再次，容器的体量太重，应用需要依赖工具系统进行部署，导致业务的迁移仍然需要工具系统人工运维去实现，难以在通用的平台层实现灵活的扩容缩容与高可用。...