1_DevOps'ish

Free scanning for secrets? I like this latest GitHub offering!

Authors: Joe Betz (Google), Cici Huang (Google) In Kubernetes 1.26, the 1st alpha release of validating admission policies is available! Validating admission policies use the Common Expression Language (CEL) to offer a declarative, in-process alternative to validating admission webhooks . CEL was first introduced to Kubernetes for the Validation rules for CustomResourceDefinitions . This enhancement expands the use of CEL in Kubernetes to support a far wider range of admission use cases. Admission webhooks can be burdensome to develop and operate. Webhook developers must implement and maintain a webhook binary to handle admission requests. Also, admission webhooks are complex to operate. Each webhook must be deployed, monitored and have a well defined upgrade and rollback plan. To make matters worse, if a webhook times out or becomes unavailable, the Kubernetes control plane can become unavailable. This enhancement avoids much of this complexity of admission webhooks by embedding CEL expressions into Kubernetes resources instead of calling out to a remote webhook binary. For example, to set a limit on how many replicas a Deployment can have. Start by defining a validation policy: apiVersion : admissionregistration.k8s.io/v1alpha1 kind : ValidatingAdmissionPolicy metadata : name : "demo-policy.example.com" spec : matchConstraints : resourceRules : - apiGroups : ["apps" ] apiVersions : ["v1" ] operations : ["CREATE" , "UPDATE" ] resources : ["deployments" ] validations : - expression : "object.spec.replicas = 5" The expression field contains the CEL expression that is used to validate admission requests. matchConstraints declares what types of requests this ValidatingAdmissionPolicy is may validate. Next bind the policy to the appropriate resources: apiVersion : admissionregistration.k8s.io/v1alpha1 kind : ValidatingAdmissionPolicyBinding metadata : name : "demo-binding-test.example.com" spec : policy : "demo-policy.example.com" matchResources : namespaceSelector : - key : environment, operator : In, values : ["test" ] This ValidatingAdmissionPolicyBinding resource binds the above policy only to namespaces where the environment label is set to test . Once this binding is created, the kube-apiserver will begin enforcing this admission policy. To emphasize how much simpler this approach is than admission webhooks, if this example were instead implemented with a webhook, an entire binary would need to be developed and maintained just to perform a = check. In our review of a wide range of admission webhooks used in production, the vast majority performed relatively simple checks, all of which can easily be expressed using CEL. Validation admission policies are highly configurable, enabling policy authors to define policies that can be parameterized and scoped to resources as needed by cluster administrators. For example, the above admission policy can be modified to make it configurable: apiVersion : admissionregistration.k8s.io/v1alpha1 kind : ValidatingAdmissionPolicy metadata : name : "demo-policy.example.com" spec : paramKind : apiVersion : rules.example.com/v1 # You also need a CustomResourceDefinition for this API kind : ReplicaLimit matchConstraints : resourceRules : - apiGroups : ["apps" ] apiVersions : ["v1" ] operations : ["CREATE" , "UPDATE" ] resources : ["deployments" ] validations : - expression : "object.spec.replicas = params.maxReplicas" Here, paramKind defines the resources used to configure the policy and the expression uses the params variable to access the parameter resource. This allows multiple bindings to be defined, each configured differently. For example: apiVersion : admissionregistration.k8s.io/v1alpha1 kind : ValidatingAdmissionPolicyBinding metadata : name : "demo-binding-production.example.com" spec : policy : "demo-policy.example.com" paramsRef : name : "demo-params-production.example.com" matchResources : namespaceSelector : - key : environment, operator : In, values : ["production" ] apiVersion : rules.example.com/v1 # defined via a CustomResourceDefinition kind : ReplicaLimit metadata : name : "demo-params-production.example.com" maxReplicas : 1000 This binding and parameter resource pair limit deployments in namespaces with the environment label set to production to a max of 1000 replicas. You can then use a separate binding and parameter pair to set a different limit for namespaces in the test environment. I hope this has given you a glimpse of what is possible with validating admission policies! There are many features that we have not yet touched on. To learn more, read Validating Admission Policy . We are working hard to add more features to admission policies and make the enhancement easier to use. Try it out, send us your feedback and help us build a simpler alternative to admission webhooks! How do I get involved? If you want to get involved in development of admission policies, discuss enhancement roadmaps, or report a bug, you can get in touch with developers at SIG API Machinery .

