乐趣区

关于kubernetes:未完待续笔记-K8S-基础使用

jiezi

[笔记] K8S 根底应用

  • https://kubernetes.io/docs
  • https://kubernetes.io/zh/docs

下面俩是这玩意儿的官网文档，或者挺全的，但反正我感觉就没说到点上：想查啥它不说啥，只管自个儿念经。

所以我就想本人搞一个，万一本人哪天阿尔兹海默失忆了，如果那时候还活着的话，兴许也还能从新拾起来这部分把握过的货色。

根本

这 k8s 的一大特点就是概念贼 TM 多。它那套文档喜爱先介绍概念，那我就对着干，先从介绍怎么使开始吧：

个别在应用中根本不会用到 kubectl 以外的命令。

根本的应用就是这些的简略示例：

  • 查有哪些 Pod
  • 进入 Pod

还有一个很有用的基本概念：

  • Pod 和 Container 到底是啥子关系

查 Pod

如果你想查有哪些 Pod 的话：

kubectl get po

如果想指定 wahaha 这个命名空间（不晓得这是啥没关系用用就能晓得想查概念可本人查）：

kubectl get po -n wahaha

这个 -n 也能够写成 --namespace，前者是简写。

好了，会用这些，你就迈出了一大步。如果你有 Pod，那你看到的打印应该会是一个如同表格一样比拟参差的文本输入。想看更多字段能够【🦕在前面加上】-o wide：

kubectl get po -n wahaha -o wide

（当前呈现【🦕在前面加上】的字样就示意上面的命令是上一条提到的命令前面加上所述内容——当然要有空格离开！我并不是在说字符串拼接！）

如果想间接看全副的 Pod 就这样：

kubectl get po -A

还有别的查法：就是带上选项 -l 而后用选择器去找那种，在 label 有特定定义的 Pod。

进 Pod

个别

如果你有一个 Pod 叫 abc（在默认命名空间下），而且这个 Pod 只有一个容器，那进去的方法就是：

kubectl exec abc -t -i -- sh
  • 个别那个 sh 是用 bash，后者更好用但不肯定有，这取决于建设容器的镜像。
  • 那个 -i 的软件自释义：Pass stdin to the container，大略意思应该是 传递 stdin（规范输出）到容器中。
  • 那个 -t 的软件自释义：Stdin is a TTY，大略意思应该是 规范输出（stdin）是终端（TTY）（或者说「规范输出是来自终端的」）。

下面我解释了俩选项（Option），我是从 kubectl exec -h 的输入看到这些的，这个输入还示意了这些短选项名的等价长名版本（以及如果不指定的话的默认值）。

这里所谓的 进容器 含意其实是 能够交互式地操作容器 ，做这种事肯定离不开 SHell，而 Linux 个别会默认装好 sh ash bash 这三个 SHell 软件，当然也可能只装了 sh 这一个或者只是没装 bash。这里不思考 都没装 的状况。那么，所谓 进容器 其实就是 要：以交互模式启动一个容器内的 sh（或者别的 SHell）软件 了。

指定容器

如果 Pod abc 之下 （我顺便不说成 里 这样的形容之后解释）有多个容器（对 Pod 定义容器的定义文件里容器是数组所以能够是多个），其中一个名字叫 ddf，想进这个容器，个别这样写：

kubectl exec abc -c ddf -t -i -- sh

就是【🦕在 外面 加上】-c ddf。

而且，这个是无所谓有没有多个容器在这 Pod 下的，只是，若 Pod 下只有一个容器，则就不用再非要指定进入哪个容器罢了。

命名空间

如果是 Pod abc 在命名空间 qwe 下，要进入其中的容器 ddf 就须要这样：

kubectl exec abc -c ddf -n qwe -t -i -- sh

其中的 -n qwe 和 -c ddf 之间的先后无所谓，所有选项和 Pod 名 abc 这些所有货色之间的程序也都是无所谓的（然而我感觉 Pod 名靠前紧挨在 exec 后写会清晰一点）。

Pod and Container

下面说 Pod 下 而不是 Pod 内，是因为 Pod 是没有实体的，容器有，而 Pod 则是一组容器，只是对 K8S 来说，调度编排最小单位是 Pod。

