共计 2337 个字符，预计需要花费 6 分钟才能阅读完成。
背景：
作为腾讯云的老用户我大略是 2018 年开始应用腾讯云的 tke 服务的。过后是 1.10，当初线上还有一个 tke1.12 的集群，鉴于晚期更新迭代较慢。我抉择了在腾讯云下面 kubeadm 的形式自建 kubernetes 集群的形式。参见：https://duiniwukenaihe.github.io/2019/09/02/k8s-install/。前面继续降级，当初是 1.17.17 版本。最近看腾讯云云原生公众号更新的内容都比拟多，并且 tke 的版本到了 1.18 我抉择了尝试一下 tke 的服务！
注：昨天开明搭建没有截图 …. 明天就将就一下模仿演示吧！
tke 开明体验：
注：我之前开通过 tke 服务注册账号，服务受权就疏忽了！，对于这部分的内容能够参照官网文档：https://cloud.tencent.com/document/product/457/54231
1. 关上治理控制台：
https://console.cloud.tencent.com/tke2/cluster?rid=4
名为 k8s 的集群为老的集群。k8s-shanghai 为昨天新建的 tke1.18 的新的集群。因为集群曾经创立了。当初就只是截图反复一遍步骤，不去做新集群的开明了！
2. 新建集群
设置集群的名称，新增资源所属的我的项目，我这里就都是默认了。抉择 kubernetes 的版本。以后最新版本是 1.18.4。至于 runtime 运行时组件。我是间接用了 containerd 了。当然了 docker 也还算能够的在 1.18 的版本。地区我的服务器资源都部署在上海。而后抉择集群的网络环境。容器网络的组件应用了默认的 Global Router，VPC-CNI 对于我来说还没有这样的需要
3. 特别强调说一下容器的网络：
我的 cvm 网络 CIDR 是 10.0.0.0/16 的网络。容器的网络是要跟集群网络离开的失常来说抉择 192.168 或者 172.X.0.0.0/16。当然了也能够可变长子网掩码。本人玩的不是太好还是依照提醒老老实实的了默认的提醒 X 是
16，18，….，31。16 用过了,18 貌似也用了 我就抉择了 19。故容器网络的 CIDR 是 172.19.0.0/16. 节点的 pod 调配形式也能够满足我的要求！
4. 操作系统与 proxy 选型
操作系统我都抉择了 ubuntu18.04。嗯也能够用腾讯云的 tencent linux 或者 centos.kube-proxy 代理形式我抉择了 ipvs。当然了对应咱们这样业务的量级两个 proxy 代理的形式差距并不是太大，也没有孰好孰坏一说，看本人需要了！
5. 新建或者将已有资源退出 master work 节点
服务器的配置这里我是应用了已有的节点资源，master 独立部署的形式。间接把我资源池中的 cvm 资源分配给了 master 和 work。其中 master 节点是 4 核 8G 内存配置，work 节点是 16 外围 36G 内存配置。
6. 增加加强的组件
至于组件配置就看集体需要了。这边不不便截图了。我就在搭建实现的集群中理一下我顺手装置的几个组件：
cbs cfs cos 存储组件是不可短少的对我来说。
NodeProblemDetectorPlus OOMGuard 看着很有用，我也就装置上了。
NodeProblemDetectorPlus 参数设置我应该设置了一个异样重启 kubelet 的性能这边后盾也无奈查看配置参数有点不好玩了而后期待集群的初始化实现。嗯，服务器的明码能够主动生成也能够应用 ssh-key 或者本人手工输出的看本人需要了。
tke 应用体验
1. 特地不爽的一点 kuberctl get node 的排序
登陆任一一台 master 节点，第一件事件 kubectl get nodes 查看一下集群：
what？为什么排序拍的杂七乱八的 …. 能不能 ROLES master 在前？如下图：
失常的排序不都这样吗？tke 用 ip 形式显示主机名。然而 master 能不能排在后面？至于 node 节点的排序能不能有个排序的形式呢？排序这个货色提交了工单。客服回应说设计如此。幸好朋友圈有几个腾讯云的小伙伴，看我吐糟，帮拉了 tke 的一个群，反馈了一下。而后 tke 的小伙伴记录了一下。
2. csi-cbs-controller 插件的异样
没有去细看，端口异样不晓得跟哪个服务抵触了。客服最初也没有能通知我是跟哪一个插件抵触了，前面复原了。…… 次要是懒得看了。用集成服务。前提是稳固的。我集体感觉肯定是能够开箱即用的。
3. 利用市场 prometheus-opraoter 的谬误
tke 有一个利用市场，算是一个 helm 仓库吧。跑一个 Prometheus-oprator 的 helm 利用测试一下，而后又陷入了难过：
monitoring-kube-state-metrics 服务无奈启动。最初看了一下这个 POD 是应用 hostNetwork 模式的 须要应用主机端口，POD 所在节点 这个端口是否被其余利用所占用？看了一眼此节点日志嗯 8080 的确被占用了：一个名为 launcher 的服务占用了此端口：
客服给的解决方案：
集体还是不太置信。因为我没有装置任何利用只装置了加强组件和存储组件。登陆其余 work 节点也确认一下发现每个节点都有一个 launcher 利用。狐疑这是一个零碎组件
kubectl get pods --all-namespaces|grep launcher
最初找客服确认了一下，如下：
依照客服提醒批改端口吧 ……. 嗯总算起来了：
后记：
这是用 tke1.18 的第一印象。当然了 tke 的小伙伴还是很给力的，敌人帮拉了群。各种问题能够随时反馈，还说不错的。
这算是初体验吧，而后看看下一步体验一下部署其余利用，将服务 clb 代理。一步一步来吧。也心愿 tke 能有更好的用户体验！