In 2021, antisemitic incidents reached an all-time high in the U.S. According to the Anti-Defamation League (ADL), this increase represents the highest number ever recorded since the organization began tracking them in 1979. In addition to these attacks — assault, harassment, and vandalism — we’ve seen a number of influential individuals over the years making headlines for antisemitic comments and hate speech. It’s time organizations acknowledged the experiences of Jewish employees and included them in DEI efforts. The author, a DEI leader, reached out to Jewish leaders to understand and include their perspectives. Based on their input, here’s how leaders and individuals can support their Jewish employees and colleagues and fight antisemitism in their workplaces.

You know what really grinds my gears? Well, lots of things, but in this case, let’s talk about multi-cloud. Not my typical rant about multi-cloud not ever being a good best practice—because it’s not—but rather how companies talk about multi-cloud. HashiCorp just did a whole survey on how multi-cloud is the future, and at no point during that entire process did they define the term.

Pulsar aims to be a replacement for Atom users, and could challenge Visual Studio code as its development progresses further.

Neovim plugin for interacting with OpenAI GPT-3 chatbot, providing an easy interface for exploring GPT-3 and NLP. - GitHub - jackMort/ChatGPT.nvim: Neovim plugin for interacting with OpenAI GPT-3 c...

History rhymes. Federation, identity issues, and a hostile takeover. IRC was the communication platform of choice from the 90s until around 2000 when AIM took over. Around 2010, Freenode emerged as the go-to for the open-source crowd and then grew over the next decade to become the home for many software developers, DevOps professionals, and hobbyists. I’m thankful for the graduate math students that took the time to help me with my high school calculus on ##math. The events leading to the fal

Eufy lied to us about the security of its security cams.

Author: Swati Sehgal (Red Hat) The Device Plugin framework was introduced in the Kubernetes v1.8 release as a vendor independent framework to enable discovery, advertisement and allocation of external devices without modifying core Kubernetes. The feature graduated to Beta in v1.10. With the recent release of Kubernetes v1.26, Device Manager is now generally available (GA). Within the kubelet, the Device Manager facilitates communication with device plugins using gRPC through Unix sockets. Device Manager and Device plugins both act as gRPC servers and clients by serving and connecting to the exposed gRPC services respectively. Device plugins serve a gRPC service that kubelet connects to for device discovery, advertisement (as extended resources) and allocation. Device Manager connects to the Registration gRPC service served by kubelet to register itself with kubelet. Please refer to the documentation for an example on how a pod can request a device exposed to the cluster by a device plugin. Here are some example implementations of device plugins: AMD GPU device plugin Collection of Intel device plugins for Kubernetes NVIDIA device plugin for Kubernetes SRIOV network device plugin for Kubernetes Noteworthy developments since Device Plugin framework introduction Kubelet APIs moved to kubelet staging repo External facing deviceplugin API packages moved from k8s.io/kubernetes/pkg/kubelet/apis/ to k8s.io/kubelet/pkg/apis/ in v1.17. Refer to Move external facing kubelet apis to staging for more details on the rationale behind this change. Device Plugin API updates Additional gRPC endpoints introduced: GetDevicePluginOptions is used by device plugins to communicate options to the DeviceManager in order to indicate if PreStartContainer , GetPreferredAllocation or other future optional calls are supported and can be called before making devices available to the container. GetPreferredAllocation allows a device plugin to forward allocation preferrence to the DeviceManager so it can incorporate this information into its allocation decisions. The DeviceManager will call out to a plugin at pod admission time asking for a preferred device allocation of a given size from a list of available devices to make a more informed decision. E.g. Specifying inter-device constraints to indicate preferrence on best-connected set of devices when allocating devices to a container. PreStartContainer is called before each container start if indicated by device plugins during registration phase. It allows Device Plugins to run device specific operations on the Devices requested. E.g. reconfiguring or reprogramming FPGAs before the container starts running. Pull Requests that introduced these changes are here: Invoke preStart RPC call before container start, if desired by plugin Add GetPreferredAllocation() call to the v1beta1 device plugin API With introduction of the above endpoints the interaction between Device Manager in kubelet and Device Manager can be shown as below: Device Plugin framework Overview Change in semantics of device plugin registration process Device plugin code was refactored to separate 'plugin' package under the devicemanager package to lay the groundwork for introducing a v1beta2 device plugin API. This would allow adding support in devicemanager to service multiple device plugin APIs at the same time. With this refactoring work, it is now mandatory for a device plugin to start serving its gRPC service before registering itself with kubelet. Previously, these two operations were asynchronous and device plugin could register itself before starting its gRPC server which is no longer the case. For more details, refer to PR #109016 and Issue #112395 . Dynamic resource allocation In Kubernetes 1.26, inspired by how Persistent Volumes are handled in Kubernetes, Dynamic Resource Allocation has been introduced to cater to devices that have more sophisticated resource requirements like: Decouple device initialization and allocation from the pod lifecycle. Facilitate dynamic sharing of devices between containers and pods. Support custom resource-specific parameters Enable resource-specific setup and cleanup actions Enable support for Network-attached resources, not just node-local resources Is the Device Plugin API stable now? No, the Device Plugin API is still not stable; the latest Device Plugin API version available is v1beta1 . There are plans in the community to introduce v1beta2 API to service multiple plugin APIs at once. A per-API call with request/response types would allow adding support for newer API versions without explicitly bumping the API. In addition to that, there are existing proposals in the community to introduce additional endpoints KEP-3162: Add Deallocate and PostStopContainer to Device Manager API .

