mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-03-24 02:20:09 +08:00
Merge remote-tracking branch 'LCTT/master'
This commit is contained in:
Xingyu Wang
commit
6c5b5f110d
@ -1,50 +1,52 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (lxbwolf)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: reviewer: (wxy)
|
||||
[#]: publisher: (wxy)
|
||||
[#]: url: (https://linux.cn/article-11749-1.html)
|
||||
[#]: subject: (Kubernetes namespaces for beginners)
|
||||
[#]: via: (https://opensource.com/article/19/12/kubernetes-namespaces)
|
||||
[#]: author: (Jessica Cherry https://opensource.com/users/jrepka)
|
||||
|
||||
Kubernetes 命名空间入门
|
||||
======
|
||||
命名空间是什么？你为什么需要它？
|
||||
![Ship captain sailing the Kubernetes seas][1]
|
||||
|
||||
kubernetes 命名空间是什么？Shakespeare 以前写过，我们声称的命名空间，或者任何其他名字，仍是一个虚拟集群。命名空间，意味着 kubernetes 可以在单个集群上提供多个 kubernetes 的集群，类似一个对其主机进行抽象的虚拟机。[kubernetes 文档][2] 中的解释：
|
||||
> 命名空间是什么？你为什么需要它？
|
||||
|
||||
|
||||
|
||||
kubernetes <ruby>命名空间<rt>namespace</rt></ruby>是什么？正如 Shakespeare 以前写过的，我们所谓的命名空间，或者任何其他名字，就是虚拟集群。通过虚拟集群，意味着 kubernetes 可以在单个集群上提供多个 kubernetes 的集群，类似一个在其主机抽象出来的虚拟机。[kubernetes 文档][2] 中的解释：
|
||||
|
||||
> kubernetes 在一个物理集群上提供了多个虚拟集群。这些虚拟集群被称为命名空间。
|
||||
|
||||
你为什么需要命名空间？一句话概括：隔离。
|
||||
你为什么需要命名空间？一言以蔽之：隔离。
|
||||
|
||||
隔离有很多优点，如它提供了安全和干净的环境。如果你是基础设施的所属者，并且为开发者提供环境，隔离就相当重要。你最不需要的就是，一个不熟悉你集群是如何搭建的人去修改系统配置 — 这可能导致所有人都无法登录。
|
||||
隔离有很多优点，如它提供了安全和干净的环境。如果你是基础设施的所属者，并且要为开发者提供环境，隔离就相当重要。你最不需要的就是，一个不熟悉你集群是如何搭建的人去修改系统配置 —— 这可能导致所有人都无法登录。
|
||||
|
||||
### 初始命名空间
|
||||
|
||||
一个集群的三个初始命名空间：**default**、**kube-system** 和 **kube-public**。虽然你可以用这三个命名空间作技术部署，但我还是推荐你把这三个命名空间留作系统配置用，而不是你的项目。
|
||||
一个集群的三个初始命名空间：`default`、`kube-system` 和 `kube-public`。虽然技术上你可以用这三个命名空间作部署，但我还是推荐你把这三个命名空间留作系统配置用，而不是你的项目。
|
||||
|
||||
* **Default** 某些部署没有指明命名空间，这样部署可以快速创建一个网格，但如果做了很多错误信息的部署，就很能去清理。我不去修改它，因为它在为某一个目的服务时，会在不止一种情况下误导我。
|
||||
* **Kube-system** 系统相关的所有对象组成的命名空间。任何此命名空间的部署都可能是危险的操作，可能对系统本身造成不可挽回的破坏。没错，我试过；所以我不推荐。
|
||||
* **Kube-public** 所有人可读，但是这个命名空间是为系统保留的。
|
||||
* `Default` 用于某些没有指明命名空间的部署，这是一种快速创建混乱的做法，如果你在没有正确信息的情况下做了很多部署，将很难清理。我不会去动它，因为它只有这一个用途，而且在不止一种情况下误导过我。
|
||||
* `Kube-system` 是 Kubernetes 系统相关的所有对象组成的命名空间。任何对此命名空间的部署都可能是危险的操作，可能对系统本身造成不可挽回的破坏。没错，我试过；所以我不推荐。
|
||||
* `Kube-public` 所有人可读，但是这个命名空间是为系统保留的。
|
||||
|
||||
### 用命名空间来实现隔离
|
||||
|
||||
我用了多种方式通过命名空间来实现隔离。我经常用命名空间来把多个用户项目分割到不同的环境。这种方式可以有效防止跨项目的污染，因为命名空间提供了独立的环境。例如，使用者可以安装不同版本的 Jenkins，如果它们的环境变量是在不同的命名空间，就不会冲突。
|
||||
我用了多种方式通过命名空间来实现隔离。我经常用命名空间来把多个用户项目分割到不同的环境。这种方式可以有效防止跨项目的污染，因为命名空间提供了独立的环境。例如，用户可以安装不同版本的 Jenkins，如果它们的环境变量是在不同的命名空间，就不会冲突。
|
||||
|
||||
这种隔离对于清理也很有帮助。如果部署组的多个项目被废弃，你可以用命令 `kubectl delete ns <$NAMESPACENAME>` 一键删除命名空间，清理命名空间内的所有东西。（请确认被删除的是正确的命名空间。我曾经在生产环境删除了错误的命名空间，这很不好。）
|
||||
这种隔离对于清理也很有帮助。如果开发小组的多个项目突然被废弃，你可以用命令 `kubectl delete ns <$NAMESPACENAME>` 一键删除命名空间，清理命名空间内的所有东西。（请确认被删除的是正确的命名空间。我曾经在生产环境删除了错误的命名空间，这很不好。）
|
||||
|
||||
如果你是基础设施所有者，请谨慎操作，因为这可能会引发其他团队的的故障或引发其他问题。例如，如果你创建了一个特定的命名空间，里面有 DNS 函数，其他人删除了它，那么命名空间内的所有 pod 和它们运行的应用都会被清空。所有的**删除**操作在真正实施之前都应该由同事（通过 [GitOps][3]）评审一下。
|
||||
如果你是基础设施所有者，请谨慎操作，因为这可能会引发其他团队的的故障或引发其他问题。例如，如果你创建了一个特定的命名空间，里面有特殊的额外安全的 DNS 功能，但是其他人删除了它，那么命名空间内的所有 pod 和它们运行的应用都会被清空。所有的**删除**操作在真正实施之前都应该由同事（通过 [GitOps][3]）评审一下。
|
||||
|
||||
虽然官方文档不建议 [10 人以下团队][2] 使用多个命名空间，但出于架构需要，在我自己的集群上还是用了多个命名空间。集群越干净越好。
|
||||
|
||||
### 关于命名空间管理员应该知道的
|
||||
|
||||
首先，命名空间不能嵌套。部署只能在一个命名空间中进行。对于版本化项目，你不一定要用命名空间，你可以使用标签来区分有相同名字的版本化应用。命名空间使用配额来为不同的用户划分资源；例如，*某个命名空间最多能有 x 个 node*。最后，所有的命名空间对于资源类型只能使用一个独一无二的名字。
|
||||
首先，命名空间不能嵌套。部署只能在一个命名空间中进行。对于版本化项目，你不一定要用命名空间，你可以使用标签来区分有相同名字的版本化应用。命名空间使用配额来为不同的用户划分资源；例如，*某个命名空间最多能有 x 个节点*。最后，所有的命名空间对于该资源类型只能使用一个独一无二的名字。
|
||||
|
||||
### 命名空间命令操作
|
||||
|
||||
你需要安装 [Minikube][4]、 [Helm][5] 和 [kubectl][6] 命令行，才能使用下面的命名空间命令。我的文章 [_安全浏览你的 DevOps 流水线_][7] 中有它们的安装教程，你也可以去每个工程的官方主页去找安装教程。我使用的是最新的 Minikube。手动安装很快，第一次就能成功运行。
|
||||
你需要安装 [Minikube][4]、[Helm][5] 和 [kubectl][6] 命令行，才能使用下面的命名空间命令。我的文章《[安全扫描你的 DevOps 流水线][7]》中有它们的安装教程，你也可以去每个项目的官方主页去找安装教程。我使用的是最新的 Minikube。手动安装很快，第一次就能成功运行。
|
||||
|
||||
获取你的第一组命名空间：
|
||||
|
||||
@ -63,7 +65,7 @@ jess@Athena:~$ kubectl create namespace athena
|
||||
namespace/athena created
|
||||
```
|
||||
|
||||
现在开发者可以部署到你创建的命名空间；例如，这里是一个简短的 Helm 结构信息：
|
||||
现在开发者可以部署到你创建的命名空间了；例如，这里是一个简短的 Helm chart：
|
||||
|
||||
```
|
||||
jess@Athena:~$ helm install teset-deploy stable/redis --namespace athena
|
||||
@ -74,7 +76,7 @@ STATUS: deployed
|
||||
REVISION: 1
|
||||
TEST SUITE: None
|
||||
NOTES:
|
||||
** Please be patient while the chart is being deployed **
|
||||
` Please be patient while the chart is being deployed `
|
||||
Redis can be accessed via port 6379 on the following DNS names from within your cluster:
|
||||
|
||||
teset-deploy-redis-master.athena.svc.cluster.local for read/write operations
|
||||
@ -98,6 +100,7 @@ export REDIS_PASSWORD=$(kubectl get secret --namespace athena teset-deploy-redis
|
||||
```
|
||||
|
||||
2. 使用 Redis CLI 连接：
|
||||
|
||||
```bash
|
||||
redis-cli -h teset-deploy-redis-master -a $REDIS_PASSWORD
|
||||
redis-cli -h teset-deploy-redis-slave -a $REDIS_PASSWORD
|
||||
@ -110,11 +113,10 @@ kubectl port-forward --namespace athena svc/teset-deploy-redis-master 6379:6379
|
||||
redis-cli -h 127.0.0.1 -p 6379 -a $REDIS_PASSWORD
|
||||
```
|
||||
|
||||
现在这一套部署已经完成了，你有一个在命名空间 **test-deploy** 中部署的图表。
|
||||
现在这一套部署已经完成了，你有一个在命名空间 `test-deploy` 中部署的 chart。
|
||||
|
||||
查看你的命名空间中有哪些 pod：
|
||||
|
||||
|
||||
```
|
||||
jess@Athena:~$ kubectl get pods --namespace athena
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
@ -127,7 +129,6 @@ teset-deploy-redis-slave-1 1/1 Running 0 90s
|
||||
|
||||
一键删除所有东西：
|
||||
|
||||
|
||||
```bash
|
||||
jess@Athena:~$ kubectl delete namespace athena
|
||||
namespace "athena" deleted
|
||||
@ -137,7 +138,6 @@ namespace "athena" deleted
|
||||
|
||||
再次检查一下所有东西是否被删除了：
|
||||
|
||||
|
||||
```bash
|
||||
jess@Athena:~$ kubectl get pods --all-namespaces
|
||||
NAMESPACE NAME READY STATUS RESTARTS AGE
|
||||
@ -156,11 +156,11 @@ kube-system storage-provisioner 1/1 Running 0
|
||||
|
||||
### 命名空间实践
|
||||
|
||||
现在我是为了安全使用命名空间，如限制用户的权限。你可以限制所有的东西 — 从哪些角色可以访问命名空间，到命名空间可使用的集群资源（CPU 等）的配额等级。例如，我通过资源配额和基于角色的访问控制（role-based access control，RBAC）配置来确保只有允许的服务账号可以访问命名空间。
|
||||
当前我是出于安全考虑才使用命名空间，如限制用户的权限。你可以限制所有的东西 —— 从哪些角色可以访问命名空间，到命名空间可使用的集群资源（CPU 等）的配额等级。例如，我通过资源配额和<ruby>基于角色的访问控制<rt>role-based access control</rt></ruby>（RBAC）配置来确保只有允许的服务账号可以访问命名空间。
|
||||
|
||||
对于隔离方面的安全，我不希望我的私人 Jenkins 应用可以通过一个信任的本地网络被当做有公共 IP 地址的安全镜像来访问（我不得不假定，可能会做出妥协）。
|
||||
对于隔离方面的安全，我不希望我的私人 Jenkins 应用可以通过一个信任的本地网络被当做一个有公共 IP 地址的安全镜像来访问（我不得不假定，可能会被侵袭）。
|
||||
|
||||
如果你很难提前计算出到底要在你的云平台上部署多少 node（就我而言，在把我的私人服务器放到 [segfaulting][8] 之前可以部署多少个 node），那么命名空间在预算方面也很有用。虽然这超出了本文的讨论范围，而且很复杂，但值得你去调研和使用来防止你的集群过分扩展。
|
||||
如果你很难提前计算出到底要在你的云平台上部署多少节点（或者，就我而言，是在[搞崩][8]我的家庭服务器之前我能部署多少个），那么命名空间在预算方面也很有用。虽然这超出了本文的讨论范围，而且很复杂，但值得你去调研和使用来防止你的集群过分扩展。
|
||||
|
||||
### 总结
|
||||
|
||||
@ -173,7 +173,7 @@ via: https://opensource.com/article/19/12/kubernetes-namespaces
|
||||
作者：[Jessica Cherry][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[lxbwolf](https://github.com/lxbwolf)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
@ -1,8 +1,8 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: reviewer: (wxy)
|
||||
[#]: publisher: (wxy)
|
||||
[#]: url: (https://linux.cn/article-11748-1.html)
|
||||
[#]: subject: (Fixing “VLC is Unable to Open the MRL” Error [Quick Tip])
|
||||
[#]: via: (https://itsfoss.com/vlc-is-unable-to-open-the-mrl/)
|
||||
[#]: author: (Abhishek Prakash https://itsfoss.com/author/abhishek/)
|
||||
@ -10,11 +10,13 @@
|
||||
修复 “VLC is Unable to Open the MRL” 错误
|
||||
======
|
||||
|
||||
|
||||
|
||||
一个使用 [VLC 的技巧][1]是使用 [VLC] [2] 播放 YouTube 和其他在线视频。这可以帮助你[观看带有字幕的在线视频][3]。
|
||||
|
||||
但是事情并不总是这么简单，因为有时使用 VLC 打开 YouTube 视频时会遇到此错误：
|
||||
|
||||
**Your input can’t be opened: VLC is unable to open the MRL ‘<https://youtubeurl.com’>. Check the log for details.**
|
||||
> Your input can’t be opened: VLC is unable to open the MRL '<https://youtubeurl.com>'. Check the log for details.
|
||||
|
||||
![VLC error while playing YouTube videos][4]
|
||||
|
||||
@ -26,19 +28,17 @@
|
||||
|
||||
对于 VLC 也是如此。如果你[在 Ubuntu 或任何你用的系统中安装了最新的 VLC][7]，那么可能不会看到此错误。
|
||||
|
||||
### 修复 ”VLC is unable to open the MRL“ 错误
|
||||
### 修复 “VLC is unable to open the MRL” 错误
|
||||
|
||||
让我向你展示对于 YouTube 的修复步骤。
|
||||
|
||||
进入 VLC 媒体播放器的官方 Github 仓库页面，并使用 Ctrl+S 保存文件：
|
||||
进入 VLC 媒体播放器的官方 Github 仓库页面的[这个页面][8]，并使用 `Ctrl+S` 保存文件：
|
||||
|
||||
[Download youtube.lua file][8]
|
||||
|
||||
现在，你需要做的是用此下载文件替换 lib/vlc/lua/playlist 目录中的 youtube.luac（注意 luac 中的 “c”）。
|
||||
现在，你需要做的是用此下载文件替换 `lib/vlc/lua/playlist` 目录中的 `youtube.luac`（注意 luac 中的 “c”）。
|
||||
|
||||
#### Linux 中的步骤
|
||||
|
||||
如果你使用的是 Linux，请打开终端并使用 [locate 命令][9]查找 youtube.luac 文件的确切位置：
|
||||
如果你使用的是 Linux，请打开终端并使用 [locate 命令][9]查找 `youtube.luac` 文件的确切位置：
|
||||
|
||||
```
|
||||
locate youtube.luac
|
||||
@ -49,7 +49,7 @@ locate youtube.luac
|
||||
对我而言，以下是文件路径：
|
||||
|
||||
```
|
||||
[email protected]:~$ locate youtube.lua
|
||||
abhishek@itsfoss:~$ locate youtube.lua
|
||||
/usr/lib/x86_64-linux-gnu/vlc/lua/playlist/youtube.luac
|
||||
```
|
||||
|
||||
@ -65,10 +65,8 @@ sudo cp ~/Downloads/youtube.lua /usr/lib/x86_64-linux-gnu/vlc/lua/playlist/youtu
|
||||
|
||||
如果你使用的是 Windows，那么应遵循以下步骤：
|
||||
|
||||
* 将下载的 youtube.lua 文件重命名为 youtube.luac
|
||||
* 复制此文件并将其粘贴到 C:\Program Files (x86)\VideoLAN\VLC\lua\playlist\
|
||||
|
||||
|
||||
* 将下载的 `youtube.lua` 文件重命名为 `youtube.luac`
|
||||
* 复制此文件并将其粘贴到 `C:\Program Files (x86)\VideoLAN\VLC\lua\playlist\`
|
||||
|
||||
就是这些了。
|
||||
|
||||
@ -83,7 +81,7 @@ via: https://itsfoss.com/vlc-is-unable-to-open-the-mrl/
|
||||
作者：[Abhishek Prakash][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
@ -0,0 +1,100 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (DevOps is a solution to burnout worth investing in)
|
||||
[#]: via: (https://opensource.com/article/20/1/devops-burnout-solution)
|
||||
[#]: author: (Dawn Parzych https://opensource.com/users/dawnparzych)
|
||||
|
||||
DevOps is a solution to burnout worth investing in
|
||||
======
|
||||
Instead of treating burnout once it kicks in, we need to do more to
|
||||
prevent it in the first place. Here is a reminder of the cause and a
|
||||
look at solutions.
|
||||
![A person choosing between several different incentives][1]
|
||||
|
||||
Not a day goes by that I don't see a tweet or hear somebody talking about burnout. Burnout is becoming a pervasive part of our lives, especially in tech and open source communities. In [_What you need to know about burnout in open source communities_,][2] I defined burnout and explored its causes, symptoms, and potential treatments. But a better question is about prevention: How do we change the underlying processes, cultures, and tools to prevent burnout from occurring in the first place?
|
||||
|
||||
### Burnout's catalyst is unplanned work
|
||||
|
||||
Let's start by reviewing what's known about the cause of burnout. In 2019, PagerDuty published [_Unplanned work: The human impact of an always-on world_][3]. More than 35% of the study's respondents are considering leaving their jobs due to stress and work/life balance issues, also known as burnout. Companies that utilize automation and have documented response plans have fewer unplanned incidents and less stressed employees.
|
||||
|
||||
Modern software organizations use automation and documented response plans to move faster. Moving faster is necessary to stay competitive. We are in this endless cycle where customers expect more, which puts more pressure on companies to deliver more and deliver it faster, which in turn creates pressure on employees.
|
||||
|
||||
However, it is possible to move fast while having protections to prevent unplanned work and burnout. The Accelerate State of DevOps Report has been tracking trends in DevOps for six years. It allows teams to benchmark against others in the industry as low, medium, high, or elite performers. One of the findings from the [2019 State of DevOps report][4] was: "Productivity can drive improvements in work/life balance and reductions in burnout, and organizations can make smart investments to support it."
|
||||
|
||||
Productivity means more work gets done. Therefore, more value is delivered. The catch to productivity is balance: Don't do more work in the short term at the expense of burning out your people. Processes and tooling need to be in place to prevent people from feeling overworked and overwhelmed.
|
||||
|
||||
To support productivity that does not lead to burnout, organizations need to make smart investments in tooling and reduce technical debt. Investing in tooling means purchasing useful and easy-to-use solutions. The preference for building rather than buying may lead productivity to decrease and burnout to emerge. How? Instead of focusing on building features that are competitive differentiators and help the company achieve key business objectives, the developers spend countless hours trying to build something that a vendor could have quickly provided.
|
||||
|
||||
As developers spend time building non-core solutions, technical debt accrues, and features are pushed out. Instead of building all the things, buy the tooling that supports the business but is not strategic, and build the things that are core to your business strategy. You wouldn't use development resources to build your own email program, so treat other tooling the same way. Twenty percent of tools used by low-performing teams are developed primarily in-house and proprietary to the organization, compared to 5% to 6% in medium, high, and elite teams.
|
||||
|
||||
### Worthwhile solutions to burnout
|
||||
|
||||
If you want to prevent burnout, here are some areas to invest in. It's no coincidence they overlap with frequent discussions [in DevOps articles][5].
|
||||
|
||||
#### Communication and collaboration
|
||||
|
||||
Communication is at the heart of everything we do. [Laurie Barth][6] sums it up nicely: "Over time, I've learned that the biggest source of failure is often due to people and teams. A lack of communication and coordination can cause serious problems." Use tools like videoconferencing, Confluence, and Slack to ensure communication and collaboration happen.
|
||||
|
||||
But create rules around the use of these tools. Make sure to turn off Slack notifications during off-hours. I disable my notifications from 6pm to 8am.
|
||||
|
||||
Define what type of communication is best for which situations. Slack is useful for real-time, ephemeral communication, but it can lead to people feeling the need to always be on. If they're not online, they may miss an important conversation. If major or minor decisions are made in a Slack thread, document those in a longer-living system of record, giving all team members access to the necessary information.
|
||||
|
||||
Trying to debug an incident? Communicate via Slack. Need to write up a post-incident review? Post that to Confluence or a wiki.
|
||||
|
||||
Videoconferencing tools like Zoom or BlueJeans help enable remote work. Having the ability to work remotely, part-time or full-time, can reduce the stress of commuting or relocating. Videoconferences make it easy to stay connected with distributed teams because sometimes it is easier to hash things out in a face-to-face conversation than over email or Slack.
|
||||
|
||||
These tools should not be used to encourage people to work while on vacation. Time off means time away from work to rest, recover, and recharge.
|
||||
|
||||
#### Releases and deploys
|
||||
|
||||
According to the 2019 State of DevOps report, elite teams deploy code 208 times more frequently than low performers, and their lead time from committing code to deployment is 106 times faster. It may seem that the more deploys you do, the greater the likelihood of burnout, but that isn't necessarily the case. Teams that utilize continuous delivery have processes in place to deploy safely.
|
||||
|
||||
First, separate releases from deploys—just because you deployed code doesn't mean that all users should have access to it. Ring deploys make features available to a small group of people, like internal employees or beta customers. These users can help you identify bugs or provide feedback to fine-tune a feature before releasing it widely.
|
||||
|
||||
Next, create feedback loops regarding the quality of a deployment. Things don't always go as planned when deploying your code. You need the ability to rapidly stop when things go wrong. Feedback loops include implementing monitoring and observability tools. By using telemetry data along with kill switches, you can quickly turn off a poorly behaving feature rather than rolling back an entire deployment.
|
||||
|
||||
Finally, run A/B tests and experiments to learn what customers respond to. A metrics-based approach provides insight into what works and what doesn't and can help you validate a hypothesis. Instead of creating technical debt with a partial feature, collect data to see if the feature provides the expected conversions early on. If it doesn't, don't release it.
|
||||
|
||||
#### Incident resolution
|
||||
|
||||
Part of resolving incidents means knowing what to do when something breaks. And constantly putting out fires can lead to burnout. We can't prevent all incidents from happening, but we can be better prepared. Running chaos experiments or game days with tools like Gremlin can help companies prepare for the unexpected.
|
||||
|
||||
With chaos experiments, you can learn how your systems, services, and applications respond under specific scenarios. Knowing how things behave when they're broken can shorten incident-resolution times. They can also help you identify and fix vulnerabilities before an incident occurs.
|
||||
|
||||
What can you automate to reduce toil during incident resolution? For example, when you're actively working on an incident, can a Slack channel dedicated to the incident be automatically generated? Or can you create [feature flags][7] with a solution like LaunchDarkly (full disclosure: I work there) to perform common tasks during incident resolution? These could include:
|
||||
|
||||
* Dynamic configuration changes, like automatically adjusting logging levels to collect more information when an alert is triggered
|
||||
* Load-shedding to disable non-critical elements when systems are under heavy load to ensure essential tasks complete
|
||||
* Kill switches or circuit breakers to turn off features when they are impacting your service reliability
|
||||
|
||||
|
||||
|
||||
### It's not magic
|
||||
|
||||
There is no magic bullet to resolve burnout; it requires having the right people, processes, and tools. The people help create an environment of psychological safety where people are free to ask questions, experiment, make mistakes, and be creative. Think about what is most important to your organization, and invest in the right tools to support those goals and the people working towards them.
|
||||
|
||||
This month we look at ways to balance your workload, gracefully say "no," and avoid burnout.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/20/1/devops-burnout-solution
|
||||
|
||||
作者：[Dawn Parzych][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/dawnparzych
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/BUSINESS_incentives.png?itok=IhIL1xyT (A person choosing between several different incentives)
|
||||
[2]: https://opensource.com/article/19/11/burnout-open-source-communities
|
||||
[3]: https://www.pagerduty.com/resources/reports/unplanned-work/
|
||||
[4]: https://services.google.com/fh/files/misc/state-of-devops-2019.pdf
|
||||
[5]: https://opensource.com/tags/devops
|
||||
[6]: https://laurieontech.com/
|
||||
[7]: https://martinfowler.com/articles/feature-toggles.html
|
||||
@ -0,0 +1,52 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (Industrial Internet Consortium teams up with blockchain-focused security group)
|
||||
[#]: via: (https://www.networkworld.com/article/3512062/industrial-internet-consortium-teams-up-with-blockchain-focused-security-group.html)
|
||||
[#]: author: (Jon Gold https://www.networkworld.com/author/Jon-Gold/)
|
||||
|
||||
Industrial Internet Consortium teams up with blockchain-focused security group
|
||||
======
|
||||
A merger between a prominent industrial-IoT umbrella group and a blockchain-centered corporate memebership program highlights a new focus on bringing finished IoT solutions to market.
|
||||
Leo Wolfert / Getty Images
|
||||
|
||||
The Industrial Internet Consortium and the Trusted IoT Alliance announced today that they would merge memberships, in an effort to drive more collaborative approaches to [industrial IoT][1] and help create more market-ready products.
|
||||
|
||||
The Trusted IoT Alliance will now operate under the aegis of the IIC, a long-standing umbrella group for vendors operating in the IIoT market. The idea is to help create more standardized approaches to common use cases in IIoT, enabling companies to get solutions to market more quickly.
|
||||
|
||||
[[Get regularly scheduled insights by signing up for Network World newsletters.]][2]
|
||||
|
||||
“This consolidation will strengthen the ability of the IIC to provide guidance and advance best practices on the uses of distributed-ledger technology across industries, and boost the commercialization of these products and services,” said 451 Research senior [blockchain][3] and DLT analyst Csilla Zsigri in a statement.
|
||||
|
||||
Gartner vice president and analyst Al Velosa said that it’s possible the move to team up with TIoTA was driven in part by a new urgency to reach potential customers. Where other players in the IoT marketplace, like the major cloud vendors, have raked in billions of dollars in revenue, the IIoT vendors themselves haven’t been as quick to hit their sales targets. “This approach is them trying to explore new vectors for revenue that they haven’t before,” Velosa said in an interview.
|
||||
|
||||
The IIC, whose founding members include Cisco, IBM, Intel, AT&T and GE, features 19 different working groups, covering everything from IIoT technology itself to security to marketing to strategy. Adding TIoTA’s blockchain focus to the mix could help answer questions about security, which are centrally important to the continued success of enterprise and industrial IoT products.
|
||||
|
||||
Indeed, research from Gartner released late last year shows that IoT users are already gravitating toward blockchain and other distributed-ledger technologies. Fully three-quarters of IoT technology adopters in the U.S. have either brought that type of technology into their stack already or are planning to do so by the end of 2020. While almost two-thirds of respondents to the survey cited security and trust as the biggest drivers of their embrace of blockchain, almost as many noted that the technology had allowed them to increase business efficiency and lower costs.
|
||||
|
||||
**[ Also see [What is edge computing?][4] and [How edge networking and IoT will reshape data centers][5].]**
|
||||
|
||||
Join the Network World communities on [Facebook][6] and [LinkedIn][7] to comment on topics that are top of mind.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.networkworld.com/article/3512062/industrial-internet-consortium-teams-up-with-blockchain-focused-security-group.html
|
||||
|
||||
作者：[Jon Gold][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://www.networkworld.com/author/Jon-Gold/
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://www.networkworld.com/article/3243928/what-is-the-industrial-internet-of-things-essentials-of-iiot.html
|
||||
[2]: https://www.networkworld.com/newsletters/signup.html
|
||||
[3]: https://www.networkworld.com/article/3386881/why-blockchain-might-be-coming-to-an-iot-implementation-near-you.html
|
||||
[4]: https://www.networkworld.com/article/3224893/internet-of-things/what-is-edge-computing-and-how-it-s-changing-the-network.html
|
||||
[5]: https://www.networkworld.com/article/3291790/data-center/how-edge-networking-and-iot-will-reshape-data-centers.html
|
||||
[6]: https://www.facebook.com/NetworkWorld/
|
||||
[7]: https://www.linkedin.com/company/network-world
|
||||
@ -1,234 +0,0 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (File sharing with Git)
|
||||
[#]: via: (https://opensource.com/article/19/4/file-sharing-git)
|
||||
[#]: author: (Seth Kenlon https://opensource.com/users/seth)
|
||||
|
||||
File sharing with Git
|
||||
======
|
||||
SparkleShare is an open source, Git-based, Dropbox-style file sharing
|
||||
application. Learn more in our series about little-known uses of Git.
|
||||
![][1]
|
||||
|
||||
[Git][2] is one of those rare applications that has managed to encapsulate so much of modern computing into one program that it ends up serving as the computational engine for many other applications. While it's best-known for tracking source code changes in software development, it has many other uses that can make your life easier and more organized. In this series leading up to Git's 14th anniversary on April 7, we'll share seven little-known ways to use Git. Today, we'll look at SparkleShare, which uses Git as the backbone for file sharing.
|
||||
|
||||
### Git for file sharing
|
||||
|
||||
One of the nice things about Git is that it's inherently distributed. It's built to share. Even if you're sharing a repository just with other computers on your own network, Git brings transparency to the act of getting files from a shared location.
|
||||
|
||||
As interfaces go, Git is pretty simple. It varies from user to user, but the common incantation when sitting down to get some work done is just **git pull** or maybe the slightly more complex **git pull && git checkout -b my-branch**. Still, for some people, the idea of _entering a command_ into their computer at all is confusing or bothersome. Computers are meant to make life easy, and computers are good at repetitious tasks, and so there are easier ways to share files with Git.
|
||||
|
||||
### SparkleShare
|
||||
|
||||
The [SparkleShare][3] project is a cross-platform, open source, Dropbox-style file sharing application based on Git. It automates all Git commands, triggering the add, commit, push, and pull processes with the simple act of dragging-and-dropping a file into a specially designated SparkleShare directory. Because it is based on Git, you get fast, diff-based pushes and pulls, and you inherit all the benefits of Git version control and backend infrastructure (like Git hooks). It can be entirely self-hosted, or you can use it with Git hosting services like [GitLab][4], GitHub, Bitbucket, and others. Furthermore, because it's basically just a frontend to Git, you can access your SparkleShare files on devices that may not have a SparkleShare client but do have Git clients.
|
||||
|
||||
Just as you get all the benefits of Git, you also get all the usual Git restrictions: It's impractical to use SparkleShare to store hundreds of photos and music and videos because Git is designed and optimized for text. Git certainly has the capability to store large files of binary data but it is designed to track history, so once a file is added to it, it's nearly impossible to completely remove it. This somewhat limits the usefulness of SparkleShare for some people, but it makes it ideal for many workflows, including [calendaring][5].
|
||||
|
||||
#### Installing SparkleShare
|
||||
|
||||
SparkleShare is cross-platform, with installers for Windows and Mac available from its [website][6]. For Linux, there's a [Flatpak][7] in your software installer, or you can run these commands in a terminal:
|
||||
|
||||
|
||||
```
|
||||
$ sudo flatpak remote-add flathub <https://flathub.org/repo/flathub.flatpakrepo>
|
||||
$ sudo flatpak install flathub org.sparkleshare.SparkleShare
|
||||
```
|
||||
|
||||
### Creating a Git repository
|
||||
|
||||
SparkleShare isn't software-as-a-service (SaaS). You run SparkleShare on your computer to communicate with a Git repository—SparkleShare doesn't store your data. If you don't have a Git repository to sync a folder with yet, you must create one before launching SparkleShare. You have three options: hosted Git, self-hosted Git, or self-hosted SparkleShare.
|
||||
|
||||
#### Git hosting
|
||||
|
||||
SparkleShare can use any Git repository you can access for storage, so if you have or create an account with GitLab or any other hosting service, it can become the backend for your SparkleShare. For example, the open source [Notabug.org][8] service is a Git hosting service like GitHub and GitLab, but unique enough to prove SparkleShare's flexibility. Creating a new repository differs from host to host depending on the user interface, but all of the major ones follow the same general model.
|
||||
|
||||
First, locate the button in your hosting service to create a new project or repository and click on it to begin. Then step through the repository creation process, providing a name for your repository, privacy level (repositories often default to being public), and whether or not to initialize the repository with a README file. Whether you need a README or not, enable an initial README file. Starting a repository with a file isn't strictly necessary, but it forces the Git host to instantiate a **master** branch in the repository, which helps ensure that frontend applications like SparkleShare have a branch to commit and push to. It's also useful for you to see a file, even if it's an almost empty README file, to confirm that you have connected.
|
||||
|
||||
![Creating a Git repository][9]
|
||||
|
||||
Once you've created a repository, obtain the URL it uses for SSH clones. You can get this URL the same way anyone gets any URL for a Git project: navigate to the page of the repository and look for the **Clone** button or field.
|
||||
|
||||
![Cloning a URL on GitHub][10]
|
||||
|
||||
Cloning a GitHub URL.
|
||||
|
||||
![Cloning a URL on GitLab][11]
|
||||
|
||||
Cloning a GitLab URL.
|
||||
|
||||
This is the address SparkleShare uses to reach your data, so make note of it. Your Git repository is now configured.
|
||||
|
||||
#### Self-hosted Git
|
||||
|
||||
You can use SparkleShare to access a Git repository on any computer you have access to. No special setup is required, aside from a bare Git repository. However, if you want to give access to your Git repository to anyone else, then you should run a Git manager like [Gitolite][12] or SparkleShare's own Dazzle server to help you manage SSH keys and accounts. At the very least, create a user specific to Git so that users with access to your Git repository don't also automatically gain access to the rest of your server.
|
||||
|
||||
Log into your server as the Git user (or yourself, if you're very good at managing user and group permissions) and create a repository:
|
||||
|
||||
|
||||
```
|
||||
$ mkdir ~/sparkly.git
|
||||
$ cd ~/sparkly.git
|
||||
$ git init --bare .
|
||||
```
|
||||
|
||||
Your Git repository is now configured.
|
||||
|
||||
#### Dazzle
|
||||
|
||||
SparkleShare's developers provide a Git management system called [Dazzle][13] to help you self-host Git repositories.
|
||||
|
||||
On your server, download the Dazzle application to some location in your path:
|
||||
|
||||
|
||||
```
|
||||
$ curl <https://raw.githubusercontent.com/hbons/Dazzle/master/dazzle.sh> \
|
||||
\--output ~/bin/dazzle
|
||||
$ chmod +x ~/bin/dazzle
|
||||
```
|
||||
|
||||
Dazzle sets up a user specific to Git and SparkleShare and also implements access rights based on keys generated by the SparkleShare application. For now, just set up a project:
|
||||
|
||||
|
||||
```
|
||||
`$ dazzle create sparkly`
|
||||
```
|
||||
|
||||
Your server is now configured as a SparkleShare host.
|
||||
|
||||
### Configuring SparkleShare
|
||||
|
||||
When you launch SparkleShare for the first time, you are prompted to configure what server you want SparkleShare to use for storage. This process may feel like a first-run setup wizard, but it's actually the usual process for setting up a new shared location within SparkleShare. Unlike many shared drive applications, with SparkleShare you can have several locations configured at once. The first shared location you configure isn't any more significant than any shared location you may set up later, and you're not signing up with SparkleShare or any other service. You're just pointing SparkleShare at a Git repository so that it knows what to keep your first SparkleShare folder in sync with.
|
||||
|
||||
On the first screen, identify yourself by whatever means you want on record in the Git commits that SparkleShare makes on your behalf. You can use anything, even fake information that resolves to nothing. It's purely for the commit messages, which you may never even see if you have no interest in reviewing the Git backend processes.
|
||||
|
||||
The next screen prompts you to choose your hosting type. If you are using GitLab, GitHub, Planio, or Bitbucket, then select the appropriate one. For anything else, select **Own server**.
|
||||
|
||||
![Choosing a Sparkleshare host][14]
|
||||
|
||||
At the bottom of this screen, you must enter the SSH clone URL. If you're self-hosting, the address is something like **<ssh://username@example.com>** and the remote path is the absolute path to the Git repository you created for this purpose.
|
||||
|
||||
Based on my self-hosted examples above, the address to my imaginary server is **<ssh://git@example.com:22122>** (the **:22122** indicates a nonstandard SSH port) and the remote path is **/home/git/sparkly.git**.
|
||||
|
||||
If I use my Notabug.org account instead, the address from the example above is **[git@notabug.org][15]** and the path is **seth/sparkly.git**.
|
||||
|
||||
SparkleShare will fail the first time it attempts to connect to the host because you have not yet copied the SparkleShare client ID (an SSH key specific to the SparkleShare application) to the Git host. This is expected, so don't cancel the process. Leave the SparkleShare setup window open and obtain the client ID from the SparkleShare icon in your system tray. Then copy the client ID to your clipboard so you can add it to your Git host.
|
||||
|
||||
![Getting the client ID from Sparkleshare][16]
|
||||
|
||||
#### Adding your client ID to a hosted Git account
|
||||
|
||||
Minor UI differences aside, adding an SSH key (which is all the client ID is) is basically the same process on any hosting service. In your Git host's web dashboard, navigate to your user settings and find the **SSH Keys** category. Click the **Add New Key** button (or similar) and paste the contents of your SparkleShare client ID.
|
||||
|
||||
![Adding an SSH key][17]
|
||||
|
||||
Save the key. If you want someone else, such as collaborators or family members, to be able to access this same repository, they must provide you with their SparkleShare client ID so you can add it to your account.
|
||||
|
||||
#### Adding your client ID to a self-hosted Git account
|
||||
|
||||
A SparkleShare client ID is just an SSH key, so copy and paste it into your Git user's **~/.ssh/authorized_keys** file.
|
||||
|
||||
#### Adding your client ID with Dazzle
|
||||
|
||||
If you are using Dazzle to manage your SparkleShare projects, add a client ID with this command:
|
||||
|
||||
|
||||
```
|
||||
`$ dazzle link`
|
||||
```
|
||||
|
||||
When Dazzle prompts you for the ID, paste in the client ID found in the SparkleShare menu.
|
||||
|
||||
### Using SparkleShare
|
||||
|
||||
Once you've added your client ID to your Git host, click the **Retry** button in the SparkleShare window to finish setup. When it's finished cloning your repository, you can close the SparkleShare setup window, and you'll find a new **SparkleShare** folder in your home directory. If you set up a Git repository with a hosting service and chose to include a README or license file, you can see them in your SparkleShare directory.
|
||||
|
||||
![Sparkleshare file manager][18]
|
||||
|
||||
Otherwise, there are some hidden directories, which you can see by revealing hidden directories in your file manager.
|
||||
|
||||
![Showing hidden files in GNOME][19]
|
||||
|
||||
You use SparkleShare the same way you use any directory on your computer: you put files into it. Anytime a file or directory is placed into a SparkleShare folder, it's copied in the background to your Git repository.
|
||||
|
||||
#### Excluding certain files
|
||||
|
||||
Since Git is designed to remember _everything_ , you may want to exclude specific file types from ever being recorded. There are a few reasons to manage excluded files. By defining files that are off limits for SparkleShare, you can avoid accidental copying of large files. You can also design a scheme for yourself that enables you to store files that logically belong together (MIDI files with their **.flac** exports, for instance) in one directory, but manually back up the large files yourself while letting SparkleShare back up the text-based files.
|
||||
|
||||
If you can't see hidden files in your system's file manager, then reveal them. Navigate to your SparkleShare folder, then to the directory representing your repository, locate a file called **.gitignore** , and open it in a text editor. You can enter file extensions or file names, one per line, into **.gitignore** , and any file matching what you list will be (as the file name suggests) ignored.
|
||||
|
||||
|
||||
```
|
||||
Thumbs.db
|
||||
$RECYCLE.BIN/
|
||||
.DS_Store
|
||||
._*
|
||||
.fseventsd
|
||||
.Spotlight-V100
|
||||
.Trashes
|
||||
.directory
|
||||
.Trash-*
|
||||
*.wav
|
||||
*.ogg
|
||||
*.flac
|
||||
*.mp3
|
||||
*.m4a
|
||||
*.opus
|
||||
*.jpg
|
||||
*.png
|
||||
*.mp4
|
||||
*.mov
|
||||
*.mkv
|
||||
*.avi
|
||||
*.pdf
|
||||
*.djvu
|
||||
*.epub
|
||||
*.od{s,t}
|
||||
*.cbz
|
||||
```
|
||||
|
||||
You know the types of files you encounter most often, so concentrate on the ones most likely to sneak their way into your SparkleShare directory. If you want to exercise a little overkill, you can find good collections of **.gitignore** files on Notabug.org and also on the internet at large.
|
||||
|
||||
With those entries in your **.gitignore** file, you can place large files that you don't want sent to your Git host in your SparkleShare directory, and SparkleShare will ignore them entirely. Of course, that means it's up to you to make sure they get onto a backup or distributed to your SparkleShare collaborators through some other means.
|
||||
|
||||
### Automation
|
||||
|
||||
[Automation][20] is part of the silent agreement we have with computers: they do the repetitious, boring stuff that we humans either aren't very good at doing or aren't very good at remembering. SparkleShare is a nice, simple way to automate the routine distribution of data. It isn't right for every Git repository, by any means. It doesn't have an interface for advanced Git functions; it doesn't have a pause button or a manual override. And that's OK because its scope is intentionally limited. SparkleShare does what SparkleShare sets out to do, it does it well, and it's one Git repository you won't have to think about.
|
||||
|
||||
If you have a use for that kind of steady, invisible automation, give SparkleShare a try.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/19/4/file-sharing-git
|
||||
|
||||
作者：[Seth Kenlon (Red Hat, Community Moderator)][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/seth
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/rh_003499_01_cloud21x_cc.png?itok=5UwC92dO
|
||||
[2]: https://git-scm.com/
|
||||
[3]: http://www.sparkleshare.org/
|
||||
[4]: http://gitlab.com
|
||||
[5]: https://opensource.com/article/19/4/calendar-git
|
||||
[6]: http://sparkleshare.org
|
||||
[7]: /business/16/8/flatpak
|
||||
[8]: http://notabug.org
|
||||
[9]: https://opensource.com/sites/default/files/uploads/git-new-repo.jpg (Creating a Git repository)
|
||||
[10]: https://opensource.com/sites/default/files/uploads/github-clone-url.jpg (Cloning a URL on GitHub)
|
||||
[11]: https://opensource.com/sites/default/files/uploads/gitlab-clone-url.jpg (Cloning a URL on GitLab)
|
||||
[12]: http://gitolite.org
|
||||
[13]: https://github.com/hbons/Dazzle
|
||||
[14]: https://opensource.com/sites/default/files/uploads/sparkleshare-host.jpg (Choosing a Sparkleshare host)
|
||||
[15]: mailto:git@notabug.org
|
||||
[16]: https://opensource.com/sites/default/files/uploads/sparkleshare-clientid.jpg (Getting the client ID from Sparkleshare)
|
||||
[17]: https://opensource.com/sites/default/files/uploads/git-ssh-key.jpg (Adding an SSH key)
|
||||
[18]: https://opensource.com/sites/default/files/uploads/sparkleshare-file-manager.jpg (Sparkleshare file manager)
|
||||
[19]: https://opensource.com/sites/default/files/uploads/gnome-show-hidden-files.jpg (Showing hidden files in GNOME)
|
||||
[20]: /downloads/ansible-quickstart
|
||||
@ -1,73 +0,0 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (lxbwolf)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (5 predictions for Kubernetes in 2020)
|
||||
[#]: via: (https://opensource.com/article/20/1/kubernetes-2020)
|
||||
[#]: author: (Scott McCarty https://opensource.com/users/fatherlinux)
|
||||
|
||||
5 predictions for Kubernetes in 2020
|
||||
======
|
||||
Plus, a look back at the most popular Kubernetes articles on the site in
|
||||
2019.
|
||||
![Person drinking a hat drink at the computer][1]
|
||||
|
||||
How do you track a wildly popular project like Kubernetes? How do you figure out where it’s going? If you are contributing to the project or participating in Special Interest Groups (SIGs), you might gain insight by osmosis, but for those of you with day jobs that don’t include contributing to Kubernetes, you might like a little help reading the tea leaves. With a fast-moving project like Kubernetes, the end of the year is an excellent time to take a look at the past year to gain insight into the next one.
|
||||
|
||||
This year, Kubernetes made a lot of progress. Aside from inspecting code, documentation, and meeting notes, another good source is blog entries. To gain some insights, I took a look at the top ten Kubernetes articles on Opensource.com. These articles give us insight into what topics people are interested in reading, but just as importantly, what articles people are interested in writing. Let’s dig in!
|
||||
|
||||
(Get the full list of top 10 Kubernetes articles from 2019 at the end.)
|
||||
|
||||
First, I would point out that five of these articles tackle the expansion of workloads and where they can run. This expansion of workloads includes data science, PostgreSQL, InfluxDB, and Grafana (as a workload, not just to monitor the cluster itself) and Edge. Historically, Kubernetes and containers in general have mostly run on top of virtual machines, especially when run on infrastructure provided by cloud providers. With this interest in Kubernetes at the edge, it’s another sign that end users are genuinely interested in Kubernetes on bare metal (see also [Kubernetes on metal with OpenShift][2]).
|
||||
|
||||
Next, there seems to be a lot of hunger for operational knowledge and best practices with Kubernetes. From [Kubernetes Operators][3], to [Kubernetes Controllers][4], from [Secrets][5] to [ConfigMaps][6], developers and operators alike are looking for best practices and ways to simplify workload deployment and management. Often we get caught up in the actual configuration example, or how people do it, and don’t take a step back to realize that all of these fall into the bucket of how to operationalize the deployment of applications (not how to install or run Kubernetes itself).
|
||||
|
||||
Finally, people seem to be really interested in getting started. In fact, there is so much information on how to build Kubernetes that it intimidates people and gets them down the wrong path. A couple of the top articles focus on why you should learn to run applications on Kubernetes instead of concentrating on installing it. Like best practices, people often don’t take a step back to analyze where they should invest their time when getting started. I have always advocated for, where possible, spending limited time and money on using technology instead of building it.
|
||||
|
||||
### 5 predictions for Kubernetes in 2020
|
||||
|
||||
So, looking back at those themes from 2019, what does this tell us about where 2020 is going? Well, combining insight from these articles with my own broad purview, I want to share my thoughts for 2020 and beyond:
|
||||
|
||||
1. Expansion of workloads. I would keep my eye on high-performance computing, AI/ML, and stateful workloads using Operators.
|
||||
|
||||
2. More concrete best practices, especially around mature standards like PCI, HIPAA, NIST, etc.
|
||||
|
||||
3. Increased security around rootless and higher security [runtimes classes][7] (like [gVisor][8], [Kata Containers][9], etc.)
|
||||
|
||||
4. Better standardization on Kubernetes manifests as the core artifact for deployment in development and sharing applications between developers. Things like [podman generate kube][10], [podman play kube][11], and all in one Kubernetes environments like [CodeReady Containers (CRC)][12]
|
||||
|
||||
5. An ever-wider ecosystem of network, storage and specialized hardware (GPUs, etc.) vendors creating best of breed solutions for Kubernetes (in free software, we believe that open ecosystems are better than vertically integrated solutions)
|
||||
|
||||
|
||||
|
||||
|
||||
I'm looking forward to another great year in Kubernetes!
|
||||
|
||||
**Top 10 Kubernetes articles for 2019**
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/20/1/kubernetes-2020
|
||||
|
||||
作者：[Scott McCarty][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/fatherlinux
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/coffee_tea_laptop_computer_work_desk.png?itok=D5yMx_Dr (Person drinking a hat drink at the computer)
|
||||
[2]: https://blog.openshift.com/kubernetes-on-metal-with-openshift/
|
||||
[3]: https://kubernetes.io/docs/concepts/extend-kubernetes/operator/
|
||||
[4]: https://kubernetes.io/docs/concepts/architecture/controller/
|
||||
[5]: https://kubernetes.io/docs/concepts/configuration/secret/
|
||||
[6]: https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/
|
||||
[7]: https://kubernetes.io/docs/concepts/containers/runtime-class/
|
||||
[8]: https://gvisor.dev/
|
||||
[9]: https://katacontainers.io/
|
||||
[10]: https://developers.redhat.com/blog/2019/01/29/podman-kubernetes-yaml/
|
||||
[11]: https://www.redhat.com/en/blog/rhel-81-minor-release-major-new-container-capabilities
|
||||
[12]: https://developers.redhat.com/products/codeready-containers/overview
|
||||
231
translated/tech/20190405 File sharing with Git.md
Normal file
231
translated/tech/20190405 File sharing with Git.md
Normal file
@ -0,0 +1,231 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (wxy)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (File sharing with Git)
|
||||
[#]: via: (https://opensource.com/article/19/4/file-sharing-git)
|
||||
[#]: author: (Seth Kenlon)
|
||||
|
||||
用 Git 共享文件
|
||||
======
|
||||
|
||||
> SparkleShare 是一个开源的基于 Git、Dropbox 风格的文件共享应用程序。在我们的系列文章中了解有关 Git 鲜为人知的用法。
|
||||
|
||||
![][1]
|
||||
|
||||
[Git][2] 是一个少有的能将如此多的现代计算封装到一个程序之中的应用程序，它可以用作许多其他应用程序的计算引擎。虽然它以跟踪软件开发中的源代码更改而闻名，但它还有许多其他用途，可以让你的生活更轻松、更有条理。在这个 Git 系列中，我们将分享七种鲜为人知的使用 Git 的方法。
|
||||
|
||||
今天，我们将看看 SparkleShare，它使用 Git 作为文件共享的基础。
|
||||
|
||||
### 用于文件共享的 Git
|
||||
|
||||
Git 的优点之一是它具有固有的分发能力。它可用来建立共享。即使你只是与自己网络上的其他计算机共享资源库，Git 也会为从共享位置获取文件的行为带来透明性。
|
||||
|
||||
随着其界面的发展，Git 变得非常简单。虽然因用户而异，他们坐下来完成一些工作时的共同点仅仅是 `git pull` 或稍微复杂一点的 `git pull && git checkout -b my-branch`。但是，对于某些人来说，将*命令输入*到他们的计算机中的做法完全是令人困惑或烦恼的。计算机旨在使生活变得轻松，计算机擅长重复性工作，因此有更简便的方法可以与 Git 共享文件。
|
||||
|
||||
### SparkleShare
|
||||
|
||||
[SparkleShare][3] 项目是一个基于 Git 的跨平台的开源的 Dropbox 式的文件共享应用程序。它通过将文件拖放到专门指定的 SparkleShare 目录中的简单操作，自动执行所有 Git 命令，触发添加、提交、推送和拉取过程。因为它基于 Git，所以你可以获得基于差异（diff）的快速推送和拉取，并且继承了 Git 版本控制和后端基础设施（如 Git 挂钩）的所有优点。它可以完全自托管，也可以将其与 [GitLab][4]、GitHub、Bitbucket 等 Git 托管服务一起使用。此外，由于它基本上只是一个 Git 的前端，因此你可以在可能没有 SparkleShare 客户端但有 Git 客户端的设备上访问 SparkleShare 中的文件。
|
||||
|
||||
正如你获得 Git 的所有好处一样，你也会受到所有常见的 Git 限制：使用 SparkleShare 存储数百张照片、音乐和视频是不切实际的，因为 Git 是为文本而设计和优化的。Git 当然可以存储二进制文件的大文件，但是因为它可以跟踪历史记录，因此一旦将文件添加到其中，几乎就不可能完全删除它。这在某种程度上限制了 SparkleShare 对某些人的实用性，但使其非常适合许多工作流程，包括 [日程安排][5]。
|
||||
|
||||
#### 安装 SparkleShare
|
||||
|
||||
SparkleShare 是跨平台的，可从[网站][6]获得适用于 Windows 和 Mac 的安装程序。对于 Linux，有一个 [Flatpak][7] 安装包，或者你可以在终端中运行以下命令：
|
||||
|
||||
```
|
||||
$ sudo flatpak remote-add flathub https://flathub.org/repo/flathub.flatpakrepo
|
||||
$ sudo flatpak install flathub org.sparkleshare.SparkleShare
|
||||
```
|
||||
|
||||
### 创建一个 Git 存储库
|
||||
|
||||
SparkleShare 并不是软件即服务（SaaS）。你在计算机上运行 SparkleShare 以与 Git 存储库进行通信，而 SparkleShare 并不存储你的数据。如果你还没有与文件夹同步的 Git 存储库，则必须在启动 SparkleShare 之前创建一个文件夹。你有三个选择：托管的 Git、自托管 Git 或自托管 SparkleShare。
|
||||
|
||||
#### 托管的 Git
|
||||
|
||||
SparkleShare 可以使用你可以访问的任何 Git 存储库进行存储，因此，如果你拥有（或可在其中创建的）GitLab 或任何其他托管服务的帐户，则它可以成为 SparkleShare 的后端。例如，开源 [Notabug.org][8] 服务是一个类似于 GitHub 和 GitLab 的 Git 托管服务，但其独特性足以证明 SparkleShare 的灵活性。根据用户界面的不同，不同的托管服务创建新存储库的方法也有所不同，但是所有主要存储库都遵循相同的通用模型。
|
||||
|
||||
首先，在托管服务中找到创建一个新项目或存储库的按钮，单击它以开始。然后逐步完成存储库的创建过程，为存储库提供名称、隐私级别（存储库通常默认为公共），以及是否使用 `README` 文件初始化存储库。无论你是否需要个 `README` 文件，请初始化建立一个。使用一个文件创立存储库不是绝对必要的，但是它会强制 Git 主机实例化存储库中的 `master` 分支，这有助于确保前端应用程序（例如 SparkleShare）具有要提交并推送的分支。即使文件几乎是空的 `README` 文件，也可以用来查看该文件以确认你已连接成功。
|
||||
|
||||
![Creating a Git repository][9]
|
||||
|
||||
创建存储库后，获取其用于 SSH 克隆的 URL。你可以像获取任何人从 Git 项目获得其 URL 一样获得此 URL：导航至存储库页面并查找 “Clone” 按钮或字段。
|
||||
|
||||
![Cloning a URL on GitHub][10]
|
||||
|
||||
*GitHub 的克隆 URL。*
|
||||
|
||||
![Cloning a URL on GitLab][11]
|
||||
|
||||
*GitLab 的克隆 URL。*
|
||||
|
||||
这是 SparkleShare 用于获取数据的地址，因此请记下它。你的 Git 存储库现已配置好。
|
||||
|
||||
|
||||
#### 自托管的 Git
|
||||
|
||||
你可以使用 SparkleShare 访问你有权访问的任何计算机上的 Git 存储库。除了一个 Git 裸存储库外，无需任何特殊设置。但是，如果你想将对 Git 存储库的访问权授予其他任何人，则应运行 [Gitolite][12] 之类的 Git 管理器或 SparkleShare 自己的 Dazzle 服务器来帮助你管理 SSH 密钥和帐户。至少，创建一个特定于 Git 的用户，以便有权访问你的 Git 存储库的用户不会自动获得对服务器其余部分的访问权限。
|
||||
|
||||
以 Git 用户身份登录服务器（如果你非常擅长管理用户和组权限，则可以以自己的用户登录）并创建存储库：
|
||||
|
||||
```
|
||||
$ mkdir ~/sparkly.git
|
||||
$ cd ~/sparkly.git
|
||||
$ git init --bare .
|
||||
```
|
||||
|
||||
你的 Git 存储库现已配置好。
|
||||
|
||||
#### Dazzle
|
||||
|
||||
SparkleShare 的开发人员提供了一个名为 [Dazzle][13] 的 Git 管理系统，以帮助你自托管 Git 存储库。
|
||||
|
||||
在你的服务器上，将 Dazzle 应用程序下载到你的路径中的某个位置：
|
||||
|
||||
```
|
||||
$ curl https://raw.githubusercontent.com/hbons/Dazzle/master/dazzle.sh --output ~/bin/dazzle
|
||||
$ chmod +x ~/bin/dazzle
|
||||
```
|
||||
|
||||
Dazzle 设置了一个特定于 Git 和 SparkleShare 的用户，并且还基于 SparkleShare 应用程序生成的密钥实现了访问权限。现在，只需设置一个项目：
|
||||
|
||||
```
|
||||
$ dazzle create sparkly
|
||||
```
|
||||
|
||||
你的服务器现在已经配置好，可以用作 SparkleShare 托管了。
|
||||
|
||||
### 配置 SparkleShare
|
||||
|
||||
首次启动 SparkleShare 时，系统会提示你配置要让 SparkleShare 用于存储的服务器。这个过程可能看起来像一个首次运行的安装向导，但实际上是在 SparkleShare 中设置新共享位置的通常过程。与许多共享驱动器应用程序不同，使用 SparkleShare 可以一次配置多个位置。你配置的第一个共享位置并不比你以后可以设置的任何共享位置重要，并且你也没有注册 SparkleShare 或任何其他服务。你只是将 SparkleShare 指向 Git 存储库，以便它知道如何使第一个 SparkleShare 文件夹保持同步。
|
||||
|
||||
在第一个屏幕上，给出一个身份，SparkleShare 将在代表你进行的 Git 提交记录中使用这些信息。你可以使用任何内容，甚至可以不代表任何意义的伪造信息。它仅用于提交消息，如果你对审查 Git 后端进程没有兴趣，你可能甚至看不到它们。
|
||||
|
||||
下一个屏幕提示你选择主机类型。如果你使用的是 GitLab、GitHub、Planio 或 Bitbucket，则可以选择一个适当的。否则，请选择“自己的服务器”。
|
||||
|
||||
![Choosing a Sparkleshare host][14]
|
||||
|
||||
在此屏幕底部，您必须输入 SSH 的克隆 URL。如果你是自托管的 Git，则地址类似于 `<ssh://username@example.com>`，而远程路径是为此目的而创建的 Git 存储库的绝对路径。
|
||||
|
||||
根据上面的自托管示例，我虚构的服务器的地址为 `ssh://git@example.com:22122`（`:22122` 表示非标准的 SSH 端口），远程路径为 `/home/git/sparkly.git`。
|
||||
|
||||
如果我改用 Notabug.org 帐户，则上例中的地址为 `ssh://git@notabug.org`，路径为 `seth/sparkly.git`。
|
||||
|
||||
SparkleShare 首次尝试连接到主机时将失败，因为你尚未将 SparkleShare 客户端 ID（特定于 SparkleShare 应用程序的 SSH 密钥）复制到 Git 主机。这是预料之中的，所以不要取消该过程。将 SparkleShare 设置窗口保持打开状态，并从系统任务栏中的 SparkleShare 图标处获取客户端 ID。然后将客户端 ID 复制到剪贴板，以便可以将其添加到 Git 主机。
|
||||
|
||||
![Getting the client ID from Sparkleshare][16]
|
||||
|
||||
#### 将你的客户端 ID 添加到托管的 Git 帐户
|
||||
|
||||
除了较小的 UI 差异外，在任何托管服务上添加 SSH 密钥（所有客户端 ID 都是这样）的过程基本上是相同的。在你的 Git 主机的 Web 仪表板中，导航到你的用户设置，然后找到 “SSH 密钥”类别。单击“添加新密钥”按钮（或类似按钮），然后粘贴你的 SparkleShare 客户端 ID 的内容。
|
||||
|
||||
![Adding an SSH key][17]
|
||||
|
||||
保存密钥。如果你希望其他人（例如协作者或家庭成员）能够访问同一存储库，则他们必须向你提供其 SparkleShare 客户端 ID，以便你可以将其添加到帐户中。
|
||||
|
||||
#### 将你的客户端 ID 添加到自托管的 Git 帐户
|
||||
|
||||
SparkleShare 客户端 ID 只是一个 SSH 密钥，因此将其复制并粘贴到 Git 用户的 `~/.ssh/authorized_keys`文件中。
|
||||
|
||||
#### 使用 Dazzle 添加你的客户 ID
|
||||
|
||||
如果你使用 Dazzle 管理 SparkleShare 项目，请使用以下命令添加客户端 ID：
|
||||
|
||||
```
|
||||
$ dazzle link
|
||||
```
|
||||
|
||||
当 Dazzle 提示你输入该 ID 时，请粘贴在 SparkleShare 菜单中找到的客户端 ID。
|
||||
|
||||
### 使用 SparkleShare
|
||||
|
||||
将客户端 ID 添加到 Git 主机后，在 SparkleShare 窗口中单击“重试”按钮以完成设置。克隆存储库完成后，你可以关闭 SparkleShare 设置窗口，并在你的家目录中找到一个新的 `SparkleShare` 文件夹。如果你设置了带有托管服务的 Git 存储库，并选择包括 `README` 文件或许可证文件，则可以在 SparkleShare 目录中看到它们。
|
||||
|
||||
![Sparkleshare file manager][18]
|
||||
|
||||
此外，有一些隐藏目录，你可以通过在文件管理器中显示隐藏目录来查看。
|
||||
|
||||
![Showing hidden files in GNOME][19]
|
||||
|
||||
使用 SparkleShare 的方式与使用计算机上任何目录的方式相同：将文件放入其中。每当将文件或目录放入 SparkleShare 文件夹时，它都会在后台复制到你的 Git 存储库。
|
||||
|
||||
#### 排除某些文件
|
||||
|
||||
由于 Git 从设计上就是要记住*一切*，因此你可能希望从记录中排除特定的文件类型。排除一些文件是有原因的。通过定义摆脱 SparkleShare 限制的文件，可以避免意外复制大文件。你还可以为自己设计一种方案，使你可以将存储在一个目录中的逻辑上属于同一文件（例如，MIDI 文件及其 .flac 导出文件），但是可以自己手动备份大文件，而同时让 SparkleShare 备份基于文本的文件。
|
||||
|
||||
如果在系统的文件管理器中看不到隐藏的文件，请显示它们。导航到你的 SparkleShare 文件夹，然后到代表你的存储库的目录，找到一个名为 `.gitignore` 的文件，然后在文本编辑器中将其打开。你可以在 `.gitignore` 中输入文件扩展名或文件名（每行一个），任何与你列出的文件匹配的文件都会被忽略（如文件名所示）。
|
||||
|
||||
```
|
||||
Thumbs.db
|
||||
$RECYCLE.BIN/
|
||||
.DS_Store
|
||||
._*
|
||||
.fseventsd
|
||||
.Spotlight-V100
|
||||
.Trashes
|
||||
.directory
|
||||
.Trash-*
|
||||
*.wav
|
||||
*.ogg
|
||||
*.flac
|
||||
*.mp3
|
||||
*.m4a
|
||||
*.opus
|
||||
*.jpg
|
||||
*.png
|
||||
*.mp4
|
||||
*.mov
|
||||
*.mkv
|
||||
*.avi
|
||||
*.pdf
|
||||
*.djvu
|
||||
*.epub
|
||||
*.od{s,t}
|
||||
*.cbz
|
||||
```
|
||||
|
||||
你知道最经常遇到哪些文件类型，因此请集中精力处理最有可能潜入你的 SparkleShare 目录的文件。如果您想稍微矫枉过正一些，可以在 Notabug.org 以及整个网上找到 `.gitignore` 文件的好集合。
|
||||
|
||||
通过将这些条目保存在 `.gitignore` 文件中，你可以将不需要发送到 Git 主机的大文件放在 SparkleShare 目录中，SparkleShare 将完全忽略它们。当然，这意味着您需要确保它们可以备份或通过其他方式分发给你的 SparkleShare 合作者。
|
||||
|
||||
### 自动化
|
||||
|
||||
[自动化][20] 是我们与计算机达成的默契之一：计算机执行重复的、无聊的工作，而我们人类要么不擅长做这些，要么不擅长记忆这些。SparkleShare 是一种很好的、简单的自动执行例行数据分发的方法。无论如何，这并不适合每个 Git 存储库。它没有用于高级 Git 功能的接口，它没有暂停按钮或手动管理的操作。没关系，因为它的范围是有意限制的。SparkleShare 可以完成 SparkleShare 计划要做的事情，它做得很好，而且它是你无需关心的一个 Git 存储库。
|
||||
|
||||
如果你想使用这种稳定的、看不见的自动化，请尝试一下 SparkleShare。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/19/4/file-sharing-git
|
||||
|
||||
作者：[Seth Kenlon][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[wxy](https://github.com/wxy)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/seth
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/rh_003499_01_cloud21x_cc.png?itok=5UwC92dO
|
||||
[2]: https://git-scm.com/
|
||||
[3]: http://www.sparkleshare.org/
|
||||
[4]: http://gitlab.com
|
||||
[5]: https://opensource.com/article/19/4/calendar-git
|
||||
[6]: http://sparkleshare.org
|
||||
[7]: /business/16/8/flatpak
|
||||
[8]: http://notabug.org
|
||||
[9]: https://opensource.com/sites/default/files/uploads/git-new-repo.jpg (Creating a Git repository)
|
||||
[10]: https://opensource.com/sites/default/files/uploads/github-clone-url.jpg (Cloning a URL on GitHub)
|
||||
[11]: https://opensource.com/sites/default/files/uploads/gitlab-clone-url.jpg (Cloning a URL on GitLab)
|
||||
[12]: http://gitolite.org
|
||||
[13]: https://github.com/hbons/Dazzle
|
||||
[14]: https://opensource.com/sites/default/files/uploads/sparkleshare-host.jpg (Choosing a Sparkleshare host)
|
||||
[15]: mailto:git@notabug.org
|
||||
[16]: https://opensource.com/sites/default/files/uploads/sparkleshare-clientid.jpg (Getting the client ID from Sparkleshare)
|
||||
[17]: https://opensource.com/sites/default/files/uploads/git-ssh-key.jpg (Adding an SSH key)
|
||||
[18]: https://opensource.com/sites/default/files/uploads/sparkleshare-file-manager.jpg (Sparkleshare file manager)
|
||||
[19]: https://opensource.com/sites/default/files/uploads/gnome-show-hidden-files.jpg (Showing hidden files in GNOME)
|
||||
[20]: /downloads/ansible-quickstart
|
||||
@ -0,0 +1,67 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (lxbwolf)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (5 predictions for Kubernetes in 2020)
|
||||
[#]: via: (https://opensource.com/article/20/1/kubernetes-2020)
|
||||
[#]: author: (Scott McCarty https://opensource.com/users/fatherlinux)
|
||||
|
||||
2020 年对 Kubernetes 的 5 项预测
|
||||
======
|
||||
请先回顾下 2019 年网站上最受欢迎的 Kubernetes 的文章。
|
||||
![Person drinking a hat drink at the computer][1]
|
||||
|
||||
你怎么追踪一个广受欢迎的项目（如 Kubernetes）的发展轨迹？你怎么能了解它发展到什么程度了？如果你在为这个项目作贡献或加入了 SIG（Special Interest Group），可能你会在潜移默化中了解到它的发展轨迹，但如果你的全日工作不涉及到为 Kubernetes 作贡献，那么你可能需要一点关于未来的预测来帮助你了解。对于一个诸如 Kubernetes 的快速发展的项目，年末是回顾过去的一年和展望新的一年的最好时机。
|
||||
|
||||
今年，Kubernetes 取得了很大的进展。除了去查看源码、文档、会议笔记，你也可以去浏览博客。为了深入了解，我在 Opensource.com 上看了 Kubernetes 的 top 10 文章。通过这些文章，我们能了解开发者们更喜欢读和写哪些话题的文章。我们开始吧！
|
||||
|
||||
(2019 年末获取 Kubernetes 文章的 top 10。)
|
||||
|
||||
首先，我要指明这些文章中有 5 篇是关于 Kubernetes 工作负载的扩展以及它们可以运行在什么场景。这些工作负载涵盖数据科学、PostgreSQL、InfluxDB、Grafana（不仅仅监控集群本身）和 Edge。从历史角度看，Kubernetes 和容器都是在虚拟机上运行的，尤其是运行在由云提供的基础设施上时。抛开对于 Kubernetes 的兴趣因素，这也表明了终端用户们极度希望在裸机上安装 Kubernetes（参照[OpenShift 环境安装 Kubernetes][2]）。
|
||||
|
||||
其次，也有很多开发者希望了解操作相关的知识以及 Kubernetes 的最佳实践。从 [Kubernetes 操作][3] 到 [Kubernetes 控制器][4]，从 [Secrets][5] 到 [ConfigMaps][6]，开发者和运维人员都希望能找到简化部署和管理工作的最佳实践。我们经常纠结在怎么去修改配置文件或别人会怎么配置，而不去回头想想这些配置是怎么让应用部署运转的（不是怎么安装，也不是怎么运行 Kubernetes）。
|
||||
|
||||
最后，人们似乎对入门教程真的感兴趣。事实上，构建 Kubernetes 所需了解的信息太多了，以至于让人们望而却步，也使他们走了错误的路。流行度高的文章中有几篇讲述了为什么你需要了解用 Kubernetes 运行应用程序，而不仅仅是安装它。就是最佳实践类的文章一样，人们也通常不会回头分析在入门时他们应该在什么地方花费时间。我一直秉持的理念是，把有限的时间和金钱投入到如何使用某项技术上，而不是如何构建它。
|
||||
|
||||
### 2020 年对 Kubernetes 的 5 项预测
|
||||
|
||||
回顾下 2019 年的相关主题，这些主题告诉我们 2020 年将如何发展？结合这些文章中的观点，加上我自己的看法，我来分享下我对于 2020 年以及未来发展趋势的想法：
|
||||
|
||||
1. 工作负载扩展。我会关注高性能计算，AI/ML 以及使用 Operator 的有状态工作负载。
|
||||
|
||||
2. 更多的生产中的最佳实践，尤其是跟一些成熟的标准相关的，像 PCI，HIPAA，NIST 等等.
|
||||
|
||||
3. rootless 相关的更好的安全性和 [runtimes classes][7]（如 [gVisor][8]，[Kata Containers][9] 等等）更高的安全性。
|
||||
|
||||
4. 在部署和开发者们共享应用时，把 Kubernetes 清单的更好的规范标准作为部署的核心要素。如 [podman generate kube][10], [podman play kube][11], 还有多合一 Kubernetes 环境，如 [CodeReady Containers (CRC)][12]
|
||||
|
||||
5. 一个前所未有的网络、存储和专业硬件（如 GPU 等等）供应商的生态系统，为 Kubernetes 提供 BoB（译注：best of breed，单项最佳品牌）解决方案（在免费软件中，我们相信开放的生态系统好过垂直整合的解决方案）。
|
||||
|
||||
期待 Kubernetes 在新的一年里再创辉煌！
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/20/1/kubernetes-2020
|
||||
|
||||
作者：[Scott McCarty][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[lxbwolf](https://github.com/lxbwolf)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/fatherlinux
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/coffee_tea_laptop_computer_work_desk.png?itok=D5yMx_Dr (Person drinking a hat drink at the computer)
|
||||
[2]: https://blog.openshift.com/kubernetes-on-metal-with-openshift/
|
||||
[3]: https://kubernetes.io/docs/concepts/extend-kubernetes/operator/
|
||||
[4]: https://kubernetes.io/docs/concepts/architecture/controller/
|
||||
[5]: https://kubernetes.io/docs/concepts/configuration/secret/
|
||||
[6]: https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/
|
||||
[7]: https://kubernetes.io/docs/concepts/containers/runtime-class/
|
||||
[8]: https://gvisor.dev/
|
||||
[9]: https://katacontainers.io/
|
||||
[10]: https://developers.redhat.com/blog/2019/01/29/podman-kubernetes-yaml/
|
||||
[11]: https://www.redhat.com/en/blog/rhel-81-minor-release-major-new-container-capabilities
|
||||
[12]: https://developers.redhat.com/products/codeready-containers/overview
|
||||
Loading…
Reference in New Issue
Block a user