kubeadm部署Kubernetes kubeadm简介 # kubeadm是一位高中生的作品,他叫Lucas Kaldstrom,芬兰人,17岁用业余时间完成的一个社区项目: # kubeadm的源代码,就在kubernetes/cmd/kubeadm目录下,是kubernetes项目的一部分, # 其中,app/phases文件夹下代码,对应的就是工作原理中详细介绍的每一个具体步骤: # 两条指令完成一个Kubernetes集群的部署: # 创建一个Master节点 # init # 将一

K8S的api-server证书包含很多IP和域名,有时候后期才发现证书内有错误,需要重新生成该证书. 修改server-csr.json,修改后基于原来的ca证书重新生成server.perm  server-key.pem cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes server-csr.json | cfssljson -bare server cp serve

Background kubernetes是master-slave结构,master node是集群的大脑, 当master node发生故障时整个集群都"out of control".master node中最重要的当属apiserver组件, 它负责处理所有请求, 并持久化状态到etcd. 一般我们会部署多份apiserver实现高可用.官方建议在多个apiserver前面部署一个LB进行负载均衡,当其中一台apiserver发生故障之后,LB 自动将流量切换到其他实例上面.这

kubeadm安装的k8s集群默认需要用户登陆认证,无法直接使用命令curl访问.所以首先的第一步就是获取token. 先找到k8s集群中的dns组件coredns,之前的版本使用的是kube-dns. [root@k8s-master ~]# kubectl -n kube-system get sa coredns -o yaml apiVersion: v1 kind: ServiceAccount metadata: creationTimestamp: "2019-09-26T12:2

环境:阿里云 压测主机:阿里云ECS(非LB后的主机) 压测目标:阿里云k8s自己的某个服务 k8s配置在kube-system 按照之前的ingress-nginx 配置了一个内网的ingress-nginx,对监听的443和80进行代理 LB为内网IP的lb,共享性的,然后在service的kube-system的ingress里添加了lb的实例 压测经过LB的时候,总是出现超时3%左右的超时连接 最后优化nginx-controler还是不行 然后试着把 ingress-nginx的Clu

用命令行总是很麻烦,因为要自定义一些证书的位置....... curl https://1.2.3.1:443/api/v1/nodes \ --cacert /etc/kubernetes/pki/ca.crt \ --cert /etc/kubernetes/pki/apiserver-kubelet-client.crt \ --key /etc/kubernetes/pki/apiserver-kubelet-client.key

一.脚本说明: 本实验中master.node.etcd都是单体. 安装顺序为:先安装test1节点主要组件,然后开始安装test2节点,最后回头把test1节点加入集群中,这样做目的是理解以后扩容都需要进行哪些操作 实验架构: test1: 192.168.0.91 etcd.kubectl工具.kube-apiserver.kube-controller-manager.kube-scheduler.kubelet组件.cni.kube-proxy test2: 192.168.0.92 d

#证书自签名脚本 root@k8s-master: ~/k8s/k8s-cert :: $ cat k8s-cert.sh cat > ca-config.json <<EOF { "signing": { "default": { "expiry": "87600h" }, "profiles": { "kubernetes": { "expiry"

在公司,使用dns切换,可能会比keepalived+haproxy,更精简的易维护. 毕竟,高可用只是偶尔切换,不是时时切换. 且dns解析在自己可控时,更不会影响k8s线上使用了. (部分代码,由于担心太冗长,已使用xxx代替,这些xxx完全可以自己生成的) 使用步骤如下: 先在每个master上安装etcd,运行如下命令: sh k8s.sh k8s.xxx.com.cn etcd 等每个master上的etcd安装好之后,运行如下命令: sh k8s.sh k8s.xxx.com.cn

Declarative API k8s: cluster-api Introduction to Kubernetes Cluster-API Project Declarative Management of Kubernetes Objects Using Configuration Files Imperative/Declarative and a Few `kubectl` tricks Kubernetes Object Management (official) api-exten

kubernetes是google开源的容器集群管理系统,提供应用部署.维护.扩展机制等功能,利用kubernetes能方便管理跨集群运行容器化的应用,简称:k8s(k与s之间有8个字母) Pod:若干相关容器的组合,Pod包含的容器运行在同一host上,这些容器使用相同的网络命令空间.IP地址和端口,相互之间能通过localhost来发现和通信.另外,这些容器还可共享一块存储卷空间.在k8s中创建,调度和管理的最小单位就是Pod,而非容器,Pod通过提供更高层次的抽象,提供了更加灵活的部署和管

