背景：
作为腾讯云的老用户我大略是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能有更好的用户体验！