k8s

感谢分享原文- http://bjbsair.com/2020-04-03/tech-info/29914.html Kubeedge除了在kubernetes的方面做了各种异步通信通道，保障offline后的业务连续性之外；还定义了一系列的设备抽象，用来管理边缘设备。而且，其v1.0版本正朝着边缘端服务网格，以及函数式计算等方向发展。 官方文档： https://docs.kubeedge.io/en/latest/ 架构 整体架构图比较明了，在不考虑edgesite的情况下，其架构分为了云端和边缘端。其实可以理解为kubernetes的管理侧和kubelet节点侧（对应edge端）。但是请注意，这里的场景是边缘计算，意味着edge端的网络环境难以保障。 云边通信 于是就衍生出了cloud端的cloud Hub与edge端的Edge Hub。这两个模块之间通过websocket或者quic通信，相当于建立了一条底层通信隧道，供k8s和其他应用通信。当然，使用什么协议通信不是重点，重点是如何保障当着之间的链路都无法保障的时候，业务不受到影响，这就是MetaManager的要解决的问题了。 CloudHub 前面提到cloud端的cloudHub就是一个隧道的server端，用于大量的edge端基于websocket或者quic协议连接上来；没错，这货才是正儿八经的二传手

目录 之前手动部署一个镜像到k8s集群中，发现一些配置出错了，导致pod一直在不停的重启，下面记录强制删除pod的命令 先说下网上大部分强制删除操作吧，我试了好几次不管用，尴尬 kubectl delete pod -n namespace podname --force --grace-period=0 言归正传，记录下强制删除pod的命令 当你的pod是通过deployment来创建的，可以这样删除 kubectl delete deployments.apps -n namespace podname 当你是直接通过rc来部署时（也是我自己这样部署的）,编辑rc，将启动数量改为0，那么你的pod就会被删掉了 kubectl edit replicationcontroller podname -n namespace 来源： https://www.cnblogs.com/levcon/p/12655586.html

作者 | 贾之光 阿里巴巴高级开发工程师 本文整理自《CNCF x Alibaba 云原生技术公开课》第 30 讲， 点击直达课程页面 。 关注“阿里巴巴云原生”公众号，回复关键词**“入门”**，即可下载从零入门 K8s 系列文章 PPT。 一、RuntimeClass 需求来源 容器运行时的演进过程 我们首先了解一下容器运行时的演进过程，整个过程大致分为三个阶段： 第一个阶段：2014 年 6 月 Kubernetes 正式开源，Docker 是当时唯一的、也是默认的容器运行时； 第二个阶段：Kubernetes v1.3 rkt 合入 Kubernetes 主干，成为了第二个容器运行时。 第三个阶段：Kubernetes v.15 与此同时，越来越多的容器运行时也想接入到 Kubernetes 中。如果还是按 rkt 和 Docker 一样内置支持的话，会给 Kubernetes 的代码维护和质量保障带来严重挑战。 社区也意识到了这一点，所以在 1.5 版本时推出了 CRI，它的全称是 Container Runtime Interface。这样做的好处是：实现了运行时和 Kubernetes 的解耦，社区不必再为各种运行时做适配工作，也不用担心运行时和 Kubernetes 迭代周期不一致所带来的版本维护问题。比较典型的，比如 containerd 中的 cri

Kubernetes自从 1.6 起便号称可以承载5000个以上的节点，但是从数十到5000的路上，难免会遇到问题。 本片文章即分享Open API在kubernetes 5000之路上的经验，包括遇到的问题、尝试解决问题以及找到真正的问题。 遇到的问题以及如何解决 问题一：1 ~ 500个节点之后 问题： kubectl 有时会出现 timeout（p.s. kubectl -v=6 可以显示所有API细节指令） 尝试解决： 一开始以为是kube-apiserver服务器负载的问题，尝试增加proxy做replica协助进行负载均衡 但是超过10个备份master的时候，发现问题不是因为kube-apiserver无法承受负载，GKE通过一台32-core VM就可以承载500个节点 原因： 排除以上原因，开始排查master上剩下的几个服务(etcd、kube-proxy) 开始尝试调整etcd 通过使用 datadog 查看etcd吞吐量，发现有异常延迟(latency spiking ~100 ms) 通过 Fio 工具做性能评估，发现只用到10%的IOPS(Input/Output Per Second)，由于写入延迟(write latency 2ms)降低了性能 尝试把SSD从网络硬盘变为每台机器有个local temp drive（SSD） 结果从~100ms —>

前言 通过 K8s，用户能够自定义基础设施，可以平行的替换或改造平台的已有功能，而非只能局限在平台提供的能力之上构建。但正是这样的“白盒化”体验，正在为越来越多的研发和运维带来“太复杂”的困扰。 从 Kubernetes 到“以应用为中心”的美好未来之间，全世界的 PaaS 工程师其实都在期待一项全新的技术能够弥补这之间的鸿沟。阿里云原生应用平台团队的做法是，通过为应用“建模”的方式来解决这个问题，这也正是 Open Application Model (OAM) 开源项目得以创建的重要目的。 阿里巴巴的容器化之旅 阿里巴巴的容器化之旅始于 2013 年。在 Docker 诞生之前，阿里巴巴基于 lxc 的容器引擎研发了容器技术 T4，用于在裸机上部署和管理应用程序。 2017 年, 阿里巴巴内部孵化了类似于 K8s 的容器编排引擎 Sigma 作为资源统一层，用于管理内部机器池，平均利用率达到 40％。 2018 年，Sigma 重新设计并迁移成兼容 K8s API，阿里巴巴重新编写了自定义控制器和调度算法，并向暴露声明式 API 给用户试用。 2019 年底，阿里巴巴中的大多数应用都在 K8s 上运行，并且在 K8s 之上构建了数十个原生框架，构筑 K8s 生态系统。而 2019 年的 双11 活动不仅仅是商业上的成功，更是 K8s 基础设施可以支持如此大规模的有力证明。