背景与挑战 随着腾讯自研上云及公有云用户的迅速增长,一方面,腾讯云容器服务TKE服务数量和核数大幅增长, 另一方面我们提供的容器服务类型(TKE托管及独立集群.EKS弹性集群.edge边缘计算集群.mesh服务网格.serverless knative)也越来越丰富.各类容器服务类型背后的核心都是K8s,K8s核心的存储etcd又统一由我们基于K8s构建的etcd平台进行管理.基于它我们目前管理了千级etcd集群,背后支撑了万级K8s集群. 在万级K8s集群规模下的我们如何高效保障etcd集群的

1背景与挑战随着腾讯自研上云及公有云用户的迅速增长,一方面,腾讯云容器服务TKE服务数量和核数大幅增长, 另一方面我们提供的容器服务类型(TKE托管及独立集群.EKS弹性集群.edge边缘计算集群.mesh服务网格.serverless knative)也越来越丰富.各类容器服务类型背后的核心都是K8s,K8s核心的存储etcd又统一由我们基于K8s构建的etcd平台进行管理.基于它我们目前管理了千级etcd集群,背后支撑了万级K8s集群.在万级K8s集群规模下的我们如何高效保障etcd集群的稳

关于我们 更多关于云原生的案例和知识,可关注同名[腾讯云原生]公众号~ 福利: ①公众号后台回复[手册],可获得<腾讯云原生路线图手册>&<腾讯云原生最佳实践>~ ②公众号后台回复[系列],可获得<15个系列100+篇超实用云原生原创干货合集>,包含Kubernetes 降本增效.K8s 性能优化实践.最佳实践等系列. ③公众号后台回复[白皮书],可获得<腾讯云容器安全白皮书>&<降本之源-云原生成本管理白皮书v1.0> ④公众号

目录 一.写在前面 二.K8S为我们提供了怎样的能力 三.架构 3.1.MasterNode 3.2.WorkerNode 四.核心组件 4.1.ApiServer 4.1.1.概述 4.1.2.是集群管理API的统一入口 4.1.3.提供了完备的安全认证机制 4.1.4.典型使用场景 4.1.5.Api Proxy接口 4.2.ControllerManager 4.2.1.Replication Controller 4.2.2.Node Controller 4.2.3.ResourceQ

Android的init过程(一) 本文使用的软件版本 Android:4.2.2 Linux内核:3.1.10 在上一篇文章中介绍了init的初始化第一阶段,也就是处理各种属性.在本文将会详细分析init最重要的一环:解析init.rc文件. init.rc 文件并不是普通的配置文件,而是由一种被称为“Android初始化语言”(Android Init Language,这里简称为AIL)的脚本写成的文件.在了解init如何解析init.rc文件之前,先了解AIL非常必要,否则机械地分析 i

转自:http://www.cnblogs.com/nokiaguy/p/3164799.html Android的init过程(一) 本文使用的软件版本 Android:4.2.2 Linux内核:3.1.10 在上一篇文章中介绍了init的初始化第一阶段,也就是处理各种属性.在本文将会详细分析init最重要的一环:解析init.rc文件. init.rc 文件并不是普通的配置文件,而是由一种被称为“Android初始化语言”(Android Init Language,这里简称为AIL)的脚

https://feisky.gitbooks.io/kubernetes/components/api-aggregation.html API convention Kubernetes deep dive Code conventions 获取支持的服务: $ kubectl get apiservice NAME AGE v1. 35d v1.apps 35d v1.authentication.k8s.io 35d v1.authorization.k8s.io 35d v1.auto

2016-01-25更新 上篇文章总结k8s中搭建hbase时,遇到Pod中hostname的DNS解析问题,本篇将通过修改kube2sky源码来解决这个问题. 1 前言 kube2sky在Github上的项目(戳这里)一直在更新,放在DockerHub平台上的镜像滞后较多,有重新构建的必要.虽然新版kube2sky加入了对Pod的DNS解析,域名格式为<pod-ip-address>.<namespace>.pod.<cluster-name>,并不能直接通过host

k8s的api-server组件负责提供restful api访问端点, 并且将数据持久化到etcd server中. 那么k8s是如何组织它的restful api的? 一, namespaced resources 所谓的namespaced resources,就是这个resource是从属于某个namespace的, 也就是说它不是cluster-scoped的资源. 比如pod, deployment, service都属于namespaced resource. 那么我们看一下如何请

apiserver的部署 api-server的部署脚本 [root@mast-1 k8s]# cat apiserver.sh #!/bin/bash MASTER_ADDRESS=$1 主节点IP ETCD_SERVERS=$2 etcd地址 cat <<EOF >/opt/kubernetes/cfg/kube-apiserver KUBE_APISERVER_OPTS="--logtostderr=true \\ --v=4 \\ --etcd-servers=${ET