我作为一个刚学习Kubernetes一个星期的初学者，看到的景象是这样的

对于Kubeflow这个机械学习工具，我产生了兴趣，开始学习Kubernetes。经过一周左右的尝试，我总结了一些感想。

如果有任何评论或补充，请毫不犹豫地提出。期待已经有多年Kubernetes经验的前辈们的到来。

1. 读音让我很困惑

对于初学者来说，Kubernetes最容易困惑的可能是发音。因为Kubernetes本身由Google员工如下Tweet所述，应该是一致的。

大多数团队成员会说：koo-ber-net-ees，或者只说’k8s’或’k-eights’。

问题是与其他Kube◯◯◯家族相关的。虽然有许多在海外引起了讨论，但有几条推文似乎具有决定性。

kubectl的发音是”kube control”而不是”cube control”。它是Kubernetes而不是Cube-rnetes。无论Brian Grant说什么都无关紧要。不要@我 — Ian Lewis (@IanMLewis) 2018年10月4日

“kubectl”的官方发音是kube-control，而不是kube-cuttle… @bgrant0607 在 #KubeCon 最后的主题演讲中提醒我们要保持诚实。这让我想起了JEE的Bill Shannon和 #JavaEE 😉 pic.twitter.com/dAo5gc5pMj— Arun Gupta (@arungupta) 2017年12月8日

总的来说，似乎没有太多一致的意见。只是通过观看Youtube视频，我感觉有很多人发音为”立方○○”。

经过思考，我决定将Kubernetes的发音明确为“克”，而其他词则以类似“库”的发音“克约”来表达。

总结起来，代表性的东西如下。

2. 学习成本，特别是初始成本较高。

当阅读参考书籍和网络上的入门文章时，最初是从环境搭建开始的，大多数人可能会坦率地认为”Kubernetes真的挺麻烦的”，我也是其中之一。

如果现在可以给当时的自己发一些建议的话，那就是在学会使用 kubectl 之前要坚持努力。

一旦你学会了使用kubectl，就能够在Kubernetes世界中扩大你的操作范围。说得夸张些，我认为使用kubectl来修改和操作yaml文件就像是站在起跑线上的起点。

介绍·Kubectl 读物

在接触 Kubernetes 之前，我认为可以通过 Dashboard 2 等以一种酷炫的方式进行操作，但实际上却是发送各种命令来进行相对低调的工作。

3. 执行 kubectl apply 后无法确定是否成功。

好了，终于掌握了kubectl这个技能，不过接下来又遇到了下一个问题。

▶kubectl apply -f xxxxxx.yml
pod "xxxxxx" created!

太好了！成功了！让我看看确认一下。

$kubectl get pod
NAME                         READY   STATUS         RESTARTS   AGE
nginx-pod                    0/1     ErrImagePull   0          6s

拉取图像出错！无法成功启动！！

看起来Docker镜像的拉取失败了。

尽管kubectl的apply命令成功执行了并不意味着它真正运行起来了，所以不能保证它是否正常运行。最终还是需要执行kubectl get xxx来确认。

顺便在删除各个资源时

▶kubectl delete -f xxxxxx.yml
pod "xxxxxx" deleted

只显示”と”。
真的所有相关资源都消失了吗？依赖关系会出问题吗？我必须自己确认一下吗…

4. 不懂yaml的写法

只要自己编写yaml文件，就可以自由地控制和配置容器，这一点我明白了。现在马上来写吧。先来确认一下示例代码。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

只需要一个选项的汉语本地化改写：
用三个容器…
加上负载均衡…
剩下的要把容器镜像也改成自己制作的呢…

嗯…我应该如何修正呢？

如果在Github或其他地方有一个分发yaml文件的话，就算是一只猴子也能搭建环境。
但是，如果想自己编写的话，一下子就不知道从何处着手了。

这种写法可以吗？
会不会有矛盾？
这么简单真的没问题吗？

因为从本质上来说我不熟悉声明式管理，所以我无法做出初始的指导。

由于我不知道apiversion到底是什么，所以从第一行开始我不知道该怎么做。

根据结论，似乎需要根据自己想要创建的资源来确认，使用命令 “kubectl api-resources”。

在寻找不同选项的过程中，我发现了一个名为 Kubernetes YAML Validation 的网站。非常方便。

5. 缺乏具体的的演示

我了解了yaml文件的规则，并且知道如果努力的话，可以自己进行各种定制。但是，我还不知道怎样将自己构思的结构转化为yaml文件，还没有明确的具体想法。

有没有什么看起来不错的演示可用？

在企业中有很多案例，但具体应该用什么样的设置或结构来执行还是个谜。
对于初学者来说，更想了解的是yaml文件和docker文件的编写方式。如何打开容器的端口，如何指定kind等。

部署Nginx并显示演示页面。嗯，这就结束了吗？
仅仅这样无法体会到Kubernetes的强大之处。
是否有自动修复和扩展的演示呢？

6. 与云托管服务的整合存在困难。

由于Kubernetes是开源的，因此可以在各种云端进行服务化。

我这次尝试了一下AWS的EKS托管服务，但是Route53和VPC的设置太麻烦了。虽然可以通过CloudFormation自动化环境构建，但作为Kubernetes新手，仍然需要理解每个资源的目的，所以最终还是花了很多时间。

这个认证流程真的很麻烦。感觉就像是把开源代码粘贴在一起的合体机器人一样。文档也没有整理得很好，感觉不太系统化。或许使用GCP会更方便一些吧…

在下面的工作坊中，介绍了一系列的操作，但是适合有一定AWS基础知识的人参加。

亚马逊EKS工作坊：亚马逊EKS工作坊

因为对于ALB的设定仍然不太清楚，所以需要好好学习一下。

7. 难以把握成本感觉

非常抱歉，再次使用EKS的時候，使用Kubernetes會創建許多複合的資源，例如EC2和CloudWatch等。

这个到底要花多少钱啊？

EBS和其他的一起消失吗？不会像僵尸一样自动复活，对吗？

由于yaml文件可以一次性生成多种资源，所以很难掌握成本感。我认为无论是GCP、Azure、IBM还是Alibaba，这个问题可能都是一样的。

如果能够在yaml文件中自动为资源打标签，那么跟踪成本也会更容易，但是…

这个地方也是今后需要调查的地方吗？

8. 信息的过时速度很快

经过各种学习后，我最终得出了这个结论。

这个知识能持续多久呢？

由于Kubernetes自身的开发周期迅速，网上的入门文章和参考书籍中有些部分已经过时。
几乎每个月都会举行聚会，Slack上的帖子也堆积如山。老实说，跟上进度相当困难…

努力学到的知识可能在一年后会变成”哦，那个已经不能用了，请用这个吧”。

我认为这不仅仅是针对Kubernetes，但我意识到盲目地相信Qiita的文章和个人博客是不好的。

这篇文章很快就会变得陈腐无用。

理所当然的是，最可靠的是官方文件。

阅读公式文档。
Kubernetes文档 – Kubernetes