Red Hat cutting hundreds of jobs, CEO says in letter to employees | WRAL TechWire
"We will reduce the associate base of Red Hat over the next few weeks," CEO Matt Hicks wrote in the email. He said the layoffs would be "just under 4% in total."
Blog: Kubernetes 1.27: Server Side Field Validation and OpenAPI V3 move to GA
Author : Jeffrey Ying (Google), Antoine Pelisse (Google)
Before Kubernetes v1.8 (!), typos, mis-indentations or minor errors in
YAMLs could have catastrophic consequences (e.g. a typo like
forgetting the trailing s in replica: 1000 could cause an outage,
because the value would be ignored and missing, forcing a reset of
replicas back to 1). This was solved back then by fetching the OpenAPI
v2 in kubectl and using it to verify that fields were correct and
present before applying. Unfortunately, at that time, Custom Resource
Definitions didn’t exist, and the code was written under that
assumption. When CRDs were later introduced, the lack of flexibility
in the validation code forced some hard decisions in the way CRDs
exposed their schema, leaving us in a cycle of bad validation causing
bad OpenAPI and vice-versa. With the new OpenAPI v3 and Server Field
Validation being GA in 1.27, we’ve now solved both of these problems.
Server Side Field Validation offers resource validation on create,
update and patch requests to the apiserver and was added to Kubernetes
in v1.25, beta in v1.26 and is now GA in v1.27. It provides all the
functionality of kubectl validate on the server side.
OpenAPI is a standard, language
agnostic interface for discovering the set of operations and types
that a Kubernetes cluster supports. OpenAPI V3 is the latest standard
of the OpenAPI and is an improvement upon OpenAPI
V2
which has been supported since Kubernetes 1.5. OpenAPI V3 support was
added in Kubernetes in v1.23, moved to beta in v1.24 and is now GA in
v1.27.
OpenAPI V3
What does OpenAPI V3 offer over V2
Built-in types
Kubernetes offers certain annotations on fields that are not
representable in OpenAPI V2, or sometimes not represented in the
OpenAPI v2 that Kubernetes generate. Most notably, the "default" field
is published in OpenAPI V3 while omitted in OpenAPI V2. A single type
that can represent multiple types is also expressed correctly in
OpenAPI V3 with the oneOf field. This includes proper representations
for IntOrString and Quantity.
Custom Resource Definitions
In Kubernetes, Custom Resource Definitions use a structural OpenAPI V3
schema that cannot be represented as OpenAPI V2 without a loss of
certain fields. Some of these include nullable, default, anyOf, oneOf,
not, etc. OpenAPI V3 is a completely lossless representation of the
CustomResourceDefinition structural schema.
How do I use it?
The OpenAPI V3 root discovery can be found at the /openapi/v3
endpoint of a Kubernetes API server. OpenAPI V3 documents are grouped
by group-version to reduce the size of the data transported, the
separate documents can be accessed at
/openapi/v3/apis/group/version and /openapi/v3/api/v1
representing the legacy group version. Please refer to the Kubernetes
API Documentation for more
information around this endpoint.
Various consumers of the OpenAPI have already been updated to consume
v3, including the entirety of kubectl, and server side apply. An
OpenAPI V3 Golang client is available in
client-go .
Server Side Field Validation
The query parameter fieldValidation may be used to indicate the
level of field validation the server should perform. If the parameter
is not passed, server side field validation is in Warn mode by
default.
Strict: Strict field validation, errors on validation failure
Warn: Field validation is performed, but errors are exposed as
warnings rather than failing the request
Ignore: No server side field validation is performed
kubectl will skip client side validation and will automatically use
server side field validation in Strict mode. Controllers by default
use server side field validation in Warn mode.
With client side validation, we had to be extra lenient because some
fields were missing from OpenAPI V2 and we didn’t want to reject
possibly valid objects. This is all fixed in server side validation.
Additional documentation may be found
here
What's next?
With Server Side Field Validation and OpenAPI V3 released as GA, we
introduce more accurate representations of Kubernetes resources. It is
recommended to use server side field validation over client side, but
with OpenAPI V3, clients are free to implement their own validation if
necessary (to “shift things left”) and we guarantee a full lossless
schema published by OpenAPI.
Some existing efforts will further improve the information available
through OpenAPI including CEL validation and
admission , along with OpenAPI
annotations on built-in types.
Many other tools can be built for authoring and transforming resources
using the type information found in the OpenAPI v3.
How to get involved?
These two features are driven by the SIG API Machinery community,
available on the slack channel #sig-api-machinery, through the
mailing
list and we
meet every other Wednesday at 11:00 AM PT on Zoom.
We offer a huge thanks to all the contributors who helped design,
implement, and review these two features.
Alexander Zielenski
Antoine Pelisse
Daniel Smith
David Eads
Jeffrey Ying
Jordan Liggitt
Kevin Delgado
Sean Sullivan
'Alexa, set the alarm for me to take my medication'
Older adults use voice assistant devices more often with training and flyers with instructions to complement their daily routine, according to a new University of Michigan study that looked at long-term usage.
Sudan internet shutting down as fighting causes power cuts
Sudan is experiencing severe internet outages amid a power struggle that has pitted the army against a powerful paramilitary force in the streets of the capital Khartoum and around the country.
“This was the first double supply chain attack,” that has been publicly disclosed. | The 3CX attack gets wilder, marks first 'cascading software supply chain compromise'
The surprising story of the supply chain hack of VoIP provider 3CX got even crazier this week. Here's what your application security need to know.
Redbox Owner Interested in Buying Netflix’s DVD Business
Chicken Soup for the Soul Entertainment CEO Bill Rouhana tells THR he wants to buy the DVD business, though a Netflix source said it is not for sale, and will be wound down.
Report: cheap Chromebooks, due to their short lifespans and lack of repairability, are less sustainable and more expensive for schools than pricier devices
A new investigation calls out Chromebooks for their short lifespans.
The Rust Foundation is an independent non-profit organization to steward the Rust programming language and ecosystem, with a unique focus on supporting the set of maintainers that govern and develop the project.
Ansible can great for automating routine IT tasks, but some may feel stymied by the command line. For those, here's how to install the Semaphore graphical user interface.
Fora short period of time this was actually a decent source of information, that clearly has passed | BuzzFeed News Is Shutting Down, Company Laying Off 180 Staffers
BuzzFeed is shutting down BuzzFeed News because it is not able to turn a profit, according to a memo CEO Jonah Peretti sent to company staff Thursday. The digital publisher is laying off 15% of its…
The Silent Killer of Your Operating Practice: Fear
Amanda Schwartz Ramirez, former PayPal strategy leader and now COO advisor for startups, shares the 5 biggest fears that can derail your company's strategic planning sessions (and tactical advice for how to sidestep them).
After almost two years since SLSA’s initial preview release, we are pleased to announce our first official stable version, SLSA v1.0! The full announcement can be found at the OpenSSF press release, and a description of changes can be found at What’s new in v1.0. Thank you to all members of the SLSA community who made this possible through your feedback, suggestions, discussions, and pull requests!
Blog: Kubernetes 1.27: Query Node Logs Using The Kubelet API
Author: Aravindh Puthiyaparambil (Red Hat)
Kubernetes 1.27 introduced a new feature called Node log query that allows
viewing logs of services running on the node.
What problem does it solve?
Cluster administrators face issues when debugging malfunctioning services
running on the node. They usually have to SSH or RDP into the node to view the
logs of the service to debug the issue. The Node log query feature helps with
this scenario by allowing the cluster administrator to view the logs using
kubectl . This is especially useful with Windows nodes where you run into the
issue of the node going to the ready state but containers not coming up due to
CNI misconfigurations and other issues that are not easily identifiable by
looking at the Pod status.
How does it work?
The kubelet already has a /var/log/ viewer that is accessible via the node
proxy endpoint. The feature supplements this endpoint with a shim that shells
out to journalctl , on Linux nodes, and the Get-WinEvent cmdlet on Windows
nodes. It then uses the existing filters provided by the commands to allow
filtering the logs. The kubelet also uses heuristics to retrieve the logs.
If the user is not aware if a given system services logs to a file or to the
native system logger, the heuristics first checks the native operating system
logger and if that is not available it attempts to retrieve the first logs
from /var/log/servicename or /var/log/servicename.log or
/var/log/servicename/servicename.log .
On Linux we assume that service logs are available via journald, and that
journalctl is installed. On Windows we assume that service logs are available
in the application log provider. Also note that fetching node logs is only
available if you are authorized to do so (in RBAC, that's get and
create access to nodes/proxy ). The privileges that you need to fetch node
logs also allow elevation-of-privilege attacks, so be careful about how you
manage them.
How do I use it?
To use the feature, ensure that the NodeLogQuery
feature gate is
enabled for that node, and that the kubelet configuration options
enableSystemLogHandler and enableSystemLogQuery are both set to true. You can
then query the logs from all your nodes or just a subset. Here is an example to
retrieve the kubelet service logs from a node:
# Fetch kubelet logs from a node named node-1.example
kubectl get --raw "/api/v1/nodes/node-1.example/proxy/logs/?query=kubelet"
You can further filter the query to narrow down the results:
# Fetch kubelet logs from a node named node-1.example that have the word "error"
kubectl get --raw "/api/v1/nodes/node-1.example/proxy/logs/?query=kubelet&pattern=error"
You can also fetch files from /var/log/ on a Linux node:
kubectl get --raw "/api/v1/nodes/insert-node-name-here/proxy/logs/?query=/insert-log-file-name-here"
You can read the
documentation
for all the available options.
How do I help?
Please use the feature and provide feedback by opening GitHub issues or
reaching out to us on the
#sig-windows channel on the
Kubernetes Slack or the SIG Windows
mailing list .
Seagate to pay $300 million penalty for shipping Huawei 7 million hard drives
Seagate sold the drives to Huawei between August 2020 and September 2021 despite an August 2020 rule that restricted sales of certain foreign items made with US technology to the company.