k8s 常用命令

末尾的参数都是可选项，可以跟一个或者同时跟多个参数，可以按 namespace 、label 等筛选，也可以扩展更多信息、

查看资源

kubectl get all # 查看所有资源的信息

kubectl get pod/svc/deployment/nodes/namespaces --all-namespaces
kubectl get pod -n kube-system # 根据 namespace 查看 pod
kubectl get pods -o wide # 显示详细信息
kubectl get pod -o wide --all-namespaces
kubectl get pods pod_name
kubectl get pods -l app=example # 根据 label 的 key=value 匹配

kubectl get componentstatuses # 查看组件状态
kubectl cluster-info # 查看集群信息

查看资源描述

kubectl describe pod/svc/deployment/nodes/namespaces
kubectl describe pod pod_name -n kube-system 

查看资源日志

kubectl logs pod_name -n kube-system
kubectl logs pod_name -n kube-system -c container_name # 如果 Pod 有多个容器，需要加容器名参数

删除资源

kubectl delete pod pod_name 
kubectl delete svc svc_name 

在 pod 内执行命令

kubectl exec pod_name  -n namespace cmd

扩容缩容

kubectl scale deployment deployment_name --replicas=8

k8s相关教程

https://kubernetes.io/zh/docs/tasks/tools/install-kubectl/

k8s部署应用

https://www.cnblogs.com/benjamin77/p/12446781.html

k8s 爬虫

https://zhuanlan.zhihu.com/p/85320056

k8s 集群方案

GitOps或Git操作版本控制。通过这种方法，你可以将所有的Kubernetes YAML文件都保存在Git仓库下，这样你就可以精确地知道什么时候进行了更改，谁进行了更改，以及到底更改了什么。这使得整个组织更加透明，避免了成员需要到哪里去寻找所需内容的歧义，提高了效率。同时，只需合并一个拉取请求就可以更容易地自动对Kubernetes资源进行更改。

ansible 安装 k8s集群

Gitlab+Jenkins Pipeline+Docker+k8s+Helm自动化部署实践

https://zhuanlan.zhihu.com/p/140699919?utm_source=wechat_session&utm_medium=social&utm_oi=781197657170276352

https://mp.weixin.qq.com/s/m9v6Fx9tUYDca23Sa71ftA

容器的持续集成与部署

修改代码->自动构建镜像->自动更新容器并发布

https://mp.weixin.qq.com/s?__biz=MjM5MjAwODM4MA==&mid=2650779899&idx=3&sn=9f32dc163c4c6686f5ac49241debfd3b&chksm=bea7c12889d0483e57cdbc349dd0e29955992bc9aa75f8ac228b366ec9f9faef7754e79937f6&scene=126&sessionid=1599722225&key=35e83ae871889873ba8e54ee017419d1913b4fff581f0356ecbd3f07e86e18639caf259b5287a22b35b4a9a23f20d1e017849833b8345fb97d4bdd33912b27ee08dcf532a6ebb0477fe6004dd9397c5a2498cfe1e78c72ae00567e7733c5a4dda51add10799359282e9945c3639069247c6a238306833eff8444864012a41a88&ascene=1&uin=MTkzOTU2NzUwMg%3D%3D&devicetype=Windows+10+x64&version=62090538&lang=zh_CN&exportkey=AX4FnFBERT%2B1y2LB1R5agaM%3D&pass_ticket=Df5Mnq5r2uJwBPC8s0GlMi1DUfhSwXb9nrFZIO0JS5kC70eWfQl0Hv5hGygqkTcK&wx_header=0

K8S更多的认识

https://mp.weixin.qq.com/s?__biz=MjM5MjAwODM4MA==&mid=2650776470&idx=1&sn=2e63f57d5f9063d14ff31a10d2754a6f&chksm=bea7d24589d05b53e39e8239a130cd7a460cc9ad14fb14b0dc24a850a2c1423ba6a1650ff9a0&scene=126&sessionid=1599726749&key=311c00f061d776a9e9b4dd687107402f5a02f2bfb148bd04b4b8171fccaaa134d57e5886dc494937748545c540599a0a430becccae4ffb3036e13a52f7b96944b1e0f7ecfd6e4be9b096a865f64821938ee74b9c222117d6210c116814561bf7ef4d037302068ace2e50276ede79924165a369c3beda1866ee6281c0d0957167&ascene=1&uin=MTkzOTU2NzUwMg%3D%3D&devicetype=Windows+10+x64&version=62090538&lang=zh_CN&exportkey=AT18Ry3k%2FC%2F19sNMub0PuKA%3D&pass_ticket=Df5Mnq5r2uJwBPC8s0GlMi1DUfhSwXb9nrFZIO0JS5kC70eWfQl0Hv5hGygqkTcK&wx_header=0

Kubernetes并非灵丹妙药。它可以帮助你将托管应用程序的复杂性转移到精心设计的Kubernetes架构中，但这些复杂性本身并不会消失。你始终需要保护和维护平台。

为了让普通的工作负载也能使用集群，我们需要管理很多附加组件。有些附件几乎每个人都在使用，则有些则比较小众。其中包括Nginx（Ingress控制器）、cert-manager和cluster-autoscaler（在没有足够的容量时添加额外的节点）等。还有一些软件专门为环境定制的关键功能非常独特，而且也同样需要管理。此外，这些组件也需要定期更新，有时可能还有质量问题。Helm或Terraform等配置管理工具几乎是必须的：手动调整集群非常危险，而且没有声明式设置你根本没办法启动另外一个一模一样的集群。我亲身经历过在运维过程或替换成更成熟的集群时引发了无穷无尽的问题。

在Kubernetes上运行任何重要的技术栈，都需要缜密的策划。放任员工随意部署他们喜欢的软件，只会让你的集群陷入混乱。最终，你只能得到一堆层次不齐的应用程序散布在几十个（甚至可能是一个）命名空间中，却没有人知道它们是如何组织在一起的。虽然旧的意大利面条式的基础设施非常混乱，但如今你只是换成了一种新型的意大利面条式的基础设施，最后还用一个更加冰凉的盘子端了上来。

我所见过的最成功的Kubernetes实现方式是：基础设施专家与开发人员合作，确保工作负载的配置合理、标准化、相互保护，而且还有明确的通信模式。基础设施专家负责在基础设施上处理应用程序的初始设置，并将其连接到构建/发布系统，如此一来，开发团队无需他们的帮助即可发布新版本的代码。其实，这个过程反应的是组织广泛的文化，如果你们的工程非常混乱，沟通不顺畅，而且职责不明确，那么托管的环境都将逐一反映出来。即便使用Kubernetes，你们的系统也会非常不可靠；而且在最糟糕的情况下，不可靠之余，还会引发不可维护、成本昂贵等各种问题。