Kubernetes 1.18增加了功能，解决了缺点
Kubernetes无疑是一项强大的技术，但它也有缺点。
例如，在Kubernetes下进行调试一直是一个挑战。 刚开始时，Kubernetes打算在Linux系统上运行，而在Windows下运行Kubernetes尚未发挥其全部潜力。 此外，如何管理可能会破坏整个Kubernetes集群的意外更改仍然存在麻烦。
Kubernetes 1.18承诺提供一些功能来解决这些缺点。 让我们看看其中的一些。
Kubectl运行限制
在Kubernetes 1.18之前的任何版本中，开发人员都可以使用kubectl run命令从命令行强制创建API资源。 例如，您将创建如下部署：
kubectl run my-deployment --image=my-app-image --restart=Always 或像这样的CronJob：
kubectl run my-cronjob --schedule="*/1 * * * *" --restart=OnFailure \
--image=busybox -- /bin/sh -c "date; echo Hello from the Kubernetes cluster" 从Kubernetes 1.18开始，您可以使用kubectl run创建的唯一API资源是单个pod 。 在生产级别，如果公司使用清单文件在Kubernetes中创建资源，这不会有太大影响。 但是在这种情况下，使用kubectl运行的脚本（例如在CI / CD脚本中）将导致用法破损。 因此，公司应审查其Kubneretes实施，以识别此新限制带来的潜在问题。
增强的调试
Kubernetes 1.18引入了一个新的命令集kubectl debug。 此命令旨在允许交互式故障排除 。 使用kubectl调试，它将在pod中创建一个临时调试容器。 调试容器可以配置为报告容器中容器活动的不同方面。 例如，此命令将创建一个名为“ mypod：”的容器。
kubectl debug mypod --image=debian 该容器将具有一个调试容器，该容器根据容器映像debian附加到该容器。 默认情况下，调试容器将报告从被调试容器发出的调试信息。
Kubectl调试将证明是对开发人员，管理员和安全专家解决Kubernetes集群中问题的方式的重大改进。
服务器端适用
kubectl apply命令用于对Kubernetes集群执行Kubernetes清单文件。 例如，考虑下面的清单文件。 它描述了一个吊舱。
apiVersion: v1
kind: Pod
metadata:
name: static-web
labels:
app: web
spec:
containers:
– name: web
image: nginx
ports:
– name: web
containerPort: 80
protocol: TCPKubernetes YAML文件，名称为my-pod.yaml，用于描述Pod
要在Kubernetes集群上创建Pod，请使用kubectl apply命令，如下所示：
kubectl apply -f my-pod.yaml 在Kubernetes 1.18之前，YAML文件中的信息将从本地客户端发送到Kubernetes集群中托管的Kubernetes API服务器上。 然后从Kubernetes控制平面内执行Pod创建过程。
但是，有一个问题。
在Kubernetes的早期版本中，当使用kubectl apply时，集群中没有记录谁对Kubernetes资源进行了更改。 结果，审计和变更管理很难跟踪。
Kubernetes 1.18将发布一个新的选项 ，即服务器端，这样就可以直接在服务器上执行kubectl apply。 这意味着将在服务器端记录谁对集群状态进行了更改以及何时进行了更改。
确定谁对集群进行了更改以及何时进行更改的能力将使系统管理员和DevOps人员的工作更加轻松。
更多Windows支持
Kubernetes 1.18增加了一种更加通用的方式，可以将运行Windows容器的Pod分配给运行Windows的Kubernetes节点机器。 在API资源RuntimeClass中增加了对Windows的支持 ，这使之成为可能。
这是创建Windows运行时类的方法。
apiVersion: node.k8s.io/v1beta1
kind: RuntimeClass
metadata:
name: windows-amd64
handler: ‘docker’
scheduling:
nodeSelector:
kubernetes.io/os: ‘windows’
kubernetes.io/arch: ‘amd64’
node.kubernetes.io/windows-build: ‘10.0.18362’
tolerations:
– effect: NoSchedule
key: windows
operator: Equal
value: “true”Kubernetes API资源RuntimeClass现在支持Windows操作系统的值
一旦定义了RuntimeClass并将其分配给节点，就可以使用RuntimeClass来配置Pod，如下所示：
apiVersion: v1
kind: Pod
metadata:
name: cool-pod
spec:
runtimeClassName: windows-amd64
containers:
– name: cool-container
image: myrepo/cool-image将窗格分配给Windows特定的节点
增强的RuntimeClass支持旨在简化Windows资源的部署过程。
不变的配置
Kubernetes集群面临的最大安全风险之一就是机密的损坏 。 机密是Kubernetes API资源，它使信息以加密方式可用于Kubernetes集群中的对象。 如果机密被无意或恶意更改，则该入侵可能会使使用该机密的应用程序屈服。
现在在Kubernetes 1.18中，该程序添加了该字段，该字段对于秘密规范是不变的。 使用该字段，机密清单文件中的不可变将使机密变为只读，并且不会发生意外更改。 下面显示了一个秘密清单，其中添加了不可变的字段。
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
username: YWRtaW4=
password: MWYyZDFlMmU2N2Rm
immutable: true从Kubernetes 1.18开始，不可变字段将使秘密不可更改。
除了字段增加和Kubernetes秘密规范不可变外，该字段也已添加到Kubernetes ConfigMaps的规范中。 将ConfigMap视为未加密的机密。 因此，开发人员不仅可以保护Kubernetes机密中的数据免受意外更改的影响，而且ConfigMap可以采取相同的预防措施。
放在一起
作为一种主流技术，Kubernetes在IT生态系统中继续发展 。 但是随着其流行度的提高，在生产中使用Kubernetes的复杂性也随之增加。
幸运的是，Kubernetes 1.18中引入的新功能将解决Kubernetes在调试，Windows支持和群集安全性方面向系统管理员提出的许多挑战。
翻译自: https://www.theserverside.com/blog/Coffee-Talk-Java-News-Stories-and-Opinions/Kubernetes-118-adds-more-power-addresses-shortcomings