千呼万唤始出来?Go 1.25解决Git仓库子目录作为模块根路径难题
千呼万唤始出来?Go 1.25解决Git仓库子目录作为模块根路径难题 - Tony Bai =============== Tony Bai 一个程序员的心路历程 Google Go语言编码风格规范 ...
千呼万唤始出来?Go 1.25解决Git仓库子目录作为模块根路径难题 - Tony Bai =============== Tony Bai 一个程序员的心路历程 Google Go语言编码风格规范 ...
Go项目该拥抱Monorepo吗?Google经验、etcd模式及白盒交付场景下的深度剖析 - Tony Bai =============== Tony Bai 一个程序员的心路历程 Google Go语言编码风格规范 ...
近期learnk8s网站上发布了一些关于k8s的好文章,这里搬运并翻译了一些,供大家参考。 本文翻译自《Architecting Kubernetes clusters — choosing a worker node size》。 当您创建Kubernetes集群时,冒出的第一个问题之一是:“我应该使用哪种类型的工作节点以及需要多少个这样的节点”。 如果您正在构建在内部部署的k8s集群,是应该订购一些最近一代的新服务器,还是使用数据中心内的十几台旧机器? 或者,如果您使用Google Kubernetes Engine(GKE)等托管Kubernetes服务,您是否应该使用八个n1-standard-1或两个n1-standard-4实例来实现所需的计算能力呢? ...
距离我的第一门网课《Kubernetes基础:开启云原生之门》上线已经过去5个多月了,我的实战课《Kubernetes实战:高可用集群搭建、配置、运维与应用》终于在9月27日正式上线了。 一. 课程介绍 《Kubernetes实战:高可用集群搭建、配置、运维与应用》的课程内容与最初课程设计时规划的内容大纲没有太多出入,基本就是根据我最初的想法拟定的内容,这也基本是我这两年学习k8s、积累的k8s实践的路线。整个课程基于kubernetes 1.10.2版本(docker 17.03.2ce)。课程内容大致分为七个部分(与课程主页的课程目录结构稍有差异,但课程内容是一致的): ...
ROS,全称是Robot Operating System,字面译为“机器人操作系统”。不过ROS并非是一个真正意义上的操作系统,而仅仅是一套用于机器人操作和控制软件开发的开发框架(framework),包括各种库和工具。 ROS在2007年诞生于斯坦福大学的人工智能实验室Stanford Artificial Intelligence Laboratory,简称SAIL;2008年至2013年,ROS的开发和推广由Willow Garage公司(该公司2014年已关门大吉)主导。2013年8月,ROS的管理权转移给了Open Source Robotics Foundation。截至目前,ROS已经成为全世界使用和支持最为广泛的机器人开发框架之一。 ...
续接上文。 五、第三步:启动emei、wudang上的apiserver 跨三个node的etcd cluster已经建成并完成了数据同步,下面进行ha cluster改造的重要一步:启动wudang、emei上的apiserver ...
Kubernetes集群的核心是其master node,但目前默认情况下master node只有一个,一旦master node出现问题,Kubernetes集群将陷入“瘫痪”,对集群的管理、Pod的调度等均将无法实施,即便此时某些用户的Pod依旧可以正常运行。这显然不能符合我们对于运行于生产环境下的Kubernetes集群的要求,我们需要一个高可用的Kubernetes集群。 不过,目前Kubernetes官方针对构建高可用(high-availability)的集群的支持还是非常有限的,只是针对少数cloud-provider提供了粗糙的部署方法,比如:使用kube-up.sh脚本在GCE上、使用kops在AWS上等等。 高可用Kubernetes集群是Kubernetes演进的必然方向,官方在“Building High-Availability Clusters”一文中给出了当前搭建HA cluster的粗略思路。Kubeadm也将HA列入了后续版本的里程碑计划,并且已经出了一版使用kubeadm部署高可用cluster的方法提议草案。 ...
除了在生产环境使用的Kubernetes 1.3.7集群之外,我这里还有一套1.5.1的Kubernetes测试环境,这个测试环境一来用于验证各种技术方案,二来也是为了跟踪Kubernetes的最新进展。本篇要记录的一个异常就是发生在该测试Kubernetes集群中的。 一、缘起 前两天我在Kubernetes测试环境搭建一套Ceph,为了便于ceph-deploy的安装,我通过hostnamectl命令将阿里云默认提供的复杂又冗长的主机名改为短小且更有意义的主机名: iZ25beglnhtZ -> yypdmaster iz2ze39jeyizepdxhwqci6z -> yypdnode 以yypdmaster为例,修改过程如下: # hostnamectl --static set-hostname yypdmaster # hostnamectl status Static hostname: yypdmaster Transient hostname: iZ25beglnhtZ Icon name: computer-vm Chassis: vm Machine ID: 91aa4b8f2556de49e743dc2f53e8a5c4 Boot ID: 5d0e642ebafa460086388da4177e488e Virtualization: kvm Operating System: Ubuntu 16.04.1 LTS Kernel: Linux 4.4.0-58-generic Architecture: x86-64 # cat /etc/hostname yypdmaster hostnamectl并未修改/etc/hosts,我手动在/etc/hosts中将yypdmaster对应的ip配置上: xx.xx.xx.xx yypdmaster 重新登录后,我们看到主机名状态:Transient hostname不见了,只剩下了静态主机名: ...
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 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。 ...