Suggested Reads

Suggested Reads

54946 bookmarks
Newest
Scaling Mastodon: The Compendium | Hazel Weakly
Scaling Mastodon: The Compendium | Hazel Weakly
This is honestly a very hastily written selection of various snippets, with text extracted, and notes. No real editing thought was put into this, so I hope it’s...
·hazelweakly.me·
Scaling Mastodon: The Compendium | Hazel Weakly
🤯🤯🤯 Wow! | AWS successfully runs AWS compute and machine learning services on an orbiting satellite in a first-of-its kind space experiment | AWS Public Sector Blog
🤯🤯🤯 Wow! | AWS successfully runs AWS compute and machine learning services on an orbiting satellite in a first-of-its kind space experiment | AWS Public Sector Blog
At re:Invent 2022, AWS announced that it successfully ran a suite of AWS compute and machine learning (ML) software on an orbiting satellite, in a first-of-its-kind space experiment. The experiment, conducted over the past 10 months in low Earth orbit (LEO), was designed to test a faster, more efficient method for customers to collect and analyze valuable space data directly on their orbiting satellites using the cloud.
·aws.amazon.com·
🤯🤯🤯 Wow! | AWS successfully runs AWS compute and machine learning services on an orbiting satellite in a first-of-its kind space experiment | AWS Public Sector Blog
What Actually Happens When You Publish a Container Port
What Actually Happens When You Publish a Container Port
Have you ever wondered what actually happens when you ask Docker to publish a port? How port publishing implementation differs between Docker Engine and Docker Desktop? How to publish a port with containerd? How nerdctl and Lima implement port forwarding?
·iximiuz.com·
What Actually Happens When You Publish a Container Port
PHP 7 Is Officially Dead
PHP 7 Is Officially Dead
As of today, PHP 7.4 is end of life, which means the PHP 7 version is now officially retired. Some distributions will backport security patches, but really, it's time to move on.
·lowendbox.com·
PHP 7 Is Officially Dead
New Amazon EC2 Instance Types In the Works – C7gn, R7iz, and Hpc7g | Amazon Web Services
New Amazon EC2 Instance Types In the Works – C7gn, R7iz, and Hpc7g | Amazon Web Services
We are getting ready to launch three new Amazon Elastic Compute Cloud (Amazon EC2) instance types and I am happy to be able to give you a sneak peek at them today. C7gn Instances are designed for your most demanding network-intensive workloads: network virtual appliances (firewalls, virtual routers, load balancers, and so forth), data analytics, […]
·aws.amazon.com·
New Amazon EC2 Instance Types In the Works – C7gn, R7iz, and Hpc7g | Amazon Web Services
Universal Crossplane is now available from the Amazon EKS console
Universal Crossplane is now available from the Amazon EKS console
We’re pleased to announce the availability of Upbound Universal Crossplane (UXP) as an add-on for Amazon Elastic Kubernetes Service. This integration makes Upbound’s enterprise-grade distribution of Crossplane an effortless one-click installation for customers who want to run control planes on Amazon EKS.
·blog.upbound.io·
Universal Crossplane is now available from the Amazon EKS console
FFmpeg - Ultimate Guide | IMG.LY Blog
FFmpeg - Ultimate Guide | IMG.LY Blog
This guide covers the ins and outs of FFmpeg starting with fundamental concepts and moving to media transcoding and video and audio processing providing practical examples along the way.
·img.ly·
FFmpeg - Ultimate Guide | IMG.LY Blog
Blog: registry.k8s.io: faster, cheaper and Generally Available (GA)
Blog: registry.k8s.io: faster, cheaper and Generally Available (GA)
Authors : Adolfo García Veytia (Chainguard), Bob Killen (Google) Starting with Kubernetes 1.25, our container image registry has changed from k8s.gcr.io to registry.k8s.io . This new registry spreads the load across multiple Cloud Providers & Regions, functioning as a sort of content delivery network (CDN) for Kubernetes container images. This change reduces the project’s reliance on a single entity and provides a faster download experience for a large number of users. TL;DR: What you need to know about this change Container images for Kubernetes releases from 1.25 onward are no longer published to k8s.gcr.io, only to registry.k8s.io. In the upcoming December patch releases, the new registry domain default will be backported to all branches still in support (1.22, 1.23, 1.24). If you run in a restricted environment and apply strict domain/IP address access policies limited to k8s.gcr.io, the image pulls will not function after the migration to this new registry. For these users, the recommended method is to mirror the release images to a private registry. If you’d like to know more about why we made this change, or some potential issues you might run into, keep reading. Why has Kubernetes changed to a different image registry? k8s.gcr.io is hosted on a custom Google Container Registry (GCR) domain that was setup solely for the Kubernetes project. This has worked well since the inception of the project, and we thank Google for providing these resources, but today there are other cloud providers and vendors that would like to host images to provide a better experience for the people on their platforms. In addition to Google’s renewed commitment to donate $3 million to support the project's infrastructure, Amazon announced a matching donation during their Kubecon NA 2022 keynote in Detroit. This will provide a better experience for users (closer servers = faster downloads) and will reduce the egress bandwidth and costs from GCR at the same time. registry.k8s.io will spread the load between Google and Amazon, with other providers to follow in the future. Why isn’t there a stable list of domains/IPs? Why can’t I restrict image pulls? registry.k8s.io is a secure blob redirector that connects clients to the closest cloud provider. The nature of this change means that a client pulling an image could be redirected to any one of a large number of backends. We expect the set of backends to keep changing and will only increase as more and more cloud providers and vendors come on board to help mirror the release images. Restrictive control mechanisms like man-in-the-middle proxies or network policies that restrict access to a specific list of IPs/domains will break with this change. For these scenarios, we encourage you to mirror the release images to a local registry that you have strict control over. For more information on this policy, please see the stability section of the registry.k8s.io documentation . What kind of errors will I see? How will I know if I’m still using the old address? Errors may depend on what kind of container runtime you are using, and what endpoint you are routed to, but it should present as a container failing to be created with the warning FailedCreatePodSandBox . Below is an example error message showing a proxied deployment failing to pull due to an unknown certificate: FailedCreatePodSandBox: Failed to create pod sandbox: rpc error: code = Unknown desc = Error response from daemon: Head “https://us-west1-docker.pkg.dev/v2/k8s-artifacts-prod/images/pause/manifests/3.8”: x509: certificate signed by unknown authority I’m impacted by this change, how do I revert to the old registry address? If using the new registry domain name is not an option, you can revert to the old domain name for cluster versions less than 1.25. Keep in mind that, eventually, you will have to switch to the new registry, as new image tags will no longer be pushed to GCR. Reverting the registry name in kubeadm The registry used by kubeadm to pull its images can be controlled by two methods: Setting the --image-repository flag. kubeadm init --image-repository=k8s.gcr.io Or in kubeadm config ClusterConfiguration : apiVersion : kubeadm.k8s.io/v1beta3 kind : ClusterConfiguration imageRepository : "k8s.gcr.io" Reverting the Registry Name in kubelet The image used by kubelet for the pod sandbox (pause ) can be overridden by setting the --pod-infra-container-image flag. For example: kubelet --pod-infra-container-image=k8s.gcr.io/pause:3.5 Acknowledgments Change is hard , and evolving our image-serving platform is needed to ensure a sustainable future for the project. We strive to make things better for everyone using Kubernetes. Many contributors from all corners of our community have been working long and hard to ensure we are making the best decisions possible, executing plans, and doing our best to communicate those plans. Thanks to Aaron Crickenberger, Arnaud Meukam, Benjamin Elder, Caleb Woodbine, Davanum Srinivas, Mahamed Ali, and Tim Hockin from SIG K8s Infra, Brian McQueen, and Sergey Kanzhelev from SIG Node, Lubomir Ivanov from SIG Cluster Lifecycle, Adolfo García Veytia, Jeremy Rickard, Sascha Grunert, and Stephen Augustus from SIG Release, Bob Killen and Kaslin Fields from SIG Contribex, Tim Allclair from the Security Response Committee. Also a big thank you to our friends acting as liaisons with our cloud provider partners: Jay Pipes from Amazon and Jon Johnson Jr. from Google.
·kubernetes.io·
Blog: registry.k8s.io: faster, cheaper and Generally Available (GA)