如果你的 K8S 是基于 Docker 运行的，这意味着，K8S 相干组件是一些 Docker 容器，并且你启动的 Pod，在它的所在节点，也能够用 docker ps 找到对应的运行中的容器，并且你还会发现，用 docker exec 来进入这个容器，看起来简直和下面通过 Pod 进容器，是一样的。

如此一来，K8S 就更像是一个 Docker 的下层封装了。（当然了论文档的话却是 Docker 的更好一些 K8S 的则更像是在搞形式主义。。。。）

如果你在 qwe 命名空间下有 abc Pod 下的 ddf 容器，能够参考以下这样的命令去 在正确的节点 找到对应容器：

docker ps | (fgrep qwe | fgrep abc | fgrep ddf)

下面的小括号能够不写；小括号内（用 | 离开的）三个局部程序可轻易调换（指这不会导致输入后果会有内容上的不同）。

而后输入内容会很长，前面有个字段是容器名字，这个名字里蕴含了：K8S Pod 名、在 K8S Pod 下定义的容器名、K8S 命名空间名 等局部。

你当初晓得了它对应的 Docker 容器名是比方 xxxxxxxxxxx，进入就是像这样：

docker exec -t -i -- xxxxxxxxxxx sh

命令 docker 的参数和命令 kubectl 是不太一样的，只是简写的状况下会类似：

docker exec -ti xxxxxxxxxxx sh

命令 docker 的容器名是无关选项的参数局部（在 -- 后的局部）的第一项，在其中执行什么命令则是这里的第二项；

命令 kubectl 则不是这样，无关选项的参数局部（在 -- 后的局部）全是在容器内要执行的命令，而 Pod 名自身如同是在选项相干参数区域里被非凡看待的局部。（大略是因而 K8S 才会强烈建议不要省略双横线 -- 吧。）

写对象定义

就是个别的写 Yaml，等价的 Json 也是能够的。

解释

就是子命令 kubectl explain。它前面跟一种对象门路的写法，比方，你想写一个 Ingress 的定义，你就能够执行：

kubectl explain Ingress # or # kubectl explain ing

来获取到一些信息。输入内容里，一共有这几大块：

  • KIND：这个是定义对象的类型（全称）。
  • VERSION：这个应该是这个类型以后的版本（据说这就是 K8S 插件设计的体现）。
  • DESCRIPTION：这个上面是以后所指对象的形容。
  • FIELDS：字段；这个上面的也能够了解在以后对象门路下的子对象门路。

我这里执行 kubectl explain ing 的输入切实这样的：

KIND:     Ingress
VERSION:  extensions/v1beta1

DESCRIPTION:
     Ingress is a collection of rules that allow inbound connections to reach
     the endpoints defined by a backend. An Ingress can be configured to give
     services externally-reachable urls, load balance traffic, terminate SSL,
     offer name based virtual hosting etc. DEPRECATED - This group version of
     Ingress is deprecated by networking.k8s.io/v1beta1 Ingress. See the release
     notes for more information.

FIELDS:
   apiVersion   <string>
     APIVersion defines the versioned schema of this representation of an
     object. Servers should convert recognized schemas to the latest internal
     value, and may reject unrecognized values. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources

   kind <string>
     Kind is a string value representing the REST resource this object
     represents. Servers may infer this from the endpoint the client submits
     requests to. Cannot be updated. In CamelCase. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds

   metadata     <Object>
     Standard object's metadata. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

   spec <Object>
     Spec is the desired state of the Ingress. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

   status       <Object>
     Status is the current state of the Ingress. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

我看到字段上面有个 spec，假如我是依据它的形容体会了它能够用来干啥，我想晓得它的子对象（即它的 字段），那就执行 kubectl explain ing.spec，就能够看到输入：

KIND:     Ingress
VERSION:  extensions/v1beta1

RESOURCE: spec <Object>

DESCRIPTION:
     Spec is the desired state of the Ingress. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

     IngressSpec describes the Ingress the user wishes to exist.