目录 将制作的镜像推送到docker的私有仓库 k8s部署该镜像 k8s创建命名空间及secret 创建demo服务的yaml文件，我们service和deployment放在一个yaml文件中 启动 查看pod 环境：（docker ,k8s集群），继续上次docker 启动的java程序的镜像为例( https://www.cnblogs.com/levcon/p/12442662.html ) 将制作的镜像推送到docker的私有仓库 docker tag demo-img:latest localhost:5000/demo-img:1.0 docker push localhost:5000/demo-img:1.0 k8s部署该镜像 k8s创建命名空间及secret 创建命名空间cl-test，这里名字根据自己的命名规范自己定义，我这是测试用的 kubectl create namespace cl-test 创建完ns后，我们要给这个ns创建secret kubectl create secret docker-registry regcred --docker-server=your resroty ip:5000 --docker-username=root --docker-password=xxxx@ --docker-email=xxxx@163.com

目录 1.部署kubernetesubernetes的内网资源配置清单 2.配置dns解析 3.浏览器访问k8s-yaml.od.com 4.下载docker镜像并打包上传到harbor仓库 5.准备资源配置清单 6.应用资源配置 7.检查创建的资源 8.验证coreDNS 1.部署kubernetesubernetes的内网资源配置清单 在hdss7-200.host.com上，配置一个NGINX，用以提供kubernetes统一的访问资源清单入口 [root@hdss7-200 html]# vi /etc/nginx/conf.d/k8s-yaml.od.com.conf server { listen 80; server_name k8s-yaml.od.com; location / { autoindex on; default_type text/plain; root /data/k8s-yaml; } } [root@hdss7-200 html]# nginx -t [root@hdss7-200 html]# nginx -s reload [root@hdss7-200 html]# cd /data [root@hdss7-200 data]# mkdir k8s-yaml [root@hdss7-200 data]# cd k8s-yaml/

作者 | 王旭 蚂蚁金服资深技术专家 本文整理自《CNCF x Alibaba 云原生技术公开课》第 28 讲， 点击直达课程页面 。 关注“阿里巴巴云原生”公众号，回复关键词**“入门”**，即可下载从零入门 K8s 系列文章 PPT。 一、缘起：安全容器的命名 Phil Karlton 有一句名言：“计算机科学界只有两个真正的难题——缓存失效和命名。” 对我们容器圈而言，我相信「命名」绝对配得上这句话。这毫无疑问是一件让老开发者沉默、让新人落泪的事情。仅就系统软件而言，我们当今比较通行地称为**「Linux 容器技术」**这个概念，它曾经用过的名字还有 Jail, Zone, Virtual Server, Sandbox 等。同样，在早期虚拟化的技术栈里也把一类虚拟机叫做容器，毕竟这个词本身就指代那些用来包容、封装和隔离的器物。它实在太过常见了，以至于以严谨著称的 Wikipedia，它的词条叫做「OS-Level Virtualization」(系统级虚拟化) ，从而回避了「什么是容器」这个问题。 在 2013 年，Docker 问世之后，容器这个概念伴随着不可变基础设施、云原生这一系列概念在随后的几年间以摧枯拉朽之势颠覆了基于“软件包+配置”这种细粒度组合的应用部署，用简单的声明式策略和不可变的容器就清爽地定义了软件栈。应用怎么部署，在这儿似乎有点离题了

一、初始化服务器 1 关闭防火墙 ​ 【所有主节点都执行】 ​ [root@k8s-master1 ~]# systemctl stop firewalld [root@k8s-master1 ~]# systemctl disable firewalld 2 关闭selinux ​ 【所有主节点都执行】 # setenforce 0 # vim /etc/selinux/config 修改SELINUX=enforcing 为 SELINUX=disabled 3 配置主机名 ​ 【所有主节点都执行】 ​ hostnamectl set-hostname 主机名 4 配置名称解析 ​ 【所有主节点都执行】 vim /etc/hosts ​ 添加如下四行 192.168.31.63 k8s-master1 192.168.31.64 k8s-master2 192.168.31.65 k8s-node1 192.168.31.66 k8s-node2 5 配置时间同步 ​ 选择一个节点作为服务端，剩下的作为客户端 ​ master1为时间服务器的服务端 ​ 其他的为时间服务器的客户端 ​ ​ 1）配置k8s-master1 # yum install chrony -y # vim /etc/chrony.config #修改三项 server 127.127.1.0 iburst

Kubernetes是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效（powerful）,Kubernetes提供了应用部署，规划，更新，维护的一种机制。 前提条件是，有storageclass，利用pvc 创建持久化存储 创建kube-ops namespace 这里创建opspvc 另外把accessmode 换成readwritemany，因为会有多个pod 进行读写 然后部署jenkins master deployment如下 --- apiVersion: extensions/v1beta1 kind: Deployment metadata: name: jenkins namespace: kube-ops spec: template: metadata: labels: app: jenkins spec: terminationGracePeriodSeconds: 10 serviceAccountName: jenkins containers: - name: jenkins image: jenkins/jenkins:lts imagePullPolicy: IfNotPresent ports: - containerPort: 8080 name: web protocol: