K8s 开船记-全站登船:Powered by .NET Core on Kubernetes

今天 18:30 左右,我们迈出了 kubernetes 航行的关键一步——全站登船,完成了全站应用部署从 docker swarm 集群向 k8s 集群的切换,以前所未有的决心与信心重新开起这艘巨轮,而这次航行能否成功就看明天访问高峰时狂风巨浪下的表现。

部署在 k8s 上的应用会在页脚显示下面的信息,如果航行失败,"Kubernetes" 会变成 "Linux" 。

Powered by .NET Core on Kubernetes

Kubernetes 集群部署情况如下。

用了3台2核4G阿里云服务器作为 master 搭建了高可用集群,worker 节点目前用了12台4核8G阿里云服务器,明天根据负载情况看是否需要加服务器。

Kuberneres 网络插件使用的是 calico 。

DNS 服务器使用的是 coredns ,由于之前遭遇过因为 dns  解析问题造成翻船,这次部署了 nodelocaldns 在每个节点进行本机 dns 缓存(相关博文)。

Ingress Controller 使用的是 kubernetes 社区维护的 kubernetes/ingress-nginx,还有一个 nginx 公司与社区共同维护的 nginxinc/kubernetes-ingress,我们推荐使用前者(相关博文)。

博客站点的部署采用了 HPA(Horizontal Pod Autoscaler) ,基于 CPU 与 QPS 监控指标进行自动伸缩,监控指标数据来自 prometheus (相关博文)。

部署工具用的是 helm ,helm 强大的模板引擎让我们可以用一个模板搞定 90% 以上应用的部署。

目前一共部署了 115 个应用 pod ,56 个应用 service 。

原文地址:https://www.cnblogs.com/cmt/p/12353192.html

时间: 2024-10-10 21:36:41

K8s 开船记-全站登船:Powered by .NET Core on Kubernetes的相关文章

k8s 开船记-触礁:四涡轮发动机撞坏3个引发502故障

(图片来自网络) 非常抱歉,这次开船触礁故障给您带来麻烦了,请您谅解. 在我们昨天发布 k8s 开船记首航博文后,有园友在评论中发来贺词——“泰坦尼克号出发了[狗头]”,借此吉言,今天船就触礁了,还好不是冰山.在触礁后,我们收到了唯一一封贺电,贺电署名——“隔壁正在打酱油的 docker swarm 集群”. 触礁时间发生在今天上午 10:18~10:30 左右,当时航行用的是四涡轮发动机(4个nodes). 10:18 左右开始,3与4号发动机(k8s-n3与k8s-n4节点)被撞坏熄火,重新

k8s 开船记:升级为豪华邮轮(高可用集群)与遇到奇怪故障(dns解析异常)

之前我们搭建的 k8s 集群只用了1台 master ,可用性不高,这两天开始搭建高可用集群,但由于之前用 kubeadm 命令创建集群时没有使用 --control-plane-endpoint 参数,无法直接升级现有集群,只能重新创建高可用(High-Availability)集群. 高可用集群的原理很简单,多台 master ,每台都保存集群数据(etcd),所有 nodes 通过专门搭建的负载均衡访问 api server ,这样当部分 master 宕机时,对集群正常运行无影响. 我们

k8s 开船记-首航:博客站点从 docker swarm 切换到 k8s

昨天晚上,我们将博客站点的生产环境从 docker swarm 集群切换到了 k8s 集群,开船到目前,航行非常平稳,可以说首航成功! k8s 集群是我们用10台阿里云服务器自己搭建的,1台 master 配置是2核4G,9台 nodes 配置都是4核8G,kubernetes 版本是 1.16.3 . 博客站点请求入口没有走 ingress ,直接通过 service 监听 30080 端口,阿里云负载均衡转发请求到该端口. apiVersion: v1 kind: Service metad

k8s 开船记-修船:改 readinessProbe ,去 DaemonSet ,上 ??Autoscaler

(图片来自网络) 改 readinessProbe 对于昨天 k8s 尼克号发生的触礁事故,我们分析下来主要是2个原因,一是当时4个节点不够用造成部分容器负载过高而宕机,二是 readinessProbe 健康检查配置不合理,造成重启后的容器无法通过健康检查. skipping: failed to "StartContainer" for "blog-web" with CrashLoopBackOff. CrashLoopBackOff 是指容器“启动 ->

豌豆荚登船测试挺有意思~~

今天玩了下豌豆荚的登船测试,还是蛮有意思滴哒~~ 总结啦下就是调试工具的熟练使用啦 进入测试: 第一关: 看了下页面没有任何点击的地方就打开了调试工具,找了下elements,很轻松的找到哒 点击链接进入第二关 第二关: 第二关的密码也是藏在elements中啦,就是密码有点长,刚开始自己输的还输错了,导致落水哒~~(>_<)~~,复制粘贴哒下好啦 输入密码进入第三关 第三关: 第三关的稍微比较难找哒,不过仔细点就找到啦 将后面的step4到后面的输入浏览器即可进入第四关 第四关: 第四关很简

K8S 1.12大特性最快最深度解析:Kubernetes CSI Snapshot(上)

? 背景 许多存储系统提供了创建存储卷“快照”(snapshot)的能力,以防止数据丢失.快照可以替代传统的备份系统来备份和还原主要数据和关键数据.快照能够快速备份数据(例如,创建GCE PD快照仅需要几分之一秒), 并提供快速恢复时间目标(RTO)和恢复点目标(RPO).快照还可用于数据复制.分发和迁移. 早在kubernetes 1.8版本中,卷快照系统原型已经发布,其实现位于external-storage(https://github.com/kubernetes-incubator/e

行车记+翻车记:.NET Core 新车改造,C# 节能降耗,docker swarm 重回赛道

非常抱歉,10:00~10:30 左右博客站点出现故障,给您带来麻烦了,请您谅解. 故障原因与博文中谈到的部署变更有关,但背后的问题变得非常复杂,复杂到我们都在怀疑与阿里云服务器 CPU 特性有关. 这篇博文本来准备 9:30 左右发布的,但发布博文时出现了 docker swarm 部署异常情况,切换到 docker-compose 部署后问题依旧,一直到 10:30 左右才恢复正常,继续发布这篇博文,在标题中加上了“翻车记”. 原先的博文正文开始: 周一向大家汇报车况之后,我们的 .NET

大海航行靠舵手 华为云靠什么征服K8S?

Kubernetes是Google开源的容器集群管理系统或者称为分布式操作系统.它构建在Docker技术之上,为容器化的应用提供资源调度.部署运行.服务发现.扩容缩容等整一套功能,本质上可看作是基于容器技术的mini-PaaS平台.Kubernetes的目标是让开发者可以像管理产品一样管理服务,同时提高资源的利用率,让开发者更关注在应用开发本身,高可用的事情交给Kubernetes. 实际上,Kubernetes的英文原意是指用来操纵和控制船舶航向的船舵,这也是为什么Kubernetes的Log

K8s基于DNS的服务发现(转)

原文地址:https://www.oschina.net/question/2657833_2201246 1.Kubernetes中如何发现服务 ◆   发现Pod提供的服务 首先使用nginx-deployment.yaml文件创建一个Nginx Deployment,文件内容如图所示: 首先创建两个运行Nginx服务的Pod: 使用kubectl create -f nginx-deployment.yaml指令创建,这样便可以得到两个运行nginx服务的Pod.待Pod运行之后查看一下它