FIELDS:
   backend      <Object>
     A default backend capable of servicing requests that don't match any rule.
     At least one of 'backend' or 'rules' must be specified. This field is
     optional to allow the loadbalancer controller or defaulting logic to
     specify a global default.

   ingressClassName     <string>
     IngressClassName is the name of the IngressClass cluster resource. The
     associated IngressClass defines which controller will implement the
     resource. This replaces the deprecated `kubernetes.io/ingress.class`
     annotation. For backwards compatibility, when that annotation is set, it
     must be given precedence over this field. The controller may emit a warning
     if the field and annotation have different values. Implementations of this
     API should ignore Ingresses without a class specified. An IngressClass
     resource may be marked as default, which can be used to set a default value
     for this field. For more information, refer to the IngressClass
     documentation.

   rules        <[]Object>
     A list of host rules used to configure the Ingress. If unspecified, or no
     rule matches, all traffic is sent to the default backend.

   tls  <[]Object>
     TLS configuration. Currently the Ingress only supports a single TLS port,
     443. If multiple members of this list specify different hosts, they will be
     multiplexed on the same port according to the hostname specified through
     the SNI TLS extension, if the ingress controller fulfilling the ingress
     supports SNI.

而后基于这种方法，应该就能够「无师自通」地学会怎么写定义文件了。。。（你看它甚至给你指明了字段的类型。。。🐌）

（然而，什么 po 啊 ing 啊 sc 啊 psp 啊 sts 啊等等等等，这么多资源了。。。。我当初还不晓得怎么晓得所有类型的资源以及对应全（简）称。）

现实状态下反正是这样的。我晓得实际上不是现实状态，最快的学习程序也并不是它们官网给的这种帮忙信息或者在线文档（谷歌的在线文档是真的搪塞又念经可能的确是没给员工留出太多工夫写吧），是啥我也不晓得，然而，晓得能够像这样 kubectl explain 的话，应该能略微升高一点难度了吧。。。（只惋惜不是中文。。。）

生成 Pod 或者别的 KIND 的资源个别都是写定义文件，或者是 Yaml 或者是 Json。具体示例大家能够本人搞，这里只是介绍一种用于了解具体的某份定义文件的路径。（那这么多杂七杂八的也够你查和了解一阵子了。。。）

相应的，对于 docker 也是同样的情理，比方你想看某个镜像的默认启动命令，然而不晓得咋看，那也能够这样：

  • 首先，镜像不就是 image 嘛，那就执行 docker image --help 获取一下帮忙信息；
  • 它会列出来这个子命令的再下一级子命令，我反正看来看去就看 inspect 如同是我要用的，因为别的都跟我想做的齐全不搭边，那就执行一下 docker image inspect nginx 如果你想看 nginx 这个镜像的默认启动命令的话，而后就会进去一堆 Json，这总比 Yaml 看着释怀吧？你就可以看这个镜像的很多方面细节了。
  • 而后看到能够的键值对就能够挨个搜一下，比方我搜到这么个乏味的货色：https://yeasy.gitbook.io/docker_practice/image/dockerfile/entrypoint（原来启动时执行的命令不光在 CMD 里）

找资源

个别，不论啥 KIND 下，第一波字段，都会有 metadata 这一个。对于 Ingress 资源来说就是执行 kubectl explain ing.metadata 能够看到对于这一个层级的具体介绍。这里定义 元信息，像如，这个资源对象叫啥、在哪个命名空间，都是在这儿定义的。

而个别，在不论 啥 KIND 的资源下的 metadata 下，都有一个字段叫 labels，能够看到类型是键值对（map），这个外面你能够任意定义各种字段与值的对应：

  • 首先能够看到，执行 kubectl explain ing.metadata.labels 的话它是没有 FIELDS 局部来示意其下字段有哪些的，只是有一个 FIELD 局部来像 DESCRIPTION 局部一样用于对 ing.metadata.labels 本身来做不同方面的形容。
  • 其次，如果尝试执行 kubectl explain ing.metadata.labels.aaaa 或者 kubectl explain ing.metadata.labels.zzzz 这样，即在下一级对象门路轻易写，也都是能正确执行并失去一个 DESCRIPTION 局部为 <empty>（示意空）的输入信息的，但这种行为在 对象（Object）类型 的层级下就不行，不信本人轻易试试，比方，执行 kubectl explain ing.metadata.zzz 会有错误信息：error: field "zzz" does not exist。

而后 selector。。。。

（未完）

（重大发现：服务的选择器该当对应豆荚的标签！！！而不是部署或正本集的标签！！！（之所以叫重大发现是因为居然没有任何一个示例体现出这一点；大家都是把能跑就行给来回复制的吗。。。））

退出移动版