Here’s how companies and other organizations are trying to make plastics more sustainable

Campus Martius was used as the central point when Detroit was created. Now, it serves as a major gathering hub. On The Daily J podcast, WWJ’s Zach Clark digs into the past, present and future of the park, which has breathed new life into the city.

Spotify is set to commercialize a developer-focused project it open-sourced three years ago, with plans to sell companies premium plugins.

😵‍💫😵‍💫😵‍💫

Edgegap is on a mission to make distributed infrastructures easy to use. Our platform automates the deployment and management of game…

10-inch tablet with detachable keyboard case should be available in early 2023.

This repo includes ChatGPT promt curation to use ChatGPT better.

Deep dive into how Tailscale successfully markets its products on Hacker News. And learnings on how to write product articles for the developer audience.

Author: Xing Yang (VMware), Ashutosh Kumar (VMware) Kubernetes v1.24 introduced an alpha quality implementation of improvements for handling a non-graceful node shutdown . In Kubernetes v1.26, this feature moves to beta. This feature allows stateful workloads to failover to a different node after the original node is shut down or in a non-recoverable state, such as the hardware failure or broken OS. What is a node shutdown in Kubernetes? In a Kubernetes cluster, it is possible for a node to shut down. This could happen either in a planned way or it could happen unexpectedly. You may plan for a security patch, or a kernel upgrade and need to reboot the node, or it may shut down due to preemption of VM instances. A node may also shut down due to a hardware failure or a software problem. To trigger a node shutdown, you could run a shutdown or poweroff command in a shell, or physically press a button to power off a machine. A node shutdown could lead to workload failure if the node is not drained before the shutdown. In the following, we will describe what is a graceful node shutdown and what is a non-graceful node shutdown. What is a graceful node shutdown? The kubelet's handling for a graceful node shutdown allows the kubelet to detect a node shutdown event, properly terminate the pods on that node, and release resources before the actual shutdown. Critical pods are terminated after all the regular pods are terminated, to ensure that the essential functions of an application can continue to work as long as possible. What is a non-graceful node shutdown? A Node shutdown can be graceful only if the kubelet's node shutdown manager can detect the upcoming node shutdown action. However, there are cases where a kubelet does not detect a node shutdown action. This could happen because the shutdown command does not trigger the Inhibitor Locks mechanism used by the kubelet on Linux, or because of a user error. For example, if the shutdownGracePeriod and shutdownGracePeriodCriticalPods details are not configured correctly for that node. When a node is shut down (or crashes), and that shutdown was not detected by the kubelet node shutdown manager, it becomes a non-graceful node shutdown. Non-graceful node shutdown is a problem for stateful apps. If a node containing a pod that is part of a StatefulSet is shut down in a non-graceful way, the Pod will be stuck in Terminating status indefinitely, and the control plane cannot create a replacement Pod for that StatefulSet on a healthy node. You can delete the failed Pods manually, but this is not ideal for a self-healing cluster. Similarly, pods that ReplicaSets created as part of a Deployment will be stuck in Terminating status, and that were bound to the now-shutdown node, stay as Terminating indefinitely. If you have set a horizontal scaling limit, even those terminating Pods count against the limit, so your workload may struggle to self-heal if it was already at maximum scale. (By the way: if the node that had done a non-graceful shutdown comes back up, the kubelet does delete the old Pod, and the control plane can make a replacement.) What's new for the beta? For Kubernetes v1.26, the non-graceful node shutdown feature is beta and enabled by default. The NodeOutOfServiceVolumeDetach feature gate is enabled by default on kube-controller-manager instead of being opt-in; you can still disable it if needed (please also file an issue to explain the problem). On the instrumentation side, the kube-controller-manager reports two new metrics. force_delete_pods_total number of pods that are being forcibly deleted (resets on Pod garbage collection controller restart) force_delete_pod_errors_total number of errors encountered when attempting forcible Pod deletion (also resets on Pod garbage collection controller restart) How does it work? In the case of a node shutdown, if a graceful shutdown is not working or the node is in a non-recoverable state due to hardware failure or broken OS, you can manually add an out-of-service taint on the Node. For example, this can be node.kubernetes.io/out-of-service=nodeshutdown:NoExecute or node.kubernetes.io/out-of-service=nodeshutdown:NoSchedule . This taint trigger pods on the node to be forcefully deleted if there are no matching tolerations on the pods. Persistent volumes attached to the shutdown node will be detached, and new pods will be created successfully on a different running node. kubectl taint nodes node-name node.kubernetes.io/out-of-service=nodeshutdown:NoExecute Note: Before applying the out-of-service taint, you must verify that a node is already in shutdown or power-off state (not in the middle of restarting), either because the user intentionally shut it down or the node is down due to hardware failures, OS issues, etc. Once all the workload pods that are linked to the out-of-service node are moved to a new running node, and the shutdown node has been recovered, you should remove that taint on the affected node after the node is recovered. What’s next? Depending on feedback and adoption, the Kubernetes team plans to push the Non-Graceful Node Shutdown implementation to GA in either 1.27 or 1.28. This feature requires a user to manually add a taint to the node to trigger the failover of workloads and remove the taint after the node is recovered. The cluster operator can automate this process by automatically applying the out-of-service taint if there is a programmatic way to determine that the node is really shut down and there isn’t IO between the node and storage. The cluster operator can then automatically remove the taint after the workload fails over successfully to another running node and that the shutdown node has been recovered. In the future, we plan to find ways to automatically detect and fence nodes that are shut down or in a non-recoverable state and fail their workloads over to another node. How can I learn more? To learn more, read Non Graceful node shutdown in the Kubernetes documentation. How to get involved? We offer a huge thank you to all the contributors who helped with design, implementation, and review of this feature: Michelle Au (msau42 ) Derek Carr (derekwaynecarr ) Danielle Endocrimes (endocrimes ) Tim Hockin (thockin ) Ashutosh Kumar (sonasingh46 ) Hemant Kumar (gnufied ) Yuiko Mouri(YuikoTakada ) Mrunal Patel (mrunalp ) David Porter (bobbypage ) Yassine Tijani (yastij ) Jing Xu (jingxu97 ) Xing Yang (xing-yang ) There are many people who have helped review the design and implementation along the way. We want to thank everyone who has contributed to this effort including the about 30 people who have reviewed the KEP and implementation over the last couple of years. This feature is a collaboration between SIG Storage and SIG Node. For those interested in getting involved with the design and development of any part of the Kubernetes Storage system, join the Kubernetes Storage Special Interest Group (SIG). For those interested in getting involved with the design and development of the components that support the controlled interactions between pods and host resources, join the Kubernetes Node SIG.

Ahmad Abouammo was found guilty for his part in a scheme to acquire the personal information of Twitter users for a Saudi government agent, NBC News reports.

Empowering everyone to build reliable and efficient software.

I finally decided to create an account on Mastodon. You can follow me at @jsq@mastodon.social. I put this off for so long because I was skeptical and I did n...