One place for hosting & domains


      How to Get Started as a WordPress Contributor

      And WordPress — the behemoth that powers 30% of the internet — is the ultimate open-source project. That means it’s developed and maintained by a dedicated community of contributors — awesome people like you and me — rather than a for-profit company.

      Even better? Becoming one of those stalwart WordPress contributors and shaping the future of the platform is easier than you might imagine. Plus, there are many excellent avenues for contributing. Along with the obvious coding and development roles, you can get involved in design, translation, community outreach, and much more.

      So let’s first talk about what contributing to WordPress actually means (no, you’re not going to be pressing words, Amelia Bedelia) and why you should do it. Then I’ll walk you through the step-by-step process of finding your niche and making the right connections.

      Why You Should Consider Contributing to WordPress

      WordPress’ community is what made it the flexible, powerful platform it is today. is a totally free and open-source platform. This means that instead of being run by a large company, WordPress is developed and maintained by a dedicated community of users.

      “Wait, rewind! What about”

      Great question! offers free software that anybody can use to create a self-hosted website. uses the same platform but is run by a for-profit company. If you really want to get into the nitty-gritty about WordPress, both the .com and .org sites, check out our WordPress Differences Beginner’s Guide.

      In this post, we’re just talking about — the open-source, free-to-use software.

      OK, back to it.

      WordPress relies on this community of users to keep it updated, add new features and functionality, provide testing and support, and much more.

      Of course, you don’t need to know anything about the larger world of WordPress to use the platform for your own websites — you can literally set up a WordPress website in just a few minutes.

      However, it may be worth your while to get involved in the platform’s development, and here’s why:

      • You get the chance to give back to the community that’s provided you with an invaluable resource.
      • Working as a contributor helps you learn more about WordPress, as well as other areas related to web development.
      • It’s a perfect way to exercise your existing skills or develop new abilities.
      • You’ll gain valuable experience you can add to your resume or use to attract clients.
      • Immersing yourself in the WordPress community enables you to make connections and build professional and personal relationships with other contributors.

      Altogether, these reasons build a compelling case for giving the role of WordPress contributor a try. What’s more, you have the flexibility to put as much or as little time into the endeavor as you’d like, and there are plenty of different ways to get involved.

      WordPress + DreamHost

      Our automatic updates and strong security defenses take server management off your hands so you can focus on creating a great website.

      How to Get Started as a WordPress Contributor

      Just like walking into a real-life party, you’ve got to find the right place for you in the WordPress crowd — whether it’s on the development dance floor or in the community outreach corner. Regardless of your particular niche and skill set, you can follow these three steps to get off on the right foot as a WordPress contributor.

      Step 1: Research WordPress and Its Community

      Structured courses found on sites like WP Apprentice are a perfect way to learn about WordPress.

      Whether you’re a relative noob or you’ve been using WordPress for years, learning more about the platform and its community is a smart first step. For one, you’ll need more in-depth knowledge about WordPress as a contributor than you ever did as a user. Plus, spending some time immersed in WordPress can help you figure out where you’ll fit into the picture.

      Start out by reading up on the history and development of WordPress. This will provide you with a solid grounding in the platform’s mission and goals and will give you some idea of how far it’s come over time. WordPress has followed a long road from its beginning as simple blogging software to its current iteration as a multifaceted Content Management System (CMS), and there have been plenty of twists and turns along the way.

      Once you have a better sense of how the platform came to be and the ways it’s changed since its inception, you can begin to learn more about its present-day form, focusing on whatever areas catch your interest. This step can take as much or as little time as you’d like, depending on how much you already know.

      There are plenty of ways to learn about WordPress, but some excellent places to start include:

      • Structured Online Courses — You can find a ton of options out there, from free half-hour tutorials to longer, more pricey options.
      • Dedicated YouTube Channels — There’s lots of free, quality information available on YouTube, mainly through channels such as WPBeginner and WPCrafter.
      • News Sources — Of course, you’ll want to keep your eye on the official news page. However, there are also other sites devoted to the latest WordPress happenings, such as WP Tavern and Post Status.
      • Forums — The web is packed with forums devoted to WordPress in general and to specific themes, plugins, and more. You can find them on itself, on developer websites, and through Google searches.
      • Blogs — There are blogs for WordPress beginners, experts, developers, and just about every niche you can think of. Reading posts on sites like Torque and our own blog is a simple, free way to learn much of what you’ll need to know.

      Throughout the course of your research, take note of your favorite resources. You’ll want to keep visiting them over time, to stay up to date and continue your WordPress education. When you feel like you have a solid understanding of WordPress and know what aspects interest you most, it’s probably time to move on to the next step.

      Step 2: Decide on a Field of Contribution

      Make WordPress is home to many teams of contributors and volunteers.

      If you’re imagining that all WordPress contributors are developers or programmers, it’s time to stop with the stereotypes.

      Just kidding.

      Many people make this assumption! Of course, a lot of people in the WordPress community are developers and programmers. However, there are a lot more options available when it comes to getting involved with the platform.

      A project as big and complex as WordPress needs many kinds of people to keep it running. This is fortunate because it means you’re likely to find an area of contribution that’s perfectly suited to your personal skill set and goals. Whether you’re interested in design, writing, or working with people, you can easily find a role to match your desires (or more than one).

      The research stage should have given you a few ideas for where you might fit into the WordPress community. There are a lot of options available.

      Core Development and Beta Testing

      This is the area that probably comes to mind first when you think about WordPress contributors. Plenty of coders are required to work on the project — they’re responsible for adding new features, improving existing functionality, creating updates and patches, beta testing, and fixing bugs and other issues. Some developers stick to one or two areas of expertise, while others try their hand at just about everything.

      If you’re at all interested in coding and development, you should get involved. What’s more, you don’t need to be an expert or have a lot of experience. WordPress is a beginner-friendly project and has some simple ways to get you started even if you’re a relative novice. You can get your feet wet with the WordPress Beta Tester plugin, then work your way up. Plus, experienced developers are always around to help you out and answer questions.

      The best place to start if you’re interested in core development and beta testing is by reading through the Core Contributor Handbook. This resource will tell you just about everything you need to know about the project’s organization, workflows, best practices, and more. Then, you can get started with some tasks earmarked for beginning contributors, such as handling basic bugs and testing patches.

      Design and User Interface

      WordPress’ user interface is the result of years of work by designers and developers.

      If you’re more of a designer than a developer, you may be interested in helping to improve the platform’s design and user interface (UI). These are key elements that impact the experience of every person who uses the platform. A solid UI streamlines the workflow for experienced users and makes their lives a little easier. And it definitely plays a major role in whether or not newcomers stick around.

      WordPress’ design and UI are constantly evolving as developers and users find better ways to organize information and handle common tasks. Just as with core development, the team behind this niche is open to anyone who wants to help out. Some design experience will certainly enable you to get up and running more quickly, but you don’t need to be an expert.

      There are a number of ways to start contributing to WordPress’ UI and design. You can deal with design-related tickets, work on mockups, or help out with whatever the team’s current primary focuses happen to be. Before jumping into any of these projects, check out the Design Handbook and then follow the recommended first steps for getting involved.

      Plugin and Theme Development

      This area of contribution is a little different from the rest. Creating themes and plugins isn’t exactly part of the main WordPress project even though it’s a crucial aspect of the platform’s development. The wide availability of free and low-cost themes and plugins is a big part of what makes WordPress so popular, and what keeps it relevant year after year. Adding to that collection helps expand the CMSs capabilities, so this is a vital function.

      You’ll need some experience with coding and development if you want to jump straight into building plugins and themes. If you are a complete beginner, though, you’ll simply need to spend some time beefing up your skills. Put in the effort to learn about how themes and plugins work, then start out by creating something small and simple. Let other people test the results and use their feedback to improve.

      For plugin and theme development, you may want to start with a dedicated course. There are free options as well as premium tutorials from services like Udemy. You’ll also find relevant information about building themes and creating plugins in the WordPress Codex. If you run into any trouble along the way, have questions, or want to find a team to collaborate with, check out the official forums. Chances are, you’ll find lots of developers there who are willing to help you out.


      The WordPress Codex is a handy resource that needs to be kept up-to-date at all times.

      Perhaps, like myself, you’re more of a writer than a developer — where do the word people fit in the WordPress community? On the documentation team. Boom.

      WordPress is a complex CMS with a lot of moving parts — plenty of resources are required to teach people the ropes and keep everything straight. That means writers and editors are needed to add new content and make sure existing materials are up to date.

      WordPress contributors who work on documentation are responsible for a number of projects. They add articles to the Codex and makes changes to it when necessary. In addition, they work on the contributor handbooks, the WordPress developer website, and inline documentation for the platform itself. All of these resources are invaluable for new WordPress users and veterans alike, so they need to be accurate and current.

      If you have some writing, editing, proofreading, or fact-checking experience under your belt, this is a perfect way to contribute to the platform. Check out the Make WordPress page for the documentation team — you’ll find helpful links to connect with fellow contributors.

      Plugin and Theme Review

      Plugins and themes go through a review process before they’re listed in the official WordPress directories.

      If you’re interested in working with themes and plugins, but don’t want to get involved in development, there’s another avenue to consider — reviewing them. After all, not just any theme or plugin is allowed into the official WordPress directories. Each submission must go through a vetting process to ensure it meets basic requirements and is safe for people to use on their sites.

      There are two separate teams involved in the review process, one for themes and one for plugins. Both check all new submissions against basic guidelines. If you join one of these teams, you’ll be given a specific procedure to follow, although it will still help to have some solid knowledge about how themes and plugins work.

      You can check out the Theme Review Team and Plugin Review Team handbooks on the Make WordPress website, and follow the instructions within for getting involved. The plugin team isn’t always accepting new members, but if it’s currently closed you can bookmark the page and keep an eye on it for future developments.

      Translation and Accessibility

      One of the best things about an online community is that it can easily transcend barriers such as location, nationality, and ability. Just about anyone can contribute to WordPress and make their voice heard, no matter who they are or where they’re from. Similarly, people from all countries and walks of life use WordPress to create and run their websites.

      This means the platform needs to be as flexible and accessible as possible, to meet the needs of various types of users. Two teams in particular help to achieve this goal: the translation and accessibility groups. The translation team, also referred to as the ‘polyglots’, works on adding more languages to WordPress. The accessibility team is focused on making the platform as useful as possible for everyone — regardless of hardware, software, or any sensory or physical impairment.

      These two fields have similar goals but benefit from somewhat different skill sets. If you’re interested in joining the polyglot team, you’ll, of course, want knowledge of at least one other language, along with solid writing and editing skills. As for the accessibility team, it’s largely made up of developers and coders and will most likely start you off by helping with accessibility-related testing and support tickets.

      Community Outreach

      WordCamps are excellent events for WordPress newbies and experts alike.

      Not everyone is happy to stay behind a computer screen all day. Some people are more interested in getting out and making professional and personal connections. If this sounds like you, it might be worth checking out the WordPress community outreach team.

      As we’ve already talked about, the WordPress community is large, diverse, and spread out geographically. It takes a lot of work to keep everyone on the same page and working towards the same goals. Plus, as WordPress grows, its community does too — and contributors need to make connections with new members and get them excited about the platform.

      The community outreach team handles official WordPress events, such as Meetups and WordCamps. They also run mentorship programs, work hard to attract new contributors to all the Make WordPress teams, and manage various other initiatives. If you have solid people skills and enjoy working with programs and events, check out the team’s current projects. Then jump into their Slack channel or use their contact form to get in touch.

      Other Opportunities

      The fields listed above are just some of the many ways you can get involved as a WordPress contributor. For even more options, check out the main page of the Make WordPress website. You’ll find plenty of other groups looking for members, working on projects such as:

      Finally, if you have an idea for how to contribute to the WordPress community but can’t find a dedicated group, try posting your thoughts and goals in the forums. Chances are, you’ll find like-minded people interested in the same type of work!

      Step 3: Stay Involved in the WordPress Community

      WordPress Meetups are held all over the world, bringing contributors and enthusiasts alike together.

      Just as it’s important to keep learning about WordPress while you’re working as a contributor, it’s also crucial to stay involved with the community. You’ve got to (digitally) mix and mingle! This will help to keep you updated about important news and events and makes it easier to find people to collaborate with and to get help from when you need it.

      Even if you’re dedicated to a specific area of contribution, such as translation, you’ll want to occasionally step outside that niche and talk to people involved in other parts of the project. Meeting new people and encountering new ideas this way will help to inform your own work and ensure that everyone is working towards the same goals. Here are a few ways to get — and stay — involved in the community:

      • Continue to frequent your favorite research sources especially forums and blogs.
      • Stay up-to-date on WordPress news and happenings.
      • Keep your eye on the new WordPress Events and News widget in the admin area of your website(s).
      • Consider attending dedicated WordPress events, such as WordCamps and Meetups. This is a great way to meet people, share ideas, and start collaborations. If there aren’t any opportunities in your area, you can always start one yourself!

      Becoming a WordPress contributor takes time and effort — but it’s well worth the investment. You’ll be part of a vast community of people all working towards a common goal, and you’ll have the chance to put your own stamp on the world’s most popular CMS.

      Be Awesome on the Internet

      Join our monthly newsletter for tips and tricks to build your dream website!

      But Wait, There’s More

      If you’ve only ever used WordPress to build and maintain your website, it may surprise you to learn how much goes on behind the scenes. A vast, thriving community is required to keep the platform at its best — including developers, designers, writers, and more. Getting involved in this community is simple, and in exchange, you’ll be met with plenty of opportunities for professional development and growth.

      To get started as a WordPress contributor, you’ll want to:

      1. Conduct some research on the platform and community, learning as much as you can and finding out what areas speak to you.
      2. Decide on one or more fields of contribution that are a match to your skills, interests, and goals.
      3. Stay involved with the WordPress community through forums, blogs, news, and events.

      And remember, if you’re looking for a web host that works seamlessly with WordPress, look no further! DreamHost regularly earns top marks and reviews, giving you the confidence to run your WordPress site with a true web hosting standout. We’ve worked hard to earn this noteworthy recommendation, designing services that make site management a snap. We aim to elevate your WordPress experience with quality tools and powerful resources to ensure peak WordPress performance. Check out our Managed WordPress Hosting plans today!

      Source link

      Getting Started with Kubernetes: A kubectl Cheat Sheet


      Kubectl is a command-line tool designed to manage Kubernetes objects and clusters. It provides a command-line interface for performing common operations like creating and scaling Deployments, switching contexts, and accessing a shell in a running container.

      How to Use This Guide:

      • This guide is in cheat sheet format with self-contained command-line snippets.
      • It is not an exhaustive list of kubectl commands, but contains many common operations and use cases. For a more thorough reference, consult the Kubectl Reference Docs
      • Jump to any section that is relevant to the task you are trying to complete.


      Sample Deployment

      To demonstrate some of the operations and commands in this cheat sheet, we’ll use a sample Deployment that runs 2 replicas of Nginx:


      apiVersion: apps/v1
      kind: Deployment
        name: nginx-deployment
        replicas: 2
            app: nginx
              app: nginx
            - name: nginx
              image: nginx
              - containerPort: 80

      Copy and paste this manifest into a file called nginx-deployment.yaml.

      Installing kubectl

      Note: These commands have only been tested on an Ubuntu 18.04 machine. To learn how to install kubectl on other operating systems, consult Install and Set Up kubectl from the Kubernetes docs.

      First, update your local package index and install required dependencies:

      • sudo apt-get update && sudo apt-get install -y apt-transport-https

      Then add the Google Cloud GPG key to APT and make the kubectl package available to your system:

      • curl -s | sudo apt-key add -
      • echo "deb kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list
      • sudo apt-get update

      Finally, install kubectl:

      • sudo apt-get install -y kubectl

      Test that the installation succeeded using version:

      Setting Up Shell Autocompletion

      Note: These commands have only been tested on an Ubuntu 18.04 machine. To learn how to set up autocompletion on other operating systems, consult Install and Set Up kubectl from the Kubernetes docs.

      kubectl includes a shell autocompletion script that you can make available to your system’s existing shell autocompletion software.

      Installing kubectl Autocompletion

      First, check if you have bash-completion installed:

      You should see some script output.

      Next, source the kubectl autocompletion script in your ~/.bashrc file:

      • echo 'source <(kubectl completion bash)' >>~/.bashrc
      • . ~/.bashrc

      Alternatively, you can add the completion script to the /etc/bash_completion.d directory:

      • kubectl completion bash >/etc/bash_completion.d/kubectl


      To use the autocompletion feature, press the TAB key to display available kubectl commands:


      annotate apply autoscale completion cordon delete drain explain kustomize options port-forward rollout set uncordon api-resources attach certificate config cp describe . . .

      You can also display available commands after partially typing a command:


      delete describe diff drain

      Connecting, Configuring and Using Contexts


      To test that kubectl can authenticate with and access your Kubernetes cluster, use cluster-info:

      If kubectl can successfully authenticate with your cluster, you should see the following output:


      Kubernetes master is running at https://kubernetes_master_endpoint CoreDNS is running at https://coredns_endpoint To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

      kubectl is configured using kubeconfig configuration files. By default, kubectl will look for a file called config in the $HOME/.kube directory. To change this, you can set the $KUBECONFIG environment variable to a custom kubeconfig file, or pass in the custom file at execution time using the --kubeconfig flag:

      • kubectl cluster-info --kubeconfig=path_to_your_kubeconfig_file

      Note: If you’re using a managed Kubernetes cluster, your cloud provider should have made its kubeconfig file available to you.

      If you don’t want to use the --kubeconfig flag with every command, and there is no existing ~/.kube/config file, create a directory called ~/.kube in your home directory if it doesn’t already exist, and copy in the kubeconfig file, renaming it to config:

      • mkdir ~/.kube
      • cp your_kubeconfig_file ~/.kube/config

      Now, run cluster-info once again to test your connection.

      Modifying your kubectl Configuration

      You can also modify your config using the kubectl config set of commands.

      To view your kubectl configuration, use the view subcommand:


      apiVersion: v1 clusters: - cluster: certificate-authority-data: DATA+OMITTED . . .

      Modifying Clusters

      To fetch a list of clusters defined in your kubeconfig, use get-clusters:

      • kubectl config get-clusters


      NAME do-nyc1-sammy

      To add a cluster to your config, use the set-cluster subcommand:

      • kubectl config set-cluster new_cluster --server=server_address --certificate-authority=path_to_certificate_authority

      To delete a cluster from your config, use delete-cluster:

      Note: This only deletes the cluster from your config and does not delete the actual Kubernetes cluster.

      • kubectl config delete-cluster

      Modifying Users

      You can perform similar operations for users using set-credentials:

      • kubectl config set-credentials username --client-certificate=/path/to/cert/file --client-key=/path/to/key/file

      To delete a user from your config, you can run unset:

      • kubectl config unset users.username


      A context in Kubernetes is an object that contains a set of access parameters for your cluster. It consists of a cluster, namespace, and user triple. Contexts allow you to quickly switch between different sets of cluster configuration.

      To see your current context, you can use current-context:

      • kubectl config current-context



      To see a list of all configured contexts, run get-contexts:

      • kubectl config get-contexts


      CURRENT NAME CLUSTER AUTHINFO NAMESPACE * do-nyc1-sammy do-nyc1-sammy do-nyc1-sammy-admin

      To set a context, use set-context:

      • kubectl config set-context context_name --cluster=cluster_name --user=user_name --namespace=namespace

      You can switch between contexts with use-context:

      • kubectl config use-context context_name


      Switched to context "do-nyc1-sammy"

      And you can delete a context with delete-context:

      • kubectl config delete-context context_name

      Using Namespaces

      A Namespace in Kubernetes is an abstraction that allows you to subdivide your cluster into multiple virtual clusters. By using Namespaces you can divide cluster resources among multiple teams and scope objects appropriately. For example, you can have a prod Namespace for production workloads, and a dev Namespace for development and test workloads.

      To fetch and print a list of all the Namespaces in your cluster, use get namespace:


      NAME STATUS AGE default Active 2d21h kube-node-lease Active 2d21h kube-public Active 2d21h kube-system Active 2d21h

      To set a Namespace for your current context, use set-context --current:

      • kubectl config set-context --current --namespace=namespace_name

      To create a Namespace, use create namespace:

      • kubectl create namespace namespace_name


      namespace/sammy created

      Similarly, to delete a Namespace, use delete namespace:

      Warning: Deleting a Namespace will delete everything in the Namespace, including running Deployments, Pods, and other workloads. Only run this command if you’re sure you’d like to kill whatever’s running in the Namespace or if you’re deleting an empty Namespace.

      • kubectl delete namespace namespace_name

      To fetch all Pods in a given Namespace or to perform other operations on resources in a given Namespace, make sure to include the --namespace flag:

      • kubectl get pods --namespace=namespace_name

      Managing Kubernetes Resources

      General Syntax

      The general syntax for most kubectl management commands is:

      • kubectl command type name flags


      • command is an operation you’d like to perform, like create
      • type is the Kubernetes resource type, like deployment
      • name is the resource’s name, like app_frontend
      • flags are any optional flags you’d like to include

      For example the following command retrieves information about a Deployment named app_frontend:

      • kubectl get deployment app_frontend

      Declarative Management and kubectl apply

      The recommended approach to managing workloads on Kubernetes is to rely on the cluster’s declarative design as much as possible. This means that instead of running a series of commands to create, update, delete, and restart running Pods, you should define the workloads, services, and systems you’d like to run in YAML manifest files, and provide these files to Kubernetes, which will handle the rest.

      In practice, this means using the kubectl apply command, which applies a particular configuration to a given resource. If the target resource doesn’t exist, then Kubernetes will create the resource. If the resource already exists, then Kubernetes will save the current revision, and update the resource according to the new configuration. This declarative approach exists in contrast to the imperative approach of running the kubectl create , kubectl edit, and the kubectl scale set of commands to manage resources. To learn more about the different ways of managing Kubernetes resources, consult Kubernetes Object Management from the Kubernetes docs.

      Rolling out a Deployment

      For example, to deploy the sample Nginx Deployment to your cluster, use apply and provide the path to the nginx-deployment.yaml manifest file:

      • kubectl apply -f nginx-deployment.yaml


      deployment.apps/nginx-deployment created

      The -f flag is used to specify a filename or URL containing a valid configuration. If you’d like to apply all manifests from a directory, you can use the -k flag:

      • kubectl apply -k manifests_dir

      You can track the rollout status using rollout status:

      • kubectl rollout status deployment/nginx-deployment


      Waiting for deployment "nginx-deployment" rollout to finish: 1 of 2 updated replicas are available... deployment "nginx-deployment" successfully rolled out

      An alternative to rollout status is the kubectl get command, along with the -w (watch) flag:

      • kubectl get deployment -w


      NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 0/2 2 0 3s nginx-deployment 1/2 2 1 3s nginx-deployment 2/2 2 2 3s

      Using rollout pause and rollout resume, you can pause and resume the rollout of a Deployment:

      • kubectl rollout pause deployment/nginx-deployment


      deployment.extensions/nginx-deployment paused
      • kubectl rollout resume deployment/nginx-deployment


      deployment.extensions/nginx-deployment resumed

      Modifying a Running Deployment

      If you’d like to modify a running Deployment, you can make changes to its manifest file and then run kubectl apply again to apply the update. For example, we’ll modify the nginx-deployment.yaml file to change the number of replicas from 2 to 3:


      . . .
        replicas: 3
            app: nginx
      . . .

      The kubectl diff command allows you to see a diff between currently running resources, and the changes proposed in the supplied configuration file:

      • kubectl diff -f nginx-deployment.yaml

      Now allow Kubernetes to perform the update using apply:

      • kubectl apply -f nginx-deployment.yaml

      Running another get deployment should confirm the addition of a third replica.

      If you run apply again without modifying the manifest file, Kubernetes will detect that no changes were made and won’t perform any action.

      Using rollout history you can see a list of the Deployment’s previous revisions:

      • kubectl rollout history deployment/nginx-deployment


      deployment.extensions/nginx-deployment REVISION CHANGE-CAUSE 1 <none>

      With rollout undo, you can revert a Deployment to any of its previous revisions:

      • kubectl rollout undo deployment/nginx-deployment --to-revision=1

      Deleting a Deployment

      To delete a running Deployment, use kubectl delete:

      • kubectl delete -f nginx-deployment.yaml


      deployment.apps "nginx-deployment" deleted

      Imperative Management

      You can also use a set of imperative commands to directly manipulate and manage Kubernetes resources.

      Creating a Deployment

      Use create to create an object from a file, URL, or STDIN. Note that unlike apply, if an object with the same name already exists, the operation will fail. The --dry-run flag allows you to preview the result of the operation without actually performing it:

      • kubectl create -f nginx-deployment.yaml --dry-run


      deployment.apps/nginx-deployment created (dry-run)

      We can now create the object:

      • kubectl create -f nginx-deployment.yaml


      deployment.apps/nginx-deployment created

      Modifying a Running Deployment

      Use scale to scale the number of replicas for the Deployment from 2 to 4:

      • kubectl scale --replicas=4 deployment/nginx-deployment


      deployment.extensions/nginx-deployment scaled

      You can edit any object in-place using kubectl edit. This will open up the object’s manifest in your default editor:

      • kubectl edit deployment/nginx-deployment

      You should see the following manifest file in your editor:


      # Please edit the object below. Lines beginning with a '#' will be ignored,
      # and an empty file will abort the edit. If an error occurs while saving this file will be
      # reopened with the relevant failures.
      apiVersion: extensions/v1beta1
      kind: Deployment
      . . . 
        progressDeadlineSeconds: 600
        replicas: 4
        revisionHistoryLimit: 10
      . . .

      Change the replicas value from 4 to 2, then save and close the file.

      Now run a get to inspect the changes:

      • kubectl get deployment/nginx-deployment


      NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 2/2 2 2 6m40s

      We’ve successfully scaled the Deployment back down to 2 replicas on-the-fly. You can update most of a Kubernetes’ object’s fields in a similar manner.

      Another useful command for modifying objects in-place is kubectl patch. Using patch, you can update an object’s fields on-the-fly without having to open up your editor. patch also allows for more complex updates with various merging and patching strategies. To learn more about these, consult Update API Objects in Place Using kubectl patch.

      The following command will patch the nginx-deployment object to update the replicas field from 2 to 4; deploy is shorthand for the deployment object.

      • kubectl patch deploy nginx-deployment -p '{"spec": {"replicas": 4}}'


      deployment.extensions/nginx-deployment patched

      We can now inspect the changes:

      • kubectl get deployment/nginx-deployment


      NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 4/4 4 4 18m

      You can also create a Deployment imperatively using the run command. run will create a Deployment using an image provided as a parameter:

      • kubectl run nginx-deployment --image=nginx --port=80 --replicas=2

      The expose command lets you quickly expose a running Deployment with a Kubernetes Service, allowing connections from outside your Kubernetes cluster:

      • kubectl expose deploy nginx-deployment --type=LoadBalancer --port=80 --name=nginx-svc


      service/nginx-svc exposed

      Here we’ve exposed the nginx-deployment Deployment as a LoadBalancer Service, opening up port 80 to external traffic and directing it to container port 80. We name the service nginx-svc. Using the LoadBalancer Service type, a cloud load balancer is automatically provisioned and configured by Kubernetes. To get the Service’s external IP address, use get:

      • kubectl get svc nginx-svc


      NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nginx-svc LoadBalancer 80:30153/TCP 22m

      You can access the running Nginx containers by navigating to EXTERNAL-IP in your web browser.

      Inspecting Workloads and Debugging

      There are several commands you can use to get more information about workloads running in your cluster.

      Inspecting Kubernetes Resources

      kubectl get fetches a given Kubernetes resource and displays some basic information associated with it:

      • kubectl get deployment -o wide


      NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR nginx-deployment 4/4 4 4 29m nginx nginx app=nginx

      Since we did not provide a Deployment name or Namespace, kubectl fetches all Deployments in the current Namespace. The -o flag provides additional information like CONTAINERS and IMAGES.

      In addition to get, you can use describe to fetch a detailed description of the resource and associated resources:

      • kubectl describe deploy nginx-deployment


      Name: nginx-deployment Namespace: default CreationTimestamp: Wed, 11 Sep 2019 12:53:42 -0400 Labels: run=nginx-deployment Annotations: 1 Selector: run=nginx-deployment . . .

      The set of information presented will vary depending on the resource type. You can also use this command without specifying a resource name, in which case information will be provided for all resources of that type in the current Namespace.

      explain allows you to quickly pull configurable fields for a given resource type:

      • kubectl explain deployment.spec

      By appending additional fields you can dive deeper into the field hierarchy:

      • kubectl explain deployment.spec.template.spec

      Gaining Shell Access to a Container

      To gain shell access into a running container, use exec. First, find the Pod that contains the running container you’d like access to:


      nginx-deployment-8859878f8-7gfw9 1/1 Running 0 109m nginx-deployment-8859878f8-z7f9q 1/1 Running 0 109m

      Let’s exec into the first Pod. Since this Pod has only one container, we don’t need to use the -c flag to specify which container we’d like to exec into.

      • kubectl exec -i -t nginx-deployment-8859878f8-7gfw9 -- /bin/bash



      You now have shell access to the Nginx container. The -i flag passes STDIN to the container, and -t gives you an interactive TTY. The -- double-dash acts as a separator for the kubectl command and the command you’d like to run inside the container. In this case, we are running /bin/bash.

      To run commands inside the container without opening a full shell, omit the -i and -t flags, and substitute the command you’d like to run instead of /bin/bash:

      • kubectl exec nginx-deployment-8859878f8-7gfw9 ls


      bin boot dev etc home lib lib64 media . . .

      Fetching Logs

      Another useful command is logs, which prints logs for Pods and containers, including terminated containers.

      To stream logs to your terminal output, you can use the -f flag:

      • kubectl logs -f nginx-deployment-8859878f8-7gfw9

      Output - - [12/Sep/2019:17:21:33 +0000] "GET / HTTP/1.1" 200 612 "-" "" "-" 2019/09/16 17:21:34 [error] 6#6: *1 open() "/usr/share/nginx/html/favicon.ico" failed (2: No such file or directory), client:, server: localhost, request: "GET /favicon.ico HTTP/1.1", host: "", referrer: "" . . .

      This command will keep running in your terminal until interrupted with a CTRL+C. You can omit the -f flag if you’d like to print log output and exit immediately.

      You can also use the -p flag to fetch logs for a terminated container. When this option is used within a Pod that had a prior running container instance, logs will print output from the terminated container:

      • kubectl logs -p nginx-deployment-8859878f8-7gfw9

      The -c flag allows you to specify the container you’d like to fetch logs from, if the Pod has multiple containers. You can use the --all-containers=true flag to fetch logs from all containers in the Pod.

      Port Forwarding and Proxying

      To gain network access to a Pod, you can use port-forward:

      • sudo kubectl port-forward pod/nginx-deployment-8859878f8-7gfw9 80:80


      Forwarding from -> 80 Forwarding from [::1]:80 -> 80

      In this case we use sudo because local port 80 is a protected port. For most other ports you can omit sudo and run the kubectl command as your system user.

      Here we forward local port 80 (preceding the colon) to the Pod’s container port 80 (after the colon).

      You can also use deploy/nginx-deployment as the resource type and name to forward to. If you do this, the local port will be forwarded to the Pod selected by the Deployment.

      The proxy command can be used to access the Kubernetes API server locally:

      • kubectl proxy --port=8080


      Starting to serve on

      In another shell, use curl to explore the API:

      curl http://localhost:8080/api/


      { "kind": "APIVersions", "versions": [ "v1" ], "serverAddressByClientCIDRs": [ { "clientCIDR": "", "serverAddress": "" } ]

      Close the proxy by hitting CTRL-C.


      This guide covers some of the more common kubectl commands you may use when managing a Kubernetes cluster and workloads you’ve deployed to it.

      You can learn more about kubectl by consulting the official Kubernetes reference documentation.

      There are many more commands and variations that you may find useful as part of your work with kubectl. To learn more about all of your available options, you can run:

      kubectl --help

      Source link

      Getting Started with Dedicated CPUs

      Updated by Linode

      Written by Ryan Syracuse

      This guide will serve as a brief introduction into what a Dedicated CPU Linode is and how to add one to your Linode account. Review our Use Cases for Dedicated CPUs guide for more information about the tasks that work well on this instance type.

      What is a Dedicated CPU Linode?

      In contrast with a Standard Linode, which gives you access to shared virtual CPU cores, a Dedicated CPU Linode offers entire physical CPU cores that are accessible only by your instance. Because your cores will be isolated to your Linode, no other Linodes can schedule processes on them, so your instance will never have to wait for another process to complete its execution, and your software can run at peak speed and efficiency.

      While a Standard Linode is a good fit for most use cases, a Dedicated CPU Linode is recommended for a number of workloads related to high, sustained CPU processing, including:

      Deploying a Dedicated CPU Linode

      Create a Dedicated CPU Linode in the Cloud Manager

      1. Log in to the Linode Cloud Manager.

      2. Click on the Create dropdown menu at the top left of the page, and select the Linode option.

      3. Select a Distribution, One-Click App, or Image to deploy from.


      4. Choose the region where you would like your Linode to reside. If you’re not sure which to select, see our How to Choose a Data Center guide. You can also generate MTR reports for a deeper look at the network route between you and each of our data centers.

      5. At the top of the Linode Plan section, click on the Dedicated CPU tab and select the Dedicated CPU plan you would like to use.

      6. Enter a label for your new Linode under the Linode Label field.

      7. Enter a strong root password for your Linode in the Root Password field. This password must be at least six characters long and contain characters from at least two of the following categories:

        • lowercase letters
        • uppercase letters
        • numbers
        • punctuation characters


        You will not be prompted to enter a root password if you are cloning another Linode or restoring from the Linode Backups service.

      8. Optionally, add an SSH key, Backups, or a Private IP address.

      9. Click the Create button when you have finished completing this form. You will be redirected to the overview page for your new Linode. This page will show a progress bar which will indicate when the Linode has been provisioned and is ready for use.

      Next Steps

      See our Getting Started guide for help with connecting to your Linode for the first time and configuring the software on it. Then visit the How to Secure Your Server guide for a collection of security best practices for your new Linode.

      Find answers, ask questions, and help others.

      This guide is published under a CC BY-ND 4.0 license.

      Source link