1_DevOps'ish

1_DevOps'ish

56730 bookmarks
Custom sorting
Updated whitepaper available: AWS Security Incident Response Guide | Amazon Web Services
Updated whitepaper available: AWS Security Incident Response Guide | Amazon Web Services
The AWS Security Incident Response Guide focuses on the fundamentals of responding to security incidents within a customer’s Amazon Web Services (AWS) Cloud environment. You can use the guide to help build and iterate on your AWS security incident response program. Recently, we updated the AWS Security Incident Response Guide to more clearly explain what […]
·aws.amazon.com·
Updated whitepaper available: AWS Security Incident Response Guide | Amazon Web Services
Blog: Kubernetes 1.26: Retroactive Default StorageClass
Blog: Kubernetes 1.26: Retroactive Default StorageClass
Author: Roman Bednář (Red Hat) The v1.25 release of Kubernetes introduced an alpha feature to change how a default StorageClass was assigned to a PersistentVolumeClaim (PVC). With the feature enabled, you no longer need to create a default StorageClass first and PVC second to assign the class. Additionally, any PVCs without a StorageClass assigned can be updated later. This feature was graduated to beta in Kubernetes 1.26. You can read retroactive default StorageClass assignment in the Kubernetes documentation for more details about how to use that, or you can read on to learn about why the Kubernetes project is making this change. Why did StorageClass assignment need improvements Users might already be familiar with a similar feature that assigns default StorageClasses to new PVCs at the time of creation. This is currently handled by the admission controller . But what if there wasn't a default StorageClass defined at the time of PVC creation? Users would end up with a PVC that would never be assigned a class. As a result, no storage would be provisioned, and the PVC would be somewhat "stuck" at this point. Generally, two main scenarios could result in "stuck" PVCs and cause problems later down the road. Let's take a closer look at each of them. Changing default StorageClass With the alpha feature enabled, there were two options admins had when they wanted to change the default StorageClass: Creating a new StorageClass as default before removing the old one associated with the PVC. This would result in having two defaults for a short period. At this point, if a user were to create a PersistentVolumeClaim with storageClassName set to null (implying default StorageClass), the newest default StorageClass would be chosen and assigned to this PVC. Removing the old default first and creating a new default StorageClass. This would result in having no default for a short time. Subsequently, if a user were to create a PersistentVolumeClaim with storageClassName set to null (implying default StorageClass), the PVC would be in Pending state forever. The user would have to fix this by deleting the PVC and recreating it once the default StorageClass was available. Resource ordering during cluster installation If a cluster installation tool needed to create resources that required storage, for example, an image registry, it was difficult to get the ordering right. This is because any Pods that required storage would rely on the presence of a default StorageClass and would fail to be created if it wasn't defined. What changed We've changed the PersistentVolume (PV) controller to assign a default StorageClass to any unbound PersistentVolumeClaim that has the storageClassName set to null . We've also modified the PersistentVolumeClaim admission within the API server to allow the change of values from an unset value to an actual StorageClass name. Null storageClassName versus storageClassName: "" - does it matter? Before this feature was introduced, those values were equal in terms of behavior. Any PersistentVolumeClaim with the storageClassName set to null or "" would bind to an existing PersistentVolume resource with storageClassName also set to null or "" . With this new feature enabled we wanted to maintain this behavior but also be able to update the StorageClass name. With these constraints in mind, the feature changes the semantics of null . If a default StorageClass is present, null would translate to "Give me a default" and "" would mean "Give me PersistentVolume that also has "" StorageClass name." In the absence of a StorageClass, the behavior would remain unchanged. Summarizing the above, we've changed the semantics of null so that its behavior depends on the presence or absence of a definition of default StorageClass. The tables below show all these cases to better describe when PVC binds and when its StorageClass gets updated. PVC binding behavior with Retroactive default StorageClass PVC storageClassName = "" PVC storageClassName = null Without default class PV storageClassName = "" binds binds PV without storageClassName binds binds With default class PV storageClassName = "" binds class updates PV without storageClassName binds class updates How to use it If you want to test the feature whilst it's alpha, you need to enable the relevant feature gate in the kube-controller-manager and the kube-apiserver. Use the --feature-gates command line argument: --feature-gates="...,RetroactiveDefaultStorageClass=true" Test drive If you would like to see the feature in action and verify it works fine in your cluster here's what you can try: Define a basic PersistentVolumeClaim: apiVersion : v1 kind : PersistentVolumeClaim metadata : name : pvc-1 spec : accessModes : - ReadWriteOnce resources : requests : storage : 1Gi Create the PersistentVolumeClaim when there is no default StorageClass. The PVC won't provision or bind (unless there is an existing, suitable PV already present) and will remain in Pending state. $ kc get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE pvc-1 Pending Configure one StorageClass as default. $ kc patch sc -p '{"metadata":{"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}' storageclass.storage.k8s.io/my-storageclass patched Verify that PersistentVolumeClaims is now provisioned correctly and was updated retroactively with new default StorageClass. $ kc get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE pvc-1 Bound pvc-06a964ca-f997-4780-8627-b5c3bf5a87d8 1Gi RWO my-storageclass 87m New metrics To help you see that the feature is working as expected we also introduced a new retroactive_storageclass_total metric to show how many times that the PV controller attempted to update PersistentVolumeClaim, and retroactive_storageclass_errors_total to show how many of those attempts failed. Getting involved We always welcome new contributors so if you would like to get involved you can join our Kubernetes Storage Special-Interest-Group (SIG). If you would like to share feedback, you can do so on our public Slack channel . Special thanks to all the contributors that provided great reviews, shared valuable insight and helped implement this feature (alphabetical order): Deep Debroy (ddebroy ) Divya Mohan (divya-mohan0209 ) Jan Šafránek (jsafrane ) Joe Betz (jpbetz ) Jordan Liggitt (liggitt ) Michelle Au (msau42 ) Seokho Son (seokho-son ) Shannon Kularathna (shannonxtreme ) Tim Bannister (sftim ) Tim Hockin (thockin ) Wojciech Tyczynski (wojtek-t ) Xing Yang (xing-yang )
·kubernetes.io·
Blog: Kubernetes 1.26: Retroactive Default StorageClass
Why TikTok's future has never been so cloudy
Why TikTok's future has never been so cloudy
ByteDance thought it had a deal with the government in August. Then came the bans — and a spying scandal
·open.substack.com·
Why TikTok's future has never been so cloudy
Folks have said that there’s a need for updated container basics for myriad reasons. I’ll try and highlight more content like this. | Back to basics: accessing Kubernetes pods
Folks have said that there’s a need for updated container basics for myriad reasons. I’ll try and highlight more content like this. | Back to basics: accessing Kubernetes pods
Kubernetes is a colossal beast. You need to understand many different concepts before it starts being useful. When everything is set up, you’ll probably want to expose some pods to the outside of the cluster. Kubernetes provides different ways to do it: I’ll describe them in this post.
·blog.frankel.ch·
Folks have said that there’s a need for updated container basics for myriad reasons. I’ll try and highlight more content like this. | Back to basics: accessing Kubernetes pods
Microsoft aims for AI-powered version of Bing - The Information
Microsoft aims for AI-powered version of Bing - The Information
Microsoft Corp is in the works to launch a version of its search engine Bing using the artificial intelligence behind OpenAI-launched chatbot ChatGPT, The Information reported on Tuesday, citing two people with direct knowledge of the plans.
·reuters.com·
Microsoft aims for AI-powered version of Bing - The Information
Large Language Models as Corporate Lobbyists
Large Language Models as Corporate Lobbyists
We demonstrate a proof-of-concept of a large language model conducting corporate lobbying related activities. We use an autoregressive large language model (OpenAI's text-davinci-003) to determine...
·arxiv.org·
Large Language Models as Corporate Lobbyists
LostPass: after the LastPass hack, here’s what you need to know
LostPass: after the LastPass hack, here’s what you need to know
Do you use the LastPass password manager? Did you know they suffered a data breach, and that your passwords may be at risk? You do now. Here's what you need to know.
·grahamcluley.com·
LostPass: after the LastPass hack, here’s what you need to know